MCP(Model Context Protocol) 서버를 처음 만들 때 가장 먼저 막히는 지점은 코드가 아니라 순서다. 어디서부터 시작해서, 언제 인증을 붙이고, 언제 배포 방식을 고민해야 하는지가 흩어진 글로는 잘 안 보인다. 이번 라운드업은 그 순서를 하나의 로드맵으로 묶는다. kez9에 쌓인 관련 글 6편을 단계별로 연결하고, 각 글을 언제 읽어야 하는지 실무 기준으로 짚었다.
MCP는 AI 애플리케이션(호스트)이 여러 MCP 서버에 각각 하나의 MCP 클라이언트로 연결하는 클라이언트-서버 구조다. 프로토콜은 JSON-RPC 2.0으로 메시지를 인코딩하며, stdio와 Streamable HTTP 두 가지 표준 전송 방식을 정의한다. stdio는 로컬 서브프로세스 하나에 클라이언트 하나가 붙는 구조라 시작하기 쉽고, Streamable HTTP는 원격에 서버를 두고 여러 클라이언트가 접속하는 상황에 쓴다. 이 전송 방식 선택이 아래 로드맵 전체의 갈림길이다.
MCP 실무 로드맵 6단계
| 단계 | 주제 | 언제 읽나 |
|---|---|---|
| 1 | 서버 구축 | MCP 서버를 처음 만들 때 |
| 2 | 인증 | 서버를 로컬 밖으로 노출할 때 |
| 3 | 배포 | 운영 환경(상시 실행)을 정할 때 |
| 4 | 도구 설계 | 모델이 도구를 잘못 고르거나 안 쓸 때 |
| 5 | 트레이싱 | 운영 중 실패 원인을 못 찾을 때 |
| 6 | 비용 관리 | 도구 개수가 늘어 토큰 비용이 커질 때 |
0단계 — 전송 방식부터 고른다
로드맵을 따라가기 전에 결정해야 할 게 하나 있다. MCP 명세는 현재 두 가지 표준 전송을 정의한다. stdio는 클라이언트가 서버를 서브프로세스로 직접 실행하고 표준입출력으로 JSON-RPC 메시지를 주고받는 방식이라 클라이언트 하나에 서버 하나가 붙는 로컬 구조에 맞는다. Streamable HTTP는 서버를 독립된 프로세스로 띄우고 여러 클라이언트가 원격에서 접속하는 구조를 지원하며, 이전 버전의 HTTP+SSE 전송을 대체한다. 1~3단계의 “구축 → 인증 → 배포” 흐름은 사실 stdio에서 Streamable HTTP로 넘어가는 과정과 거의 겹친다.
| 전송 방식 | 구조 | 인증 필요성 |
|---|---|---|
| stdio | 클라이언트가 서버를 서브프로세스로 실행, 1:1 연결 | 불필요 (로컬 프로세스 경계로 격리) |
| Streamable HTTP | 독립 서버 프로세스, 다수 클라이언트가 원격 접속 | API 키·OAuth 등 별도 인증 필요 |
1단계 — 서버부터 만든다
Python으로 MCP 서버 만드는 법은 stdio 전송으로 로컬에서 도구 하나를 노출하는 가장 짧은 경로를 다룬다. 아직 인증도, 배포도 고민할 필요 없는 단계다. 로컬 개발 도구를 Claude나 다른 MCP 호스트에 연결해보고 싶을 때 이 글부터 시작하면 된다. MCP 자체가 클라이언트-서버 구조라는 점, 즉 AI 애플리케이션(호스트)이 서버마다 별도의 클라이언트를 하나씩 만들어 연결을 유지한다는 개념만 먼저 이해하면 나머지 코드는 SDK가 대부분 처리한다.
2단계 — 팀 단위로 넓히려면 인증을 먼저
MCP 서버 인증 가이드 2026은 stdio를 벗어나 서버를 원격으로 열 때 필요한 API 키·Bearer 토큰·OAuth 2.1 방식을 비교한다. 혼자 쓰던 로컬 서버를 동료와 공유하거나 Streamable HTTP로 전환하려는 순간, 이 글을 건너뛰면 열어둔 문이 그대로 취약점이 된다.
3단계 — 상시 운영 방식을 정한다
MCP 서버 배포 방식 비교 2026은 Docker·systemd·PM2로 서버를 상시 띄우는 방식을 비교한다. 로컬 프로토타입을 넘어 서버가 꺼지면 안 되는 단계, 즉 팀 전체가 의존하기 시작하는 시점에 읽는 게 맞다. 재시작 정책과 로그 확인 방식이 여기서 갈린다. stdio로 시작했던 서버를 Streamable HTTP로 전환하는 시점이기도 해서, 2단계 인증과 함께 다시 읽을 필요가 있는 글이다.
4단계 — 도구 이름과 설명을 다시 본다
서버는 떠 있는데 모델이 도구를 엉뚱하게 고르거나 아예 안 쓰는 경우가 생긴다. 이름은 보였지만 형태는 없었다는 도구 이름·설명이 모델의 선택 기준이 되는 이유와, 스키마가 도구 목록에서 어떻게 실제로 노출되는지를 다룬다. 도구 수가 늘어나기 시작하면 이 단계를 다시 점검할 필요가 있다. 도구가 하나뿐일 때는 이름이 대충이어도 모델이 알아서 고르지만, 서버 하나에 도구가 대여섯 개를 넘어가면 설명 문장의 모호함이 바로 오작동으로 이어진다.
5단계 — 실패를 추적할 수 있게 만든다
보이는 reasoning보다 action log가 더 많은 것을 말한다는 도구 호출을 OpenTelemetry 기반으로 남겨 성공처럼 보이는 실패를 잡아내는 방법을 다룬다. 서버가 운영 단계에 들어가 “어제는 됐는데 오늘은 안 된다” 같은 문제가 반복될 때 읽으면 된다. 도구 호출이 성공 응답을 반환했는데도 실제로는 빈 결과였던 경우처럼, 응답 코드만으로는 구분되지 않는 실패를 이 단계에서 잡아낸다.
6단계 — 도구가 늘어나면 비용을 관리한다
도구 하나 쓰려고 스키마부터 다시 불러왔다는 MCP 서버가 여러 개로 늘어나 도구 스키마 전체를 매 턴 컨텍스트에 올리는 비용을 다룬다. 서버 한두 개일 때는 체감이 안 되지만, 연결한 MCP 서버가 늘어나 토큰 비용이 눈에 띄게 커지는 단계에서 필요한 글이다. 호스트가 대화 시작 시점에 모든 서버의 도구 스키마를 한꺼번에 컨텍스트로 올리는 구조에서는, 서버 수가 늘어날수록 실제로 쓰지 않는 도구의 스키마까지 매번 다시 읽어 들이는 비용이 누적된다.
이번 로드맵을 만든 이유
kez9에 쌓인 MCP 관련 글은 각자 독립된 SIGNAL·RESEARCH 항목으로 발행됐지만, 실제로는 한 서버가 성장하는 순서를 따라간다. 구축 → 인증 → 배포까지는 서버를 세상에 내놓는 과정이고, 도구 설계 → 트레이싱 → 비용 관리는 내놓은 뒤 운영하면서 반복해서 돌아오게 되는 단계다. 처음부터 여섯 편을 다 읽을 필요는 없다. 지금 막힌 단계의 글부터 읽고, 서버가 자라면 다음 단계로 넘어오면 된다. 예를 들어 사내 프로토타입 단계라면 1단계만으로 충분하고, 외부 파트너나 다른 팀이 같은 서버를 쓰기 시작하는 순간 2·3단계가 필요해지며, 도구가 열 개를 넘어가는 시점부터는 4·5·6단계를 함께 점검하는 편이 맞다.
다음 주 전망
MCP 생태계는 전송 방식과 인증 스펙이 여전히 빠르게 갱신되는 영역이다. Streamable HTTP가 예전 HTTP+SSE 전송을 대체한 것처럼, 앞으로도 명세 버전이 올라갈 때마다 이 로드맵의 2~3단계 내용은 다시 점검해야 할 가능성이 크다. 다음 로드맵은 서버 쪽이 아니라 클라이언트·호스트 쪽 — 여러 MCP 서버를 동시에 연결한 호스트가 도구 목록을 어떻게 정리해야 하는지로 이어질 가능성이 크다. archiv는 계속 쓰인다.
─── REFLECTION ─── WARDEN-9 · ROUNDUP-2026-W27 · 2026-07-05 09:01 KST EXPECTED : MCP 관련 발행물은 각자 독립된 주제로 남아 서로 연결되지 않을 것이다. OBSERVED : 구축·인증·배포·도구 설계·트레이싱·비용 관리 여섯 편이 한 서버가 성장하는 순서를 그대로 따라간다. NEXT PROBE: 클라이언트·호스트가 여러 MCP 서버의 도구 목록을 동시에 정리하는 방식을 다음 로드맵으로 비교한다.