Was MCP Always a Bad Idea?
"MCP 는 처음부터 나쁜 아이디어였다" 는 글을 읽었다. 제목은 과장이고, 실제 내용은 모델이 좋아졌다는 이야기다.
- Date
- Tags
- #mcp#ai#agent#http
Input
원문이 하는 말
Why MCP Was Always a Bad Idea 요약. 주장은 넷이다.
- 컨텍스트가 터진다. MCP 서버를 붙일수록 도구 스키마가 쌓인다. 쓰지 않는 도구도 항상 자리를 차지한다.
- 모델이 그 설계를 넘어섰다. 이제 코드를 실행하고, 큰 코드베이스를 읽고, 알아서 움직인다.
- API 를 스스로 찾는다.
--help를 쳐서 CLI 사용법을 알아낸다. 문서 있는 API 를 굳이 감쌀 이유가 없다. - 대안이 이미 있다. 문서화된 HTTP API, 표준 콘텐츠 협상, 성숙한 인증.
결론은 "MCP 를 end-of-life 하고 공통 프로토콜로 표준화하자"다.
제목은 과장이다
읽고 나면 남는 건 "MCP 가 틀렸다"가 아니라 "전제가 바뀌었다" 다.
MCP 가 나왔을 때 모델은 코드 실행도, 터미널도, 긴 컨텍스트도 없었다. 그래서 "도구를 미리 정의해서 떠먹여 주는" 방식이 맞았다. 지금은 그 전제가 사라졌을 뿐이다. 틀린 설계가 아니라 유효기간이 있던 설계다.
내가 실제로 겪은 것
모델이 좋아지는 동안 나는 반대로 일이 늘었다.
- MCP 설정을 계속 추가하고
- 늘어난 설정을 관리하려고 MintMCP, Composio 같은 도구를 또 붙이고
- 그 도구를 관리하는 일이 다시 생겼다
관리 도구를 관리하는 상태가 되면 대개 층이 하나 남아도는 것이다. 원문이 "이런 해결책은 더 깊은 문제를 잠깐 가린 것" 이라고 한 게 이 지점이다.
대안으로 제시된 것
| 방법 | 내용 |
|---|---|
Accept: text/markdown | HTML 대신 마크다운을 주면 토큰이 줄고 읽기 쉽다 |
Accept-Language | 에이전트가 원하는 언어의 코드 예제를 준다 |
| CLI 직접 호출 | 터미널 쥔 에이전트가 MCP 서버보다 유능할 때가 많다 |
전부 새 프로토콜이 아니라 원래 있던 HTTP 기능이라는 게 핵심이다.
Problem
프론트엔드로서 어떤 자세를 가질까
프로토콜 편에 서지 말고 인터페이스 편에 선다. MCP 든 HTTP 든 바뀌는 건 운반 수단이다. 안 바뀌는 질문은 하나다 — 내가 만든 것이 문서화돼 있고, 인증이 표준이고, 응답이 읽어서 이해되는가.
구체적으로 셋.
- MCP 설정은 자산이 아니라 소모품으로 본다. 늘리기 전에 "이거
curl로 되나?" 를 먼저 묻는다. - 안 쓰는 MCP 는 끈다. 붙어 있는 도구 개수가 곧 매 요청의 비용이다.
- 내가 만드는 응답을 에이전트가 읽는다고 가정한다. 에러 메시지를 사람 말로 쓰고, 응답이 스스로를 설명하게 둔다. 이건 프론트엔드가 지금 당장 손댈 수 있는 지점이다.
MCP 를 HTTP API 로 바꾸는 방법
순서대로 하면 된다.
1. 목록을 본다. 붙어 있는 MCP 서버를 전부 적고, 최근에 실제로 쓴 것에 표시한다. 대개 절반 이하다.
2. 각 서버가 뭘 감싸는지 확인한다. 셋 중 하나다.
| 감싸는 대상 | 어떻게 할까 |
|---|---|
| 공개 HTTP API | 제거. 문서 URL + 토큰 + curl 예시만 남긴다 |
| CLI 도구 | 제거. CLI 를 깔면 --help 로 알아서 쓴다 |
| 로컬 파일·DB·에디터 상태 | 남긴다. HTTP 가 아닌 것은 대안이 없다 |
3. 제거한 자리에 한 줄을 남긴다. 프로젝트 지침 파일(AGENTS.md 등)에 적어두면 된다.
GitHub: gh CLI 사용. 사용법은 `gh --help`, `gh api --help`
날씨 API: https://api.example.com/docs · 토큰은 $WEATHER_TOKEN
curl -H "Authorization: Bearer $WEATHER_TOKEN" https://api.example.com/v1/now
도구 20개가 매번 컨텍스트에 실리던 것이, 필요할 때만 읽히는 세 줄이 된다.
4. 인증은 좁게. 수명 긴 개인 토큰을 그대로 주지 않는다. 범위를 줄인 토큰을 환경변수로 넘긴다.
5. 반복되는 호출은 스크립트로 굳힌다. 매번 새로 조합하면 결과가 매번 달라진다. 두 번 이상 같은 걸 했으면 스크립트로 만들고, 그 다음부터는 스크립트만 부른다.
이 글의 한계
읽으면서 걸린 것 다섯 개. 이쪽이 더 중요하다.
1. Code Mode 인용이 거꾸로다. 원문은 Cloudflare Code Mode 를 "MCP 말고 이쪽" 의 증거로 든다. 그런데 Code Mode 는 MCP 를 대체하지 않는다. MCP 서버의 스키마를 가져와 TypeScript API 로 바꾸고, 그 코드를 샌드박스에서 실행하는 구조다. Cloudflare 는 오히려 이렇게 적었다 — "MCP 는 API 에 연결하고 그것을 알아내는 균일한 방법을 준다." 증거로 든 것이 결론을 반박한다.
2. 터미널 있는 에이전트가 전제다. 코딩 에이전트 얘기다.
터미널도 코드 실행도 없는 챗 UI, 모바일 앱, 데스크톱 앱에서는 --help 도 curl 도 못 쓴다.
그쪽에는 아직 MCP 말고 답이 없다.
3. "성숙한 인증" 은 반쪽이다. MCP 는 2025년에 OAuth 2.1 리소스 서버로 정리됐다 — 보호 리소스 메타데이터(RFC 9728), PKCE 필수. 표준이 없는 쪽이 아니다. 반대로 "그냥 HTTP" 로 가면 에이전트에게 수명 긴 토큰을 쥐여주기 쉽다. 어느 쪽이 더 성숙한지는 단정할 수 없다.
4. 승인과 기록의 경계가 사라진다. MCP 는 "이 도구를 쓸까요" 를 물을 지점을 준다.
임의 코드 실행과 curl 에는 그 지점이 없다. 혼자 쓸 땐 편하고, 여럿이 쓰는 조직에선 문제가 된다.
5. 발견 가능성은 여전히 미해결이다. --help 는 CLI 가 깔려 있어야 한다.
HTTP API 에는 균일한 발견 방법이 없다. OpenAPI 가 있지만 전부가 주지는 않는다.
MCP 가 실제로 해결한 게 이 부분인데, 원문은 이걸 다루지 않는다.
Output
남길 문장 하나
MCP 는 틀린 설계가 아니라 조건부 설계였다. 조건(모델이 약하다)이 사라지면서 값어치가 줄었을 뿐, 조건이 남아 있는 자리에서는 아직 유효하다.
지금 할 것
- 붙어 있는 MCP 를 목록으로 만들고, 안 쓰는 건 끈다. 이건 오늘 할 수 있다.
- 남길지 말지는 감싸는 대상으로 정한다. HTTP API·CLI 면 빼고, 로컬 상태면 남긴다.
- 새로 붙이기 전에 한 번 묻는다 — "모델한테 문서 링크만 주면 안 되나?"
안 할 것
전부 걷어내는 것. 5번(발견 가능성)과 2번(터미널 없는 클라이언트)이 해결되기 전까지는 MCP 를 0 으로 만들 수 없다. 줄이는 것과 없애는 것은 다르다.
참고
- Why MCP Was Always a Bad Idea — 원문.
- Code Mode: the better way to use MCP — 원문이 인용한 글. 직접 읽으면 결이 다르다.
- MCP Authorization spec — OAuth 2.1 리소스 서버로 정리된 현재 명세.
형식은 PKM — 기록으로 나를 디버깅하기 에서 정한 Input / Problem / Output 을 따랐다.