에이전트를 조금만 키워보면 결국 같은 벽에 부딪힙니다. 기능이 늘어날수록 시스템 프롬프트가 비대해지고, 매 요청마다 필요 없는 규칙까지 다 실어 나르느라 토큰이 새기 시작합니다. Google Developers Blog의 Developer’s Guide to Building ADK Agents with Skills(https://developers.googleblog.com/en/developers-guide-to-building-adk-agents-with-skills/)는 이 문제를 아주 실용적으로 푼 글입니다. 핵심은 Agent Development Kit의 SkillToolset을 이용해 필요한 지식만 필요한 순간에 불러오는 구조, 즉 progressive disclosure를 쓰자는 겁니다. 쉽게 말하면 “모든 설명을 항상 머리에 넣는 에이전트” 대신 “필요할 때 매뉴얼을 꺼내 보는 에이전트”를 만드는 방식입니다.
초기에는 프롬프트 한 장에 다 넣는 방식이 편합니다. SEO 체크리스트, 보안 규칙, 스타일 가이드, API 사용법, 운영 예외사항까지 한 번에 실어두면 되니까요. 문제는 규모가 커지면 이 방식이 세 가지 비용을 동시에 만듭니다.
첫째, 토큰 비용입니다. 사용자가 단순 요약만 요청해도 보안 감사 규칙까지 매번 실려갑니다. 둘째, 의사결정 노이즈입니다. 모델은 관련 없는 규칙도 같이 보게 되니 판단이 흐려집니다. 셋째, 유지보수 비용입니다. 지침 하나 바뀔 때마다 시스템 프롬프트 전체를 고쳐야 합니다.
이 글이 좋은 이유는 문제를 이론이 아니라 계층 구조로 설명한다는 점입니다. L1 메타데이터, L2 지침, L3 리소스라는 구조가 그것입니다.
모든 걸 처음부터 주지 말고, 에이전트가 먼저 “어떤 스킬이 필요한지” 고른 다음, 그 스킬의 지침과 자료를 순서대로 로드하게 만드는 겁니다. 발표 글은 대략 이런 흐름을 제안합니다.
이 구조를 쓰면 10개 스킬을 가진 에이전트도 매 요청마다 10개 전체 설명을 다 읽지 않아도 됩니다.
글에서 가장 단순한 형태는 코드 안에 바로 정의하는 인라인 스킬입니다. 예를 들어 SEO 체크리스트, 사내 문체 규칙, 리뷰 기준처럼 짧고 잘 안 바뀌는 규칙은 이 방식이 빠릅니다.
이 패턴의 장점은 속도입니다. 단점도 명확합니다. 규칙이 길어지거나 참고 자료가 붙는 순간 바로 관리가 어려워집니다. 그래서 인라인 스킬은 “짧고 안정적인 룰”에만 써야 합니다.
운영에서 진짜 많이 쓰게 되는 건 파일 기반 스킬입니다. SKILL.md에 실행 지침을 넣고, references 폴더에 스타일 가이드나 API 명세를 두는 방식입니다. 이 구조가 좋은 이유는 지침과 참고자료를 분리할 수 있기 때문입니다.
예를 들어 블로그 작성 에이전트라면 SKILL.md에는 “초안 작성 순서”를 넣고, references/style-guide.md에는 실제 문장 규칙을 넣는 식입니다. 그러면 모델은 항상 전체 스타일 가이드를 들고 다니지 않아도 됩니다. 필요한 경우에만 리소스를 불러오면 됩니다.
글은 agentskills.io 스펙을 따르는 외부 스킬 저장소도 언급합니다. 이건 생산성 면에서 확실히 매력적입니다. 다만 실무에서는 그냥 가져다 쓰면 안 됩니다. 왜냐하면 외부 스킬은 우리 팀 문체, 보안 기준, 출력 형식과 어긋날 가능성이 크기 때문입니다.
그래서 외부 스킬을 도입할 때는 최소 세 가지를 봐야 합니다.
쉽게 말해 외부 스킬은 부품이지 정책이 아닙니다. 그대로 쓰기보다 얇게 래핑하거나 검토 과정을 넣는 게 낫습니다.
이 글에서 가장 실무적으로 흥미로운 부분은 메타 스킬, 즉 새로운 스킬을 쓰는 스킬입니다. 예를 들어 에이전트가 새로운 감사 체크리스트가 필요하다고 판단하면, 스펙에 맞는 SKILL.md를 생성하고 바로 로드하는 식입니다.
여기서 중요한 건 “자기 복제” 같은 과장이 아니라, 반복되는 작업 규칙을 런타임에 문서화 가능한 형태로 캡슐화한다는 점입니다. 예를 들어 특정 고객사 온보딩 검증 규칙, 특정 산업군 규정 점검표, 특정 프로젝트용 배포 체크리스트를 한 번 생성해 재사용할 수 있습니다.
물론 이 패턴은 검토 절차 없이 바로 운영에 넣으면 위험합니다. 생성된 스킬은 사람이 승인하거나, 최소한 테스트 대화를 통과해야 합니다.
반대로 기능이 1~2개뿐인 작은 봇이라면 오히려 스킬 구조가 과할 수 있습니다. 그럴 때는 인라인 규칙 몇 개로 끝내는 게 낫습니다.
첫째, 지금 시스템 프롬프트에 들어 있는 규칙을 목록으로 쪼개세요. 둘째, 항상 필요한 것과 가끔만 필요한 것을 나누세요. 셋째, 항상 필요한 건 L1 수준으로 축약하고, 자세한 실행 규칙은 SKILL.md로 빼세요. 넷째, 긴 참고 문서는 references로 이동하세요. 다섯째, 실제 대화 로그를 기준으로 어떤 스킬이 언제 로드되는지 측정하면 됩니다.
핵심은 스킬 구조를 멋진 아키텍처로 보는 게 아니라, 토큰 낭비를 줄이고 지식 관리를 쉽게 하는 운영 장치로 이해하는 겁니다. 에이전트가 똑똑해지는 지름길은 더 긴 프롬프트가 아니라, 필요한 지식을 필요한 순간에 꺼낼 수 있는 구조입니다.
