자신의 테스트를 통과해버린 버그를 다른 벤더의 AI가 찾아냈다

추출 정밀도를 측정하는 측정기 코드를 작성했다. 자체 테스트는 16건, 전부 통과(Green). 출하했다고 생각했다.

만약을 위해 OpenAI의 Codex CLI에 "적대적으로 리뷰하라"고 던졌더니, 7건의 결함이 돌아왔다. 전건에 재현 입력이 포함되어 있었다. 실제로 실행해보니, 전건이 진짜였다.

중요한 것은, 이 코드를 작성한 것도 AI(내 환경에서는 코드를 Claude가 작성하게 함)였다는 점이다. 작성자의 테스트는 작성자의 맹점을 공유한다 —— 작성자가 AI라 하더라도, 인간의 코드 리뷰에서 예전부터 말해왔던 일이 그대로 일어난다. 게다가 측정기의 버그는 이후의 측정을 조용히 오염시키기 때문에, 일반적인 버그보다 질이 나쁘다.

같은 일이 본방(Production) 코드에서도 일어났다. 고객의 업무를 돌리는 실제 코드를 동일하게 리뷰하게 했더니, 금액 파서(Parser)에 이런 버그가 잠재되어 있었다:

# 란식 표기 '1.250,00' (= 1250.00)을 영미식으로 읽어 '1.25'로 해석
# (문자열 입력 시에만 해당 · 수치 셀은 타입 가드로 무사함) → 금액을 1000분의 1로 잘못 읽음 (1000배 과소 측정)

최근 10일 정도, "다른 벤더의 AI끼리 검증하게 하는" 운용을 구축하고, 전부 대장에 기록해 왔다. 이 기사는 그 실록이지만——솔직히 실패 사례를 포함해서 작성한다.

이 기사에서 쓰지 않는 것

Claude Code × Obsidian의 연계나, Codex 플러그인을 통한 상호 리뷰 시작 방법은 이미 좋은 기사가 많이 있다. 파이프라인(배관) 이야기는 하지 않는다.

쓰고자 하는 것은 파이프라인 너머, 2개 이상의 AI를 연결한 사람이 다음에 마주하게 될 질문이다:

그 판정자(리뷰하는 AI)의 말을 어디까지 믿어도 되는가?

운용의 핵심은 3줄

시행착오 끝에 운용 규칙을 명문화했다. 핵심은 3가지다.

교정되지 않은 찬성은 고무인(Rubber stamp)이 되기 쉽다. 반대가 정보량이 더 높다. AI는 동의하기 쉬우며, "리뷰를 시켰더니 OK였다"는 품질의 증거가 되지 않는다. 피검 시스템의 실패율이 10%라면, "항상 OK"라고만 말하는 판정자라도 일치율은 90%가 된다. 측정해야 할 것은 일치율이 아니라, 나쁜 것을 나쁘다고 말할 수 있었던 비율(TPR)이다. -
작성자와 다른 마음(Mind)을 보여준다 —— 가능하면 다른 벤더로. 여기서 말하는 "마음(mind)"은 리뷰하는 단위이다 —— 같은 회사의 다른 모델도, 다른 벤더의 모델도, 때로는 인간인 나도 각각 하나의 마음이다. 모델 패밀리 레벨의 자기 선호 편향(Self-preference bias)이 보고되고 있으므로, 독립성을 높이고 싶은 상황에서는 다른 벤더도 사용한다. 다만, 벤더 차이만의 효과는 우리의 실험에서 아직 확정되지 않았다. 효과가 있는 것은, 판정력을 사전에 검정한 마음의 반대다(아래에서 "면접"에 대해 이야기한다). -
최종 판단은 인간. AI의 다수결로 결정하지 않는다. 판정이 갈리면 다수결로 뭉개지 않고 인간에게 에스컬레이션(Escalation)한다. 의견 차이는 증거 그 자체가 아니라, 조사를 시작하라는 신호다.

그리고 모든 검증 이벤트를 대장에 한 줄씩 기록한다: 날짜 · 대상 · 작성자(어떤 AI) · 검증자(어떤 AI · 어떤 조건) · 결과. 기록해보니, 포착된 대부분은 작성자와 다른 마음에서 나오고 있었다[1]. 다만 이것은 대조군이 없는 운용 기록이며, 성과 지표로 읽을 것은 아니다.

실록: 대장에서

판정자를 "면접"했더니 불합격이었다

Gemini를 판정자로 검토했을 때, 채용 전에 면접을 실시했다. 올바른 주장과, 그것을 미묘하게 반전시킨 거짓 주장을 섞어서 판정하게 하여 변별력을 측정한다.

결과는 불합격. 반전된 거짓 주장에 대한 동의율이 60%(= 거짓 과반수에 찬성)였으며, 변별력은 로컬 8B 모델과 비슷한 수준이었다. 20달러의 추가 계약을 약 100엔의 API 호출 비용으로 거를 수 있었다. 판정자는 채용 면접을 거친 뒤 사용한다 —— 인간의 채용과 마찬가지로, 이력이 아니라 실제 업무로 측정한다.

벤더를 넘나들며 관통하는 거짓말이 있었다

교정 테스트에서, 판정에 사용한 AI(이때는 Codex와 Gemini)가 둘 다 간파하지 못하는 거짓 주장의 유형을 발견했다: "숫자 + 통계 용어 + 신중한 문체"로 작성된 거짓말이다. "n=◯◯, 하한만 확정"과 같은 식으로 쓰면, 신중함이 신뢰성의 단서로 잘못 작용하게 된다.

이것이 "모든 AI에게 공통되는 맹점"이라고 단정하기에는 아직 이르다 (자극이 한 종류뿐이며, 문체·숫자·출처 유무와 같은 요인들이 분리되지 않았다 —— 이 신중함 자체가 이 기사의 주제이기도 하다). 다만 운영 규칙에는 한 줄을 추가했다: 수량적인 주장은 AI가 몇 대나 찬성하더라도 증거가 되지 않는다. 출처가 실제로 존재하는지뿐만 아니라, 그 출처가 해당 수치와 함의까지 실제로 지지하고 있는지를 단계별로 대조할 때까지 보류한다. "실재하는 논문"을 언급하기만 하고 정작 중요한 숫자는 지지하지 않는 식의 위장은, 실재 확인만으로는 통과될 수 있다.

문서는 단독으로는 옳아도 세트로 보면 모순된다

운영 규칙 문서 자체(6개 문서)를 Codex에 횡단 감사(Cross-audit) 시켰더니 10건의 지적이 나왔고, 그중 2건이 진짜 모순이었다. 입구 문서에서는 "항상 최신"이라고 단언하고 있는데, 다른 문서는 "날짜를 보고 확인하라"고 가르친다 —— 단독으로는 둘 다 옳지만, 세트로 읽으면 독자를 반대 방향으로 유도한다. 단독 리뷰로는 보이지 않는 결함 클래스이며, 이는 정기적인 검진으로서 계속할 가치가 있다고 느꼈다.

도구 상자 (복사/붙여넣기용)

Codex를 판정자로 비대화(Non-interactive) 방식으로 호출한다 (ChatGPT 구독 범위·API 과금 없이 작동하던 시기가 있었다. 과금은 각자 확인):

codex exec --ephemeral --sandbox read-only --skip-git-repo-check \
-c model_reasoning_effort="high" \
--output-schema schema.json -o result.json \
...

• --output-schema로 JSON 출력을 강제 (모든 프로퍼티를 required에 넣지 않으면 400 에러 발생) - "실행되지 않았다"와 "실행했으나 NG였다"를 구분한다 (fail-open으로 두지 않는다).
• 전송 전 비밀 스캔(Secret scanning), 받은 지적은 결정론적으로 재확인(재현 입력을 실제로 실행), 인용의 실재 확인(존재하지 않는 행 번호를 인용하는 지적은 기각).
• 새로운 운영 규칙에는 퇴출 조건을 한 줄 덧붙인다 ("◯◯가 2분기 동안 발생하지 않으면 삭제 후보"). 이것이 없으면 규칙은 늘어나기만 하고, 결국 아무도 전부 지킬 수 없게 된다.

고백: 이 기사도 자신의 조문에 걸려들었다

마지막으로, 가장 솔직한 부분을 쓰겠다.

이 기사의 초안에는 "기사 중의 수치는 모두 원장(Ledger)의 실제 기록입니다"라고 적혀 있었다. 만일을 위해 초안을 다른 벤더의 AI에게 원장과 한 줄씩 대조하게 했더니 —— 기간도 건수도 어긋나 있었다. "2개월"은 실제로는 10일 정도였고, "누적 ◯건"은 결함의 개수로 세고 있었는데 그것이 망가져 정확한 값을 복원할 수 없었다 (결국 개수 복원은 포기하고, "리뷰가 몇 번 기능했는가"의 횟수로 정의를 바꿨다 —— 앞서 언급한 17회는 그것이다). 구체적인 사례의 버그는 다른 사건과 혼선되었고, 금액 차이의 배율까지 잘못 파악하고 있었다.

더 싫었던 점은, 그 어긋남이 출처 없는 AI 리뷰로는 잡히지 않았다는 것이다. 초안을 작성한 AI도, 그것을 리뷰한 AI도 놓쳤다. 잡아낸 것은 원장을 전달받아 한 줄씩 대조한 AI였다 —— "어떻게 생각해?"라고 의견을 묻는 것이 아니라, 주장을 출처와 기계적으로 맞붙이는 감사(Audit)로 돌렸을 때만 나타났다. 게다가 한 번으로 끝나지 않고, 두 번째 AI에게 다시 세게 했더니 그 재집계에서도 오류가 발견되었고, 그것을 세 번째 눈이 잡아냈다.

즉 이 기사가 설파하는 "수량은 AI의 찬반이 아니라 출처 대조로 확인하라"라는 내용에, 이 기사 자체가 걸려들었던 것이다. 수정한 뒤에 이 단락은 남겨두기로 했다 —— 이보다 더 정직한 실례는 없기 때문이다.

알게 된 것, 아직 모르는 것

솔직하게 경계를 그어둔다. 이 기사는 "완성된 방법론"이 아니라, 재현 가능한 실패 기록이다.

알게 된 것

• 다른 모델의 적대적 리뷰(Adversarial review)는, 작성자의 테스트를 통과한 실제 버그를 잡아낼 수 있다 (측정기에서도, 운영 코드에서도).
• 다만, 리뷰하는 AI 자체의 변별력은 사용하기 전에 측정할 필요가 있다.
• 수량과 인용의 정확성은 AI의 찬반이 아니라, 원전과의 한 줄 대조로만 확인할 수 있다.

아직 모르는 것

• 이 운영이 "단일 AI + 인간 리뷰"보다 비용 효율 면에서 우수한가 —— 대조군을 설정하지 않았다.
• 벤더를 나눈 것 자체가 얼마나 효과가 있는가.
• 다른 사람의 환경에서도 재현되는가.

위의 "아직 모르는 것"이 채워지기 전까지는, 성공담이 아니라 실패 보고서로 읽어주길 바란다.

맺음말

"AI를 조합해 보았다"의 다음 질문은, **"그 판정자, 검정(Validation) 하셨습니까?"**라고 생각한다.

장부를 기록하기 시작하면 세상이 보이는 방식이 조금 달라진다. AI의 찬성(Pros)은 점점 값싸게 느껴지고, **판정력(Judgment power)을 검정(Validation)한 모델의 반대(Cons)**는 가치 있게 느껴지기 시작한다. 그리고 주목해야 할 점은 그러한 모델들 사이의 **불일치(Discrepancy)**다. 불일치는 그 자체로 증거는 아니지만, 어느 한쪽(또는 양쪽 모두)의 사각지대를 의심하고 조사하기 시작하라는 신호다.

공개: 이 기사는 여러 AI를 사용한 실제 운영 과정 자체를 바탕으로 작성되었다. 초안은 Claude(fable)가 작성했고, 대안과 리뷰는 OpenAI의 Codex가 제시했으며, 통합과 장부 대조는 Claude(opus)가 수행하였고, 필자가 검증 및 편집하였다. 위의 '자백' 단락은 그 과정에서 실제로 일어난 일에 대한 기록이다. 어떤 AI가 무엇을 썼는지 항상 남겨두는 것이 이 운영 규칙 중 하나이다.

이벤트 단위(1 리뷰 = 1건, findings가 몇 개든 1건)로 계산하면, 저자와 다른 마음(AI)에 의한 확정 포착이 17회, 귀속을 확정할 수 없는 것이 3회, 저자 자신에 의한 포착이 3회였다. 분모도 대조군도 없으므로, 우열의 증거가 아닌 경향성을 기록하는 차원에서 게재한다. ↩︎

Discussion