스킬을 만드는 스킬 — Anthropic의 메타 도구를 뜯어봤다

프롬프트 엔지니어링은 끝났다

솔직히 말하자. 2026년에도 프롬프트 끝에 “please”를 붙이면 결과가 달라진다는 팁을 공유하는 사람이 있다. 그건 엔지니어링이 아니라 미신이다.

Anthropic은 다른 길을 걸었다. 프롬프트를 잘 쓰는 법을 연구하는 대신, 프롬프트를 잘 쓸 수밖에 없는 구조를 만들었다. 그게 스킬이고, 이 시리즈에서 지금까지 뜯어본 웹앱, PPT, 포스터가 그 산물이다.

그런데 그 스킬들은 누가 만들었나? 486줄짜리 설명서가 하나 더 있다. 스킬을 만드는 스킬. skill-creator. 이 시리즈에서 다룬 모든 스킬의 어머니다.

그리고 이것을 Anthropic은 오픈소스로 풀었다. 왜?

이걸 단순한 오픈소스 미덕으로만 읽으면 절반만 본 셈이다. 더 정확히 말하면, Anthropic은 포맷을 열어 생태계를 넓히고, 가장 중요한 실행 경험은 자기 런타임에 묶어두는 전략을 택했다. SKILL.md는 누구나 읽을 수 있지만, 트리거 최적화와 블라인드 비교 파이프라인은 claude -p에서만 자연스럽게 돌아간다. Android가 오픈소스지만 진짜 힘은 Google 서비스에 남겨두는 방식과 닮아 있다. 생태계는 열고, 핵심 경험은 쥔다.

팩토리 패턴이다

소프트웨어 엔지니어라면 이 구조가 익숙할 것이다. 스킬을 생산하는 파이프라인은 이렇게 생겼다:

의도 파악 → 스킬 초안(SKILL.md) → 테스트 → 블라인드 평가 → 개선 → 테스트 → …

반복 루프가 핵심이다. 한 번 쓰고 끝이 아니라, Red-Green-Refactor다. TDD를 AI 스킬에 적용한 것이다.

여기서 눈여겨볼 건 “테스트”와 “평가”가 분리되어 있다는 점이다. 테스트는 실행, 평가는 판단. 이 구분이 없으면 스킬은 빠르게 과적합(overfitting)에 빠진다.

과적합 — 이 설명서가 가장 경계하는 것

설명서에 이런 문장이 있다:

테스트 프롬프트 34개에 맞추면 그 34개에서는 잘 돌아간다. 하지만 백만 번의 실전 호출에서는 무너진다. 시험 문제를 외워서 만점 받는 것과 같다.

해결책이 흥미롭다. ALWAYS, NEVER 같은 하드코딩 대신 “왜 이렇게 해야 하는지”를 설명하라고 지시한다. AI가 규칙이 아니라 원리를 이해하면, 처음 보는 상황에서도 올바르게 행동한다.

시니어 개발자라면 이 문장에서 고개를 끄덕일 것이다. “규칙을 강제하지 말고 원리를 가르쳐라.” 이건 좋은 시니어가 코드 리뷰에서 반복하는 태도와 같다. 단기적으로는 규칙이 빠르지만, 장기적으로는 원리가 훨씬 강하다.

이중 맹검 — 스킬 평가 시스템

스킬 v1과 v2 중 어느 것이 더 나은지 판단하는 방식이 인상적이다.

스킬 v1 결과물 ──┐
                 ├──→ 블라인드 심판 AI → "B가 더 낫다" → 이유는?
스킬 v2 결과물 ──┘

심판 AI는 어느 것이 v1이고 어느 것이 v2인지 모른다. **이중 맹검법(Double-blind)**이다. 논문 심사에서 저자 이름을 가리는 것과 같은 원리.

이게 중요한 이유: 사람이 직접 평가하면 “내가 만든 v2가 더 낫겠지”라는 확증 편향이 들어온다. AI 심판도 완벽하지 않지만, 적어도 자기가 만든 버전이라는 사실을 모르면 편향은 줄어든다.

트리거 최적화 — 가장 날카로운 부분

스킬의 description 필드는 사실상 라우터다. 사용자의 프롬프트가 들어왔을 때, 이 스킬을 꺼내올지 말지를 결정하는 매칭 로직.

이 트리거 정확도를 최적화하는 전용 파이프라인이 있다:

1. 테스트 프롬프트 20개 생성 — 발동해야 할 것 10개, 발동하면 안 되는 것 10개
2. 학습 데이터 60% / 검증 데이터 40% 분리 — 과적합 방지
3. 자동 최적화 루프 5회 반복
4. 최적 description 추출

여기서 핵심은 네거티브 테스트 케이스다. 발동해야 할 때 발동하는 건 쉽다. 발동하면 안 될 때 발동하지 않는 게 어렵다. False positive를 잡는 것이 이 시스템의 진짜 가치다.

설명서가 제공하는 “나쁜 테스트”와 “좋은 테스트”의 예시도 날카롭다:

❌ "Format this data" — 너무 일반적. 이런 프롬프트에 아무 스킬이나 걸려들면 안 된다.

✅ "ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column..." — 실제 사용자의 자연스러운 말투. 이런 엣지 케이스에서 정확하게 반응해야 한다.

3단계 로딩 — 한정된 메모리에 대한 엔지니어링

AI의 컨텍스트 윈도우는 유한하다. 스킬이 10개, 20개, 100개가 되면 전부 메모리에 올릴 수 없다. 이 문제를 해결하는 설계:

skill-name/
├── SKILL.md
│   ├── YAML 메타데이터  ← 1단계: 항상 상주 (~100단어)
│   └── 마크다운 본문     ← 2단계: 발동 시 로딩
└── 리소스/
    ├── scripts/         ← 3단계: 필요 시 실행 (읽지 않고 실행만)
    └── references/      ← 3단계: 필요 시 개별 로딩

1단계는 OS의 프로세스 목록과 같다. 항상 떠 있지만 가볍다. 2단계는 프로세스 실행. 3단계는 디스크 I/O. Lazy loading을 인간이 읽는 문서에 적용한 것이다.

스킬 본문은 500줄 이하를 권장한다. 왜? 길어지면 AI가 앞부분을 잊는다. 이건 코드에서 함수가 길어지면 위에 뭘 했는지 까먹는 것과 같다. Short functions, short skills.

스킬 설계의 공통 패턴

다음 편에서 3개의 스킬을 직접 만들어보면, 공통된 설계 패턴 5가지가 반복적으로 나타난다:

1. YAML Frontmatter — name + description으로 스킬 메타데이터 정의. description이 트리거(라우터) 역할
2. 발동/비발동 조건 명시 — 유사하지만 본질이 다른 행위를 명확히 구분
3. 경계 사례 처리 — 모호한 요청에 대한 질문 프로토콜 내장
4. Phase 기반 파이프라인 — 각 단계를 독립적으로 실행 가능하도록 구조화
5. 출력 포맷 템플릿 — 일관된 마크다운 기반 리포트 형식

이 패턴들은 skill-creator가 강제한 것이 아니라, 도메인에 맞는 스킬을 만들다 보면 자연스럽게 수렴되는 구조다. 이것이 “규칙을 강제하지 말고 원리를 가르쳐라”의 결과다.

이미 프로덕션 레벨인가?

좋은 설계라는 평가와 별개로, 이걸 곧바로 프로덕션 해법으로 받아들이기에는 아직 이른 면이 있다. 냉정하게 한계를 짚어보면 이렇다.

1. 벤더 락인 — SKILL.md는 열려 있지만, 핵심은 닫혀 있다.

SKILL.md 자체는 마크다운 + YAML frontmatter다. 표준 기술이고 어디서든 읽을 수 있다. 하지만 트리거 최적화(run_loop.py)와 블라인드 비교는 claude -p CLI가 필요하다. Cursor, Copilot, Windsurf에서 이 SKILL.md를 실행할 수 있는가? 마크다운은 읽히겠지만, 트리거 라우팅과 Phase 파이프라인은 Claude Code의 스킬 시스템이 해석해야 동작한다. 멀티 에이전트 환경에서의 이식성(portability)은 현재 없다.

2. 도입 비용이 높다.

스킬 하나를 제대로 만들고 최적화하려면 테스트 루프를 여러 번 돌려야 한다. “5분이면 뚝딱”이 아니라 “반나절은 잡아야 할” 작업이다. API 비용도 무시할 수 없다 — 트리거 최적화 루프 5회에 블라인드 비교까지 돌리면 토큰 수만 개가 소모된다. DX를 개선하겠다는 도구의 초기 비용이 반나절이면, 대부분의 개발자는 기존 방식을 유지할 것이다.

3. 스킬 유지보수 비용이 보이지 않는다.

10인 팀에서 스킬 3개 만드는 건 쉽다. 50인 조직에서 각 팀이 자기 스킬을 만들기 시작하면? 스킬 간 충돌, 버전 관리, 팀 간 표준화 — 새로운 관리 비용이 생긴다. 팀 컨벤션이 바뀌면 SKILL.md를 누가, 언제 업데이트하나? 스킬을 만드는 것보다 유지하는 것이 더 어려운 문제다.

4. 기존 도구와의 경계가 불분명하다.

코드 리뷰 스킬의 TypeScript Strict Mode 감사? ESLint나 Biome의 커스텀 룰로도 가능하다. 릴리즈 노트 자동화? release-please, semantic-release 같은 성숙한 도구가 이미 있다. 이 스킬이 기존 도구를 대체하는 것인지, 위에 얹어지는 것인지 — 포지셔닝이 명확하지 않으면 도입 근거가 약해진다.

그럼에도 쓸 가치가 있는 이유

한계가 많은데 왜 이 도구를 분석하고, 다음 편에서 직접 만들어보는가?

그럼에도 이 접근이 무시하기 어려운 이유는 분명하다. 진짜 가치는 스킬 자체가 아니라, “팀의 암묵지를 명시지로 바꾸는 행위”에 있다.

SKILL.md를 작성하려면 “우리 팀의 규칙이 정확히 뭐지?”를 처음으로 정리해야 한다. “any 쓰지 마세요”를 “왜 any가 안 되는지, 어디까지가 위반인지, as 캐스팅은 되는 건지” 수준까지 파고들어야 한다. 이 정리 과정 자체가 팀 컨벤션 문서화의 부산물이다.

기존 도구 비교? ESLint는 AST 수준의 정적 분석, 이 스킬은 “이벤트 핸들러 내부에 비즈니스 로직이 있는가” 같은 의미론적 판단이다. release-please는 커밋 메시지를 그대로 나열하고, 이 스킬은 “fix: null pointer in auth middleware”를 “로그인 오류 수정”으로 번역한다. 겹치면서도 다른 레이어다.

결국 이 도구의 본질은 **“AI에게 우리 팀의 판단 기준을 가르치는 것”**이다. 린터는 문법을 안다. 이 스킬은 “우리 팀에서는 이게 왜 안 되는지”를 안다. 판단을 코드화하는 것 — 그게 프롬프트 엔지니어링과 스킬 엔지니어링의 차이다.

• “각자 프롬프트 짜는” 상태에서 “팀 전체가 같은 스킬을 쓰는” 상태로 가고 싶은 테크 리드
• 사내 AI 도구 파이프라인을 구축하려는 CTO — 스킬을 한 번 만들면 팀 전체에 배포할 수 있다
• 프롬프트를 “잘 쓰는” 단계를 넘어 “구조화하는” 단계로 가려는 시니어

다음 편부터는 직접 돌려본다. 3개의 스킬을 만들고, 이 글에서 분석한 메커니즘이 실전에서 작동하는지 검증한다.

관련 링크

• 2편: 코드 리뷰 스킬 — 팀 컨벤션을 AI에 이식하기
• 3편: 릴리즈 노트 자동 생성 — git log를 사용자 언어로
• 4편: 온보딩 문서 생성 — 과적합과의 싸움
• 이 시리즈에서 생성한 3개 스킬 (GitHub) — 실제 SKILL.md 전체 코드
• skill-creator 원본 (GitHub) — 486줄 팩토리 코드
• Anthropic Skills Repository

프롬프트를 잘 쓰는 것은 기술이다. 프롬프트를 잘 쓸 수밖에 없는 구조를 만드는 것은 엔지니어링이다.