핵심 요약
- MCP(Model Context Protocol) 서버가 각자 다수의 도구와 스키마를 제공하면서 에이전트의 컨텍스트 창이 비대해지는 문제가 발생하고 있음
- 코드 실행과 API 직접 호출 능력이 발전한 최신 에이전트 환경에서는 대부분의 MCP 서버가 더 이상 필수적이지 않다는 비판이 제기됨
- 대안으로 이미 표준 인터페이스를 갖춘 HTTP API와 CLI로 MCP 서버를 대체하자는 제안이 제시됨
AI 에이전트 생태계에서 도구 호출 표준으로 자리 잡았던 MCP가 코드 실행·API 직접 호출 능력의 성장에 따라 효용성을 재검토해야 한다는 분석 기사
목차
2026년 9월, StepFun이 공개한 Step 5 Preview는 단일 에이전트 액션에서 약 950회의 웹 페치를 조율한 것으로 기록됐다. 600B 파라미터의 희소 MoE 구조, 92개 Transformer 레이어의 깊고 좁은 설계다. 이 사례가 시사하는 건 단순한 성능 수치가 아니다. 에이전트가 도구와 API를 직접 다루는 능력이 한 단계 도약했다는 점이다. 이런 흐름 속에서 오래도록 에이전트 도구 통합의 표준처럼 불리던 MCP(Model Context Protocol)에 대한 MCP 비판이 다시 수면 위로 떠올랐다.
MCP 비판의 첫 번째 쟁점: 컨텍스트 비대화
MCP 비판의 중심에 있는 첫 번째 쟁점은 컨텍스트 비대화다. MCP 서버 하나가 수십 개의 도구와 그에 맞는 스키마를 정의하고, 에이전트는 이를 매번 시스템 프롬프트에 싣는다. 서버가 늘어나면 컨텍스트 창이 기하급수적으로 부풀고, 토큰 비용과 응답 지연이 함께 올라간다.
실무에서 체감하는 손실은 더 직접적이다. 모델이 “쓸 수 있는 도구가 너무 많은” 상태에서 잘못된 도구를 선택하는 비율이 높아지고, 그게 다시 재시도와 비용 폭증으로 이어진다. 필자는 이 지점이 가장 실질적인 문제라고 본다. 도구의 “표준화”라는 명분 아래, 각 MCP 서버가 자기만의 스키마를 들고 등장한 결과, 에이전트 개발자는 통합 작업보다 컨텍스트 관리에 시간을 더 쓰고 있다.
MCP 비판의 두 번째 축: 직접 호출의 현실화
두 번째 비판은 더 근본적이다. 코드 실행과 API 직접 호출 능력이 성장하면서, MCP라는 중개 계층이 오히려 병목이 됐다는 주장이다. 오늘날 에이전트는 셸을 띄우고 curl 한 줄로 HTTP API를 두드리고, jq로 응답을 가공한 뒤 다음 단계로 넘기는 게 가능하다. Step 5 Preview의 950회 웹 페치 사례는 이런 직접 호출 패턴이 대규모 워크로드에서도 현실화됐음을 보여준다. MCP가 약속했던 “도구 호출의 표준”이, 사실은 표준 인터페이스를 갖춘 HTTP API·CLI 호출을 한 번 더 감싼 형태였다는 시각이 힘을 얻는 이유다.
대안: HTTP API와 CLI로 도구 노출 방식을 전환
MCP 비판론자들이 제시하는 대안은 의외로 평범하다. 도구를 HTTP API와 CLI로 노출하고, 에이전트는 코드 실행을 통해 직접 호출하라는 것이다. 인증은 OAuth/API 키로 처리하고, 도구 정의는 그때그때 함수 시그니처 수준으로만 컨텍스트에 실으면 된다. 이렇게 하면 컨텍스트 점유를 대폭 줄이면서도, 도구 진화를 MCP 스펙 변경에 묶이지 않고 자유롭게 가져갈 수 있다.
| 항목 | MCP 서버 | HTTP API 직접 호출 | CLI 직접 호출 |
|---|---|---|---|
| 컨텍스트 비용 | 높음 (도구·스키마 상시 로드) | 낮음 (필요 시점에만 정의) | 낮음 (셸 호출) |
| 표준화 수준 | MCP 스펙 종속 | OpenAPI 등 성숙 표준 | POSIX/셸 규약 |
| 다단계 워크플로 | 강점 | 보통 (직접 구현) | 보통 (직접 구현) |
| 인증 | MCP 내부 처리 | OAuth·API 키 | 환경 변수·키파일 |
| 유지보수 | 서버 업데이트 전파 필요 | 엔드포인트 단위 독립 | 바이너리 단위 독립 |
표에서 보듯 MCP는 “여러 도구를 한 묶음으로 노출”하는 데서 강점이 있다. 다만 그 비용을 정당화할 만큼 표준화 우위가 크지 않다는 게 비판의 핵심이다.
MCP 비판 이후 균형 잡힌 시각: MCP가 여전히 유효한 영역
MCP가 무용하다는 주장은 성급하다. 표준화되지 않은 사내 시스템을 에이전트에 한 번에 묶어 노출해야 하는 경우, MCP의 도구 번들링은 여전히 유효하다. 다만 일반적인 SaaS API·CLI·웹 호출이 주를 이루는 워크로드라면, 굳이 MCP를 거치지 않는 게 이득이다. 결국 답은 단일이 아니라 워크로드별 혼합 적용이다.
MCP 비판 이후의 실용적 선택
2026년 9월 시점에서, 에이전트 도구 통합은 “한 가지 프로토콜로 정답을 통일”하는 단계에서 벗어났다. 도구 정의의 컨텍스트 비용을 누가 부담하느냐, 표준화 요구가 어느 정도냐, 인증·권한을 누가 관리하느냐에 따라 선택이 갈린다. MCP 비판은 이 선택을 다시 열어뒀다는 데 의의가 있다.
실무 적용 포인트
- 도구 목록이 5개를 넘는 MCP 서버는 우선 HTTP API 직접 호출로 전환을 검토한다.
- 컨텍스트 비용 모니터링: 도구 정의로 인한 입력 토큰 비율을 주 단위로 측정한다.
- 워크플로가 단순 호출 1~2단계로 끝나면 MCP의 중개 계층을 거치지 않는 편이 낫다.
- 레거시 사내 시스템은 MCP로 묶고, 외부 SaaS는 직접 호출로 분리하는 혼합 전략을 기본값으로 둔다.
지금 바로 해볼 것
- 현재 운영 중인 MCP 서버에서 도구 정의를 추출해 컨텍스트 점유 토큰 수를 측정한다.
- 같은 기능을 HTTP API와 OpenAPI 명세로 다시 정의해, 에이전트가 셸에서 직접 호출하는 코드를 작성해 본다.
- 인증 흐름을 OAuth/API 키 방식으로 단순화하고, MCP 내부 인증 의존도를 낮춘다.
- 도구가 늘어날 때 컨텍스트 비용이 선형으로 증가하는지 로그로 확인한다.
- 사내 표준이 없는 레거시 시스템만 MCP로 묶고, 나머지는 직접 호출로 분리한다.
자주 묻는 질문
MCP를 당장 걷어내야 하나요?
아닙니다. 사내 레거시 도구를 한꺼번에 묶어야 할 때 MCP는 여전히 효율적입니다. 새로 만드는 통합은 HTTP API·CLI 기반으로 시작하는 것이 합리적입니다.
컨텍스트 비대화가 실제 비용에 얼마나 영향을 주나요?
도구 정의를 매 요청마다 실어 보낸다면, 입력 토큰의 20~40%가 도구 메타데이터로 소모되는 사례가 보고되고 있습니다. 모델과 요금제에 따라 월 수백만 원 단위 차이가 날 수 있습니다.
HTTP API로 직접 호출할 때의 단점은 무엇인가요?
에이전트가 인증·재시도·에러 처리를 직접 다뤄야 합니다. 멀티스텝 워크플로가 길어질수록 코드 복잡도가 빠르게 올라가므로, 도구 수가 적고 호출 빈도가 높은 경우에 가장 효과적입니다.
Step 5 Preview의 950회 웹 페치는 왜 중요한가요?
에이전트가 인간의 개입 없이 대규모 도구 호출을 안정적으로 조율할 수 있다는 증거이기 때문입니다. 이런 능력이 보편화되면, 도구 통합의 병목은 “어떤 프로토콜”이 아니라 “어떤 코드를 짜느냐”로 이동합니다.
참고 원문
이 기사는 다음 원문을 확인해 작성했습니다: geeknews — MCP는 처음부터 잘못된 아이디어였을까?
전문가 코멘트(AI)
ML 시스템 엔지니어
MCP의 컨텍스트 비대화 비판은 실측 가능한 실무 문제이나, ‘코드 실행으로 대체’는 모델 능력에 대한 과도한 의존을 숨기고 있다
도구 정의가 시스템 프롬프트를 상시 점유하며 입력 토큰 비용과 도구 선택 오류율을 함께 끌어올리는 문제는 에이전트 운영 현장에서 실제로 관측되는 구조적 병목이다. 컨텍스트를 절약하려는 동기 자체는 타당하며, 도구 정의를 필요 시점에 동적으로 로드하거나 함수 시그니처 수준으로 축약하는 접근은 프롬프트 캐싱·RAG 기반 도구 검색 등과 결합하면 즉시 실용적인 개선을 만든다. 다만 코드 실행 기반 직접 호출은 모델의 계획·오류 복구 능력이 충분히 높다는 전제 위에 서 있고, 소형 모델이나 저비용 배포 환경에서는 오히려 MCP의 스키마 강제가 오류율을 낮추는 가드레일 역할을 한다. 또한 직접 호출 방식은 인증·재시도·샌드박스 격리를 에이전트 코드가 전부 떠안게 되므로, 단순 호출 1~2단계가 아닌 멀티스텝 워크로드에서는 유지보수 비용이 역전될 수 있다. 장기적으로는 프로토콜의 존폐보다 ‘도구 정의의 지연 로딩과 점진적 디스커버리’를 스펙 수준에서 어떻게 표준화하느냐가 관건이 될 것이다.
API 플랫폼 아키텍트
성숙한 HTTP API와 CLI를 도구 인터페이스로 돌아가자는 제안은 실용적이지만, MCP가 해결하려던 상호운용성·권한 위임 문제를 그대로 각 조직에 떠넘긴다
OpenAPI와 POSIX 계열 규약이라는 이미 검증된 인터페이스 위에 에이전트를 얹는 발상은 재발명의 낭비를 줄인다는 점에서 매우 건전하다. 도구 제공자 입장에서도 MCP 서버를 별도 운영할 필요 없이 기존 API 문서화 수준만으로 에이전트 접근성을 확보할 수 있어 생태계 진입 장벽이 낮아진다. 그러나 MCP가 표준화하려던 핵심 가치 — 도구 디스커버리, 세션 관리, 위임된 권한(스코프 기반 인증)의 일관된 모델 — 는 직접 호출 방식에서 서비스마다 제각각 재구현되어야 하며, 이는 에이전트가 수십 개 SaaS를 넘나드는 실제 워크로드에서 통합 비용을 다시 폭증시킬 수 있다. 보안 측면에서도 에이전트가 셸과 범용 네트워크 접근 권한을 가진다는 것은 프롬프트 인젝션 시 공격 표면이 MCP의 샌드박스보다 훨씬 넓어진다는 의미다. 결국 이 대안은 ‘레거시 통합엔 MCP, 성숙 API엔 직접 호출’이라는 워크로드별 혼합이 현실적 정착점이 될 가능성이 높으며, 단일 표준의 몰락이 아니라 표준의 역할 축소로 읽는 것이 정확하다.
비판적 분석가
지금이라는 타이밍 자체가 수상하다 — MCP 비붕은 기술 논쟁의 탈을 쓴 인프라 주도권 다툼으로 읽힌다
공식 내러티브는 ‘기술이 발전했으니 중개 계층이 불필요해졌다’는 깔끔한 진화론이지만, 이면을 들여다보면 그림이 달라진다. MCP는 애초에 특정 모델 제공사의 생태계 확장 전략에서 태어났고, 컨텍스트 창을 자사 클라이언트가 통제하는 구조는 플랫폼 사업자에게 막대한 영향력을 준다. 도구 정의가 컨텍스트를 점유한다는 비판 자체는 사실이지만, 그 비용을 ‘토큰 과금’으로 청구하는 이해관계자와 그 해법으로 코드 실행 샌드박스를 파는 이해관계자가 겹쳐 있다는 점이 흥미롭다. 대형 API 제공자들이 ‘코드 실행으로 직접 호출하세요’를 밀면, 도구 생태계의 진입점이 개방형 프로토콜에서 자사 인프라로 이동할 가능성이 있다. 즉 이 논쟁은 MCP의 존폐가 아니라, 에이전트가 도구에 접근하는 관문을 누가 소유하느냐의 문제로 읽힌다. 독자가 스스로 물어야 할 것은 — ‘도구 정의의 토큰 비용’을 강조하는 측이 정작 컨텍스트 캐싱 같은 저렴한 해법 대신 왜 하필 아키텍처 전면 교체를 주장하는가, 그 대체안의 수혜자는 누구인가, 이다.
물밑 시나리오
- 컨텍스트 비대화 프레임은 사실상 오래된 문제인데 ‘950회 웹 페치’ 같은 화려한 모델 출시 데모와 맞물려 재점화된 것으로 보인다 — 데모의 화제성을 얻는 신모델 제공사와 프로토콜 종속을 약화시켜 자사 API 직접 사용을 늘리고 싶은 플랫폼 사업자의 이해가 일치하는 타이밍이다.
- MCP를 걷어내라는 압박이 커질수록, 오히려 MCP 진영이 ‘공식 코드 실행 런타임’이나 ‘동적 도구 로딩 유료 기능’으로 재무장할 여지가 있으며, 비판 논쟁 자체가 유료 업그레이드 수요를 만드는 시장 조성 장치로 기능할 가능성이 있다.