Agent CLI 시대

MCP가 주목받던 시기를 지나 CLI가 다시 부상하고 있다. 왜 CLI인지, 어떤 도구를 선택해야 하는지, 그리고 결국 중요한 건 뭔지.

Agent CLI 시대

CLI가 다시 뜨고 있다

Codex CLI, Gemini CLI, Obsidian CLI. 최근 출시되는 AI 도구들의 공통점이 있다. 터미널에서 명령어를 입력하는 CLI 형태라는 것이다.

이상한 일이다. AI 시대라면 더 화려하고 편한 인터페이스가 어울릴 것 같은데, 왜 오히려 구식의 명령어 입력 방식이 부상하고 있을까.

이유는 간단하다. AI 에이전트에게 CLI가 가장 효율적인 인터페이스이기 때문이다.

MCP의 한계

AI 에이전트가 외부 도구를 사용하려면 그 도구의 스펙, 사용법, 파라미터 정보를 알아야 한다. MCP(Model Context Protocol)는 이 문제를 해결하기 위해 주목받았다.

그런데 실제로 MCP를 쓰다 보면 문제가 생긴다. 에이전트가 일할 때 모든 MCP 도구의 스펙을 상시로 들고 있어야 한다. Playwright MCP 하나만 해도 수천 토큰의 스펙을 매 요청마다 포함해야 한다. 사용할지 안 할지도 모르는 도구의 설명서를 항상 들고 다니는 셈이다.

Eric Holmes는 "MCP is dead. Long live the CLI."라는 글에서 이 문제를 정면으로 지적했다. 그가 꼽은 CLI의 강점은 다섯 가지다.

1. LLM 친숙도 — 수백만 건의 man page와 기술 문서로 학습된 LLM은 CLI를 자연스럽게 다룬다.
2. 디버깅 투명성 — 같은 명령어를 터미널에서 직접 실행해볼 수 있다. MCP는 JSON 프로토콜 로그를 뒤져야 한다.
3. 조합성 — 파이프, grep, jq와 조합이 된다. terraform show -json | jq '.resource_changes[]' 같은 게 가능하다.
4. 기존 인증 재활용 — AWS 프로파일, GitHub 토큰 등 검증된 인증 체계를 그대로 쓴다.
5. 운영 단순성 — 필요할 때 실행하고 끝. 백그라운드 프로세스가 필요 없다.

CLI 형태가 되면 에이전트는 도구의 전체 스펙 대신 간단한 설명 몇 줄만 들고 있으면 된다. 구체적인 사용법이 필요하면 --help를 실행해서 그때 확인한다. 처음부터 모든 걸 외우는 대신, 필요할 때 찾아보는 방식이다.

이건 Claude Code의 auto memory와 같은 맥락이다. 기억 전체를 상시 로딩하지 않고, 200줄 정도의 목차만 들고 있다가 필요한 기억을 그때 꺼내 쓴다.

그래서 MCP는 죽었나

아니다. 이 논쟁은 프레임 자체가 잘못됐다.

unclejobs.ai의 스레드가 이 점을 잘 짚었다. API, MCP, CLI, Skills는 대체 관계가 아니라 서로 다른 레이어에서 다른 문제를 풀고 있다.

• API — 서비스 간 통신의 기반. 엔진의 피스톤.
• MCP — AI가 외부 도구에 접근하는 표준 통로. 도로와 신호 체계.
• CLI — 사용자(와 에이전트)가 명령하는 인터페이스. 핸들과 페달.
• Skills — AI가 도구를 "잘" 쓰는 법을 아는 지식 꾸러미. 운전 교본.

핸들이 도로를 대체하지 않는다. "MCP → CLI로 진화한다"는 도로가 핸들이 된다는 말이다.

실제로 Scalekit이 CLI vs MCP 벤치마크를 75회 돌렸을 때, CLI가 10~32배 저렴하고 신뢰성 100%였다. 수치만 보면 CLI 압승이다. 하지만 Scalekit의 결론도 "그래도 MCP를 써야 할 때가 있다"였다. 벤치마크가 개발자 한 명의 개인 자동화 시나리오였기 때문이다.

멀티테넌트 환경에서는 얘기가 다르다. 수십 명의 유저를 각각 다른 권한으로 관리하려면 CLI의 환경 변수만으로는 부족하다. 유저별 OAuth, 테넌트 격리, 감사 로그 — MCP가 프로토콜 레벨에서 해결하는 문제들이다. Slack이 CLI가 아니라 MCP 서버를 공식 출시한 이유가 이거다.

그래서 판단 기준은 이렇다.

• CLI가 있는 서비스 + 개인 자동화 → CLI
• CLI가 없는 SaaS (Notion, Linear 등) → MCP
• 멀티테넌트 B2B 제품 → MCP
• 반복되는 복잡한 워크플로우 → Skills

이 넷은 동시에 존재해야 돌아간다.

실제로 쓰면서 느낀 것

나는 6개의 Google Workspace 계정을 관리한다. 대모산개발단 대표 계정, 조코딩AX파트너스 계정, 개인 계정 등. 메일 확인, 일정 관리, 문서 작업을 AI 에이전트에게 시키고 싶었다.

gws: Google 공식 CLI

처음 선택한 건 gws(Google Workspace CLI)였다. Google 개발자 팀이 만든 공식 도구다.

장점은 분명했다. Google Discovery Service를 읽어서 명령어를 동적으로 생성하기 때문에 API가 추가되면 자동 반영된다. 100개 이상의 AI 에이전트 스킬도 기본 제공한다.

문제가 하나 있었는데, OAuth 토큰이 하루에 한 번 만료됐다. AI 에이전트가 메일을 확인하려는데 "인증 만료"가 뜨면, 브라우저를 열어서 재인증을 해야 했다. 자동화의 의미가 없었다.

gogcli: 더 나은 대안

그러다 gogcli를 발견했다. "gog랑 gws 차이점이 뭐야?"라고 조사하기 시작했고, 결정적인 차이는 인증 방식이었다.

gogcli는 Google Workspace의 서비스 계정(Service Account)을 지원한다. 서비스 계정은 도메인 전체 위임(Domain-wide Delegation)을 통해 조직 내 모든 계정에 접근할 수 있고, 토큰이 자동 갱신된다. 한 번 설정하면 재인증이 필요 없다.

개인 Gmail 계정(OAuth만 가능)과 조직 계정(Service Account 가능)을 분리해서 관리할 수 있는 것도 실용적이었다.

결과적으로 지금 내 설정은 이렇다.

조직 계정 4개 → Service Account (만료 없음)
개인 계정 2개 → OAuth (자동 갱신, OS 키링 저장)

AI 에이전트가 새벽에 메일을 확인하든, 주말에 일정을 잡든, 인증 문제로 멈추는 일이 없어졌다.

agent-slack과 Telegram

Google Workspace만이 아니다. Slack도 agent-slack CLI로 자동화했다. Slack Desktop의 로컬 데이터를 자동 감지해서 인증하기 때문에 별도 설정이 필요 없다. 채널 읽기, 메시지 발송, 파일 다운로드까지 전부 CLI로 된다.

Telegram은 봇 토큰으로 연동했다. Claude Code에서 Telegram 메시지를 읽고 답장하는 게 가능해졌다.

이 도구들의 공통점은 텍스트 입출력이다. 모든 결과가 JSON이나 텍스트로 나온다. 대규모 언어 모델에게 이보다 자연스러운 인터페이스는 없다.

CLI + Skills 조합: /daily

이 CLI 도구들이 진짜 힘을 발휘하는 건 Skills와 조합할 때다.

gogcli로 6개 계정의 캘린더, 안 읽은 메일, 할 일 목록을 한 번에 조회하고, agent-slack으로 그 결과를 내 Slack DM에 보내는 /daily 스킬을 만들었다. 매일 아침 브리핑을 자동으로 받는 구조다.

gogcli (캘린더 + 메일 + 할 일) → 요약 → agent-slack (DM 전송)

gogcli와 agent-slack은 CLI(조작 레이어)다. 이 둘을 어떤 순서로, 어떤 기준으로 실행할지를 정의한 게 /daily 스킬(지식 레이어)이다. CLI만 있으면 매번 같은 지시를 반복해야 하고, 스킬만 있으면 도구에 접근할 수 없다. 둘이 합쳐져야 워크플로우가 된다.

도구의 특성을 파악하라

gws에서 gogcli로 갈아타면서 느낀 게 있다. 도구를 선택할 때 기능 목록만 보면 안 된다. 기능은 비슷해 보여도 실제 사용 환경에서의 마찰이 다르다.

gws와 gogcli는 둘 다 Google Workspace CLI다. 둘 다 메일을 보내고, 일정을 잡고, 드라이브를 관리한다. 기능만 보면 비슷하다. 하지만 AI 에이전트가 자율적으로 쓰려면, 인증이 끊기지 않는 게 기능보다 중요하다.

이건 CLI vs MCP 선택에서도, 같은 레이어 안의 도구 선택에서도 마찬가지다. MCP가 나쁜 게 아니라, CLI로 충분한 곳에 MCP를 얹으면 불필요한 복잡성이 생긴다. 같은 CLI끼리도 인증 방식 하나가 자동화의 성패를 가른다.

도구가 넘쳐나는 시대다. 새로운 게 나올 때마다 바로 달려들기보다, 잠깐 멈추고 생각할 필요가 있다.

• 이 도구가 해결하려는 문제가 내 문제와 같은가?
• 내 사용 환경(AI 에이전트, 자동화, 멀티 계정 등)에서 마찰이 어디서 생기는가?
• 같은 문제를 더 단순하게 해결하는 대안이 있는가?

생각하고 실행하라

이건 CLI 도구 선택에만 해당되는 얘기가 아니다.

바이브 코딩이 유행이다. AI에게 "이거 만들어줘"라고 하면 뚝딱 나온다. 하지만 뭘 만들어달라고 할지, 어떤 도구로 할지, 왜 이 방법인지를 결정하는 건 여전히 사람의 몫이다.

나는 gws를 1주일 쓰고 나서 gogcli로 갈아탔다. 1주일간 매일 재인증하면서 "이게 맞나?" 싶었고, 대안을 찾아보니 더 나은 선택지가 있었다. 처음부터 완벽한 도구를 고를 수는 없다. 하지만 불편함을 느꼈을 때 그냥 참지 않고, 왜 불편한지 생각하고 대안을 찾는 과정이 중요하다.

AI가 실행을 대신해주는 시대일수록, 생각의 비중은 오히려 커진다. 뭘 시킬지, 왜 시킬지, 어떤 도구로 시킬지. 실행은 빨라졌지만, 잘못된 방향으로의 실행도 그만큼 빨라졌다.

CLI가 다시 부상하는 것도 결국 같은 맥락이다. "새롭고 화려한 것"이 아니라 "적절한 것"을 선택한 결과다.

visitor@seunan.dev:~$ cat agent-cli-era
# 적절한 도구를 고르는 것도 실력이다.