Agent Skills: 에이전트 절차기억을 코드처럼 관리하는 법

문서 성격 이 문서는 원문 「Agent Skills」의 1장부터 Appendix B까지를 한국어 강의·실무 활용에 맞게 재구성한 통합 정리본입니다. 장별 반복 설명은 줄이고, 핵심 개념·운영 원칙·평가 체계·실무 체크리스트를 MECE 구조로 재배치했습니다. 번역 및 편집 기준: 직역 30% / 의역 70%, 전문성 유지, 한국어 자연스러움 우선, 핵심 기술 용어는 영문 병기.

원문: Agent Skills, May 2026 · Authors: Tanvi Singhal, Gabriela Hernandez Larios, Debanshu Dus, Lavi Nigam, Smitha Kolan

목차

0. 한눈에 보는 Executive Summary

1. MECE 구조 지도

2. 용어 통일표

3. 통합 번역·정리본

   3.1 Agent Skills의 정의와 문제의식

   3.2 Skill 구조와 첫 Skill 만들기

   3.3 빠른 확산의 이유와 멀티 에이전트와의 관계

   3.4 Skill 평가 체계

   3.5 프로토타입에서 프로덕션으로

   3.6 메타 스킬과 자기 개선형 Skill

   3.7 Skills 조합과 패키징

   3.8 수많은 Skill 중 무엇을 선택할 것인가

   3.9 결론: 형식은 정착, 일은 시작

4. Appendix A 통합 실무 치트시트

5. Appendix B 리테일 사례 연구

6. 강의용 요약 패키지

7. 실무 적용 체크리스트

8. 한눈에 보는 Executive Summary

한 문장 핵심**:** Agent Skill은 에이전트가 필요한 순간에만 특정 업무 수행법과 조직 지식을 불러오게 하는 폴더 기반 절차기억 단위다.

핵심 질문	통합 답변
Agent Skill은 무엇인가?	SKILL.md를 중심으로 scripts/, references/, assets/를 선택적으로 포함하는 폴더다. 에이전트에게 특정 업무를 어떻게 수행할지 알려 주는 절차기억 역할을 한다.
왜 중요한가?	거대한 시스템 프롬프트에 모든 지시를 넣을 때 생기는 컨텍스트 로트와 멀티 에이전트 운영 과부하를 줄인다.
어떻게 작동하는가?	메타데이터는 항상 가볍게 보이고, Skill 본문과 리소스는 트리거될 때만 단계적으로 로드된다. 이것이 점진적 공개다.
어떻게 검증하는가?	Trigger, Execution, Regression, Token Budget 네 조건을 모두 평가해야 한다. 테스트 없는 Skill은 역량이 아니라 희망사항이다.
프로덕션에서 무엇이 자산인가?	범용 런타임은 점점 코모디티화된다. 장기 자산은 회사의 절차와 판단을 담은 Skill 라이브러리다.

핵심 메시지 7개

1. Skill은 “무엇을 아는가”가 아니라 “어떻게 하는가”를 저장한다.

2. description 필드는 Skill 선택을 결정하는 라우팅 알고리즘이다.

3. 점진적 공개는 사용 가능한 역량은 넓히고 활성 컨텍스트는 작게 유지한다.

4. 많은 시스템은 “멀티 에이전트”보다 “단일 에이전트 + Skill 라이브러리”로 단순화할 수 있다.

5. Skill 평가는 최종 출력뿐 아니라 도구 호출 궤적까지 포함해야 한다.

6. 메타 스킬은 유망하지만 평가 게이트가 없으면 자기 개선이 아니라 자기 악화가 된다.

7. 조직 지식은 문서가 아니라 버전 관리·테스트·거버넌스 가능한 Skill 라이브러리로 축적해야 한다.

8. MECE 구조 지도

원문의 장별 구성을 중복 없이 재배열하면 다음 네 축으로 정리된다. 각 축은 서로 겹치지 않으면서 전체 논지를 포괄한다.

MECE 축	포함 장	핵심 내용	강의 키워드
A. 개념과 구조	1~2장	Agent Skills의 정의, 폴더 구조, 점진적 공개, 첫 Skill 작성법	절차기억, SKILL.md, description
B. 채택 이유와 설계 선택	3장	멀티 에이전트 과부하를 줄이고, 단일 에이전트가 여러 전문 역할을 수행하게 하는 방식	운영 부담, 단일 에이전트+Skills
C. 평가와 프로덕션화	4~5장	Trigger/Execution/Regression/Token Budget 평가, 프로덕션에서의 컨텍스트 오버플로와 Skill 단위 개선	평가 커버리지, EDD, 토큰 예산
D. 진화와 거버넌스	6~8장	메타 스킬, Skill 조합, Capability Profiles, Skill 선택·감사·버전 고정	메타 스킬, DAG, 공급망 보안
E. 실천과 사례	9장, Appendix A/B	작게 시작하고, 코드처럼 다루며, 리테일 사례처럼 조직 지식을 Skill 라이브러리로 축적	치트시트, Read/Draft/Act, 전략 자산

중복 제거 원칙

용어 설명은 장마다 반복하지 않고 “용어 통일표”에 모았다.

점진적 공개, 컨텍스트 로트, 평가 커버리지는 여러 장에서 반복되므로 각각 개념·평가·운영 파트에 한 번씩만 배치했다.

각 장은 “핵심 논지 → 실무 원칙 → 강의 포인트” 순서로 정리했다.

사례와 체크리스트는 본문 설명과 분리해 Appendix A/B와 강의용 요약에 재배치했다.

2. 용어 통일표

원문 용어	통일 번역	사용 기준
Agent Skill	Agent Skill / 에이전트 스킬	문서 전체 핵심 고유 개념. 첫 등장 후에는 Skill로 줄여 쓴다.
Skill	Skill / 스킬	폴더 기반 업무 수행 단위. 일반 명사처럼 쓰일 때도 영문 유지.
SKILL.md	SKILL.md	Skill의 핵심 지침 파일. 파일명은 번역하지 않는다.
progressive disclosure	점진적 공개	필요한 정보만 단계적으로 로드하는 구조.
procedural memory	절차기억	업무를 단계별로 수행하는 방법에 대한 기억.
context rot	컨텍스트 로트 / 맥락 품질 저하	컨텍스트가 길고 혼탁해지며 모델 성능이 떨어지는 현상.
description field	description 필드	Skill 라우팅을 결정하는 설명. “라우팅 알고리즘”으로 취급.
trigger	트리거 / 활성화 조건	Skill이 로드되어야 하는 조건.
anti-trigger	비활성화 조건	Skill이 켜지면 안 되는 조건.
MCP	MCP	외부 시스템에 도달하게 하는 연결 계층. Skill과 경쟁하지 않고 조합된다.
AGENTS.md	AGENTS.md	프로젝트 전역 지침을 담는 항상 로드되는 파일.
Eval coverage	평가 커버리지	Trigger, Execution, Regression, Token Budget을 모두 검증한 상태.
tool trajectory	도구 호출 궤적	도구를 어떤 순서와 방식으로 호출했는지의 실행 경로.
LLM-as-Judge	LLM-as-Judge / 심판 LLM	LLM이 루브릭에 따라 산출물을 평가하는 방식.
Canary / Shadow Mode	카나리 / 섀도 모드	실제 배포 전 제한 트래픽 또는 비가시적 병렬 실행으로 검증하는 방식.
token budget	토큰 예산	모델 앞에 놓을 수 있는 활성 컨텍스트 자원.
active context	활성 컨텍스트	현재 모델 입력에 실제로 들어가 주의력을 소비하는 정보.
meta-skill	메타 스킬	다른 Skill을 작성·평가·개선하는 Skill.
DAG orchestration	DAG 오케스트레이션	유향 비순환 그래프 기반 실행 조율.
Capability Profile	Capability Profile / 역량 프로필	실행 상태별 Skill, 도구, 지침, 파라미터 묶음.
Context Debt	컨텍스트 부채	지시문 과잉으로 생기는 주의력 낭비와 유지보수 비용.
first-party skill	1st-party 벤더 Skill / 공식 벤더 Skill	도구나 플랫폼 제공자가 직접 만든 Skill.
pinning	버전 고정	의존하는 Skill을 특정 버전으로 묶어 변경 위험을 줄이는 방식.
Read / Draft / Act	읽기 / 초안 / 실행 사다리	Skill 권한과 검토 수준을 나누는 거버넌스 모델.
Domain Expertise as Code	코드로서의 도메인 전문성	조직의 업무 판단과 절차를 코드처럼 버전 관리하는 접근.

3. 통합 번역·정리본

아래 본문은 원문의 장별 내용을 그대로 반복 번역하지 않고, 강의와 실무 적용에 필요한 흐름으로 재정렬한 통합 정리본이다.

3.1 Agent Skills의 정의와 문제의식

Agent Skills는 에이전트에게 지식과 회사 고유의 맥락을 갖추게 하는 방식이다. 하나의 Agent Skill은 SKILL.md 파일을 포함한 폴더이며, 필요에 따라 scripts/, references/, assets/ 디렉터리를 함께 포함한다. 이 구조는 범용 에이전트를 필요할 때마다 특정 업무 전문가로 바꾸어 주는 가벼운 기본 구성 단위다.

문제	Skill의 해법
지시가 많아질수록 결과가 나빠진다	모든 지시를 시스템 프롬프트에 넣지 않고, 필요한 Skill만 로드한다.
LLM은 “어떻게 하는가”를 잘 기억하지 못한다	절차기억을 SKILL.md와 보조 리소스로 구조화한다.
멀티 에이전트가 과도하게 복잡하다	많은 경우 단일 범용 에이전트가 여러 Skill을 오가며 전문 역할을 수행한다.
벤더와 플랫폼이 계속 달라진다	폴더와 마크다운 기반 구조라 파일 시스템 접근만 있으면 이식성이 높다.

강의 포인트: Agent Skill을 “프롬프트 조각”이 아니라 “절차기억을 담은 가벼운 소프트웨어 패키지”로 설명하면 이후 평가·운영·거버넌스 논지가 자연스럽게 연결된다.

3.2 Skill 구조와 첫 Skill 만들기

Skill을 만드는 길은 두 가지다. 첫째, 도메인 전문가가 이미 가진 런북, 가이드, 조직 지식을 에이전트가 사용할 수 있는 형식으로 바꾼다. 둘째, 에이전트가 성공적으로 수행한 반복 가능 워크플로를 Skill로 결정화한다. 두 경로의 산출물은 동일하게 SKILL.md를 중심으로 한 Skill 폴더다.

cafe-preparation/

├── SKILL.md          # 필수: 메타데이터 + 지침

├── scripts/          # 선택: 결정론적 실행 코드

├── references/       # 선택: 필요할 때만 로드하는 도메인 지식

└── assets/           # 선택: 템플릿, 스키마, 리소스

핵심은 점진적 공개다. 이름과 description 같은 메타데이터는 항상 가볍게 노출되지만, SKILL.md 본문은 Skill이 트리거될 때만 로드된다. scripts, references, assets는 본문이 실제로 필요로 할 때만 사용된다. 따라서 100개의 Skill을 설치해도 매 턴마다 전체 본문 비용을 지불하지 않는다.

작성 요소	실무 기준
이름	디렉터리는 snake_case, Skill 이름은 kebab-case, 가능하면 동명사형을 쓴다. utils나 tools처럼 일반적인 이름은 피한다.
description	무엇을 하는지, 언제 쓰는지, 언제 쓰면 안 되는지를 명확히 쓴다. 이것이 라우팅 알고리즘이다.
scripts/	파싱, 계산, 포맷 변환처럼 결정론적인 작업을 넣는다. 모델은 결정하고 스크립트는 실행한다.
references/	Skill이 실행된 뒤에야 필요한 도메인 원칙, 정의, 예외 처리를 둔다.
assets/	출력 템플릿, 스키마, 설정 파일을 둔다.

3.3 빠른 확산의 이유와 멀티 에이전트와의 관계

Agent Skills가 빠르게 확산된 이유는 운영 복잡성을 줄이기 때문이다. 반복적인 백오피스 자동화를 만들 때 과거에는 라우터 에이전트와 여러 하위 전문 에이전트를 배치하는 멀티 에이전트 구조를 기본 선택지로 삼기 쉬웠다. 하지만 이는 배포, CI/CD, 라우팅, 평가 표면을 크게 늘린다.

설계 선택지	장점	주요 위험
하나의 거대 컨텍스트	구현이 단순하다	컨텍스트 로트와 토큰 비용이 즉시 커진다.
RAG over Runbooks	문서를 검색해 활용할 수 있다	벡터 DB, 임베딩, 청킹 전략 운영 부담이 생긴다.
프로세스별 하위 에이전트	역할 분리가 명확하다	배포와 평가 표면이 폭증한다.
하나의 에이전트 + 여러 Skills	절차를 폴더 단위로 확장하고 필요한 것만 로드한다	description 품질과 평가 체계가 중요해진다.

Skills가 멀티 에이전트를 없애는 것은 아니다. 실제 병렬성, 권한·보안 경계, 이기종 모델, 상호 견제 구조가 필요할 때는 멀티 에이전트가 여전히 적합하다. 다만 많은 시스템은 처음부터 멀티 에이전트로 복잡하게 설계할 필요 없이, 단일 에이전트와 Skill 라이브러리로 우아하게 단순화할 수 있다.

3.4 Skill 평가 체계

테스트가 없는 Skill은 역량이 아니라 희망사항이다**.** Skill은 잘못 설계되면 성능을 개선하는 것이 아니라 오히려 떨어뜨릴 수 있다. 따라서 모든 Skill은 네 가지 실패 모드를 기준으로 평가되어야 한다.

실패 모드	의미	평가 방법
Trigger Failure	잘못된 Skill이 켜지거나, 맞는 Skill이 켜지지 않는다	긍정/부정 트리거 테스트와 라우팅 로그 확인
Execution Failure	Skill은 켜졌지만 출력이나 도구 호출이 틀린다	골든 데이터셋, 도구 호출 궤적 검증, LLM-as-Judge
Token Budget Failure	Skill 본문이 커서 다른 턴의 성능을 떨어뜨린다	5~15개 Skill 동시 로딩 조건에서 평가
Regression	새 Skill이 기존 Skill의 라우팅이나 실행을 깨뜨린다	전체 라이브러리 평가 스위트 실행

평가는 최종 출력만 보아서는 부족하다. 특히 실행 허용형 Skill에서는 도구를 어떤 순서와 방식으로 호출했는지, 즉 도구 호출 궤적을 함께 검증해야 한다. 읽기 전용 Skill은 ANY_ORDER 수준으로 충분할 수 있지만, 실행 허용형 Skill은 IN_ORDER 또는 EXACT 수준의 궤적 검증이 필요하다.

평가 패턴	용도
Eval-as-Unit-Test	Skill 변경마다 CI에서 자동으로 실행되는 최소 테스트.
Golden Dataset	대표 입력과 기대 출력·도구 호출을 버전 관리하는 기준 데이터셋.
LLM-as-Judge	루브릭에 따라 대규모 출력을 평가하되, 사람 평가와 보정해야 한다.
Adversarial / Red-Team	경계 사례와 악조건으로 트리거·실행 실패를 드러낸다.
Canary / Shadow Mode	전체 출시 전 제한 트래픽 또는 병렬 비가시 실행으로 회귀를 확인한다.

3.5 프로토타입에서 프로덕션으로

프로토타입이 실제 고객 환경으로 들어가면 문제의 중심은 모델이 아니라 모델 주변의 엔지니어링이 된다. 런타임은 대화 유지, 모델 호출, 도구 실행, 파일 읽기, 응답 반환 같은 공통 기능을 수행한다. 차별화된 전문성은 런타임이 아니라 Skill 라이브러리에 쌓인다.

개선 방식	속도	위험	주체	컨텍스트 비용
모델 교체	며칠~몇 주	무관한 작업의 회귀	ML/플랫폼팀	가중치 기반
시스템 프롬프트 수정	분~시간	컨텍스트 로트, 지시 충돌	프롬프트 소유자	매 턴 정적 비용
파인튜닝	몇 주~몇 달	망각, 과적합	ML팀	가중치 기반
새 Skill 추가	시간~며칠	매칭되는 턴에 제한	도메인팀	트리거 시 동적 비용

프로덕션에서 흔한 실패 모드는 환각만이 아니라 컨텍스트 오버플로다. 컨텍스트 창이 크더라도 관련 정보가 중간에 묻히거나, 도구 출력과 반쯤 관련 있는 검색 결과가 섞이면 모델 성능은 조용히 떨어진다. 따라서 활성 컨텍스트는 그릇이 아니라 예산으로 다루어야 한다.

용량보다 중요한 것은 실제 모델 앞에 놓인 활성 컨텍스트의 품질과 크기다.

점진적 공개는 사용 가능한 역량을 넓히면서도 활성 컨텍스트를 작게 유지한다.

프로덕션 시스템의 지속 가능한 개선 단위는 모델 교체보다 작고 테스트 가능한 Skill이다.

3.6 메타 스킬과 자기 개선형 Skill

메타 스킬은 다른 Skill을 작성하거나, 평가하거나, 개선하는 Skill이다. 인간이 첫 버전을 쓰고 평가 체계를 세운 뒤, 메타 스킬은 반복적인 유지보수를 돕는 방향으로 쓰는 것이 안전하다.

메타 스킬 유형	역할	주의점
작성형	워크플로 설명을 받아 SKILL.md 초안을 만든다	초안은 반드시 Draft 단계에서 시작한다.
실행 추적 기반 작성 보조	성공한 실행 궤적을 Skill로 전환한다	사람이 단계의 타당성을 확인해야 한다.
개선형	실패 평가 케이스를 바탕으로 수정안을 제안한다	평가 게이트와 사람 diff 검토가 필요하다.
라이브러리 진화형	반복되는 새 문제를 발견해 새 Skill 추가를 제안한다	지표 게임과 회귀 위험이 가장 크다.

메타 스킬은 평가 스위트가 좋을 때만 유용하다. 허술한 지표를 주면 에이전트는 실제 품질이 아니라 그 지표만 좋아지도록 최적화할 수 있다. 그러므로 자율 개선 루프에는 트리거 정확도 테스트, 회귀 테스트, 사람의 표본 검토가 필수다.

3.7 Skills 조합과 패키징

실제 워크플로는 하나의 Skill 안에 깔끔하게 들어가지 않는다. 따라서 Skill 간 참조, 상태 전달, 순환 의존성 방지, 실행 환경별 패키징을 설계해야 한다. 단순한 프롬프트 체이닝은 상태를 불투명하게 만들고 오류를 누적시킨다.

아키텍처	메커니즘	적합한 경우
선형 파이프라인	고정 노드 사이에서 텍스트를 순차 전달	단일 도메인, 낮은 복잡도의 생성 작업
DAG 오케스트레이션	그래프 기반 실행과 파일 메시지 버스식 상태 전달	높은 신뢰성이 필요한 멀티 에이전트 워크플로
Capability Profiles	Skill·도구·지침·파라미터 번들을 실행 상태별로 교체	역할 기반 배포와 도메인 특화 에이전트

컨텍스트 부채도 중요한 문제다. “항상 X를 하라” 같은 지시를 description에 계속 덧붙이면 모델의 주의력을 낭비한다. 더 나은 방식은 복잡한 판단과 규칙을 테스트 가능한 scripts/와 결정론적 제약으로 옮기는 것이다. 즉, 규칙을 길게 쓰지 말고 소프트웨어를 작성해야 한다.

3.8 수많은 Skill 중 무엇을 선택할 것인가

Skill 생태계가 커질수록 선택과 공급망 관리가 중요해진다. 외부 Skill은 편리한 프롬프트 조각이 아니라, 사용자의 컨텍스트 안에서 실행되는 코드 의존성으로 취급해야 한다.

판단 규칙	실무 의미
특정 벤더 도구에는 1st-party Skill 우선	BigQuery, Stripe처럼 제품 지식이 필요한 경우 공식 Skill이 더 정확하고 유지보수될 가능성이 높다.
의존하는 것은 모두 버전 고정	어제 작동한 커뮤니티 Skill이 내일 깨질 수 있다.
도입 전 감사	비밀값, 권한, 외부 의존성, 악성 코드 가능성을 확인한다.

출처	기본 태세	유지보수
1st-party 벤더 Skill	기본 신뢰, 그래도 버전 고정	기반 제품을 만든 팀
조직 선별 Skill	조직 내부 신뢰, 도입 시 리뷰	내부 도메인 팀 + PR 리뷰
커뮤니티 Skill	도입 전 감사, 강한 버전 고정	자원 기여자, 유지보수 품질 편차 큼

3.9 결론: 형식은 정착되었고, 일은 이제 시작되었다

Agent Skill은 하나의 마크다운 파일과 선택적 스크립트를 담은 단순한 폴더처럼 보인다. 그러나 그 단순함 때문에 오히려 중요한 작업이 주변에서 가능해진다. 현실적인 동시 로딩 조건에서 평가하고, Skill을 워크플로로 조합하며, 성공적인 실행 추적에서 초안을 만들고, 조직 지식을 버전 관리·테스트·거버넌스 가능한 라이브러리로 만드는 일이 이제 다룰 수 있는 문제가 되었다.

실천 결론**:** 작게 시작하라. 이미 가진 지식에서 출발하라. Skills를 코드처럼 다루라. 배포한 것을 측정하라. Skills로 충분한 곳에 멀티 에이전트 아키텍처를 과하게 적용하지 말라.

4. Appendix A 통합 실무 치트시트

이 파트는 내일부터 바로 Skill을 만들 팀을 위한 실행 지침이다.

4.1 최소 SKILL.md 템플릿

---

name: skill-name

description: |

  [이 Skill이 하는 일을 동사로 시작하는 한 문장으로 적는다.]

  사용자가 [트리거 문구 1], [트리거 문구 2], 또는 [트리거 문구 3]을 요청할 때 사용한다.

  [비활성화 조건 1] 또는 [비활성화 조건 2]에는 사용하지 않는다.

version: 1.0.0

license: MIT

allowed-tools: [Optional] Read Bash Write

metadata:

  author: [Optional] your-handle

---

Skill Name

When to use

• [구체적인 사용 시나리오]

When NOT to use

• [범위 밖 시나리오]

Workflow

1. [단계]

2. [단계]

3. [경계 사례]는 references/advanced.md를 참고한다.

Examples

• Input: “…” → Output: “…”

Output format

• assets/template.md 등을 사용한다.

4.2 다섯 가지 규칙

1. 하나의 Skill, 하나의 일. 한 문장으로 설명되지 않으면 나누어라.

2. description은 인터페이스다. 모호한 description은 사용되지 않는 Skill을 만든다.

3. Skills는 의존성이다. 버전 관리, 버전 고정, PR 리뷰, 테스트를 적용하라.

4. 올바른 팀이 올바른 Skill을 소유해야 한다. 도메인 Skill은 도메인 전문가가 소유한다.

5. 에이전트 런타임은 교체 가능하다. Skill을 특정 런타임에 묶지 말라.

4.3 Skill 스멜: 보이면 수정할 징후

SKILL.md가 5,000단어를 넘는다: 두 개의 Skill이거나 references/로 옮겨야 할 자료일 가능성이 높다.

두 도메인 팀이 소유할 수 있다: 팀 경계를 기준으로 분해해야 한다.

테스트 케이스 세 개를 쓸 수 없다: description이 모호하거나 범위가 너무 넓다.

description이 “도움을 주는 Skill”처럼 시작한다: 트리거, 입력, 출력을 명시하도록 다시 써라.

edge case 섹션이 계속 늘어난다: 각 경계 사례가 별도 Skill이 되어야 할 수 있다.

4.4 평가·배포 체크리스트

분류	체크 항목
평가 커버리지	긍정/부정 트리거, 대표 입력 출력, 회귀 없음, 5~15개 Skill 동시 로딩 조건의 토큰 예산 확인
배포 전 검증	프런트매터 린트 통과, description의 what/when/when-not 포함, scripts 단위 테스트 통과
보안	비밀값, 하드코딩 경로, 신뢰할 수 없는 의존성, 무단 권한 요청 확인
리뷰	작성자가 아닌 다른 사람이 description을 검토하고, 공개 배포 시 여러 도구 설치 경로를 테스트

4.5 한 줄짜리 사고 모델

구성 요소	비유
System prompt	본능
AGENTS.md	프로젝트 README
Tools / MCP	손
RAG	도서관
Skills	첫날 숙련된 동료가 건네주는 런북이자 AI가 잊지 않는 절차서

4.6 내일 시작하는 절차

1. 가장 숙련된 실무자를 한 시간 만나 정기적으로 수행하는 워크플로 세 가지를 말하게 하고 녹음한다.

2. 가장 자주 반복되는 워크플로 하나를 고르고, Skill 없이 실행해 에이전트가 실패하는 지점을 기록한다.

3. 녹취록을 바탕으로 SKILL.md를 초안 작성하되, 본문보다 먼저 평가 케이스 세 개를 쓴다.

4. 읽기 전용 단계로 배포하고, 프로덕션 유사 조건에서 트리거 정확도 90% 이상이 될 때까지 description을 조정한다.

5. 한 번에 하나의 워크플로씩 반복한다. 첫날 LLM에게 Skill 50개를 만들게 하지 않는다.

6. Appendix B 리테일 사례 연구

리테일 사례는 Agent Skills가 조직의 도메인 전문성을 코드처럼 축적하는 방식을 보여 준다. 같은 런타임과 비슷한 데이터 API를 쓰더라도, 각 회사의 구매·머천다이징·카테고리 판단 기준이 다르면 고객 경험은 완전히 달라진다.

5.1 Skills-first 리테일 아키텍처

계층	역할	예시
고객 접점	사용자 입력을 런타임으로 보내고 응답을 표시하는 얇은 표면	웹 채팅, 모바일 앱, 매장 키오스크, 음성 에이전트, SMS
에이전트 런타임 + 오케스트레이터	대화를 유지하고, 필요한 Skill을 로드하며, 도구 호출과 응답 조립을 담당	ADK, Claude Agent SDK, Skills 표준 지원 런타임
데이터·도구 계층	상품·재고·고객·프로젝트 지식과 검색 도구 제공	상품 카탈로그, 실시간 재고, 고객 프로필, 프로젝트 KB, 벡터 검색

중요한 차별화 지점은 런타임이 아니라 런타임에 로드되는 Skills다. Skills는 브랜드의 판단과 전문성을 담고, MCP와 검색 통합은 데이터 배관을 담당하며, 모델은 교체 가능하다.

5.2 예시 Skill 라이브러리

Skill	담는 전문성	소유 팀	권한 단계
project-guidance	모호한 프로젝트 질문을 단계별 계획으로 바꾸는 현장 기술 지식	현장 기술 지식 팀	읽기 전용
materials-list	프로젝트 설명을 자재 명세서/BOM으로 변환	Pro 머천다이징 팀	초안 전용
review-summarize	긴 제품 리뷰를 장점, 단점, 일반 사용 사례로 요약	개인화 팀	읽기 전용
delivery-window	고객 위치와 재고·화물 네트워크 기반 배송 옵션/ETA 계산	풀필먼트 팀	읽기 전용
return-policy	반품 규칙과 예외 조건 설명	고객 서비스 팀	읽기 전용

5.3 같은 질의가 라이브러리를 통과하는 방식

고객이 “아이들 욕실을 리모델링하고 싶은데, 뭐가 필요할까요?”라고 묻는다고 하자. 세션 시작 시 런타임은 모든 Skill의 L1 description만 가볍게 확인한다. project-guidance가 먼저 로드되어 리모델링 단계 개요를 만들고, 고객이 배송을 묻는 순간 delivery-window가 로드된다. 특정 품목의 반품을 물으면 return-policy가 로드된다. 거대한 “리모델링 어시스턴트” 하나가 모든 시나리오를 항상 품고 있는 것이 아니라, 대화가 도달한 지점의 전문성만 활성 컨텍스트로 들어온다.

5.4 거버넌스: 소유권과 권한 단계

권한 단계	허용 능력	검토 주체	예시
Read-Only	데이터 조회·설명 가능, 상태 변경 불가	도메인 팀 승인	review-summarize, store-locator, project-guidance
Draft-Only	사람 검토용 콘텐츠 생성 가능, 발송·확정 불가	도메인 팀 + 형식 소유자	draft-customer-email, materials-list
Action-Allowed	실제 시스템에서 되돌릴 수 없는 작업 가능	도메인 팀 + 보안/컴플라이언스 + 임원 승인	issue-refund, send-customer-message, reserve-inventory

이 구조는 보안팀과 규제기관에 설명하기 쉽다. 블랙박스 에이전트가 무엇이든 하는 구조보다, 어떤 Skill이 어떤 권한으로 무엇을 할 수 있는지 분리되어 있기 때문이다.

5.5 전략적 결론

범용 에이전트 런타임은 점점 누구나 접근할 수 있는 인프라가 된다. 경쟁사가 따라 하기 어려운 것은 런타임이 아니라 회사가 실제로 알고 있는 것, 즉 오랜 시간 축적된 판단과 운영 패턴을 담은 Skill 라이브러리다. 따라서 커스텀 에이전트 자체보다 Skill 라이브러리가 더 지속 가능한 전략 자산이 된다.

6. 강의용 요약 패키지

6.1 90분 강의안

시간	주제	진행 방식	핵심 산출물
0~10분	문제 제기: 왜 에이전트는 지시가 많아질수록 약해지는가	강의 + 질문	컨텍스트 로트 개념 이해
10~25분	Agent Skill의 정의와 구조	도식 설명 + 폴더 구조 보기	SKILL.md, scripts/, references/, assets/ 구분
25~40분	description 작성 실습	개별 또는 조별 실습	긍정 트리거 2개, 부정 트리거 1개
40~55분	평가 체계	실패 모드 분류 활동	Trigger/Execution/Regression/Token Budget 진단
55~70분	프로덕션과 거버넌스	사례 토론	Read/Draft/Act 권한 단계 설계
70~85분	리테일 사례 응용	조별 미니 설계	도메인 Skill 라이브러리 초안
85~90분	정리	핵심 문장 회수	다음 실천 과제 선정

6.2 12장 슬라이드 구성안

슬라이드	제목	핵심 메시지
1	오늘의 질문	에이전트에게 조직 지식과 절차를 어떻게 안정적으로 넣을 것인가
2	Agent Skill 한 문장 정의	필요할 때 로드되는 절차기억 폴더
3	왜 시스템 프롬프트만으로 부족한가	컨텍스트 로트와 지시 충돌
4	Skill Anatomy	SKILL.md, scripts, references, assets
5	점진적 공개	메타데이터 → 본문 → 리소스의 3단계 로딩
6	Skill 작성의 두 경로	조직 지식 번역 vs 성공 실행 결정화
7	멀티 에이전트와의 관계	대체가 아니라 과도한 복잡성의 재조정
8	평가 실패 모드	Trigger, Execution, Token Budget, Regression
9	프로덕션에서 중요한 것	모델보다 주변 엔지니어링과 Skill 라이브러리
10	메타 스킬	작성, 추적 기반 작성, 개선, 라이브러리 진화
11	거버넌스	버전 고정, 감사, Read/Draft/Act
12	내일의 실행	숙련자 인터뷰 → 평가 케이스 → 읽기 전용 배포

6.3 수업 활동

활동	지시문	평가 기준
description 리라이팅	“문서 작업을 돕는다” 같은 모호한 설명을 Skill description으로 다시 써라.	what/when/when-not 포함 여부
실패 모드 진단	주어진 실패 사례를 네 실패 모드 중 하나로 분류하라.	분류 근거의 명확성
권한 단계 설계	환불, 이메일 발송, 재고 예약 Skill의 Read/Draft/Act 단계를 정하라.	위험도와 검토 주체의 적합성
도메인 Skill 라이브러리 설계	자신의 학교/회사/콘텐츠 제작 업무에서 반복 워크플로 5개를 Skill 후보로 나누어라.	단일 책임과 소유자 지정 여부

6.4 토론 질문

1. 어떤 업무는 Skill로 충분하고, 어떤 업무는 멀티 에이전트가 필요한가?

2. description을 라우팅 알고리즘으로 본다는 말은 실제 작성 방식에 어떤 변화를 요구하는가?

3. 조직 지식을 Skill로 만들 때 AI팀과 도메인팀의 역할은 어떻게 나뉘어야 하는가?

4. 메타 스킬이 자기 개선을 하도록 허용할 때 가장 위험한 지점은 무엇인가?

5. 교육 콘텐츠 제작 업무에서 Skill로 만들 만한 반복 워크플로는 무엇인가?

6.5 미니 퀴즈와 정답

문항	정답
Skill의 필수 파일은 무엇인가?	SKILL.md
Skill 로드 여부를 결정하는 핵심 필드는 무엇인가?	description 필드
점진적 공개의 핵심 효과는 무엇인가?	활성 컨텍스트를 작게 유지하면서 사용 가능한 역량을 확장한다.
Skill 평가의 네 실패 모드는 무엇인가?	Trigger, Execution, Token Budget, Regression
MCP와 Skill의 차이는 무엇인가?	MCP는 외부 시스템 도달 범위, Skill은 업무 수행 노하우를 담당한다.
프로덕션에서 활성 컨텍스트를 무엇처럼 다뤄야 하는가?	그릇이 아니라 예산

7. 실무 적용 체크리스트

아래 체크리스트는 실제 팀에서 Agent Skills 도입을 시작할 때 사용할 수 있는 최소 운영 절차다.

단계	해야 할 일	완료 기준
1. 후보 발굴	숙련자 인터뷰로 반복 워크플로 3개 수집	각 워크플로의 입력, 출력, 예외가 설명됨
2. 범위 분해	각 후보가 “하나의 Skill, 하나의 일”인지 확인	한 문장으로 설명 가능
3. 평가 먼저 작성	긍정 케이스 2개, 부정 케이스 1개 작성	본문 작성 전 평가 케이스 완료
4. description 작성	what/when/when-not을 명시하고 트리거 키워드 앞에 배치	동료 리뷰 통과
5. 리소스 분리	결정론적 코드는 scripts/, 세부 지식은 references/, 템플릿은 assets/로 분리	SKILL.md 본문이 짧고 명확함
6. 읽기 전용 배포	프로덕션 유사 조건에서 테스트	트리거 정확도 90% 이상
7. 라이브러리 관리	버전 고정, PR 리뷰, 보안 스캔, 회귀 테스트 적용	CI에서 평가 스위트 통과
8. 확장	성공한 Skill만 Draft/Action 단계로 승격	권한 단계별 승인자 명시

마지막 문장: 형식은 정착되었다. 일은 이제 막 시작되었다.