서브 에이전트(Sub-agents)는 필요하지 않습니다

지난 1년 동안 올라온 어떤 "에이전트 아키텍처 (agent architecture)" 포스트를 열어봐도 똑같은 다이어그램을 마주하게 될 것입니다. 상단에는 **Orchestrator (오케스트레이터)**라고 표시된 상자가 있고, 거기서 Researcher (연구자), Coder (코더), Tester (테스터), Reviewer (검토자) — 때로는, 세상에나, CEO 에이전트까지 — 로 화살표가 퍼져 나가는 모습 말이죠. 아주 아름답게 그려져 있습니다. 그라데이션 노드에 깔끔한 선까지, 완벽하죠. 하지만 그것은 아키텍처가 아닙니다. 그것은 조직도 (org chart)입니다. 당신은 이 그림을 전에도 본 적이 있을 것입니다. 다만 실제로 작동하는 모습은 본 적이 없을 뿐입니다.

우리는 이미 이 실험을 했습니다. 1975년에 말이죠.

Fred Brooks는 1975년 IBM의 OS/360을 대상으로 이 실험을 수행했고, 이를 The Mythical Man-Month에 기록했습니다: 지연되고 있는 소프트웨어 프로젝트에 인력을 추가하는 것은 프로젝트를 더 지연시킨다는 것입니다. 그 이유는 게으름 때문이 아니라 산술적인 문제였습니다. 팀에 새로운 인원이 추가될 때마다 통신 경로 (communication paths)가 추가되며, 그 경로는 n(n−1)/2에 따라 증가합니다. 즉, 조정 비용 (coordination cost)이 도움의 속도보다 더 빠르게 상승한다는 것입니다. 두 명이면 한 개의 선, 다섯 명이면 열 개의 선, 열 명이면 마흔다섯 개의 선이 생깁니다.

이제 다시 스웜 (swarm) 다이어그램을 보십시오. 오케스트레이터의 유일한 업무는 하위 작업 (subtasks)을 배분하고 돌아오는 결과물을 조정하는 것인데, 이는 곧 Brooks가 경고했던 통신 오버헤드 (communication overhead) 그 자체가 된다는 뜻입니다. 우리는 문제에 인력을 투입하는 것이 왜 확장성 (scale)을 갖지 못하는지에 대한 50년 된 결과를 언어 모델 (language models)로 가져와서, 더 멋진 도구로 그려낸 뒤, 그것을 에이전트 메쉬 (agent mesh)라고 불렀습니다. 진보한 것 같지 않나요?

위임(Delegation) 과정에서 컨텍스트는 살아남지 못합니다

다이어그램을 제외한 실제 메커니즘은 다음과 같습니다. 서브 에이전트 (sub-agent)는 자신만의 격리된 컨텍스트 윈도우 (context window) 내에서 실행됩니다. 작업이 완료되면, 서브 에이전트는 부모 에이전트에게 자신의 추론 (reasoning) 과정을 전달할 수 없으며, 오직 압축된 요약본만을 전달할 수 있습니다. Anthropic의 context-engineering guide에서도 정확히 이 점을 명시하고 있습니다: 서브 에이전트는 응축된 결과를 반환하지만, 그 결과를 만들어낸 상세한 컨텍스트 (detailed context)는 아무도 볼 수 없는 윈도우 안에 갇혀 있게 됩니다.

따라서 각 자식(child)에게 필요한 것을 제공하기 위해, 여러분은 상태(state)를 파일, 데이터베이스, 또는 git에 영구적으로 저장(persist)하고, 모든 서브 에이전트(sub-agent)의 상단에서 이를 다시 읽어 들입니다. 이것 또한 아키텍처(architecture)가 아닙니다. 그것은 단순한 배관 작업(plumbing)일 뿐입니다. 여러분은 단일 루프(single loop)가 이미 무료로 가지고 있는 공유 컨텍스트(shared context)를 재현하기 위한 목적으로만 존재하는 인프라를 구축하고 유지 관리하고 있는 것입니다. 단일 루프는 애초에 컨텍스트를 분할하지 않았기 때문에 그 컨텍스트를 공짜로 가지고 있는 것입니다.

그 증거는 바로 임시방편(workaround)입니다. Claude Code 이슈를 읽어보면, 부모 에이전트가 자식 에이전트가 무엇을 하고 있었는지 다시 발견할 수 있도록 하기 위해, 사람들이 서브 에이전트에게 임시 상태 파일(temp state file)을 쓰게 하거나 git에 커밋하게 만드는 것을 볼 수 있습니다. Cloudflare의 코드 리뷰 파이프라인은 이와 동일한 작업을 절제된 방식으로 수행합니다. 즉, 전체 머지 리퀘스트(merge request)를 7명의 리뷰어에게 7번 전달하지 않기 위해, 공유 컨텍스트 파일과 디스크에 기록되는 파일별 패치(patch) 파일을 사용합니다. "에이전트들이 서로의 컨텍스트를 볼 수 없다"는 문제에 대한 해결책이 "컨텍스트를 디스크에 쓰고 모두가 다시 읽게 하는 것"이라면, 여러분은 이미 버려버린 공유 메모리(shared memory)를 재발명한 셈입니다. 더 느리고, YAML만 더 늘어난 채로 말이죠.

그리고 토큰(tokens) 문제입니다. 에이전트 간에 작업을 분할한다는 것은 모든 경계(boundary)를 넘을 때마다 컨텍스트를 다시 전달해야 함을 의미하며, 따라서 토큰 비용을 배수로 지불하게 됩니다. 오케스트레이터(orchestrator) 또한 공짜가 아닙니다. 모든 자식의 출력을 읽고 조정(reconcile)해야 하므로, N개의 에이전트로 팬아웃(fan-out)할 경우 비용은 N이 아니라 약 N+1이 되는 경향이 있습니다. 더 많은 가동 부품, 더 많은 토큰, 더 많은 실패 지점, 이 모든 것이 단 하나의 루프가 혼자서도 만들어냈을 답을 내놓기 위해 사용됩니다. 그라데이션 효과를 입힌 비싼 쓰레기(Expensive bullshit with a gradient fill)입니다.

실제로 에이전트를 출시한 사람들에게 물어보세요

실제로 이를 출시해 본 사람들의 이야기부터 시작해 봅시다. PostHog는 프로덕션 환경에서 에이전트를 구축하며 1년을 보냈고, 동일한 결론에 도달했습니다. 단일 루프가 서브 에이전트보다 낫다는 것입니다. 왜냐하면 위임(delegation)의 모든 계층은 컨텍스트를 손실시키고, 도구를 체이닝(chaining)하고 스스로 교정(self-correct)하는 모델의 능력을 깎아먹기 때문입니다.

하지만 멀티 에이전트 시스템(multi-agent systems)에 대해 가장 크게 목소리를 높이는 곳은 바로 Cognition입니다. 네, 코딩 에이전트인 Devin을 만드는 그 회사입니다. 2025년 6월, 그들의 Walden Yan은 "]Don't Build Multi-Agents["(https://cognition.ai/blog/dont-build-multi-agents)라는 글을 발표했으며, 핵심 논점은 위에서 언급한 것과 같았습니다. 병렬 에이전트들은 서로가 무엇을 가정했는지 볼 수 없기 때문에 상충하는 암묵적 결정(implicit decisions)을 내린다는 것입니다. 두 개의 서브 에이전트(sub-agents)에게 동일한 것을 만들라고 요청하면, 한쪽은 특정 화풍의 새를 만들고 배경은 다른 화풍으로 만드는 결과가 나옵니다. (이것은 제 예시가 아니라 그의 Flappy-Bird 예시입니다.)

그런 다음 다음에 일어난 일을 보십시오. 10개월 후인 2026년 4월, Yan은 실제 운영 환경(production)에서 작동하는 후속 글을 게시했습니다. 그 조건을 읽어보십시오. 작동하는 패턴은 쓰기(writes) 작업을 싱글 스레드(single-threaded)로 유지하는 것입니다. 즉, 많은 에이전트가 지능을 기여할 수는 있지만, 단 하나의 스레드만이 커밋(commits)을 수행합니다. 제멋대로 날뛰는 군집(swarm)이나 에이전트들이 서로 임의로 협상하는 방식은 그는 여전히 주의 분산 요소로 분류합니다. 가장 강력한 지지자의 "우리가 해결책을 찾아냈다"는 말은 결국 "우리는 그들이 서로의 발을 밟게 두는 것을 그만두었다"는 뜻임이 드러났습니다.

이제 당신이 제기할 반론은 이럴 것입니다: 하지만 Anthropic의 연구 시스템은 단일 에이전트보다 90.2% 더 나은 성능을 보였는데요. 맞습니다. 연구 분야에서는 그랬습니다. 하지만 그 설정은 채팅보다 약 15배 더 많은 토큰(tokens)을 소모하며, 토큰 사용량만으로도 성능 차이의 약 80%를 설명할 수 있습니다. 이를 번역하자면: 그 승리는 대부분 "우리가 훨씬 더 많은 연산(compute) 비용을 지불했다"는 것이며, 독립적인 검색 방향으로 병렬화가 가능한 영역에서 이루어진 결과입니다. 만약 당신의 작업이 독립적이고 읽기 전용(read-only)인 방향으로 분해될 수 있고 그 답변이 비용을 지불할 가치가 있다면, 그렇게 하십시오. 그렇지 않다면, 당신은 단 한 번의 루프(loop)로도 충분했을 컨텍스트(context)를 다시 전달하기 위해 그 몇 배의 비용을 지불하고 있는 것입니다. 조건을 읽어보십시오.

그리고 이러한 시스템이 고장 날 때, 그것들은 특정한 방식으로 고장 납니다. Berkeley의 MAST 연구 (Cemri et al., 2025)는 AutoGen, ChatDev, CrewAI와 같은 흔히 알려진 7개의 프레임워크(frameworks)에 걸쳐 1,600개 이상의 실행 트레이스(execution traces)를 주석 처리하였으며, 실패율이 41%에서 무려 87%에 달한다는 것을 기록했습니다. 실패는 설계 및 조정(coordination) 문제에 집중되어 있습니다. 즉, 모델이 멍청해서가 아니라 시스템 설계 문제와 에이전트 간의 불일치(misalignment), 에이전트들이 서로 엇갈린 대화를 하거나 작업이 완료되었다는 합의에 도달하지 못하는 등의 문제입니다. 저자들은 이를 명확하게 말합니다. 이것은 모델의 문제가 아니기 때문에 더 나은 베이스 모델(base model)이 이를 해결해주지 않을 것입니다. 이것은 아키텍처 다이어그램(architecture diagram)의 탈을 쓴 조직도(org-chart) 문제입니다. 이 패턴이 보이십니까?

실제로 병렬화해야 하는 곳

두 작업이 진정으로 독립적일 때는, 중간에 오케스트레이터(orchestrator) 없이 각각 고유한 전체 컨텍스트(context)를 가진 두 개의 별도 루프(loop)로 병렬화하십시오. 그것은 멀티 에이전트 시스템(multi-agent system)이 아닙니다. 그것은 두 개의 프로그램을 실행하는 것입니다.

구분은 그토록 간단합니다. 독립적인 작업은 별도의 루프로서 병렬화하십시오. 단일 사고 흐름(train of thought)을 분할했다가 다시 재조립하기 위해 오케스트레이터를 세우지 마십시오. 재조립 과정 자체가 전체 비용이기 때문이며, 단일 루프는 그 비용을 지불할 필요가 없었습니다. 단일 루프는 하나의 메시지 히스토리(message history) 내에서 수백 단계에 걸쳐 스스로를 수정(self-corrects)하며, Temporal과 같은 도구를 하단에 배치하면 어떤 단계에서든 체크포인트(checkpoint)를 생성하고 재개할 수 있습니다. 또한 새벽 2시에 포렌식(forensic)적으로 재구성해야 하는 그룹 채팅 대신, 하나의 깔끔하고 선형적인 트레이스(trace)를 남깁니다.

더 나은 도구는 이미 존재합니다. 그것은 당신이 메시(mesh)를 그리러 가는 길에 지나쳐 버린 바로 그 루프입니다.