프롬프트의 한계에서 시작하자
프롬프트를 다듬다 보면 어느 순간 벽에 닿는다. 공들여 만든 지시문이 1회용이라는 것. 메모장에 복사해두고, 쓸 때마다 찾아서, 붙여넣고, 상황에 맞게 고치고… 이 과정 자체가 새로운 반복 작업이 된다.
스킬(Skill)은 검증된 작업 절차를 파일로 저장해, 명령어 하나로 재실행하는 방법이다. /회의록이라고 입력하면 저장된 절차 전체 — 자료 읽기, 형식 맞추기, 검토, 저장 — 가 순서대로 실행된다.
프롬프트는 지시이고, 스킬은 자산이다. 지시는 사라지지만 자산은 쌓인다.
스킬이 하나씩 쌓이면 범용 AI가 내 업무에 특화된 전용 도구로 바뀐다. 이 글은 그 개념부터 제작, 운영까지를 다룬다.
프롬프트 vs 스킬: 무엇이 다른가
| 프롬프트 | 스킬 | |
|---|---|---|
| 형태 | 대화창에 입력하는 지시문 | 파일로 저장된 절차 문서 |
| 수명 | 그 대화에서 끝 | 영구 (파일이니까) |
| 실행 | 매번 작성·붙여넣기 | /이름 한 단어 |
| 개선 | 기억에 의존 | 파일에 규칙이 누적 |
| 공유 | 메신저로 텍스트 전달 | 파일 복사로 끝 |
핵심 차이는 개선의 누적이다. 프롬프트로 일하면 “지난번에 뭐라고 지시했더라”를 매번 떠올려야 하지만, 스킬은 시행착오에서 배운 규칙이 파일에 차곡차곡 쌓인다. 석 달 뒤의 스킬은 오늘의 스킬보다 확실히 낫다.
(참고: 여기서 다루는 스킬은 Claude Code 기준이다. 도구가 달라도 “절차를 파일로 저장해 재사용한다”는 원리는 같다. Claude Code 자체가 처음이라면 설치 가이드를 먼저 보자.)
스킬의 구조: 파일 하나가 전부다
작업 폴더의 .claude/skills/ 아래에 스킬 이름의 폴더를 만들고, 그 안에 SKILL.md 파일을 두면 끝이다.
내 작업폴더/
└── .claude/
└── skills/
└── 회의록/
└── SKILL.md
이것만으로 /회의록이라는 명령어가 생긴다. SKILL.md의 내용은 마크다운으로 쓰는 평범한 문서다.
---
name: 회의록
description: 녹취록이나 메모를 표준 회의록으로 정리한다
---
# 회의록
## 실행 조건
사용자가 /회의록 [파일경로] 로 호출할 때
## 절차
1. 파일 전체를 읽는다
2. 다음 구조로 정리한다:
- 회의 개요 (일시, 참석자, 주제)
- 논의 내용 (주제별 3–5줄)
- 결정 사항 (번호 목록)
- 액션 아이템 (담당자와 기한 표기)
3. '결과물/회의록_[날짜].md' 로 저장한다
## 금지사항
- 발언하지 않은 내용을 추론해서 적지 않는다
- 결정 사항과 논의 사항을 섞지 않는다
4가지 구성 요소
| 구성 | 역할 | 작성 요령 |
|---|---|---|
| 이름·설명 | 스킬 식별 | 상단에 한 줄로 |
| 실행 조건 | 언제 발동하나 | 호출 형식과 인자(파일경로 등) 명시 |
| 절차 | 무엇을 순서대로 | 번호 목록, 한 단계 = 한 행동 |
| 금지사항 | 무엇을 하면 안 되나 | 시행착오가 쌓이는 곳 |
절차만 쓰고 금지사항을 비워두기 쉬운데, 실전에서는 금지사항이 품질을 결정한다. “해라”는 대체로 지켜지지만, 적지 않은 “당연한 것”에서 사고가 나기 때문이다.
제작 방법: 두 가지 경로
방법 A — 성공한 작업을 굳히기 (추천)
가장 좋은 스킬 재료는 방금 만족스럽게 끝난 작업이다. 그 자리에서 이렇게 말한다.
“방금 한 작업 과정을 스킬로 만들어줘. 이름은 ‘회의록’으로.”
AI가 대화 내용을 바탕으로 SKILL.md를 직접 작성한다. 절차가 상상이 아니라 실제 성공 사례에서 나오기 때문에, 백지에서 쓰는 것보다 정확하다.
방법 B — 직접 설계하기
처음부터 손으로 써도 된다. 이때 지킬 것은 하나 — 작게 시작하라. 첫 버전은 절차 3줄이면 충분하다.
## 절차
1. 파일을 읽는다
2. 핵심 3가지를 뽑는다
3. 결과물 폴더에 저장한다
이걸로 몇 번 돌려보고, 마음에 안 드는 부분이 나올 때마다 규칙을 추가한다. 처음부터 완벽한 20줄 절차를 설계하려는 시도는 대부분 실패한다 — 실제로 어디서 어긋나는지는 돌려보기 전엔 모르기 때문이다.
무엇을 스킬로 만들까: 판단 기준 3가지
전부 스킬로 만들 필요는 없다. 세 조건을 확인하자.
| 조건 | 이유 |
|---|---|
| 주 1회 이상 반복하는가 | 빈도가 낮으면 그냥 대화가 빠르다 |
| 절차가 3단계 이상인가 | 한 문장 지시는 스킬화 이득이 없다 |
| 품질 기준이 명확한가 | ”이 형식, 이 체크리스트”가 있어야 절차가 된다 |
셋 다 해당하면 만들 가치가 충분하고, 하나도 해당하지 않으면 말로 시키는 게 낫다. 좋은 첫 스킬 후보: 주간 보고 초안, 회의록 정리, 자료 요약, 파일 정리 — “매번 하는데 매번 귀찮은 것” 이 정답이다.
활용과 운영: 실패하지 않는 원칙 4가지
1. 금지사항은 시행착오의 기록이다
운영하다 마음에 안 드는 결과가 나오면, 그 사례를 금지사항에 한 줄 추가한다. “표에 단위를 빼먹었다” → “모든 수치에 단위를 표기한다”. 이 축적이 스킬의 진짜 가치다.
2. 되돌리기 어려운 단계 앞에는 확인을 넣는다
삭제, 대량 이동, 외부 전송처럼 실수 비용이 큰 단계 앞에는 절차에 이렇게 명시한다.
3. 변경 계획을 먼저 보여주고, 승인을 받은 후 실행한다
3. 스킬이 스스로 검사하게 한다
품질 기준을 체크리스트로 만들어 절차 안에 넣으면, 검사를 내 기억력에 의존하지 않게 된다.
## 자체 검토
저장 전에 다음을 확인하고 결과를 출력한다:
- [ ] 모든 수치에 단위가 있는가
- [ ] 결정 사항에 담당자가 있는가
- [ ] 출처가 명시되었는가
4. 다듬는 것도 AI에게 시킨다
스킬 수정에 편집기를 열 필요도 없다. “방금 결과에서 표 형식이 어긋났어. 스킬에 표 규칙을 추가해줘”라고 하면 AI가 SKILL.md를 직접 고친다. 스킬은 만들고 끝나는 문서가 아니라 계속 길러지는 문서다.
흔한 실수 3가지
- 너무 큰 스킬 하나 — “조사부터 보고서 완성까지”를 한 스킬에 담으면 중간 통제를 잃는다. 조사 스킬 + 작성 스킬로 나누고, 필요하면 순서대로 호출하자
- 검증 안 된 절차를 스킬화 — 스킬은 성공을 복제하는 도구지, 성공을 만들어주는 도구가 아니다. 먼저 대화로 만족스러운 결과를 만들고, 그 다음에 굳히자
- 사람의 최종 검토 생략 — 아무리 정교한 스킬도 산출물의 책임은 사람에게 있다. 특히 외부로 나가는 결과물은 반드시 직접 읽어보자
정리: 프롬프트 → 스킬 → 시스템
이 카테고리의 흐름을 한 줄로 정리하면 이렇다.
- 프롬프트 로 원하는 결과를 얻는 법을 익히고
- 잘 되는 프롬프트를 스킬로 굳혀 자산으로 만들고
- 스킬들이 쌓이면 나만의 업무 시스템이 된다
첫 스킬은 오늘 가장 귀찮았던 반복 작업으로 시작하자. 3줄짜리 절차면 충분하다.