여러분, 최근 AI 에이전트 개발에서 'MCP(Model Context Protocol)'를 사용해 보셨나요?
최근 1년 동안 MCP는 "AI 시대의 HTTP다!"라며 큰 각광을 받아왔습니다. 저 역시 처음에는 "이걸로 AI가 다양한 도구를 구조화해서 사용할 수 있겠구나!"라며 흥분해서 구현해 보기도 했죠.
하지만 실제로 프로덕션 환경에서 돌려보니 뭔가 묘한 위화감이랄까요, 골치 아픈 늪에 빠진 듯한 느낌이 들었습니다. 그리고 최근 글로벌 개발자 커뮤니티를 지켜보니 전혀 반대의 트렌드가 오고 있다는 것을 깨달았습니다.
바로 "MCP 사용을 줄이고, 에이전트가 직접 CLI(커맨드 라인 인터페이스)를 실행하게 한다"는 접근입니다.
엔지니어 Eric Holmes 씨가 자신의 블로그 글(MCP is dead. Long live the CLI.)에서 남긴 날카로운 한마디가 지금의 트렌드를 상징하고 있습니다.
"MCP is dead. Long live the CLI." (MCP는 죽었다. CLI 만세)
이 말이 겉보기에는 그저 반항적인 감정 표현처럼 들릴지 모르지만, 실제 개발 현장에 적용해 보면 결코 과장된 이야기가 아닙니다. 이번 글에서는 왜 지금 굳이 'CLI 퍼스트'인지 그 현실적인 이유를 이야기해 보려고 합니다.
MCP의 설계 사상 자체는 매우 훌륭했습니다
오해가 없도록 먼저 말씀드리자면, MCP의 콘셉트는 이치에 맞습니다.
- 외부 기능을 Tool로 정의한다
- Tool의 파라미터를 Schema로 기술한다
- 에이전트가 컨텍스트로 Tool을 로드한다
- 에이전트가 이 도구들을 호출하여 작업을 실행한다
이러한 접근 방식은 구조화되어 있고 확장성이 높으며, 인터페이스가 표준화된다는 큰 장점이 있습니다. 아키텍처 다이어그램으로 그리면 믿을 수 없을 만큼 깔끔하죠.
하지만, 이론과 현실의 소프트웨어 개발은 다릅니다.
현장에서 직면하는 'MCP의 3가지 함정'
일상적인 워크플로우에 MCP를 도입하면 예상치 못한 '기술 부채'가 쌓이기 쉽습니다. 구체적으로 다음과 같은 3가지 문제점이 있습니다.
1. 무시할 수 없는 토큰 오버헤드
MCP에서는 모델이 도구를 이해할 수 있도록 'Schema + 설명문'을 먹여야 합니다.
만약 에이전트가 여러 개의 MCP 서버에 연결된다면 어떻게 될까요?
- 도구의 이름
- 도구의 상세한 설명
- 파라미터의 JSON 구조
이 정보들이 모두 컨텍스트 윈도우를 차지하게 됩니다.
예를 들어, 10개의 MCP 서비스가 있고 각각 5개의 도구를 제공한다고 가정해 봅시다. 에이전트가 실제 작업에 들어가기도 전에 수천 토큰이 도구 설명만으로 증발하는 셈입니다. 추론 체인이 길어지는 작업에서는 비용이나 성능 측면에서 결코 무시할 수 없는 오버헤드입니다.
2. '바퀴의 재발명'이라는 고역
솔직히 말해서 많은 MCP 서버들이 그저 기존 도구들의 래퍼(Wrapper)에 불과하지 않나요?
- GitHub 제어
- Docker 관리
- 로그 분석
- CI/CD 트리거
- 클라우드 리소스 관리
이런 작업들은 이미 우리가 매일같이 두드리고 있는 완성도 높은 CLI 도구들이 존재합니다.
git, gh, docker, kubectl, aws, curl 등이 그것이죠.
이것을 MCP로 구현하려고 하면 아래와 같은 다중 구조가 됩니다.
CLI -> API -> MCP Server -> Agent레이어가 하나 늘어날 때마다 유지보수의 복잡성은 기하급수적으로 높아집니다. 대체 무엇을 위한 효율화인지 알 수 없게 됩니다.
3. Unix 파이프라인의 파괴
개인적으로 가장 아쉬운 부분이 바로 이 점입니다. Unix 철학의 핵심은 "한 가지 일을 잘하는, 작은 도구들을 조합한다(Make small tools that work together)"는 것입니다.
CLI의 진수는 grep, jq, awk, rg, tail 등을 연결하는 조합성(Composability)에 있습니다.
# 현장에서 자주 쓰는 패턴
tail -f logs/server.log | grep error | jq .개발이나 운영 현장에서 일상적으로 사용하는 이 유연한 파이프라인 처리가, MCP로 넘어가면 '고립된 함수 호출'로 토막 나버립니다. 구조화를 얻는 대신 CLI 특유의 유연성을 버리게 되는 것입니다.
왜 AI 에이전트에게 CLI가 '자연스러운' 것일까?
여기서 원점으로 돌아가 봅시다.
현대적인 LLM들은 CLI를 다루는 데 엄청나게 능숙합니다.
이유는 간단합니다. 그들의 학습 데이터에는 방대한 양의 GitHub 리포지토리, 셸 스크립트, DevOps 문서, CI/CD 설정 파일, 그리고 Stack Overflow의 Q&A가 포함되어 있기 때문입니다.
모델들은 숨쉬듯 아래의 요소들을 이해하고 있습니다.
- 옵션 플래그 (flags)
- 파이프 처리 (pipes)
- 셸의 에러 메시지
- man 페이지 (매뉴얼)
에이전트에게 셸 실행 권한을 부여하면 놀라울 정도로 매끄럽게 작업을 수행합니다.
코드를 검색하고, 파일을 직접 수정하고, 테스트를 돌리고, 에러를 디버깅하고, 커밋합니다. 이 일련의 루프가 '터미널 안에서' 완벽하게 끝나는 것입니다.
디버깅 효율을 극대화하는 '높은 재현성'
CLI가 MCP를 압도하는 또 다른 결정적인 강점이 바로 '재현성(Reproducibility)'입니다.
만약 에이전트가 아래 명령어를 실행하다가 에러로 멈췄다고 합시다.
kubectl get pods우리 인간 개발자들은 동일한 명령어를 복사해서 직접 터미널에 입력하는 것만으로 에이전트가 직면한 상황을 100% 재현할 수 있습니다. 디버깅이 굉장히 다이렉트하죠.
반면, MCP 호출에서 에러가 발생하면 어떨까요?
JSON 페이로드를 들여다보고, 도구의 실행 로그를 뒤지고, MCP 서버의 상태를 확인해야 합니다. 시스템이 복잡해질수록 원인 규명에 빼앗기는 시간이 늘어납니다.
트렌드는 'CLI 퍼스트' 에이전트로
최근 출시되는 AI 프로그래밍 도구들을 살펴보면, 명확하게 CLI-first 설계로 방향을 틀고 있습니다.
- Claude Code
- Codex CLI
- Gemini CLI
이 도구들의 공통점은 명확합니다.
- 터미널 위에서 직접 작동한다
- 에이전트에게 셸 명령어 실행을 허용한다
- 로컬 파일 시스템을 직접 조작한다
- 기존의 개발 도구 체인을 그대로 활용한다
즉, "에이전트를 위해 새로운 도구 생태계를 만들 필요가 전혀 없었다"는 것입니다. 인간 개발자가 수십 년에 걸쳐 정제해 온 도구를 그대로 사용하면 되는 것이죠.
전형적인 CLI 에이전트의 워크플로우
예를 들어 대규모 코드 리팩토링 시에는:
rg "oldDeprecatedFunction" .
git diff
npm test
git commit프로덕션 환경의 디버깅 조사 시에는:
tail -f logs/server.log
grep error
curl -v api/auth/check
docker-compose up새로운 API 서비스 구축 시에는:
cargo new my_api
cargo add axum sqlx
cargo watch
curl localhost:3000/health새로운 프로토콜도, 새로운 서버도, 불필요한 추상화 레이어도 필요 없습니다. 그저 그곳에 있는 기존 CLI를 사용하기만 하면 됩니다. Simple is best죠.
그럼에도 불구하고, MCP가 빛을 발하는 상황은?
오해하지 마시길 바랍니다. 이 글이 "MCP를 전부 갖다 버려라"고 말하는 것은 아닙니다. 적재적소라는 게 있으며, 다음과 같은 시나리오에서는 분명 MCP의 강점이 살아납니다.
- 엔터프라이즈용 SaaS와의 복잡한 연동
- 타입 안정성(Type-safe)이 강력하게 요구되는 API 조작
- 보안 및 컴플라이언스 요구사항이 엄격한 환경
- 개발자 대상이 아닌 일반 사용자용 애플리케이션
이러한 영역에서는 견고하게 구조화된 프로토콜이 필수적입니다. 하지만 일상적인 '개발자의 워크플로우'에 있어서는, CLI라는 인터페이스가 이미 최적의 해답을 내놓았다고 말할 수밖에 없습니다.
요약: AI는 '터미널'을 재발견했다
지난 몇 년간 우리는 "AI를 위한 새로운 도구 프로토콜이 필요하다"고 믿어왔습니다.
하지만 현실은 훨씬 수수하고, 그리고 합리적이었습니다.
AI는 새로운 개발 환경을 발명한 것이 아니라, 수십 년 전부터 존재해 온 세련된 시스템인 '터미널(Terminal)'의 가치를 재발견한 것에 불과할지도 모릅니다.
조합해서 파이프로 연결할 수 있고, 디버깅이 쉬우며, 누구나 재현할 수 있고, 무한히 확장할 수 있는 시스템.
돌고 돌아 최고의 인터페이스는 항상 우리 곁에 있었다는 결말이네요.
여러분의 프로젝트에서는 MCP와 CLI 중 어느 쪽을 주력으로 사용하고 계신가요? 현재의 설정이나 개발 환경에서 고민되는 점들을 댓글이나 SNS에서 꼭 들려주세요! 다양한 의견과 정보 교환을 기다립니다.
참고 링크:
