Google Cloud Tech 정리

Five Skill Patterns ADK를 쓴다면 알아 둘 것

Google Cloud의 《5 Agent Skill Design Patterns Every ADK Developer Should Know》를 바탕으로 정리

왜 설계 패턴이 필요한가

SKILL.md의 YAML만 쓰면 된다고 여기기 쉽지만, 그것은 껍데기입니다. 어려운 쪽은 내용 설계입니다. 단계를 건너뛰지 않게, 넘겨짚지 않게, 매번 다른 형태로 내놓지 않게 — 어떻게 할 것인가. 그 답이 이 다섯 가지입니다.

01

다섯 가지, 한눈에

# 패턴 한마디로
01 Tool Wrapper 필요할 때만 전문 지식을 불러온다
02 Generator 템플릿으로 출력 형태를 맞춘다
03 Reviewer 체크리스트로 품질을 본다
04 Inversion 충분히 묻고 나서 손대기
05 Pipeline 단계를 무너뜨리지 않는 파이프라인

02 — Tool wrapper

Tool Wrapper

그 자리에서 전문가가 된다

문제

프레임워크 자료(FastAPI 관례, React 규약, SQL 스타일 지침…)를 전부 시스템 프롬프트에 밀어 넣으면 토큰이 불어나고 주의도 흩어집니다.

방법

SKILL.md에 '이 말이 나오면'이라는 방아쇠를 적어 둡니다. 사용자가 그 프레임워크를 꺼냈을 때만 references/에서 해당 관례를 불러옵니다.

SKILL.md → Tool Wrapper pattern 
# 방아쇠
when: 사용자가 "FastAPI" 또는 "API endpoint"를 꺼냈을 때
load: references/fastapi-conventions.md

# 에이전트의 동작
then: 불러온 관례에 따라 개발한다
       토큰을 쓰는 것은 필요할 때만

듣는 지점

컨텍스트를 어지럽히지 않습니다. 관계 있을 때만 전문 지식을 넣으므로 엉뚱한 정보에 끌려가지 않습니다.

03 — Generator

Generator

템플릿으로 형태를 맞춘다

문제

자유롭게 쓰게 하면 리포트 형태가 매번 달라집니다. 목차가 있다 없다, 세 단락이다 서른 단락이다.

방법

미리 템플릿을 두고(assets/에 둡니다), 처음부터 짜게 하는 대신 빈칸을 채우게 합니다.

assets/report-template.md 
# {{title}}

## Executive Summary
{{summary: 요점을 2~3문장으로}}

## Key Findings
{{findings: 항목별로 3~5개}}

## Risk Assessment
| 리스크 | 심각도 | 할 일 |
|---|---|---|
{{risks: 표에 넣는다}}

## Next Steps
{{actions: 우선순위대로 늘어놓는다}}

듣는 지점

형태와 내용을 떼어 놓습니다. 모델은 내용에 집중하고, 형태는 템플릿이 지킵니다.

04 — Reviewer

Reviewer

체크리스트로 본다

문제

나온 것이 '맞아 보이는데' 구멍이 있을 때가 있습니다. 가장자리 조건, 보안 확인, 팀의 약속이 빠져 있습니다.

방법

따로 세운 리뷰용 스킬을 두고, references/에서 전용 체크리스트를 불러옵니다. 한 항목씩 확인하게 하고 심각도로 나눠 보고하게 합니다.

Critical

보안 구멍, 정보 유출

Warning

성능, 손보기 쉬움

Info

스타일 제안, 정석

듣는 지점

만드는 갈래와 보는 갈래를 나눕니다. 한쪽이 손을 움직이고 다른 쪽이 검사합니다 — 코드의 PR 리뷰와 같은 모양입니다.

05 — Inversion

Inversion

충분히 묻고 나서 움직인다

문제

"사이트 만들어 줘" 한마디에 곧바로 코드를 쓰기 시작합니다. 나온 것은 바라던 것과 딴판입니다. 모델은 본래 먼저 움직이려 하기 때문입니다.

방법

행동을 뒤집습니다. 실행자가 아니라 먼저 듣는 쪽을 시킵니다. 건너뛸 수 없는 관문(non-negotiable gates)을 두고, 필요한 조건이 갖춰질 때까지 착수시키지 않습니다.

Inversion의 흐름 
✕ 보통의 에이전트
  사용자: 「사이트 만들어 줘」
  Agent  → 곧바로 React 작업을 시작한다…

✓ Inversion의 경우
  사용자: 「사이트 만들어 줘」
  Agent  → Phase 1: 듣기
           「어떤 종류의 사이트인가요」
           「누구를 위한 것인가요」
           「참고하고 싶은 모양이 있나요」
         → Phase 2: 맞춰 보기
           「정리하면 이렇습니다. 맞나요」
         → Phase 3: 착수
           개발을 시작한다

듣는 지점

먼저 물으면 지어내 메우는 일이 줄어듭니다. 손에 든 정보가 갖춰질수록 나오는 것이 좋아집니다.

06 — Pipeline

Pipeline

단계를 무너뜨리지 않는 파이프라인

문제

손이 많이 가는 일에서는 단계를 건너뛰고, 합쳐 버리고, 중간의 요긴한 데를 잊습니다. 다루는 정보가 길어지면 더 그렇습니다.

방법

스킬을 무너뜨릴 수 없는 파이프라인으로 설계합니다. 단계(phase)를 분명히 정하고, 그 사이에 관문(gate)을 둡니다. 지금 단계를 마치고 사람의 확인을 받기 전에는 다음으로 못 갑니다.

Phase 1
Research
→

Gate

→
Phase 2
Plan
→

Gate

→
Phase 3
Execute
→
Done
Verify

듣는 지점

읽을 수 없는 문장 생성을, 제어되고 되풀이할 수 있고 나중에 따라갈 수 있는 상태 기계로 바꿉니다.

07

짚어 둘 것

Progressive Disclosure(단계적으로 열기)

ADK의 SkillToolset은 필요할 때만 지시와 문맥을 불러오게 합니다. 토큰을 아끼고 초점도 지킵니다.

형태와 내용을 나눈다

SKILL.md는 표준화된 껍데기를 제공하고, 이 패턴들이 정하는 것은 '어떻게 생각하고 어떻게 움직이는가'라는 안쪽의 갈래입니다.

섞어 쓴다

섞어 쓸 수 있습니다. 파이프라인 마지막에 리뷰를 두거나, 제너레이터 앞에 Inversion을 넣어 조건을 모으거나.

08

함께 읽기

프롬프트 설계 가이드 → Claude Skills 실전 가이드 → GEO 입문 가이드 →