구글 agents-cli로 AI 에이전트 제작·평가·배포 흐름 가져다 쓰기

• 이번 글은 세 가지 AI 제품 소식을 묶었지만, 개발자 입장에서 제일 건질 건 구글의 agents-cli임

  • AI 에이전트를 만드는 것 자체보다, 만든 뒤에 평가하고 배포하고 운영하는 과정이 더 귀찮아졌다는 문제의식에서 출발함
  • agents-cli는 코딩 에이전트가 아니라, Claude Code나 Codex 같은 도구에 구글 클라우드 기반 에이전트 워크플로를 붙이는 CLI임

• 먼저 Anthropic의 Fable 5가 다시 열렸다는 소식이 있음

  • Fable 5는 보안 연구진이 안전장치를 우회하는 프롬프트를 찾아낸 뒤, 6월 12일 미국 정부의 수출 통제 대상이 됐던 모델임
  • Anthropic은 Fable 5와 상위 모델 Mythos 5를 잠시 중단했고, 6월 30일 미국 상무부가 통제를 풀면서 7월 1일 다시 접근이 가능해짐
  • 프로모션은 7월 1일부터 7월 7일 밤 태평양 시간까지고, Pro, Max, Team, 일부 Enterprise 플랜에서 주간 사용 한도의 최대 50%까지 추가 비용 없이 쓸 수 있음

• 다만 Fable 5 재개는 반갑지만 조건은 꽤 애매함

  • 웹, 모바일, 데스크톱, Claude Code 2.1.170 이상, Cowork, Claude Tag 등에서 쓸 수 있음
  • PCWorld는 원래 예고보다 기간이 절반 수준이고 50% 한도도 있어 구독자 불만이 있었다고 전함
  • 큰 프로젝트를 통째로 맡기기보다는, 평소에 막혔던 난도 높은 작업 한두 개에 몰아서 모델 체감을 해보는 쪽이 현실적임

• 두 번째 포인트는 구글이 공개한 DESIGN.md임. AI가 만드는 화면이 왜 다 비슷한지에 대한 꽤 실용적인 답임

  • AI에게 화면을 맡기면 그라데이션 버튼, 대문자 제목, 카드 레이아웃, 의미 없는 호버 효과 같은 흔한 결과물이 나오기 쉬움
  • 디자인 업계에서는 이런 결과물을 슬롭(slop)이라고 부르는데, 기능은 되지만 제품의 의도나 개성이 빠진 산출물이라는 뜻임
  • 원인은 단순함. AI가 우리 브랜드 색, 간격, 컴포넌트 규칙, 레이아웃 철학을 모른 채 웹에서 흔히 본 평균값으로 화면을 만들기 때문임

• DESIGN.md는 이 디자인 맥락을 마크다운 한 파일로 넘기는 형식임

  • 앞부분에는 색, 타이포, 모양 같은 디자인 토큰을 기계가 읽기 좋게 적음
  • 뒷부분에는 색과 간격, 레이아웃을 왜 그렇게 정했는지 사람과 AI가 함께 읽을 설명을 둠
  • 완전한 Figma 스펙이나 코드 라이브러리 명세는 아니고, 시스템의 의도를 AI에게 전달하는 쪽에 가까움

• Atlassian이 이 방식을 자기네 도구와 비교해봤는데, 결론이 꽤 현실적임

  • Team '26 대시보드 데모처럼 빠른 프로토타입에서는 DESIGN.md가 뻔한 화면을 Atlassian 스타일에 가깝게 바꾸는 데 도움이 됐음
  • Tailwind나 Shadcn 같은 공용 UI 도구를 바탕으로 새 화면을 빠르게 만들 때 특히 잘 맞았다고 함
  • 반대로 실제 프로덕션 코드에서는 기존 MCP 서버와 AI 스킬보다 못했음

• 그래서 DESIGN.md의 핵심은 “쓸까 말까”가 아니라 “언제 쓸까”임

  • 낯선 도구에서 빠르게 프로토타입을 만들거나, 고객별 브랜드 스타일을 얹어 결과물을 뽑게 할 때는 한 파일로 통째로 주는 방식이 잘 맞음
  • 이미 컴포넌트와 디자인 규칙이 갖춰진 제품에서는 필요한 맥락만 그때그때 불러오는 MCP나 스킬 방식이 더 싸고 정확할 가능성이 큼
  • 결국 맨바닥에서 화면을 그리는지, 기존 시스템 위에 얹는 작업인지부터 구분해야 함

• 마지막으로 구글의 google/agents-cli는 AI 에이전트 개발을 “만들기”에서 끝내지 않게 만드는 도구임

  • 로컬에서는 API 키만으로 만들고 돌려볼 수 있고, 실제 배포와 운영 단계에서는 구글 클라우드가 필요함
  • 아직 정식 출시 전 프리뷰 단계라 기능은 바뀔 수 있음
  • 설치는 npx skills add google/agents-cli 한 줄로 가능하다고 소개됨

• agents-cli가 흥미로운 이유는 에이전트 개발 순서를 도구 안에 박아놨다는 점임

  • 어떤 모델을 고를지, 작업 중 멀쩡한 코드를 덮어쓰지 않게 할지 같은 규칙도 같이 담김
  • 사용자는 복잡한 명령을 외우기보다 “긴 글을 짧고 툭툭 끊기는 말투로 압축하는 에이전트를 만들어줘”처럼 요청할 수 있음
  • 그러면 코딩 도구가 뼈대 생성, 평가, 배포까지 이어서 처리하는 흐름임

• 특히 평가 흐름이 꽤 제대로 잡혀 있음

  • 평가용 데이터를 만들고, 결과를 채점하고, 두 버전을 비교함
  • 실패한 케이스끼리 묶어 원인을 보고, 그 결과로 프롬프트를 자동으로 다듬음
  • 채점도 사람이 전부 보는 방식만이 아니라, 다른 모델이 답안을 매기는 LLM-as-judge 방식까지 준비돼 있음

sequenceDiagram
    participant 개발자
    participant 코딩도구
    participant 에이전트
    participant 평가모델
    participant 구글클라우드
    개발자->>코딩도구: 에이전트 제작 요청
    코딩도구->>에이전트: 뼈대 생성 및 실행
    코딩도구->>평가모델: 결과 채점 요청
    평가모델-->>코딩도구: 실패 케이스와 점수 반환
    코딩도구->>에이전트: 프롬프트 개선
    코딩도구->>구글클라우드: 배포 및 운영 연결

기술 맥락

• 여기서 중요한 선택은 에이전트 개발을 단순 생성 작업이 아니라 평가 가능한 파이프라인으로 다루는 거예요. 에이전트는 한 번 잘 대답했다고 끝나는 물건이 아니라, 입력이 조금만 바뀌어도 품질이 흔들릴 수 있거든요.

• agents-cli가 평가 데이터 생성, 채점, 버전 비교, 실패 케이스 분류를 한 흐름에 넣은 이유도 여기에 있어요. 사람이 매번 “대충 괜찮네” 하고 넘기면 운영 중에 실패 패턴을 놓치기 쉬우니까요.

• DESIGN.md와 MCP 비교도 같은 맥락이에요. 맨바닥 프로토타입에서는 디자인 맥락을 한 파일로 크게 던지는 게 빠르지만, 이미 컴포넌트와 규칙이 있는 제품에서는 필요한 맥락만 불러오는 편이 비용과 일관성 면에서 유리해요.

• 결국 AI 도구를 잘 쓰는 핵심은 모델 성능만 보는 게 아니라, 어떤 맥락을 언제 얼마나 줄지 정하는 데 있어요. 이 판단이 엉키면 토큰은 많이 쓰는데 결과물은 더 흔한 화면이나 불안정한 에이전트가 되기 쉽거든요.