MCP 서버는 원격에 둬야 할까, 로컬에 둬야 할까 — 전송 방식이 결정되는 한 줄

MCP(Model Context Protocol)로 코딩 어시스턴트에 도구를 노출하다 보면 한 가지 질문이 반드시 등장한다. 이 MCP 서버를 대체 어디서 돌려야 하는가? 같은 머신 안에서? 아니면 네트워크 너머 원격 박스에서?

배경: MCP와 전송 방식

MCP(Model Context Protocol — AI 모델과 외부 도구를 잇는 공개 표준)는 코딩 어시스턴트 같은 클라이언트가 "도구를 가진 서버"와 약속된 형식으로 대화하게 해준다. 클라이언트가 도구 실행을 요청하면, 서버가 그 도구를 실제로 돌리고 결과를 돌려준다.

여기서 자주 간과되는 축이 전송 방식(transport — 클라이언트와 서버가 물리적으로 어떻게 메시지를 주고받는가)이다. MCP는 크게 두 가지를 제공한다.

• stdio: 서버가 클라이언트의 자식 프로세스로 같은 머신에서 뜨고, 표준입출력(stdin/stdout)으로 메시지를 주고받는다. 네트워크가 끼지 않는다.
• HTTP / SSE / Streamable HTTP: 서버가 네트워크 너머에 있고, 클라이언트가 HTTP 요청으로 원격 서버와 통신한다.

두 방식의 구조를 각각 살펴보면 이렇다.

로컬 stdio — 같은 머신에서 자식 프로세스로

원격 HTTP — 네트워크 너머의 서버

stdio는 모든 화살표가 같은 박스 안에서 순환한다. HTTP는 MCP 서버가 원격에 있어 빌드 대상인 project_dir에 닿지 못한다 — 끊어진 점선이 원격 배치의 핵심 미스매치다.

stdio: 자식 프로세스로 태어나는 서버

stdio 방식을 이해하는 핵심은 "서버가 독립 데몬이 아니라 클라이언트의 자식 프로세스"라는 점이다. 어시스턴트가 MCP 서버를 직접 subprocess로 띄우고, 그 프로세스의 stdin으로 요청을 보내며, stdout으로 응답을 받는다.

모든 화살표가 같은 박스 안에서 순환한다. 네트워크 구간이 전혀 없고, 서버가 호출하는 appbuild와 그 빌드가 읽는 project_dir이 모두 같은 머신에 있어 경로와 디바이스가 자연스럽게 맞아떨어진다.

remote HTTP: 네트워크 너머의 서버

원격 HTTP 방식에서는 서버가 별도 머신에서 독립 실행된다. 클라이언트는 인증 토큰을 실어 HTTP 요청을 보낸다. 겉으로는 멀쩡해 보이지만, 도구가 손댈 수 있는 파일시스템이 어디인지를 따져보면 균열이 생긴다.

점선이 핵심이다. 원격 도구가 실행되는 곳은 원격 파일시스템 옆이지, 내 project_dir 옆이 아니다. 빌드 대상인 소스코드와 연결된 디바이스는 여전히 내 머신에 남아, 원격 서버가 뻗은 손이 닿지 않는다.

문제: 빌드는 대체 어느 박스에서 일어나야 하나

우리 도구의 정체를 다시 보자. appbuild 같은 로컬 바이너리이고, project_dir이라는 로컬 파일을 입력으로 받으며, 결과물을 만들고 로컬에 연결된 디바이스를 다룬다. 즉 도구가 손대는 대상이 전부 이 머신 안에 있다.

여기서 "서버를 원격에 둘까?"라는 발상이 왜 함정인지 드러난다. 서버를 원격 박스에 올리면, 도구 실행 요청을 받아 실제로 appbuild를 실행하는 주체는 그 원격 박스가 된다. 그런데 빌드 대상인 project_dir은 내 로컬 디스크에 있다. 원격 서버는 그 경로를 찾을 수 없다. 연결된 디바이스도 내 책상 위에 꽂혀 있지 원격 박스에 꽂혀 있지 않다.

핵심 미스매치: 실행 위치 vs 데이터 위치

왜 이게 문제인지를 한 장으로 정리하면 이렇다.

stdio는 실행과 데이터가 같은 곳에 있어 장벽이 없다. remote HTTP는 실행(원격)과 데이터(로컬) 사이에 네트워크 장벽이 놓이고, 이 장벽은 단순한 설정으로 우회할 수 없다 — 데이터 자체를 원격으로 옮기지 않는 한.

두 방식 비교 요약

항목	로컬 stdio	원격 HTTP
서버 위치	내 머신 (자식 프로세스)	원격 서버 (독립 데몬)
통신 방식	stdin / stdout (IPC)	HTTP / SSE / WebSocket
인증 필요 여부	불필요 (같은 OS 계정)	필요 (토큰, OAuth 등)
네트워크 지연	없음 (메모리 수준)	수~수십 ms (연결 끊김 가능)
로컬 파일 접근	✅ 직접 접근	❌ 접근 불가
로컬 디바이스 접근	✅ 직접 접근	❌ 접근 불가
보안 설정 비용	OS 계정 권한으로 충분	방화벽, TLS, 토큰 관리 필요
적합한 use case	데이터·작업이 이 머신에 있을 때	데이터·작업이 원격에 있을 때

결정 기준: 두 가지 질문

어느 쪽을 골라야 하는지는 두 가지 질문으로 정리된다. 데이터가 어디에 있는가, 그리고 작업은 어디서 일어나야 하는가.

대부분의 로컬 개발 시나리오에서는 첫 번째 분기에서 끝난다 — "데이터가 이 머신에 있고, 작업도 이 머신에서 일어난다" → 로컬 stdio. 원격이 옳은 경우는 데이터와 작업이 원래부터 원격에 있을 때다.

효과: 마찰 없는 기본값과 그 경계

개인 개발 머신의 도구를 코딩 어시스턴트에 노출하는 시나리오에서, 로컬 stdio는 가장 마찰이 적은 선택이다. 별도 서버를 띄워 둘 필요도, 토큰을 발급·갱신할 필요도, 방화벽·포트를 고민할 필요도 없다. 어시스턴트가 서버를 자식으로 띄우고, 그 서버가 바로 옆에 있는 appbuild를 호출해 바로 옆에 있는 project_dir을 빌드한다. 도구와 데이터가 있는 곳에 서버가 함께 있다 — 이것이 핵심이다.

원격 HTTP가 틀린 선택이라는 말은 아니다. 그것은 "공유"와 "클라우드"가 진짜 요구사항일 때의 선택이다. 여러 개발자가 같은 도구 집합을 함께 쓰거나, 도구 자체가 클라우드 리소스에 사는 경우라면 원격이 옳다. 다만 그때는 인증·전송 보안·지연이라는 비용을 함께 받아들이는 것이고, 무엇보다 작업과 데이터가 원격에 있다는 전제가 성립해야 한다.

결국 이 글의 답은 단순하다. 로컬 개발 도구를 노출하려면 서버도 로컬에 두고 stdio로 연결하라. 전송 방식은 취향이 아니라, 작업과 데이터의 위치가 강제하는 결론이다.

기본값을 로컬 stdio로 잡으면 불필요한 인증·네트워크 복잡도를 들이지 않고도 개인 개발 도구를 어시스턴트에 즉시 쥐여줄 수 있고, 원격은 정말 공유가 필요할 때만 의식적으로 꺼내 쓰는 카드가 된다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.