원격 MCP와 배포 전략

2026-09-15Views 5약 9분생성형 AI 활용

Summary

로컬에서 잘 되던 서버가 팀에서는 부족한 이유

로컬 stdio MCP 서버는 개인용 공구함에 가깝다. 내 컴퓨터에서 Host가 서버 프로세스를 직접 실행하고, 환경변수에 담긴 토큰으로 파일이나 API에 접근한다. 실험하기 쉽고 빠르다. 하지만 팀 전체가 쓰기 시작하면 질문이 달라진다.

누가 어떤 버전의 서버를 쓰고 있는가? 퇴사자의 토큰은 회수되었는가? 장애가 났을 때 어디에서 로그를 볼 수 있는가? 위험한 Tool이 추가되었을 때 누가 승인하는가?

원격 MCP 서버는 이 문제를 중앙에서 관리하기 위한 방식이다. 개인 PC마다 서버를 설치하는 대신, 팀이 신뢰하는 HTTPS 엔드포인트를 만들고 그 뒤에 인증, 권한, 로그, 배포 파이프라인을 붙인다. 즉 "돌아가는 코드"를 "운영 가능한 서비스"로 바꾸는 단계다.

원격 MCP와 배포 전략 AI 생성 이미지

stdio 서버와 원격 HTTP 서버의 차이

로컬 stdio 방식에서는 Host가 command와 args로 MCP 서버를 실행한다. 통신은 표준 입력과 표준 출력으로 오간다. 서버는 stdin으로 JSON-RPC 메시지를 읽고, stdout으로 JSON-RPC 메시지를 돌려준다. 인증 정보는 보통 환경변수나 로컬 시크릿에서 읽는다. MCP의 HTTP 기반 인증 규격도 stdio에는 적용하지 않고, 환경에서 자격 증명을 가져오는 방향으로 설명된다. 로컬 하위 프로세스이기 때문이다.¹

반면 원격 서버는 네트워크 위의 서비스다. 클라이언트는 https://mcp.company.com/support 같은 주소로 요청을 보낸다. 현재 MCP의 표준 전송 방식은 크게 stdio와 Streamable HTTP로 나뉘며, 원격 MCP에서는 Streamable HTTP가 핵심 선택지다.² 이 방식에서는 서버가 하나의 MCP 엔드포인트를 제공하고, 클라이언트는 JSON-RPC 메시지를 HTTP POST로 보낸다. 응답은 일반 JSON일 수도 있고, 서버가 여러 메시지를 흘려보내야 할 때는 SSE 스트림일 수도 있다. 필요하면 클라이언트가 GET으로 SSE 스트림을 열어 서버 메시지를 받을 수도 있다.

운영상 차이는 다음처럼 정리할 수 있다.

구분	로컬 stdio	원격 HTTP
실행 위치	사용자 PC	서버, VM, 컨테이너, 클라우드
설치 방식	개인별 설정	중앙 배포 후 URL 연결
인증	로컬 환경변수 중심	OAuth, SSO, API Gateway, JWT
로그	개인 PC 로그에 흩어짐	중앙 수집 가능
업데이트	사용자마다 다를 수 있음	버전 통제 가능
장애 대응	개인 환경 문제와 섞임	헬스체크·모니터링 가능
위험	로컬 파일·토큰 노출	네트워크 공격면·권한 오남용

따라서 원격화의 목적은 단순히 "서버를 밖에 띄우는 것"이 아니다. 팀이 같은 서버, 같은 정책, 같은 로그를 기준으로 일하게 만드는 것이다.

원격 MCP의 기본 구조

팀용 MCP 서버는 보통 다음 구조로 시작한다.

MCP Host
  ↓ HTTPS
API Gateway / Load Balancer
  ↓ 인증·속도 제한·라우팅
MCP Server
  ↓
사내 API / DB / SaaS / 파일 저장소

MCP 서버는 Tool, Resource, Prompt를 제공한다. API Gateway는 TLS 종료, JWT 검증, IP 제한, 요청 크기 제한, 속도 제한을 맡을 수 있다. 사내 SSO나 OAuth 서버는 사용자가 누구인지 확인한다. 실제 Tool 함수는 "이 사용자가 이 Tool을 이 범위로 호출해도 되는가"를 다시 확인해야 한다.

중요한 원칙은 인증과 인가를 나누는 것이다.

인증: 이 요청을 보낸 사람이 누구인가?
인가: 이 사람이 이 Tool과 이 데이터에 접근해도 되는가?

Gateway에서 로그인만 확인하고, MCP 서버 안에서 Tool별 권한 검사를 하지 않으면 위험하다. 예를 들어 read_ticket은 전 직원에게 허용해도, submit_customer_reply는 고객지원팀과 관리자 승인에만 열어야 할 수 있다.

원격 HTTP 서버에서는 전송 계층의 기본 방어도 함께 챙겨야 한다. Streamable HTTP 서버는 들어오는 연결의 Origin 헤더를 검증해야 하며, 로컬에서 HTTP 서버를 띄워 테스트할 때도 가능하면 0.0.0.0이 아니라 127.0.0.1에만 바인딩하는 편이 안전하다.² 로컬 웹페이지가 DNS 리바인딩 같은 방식으로 사용자의 로컬 MCP 서버에 접근하는 상황을 막기 위해서다.

어디에 배포할 것인가

MCP 서버의 배포 환경은 유행보다 업무 특성으로 고르는 편이 낫다.

Docker

Docker는 가장 무난한 시작점이다. 서버 코드, 런타임, 의존성을 이미지로 묶을 수 있다. 로컬 테스트와 운영 배포의 차이도 줄어든다.

FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY dist ./dist
ENV NODE_ENV=production
CMD ["node", "dist/server.js"]

Docker는 사내 VM, ECS, Cloud Run, Kubernetes 어디로든 옮기기 쉽다. 팀에서 처음 원격 MCP를 운영한다면 "Docker 이미지 + 사내 VM 또는 관리형 컨테이너 서비스" 조합이 현실적이다.

서버리스와 엣지

서버리스는 읽기 중심 Tool, 짧은 API 호출, 외부 SaaS 연동에 잘 맞는다. 인프라 관리 부담이 낮고 자동 확장이 쉽다. Cloudflare Workers 같은 환경에서도 원격 MCP 서버를 /mcp 엔드포인트로 배포하는 예시가 제공된다.³

다만 주의할 점이 있다. 서버리스는 실행 시간 제한, 콜드 스타트, 장기 연결, 파일 시스템 제약이 있다. 긴 배치 작업, 무거운 브라우저 자동화, 사내망 전용 DB 접속에는 맞지 않을 수 있다. 세션 상태가 필요하다면 메모리에 두지 말고 Redis, Durable Object, 데이터베이스 같은 외부 저장소를 사용해야 한다.

사내 VM

사내 VM은 레거시 시스템, 내부망 DB, 폐쇄망 API와 연결할 때 편하다. 네트워크 정책을 단순하게 만들 수 있고, 기존 모니터링 체계에 올리기도 쉽다.

대신 패치, 재시작, 로그 로테이션, 디스크 관리, 프로세스 감시를 직접 챙겨야 한다. 작은 팀이라면 systemd + Docker + reverse proxy 정도로 시작하고, 운영 부담이 커질 때 컨테이너 오케스트레이션으로 옮기는 편이 낫다.

Kubernetes

Kubernetes는 여러 MCP 서버를 팀 단위로 운영하고, 배포 승인, 롤백, 오토스케일링, 서비스 메시, 시크릿 관리를 이미 쓰고 있는 조직에 적합하다. 준비되지 않은 팀이 첫 MCP 서버 때문에 Kubernetes를 도입할 필요는 없다.

Kubernetes에 올릴 때는 최소한 다음을 갖춘다.

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
livenessProbe:
  httpGet:
    path: /health/live
    port: 8080

live는 프로세스가 살아 있는지 확인한다. ready는 외부 API, DB, 시크릿 로딩처럼 실제 요청을 받을 준비가 되었는지 확인한다. 두 검사를 섞으면 장애 때 오히려 재시작 폭탄이 생길 수 있다.

인증·인가 계층 붙이기

HTTP 기반 MCP 서버에 인증을 붙인다면 OAuth 2.1 흐름을 기준으로 생각하는 것이 안전하다. MCP 인증 규격은 HTTP 기반 전송에서 액세스 토큰을 Authorization 헤더로 보내는 방식을 설명한다. 토큰은 URL 쿼리 문자열에 넣으면 안 되고, 같은 논리 세션 안의 요청이라도 매 HTTP 요청마다 포함해야 한다. 토큰이 없거나 만료되면 401, 스코프나 권한이 부족하면 403을 반환하는 식으로 구분한다. PKCE, HTTPS, 리다이렉트 URI 검증도 중요한 요구사항이다.¹

실무에서는 세 가지 패턴이 많다.

첫째, MCP 서버가 직접 OAuth를 처리한다. 서버가 로그인, 콜백, 토큰 검증을 모두 담당한다. 작은 서비스에는 단순하지만, 여러 서버가 생기면 구현이 반복된다.

둘째, API Gateway가 인증을 처리한다. Gateway나 사내 프록시가 SSO 로그인을 확인하고, MCP 서버에는 검증된 사용자 ID와 그룹 정보를 전달한다. 이때 MCP 서버는 Gateway에서 온 요청만 신뢰해야 한다. 외부에서 MCP 서버로 직접 들어오는 우회 경로를 막지 않으면 의미가 없다.

셋째, 사내 SSO와 Tool 권한 테이블을 결합한다. 로그인은 SSO가 맡고, MCP 서버는 내부 정책 DB에서 Tool 권한을 확인한다.

예를 들어 정책은 다음처럼 단순하게 시작할 수 있다.

server: support-mcp
roles:
  support_reader:
    tools:
      - search_tickets
      - read_ticket
  support_writer:
    tools:
      - search_tickets
      - read_ticket
      - create_reply_draft
  support_approver:
    tools:
      - submit_customer_reply
approval_required:
  - submit_customer_reply
  - change_ticket_status

권한은 프롬프트가 아니라 서버에서 검사해야 한다. 모델이 "나는 관리자다"라고 말해도 서버는 토큰의 사용자, 그룹, 스코프만 믿어야 한다.

또 하나 중요한 점은 토큰의 대상이다. MCP 서버는 받은 액세스 토큰이 자기 자신을 대상으로 발급된 것인지 확인해야 한다. 다른 서비스용 토큰을 그대로 받아들이거나, 클라이언트가 보낸 토큰을 하위 API로 그대로 넘기는 방식은 피해야 한다. MCP 서버가 사내 API나 외부 SaaS를 호출해야 한다면, 그 API에 맞는 별도의 자격 증명이나 위임 흐름을 사용해야 한다.¹

버전 관리와 호환성

MCP 서버의 버전 관리는 코드 버전보다 Tool 계약 관리에 가깝다. 모델과 Host는 Tool 이름, 설명, 입력 스키마를 보고 호출을 결정한다. 따라서 다음 변경은 깨지는 변경으로 봐야 한다.

Tool 이름 변경
필수 입력값 추가
기존 입력값 의미 변경
반환 형식의 핵심 필드 삭제
읽기 Tool을 쓰기 Tool로 바꾸기
같은 이름의 Tool에 더 넓은 권한 부여

안전한 변경은 보통 다음에 가깝다.

새 Tool 추가
선택 입력값 추가
설명을 더 명확하게 수정
반환값에 보조 필드 추가
내부 성능 개선

원격 서버는 다음 방식으로 운영한다.

/mcp/v1  안정 버전
/mcp/v2  다음 버전, 일부 팀만 테스트

또는 엔드포인트는 유지하되 서버 메타데이터와 배포 태그로 버전을 관리할 수 있다. HTTP 기반 MCP에서는 초기화 과정에서 협상한 프로토콜 버전도 중요하다. 최신 Streamable HTTP에서는 클라이언트가 이후 요청에 MCP-Protocol-Version 헤더를 포함해 서버가 어떤 프로토콜 버전 기준으로 응답해야 하는지 알 수 있게 한다.² 서버 버전, Tool 계약 버전, MCP 프로토콜 버전은 서로 다른 축이므로 운영 문서에서 구분해 두는 편이 좋다.

중요한 것은 "오늘 배포한 Tool 설명 변경이 모든 사용자의 작업 흐름을 바꿀 수 있다"는 점이다. 롤백도 미리 준비한다. 컨테이너 이미지는 latest만 쓰지 말고 support-mcp:1.4.2처럼 고정 태그를 남긴다. 데이터베이스 마이그레이션이 있다면 서버 롤백과 함께 되돌릴 수 있는지 확인한다. Tool 스키마 변경은 배포 전에 MCP Inspector나 테스트 Host로 tools/list, 주요 tools/call을 자동 점검한다.

운영 체크리스트

원격 MCP 서버를 팀에 공개하기 전에는 다음 항목을 확인한다.

HTTPS가 적용되어 있는가?
인증 없는 공개 엔드포인트가 아닌가?
Gateway를 우회해 MCP 서버에 직접 접근할 수 없는가?
Streamable HTTP 서버가 Origin 헤더를 검증하는가?
토큰을 URL이 아니라 Authorization 헤더로만 받는가?
액세스 토큰의 audience와 스코프를 서버에서 검증하는가?
Tool별 권한 검사가 서버 코드에 있는가?
쓰기 Tool은 미리보기와 승인 단계를 거치는가?
요청 크기, 응답 크기, 실행 시간 제한이 있는가?
외부 API 실패와 재시도 정책이 정리되어 있는가?
멱등성이 필요한 Tool에 요청 ID가 있는가?
로그에 사용자 ID, Tool 이름, 버전, 지연 시간, 결과 상태가 남는가?
로그에서 토큰, 개인정보, 고객 비밀이 마스킹되는가?
/health/live, /health/ready 같은 헬스체크가 있는가?
새 버전 배포 후 즉시 롤백할 수 있는가?

로그는 특히 중요하다. MCP 서버는 모델의 판단으로 호출되지만, 운영 책임은 서버 소유자에게 있다. "누가, 언제, 어떤 입력으로, 어떤 Tool을 호출했고, 외부 시스템에 어떤 결과가 생겼는가"를 추적할 수 있어야 한다.

팀용 MCP 서버 카탈로그 만들기

서버가 세 개를 넘기 시작하면 목록 관리가 필요하다. 카탈로그는 내부 앱스토어처럼 만들면 된다. 목적은 서버 홍보가 아니라 안전한 발견과 사용이다.

각 MCP 서버 문서에는 최소한 다음을 적는다.

name: support-mcp
owner: Customer Platform Team
endpoint: https://mcp.company.com/support/v1
transport: Streamable HTTP
auth: Company SSO + OAuth scopes
risk_level: medium
data_access:
  - support tickets
  - customer profile summary
write_tools:
  - submit_customer_reply: approval required
  - change_ticket_status: approval required
read_tools:
  - search_tickets
  - read_ticket
logs: central audit log, 180 days
release_channel: stable
protocol_version: "2025-06-18"
rollback_contact: oncall-customer-platform

카탈로그에는 사용 정책도 함께 둔다.

승인된 Host에서만 연결한다.
개인 토큰으로 운영 서버에 접근하지 않는다.
고객 데이터 Tool은 회사 계정과 SSO를 사용한다.
쓰기 Tool은 자동 실행하지 않는다.
새 Tool 추가는 보안 리뷰와 변경 로그를 거친다.
장애나 오작동은 서버 소유팀에 보고한다.

이 문서는 길 필요가 없다. 중요한 것은 팀원이 "이 서버가 무엇을 할 수 있고, 무엇을 하면 안 되는지"를 바로 이해하는 것이다.

작게 시작해 중앙으로 모으기

원격 MCP 배포의 목표는 거대한 플랫폼을 한 번에 만드는 것이 아니다. 먼저 로컬에서 검증한 읽기 중심 서버 하나를 Docker로 묶는다. 팀용 HTTPS 엔드포인트를 만든다. SSO를 붙인다. Tool 호출 로그를 남긴다. 카탈로그에 등록한다. 그다음 쓰기 Tool과 승인 흐름을 추가한다.

개인 PC의 MCP 서버는 빠른 실험에 좋다. 팀의 원격 MCP 서버는 신뢰와 반복 사용에 좋다. 둘은 경쟁 관계가 아니다. 로컬에서 배우고, 원격에서 운영한다. 이 전환을 제대로 해내면 MCP는 개인 생산성 도구를 넘어 팀의 AI 연결 인프라가 된다.

참고

¹Authorization - Model Context Protocol

²Transports - Model Context Protocol

³Build a Remote MCP server

책 목록

MCP: AI 에이전트 연결의 표준

전체 목차 보기