CLI 논제

일주일 만에 Hacker News 스레드 세 개. 합산 1,638포인트. 하나의 결론: IDE는 인간을 위한 것이고, CLI는 에이전트를 위한 것입니다.¹²³

Boris Tane의 계획/실행 분리(716포인트)는 전적으로 터미널에서 실행됩니다.¹ “CLI를 통한 MCP 비용 절감” 분석(304포인트)은 MCP 도구 호출을 claude --print로 대체하여 94%의 토큰 감소를 측정했습니다.³ Vercel의 just-bash 프로젝트(87포인트)는 에이전트 도구의 80%를 제거하면 모든 것이 더 빠르고, 저렴하고, 안정적이 된다는 것을 입증했습니다.⁴ 별도의 벤치마크에서는 CLI 접근 방식이 동등한 작업에 대해 MCP보다 35배 적은 토큰을 사용한다는 결과가 나왔습니다.¹⁰

이 패턴이 반복적으로 나타나는 이유는 아키텍처가 그것을 강제하기 때문입니다. 에이전트에는 조합성, 스크립트 가능성, 그리고 최소한의 오버헤드가 필요합니다. CLI는 세 가지 모두를 제공합니다. IDE는 어느 것도 제공하지 않습니다.

요약

CLI 우선 에이전트 아키텍처는 MCP 기반 접근 방식 대비 토큰 오버헤드가 94% 적고, 3.5배 빠르며, 표준 Unix 도구와 조합됩니다. 계획/실행 분리가 효과적인 이유는 CLI 산출물이 IDE 상태가 아닌 이식 가능한 마크다운 파일이기 때문입니다. Remote Control은 조합성의 이점을 희생하지 않으면서 CLI 에이전트를 원격으로 감독할 수 있게 합니다. 모든 본격적인 에이전트 시스템이 터미널로 수렴하는 이유는 터미널이 이미 자동화가 존재하는 곳이기 때문입니다.

계획/실행 분리

Boris Tane은 454명의 HN 댓글 작성자가 자신만의 변형으로 검증한 3단계 워크플로우를 문서화했습니다: 조사, 계획, 구현.¹ 핵심 관찰: 작성된 계획을 검토하고 승인하기 전까지는 절대 에이전트가 코드를 작성하게 하지 마세요.

이 워크플로우는 각 단계에서 마크다운 산출물을 생성합니다. research.md는 코드베이스 분석을 담고, plan.md는 코드 스니펫이 포함된 구현 전략을 담습니다. 개발자는 편집기에서 검토하고, 인라인 주석을 추가한 다음, 명시적인 지시와 함께 주석이 달린 계획을 다시 전달합니다: “아직 구현하지 마세요.” 이 주석 순환은 단 한 줄의 코드가 작성되기 전에 1회에서 6회까지 반복됩니다.

전체 루프는 터미널에서 claude를 통해 실행됩니다. IDE 플러그인 없음. 시각적 diff 도구 없음. 마크다운 파일 입력, 마크다운 파일 출력. 산출물은 대화 상태가 아닌 파일로 존재하기 때문에 컨텍스트 윈도우 압축에도 살아남습니다.

저의 자율 루프는 동일한 분리를 기계 규모로 구현합니다. PRD 파일이 수용 기준과 함께 스토리를 정의합니다. 각 스토리마다 새로운 에이전트가 생성되어, 현재 git 상태와 이전 에이전트가 수행한 작업에 대한 브리핑을 받습니다. 에이전트가 구현하고, 독립적인 검증자가 테스트를 실행하며(에이전트의 자기 보고를 절대 신뢰하지 않음), 세 명의 코드 리뷰어가 diff를 병렬로 평가합니다. 전체 오케스트레이션은 bash 스크립트 내 claude --print 호출을 통해 실행됩니다. 프레임워크 없음, 런타임 없음, 서버 없음.

계획/실행 분리가 터미널에서 효과적인 이유는 터미널이 이 분리를 구조적으로 만들기 때문입니다. 계획은 파일을 생성합니다. 실행은 파일을 소비합니다. 두 단계 사이의 경계는 디스크에 있는 파일로, 보이고 감사 가능합니다. IDE 플러그인 내부에 묻혀 있는 상태 전환이 아닙니다.

에이전트에게 CLI가 IDE보다 나은 이유

이 주장은 세 가지 기둥에 기반합니다: 비용, 조합성, 컨텍스트 효율성.

비용: 94% 토큰 감소

Kan Yilmaz는 네 가지 시나리오에서 MCP 대비 CLI의 토큰 오버헤드를 측정했습니다.³ 수치가 모든 것을 말해줍니다:

MCP는 모든 대화에 도구 스키마를 주입합니다. 84개의 도구가 있으면, 에이전트가 작업을 시작하기도 전에 스키마 오버헤드만으로 15,540 토큰을 소비합니다. CLI 호출은 스키마 오버헤드가 없습니다. 모델이 이미 표준 명령줄 인터페이스를 이해하고 있기 때문입니다.¹⁰ 한 사용자는 135개의 도구에서 MCP_DOCKER가 125,964 토큰을 소비하는 것을 문서화했습니다.¹⁴

Jannik Reinhard는 Intune 규정 준수 작업에 대한 병렬 벤치마크를 실행했습니다: 동등한 출력에 대해 MCP는 145,000 토큰, CLI는 4,150 토큰이었습니다.¹⁰ CLI 에이전트는 컨텍스트 윈도우의 95%를 추론에 사용할 수 있었습니다. MCP 에이전트는 예산의 대부분을 도구 정의에 소비했습니다.

조합성: Unix 파이프는 이미 작동합니다

Vercel의 v0 팀은 에이전트 도구의 80%를 제거하고 단일 bash 환경으로 대체했습니다.⁹ 결과:

Andrew Qu는 그 근거를 설명했습니다: “우리는 모델이 스스로 처리할 수 있는 문제를 해결하고 있었습니다.” 파일 시스템, grep, 파이프, 리다이렉트는 이미 조합됩니다. 모델은 이것들을 이해합니다. cat | grep | jq가 기본적으로 처리하는 작업에 대해 커스텀 MCP 도구를 만드는 것은 기능 추가 없이 오버헤드만 추가합니다.¹³

Anthropic의 자체 문서가 이 패턴을 확인합니다. Claude Code는 Unix 철학을 따릅니다: 로그를 파이프로 연결하고, CI에서 실행하고, 다른 도구와 체이닝합니다.⁵ 헤드리스 모드(claude -p)는 구조화된 JSON 출력, 스키마 적용, 캡처된 세션 ID를 통한 세션 재개를 지원합니다. Anthropic는 헤드리스 모드를 CI/CD 및 스크립트 워크플로우의 주요 통합 경로로 제시합니다.⁵

Simon Willison은 그 함의를 제시합니다: 코드를 작성하는 것은 이제 저렴합니다.⁶ 누구도 듣고 싶어 하지 않는 그 귀결은, 검증이 이제 비용이 드는 부분이라는 것입니다. CLI 에이전트는 기존 검증 인프라와 조합됩니다. 테스트 러너, 린터, 타입 체커, 보안 스캐너, 배포 파이프라인: 모두 명령줄 도구입니다. IDE 에이전트는 각각에 대해 플러그인이 필요합니다. CLI 에이전트는 파이프로 연결하면 됩니다.

컨텍스트 효율성: 노이즈가 아닌 시그널에 대한 추론

컨텍스트 윈도우는 유한합니다. 도구 스키마, 대화 기록, MCP 오버헤드에 소비되는 모든 토큰은 추론에 사용할 수 없는 토큰입니다. CLI 아키텍처는 설계상 컨텍스트 예산을 간결하게 유지합니다.

새로운 claude --print 호출은 전체 대화 컨텍스트(~100K+ 토큰)를 상속하는 대신 집중된 프롬프트(~2K 토큰)를 받습니다. 각 작업은 깨끗하게 시작됩니다. 축적된 상태 없음. 오래된 도구 정의 없음. 대화 드리프트 없음.

저의 인프라는 17개 생명주기 이벤트에 걸쳐 84개의 훅을 실행하며, 모두 CLI 호출로 오케스트레이션됩니다. 각 에이전트 생성은 브리핑을 받습니다: 현재 git 상태, 이전 에이전트가 수행한 작업 요약, 그리고 해당 작업의 수용 기준. 메모리 대신 브리핑. 모델은 30단계의 축적된 컨텍스트를 탐색하는 것보다 명확한 브리핑을 더 잘 실행합니다.

에이전틱 시스템에서의 Unix 철학에 대한 학술 분석이 이 원칙을 공식화했습니다: 다양한 인터페이스를 균일한 추상화로 통합하되, 조합성과 다루기 쉬움을 위해 일부 전문성의 손실을 수용합니다.¹¹ 파일과 유사한 추상화 및 코드 기반 사양은 인지적, 공학적 부담을 줄입니다. CLI 에이전트는 50년에 걸친 그 설계 작업을 상속받습니다.

Remote Control이 판도를 바꿉니다

CLI 우선 에이전트에 대한 명백한 반론: IDE의 시각적 피드백을 잃게 됩니다. Anthropic가 2026년 2월 25일에 답을 내놓았습니다. Remote Control은 모든 브라우저 또는 Claude 모바일 앱에서 로컬 Claude Code 세션에 연결합니다.² 이 기능은 Hacker News에서 531포인트와 313개의 댓글을 받았습니다.

Remote Control은 어떤 것도 클라우드로 이동시키지 않습니다. 에이전트는 로컬에서 계속 실행됩니다. 터미널 세션은 TLS를 통해 Anthropic의 API에 등록하고 작업을 폴링합니다. 모든 트래픽은 아웃바운드 HTTPS를 통과합니다. 인바운드 포트는 열리지 않습니다.²

이 기능은 감독 격차를 해소합니다. Remote Control 이전에 CLI 에이전트에는 두 가지 모드가 있었습니다: 감독(터미널 앞에 앉아 있기) 또는 비감독(떠나서 잘 되길 바라기). Remote Control은 세 번째 모드를 만듭니다: 비동기 거버넌스. 승인 프롬프트가 휴대폰으로 전달됩니다. 어디서든 승인, 거부 또는 방향 수정이 가능합니다.

저의 훅 시스템은 영향 범위별로 작업을 분류합니다. 로컬 작업(파일 쓰기, 테스트 실행)은 자동 승인됩니다. 공유 작업(git 커밋)은 경고합니다. 외부 작업(푸시, 배포)은 사람의 검토로 넘깁니다. Remote Control은 그 “넘기기” 경로를 차단 대기에서 비동기 알림으로 바꿉니다. 에이전트는 이전 작업의 검토를 휴대폰에서 진행하는 동안 다음 스토리 작업을 계속합니다.

IDE는 실행 환경이 아닌 표시 레이어가 됩니다. Remote Control을 통해 진행 상황을 모니터링합니다. 품질 게이트가 문제를 감지하면 개입합니다. CLI 에이전트가 작업을 수행합니다. IDE는 결과를 보여줍니다.

Bash 에이전트 패턴

Vercel의 just-bash는 AI 에이전트를 위해 특별히 구축된 인메모리 가상 파일 시스템을 갖춘 시뮬레이션된 bash 환경입니다.⁴ 이 설계는 에이전트 아키텍처에 대한 세 가지 확신을 담고 있습니다:

샌드박싱보다 격리. 각 호출은 격리된 상태로 실행됩니다. 환경 변수, 함수, 작업 디렉토리는 호출 간에 초기화됩니다. 파일 시스템은 유지됩니다. 지연 파일 로딩은 파일이 처음 읽을 때 로드되어 캐시되며, 에이전트가 읽기 전에 작성한 파일은 로드되지 않음을 의미합니다. 에이전트는 작업 간에 자체 환경을 오염시킬 수 없습니다.

커스텀 도구보다 기존 도구. Grep은 50년 된 도구이며 커스텀 검색 MCP 도구가 복제하는 것을 정확히 처리합니다. jq는 JSON를 파싱합니다. curl은 URL을 가져옵니다. 모델은 훈련 데이터에서 이러한 인터페이스를 알고 있습니다. 커스텀 도구는 스키마 주입과 문서화가 필요합니다. 표준 도구는 둘 다 필요하지 않습니다.

프레임워크 아키텍처보다 최소 아키텍처. Andrew Qu가 이 원칙을 포착했습니다: “모델은 점점 더 똑똑해지고 컨텍스트 윈도우는 점점 커지고 있으므로, 최고의 에이전트 아키텍처는 거의 아키텍처가 없는 것일 수 있습니다.”¹³

저의 하네스는 프로덕션 규모에서 이 패턴을 검증합니다. Claude Code를 오케스트레이션하는 약 15,000줄의 bash. 17개 이벤트 유형에 걸친 84개의 훅. 디스패처, 품질 게이트, 시맨틱 검색 통합, 자율 루프. Python 런타임 없음, 프레임워크 의존성 없음. bash의 거친 면(네이티브 JSON 없음, 비동기 없음, 적절한 데이터 구조 없음)은 실제로 존재하지만 해결 가능합니다. jq가 JSON를 처리합니다. 순차 처리는 사실 장점입니다: 게이트는 경쟁이 아니라 순서대로 실행되어야 합니다.

이 패턴이 작동하는 이유는 에이전트 오케스트레이션이 근본적으로 stdin을 읽고, 결정을 내리고, stdout을 쓰는 것이기 때문입니다. 이 설명은 bash의 설계 목적과 정확히 일치합니다. 그보다 더 복잡한 것은 도구가 잘못된 것이 아니라 작업 분해가 잘못되었음을 나타냅니다.

아키텍처적 결정으로서의 비용

비용 결정은 복리로 작용합니다. 비상태 작업에서 MCP 대신 CLI를 선택하면 호출당 94%를 절약합니다.³ 하루 100개 작업 기준으로, 도구 정의 오버헤드만으로 월 $228의 절감을 달성합니다.³ 이러한 절감은 더 많은 작업을 위한 예산을 확보하고, 이는 더 많은 절감을 만들어냅니다. 아키텍처가 스스로 비용을 회수합니다.

세 가지 비용 계층이 독립적으로 복리 효과를 냅니다:

토큰 계층. 시스템 프롬프트 압축. 저는 CLAUDE.md 파일과 8개의 규칙 파일에 걸쳐 ~3,500 토큰의 시스템 프롬프트를 운영합니다. 제약 조건이 설명보다 효과적입니다. “민감한 경로와 일치하는 도구 호출을 거부하라”는 자격 증명을 보호해야 하는 이유에 대한 15줄의 설명과 동일한 역할을 합니다. Anthropic의 모범 사례 문서도 같은 점을 강조합니다: 컨텍스트 윈도우가 차면 성능이 저하됩니다.⁷ 낭비되는 모든 토큰은 두 배의 비용을 치릅니다: 한 번은 직접적인 API 요금으로, 다시 한 번은 추론 품질 저하로.

에이전트 계층. 긴 대화 대신 새로운 생성. 자율 실행에서 각 스토리는 깨끗한 컨텍스트 윈도우를 가진 새 에이전트를 받습니다. Geoffrey Huntley는 Sonnet으로 시간당 $10.42에 자율 개발을 실행하는 “The Ralph Loop”라는 유사한 패턴을 문서화했습니다.¹² 각 에이전트가 새롭게 시작하므로 컨텍스트가 절대 팽창하지 않습니다. 시스템 프롬프트에 대한 캐시 히트는 90% 저렴하므로(Opus 4.6에서 100만 토큰당 $5.00 대비 $0.50), 새로운 생성에 걸쳐 반복되는 시스템 프롬프트는 최소한의 오버헤드만 발생합니다.⁸

아키텍처 계층. 비상태 작업에는 CLI, 상태 유지 작업에는 MCP. 단발성 평가를 위한 claude --print 호출은 연결 오버헤드를 추가하지 않습니다. MCP는 도구가 영구 상태 또는 스트리밍이 필요할 때 적합합니다. 대부분의 에이전트 작업은 단발성 평가, 분류 또는 코드 생성 작업입니다. CLI는 더 낮은 비용과 더 간단한 디버깅으로 이 모든 것을 처리합니다.

지난주 저의 자율 루프에서 나온 구체적인 예시: 밤새 5개의 PRD 스토리가 처리되었습니다.¹⁵ 각 스토리는 새 에이전트를 생성하고(~2K 토큰 브리핑), 구현을 실행하고(평균 ~15K 토큰), 이후 3개의 리뷰 에이전트를 생성했습니다(각 ~2K 토큰). 스토리당 총계: ~23K 토큰. 장시간 실행되는 MCP 대화에서 동일한 워크플로우는 세 번째 스토리까지 스토리당 ~100K+ 토큰의 축적된 컨텍스트를 운반할 것입니다. CLI로 5개 스토리: 총 ~115K 토큰. MCP 대화로 5개 스토리: 총 ~500K+ 토큰. 비용 비율은 추가 스토리마다 복리로 증가합니다.

MCP가 여전히 유리한 경우

CLI 논제는 MCP에 대한 보편적 반대 논거가 아닙니다. MCP는 CLI가 부족한 특정 시나리오에서 유리합니다.

상태 유지 도구 서버. 호출 간에 연결 풀을 유지하는 데이터베이스 브라우저는 MCP의 영구 서버 모델로부터 이점을 얻습니다. 모든 CLI 호출마다 재연결하면 지연 시간과 인증 오버헤드가 추가됩니다. 호출 간에 상태가 필요한 도구라면 MCP가 올바른 선택입니다.

구조화된 유효성 검사. MCP 도구 스키마는 입출력 계약을 강제합니다. CLI 호출은 임의의 텍스트를 허용합니다. 에이전트가 정밀한 스키마(API 키 형식, 날짜 범위, 열거형 옵션)에 맞는 구조화된 입력을 제공해야 할 때, MCP 스키마는 도구가 처리하기 전에 잘못된 형식의 입력을 잡아냅니다. CLI 유효성 검사는 도구 자체 또는 래퍼 스크립트가 제약 조건을 강제해야 합니다.

멀티 테넌트 접근 제어. MCP 서버는 사용자별 권한을 중앙에서 강제할 수 있습니다. CLI 도구는 운영 체제 사용자의 권한을 상속합니다. 서로 다른 에이전트가 서로 다른 접근 수준이 필요한 팀 환경에서 MCP는 더 세밀한 인가를 제공합니다.

스트리밍 응답. 점진적 출력을 생성하는 장시간 실행 작업(로그 테일링, 빌드 진행 상황, 데이터베이스 내보내기)은 완료까지 차단하는 CLI 호출보다 MCP의 스트리밍 프로토콜을 통해 더 잘 작동합니다.

판단 기준: 작업이 비상태이고 단발성이면 CLI를 사용합니다. 작업이 영구 상태, 구조화된 계약 또는 스트리밍이 필요하면 MCP를 사용합니다. 저의 하네스에서 약 90%의 작업이 비상태입니다. MCP가 필요한 10%는 진정으로 그로부터 이점을 얻습니다. 90%를 최적화하면 가장 큰 수익을 얻을 수 있습니다.

오늘 바로 구축할 수 있는 것

세 가지 패턴, 각각 오후 한나절이면 구축 가능하고, 서로 복합적으로 작용합니다.

패턴 1: 계획/실행 분리

# Plan phase: research and plan, no implementation
claude -p "Research the codebase and write research.md" \
  --allowedTools "Read,Glob,Grep,Write"

# Review: read annotations in research.md, write plan.md
claude -p "Read my annotations in research.md and write plan.md" \
  --allowedTools "Read,Write"

# Implement: follow the approved plan
claude -p "Implement the plan in plan.md" \
  --allowedTools "Read,Write,Edit,Bash"

각 단계는 범위가 지정된 도구 권한을 받습니다. 계획 에이전트는 코드를 편집할 수 없습니다. 구현 에이전트는 웹을 탐색할 수 없습니다. 파일 경계가 분리를 강제합니다. --allowedTools 플래그가 CLI 수준에서 강제를 수행합니다. 설정 파일 없음. 플러그인 설정 없음. 호출당 하나의 플래그, 해당 단계에 필요한 권한에 정확히 범위가 지정됩니다.

주석 순환이 “더 나은 프롬프팅”과의 핵심 차별화 요소입니다. 편집기에서 계획을 검토합니다. 동의하지 않는 부분을 삭제합니다. 여백에 메모를 추가합니다. 에이전트는 주석이 달린 파일을 읽고 수정합니다. 두 가지 다른 지능(인간의 도메인 지식, 모델의 코드 생성 능력)이 동일한 문서에서 수렴하기 때문에 계획이 매번 개선됩니다.

패턴 2: 작업당 새로운 생성

for story in $(jq -r '.stories[].id' prd.json); do
  # Each story gets fresh context with a focused briefing
  criteria=$(jq -r ".stories[] | select(.id==\"$story\")" prd.json)
  state=$(git diff --stat HEAD~1)
  briefing="Git state: $state --- Story: $criteria"

  claude -p "Implement: $briefing" \
    --output-format json \
    --allowedTools "Read,Write,Edit,Bash,Glob,Grep" \
    | jq -r '.result'

  # Independent verification: never trust self-report
  python -m pytest -v
done

축적된 컨텍스트 없음. 대화 드리프트 없음. 각 에이전트는 집중된 브리핑과 함께 깨끗한 윈도우를 받습니다. --output-format json 플래그는 세션 ID를 포함한 구조화된 출력을 캡처하여, 스토리에 후속 작업이 필요할 경우 결정론적 대화 재개를 가능하게 합니다.

독립적 검증 단계는 구현 단계보다 더 중요합니다. 에이전트는 제가 팬텀 검증이라 부르는 현상을 보입니다: 실제로 실행하지 않고 테스트가 통과했다고 주장하는 것입니다. 에이전트의 컨텍스트 윈도우 밖에서 pytest를 실행하면 이 실패 모드를 완전히 제거합니다. 에이전트는 자신이 만들지 않은 결과를 왜곡할 수 없습니다.

패턴 3: 병렬 리뷰 파이프라인

diff=$(git diff HEAD~1)

# Three reviewers with independent context
claude -p "Review for bugs: $diff" --output-format json > /tmp/correctness.json &
claude -p "Review for vulnerabilities: $diff" --output-format json > /tmp/security.json &
claude -p "Review for style issues: $diff" --output-format json > /tmp/conventions.json &
wait

# Merge findings from all three
jq -s 'map(.result)' /tmp/correctness.json /tmp/security.json /tmp/conventions.json

세 개의 에이전트. 세 가지 관점. 공유 상태 제로. 리뷰어 간의 의견 불일치가 단일 리뷰어가 놓치는 바로 그 이슈를 드러냅니다. & 연산자와 wait 내장 명령이 병렬 처리를 담당합니다. 비동기 런타임 없음. 스레드 풀 없음. 오케스트레이션 프레임워크 없음. Bash 작업 제어가 그 일을 합니다.

이 패턴의 힘: 각 리뷰어가 하나의 관심사에 대해 전체 컨텍스트 윈도우를 사용합니다. 정확성, 보안, 스타일에 주의를 분산시키는 단일 리뷰어는 전용 컨텍스트를 가진 세 명의 전문가보다 성능이 떨어집니다. CLI는 각 호출이 독립적인 메모리를 가진 독립적인 프로세스이기 때문에 이 분리를 간단하게 만듭니다.

핵심 요점

에이전트 시스템을 구축하는 개발자를 위해: - 모든 에이전트 생성에 claude -p로 시작하세요. 영구 상태가 필요할 때만 MCP를 추가하세요. - 단계별로 도구 권한을 범위 지정하세요. 계획 에이전트는 읽습니다. 구현 에이전트는 작성합니다. 리뷰 에이전트는 diff를 읽습니다. - 비상태 작업에서 MCP 대신 CLI를 선택하여 토큰 오버헤드를 94% 절감하세요.³

자율 워크플로우를 확장하는 팀을 위해: - 새로운 에이전트 생성은 컨텍스트 드리프트를 방지하고 작업당 토큰 비용에 상한을 둡니다. - Remote Control은 CLI 아키텍처를 변경하지 않으면서 “비감독”을 “비동기 감독”으로 전환합니다.² - Vercel의 데이터는 직관에 반하는 결과를 입증합니다: 도구가 적을수록 성공률이 낮아지는 것이 아니라 높아집니다.⁴

에이전트 인프라를 선택하는 아키텍트를 위해: - CLI 에이전트는 기존 CI/CD, 테스팅, 배포 도구와 조합됩니다. 통합 작업이 필요 없습니다. - Unix 철학(파이프를 통한 소규모 도구 조합)은 모든 에이전트 전용 프레임워크보다 앞서고 성능도 앞섭니다.¹¹ - 10% 생산성 벽은 에이전트를 채팅 도구가 아닌 인프라로 취급하기 시작하면 무너집니다.

AI 엔지니어링 시리즈의 일부입니다. 함께 읽어보세요: 인프라로서의 Claude Code, 발톱의 해부학, 자율 루프, 그리고 10% 벽.