도구 호출 표준으로서 MCP(Model Context Protocol)가 “dead”라는 이야기가 종종 나오는데, 저는 현장에서 중요한 기준을 표준의 순도가 아니라 자동화 성공률로 두면 결론이 달라진다고 느꼈습니다. 이 글에서는 MCP와 CLI를 경쟁이 아니라 레이어로 공존시키는 관점, 그리고 토큰 효율·의도 기반 설계가 왜 성공률에 영향을 주는지 정리해보겠습니다.
MCP와 CLI는 왜 경쟁이 아니라 ‘레이어’일까요?
MCP와 CLI를 같은 선상에서 비교하면 “기존 CLI를 대체하나?” 같은 질문으로 흐르기 쉽습니다. 그런데 프로토콜을 **‘시스템 간 언어(system-to-system language)’**로 보면, 둘은 역할이 다릅니다.
- CLI: 운영체제/런타임과 강하게 맞물린 “저수준이지만 범용적인” 인터페이스입니다. 이미 방대한 생태계가 있고, 파일/프로세스/파이프 같은 강력한 조합성을 제공합니다.
- MCP: 모델(에이전트)이 도구를 쓰기 쉽게 만드는 “상위 레이어”입니다. 상위 계층일수록 보통 **제약과 표준(관측성/인증/보안)**이 더 많이 필요해지는데, MCP는 그 지점을 정면으로 다룹니다.
즉 “CLI vs MCP”가 아니라, 실제로는 “CLI 같은 기존 자산 위에 MCP라는 의도/거버넌스 레이어를 얹어 자동화를 더 안정적으로 만들 수 있나?”에 더 가깝습니다.
토큰 효율: MCP 확산이 오히려 성공률을 떨어뜨릴 수 있는 이유
MCP가 확산되면서 생긴 실전 이슈 중 하나가 도구 스키마 노출이 컨텍스트를 잠식하는 문제입니다. 도구가 많아질수록 모델에게 “사용 가능한 모든 도구 설명”을 계속 주입하게 되고, 그만큼:
- 중요한 업무 맥락이 컨텍스트에서 밀려나고
- 모델은 도구 선택/인자 구성에서 실수할 확률이 증가하며
- 결과적으로 자동화 성공률이 떨어질 수 있습니다
이 지점에서 흥미로운 흐름이 등장합니다. 스키마를 잔뜩 주는 방식 대신, 모델이 덜 읽어도 되도록 호출 방식을 바꾸는 시도들입니다.
(1) 셸/파일시스템식 호출: 익숙한 인터페이스로 컨텍스트를 줄이기
도구 스키마를 “API 문서”처럼 전부 노출하기보다, 모델이 상대적으로 익숙한 패턴으로 호출하게 만드는 접근입니다. 예를 들어 “파일을 만들고, 명령을 실행하고, 결과를 읽는” 흐름은 스키마 설명을 길게 넣지 않아도 이해가 됩니다.
(2) 코드(함수)식 호출: 제어흐름을 모델이 아닌 프로그램이 맡기
더 강력한 방식은 **제어흐름(control flow)**을 모델에게 맡기지 않고, 프로그램이 맡는 것입니다. 모델은 “의도”만 내고, 코드는 검증/재시도/분기/상태관리를 책임집니다. 이때 모델은 매번 방대한 도구 스키마를 ‘암기’하듯 읽을 필요가 줄고, 실패가 나도 코드가 회복시켜 성공률을 올리기 쉽습니다.
아래는 개념을 보여주기 위한 간단한 예시입니다(실제 MCP SDK가 아니라 구조를 설명하는 의사코드입니다).
def run_release_automation(intent: str):
# 모델은 "의도"만 제안
plan = llm.propose_plan(intent)
# 프로그램이 제어흐름을 소유: 검증/실행/재시도/관측
for step in plan.steps:
validate(step) # 입력 검증/권한 확인
result = tool_runner(step) # MCP 또는 CLI 호출
record_observability(step, result)
if result.failed:
step = recover(step, result) # 재시도/대체 경로
result = tool_runner(step)
return summarize_results()
핵심은 “모델이 모든 걸 즉흥적으로 처리”하는 구조에서 벗어나, 모델은 의도·제안, 프로그램은 실행·안전·관측을 가져가는 분업입니다.
MCP의 진짜 가치: 메커니즘이 아니라 ‘의도 기반 설계’를 강제하는 점
제가 MCP를 긍정적으로 보는 이유는 “새로운 호출 방식” 자체라기보다, 의도를 API 설계에 강제한다는 점입니다.
- “이 도구는 무엇을 할 수 있나?”를 나열하는 대신
“이 도구는 어떤 의도를 어떤 제약 하에서 수행하나?”로 인터페이스를 재구성하게 됩니다. - 그 결과로 자연스럽게
- 최소 권한(권한 설계)
- 감사 가능성(누가 무엇을 했나)
- 관측성(성공/실패 원인)
같은 운영 요소가 API 레벨에서 붙기 쉬워집니다.
이게 곧 제가 중요하게 보는 자동화 성공률과 연결됩니다. 단발성 데모는 CLI만으로도 멋지게 만들 수 있지만, 지속 운영에서 성공률을 올리려면 “실패했을 때 왜 실패했는지”와 “다시 시도해도 안전한지”가 시스템에 내장돼야 하니까요.
“MCP is dead” 논쟁을 제가 다르게 보는 기준: 성공률(B)이면 결론이 바뀝니다
대화에서 저는 MCP의 성공 기준을 (A) “명시적 표준으로서의 통일성”보다 (B) “현장에서의 문제 해결력”으로 두는 편이라고 했습니다. 특히 자동화 성공률을 지표로 잡으면, “MCP가 dead” 논쟁은 종종 이렇게 재해석됩니다.
- 표준 스펙의 순수성이 약해지거나 벤더가 흡수해도
→ 현장에서 성공률이 오르고 운영이 쉬워지면 의미가 있습니다. - 반대로 MCP를 썼는데도
→ 스키마 과부하, 권한/감사 미정착, 상태관리 부재로 성공률이 떨어지면
“MCP를 썼다”는 사실 자체는 큰 의미가 없습니다.
결국 제 결론은 이렇습니다. MCP는 “CLI를 대체하는 혁신”이라기보다, CLI 기반 자동화를 의도 기반·거버넌스 친화적으로 재포장해 성공률을 끌어올릴 가능성이 있는 레이어입니다.
도구 폭증 시대의 균형점: ‘의도 기반 추상화’ vs ‘범용 API 노출’
마지막으로 처음 정리에서 남았던 열린 질문을 제 나름의 기준으로 정리해보면, 균형점은 “멋진 범용성”이 아니라 자동화 성공률에 기여하느냐로 잡는 게 현실적입니다.
- 성공률이 중요한 핵심 업무(배포, 결제, 권한 변경 등)
→ 의도 기반 추상화 + 강한 제약/관측/권한이 유리합니다. - 탐색적 업무(리서치성 작업, 임시 데이터 가공 등)
→ **범용 API 노출(혹은 CLI 직접 호출)**이 생산적일 때가 많습니다. - 그리고 둘 다 필요하다면
→ “자주 쓰는 의도 API(상위)” + “탈출구로 CLI/로우레벨(하위)”의 2계층이 운영에 강합니다.
마무리
저는 MCP가 “죽었다/살았다”의 문제가 아니라, CLI 생태계를 버리지 않고도 자동화 성공률을 올릴 수 있는 상위 레이어로 자리 잡느냐의 문제라고 봅니다. MCP와 CLI를 함께 두고, 모델은 의도에 집중시키고, 프로그램은 제어흐름·안전·관측을 책임지게 만드는 방향이 가장 실전적이었습니다.
