두 AI가 같은 답을 골랐다 — 값어치는 그 답 속의 틀린 추론을 잡은 것

2026-06-05 · Ascendy Engineering

TL;DR

인프라 결정 하나를 두고 Claude와 Codex가 독립적으로 같은 옵션에 도달했다. 보통이라면 “합의 끝, 진행”이다.
그런데 둘째 AI(Codex)의 진짜 값어치는 결론에 반대한 게 아니었다. 같은 답을 골랐으면서도, 그 맞는 답을 떠받친 두 개의 틀린 추론을 잡아냈다.
틀린 추론 ①: 안전장치의 명분을 틀린 인과(“이 스크립트가 과거 인시던트를 냈다”)에 매달았다. ②: 안전장치가 이름뿐(“주석 달면 충분”)이라 실행 경로를 못 막았다.
교훈: second reviewer를 “답이 맞나 검산”으로만 쓰면 이걸 놓친다. 답이 맞아도 load-bearing 추론은 틀릴 수 있다. adversary의 값어치는 결론 반대가 아니라 맞는 답 속 추론 감사다.

소스 노트. 이 글은 인프라 팀의 Tier 3 결정문(두 에이전트의 verbatim 의견 + 합의가 박제된 기록)을 1차 소스로 한다(정제본 경로는 frontmatter sourceIntake 참조). 무엇을 결정했나는 별도 글 한 번에 안 지운 이유 — 두 곳에 정의된 워크로드가 다룬다. 이 글은 다른 층 — 그 결정에 이른 두 AI 토론의 epistemics다. 클라우드 provider·워크로드·스크립트·플래그 실명은 일반화했다. 두 번째 AI를 어떻게 부르고 언제 멈추나의 구체 사례편이기도 하다.

합의로 끝날 뻔한 결정

상황은 흔한 인프라 정리였다. 같은 프로덕션 워크로드 12개가 두 곳에 정의돼 있었다 — raw Kubernetes 매니페스트와 chart 템플릿. 둘이 평행하게 자라면서 어느 쪽이 권위인지 선언된 적이 없었다. 정리해야 했다.

세 옵션이 있었다. (A) chart를 권위로 선언하고 raw 매니페스트 12개를 한 PR에서 동시 삭제, (B) raw를 권위로 격상, (C) 전환형 — chart를 권위로 선언하되 raw는 “배포 금지”로 마킹하고 레거시 직접변경 경로에 게이트를 걸어두고, 실제 삭제는 후속 단계로 미룬다.

두 AI에게 독립적으로 의견을 물었다. Claude도 Codex도 같은 답을 냈다 — C(전환형)를 즉시 택하고, A(완전 정리)를 최종 목표로. B는 둘 다 탈락시켰다(지난 분기 chart에 쌓인 안전장치들이 chart 도구의 hook/release 의미론에 의존해, raw로는 재구현이 불가능하니까).

여기서 끝났어야 정상이다. 두 명의 시니어가 독립적으로 같은 결론 → 강한 신호 → 진행. 실제로 옵션 선택은 그대로 갔다. 그런데 토론의 값어치는 이 합의가 아니라, 그 다음에 있었다.

같은 답, 갈린 추론

Codex는 C에 동의하면서도 Claude의 추론 두 군데를 꺾었다.

① 인과 교정. Claude는 레거시 배포 스크립트의 직접변경 경로를, 과거 한 이미지-태그 회귀 인시던트의 *“2차 원인”*처럼 프레이밍했다. Codex가 막았다:

그 인시던트의 root는 chart values의 stale default와 값 재사용(reuse) 옵션의 상호작용이다. 배포 스크립트가 아니다. 스크립트는 다른 축의 위험 — 추적되지 않는 직접 변경이 release 상태와 cluster 상태를 어긋나게 하는 드리프트 — 이다. “스크립트가 그 인시던트를 냈다”고 overclaim하지 마라.

옵션은 똑같이 C인데, C를 정당화하는 근거가 틀렸다는 지적이었다.

② 물렁한 안전장치 거부. Claude는 raw 매니페스트를 “배포 금지”로 막는 데 헤더 주석이면 충분하다고 봤다. Codex가 거부했다:

주석은 파일을 열어야 보인다. 그런데 스크립트의 변경 호출은 파일을 안 열어도 실행된다. 주석으론 apply를 못 막는다. 실행 가능한 하드게이트를 지금 박아라 — 명시적인 operator 확인 없이는 build·push·변경에 닿기도 전에 종료되도록.

crux — 답이 아니라 근거가 틀렸다

이게 핵심이다. 두 AI는 무엇을 할지에 동의했다. 갈린 건 왜와 얼마나 단단히였다.

옵션 선택이 같아도 추론은 갈릴 수 있고, 종종 그 갈린 추론이 진짜 이야기다. Claude의 결론(C)은 옳았다. 하지만 그 결론을 떠받친 두 근거에 결함이 있었다:

과대 인과 — 안전장치의 명분을 틀린 인과에 매달았다. 근거가 틀리면, 누군가 “그 인시던트는 사실 다른 원인이었다”고 반박하는 순간 안전장치의 명분이 통째로 흔들린다. 옳은 장치가 틀린 이유로 서 있으면, 그 이유가 무너질 때 장치도 같이 의심받는다.
이름뿐인 안전장치 — “주석이면 충분”은 실행 경로를 못 막는, 이름뿐인 방어였다.

둘 다 맞는 답(C) 안에 들어앉은 결함이다. 그래서 “답이 맞나?”만 보는 리뷰로는 안 잡힌다. C가 맞는지만 검산했다면 둘 다 통과했을 것이다.

수렴 — 두 반박을 모두 채택

합의문은 Codex의 두 반박을 모두 받았다:

안전장치의 정당화를 드리프트 위험 자체로 갈아끼웠다. “스크립트가 과거 인시던트를 냈으니 막는다”가 아니라, “추적되지 않는 직접 변경이 release/cluster 드리프트를 만드니 막는다.” 명분이 틀린 인과에서 분리되니, 인과 논쟁과 무관하게 단단해졌다.
헤더 주석을 실행 가능한 하드게이트로 격상했다. 결정문에 “load-bearing 안전은 파일의 존재나 주석이 아니라 게이트”라고 못 박혔다.

두 의견은 결정문에 verbatim으로 남아, 나중에 누구든 이 합의가 어떻게 만들어졌는지 audit할 수 있다.

가져갈 것

second reviewer를 “답 검산기”로만 쓰지 마라. 둘이 같은 답을 내도, 그 답을 떠받친 추론은 틀릴 수 있다. adversary의 진짜 값어치는 결론 반대가 아니라 맞는 답 속 load-bearing 추론 감사다.
adversary가 잡는 두 전형: ① 결론은 맞는데 근거가 틀린 경우(인과 overclaim) ② 결론은 맞는데 대책이 약한 경우(주석 vs 실행 게이트). 둘 다 “답이 맞나?” 리뷰를 통과해 버린다.
안전장치의 명분을 틀린 인과에 매달지 마라. 명분이 흔들리면 장치도 흔들린다. 옳은 대책은 옳은 이유 위에 세워라.
합의는 토론의 끝이 아니다. 두 명이 같은 결론에 도달한 바로 그 지점에서, 그 결론의 근거를 한 번 더 의심하는 게 second reviewer의 일이다.

저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.

Tags: ai-collaboration, adversarial-review, decision-making, code-review, reasoning