표준이 된 지 2년도 안 돼서 나온 회의론
'MCP는 처음부터 나쁜 아이디어였다'라는 제목의 글이 올라왔어요. MCP가 뭐냐면 Model Context Protocol, 2024년 11월에 Anthropic이 공개한 프로토콜인데, AI 모델이 외부 도구나 데이터에 접근하는 방식을 표준화한 거예요. 'AI계의 USB-C'라는 비유로 소개됐죠. 그 뒤로 OpenAI, 구글, 마이크로소프트가 다 채택했고, 2025년 12월에는 리눅스 재단 산하의 에이전틱 AI 재단으로 이관돼서 공식 오픈 표준이 됐어요. 사실상 업계 표준이 된 기술에 대고 '애초에 틀렸다'고 하는 거니까 꽤 센 주장인데요. 그런데 이 회의론이 이 글 하나에서 나온 게 아니라, 2025년 하반기부터 꾸준히 쌓여온 흐름이라는 게 중요해요. 글의 세부 논거는 원문에서 확인하시고, 여기서는 MCP 회의론자들이 공통적으로 드는 근거와 그에 대한 반론을 정리해 볼게요.
MCP가 실제로 하는 일
먼저 구조부터요. MCP는 클라이언트-서버 모델이에요. 서버는 도구(tool), 리소스(resource), 프롬프트(prompt) 세 가지를 노출하고, 클라이언트(Claude Desktop이나 Cursor 같은 호스트 앱)가 이걸 모델에게 보여줘요. 통신은 JSON-RPC 2.0이고, 로컬 프로세스와 표준 입출력으로 연결하는 stdio 방식과 HTTP 방식 두 가지가 있어요. 예를 들어 GitHub MCP 서버를 연결하면 모델이 '이슈 목록 가져오기', 'PR 만들기' 같은 도구를 볼 수 있게 되고, 필요할 때 호출하는 식이에요. 도구를 하나 만들면 어떤 호스트에서든 쓸 수 있다는 게 핵심 약속이었죠.
회의론의 세 가지 근거
첫째, 컨텍스트 낭비예요. MCP 서버를 연결하면 그 서버가 가진 모든 도구의 이름, 설명, 입력 스키마가 매 요청마다 모델의 컨텍스트에 통째로 들어가요. 도구가 5개면 괜찮은데, 서버 몇 개 붙여서 50개, 100개가 되면 사용자가 한마디 하기도 전에 수만 토큰이 소모돼요. 비용도 문제지만 더 큰 문제는 성능이에요. 선택지가 많아질수록 모델이 엉뚱한 도구를 고르는 비율이 올라가거든요. 비유하자면 요리사한테 칼 한 자루 대신 300개짜리 도구 세트를 매번 통째로 보여주는 거예요.
둘째, 보안이에요. 초기 MCP 스펙에는 인증이 아예 없었어요. 2025년 3월과 6월 스펙 개정에서 OAuth 2.1이 들어왔지만, 더 근본적인 문제가 남아요. 도구 설명 자체에 악의적인 지시를 심는 '툴 포이즈닝', 도구가 돌려주는 결과에 명령어를 숨기는 프롬프트 인젝션 같은 거요. 사이먼 윌리슨이 '치명적 삼중주'라고 이름 붙인 조합이 있는데, 비공개 데이터 접근 권한, 신뢰할 수 없는 콘텐츠 노출, 외부 통신 능력 이 세 가지가 한 에이전트에 모이면 데이터 유출은 시간문제라는 거예요. MCP는 이 세 가지를 너무 쉽게 한자리에 모아줘요. 게다가 npm에서 아무 MCP 서버나 받아서 로컬에서 내 권한으로 실행하는 게 지금의 일반적인 사용 패턴이라, 공급망 공격에도 취약하죠.
셋째, 애초에 필요 없었다는 주장이에요. 이게 가장 아픈 지적인데요. 요즘 모델은 코드를 정말 잘 짜요. 그러면 도구 하나하나를 JSON 스키마로 정의해서 보여줄 게 아니라, 그냥 API 문서나 SDK를 주고 코드를 짜게 하면 되지 않냐는 거예요. 실제로 2025년 11월에 Anthropic 스스로 '코드 실행과 MCP'라는 글을 냈는데, 모델이 MCP 도구를 직접 호출하는 대신 도구를 감싼 코드를 작성해서 실행하게 했더니 토큰 사용량이 15만에서 2천으로, 98% 넘게 줄었다는 내용이었어요. 클라우드플레어도 비슷한 시기에 '코드 모드'라는 접근을 내놨고요. 그리고 gh 같은 CLI가 이미 있는데 왜 GitHub MCP 서버가 따로 필요하냐, 에이전트한테 bash만 주면 되는 거 아니냐는 목소리도 계속 나와요. 2025년 10월에 나온 Agent Skills도 이 흐름이에요. 도구 정의를 미리 다 올리는 대신 마크다운 파일로 사용법을 적어두고 필요할 때만 읽게 하는 방식이거든요.
그래도 MCP가 남는 이유
반론도 만만치 않아요. 첫째, 코딩 에이전트가 아닌 호스트에서는 여전히 MCP가 답이에요. 일반 사용자가 쓰는 데스크톱 앱이나 챗봇에서 모델이 bash를 돌리게 할 순 없잖아요. 둘째, 배포와 발견의 문제예요. 'MCP 서버 하나 만들면 어디서든 연결된다'는 약속은 CLI로는 안 되는 거예요. 2025년 9월에 나온 MCP 레지스트리가 이 역할을 하고 있고요. 셋째, 지적된 문제들이 실제로 고쳐지고 있어요. 컨텍스트 낭비는 도구 정의를 미리 다 올리지 않고 필요할 때 검색해서 불러오는 '툴 서치' 방식으로 해결되는 중이고, 인증은 스펙에 들어갔고, 권한 범위를 나누는 논의도 진행 중이에요. 그러니까 '설계가 틀렸다'기보다 '초기 설계가 너무 단순했고 빠르게 보완되는 중'이라는 게 더 정확한 진단일 수 있어요.
한국 개발자에게는
실무 관점에서 정리하면 이래요. 에이전트를 만들고 있다면 MCP 서버를 무작정 많이 붙이지 마세요. 실제로 쓰는 도구만 남기고, 가능하면 툴 서치나 지연 로딩을 지원하는 호스트를 쓰세요. 사내 도구를 연결할 때는 MCP 서버를 새로 만들기 전에 이미 CLI가 있는지, 있다면 스킬 파일 하나로 충분하지 않은지 먼저 물어보세요. 그리고 어떤 방식이든 외부 콘텐츠를 읽는 도구와 외부로 데이터를 보내는 도구를 한 에이전트에 같이 주는 건 정말 신중해야 해요. 앞서 말한 삼중주가 바로 그거니까요. MCP를 배울 가치는 여전히 있어요. 다만 프로토콜 자체보다 '모델에게 도구를 어떻게 노출하는 게 효율적인가'라는 설계 감각이 더 오래가는 지식이에요.
정리하며
MCP는 도구 연결의 표준화라는 문제를 풀었지만, 컨텍스트 비용과 보안이라는 새 문제를 만들었고, 지금 업계는 '스키마 나열' 대신 '코드 실행'과 '지연 로딩'으로 답을 옮겨가는 중이다. 이게 오늘의 한 줄이에요.
여러분은 지금 에이전트에 MCP 서버를 몇 개나 붙여 쓰고 계세요? 그중에 실제로 매일 호출되는 건 몇 개인가요? 그리고 CLI나 코드 실행으로 대체할 수 있는 건 없나요?
🔗 출처: Hacker News