원격 MCP 서버 vs 로컬 MCP 서버: 무엇을 써야 할까

로컬 MCP 서버는 내 컴퓨터에서 돌아갑니다. AI 앱이 하위 프로세스로 실행하고 표준 입출력으로 대화하며, 자격 증명은 환경 변수에서 읽습니다. 원격 MCP 서버는 HTTPS URL에 있고, Streamable HTTP 전송을 쓰며, 각 사용자를 OAuth로 로그인시킵니다. 내 파일과 내 API 키라면 로컬을, 팀이 공유하거나 제품으로 판매하는 것이라면 원격을 쓰세요.

이것이 한 문단으로 정리한 결정입니다. 나머지는 명세가 정의하는 두 전송 방식, 각각이 보안과 운영에 의미하는 바, 선택 방법, 그리고 우리 것을 포함해 일부 서버가 원격 전용인 이유를 설명합니다.

MCP 명세가 정의하는 두 가지 전송 방식

Model Context Protocol은 모든 메시지를 JSON-RPC로 인코딩합니다. 명세(2025-11-25 개정판)는 그 메시지를 나르는 표준 전송 방식을 정확히 두 가지 정의하며, 클라이언트는 가능하면 첫 번째를 지원해야 한다고 말합니다.

stdio. 클라이언트가 서버를 하위 프로세스로 실행합니다. 서버는 표준 입력에서 JSON-RPC 메시지를 읽고 표준 출력에 한 줄에 하나씩 씁니다. 표준 오류에 로그를 남길 수 있고, stdout에는 그 외 아무것도 쓰면 안 됩니다.
Streamable HTTP. 서버는 https://example.com/mcp 같은 단일 HTTP 엔드포인트를 가진 독립 프로세스로, POST와 GET을 받습니다. 클라이언트의 모든 메시지는 POST입니다. 서버는 JSON 객체 하나로 답하거나, 보낼 메시지가 여럿이면 Server-Sent Events 스트림을 엽니다. 2024-11-05 개정판의 옛 HTTP+SSE 전송을 대체했고, 옛 방식은 이제 폐기 예정입니다.

"로컬"과 "원격"은 이 둘의 일상적 이름입니다. 로컬 서버는 거의 항상 stdio이고, 원격 서버는 항상 Streamable HTTP입니다. Streamable HTTP 서버를 localhost에서 돌릴 수도 있고, 명세는 그런 서버가 127.0.0.1에만 바인딩해야 한다고 적지만, 흔한 형태는 위의 둘입니다. 명세의 전송 방식 절에 전체 규칙이 있고, 원격 서버 용어집 항목이 짧은 버전입니다.

로컬 서버는 어떻게 동작하는가

무언가를, 보통 Node, Python, Go로 된 작은 프로그램을 설치하고 실행 명령과 함께 AI 앱 설정에 추가합니다. 앱이 시작되면 프로세스를 띄웁니다. 서버는 보통 앱이 넘겨주는 환경에서 API 키나 데이터베이스 경로를 읽습니다. 앱을 닫으면 프로세스는 죽습니다.

이것이 MCP의 원래 형태이고, 여전히 많은 종류의 서버에 맞는 형태입니다.

지정한 폴더를 읽는 파일시스템 서버
셸 프로필에 연결 문자열을 둔 데이터베이스 서버
이미 컴퓨터에 설치된 CLI 도구의 래퍼
오후 한나절에 프로토타이핑하는 모든 것

강점은 단순함과 지역성입니다. 네트워크도, TLS 인증서도, 로그인도, 멀티테넌시도 없습니다. 서버는 그것을 실행한 한 사람을 위해 일합니다. 명세는 stdio 서버가 OAuth 인가 흐름을 쓰지 말고 환경에서 자격 증명을 가져와야 한다고 말합니다.

약점은 같은 사실을 팀 쪽에서 본 것입니다. 모든 사람이 각자의 사본을 설치하고 갱신합니다. 사본마다 자기 키가 필요합니다. 노트북의 설정 파일에 있는 키는 복사되고, 실수로 커밋되고, 누군가 떠날 때 남겨질 수 있는 키입니다. 그리고 누가 무엇을 호출했는지 중앙에서 아는 방법이 없습니다.

원격 서버는 어떻게 동작하는가

원격 서버는 웹 서비스입니다. URL로 앱에 추가합니다. 첫 호출에서 서버는 메타데이터를 가리키는 포인터와 함께 401 Unauthorized로 답합니다. 앱이 인가 서버를 찾아 브라우저를 열고, 사용자가 로그인해 스코프 집합을 승인하면, 그때부터 모든 요청이 Authorization 헤더에 베어러 토큰을 싣습니다. 앱 안의 MCP 클라이언트가 이 모든 과정을 처리하고, 사용자에게는 동의 화면만 보입니다.

Streamable HTTP에는 사용자나 운영자로서 눈에 띄는 몇 가지 장치가 있습니다.

세션. 서버는 초기화 때 MCP-Session-Id 헤더를 돌려줄 수 있고, 그러면 클라이언트는 모든 요청에 그것을 보내야 합니다. 서버는 언제든 세션을 끝낼 수 있고, 그 후 클라이언트는 새 세션을 시작합니다.
스트리밍. 긴 도구 호출에서 서버는 SSE 스트림을 열어 진행 알림을 보내고 응답으로 마무리할 수 있습니다. 연결이 끊기면 클라이언트는 Last-Event-ID로 재연결할 수 있고, 서버는 놓친 것을 다시 보낼 수 있습니다.
Origin 검증. 서버는 모든 연결에서 Origin 헤더를 검증하고 잘못된 것은 403으로 거부해야 합니다. 악성 웹 페이지가 브라우저를 통해 서버와 대화하는 것을 막기 위해서입니다.
매 호출 인증. 토큰은 각 요청의 헤더에 들어가며 URL에는 절대 넣지 않고, 서버는 그 토큰이 바로 이 서버를 위해 발급된 것인지 확인해야 합니다.

보상은 하나의 배포가 모두를 섬긴다는 것입니다. 아무도 아무것도 설치하지 않습니다. 접근은 사람별로 부여되고, 승인한 범위로 제한되며, 서버 쪽에서 취소할 수 있습니다. 모든 호출을 토큰 뒤의 사람에 대해 감사할 수 있습니다.

비용은 이제 서비스를 운영하게 된다는 것입니다. 호스팅, TLS, 가동 시간, 속도 제한, 테넌트 격리, 그리고 OAuth 인가 서버 또는 그와의 연동. 나만 쓰는 서버에는 과한 장치입니다.

원격 MCP 서버와 로컬 MCP 서버 나란히 비교

	로컬(stdio)	원격(Streamable HTTP)
실행 위치	내 컴퓨터, 하위 프로세스	나 또는 공급사가 운영하는 호스트
클라이언트 접근 방식	명령을 실행	HTTPS URL에 접속
대상 사용자	프로세스당 한 사람	여러 사람, 하나의 배포
자격 증명	환경 변수, 설정 파일	사람별 OAuth 토큰, 스코프 지정, 취소 가능
설치	각자 설치하고 갱신	없음. URL만 추가
네트워크 노출	없음	공개 엔드포인트. TLS, Origin 검사, 속도 제한 필요
감사 기록	서버가 로컬에 남기는 것	중앙, 토큰과 사람별
지연 시간	가장 낮음	네트워크 왕복
적합한 용도	파일, 로컬 DB, CLI, 프로토타입	SaaS 제품, 팀 데이터, 다중 사용자 전반
명세의 인증 지침	OAuth 대신 환경 사용	인가 명세의 OAuth 2.1 흐름

무엇을 써야 하는가

세 가지 질문을 하세요.

누구의 데이터인가? 서버가 내 파일이나 나만 만지는 데이터베이스를 읽는다면 로컬. 여러 사람이 공유하고, 회사에 속한 레코드가 있으며, 사람마다 권한이 다른 시스템을 읽는다면 원격. 로컬 서버는 "Priya는 거래 금액을 볼 수 있고 Tom은 볼 수 없다"를 표현할 방법이 없습니다. 받은 키의 권한으로 돌 뿐입니다.

누가 설치해야 하는가? 답이 "나, 한 번"이라면 로컬도 괜찮습니다. 답이 "모든 팀원이, 그리고 계속 갱신"이라면 원격 서버가 그 수고를 통째로 없앱니다. 우리는 로컬 버전이 일주일 안에 무너지는 것을 봤습니다. 한 사람의 설정에는 옛 키가, 다른 사람의 설정에는 그 사람 컴퓨터에서만 동작하는 경로가 있는 식입니다.

누군가 떠나면 어떻게 되는가? 로컬 서버라면 그 사람의 키는 내가 볼 수 없는 파일 안에 있습니다. OAuth로 뒷받침되는 원격 서버라면 계정을 취소하는 순간 그 사람이 만든 모든 토큰이 다음 호출에서 끝납니다.

작은 팀에 합리적인 규칙은 이렇습니다. 각자의 노트북에 있는 개발 도구에는 로컬 서버, 팀이 실제로 일하는 모든 제품에는 원격 서버.

팀이 자체 원격 서버를 호스팅해야 할 때

대부분의 팀은 공급사가 운영하는 원격 서버에 연결할 것입니다. 때로는 직접 호스팅하는 것이 맞습니다. 공급사가 없는 내부 시스템, 어시스턴트가 사람별 권한으로 질의하길 원하는 데이터베이스, 직접 만든 API 같은 경우입니다. 그 전에 도구 자체가 아닌 부분의 예산을 잡으세요.

인가 서버. MCP 인가 명세는 PKCE와 메타데이터 발견을 갖춘 OAuth 2.1을 기대합니다. 직접 운영하거나, 이를 지원하는 ID 공급자를 서버 앞에 둘 수 있습니다.
모든 요청에서의 토큰 검증. 토큰이 다른 리소스가 아니라 내 서버를 위해 발급되었는지 확인하는 것을 포함합니다.
테넌트 격리. 요청의 토큰이 볼 수 있는 범위를 제한해야 합니다. 그 토큰을 중심으로 요청마다 새 인스턴스나 새 컨텍스트가 만들어지고, 사람 사이에 아무것도 캐시되지 않도록 서버를 설계하세요.
속도 제한과 감사. 바쁜 클라이언트 하나가 나머지를 굶겨서는 안 되고, 나중에 누가 어떤 도구를 실행했는지 알아야 합니다.
운영. TLS, 가동 시간, 클라이언트를 깨뜨리지 않고 도구 목록 버전 관리하기.

이 목록이 필요에 비해 무거워 보인다면, 서버를 로컬로 두거나 공급사를 기다리세요.

Atrix가 원격 전용인 이유

우리 자신의 MCP 서버가 이 선택의 실례입니다. Atrix는 공유 워크스페이스입니다. 팀의 프로젝트, 문서, 고객, 캘린더, 인사 기록이 그 안에 있고, 각자가 볼 수 있는 것이 다릅니다. 로컬 서버라면 만든 사람만큼 강력한 키 하나를 모든 노트북에서 돌려야 하고, 서버는 실제로 누가 묻고 있는지 결코 알 수 없습니다.

그래서 Atrix 서버는 Streamable HTTP를 쓰는 단일 원격 엔드포인트 https://atrix.dev/api/mcp입니다. 설치할 패키지가 없습니다. Claude Code에서는 설정 전체가 한 줄, claude mcp add --transport http atrix https://atrix.dev/api/mcp이고, 이어서 /mcp에서 Authenticate를 선택합니다. 브라우저가 열리고, 워크스페이스를 고르고 스코프를 승인하면, 클라이언트는 수명이 짧은 액세스 토큰과 회전하는 리프레시 토큰을 저장합니다. 서버는 제시된 토큰을 중심으로 요청마다 새 인스턴스를 만들므로 요청 사이나 워크스페이스 사이에 아무것도 공유되지 않고, 모든 호출은 도구, 결과, 대상별로 감사됩니다. 85개 도구를 제공하며 공식 MCP 레지스트리와 Glama에 등록되어 있습니다. 기능 페이지에서 도구가 무엇을 하는지 다룹니다.

한계도 실재합니다. 오프라인 모드는 없고, Atrix 계정 없이는 쓸 수 없습니다. 속도 제한은 토큰당 분당 120회 호출, 30회 쓰기입니다. 그리고 스코프는 사람이 이미 할 수 있는 것을 좁힐 수만 있으므로, 누군가의 계정으로 연결된 어시스턴트는 그 사람 이상을 결코 볼 수 없습니다. 모든 것에 닿는 서버가 필요하다면 이것은 아니며, 우리는 그것이 옳은 선택이라고 생각합니다.

FAQ

원격 MCP 서버와 로컬 MCP 서버의 차이는 무엇인가요?

로컬 서버는 내 컴퓨터에서 하위 프로세스로 돌고 stdio로 대화하며 자격 증명은 환경에서 옵니다. 원격 서버는 HTTPS URL에서 Streamable HTTP로 돌고, 각 사용자를 OAuth로 인증하며, 하나의 배포로 많은 사용자를 섬깁니다.

stdio와 Streamable HTTP 중 무엇이 더 나은가요?

일반적으로 어느 쪽이 더 낫지는 않습니다. 명세는 둘 다 정의하고, 클라이언트에게 가능하면 stdio를 지원하라고 합니다. stdio는 더 단순하고 네트워크 노출이 없으며, Streamable HTTP는 서버가 공유되거나 사용자 컴퓨터 밖에서 호스팅될 때의 유일한 선택지입니다.

Streamable HTTP 서버를 로컬에서 돌릴 수 있나요?

예. 명세는 로컬에서 도는 HTTP 서버가 localhost에만 바인딩해야 하고 DNS 리바인딩을 막기 위해 Origin 헤더를 검증해야 한다고 말합니다. 단일 사용자 서버로는 여전히 stdio보다 덜 흔한 형태입니다.

원격 MCP 서버에 OAuth가 필요한가요?

MCP 인가 명세는 HTTP 전송을 쓰는 구현이 이를 따라야 한다고 말하며, OAuth 2.1 위에 만들어져 있습니다. 일부 서버는 대신 붙여 넣은 베어러 토큰을 받는데, 더 단순하고 더 약합니다. 토큰이 오래 살고, 설정 파일에 있으며, 동의 화면으로 범위가 제한되지 않습니다.

HTTP+SSE 전송은 어떻게 되었나요?

2024-11-05 개정판에서 정의되었고 2025-03-26에 Streamable HTTP로 대체되었습니다. 현재 명세는 이를 폐기 예정으로 표시하고, 클라이언트와 서버가 옛 형태와 호환을 유지하는 방법을 설명합니다.

Atrix MCP 서버를 로컬로 쓸 수 있나요?

아니요. https://atrix.dev/api/mcp의 원격 전용입니다. 워크스페이스 데이터가 공유되고, 사람별 권한을 호출마다 서버가 강제해야 하기 때문입니다.

다음 단계

어시스턴트를 Atrix에 연결한다면 개발자 개요에 Claude Code, Claude Desktop, ChatGPT, Cursor의 정확한 단계가 있고, MCP 기능 페이지에 도구 목록이 있습니다. 자체 서버를 어떻게 만들지 결정 중이라면 MCP 클라이언트와 원격 MCP 서버 항목을 먼저 읽으세요.

원격 MCP 서버와 로컬 MCP 서버: stdio, Streamable HTTP, 그리고 팀이 선택해야 할 것