들어가며
AI 에이전트 아키텍처의 뜻밖의 회귀
최근 인공지능 생태계는 단순한 텍스트 생성을 넘어, 자율적으로 시스템과 상호작용하는 에이전틱 AI(Agentic AI) 시대로 진입했습니다. 이 고도화 과정에서 엔지니어들이 직면한 가장 큰 기술적 난제는 파편화된 외부 시스템과의 연동이었습니다.
2024년 말 Anthropic이 발표한 MCP(Model Context Protocol)는 이러한 문제를 해결할 'AI를 위한 USB-C'라는 찬사를 받으며 새로운 표준으로 급부상 했습니다.
그러나 최근 실제 프로덕션 환경에서 AI 에이전트를 구축 및 운영하는 최상위 엔지니어와 연구자들 사이에서 아키텍처의 근본적인 방향성에 대한 새로운 논의가 촉발되고 있습니다.
상대적으로 무거운 프로토콜인 MCP 대신 50년 전 유닉스(Unix) 철학의 정수인 CLI(Command Line Interface)를 기본 통신 규격으로 채택하는 회귀 현상이 가속화되고 있습니다. 이미 Claude Code, Gemini CLI, Cursor, OpenClaw 등 시장을 주도하는 에이전트 도구들은 CLI 기반으로 설계되었습니다.
가장 진보된 AI 시스템이 왜 가장 낡은 인터페이스에 주목하는지, 본 아티클에서는 그 기술적 배경을 분석하고 상황에 맞는 아키텍처 선택 기준을 제시하고자 합니다.
CLI-First 필요성의 대두: 자원 한계와 병목 현상
LLM 기반 에이전트 설계에서 가장 비용이 높고 제한적인 자원은 컨텍스트 윈도우(Context Window)입니다. CLI-First 아키텍처는 이 자원의 효율적 활용 측면에서 MCP 대비 압도적인 우위를 점합니다.
① 토큰 소모의 구조적 한계 (Front-loading Overhead)
MCP 아키텍처는 에이전트가 도구를 인식하게 하기 위해 도구의 명세(이름, 기능 설명, 파라미터, JSON 스키마 등)를 시스템 프롬프트에 사전에 적재(Front-loading)해야 합니다.
이는 단일 도구 환경에서는 문제가 되지 않으나, 수십 개의 도구가 연결된 엔터프라이즈 환경에서는 치명적인 병목을 유발합니다. 예를 들어, GitHub MCP 서버를 연결할 경우 약 93개의 도구 스키마가 로드되며, 실제 작업을 시작하기도 전에 55,000개 이상의 토큰이 소모됩니다.
반면, 기존 GitHub CLI(gh)를 활용하는 CLI-First 접근법은 무거운 스키마 주입 없이 약 200토큰 내외로 동일한 작업을 수행합니다. 이는 MCP 대비 약 275배 높은 토큰 효율성을 의미합니다.
② 중간 결과 처리의 비효율성
"구글 드라이브 문서를 읽고 이메일에 첨부하는" 다단계 워크플로우를 가정할 때, MCP 아키텍처는 도구 호출 결과값을 반드시 모델의 컨텍스트 윈도우에 반환해야 합니다. 대량의 문서 데이터가 모델 내부를 두 번 통과하게 되며, 이는 구조적 비효율과 응답 지연, 나아가 컨텍스트 초과로 인한 워크플로우 중단의 원인도 될 수 있습니다.
CLI는 데이터를 로컬 파일 시스템에 임시 저장하고 파이프라인을 통해 처리합니다. 모델은 거대한 원본 데이터 대신 Exit code나 짧은 표준 출력(stdout) 같은 메타데이터만 수신합니다.
프로그래밍 패러다임에 비유하자면, MCP의 방식이 'Call by Value'라면 CLI의 방식은 'Call by Reference'와 같습니다.
왜 하필 CLI인가? : 네이티브 언어와 관측성
① LLM의 네이티브 언어: 유닉스 철학과 쉘 스크립트
CLI는 최신 AI 모델들에게 가장 익숙한 '모국어'입니다. 모델들은 Pre-training 단계에서 수십 년간 누적된 터미널 상호작용과 Bash 스크립트 데이터를 완벽하게 내재화했습니다. 터미널은 철저히 텍스트 스트림 기반으로 작동하며, 이는 텍스트를 예측하는 LLM에게 최적의 인터페이스입니다.
"CLI가 레거시 기술이라는 바로 그 점 때문에, AI 에이전트가 네이티브 환경에서 가장 쉽고 완벽하게 사용할 수 있는 도구가 됩니다." — Andrej Karpathy (OpenAI 공동 창업자)
② 관측성(Observability)과 Human-in-the-loop
MCP는 통신 과정이 추상화되어 있어 내부 에러 발생 시 원인 파악이 어렵습니다. 반면 CLI는 모든 실행 이력과 표준 출력(stdout), 표준 에러(stderr) 메시지가 투명하게 노출됩니다. 이러한 가시성은 에이전트 작업 실패 시 개발자가 터미널에서 즉각적으로 명령어를 수정하거나 디버깅을 지원할 수 있는 완벽한 Human-in-the-loop 환경을 제공합니다.
확장성 한계의 극복: Agent Skills 개방형 표준
CLI-First 방식의 약점은 "에이전트가 사전에 어떤 명령어가 존재하는지 알 수 없다"는 점이었습니다. 이 문제를 완벽히 보완한 것이 Anthropic을 필두로 정립된 'Agent Skills'라는 개방형 표준 규격입니다.
Agent Skills의 일반적인 구조
📁 my-skill/ (최상위 스킬 폴더)
├── 📄 SKILL.md (필수: YAML 메타데이터와 핵심 지침 포함)
├── 📁 scripts/ (선택: 쉘을 통해 동적 실행할 스크립트)
├── 📁 references/ (선택: 참조용 대용량 API 스키마/가이드)
└── 📁 assets/ (선택: 템플릿 파일 등)
Plain Text
복사
기존 방식이 세상의 모든 설명서를 무거운 가방에 짊어지는 것이라면, Agent Skills는 필요할 때만 도서관에서 책을 빌려보는 '단계적 정보 공개(Progressive Disclosure)' 전략을 취합니다.
1.
발견 (Discovery): 세션 시작 시, 에이전트는 스킬 폴더를 스캔하여 SKILL.md 상단의 이름과 요약 설명만을 가볍게 시스템 프롬프트에 주입합니다.
2.
활성화 (Activation): 사용자의 의도와 일치한다고 판단되면, 자율적으로 해당 SKILL.md 파일의 본문을 컨텍스트 윈도우에 로드합니다 (도서 대출).
3.
실행 (Execution): 대용량 스키마나 코드가 필요해지면, 보조 파일들을 쉘 명령어로 동적 실행합니다. 스크립트 원본은 로드되지 않고 '실행 결과'만 반환되므로 무한한 확장성을 얻게 됩니다.
CLI vs MCP 벤치마크 및 아키텍처 선택 가이드
① 벤치마크 분석
실제 공유된 성능 벤치마크 결과를 보면 CLI 기반 아키텍처는 유의미한 효율성을 입증했습니다.
측정 항목 | MCP | CLI | 분석 결과 |
Device Compliance | 145,000 토큰 소모 | 4,150 토큰 소모 | 35배 비용 절감 |
Playwright (브라우저 자동화) | 85,500 토큰 | 6,500 토큰 | 13배 효율성 달성 |
작업 완료 점수 | 60 / 100점 | 77 / 100점 | 성공률 28% 향상 |
토큰 효율성 점수 (TES) | 152.3 | 202.1 | CLI 33% 우위 |
•
TES(Token Efficiency Score)는 작업 성공률과 리소스 소모량의 상관관계를 나타내는 지표입니다. CLI는 불필요한 프로토콜 오버헤드를 제거하여 모델이 순수 추론에 집중하게 만들며, 이는 실패 복구와 리팩토링의 유연성으로 이어집니다.
② 그렇다면 MCP는 이제 필요없나?
그렇지 않습니다. 상태 유지(Stateful)가 필수적인 복잡한 세션 관리나, 이전 결과를 지속적으로 참조해야 하는 다중 워크플로우에서는 MCP가 압도적 우위를 점합니다. 실시간 스트리밍 응답이나 복잡한 비즈니스 로직이 필요한 환경 역시 MCP의 구조화된 아키텍처가 적합합니다.
결국 CLI와 MCP는 상호 보완적 관계입니다. 시스템 특성에 따라 아키텍처를 선택하는 하이브리드 형태로 구성하는 것을 검토해야 합니다.
•
CLI-First 권장: 자원(토큰) 한계에 민감한 다중 도구 연결 환경, 무상태(Stateless) 기반의 일회성 동작, 즉각적 디버깅(stdout/stderr)이 필요한 환경, 보안이 확보된 서버 환경
•
MCP 권장: 중앙 집중식 감사 및 OAuth 기반의 정교한 접근 제어가 필요한 환경, 실시간 스트리밍 및 호출 간 상태 유지가 필수적인 서비스, 기존 CLI가 부재한 외부 통합 시스템
에이전트 친화적 CLI 설계 원칙
내부 시스템을 CLI-First로 구축할 때, 인간이 아닌 '에이전트'에 최적화된 설계가 필요합니다.
1.
구조화된 데이터 출력: stdout/stderr를 엄격히 분리하고, 파싱 오류 방지를 위해 -json 플래그를 필수적으로 지원합니다.
2.
명확한 종료 코드: 단순 0(성공)/1(실패)을 넘어 오류 코드를 세분화하여, 에이전트가 자율적으로 오류 복구를 수행하도록 유도합니다.
3.
작업의 멱등성(Idempotency) 확보: 반복 실행에도 시스템 상태가 안전하도록 선언적 명령어(apply, sync)를 설계하거나 -if-not-exists 플래그를 제공합니다.
4.
예제 중심 문서화: 에이전트의 문법 추론 정확도를 높이기 위해 -help 조회 시 구체적인 예제와 계층적 탐색 구조를 제공합니다.
5.
파이프라인 조합성: 다단계 파이프라인 구축을 위해 헤더 등 시각적 요소를 제거하고 순수 데이터만 반환하는 -quiet(q) 플래그를 지원합니다.
6.
대화형 확인 프롬프트 우회: 쉘 세션을 중단시키는 확인 절차(y/n)를 우회할 수 있도록 -yes 또는 -force 플래그를 제공합니다.
7.
실행 가능한 에러 메시지: 실패 시 명확한 에러 타입(file_not_found 등)과 구체적인 다음 조치 단계를 제시하여 추론 경로를 가이드합니다.
8.
일관된 명사-동사 문법: create-user 같은 혼재된 문법을 지양하고, user create 형태의 일관된 트리 구조를 채택하여 탐색 효율을 높입니다
마치며
가장 진보된 AI를 깨우는 가장 단순한 인터페이스
MCP는 표준화와 정교한 상태 관리를 통해 엔터프라이즈 환경에 안정성을 부여하는 훌륭한 아키텍처입니다. 반면 CLI-First 아키텍처는 유닉스 철학의 단순함과 압도적인 토큰 효율성을 바탕으로 에이전트의 실질적인 문제 해결 능력을 극대화합니다.
가장 진보된 인공지능 에이전트 시대를 견인하는 강력한 동력이 가장 오래된 인터페이스인 CLI의 단순함에서 비롯되고 있다는 점은 우리에게 깊은 시사점을 남깁니다.
결국 아키텍처를 선택하는 엔지니어에게 필요한 태도는 특정 기술의 우열을 가리는 것이 아닙니다. 사용자의 맥락과 환경, 시스템의 제약을 깊이 이해하고, 필요에 따라 유연하게 배치하는 하이브리드형 아키텍처 설계가 그 어느 때보다 중요해진 시점입니다.
참고 자료
이상용 프로 / 오픈소스사업팀
오픈소스 기술 연구와 개발을 담당하고 있어요