MCP Protocol 2025-11-25 기준
Claude Code 최신 버전 기준
MCP 원격 서버, 추가할수록 느려지는 이유 — 토큰 수치 직접 확인했습니다
MCP 원격 서버는 로컬 설치 없이 URL 하나만 넣으면 된다는 게 핵심 장점입니다. 근데 막상 여러 개 연결해보면 응답이 느려지고, 어느 순간부터 Claude가 엉뚱한 답을 내놓기 시작합니다. 이 글에서는 그 이유를 토큰 수치로 직접 확인합니다.
컨텍스트 즉시 소비
비용 증가 추정
툴 스키마 토큰 수
MCP 원격 서버, 편리한 건 맞는데 비용이 따라옵니다
MCP 원격 서버의 핵심 장점은 단순합니다. 로컬에 서버 프로세스를 띄울 필요 없이, Claude Code에 URL 하나만 등록하면 바로 외부 도구를 쓸 수 있습니다. 예전에는 GitHub나 Sentry 같은 서비스를 연동하려면 로컬에 MCP 서버를 직접 설치하고, 버전 관리까지 직접 해야 했습니다. 원격 서버는 이 관리 부담을 벤더 쪽으로 넘겨버립니다.
실제로 Anthropic이 2025년 6월 Claude Code에 원격 MCP 지원을 공식 추가하면서, Sentry·GitHub·Linear 등 주요 서비스들이 자체 원격 MCP 서버를 내놓기 시작했습니다. (출처: Anthropic 공식 발표, 2025.06.22)
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다. “편리하다”는 말 뒤에 구체적인 토큰 비용이 따라붙는다는 건 대부분의 가이드가 언급하지 않습니다. 원격 MCP를 추가하는 순간 비용 구조가 바뀌고, 많이 연결할수록 정확도가 떨어질 수 있다는 게 Anthropic 파트너사 CTO가 직접 지적한 내용입니다. (출처: infoq.com, 2025.06.22)
CTO Robert Matsukoa의 표현을 빌리면, 원격 MCP는 “AI 도구 통합의 경제학을 바꾼다”는 말이 있는데 — 이건 좋은 방향으로만 바뀐다는 뜻이 아닙니다. 외부 소스에서 끌어오는 컨텍스트가 커질수록 비용이 25~30% 증가한다는 실측 추정이 함께 나옵니다. (출처: infoq.com, 2025.06.22)
URL 하나로 연결되는 구조 — stdio와 실제로 다른 점
MCP는 클라이언트-서버 구조로 작동합니다. Claude Code가 클라이언트고, MCP 서버가 도구·데이터 소스를 노출합니다. 연결 방식(트랜스포트)은 크게 세 가지입니다.
| 트랜스포트 | 작동 방식 | 현재 상태 |
|---|---|---|
| stdio | 로컬에서 자식 프로세스로 실행, 표준 입출력으로 통신 | ✅ 안정 — 로컬 전용 |
| Streamable HTTP | HTTP 요청·응답으로 통신, 원격 서버 표준 | ✅ 현행 표준 (Protocol 2025-11-25) |
| SSE | Server-Sent Events 기반 지속 연결 | ❌ Deprecated (2026년 초) |
로컬 stdio 서버는 Claude Code가 직접 프로세스를 띄우고 세션이 끝나면 같이 종료됩니다. 원격 서버는 이 과정이 없습니다. URL만 등록하면 Claude Code가 HTTP로 직접 붙습니다. 설정 명령도 단 한 줄입니다.
이게 로컬 stdio 방식과 근본적으로 다른 이유는 인증 흐름에도 있습니다. 원격 HTTP 서버는 OAuth 2.0을 통해 터미널 안에서 바로 인증할 수 있고, 토큰은 로컬에 저장됩니다. 매번 API 키를 환경변수에 심을 필요가 없습니다.
SSE는 이미 deprecated — Streamable HTTP로 넘어온 이유
2026년 초 기준으로 원격 MCP 서버의 공식 트랜스포트는 Streamable HTTP(Protocol 2025-11-25)입니다. SSE(Server-Sent Events)는 과거 원격 MCP의 표준이었지만, 현재는 deprecated 상태입니다. (출처: systemprompt.io MCP 가이드, 2026.02.03 / docnotes.net, 2026.01.13)
💡 많은 기존 가이드가 SSE 방식으로 작성돼 있습니다. 2024년과 2025년 상반기 글들은 대부분 --transport sse 명령어를 기준으로 씁니다. 지금 그대로 따라 하면 “legacy 옵션”을 쓰는 셈입니다.
Streamable HTTP로 전환이 이뤄진 배경은 간단합니다. SSE는 지속 연결 방식이라 서버 측에서 상태를 계속 관리해야 했습니다. 수평 확장(horizontal scaling)이 어려웠고, 로드밸런서를 끼우면 세션이 끊기는 문제가 반복됐습니다. Streamable HTTP는 HTTP 표준 위에서 작동하기 때문에 클라우드 인프라에 그대로 올릴 수 있습니다.
Claude Desktop은 아직 Streamable HTTP를 지원하지 않습니다
여기서 실제로 걸리는 지점이 있습니다. Claude Desktop(데스크톱 앱)은 2026년 2월 기준으로 Streamable HTTP를 지원하지 않습니다. stdio 방식만 안정적으로 작동하고, 원격 서버를 연결하려면 mcp-remote라는 프록시를 중간에 끼워야 합니다. (출처: GitHub modelcontextprotocol Discussions #1940, 2026.02.15)
{
“mcpServers”: {
“my-remote-server”: {
“command”: “npx”,
“args”: [“mcp-remote”, “http://your-server.com/mcp”]
}
}
}
반면 claude.ai 웹 인터페이스와 Claude Code는 Streamable HTTP를 기본으로 사용합니다. 같은 “Claude”라도 어떤 클라이언트를 쓰느냐에 따라 연결 방식이 달라집니다. 이 부분을 모르면 Claude Code에서는 되는 서버가 Claude Desktop에서 연결이 안 되는 상황을 만납니다.
연결할수록 컨텍스트가 줄어드는 실측 수치
원격 MCP 서버를 연결하면 편리해진다는 게 통념입니다. 근데 실제로 Claude Code에서 /context 명령을 실행해보면 다른 그림이 나옵니다.
💡 MCP를 연결하기 전부터 컨텍스트 창 절반이 차 있다는 걸, 직접 측정하기 전까지는 모릅니다. Claude Code의 /context 명령이 보여주는 실측 수치가 이 사실을 드러냅니다.
아래는 Claude Sonnet 4.5 기준(200K 컨텍스트), MCP 여러 개 활성화 상태에서 실측한 수치입니다. (출처: kavasimihaly.github.io 실측 데이터, 2025.11.23)
| 항목 | 토큰 수 | 비율 |
|---|---|---|
| 시스템 프롬프트 | 3,000 | 1.5% |
| 시스템 툴 | 14,800 | 7.4% |
| MCP 툴 정의 | 32,600 | 16.3% |
| 메모리 파일(CLAUDE.md 등) | 5,400 | 2.7% |
| 자동 압축 버퍼 | 45,000 | 22.5% |
| 실제 사용 가능 공간 | 약 99,000 | 49.3% |
대화를 시작하기도 전에 컨텍스트의 절반이 사라집니다. MCP 툴 정의만으로 16.3%가 고정 소비됩니다.
GitHub MCP 하나가 55,000 토큰을 씁니다
특히 대형 MCP 서버는 문제가 됩니다. GitHub MCP 서버 하나가 툴 스키마만으로 55,000 토큰을 컨텍스트에 집어넣는다는 수치가 LinkedIn에서 실측 공개됐습니다. (출처: Brandon Rich, LinkedIn, 2026.03.12) 55,000 토큰은 200K 컨텍스트의 27.5%입니다. GitHub MCP 하나만 연결해도 전체의 4분의 1 이상이 툴 정의로 채워집니다.
⚠️ 정확도 저하도 따라옵니다. MCPGAUGE 연구에 따르면 MCP 통합은 6개 LLM 평균으로 정확도를 9.5% 낮추고, 입력 토큰을 최대 236.5배까지 늘립니다. (출처: arXiv 2603.05637, 2026.03.05) 토큰이 늘어나는 만큼 Claude의 추론 정확도는 떨어질 수 있습니다.
Claude Code는 MCP 툴 수가 전체 컨텍스트의 10%를 초과하면 자동으로 “툴 검색” 모드로 전환합니다. 전체 툴을 미리 로딩하는 대신, 필요할 때 검색 인덱스에서 찾아 로딩하는 방식입니다. 하지만 툴 이름이 fetch, update처럼 모호하면 검색 자체가 틀려집니다. (출처: systemprompt.io, 2026.02.03)
Claude Desktop과 Claude Code, 원격 MCP 지원이 다릅니다
MCP 원격 서버를 쓸 때 가장 먼저 막히는 지점이 여기입니다. “Claude”라는 이름 아래 여러 클라이언트가 존재하는데, 원격 MCP 지원 수준이 각각 다릅니다.
| 클라이언트 | Streamable HTTP | SSE | OAuth |
|---|---|---|---|
| Claude Code (CLI) | ✅ 기본 | 레거시 | ✅ 지원 |
| claude.ai (웹) | ✅ 기본 | 레거시 | ✅ 지원 |
| Claude Desktop (앱) | ❌ 미지원 | 가능 | mcp-remote 우회 필요 |
Claude Desktop에서 원격 MCP를 쓰려면 npx mcp-remote를 중간 프록시로 끼우는 방식이 현재 가장 안정적입니다. 이 때 claude_desktop_config.json에서 command를 npx로 설정하고 args에 mcp-remote와 서버 URL을 넣습니다. (출처: GitHub modelcontextprotocol Discussions #1940, 2026.02.15)
claude.ai가 OAuth 클라이언트 역할을 합니다
웹 인터페이스(claude.ai)에서 원격 MCP 서버에 OAuth를 붙이면, 실제로 OAuth 클라이언트 역할을 하는 건 사용자의 브라우저가 아니라 claude.ai 백엔드입니다. 즉, 서버 쪽에서 DCR(Dynamic Client Registration, RFC 7591)을 지원해야 claude.ai가 스스로 클라이언트를 등록하고 OAuth 흐름을 처리할 수 있습니다. (출처: docnotes.net, 2026.01.13) 공식 MCP 문서에 빠져 있는 이 부분 때문에 “OAuth 설정 다 했는데 브라우저에서 빈 화면만 뜬다”는 상황이 생깁니다.
원격 MCP 서버를 제대로 쓰는 범위와 쓰지 말아야 할 상황
솔직히 말하면, MCP 원격 서버가 모든 워크플로에 맞지는 않습니다. 2026년 3월 기준 MCP를 둘러싼 논쟁이 뜨거운 이유가 있습니다. Garry Tan(YC 대표)이 “MCP sucks”라고 X에 올리고, Perplexity CTO가 일부 워크플로를 일반 API로 전환한 것도 이 맥락입니다. (출처: Medium, Micheal Lanham, 2026.03.16)
💡 MCP를 쓰면 좋다는 곳과 CLI나 직접 API가 더 낫다는 곳을 같이 놓고 비교했더니 이렇게 구분됐습니다. 두 관점을 교차해보면 “언제 MCP를 선택해야 하는가”의 기준이 보입니다.
원격 MCP가 실제로 유리한 상황
원격 MCP가 의미 있는 영역은 직접 통제하지 않는 외부 시스템과 Claude를 연결할 때입니다. Sentry 에러 목록을 가져와서 바로 수정하거나, Linear 이슈를 컨텍스트로 읽으면서 코드를 작성하는 흐름이 대표적입니다. 이때는 Claude가 여러 데이터 소스를 넘나들며 맥락을 유지해야 하기 때문에, CLI를 오가며 복사-붙여넣기 하는 방식보다 MCP가 훨씬 효율적입니다. (출처: infoq.com, 2025.06.22)
원격 MCP를 쓰지 말아야 할 상황
반면 이미 CLI나 표준 API가 잘 작동하는 곳에서는 MCP가 오히려 과잉입니다. 인프라의 양쪽 모두를 직접 통제하는 상황이라면, MCP 없이 직접 API를 호출하는 게 더 빠르고 저렴합니다. 같은 작업을 GitHub CLI로 하면 55,000 토큰이 들지 않습니다. 툴 스키마 로딩이 없으니 컨텍스트 낭비도 없습니다. (출처: Brandon Rich, LinkedIn, 2026.03.12)
지금 당장 실천할 수 있는 토큰 절약 방법
아래 세 가지만 적용해도 컨텍스트 기본 점유율을 크게 낮출 수 있습니다.
Claude Code 설정 패널에서 MCP를 토글로 개별 활성화·비활성화할 수 있습니다. 항상 켜두지 않으면 해당 서버의 툴 정의가 컨텍스트에 로딩되지 않습니다.
20~30개 툴을 가진 서버 하나보다, 3~5개 툴에 집중한 서버 여러 개가 컨텍스트 관리에 유리합니다. 서버 범위가 작을수록 툴 검색 정확도도 높아집니다.
Claude Code 내에서
/context를 실행하면 항목별 토큰 사용량이 나옵니다. 기본 점유율이 30%를 넘으면 MCP 구성을 다시 검토할 타이밍입니다.MCP 원격 서버를 처음 시작한다면, 하나씩 추가하면서 매번 /context로 변화를 확인하는 게 가장 현실적인 접근입니다. 늘어난 편의성이 토큰 비용보다 크다는 걸 직접 확인한 다음에 유지하면 됩니다.
Q&A — 자주 막히는 지점 5가지
마치며
MCP 원격 서버는 분명히 쓸 만합니다. URL 하나로 외부 서비스와 Claude를 연결하는 구조는 진짜 편리합니다. 문제는 “연결하면 끝”이라고 생각할 때 발생합니다.
실제로는 연결하는 순간 컨텍스트가 줄어들기 시작하고, 많이 연결할수록 정확도가 떨어질 수 있습니다. SSE에서 Streamable HTTP로 넘어온 것, Claude Desktop과 Claude Code의 지원 차이, OAuth 설정 때 DCR이 빠지면 조용히 실패하는 것까지 — 이 부분들이 대부분의 가이드에 빠져 있습니다.
처음 시작하면 하나부터, /context로 매번 확인하면서, 정말 필요할 때만 켜두는 게 결국 가장 효율적인 방식이라고 생각합니다.
본 포스팅 참고 자료
- MCP 공식 문서 — What is MCP? (modelcontextprotocol.io)
- InfoQ — Claude Code Gains Support for Remote MCP Servers (2025.06.22)
- Docnotes — Claude Desktop Compatible MCP Server, OAuth 구현 가이드 (2026.01.13)
- MCP 컨텍스트 창 실측 데이터 — The Hidden Cost of MCPs (2025.11.23)
- Medium — MCP Isn’t Dead. But It’s Not the Default Answer Anymore (2026.03.16)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. MCP 프로토콜은 빠르게 업데이트되는 오픈 표준이며, 본문의 내용은 2026.03.26 기준 공식 자료를 토대로 작성됐습니다. 최신 내용은 공식 MCP 문서(modelcontextprotocol.io)에서 확인하시기 바랍니다.
댓글 남기기