Google Cloud가 2026년 4월 공개한 Agents CLI는 AI 에이전트 개발에서 자주 생기는 간극을 줄이려는 도구입니다. 로컬에서 만든 에이전트는 그럴듯하게 동작하지만, 평가·인프라·배포·운영으로 넘어가면 갑자기 복잡해집니다. 문서는 흩어져 있고, 클라우드 구성은 많고, coding assistant는 필요한 맥락을 찾느라 토큰을 낭비합니다. Agents CLI는 이 과정을 하나의 명령형 백본으로 묶겠다는 방향입니다.
공식 설명에 따르면 Agents CLI는 Gemini CLI, Claude Code, Cursor 같은 AI coding assistant가 Google Cloud agent stack을 기계가 읽기 쉬운 방식으로 사용할 수 있게 합니다. Agent Platform, Cloud Run, A2A Integration 같은 요소를 연결하고, create, eval, infra, deploy, publish 흐름을 CLI로 다룹니다. 예제에서는 uvx google-agents-cli setup, agents-cli create, agents-cli eval run, agents-cli infra single-project, agents-cli deploy, agents-cli publish gemini-enterprise 같은 명령이 등장합니다.
AI 에이전트 개발의 병목은 모델 호출 코드가 아닙니다. 진짜 병목은 주변부입니다. 인증은 어디서 처리할지, 세션은 어디에 저장할지, 도구 권한은 어떻게 나눌지, 평가 데이터는 어떻게 만들지, 배포 환경은 어떻게 재현할지, 장애 로그는 어디서 볼지 같은 문제입니다. 이 부분이 정리되지 않으면 에이전트는 데모에서 멈춥니다.
CLI가 중요한 이유는 반복 가능한 경로를 만들기 때문입니다. 사람이 웹 콘솔에서 이것저것 눌러 만든 환경은 재현하기 어렵습니다. 에이전트가 문서 페이지를 읽고 추측해서 만든 환경은 더 위험합니다. 반대로 CLI 명령이 정해져 있으면 coding assistant도 같은 경로를 따라 scaffold, evaluate, deploy를 수행할 수 있습니다. 사람은 명령 결과와 diff를 검토하면 됩니다.
많은 팀이 에이전트 PoC를 만들 때 로컬에서 잘 돌아가는지만 봅니다. 몇 가지 프롬프트와 도구 호출이 성공하면 “배포 가능”하다고 판단합니다. 하지만 프로덕션에서는 다른 질문을 해야 합니다. 같은 입력에 대해 결과가 충분히 안정적인가? 실패했을 때 재시도 정책은 있는가? 도구 호출이 중복 실행되면 문제가 없는가? 사용자의 민감 정보가 로그에 남지 않는가? 모델이 외부 작업을 수행하기 전에 human-in-the-loop가 필요한가?
Agents CLI의 eval 흐름이 중요한 이유가 여기에 있습니다. agents-cli eval run처럼 평가를 명령으로 실행하고, agents-cli eval compare로 두 실행을 비교할 수 있어야 변경이 개선인지 퇴보인지 판단할 수 있습니다. 단순히 “이번에는 답이 좋아 보인다”는 리뷰는 에이전트 운영에 부족합니다. 최소한 목표 trajectory, tool call sequence, 최종 답변, 실패율, 비용, latency를 함께 봐야 합니다.
Agents CLI는 사람이 직접 사용할 수도 있지만, 더 흥미로운 지점은 AI coding assistant가 CLI를 호출하는 흐름입니다. 다만 이때도 모든 권한을 열어주면 안 됩니다. coding assistant에게는 scaffold와 test까지 맡기고, infra provision이나 deploy는 사람 승인 단계를 두는 편이 안전합니다. 특히 비용이 발생하거나 외부 사용자가 접근할 수 있는 자원이 만들어지는 명령은 자동 실행 대상에서 제외해야 합니다.
좋은 운영 방식은 세 단계입니다. 첫째, agent가 프로젝트 구조와 기본 코드를 생성합니다. 둘째, agent가 평가를 실행하고 결과 요약을 남깁니다. 셋째, 사람이 diff, 권한, 비용, 배포 대상을 확인한 뒤 deploy 명령을 승인합니다. 이 구조를 쓰면 개발 속도는 올리면서도 통제권을 잃지 않습니다.
에이전트 배포 체크리스트는 일반 웹 API보다 넓어야 합니다. 모델이 판단하고 도구를 호출하기 때문입니다. 먼저 권한 경계를 봐야 합니다. 어떤 도구가 읽기 전용인지, 어떤 도구가 쓰기인지, 어떤 작업에 승인 게이트가 필요한지 구분해야 합니다. 다음은 상태 저장입니다. 세션, 메모리, 작업 큐, idempotency key가 어디에 저장되는지 확인해야 합니다. 세 번째는 평가입니다. 정상 케이스뿐 아니라 권한 없음, 외부 API 실패, 중복 webhook, 악성 입력, 긴 컨텍스트 입력을 넣어야 합니다.
네 번째는 관측성입니다. 에이전트는 최종 답변만 보면 안 됩니다. 어떤 tool을 어떤 인자로 호출했는지, 어떤 상태 전이가 있었는지, 모델 호출 비용은 얼마였는지, 사용자에게 어떤 메시지를 보냈는지 추적해야 합니다. 다섯 번째는 롤백입니다. 에이전트가 잘못된 도구 호출을 만들었을 때 코드 롤백만으로 충분한지, 이미 외부 시스템에 반영된 작업을 되돌릴 수 있는지 봐야 합니다.
처음부터 모든 에이전트를 Agents CLI 기반으로 옮길 필요는 없습니다. 반복 배포가 필요한 내부 도구 하나를 고르는 편이 좋습니다. 예를 들어 비용 리포트 승인, 고객 지원 분류, 리드 스코어링, 문서 QA 같은 업무입니다. 이 작업에 대해 create, eval, deploy 흐름을 만들고, 평가 데이터 30~50개를 먼저 쌓습니다. 그 다음 CLI 명령을 CI에 묶어 PR마다 eval을 돌립니다. 성능 기준을 넘지 못하면 배포하지 않습니다.
이때 중요한 건 프롬프트를 계속 고치는 것보다 평가 세트를 먼저 고정하는 것입니다. 기준이 없으면 coding assistant가 만든 변경이 좋아졌는지 알 수 없습니다. CLI는 자동화를 제공하지만, 무엇을 좋은 결과로 볼지는 팀이 정해야 합니다.
Agents CLI의 의미는 “명령 몇 개로 배포가 쉬워졌다”가 아닙니다. 에이전트 개발을 반복 가능한 소프트웨어 공정으로 바꾸려는 시도입니다. 실무팀이 얻어야 할 포인트는 명확합니다. AI coding assistant에게 일을 맡기려면, assistant가 따라갈 수 있는 명령형 경로와 사람이 통제할 승인 지점을 같이 설계해야 합니다.
