에이전트끼리 대화시키는 멀티에이전트 코딩, 효과는 어디까지 진짜인가

에이전트끼리 서로 메시지를 주고받게 하는 방식이 실제로 코딩 결과물을 좋아지게 만드는지를 두고 클로드 코드 사용자 사이에서 최근 의견이 갈렸다. 한쪽은 컨텍스트가 뒤섞이는 문제를 줄이고 다른 모델에 작업을 넘기는 데 쓸모가 있다고 봤다. 다른 쪽은 토론 형태의 멀티에이전트가 토큰만 태울 뿐 단일 워크플로우 처리와 결과 차이가 크지 않다고 반박했다. 앤트로픽 자체 연구와 최근 학계 결과, 클로드 코드가 얼마 전 내놓은 대응 기능까지 놓고 보면 이 질문의 답은 "무엇에 쓰느냐"에 따라 갈린다.

왜 코딩은 리서치만큼 잘 쪼개지지 않는가

앤트로픽은 자사 블로그 "When to use multi-agent systems (and when not to)"에서 원칙을 밝혔다. 여러 출처를 뒤지는 리서치처럼 읽기 작업이 많은 태스크는 병렬로 쪼개기 쉽지만 코드를 쓰는 작업은 그렇지 않다는 것이다. 읽기 행동은 서로 부딪히지 않지만 쓰기 행동을 병렬화하려면 에이전트 사이에 맥락을 전달하고 결과를 다시 하나로 합쳐야 하는 이중의 부담이 붙는다. 앤트로픽이 자체 리서치 시스템을 다룬 별도 글에서는 멀티에이전트가 성능을 끌어올리는 힘의 80%가 단순히 얼마나 많은 토큰을 태우느냐로 설명된다고 밝혔다. 오퍼스와 소네트를 조합한 멀티에이전트 구성이 자체 리서치 평가에서 단일 오퍼스보다 90.2% 앞섰지만 그 대가로 일반 채팅 대비 토큰을 15배 가까이 썼다. 쓰기 작업이 중심인 코딩에서는 이 교환비가 훨씬 불리해질 수밖에 없다.

토론시키는 방식은 판단을 정말 좋아지게 하나

토론형 멀티에이전트가 토큰만 더 쓰고 결과 차이는 작다는 방의 반론은 최근 학계 결과와 상당 부분 겹친다. 2025~2026년 사이 아카이브에 공개된 여러 통제 실험은 Qwen3·DeepSeek·Gemini 등 세 모델군과 다섯 가지 아키텍처를 놓고 계산량을 동일하게 맞추면 단일 에이전트가 토론형 멀티에이전트와 비슷하거나 오히려 앞선다는 결과를 냈다. 토론이 만들어내는 것처럼 보이는 성능 향상 상당수는 아키텍처의 우월함이 아니라 단순히 더 많은 계산과 더 긴 맥락을 썼기 때문이라는 설명이다. 다수결 압력이 오히려 독립적인 교정을 억누른다는 지적도 나왔다. 에이전트들이 진짜로 숙고하기보다 다수 의견에 맞춰 결론을 수렴해버린다는 것이다.

한 클코단 참가자는 수백 건의 테스트를 거친 뒤 토론형 하네스를 워크플로우 기반 처리로 완전히 바꿨다고 전했다. 판단이 갈리는 문제 — 설계 대안 비교, 위험 평가, 코드 리뷰 — 에서는 여러 관점을 붙이는 게 편향을 줄이는 효과가 있다. 다만 라운드가 늘어날수록 비용이 빠르게 불어나므로 그 무게가 비용을 정당화할 때만 쓰는 게 합리적이라는 쪽으로 커뮤니티 안팎의 시각이 모인다.

쓸모가 갈리는 지점 — 위임과 교차검증

에이전트 간 통신 자체가 무의미한 것은 아니다. 방에서 유의미한 사례로 꼽힌 두 가지 — 다른 모델에 이미지 리소스를 요청하는 위임, 코덱스·클로드·GPT Pro를 교차검증에 쓰는 조합 — 는 웹에서 확인되는 실사용 패턴과 겹친다.

이미지 생성처럼 코드가 아니라 비트맵 산출물이 필요한 작업은 애초에 코딩 모델의 전문 영역이 아니다. 이런 요청을 이미지 전문 모델에 넘기는 라우터 방식은 각 모델의 강점을 살리는 위임이지 토론이 아니다. 판단을 겨루게 하는 게 아니라 애초에 잘하는 쪽에 일을 넘기는 구조다.

교차검증도 토론과는 다른 메커니즘으로 작동한다. 크로스모델 코드 리뷰를 다룬 아카이브 연구는 코덱스가 작성한 코드를 클로드가 검토하게 했을 때 정답률이 71.6%에서 89.7%로 뛰었다고 보고했다. 클로드·코덱스·제미니를 나란히 돌리는 팀들 사이에서는 한 모델만 쓸 때보다 버그를 3분의 1가량 더 잡아낸다는 관찰도 나온다. 모델마다 놓치는 지점이 겹치지 않기 때문이라는 설명이다. 클로드는 로직 문제를, 코덱스는 인프라 설정 실수를, 제미니는 파일 간 패턴을 상대적으로 잘 잡아낸다는 식의 역할 차이도 거론된다. 방에서 나온 "봇별로 역할과 성격을 다르게 구축하면 판단이 달라지므로 용도별로 골라 써야 한다"는 정리는 이 지점과 정확히 겹친다.

클로드 코드가 내놓은 답 — 워크플로우와 에이전트 팀

클로드 코드도 토론형 멀티에이전트의 비효율에 다른 방식으로 대응했다. 2026년 5월 말 연구 프리뷰로 나온 다이나믹 워크플로우는 에이전트끼리 채팅으로 합의를 보게 하는 대신, 클로드가 자바스크립트로 오케스트레이션 스크립트를 직접 짜서 작업을 하위 태스크로 쪼개고 병렬로 돌린 뒤 결과를 검증하는 쪽을 택했다. 제어 흐름의 일부를 코드로 처리할 수 있다. 인포큐(InfoQ) 보도에 따르면 번(Bun)이 자사 코드베이스를 Zig에서 러스트로 옮긴 사례는 약 75만 줄을 11일 만에 테스트 통과율 99.8%로 마쳤다.

반대편에는 에이전트 팀이 있다. 2월 연구 프리뷰로 공개돼 정식 기능으로 문서화된 이 방식은 팀 리드 세션이 작업을 나누면 팀원들이 공유 작업 목록을 두고 서로 직접 메시지를 주고받는다. 리드를 거치지 않는 피어투피어 구조다. 여전히 실험적 플래그 뒤에 있고 병렬 리서치·리뷰처럼 독립적으로 나눌 수 있는 작업에 권장된다. 두 기능을 나란히 놓고 보면 클로드 코드 자체가 "토론"보다 "결정론적 분업"에 무게를 싣고 있다는 신호로 읽을 수 있다.

토큰 청구서로 보면 답은 더 분명해진다

서브에이전트를 붙이면 청구되는 토큰도 그만큼 는다. 개발자 커뮤니티에 공유된 사용량 분석에 따르면 서브에이전트 세션이 전체 토큰 사용량의 85%를 차지한 사례가 보고됐다. 서브에이전트 세 개를 띄우면 단일 세션 대비 토큰 소모가 네 배 가까이 뛴다는 관찰도 있다. 주간 한도가 있는 요금제에서 서브에이전트를 남발해 15분 만에 한도를 소진했다는 보고도 나왔다. 같은 작업을 순차 처리했다면 30분은 버텼을 것이라는 계산이다.

1인 개발자와 소규모 팀 사이에서 반복되는 조언은 비교적 일관적이다. 프로젝트 문서(CLAUDE.md), 플랜 모드, 스택에 맞는 슬래시 명령 몇 개를 갖추는 쪽이 멀티에이전트 구성보다 실익이 크다. 독립적으로 쪼갤 수 있는 작업이 실제로 쌓여 있을 때, 그리고 위임이나 교차검증처럼 토론이 아닌 방식으로 여러 모델을 쓸 때만 여러 에이전트를 굴리는 비용이 회수된다. 방의 논쟁은 에이전트끼리 말을 섞게 할 것이냐, 코드가 짠 계획대로 각자 맡은 일만 하게 할 것이냐는 질문으로 요약됐다.

지금까지 쌓인 증거는 후자 쪽에 좀 더 무게를 싣는다.