에이전트(Agent)에 도구를 추가하는 것은 쉽습니다. 하지만 너무 많은 도구를 추가하는 것은 에이전트를 망가뜨리는 지름길입니다.

데이터베이스를 연결하고, API를 래핑(Wrap)하고, 서버를 게시하는 작업은 몇 줄의 설정만으로 가능합니다. 하지만 특정 개수를 넘어서면 에이전트의 속도가 느려지고 잘못된 도구를 선택하기 시작합니다. Anthropic은 이 메커니즘을 문서화한 바 있습니다. 도구 정의(Tool definitions)만으로도 에이전트가 작업을 시작하기도 전에 수만 개의 토큰(Tokens)을 소비할 수 있습니다.

규모가 커짐에 따라 세 가지 문제가 발생합니다: 무엇을 노출할 것인가, 에이전트가 이를 어떻게 찾을 것인가, 그리고 누가 접근을 제어할 것인가입니다.

원시 인프라가 아닌 역량을 래핑하세요

가장 흔한 프로덕션 실수는 일반적인 기술적 연산을 노출하는 것입니다:

execute_sql(query)
call_http(url, method, body)
run_shell(command)

이는 너무 많은 책임을 확률적 모델 추론(Probabilistic model reasoning)에 떠넘기는 행위입니다. 모델은 테이블 이름을 파악하고, 스키마(Schema) 관계를 이해하며, 유효한 쿼리를 구성하고, 파괴적인 연산을 피해야 합니다. 모든 호출은 환각(Hallucination)이 발생할 수 있는 새로운 기회가 됩니다.

프로덕션 도구는 비즈니스 역량(Business capability)을 노출해야 합니다:

simulate_order_cancellation(order_id)
request_order_cancellation(order_id, reason)
create_refund_proposal(order_id, amount, evidence)

도구 뒤에 있는 도메인 서비스(Domain service)가 주문 상태, 환불 한도, 고객 소유권, 멱등성(Idempotency) 및 감사(Audit)를 강제합니다. 모델은 역량을 선택하고, 비즈니스 시스템이 연산을 검증합니다.

API는 유지됩니다. MCP는 적응합니다.

기존의 주문 서비스는 이미 인증, 검증, 상태 확인, 트랜잭션 및 이벤트 게시를 처리하고 있습니다. 이를 MCP 서버 내부에서 재구현하지 마세요. 대신 다음과 같이 구성하십시오:

Agent → MCP 호출 → 얇은 어댑터(Thin adapter) → HTTPS → 주문 서비스 → DB + 이벤트

MCP 계층은 에이전트용 역량 설명과 기존 서비스 계약(Service contracts) 사이를 번역합니다. 비즈니스 로직은 웹, 모바일, 배치(Batch) 및 에이전트 클라이언트 전반에서 재사용 가능한 상태로 유지됩니다.

도구 카탈로그 문제

수백 개의 도구를 사용할 수 있는 상황에서는 모든 모델 요청이 비용이 많이 들고 신뢰할 수 없게 됩니다. 아키텍처는 "모두 로드하기"에서 "검색 및 필터링"으로 전환되어야 합니다:

사용자 목표 → 기능 검색 → 권한 필터링 → 순위가 매겨진 도구 → 모델이 5~10개 수신

카탈로그 항목에는 이름과 스키마(Schema) 이상의 정보가 필요합니다:

name: create_supplier_assessment
domain: procurement
owner: supplier-risk-team
...

도구 설계는 제품 설계가 됩니다. 좋은 도구란 올바르게 선택하기 쉽고, 오용하기 어렵며, 범위가 제한적이고, 부작용(Side effects)이 명시적이며, 실패 모드(Failure modes)가 명확하고, 응답 시 토큰 효율적(Token-efficient)인 도구입니다.

MCP 권한 부여(Authorization): 필요하지만 충분하지는 않음

MCP에는 OAuth 기반의 권한 부여 프레임워크가 포함되어 있습니다. 이는 프로토콜 수준의 상호 운용성(Interoperability)을 처리합니다. 하지만 다음 사항은 처리하지 않습니다:

• 도구 수준의 권한 부여 (Tool-level authorization): 이 에이전트가 이 특정 도구를 호출할 수 있는가?
• 사용자 동의 범위 (User consent scope): 인간이 이 특정 작업을 승인했는가?
• 자격 증명 저장 (Credential storage): 다운스트림 서비스 토큰은 어디에 저장되는가?
• 서버 신뢰 (Server trust): 이 MCP 서버는 검토 및 승인되었는가?
• 프롬프트 주입 저항성 (Prompt-injection resistance): 입력 조작을 통해 제어 장치를 우회할 수 있는가?

유효한 토큰은 신원을 증명합니다. 하지만 에이전트가 이 도구를 호출할 수 있는지, 사용자가 이 작업을 승인했는지, 또는 요청된 금액이 정책 범위 내에 있는지는 증명하지 못합니다.

MCP 서버를 소프트웨어 공급업체로 취급하기

내부 MCP 레지스트리(Registry)가 개발자들이 온라인에서 찾아낸 URL 목록이 되어서는 안 됩니다. 각 프로덕션 서버에는 거버넌스(Governance)가 필요합니다:

name: procurement-capabilities
owner: procurement-platform-team
version: 2.3.1
...

플랫폼은 각 서버의 전체 생명주기(Lifecycle)를 관리해야 합니다. 즉, 사전에 등록 및 소유권을 정의하고, 배포 전 보안 검토를 수행하며, 버전 관리와 함께 폐기(Deprecate) 및 취소(Revoke)를 위한 깔끔한 경로를 제공해야 합니다. 이는 공급망(Supply chain) 내의 다른 모든 종속성(Dependency)에 적용하는 것과 동일한 규율입니다.

신뢰 구역(Trust zone)별로 게이트웨이 분할하기

500개의 도구를 가진 하나의 범용 게이트웨이는 보안 안티 패턴(Anti-pattern)이자 카탈로그 문제입니다. 도메인과 위험도에 따라 분할하십시오:

analytics-readonly-gateway        → 읽기 전용 데이터 도구 (read-only data tools)
developer-tools-gateway           → 코드, 문서, CI/CD
customer-service-gateway          → CRM, 주문 관리
...

모델이 단순히 비용 데이터를 조회해야 한다는 이유만으로 프로덕션 삭제 (production-deletion) 도구를 볼 수 있어서는 안 됩니다. 게이트웨이 세분화 (segmentation)는 보안 경계 (security boundary)인 동시에 도구 선택의 품질을 개선하는 방법입니다. 즉, 무관한 도구가 적을수록 모델의 선택이 더 정확해집니다.

코드 실행 (Code execution): 새로운 오케스트레이션 (orchestration)

초기 에이전트 (Early agents): 도구 하나를 호출하고, 모델로 돌아오고, 다른 도구를 호출하고, 다시 돌아오는 과정을 반복합니다. 각 왕복 (round trip) 과정은 토큰을 소모하고 지연 시간 (latency)을 추가합니다.

최신 패턴: 모델에게 샌드박스화된 실행 환경 (sandboxed execution environment)을 제공합니다:

모델 (Model) → 샌드박스 프로그램 (Sandboxed program)
           ├── 도구 A 호출
           ├── 도구 B를 병렬로 호출
...

이는 분석 작업 시 왕복 횟수를 10회 이상에서 1회로 줄여줍니다. 플랫폼은 안전한 도구, 리소스 제한 (resource limits), 네트워크 제한 (network restrictions), 그리고 출력 검증 (output validation)을 제공합니다. 모델은 이를 연결하는 글루 코드 (glue code)를 작성합니다.

샌드박스는 여전히 격리 (isolation), CPU 및 메모리 제한 (caps), 자격 증명 경계 (credential boundaries), 패키지 제한 (package restrictions), 그리고 감사 (auditing)가 필요합니다. 코드 실행은 유연성을 제공하는 것이지, 안전성을 보장하는 것이 아닙니다.

월요일 아침에 해야 할 일

1. 기존 MCP 서버를 감사 (Audit) 하십시오. 각 서버에 소유자, 보안 검토, 데이터 분류, 그리고 네트워크 경계가 지정되어 있습니까? 그렇지 않다면 프로덕션 환경에 사용할 준비가 되지 않은 것입니다.

2. 요청당 도구 개수를 확인하십시오. 모델이 50개 이상의 도구 정의를 받는다면 카탈로그 문제입니다. 검색 기반의 도구 선택 (search-based tool selection)을 구현하십시오.

3. 신뢰 구역 (trust zone)에 따라 게이트웨이를 세분화하십시오. 도구를 도메인 및 위험 수준에 매핑하십시오. 읽기 전용 분석 작업을 쓰기 작업 (write operations)과 분리하십시오.

4. 도구의 세분도 (granularity)를 검토하십시오. 가공되지 않은 SQL, HTTP, 또는 셸 (shell)을 노출하는 각 도구는 언제든 프로덕션 장애 (production incident)로 이어질 수 있는 시한폭탄입니다. 인프라가 아닌 비즈니스 역량 (business capabilities)을 래핑 (wrap) 하십시오.

이 시리즈의 이전 글: Agent Identity and Durable Workflows: The Two Problems MCP Can't Solve — 왜 ID와 상태 지속성이 실제 엔터프라이즈 격차인가.
이 시리즈의 다음 글: Agent Identity and Durable Workflows: The Two Problems MCP Can't Solve — 왜 ID와 상태 지속성이 실제 엔터프라이즈 격차인가.