MCP 서버 클라우드 맥 배포: 출시 검수 가이드

MCP Inspector는 기본 실행 시 웹 화면과 프록시를 각각 6274번과 6277번 포트에서 엽니다. 공식 MCP Inspector 안내는 원격 검수 도구가 로컬 프로세스를 실행할 수 있다고 설명합니다. 따라서 MCP 서버 클라우드 맥 배포는 맥 전용 도구가 있을 때만 선택하고, 원격 서비스는 Streamable HTTP로 전환한 뒤 새 규격과 이전 연결 방식을 함께 검증해야 합니다.

이 글은 다음 세 부류를 위한 안내입니다.

• 로컬 MCP 서버를 팀 공유 원격 서비스로 바꾸려는 개발자
• OpenAI Agents SDK 같은 AI 에이전트에서 맥 도구를 호출하려는 통합 팀
• 클라우드 맥의 권한, 프로세스, 보안, 출시 검수를 맡은 플랫폼 엔지니어

마지막 업데이트: 2026년 8월 13일
데이터 확인 기준: MCP 2026년 7월 28일 출시 안내, 공식 Streamable HTTP 규격

주의: MCP는 특정 운영체제에서만 실행되는 프로토콜이 아닙니다. 맥이 필요한 이유는 프로토콜이 아니라 Xcode, macOS 전용 명령, Apple 도구 또는 특정 맥 애플리케이션 때문입니다.

1단계: 클라우드 맥 필요성 판단

로컬에서 stdio 방식으로 잘 작동하던 서버를 그대로 외부에 공개하면 문제가 생깁니다. 원격 클라이언트는 로컬 표준 입출력에 접근할 수 없습니다. 서버를 모든 네트워크 인터페이스에 바인딩하면 파일과 명령 실행 권한이 과도하게 노출될 수 있습니다. 개발자의 개인 환경 변수, 로그인 상태, 작업 폴더가 서버 실행 계정에 섞이는 문제도 생깁니다.

먼저 다음 세 가지를 나누어 판단해야 합니다.

• 계속 로컬 실행: 개인용 파일 검색과 로컬 자동화처럼 외부 공유가 필요하지 않은 경우
• 일반 클라우드 서버: 운영체제에 독립적인 데이터 조회, 웹 API, 문서 처리 도구
• 클라우드 맥: Xcode, macOS 명령, 맥 애플리케이션, Apple 개발 도구처럼 실행 환경 자체가 맥이어야 하는 경우

맥이 필요하지 않은 도구를 클라우드 맥으로 옮기면 운영체제 비용과 원격 접속 관리만 늘어납니다. 반대로 맥 앱 호출을 일반 서버로 옮기면 도구가 설치되지 않거나, 권한 승인과 사용자 세션 문제로 호출이 실패할 수 있습니다. 환경 선택을 끝낸 뒤에야 클라우드 맥 환경 상담을 위한 도움 센터를 확인할 가치가 생깁니다.

2단계: 프로토콜과 클라이언트 경계 확인

MCP 2026-07-28은 프로토콜 핵심을 무상태 방식으로 바꾸고, 기존 초기화 교환과 Mcp-Session-Id 중심 흐름을 제거했습니다. 각 요청이 필요한 정보를 자체적으로 전달하도록 바뀌었으며, 서버 검색이 필요하면 별도 발견 요청을 사용할 수 있습니다. 출시 문서에는 권한 강화, 요청 라우팅 헤더, 확장 구조와 구형 HTTP+SSE의 유예 정책도 정리되어 있습니다.

SDK가 새 규격을 지원한다는 사실과 프로젝트가 새 규격을 실제로 사용한다는 사실은 다릅니다. 사용 중인 클라이언트, SDK 세대, 서버 실행 방식, 목표 프로토콜을 배포 전에 표로 고정해야 합니다.

TypeScript SDK의 서버 전송 문서는 원격 서버에 Streamable HTTP를, 로컬 자식 프로세스에 stdio를 사용하는 방향을 설명합니다. 다만 SDK의 기본 설정과 실제 프로젝트의 설정이 일치하는지는 별도로 확인해야 합니다.

3단계: 클라우드 맥 첫 한 시간 설정

서버가 전달된 직후에는 기능을 추가하기보다 실행 경계를 고정해야 합니다.

1. MCP 서버 전용 운영 계정을 만듭니다. 개인 관리자 계정으로 상시 실행하지 않습니다.
2. 전용 작업 폴더를 만들고 도구가 꼭 필요한 하위 경로만 읽고 쓰게 합니다.
3. 실행 파일, 캐시, 임시 파일, 결과 파일의 위치를 분리합니다.
4. 런타임과 패키지 버전을 잠금 파일로 고정합니다.
5. 환경 변수 또는 비밀 저장 방식으로 토큰을 주입합니다.
6. 프로세스 수호, 예외 재시작, 종료 신호 처리를 설정합니다.
7. 로그 회전과 보존 정책을 정하고 토큰과 전체 요청 본문이 남지 않게 합니다.
8. 처음부터 다시 설치할 수 있도록 명령과 설정 파일을 문서화합니다.

토큰을 소스 코드, 실행 인자, 일반 로그에 넣으면 접근 권한을 줄여도 유출 경로가 남습니다. 특히 도구가 셸 명령이나 파일 읽기를 지원한다면 환경 변수 전체를 도구가 볼 수 있는지까지 확인해야 합니다. 개인정보와 접근 토큰의 보관 범위는 SSHMac 개인정보 처리 안내와 내부 운영 정책에 함께 기록하는 편이 안전합니다.

4단계: 원격 엔드포인트 전환

로컬 stdio 진입점과 원격 HTTP 진입점을 분리하되, 도구의 실제 업무 로직은 공유하세요. 이렇게 해야 로컬 디버깅과 원격 배포가 같은 입력 검증과 권한 판단을 사용합니다.

Streamable HTTP 서버는 하나의 MCP 엔드포인트에서 POST 요청을 받고, 요청에 따라 일반 JSON 응답 또는 이벤트 스트림을 반환할 수 있습니다. 공식 규격은 클라이언트가 application/json과 text/event-stream을 모두 받을 수 있어야 한다고 규정합니다. Origin 검증과 인증도 함께 적용해야 하며, 잘못된 Origin에는 HTTP 403을 반환할 수 있습니다. 세부 동작은 2026년 7월 28일 전송 규격을 기준으로 점검하세요.

새 규격에서 프로토콜 세션이 없어졌다고 해서 모든 업무 상태가 사라지는 것은 아닙니다. 여러 호출에 걸쳐 유지해야 하는 작업 ID, 승인 상태, 결과 위치는 데이터베이스나 명시적인 업무 상태로 관리해야 합니다. 전송 계층의 연결 상태를 업무 상태처럼 사용하면 재시작이나 다른 인스턴스로의 라우팅에서 오류가 납니다.

공개 전에는 다음을 적용합니다.

• TLS가 적용된 제한된 도메인만 MCP 엔드포인트로 사용합니다.
• 인증 없는 상태에서 도구 목록과 호출이 노출되지 않게 합니다.
• 프록시에서 요청 본문과 인증 헤더를 임의로 기록하지 않습니다.
• Origin, 인증서, 요청 크기, 시간 제한을 별도로 검증합니다.
• 새 규격 연결 실패 시 구형 클라이언트 경로를 제한적으로 시험합니다.

원격 배포 선택 점수

아래 점수는 공식 성능 측정값이 아니라 배포 의사결정을 위한 편집 기준입니다. 맥 의존성, 원격 공유 필요성, 보안 관리 부담을 각각 5점 만점으로 평가하세요.

세 항목 중 맥 의존성이 낮다면 클라우드 맥을 기본값으로 선택하지 마세요. 반대로 맥 앱 호출이 핵심이고 팀 공유가 필요하다면 원격화에 투자할 이유가 있습니다.

클라이언트 연결 문제와 회귀 경로

MCP 서버를 맥에 배포한 뒤 클라이언트가 연결되지 않는다면 먼저 서버가 실행 중인지보다 전송 방식과 주소를 확인해야 합니다.

1. 서버가 127.0.0.1에만 바인딩되어 있지 않은지 확인합니다.
2. 외부에 공개할 때는 허용된 도메인과 포트만 역방향 프록시로 전달합니다.
3. 클라이언트가 Streamable HTTP를 지원하는지 확인합니다.
4. POST 요청의 Accept 헤더와 서버의 콘텐츠 형식을 확인합니다.
5. 인증 헤더가 프록시에서 제거되지 않았는지 확인합니다.
6. 새 연결이 실패하면 구형 SSE 경로를 제한된 테스트 계정으로만 검증합니다.
7. 양쪽 로그에서 요청 ID, 오류 유형, 인증 결과를 대조합니다.

구형 연결이 된다고 해서 새 규격 배포가 끝난 것은 아닙니다. 목표 클라이언트가 새 전송을 실제로 선택하는지, 서버가 잘못된 요청에 안전하게 실패하는지까지 확인해야 합니다.

세션 상태와 업무 상태 분리

새 MCP 프로토콜이 세션 유지에 덜 의존한다고 해서 장시간 작업의 상태 관리가 자동으로 해결되는 것은 아닙니다. 원격 서비스에서 유지해야 하는 상태를 다음처럼 구분하세요.

• 프로토콜 상태: 초기화와 기능 협상처럼 요청 흐름에 필요한 정보
• 업무 상태: 승인 여부, 작업 ID, 생성 파일 위치, 외부 작업의 진행 상태
• 보안 상태: 토큰의 유효 기간, 호출 주체, 승인 기록

업무 상태는 명시적인 저장소와 만료 정책으로 관리해야 합니다. 서버 재시작 뒤에도 이어져야 하는 작업이라면 전송 연결이나 메모리 변수에만 저장하지 마세요. 반대로 단순 조회처럼 상태가 필요 없는 도구는 요청마다 독립적으로 처리하는 편이 장애 범위를 줄입니다.

5단계: 출시 당일 권한과 도구 검수

검수 순서는 도구 발견, 정상 호출, 잘못된 입력, 권한 거부, 위험한 요청 순서가 좋습니다. MCP Inspector는 웹 화면과 명령줄 방식으로 MCP 서버를 확인할 수 있고, 원격 Streamable HTTP 대상에 연결하는 옵션도 제공합니다. 공식 Inspector 사용 문서를 기준으로 다음 항목을 기록하세요.

• tools/list에서 실제 공개할 도구만 표시되는가
• 필수 인자 누락과 잘못된 형식이 예측 가능한 오류로 반환되는가
• 정상 호출 결과가 모델이 이해할 수 있는 구조인가
• 인증 토큰이 없거나 잘못된 경우 거부되는가
• 파일 경로를 상위 폴더로 탈출할 수 없는가
• 외부 주소 요청을 통해 SSRF가 발생하지 않는가
• 명령 실행 도구가 허용 목록 밖의 프로그램을 실행하지 않는가
• 토큰이 반환값과 로그에 섞이지 않는가
• 위험 작업에 별도 승인 단계가 있는가

MCP Inspector 자체도 로컬 프로세스를 시작하거나 지정한 MCP 서버에 연결할 수 있는 프록시를 포함합니다. 따라서 검수 도구를 공용 네트워크에 그대로 노출하지 말고, 로컬 바인딩이나 인증된 관리망에서만 사용하세요.

6단계: 첫 주 운영과 후퇴 계획

출시 후에는 실제 AI 에이전트 클라이언트 하나를 정해 끝까지 연결합니다. OpenAI Agents SDK는 에이전트에 MCP 기반 도구를 연결할 수 있지만, 에이전트가 모든 도구를 자동으로 안전하게 선택한다는 뜻은 아닙니다. 공식 에이전트 문서를 확인한 뒤 도구 선택, 승인, 오류 처리 정책을 직접 지정해야 합니다.

첫 주에는 다음 사건을 별도 지표로 기록하세요.

• 서버 시작 실패
• 도구 목록 조회 실패
• 도구 호출 오류
• 권한 거부
• 프록시와 인증 실패
• 작업 폴더 접근 거부
• 비정상 종료와 재시작

특정 지연 시간이나 처리량을 일반적인 성능 기준처럼 쓰지는 마세요. 맥 구성, 도구의 외부 API, 네트워크 경로에 따라 결과가 달라집니다. 같은 입력으로 로컬과 원격을 각각 호출해 실패 유형과 재현 조건을 비교하는 방식이 더 유효합니다.

배포 버전, 패키지 잠금 파일, 환경 설정, 빠른 차단 방법을 함께 보관해야 합니다. MCP 규격, SDK 주 버전, 주요 클라이언트의 전송 방식이 바뀌면 새 기능을 바로 적용하지 말고 호환성 표와 권한 검수를 다시 실행하세요. 새 규격의 구형 기능에는 공식 유예 정책이 안내되어 있지만, 실제 클라이언트가 그 기간 동안 계속 지원한다는 보장은 별도로 확인해야 합니다.

현재 방식과 클라우드 맥의 선택

현재 로컬 방식은 개인 컴퓨터가 꺼지면 서비스가 멈추고, 팀원이 같은 실행 환경을 공유하기 어렵습니다. 일반 클라우드 서버는 맥 앱과 Apple 도구를 실행하지 못할 수 있으며, 로컬 stdio를 그대로 외부 연결로 바꿀 수도 없습니다. 반면 클라우드 맥은 맥 전용 실행 환경을 제공하지만 계정 권한, 프로세스 관리, 원격 접근 통제가 추가됩니다.

따라서 먼저 도구가 실제로 macOS를 요구하는지 확인한 뒤, Streamable HTTP 전환과 권한 검수 항목을 정리하세요. 그 결과 맥 전용 실행 환경이 분명하고 임시 팀 공유나 테스트 기간이 필요하다면 SSHMac의 맥 미니 렌탈과 전달 방식을 비교해 보는 편이 합리적입니다. 장기간 고정 부하를 계속 처리하거나 물리 장치 연결이 필수라면 직접 장비를 운영하는 편이 더 적합할 수 있습니다.