MCP는 죽지 않았다 — 그래도 우리가 MCP를 고집하는 이유

"CLI가 답이다"라는 글이 화제입니다. 토큰·속도·디버깅에서 CLI가 유리하다는 주장은 '터미널 앞의 개발자'를 전제로 했을 때 대체로 맞습니다. 그런데 꼼꼼한을 쓰는 분들은 지하철에서 폰으로 메모를 펼치는 일반 사용자예요. 꼼꼼한 만능수첩은 내 생각이 담긴 USB 드라이브, MCP는 그 드라이브를 어떤 AI에든 꽂는 커넥터입니다.

며칠 전 개발자 커뮤니티에서 "MCP는 죽었나?"라는 글이 돌았습니다. AI를 외부 도구에 연결하는 표준인 MCP(Model Context Protocol)가 사실은 너무 무겁고, 기존 CLI(명령줄 도구)를 쓰는 게 더 가볍고 빠르다는 주장이었습니다. 우리는 MCP 서버를 직접 만들어 운영하는 입장이라, 이 글을 그냥 넘길 수 없었습니다. 그래서 정면으로 따져봤습니다.

#먼저, 그 글이 맞는 부분

비판의 핵심은 세 가지였습니다. 첫째, MCP 서버를 붙이면 도구 설명만으로 AI의 작업 공간(컨텍스트)을 잡아먹는다. 둘째, 도구를 부를 때마다 서버를 한 번 더 거쳐서 느리다. 셋째, CLI는 사람과 AI가 같은 명령을 쓰고 터미널에서 바로 디버깅할 수 있다.

인용된 측정에 따르면, 대표적인 서비스 네 개의 MCP 도구 정의를 모두 합치면 도구 77개에 약 2만 1천 토큰, 컨텍스트의 10.5%를 차지했습니다. 솔직히 인정합니다. 개발자가 터미널에서 일하는 환경이라면, 이 지적은 대체로 옳습니다.

#그래서 우리 걸 직접 재봤습니다

비판이 옳은지 확인하려면 우리 숫자를 봐야 합니다. 꼼꼼한 MCP 서버의 도구 정의를 그대로 뽑아 같은 방식으로 측정했습니다.

꼼꼼한은 도구가 29개, 정의를 다 합쳐도 컨텍스트의 4% 남짓이었습니다. 도구 하나하나를 가볍게 설계한 결과입니다. 게다가 요즘 AI 클라이언트는 '필요할 때만 도구를 불러오는' 지연 로딩을 지원합니다. 모든 도구를 미리 펼쳐두는 게 아니라, 쓸 때만 꺼내 옵니다. "MCP가 컨텍스트를 상시 점유한다"는 가장 큰 우려는, 잘 만든 서버와 최신 클라이언트 조합에서는 이미 상당히 해소되어 있습니다.

#CLI는 무엇을 전제하는가

여기서부터가 진짜 핵심입니다. "CLI를 쓰자"는 말은 멋지게 들리지만, 조용히 깔린 전제가 있습니다. 쓰는 사람이 개발자라는 것.

CLI로 일하려면 터미널이 있어야 하고, 도구를 설치할 줄 알아야 하고, 토큰을 환경변수에 넣을 줄 알아야 하고, curl·jq·psql 같은 명령을 알아야 합니다. AI가 ffmpeg를 잘 다루는 것도, 그 사용법이 이미 학습돼 있기 때문이지 새로 만든 CLI는 결국 또 가르쳐야 하고요.

그런데 꼼꼼한을 쓰는 분들을 떠올려 보세요. 출근길 지하철에서 폰을 꺼내 이번 주 계획을 적고, 주말 여행지를 정리하고, 아이 학습 플래너를 채우는 분들입니다. 이분들에게 "환경변수에 토큰을 넣고 curl로 GraphQL을 호출하세요"라고 말할 수는 없습니다.

#그래서 우리가 MCP를 고집합니다

꼼꼼한이 MCP를 선택한 이유는 네 가지입니다.

• 연결의 유연성. 드라이브는 하나, 꽂히는 호스트는 여럿. 같은 꼼꼼한 데이터에 어떤 AI든 붙을 수 있습니다. 클라이언트마다 따로 도구를 배포하지 않아도, 한 번 만든 연결이 여러 환경에서 그대로 작동합니다.
• 클라우드에서 바로 연동. 로컬에 설치할 게 없습니다. URL 하나 추가하고 로그인 한 번이면 끝. 터미널도, 설정 파일도, 권한 다툼도 없이 클라우드 환경에서 곧바로 이어집니다.
• 범용 AI 호환. 특정 도구·특정 환경에 묶이지 않습니다. MCP는 표준 프로토콜이라, 이 AI든 저 AI든 같은 약속으로 알아듣습니다. 사용자가 쓰던 AI를 그대로 쓰면서 꼼꼼한을 꺼낼 수 있습니다.
• 언제 어디서나. 모바일·웹·데스크탑 어디서 열어도 같은 도구가 따라옵니다. 설치하고 설정하는 도구가 아니라, 그냥 꽂아 쓰는 도구. 일반 사용자에게 이건 타협할 수 없는 가치입니다.

#자리를 나눠 보면 분명해집니다

오해는 없으면 합니다. 우리는 CLI가 나쁘다고 말하는 게 아닙니다. 자리가 다를 뿐입니다.

#USB가 끝내 살아남은 이유

전송 속도만 보면 USB보다 빠른 직결 인터페이스는 시대마다 있었습니다. 전용 포트, 더 효율적인 규격들. 그런데 결국 책상 위에 남은 건 USB-C 한 모양이었습니다.

이유는 USB가 가장 빠르거나 가장 효율적이어서가 아닙니다. 누구나, 어디에나, 한 모양으로 꽂을 수 있어서입니다. 표준의 자리는 '최적'이 아니라 '범용'이 차지합니다.

MCP가 'AI 생태계의 USB-C'라 불린 건 그저 멋진 표어가 아니었습니다. 본질이 그렇습니다. 이론적으로 가장 가벼운 길은 CLI일 수 있지만, 수많은 사람이 어디서나 꽂아 쓰는 '범용 포트'의 자리는, 표준이 가져갑니다. 꼼꼼한 만능수첩이라는 드라이브에, MCP라는 커넥터가 달려 있는 이유입니다.

#마치며

"MCP는 죽었나?"라는 질문에 대한 우리 대답은 이렇습니다. 개발자의 터미널 안에서는, CLI가 이길 수 있습니다. 그 지적은 정당하고, 우리도 사내 작업에서는 CLI와 Skills를 씁니다.

하지만 수백만 일반 사용자의 손끝에서는, 표준 포트가 이깁니다. 내 생각이 담긴 드라이브 한 개를, 쓰던 AI든 새로 나올 AI든 그냥 꽂아서 쓰는 경험 — 그걸 가능하게 하는 건 지금으로선 MCP입니다. 그래서 우리는, 알면서도, MCP를 고집합니다.

가장 가벼운 길을 좇기보다, 가장 많은 사람이 꽂을 수 있는 길을 택했습니다. 꼼꼼한이 MCP를 고집하는 이유, 결국 USB가 남은 이유와 같습니다.