MCP 붙여보고 "장점이 약한데요?" 싶었다면, 그 의심이 맞습니다

MCP 서버를 한 번 만들어보면 비슷한 감상에 도달합니다. 생각보다 장점이 약합니다. 서버 안을 열어보면 결국 원래 API를 그대로 호출하고 있고, 툴 정의는 컨텍스트를 차지하고, 파일이나 긴 글을 넘기려 하면 제약이 줄줄이 나옵니다.

그럴 바에는 API를 만들고 프롬프트에 설명을 적어두는 편이 낫겠다는 결론이 나옵니다. 이 의심은 틀리지 않습니다. 다만 같은 기술을 놓고 평가가 정반대로 갈립니다. 기술의 문제가 아니라 서 있는 자리의 문제입니다.

툴 정의가 컨텍스트를 먹는다는 지적부터

MCP를 붙이면 툴 목록과 설명·입력 스키마가 모델 컨텍스트에 실리고, 서버를 붙일수록 쌓입니다. 비용보다 아픈 쪽은 툴 선택 정확도입니다. 후보가 많아질수록 모델이 엉뚱한 툴을 고르고, 그 재시도가 컨텍스트를 또 먹습니다.

크기를 숫자로 못 박기는 어렵습니다. 툴 하나당 550토큰이라는 글이 있고 1,400토큰이라는 글이 있습니다. 같은 "서버 3개"를 두고 어떤 글은 55,000토큰을, 다른 글은 143,000토큰을 적습니다. 툴 개수도 모델도 측정 방식도 제각각이라 정확한 숫자를 주장할 수는 없습니다. 무시할 수 없는 크기라는 것만 분명합니다.

이 문제를 줄이는 방법은 따로 정리한 적이 있습니다. 결론만 옮기면 도구를 줄이는 게 아니라 지금 필요한 것만 올리는 쪽입니다.

그런데 API로 바꿔도 그 비용은 사라지지 않습니다

"그러면 그냥 API로 하면 되잖아"가 다음 수순입니다. 그런데 툴 스키마가 빠진 자리에 API 명세를 적은 프롬프트가 들어갑니다. 토큰은 사라지는 게 아니라 옮겨갈 뿐입니다.

게다가 손으로 쓴 설명은 코드에서 생성된 스키마보다 쉽게 낡습니다. 파라미터를 하나 추가하고 문서에 반영하지 않으면 모델은 계속 옛날 규격으로 호출합니다.

진짜 차이는 설명서를 누가 관리하는가입니다

나란히 놓고 겹치는 것을 걷어내면 차이는 두 개만 남습니다. 설명서를 누가 관리하는가, 그리고 로컬 접근입니다. 먼저 앞쪽입니다.

API   규격을 어딘가 적어두고 · 클라이언트마다 넣어주고 · 바뀔 때마다 전부 고침
MCP   서버가 코드에서 생성해서 접속할 때 넘겨줌

이 이득의 크기는 붙일 클라이언트 수에 정비례합니다. 클라이언트가 하나면 이득은 정확히 0입니다. 이 글에서 가장 중요한 한 줄입니다.

에디터 하나에서만 쓸 도구를 MCP로 감싸는 것은 그래서 손해입니다. 반대로 여러 AI 클라이언트에 물려야 하고 그중 일부가 남의 제품이라면 계산이 달라집니다.

본체 코드를 건드리지 않고 내부 도구들을 한꺼번에 붙였던 기록이 이 이득을 본 경우입니다.

API가 원리적으로 못 하는 자리가 하나 있습니다

stdio 방식의 MCP 서버는 사용자 컴퓨터에서 자식 프로세스로 실행됩니다. 포트도 URL도 없습니다. "서버"라는 이름과 달리 주소를 찾아가는 관계가 아니라, AI 클라이언트가 프로그램을 직접 띄워 표준입출력으로 붙잡고 있는 관계입니다. 그래서 로컬 파일, 로컬 DB, 사내망 안쪽 자원에 손이 닿습니다.

어딘가에 떠 있는 HTTP 서버는 사용자 노트북 안의 파일에 접근할 방법이 없습니다. 편의 차이가 아니라 능력 차이라서 우회할 설계가 없습니다. 앞서 말한 두 번째 차이가 이것입니다.

반대로 파일과 긴 본문은 MCP의 명확한 약점입니다

5,000자짜리 본문을 툴 인자로 넘기는 일은 API 쪽이 우월합니다. 프로그램끼리라면 변수에 담아 참조만 넘기면 끝납니다. 그런데 LLM은 툴 인자를 한 글자씩 출력해서 만듭니다. 5,000자를 넘기려면 5,000자를 출력 토큰으로 다시 타이핑해야 합니다.

쪽지 한 장으로 "저 방 짐 전부 옮겨주세요"라고 말하는 것과, 물건을 하나씩 손으로 나르는 것의 차이입니다.

게다가 같은 본문에 값을 세 번 치릅니다.

읽을 때 입력 토큰으로 한 번

쓸 때 출력 토큰으로 한 번, 출력은 보통 입력보다 몇 배 비쌉니다

그 뒤로 대화가 이어지는 모든 턴에서 컨텍스트로 계속

JSON 이스케이프까지 겹치면 본문이 길수록 깨집니다. 해법은 본문이 모델을 우회하게 만드는 것입니다. 파일 경로를 넘기거나, 미리 업로드한 뒤 식별자만 넘기거나, 프리사인드 URL을 넘깁니다.

클라우드에 올리는 순간 전제가 뒤집힙니다

여기까지는 로컬 stdio를 전제로 한 이야기입니다. 클라우드에 올리면 이 전제가 무너집니다.

사용자와 같은 파일시스템이 아닙니다. 파일 경로를 넘기던 우회법이 그대로 죽습니다

인증이 새 숙제로 등장합니다. stdio에서는 "내 계정으로 실행된다"는 사실 자체가 인증이었습니다

로컬 자원 접근이라는 두 번째 차이가 사라집니다

다만 무너지는 것은 두 축 중 하나뿐입니다. 사라지는 쪽은 로컬 접근이고, 설명서를 서버가 관리한다는 이득은 원격에서도 그대로 남습니다. 오히려 커집니다. 붙는 클라이언트가 많을수록 이득이 커진다는 규칙은 그대로인데, 원격 서버는 애초에 클라이언트 수를 통제할 수 없는 자리에 놓이기 때문입니다.

그래서 원격으로 가면 MCP를 쓰는 이유가 로컬 접근에서 배포로 갈아탑니다. 큰 서비스들이 원격 MCP 서버를 내놓는 이유가 정확히 이것입니다.

MCP를 다룬 글들이 서로 안 맞는 이유가 대체로 여기입니다. 로컬 stdio를 놓고 말하는 사람과 원격 서버를 놓고 말하는 사람이 같은 단어로 다른 것을 이야기합니다. 어느 쪽 전제인지 확인하지 않으면 비교 자체가 성립하지 않습니다.

판단 기준은 한 줄로 줄어듭니다

질문은 "MCP가 좋은가"가 아니라 "내가 통제하지 않는 쪽이 있는가"입니다.

만들기 전에 짚어볼 항목은 다섯 개입니다.

붙일 AI 클라이언트가 몇 개인지 셉니다. 하나면 MCP의 관리 이득은 0입니다

접근할 자원이 사용자 컴퓨터 안에 있는지 확인합니다. 있으면 API로는 방법이 없습니다

주고받을 데이터에 긴 본문이나 파일이 섞이는지 봅니다. 섞이면 우회 설계부터 정합니다

로컬로 갈지 원격으로 갈지 먼저 정합니다

이미 나와 있는 서버가 있는지 먼저 찾아봅니다

만들기로 정했다면 스펙 버전부터 봅니다

MCP는 반년이면 낡습니다. 이 글은 2026-07-28 스펙을 기준으로 합니다.

Roots·Sampling·Logging이 SEP-2577로 deprecated 됐습니다. 폐기가 아니라 deprecated이고 12개월 호환 창이 보장돼서 지금 돌아가는 구현이 당장 깨지지는 않습니다

대체 경로가 함께 정리됐습니다. Roots는 툴 파라미터·리소스 URI·서버 설정으로, Sampling은 LLM 제공자 API를 직접 붙이는 쪽으로, Logging은 stdio의 stderr와 표준 관측 도구로 옮깁니다

레거시 HTTP+SSE 전송도 deprecated 됐고 Streamable HTTP로 이전합니다

서버가 먼저 거는 호출은 Multi Round-Trip Requests(SEP-2322)가 받습니다

이미 만들어둔 것을 급히 뜯어고칠 필요는 없습니다. 새로 만드는 구현에 deprecated 기능을 채택하지 않는 것으로 충분합니다.

그리고 대부분은 만드는 쪽이 아닙니다

논쟁은 늘 "만들까 말까"로 벌어집니다. 그런데 MCP 사용자의 대다수는 남이 만든 것을 쓰는 쪽입니다. 만드는 비용을 치르지 않으니 손익 계산이 다릅니다.

앞에서 말한 큰 서비스들이 그 경우입니다. 통제하지 못하는 사용자가 수백만 명 있고, 그들이 각자 다른 AI 클라이언트를 쓰고, 그 코드를 고칠 방법이 없습니다.

MCP는 아키텍처가 아니라 배포 채널에 가깝습니다. 이미 있는 API를 여러 AI 클라이언트에 꽂기 위한 규격입니다. 그래서 "MCP가 좋으냐 API가 좋으냐"에는 답이 나오지 않고, 답이 나오는 질문은 "나에게 배포 문제가 있는가"입니다.

MCP는 좋은 기술이지만 모두에게 필요한 기술은 아닙니다. 붙여보고 안 맞는다고 느꼈다면 이해를 못 한 것이 아니라, 필요 없는 자리에 서 있는 것일 수 있습니다.