몇 주 전까지 저희의 OpenDiagram 코드베이스에 존재했던 타입입니다:

export type WorkspaceAgentId = "router" | "memory" | "diagram" | "canvas" | "answer";

다섯 개의 에이전트. 메시지를 분류하기 위한 전면의 라우터 (router), 프로젝트 컨텍스트를 가져오기 위한 메모리 에이전트 (memory agent), 설계를 계획하기 위한 다이어그램 에이전트 (diagram agent), 이를 렌더링하기 위한 캔버스 에이전트 (canvas agent), 그리고 답변을 작성하기 위한 답변 에이전트 (answer agent). 진행 이벤트가 UI로 스트리밍되어 에이전트들 사이에서 바통이 전달되는 모습을 지켜볼 수 있었고, 작은 스피너들이 순차적으로 불을 밝혔습니다.

데모는 아주 훌륭했습니다.

하지만 이제 그것은 사라졌습니다. 하나의 루프 (loop), 두 개의 도구 (tools), 그리고 앱은 이전보다 더 많은 일을 수행합니다.

만약 당신이 올해 에이전트 프로젝트를 시작하면서 가장 먼저 팬아웃 (fan-out) 다이어그램을 그리려는 본능이 든다면, 이 글은 당신을 위한 것입니다. 왜냐하면 그것이 저의 첫 번째 본능이었고, 제가 그것을 그렸을 때 이미 18개월이나 뒤처진 방식이었기 때문입니다.

왜 우리 모두가 이런 방식으로 만들었는가

라우터-오케스트레이터 (router-orchestrator) 구조는 어리석은 것이 아니었습니다. 그것은 당시 존재했던 문제에 대한 올바른 해답이었습니다.

2024년에는 모델들이 두 가지 측면에서 눈에 띄게 부족했습니다: 맥락을 놓치지 않고 긴 혼합 컨텍스트 (mixed context)를 유지하는 것, 그리고 넓은 액션 공간 (action space)에서 올바른 행동을 선택하는 것. 이 두 가지 모두 범위를 좁힘으로써 해결할 수 있었습니다. 각 에이전트에게 세 개의 도구와 하나의 작업만을 부여하면 잘못된 선택을 할 수 없습니다. 에이전트에게 신선하고 짧은 컨텍스트를 주면 혼란을 겪지 않습니다. OpenAI는 Swarm을 출시했고, Microsoft는 AutoGen을 출시했으며, 인터넷상의 모든 튜토리얼이 동일한 그림을 그렸기에 저 또한 그렇게 그렸습니다.

그런 제약은 대부분 사라졌습니다. 오늘날의 모델들은 긴 지침을 따르고, 40개 메시지 전의 내용을 기억하며, 수십 개의 도구 중에서 큰 어려움 없이 선택할 수 있습니다. 만약 여러분이 여전히 2026년에 작업을 전문가들로 분리하고 있다면, 여러분의 모델이 가지고 있지 않은 한계에 맞춰 엔지니어링을 하고 있을 가능성이 높습니다.

LangChain 자체 가이드라인도 이와 같은 내용으로 시작합니다: 에이전트 하나부터 시작하고, 에이전트를 추가하기 전에 도구를 먼저 추가하며, 실제로 벽에 부딪힐 때만 다중 에이전트로 넘어가는 것입니다. 이는 2026년 1월의 아키텍처 비교에서 나온 내용인데, 저 역시 허술했던 부분이 포착되었기 때문에 전체를 읽어볼 가치가 있습니다.

청구서에 적힌 것과 적히지 않은 부분

주장을 바꾸는 사소한 고백입니다.

저는 제 방식을 라우터(router)라고 불렀습니다. LangChain의 분류법에서 라우터는 상태 비저장(stateless)입니다: 분류하고, 병렬로 분산하며, 합성하고, 끝납니다. 단일 요청에 대해 세 번의 모델 호출이 필요하며, 이는 다른 대안들과 같습니다. 실제로 비용이 많이 드는 방식은 아닙니다.

제가 구축했던 것은 라우터라는 이름을 입힌 서브 에이전트(subagents) 패턴이었습니다. 분류하고, 전문가에게 위임하며, 그 결과를 답변을 작성하는 메인 에이전트를 통해 다시 흐르게 하는 것입니다. Sydney Runkle은 이것의 비용에 대해 직설적으로 말합니다: 모든 것이 발언되기 전에 집으로 돌아와야 하기 때문에

Walden Yan은 Don't Build Multi-Agents에서 이를 정확히 지적했습니다: "행동에는 암묵적인 결정이 수반되며, 상충하는 결정은 나쁜 결과를 초래한다". 두 개의 에이전트가 각각 명명(naming), 간격(spacing), 예외 케이스(edge cases), 스타일(style)에 대해 수십 가지의 명시되지 않은 선택을 내립니다. 아무도 이를 조정하지 않습니다. 통합(integration) 단계에 이르러서야 이를 알게 되는데, 다이어그램 도구의 경우 두 사람이 서로 대화도 하지 않은 채 각각 절반씩 그린 것 같은 캔버스를 마주하게 된다는 것을 의미합니다.

세 번째 비용이자, 실제로 저를 지치게 만든 것은 바로 디버깅 가능성(debuggability)입니다. 하나의 에이전트는 위에서 아래로 읽을 수 있는 하나의 트레이스(trace)를 제공합니다. 하지만 다섯 개의 에이전트는 프로세스 간의 대화를 제공하며, 각 프로세스는 국소적으로는 합리적인 결정을 내렸지만 결과적으로는 전역적으로 잘못된 결정을 내리게 됩니다. 제가 가진 모든 디버깅 습관은 스택의 어딘가에 결정론(determinism)이 존재한다는 가정하에 작동합니다. 하지만 여기에는 결정론이 어디에도 존재하지 않습니다.

그 모든 장치들을 갖추고도, 저에게는 두 가지 도구가 있었습니다.

하루 차이로 발표된 두 개의 블로그 포스트

만약 제가 단순히 느낌(vibes)만으로 글을 썼다면, 이 대목에서 훨씬 더 멍청한 글을 썼을 것입니다.

Cognition은 2025년 6월 12일에 _Don't Build Multi-Agents_를 발표했습니다. Anthropic은 2025년 6월 13일에 How we built our multi-agent research system을 발표하며, 내부 연구 평가(research eval)에서 단일 에이전트보다 90.2% 더 높은 성능을 보인 오케스트레이터-워커(orchestrator-worker) 아키텍처를 설명했습니다. 제목은 정반대이고 발표일은 연속적이지만, 두 팀 모두 명백히 자신들이 무엇을 하고 있는지 알고 있는 팀들입니다.

이것은 어느 한 쪽의 편을 들라는 신호가 아니라, 더 깊이 읽어보라는 신호입니다.

Harrison Chase는 며칠 후 그 교집합을 찾아보았고, 그들이 실제로 동의하는 지점을 발견했습니다: "읽기 작업 (read actions)은 본질적으로 쓰기 작업 (write actions)보다 병렬화 (parallelizable)하기가 더 쉽다". 읽기는 깔끔하게 팬아웃 (fan out)됩니다. 반면 쓰기는 충돌이 발생하는데, 이제 두 세트의 암묵적인 결정들을 병합 (merge)해야 하기 때문입니다. Anthropic의 시스템이 이 지점에서 어떻게 작동하는지 살펴보면, 헤드라인 수치에 가려져 놓치기 쉬운 부분이 있습니다. 즉, 연구는 서브 에이전트 (subagents)들 사이에서 병렬로 실행되지만, 리드 에이전트 (lead agent)가 단 한 번의 패스 (pass)로 직접 보고서를 작성한다는 것입니다. 그들 역시 쓰기 작업을 병렬화하지 않았습니다.

90.2%라는 수치를 재맥락화하는 숫자는 같은 포스트에 있습니다. Anthropic은 BrowseComp 성능의 "분산 (variance) 중 80%가 토큰 사용량 자체로 설명된다"는 것을 발견했습니다. 멀티 에이전트 (Multi-agent) 방식이 주로 승리한 이유는 더 많은 비용을 썼기 때문입니다. 에이전트는 채팅보다 대략 4배 더 많은 토큰을 소모하며, 멀티 에이전트 시스템은 약 15배를 소모합니다. 이것은 컴퓨팅 자원 (compute)을 구매한 것이며, 때로는 좋은 선택일 수 있지만, 승리의 원인을 아키텍처 (architecture) 덕분으로 돌리기 전에 당신이 무엇을 사고 있는지 알고 있어야 합니다.

이 내용을 인용하는 대부분의 사람들이 놓친 업데이트

Cognition은 2026년 4월에 후속 보고서인 Multi-Agents: What's Actually Working을 발표했습니다. 동일한 저자가 10개월 후 업데이트된 관점을 제시한 것입니다. 오늘날 실제로 작동하는 멀티 에이전트 시스템의 범주는 더 좁고 구체적입니다: 여러 에이전트가 지능을 기여하되 "쓰기는 싱글 스레드 (single-threaded)로 유지된다"는 것입니다. 읽기 전용 헬퍼 (Read-only helpers)는 괜찮으며, 그는 실제로 현장에서 작동하는 대부분의 멀티 에이전트 설정이 정확히 그러하며, 동료보다는 도구 호출 (tool call)에 더 가깝다고 지적합니다.

따라서 "멀티 에이전트는 끝났다"는 말은 틀렸으며, 2025년 포스트만을 인용하는 사람은 1년 뒤처진 것입니다. 저 또한 후속 보고서를 읽기 전까지는 바로 그런 사람이었습니다.

그 보고서에는 정말 기이한 발견도 하나 포함되어 있습니다. Devin의 리뷰 에이전트(review agent)는 코드를 작성한 에이전트와 컨텍스트(context)를 전혀 공유하지 않을 때 더 잘 작동하며, Devin이 작성한 PR(Pull Request)에서 PR당 약 2개의 버그를 잡아내는데, 그중 약 58%가 심각한 수준입니다. 이는 10개월 전의 '모든 것을 공유하라'는 원칙과 정면으로 모순되는 것처럼 보이지만, 사실 그렇지 않습니다. 작성자의 가정이나 주의력(attention)을 방해하는 수 시간 동안 쌓인 컨텍스트 없이, 디프(diff)로부터 역으로 추론하는 리뷰어는 작성자보다 해당 디프에 대해 더 똑똑하게 판단하기 때문입니다. 저는 저자가 이 발견을 이전 게시물에 맞추기 위해 다듬지 않고 있는 그대로 공개했다는 점이 마음에 듭니다.

두 게시물을 거치며 완전히 사라진 것은 제가 직접 구축했던 특정 방식입니다. 모든 턴(turn) 앞에 분류기(classifier)를 두어, 모델이 작업의 일부로 어차피 답변할 질문에 대해 직렬 모델 호출(serial model call) 비용을 지불하며 답을 구하게 한 뒤, 대화 내용 대신 요약본을 전문가(specialist)에게 전달하는 방식 말입니다.

그래서 저는 그것을 삭제했습니다

전체 오케스트레이션 레이어(orchestration layer)는 다음과 같이 축소되었습니다. 저는 현재 Vercel AI SDK를 사용 중입니다:

const tools = {
  ask_user: askUserTool,
  draw_diagram: createDrawDiagramTool(log, themes[themeName]),
...

이것이 전부입니다. 과거에 다섯 개의 에이전트와 진행 이벤트 시스템(progress-event system)이 수행하던 작업의 전부가 이것입니다.

모델은 요청을 읽고, 작업을 수행하는 데 사용하는 것과 동일한 추론 패스(reasoning pass) 내에서 명확한 질문을 던질지, 새로운 것을 그릴지, 아니면 이미 캔버스에 있는 다이어그램을 수정할지를 결정합니다. 결정과 실행은 동일한 컨텍스트를 공유하는데, 왜냐하면 그것들이 곧 동일한 컨텍스트이기 때문입니다. 전달 과정에서 요약되는 것은 아무것도 없습니다.

라우팅 로직(routing logic)은 어디로 갔을까요? 바로 도구 설명(tool descriptions) 속으로 들어갔습니다.

description:
  "최종 다이어그램을 사용자의 캔버스에 렌더링합니다. 채팅에 짧은 계획을 작성한 후, " +
  "디자인당 정확히 한 번 호출하십시오. 다이어그램을 업데이트하려면 targetId를 설정하십시오. " +
  "...

이 부분은 다른 사람이 작성한 이 포스트를 읽었을 때 제가 과소평가했을 법한 대목입니다. 라우터(router) 설정에서는 라우터 프롬프트(router prompt)가 누가 무엇을 처리할지 결정합니다. 하지만 단일 루프(single loop) 구조에서는 **도구 설명(tool descriptions)이 곧 라우팅 로직(routing logic)**이며, 단순히 도구가 무엇을 하는지 정중하게 설명하는 것을 넘어 언제 호출해야 하는지에 대해 규정적(prescriptive)이어야 합니다. 도구 설명을 마치 독스트링(docstrings)처럼 작성하면, 모델이 잘못된 시점에 올바른 도구를 호출하게 됩니다. 문장 하나를 다시 쓰는 것은 에이전트 경계(agent boundary)를 옮기는 것보다 훨씬 저렴한 실험이며, 저는 절약된 모델 호출 비용을 위해서라면 언제든 기꺼이 문장을 고쳐 쓰겠습니다.

단계 제한(step cap) 또한 그 존재 가치가 충분합니다. 라우터는 구조적으로 작업을 제한하지만, 그래프(graph)는 그냥 종료될 뿐입니다. 루프(loop)는 허용한다면 계속해서 돌아가기 때문에, 실제로 명시해 둔 상한선이 필요합니다. (참고로 isStepCount는 AI SDK 7의 철자입니다. 이전에는 stepCountIs였으므로, 온라인에서 찾을 수 있는 예제의 절반은 컴파일되지 않을 것입니다.)

여전히 분리해야 하는 경우

저는 멀티 에이전트(multi-agent)에 반대하는 것이 아니며, 이 글의 결론이 "영원히 항상 하나의 루프만 사용하라"는 뜻이라고 생각하지도 않습니다.