Table of contents
Inspector — 빠른 피드백 루프의 출발
5편에서 npx @modelcontextprotocol/inspector로 서버를 띄워봤다. 가볍게 다뤘지만 실전 개발 흐름에서는 Inspector의 위치가 가장 크다.
서버 코드를 고치고 → 호스트(Claude Desktop)를 재시작 → 채팅에서 도구를 부르고 → 응답을 확인하는 사이클은 한 라운드에 분 단위가 걸린다. Inspector를 끼우면 같은 사이클이 초 단위가 된다. 도구·자원·프롬프트별 탭에서 인자를 직접 입력해 호출하고, 캐퍼빌리티가 어떻게 협상됐는지 한 화면에서 본다.
세 가지 패턴이 자주 쓰인다.
- 로컬 개발 —
npx @modelcontextprotocol/inspector node ./build/index.js로 로컬 빌드를 띄운다. 코드 수정 → 재빌드 → Inspector 재연결만 반복한다. - npm/PyPI 패키지 검수 —
npx @modelcontextprotocol/inspector npx @modelcontextprotocol/server-filesystem /path처럼 공개 서버를 바로 띄워 동작을 확인한다. 호스트에 등록하기 전에 한 번 거치는 게 좋다. - 원격 서버 디버깅 — Streamable HTTP 트랜스포트로 원격 서버에 붙어서 capability·인증 흐름을 본다.
Inspector는 디버깅 GUI인 동시에 spec 시각화 도구다. 처음 MCP 서버를 만든다면 호스트보다 Inspector를 먼저 본다 — 코드와 spec 사이의 거리가 가장 짧은 자리다.
Registry — 서버를 찾는 카탈로그
서버를 만들어 공개해도 남이 어떻게 찾을지가 다음 문제다. MCP Registry가 그 자리에 들어선다. 2026년 현재 preview 단계지만, Anthropic·GitHub·PulseMCP·Microsoft가 같이 운영하는 공식 중앙 메타데이터 저장소다.
Registry 자체는 코드를 호스팅하지 않는다. npm·PyPI·Docker Hub 같은 패키지 저장소가 코드와 바이너리를 들고 있고, Registry는 그걸 가리키는 메타데이터만 갖는다. 한 서버에 대해 표준화된 server.json이 들어 있다.
{
"name": "io.github.example/weather",
"description": "Weather data via NWS API",
"packages": [
{ "registry": "npm", "name": "@example/mcp-weather", "version": "1.2.0" }
],
"remotes": [
{ "transport": "streamable-http", "url": "https://weather.example.com/mcp" }
]
}
출처: Model Context Protocol Registry 공식 문서
이름 공간(io.github.user/server 같은 reverse-DNS 형식)은 DNS·GitHub 인증으로 검증한다. 누구나 임의로 이름을 차지할 수 없게 짠 장치다.
흐름은 셋이다.
- 서버 개발자 —
server.json을 publish. - 다운스트림 마켓플레이스 — Registry API로 정기 풀링해 자기 마켓플레이스에 큐레이션·평점·추가 메타데이터를 얹는다.
- 호스트 (Claude Desktop, Cursor 등) — Registry를 직접 보지 않는다. 다운스트림 마켓플레이스나 자체 카탈로그를 통해 본다.
비공개 서버는 Registry에 올리지 않는다 — 사내 네트워크 전용이라면 자체 private registry를 운영하는 게 권장이다. Registry가 정의한 OpenAPI spec을 그대로 구현하면 호스트와 자연스럽게 호환된다.
Tasks — 긴 작업을 위한 비동기 패턴
tools/call은 동기다. 클라이언트가 요청을 보내고 응답이 올 때까지 기다린다. 그런데 수 분 걸리는 분석, 몇 시간이 걸리는 배치 처리, 외부 잡 시스템에 큐잉된 작업 같은 게 들어오면 동기 모델로는 잘 안 맞는다. 2025-11-25 spec에서 이 자리를 위해 Tasks가 experimental로 들어왔다.
Tasks의 모양은 단순하다. 일반 요청에 task 필드를 같이 보내면, 받는 쪽이 즉시 task ID를 돌려준다. 실제 결과는 나중에 polling으로 가져온다.
// 요청 (task 모드)
{ "method": "tools/call",
"params": {
"name": "monthly_revenue_report",
"arguments": { "month": "2026-04" },
"task": { "ttl": 3600000 }
}
}
// 즉시 응답 — task 데이터만
{ "result": {
"task": {
"taskId": "786512e2-...",
"status": "working",
"pollInterval": 5000
}
}
}stateDiagram-v2
[*] --> working
working --> input_required
working --> completed
working --> failed
working --> cancelled
input_required --> working
input_required --> completed
input_required --> failed
input_required --> cancelled
completed --> [*]
failed --> [*]
cancelled --> [*]Polling은 tasks/get, 결과 회수는 tasks/result. 결과 회수는 task가 종료 상태(completed/failed/cancelled)에 도달할 때까지 블록된다 — long polling 패턴이다. 중간에 사용자 입력이 필요하면 task가 input_required로 잠시 빠지고, 그 동안 elicitation이 끼어든다.
흥미로운 건 서버 → 클라이언트 요청도 task로 감쌀 수 있다는 점이다. 서버가 sampling이나 elicitation을 task-augmented로 보내면, 클라이언트가 즉시 task ID를 돌려주고 비동기로 처리한다. 호스트 입장에선 모델에게 진행 중 신호를 먼저 돌려보내고, 결과가 준비되면 다시 모델에 흘려넣을 수 있다.
Tasks는 experimental이라 향후 spec에서 모양이 더 다듬어질 가능성이 있다. 그래도 핵심 발상 — MCP 메시지를 비동기 잡 시스템과 자연스럽게 합치는 wrapper — 은 자리 잡았다고 보면 된다.
2026 로드맵 — 네 축
여기까지 본 모든 것이 지금까지 자리 잡은 spec이다. 공식 2026 로드맵이 다음으로 향하는 네 축을 정리한다.
1. Transport scalability
6편에서 짚은 stateful 세션의 한계가 가장 큰 우선순위다. 핵심은 세션 생성·재개·이전을 표준화해서 서버 재시작·수평 확장을 클라이언트에 투명하게 만드는 것. 같은 축에서 .well-known 메타데이터로 연결 없이도 서버 capability를 알 수 있게 하는 작업이 같이 간다. 레지스트리·크롤러·인덱서가 라이브 연결 없이 카탈로그를 만들 수 있게 된다.
2. Agent communication
Tasks가 production feedback에 따라 한 번 더 다듬어진다. transient failure에 대한 retry 시맨틱, 결과 보존 기간을 정하는 expiry 정책 같은 것들이 붙는다. 비동기 흐름이 진짜 production-ready가 되려면 채워야 할 자리들이다.
3. Governance maturation
표준이 한 사람·한 회사 손에 묶이면 느려지거나 편향된다. 로드맵은 contributor ladder와 working group 위임 모델을 도입해 의사결정을 분산한다. 도메인별 working group이 자기 영역 안의 SEP(Specification Enhancement Proposal)을 core maintainer 전체 검토 없이 승인할 수 있게 된다.
4. Enterprise readiness
큰 조직이 도입하면서 부딪히는 자리들 — 감사 로그, SSO 인증, gateway 동작, 설정 portability — 가 정리된다. 단, 이 작업은 core spec을 두텁게 하지 않고 확장(extension)으로 푸는 게 방향이다. core는 작게 유지하면서 enterprise 요구는 별도 layer로 커버한다.
flowchart TB
classDef axis fill:#4a90d9,color:#fff,stroke:#2c5d8f
R[2026 Roadmap]
R --> A1[Transport scalability<br/>stateless 운영, 표준 메타데이터]:::axis
R --> A2[Agent communication<br/>Tasks 다듬기]:::axis
R --> A3[Governance maturation<br/>Working Groups, contributor ladder]:::axis
R --> A4[Enterprise readiness<br/>SSO, 감사 로그, gateway]:::axis릴리즈 중심 일정에서 working-group 우선 우선순위로 운영 모델 자체가 옮겨갔다. SEP가 위 네 축에 맞으면 빠른 검토를 받는다.
마지막에 한 번 더
여덟 편을 한 줄로 줄이면 이렇다. MCP는 AI 도구와 외부 데이터·서비스가 만나는 자리에 둔 좁고 단단한 표준이다.
좁다 — 모델 선택, LLM 호출 정책, UI/UX는 다루지 않는다. 단단하다 — JSON-RPC 2.0 위에 lifecycle·primitives·transport·authorization이 한 톤으로 짜여 있다. 좁고 단단하기에 가운데 규칙만 표준이면 양쪽이 자유롭게 진화한다는 약속이 깨지지 않는다.
지금 시점에서 직접 손을 더럽힌다면 두 곳에 시간을 쓸 가치가 있다. 하나는 공식 참고 서버 리포를 그대로 띄워 Inspector에 붙여보는 것 — spec이 코드에서 어떻게 떨어지는지 가장 빠르게 잡힌다. 다른 하나는 자기 작업 흐름에서 반복적으로 부딪히는 외부 시스템 하나를 골라 5편 weather server 패턴으로 작은 MCP 서버를 만들어보는 것이다. 두 길 다 한나절이면 끝나고, 그 이후로 MCP가 추상적인 표준이 아니라 손에 잡히는 도구가 된다.
여기까지가 시리즈다. 8편의 지도가 spec 문서 안으로 들어갈 때의 길잡이가 되면 좋겠다.
Loading comments...