MCP를 무조건 붙이기 전에 비용부터 봐야 해요

MCP를 무조건 붙이기 전에 비용부터 봐야 해요

AI 뉴스 썸네일

AI 도구 연결의 표준처럼 보였던 MCP를 두고, 개발 현장에서는 꽤 현실적인 질문이 나오고 있어요. 외부 서비스를 붙이는 건 쉬워졌지만, 컨텍스트 비용과 운영 부담까지 같이 따라오기 때문이에요.

핵심 요약

구분	핵심	왜 볼 만한가요
개발도구	Quandri는 MCP가 개발 흐름에서 컨텍스트와 운영 비용을 크게 만든다고 봤어요	AI 도구를 많이 붙일수록 실제 작업 공간이 줄어드는 문제를 숫자로 보여줘요
비용 비교	Linear 이슈 조회 예시에서 MCP 방식은 약 12,957 토큰, CLI 방식은 약 200 토큰으로 계산됐어요	같은 작업도 연결 방식에 따라 비용 차이가 커질 수 있어요
대안	CLI와 API를 먼저 쓰고, 필요한 절차만 가볍게 문서화하는 방식이 제안됐어요	이미 쓰는 터미널 도구를 AI와 사람이 같이 재현할 수 있어요

1. MCP는 죽지 않았지만, 아무 데나 붙일 도구도 아니에요

MCP는 LLM이 GitHub, Linear, Notion, 데이터베이스 같은 외부 도구를 호출하게 해 주는 연결 규격이에요. 한동안 “AI 생태계의 USB-C”라는 식으로 불릴 만큼 기대가 컸어요. Quandri는 실제 업무 환경에서 써 보니 문제가 먼저 보였다고 말해요. 특히 도구 정의가 컨텍스트 창을 많이 차지하고, 별도 서버 프로세스 때문에 인증·초기화·충돌 문제가 생길 수 있다고 봤어요. 1

원문이 흥미로운 지점은 “MCP가 나쁘다”로 끝내지 않는다는 데 있어요. Quandri는 Claude Code의 Tool Search with Deferred Loading 이후 컨텍스트 부담이 85% 이상 줄었다는 업데이트도 같이 적었어요. 그래서 지금의 논점은 “MCP는 끝났다”보다 “어떤 작업에 MCP가 맞고, 어떤 작업에는 기존 CLI/API가 더 나은가”에 가까워요. 2

Quandri가 Linear, Notion, Slack, Postgres MCP 서버의 도구 정의를 재 보니 총 77개 도구가 약 21,077 토큰을 썼어요. Claude 200K 컨텍스트 기준 10.5%, GPT-4o 128K 기준 16.5%에 해당해요. 실제 작업 내용이 아니라 “쓸지도 모르는 도구 설명”이 먼저 자리를 차지하는 셈이에요. 2

Linear만 봐도 차이가 커요. Linear MCP는 42개 도구 정의가 항상 붙으면서 약 12,807 토큰을 차지해요. 반면 Linear GraphQL API를 `curl`로 직접 호출하면 같은 이슈 조회 작업에 약 200 토큰이면 충분하다고 계산했어요. 이 비교는 완벽한 일반화라기보다, 도구 연결 방식이 모델 비용과 응답 품질에 영향을 줄 수 있다는 신호로 읽는 게 좋아요. 2

개발자 흐름에서는 사람이 쓰는 명령과 AI가 쓰는 명령이 같을수록 디버깅이 쉬워요. CLI나 API는 터미널에서 바로 재현할 수 있고, `jq`, 파이프, 로그와 조합하기도 편해요. MCP는 대화 안의 도구 호출로 감춰지는 경우가 많아 실패 원인을 추적하기 어려울 수 있어요.

원문은 그래서 “CLI → API → 문서” 순서를 먼저 보자고 제안해요. 이미 강한 CLI가 있는 `gh`, `psql`, `aws` 같은 도구는 MCP 서버를 하나 더 띄우기보다 기존 명령을 잘 쓰게 만드는 편이 가볍다는 얘기예요. 반복 작업에는 필요한 사용법만 불러오는 문서화 패턴을 붙이면 되고요. 2

MCP가 쓸모없다는 뜻은 아니에요. CLI가 없는 웹 서비스, 터미널을 쓰지 않는 사용자, 팀 단위 인증과 권한 제어가 필요한 환경에서는 여전히 장점이 있어요. 특히 프로덕션 데이터베이스처럼 읽기 전용 강제, 위험 쿼리 차단, 자격 증명 보호가 중요한 곳에서는 별도 서버가 안전장치가 될 수 있어요.

왜 중요한가요

AI 도구를 붙일 때는 새 서버를 추가하기 전에 세 가지를 먼저 보면 좋아요. 같은 작업을 기존 CLI나 API로 재현할 수 있는지, 도구 정의가 매번 컨텍스트에 들어가야 하는지, 실패했을 때 사람이 터미널에서 같은 과정을 다시 실행할 수 있는지예요.

이 세 가지가 모두 괜찮다면 MCP가 꼭 필요하지 않을 수 있어요. 반대로 권한 관리, 안전한 실행 경계, 비개발자 접근성이 더 중요하다면 MCP 쪽이 나을 수 있어요. MCP를 표준이라서 붙이는 대신, 작업별 비용과 복구 가능성을 보고 고르는 흐름이 더 현실적이에요.

개인 로컬 개발에서는 CLI가 빠르고 단순해요. 팀 전체가 같은 권한 정책을 써야 하거나 접근 제어를 중앙에서 관리해야 한다면 MCP가 더 맞을 수 있어요. 결국 선택 기준은 “연결할 수 있나”가 아니라 “운영하면서 설명하고 복구할 수 있나”예요. 2

참고 자료

1. MCP는 죽었나? — GeekNews
2. MCP is dead — Quandri Engineering
3. MCP is dead. Long live the CLI — EJ Holmes
4. Model Context Protocol in Claude Code — Anthropic