🤔 MCP는 이미 죽어가고 있다? CLI가 AI 시대의 진짜 답인 이유

 

MCP 열풍, 그 뒤에 찾아온 현실

2024년 11월, 앤트로픽이 MCP(Model Context Protocol)를 발표했을 때 개발자 커뮤니티는 뒤집어졌습니다.

"드디어 AI와 외부 서비스를 표준 프로토콜로 연결할 수 있다"는 기대감으로 수많은 기업이 MCP 서버를 경쟁적으로 출시했고, "AI 퍼스트 시대의 새로운 표준"이라는 말이 넘쳐났죠.

그런데 약 1년이 지난 2026년 현재, 분위기가 조금 달라지고 있습니다.

이미 AI 개발 도구 생태계에서는 MCP를 실제로 사용해본 개발자들 사이에서 "생각보다 별로다"라는 이야기가 조용히 퍼지고 있거든요. MCP 자체가 사라지는 건 아니지만, 과연 이걸 모든 곳에 적용해야 하느냐는 물음표가 생긴 겁니다.

오늘은 MCP가 정확히 뭔지, CLI랑 어떻게 다른지, 그리고 2026년 AI 개발자들이 실제로 어떤 방향으로 도구를 선택해가고 있는지를 솔직하게 풀어볼게요.

MCP가 뭔지 모르는 분들을 위한 초간단 설명

MCP는 LLM이 외부 서비스나 도구를 사용할 수 있도록 연결해주는 표준 규격입니다.

예를 들어 클로드가 깃허브에서 코드를 가져오거나, 지라에서 이슈를 조회하거나, 슬랙에 메시지를 보낼 때 이 작업들을 표준화된 방식으로 처리하게 해준다는 개념이에요.

쉽게 비유하면 다양한 가전제품을 하나의 리모컨으로 제어할 수 있게 만드는 통합 허브 같은 것입니다. 처음 들으면 굉장히 그럴듯하게 들리죠.

실제로 출시 1년 만에 MCP SDK 월간 다운로드 수가 9,700만 건을 넘었고, 5,800개 이상의 MCP 서버가 생겨났습니다. 오픈AI, 구글, 마이크로소프트, AWS까지 채택하면서 사실상 업계 표준에 가까운 위치를 차지하게 됐어요. 2025년 12월에는 리눅스 재단 산하의 Agentic AI Foundation으로 이전해 중립성까지 확보했습니다.

그런데 여기서 한 가지 의문이 생깁니다. LLM은 원래 서비스와 대화를 잘 하고 있지 않았나요? 굳이 새로운 프로토콜이 필요한 걸까요?

사람들이 잘 모르는 LLM의 숨겨진 능력

많은 사람들이 "AI가 터미널 명령어를 쓰는 게 복잡하지 않냐"고 생각합니다. 하지만 이건 대표적인 오해예요.

LLM은 수백만 개의 매뉴얼 페이지, 스택 오버플로우 답변, 깃허브 셸 스크립트로 훈련되었습니다. 즉, CLI(명령줄 인터페이스)를 다루는 것은 AI에게 가장 자연스러운 방식 중 하나입니다.

gh pr view 123이라고 입력하면 AI는 그냥 작동합니다. 특별한 프로토콜 없이도요.

MCP는 더 깔끔한 인터페이스를 약속했지만, 결국 각 도구가 무엇을 하는지, 어떤 파라미터를 받는지, 언제 써야 하는지 문서를 작성해야 했습니다. AI가 이해해야 하는 정보의 양은 크게 다르지 않은 셈이에요.

기술의 복잡성은 새로운 레이어를 추가할수록 줄어드는 게 아니라 오히려 늘어납니다. 이미 잘 작동하는 것에 중간 계층을 끼워 넣으면, 그 계층이 새로운 고장 지점이 됩니다.

CLI의 핵심 강점 1: 나도 같이 볼 수 있다

CLI와 MCP의 가장 중요한 차이는 의외로 단순한 데서 나옵니다. 바로 "투명성"입니다.

클로드가 지라에서 뭔가 이상한 작업을 했다고 가정해봅시다. CLI 환경이라면 내가 똑같이 jira issue view를 입력해서 AI가 봤던 것과 동일한 화면을 볼 수 있어요. 같은 입력, 같은 출력, 별다른 미스터리 없이.

반면 MCP 환경에서는 그 도구가 LLM 대화 안에서만 존재합니다. 무언가 잘못되면 JSON 전송 로그를 뒤져야 하고, 디버깅이 "명령어 한 번 더 입력해보기"가 아니라 "프로토콜 디코더 켜기"가 됩니다.

이건 단순한 편의성의 문제가 아닙니다. AI와 사람이 같은 도구를 함께 쓸 수 있을 때, 협업의 진짜 가치가 만들어집니다. 내가 볼 수 없는 도구를 AI에게 맡기는 것은 블랙박스 안에서 일이 벌어지는 것과 다름없거든요.

CLI의 핵심 강점 2: 도구끼리 자유롭게 연결된다

개발자들이 CLI를 오래 쓰는 데는 이유가 있습니다. 파이프(|), 필터(grep), 리다이렉션 같은 기능 덕분에 여러 도구를 자유자재로 이어 붙일 수 있기 때문이에요.

실제 사례를 보겠습니다. 대규모 테라폼 플랜을 분석해야 할 때, 이렇게 명령어를 조합하면 됩니다.

terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'

이 한 줄로 변경 사항이 있는 리소스의 수를 정확히 뽑아낼 수 있습니다. 이미 잘 만들어진 도구들을 연결했을 뿐인데, 강력한 분석이 가능해지는 거예요.

MCP 방식으로 이걸 하려면? 전체 플랜 데이터를 컨텍스트 창에 모두 넣거나(비용도 비싸고 종종 불가능), MCP 서버 안에 필터링 기능을 직접 만들어야 합니다. 어느 쪽이든 더 많은 작업으로 더 나쁜 결과를 얻는 셈입니다.

좋은 도구는 혼자 다 하려 하지 않습니다. 다른 좋은 도구와 잘 이어지는 것이 진짜 실력이에요.

현장에서 실제로 겪는 MCP의 마찰들

이론적인 이야기를 넘어, 현장에서 개발자들이 실제로 겪는 불편함을 살펴볼게요.

MCP 서버는 프로세스입니다. 시작해야 하고, 계속 실행 중이어야 하고, 조용히 멈추면 안 됩니다. 안 되면 원인 파악이 쉽지 않아요. "클로드 코드를 재시작했더니 됐다"가 해결책이 되는 경우가 생각보다 많습니다.

인증 문제도 아쉬운 부분입니다. CLI 도구들은 이미 검증된 인증 방식을 씁니다. AWS는 프로필과 SSO를 쓰고, 깃허브는 gh auth login을 씁니다. 인증이 끊기면 내가 늘 하던 방식대로 고치면 됩니다. MCP 전용 트러블슈팅 문서를 찾아볼 필요가 없어요.

권한 제어도 한계가 있습니다. 읽기 전용 작업만 허용하거나, 특정 파라미터에서만 작동하게 하는 것이 CLI 환경에서는 가능합니다. gh pr view는 자동으로 허용하되 gh pr merge는 승인이 필요하게 설정하는 것처럼요. 이런 세밀함이 실제 업무에서는 꽤 중요한 부분이에요.

반면 CLI는 바이너리 파일입니다. 디스크에 있고, 필요하면 쓰고, 쓰지 않을 때는 조용합니다. 백그라운드 프로세스도 없고, 관리할 상태도 없습니다.

그럼 MCP는 완전히 쓸모없나요?

그렇지는 않습니다. MCP가 맞는 경우는 분명히 있어요.

CLI 대안이 아예 없는 도구라면 MCP가 현실적인 선택입니다. 표준화된 인터페이스 자체의 가치도 부정할 수 없어요. 실제로 2026년 MCP 로드맵에서는 수평적 확장, 엔터프라이즈 인증 통합, 감사 추적 등 현실적인 pain point들을 하나씩 해결해 나가고 있습니다.

다만, 이미 잘 만들어진 CLI가 있는 서비스에 굳이 MCP 서버를 추가로 만드는 것은 리소스 낭비일 가능성이 높습니다. 그 에너지를 더 좋은 CLI 완성도를 높이는 데 쓰는 것이 더 현명한 선택일 수 있어요.

AI 시대에는 "AI가 쓸 수 있는 것"을 따로 만들 필요가 없습니다. 사람이 잘 쓸 수 있게 만들면, AI도 잘 씁니다.

AI 개발 도구 생태계, 앞으로 어떻게 바뀔까

2026년을 기준으로 AI 개발 도구 생태계는 빠르게 정리되고 있습니다.

초기의 "일단 MCP 서버 만들어야 AI 퍼스트"라는 분위기는 식고, 실용적인 관점에서 도구를 선택하는 흐름이 강해지고 있어요. MCP는 리눅스 재단으로 넘어가 거버넌스를 갖추고, 기업용 기능들을 보완하면서 중요한 인프라로 자리를 잡아가고 있습니다.

흥미로운 점은, 이 논쟁이 단순히 MCP vs CLI를 넘어 더 큰 질문을 던진다는 겁니다.

AI를 위한 별도의 세계를 구축할 것인가, 아니면 사람이 쓰는 세계를 AI도 함께 쓰게 할 것인가.

수십 년간 쌓아온 CLI의 설계 철학은 결국 AI에게도 통한다는 것이 증명되고 있습니다. 새로운 것이 항상 더 나은 것은 아니에요. 때로는 오래된 방식이 오래된 이유가 있습니다.

인간과 기계가 같은 도구를 함께 쓸 수 있을 때, 협업의 진짜 가치가 만들어집니다.

마무리

MCP는 AI와 서비스를 연결하는 강력한 표준으로 성장하고 있지만, CLI가 가진 투명성, 조합 가능성, 단순함은 여전히 강력한 강점입니다. 이미 좋은 CLI가 있는 곳에서는 굳이 MCP를 추가할 필요가 없고, AI 도구를 만든다면 새로운 프로토콜보다 좋은 CLI를 먼저 갖추는 것부터 시작해보세요. 사람이 잘 쓸 수 있는 도구는 AI도 잘 씁니다.