에이전트에게 업무를 넘기는 것과, 에이전트가 업무를 제대로 처리하게 만드는 것은 전혀 다른 문제다. 전자는 도구를 켜는 일이고, 후자는 구조를 설계하는 일이다. 최근 세 가지 사례가 이 차이를 아주 구체적으로 보여준다.
UX 라이팅 리소스를 절반으로 줄인 팀이 실제로 한 일
maily.so 팀은 Claude Code와 Figma MCP를 엮어 서비스 전체 문구 검수 업무를 자동화했고, UX 라이팅 리소스를 50% 절감했다. 그런데 이 결과를 가능하게 한 건 Claude Code 자체가 아니다. 팀이 먼저 판단 기준을 시스템화했기 때문이다.
"친절하게 써줘"는 AI에게 통하지 않는다. 이 팀은 온보딩 메시지부터 경고 문구까지 톤을 5단계 스펙트럼으로 수치화했고, 용어집(Glossary)을 별도로 관리해 품질의 70%를 여기서 확보했다. 프롬프트에 모든 규칙을 때려넣는 대신, 원칙·사례·세션 요약을 독립된 마크다운 폴더 구조로 분리해 토큰 낭비를 줄이고 정확도를 높였다.
Figma MCP 연결이 만든 자동화 루프도 주목할 부분이다. 디자이너가 시안 링크를 넘기면 AI가 직접 Figma에 접속해 원본 복제 → TOBE 프레임 생성 → 텍스트 교체 → 변경 부분 마킹까지 수행한다. 이 과정에서 사람이 하던 반복 작업—가이드북 검색, 유사 사례 찾기, 수동 마킹, 교정 근거 작성—이 전부 사라졌다. 팀원은 맥락 판단과 최종 결정에만 집중할 수 있게 됐다.
여기서 한 가지 설계 원칙이 보인다. 팀원들과의 대화에서 반복되는 패턴을 공식 원칙(Docs)으로 승격시키는 '지식 승격' 구조다. AI가 단순 도구가 아니라 조직의 라이팅 자산과 함께 성장하도록 설계한 것이다. 이건 프롬프트 엔지니어링이 아니라 지식 관리 아키텍처다.
매번 2시간씩 날리던 에이전트 셋업을 2분으로
두 번째 사례는 더 실용적이다. Claude Code나 Codex CLI를 써본 사람이라면 매 프로젝트마다 CLAUDE.md를 처음부터 작성하고, 스택을 설명하고, 하지 말아야 할 것들을 다시 교육하는 데 상당한 시간을 쓴다는 걸 안다. shadkhan이 공개한 AI Agents Template Builder는 이 반복을 쉘 스크립트 하나로 끝낸다.
스크립트가 여섯 가지 질문(프로젝트 이름, 언어, 프레임워크/DB, 패키지 매니저, 모듈 목록, 보안 프로파일)에 답을 받으면, CLAUDE.md·AGENTS.md·SECURITY.md·테스트 전략 문서·모듈 스펙 스텁·CI/CD 워크플로우까지 전부 생성된다. 셋업 시간이 2시간에서 20분으로 줄었다고 보고한다.
이 접근법의 핵심은 보안을 기본값으로 구운 것이다. SECURITY.md는 Zod 기반 입력 검증, IDOR 방지를 위한 userId 필터 강제, JWT 패턴, rate limiting, 파일 업로드 보안까지 8개 레이어를 다룬다. 에이전트는 CLAUDE.md와 함께 이 파일을 읽고 모든 라우트 작성에 적용한다. PR 리뷰에서 인증 없는 라우트나 누락된 userId 필터를 잡는 빈도가 눈에 띄게 줄었다는 게 저자의 보고다.
테스트 전략도 5개 레이어(유닛·통합·보안·어드버셜·퍼포먼스)로 구조화되어 있고, 어드버셜 테스트는 IDOR 공격, SQL 인젝션, JWT 위조 시나리오를 에이전트가 직접 작성하게 한다. 팀 온보딩 관점에서 이 템플릿의 가치는 단순한 시간 절약이 아니다. 신규 팀원이 에이전트와 협업하는 방식 자체를 표준화한다는 점이다.
Google이 Vertex AI를 접은 이유, 그리고 '거버넌스'가 진짜 전장인 이유
2026년 4월 22일, Google은 Google Cloud Next에서 Vertex AI를 사실상 종료하고 Gemini Enterprise Agent Platform으로 전환했다. 단순 리브랜딩이 아니다. 아키텍처가 바뀌었다.
Vertex AI는 모델 선택·파인튜닝·배포를 잘 처리했지만, 수십 개 시스템을 동시에 오가는 자율 에이전트 플릿을 통제하는 문제에는 설계 자체가 맞지 않았다. 에이전트 하나를 만드는 건 이제 어렵지 않다. 수백 개의 에이전트가 무엇을 하고 있는지, 무엇에 접근할 수 있는지, 누가 승인했는지를 아는 것—그게 진짜 엔터프라이즈 블로커다.
Google의 답은 세 가지 거버넌스 레이어다. Agent Identity는 모든 에이전트에 암호화 ID를 부여해 모든 액션을 감사 가능하게 만든다(SPIFFE 포맷, IAM과 동일한 방식). Agent Registry는 기업 내 모든 에이전트·툴·스킬의 단일 인덱스로, 승인된 자산만 노출되도록 통제한다. Agent Gateway는 에이전트와 툴 간 연결을 단일 보안 레이어로 통과시키며 프롬프트 인젝션과 데이터 유출을 차단한다.
Payhawk의 Financial Controller Agent는 Memory Bank로 사용자 습관을 기억해 경비 제출 시간을 50% 이상 줄였다. PayPal은 Agent Payment Protocol(AP2)을 상거래 인프라로 라이브 배포했다. 월 6조 토큰이 ADK를 통해 처리된다는 수치는 이미 데모 단계가 아님을 보여준다.
MCP 통합도 주목해야 한다. Agent Gateway와 Agent Registry가 MCP 서버를 네이티브로 지원한다는 건, 이미 MCP 기반으로 만든 툴을 동일한 신원·정책 시스템 안으로 편입할 수 있다는 의미다.
세 사례가 가리키는 하나의 설계 원칙
세 사례는 규모와 맥락이 다르지만 같은 지점을 가리킨다. 에이전트에게 위임하려면 위임 가능한 구조가 먼저 있어야 한다.
maily.so 팀은 판단 기준을 마크다운 시스템으로 외재화했고, 템플릿 빌더는 컨텍스트 설정을 자동화 스크립트로 표준화했으며, Google은 에이전트 신원과 감사 추적을 플랫폼 레이어로 내재화했다. 접근 방식은 다르지만 논리는 동일하다. 에이전트가 올바르게 행동하게 만드는 구조를 인간이 먼저 설계해야 한다.
팀 관점에서 우선순위를 정리하면 이렇다. 지금 당장 실행할 수 있는 것은 CLAUDE.md와 AGENTS.md 작성 방식을 팀 템플릿으로 만드는 일이다. 쉘 스크립트로 초기화를 자동화하고, 글로벌 설정 파일(~/.claude/CLAUDE.md)에 개인 컨벤션을 올려두면 프로젝트마다 반복하는 시간이 사라진다. 중기적으로는 팀의 판단 기준—코드 컨벤션, 보안 룰, 테스트 전략—을 에이전트가 읽을 수 있는 구조화된 문서로 만드는 작업이 필요하다.
Google의 거버넌스 레이어는 당장 모든 팀이 적용할 수 있는 것은 아니다. 하지만 그 방향은 이미 정해졌다. 에이전트 수가 늘어날수록 '무엇을 만들었는가'보다 '무엇에 접근하고 무엇을 했는가를 통제할 수 있는가'가 팀 역량의 기준이 된다.
빠르게 움직이는 팀이 놓치기 쉬운 건 이 부분이다. 에이전트 도구를 켜는 데는 하루가 안 걸리지만, 에이전트가 팀 컨벤션을 따르고 보안 규칙을 지키고 감사 추적을 남기게 만드는 구조를 갖추는 데는 설계 시간이 필요하다. 그 구조 없이 속도만 올리면 결국 에이전트가 만든 부채를 사람이 정리하는 루프로 들어간다. 세 사례가 공통으로 보여주는 건, 그 구조를 먼저 만든 팀이 실제 리소스 절감과 품질 유지를 동시에 달성했다는 것이다.