세 AI가 똑같이 틀린다: 멀티 AI 코딩 triad 함정과 해결

아키텍처 결정을 앞두고 Claude 하나만 믿기가 불안할 때가 있다. 나는 결제 모듈 리팩토링을 앞두고 "혼자 판단한 LLM이 틀리면 며칠을 날린다"는 생각에, Claude·Codex·Gemini 세 모델에게 같은 설계 문제를 던졌다. 셋 다 거의 똑같은 답을 냈고 "만장일치니까 맞겠지" 하고 그대로 갔다. 결과는? 셋 다 코드베이스의 비명시 규약 하나를 똑같이 놓쳤고, 머지 후에야 터졌다. 그날 배운 게 이 글의 핵심이다 — 멀티 AI 교차검증은 강력하지만, 가장 위험한 함정은 "세 AI가 똑같이 틀리는 것"이다.

triad란 무엇인가 — 모델 다양성이 핵심

triad는 서로 다른 회사의 서로 다른 LLM(Claude, OpenAI Codex, Google Gemini/Antigravity)을 같은 문제에 독립적으로 투입하고, 산출물을 비교해 합의·불일치·고유 통찰을 가려내는 교차검증 방법론이다. 같은 모델의 내부 서브에이전트를 여러 개 돌리는 것과 본질이 다르다. 같은 모델은 같은 편향을 공유하므로 아무리 여러 개 돌려도 "직교한 시선"이 안 나온다. triad가 노리는 건 바로 그 모델 다양성이다.

핵심 가치는 "다른 회사가 만든 다른 모델이라면 서로 다른 실수를 할 것"이라는 가정이다. 그런데 이 가정이 깨지는 순간이 가장 위험하다.

실전 워크플로는 크게 둘로 갈린다.

• Planning Mode: 코드 작성 전, 세 모델의 설계안을 합성한다.
• Verification Mode: 코드 작성 후, diff/PR을 세 모델에게 교차 리뷰시킨다.

운영 규칙은 단순하다. 동일 입력, 라운드 1회 제한, 출력 파일 분리, 2/3 합의 표기. 이 글에서는 실무에서 실제로 부딪히는 네 가지 함정을 메시지·원인·해결 단계로 풀어본다.

참고: 아래 나오는 triad, agy(Antigravity), codex exec, 2/3 합의 같은 구체 명칭과 CLI 플래그는 일반 공개 표준이 아니라 이 환경 고유의 운영 컨벤션이다. 다른 팀은 다른 이름·도구로 같은 발상을 구현한다(예: 오픈소스 zen-mcp의 consensus 기능). 개념은 보편적이지만 명령어는 본인 환경에 맞게 읽으면 된다.

함정 1. 상관 오류 — 세 AI가 똑같이 틀린다

가장 비싼 함정이다. 콘솔에 에러 메시지가 안 뜬다는 게 문제다.

(콘솔 메시지 없음)
세 모델 결과가 '만장일치'로 보여 그대로 채택했는데,
실제로 동작하지 않거나 코드베이스 비명시 규약을 위반한다.

왜 생기나

최신 연구상 성능이 높은 모델일수록, 그리고 학습 데이터·아키텍처를 공유하는 모델일수록 오류가 수렴한다. arXiv의 "Great Models Think Alike"(2502.04313) 등 2025~2026 논문은 LLM 간 오류 상관(correlated error)을 정량적으로 다룬다. 만약 모델 간 오류 상관이 r=0.77이라면, 한 모델 오류 분산의 약 59%가 다른 모델과 공유된다. 그러면 세 개를 물어도 통계적으로 독립적인 "효과적 앙상블 크기"가 3이 아니라 약 1.3에 불과할 수 있다.

즉 2/3 합의가 독립 검증이 아니라 공유 편향의 증폭일 수 있다는 뜻이다. 한 에이전트의 환각이 다운스트림 에이전트에 "전제"로 수용되면, 상관 실패는 사실상 검출 불가능해진다.

주의: r=0.77, 앙상블 크기 1.3, 분산 59% 공유 같은 수치는 일반 연구 경향을 인용한 것이지 이 특정 3종 모델 조합에 그대로 측정된 값이 아니다. 실제 상관도는 모델 버전과 과업에 따라 다르다. 핵심은 "숫자"가 아니라 "합의가 독립 검증을 보장하지 않는다"는 방향성이다.

해결 단계

1. 2/3 합의를 '정답'이 아니라 '신뢰도 가중치'로만 취급한다. 합성한 plan·리뷰에서 합의 항목도 반드시 별도 라벨(만장일치 / 2-3 합의 / 단독)로 표기해 최종 판단은 사람이 한다.
2. 합의가 났어도 실행 후 반드시 기계 검증을 건다. 변경 서비스의 tsc/lint/test, npm test, 실제 런타임 헬스체크. 세 모델이 모를 수 있는 코드베이스 비명시 규약은 코드가 잡아낸다. (이게 내가 결제 모듈에서 놓친 부분이다.)
3. 에이전트끼리 서로의 출력을 입력으로 먹이지 않는다(라운드 1회 제한). 각자 원본 문제만 독립적으로 풀게 해 오류 전파 사슬을 끊는다.
4. 단독(소수) 의견을 버리지 말고 'open question'으로 남긴다. 다수가 공유한 블라인드 스팟을 소수 모델이 짚는 경우가 상관 오류의 거의 유일한 탈출구다.
5. 정말 중요한 결정엔 의도적으로 이질적인 관점을 배정한다. supportive / critical / neutral 역할을 나눠 시선의 직교성을 강제하는 방식(zen-mcp consensus가 쓰는 접근)이 도움이 된다.

함정 2. 동일 입력 원칙 위반 — 비교 자체가 깨진다

(메시지 없음)
세 산출물의 결론이 제각각이라
합의/불일치 구분이 불가능해진다.

왜 생기나

각 피어에게 프롬프트를 조금씩 다르게 주거나(컨텍스트 누락, 표현 변형), 피어가 못 읽는 파일을 본문에 안 붙이면, 세 모델은 사실상 **"다른 문제"**를 푼다. 그러면 결과의 불일치가 모델 다양성 신호인지 입력 차이 때문인지 구분할 수 없다. 교차검증의 전제 자체가 무너진다. 게다가 세 모델 stdout을 한 곳으로 합치면 출력이 인터리브되어 어느 의견이 누구 것인지 추적조차 안 된다.

해결 단계

1. 공유 프롬프트를 파일 하나로 작성하고 세 에이전트에 글자 그대로 동일하게 전달한다. 피어별 커스터마이즈 금지.

   PROMPT="$(cat /tmp/shared-prompt.txt)"
   agy   -p "$PROMPT" --add-dir "$REPO" > /tmp/agy.out 2>&1 &
   codex exec "$PROMPT"                 > /tmp/codex.out 2>&1 &
   # Claude는 같은 PROMPT로 동시에 독립 분석
   wait
   

2. 프롬프트에 자기완결적 컨텍스트를 넣는다. 리포 루트, 관련 CLAUDE.md, 관련 docs, 비명시 제약(언어 기본값, fail-closed 가드 등). 피어가 못 읽는 파일은 본문에 직접 paste한다.
3. 출력은 반드시 별도 파일로 분리한다(> /tmp/agy.out, > /tmp/codex.out). 인터리브를 막고 출처를 보존한다.
4. 출력 포맷을 프롬프트 끝에서 강제한다. "번호 매긴 목록만, 서두·맺음말 금지, 언어 고정, 발견사항 1줄 = [file:line](심각도) 설명". 포맷이 통일돼야 자동 대조가 가능하다.
5. Planning과 Verification을 섞지 않는다. 코드 존재 여부로 모드를 명확히 가른다 — 코드 작성 전엔 설계 합성, 후엔 diff 리뷰.

구분	Planning Mode	Verification Mode
시점	코드 작성 전	코드 작성 후
입력	문제·제약·목표	diff / PR
출력	합성된 설계안	발견사항 목록(심각도)
합의 표기	만장일치/2-3/단독	2/3 이상이 짚은 이슈 우선
다음 행동	사람이 설계 확정	기계 검증 후 머지

함정 3. 비용·지연 폭증 — 자명한 작업에 풀가동

(메시지 없음)
세 CLI 동시 호출로 토큰비/대기시간이 단일 대비 3배+,
오타 한 줄 고치는데 수 분 대기.

왜 생기나

세 에이전트 풀가동은 토큰 비용과 지연이 곱으로 늘어난다. reasoning high / extended context 모델은 더 비싸다. 단순 작업(오타, 한 줄 수정, 단순 질문)에 triad를 쓰면 오버헤드가 가치를 초과한다. 직렬로 호출하면 대기시간이 합으로 쌓인다. zen-mcp consensus도 컨텍스트 예산을 medium(8K)에서 high/max로 올릴수록 비용이 급증한다.

특히 GPT-4.1급 모델에서 분석 1회 비용이 AdSense 1노출 수익을 가뿐히 넘는다는 건 우리 프로젝트 운영에서도 확인된 단위경제다. 비용 감각 없이 triad를 남발하면 그냥 돈을 태우는 거다.

해결 단계

1. 발동 게이트를 좁힌다. 아키텍처/스키마 결정, 멀티파일 리팩토링, 근본원인 불명 버그, 머지 직전 PR 리뷰, 인프라/마이그레이션처럼 "놓치면 비용 큰" 비자명 작업에서만 호출한다. 단순 작업은 Claude 단독으로 끝낸다.
2. 두 피어를 병렬 백그라운드로 디스패치해 총 대기시간을 max(agy, codex)로 줄인다(직렬 합산 금지). 그 사이 Claude도 독립 분석을 동시에 한다.
3. 라운드를 1회로 제한한다. 왕복할수록 수렴이 아니라 발산하고 비용만 증가한다.
4. 컨텍스트 예산을 작업 중요도에 맞춰 단계화한다. 일반은 medium, 아키텍처 결정만 high/max. 전체 코드베이스 투입이 필요할 때만 대용량 컨텍스트 모델에 위임한다.
5. 탐색만 필요할 땐 Exploratory 서브모드(union 출력, 합의 강제 없음)로 가볍게 운용한다.

함정 4. CLI 환경 불일치 — PATH 누락·버전 드리프트·모델 미고정

command not found: agy
codex: command not found
(또는 의도와 다른 모델로 답해 결과 품질 저하)

왜 생기나

사용자 인터랙티브 셸은 ~/.local/bin을 PATH에 넣지만, 자동화 자식 셸은 이를 못 받을 수 있다. 그래서 which agy만 보고 "없다"고 오판한다. 또 agy에는 --model 플래그가 없어 모델이 settings.json에 영속되므로, 고정하지 않으면 세션마다 다른 모델로 답할 수 있다. 버전이 오래되면 옵션·동작이 달라져 결과가 흔들린다.

해결 단계

1. PATH 가드를 둔다. 못 찾으면 즉시 보고하고 중단한다 — 단일 에이전트로 몰래 폴백하지 않는다.

   AGY=$(command -v agy   || echo "$HOME/.local/bin/agy")
   CODEX=$(command -v codex || echo /opt/homebrew/bin/codex)
   [ -x "$AGY" ]   || { echo "agy 실행 불가 — 중단"; exit 1; }
   [ -x "$CODEX" ] || { echo "codex 실행 불가 — 중단"; exit 1; }
   

2. 매 세션 첫 호출 시 버전 확인 후 업데이트를 best-effort로 적용한다. 업데이트 실패는 hard-fail이 아니라 "현재 vX.Y.Z로 진행" 한 줄로 명시한다.
3. 모델을 고정한다. agy는 ~/.gemini/antigravity-cli/settings.json의 model 키에 원하는 라벨로 강제 고정한다(라벨은 TUI /settings 표기와 정확히 일치해야 함). codex는 ~/.codex/config.toml 또는 -m로 지정한다.
4. 비대화(헤드리스) 모드를 정확히 쓴다. agy는 -p '프롬프트' --print-timeout 10m --add-dir <경로>, codex는 codex exec '프롬프트'. 깊은 조사는 timeout을 10분 이상으로 둔다.
5. 피어 타임아웃·실패 시 남은 결과로 진행하되 합성 결과에 "해당 피어 누락"을 정직하게 명시하고 빠진 의견을 지어내지 않는다.

모델 버전명(예: gpt-5.5, Gemini 3.5 Flash 등)이나 일부 제품 기능 명칭·날짜는 환경 설정값·웹 요약 기반이라 버전에 따라 다를 수 있다. 실제 가용성은 본인 환경에서 확인하는 게 맞다.

실전 팁 — Do's & Don'ts

Do (이렇게)	Don't (이러지 말 것)
비자명·고비용 작업에만 triad 발동	오타·한 줄 수정에 세 모델 풀가동
합의도 라벨링 후 사람이 최종 판단	"만장일치 = 정답"으로 그대로 채택
합의 후에도 tsc/lint/test로 기계 검증	LLM 합의만 믿고 머지
동일 프롬프트를 파일로 그대로 전달	피어별로 프롬프트를 조금씩 변형
출력을 피어별 파일로 분리	stdout 한 곳에 합쳐 인터리브
두 피어 병렬 + 라운드 1회	직렬 호출 + 무한 왕복
소수 의견을 open question으로 보존	다수와 다르다고 소수 의견 폐기
피어 실패 시 누락을 정직하게 명시	빠진 피어 의견을 지어내기

한 줄 더: "검증을 검증으로 끝내지 마라"

triad의 산출물은 어디까지나 사람이 결정하기 위한 입력이다. 합의는 신뢰도를 높여줄 뿐 정답 도장이 아니다. 실제 안전망은 두 가지다 — (1) 기계 검증(테스트·타입체크·런타임 헬스체크), (2) 사람의 최종 판단. 이 둘이 빠지면 triad는 "세 배 비싼 확신"만 만들어낸다.

내부 서브에이전트와 헷갈리지 말자. 같은 모델 서브에이전트는 같은 편향을 공유하므로 직교한 시선이 안 나온다. triad의 가치는 오직 모델 다양성에서 온다 — 그리고 그 다양성이 깨지는 순간(함정 1)이 가장 위험하다.

마무리 — 요약과 다음 행동

멀티 AI 교차검증은 비자명 결정에서 분명히 가치가 있지만, 운영 규칙 없이 쓰면 "세 배 비싼 동조 현상"이 된다. 핵심만 다시 정리한다.

• 함정 1(상관 오류): 합의는 신뢰도 가중치일 뿐. 반드시 기계 검증 + 사람 판단으로 닫는다.
• 함정 2(입력 불일치): 동일 프롬프트 파일, 자기완결 컨텍스트, 출력 파일 분리, 포맷 강제.
• 함정 3(비용·지연): 발동 게이트를 좁히고 병렬·1라운드·컨텍스트 단계화로 통제한다.
• 함정 4(CLI 환경): PATH 가드·모델 고정·헤드리스 플래그·정직한 누락 표기.

다음 행동으로는, 우선 본인 워크플로에서 "triad를 켤 작업"과 "Claude 단독으로 끝낼 작업"의 게이트부터 종이에 적어보길 권한다. 그다음 공유 프롬프트 템플릿 한 장과 기계 검증 스크립트(테스트+타입체크) 하나만 갖춰도 함정의 절반은 막힌다.

더 읽을거리로, AI 코딩 도구의 운영 마찰과 에러 핸들링을 다룬 다른 글도 함께 보면 좋다. 블로그 전체 글 목록에서 AI 도구 활용 카테고리를 둘러보거나, 실전 팁 모음에서 비슷한 운영 노하우를 찾아볼 수 있다. Claude API를 직접 호출하다 과부하 에러를 만난다면 Claude API 529 Overloaded 에러 처리 글이 도움이 된다.

외부 권위 출처:

• 오류 상관 연구 — Great Models Think Alike (arXiv 2502.04313)
• 멀티 모델 consensus 오픈소스 — zen-mcp-server (GitHub)
• Anthropic의 멀티에이전트 설계 관점 — Building effective agents (Anthropic)

세 모델이 같은 답을 줬다고 안심하지 말자. 그게 가장 비싼 함정이다.