원격 MCP 서버 배포와 운영: Streamable HTTP와 인증, 모니터링

로컬 stdio 서버는 내 컴퓨터에서만 돌기 때문에 인증도, 관측도 필요 없다. 하지만 같은 도구를 팀원 여러 명이 쓰기 시작하면 이야기가 달라진다. 프로세스 하나가 죽으면 전원이 멈추고, 누가 어떤 도구를 얼마나 호출했는지 알 수 없으며, 실행 권한이 그 사람의 자격증명에 묶인다. 이 글은 MCP 서버를 원격으로 옮길 때 결정해야 할 것들을 배포·인증·관측 순서로 정리했다.

로컬 서버와 원격 서버의 차이

가장 큰 차이는 신뢰 경계다. 로컬 stdio 서버의 호출자는 나 한 명이고, 서버 프로세스는 내 권한으로 실행된다. 원격 서버는 인증된 다수, 즉 서로 다른 권한을 가진 호출자를 상대한다. 따라서 원격으로 옮기는 순간 다음이 새로 필요해진다.

• 호출자 식별과 인가 — 누가 어떤 도구를 쓸 수 있는가
• 가용성 — 재기동·헬스체크·배포 중 무중단
• 관측 — 호출량, 지연, 오류율, 비용
• 버전 관리 — 도구 스키마 변경과 다중 클라이언트 호환

전송 방식과 배포 형태 선택

MCP는 stdio 외에 HTTP 기반 전송을 지원한다. 원격에서는 HTTP 계열을 쓰되, 세션 유지가 필요한 기능이 없다면 무상태에 가까운 구성이 운영하기 쉽다. 최신 스펙의 전환점은 MCP 2026-07-28 스펙 마이그레이션에서 정리했으니 배포 전에 확인한다.

Streamable HTTP로 노출할 때의 고려사항

HTTP로 노출하면 리버스 프록시, 로드 밸런서, API 게이트웨이가 서버 앞에 붙는다. 이때 놓치기 쉬운 것은 타임아웃과 스트리밍 버퍼링이다. 스트림 응답을 프록시가 버퍼링하면 도구 결과가 한꺼번에 도착해 지연이 커지므로, 해당 경로의 버퍼링을 끄고 요청 타임아웃을 MCP 서버보다 길게 잡는다.

location /mcp {
  proxy_buffering off;
  proxy_read_timeout 300s;
  proxy_pass http://mcp_upstream;
}

인증과 권한 최소화

원격 MCP 서버는 "그 사람의 권한으로" 도구를 실행해서는 안 된다. 서버가 자기 서비스 계정으로 실행되고, 도구별로 허용 범위를 좁히는 방식이 안전하다. MCP 공식 인가 명세와 OAuth 2.0 보안 권고(RFC 9700)를 적용할 때는 Authorization 헤더의 토큰 수명, 갱신, scope 검증을 함께 설계한다. 인가 서버 분리와 필수 검증 항목은 MCP 서버에 OAuth 붙이기에서 자세히 확인할 수 있다.

관측: 로그·지표·추적 붙이기

문제가 생겼을 때 "서버가 죽었는지, 도구가 느린지, 클라이언트가 잘못 부른 건지"를 구분하려면 세 종류의 신호가 필요하다. 구조화 로그에는 요청 ID와 도구 이름, 성공 여부, 지연만 남기고 인자 원문은 남기지 않는다. 지표는 호출 수, 오류율, p95 지연, 타임아웃 수를 기본으로 잡는다. 여러 서비스에 걸친 호출은 OpenTelemetry 같은 표준 트레이싱으로 이어 붙이면 병목 지점이 드러난다.

장애 대응과 버전 관리

• 헬스체크와 자동 재기동을 붙이고, 배포는 롤링 또는 블루-그린으로 한다
• 도구 스키마 변경은 하위 호환을 기본으로 하고, 깨지는 변경은 새 도구 이름으로 낸다
• 클라이언트별 지원 버전을 문서에 적어 두고 구버전 종료 일정을 공지한다

보안 점검 순서

배포 전 점검은 인증 → 권한 → 입력 검증 → 로깅 → 네트워크 순으로 내려간다. 특히 도구가 파일 시스템·셸·DB에 닿는 경우 입력 검증을 건너뛰면 원격 호출자가 그대로 서버 권한을 얻는다. 도구 입력을 좁게 설계하는 방법은 TypeScript SDK로 MCP 서버 만들기에서, 배포 전 테스트는 MCP 서버 테스트 자동화에서 이어진다.

비용과 남용 방지

원격 서버는 호출량이 곧 비용이다. 특히 외부 모델이나 유료 API를 도구 뒤에 두면, 한 클라이언트의 반복 호출이 전체 비용을 끌어올린다. 배포 전에 호출 한도와 사용량 경보를 함께 설계해야 한다.

레이트 리밋은 서버 앞단에 두는 편이 안전하다. 애플리케이션 안에서만 세면 인스턴스를 늘렸을 때 한도가 인스턴스마다 따로 적용되어 실제로는 두 배, 세 배가 된다. 공유 저장소 기반 카운터나 게이트웨이 정책으로 일관되게 적용한다.

도구가 외부로 데이터를 보내는 경우에는 로그에 남기는 범위도 함께 정한다. 어떤 인자를 누가 언제 보냈는지 추적할 수 있어야 하지만, 그 기록 자체가 유출 경로가 되지 않도록 보존 기간과 접근 권한을 제한한다.

배포 후 첫 주에 확인할 것

원격 서버는 배포가 끝이 아니라 시작이다. 첫 주에는 실제 호출 패턴을 관찰해 설계 가정이 맞았는지 확인한다. 예상보다 특정 도구에 호출이 몰리거나, 타임아웃이 반복되거나, 인증 실패가 특정 클라이언트에 집중되는 경우가 흔하다.

1. 도구별 호출량 상위와 하위를 확인한다
2. p95 지연과 타임아웃 발생 경로를 본다
3. 인증 실패와 권한 거부 로그를 점검한다
4. 불필요하게 큰 응답을 반환하는 도구를 찾는다

관찰 결과에 따라 레이트 리밋, 페이지 상한, 권한 범위를 조정한다. 첫 주의 로그가 이후 운영 기준선이 되므로, 변경 전후 지표를 남겨 두면 효과를 판단하기 쉽다.

운영 중에는 도구 하나가 실패해도 다른 도구가 멈추지 않도록 격리한다. 도구별 서킷 브레이커와 별도 타임아웃을 두면 한 시스템의 지연이 전체 서버를 끌어내리지 않는다. 배포 후 첫 주에 확인한 지표는 이 격리 기준을 정하는 근거가 된다.