모든 SaaS가 CLI로 변모하는 이유: 에이전트 기반 개발자 인터페이스 (Agentic Developer Interfaces)의 부상

터미널을 여세요. gh pr list를 실행하세요. 이제 브라우저를 열고, GitHub에 로그인하고, 아바타를 클릭한 뒤, "Your pull requests"를 찾아 대시보드가 렌더링될 때까지 기다리세요. 첫 번째 명령은 대략 200ms가 걸렸습니다. 두 번째 작업은 4초가 걸렸고 세 번의 컨텍스트 스위칭 (Context switches)이 발생했습니다.

입력된 명령과 클릭 기반의 워크플로우 (Workflow) 사이의 이 간극 — 바로 이 때문에 당신이 의존하는 모든 SaaS 기업들이 조용히 CLI를 출시하고 있는 것입니다. 이는 파워 유저를 위한 향수 프로젝트가 아닙니다. 제품의 새로운 주요 소비자가 인간이 아니기 때문에 선택한 생존 전략입니다. 그 소비자는 문서를 읽고, API를 호출하며, 화면을 전혀 보지 않고도 명령을 체이닝 (Chaining)하는 AI 에이전트 (AI agent)입니다.

아무도 말하지 않는 GUI 세금 (GUI tax)

그래픽 인터페이스 (GUI)는 번역 계층 (Translation layer)입니다. 제품은 실제 로직 (Logic)을 소유하고 있으며, GUI는 버튼, 드롭다운, 모달을 통해 그 로직의 선별되고 정형화된 일부를 노출합니다. 사용자가 시각적으로 기능의 범위를 탐색해야 하는 비기술직 지식 노동자였을 때는 이러한 트레이드오프 (Tradeoff)가 합리적이었습니다.

하지만 LLM (Large Language Model)과의 접점에서는 살아남을 수 없습니다.

Claude Code나 Cursor 에이전트가 당신을 대신해 무언가를 수행하려 할 때 — 배포를 푸시하거나, 데이터베이스를 쿼리하거나, 이슈를 등록하거나, 설정을 리팩토링 (Refactor)할 때 — 그들은 클릭할 수 없습니다. 그들은 구조화된 텍스트를 읽고, JSON을 파싱 (Parse)하며, 셸 명령 (Shell commands)을 내보낼 수 있습니다. 마우스 호버 (Hover) 상태, 드래그 앤 드롭 (Drag-and-drop), 또는 "톱니바퀴 아이콘을 클릭한 다음 Advanced 항목까지 스크롤하세요"와 같이 요구되는 모든 것은 그들에게 보이지 않습니다. 만약 당신의 SaaS가 웹 앱 (Web app)만 제공한다면, 당신의 고객이 사용하는 에이전트들은 말 그대로 당신의 서비스를 사용할 수 없습니다.

Stripe는 이를 일찍이 알아차렸습니다. GitHub, Vercel, Fly.io, Supabase, Cloudflare, Render도 마찬가지입니다. 그들의 CLI는 사후 고려 사항이 아닙니다. 대시보드가 읽기 전용 보기 창으로 격하되는 동안, CLI는 점점 더 정전적인 인터페이스 (Canonical interface)가 되어가고 있습니다. 그 패턴은 다음과 같습니다: 모든 API 엔드포인트 (Endpoint)를 래핑 (Wrap)하는 CLI를 출시하고, 이를 주요 통합 경로로 문서화하며, 대시보드는 나중에 따라오게 만드는 것입니다.

우리가 적용해 온 경험칙(Rule of thumb): 만약 어떤 SaaS가 30초 이내에 brew install 또는 npm install -g로 설치할 수 있는 CLI를 제공하지 않는다면, 그 회사는 아직 에이전트 매개 워크플로(agent-mediated workflows)를 위한 경쟁에 뛰어들지 않은 것입니다. 이는 향후 18개월 동안 중요성이 줄어들기는커녕 더욱 커질 것입니다.

"에이전트 네이티브 (agent-native)"가 실제로 의미하는 것

CLI만으로는 충분하지 않습니다. 우리는 바이너리(binary)는 존재하지만 모든 명령어가 대화형 프롬프트(interactive prompts)를 요구하거나, 로그 파서(log parsers)를 혼란스럽게 하는 ANSI 색상 코드(ANSI color codes)를 포함하거나, 상태 메시지와 실제 페이로드(payload)가 뒤섞인 출력을 내보내는 도구들을 수없이 보아왔습니다. 그러한 CLI들은 에이전트가 stdout을 파서(parser)로 파이핑(piping)하는 용도가 아니라, iTerm에서 직접 타이핑하는 인간을 위해 설계된 것입니다.

에이전트 네이티브(Agent-native)는 구체적으로 다음과 같은 것들을 의미합니다:

• 모든 명령에 --json 옵션 제공. 예외는 없습니다. 에이전트가 TTY 형식의 테이블을 스크래핑(scrape)해야 하는 상황이 결코 발생해서는 안 됩니다.
• 멱등성(Idempotent) 작업. 동일한 명령을 다시 실행했을 때 동일한 결과가 나오거나, 구조화된 에러(structured error)와 함께 명확하게 실패해야 합니다. 에이전트는 재시도(retry)를 합니다. 재시도 시 조용히 이중 결제되거나 이중 생성되는 도구는 버그를 유발하는 주범입니다.
• 예측 가능한 종료 코드(exit codes). 성공 시 0, 실패 시 0이 아닌 값을 반환하며, 이상적으로는 특정 에러 클래스에 대해 문서화된 코드를 제공해야 합니다.
• 비 TTY(non-TTY) 모드에서의 대화형 프롬프트 금지. stdin이 터미널이 아니라면, CLI는 모든 입력에 대해 플래그(flags)나 환경 변수(environment variables)를 수용해야 합니다. 응답자가 없는 프롬프트는 에이전트를 영원히 대기 상태(hang)로 만듭니다.
• 기계가 읽을 수 있는 --help. 이는 점점 더 문서화된 OpenAPI 스타일의 명세(spec)나, 도구의 표면(tool surface)을 에이전트에 직접 노출하는 MCP 서버를 의미하게 됩니다.

이를 제대로 수행하는 기업들은 자신들의 CLI를 공개 API 계약(public API contract)처럼 취급합니다. 즉, 버전을 관리하고, 하위 호환성(backward-compatible)을 유지하며, 플래그별로 문서화합니다. 이를 잘못 수행하는 기업들은 2023년에 마케팅용 체크리스트 항목으로 CLI를 만들었을 뿐, 이후 한 번도 개선하지 않은 곳들입니다.

도구가 귀하의 에이전트 스택에 준비되었는지 평가하는 방법

우리는 우리 자신의 스택에 있는 SaaS 도구들을 다음과 같은 간단한 질문으로 감사(auditing)해 왔습니다: 코딩 에이전트가 인간의 개입(human in the loop) 없이 이 도구로 유용한 작업을 수행할 수 있는가? 다음은 우리가 실행하는 체크리스트입니다:

1. 60초 이내의 설치. brew, npm, pipx, 또는 단일 curl-to-shell 방식이어야 합니다. 설치를 위해 다운로드, 설치 마법사(installer wizard), 또는 라이선스 활성화 흐름이 필요하다면 에이전트는 여기서 멈춥니다.
2. 환경 변수 또는 일회성 login 명령어를 통한 인증. 브라우저 리다이렉트가 필요한 OAuth 흐름은 최초 설정 시에는 괜찮지만, 에이전트가 헤드리스(headless) 방식으로 사용할 수 있는 장기 생존 토큰(long-lived token)을 생성해야 합니다.
3. 모든 대시보드 동작에 상응하는 CLI 기능 존재. 클릭으로만 수행할 수 있다면