gogcli에서 gws로: REST API → CLI → AI Agent, 도구의 진화를 따라가다

들어가며

터미널을 열고 gog gmail send 한 줄이면 메일이 나가던 시절이 있었다. 브라우저를 열고 Gmail에 로그인할 필요가 없었다. 그런데 어느 날 Google이 직접 CLI를 내놓았다. 이름은 gws. "그냥 또 하나 나온 거 아냐?"라고 생각했는데, 써보니 결이 달랐다.

이 글은 gogcli에서 gws로 갈아탄 과정을 기록하면서, 그 뒤에 깔린 더 큰 흐름 — REST API → CLI → AI Agent 통합 — 을 함께 짚어보려 한다.

---

왜 CLI인가? — REST API의 불편함

Google Workspace API를 직접 쓰려면 이런 과정을 거쳐야 했다:

1. Google Cloud Console에서 프로젝트 생성
2. OAuth 2.0 자격 증명 설정
3. 토큰 발급 및 갱신 코드 작성
4. 각 API 엔드포인트마다 HTTP 요청 직접 구성
5. JSON 응답 파싱 후 원하는 정보 추출

Gmail 하나 보내려고 이 모든 걸 해야 했다. 자동화의 진입 장벽이 너무 높았다.

CLI는 이 복잡함을 한 줄로 줄여준다. 인증도 한 번만 하면 되고, 응답도 구조화된 JSON으로 바로 나온다.

---

gogcli — 커뮤니티가 먼저 만든 답

gogcli(gogcli.sh)는 Peter Steinberger가 Go 언어로 만든 Google Workspace CLI다. 2025년 말에 등장해서 빠르게 버전을 올렸다(v0.5.0 → v0.12.0이 약 2주).

사용법은 직관적이었다:

# Gmail 받은편지함 확인
gog gmail list --label INBOX --format json

# 메일 보내기
gog gmail send --to user@example.com --subject "회의록" --body "첨부 참고"

# 캘린더 일정 조회
gog calendar list --days 7

# 드라이브 파일 검색
gog drive search "분기 보고서"

좋았던 점:

• JSON 출력 — 파이프라인, 스크립트에서 바로 활용
• 직관적 명령 구조 — gog [서비스] [동작]
• CI/headless 환경 지원

아쉬웠던 점:

• 정적 명령 세트 — Google API에 새 기능이 추가되면 gogcli도 업데이트해야 했다
• 커뮤니티 프로젝트의 한계 — Google API 변경에 대한 대응 속도가 벤더 공식 도구보다 느릴 수밖에 없다

---

gws — Google이 직접 만든 "Agent-Native" CLI

2026년 3월, Google이 gws(googleworkspace/cli)를 공개했다. Rust로 작성되었고, npm으로 설치한다:

npm install -g @googleworkspace/cli

처음엔 "또 CLI 하나 나왔구나" 싶었다. 하지만 써보면 gogcli와 근본적으로 다른 설계를 발견하게 된다.

핵심 차이: Dynamic Command Surface

gogcli는 지원하는 명령이 코드에 하드코딩되어 있다. gws는 다르다. Google Discovery Service를 런타임에 읽어서 명령을 자동 생성한다. Google이 API에 새 엔드포인트를 추가하면, gws를 업데이트하지 않아도 바로 쓸 수 있다.

Google Discovery Service란?

Google은 자사 API의 모든 엔드포인트, 파라미터, 응답 형식을 JSON 스펙 문서로 공개한다. 예를 들어 https://www.googleapis.com/discovery/v1/apis/gmail/v1/rest에 접속하면 Gmail API의 전체 구조가 JSON으로 나온다 — 어떤 메서드가 있고, 각 메서드에 어떤 파라미터를 넘길 수 있는지, 응답은 어떤 형태인지가 전부 기술되어 있다.

gws는 이 Discovery 문서를 실행 시점에 가져와서 CLI 명령을 자동으로 만든다. 예를 들어 Google이 Gmail API에 drafts.create 같은 새 메서드를 추가하면, gws는 별도 업데이트 없이 다음번 실행 시 gws gmail drafts create 명령을 자동으로 제공한다. gogcli에서는 개발자가 직접 새 명령을 Go 코드로 작성하고 릴리스해야 했던 것과 대조적이다.

# Discovery 문서로부터 사용 가능한 Gmail 명령 자동 나열
gws gmail --help

# 출력 예시 (Discovery Service에서 동적 생성):
#   gws gmail users.messages.list    -- 메일 목록 조회
#   gws gmail users.messages.get     -- 특정 메일 조회
#   gws gmail users.messages.send    -- 메일 발송
#   gws gmail users.drafts.create    -- 임시보관함 생성
#   ... (API에 있는 모든 메서드가 자동으로 등장)

MCP Server 내장 — 이것이 진짜 차이

gws의 가장 큰 특징은 MCP(Model Context Protocol) 서버가 내장되어 있다는 것이다. MCP란 AI agent가 외부 도구를 자동으로 발견하고 사용할 수 있게 해주는 표준 프로토콜이다.

# MCP 서버 시작 — AI agent가 100+ 도구를 자동 발견
gws mcp

이 한 줄이면 AI agent가 Gmail, Calendar, Drive, Docs, Sheets 등 100개 이상의 skill을 동적으로 발견하고 사용할 수 있다.

실제로 어떻게 동작하나?

예를 들어 Claude Code의 MCP 설정에 gws를 등록해두면:

// claude_desktop_config.json (MCP 서버 등록)
{
  "mcpServers": {
    "google-workspace": {
      "command": "gws",
      "args": ["mcp"]
    }
  }
}

이 설정만으로 AI agent는 다음과 같은 일을 자동으로 할 수 있다:

• "오늘 받은 메일 중 중요한 거 요약해줘" → agent가 gmail.users.messages.list + gmail.users.messages.get 을 연쇄 호출하여 메일 내용을 읽고 요약
• "내일 오후 3시에 디자인 리뷰 일정 잡아줘" → calendar.events.insert 호출
• "지난주 회의록 드라이브에서 찾아줘" → drive.files.list에 검색 쿼리를 넣어 호출

핵심은, agent가 사용 가능한 도구 목록을 MCP 프로토콜로 자동 발견한다는 것이다. 개발자가 "Gmail 보내기는 이 명령으로, 캘린더 생성은 저 명령으로"라고 하나하나 알려줄 필요가 없다. gws가 Discovery Service에서 가져온 모든 API를 MCP 도구로 노출하면, agent가 알아서 상황에 맞는 도구를 골라 쓴다.

gogcli에서는 각 명령을 수동으로 tool 정의로 래핑해서 등록해야 했다. 명령이 추가될 때마다 tool 정의도 수동으로 추가해야 했고, 이건 확장성에 한계가 있었다.

---

gogcli vs gws — 한눈에 비교

항목	gogcli	gws
개발자	Peter Steinberger (커뮤니티)	Google (googleworkspace org)
언어	Go	Rust
설치	brew install steipete/tap/gogcli	npm install -g @googleworkspace/cli
명령 생성	정적 (하드코딩)	동적 (Discovery Service)
MCP 서버	없음 (외부 래핑 필요)	내장 (gws mcp)
Agent Skill 수	수동 등록	100+ 자동 노출
출시	2025년 말	2026년 3월
라이선스	MIT	Apache-2.0

gogcli가 나쁜 도구라는 뜻이 아니다. gogcli는 "개발자가 터미널에서 편하게 쓰는 도구"로서 훌륭했다. 하지만 gws는 처음부터 "AI agent가 소비하는 도구"로 설계되었다. 이 설계 철학의 차이가 결정적이다.

---

큰 그림: REST API → CLI → OpenClaw

내가 gogcli에서 gws로 갈아탄 건 단순히 "더 좋은 CLI가 나와서"가 아니다. 도구를 소비하는 주체가 바뀌고 있기 때문이다.

OpenClaw이 이 흐름을 가속시켰다

재미있는 것은 gogcli를 만든 Peter Steinberger가 OpenClaw의 창시자이기도 하다는 점이다. 그는 REST API를 CLI로 감싸고(gogcli), 그 CLI를 AI agent의 skill로 연결하는(OpenClaw) 전체 파이프라인을 직접 구축했다.

OpenClaw는 2025년 11월 Clawdbot이라는 이름으로 시작해, 2026년 1월 72시간 만에 GitHub 60,000+ stars를 달성하면서 폭발적으로 성장했다. 지금은 180,000+ stars. 이 열풍이 "AI agent가 소비하는 CLI"라는 새로운 카테고리를 만들어냈고, Google도 gws를 그 방향으로 설계한 것이다.

---

실제로 어떻게 쓰고 있나 — OpenClaw + gws

현재 OpenClaw에 gws를 연결해서 쓰고 있다. 텔레그램에서 자연어로 요청하면 AI agent가 gws CLI를 통해 Google Workspace를 조작한다.

예를 들어 텔레그램에서 이렇게 말하면:

"다음 주 월요일 오후 2시에 팀 미팅 잡고, 참석자들한테 메일 보내줘"

OpenClaw agent가:

1. Calendar API로 일정 생성
2. Gmail API로 참석자에게 초대 메일 발송
3. 결과를 텔레그램으로 요약 전달

이 모든 게 gws의 MCP 서버를 통해 이루어진다. 예전에 gogcli로 할 때는 각 명령을 OpenClaw의 tool로 일일이 등록해야 했는데, gws는 gws mcp 한 줄이면 전부 연결된다.

---

앞으로의 전망 — Agentic CLI 시대

gws가 보여준 패턴 — MCP 서버 내장, 동적 명령 생성, structured output — 은 Google만의 이야기가 아니다. 이 방향으로 모든 SaaS 벤더가 움직이고 있다.

이미 나타나고 있는 신호들:

• GitHub CLI(gh)는 이미 AI agent의 핵심 도구로 자리잡았다
• Slack, Linear, Notion 등이 MCP 서버를 공개하기 시작했다
• JetBrains 2025 조사 기준 62%의 개발자가 AI coding assistant를 사용 중
• AI agent 시장 규모는 2025년 $7.38B으로 2023년 대비 거의 2배

앞으로 SaaS를 만드는 회사라면 두 가지를 기본으로 제공해야 할 것이다:

1. Agent-Native CLI — structured JSON 출력, dynamic command surface
2. MCP Server — AI agent가 도구를 자동으로 발견하고 사용할 수 있는 인터페이스

REST API만 제공하던 시대는 끝나가고 있다. CLI도 단순히 사람용 편의 도구가 아니라, AI agent의 손과 발이 되고 있다.

---

마치며

gogcli에서 gws로의 전환은 단순한 도구 교체가 아니었다. "내가 터미널에서 쓰는 도구"에서 "AI가 대신 쓰는 도구"로 패러다임이 바뀌고 있다는 걸 체감한 경험이었다.

Peter Steinberger라는 한 개발자가 gogcli → OpenClaw이라는 경로를 직접 개척했고, Google이 gws로 그 방향을 공식화했다. 다른 벤더들도 뒤따를 것이다. 2026년은 Agentic CLI 원년으로 기억될지도 모른다.

터미널 앞에 앉아 직접 명령을 치는 시간은 줄어들고, AI agent에게 "해줘"라고 말하는 시간이 늘어나고 있다. 그 "해줘"를 가능하게 하는 것이 바로 이 Agent-Native CLI들이다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.