대부분의 사람들이 AI를 경험하는 것은 하나의 어시스턴트와의 대화입니다. ChatGPT, Claude와 같은 유사한 제품들은 하나의 대화 상대방을 제시합니다. 질문을 하면, 그것은 추론하고, 아마도 몇 가지 도구를 호출하며, 답변을 제공합니다.

이러한 경험은 자연스러운 아키텍처적 본능을 만듭니다: 만약 하나의 에이전트가 유용하다면, 그 하나의 에이전트를 더 유능하게 만들자. 더 나은 지침을 주자. 더 많은 도구를 연결하자. 더 많은 컨텍스트를 추가하자. 토큰 예산을 늘리자. 모델을 업그레이드하자.

여기가 시작할 올바른 장소입니다.

하지만 이것이 끝낼 수 있는 무한히 확장 가능한 곳은 아닙니다.

어느 시점부터는 단일 에이전트가 하나의 일관된 작업을 수행하지 못하게 됩니다. 그 지침에는 직무 기술서, 조직도, 워크플로우 엔진, 메모리 정책, 위임 정책, 검토 체크리스트, 그리고 복구 절차가 포함됩니다. 그 컨텍스트에는 요청, 계획, 중간 증거, 실패한 시도, 도구 결과, 그리고 이 모든 것에 대한 에이전트 자신의 결론이 담겨 있습니다. 그 도구 목록은 여러 영역에 걸쳐 있습니다. 그것은 조사하고, 계산하고, 편집하고, 비판하고, 검증하고, 마침내 자신의 작업을 승인하도록 요청받습니다.

아키텍처는 여전히 '에이전트'라고 표시된 하나의 상자처럼 보이기 때문에 복잡성이 사라진 것처럼 느껴집니다. 하지만 실제로는 그렇지 않습니다. 그 복잡성은 상자 안으로 이동했고, 그곳에서는 보기 어렵고, 테스트하기 어려우며, 관리하기도 더 힘들어졌습니다.

이 글은 바로 그 지점 이후에 일어나는 일에 관한 것입니다.

이전 기사에서는 에이전트를 세 부분, 즉 지침(instructions), LLM, 그리고 MCP 도구로 축소했습니다. 이것은 여전히 올바른 기반입니다. 이 글은 두 가지 논거를 추가하여 이를 확장합니다:

1. 단일 에이전트는 능력의 한계(capability ceiling)를 가집니다. 충분히 복잡하고 분해 가능한 작업의 경우, 팀은 전문화(specialization), 분리된 컨텍스트(separate contexts), 병렬성(parallelism), 그리고 독립적인 검증(independent validation)을 통해 그 한계를 넘어 확장할 수 있습니다.
2. 팀은 조정 비용(coordination tax)을 지불합니다. 하지만 그 비용은 점점 더 혼란스러워지는 프롬프트와 불안정한 컨텍스트 속에 숨겨진 채, 단일 에이전트 시스템에서도 존재합니다. MCP는 이를 명시적이고 재사용 가능한 협업 인프라로 외재화(externalize)할 수 있게 해줍니다.

실질적인 패턴은 단순함이 장점으로 남아 있는 동안에는 하나의 에이전트를 확장(scale up)하고, 암시적인 조정이 병목 현상이 될 때 팀으로 확장(scale out)하는 것입니다.

MCP란 무엇인가? (30초 요약 버전)

Model Context Protocol (MCP, spec 2025-11-25)는 도구(tools), 프롬프트(prompts), 리소스(resources)를 통해 AI 클라이언트와 외부 시스템 사이를 연결하는 인터페이스 계층입니다. 이 시리즈 전반에 걸쳐, 우리는 MCP 서버를 기업용 AI를 위한 관리된 능력 계층(governed capability layer)으로 다루어 왔습니다. 즉, 내부 시스템 및 SaaS 시스템에 대한 가볍고(thin), 원격이며(remote), 대부분 상태가 없는(stateless) 인터페이스입니다.

에이전트는 다음과 같은 요소를 갖춘 MCP 클라이언트입니다:

• 자신의 작업과 경계를 설명하는 지침 (instructions)
• 추론 및 언어 능력을 제공하는 LLM
• 외부 세계와 연결해 주는 선택된 MCP 도구 (MCP tools)

에이전트 팀은 해당 모델을 대체하는 것이 아닙니다. 대신 다음과 같이 재귀적으로 구성합니다:

• 특화된 에이전트가 MCP 도구로 노출될 수 있습니다.
• 다른 에이전트가 해당 도구를 발견하고 호출할 수 있습니다.
• 공유 협업 서비스 또한 MCP를 통해 노출될 수 있습니다.

그 결과는 새로운 종류의 소프트웨어가 아닙니다. 동일한 능력 모델(capability model)로부터 구축된 확장형(scale-out) 아키텍처입니다.

단일 에이전트가 시작하기에 적합한 지점입니다

팀을 구성하는 것은 실제 비용을 발생시킵니다. 조정자(coordinator)는 작업을 분해하고, 협업자를 선택하며, 결과를 기다리고, 충돌을 해결하며, 답변을 종합해야 합니다. 여러 에이전트는 더 많은 토큰을 소비하고 더 많은 실패 경계(failure boundaries)를 생성합니다. 공유 상태(shared state)에는 소유권, 권한, 그리고 생명주기 규칙(lifecycle rules)이 필요합니다.

많은 작업의 경우, 그 중 어느 것도 정당화되지 않습니다.

다음과 같은 작업에는 단일 에이전트를 사용하세요:

• 작업이 짧을 때
• 대부분 순차적일 때
• 하나의 컨텍스트 (context) 내에 포함될 때
• 작고 일관된 도구 세트 (toolset)로 처리 가능할 때
• 직접 검증하기 쉬울 때
• 추가적인 추론 (inference) 및 인프라 비용을 정당화할 만큼 가치가 높지 않을 때

에이전트를 추가하기 전에, 단일 에이전트의 규모를 확장(scale up)하세요:

• 지시 사항 (instructions) 개선
• 경제성이 확보되는 경우 더 강력한 모델 사용
• 도구 (tools)를 줄이고 명확하게 정의
• 결정론적 계산 (deterministic computation)을 MCP 서버로 이동
• 반복 가능한 워크플로우를 프롬프트 (prompts)로 패키징
• 장기 실행 작업에 명시적인 작업 생명주기 (task lifecycle) 부여

이는 본 시리즈 전체에서 사용되는 동일한 원칙을 따릅니다: 결정론적 능력 (deterministic capability)이 더 나은 곳에 확률론적 오케스트레이션 (probabilistic orchestration)을 추가하지 마세요. 서버 코드 (server code)가 계산을 안정적으로 수행하거나 알려진 워크플로우를 강제할 수 있다면, 서버 코드를 사용하세요. 두 번째 에이전트는 잘 설계된 도구의 대체제가 아닙니다.

하지만 규모를 확장하는 것도 결국 수확 체감 (diminishing returns)의 단계에 도달합니다.

단일 에이전트의 한계 (The Single-Agent Ceiling)

이 한계는 단순히 단일 모델의 제한만을 의미하지 않습니다. 여러 압박 요인이 복합적으로 작용합니다.

컨텍스트 포화 (Context saturation)
단일 에이전트는 계획, 증거, 중간 결과, 대화 기록, 그리고 자신의 추론 (reasoning)을 하나의 작업 컨텍스트 (working context)에 담아야 합니다. 더 큰 컨텍스트 윈도우 (context window)는 용량을 늘려주지만, 모든 관련 세부 사항이 적절한 시점에 적절한 주의 (attention)를 받는 것을 보장하지는 않습니다.

도구 과부하 (Tool overload)
범용 에이전트 (generalist agent)는 더 많은 도구가 필요합니다. 도구 설계 기사에 따르면, 선택지 세트가 커짐에 따라 도구 성능이 급격히 떨어질 수 있음을 보여주었습니다. 작업을 전문가 (specialists)들에게 나누어 주면 각 에이전트는 더 작고 관련성 높은 기능 표면 (capability surface)을 볼 수 있게 됩니다.

역할 충돌 (Role collision)
계획 (Planning), 실행 (execution), 비판 (criticism), 승인 (approval), 그리고 최종 커뮤니케이션 (final communication)은 서로 다른 행동 양식을 요구합니다. 이 모든 것을 하나의 지침 세트 (instruction set)로 인코딩하면 상충하는 목표가 생성됩니다: 빠르게 움직이되 모든 것을 검증할 것, 대안을 탐색하되 간결함을 유지할 것, 해결책을 제안하되 이를 불신할 것과 같은 식입니다.

순차적 처리량 (Sequential throughput)
단일 에이전트는 한 번에 하나의 궤적 (trajectory)만을 탐색합니다. 문제가 여러 개의 독립적인 연구 경로 (research paths)나 확인 사항을 포함하고 있을 때, 팀은 별도의 컨텍스트 (contexts)를 사용하여 이를 동시에 작업할 수 있습니다.

경로 의존성 (Path dependence)
초기의 잘못된 가정이 이후의 추론을 형성합니다. 자신의 작업을 스스로 검토하는 동일한 에이전트는 해당 결론을 만들어낸 컨텍스트를 통해서만 결론을 바라보게 됩니다.

취약한 자기 검증 (Weak self-verification)
에이전트에게 "답변을 재확인하세요"라고 말하는 것은 유용하지만, 이는 독립적인 검토자 (independent reviewer), 권위 있는 상태 경계 (authoritative state boundary), 또는 완료 전 검증이 성공해야 한다는 요구 사항을 만들어내지는 못합니다.

이러한 압박 요인들은 왜 더 많은 지침을 추가하는 것이 에이전트를 더 나쁘게 만들 수 있는지를 설명해 줍니다. 각각의 새로운 규칙은 개별적으로는 합리적일 수 있지만, 전체 프롬프트 (prompt)는 명확한 소유자와 인터페이스 (interfaces)를 가져야 할 책임들을 위한 혼잡한 제어 평면 (control plane)이 되어버립니다.

에이전트 확장 딜레마 (The Agent Scaling Dilemma)

데이터베이스 아키텍처 (Database architecture)는 오랫동안 유사한 결정에 직면해 왔습니다. 시스템이 경제적인 범위 내에 있을 때는 하나의 시스템을 확장 (scale up)하고, 성장하는 시스템이 복잡성이나 용량의 경계를 넘어서면 확장 (scale out)하는 방식입니다. 에이전트에게도 동일한 곡선이 적용됩니다.

이 다이어그램은 벤치마크 데이터가 아닌 개념적 아키텍처 곡선입니다.

단일 에이전트 (single-agent) 라인은 더 낮은 지점에서 시작합니다. 프로토타입 (prototype) 단계에서는 하나의 프롬프트, 하나의 루프 (loop), 그리고 하나의 배포 (deployment)를 능가하기 어렵습니다. 초기 성장 단계에서는 더 나은 지침, 더 나은 모델, 그리고 큐레이션된 도구 세트 (toolset)가 그 유효 범위를 확장해 줍니다.

팀의 시작점(team line)은 더 높게 형성됩니다. 팀이 원활하게 작동하기 위해서는 협업 인프라(collaboration infrastructure)가 먼저 존재해야 하기 때문입니다. 에이전트들에게는 계약(contracts), 공유된 산출물(shared artifacts), 상태 소유권(state ownership), 메모리 경계(memory boundaries), 검증(validation), 상태 추적(status tracking), 그리고 거버넌스(governance)가 필요합니다.

이러한 고려 사항들을 단일 에이전트 내부에 암묵적으로 유지하는 것이 명시적으로 표현하는 것보다 더 비용이 많이 들고 신뢰도가 떨어지는 시점에 교차점(crossover)이 발생합니다. 그 지점을 넘어서면, 팀 아키텍처(team architecture)는 단일 에이전트의 프롬프트(prompt), 컨텍스트(context), 도구 표면(tool surface)을 지속적으로 확장하지 않고도 전문화된 역량을 추가할 수 있습니다.

여기에는 중요한 차이점이 있습니다:

팀이 더 저렴해지는 것은 조정(coordination)이 사라지기 때문이 아닙니다. 팀이 확장 가능해지는 이유는 조정이 명시적이고, 재사용 가능하며, 거버넌스(governable)가 가능해지기 때문입니다.

팀은 추론을 확장(Scale Out)합니다

문제를 경계가 정해진 책임(bounded responsibilities)으로 나눌 수 있을 때 확장(scale-out)은 유용합니다.

서로 다른 에이전트들은 다음과 같은 것들을 가질 수 있습니다:

• 서로 다른 지침 (instructions)
• 서로 다른 도구 및 권한 (tools and permissions)
• 서로 다른 작업 컨텍스트 (working contexts)
• 서로 다른 산출물 소유권 (artifact ownership)
• 서로 다른 검증 책임 (validation responsibilities)
• 심지어 역할의 경제성에 따라 선택된 서로 다른 모델 (models)

연구 에이전트(research agent)가 한 가지 분기를 탐색하는 동안 다른 에이전트가 두 번째 분기를 탐색할 수 있습니다. 금융 에이전트(finance agent)는 금융 도구와 정책만을 부여받을 수 있습니다. 검토자(reviewer)는 작성자가 세운 모든 가정을 상속받지 않고도 산출물을 검사할 수 있습니다. 코디네이터(coordinator)는 모든 원본 문서를 자신의 컨텍스트에 담아두는 대신 간결한 결과물(findings)을 바탕으로 작업할 수 있습니다.

적절한 작업 형태(task shapes)에 대해 이것이 도움이 된다는 증거가 늘어나고 있습니다. Anthropic은 자사의 멀티 에이전트 연구 시스템이 내부 연구 평가에서 단일 에이전트 베이스라인보다 90.2% 더 높은 성능을 보였다고 보고했습니다. 특히 독립적인 방향성을 가진 너비 우선 쿼리(breadth-first queries)에서 그러했습니다. 동일한 보고서에 따르면, 이 멀티 에이전트 시스템은 일반적인 채팅보다 약 15배 많은 토큰을 사용했으며, 밀접하게 결합된 의존성(tightly coupled dependencies)이 있는 작업에는 적합하지 않았습니다. (Anthropic engineering)

180개의 에이전트 구성에 대한 통제된 연구 결과, 유사한 경계가 발견되었습니다. 중앙 집중식 조정(centralized coordination)은 벤치마크의 병렬화 가능한 작업(parallelizable tasks)에서 성능을 실질적으로 향상시킨 반면, 테스트된 모든 멀티 에이전트 토폴로지(multi-agent topology)는 순차적 추론(sequential reasoning) 작업에서 성능을 저하시켰습니다. (Towards a Science of Scaling Agent Systems)

결론은 에이전트가 많을수록 항상 더 좋다는 것이 아닙니다. 작업이 분할(partitioning), 병렬 탐색(parallel exploration), 전문화(specialization) 또는 독립적인 검증(independent checking)으로부터 이득을 얻을 때 팀이 성능의 한계치(ceiling)를 높여준다는 것입니다.

조정 비용(Coordination Tax)은 어떤 방식이든 존재한다

멀티 에이전트 시스템은 종종 조정 오버헤드(coordination overhead)를 추가한다는 비판을 받습니다. 그 비판은 옳지만 불완전합니다.

복잡한 단일 에이전트 또한 조정을 수행합니다. 에이전트는 자신이 어떤 책임을 수행하고 있는지 결정하고, 중간 상태(intermediate state)를 추적하며, 실패한 접근 방식을 기억하고, 증거를 확인하며, 도구 결과(tool results)를 관리하고, 자신의 답변이 유효한지 결정합니다. 차이점은 이 모든 과정이 확률적 추론(probabilistic reasoning) 내부에서 암묵적으로(implicitly) 일어난다는 점입니다.

따라서 선택지는 다음과 같습니다:

• 조정 있음
• 조정 없음

이 아니라:

• 하나의 프롬프트와 컨텍스트(context) 내부의 암묵적 조정 (implicit coordination)
• 계약(contracts), 산출물(artifacts), 메모리(memory), 작업(tasks) 및 소유권(ownership)을 통한 명시적 조정 (explicit coordination)

조정을 명시적으로 만드는 것이 비용을 없애주는 것은 아닙니다. 다만 조정을 다룰 수 있게(addressable) 만들어 줄 뿐입니다.

엔지니어링 체크리스트는 구체화됩니다:

• 작업은 어떻게 분해되는가?
• 각 책임은 어떤 에이전트가 소유하는가?
• 입력 및 출력 계약 (input and output contract)은 무엇인가?
• 중간 산출물 (intermediate artifacts)은 어디에 저장되는가?
• 권위 있는 상태 (authoritative state)를 누가 업데이트할 수 있는가?
• 중복 작업과 충돌하는 변경 사항은 어떻게 방지되는가?
• 진행 상황, 재시도 (retries), 타임아웃 (timeouts), 취소 (cancellation)는 어떻게 표현되는가?
• 모순되는 결과는 누가 해결하는가?
• 어떤 정보가, 얼마나 오래, 누구를 위해 기억될 수 있는가?
• 신원 (identity), 권한 부여 (authorization), 감사 컨텍스트 (audit context)는 어떻게 전파되는가?
• 토큰 (token), 지연 시간 (latency), 인프라 예산은 어떻게 강제되는가?

이러한 질문들은 오직 하나의 시스템 프롬프트 (system prompt) 안에 묻혀 있는 산문 형태로만 구현되어 있을 때는 답하기 어렵습니다. 일단 이 질문들이 협업 서비스 (collaboration services)로 구현되면, 그 투자는 정교하게 조정된 단일 에이전트 하나가 아닌 여러 팀을 지원할 수 있게 됩니다.

에이전트 팀에 필요한 세 가지 MCP 서비스

MCP 네이티브 플랫폼에서는 세 가지 공유 서비스가 협업 기질 (collaboration substrate)의 대부분을 담당합니다:

                            ┌─────────────────────┐
                            │  coordinator agent  │
                            └──────────┬──────────┘
...

이름보다는 책임의 분리가 더 중요합니다.

team-mcp: 조정 계층 (The Coordination Plane)

team-mcp는 선택된 에이전트들을 MCP 도구 (tools)로 노출합니다.

조정자 (coordinator)는 다음과 같은 것들을 볼 수 있습니다: