MCP 래퍼(Wrapper) 제작을 중단하고, 대신 도메인 특화 도구를 구축하세요

몇 주 전, Pinterest 엔지니어링 팀은 실제 운영 환경의 MCP 배포 수치를 공개했습니다: 월간 약 66,000회의 도구 호출(tool invocations), 844명의 활성 사용자, 월간 약 7,000시간의 엔지니어링 시간 절감 효과를 기록했습니다. (출처)

눈에 띄는 점은 규모가 아니었습니다. 바로 그들이 생략하지 않은 부분 이었습니다. 모든 서버는 운영 환경에 적용되기 전 보안, 법률, 개인정보 보호 및 컴플라이언스(compliance) 검토를 통과했습니다. 민감한 작업에는 반드시 사람의 승인이 필요했습니다.

이것이 대부분의 MCP 튜토리얼이 생략하는 부분입니다. 대부분의 가이드는 5분 만에 API를 래퍼(wrap)하는 방법을 보여줍니다. 하지만 AI 에이전트가 자율적으로 호출하기에 실제로 안전하고 유용한 도구를 설계하는 방법을 보여주는 가이드는 거의 없습니다.

이 포스트에서는 작동하는 FastMCP 3.x 코드를 사용하여, 일반적인 장애/로그 분석(incident/log-analysis) 도메인을 예시로 들어 그 간극을 메워보겠습니다.

래퍼 본능 (The wrapper instinct)

MCP 서버를 구축하는 가장 빠른 방법은 기존 API를 가져와 모든 엔드포인트(endpoint)를 1:1로 도구(tool)로 노출하는 것입니다. 다음과 같은 형태가 됩니다:

from fastmcp import FastMCP

mcp = FastMCP("incidents")
...

이 방식은 작동합니다. 데모에서는 통과할 것입니다. 하지만 이는 운영 환경에서 문제를 일으키는 정확한 패턴이기도 합니다:

• 도메인 의미론(domain semantics)의 부재. 모델은 어떤 "status" 값이 유효한지, 무엇이 중복된 장애(duplicate incident)로 간주되는지, 귀하의 시스템에서 심각도(severity)가 실제로 무엇을 의미하는지 추론해야 합니다. 이 중 어느 것도 어디에도 인코딩되어 있지 않습니다.
• 거버넌스(governance)의 부재. update_incident는 아무런 마찰 없이 호출될 수 있습니다. 요청을 잘못 읽은 에이전트가 운영 상태를 조용히 변경할 수 있습니다.
• 컨텍스트 팽창(Context bloat). GitHub의 MCP 서버를 기반으로 작업하는 한 개발자는, 아무것도 하기 전에 40개 이상의 도구를 컨텍스트(context)에 쏟아붓는 것과 같다고 설명했습니다. 이는 모델이 매 턴마다 모든 도구 설명을 바탕으로 추론해야 하므로 에이전트의 성능을 측정 가능한 수준으로 저하시킵니다.

얇은 1:1 래퍼는 데모를 빠르게 만드는 방법입니다. 하지만 에이전트가 감독 없이 호출하는 도구로서 적절한 형태인 경우는 드뭅니다.

대신 도메인 특화 도구 설계하기

대안은 더 많은 도구가 아닙니다. 도메인 전문가가 수동으로 적용할 판단력을 인코딩한, 더 적고 똑똑한 도구입니다.

재설계된 동일한 사고 분석 (incident-analysis) 도메인의 예시는 다음과 같습니다:

from fastmcp import FastMCP
from pydantic import BaseModel, Field
from enum import Enum
...

의도적으로 변경된 몇 가지 사항은 다음과 같습니다:

도메인 로직을 프롬프트 (prompt)가 아닌 도구 (tool) 내부로 이동했습니다. "무엇을 잠재적 중복으로 간주할 것인가"는 특정 도메인에 특화된 판단 사항입니다. 즉, 특정 시간 범위 내에서 오류 시그니처 (error signature)를 기준으로 클러스터링 (clustering) 하는 것입니다. 이를 도구에 인코딩하면, 모델이 매번 로직을 다시 유도하거나 (또는 추측하거나) 하는 대신 모든 호출자가 동일하고 정확한 답변을 얻게 됩니다.

읽기 (read)와 쓰기 (write)는 서로 다른 도구입니다. propose_incident_resolution은 절대 무엇도 변경할 수 없습니다. 구조적으로 읽기 전용 (read-only)입니다. apply_resolution은 상태 변경 (state change)을 위한 단일하고 좁은 경로이며, 명시적인 인간 확인 (human-confirmation) 플래그 없이는 실행을 거부합니다. 이는 Pinterest의 기술 블로그에서 민감한 작업에 대해 설명한 인간 참여형 (human-in-the-loop) 패턴을 단순화한 버전입니다.

반환 타입 (return types)은 가공되지 않은 행 (raw rows)이 아닌 구조화된 형태입니다. IncidentSummary Pydantic 모델은 에이전트(및 사용자)에게 타입이 지정된 예측 가능한 계약 (contract)을 제공합니다. 또한 needs_human_review 플래그는 모델이 딕셔너리 (dict) 목록으로부터 긴급성을 올바르게 추론하기를 기대하는 대신, 모델의 추론 중 일부를 대신 수행해 줍니다.

3배의 N이 아닌, 단 3개의 도구입니다. 모든 테이블 연산을 노출하는 대신, 이 서버는 온콜 (on-call) 엔지니어가 실제로 생각하는 방식인 "무슨 일이 일어나고 있는가", "어떻게 조치할 것인가", "좋아, 그렇게 해"에 매핑되는 세 가지 도구를 노출합니다. 컨텍스트 (context) 내의 도구 수는 줄어들었지만, 각 도구는 더 큰 도메인 비중을 갖게 됩니다.

이것이 프로토콜 선택보다 더 중요한 이유

MCP 그 자체는 인프라(infrastructure)가 되어가고 있습니다. Anthropic의 내부 사양(spec)에서 시작하여 약 16개월 만에 OpenAI, Google, Microsoft가 지원하는 Linux Foundation 표준이 되었습니다. (source) 이러한 수렴(convergence)은 프로토콜 계층이 빠르게 범용화(commoditizing)되고 있음을 의미합니다. 모든 팀이 동일한 전송(transport) 방식, 동일한 SDK, 동일한 클라이언트 지원을 사용할 수 있게 될 것입니다.

범용화되지 않을 것은 도구 설계(tool design)입니다. 자율 에이전트(autonomous agent)에게 안전하게 넘겨줄 수 있는 서버와 그렇지 않은 서버의 차이는 정확히 위에서 언급한 선택 사항들에 달려 있습니다. 즉, 무엇이 읽기 전용(read-only)인지, 무엇이 확인(confirmation)을 필요로 하는지, 그리고 매 호출마다 다시 유도되는 대신 한 번만 인코딩(encoded)될 도메인 로직(domain logic)은 무엇인지에 대한 결정입니다.

만약 여러분이 지금 MCP 서버를 구축하고 있다면, 프로토콜에 관한 결정은 대부분 이미 내려져 있습니다. 하지만 판단(judgment calls)이 필요한 영역은 그렇지 않습니다.

직접 시도해보고 싶다면: 빠른 시작

uv add fastmcp

# server.py — 최소 실행 가능 버전
from fastmcp import FastMCP

...

fastmcp dev server.py

이 명령은 MCP Inspector를 실행하여, Claude Desktop, Cursor 또는 기타 MCP 클라이언트에 연결하기 전에 가공되지 않은 도구 호출(tool calls)과 응답을 확인할 수 있게 해줍니다.

이 글은 기업이 AI를 도입할 때 실제로 무엇이 부족한지에 대해 제가 LinkedIn에 연재하고 있는 짧은 시리즈의 동반 게시물입니다. 훈련 단계의 한계부터, 왜 AI 역량을 '소유'한다는 것이 단순히 모델을 선택하는 것이 아니라 매력적이지 않은 설계 작업(design work)을 수행하는 것을 의미하는지에 대해 다룹니다.