MCP 도구 계약을 위한 실질적인 체크리스트 (연결은 쉬운 부분이기 때문)

범용 소켓은 유용하지만, 에이전트(Agent)에게는 각 도구가 무엇을 하는지, 언제 호출하는 것이 안전한지, 그리고 그 효과를 어떻게 증명할지에 대한 읽기 쉬운 계약(Contract)이 여전히 필요합니다.

모델의 메뉴에 있는 두 가지 도구를 상상해 보세요. 하나는 lookup이라고 불리고, 다른 하나는 send라고 불립니다. 둘 다 프로토콜(Protocol) 하에서 유효하며, 둘 다 깔끔하게 연결됩니다. 하지만 어느 것도 모델에게 lookup이 고객의 전체 이메일 내역을 조용히 가져올 수 있는지, 혹은 send가 호출 즉시 외부 편지함으로 메시지를 발송하는지 아니면 검토를 위해 초안을 작성하는지 알려주지 않습니다.

연결은 성공했지만, 결정 표면(Decision surface)은 실패했습니다. MCP는 그 표면에 표준화된 형태를 부여하지만, 그 자체로 결정을 읽기 쉽게 만들어주지는 않습니다. 만약 여러분이 에이전트 도구를 구축한다면, 그 간극이 바로 여러분의 작업이 실제로 시작되는 지점이며, 이 글은 여러분 자신의 표면을 검토하기 위한 체크리스트로 활용되기를 의도했습니다.

연결을 통해 무료로 얻는 것들

프로토콜의 공로를 인정해야 합니다. Anthropic이 2024년 말 MCP를 도입했을 때, 명시된 목적은 일회성 맞춤형 커넥터(Connector)를 AI 시스템을 도구 및 데이터에 연결하기 위한 단일 개방 표준으로 대체하는 것이었습니다. 그것은 실제적인 문제였고, MCP는 그에 대한 실제적인 해답입니다. 모든 모델과 모든 데이터 소스에 대해 통합 배관(Integration plumbing)을 매번 다시 구축하는 대신, 공통된 경계(Boundary)를 얻게 됩니다.

현재의 도구 사양(Tools specification)은 그 경계를 구체화합니다. 도구는 모델에 의해 제어되며, 각 도구는 메타데이터(Metadata)로 표현됩니다: 이름, 설명, 입력 스키마(Input schema), 선택적 출력 스키마(Output schema), 그리고 선택적인 동작 주석(Behavior annotations)입니다. 발견(Discovery), 호출(Invocation), 그리고 교환의 형태가 표준화되어 있습니다. 이것이 진정한 레버리지(Leverage)입니다.

하지만 표준화가 무엇을 제공하고 무엇을 제공하지 않는지 주목하십시오. 규격에 맞는 애플리케이션(Conforming application)을 사용하면 표준 인터페이스를 통해 도구를 발견(Discovery)하고 호출(Call)할 수 있습니다. 하지만 이것이 해당 도구를 이해하거나, 올바르게 선택하거나, 안전하게 호출할 수 있음을 보장하지는 않습니다. 전송 호환성(Transport compatibility)이 의미론적 명확성(Semantic clarity)을 의미하는 것은 아니며, 호스트 정책(Host policy)을 의미하는 것도 아닙니다. 동일한 명세(Specification)에서도 이 경계에 대해 주의를 기울이고 있습니다. 명세는 사람이 도구 호출을 거부할 수 있는 상태를 유지할 것을 권장하며, 동작 주석(Behavior annotations)은 이미 신뢰하는 서버로부터 온 것이 아니라면 신뢰할 수 없는 것으로 취급해야 한다고 경고합니다. 즉, 프로토콜 자체는 메타데이터가 안전 보장이 아닌 시작점일 뿐이라고 말하고 있습니다. 아래의 모든 내용은 여러분이 직접 구축해야 하는 부분입니다.

계약(Contract), 부분별 분석

사람들이 도구가 "연결되었다(Wired up)"라고 말할 때, 이는 보통 호출이 작동한다는 것을 의미합니다. 더 유용한 질문은 해당 도구가 읽기 쉬운 계약(Contract)을 노출하느냐 하는 것입니다. 그 계약을 설정 파일(Config file)을 채우기 위한 체크리스트가 아니라, 여러 가동 부품을 가진 하나의 메커니즘으로 취급하십시오.

An MCP plug feeds one continuous path through tool-contract interpretation, a host-policy gate, and three verified outcomes: changed, no-op, or unknown. Only the connector sits above the system-ownership boundary.

캡션: MCP 소켓(Socket)은 요청을 전달합니다. 도구의 의미(Meaning), 호스트 권한(Host permission), 그리고 효과의 증명(Proof of effect)은 하류(Downstream)에서 설계됩니다.

의도를 드러내는 이름(intent-revealing name)은 모델이 다른 어떤 것을 읽기 전에 이 도구를 가장 유사한 다른 도구와 분리할 수 있게 해줍니다. 제한된 설명(bounded description)은 도구가 무엇을 하는지, 그리고 결정적으로 무엇을 하지 않는지를 명시합니다. 제약된 입력 스키마(constrained input schema)는 유효하지 않거나 불충분하게 지정된 호출을 표현하기 어렵게 만들어, 위험하거나 모호한 인자(argument)가 들어설 여지를 줄여줍니다. 구조화된 출력(structured output)은 호출자에게 성공처럼 들리는 친절한 문장 대신, 실제로 어떤 일이 일어났는지에 대한 증거를 제공합니다. 명시적인 부수 효과(side effects)와 전제 조건(preconditions)은 도구가 실행되는 순간 무엇이 변하는지, 그리고 무엇이 먼저 충족되어야 하는지를 알려줍니다. 그리고 실패 의미론(failure semantics)은 호출이 계획대로 진행되지 않을 때 모델이 어떻게 이를 인식하고 복구해야 하는지를 알려줍니다.

lookup(query)를 더 잘 정의된 두 가지 도구와 비교해 보십시오. 쓰기 작업을 수행하지 않음을 약속하고 구조화된 레코드를 반환하는 읽기 전용 고객 검색 도구는, 즉시 외부 이메일을 전송하는 도구와 근본적으로 다른 객체입니다. 모호한 표면 아래에서는 두 도구 모두 동일한 일반적인 동사 뒤에 숨을 수 있습니다. 하지만 실제 계약(contract) 하에서는 모델이 행동을 결정하기 전에 두 도구를 구별할 수 있습니다. 계약의 구성 요소들은 장식이 아닙니다. 그것들은 모델이 선택을 내리는 데 사용하는 정보입니다.

추론 가능한 작은 실험

도구 표면(tool surface)의 문구가 모델의 첫 번째 움직임을 얼마나 변화시키는지 확인하고 싶어서, 이 기사를 위해 작은 로컬 피스처(local fixture)를 실행했습니다. 이것은 방향성을 제시하는 증거일 뿐 그 이상은 아니기에, 얼마나 작은 규모인지 정확히 밝히고자 합니다.

저는 10개의 합성 CRM 및 이메일 요청(request)을 작성했습니다. 각 요청을 동일한 모델인 GPT-5.6 Sol에게 두 가지 조건 하에 보여주었습니다. 모호한 조건(vague condition)은 일반적인 이름, 한 줄짜리 설명, 그리고 허용적인 스키마(permissive schemas)를 사용했습니다. 계약이 풍부한 조건(contract-rich condition)은 의도를 드러내는 이름, 부작용(side-effect) 및 전제 조건(precondition) 설명, 그리고 제약된 스키마(constrained schemas)를 묶어서 제공했습니다. 각 조건은 두 번의 독립적인 실행을 통해 사례당 6개의 관찰(observations)을 받았습니다. 어떤 도구도 실제로 실행되지는 않았습니다. 저는 실제 MCP 서버 대신 OpenAI 호환 함수 호출(function-calling) 어댑터를 사용했기 때문에, 루프 내에 백엔드도, 인증 계층(authorization layer)도, 지연 시간(latency)도, 복구 경로(recovery path)도 없었습니다.

Comparison graphic. The vague tool surface produced 49 expected first actions out of 60, while the contract-rich surface produced 60 out of 60. For explicit email sending the scores were 1 of 6 versus 6 of 6; for an unsupported email audit they were 0 of 6 versus 6 of 6. The fixture used one model and no tool was executed.

캡션: 10개의 합성 프롬프트(synthetic prompts)를 두 번 실행했을 때, 모호한 표면(vague surface)은 60개 중 49개의 예상되는 첫 번째 동작을 생성했습니다. 계약이 풍부한 표면(contract-rich surface)은 60개 중 60개를 생성했습니다. 하나의 모델을 테스트했으며, 처치(treatment)는 여러 인터페이스 차원을 동시에 변경했고, 어떤 도구도 실행되지 않았습니다.

모호한 표면은 60개의 관찰 중 49개에서 예상되는 첫 번째 동작을 생성하여 81.7%를 기록했습니다. 계약이 풍부한 표면은 60개 중 60개에서 생성하여 100%를 기록했습니다. 두 가지 범주의 프롬프트가 이 격차를 유발했습니다. 도구가 실제로 지원하지 않는 동작을 요청한 6개의 프롬프트(이메일 감사)에서, 모호한 표면은 거절하거나 명확히 하는 대신 일반적인 조회(lookup)를 시도함으로써 6개 모두 실패했습니다. 이메일 전송을 명시적으로 요청한 6개의 프롬프트에서, 모호한 표면은 단 하나만 예상대로 처리했습니다. 더 나은 메타데이터(metadata)가 이 실험 장치(fixture) 내의 두 격차를 모두 메웠습니다.

과장해서 말하지는 않겠습니다. 이것은 하나의 모델, 10개의 수동 작성된 프롬프트, 그리고 제공자 기본 온도(provider-default temperature) 설정의 결과입니다. 처치는 이름, 설명, 스키마를 함께 묶었기 때문에, 이 세 가지 중 무엇이 효과를 냈는지 분리할 수 없습니다. 이것은 벤치마크(benchmark)라기보다는 실험 장치(fixture)이며, 계수(coefficient)라기보다는 방향성을 보여주는 것입니다.

하나의 실험 장치(fixture)를 넘어 체크리스트가 중요한 이유

최근 발표된 두 편의 프리프린트(preprint)는 왜 이 경계가 저의 토이 설정(toy setup) 이상의 의미를 갖는지 보여줍니다.

2026년 7월에 제출된 프리프린트인 DynamicMCPBench는 효과 점수가 매겨진 트레이스(effect-scored traces)와 세 번의 성공을 요구하는 엄격한 pass^3 규칙을 사용하여, 15개 카테고리의 750개 작업과 121개 서버에 걸쳐 24개의 모델을 평가합니다. 가장 강력한 에이전트(agent)들도 작업의 약 절반만을 해결했습니다. 31%는 어떤 모델도 해결하지 못했습니다. 정확도는 가장 짧은 도구 체인(tool chains)에서의 39%에서 가장 긴 체인에서의 13%로 떨어졌습니다. 다시 말해, 연결성(connectivity)이 곧 완료(completion)는 아닙니다. 이 벤치마크(benchmark)에서 도구 체인이 길어질수록 신뢰도는 낮아졌습니다. 저자들은 또한 우리가 채택할 만한 가치가 있는 점을 지적합니다. 효과 점수가 매겨진 트레이스는 다듬어진 최종 답변보다 실제 행동이 발생했는지 여부에 대해 더 많은 것을 알려준다는 점입니다.

같은 달에 제출된 두 번째 프리프린트인 1,723개의 GitHub MCP 애플리케이션에 대한 실증적 연구는 점수가 어떻게 나오는지보다는 이러한 시스템이 어떻게 구축되는지를 살펴봅니다. 보고에 따르면 90.8%가 실행의 최소 일부를 로그(log)로 남기고, 77.2%가 활성화(enable) 및 비활성화(disable) 제어 기능을 노출하지만, 도구가 실행되기 전 차단 승인 게이트(blocking approval gate)를 구현한 경우는 37.2%에 불과했습니다. 이를 실제 운영 환경의 배포 현황(census)이 아니라, LLM 지원 분류 파이프라인(LLM-assisted classification pipeline)으로 분석된 GitHub 샘플로 취급하십시오. 그럼에도 불구하고, 이는 실제로 안전을 관리하는 호스트 측 제어(host-side controls)가 이질적(heterogeneous)이라는 것을 말해줍니다. 프로토콜은 인간의 거부권(veto)을 허용합니다. 조사된 대부분의 프로젝트는 실행 전에 이를 강제하지 않았습니다.

이 두 가지를 종합해 보면 다음과 같습니다. 도구 인터페이스(tool interface)는 모델에게 결정 표면(decision surface)을 제공하고, 호스트 정책(host policy)은 선택이 행동이 될 때 어떤 일이 일어날지를 규정합니다. 작동하는 연결(connection)이 있다고 해서 이 두 가지가 저절로 따라오는 것은 아닙니다.

체크리스트: 다음 도구 검토를 위한 다섯 가지 질문

도구를 출시하기 전에 모든 도구 표면(tool surface)에 대해 이 질문들을 실행해 보십시오. 의도적으로 짧게 구성되었습니다.

1. 다른 도구가 동일한 요청을 그럴듯하게 수행할 수 있습니까? 만약 그렇다면, 여러분의 이름(names)과 설명(descriptions)이 제 역할을 충분히 하지 못하고 있는 것입니다.
2. 스키마(schema)가 불충분하게 지정되었거나 위험한 호출(call)을 너무 쉽게 표현할 수 있습니까? 잘못된 호출을 표현하기 어려울 정도로 입력을 엄격하게 제한하십시오.
3. 모델이 무엇이 즉각적으로 변하는지 알고 있습니까? 부작용(side effects)과 전제 조건(preconditions)은 암묵적인 지식(tribal knowledge)이 아니라 계약(contract)에 포함되어야 합니다.
4. 결과가 구조화된 데이터(structured data)를 통해 그 효과를 증명할 수 있습니까? 확신에 찬 문장은 동작이 실제로 발생했다는 증거가 아닙니다.
5. 모델이 잘못된 선택을 하더라도 호스트(host)가 강제하는 것은 무엇입니까? 권한 부여(Authorization), 승인(approval), 그리고 추적 가능성(traceability)은 모델 외부에서 작동하며, 더 나은 문구로 이를 대체할 수는 없습니다.

플러그가 맞습니다. 이제 엔지니어링이 시작됩니다.

MCP는 플러그가 맞도록 만들어 주었으며, 그것만으로도 충분히 가치 있는 일이었습니다. 하지만 소켓(socket)은 어려운 부분을 단지 다음 단계로 미룰 뿐입니다. 진짜 작업은 무엇이 그 소켓을 통해 흐를 수 있는지, 모델이 어떻게 하나의 도구를 다른 도구와 구별할 수 있는지, 그리고 여러분의 호스트가 동작이 의도한 대로 발생했음을 어떻게 증명할지를 결정할 때 시작됩니다.

여기 여러분에게 던지는 질문이 있습니다. 여러분이 출시했거나 물려받은 도구 계약 중 가장 위험할 정도로 모호했던 것은 무엇이며, 무엇이 결국 여러분으로 하여금 계약을 엄격하게 만들게 했습니까?