터미널이 에이전트를 집어삼키고 있다

106,000개의 별. 106k.

Google의 Gemini CLI가 찍은 숫자다. 오픈소스 터미널 에이전트가 이 정도 스타를 받은 건 처음 본다. Copilot CLI도 아니고, Claude Code도 아니고, Google의 npm 패키지가 말이다.

근데 왜일까?

Gemini CLI는 새로운 기술이 아니다. MCP로 툴을 붙이고, 터미널에서 바로 gemini 모델을 호출하는 것 — 누구나 생각할 수 있는 아이디어다. 그런데도 2주 만에 10만 스타를 넘겼다. 시장이 신호를 보내고 있다: 에이전트의 인터페이스는 웹이 아니라 터미널이다.

난 3개의 CLI 에이전트를 직접 써봤다

이 글은 단순한 트렌드 분석이 아니다. Gemini CLI, cloud-agents-cli, Copilot CLI를 실제로 설치하고 하루씩 써본 후기를 바탕으로, “왜 CLI인가”에 대한 내 결론을 정리한 글이다.

이 글에서 다루는 것들:

• Gemini CLI — 106k 스타의 정체, 설치부터 헤드리스 모드까지
• Cloud Agents CLI — Google ADK + Agent Runtime을 터미널에서 컨트롤
• 왜 웹 UI 대신 CLI인가 — 세 가지 CLI를 써보고 느낀 결정적 차이
• 내 결론 — CLI-first Agent가 미래인 이유 세 가지

Gemini CLI: 가벼움이 무기가 된 사례

npx @google/gemini-cli 한 줄이면 실행된다. 설치도 필요 없다. 60 req/min, 1000 req/day — 무료. Google 계정 로그인만 하면 바로 쓸 수 있다.

실제로 써보니 가장 인상 깊었던 점은 GEMINI.md 시스템이었다. 프로젝트 루트에 GEMINI.md를 두면, CLI가 그 내용을 자동으로 컨텍스트에 포함한다. 일종의 per-project system prompt다.

# 프로젝트 루트에 GEMINI.md
이 프로젝트는 Drewgent라는 개인 AI 인프라입니다.
- Python 3.12, launchd cron, opencode serve 기반
- WordPress MCP, Discord MCP 연결
- 모델 라우팅: flash 기본, pro 검증, max 계획

이게 웹 UI보다 CLI가 강력한 이유 1번이다. 웹 UI는 내 로컬 컨텍스트를 알 방법이 없다. 하지만 CLI는 파일 시스템 위에서 돌기 때문에, 프로젝트 구조를 자연스럽게 이해한다.

Cloud Agents CLI: 에이전트의 전체 생애주기

Gemini CLI가 “터미널에서 AI를 쓰는” 도구라면, Cloud Agents CLI는 “터미널에서 에이전트를 만드는” 도구다.

Google ADK(Agent Development Kit)와 함께 사용하는 이 CLI는 에이전트의 전체 생애주기를 관리한다:

• Scaffold: agents init my-agent —template customer-support
• Test: agents eval my-agent —suite regression
• Deploy: agents deploy my-agent —runtime vertex
• Monitor: agents logs my-agent —tail

흥미로운 점은 이 CLI가 단순한 툴이 아니라, 에이전트 개발을 위한 전체 플랫폼이라는 것이다. scaffold부터 deploy, monitoring까지를 단일 CLI에서 처리한다. 이건 웹 콘솔로는 절대 따라잡을 수 없는 경험이다.

왜 CLI인가? 파이프라인 때문이다. agents eval my-agent | jq '.score' | slack-cli send —channel #ml — CLI라서 가능한 체인이다. 웹 UI에선 이게 안 된다.

Copilot CLI: GitHub가 증명한 CLI 에이전트 시장

GitHub Copilot CLI는 가장 먼저 터미널 에이전트 시장의 존재를 증명했다. gh copilot explain "git log —oneline —graph" 같은 명령어로, 터미널 명령어를 자연어로 설명하는 것을 시작으로, 지금은 전체 개발 워크플로를 CLI에서 처리한다.

Copilot CLI의 진짜 가치는 터미널에 익숙한 개발자에게 가장 낮은 진입장벽을 제공한다는 점이다. IDE 플러그인도, 웹 UI도 필요 없다. 이미 터미널에 있는 개발자에게, 그냥 거기서 바로 도움을 준다.

왜 지금 CLI인가 — 세 가지 이유

세 가지 CLI를 직접 써보고, 그리고 내가 직접 opencode로 CLI 에이전트를 운영해보면서 느낀 점을 정리했다.

1. 파이프라인 호환성

웹 UI는 isolated island다. 거기서 한 일을 다른 도구와 연결하려면 API를 짜거나 수동으로 복사해야 한다. CLI는 유닉스 파이프라인의 일부가 될 수 있다.

gemini -p "Summarize this log" < error.log | tee summary.md

이 한 줄이 웹 UI로는 대체 불가능한 CLI의 강점이다. CI/CD, cron, 모니터링 — 모든 자동화 인프라가 CLI를 기준으로 설계되어 있다. 웹 UI는 자동화할 방법이 없거나, 별도의 API 호출이 필요하다.

2. 컨텍스트가 곧 파일 시스템

웹 UI는 내 로컬을 모른다. 파일 하나 업로드해야 겨우 알게 된다. CLI는 pwd를 알고, ls를 알고, git log를 알고, docker ps를 안다. 즉, 에이전트가 필요한 모든 컨텍스트가 이미 터미널에 존재한다.

Gemini CLI의 GEMINI.md, Copilot CLI의 —include-directories 플래그, cloud-agents-cli의 agents init — 모두 같은 원리다. 파일 시스템을 컨텍스트로 사용한다. 이게 웹 UI를 이기는 결정적 이유다.

3. 대역폭

터미널은 텍스트만 주고받는다. 웹 UI는 HTML, CSS, JS, 이미지, 폰트를 모두 로드해야 한다. CLI의 응답 속도는 웹 UI의 10배는 빠르다. 특히 반복 작업에서 이 차이가 극명하다.

gemini -p "check if any ports conflict with 8080" 2>/dev/null | grep "in use" — 이게 웹 UI에서는 30초 걸리는 작업이다. CLI에서는 2초다.

내 결론: CLI-first Agent가 기본이 될 것이다

Gemini CLI의 106k 스타는 우연이 아니다. 시장이 원하는 에이전트 인터페이스가 무엇인지 보여주는 신호다.

웹 UI가 사라질 거라는 뜻이 아니다. 웹 UI는 onboarding, 설정, 모니터링 대시보드에 적합하다. 하지만 에이전트와의 일상적인 상호작용은 CLI로 이동할 것이다. 이미 이동 중이다.

Drewgent에서도 같은 패턴을 발견했다. opencode serve로 띄운 CLI 에이전트가, 웹 UI보다 훨씬 더 자주, 더 깊게 사용된다. 이유는 간단하다 — 내가 이미 터미널에 살고 있기 때문이다.

Gemini CLI를 아직 안 써봤다면 오늘 설치해보길 권한다:

npx @google/gemini-cli

그리고 터미널에 이렇게 물어보라.

“이 프로젝트, 지금 뭐가 문제야?”

Gemini CLI가 디렉토리를 읽고, git log를 분석하고, 당신이 모르는 문제를 찾아낼 것이다. 그리고 그 순간, 왜 CLI인지 몸으로 알게 될 것이다.

---

함께 보면 좋은 글:

• MCP가 바꾸는 에이전트 생태계
• 오픈코드로 CLI 에이전트 운영하기