제일 믿을 만한 AI는 한 놈이 아니었다 — 크로스 에이전트 리뷰가 일상으로 온 이유

코덱스가 파서 코드를 짜고, 그 옆 패널의 클로드가 같은 변경을 리뷰하고 있었다. 창 두 개를 띄워 복붙한 장면이 아니다. 한쪽 AI가 다른 쪽 AI에게 “이거 봐줘”라고 일을 던지고, 둘은 각자 자기 작업을 이어갔다. 상태와 결과가 한 화면에 쌓였다.

이 장면이 흥미로운 이유는 도구 데모가 아니라 검증 방식이 바뀌고 있다는 신호이기 때문이다. #31에서 “AI 코드는 더 빨리 리뷰하는 게 아니라 다르게 리뷰해야 한다”고 썼고, #35에서는 그 리뷰를 하네스의 추론형 센서로 위치시켰다. 이번 글의 테제는 그 다음 문장이다. 제일 믿을 만한 AI는 한 놈이 아니라, 서로 검사시키는 여러 놈이다. 그리고 그 문장이 실천 가능해진 이유는 모델이 더 똑똑해져서가 아니라, 복붙 세금을 걷어내는 하네스가 생겼기 때문이다.

병목은 지능이 아니라 창 전환이었다

사이드 프로젝트를 돌릴 때 클로드 코드 하나로 웬만한 일은 된다. 그런데 가끔 미심쩍다. 코덱스가 짠 파서가 경계 조건을 대충 넘긴 것 같고, 제미나이 CLI로 한 번 더 보고 싶다. 그때마다 하던 일은 이랬다.

1. 터미널 창을 하나 더 연다
2. 코드를 통째로 복사한다
3. 다른 에이전트에 붙여넣고 “리뷰해줘”를 친다
4. 결과를 다시 원래 창으로 가져온다

창이 늘수록 “어느 창에 뭘 물어봤지”가 흐려지고, 복붙 중 한 줄이 빠지기도 한다. 문제는 모델 품질이 아니라 교차 검증의 마찰 비용이다. 마찰이 높으면 사람은 검증을 생략한다. 생략된 검증은 그대로 인지 부채(#11)가 된다.

이 마찰을 없애려는 움직임은 CCB 하나만의 이야기가 아니다. 2026년 상반기 들어 업계는 같은 방향을 각자 구현했다.

공통점은 하나다. 리뷰를 ’사람이 나중에 하는 일’에서 ’에이전트가 루프 안에 끼워 넣는 일’로 옮긴다. #25에서 말한 바깥 루프의 검증 게이트가, 이제 다른 모델의 추론으로도 채워지기 시작한 것이다.

CCB가 보여주는 것 — 복붙이 아니라 위임

SeemSeam/claude_codex_bridge(CCB, Claude Codex Bridge)는 그 중에서도 “여러 CLI 코딩 에이전트를 보이는 한 워크스페이스에 몰아넣는” 쪽에 가깝다. 2026년 8월 초 기준 스타 약 3,350개, 최신 릴리즈는 v8.5.3(8월 1일). Claude·Codex·Gemini뿐 아니라 Kimi·Qwen·Cursor·Copilot·Grok·Pi·OpenCode 등 여러 CLI 패밀리를 한 허브에서 돌리는 것을 표방한다.

핵심 UX는 단순하다. 프로젝트 디렉터리에서 ccb를 띄우고, 설정으로 창·페인을 나눈 뒤, 에이전트 간에 일을 던진다.

/ask reviewer review the latest parser changes and list blocking issues.

예전에는 “코덱스 출력을 클립보드에 넣고 클로드 창으로 이동”이 전부였다. 지금은 코덱스가 계속 구현하고, 리뷰어 페인의 클로드가 그 변경을 검사하고, 둘의 대화·상태가 같은 화면에 남는다. README가 강조하는 가치도 기능 목록이 아니라 이 문장에 가깝다. stable inter-agent communication — A → B → C, A,B → C 같은 협업 그래프를 안정적으로 돌리는 것.

설정 예시도 역할이 드러나게 짜여 있다.

version = 2

[windows]
main = "main:codex"
work = "worker1:codex(worktree), worker2:claude(worktree)"
review = "reviewer:claude, qa:gemini"

구현 창과 리뷰 창을 물리적으로 갈라 둔다. 같은 모델 두 개를 나란히 두는 것과, 다른 프로바이더를 리뷰 레인에 두는 것은 성격이 다르다. 후자는 학습 데이터·정렬·도구 습관이 다른 엔진이 같은 디프를 본다는 뜻이고, 그래서 한쪽이 못 보는 종류의 버그를 다른 쪽이 잡을 여지가 생긴다. MindStudio 등이 정리한 크로스 프로바이더 리뷰 논지도 같다 — Claude와 Codex는 실수 유형이 겹치지 않는 구간이 있다.

CCB를 제품 리뷰 대상으로 삼는 글은 아니다. 여기서 중요한 건 마찰이 0에 가까워지면 교차 검증이 ’가끔 하는 성실함’에서 ’기본 루프’로 바뀐다는 점이다. 도구 이름은 바뀔 수 있다. 남는 것은 위임 가능한 리뷰 레인이다.

회로차단이 말해 주는 것 — 멀티 에이전트도 하네스 문제다

CCB v8.5.2 릴리즈 노트에는 이런 항목이 있다. 페인이 불안정하면 재시작 간격을 30초 → 60초 → 120초 → 5분 → 10분 → 30분으로 늘리고, 여섯 번 실패하면 recovery circuit을 열어 명시적 restart/remount 전까지 리스폰·디스패치를 멈춘다. 교체된 페인은 90초 관찰 기간을 두고, 새 건강 관측이 오기 전에는 큐 작업을 붙잡지 않는다.

이건 기능 나열이 아니라 신호다. 에이전트를 여러 개 돌리기 시작하면 실패 모드는 “틀린 코드”만이 아니다.

• 한 에이전트가 루프에 빠져 토큰을 태운다
• 패인이 죽고 자동 재시작이 폭풍을 만든다
• 완료 훅이 어긋나 성공으로 오인한다
• 한 쪽 장애가 협업 그래프 전체를 흔든다

그래서 멀티 에이전트 도구의 성숙도는 모델 수보다 센서와 차단기에서 갈린다. #35의 프레임을 그대로 가져오면:

자기검증만으로는 부족한 이유가 #31에 이미 있다. 모델이 구현과 테스트를 같이 쓰면 같은 잘못된 가정을 공유한다. 테스트가 녹색인데 틀린 동작을 검증하는 상태. 이때 같은 세션에 “한 번 더 검토해”라고 시키는 것은 같은 편향을 한 번 더 읽는 일에 가깝다. 세션을 가르고, 가능하면 프로바이더를 가르는 이유는 그것이다. 빌더-검증자 체인이 말하는 “평가 에이전트는 생성 세션의 누적 편향 없이 보라”는 문장과 같은 설계다.

회로차단은 그 위의 운영 문제다. 리뷰어가 맛이 가도 구현 레인이 같이 죽으면, 교차 검증은 신뢰 장치가 아니라 단일 장애점이 된다. 멀티 에이전트의 가치는 병렬성이 아니라 장애 격리 + 이질적 검증이다.

아홉 명이 필요한가 — 언제 2명이면 충분한가

CCB README는 복잡한 협업 그래프와 역할 팩, 모바일 리모트까지 말한다. 커뮤니티에는 9개 병렬 서브에이전트로 코드 리뷰를 쪼개는 설정도 있다. 인상적이지만, 사이드 프로젝트를 혼자 돌리는 입장에서 먼저 물을 질문은 이것다. 아홉 명을 관리할 일이 나한테 있는가, 아니면 검증 레인 하나가 없는가.

실무에서 체감 이득이 큰 최소 구성은 의외로 작다.

1. 구현 1 + 리뷰 1 (가능하면 다른 프로바이더)
   코덱스(또는 주력 CLI)가 짜고, 클로드(또는 다른 계열)가 차단 이슈만 본다. 범위는 “blocking issues”로 좁힌다. 스타일 논쟁을 시키면 노이즈만 는다.

2. 계산형 센서 먼저, 추론형 센서 나중
   린트·타입·테스트가 빨갛면 AI 리뷰를 부르지 않는다. #35의 처방 그대로 — 싼 센서로 왼쪽에서 거르고, 비싼 추론형 센서는 계산형이 못 보는 의미·경계·보안 구간에만 쓴다.

3. 리뷰 프롬프트를 게이트로 고정
   “전체적으로 어때?“가 아니라 #31의 순서: 의도 → 계약 → 보안 → 실패 경로 → (마지막에) 가독성. 리뷰어 에이전트 프롬프트에 이 순서를 박아 두면, 창이 바뀌어도 사각지대가 일정해진다.

4. 합의가 아니라 이견을 수집
   두 에이전트가 같은 말을 하면 안심 신호가 아니라 같은 맹점일 수도 있다. 유용한 신호는 불일치다. A만 지적한 항목을 사람이 확인하는 쪽이, 만장일치 요약보다 결함 발견에 유리한 경우가 많다.

반대로 에이전트를 늘릴수록 생기는 비용도 분명하다. 토큰 청구서가 겹치고, 핸드오프 문맥이 새고, “누가 방금 무엇을 고쳤는지” 추적 부담이 사람 쪽으로 돌아온다. 멀티 에이전트는 자동으로 품질을 올리지 않는다. 검증 그래프를 설계하지 않으면 창만 많은 단일 에이전트가 된다.

그래서 회의적인 감각도 맞다. 창 하나에 AI를 아홉 개 몰아넣는 일은 대부분의 사이드 프로젝트에 없다. 필요한 것은 보통 두 번째 눈이다. 그 두 번째 눈이 같은 모델의 새 채팅이 아니라, 다른 실패 모드를 가진 엔진이면 더 좋다. CCB 같은 도구는 그 두 번째 눈을 붙이는 비용을 낮출 뿐, 눈을 몇 개 붙일지는 여전히 설계 선택이다.

남는 것

한 줄로 정리하면 이렇다.

• 생성 속도는 이미 검증 속도를 앞질렀다 (#31).
• 검증을 루프 안에 넣는 일이 하네스 엔지니어링의 본진이다 (#35).
• 교차 프로바이더 리뷰는 그 추론형 센서를 이질적으로 만드는 방법이다.
• 회로차단·완료 계약·역할 분리 없는 멀티 에이전트는 비용만 키운다.
• 사이드 프로젝트의 기본값은 아홉 명이 아니라 구현 1 + 차단 이슈 리뷰 1이다.

코덱스가 짠 코드를 클로드에게 검사시키는 장면이 특별해 보였던 이유는, 모델이 서로 대화해서가 아니다. 사람이 클립보드로 하던 검증 네트워크를 하네스가 흡수했기 때문이다. 제일 믿을 만한 AI를 고르는 게임은 끝나가고 있다. 남는 게임은, 서로 다른 놈이 서로를 검사하게 만드는 그래프를 얼마나 얇고 단단하게 짜느냐다.

참고: SeemSeam/claude_codex_bridge (스타·릴리즈 수치 2026-08-02 조회), CCB v8.5.2 / v8.5.3 release notes, Claude Code Code Review (Anthropic), Multi-Agent Development (VS Code, 2026-02-05), Automated Code Review with Multiple AI Agents (MindStudio), 9 Parallel AI Agents That Review My Code (HAMY). CCB 기능 서술은 공개 README·릴리즈 노트 기준이며, 이 글은 특정 도구의 도입 권고가 아니라 교차 검증 구조에 대한 논평이다.