에이전트 하나가 자꾸 헤맬 때 떠오르는 유혹이 있다. “그러면 여럿 붙이면 되지 않나.” 리서처 하나, 코더 하나, 리뷰어 하나를 세워 두면 사람 조직처럼 똑똑해질 것 같다. 그런데 같은 시기에 최전선 연구소 두 곳이 정반대 결론을 내놨다. 한쪽은 멀티에이전트가 단일 에이전트를 압도했다고 했고, 다른 쪽은 아예 "멀티에이전트를 만들지 마라"고 했다. 이 모순을 정확히 읽으면, 언제 에이전트를 쪼개야 하는지가 보인다.
같은 해, 정반대 결론
Anthropic은 자사 리서치 기능을 오케스트레이터-워커 구조로 짰다. 리드 에이전트(Claude Opus 4)가 계획을 세우고 서브에이전트(Claude Sonnet 4) 서너 개를 병렬로 띄워 각자 조사하게 한 뒤 결과를 합친다. 이 구조가 내부 리서치 평가에서 단일 Opus 4보다 90.2% 나은 성능을 냈다. 대신 대가가 있다. 멀티에이전트는 일반 챗봇 대비 토큰을 약 15배 쓴다. 그리고 성능 분산의 80%가 토큰 사용량 하나로 설명됐다. 쉽게 말해, 더 잘한 게 아니라 더 많이 읽고 더 많이 생각할 자원을 쏟아부어 이긴 것이다.
같은 해 Cognition(코딩 에이전트 Devin을 만드는 팀)은 정반대 제목의 글을 냈다. “Don’t Build Multi-Agents.” 시행착오 끝에 얻은 원칙은 두 줄이다. 첫째, 컨텍스트를 공유하되 개별 메시지가 아니라 에이전트의 전체 작업 기록(trace) 을 통째로 공유하라. 둘째, 행동에는 암묵적 결정이 딸려 온다 — 여러 에이전트가 서로의 결정을 모른 채 각자 결정하면 그 결정들이 충돌하고, 충돌한 결정은 나쁜 결과를 낳는다.
모순이 아니라, 작업 모양의 차이
두 결론은 싸우지 않는다. 서로 다른 작업의 모양을 말하고 있을 뿐이다.
Anthropic이 이긴 일은 리서치다. “S&P 500 IT 기업 이사회 명단을 다 찾아라” 같은 질문은 폭 넓게 퍼지고(breadth-first), 각 갈래가 서로 독립적이며, 대부분 읽기 작업이다. 서브에이전트 A가 무엇을 찾든 서브에이전트 B의 판단을 망치지 않는다. 이런 일은 쪼갤수록 빨라지고, 단일 컨텍스트 창을 넘는 정보량도 감당된다.
Cognition이 다루는 일은 코딩이다. 코드는 앞의 결정이 뒤의 결정을 계속 제약한다. 함수 시그니처 하나를 바꾸면 그걸 부르는 모든 곳의 전제가 바뀐다. 이런 일을 서로 안 보이는 에이전트로 쪼개면, 각자는 부분만 보고 그럴듯한 결정을 내리지만 그 결정들이 합쳐지는 순간 어긋난다. Anthropic 스스로도 같은 선을 그었다. 멀티에이전트는 "모든 에이전트가 같은 컨텍스트를 공유해야 하거나 에이전트 간 의존성이 많은 작업엔 맞지 않는다"고, "대부분의 코딩은 리서치보다 진짜로 병렬화할 수 있는 일이 적다"고.
진짜 병목은 컨텍스트 공유
정리하면 판단 기준은 아키텍처가 멋지냐가 아니다. 하위 작업이 서로의 결정을 봐야 하느냐다.
봐야 한다면 — 즉 결정이 얽혀 있다면 — 에이전트를 쪼개는 순간 컨텍스트를 공유하는 비용이 폭발한다. 에이전트가 늘수록 서로에게 상태를 전달하고 맞추는 오버헤드가 붙고, 여기에 토큰 15배가 겹친다. 이럴 땐 에이전트를 늘리는 것보다 하나의 에이전트에게 더 좋은 컨텍스트를 주는 편이 거의 항상 낫다.
봐도 되고 안 봐도 되는, 읽기 중심의 독립된 갈래라면 — 그때 병렬화는 진짜로 값을 한다. 90.2%는 이 조건에서만 나온 숫자다.
창업자를 위한 결정 규칙
혼자 사업을 굴리는 사람에게 이 구분은 그대로 돈이다. 세 조건이 동시에 맞을 때만 에이전트를 쪼갠다. (1) 하위 작업이 진짜 병렬이고, (2) 읽기 위주라 서로의 결과를 오염시키지 않으며, (3) 그 일의 가치가 15배 토큰값을 정당화할 만큼 크다. 리서치·자료 수집·넓은 탐색이 여기 들어간다.
세 조건 중 하나라도 어긋나면 — 특히 결정이 얽히는 쓰기 작업이면 — 답은 단일 에이전트에 더 나은 컨텍스트다. 에이전트를 더 붙여서 똑똑해 보이게 만드는 건 쉽다. 어려운 건 이 일이 쪼개도 되는 모양인지 먼저 묻는 것이다. 대부분의 실패는 그 질문을 건너뛴 데서 나온다.