당신의 AI 에이전트가 돈을 낭비하고 있습니다. 그 이유와 해결책

우리는 Google의 Agent Development Kit (ADK)를 기반으로 구축해 왔으며, 대부분의 개발자가 너무 늦기 전까지는 알아차리지 못하는 문제에 직면했습니다. 바로 토큰 팽창 (token bloat)입니다.

"메가 프롬프트 (Mega-Prompt)"의 함정

AI 에이전트를 처음 구축할 때, 페르소나, 규칙, 절차, 도구 사용법, 예외 케이스 등 모든 것을 시스템 프롬프트 (system prompt)에 밀어 넣는 것이 본능적인 반응입니다. 처음에는 잘 작동합니다. 하지만 어느 순간 작동하지 않게 됩니다.

사용자가 "내 배포 상태가 어떻게 되나요?"라고 짧게 입력하더라도, 사용자가 메시지를 보낼 때마다 에이전트는 그 모든 지침을 모델에 다시 보냅니다.

만약 에이전트가 각각 약 1,000개의 토큰을 사용하는 10개의 기능을 가지고 있다면:

• 호출당 10,000개 이상의 토큰 소모
• 20회 대화 진행 시: 200,000개 이상의 토큰 소모
• 수천 명의 사용자를 대상으로 규모를 확장할 경우: 예산을 불태워 버린 셈이 됩니다.

왜 당신의 에이전트가 토큰을 낭비하는가 — ADK Skills: 점진적 공개 아키텍처 (Progressive Disclosure Architecture)

Google ADK Skills가 실제로 하는 일

ADK Skills는 필요한 경우에만 컨텍스트 (context)를 로드하는 3계층 아키텍처인 점진적 공개 (progressive disclosure) 방식으로 이 문제를 해결합니다. 이는 식당 메뉴판을 보는 것과, 주문할 때마다 모든 레시피를 전부 읽어주는 것의 차이와 같습니다.

세 가지 계층:

• L1 — 메타데이터 (Metadata, 스킬당 ~100 토큰): 스킬 이름과 설명만 포함됩니다. 항상 로드되며, 에이전트가 훑어보는 메뉴 역할을 합니다.
• L2 — 지침 (Instructions, ~5,000 토큰): 전체적인 실행 방법입니다. 에이전트가 특정 스킬이 관련 있다고 판단할 때만 가져옵니다.
• L3 — 리소스 (Resources, 필요 시): 외부 문서, 스타일 가이드, API 명세서 등이며, L2에서 이를 참조할 때만 불러옵니다.

ADK는 list_skills, load_skill, load_skill_resource라는 세 가지 도구를 자동으로 생성합니다.

ADK Skills — 3단계 점진적 공개 (Three-Tier Progressive Disclosure)

실제 사례: 온콜(On-Call) SRE 에이전트

당신이 10가지 역량을 가진 SRE 온콜(On-Call) 에이전트를 구축한다고 가정해 봅시다: PagerDuty 경고 분류(triage), 런북(runbook) 실행, Slack 장애 채널 관리, 로그 분석, 에스컬레이션(escalation) 프로토콜, 장애 후 보고서 작성, Kubernetes 상태 점검, 데이터베이스 진단, 비용 이상 징후 알림, 그리고 온콜 인수인계 요약입니다.

단일 구조(Monolithic)의 시스템 프롬프트를 사용할 경우: 누군가 단순히 "지금 누가 온콜 중인가요?"라고 물을 때조차 모든 쿼리는 약 10,000개의 토큰(tokens)을 소모합니다.

ADK Skills를 사용할 경우: 에이전트는 약 1,000개의 토큰으로 구성된 L1 메타데이터로 시작합니다. 사용자가 PagerDuty 경고에 대해 물으면 → 에이전트는 메뉴를 스캔하여 경고 분류(alert-triage)를 식별하고, load_skill을 호출하여 5,000개의 토큰 분량의 지침을 가져옵니다. 총합: 약 7,000개의 토큰입니다. 10,500개가 아닙니다.

스킬 파일 구조 (SKILL.md):

---
name: alert-triage
description: "Triages PagerDuty alerts, assesses severity,"
...

왜 당신의 에이전트가 토큰을 낭비하고 있는가 — ADK Skills: 점진적 공개 아키텍처 (Progressive Disclosure Architecture)

수치 분석 (가감 없는 진실)

스킬을 사용하면 요청당 항상 LLM 호출(LLM call)이 +1회 추가됩니다. 전체적인 트레이드오프(trade-off)는 다음과 같습니다:

에이전트 규모	단일 구조 (1회 LLM 호출)	ADK Skills (2회 LLM 호출)	토큰 절감량
3개 스킬	3,500 tokens	6,300 tokens	스킬 사용 시 −80% 손실
...

멀티 턴(Multi-turn) 대화에서 스킬의 진가가 드러납니다. 20개의 스킬을 가진 20턴의 대화 시:

• 단일 구조 (Monolithic): 20,500 × 20턴 = 410,000 tokens
• 스킬 (Skills): ~8,000 × 20턴 + 일회성 로드 = ~165,000 tokens

이는 전체 세션 동안 지속적으로 약 60%의 감소를 가져옵니다. 추가적인 왕복(round-trip) 비용은 오차 범위 수준으로 줄어듭니다.

머릿속에 각인되는 멘탈 모델 (The Mental Model That Sticks)

시스템 프롬프트 (System prompt) = 항상 눈에 보이는 화이트보드. 모든 대화의 모든 참여자가 매번 모든 내용을 보게 됩니다.

기술 (Skills) = 잘 정리된 인덱스가 있는 서류 보관함. 에이전트는 그 안에 무엇이 있는지 알고 있으며, 필요한 것만 꺼내어 작업을 수행합니다.

소규모 규모에서는 화이트보드 방식도 괜찮습니다. 하지만 프로덕션 규모(Production scale) — 수십 개의 기능, 수천 개의 대화, 멀티턴 세션(Multi-turn sessions) — 에서는 서류 보관함 방식이 매번 승리합니다.

ADK Skills Architecture — 화이트보드 vs. 서류 보관함

기술 (Skills)을 사용하지 말아야 할 때

다음과 같은 경우에는 일반적인 시스템 프롬프트를 사용하세요:

• 에이전트의 기능이 4개 이하일 때 — 2회의 호출 오버헤드(2-call overhead)를 감수할 가치가 없습니다.
• 지연 시간(Latency)에 민감한 단일 턴(Single-turn) 워크플로우를 구축할 때
• 지침(Instructions)들이 서로 깊게 의존적이며 깔끔하게 분리될 수 없을 때

exemplar.dev에서 에이전트 인프라(Agentic infrastructure)를 구축하고 있습니다. 개발자 도구, 온콜(On-call) 자동화, 또는 AI 네이티브 플랫폼을 작업 중이라면 함께 소통합시다.

편집자 주 — 일반적인 논의 용도로만 사용하십시오.

Exemplar Dev Platform 확인하기

💼 LinkedIn: Exemplar 팔로우하기