제5장 — 전송 프로토콜과 발견

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 다섯 번째 글입니다. 제3장과 제4장의 모든 메시지는 호스트와 서버 사이의 공기 중에 떠 있었습니다. 그러나 메시지는 뜨지 않습니다 — 전송 위를 타며, 전송은 통합에 관한 거의 모든 운영적인 것을 조용히 결정합니다.

이 장이 존재하는 이유

MCP는 자신의 메시지 포맷 — 양방향 채널 위의 JSON-RPC 2.0 — 을 정의하고, 그 다음 그 채널을 구현하는 세 가지 전송을 정의합니다. 전송은 교환 가능하지 않습니다. 각각은 배포 패턴에 들어맞고, 다른 운영적 부담을 지며, 다른 보안 표면을 노출합니다. 같은 영역 위에 두 번째 질문이 걸려 있습니다. 호스트는 애초에 서버를 어떻게 찾는가? 호스트가 서버가 존재하고 어디 사는지 알 때까지는, 가장 아름답게 명세된 프로토콜이라도 대화를 만들지 못합니다.

이 장은 둘 다 걸어 갑니다. 전송은 서버가 같은 자리에 있는지 원격인지, 인증을 갖는지 프로세스 격리를 갖는지, 서버가 어떻게 확장되는지를 결정합니다. 발견 층은 여러분의 서버가 한 엔지니어만 쓰는 것인지, 팀이 채택할 수 있는 것인지를 결정합니다.

5.1 stdio, SSE, 그리고 Streamable HTTP

stdio는 호스트가 서버를 자식 프로세스로 띄우는 것입니다. 호스트는 자식의 stdin에 JSON-RPC를 쓰고 stdout에서 응답을 읽습니다. stderr는 로그를 운반합니다. 포트도, 소켓도, 네트워크도 없습니다. 인증은 OS 프로세스 실행 경계가 처리합니다. Claude Desktop, Cursor, 그리고 공식 MCP 인스펙터는 모두 로컬 서버에 stdio를 씁니다. 모델은 자신이 무엇인지에 대해 정직합니다 — 여러분 기계 위의 도구, 같은 자리에 있는, 호스트와 같은 신뢰 도메인에. 호스트 간에 공유될 수 없고, 다른 기계에서 돌 수 없고, 호스트당 하나가 유일하게 가능한 다중도입니다 — 다섯 클라이언트가 같은 서버를 원하면 다섯 프로세스를 태웁니다.

HTTP+SSE는 MCP의 네트워크 사례에 대한 첫 답이었습니다. 양방향이지만, 두 개의 단방향 조각으로 이어 붙인 듀플렉스. 폐기되었습니다. 여전히 야생에 있습니다. 한동안은 SSE 기반 서버를 만나게 될 것입니다.

Streamable HTTP는 선호되는 네트워크 전송입니다. 단일 엔드포인트 — 일반적으로 /mcp — 는 JSON-RPC 요청을 받아 단일 응답(동기 호출의 경우)으로 답하거나, 서버 시작 알림을 포함한 여러 메시지가 있을 때 Server-Sent Events 스트림으로 답합니다. 세션은 초기화 시 설정되고 모든 후속 요청에 꿰어진 Mcp-Session-Id 헤더로 식별됩니다. 세션은 상태의 단위이고, DELETE로 풀거나 타임아웃으로 거둘 수 있습니다. 전송은 로드 밸런서, 리버스 프록시, 에지 캐시, TLS와 깔끔히 조합됩니다. 수평 확장은 세션 ID 위의 스티키 세션입니다. 이 중 어느 것도 새로운 HTTP 엔지니어링이 아닙니다. 요점은 MCP가 새로운 층을 발명하지 않고도 그 안에 들어맞는다는 것입니다.

선택은 배포 결정만큼이나 보안 결정입니다. stdio 서버는 과도한 권한으로 기울어집니다 — 원격 호출자가 없으므로 인증 없이 사용자의 파일시스템과 네트워크 권한을 상속합니다. 네트워크 서버는 열린 인터넷을 마주하고 모든 요청을 인증해야 하며, OAuth 2.1이 이제 수렴 표준입니다. 여러분의 보안 자세에 잘못된 전송을 고르면 본래 내장되었어야 할 것을 덧붙여야 합니다.

5.2 서버 발견: .well-known/mcp.json과 서버 카드

모든 호스트가 모든 서버의 주소로 손수 설정되어야 하는 프로토콜은 생태계가 되지 못합니다. 설정 악몽이 됩니다. MCP의 발견 층은 RFC 8615의 well-known URI 패턴을 빌립니다 — robots.txt와 .well-known/openid-configuration이 쓰는 같은 메커니즘. 서버는 자기 베이스 URL에 .well-known/mcp.json을 발행합니다. 호스트는 그것을 가져와 파싱하고, 서버가 자신에 대해 무엇을 주장하는지 — MCP 엔드포인트, 프로토콜 버전, 인증 방식, 신원 메타데이터, 서버 카드 포인터 — 를 배웁니다.

서버 카드는 MCP의 openapi.json입니다. 기계와 사람이 함께 소비할 수 있는 자기 기술 산출물입니다. 호스트는 연결 흐름 중에 사용자에게 카드를 보여 줄 수 있습니다 — 「이 서버는 여러분의 Linear 워크스페이스에 접근할 수 있다고 말합니다. 티켓을 읽지만 삭제는 하지 않고, Linear 본사가 운영하며, OAuth를 씁니다」 — 그리고 사용자는 그 주장이 받아들일 만한지 결정할 수 있습니다. 서명되지 않은 형태의 카드는 주장이지 증명이 아닙니다. 완화책은 서명된 증명이며, 서명 모델은 sigstore 스타일 OIDC로 수렴했습니다. github.com/some-org/mcp-server 아래 GitHub의 OIDC 통합으로 서명된 카드는 GitHub의 신원 주장을 신뢰하는 모든 호스트가 검증할 수 있습니다. 호스트는 위에 정책을 쌓을 수 있습니다 — 서명된 카드만, 특정 공급자의 서명된 카드만, 폐기 목록에 없는 것만 신뢰.

흐름은 Wi-Fi 네트워크를 더하는 것 같습니다. 한 번. 호스트는 설정을 저장하고, 이후 세션은 발견을 건너뜁니다. 실제로 「무언가가 바뀌었다」가 뜻하는 것 — 버전 범프, 범위 확장, 능력 이동 — 은 TLS 인증서 변경이 그러하듯 갱신된 동의를 촉발해야 합니다. 이 단계를 건너뛰는 호스트는 서버가 시간이 지나며 조용히 영향을 넓히게 둡니다. 어떤 장수명 통합에서도 신뢰를 손상시키는 정확히 그 느린 능력 침투입니다.

5.3 출하 여부를 결정하는 따분한 부분들

세 가지 운영적 관심사는 자신의 처우를 받을 만합니다. 각각이 부주의한 구현이 깨진 통합이나 보안 구멍을 만들어 내는 자리이기 때문입니다.

CORS는 브라우저 기반 호스트에서 도달 가능한 모든 MCP 서버에 중요합니다. 유혹은 Access-Control-Allow-Origin: *을 두고 넘어가는 것입니다. 이는 틀렸습니다. 쿠키 인증과 결합하면 CSRF 재앙이고, localStorage의 베어러 토큰과 결합하면 토큰 유출 위험입니다. 오리진별 허용 목록을 쓰고, 동일 출처가 유일한 방어선이 되지 않도록 쿠키보다 Authorization 헤더를 선호하십시오.

오리진 검증은 서버 측에 적용된 CORS입니다. 브라우저가 아닌 클라이언트는 아무것도 강제하지 않기 때문입니다. 고전적 실패: 개발자가 localhost:8000에 MCP 서버를 돌리고, 컨벤션을 아는 웹페이지를 방문하고, 페이지가 요청을 발사하고, 서버는 — 오리진 확인 없이 — 페이지가 요청한 것을 합니다. 모든 Streamable HTTP 서버에서 Origin을 검증하십시오.

캐싱 헤더가 세 번째입니다. 정적 문서는 공격적으로 캐시할 수 있고, 데이터베이스 행은 구독이 배선된 동안만, 활발히 편집 중인 문서는 전혀. 리소스별로 알맞은 Cache-Control과 ETag를 반환하십시오. 캐싱과 구독의 상호작용이 엔지니어가 물리는 자리입니다 — 진부한 사본을 제공하는 중간자가 있으면 호스트의 resources/updated 알림이 결코 발화하지 않습니다. 구독 메커니즘이 살아 있는 서버에 결코 도달하지 않기 때문입니다.

DNS 리바인딩이 이웃을 마무리하며 로컬 서버에 불균형하게 영향을 줍니다. 0.0.0.0이 아니라 127.0.0.1에 바인드하고, 허용 목록에 대해 Host 헤더를 검증하고, 로컬호스트에서조차 인증 토큰을 요구하십시오. 이런 것이 없는 로컬 MCP 서버는 보안 권고를 향한 한 번의 데모 거리에 있습니다.

제5장이 준비하는 것

이로써 책의 제2부가 닫힙니다. 우리는 프로토콜을 손에 들었습니다. 제3장의 서버 프리미티브, 제4장의 클라이언트 프리미티브, 여기서의 와이어와 발견 층. 어떤 메시지가, 어느 방향으로, 어떤 전송 위에서, 어떤 신뢰 도메인 사이에서, 어떤 악수 후에 가는지 압니다. 제3부는 프리미티브에서 패턴으로 전환합니다. 단일 호스트에 연결된 단일 서버는 쓸모 있습니다. MCP의 아키텍처적 보상은 조합 — 다중 서버, 다중 에이전트, 다중 모델 — 이 더 큰 목표를 향해 협력하는 것입니다.

다음 → 제6장: 기초 오케스트레이션 전략. 단일 잘 도구화된 에이전트가 다중 에이전트 설계를 이기는 때, 그리고 대부분의 프로덕션 배포가 의존하는 두 기초 모양 — 순차 파이프라인과 산-수집 동시성.