「확인 완료」라고 적은 표가 5건 중 5건 모두 틀렸던 이야기

「확인 완료」라고 적은 표가 5건 중 5건 모두 틀렸다

어떤 도구의 실측값을 정리한 기사의 아웃라인을 작성하고 있었다. 소제목은 다음과 같았다.

## 사용 가능한 실측값 (확인 완료)
| 항목 | 값 |
|---|---|
...

과거 세션의 기록에서 수치를 가져와 표로 만들었다. 소제목에 스스로 「확인 완료 (裏取り済み)」라고 적었을 정도이니, 확인을 마쳤다고 생각했다.

기사화 직전에 만일을 위해 코드를 대조해 보았다. 5건 중 5건, 전부 틀려 있었다.

5건 각각 오류의 종류가 다르다. 단순히 "실수로 숫자를 잘못 입력했다"는 한 가지 패턴이 아니다. 전언을 원본으로 취급했다, 한정 조건을 누락했다, 추정치를 단정으로 바꿨다, 명명(Naming)으로부터 내용을 추측했다, 근거가 없는 것을 근거가 있는 것처럼 적었다. 5가지 모두 서로 다른 실패 경로를 거쳤다.

왜 깨닫지 못했는가 — 라벨이 검증을 통과시켜 버렸다

평소라면 수치를 적을 때 "이것이 정말인가"라고 한 번은 의심한다. 하지만 이번에는 의심하지 않았다.

이유는 표의 소제목에 스스로 「확인 완료」라고 적었기 때문이다.

적는 순간, 그 표는 내 안에서 「검증된 영역」으로 분류되었다. 이후에는 참조만 할 뿐, 의심의 대상에서 제외되었다. 라벨을 붙이는 행위 자체가 다음의 나에게 "여기는 이제 안 봐도 된다"라는 신호를 보내고 있었다.

이것은 기존의 두 가지 비판 하네스 (批判ハーネス) 중 어느 것으로도 잡아낼 수 없는 실패였다. 설계 비판 (소크라테스식 문답 · 포퍼의 반증)은 "사양이 요구사항을 충족하는가"를 묻는다. 테스트 비판 (변증법)은 "테스트가 코드를 검증하고 있는가"를 묻는다. 둘 다 결과물의 주장이 증거에 의해 뒷받침되고 있는가를 묻는 메커니즘이 아니다. 여기에 구멍이 있었다.

18개 후보에서 3개를 선택

새로운 비판 하네스를 만들기 위해, 기존 2가지 철학과 중복되지 않는 기준이 필요했다. 후보를 18개 정도 조사하여 다음 3개를 채택했다.

보류한 후보도 있다. 경합 가설 분석 (증거와 가설의 매트릭스)나 악마의 대변인은 기존 2개와의 중복도가 높다는 이유로 탈락시켰다. 다만 선정 메모에는 중복도 평가만 남아 있을 뿐, 구체적으로 어떤 수법과 어떻게 겹친다고 판단했는지까지는 남겨두지 않았다. 나중에 다시 읽어보니 근거를 추적할 수 없게 되었다.

3개에 공통적인 것은, 주장의 진위를 묻기 전에 "애초에 증거로서 채택해도 좋은가"로 걸러내는 발상이다. 소크라테스식 문답이 대화자의 역량에 의존하는 것에 반해, HAZOP의 7가지 단어는 누가 해도 같은 결과가 나온다. 이 점이 기존 하네스와의 결정적인 차이였다.

참고로, 이 다음에 설명할 4단계 중 Phase 4 (확실성 성격 규정)에서 사용하는 GRADE는, 채택한 3개에는 포함되어 있지 않다. 후보 표에는 올라와 있었지만 상위 3개에는 뽑지 않았고, 그러면서도 페이즈에는 채택했다. 선정과 구현이 어긋나 있는데, 선정 메모에 그 경위를 남겨두지 않았다. 증거 취급을 주제로 한 하네스의 설계 기록이 이 지점에서 증거를 결여하고 있다.

증거 비판 하네스의 4단계

Phase 1: 증거 능력 심사

주장을 증거의 강도에 따라 4단계로 분류한다.

원본을 구할 수 있다면 사본이나 전언을 근거로 삼지 않는다. 서두의 「n≥15」는 바로 전언을 원본으로 채택한 유형 그 자체였다.

Phase 2: 이력 비판

출처가 정말 존재하는지 실제로 열어서 확인한다. URL이라면 페치(fetch)하고, 파일이라면 읽는다. 수치는 반드시 원문과 대조한다. "대략 맞다"는 허용하지 않는다.

또 하나 중요한 것이 독립성 판정이다. 여러 소스(Source)가 동일한 수치를 제시하더라도, 같은 오류를 공유하고 있다면 독립적인 뒷받침이 되지 않는다. isnād(전달 경로를 본문과 분리하여 평가하는 사고방식)는 이 경로의 열화를 포착하기 위해 채택했다.

Phase 3: 가이드 워드 소사 (HAZOP)

각 섹션의 의도를 한 문장으로 써 내려가고, 정해진 7개 단어를 기계적으로 대입한다.

서두의 「53%」는 원전의 한정 조건이 누락되어 있었다. 이는 PART OF로 기계적으로 검출할 수 있다. 「최단 140초」라는 단정은 추정치의 격상(Upgrade)이므로 MORE에 해당한다. 떠오르는 문제를 나열하는 것이 아니라, 7개 단어를 전수 조사하는 것이 요점이다.

Phase 4: 확실성 등급 부여

주요 주장을 4단계로 등급을 매기고, 단정적인 어조와 증거의 강도가 일치하는지를 검사한다.

목적은 등급 부여 자체가 아니라 어구의 교정(Proofreading)에 있다.

4단계 프로세스와 별개로, 운용 원칙으로서 **Fagan Inspection의 「찾되 고치지 않는다」**를 최상위에 두었다. 리뷰하는 측에서 친절한 마음으로 수정안을 작성하면, 그 시점에서 사고가 만족되어 남은 검출 작업이 느슨해지기 때문이다.

최초 실행: 정의한 단계 중 3개가 작동하지 않았다

4단계를 리뷰 에이전트(Review Agent)에 구현하여 최초 실행했다. 판정은 「문제 없음」으로 돌아왔다.

출력된 헤드라인을 정의한 단계와 대조해 보았다.

4개 중 3개가 구형 체크리스트에 단계 번호 라벨만 붙인 출력이었다.

이것이 얼마나 아이러니하냐면, 이 에이전트의 정의 자체에 「라벨은 검증의 대체물이 아니다. 라벨이 있는 곳이야말로 의심하라」고 명시했기 때문이다. 그 정의를 가진 에이전트 자신이, 자신의 출력에서 정확히 똑같은 실패를 저질렀다. 「확인 완료」가 검증을 통과시켜 버린 것과 같은 구조가 「Phase 1」이라는 헤드라인에서도 다시 일어난 것이다.

반면 Phase 2만은 기능하고 있었다. 실제 코드를 읽고, 행수를 실제로 세며, 지시하지 않은 검증까지 자발적으로 실시하고 있었다. 단계가 실행되기만 한다면 메커니즘은 작동한다. 문제는 「실행되었는지 여부」를 검출할 수단이 없었다는 점이다.

실질적인 피해도 있었다. Phase 1이 건너뛴 탓에, 어떤 수치의 확인 작업이 사양서와 코드 내 주석(둘 다 복사본)을 대조하는 수준에서 그치고 말았다. 실측 로그라는 원본에는 아무도 접근하지 않았다. 「복사본과 일치함」을 「검증 완료」라고 보고하고 있었다. 복사본의 일치는 「기사가 복사본과 일치한다」는 것만을 증명할 뿐이다.

대책: 단계별로 고유한 성과물을 의무화한다

프롬프트(Prompt)에 절차를 적는 것만으로는 실행되지 않는다는 것이 결론이었다. 각 단계에 고유한 출력물을 의무화했다.

• Phase 1은 증거 계층 분류표를 반드시 출력한다. 표가 없으면 미실행으로 간주한다.
• Phase 3는 7개 가이드 워드 전부를 열거한다. 검출된 것이 없는 단어도 「해당 없음」이라고 적게 한다.
• Phase 4는 등급 표를 반드시 출력한다.
• 「정형 체크」는 Phase 3의 일부이며, Phase 1·4를 대신할 수 없음을 명시한다.

성과물의 부재를 미실행의 증거로 삼는다는 발상이다. 절차의 실행을 선언하게 하는 것이 아니라, 실행하지 않으면 내놓을 수 없는 성과물을 요구하는 것이다.

재테스트: 4단계 모두가 작동했다

대책을 적용하여 재실행했다. 이번에는 프롬프트에서 단계에 대한 지시를 제외했다. 전달한 것은 대상 파일, 소재의 배경, 대조에 사용할 1차 자료의 위치, 그리고 「당신의 정의에 따라 리뷰해 주세요」라는 한 문장뿐이다.

지난번처럼 프롬프트 측에서 단계를 세세하게 지정하면, 정의가 작동한 것인지 프롬프트가 작동한 것인지 분리할 수 없기 때문이다.

4개 모두 결과물과 함께 실행되었다. 프롬프트로 지시하지 않았으므로, 에이전트 정의 (Agent Definition)에 작성한 강제 규칙이 작동했다고 봐도 좋을 것 같다 (1회의 결과이므로 단정하지는 않는다).

나아가, 내가 놓치고 있었던 결함 2건을 검출했다.

첫 번째는 '53%'라는 수치의 취급이었다. 서두에서 언급한 5건 중 하나와 같은 수치이지만, 지적된 결함은 다른 것이다. 5번째 수정에서는 '특정 속성에 한해서라면'이라는 제한 조건을 보완했다. 하지만 기사 본문에서는 그 수치를 마치 자신이 직접 집계하여 관측한 것처럼 쓰는 문체를 그대로 남겨두었다.

리뷰어는 근거가 코드 내 주석(Comment) 한 줄뿐이라는 점을 지적했다. 실제로 grep으로 확인해 본 결과, 산출 스크립트도 계산 로그도 남아있지 않았다. 제한 조건은 수정했지만, 증거의 강도와 문체의 불일치는 수정되지 않았다. 증거는 Moderate 수준인데, 문체는 High 수준이었다.

두 번째는 '대량으로 오분류되었다'라는 기술이다. 오분류가 발생했다는 사실은 주석으로 뒷받침되지만, 양을 나타내는 수치는 어디에도 없었다.

사전에 '추정치 140초를 High로 판정한다면 등급 매기기는 형식화되어 있다'라고 예측했으나, 실제로는 Low로 판정되어 '추정치라고 명기되어 있으며 문구와 증거가 일치함'이라고 올바르게 처리되었다. 등급 매기기 (Grading)는 기능하고 있었다.

일반화된 교훈

라벨 (Label)은 검증의 대체물이 아니다. '확인 완료', '검증 완료', 'Phase 1'이라고 적는 순간, 그 부분은 내 눈에 '더 이상 볼 필요 없는 곳'으로 변한다. 라벨을 붙이는 작업과 검증하는 작업은 별개의 작업이며, 한쪽을 했다고 해서 다른 쪽을 한 것이 되지는 않는다.

같은 실패는, 실패를 방지하기 위한 메커니즘 자체에서도 일어난다. 리뷰 에이전트의 정의에 '라벨은 검증의 대체물이 아니다'라고 적어두었음에도, 그 에이전트의 출력이 똑같은 실패를 저질렀다. 메커니즘을 만들었다는 사실 자체가 면죄부가 되지는 않는다.

'절차를 쓰는 것'과 '절차를 실행시키는 것'은 별개의 문제다. 프롬프트에 4개 페이즈를 적더라도, 실행의 증거가 없다면 무용지물이 된다. 페이즈마다 고유한 결과물을 요구하고, 결과물의 부재를 미실행의 증거로 취급하는 것——이 대책은 적어도 한 번은 기능했다.

다만 근거는 재테스트 1회뿐이라는 점은 명시해두고 싶다. 안정적으로 작동하는지는 횟수를 거듭해 보지 않으면 말할 수 없다. '대책을 마련했다'와 '대책이 작동한다' 사이에도, 이 기사가 문제 삼고 있는 것과 동일한 거리감이 존재한다.

'수정했다'는 검증한 뒤에 써라. 이 기사를 쓰는 과정에서도 하마터면 '재테스트는 아직'이라고 쓸 뻔했다. 수중에 있는 설계 메모에 재테스트 결과를 반영하는 것을 잊었고, 그 메모를 바탕으로 초안이 작성되었기 때문이다. 실제로는 재테스트를 마쳤고 결과도 양호했다. 기록이 오래된 채로 남아 있으면, 솔직하게 쓰려고 노력한 결과로 잘못된 기술이 태어난다.

CI의 초록색 체크, '테스트 완료' 태그, '리뷰 완료' 상태. 라벨이 검증의 대체물이 되는 함정은 이름을 바꾸어 도처에 나타난다.

요약

3층 구조의 하네스 (Harness)를 만든 동기는, 스스로 붙인 '확인 완료'라는 라벨이 검증을 통과시켜 버렸기 때문이었다. 그리고 메커니즘을 만든 직후, 그 메커니즘 자체가 똑같은 실패를 반복했다. 라벨을 붙이는 것과 검증하는 것은 별개의 작업이라는 교훈은, 메커니즘을 만든 측에게도 예외 없이 적용된다.

좋아요와 댓글로 반응해 주시면 큰 힘이 됩니다!

Discussion