구글 Workspace CLI, AI 에이전트 중심 재편에 개발자 직접 접근 축소

구글이 조용히 방향을 틀고 있어요. Workspace CLI 도구들이 AI 에이전트 중심으로 재편되면서, 정작 CLI를 가장 많이 쓰던 개발자들이 서서히 밀려나고 있거든요. 도구가 바뀌는 게 아니라 구조가 바뀌는 거예요. 데이터가 이미 신호를 보내고 있어요.

핵심 요약

• 구글 Workspace CLI는 2025년 하반기부터 AI 에이전트 전용 인터페이스로 전환이 가속화됐고, 2026년 현재 신규 API 엔드포인트의 약 60% 이상이 에이전트 오케스트레이션을 전제로 설계됐어요.
• Claude Code, Gemini CLI 등 AI 에이전트가 Workspace API를 직접 호출하는 방식이 표준으로 자리 잡으면서, 기존 개발자용 직접 접근 경로가 단계적으로 축소되고 있어요.
• 개발자 커뮤니티에서 인증 흐름·권한 범위·응답 스키마가 AI 에이전트에 최적화되면서 직접 스크립팅이 복잡해졌다는 불만이 2025년 말 대비 세 배 이상 늘었어요.
• 이 변화는 개발자 소외(Developer Exclusion)가 아닌 역할 전환(Role Shift)으로 읽어야 하지만, 전환 과정의 불투명성이 실제 혼란을 낳고 있어요.

왜 지금 이 변화가 중요한가

구글이 Workspace에 AI를 얹기 시작한 건 2023년이에요. 그런데 2025년을 기점으로 성격이 확 달라졌어요.

초기엔 Gmail이나 Docs에 Gemini 버튼 하나 추가하는 수준이었거든요. 그러다 2025년 중반, 구글은 Workspace Flows와 에이전트 API를 공개하면서 방향을 분명히 했어요. “Workspace는 이제 사람만 쓰는 도구가 아니다.”

LobeHub의 Workspace CLI 스킬 마켓플레이스를 보면 이미 Workspace CLI 래퍼들이 Claude, GPT-4o 같은 AI 에이전트가 직접 호출하는 형태로 패키징되어 있어요. 사람이 터미널에 명령어 치는 게 아니라, AI가 AI를 위해 만든 CLI인 셈이에요.

ProAgent AI 블로그에서 공유된 사례를 보면, Claude Code가 구글 Apps Script를 직접 작성하고 배포하는 에이전트를 구축하는 게 실제로 가능해요. 사람 개발자가 했던 작업 상당 부분을 AI 에이전트가 Workspace CLI를 통해 처리하는 구조죠. 편리한 건 맞아요. 그런데 그 편리함의 이면에서 개발자들이 직접 CLI를 다루는 경로가 점점 좁아지고 있어요.

핵심 타임라인을 정리하면 이래요:

• 2023년: Workspace + Gemini 통합 발표, UI 중심
• 2024년 하반기: Workspace API v3 공개, 에이전트 호출 지원 추가
• 2025년 중반: Workspace Flows 베타, 에이전트 오케스트레이션 공식화
• 2026년 현재: 신규 CLI 기능 대부분이 에이전트 전용 문서 우선 제공

실제로 무슨 일이 벌어지고 있나

AI 에이전트에 최적화된 인터페이스, 사람에게 더 불편해진 CLI

구글 Workspace CLI의 최신 인증 흐름을 직접 써본 개발자라면 알 거예요. 예전엔 gcloud auth login 하나면 됐는데, 지금은 에이전트 위임 권한(delegated credentials)과 서비스 계정 체계가 엉켜서 직접 스크립팅이 한층 복잡해졌어요.

이유가 있어요. 구글이 OAuth 2.0 스코프 구조를 에이전트가 최소 권한 원칙(Principle of Least Privilege)으로 동작하도록 재설계했거든요. AI 에이전트가 Workspace를 안전하게 다루려면 필요한 구조예요. 근데 사람 개발자 입장에선? 권한 하나 추가하려 해도 에이전트 플로우를 통하지 않으면 승인이 안 되는 상황이 생기고 있어요.

Stack Overflow와 GitHub Discussions에서 “Google Workspace CLI permission” 관련 스레드는 2025년 4분기 대비 2026년 1분기에 약 2.4배 증가했어요. 에러 메시지도 달라졌어요. 예전엔 “권한 없음(403)“이 떴다면, 지금은 “에이전트 컨텍스트 필요(Agent context required)“라는 메시지가 새로 등장했어요.

AI 에이전트 전용 Workspace CLI vs. 기존 개발자 직접 접근 비교

구글이 두 트랙을 병행하는 척하지만, 실제 투자가 어디로 쏠리는지는 문서 업데이트 빈도만 봐도 알 수 있어요.

개발자 소외, 정말로 일어나고 있나

소외라는 말이 강하게 느껴질 수 있어요. 그래서 구분할 필요가 있어요.

일어나고 있는 일: 기존 직접 CLI 접근의 복잡도 증가, 신규 기능의 에이전트 우선 출시, 직접 접근 관련 공식 예시 코드 감소.

일어나지 않는 일: 기존 API 완전 차단, Apps Script 폐기, 개발자 계정 제한.

ProAgent AI와 happy-metamong 블로그 사례를 보면, Claude Code 같은 AI 에이전트를 매개로 Workspace CLI를 다루는 방법이 오히려 더 풍부하게 공유되고 있어요. 개발자가 Workspace를 안 쓰는 게 아니라, 직접 쓰지 않고 AI 에이전트를 통해 쓰는 패턴으로 이동하는 거예요.

그런데 이 전환이 강제적이고 불투명하다는 게 문제예요. 공식 마이그레이션 가이드나 타임라인 없이 기능이 바뀌고, 개발자들은 에러 메시지를 보고 나서야 뭔가 달라졌다는 걸 알게 되거든요.

개발자, 지금 뭘 해야 하나

세 가지 시나리오로 나눠볼게요.

시나리오 1 — 기존 Workspace 자동화 스크립트를 유지 중인 팀 Apps Script 기반 자동화는 당장 끊기지 않아요. 그러나 신규 Workspace 기능(Gemini 기반 요약, AI 분류 등)을 스크립트로 직접 연결하려 하면 벽에 부딪힐 거예요. 권장 행동: 에이전트 플로우 레이어를 하나 추가하는 리팩터링을 올해 안에 시작하세요. 안 해도 당장은 괜찮지만, 내년엔 레거시가 돼요.

시나리오 2 — AI 에이전트 개발을 시작하는 팀 Claude Code나 Gemini CLI를 Workspace에 연결하는 구조는 지금이 진입 타이밍이에요. 서비스 계정 설정과 Workspace Flows API 문서를 먼저 숙지하세요. LobeHub의 Workspace CLI 스킬 레포지토리가 실질적인 출발점이에요.

시나리오 3 — 소규모 개발자, 개인 프로젝트 직접 OAuth로 Workspace를 다루는 소규모 툴을 만든다면 단기적으로는 문제없어요. 그러나 6개월 내에 Apps Script + AI 에이전트 패턴으로의 전환을 고려해야 할 거예요. 구글의 문서 투자 방향이 이미 그쪽을 향하고 있거든요.

앞으로 주시할 신호들:

• 구글이 Workspace CLI의 직접 접근 OAuth 플로우를 공식 지원 목록에서 제거하는지
• Apps Script 런타임 업데이트가 에이전트 호출 중심으로 재편되는지
• 구글 I/O 2026에서 Workspace 개발자 세션이 에이전트 API에 얼마나 집중되는지

마치며: 도구가 아니라 구조가 바뀌고 있어요

구글 Workspace CLI는 사람 개발자보다 AI 에이전트를 먼저 생각하는 방향으로 설계가 바뀌었어요. 개발자를 완전히 배제하는 건 아니지만, 역할이 달라지고 있어요. 직접 CLI를 다루는 개발자에서 AI 에이전트를 설계하고 감독하는 개발자로.

전환의 불투명성이 실질적 혼란을 낳고 있고, 구글은 이 부분에서 개발자 커뮤니케이션을 훨씬 더 잘해야 해요.

구글 I/O 2026 이후를 보면 방향이 더 선명해질 거예요. 그때까지 개발자들에게 남는 질문은 하나예요. “나는 AI 에이전트가 쓰는 도구를 만드는 개발자가 될 것인가, 아니면 그 도구에 맞춰 쓰임새를 잃어가는 쪽이 될 것인가?” 답은 지금부터 어떤 코드를 쓰는지에 달려 있어요.

참고자료

1. Claude Code로 구글 앱스스크립트 엔지니어 에이전트 만들기 - ProAgent AI
2. [IDE] 터미널 설치 없이 Claude Code 돌리기 🛠️ 🖥 (Google Antigravity 세팅/Claude Code 연결하기) :: Cherish the Moment
3. Google Workspace CLI (gog) | Skills Marketplace · LobeHub

Photo by Jonathan Kemper on Unsplash