CLI vs MCP——AI 에이전트 시대에 '가장 오래된 UI'가 재조명되는 이유

Lark(飛書), DingTalk, WeCom(企業微信), Google, Stripe——2026년에 들어서면서 테크 대기업들이 차례로 CLI 도구를 오픈 소스(Open Source)로 공개하고 있습니다.

GUI의 시대에 CLI라니 시대 역행이 아닌가? 그렇게 생각할지도 모릅니다. 하지만 실제로는 반대입니다. AI 에이전트(AI Agent)가 실무에 깊숙이 관여할수록 CLI의 가치가 재발견되고 있습니다.

이유는 간단합니다. CLI는 AI의 모국어이기 때문입니다.

LLM(대규모 언어 모델)의 학습 데이터에는 방대한 코드와 터미널 로그가 포함되어 있습니다. GUI의 스크린샷을 해석하게 하는 것보다, git commit -m "fix"라고 입력하게 하는 것이 훨씬 빠르고, 저렴하며, 정확합니다.

MCP가 'AI에게 도구를 사용하게 하는 프로토콜'로서 주목을 받았지만, CLI가 동일한 일을 더 단순하게 수행할 수 있는 케이스가 늘어나고 있습니다.

이 기사에서는 CLI 부활의 배경, 주목할 만한 OSS(오픈 소스 소프트웨어) 프로젝트, 그리고 MCP와의 활용 구분법을 정리합니다.

1. 왜 지금 CLI인가——AI에게 있어 '이상적인 UI'

GUI는 인간을 위해 만들어진 인터페이스입니다. 버튼, 드롭다운, 드래그 앤 드롭——모든 것이 '눈으로 보고 손으로 조작하는 것'을 전제로 합니다.

하지만 AI 에이전트에게는 '눈'도 '손'도 없습니다. 있는 것은 텍스트의 입출력뿐입니다.

특성	GUI	CLI
입력	마우스·터치·시각적 조작	텍스트 커맨드
...

CLI의 출력은 그대로 LLM의 컨텍스트(Context)에 흘려보낼 수 있습니다. GUI의 출력은 스크린샷을 찍어 이미지 인식에 걸쳐야 합니다. 어느 쪽이 빠를지는 명백합니다.

저도 AI 에이전트에게 GUI 조작을 시키려다 브라우저 자동화로 고생했던 경험이 있습니다. 버튼 위치가 몇 픽셀만 어긋나도 전부 멈춰버립니다. CLI로 전환하자마자 안정적으로 동작하는 것을 보고 '처음부터 이쪽으로 할 걸 그랬다'고 생각했습니다.

2. 주목할 만한 OSS 프로젝트

2.1 CLI-Anything: 소프트웨어를 한 줄로 CLI화

CLI-Anything은 임의의 오픈 소스 소프트웨어에 대해 CLI 래퍼(Wrapper)를 자동으로 생성하는 도구입니다.

할 수 있는 일:

• 소스 코드 분석 → API 도출 → 커맨드 설계 → 구현 → 테스트 → 공개를 자동으로 실행
• Draw.io, OBS Studio 등의 GUI 앱을 커맨드라인을 통해 조작 가능하게 함
• AI 에이전트가 --help를 통해 단계적으로 커맨드를 학습할 수 있는 설계

# 설치
pip install cli-anything
# Draw.io의 CLI 래퍼 생성
...

이 부분이 흥미롭습니다. 에이전트는 처음에 --help만 읽으면 됩니다. 모든 도구 정의를 컨텍스트에 채워 넣는 MCP와 비교했을 때, 토큰 소비가 최대 30분의 1로 줄어든다고 합니다.

2.2 Open CLI: 웹사이트를 커맨드라인화

Open CLI는 웹사이트나 Electron 앱을 CLI 도구로 변환하는 프로젝트입니다.

대응 플랫폼 예시:

서비스	CLI로 할 수 있는 일
Hacker News	기사 목록 취득, 댓글 열람
...

백그라운드에서 헤드리스 브라우저(Headless Browser)가 동작하며, 결과만을 텍스트/JSON으로 반환합니다. AI 에이전트에게는 'API가 존재하지 않는 서비스에도 CLI로 액세스할 수 있다'는 의미에서 강력합니다.

3. 공식 CLI 생태계의 확장

OSS뿐만 아니라 공식 CLI의 정비도 가속화되고 있습니다.

# GitHub CLI: 리포지토리 생성부터 PR 리뷰까지
gh repo create my-app --public --clone
gh pr create --title "feat: add auth" --body "OAuth2 대응"
...

이러한 공식 CLI는 안정적이며, API 키를 통한 인증도 잘 갖춰져 있습니다. AI 에이전트가 MCP를 통해 API를 호출하는 대신, CLI를 직접 호출하는 선택지가 현실적이 되고 있습니다.

4. CLI vs MCP: 구조적인 차이

여기서부터가 본론입니다. MCP와 CLI는 'AI에게 도구를 사용하게 한다'는 동일한 목표에 대해 완전히 다른 접근 방식을 취합니다.

MCP의 메커니즘

MCP(Model Context Protocol)는 LLM의 컨텍스트에 도구 정의(Tool Definition)를 주입하고, Function Calling을 통해 호출하는 프로토콜입니다.

[LLM의 컨텍스트]
├── 시스템 프롬프트 (System Prompt)
├── 도구 정의 A (JSON Schema) ← 항상 전체를 주입
...

CLI의 작동 방식

CLI 기반에서는 에이전트가 필요할 때만 --help를 통해 사용법을 확인합니다.

[LLM의 컨텍스트]
├── 시스템 프롬프트 (System Prompt)
├── "shell에서 명령어를 실행할 수 있습니다" (단 한 줄)
...

비교표

관점	MCP	CLI
도구 정의 비용	모든 도구 정의를 상시 컨텍스트에 주입. 도구 추가 시마다 토큰 소비 증가	--help를 통해 필요할 때만 획득. 미사용 도구의 토큰 소비는 제로
디버깅	에이전트 내부의 블랙박스(Black Box). 인간이 재현하기 어려움	명령어를 복사하여 터미널에 붙여넣는 것만으로 재현 가능
조합성	1개 도구당 1회 호출. 복잡한 태스크는 여러 라운드(Multi-round) 필요	파이프 `
구조화된 출력 (Structured Output)	JSON (Function Calling의 반환값)	--output json / --format csv로 유연하게 전환
에러 핸들링 (Error Handling)	도구마다 형식이 다름. 통일되어 있지 않음	종료 코드(Exit Code) + stderr의 통일된 규약
인간의 학습	도구 정의의 JSON Schema를 읽어야 함	man / --help로 즉시 확인

솔직히 MCP를 몇 가지 직접 만들어 본 경험이 있는데, 디버깅의 고통은 실로 엄청납니다. 에이전트가 내부에서 무엇을 하고 있는지 보이지 않습니다. 같은 작업을 CLI로 구현했을 때는 실패한 명령어를 그대로 터미널에서 재실행할 수 있었기에, 원인 파악이 압도적으로 빨랐습니다.

5. MCP가 승리하는 상황

지금까지 CLI를 밀어붙여 왔지만, MCP에는 명확한 이점이 있는 케이스가 있습니다. 공정하게 정리하자면 다음과 같습니다.

MCP가 적합한 상황:

• 멀티 테넌트 (Multi-tenant) 환경: 여러 사용자의 권한을 통합적으로 관리해야 하는 경우. CLI는 원칙적으로 실행 사용자의 권한으로 동작합니다.
• 클라우드 플러그인 시장: Slack App이나 ChatGPT Plugins와 같은 마켓플레이스에서는 MCP의 표준화된 인터페이스가 유리합니다.
• 인증의 일원 관리: OAuth, API 키의 라이프사이클 관리를 프레임워크 측에 맡기고 싶은 경우.
• 실행 환경의 제약: 터미널 접근 권한이 없는 환경 (Web 기반 챗봇 등)

CLI가 적합한 상황:

• 로컬 환경에서의 개발 및 자동화
• 기존 UNIX 도구군과의 통합
• 디버깅과 트러블슈팅(Troubleshooting) 속도가 중요한 경우
• 토큰 비용을 최소화하고 싶은 경우

어느 한쪽이 완전히 승리하는 것은 아닙니다. 현재로서는 CLI가 "비용 대비 효율이 높은 상황이 많다"는 느낌입니다.

6. 융합의 트렌드: CLI ↔ MCP의 상호 변환

이분법적인 선택이 아니라, 융합이 시작되고 있습니다.

# MCP 서버를 CLI 도구로 사용할 수 있게 하는 브릿지
mcp-to-cli --server github-mcp --output gh-mcp-cli
# 반대로, 기존 CLI 도구를 MCP 서버로 공개
...

MCP 또한 "모든 도구 정의의 상시 주입"에서 "필요할 때만 로드하는 지연 로딩(Lazy Loading)" 방식으로 진화하고 있습니다. 이는 정확히 CLI의 --help 방식을 도입한 움직임입니다.

결국 개발자는 어느 한쪽을 선택하는 것이 아니라, 상황에 따라 구분해서 사용하거나—심지어 의식조차 하지 않는 방향으로 나아갈 것이라고 생각합니다.

7. 요약

CLI는 "오래된 기술의 재발견"이 아닙니다. AI 에이전트 시대에 최적화된, 텍스트 퍼스트(Text-first) 인터페이스로서 정당하게 평가받고 있습니다.

• 토큰 소비: CLI의 --help를 통한 필요 시 학습으로 최대 30배 절감
• 디버깅: 명령어 복사/붙여넣기로 즉시 재현. MCP의 블랙박스와는 천양지차
• 조합성: 파이프라인을 통한 원라이너(One-liner)화. MCP는 1개 도구당 1회 왕복
• 단, MCP는 멀티 테넌트 및 인증 일원 관리 측면에서 여전히 우위에 있음

여러분의 AI 에이전트는 도구를 MCP를 통해 호출하고 있나요, 아니면 CLI를 통해 호출하고 있나요? 만약 두 가지를 모두 구분해서 사용하고 있다면, 어떤 기준으로 나누고 있는지 댓글로 알려주세요.

토론 (Discussion)