Category
MCP(Model Context Protocol)는 LLM과 외부 도구·데이터 소스를 잇는 표준 프로토콜이다. 도구마다 개별 연동을 만들던 방식을 서버·클라이언트 규약 하나로 통일해, 한국 개발자에게는 사내 시스템에 에이전트를 붙일 때 재사용 가능한 연결 계층을 만드는 기반이 된다.
호스트 진영이 OpenAI·Google까지 합류해 사실상 표준이 되자, 공격 표면 논의도 '툴 설명문에 숨긴 프롬프트 인젝션' 단계를 넘어섰다. 더 구조적인 위험은 원격 MCP가 OAuth 2.1 리소스 서버로 동작하면서 생기는 위임 권한이다. 사용자가 클라이언트의 동의 화면에서 별 의심 없이 승인하면, 그 토큰으로 서버는 Gmail·캘린더·내부 DB에 광범위하게 접근한다. 여기에 confused deputy 문제가 겹친다. 한 서버가 다른 다운스트림 API의 자격증명을 대리 보관하면, 악성 툴 호출이 정당한 토큰을 빌려 권한을 우회할 수 있다. 스펙은 리소스 인디케이터(RFC 8707)로 토큰 수신 대상을 못박고, 토큰 패스스루를 명시적으로 금지하는 방향으로 보강됐지만, 실제 구현은 여전히 과도한 scope를 한 번에 요구하는 경우가 많다. 권한 최소화는 코드가 아니라 동의 설계의 문제로 넘어왔다.
modelcontextprotocol/registry가 프리뷰를 벗고 1.0으로 올라서면서, 그동안 GitHub README와 입소문에 흩어져 있던 MCP 서버들이 단일 메타 레지스트리에 등록·검색 가능해졌다. 핵심은 중앙 저장소가 아니라 네임스페이스(io.github.*, com.example.*) 기반의 분산 인덱스라는 점이다. 서버 발행자는 server.json에 transport(stdio/streamable-http), 패키지 출처(npm·PyPI·OCI), 인증 요구사항을 선언하고, Anthropic·VS Code·Cursor 같은 호스트가 이 인덱스를 미러링해 자체 서브레지스트리를 구성한다. DNS 또는 GitHub OIDC로 네임스페이스 소유권을 증명하게 해 'anthropic.com 사칭 서버' 같은 타이포스쿼팅을 차단하는 게 설계의 중심축이다. 다만 등록은 메타데이터 검증일 뿐 코드 감사가 아니라서, 서명된 출처와 실제 안전성은 여전히 별개 문제로 남는다.
MCP 전송 논쟁이 한 라운드 정리됐다. 초기의 HTTP+SSE 듀얼 엔드포인트 방식은 폐기되고 단일 /mcp 엔드포인트로 POST·스트리밍을 처리하는 Streamable HTTP가 원격 표준으로 자리잡았다. SSE 방식이 연결 상태를 서버가 길게 들고 있어야 해서 서버리스·로드밸런서 환경과 충돌했던 게 직접 원인이다. Streamable HTTP는 요청별로 일반 JSON 응답을 줄지 text/event-stream을 줄지 서버가 선택하고, Mcp-Session-Id 헤더로 세션을 잇기 때문에 스테이트리스 워커에도 얹기 쉽다. 그럼에도 stdio는 사라지지 않았다. 로컬 파일·DB·CLI에 붙는 데스크톱 서버에서는 네트워크 왕복도 인증 핸드셰이크도 없는 stdio가 여전히 가장 단순하고 빠르며, 원격은 OAuth 2.1 리소스 서버로 보호되는 멀티테넌트 SaaS형 서버의 몫으로 역할이 갈렸다.