개발하는 TeEm0

1. 왜 지금 MCP 로드맵을 봐야 하나

MCP(Model Context Protocol)를 처음 붙였을 때 느낌은 대체로 비슷하다. "어, 생각보다 별거 없네." JSON-RPC 기반으로 tools/list 받아오고 tools/call 던지면 끝이다. 사내 위키 검색, Jira 티켓 조회 정도 붙이는 데는 반나절이면 충분하다.

문제는 그다음이다. 실제로 운영에 넣어보면 이런 것들이 터진다.

• Terraform plan/apply를 도구로 노출했더니 3분 넘게 걸리는 호출에서 커넥션이 끊긴다.
• 배포 승인 같은 사람 개입(human-in-the-loop)이 필요한 작업을 요청·응답 한 번으로 표현할 방법이 없다.
• 에이전트가 사내 API를 호출하는데, 그 요청의 주체가 누구인지 감사 로그에서 구분이 안 된다. 전부 서비스 계정 하나로 찍힌다.
• 팀별로 MCP 서버를 만들다 보니 툴이 300개를 넘어갔고, tools/list 응답만 수만 토큰이 되면서 모델이 엉뚱한 툴을 고르기 시작한다.

이번 MCP 로드맵이 짚은 지점이 정확히 여기다. 요약에 따르면 앞으로 수개월간 장시간 실행되는 에이전트 작업, 에이전트 신원·권한 위임, 대규모 Tool 탐색을 핵심 과제로 잡고, 요청·응답 중심 구조를 넘어 서버 주도 이벤트, Webhook·Channel, 실행 중 작업 제어를 강화하겠다는 것이다.

이건 사실상 "MCP를 RPC 라이브러리에서 분산 작업 시스템 프로토콜로 확장하겠다"는 선언이다. 우리가 지난 15년간 메시지 큐, 워크플로 엔진, OAuth 인가 서버로 풀어온 문제들이 그대로 올라와 있다. 그래서 인프라 하는 사람이 볼 값어치가 있다.

참고: 아래 내용 중 구체적인 메시지 스키마·필드명은 확정 명세가 아니라 설계 개념을 설명하기 위한 예시다. 실제 필드명과 릴리스 일정은 공식 명세 문서 확인 필요.

2. 핵심 개념: 요청·응답을 넘어서면 뭐가 달라지나

장시간 작업 = "티켓 발급" 패턴

비유하자면 지금까지의 MCP tool call은 편의점 계산대다. 물건 내밀면 바로 결제되고 끝. 반면 장시간 작업은 세탁소에 가깝다. 옷 맡기면 접수증(task id)을 주고, 나중에 찾으러 가거나 "다 됐어요" 문자를 받는다.

HTTP 세계에서 이미 표준화된 패턴이 있다. 202 Accepted + Location 헤더로 상태 조회 URL을 주는 방식이다. MCP도 결국 비슷한 모양으로 갈 것으로 보인다. 개념적으로는 이렇다.

// 1) 툴 호출 → 즉시 완료 대신 작업 접수
{"jsonrpc":"2.0","id":7,"result":{
  "task":{"id":"task_9f3a","status":"working","pollInterval":5}
}}

// 2) 상태 조회 (개념 예시)
{"jsonrpc":"2.0","id":8,"method":"tasks/get","params":{"taskId":"task_9f3a"}}
{"jsonrpc":"2.0","id":8,"result":{
  "status":"input_required",
  "message":"prod 클러스터 apply 승인이 필요합니다"
}}

// 3) 실행 중 취소
{"jsonrpc":"2.0","id":9,"method":"tasks/cancel","params":{"taskId":"task_9f3a"}}

여기서 인프라 관점의 핵심은 상태를 어디에 두느냐다. task id를 발급한 순간부터 MCP 서버는 stateless가 아니다. 서버 인스턴스 3대를 ALB 뒤에 두고 있는데 task 상태를 프로세스 메모리에 들고 있으면, 다음 폴링이 다른 인스턴스로 가는 순간 끝이다.

$ curl -s -X POST https://mcp.internal/rpc \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":8,"method":"tasks/get","params":{"taskId":"task_9f3a"}}'

{"jsonrpc":"2.0","id":8,"error":{"code":-32602,"message":"Unknown task: task_9f3a"}}

이 에러를 스테이징에서 만나면 십중팔구 스티키 세션이 없거나 상태 저장소가 로컬인 경우다. Redis나 DB로 빼고, task 레코드에 TTL을 반드시 걸어라. 걸지 않으면 취소되지 않은 좀비 task가 쌓여서 결국 메모리나 테이블이 부푼다.

서버 주도 이벤트: 폴링을 걷어낸다

로드맵이 Webhook과 Channel을 언급한 건, 폴링만으로는 감당이 안 되기 때문이다. 에이전트 10개가 각각 5초마다 20개 task를 폴링하면 초당 40 RPS가 아무 일도 안 하면서 나간다. 게다가 폴링은 클라이언트가 살아있을 때만 동작한다. 배치성 에이전트가 잠들어 있는 동안 작업이 끝나면 알 방법이 없다.

세 가지 전달 방식의 트레이드오프를 정리하면 이렇다.

Webhook을 쓰기로 했다면 세 가지는 무조건 챙겨야 한다. 서명 검증(HMAC), 멱등키(같은 이벤트 두 번 와도 안전하게), 재시도 시 지수 백오프. 이건 MCP라서 특별한 게 아니라 Stripe·GitHub Webhook 다뤄본 사람이면 몸에 익은 것들이다. 그대로 가져오면 된다.

# 수신 측 서명 검증 (FastAPI 예시)
import hmac, hashlib
from fastapi import Request, HTTPException

SECRET = b"whsec_..."

async def verify(req: Request) -> bytes:
    raw = await req.body()
    sig = req.headers.get("x-mcp-signature", "")
    ts  = req.headers.get("x-mcp-timestamp", "")
    expect = hmac.new(SECRET, ts.encode() + b"." + raw, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expect, sig):
        raise HTTPException(401, "signature mismatch")
    return raw

헤더 이름은 구현체마다 다르니 공식 명세 확인 필요하지만, 구조는 어디나 같다. 타임스탬프를 서명 대상에 포함시켜 리플레이를 막는 것까지가 세트다.

신원과 권한 위임: "누가 이 API를 부른 건가"

이게 로드맵에서 가장 실무적으로 아픈 부분이다. 지금 대부분의 사내 MCP 서버는 이렇게 생겼다.

[사용자] → [LLM 에이전트] → [MCP 서버] --(서비스 계정 토큰)--> [사내 API]
                                          ↑ 여기서 신원이 증발한다

사내 API 감사 로그에는 svc-mcp-bot만 찍힌다. 김대리가 요청한 건지 박과장이 요청한 건지 모른다. 보안팀이 이걸 발견하는 순간 프로젝트는 멈춘다. 실제로 겪어봤다.

제대로 하려면 토큰 교환(RFC 8693 Token Exchange) 개념이 필요하다. 사용자의 토큰을 MCP 서버가 받아서, 다운스트림 API용 토큰으로 교환하되 스코프는 좁히는 방식이다.

$ curl -s -X POST https://idp.internal/oauth2/token \
  -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
  -d subject_token="$USER_ACCESS_TOKEN" \
  -d subject_token_type=urn:ietf:params:oauth:token-type:access_token \
  -d audience=https://api.internal/deploy \
  -d scope="deploy:read deploy:plan" \
  -u "mcp-server:$CLIENT_SECRET"

{"access_token":"eyJhbGciOi...","issued_token_type":"urn:ietf:params:oauth:token-type:access_token",
 "token_type":"Bearer","expires_in":300,"scope":"deploy:read deploy:plan"}

발급된 토큰의 클레임에는 원 사용자(sub)와 대리 주체(act, actor)가 함께 들어간다. 다운스트림 API는 "박과장을 대신해 mcp-server가 호출함"을 그대로 로깅할 수 있다. 감사 요건이 여기서 해결된다.

여기에 더해 스코프를 툴 단위로 쪼개는 설계가 필요하다. 실수하기 쉬운 게 MCP 서버 전체에 하나의 스코프를 주는 것이다. 그러면 읽기 툴 하나 쓰려고 쓰기 권한까지 딸려온다. 최소한 read / write / destructive 세 등급으로는 나누고, destructive 계열은 사람 승인 없이는 실행 불가로 강제하는 게 안전하다. 앞서 말한 input_required 상태가 이 지점에서 쓰인다.

수천 개 Tool: 카탈로그를 검색 문제로 바꾸기

툴이 300개 넘어가면 tools/list를 통째로 컨텍스트에 넣는 방식은 무너진다. 토큰도 문제지만 더 큰 문제는 정확도다. 이름이 비슷한 툴 40개 중에서 모델이 맞는 걸 고르길 기대하는 건 무리다.

해법 방향은 결국 두 단계다.

1. 계층화: 카테고리/네임스페이스 단위로 먼저 좁히고, 그 안에서 툴 목록을 편다. infra.k8s.*, infra.terraform.*, biz.jira.* 식으로 접두어 규칙을 강제하면 이후에 뭘 하든 편해진다.
2. 검색형 탐색: 툴 설명을 임베딩해 두고 "지금 하려는 일"에 맞는 상위 N개만 노출한다. 사실상 툴 카탈로그를 RAG로 다루는 것이다.

여기서 자주 하는 실수. 툴 목록이 매 호출마다 바뀌면 캐시가 다 깨진다. 프롬프트 캐싱을 쓰고 있다면 툴 정의 블록은 안정적으로 유지되는 게 유리하다. 세션 시작 시점에 툴 세트를 고정하고, 정말 필요할 때만 notifications/tools/list_changed 같은 변경 알림으로 갱신하는 편이 낫다. 매번 동적으로 셔플하면 캐시 히트율이 바닥을 친다.

3. 실무 관점: 도입 전 체크리스트와 흔한 함정

흔한 함정 1 — LB/프록시 타임아웃

SSE나 장시간 스트리밍을 붙이면 거의 반드시 만나는 게 이거다.

upstream timed out (110: Connection timed out) while reading upstream,
client: 10.0.3.41, server: mcp.internal, request: "POST /rpc HTTP/1.1"

클라이언트 쪽에서는 이렇게 보인다.

McpError: MCP error -32001: Request timed out
    at Client._onresponse (.../client/index.js)

nginx면 proxy_read_timeout, proxy_buffering off, ALB면 idle timeout을 손봐야 한다. 다만 타임아웃을 늘리는 건 임시방편이다. 근본 해법은 장시간 작업을 task로 분리해서 커넥션 수명과 작업 수명을 떼어놓는 것이고, 로드맵이 가려는 방향도 그쪽이다.

흔한 함정 2 — 인증 실패를 툴 에러로 삼키기

MCP 서버가 다운스트림 401을 그냥 텍스트로 감싸서 모델에게 돌려주면, 모델은 "권한이 없나 보다" 하고 다른 툴로 우회를 시도한다. 이건 위험하다. 인증/인가 실패는 프로토콜 레벨 에러로 명확히 올리고, 재인증 플로우로 유도해야 한다.

{"jsonrpc":"2.0","id":12,"error":{
  "code":-32603,
  "message":"Unauthorized",
  "data":{"reason":"insufficient_scope","required":"deploy:apply",
          "authorizeUrl":"https://idp.internal/authorize?..."}}}

필드 구조는 구현마다 다르니 공식 명세 확인 필요. 중요한 건 "모델이 알아서 판단하게 두지 말고, 클라이언트가 처리할 수 있는 신호로 내려보내라"는 원칙이다.

흔한 함정 3 — 멱등성 없는 재시도

Webhook 재시도, 에이전트 자동 재시도, 사용자 수동 재시도가 겹치면 같은 배포가 세 번 돈다. 상태 변경 툴에는 클라이언트가 생성한 멱등키를 파라미터로 받아라. 서버는 그 키로 24시간 정도 결과를 캐싱하고, 같은 키면 실행 없이 이전 결과를 돌려준다. 이 한 줄이 사고를 몇 번 막아준다.

운영 체크리스트

• 관측성: trace id를 사용자 → 에이전트 → MCP 서버 → 다운스트림 API 전 구간에 전파. 툴 이름·소요시간·토큰 사용량을 span attribute로. OpenTelemetry 붙여두면 나중에 "어떤 툴이 제일 자주 실패하나"를 바로 본다.
• 레이트 리밋: 에이전트는 사람보다 훨씬 빠르고 집요하다. 서버 전체 + 사용자별 + 툴별 3계층으로. 특히 destructive 툴은 별도로 조여라.
• 타임아웃 계층: 툴 실행 타임아웃 < MCP 요청 타임아웃 < LB idle 타임아웃 순서가 지켜지는지 확인. 역전되면 원인 파악이 지옥이 된다.
• 킬 스위치: 툴 단위로 즉시 비활성화하는 플래그. 사고 났을 때 서버 전체를 내리지 않고 문제 툴만 끄는 수단이 반드시 필요하다.
• 버전 고정: MCP 명세가 활발히 움직이는 중이다. 클라이언트/서버 SDK 버전을 lock 하고, 업그레이드는 스테이징에서 프로토콜 버전 네고 로그부터 확인한 뒤에.

지금 당장 해야 하나?

솔직히 말하면, 로드맵 항목들은 아직 움직이는 표적이다. 명세가 확정되기 전에 예상 스키마에 맞춰 구현하면 나중에 다 뜯어야 한다. 대신 프로토콜과 무관한 부분은 지금 해두면 손해가 없다.

• task 상태를 외부 저장소로 빼기 (어차피 필요)
• 툴 네이밍 규칙과 read/write/destructive 등급 정하기
• 토큰 교환 기반 위임 구조 설계 (IdP 쪽 작업이라 MCP와 독립)
• trace 전파와 툴별 메트릭

반대로 Webhook 수신 엔드포인트, Channel resume 로직처럼 명세에 직접 묶인 것은 확정 릴리스를 기다리는 편이 낫다.

4. 정리

한 줄 요약: MCP가 "함수 호출 프로토콜"에서 "분산 작업 프로토콜"로 넘어가는 중이고, 그 과정에서 우리가 이미 아는 큐·워크플로·OAuth 문제들이 그대로 재등장한다.

누가 언제 봐야 하냐면 —

• 사내 에이전트 플랫폼을 설계 중이라면 지금. 상태 저장 위치와 권한 위임 구조는 나중에 바꾸기가 정말 어렵다.
• MCP 서버를 이미 몇 개 굴리고 있다면 지금. 툴 네이밍과 권한 등급 정리는 서버가 5개일 때 하는 것과 50개일 때 하는 것의 난이도가 다르다.
• PoC 단계라면 급하지 않다. 짧은 요청·응답 툴 몇 개로 가치를 먼저 증명하고, 위 내용은 "다음 단계에 이런 게 온다" 정도로 알아두면 충분하다.

개인적으로 가장 중요하다고 보는 건 권한 위임이다. 나머지는 기술적으로 풀면 되지만, 신원이 증발하는 구조는 보안 리뷰 한 번에 프로젝트를 통째로 멈추게 만든다. 아키텍처 다이어그램 그릴 때 "이 화살표에 실린 신원은 누구인가"를 화살표마다 적어보길 권한다. 빈칸이 나오는 곳이 나중에 터질 곳이다.

참고 자료

• 새로운 MCP 로드맵 - 앞으로 집중할 5가지 영역 (GeekNews) — 이 글의 출처
• Model Context Protocol 공식 사이트 — 최신 명세와 로드맵 원문 확인
• MCP 명세 문서 — 메시지 스키마·필드명은 반드시 여기서 확인
• modelcontextprotocol GitHub 조직 — SDK, 논의 중인 SEP/이슈
• RFC 8693 — OAuth 2.0 Token Exchange — 위임 토큰 설계의 기준 문서
• RFC 8707 — Resource Indicators for OAuth 2.0 — audience 지정으로 토큰 오남용 줄이기
• OpenTelemetry Traces — 에이전트 전 구간 trace 전파 설계 참고