2026년 7월 29일 기준, AGNTCon + MCPCon Europe는 2026년 9월 17일부터 18일까지 암스테르담에서 열릴 예정이며 공식 일정에는 MCP 도전 과제와 에이전트 인프라 논의가 포함되어 있습니다. 공식 행사 일정이 보여주는 방향처럼, 원격 MCP 배포의 핵심은 단순한 연결이 아니라 운영 가능한 신뢰 경계입니다.
증상 → 로컬 MCP Server를 그대로 외부에 열려고 합니다.
가장 빠른 해법 → 도구와 데이터 권한을 먼저 나누고, 격리 환경에서 HTTPS와 표준 인증을 붙인 뒤 실패 응답까지 검수합니다.
이 글은 이미 로컬 STDIO MCP Server를 만들었고 원격 공유를 준비하는 개발자를 위한 내용입니다. 팀의 공통 AI Agent 도구 입구를 설계하는 플랫폼 엔지니어, 인증과 감사 로그를 담당하는 보안 담당자도 함께 볼 수 있습니다.
마지막 업데이트: 2026년 7월 29일. 행사 일정은 공식 행사 페이지에서, 전송과 인증 기준은 MCP 공식 규격과 공식 보안 지침에서 확인했습니다.
설계 단계의 신뢰 경계
원격 MCP 배포는 명령어를 실행하는 작업이 아니라 접근 범위를 다시 설계하는 작업입니다. 로컬 환경에서는 클라이언트가 하위 프로세스를 직접 실행하지만, HTTP 환경에서는 네트워크를 건너온 요청이 서버 프로세스와 하위 API에 도달합니다.
먼저 다음 항목을 문서로 고정합니다.
- 외부에 노출할 도구 이름과 입력값
- 읽기만 가능한 데이터와 수정 가능한 데이터
- 파일 쓰기, 삭제, 결제, 배포처럼 사용자 동의가 필요한 작업
- 원격 호출을 금지할 작업
- 하위 API에 전달할 수 있는 사용자 정보
- 팀 전체가 공유할 자격 증명과 개인별 자격 증명
MCP의 서버 기능은 프롬프트, 리소스, 도구로 나뉘며, 특히 도구는 모델이 실행할 수 있는 작업으로 취급됩니다. 공식 서버 개요도 도구를 실행 기능으로 설명하므로, 도구 설명만 믿고 자동 실행을 허용해서는 안 됩니다.
| 설계 항목 | 로컬 STDIO | 원격 HTTP | 결정 기준 |
|---|---|---|---|
| 실행 주체 | 클라이언트가 하위 프로세스 실행 | 독립 서버 프로세스 | 여러 사용자가 공유하면 HTTP |
| 기본 접근 범위 | 같은 기기의 클라이언트 중심 | 네트워크 요청 전체 | 외부 공개 여부 |
| 인증 | 환경 변수나 로컬 설정 | HTTP 인증과 토큰 검증 | 사용자별 권한 필요 여부 |
| 공격면 | 로컬 명령과 파일 시스템 | 네트워크, 출처, 세션, 인증 | 공개 범위가 넓을수록 증가 |
| 운영 부담 | 낮음 | 인증, 로그, 회전, 검수 필요 | 장기 운영 인력과 절차 |
공식 규격은 HTTP 인증을 선택 기능으로 보지만, HTTP 기반 구현이 인증을 지원한다면 해당 규격을 따르도록 권고합니다. 반대로 STDIO 구현은 같은 인증 흐름을 그대로 적용하기보다 환경에서 자격 증명을 가져오는 방식이 적합합니다. 인증 규격의 전송별 기준을 기준으로 판단해야 합니다.
최초 배포를 위한 격리 환경
원격 MCP Server를 일반 사용자 계정이나 관리자 권한으로 실행하면 도구 하나의 취약점이 서버 전체 권한으로 확대될 수 있습니다. 개발 단계에서 연결이 잘 되었다는 이유로 운영 서버에 같은 실행 조건을 복사하지 마세요.
다음 순서로 기준 환경을 만듭니다.
- MCP 전용 비특권 계정을 만듭니다.
- 실행 디렉터리, 임시 디렉터리, 읽기 전용 설정 디렉터리를 분리합니다.
- 필요한 파일 경로만 읽기 또는 쓰기로 허용합니다.
- 하위 API에 필요한 도메인과 포트만 네트워크 허용 목록에 넣습니다.
- 셸, 패키지 관리자, 클라우드 메타데이터 주소와 같은 불필요한 접근을 차단합니다.
- 애플리케이션 의존성, 운영체제 의존성, 환경 변수 이름, 설정 파일 형식을 기록합니다.
- 같은 기록만으로 다시 만들 수 있는 이미지나 설치 절차를 보관합니다.
파일 검색 도구라면 전체 홈 디렉터리를 마운트하지 말고 업무 디렉터리만 연결해야 합니다. 배포 도구라면 읽기 작업과 실행 작업을 분리하고, 실행 작업에는 별도의 동의 절차를 둬야 합니다. 공식 보안 지침은 파일 시스템과 네트워크 권한을 최소화하고 샌드박스 사용을 권고합니다.
| 격리 영역 | 허용할 것 | 차단하거나 제한할 것 |
|---|---|---|
| 파일 시스템 | 작업에 필요한 특정 경로 | 홈 전체, SSH 키, 비밀값 저장소 |
| 네트워크 | 승인된 하위 API 주소 | 임의 외부 주소, 내부 관리망 |
| 프로세스 | MCP 실행 프로세스와 필요한 하위 작업 | 관리자 명령, 임의 셸 실행 |
| 설정 | 읽기 전용 기본 설정 | 실행 중 임의 설정 변경 |
| 비밀값 | 전용 비밀 저장소에서 필요한 값만 주입 | 소스 코드와 로그에 직접 저장 |
Macstripe의 클라우드 개발 환경 격리 안내를 함께 참고하면, 원격 MCP 환경을 만들 때 운영 계정과 작업 계정을 나누는 기준을 별도로 정리할 수 있습니다.
HTTPS와 OAuth 2.1 연결
HTTP로 전환한 뒤 가장 흔한 실수는 먼저 포트를 열고 나중에 인증을 붙이는 방식입니다. 이 순서는 테스트 토큰과 임시 우회 로직을 운영 코드에 남기기 쉽습니다.
MCP 공식 인증 흐름을 적용할 때는 다음 항목을 확인합니다.
- MCP 서버를 보호된 리소스 서버로 정의합니다.
- 서버의 표준 리소스 식별자를 정합니다.
- 인증 서버 위치를 보호된 리소스 메타데이터로 제공합니다.
- 클라이언트가 요청하는 토큰의
resource값이 MCP 서버 주소와 일치하는지 확인합니다. - 토큰의 발급자, 대상, 만료 시간, 서명과 필요한 범위를 검증합니다.
- 만료되거나 잘못된 토큰에는
401을 반환합니다. - 권한 부족에는 별도의 범위 부족 응답을 사용합니다.
- 토큰을 하위 API로 그대로 전달하는 토큰 통과 방식을 사용하지 않습니다.
MCP 규격은 HTTP 인증에 OAuth 2.1 기반 흐름을 사용하며, 클라이언트가 토큰을 요청할 때 대상 리소스를 명시하도록 요구합니다. 인증 규격의 리소스 식별자 설명을 기준으로 서버 주소와 토큰 대상을 일치시켜야 합니다.
HTTPS는 로그인 화면만 보호하는 장치가 아닙니다. 콜백 주소, 토큰 교환, 요청 본문, 오류 응답이 이동하는 전체 경로를 보호합니다. 개발 환경의 루프백 주소를 제외하면 운영 OAuth 주소에 평문 HTTP를 허용하지 않는 편이 안전합니다. 운영 환경에서는 HTTPS와 대상 리소스 검증을 함께 적용해야 합니다.
| 인증 상황 | 권장 방식 | 피해야 할 방식 | 검수 포인트 |
|---|---|---|---|
| 사용자가 직접 승인 | OAuth 2.1 권한 부여 흐름 | 공유 API 키 하나로 모든 사용자 처리 | 동의 화면과 범위 |
| 서비스 대 서비스 | 공식 클라이언트 자격 증명 확장 | 사용자 토큰 재사용 | 발급자와 대상 |
| 내부 단일 클라이언트 | 제한된 베어러 토큰 | 쿼리 문자열에 토큰 삽입 | 회전과 폐기 |
| 하위 API 연동 | MCP 전용 토큰과 별도 하위 자격 증명 | 받은 토큰을 그대로 전달 | 대상과 감사 주체 |
서비스 대 서비스 연결에는 사용자 상호 작용이 없는 클라이언트 자격 증명 흐름을 검토할 수 있습니다. 다만 이는 기본 사용자 승인 흐름을 생략하는 확장이므로, 공식 클라이언트 자격 증명 문서처럼 적용 범위와 비밀값 보관 방식을 따로 검토해야 합니다.
비밀값과 로그 관리
원격 MCP Server에는 최소 세 종류의 자격 증명이 생깁니다.
- MCP 클라이언트가 인증 서버에 사용하는 클라이언트 자격 증명
- 사용자를 대신해 MCP 서버에 접근하는 사용자 토큰
- MCP 서버가 하위 API에 접근하는 서비스 자격 증명
세 가지를 같은 환경 변수 파일이나 같은 데이터베이스 필드에 저장하면 회전과 폐기가 어려워집니다. 특히 사용자 토큰과 하위 API 자격 증명을 연결하면, 한쪽이 노출되었을 때 책임 범위를 추적하기 어렵습니다.
로그에는 다음 정보를 남길 수 있습니다.
- 요청 식별자
- 인증 주체의 내부 식별자 또는 해시값
- 호출한 도구 이름
- 요청 시작과 종료 상태
- 권한 부족, 만료, 하위 API 실패 같은 오류 종류
- 하위 시스템의 응답 코드
다음 정보는 기록하지 않습니다.
Authorization헤더 전체- 접근 토큰과 갱신 토큰
- 클라이언트 비밀값
- 하위 API 키
- 사용자가 입력한 원문 비밀번호
- 파일 내용과 개인정보가 포함된 원문 응답
외부 클라이언트에는 “권한 검증 실패”처럼 진단 가능한 범주의 메시지만 돌려주고, 내부 로그에는 상관관계 식별자와 상세 원인을 남깁니다. 오류 세부 정보가 내부 경로와 인증 상태를 노출하지 않도록 응답을 일반화해야 합니다.
클라이언트 연결과 실패 처리
서버가 정상 응답하는지만 확인하면 운영 검수는 끝나지 않습니다. 실패 상태가 올바르게 구분되는지 확인해야 합니다.
다음 순서로 테스트합니다.
- 토큰 없이 MCP 엔드포인트에 요청합니다.
- 잘못된 발급자의 토큰을 보냅니다.
- MCP 서버가 아닌 다른 대상용 토큰을 보냅니다.
- 만료된 토큰을 보냅니다.
- 유효한 토큰으로 허용되지 않은 도구를 호출합니다.
- 하위 API를 차단한 상태에서 도구를 실행합니다.
- 세션 식별자를 바꿔 다른 사용자 상태에 접근하는지 확인합니다.
- 클라이언트가 재인증 후 정상적으로 다시 연결되는지 확인합니다.
Streamable HTTP를 사용할 때는 MCP 엔드포인트의 Origin 값을 검증해야 하며, 잘못된 출처에는 403을 반환해야 합니다. 공식 전송 규격은 로컬 실행 시 루프백 주소에만 바인딩하고, 외부 연결에는 적절한 인증을 적용하도록 안내합니다. Streamable HTTP 보안 기준을 배포 전 테스트 목록에 넣으세요.
실패 로그는 인증 실패, 권한 부족, 하위 API 실패, 서버 내부 오류처럼 분류합니다. 스택 추적, 내부 주소, SQL 문장, 토큰 값은 외부 응답에 넣지 않습니다. 클라이언트가 같은 요청을 반복해도 안전한지, 중복 쓰기 작업이 발생하지 않는지도 확인해야 합니다.
운영 전 최종 검수
다음 표에서 하나라도 답이 “아니오”라면 전체 공개를 미루고 해당 항목을 수정해야 합니다.
| 검수 항목 | 합격 기준 | 실패 시 조치 |
|---|---|---|
| 최소 권한 | 도구와 범위가 업무별로 분리됨 | 범위 재설계 |
| 인증 | 발급자, 대상, 만료, 서명을 검증함 | 인증 미들웨어 수정 |
| HTTPS | 운영 경로와 콜백이 모두 암호화됨 | 평문 경로 차단 |
| 비밀값 | 코드와 로그에 비밀값이 없음 | 저장소와 로그 정리 |
| 철회 | 사용자, 클라이언트, 토큰을 개별 폐기 가능 | 폐기 절차 추가 |
| 세션 | 인증과 세션 식별자를 분리함 | 세션 검증 로직 수정 |
| 복구 | 설정과 의존성을 다시 만들 수 있음 | 기준 이미지와 백업 작성 |
| 회귀 테스트 | 규격과 SDK 변경 뒤 다시 검증함 | 테스트 자동화 |
공식 타입스크립트 SDK 저장소는 2026년 7월 28일 규격 변경과 SDK 지원 내용을 별도로 안내하고 있습니다. SDK 변경 지원 문서처럼, 규격이나 SDK가 업데이트되었다고 기존 동작이 자동으로 안전해지는 것은 아닙니다. 인증, 범위, 전송, 세션 테스트를 다시 실행해야 합니다.
장기 운영에서는 다음 작업을 일정으로 고정합니다.
- 클라이언트 자격 증명과 하위 API 키의 회전
- 사용자 토큰과 동의 기록의 폐기
- 도구 목록과 권한 범위의 분기별 검토
- 운영 이미지와 의존성의 재현성 확인
- 규격과 SDK 변경 뒤 회귀 테스트
- 백업 복구와 이전 버전 롤백 연습
로컬 실행을 그대로 유지하는 방법은 네트워크 공격면이 작고 빠르게 시작할 수 있다는 장점이 있습니다. 반면 팀 공용 접근, 중앙 감사, 사용자별 권한 관리에는 불리합니다. 원격 HTTP 방식은 공유와 자동화에 유리하지만 인증 서버, HTTPS, 로그, 세션, 하위 API 자격 증명까지 함께 운영해야 합니다. 따라서 “원격으로 공유해야 하는가”가 먼저이며, 단지 다른 기기에서 쓰고 싶다는 이유만으로 공개 서버를 만드는 것은 좋은 선택이 아닙니다.
자주 묻는 질문
로컬 MCP Server를 원격 서버로 옮길 때 가장 먼저 해야 할 일은 무엇인가요?
실행 명령부터 외부에 공개하면 안 됩니다. 먼저 도구 목록, 읽는 데이터, 쓰기 작업, 사용자 동의가 필요한 작업을 분류해야 합니다. 그다음 비특권 계정과 제한된 파일 시스템을 사용하는 격리 환경을 만든 뒤 HTTPS와 인증을 붙여야 합니다. 연결 성공은 운영 가능성을 의미하지 않습니다.
원격 MCP Server는 항상 OAuth 2.1을 사용해야 하나요?
모든 MCP 구현에 인증이 강제되는 것은 아닙니다. 그러나 HTTP로 외부 클라이언트가 접근하고 사용자별 권한이나 민감한 데이터가 포함된다면 공식 인증 규격에 맞춘 OAuth 2.1 흐름이 적합합니다. 단일 내부 자동화라면 별도 확장을 검토할 수 있지만, 토큰의 대상과 발급자를 반드시 검증해야 합니다.
MCP Server에서 인증 정보가 로그로 새지 않게 하려면 어떻게 해야 하나요?
Authorization 헤더, 접근 토큰, 갱신 토큰, 클라이언트 비밀값, 하위 API 키를 로그에 남기지 않아야 합니다. 대신 요청 식별자, 사용자 식별자의 해시값, 도구 이름, 결과 상태, 지연 시간처럼 감사에 필요한 정보만 기록합니다. 오류 원인은 내부 로그에 남기되 외부 응답에는 일반화된 메시지를 사용합니다.
MCP의 STDIO 방식과 HTTP 방식은 배포 관점에서 어떻게 다른가요?
STDIO는 클라이언트가 같은 기기에서 하위 프로세스를 실행하므로 네트워크 공개와 원격 인증 부담이 작습니다. HTTP는 여러 클라이언트가 독립 프로세스에 접근하므로 HTTPS, 출처 검증, OAuth 2.1, 세션 수명, 감사 로그가 필요합니다. 공유가 목적이면 HTTP가 유리하지만 보안 운영 범위도 함께 커집니다.
