AI에게 매번 '방법'을 설명하는 것을 그만두기 — Agent Skills (SKILL.md)로 문맥을 과하게 늘리지 않고 '할 줄 아는

AI에게 코드를 작성하게 하거나, 조사를 시키다 보면 이런 경험, 없으신가요?

"이 프로젝트의 커밋 메시지는 이런 형식으로 작성해줘"

"리뷰할 때는 먼저 여기를 보고, 그다음 여기를 확인해줘"

"릴리스 전에는 반드시 이 절차대로 체크해줘"

매번, 매번 똑같은 것을 설명하고 있습니다. 채팅창을 새로 열 때마다 다시 처음부터. 프롬프트 어딘가에 복사해서 붙여넣은 "긴 서문"을 마치 주문처럼 붙여넣고 있습니다. 팀에서 사용하고 있다면 멤버마다 미묘하게 다른 지시를 내리게 되어, AI의 출력도 왠지 제각각입니다.

솔직히 말하면, 저도 처음에는 이것이 당연하다고 생각했습니다. AI는 똑똑하니까 제대로 설명하면 응답해 줄 것이다. 그러니 정중하게 설명하자, 라고 말이죠.

하지만 어느 순간 문득 깨달았습니다. 이것은 똑똑함의 문제가 아니라, "방법(절차)을 전달하는 방식"의 문제가 아닐까 하고 말입니다.

우수한 신입 사원이 들어왔다고 가정했을 때, 매일 아침 "우리 회사의 경비 정산은 이렇게 하고..."라며 하나부터 열까지 계속 설명하시겠습니까? 그러지 않으시겠죠. 처음에 한 번, 온보딩 (Onboarding) 자료를 전달합니다. 그다음에는 본인이 필요할 때 그것을 봅니다. AI에게도 그것과 똑같은 일을 해주면 됩니다.

그 "온보딩 자료"에 해당하는 것이 오늘의 주인공, **Agent Skills (에이전트 스킬)**입니다.

이 기사에서는 AI 개발이 아직 익숙하지 않은 분들도 뒤처지지 않도록, 용어의 의미부터 왜 중요한지, 어떻게 작성하는지, 그리고 사고를 방지하기 위한 안전 설계까지 순서대로 천천히 풀어서 설명하겠습니다. 내일부터 직접 하나를 만들 수 있는 단계까지 함께 가봅시다.

먼저 결론부터 말씀드리겠습니다.

Agent Skills란 "AI에게 갖추게 하고 싶은 '방법'을 하나의 폴더에 모아둔 것"입니다. 그 폴더 안에 SKILL.md라는 한 장의 Markdown 파일이 있으면 OK. 이것이 최소 단위입니다.

Anthropic (Claude를 만드는 회사)이 2025년 10월에 발표한 메커니즘으로, 공식 측은 "스킬을 만드는 것은 새로 들어오는 사람을 위한 온보딩 가이드를 준비하는 것과 같다"라고 설명하고 있습니다. 범용적인 AI에게 당신의 현장 전문 지식을 "갖게 하는 것". 그것이 스킬입니다.

여기서 한 가지만 중요한 용어를 풀어서 설명해 두겠습니다.

절차적 지식 (procedural knowledge)… 거칠게 말하면 "방법에 대한 지식"입니다. "정답이 무엇인가"가 아니라, "어떤 절차로 하는가", "어떤 순서로 주의해야 하는가"라는 지식을 말합니다. 레시피, 업무 매뉴얼, 체크리스트. 그것이 절차적 지식입니다.

AI는 일반적인 지식 ("PDF란 무엇인가"와 같은 선언적 지식)은 원래 산더미처럼 가지고 있습니다. 하지만 "우리 팀에서는 이런 절차로 한다"라는 현장 고유의 방법은 모릅니다. 그 부분을 채워주는 것이 스킬인 셈입니다.

폴더의 내용은 가장 심플하면 다음과 같습니다.

my-skill/
└── SKILL.md ← 이것 한 장만 있어도 훌륭한 스킬

그리고 절차가 복잡해지면 부속 파일이나 스크립트를 추가할 수 있습니다.

pdf-form-filler/
├── SKILL.md ← 입구. 방법의 본체
├── reference.md ← 상세 사양 (필요할 때만 읽음)
...

"파일을 추가할 수 있다는 건 알겠어. 하지만 너무 많이 추가하면 AI가 읽어야 할 양이 늘어나서 머리가 터지지 않을까?"

매우 좋은 질문입니다. 그리고 그 불안을 깔끔하게 해소해 주는 것이 다음에 이야기할 **Progressive Disclosure (단계적 개시)**라는 메커니즘입니다. 이 부분이 이 기사의 가장 핵심이므로 정중하게 설명하겠습니다.

스킬이 왜 대단한지 이해하려면 AI의 "책상 넓이"를 알아둘 필요가 있습니다.

AI는 한 번에 읽을 수 있는 글자 수에 상한이 있습니다. 이 "한 번에 읽을 수 있는 작업 공간"을 **컨텍스트 윈도우 (Context Window)**라고 부릅니다. 책상의 넓이라고 상상해 보세요. 그리고 AI가 읽는 글자 덩어리를 **토큰 (Token)**이라고 합니다 (대략 일본어 1~2글자나 영어 단어의 일부가 1토큰 정도라고 거칠게 이해해도 괜찮습니다).

책상이 넓다고는 해도 무한하지는 않습니다. 절차서를 전부 책상 위에 펼쳐 놓으면, 정작 중요한 작업을 할 공간이 없어집니다. 게다가 사용하지 않는 종이까지 책상에 올려두면, AI는 그것을 매번 전부 다시 읽어야 하므로 비용 (API 요금)도 시간도 많이 듭니다.

따라서 "스킬을 100개 넣으면 무거워지지 않을까?"라는 불안은 매우 정확한 직관입니다. 평범하게 전부 읽게 하면 확실히 과부하가 걸립니다.

Progressive Disclosure(점진적 공개)는 한마디로 "처음부터 전부 펼쳐놓지 않고, 필요할 때 필요한 만큼만 조금씩 꺼내 놓는" 메커니즘입니다.

두꺼운 매뉴얼을 떠올려 보세요. 당신은 처음에 모든 페이지를 암기하나요? 그렇지 않죠. 먼저 목차를 보고 "이 장이 관련이 있겠군"이라고 짐작한 뒤, 그 장만 읽습니다. 더 자세한 수치가 필요해지면 부록을 찾아보죠. 스킬(Skill)은 이와 완전히 똑같이 동작합니다.

구체적으로는 세 가지 레벨로 나뉩니다.

레벨 1: 메타데이터 (항상 책상 끝에 놓여 있는 "목차")

AI가 기동되는 순간, 설치된 모든 스킬의 name(이름)과 description(설명)만이 시스템 프롬프트(AI에게 내리는 상주 지시 사항)에 로드됩니다. 이는 단 수십 토큰에 불과합니다. 스킬이 100개 있어도 목차가 100줄 있는 정도의 가벼움입니다. 이를 통해 AI는 책상을 압박하지 않고도 "어떤 스킬이 손에 있는지"를 파악할 수 있습니다.

레벨 2: 본문 (관련 있어 보이는 "장"만 열기)

사용자의 요청이 특정 스킬의 설명과 일치할 때입니다. 예를 들어 "이 PDF 양식을 채워줘"라는 요청을 받았는데, description에 "PDF 양식 작성을 수행함"이라고 적힌 스킬이 있다면, AI는 그제서야 SKILL.md의 본문을 읽어 들입니다. 방법의 핵심 내용은 바로 이 순간에 로드됩니다.

레벨 3: 부속 파일/스크립트 ("부록"을 필요할 때만 찾아보기)

본문 안에 "양식을 채울 때는 forms.md를 읽으세요"라고 적혀 있다면, AI는 양식을 다루는 단계에 이르러서야 비로소 forms.md를 엽니다. 양식 항목을 기계적으로 추출하는 처리는 동봉된 extract_fields.py를 실행합니다(내용을 읽지 않고 단순히 실행만 합니다).

표로 정리하면 다음과 같습니다.

레벨	무엇이	언제 읽히는가	비용
1. 메타데이터	name + description	기동 시, 항상 (전체 스킬 분량)	극소 (수십 토큰 × 개수)
...

여기서 소름 돋는 포인트는, 이 메커니즘 덕분에 Anthropic 측의 말에 따르면 **스킬에 번들(Bundle)할 수 있는 문맥의 양은 "실질적으로 무제한(effectively unbounded)"**이 된다는 점입니다.

왜일까요? 책상 위에 올라오는 것은 "목차(메타데이터)"뿐이고, 두꺼운 내용은 파일로서 외부에 놓여 있기 때문입니다. AI는 파일 시스템을 가지고 있으므로, 필요할 때마다 그때그때 가져오면 됩니다. 전부를 떠안고 있을 필요가 없습니다.

이것은 잘 생각해보면 인간의 일하는 방식 그 자체입니다. 유능한 사람일수록 모든 것을 머릿속에 집어넣는 것이 아니라, "어디에 무엇이 적혀 있는지"를 알고 있어서 필요할 때 슥 꺼내 쓸 수 있습니다. 스킬은 그것을 AI에게 부여하는 메커니즘입니다.

그리고 또 하나 반가운 점은 스크립트를 동봉할 수 있다는 것입니다. 리스트 정렬 같은 정해진 처리를 AI에게 매번 토큰을 써가며 "생각하게" 만드는 것은 비용이 많이 들고, 가끔 실수도 합니다. 하지만 미리 작성된 프로그램을 실행하게 하면 비용도 저렴하고, 몇 번을 반복해도 같은 결과가 나옵니다. **"생각해야 할 부분은 AI에게, 정해진 부분은 코드에"**라는 역할 분담이 스킬 안에서 자연스럽게 이루어지는 것입니다.

이론은 이쯤 해두고, 직접 손을 움직여 봅시다. 가장 작은 스킬은 다음과 같은 형태입니다.

---
name: commit-message-writer
description: Git 커밋 메시지를 작성하거나 정리할 때 사용. Conventional Commits 형식(feat/fix/docs 등)을 따르며, 제목은 50자 이내, 본문에는 "이유"를 1~2줄로 작성.
...

단지 이것뿐입니다. ---로 둘러싸인 부분이 frontmatter(프론트매터), 즉 파일 도입부의 설정란입니다. 여기에 적는 name과 description 두 가지만 필수입니다. 나머지는 Markdown 본문에서 평소처럼 절차를 적으면 됩니다.

포인트는 본문이 그대로 "AI를 위한 작업 지시서"가 된다는 점입니다. 당신이 팀의 신입 사원에게 건네는 메모와 거의 같은 감각으로 작성할 수 있습니다.

여기서 한 가지만 강조하겠습니다. description은 단순한 설명문이 아니라 "발화 스위치"입니다.

기억해 보세요. 레벨 1에서 항상 읽히는 것은 name과 description뿐입니다. 즉, AI는 이 description을 보고 "지금의 요청에 이 스킬이 관련이 있는가?"를 판단합니다. 따라서 description이 "유용한 도구 모음"처럼 모호하면, 필요할 때 발화하지 않고 필요하지 않을 때 폭발합니다. "언제 사용하는가 (Use when)"를 구체적인 동사로 작성하는 것이 효과적인 스킬을 만드는 가장 중요한 요령입니다.

최소 버전에서 현장에서 효과를 발휘하는 요소들을 추가해 봅시다. 발화 정밀도를 높이는 "Use when / Don't use when", 깊은 정보를 전달하는 "부속 파일 참조", 정해진 처리를 맡기는 "스크립트". 이 세 가지를 넣으면 훨씬 실전적이 됩니다.

---
name: pr-review-checklist
description: |
...

디렉터리 구성은 다음과 같습니다.

pr-review-checklist/
├── SKILL.md
├── references/
...

여기서 단계적 공개 (Progressive Disclosure)가 효과를 발휘하고 있다는 점이 보이시나요? security.md의 내용은 평소에는 읽히지 않습니다. 리뷰의 4번(보안) 단계에 도달하여 정말로 필요해졌을 때만 AI가 이를 엽니다. 덕분에 SKILL.md 본체는 가벼운 상태를 유지할 수 있습니다.

그리고 정해진 처리는 스크립트로 넘깁니다. 예를 들어 "너무 큰 차이점(diff)을 파일별로 분할하는" 것과 같은 처리는 AI에게 생각하게 하는 것보다, 이런 작은 코드를 실행하게 하는 것이 더 저렴하고 확실합니다.

#!/usr/bin/env bash
# scripts/split_diff.sh — 스테이징된 차이점을 파일 단위로 분할하여 출력함
set -euo pipefail
...

PDF skill의 공식 예시도 바로 이런 형태였습니다. "폼 항목을 추출한다"라는 결정적인 처리는 미리 작성된 Python 스크립트를 실행하게 합니다. PDF 본체도 스크립트 내용도 테이블 위에 올리지 않고, 그저 실행하여 결과만 받습니다. 그렇기 때문에 몇 번을 반복해도 동일한 결과가 나오며 (재현 가능성), 토큰도 소비하지 않습니다. 정해진 처리일수록 코드에 맡기는 것이 더 행복해질 수 있다는 좋은 예시라고 생각합니다.

스킬을 다루기 시작하면 반드시 이 의문에 부딪히게 됩니다. "Skill은 MCP나 서브 에이전트 (Subagent)와 무엇이 다른가?"

솔직히 말씀드리면, 저도 처음에는 혼란스러웠습니다. 하지만 정리하고 나면 의외로 명쾌해집니다. 역할의 "층 (Layer)"이 각각 다르기 때문입니다. 한마디로 정의하면 다음과 같습니다.

Skill = HOW (어떻게 하는가) … 절차와 방법을 필요할 때 읽히게 하는 휴대 가능한 모듈.

MCP = WHAT (무엇에 연결하는가) … 데이터베이스나 API 등 외부 도구 및 데이터로의 표준적인 접속구. AI의 USB-C와 같은 것.

Subagent = WHO (누구에게 시킬 것인가) … 독립된 작업 공간을 가진 "별동대". 무거운 작업이나 전문적인 작업을 떼어내어 위임함.

AGENTS.md = WHERE (어디를 걷는가) … 리포지토리에 계속 두는 "지도". 항상 읽히는 상주형 취급 설명서.

Prompt = 지금 한 번의 지시 … 그 자리에서만 유효하며, 끝나면 사라짐.

표로 정리하면 다음과 같습니다.

관점	Skill	MCP	Subagent	AGENTS.md	일반 Prompt
역할	방법 (HOW)	외부 연결 (WHAT)	위임·분담 (WHO)	리포지토리 지도	일회성 지시
구현체	SKILL.md 폴더	MCP 서버	.claude/agents/	리포지토리 루트	채팅창
읽히는 방식	관련 있을 때만 (단계적)	기동 시 정의 로드	위임했을 때	항상	그 순간에만
재사용성	높음 (휴대 가능)	높음 (표준화)	프로젝트 종속적	리포지토리 단위	낮음 (일회용)

그리고 중요한 점은, 이것들이 대립하는 것이 아니라 조합하는 것이라는 사실입니다.

예를 들어, 다음과 같은 흐름이 됩니다. AI가 '보안 코딩 절차'를 Skill로서 읽어들이고, Git 리포지토리(Repository)에 대한 액세스는 MCP를 통해 수행하며, 무거운 코드 리뷰 작업만은 독립된 Subagent에게 위임합니다. 해당 리포지토리 전체를 다루는 방법은 AGENTS.md에 적혀 있습니다. 이것이 2026년 AI 에이전트 설계의 꽤 정석적인 형태가 되어가고 있습니다.

헷갈릴 때 기억하는 방법은 간단합니다. "방법을 가르치고 싶다"면 Skill. "외부의 무언가와 연결하고 싶다"면 MCP. "무거운 작업을 떼어내고 싶다"면 Subagent. 이것만 파악해 두면 대부분 길을 잃지 않습니다.

스킬은 쉽게 만들 수 있는 만큼, 대충 만들면 "발화(Trigger)되지 않음", "폭주(Over-triggering)함", "비대해짐"과 같은 은근한 스트레스가 쌓입니다. 공식 가이드라인과 제가 중요하다고 생각하는 원칙 몇 가지를 공유하겠습니다.

1. 평가(잘 안 풀리는 상황)에서 시작하기.

처음부터 완벽한 스킬을 쓰려고 하지 마세요. 우선 AI에게 평소처럼 태스크를 시켜보고, "여기서 막히네", "이 문맥이 매번 부족하네"와 같은 빈틈을 찾아냅니다. 그 빈틈을 메우기 위해 스킬을 작성합니다. 앞질러서 전부 다 쓰려고 하면, 대개 사용되지 않는 장(Chapter)만 생기게 됩니다.

2. 1스킬 = 1작업으로 좁히기.

"편리 기능 모음" 같은 만능 스킬은 description(설명)이 모호해져 발화가 불안정해집니다. 커밋 메시지용, PR 리뷰용과 같이 작업별로 나누세요. 많이 가지고 있어도 단계적 공개(Progressive Disclosure)를 통해 무거워지지 않으므로, 작게 나누는 것이 손해 볼 일이 없습니다.

3. description은 "발화 트리거(Trigger)"로서 작성하기.

이 점은 몇 번이고 강조하고 싶습니다. name과 description만이 항상 읽히는 목차이므로, 이곳의 품질이 전부입니다. "언제 사용하는지"를 구체적인 동사와 구절로 작성하세요. "Use when:", "Don't use when:"을 넣으면 폭주와 불발을 모두 줄일 수 있습니다.

4. 본문은 간결하게. 깊은 내용은 부속 파일로.

SKILL.md 본체는 "작업 수준의 가이드"에 머물게 하고, 백과사전으로 만들지 마세요. 좀처럼 함께 사용하지 않는 정보나 특정 상황에서만 필요한 상세 내용은 별도 파일로 분리합니다. 참조의 중첩(Nesting)은 1단계 정도로 억제하는 것이 다루기 쉽습니다.

5. "실행하는 코드"인지 "읽는 참조"인지 명확히 하기.

동봉된 파일이 AI가 실행할 스크립트인지, AI가 읽을 참조 자료인지 구분해야 합니다. 이것이 모호하면 AI가 혼란을 겪습니다. SKILL.md 안에서 "이것은 실행해줘", "이것은 참조해줘"라고 명시해 주세요.

6. Claude와 함께 키우기.

작업하면서 "지금 했던 좋은 방식, 스킬에 적어둬", "아까 실패한 거 왜 그랬는지 되돌아보고 절차에 추가해줘"라고 AI에게 요청하세요. 처음부터 완벽을 노리기보다, 사용하면서 살을 붙여 나가는 것이 현장에서 정말 효과적인 스킬이 됩니다.

함정(Pitfalls)도 표로 정리해 두겠습니다.

함정	증상	대책
description이 모호함	필요할 때 발화하지 않음 / 상관없는데 폭주함	"언제 사용할지/사용하지 않을지"를 동사로 구체적으로 작성
...

여기서 스킬 제작을 돕는 프롬프트 2개를 남겨둡니다. 그대로 사용하실 수 있습니다.

프롬프트 ①: 기존 워크플로우로부터 SKILL.md 초안 작성하기

당신은 Agent Skill 설계자입니다. 다음의 "내가 항상 AI에게 설명하는 절차"를
SKILL.md의 초안으로 변환해 주세요.
# 항상 설명하는 절차
...

프롬프트 ②: description(발화 트리거) 품질 리뷰

다음 SKILL.md의 description을 발화 트리거로서 평가해 주세요.
(여기에 description을 붙여넣기)
# 관점
...

이 부분은 가볍게 넘길 곳이 아닙니다. 오히려 이 부분을 이해하고 있는 사람이 가장 안심하고 스킬을 사용할 수 있다고 생각합니다.

스킬은 지시와 코드 모두를 AI에게 전달할 수 있습니다. 이것이 스킬의 힘의 원천인 동시에 위험의 근원이기도 합니다. Anthropic 공식 가이드에서도 명확히 경고하고 있습니다. 악의적인 스킬은 환경에 취약성을 가져오거나, AI가 정보를 유출하게 하거나, 의도하지 않은 조작을 수행하게 할 수 있다고 말이죠.

생각해 보면 당연한 일입니다. 스킬 안의 지시는 AI가 순순히 따를 것이고, 동봉된 스크립트는 실행될 것입니다. 즉, 누군가 만든 "편리해 보이는 스킬"을 내용도 보지 않고 넣는 것은, 모르는 사람이 작성한 쉘 스크립트를 sudo

로 실행하는 것과 약간 비슷하죠.

그래서 최소한 이것만은 지켜줬으면 하는 가이드라인을 정해두려 합니다.

신뢰할 수 있는 소스의 스킬만 넣는다. 공식 문서나 본인/자사가 작성한 것부터 시작한다. -
신뢰도가 낮은 스킬은 도입 전에 모든 파일을 읽는다. 특히 동봉된 스크립트, 의존성, 외부 네트워크에 접속하려는 지시나 코드에 주목한다. "왜 이 스킬이 외부 URL과 통신해야 하지?"라는 의문이 들면 일단 멈춘다. -
비밀 정보, 개인 정보, 고유 ID나 토큰을 스킬에 절대 포함하지 않는다. 스킬은 Git을 통해 공유되거나 공개되는 경우가 많다. API 키나 개인 정보를 본문이나 샘플에 적으면 그대로 유출됩니다. 예시는 반드시 더미(Dummy) 데이터를 사용한다. -
비가역적인(Irreversible) 조작은 스킬 내에서 "자동 실행"시키지 않는다. 전송, 결제, 삭제, 공개, 배포 등. 이런 종류의 "나중에 취소할 수 없는" 조작은 스킬의 절차로서 "인간에게 확인하기" 단계까지만 제한한다. 실행 트리거는 인간이 쥐고 있어야 한다.

이 마지막 점을 스킬 내에 명시해 두는 것이 은근히 효과적입니다. 예를 들어 본문에 다음과 같이 적어둡니다.

## 안전 경계 (이 스킬의 절대 규칙)
- 파괴적/비가역적 조작 (운영 DB 쓰기, 결제, 외부 전송, 삭제, 공개, 배포)은
**제안 및 드라이 런(Dry run) 단계까지만** 허용한다. 실행은 반드시 인간의 명시적인 승인을 얻은 후 진행할 것.
...

그리고 타인에게 받은 스킬을 넣기 전 체크할 때는 다음과 같은 프롬프트가 유용합니다.

프롬프트 ③: 신뢰할 수 없는 스킬의 안전 감사

지금부터 외부에서 입수한 Agent Skill을 도입해도 될지 감사하겠습니다.
다음 스킬의 모든 파일(SKILL.md 및 부속 파일·스크립트)을 읽고,
다음 관점에서 리스크를 찾아내 주세요. 최종 판단은 제가 하겠습니다.
...

스킬은 "AI를 구속하는 것"이 아니라, "안전한 범위 내에서 AI가 제대로 일할 수 있도록 만드는 울타리"라고 저는 생각합니다. 울타리가 있기 때문에 안심하고 맡길 수 있는 것이죠.

스킬을 설계할 때의 인간과 AI의 역할 분담을 표로 정리해 두겠습니다. 이는 스킬에 국한되지 않고, AI 시대의 모든 제작 활동 전반에 유효한 사고방식이라고 생각합니다.

공정	인간이 할 일 (What/Why)	AI에게 맡길 일 (How)
어떤 스킬을 만들 것인가	"어떤 절차가 매번 번거로운가"를 선택	후보군 도출을 도움
...

모든 것을 AI에게 통째로 떠넘기는 것이 아닙니다. "무엇을(What)", "왜(Why)"는 인간이 쥐고, "어떻게(How)"를 AI에게 넘겨주는 것. 이것이 속도와 안심을 양립시키는 균형이라고 느낍니다.

그 토대 위에서, 내일부터 시작할 첫걸음은 이 정도로 작아도 괜찮습니다.

매번 복사해서 붙여넣고 있는 지시사항을 딱 하나만 떠올린다. 커밋 규약이든 리뷰 절차든 무엇이든 좋습니다. -
그것을 SKILL.md에 붙여넣고, frontmatter에 name과 description을 추가한다 (description은 "언제 사용하는가"를 동사로 작성). -
사용 중인 도구(Claude Code 등)의 스킬 저장소(예: .claude/skills/)에 둔다. -
관련 요청을 던져서 제대로 발화(Trigger)되는지만 확인한다. 발화되지 않는다면 description을 수정한다.

이게 전부입니다. 하나가 작동하기 시작하면, 나머지는 같은 과정을 반복하며 늘려가기만 하면 됩니다.

마지막으로, 조금 더 큰 이야기를 해보고 싶습니다.

스킬을 작성한다는 것은 결국 **"미래의 자신과 AI에게 남기는 쪽지"**를 쓰는 것과 같습니다.

오늘의 내가 머릿속에 있는 방식을 딱 한 번만 언어로 표현해 둡니다. 그러면 내일의 나는 똑같은 설명을 할 필요가 없습니다. 다음 주의 나도, 팀 멤버도, 그리고 미래의 AI 세션도 그 쪽지를 읽고 동일한 품질로 움직일 수 있습니다.

저는 매일의 선택을 "내일의 내가 '고마워요(아자스)'라고 말해줄까?"라는 기준으로 결정하곤 하는데, 스킬 만들기가 바로 그것이라고 생각합니다. 오늘 10분을 들여 절차 하나를 스킬로 만들어 두면, 내일의 내가 "이거 써놓아 줘서 고마워요"라고 말해줄 것입니다. 그런 작은 미래를 향한 배려의 축적 말이죠.

게다가 이것은 자산이기도 합니다. 일회성 프롬프트는 그 자리에서 사라지지만, 스킬로 만들어 두면 그것은 쌓여서 24시간 언제든, 몇 번이고 동일한 방식을 재현해 줍니다. 코드가 자산이 되는 것과 마찬가지로, "방식(How-to)"도 자산이 됩니다. What(무엇을)과 Why(왜)를 인간이 쥐고, How(어떻게)를 AI가 갖게 하는 것. 그 축적이 서서히 큰 힘을 발휘할 것이라고 믿습니다.

AI가 똑똑해질수록, 차이를 만드는 것은 "똑똑한 AI를 가지고 있는가"가 아니라, "자신의 현장 방식을 얼마나 깔끔하게 AI에게 전달할 수 있는가"가 될 것입니다. 스킬(Skill)은 이를 위한 가장 실질적인 도구라고 생각합니다.

매번 처음부터 다시 설명해야 하는 번거로움을 오늘부터 하나씩 줄여보는 건 어떨까요? 내일의 당신이 분명 "고마워"라고 말해줄 것입니다.

• Anthropic Engineering 「Equipping agents for the real world with Agent Skills」
• Claude Docs 「Agent Skills — Overview / Best practices」 (platform.claude.com)
• Agent Skills 오픈 표준 (agentskills.io, 2025-12-18 공개)
• Anthropic 「Building effective agents」 (Skill / MCP / 서브 에이전트(Sub-agent)의 역할 정리)