필자는 해외 AI 관련 뉴스를 매일 1건씩 검증하여 발신하는 도전의 15일차로, Google이 공개한 google/skills를 실제로 설치하고 작동시켜 보았다. Google Cloud/Ads/Analytics 등의 공식 Agent Skills를 모은 리포지토리(Apache-2.0)이며, 본고 작성 시점에는 skills/ 아래에 155건, 플러그인 내에 5건, 총 160건의 SKILL.md가 수록되어 있다. 필자가 검색한 범위에서는 Zenn, Qiita, note 어느 곳에서도 일본어 원문 소개 기사는 발견되지 않았다(2026-10-12 기준).
13일차에는 anthropics/knowledge-work-plugins (Anthropic 공식 플러그인 모음)을 검증했다. 이번에는 같은 '공식 배포 Agent Skills'라는 기반 위에서, 양쪽의 배포 방식, 구성, 도입 경험이 어떻게 다른지를 실측하여 비교한다.
결론부터 말하자면, google/skills의 finding-google-skills 스킬은 내용물이 없는 '검색 라우터'이며, 실행 시 index.json (155건 분량의 메타데이터)을 네트워크를 통해 가져와 해당되는 스킬만 추가로 가져오는 설계였다. 같은 질문을 '라우터 없음'과 '라우터 있음'으로 던져 비교했을 때, 라우터가 있는 쪽만이 'Cloud Run 단독으로는 Quality 관련 알림이 작동하지 않는다 (Vertex AI Online Monitors 의존적이기 때문)'라는, 일반적인 지식으로는 나오지 않는 구체적인 제약을 정확하게 도출해냈다.
google/skills란 무엇인가
공식 README에 따르면, 본 리포지토리는 Google Cloud/Gemini 관련 제품을 위한 Agent Skills와 플러그인을 모은 공식 리포지토리이다. 구성은 크게 두 가지로 나뉜다.
skills/ (155건): ads, analytics, cloud, developers, identity의 5개 카테고리로 나뉘어 있는 순수 SKILL.md 파일들. 슬래시 커맨드는 없으며, '읽고 따르기만 하는' 문서형 스킬이다.plugins/ (2건, 5스킬 내포): .claude-plugin/plugin.json, gemini-extension.json, .codex-plugin/plugin.json을 동봉하여 Claude Code/Gemini CLI/Codex 각각에 대응하는 멀티 타겟 구성이다. google-cloud-developer 플러그인은 developer-knowledge라는 MCP 서버 (google_credentials 인증 필수)도 동봉하고 있었다.
라이선스는 리포지토리 직하단에 LICENSE가 하나만 있으며, README의 '## License' 절에
하위 파일 수(155개)와는 일치하지만, plugins/
하위에 포함된 5개는 제외하는 것이었다. 즉 이 CLI의 발견 대상은 skills/
디렉터리의 순수한 SKILL.md만이며, 플러그인 내부의 SKILL.md는 CLI의 검색 및 설치 대상에서 제외된다.
day-013(anthropics/knowledge-work-plugins)와의 비교
| 관점 | anthropics/knowledge-work-plugins (day-013) | google/skills (day-015) |
|---|
| 도입 명령어 | Claude Code 내장 플러그인 메커니즘(claude plugin marketplace add → claude plugin install) | 서드파티 CLI npx skills add (SKILL.md 단위, -s로 개별 선택 가능) |
| 도입 단위 | 플러그인 단위(스킬+슬래시 명령어+HTML 대시보드의 세트) | SKILL.md 단위. 슬래시 명령어는 기본적으로 없음 |
| 구성 | 11종의 플러그인, 각 플러그인은 2~몇 개의 스킬+슬래시 명령어 | 155개의 순수 스킬+2개의 멀티 에이전트용 플러그인(MCP 서버 포함) |
| 로드 방식 | 상주(로컬 파일로서 처음부터 읽힘) | 온디맨드(finding-google-skills와 같은 일부 스킬은 실행 시 네트워크에서 index.json을 가져옴) |
| 라이선스 | Apache-2.0, 단일 LICENSE | Apache-2.0, 단일 LICENSE(동 방식) |
대상 독자라는 관점에서 볼 때, anthropics 버전은 '사용자의 로컬 디렉터리에 기억/태스크를 쌓는 개인용 지식 작업 보조', google 버전은 '제품 문서를 필요할 때 끌어오는 클라우드 제품의 의사결정 지원 카탈로그'라는 점에서, 같은 '공식 Agent Skills 배포'임에도 설계 사상이 대조적이었다.
finding-google-skills
루터의 효과를 Before/After로 측정하기
검증: finding-google-skills
자체적으로 콘텐츠를 가지고 있지 않은 루터이므로, 효과를 측정하려면 실제로 작동시켜 비교하는 것이 가장 이해하기 쉽다. day-013과 동일한 방식으로(claude -p
비대화 모드, 부모 세션의 환경 변수를 env -u
로 분리하여 독립시킴) 동일한 질문을 '루터 없음・도구 금지'와 '루터 있음・Skill/curl만 허용' 두 가지 조건으로 던졌다.
질문문(공통):
I have an AI agent instrumented with OpenTelemetry deployed on Cloud Run. I want to set up monitoring alerts for it covering latency, errors, cost, safety, and quality. According to official Google guidance, what alerts should I configure, in what output format, and are there any caveats?
Before: 루터 없음, 도구 금지
env -u CLAUDE_CODE_SESSION_ID -u CLAUDE_CODE_REMOTE_SESSION_ID -u CLAUDE_CODE_CHILD_SESSION \
-u CLAUDE_CODE_MESSAGING_SOCKET -u CLAUDE_CODE_MESSAGING_TOKEN \
claude -p "(위 질문 + Do not use any tools, just answer in plain text from what you know.)" \
...
응답의 시작 부분(전체 내용은 experiments/day-015/logs/before_run.json):
I don't know of a single Google document that prescribes an official alert list and output format for this setup, and I'd rather not invent one.
그 후에는 Cloud Run 내장 메트릭이나 OTel의 GenAI Semantic Convention을 추론하여, 범용적인 알림(PromQL/MQL 또는 YAML/Terraform) 초안을 제시했습니다. Quality에 대해서는 '평가 파이프라인을 직접 구축해야 하며, 그대로는 작동하지 않는다'라는 일반론으로 끝났습니다. 환각은 아니었지만 솔직한 선행 설명이었고 구체성은 부족했습니다.
finding-google-skills
설치된 Skill/curl만 허용
After:
env -u CLAUDE_CODE_SESSION_ID -u CLAUDE_CODE_REMOTE_SESSION_ID -u CLAUDE_CODE_CHILD_SESSION \
-u CLAUDE_CODE_MESSAGING_SOCKET -u CLAUDE_CODE_MESSAGING_TOKEN \
claude -p "(동일한 질문 + use the Skill tool / any skill you have access to, and Bash only for \..."
응답 시작 부분(전체 내용은 experiments/day-015/logs/after_run.json):
This comes from Google's published skill
agent-platform-alert-configuration
, from the google/skills catalog. I also checked cloud-run-alert-configuration.
이번에는 구체적으로 다음 내용을 정확하게 추출했습니다.
12개의 정책을 5개 카테고리로 '정확히(exactly)' 지정(Reliability 5건・Cost 1건・Safety 1건・Quality 3건・Security 1건)이라는, 스킬 본문의 규칙 그대로입니다. -
출력 형식은 Terraform만, Reliability 계열은 PromQL, Safety/Security 계열은 SQL(condition_sql, provider 6.0.0 이상 필요) 등 언어의 구분 사용. -
가장 중요한 주의사항(caveat):
'Quality 알림은 Cloud Run에서 작동하지 않는다'. Reliability/Cost/Safety/Security는 범용 OTel 메트릭으로 Cloud Run 등 어떤 런타임에서도 작동하지만, Quality는 Vertex AI Online Monitors에 엄격하게 연결되어 있어 Cloud Run 단독으로는 작동할 수 없다는, 스킬 본문의 description에 적힌 제약 조건을 그대로 정확히 인용했습니다. Before 답변은 '평가 파이프라인을 직접 제작해야 한다'라는 일반론에 그쳤고, Vertex AI 의존성이라는 구체적인 제품적 이유까지는 언급하지 않았습니다. -
cloud-run-alert-configuration
이라는 별도의 스킬 존재에도 알아차리고, Cloud Run 자체의 인프라용 알림(5xx 가용성 SLO・P95/P99 지연 시간 등)과의 역할 분담을 설명했습니다.
실행 메타정보를 비교해 보면, Before는 num_turns=1(도구 호출 0회)인 반면, After는 num_turns=5이고, total_cost_usd도 Before의 0.076달러에서 After의 0.172달러로 증가했습니다. 이는 index.json(약 75KB, 155건 분량의 메타데이터)을 가져오는 → 필터링하는 → 해당되는 2개 스킬의 SKILL.md를 추가로 가져오는 등 여러 단계가 실제로 발생했기 때문입니다.
검증 범위에서 제외한 것
agent-platform-alert-configuration
스킬 자체는 Python 보조 스크립트 실행・GCP 프로젝트 ID 필수・과금 명시 확인 필수・Terraform lint까지 요구하는 무거운 설계이며, 실제로 알림을 배포하는 과정은 유료 GCP 리소스 생성을 수반합니다. 이 챌린지의 방침(유료 API 키・GCP 리소스 생성 전제하지 않음)에 따라, 이번에는 '정확하게 라우팅되고 올바른 내용을 읽어낼 수 있는지'라는 읽기 부분만을 검증 범위로 삼았습니다. 마찬가지로, google-cloud-developer 플러그인의 developer-knowledge MCP 서버는 google_credentials 인증이 필수적이므로 미검증했습니다.
요약
google/skills를 설치하고 finding-google-skills 라우터의 효과를 실측했습니다. 내용물이 없는 라우터 하나가 네트워크를 통해 올바른 스킬을 가져오고, 'Quality 관련 알림은 Cloud Run 단독으로는 작동하지 않는다'라는 구체적인 제품 지식을 정확하게 도출하는 것을 확인할 수 있었습니다. day-013의 anthropics/knowledge-work-plugins가 '로컬에 상주하는 개인용 기억'이었다면, google/skills는 '필요할 때마다 네트워크에서 가져오는 제품 카탈로그'라는 대조적인 설계였으며, 이는 같은 '공식 Agent Skills'이라는 틀 안에서도 흥미로운 차이점이었습니다.
v1.1.0
논의
