한 팀은 에이전트 프레임워크에서 지원 에이전트를 만듭니다. 다른 팀은 재무 에이전트를 만들고, 세 번째 팀은 영업 운영 에이전트를 만듭니다. 각 데모는 인상적입니다. 각 에이전트는 프롬프트, 모델, 일부 메모리, 몇 가지 도구, 그리고 멋진 워크플로우 그래프를 가지고 있습니다. 그러다가 기업의 현실이 찾아옵니다.

지원 에이전트는 자체적인 사설 Salesforce 커넥터를 갖습니다. 재무 에이전트는 동일한 고객 데이터에 대한 다른 커넥터를 갖습니다. 영업 운영 에이전트는

Model Context Protocol (MCP, spec 2025-11-25)는 도구(tools), 프롬프트(prompts), 리소스(resources)를 통해 AI 클라이언트와 외부 시스템 사이를 연결하는 인터페이스 계층입니다. 기업용 배포 환경에서 MCP 서버는 내부 시스템 및 SaaS 플랫폼 상의 얇고(thin), 원격이며, 대부분 상태가 없는(stateless) 인터페이스 계층이어야 합니다. 이는 웹 서버나 모바일 백엔드에 대응하는 AI 지향적(AI-facing) 요소입니다.

이로 인해 다음의 아키텍처적 관점이 명확해집니다:

• MCP 서버는 거버넌스가 적용된 기능 계층(governed capability layer)입니다.
• 에이전트(agents)는 MCP 클라이언트입니다.

에이전트는 많은 프레임워크가 보여주는 것보다 훨씬 단순합니다

아키텍처에 대해 논하기 전에, 멘탈 모델(mental model)을 단순화하는 것이 도움이 됩니다.

본질적으로 기업용 에이전트는 보통 다음 세 가지만 필요로 합니다:

1. 지침 (Instructions) — 직무 기술서입니다. 이 에이전트의 용도, 성공의 기준, 준수해야 할 경계, 사용해야 할 톤, 명확한 설명이 필요한 시점, 중단해야 할 시점, 그리고 에스컬레이션(escalate)해야 할 시점을 정의합니다.

2. LLM — 추론 및 언어 엔진입니다. 요청을 해석하고, 다음 행동을 결정하며, 도구를 호출하고, 결과를 읽고, 답변을 생성합니다.

3. 도구 (Tools) — 행동 및 데이터 액세스 접점입니다. 진지한 기업용 설계에서 이러한 도구는 단일 에이전트 내에 묶인 개별적인 헬퍼 함수(helper functions)가 아니라, MCP 서버로부터 제공됩니다.

이는 다음과 같은 단순한 루프(loop)로 이어집니다:

지침 읽기
사용자 요청 읽기
직접 답변할지 또는 도구를 호출할지 결정
...

이것이 기본적인 ReAct 루프입니다. 많은 실제 기업 사례에서 이것이 올바른 기본 모델입니다. 에이전트가 유용하게 작동하기 위해 거대한 그래프, 복잡한 프라이빗 어댑터(private adapters)의 미로, 또는 프레임워크 특화된 추상화(abstractions)의 더미가 필요하지는 않습니다.

"에이전트는 단순하다"라는 주장은 하기 쉽고 의심하기도 쉽습니다. 그러니 코드로 이를 증명해 보겠습니다.

단순함은 실재합니다: 40줄로 구현한 에이전트

PMCP SDK를 사용하여 Rust로 작성된 완전한 에이전트 예시입니다. Rust에 익숙하지 않더라도 걱정하지 마세요. 주석이 모든 중요한 라인을 설명해주며, 중요한 것은 코드의 구조입니다. 위에서 언급한 세 가지 부분이 어떻게 세 개의 코드 조각으로 직접 매핑되는지 확인해 보세요.

// -- 의존성 (Dependencies) --
// pmcp-agent: PMCP SDK를 위한 어디서나 배포 가능한 에이전트 결정 루프 (decision loop).
// 여기서 에이전트는 교체 가능한 세 가지 "이음매 (seams)"에 대한 루프입니다:
...

이제 여러분이 작성하지 않은 것들을 살펴보십시오:

• ReAct 루프를 작성하지 않았습니다. AgentEngine::run 자체가 루프입니다.
• 도구 호출(tool-dispatch)을 위한 배관 작업, 인자 파싱(argument parsing), 결과 스레딩(result threading)이 없습니다.
• 재시도(retry), 예산(budget), 또는 턴 제한(turn-limit)에 대한 장부 기록이 없습니다. 설정(config)과 엔진(engine)이 이를 관리합니다.
• 프레임워크 특정적인 그래프(graph), 노드(node), 또는 엣지(edge) 추상화가 없습니다.

남은 것은 정확히 세 부분으로 구성된 모델입니다: 한 단락의 지침(instructions), 모델 이름, 그리고 도구 이음매(tools seam)입니다. 에이전트는 의도적으로 얇게(thin) 설계되었습니다. 에이전트의 모든 레버리지는 ToolInvoker의 반대편에 존재합니다.

직접 타이핑하는 대신 스캐폴딩(scaffold)을 하고 싶다면, CLI가 전체 구조를 생성하고 스크립트된 모델을 대상으로 오프라인에서 실행할 수 있게 해줍니다. 따라서 실제 LLM이나 MCP 서버를 연결하기 전에 루프를 미리 확인할 수 있습니다:

cargo pmcp agent new support-agent   # 지침 + 세 가지 이음매 스캐폴딩
cargo pmcp agent dev --source fixed   # API 키나 네트워크 없이 오프라인에서 루프 실행

도구가 어디에서 오는가

이 예제에서 가장 중요하지만 가장 덜 중요해 보이는 한 줄은 바로 이것입니다:

OrdersTools,          // 파트 3: 도구 (MCP 경계/boundary)

ToolInvoker 경계(seam)는 에이전트와 외부 세계 사이의 전체 경계입니다. 그곳에 무엇을 연결하느냐에 따라 에이전트의 기능(capabilities)이 어디에 위치할지가 결정됩니다. 이것이 바로 하나의 타입 파라미터(type parameter)로 표현된 이 시리즈의 핵심적인 아키텍처 논거입니다. AI 에이전트는 단순히 MCP 클라이언트(client)일 뿐이라는 점을 이해하면 모든 것이 제자리를 찾게 되며, MCP 서버 커넥터(connector)를 구축하는 데 들인 모든 투자는 보안, 단순성, 확장성이라는 거대한 배당금으로 돌아옵니다.

개인적인 헬퍼 함수(helper functions)로 가득 찬 구조체(struct)를 연결하면, 당신은 '매드 맥스(Mad Max)'식 호송대를 다시 만든 셈이 됩니다. 즉, 이 에이전트만의 Salesforce 로직, 이 에이전트만의 "북미" 데이터, 이 에이전트만의 인증(auth)이 뒤섞이게 됩니다. 반면, 각 호출을 **관리되는 MCP 서버(governed MCP server)**로 전달하는 인보커(invoker)를 연결하면, 모든 기능은 단 한 번 설계, 보안 적용, 테스트 및 관찰(observed)되도록 설계된 공유 플랫폼 레이어(platform layer)로부터 제공됩니다.

PMCP SDK는 바로 그러한 프로덕션용 인보커를 제공합니다. 실제 에이전트는 OrdersTools 대신, 각 도구 호출을 MCP 서버로 전달하고 그 결과를 반환하는 ClientToolInvoker를 사용합니다. 이때 태스크(tasks)로 모델링된 장기 실행 작업(long-running work)도 포함됩니다:

// 프로덕션: 도구 경계(tools seam)가 관리되는 MCP 서버로 전달합니다.
// `connector`는 주문/CRM/창고 서버를 가리키는 MCP 클라이언트입니다.
// 에이전트는 별도의 프라이빗 커넥터 코드를 갖지 않으며, 플랫폼의 것을 빌려 씁니다.
...

에이전트의 다른 부분은 전혀 변하지 않습니다. 지침(instructions)도, 루프(loop)도, 모델(model)도 동일합니다. 유일하게 변한 것은 _기능이 어디에서 오는가_이며, 이것이야말로 당신의 에이전트 군단(fleet of agents)이 통제 가능한지(governable)를 결정해야 하는 유일한 요소입니다.

이것은 코드 차이(code diff)로 본 '기능 우선 모델(capability-first model)'입니다. 프라이빗 도구 인보커를 MCP 기반 인보커로 교체하는 것은 단 한 줄의 변경일 뿐이며, 이는 통제 불능의 데모와 플랫폼 시민(platform citizen) 사이의 차이를 만듭니다.

뇌를 교체하는 것은 단 한 줄이면 충분합니다

에이전트가 얼마나 얇아야 하는지를 증명하는 또 다른 접점(seam)은 LLM입니다. 모델이 CompletionSource 뒤에 위치하기 때문에, 모델을 변경하더라도 루프(loop), 도구(tools), 또는 지침(instructions)에는 전혀 영향을 주지 않습니다.

use pmcp_agent::sources::{AnthropicSource, OpenAiCompatSource, SecretString};

let key = SecretString::new(std::env::var("LLM_API_KEY")?);
...

두 방식 모두 동일한 접점을 충족하므로, 둘 다 AgentEngine::new에 바로 적용됩니다. 스크립트 기반 또는 로컬 모델을 사용하여 오프라인에서 개발한 뒤, 에이전트를 다시 작성할 필요 없이 프로덕션 환경을 위해 호스팅된 모델로 승격시킬 수 있습니다. 모델 교체가 이토록 쉬워지면, 특정 벤더(vendor)와 비즈니스 로직을 얽히게 만드는 일을 중단하게 됩니다. 그리고 재사용 가능한 작업물을 도구 접점(tools seam) 뒤에 있는 MCP 서버라는 본연의 위치에 유지할 수 있습니다.

역량 우선 에이전트 모델 (The Capability-First Agent Model)

코드에서 한 걸음 물러나 아키텍처를 바라보면 하나의 원칙이 읽힙니다: 역량(capabilities)은 공유 인프라이며, 에이전트는 얇은 클라이언트(thin clients)입니다.

1. 역량은 MCP 서버에 존재합니다. 도구(tools), 프롬프트(prompts), 리소스(resources), 그리고 거버넌스가 적용된 코드 모드 인터페이스(governed code-mode surfaces)는 공유 플랫폼 계층에 속해야 합니다.

2. 에이전트는 얇게 유지됩니다. 에이전트는 대부분 지침(instructions), LLM, 그리고 선택된 역량 세트—위에서 본 40줄의 코드—로 구성됩니다.

3. 특화된 에이전트 자체가 역량이 될 수 있습니다. 이후 설계에서 특화된 에이전트를 MCP를 통해 노출한다면, 다른 에이전트가 이를 일반적인 도구처럼 호출할 수 있습니다. (PMCP의 AgentServer 어댑터가 정확히 이 역할을 수행합니다. 이는 일반적인 MCP 서버와 동일한 루프를 노출합니다. 이 재귀적 단계는 다음 글의 주제입니다.)

4. 공유 상태(shared state)는 명시적으로 유지됩니다. 작업(tasks), 아티팩트(artifacts), 그리고 기록 시스템(systems of record)은 숨겨진 프롬프트 상태(prompt state)나 비공개 커넥터 로직보다 공유 상태를 담기에 더 적합한 장소입니다.

이 글은 주로 처음 두 가지 포인트에 대해 다룹니다. 다음 글에서는 이 모델을 팀 단위로 확장합니다.

실수: 도구를 에이전트의 부산물로 취급하는 것

오늘날 흔히 볼 수 있는 개발 패턴은 다음과 같습니다:

1. 에이전트 프레임워크 (agent framework) 선택
2. 에이전트의 지침 (instructions) 정의
3. 모델 (model) 선택
4. 해당 에이전트를 위한 도구 (tools) 작성
5. 이들을 서로 연결

에이전트가 눈에 보이는 실체이기 때문에 이는 자연스럽게 느껴집니다. 하지만 아키텍처 관점에서는 거꾸로 되어 있습니다. 도구가 단일 에이전트의 일부로서 생성될 때, 다음과 같은 문제들이 빠르게 나타납니다:

• 동일한 백엔드 (backend)가 서로 다른 팀들에 의해 여러 번 래핑 (wrapped) 됩니다.
• 에이전트 간에 비즈니스 의미론 (business semantics)이 어긋납니다.
• 인증 (authentication) 및 인가 (authorization) 로직이 중복됩니다.
• 관찰 가능성 (observability)이 에이전트 코드베이스 (codebases) 전반에 걸쳐 파편화됩니다.
• 테스트 품질이 팀마다 다릅니다.
• 보안 태세 (security posture)가 마지막 커넥터 (connector)를 작성한 사람이 누구인지에 따라 결정됩니다.
• 어떤 도구 구현체가 정식 (canonical) 버전인지 아무도 모릅니다.

이것이 조직이 결국 **통제 불능의 에이전트 (rogue agents)**를 갖게 되는 방식입니다. 개별적으로는 영리하지만, 집합적으로는 통제할 수 없는 상태가 되는 것입니다. 더 깊은 문제는 도구 계층 (tool layer)을 공유 플랫폼 인프라 (shared platform infrastructure)로 취급해야 함에도 불구하고, 일회용 애플리케이션 코드 (disposable application code)로 취급하고 있다는 점입니다. 코드상에서 이 실수는 단 하나의 선택, 즉 ToolInvoker 접점 (seam)에 무엇을 전달하느냐의 문제입니다.

자동차보다 먼저 도로를 구축하라

제가 아는 가장 깔끔한 비유는 교통입니다.

[

에이전트 우선 (agent-first) 모델은 마치 '매드 맥스'의 호송대와 같습니다. 모든 팀이 자신만의 차량을 처음부터 직접 만듭니다. 바퀴가 다르고, 연료 시스템이 다르고, 제어 장치가 다릅니다. 각 차량은 개별적으로는 뛰어날지 모르지만, 시스템 전체는 혼란스럽고 비용이 많이 듭니다.

MCP 우선 (MCP-first) 모델은 도로를 먼저 구축한 도시와 같습니다. 도로는 포장되어 있고, 차선은 표시되어 있으며, 신호등은 표준화되어 있고, 표지판은 공유되며, 유지보수는 조직화되어 있고, 안전 규칙은 명시적입니다. 일단 이러한 인프라가 존재하면, 누구나 운전할 수 있는 다양한 종류의 효율적인 차량들이 이를 이용할 수 있습니다.

그것이 바로 기업용 AI를 위한 MCP 서버가 존재하는 이유입니다. MCP 서버는 도로입니다. MCP 서버는 조직에 데이터 시스템에 대한 공유 인터페이스, 공유 비즈니스 정의, 공유 인증 및 인가 경계(authentication and authorization boundaries), 공유 관찰성(observability), 공유 테스트 규율, 그리고 공유 거버넌스(governance)를 제공합니다. 에이전트(Agents)는 그 인프라 위를 달리는 차량입니다. 어떤 것은 단순하고, 어떤 것은 전문화되어 있으며, 어떤 것은 공격적으로 최적화되어 있지만, 모두 동일한 도로 시스템의 혜택을 받습니다.

기업의 변화 (The Enterprise Shift)

제가 기업 팀들이 변화하기를 바라는 지점은 바로 이것입니다:

"이 조직에는 어떤 MCP 서버가 필요한가?"를 묻기 전에 "이 에이전트에게 어떤 도구가 필요한가?"라고 묻는 것을 멈추십시오.

이 두 질문은 동일하지 않습니다. 첫 번째 질문은 국소적(local)이고 단기적입니다. 두 번째 질문은 아키텍처(architectural)에 관한 것입니다. 기업 우선(enterprise-first)의 순서는 다음과 같은 모습에 가깝습니다:

1. 핵심 데이터 시스템과 비즈니스 도메인을 식별합니다.
2. 이전 글들에서 다룬 베스트 프랙티스(best practices)를 사용하여 해당 시스템들을 위한 MCP 서버를 구축합니다.
3. 결과 지향적인 도구(tools), 프롬프트(prompts), 리소스(resources), 그리고 적절한 경우 코드 모드(code mode)를 노출합니다.
4. 서버 계층에서 보안, 테스트 및 거버넌스를 적용합니다.
5. 그제서야 에이전트를 지침 세트(instruction sets)와 모델(models), 그리고 선택된 MCP 기능(capabilities)의 조합으로 정의합니다.