핵심 개념: Claude Code의 "스킬(Skill)"은 SKILL.md 파일에 정의된 재사용 가능한 워크플로우 패키지입니다. 슬래시 커맨드가 "단일 프롬프트의 자동화"라면, 스킬은 "복잡한 멀티스텝 워크플로우의 패키지화"입니다.
PM이 Claude Code에서 반복 작업을 자동화하는 방법은 3가지입니다.
┌─────────────────────────────────────────────────────────────────┐
│ Claude Code 재사용 메커니즘 │
├──────────────────┬──────────────────┬───────────────────────────┤
│ 슬래시 커맨드 │ 커스텀 스킬 │ 커스텀 에이전트 │
│ (.claude/ │ (.claude/ │ (.claude/ │
│ commands/) │ skills/) │ agents/) │
├──────────────────┼──────────────────┼───────────────────────────┤
│ 단일 프롬프트 │ SKILL.md + │ 시스템 프롬프트 + │
│ 마크다운 파일 │ 보조 파일 패키지 │ 도구 제한 설정 │
├──────────────────┼──────────────────┼───────────────────────────┤
│ /today 입력 │ 자동 감지 or │ Task 도구로 │
│ → 즉시 실행 │ 명시적 호출 │ 서브에이전트 실행 │
├──────────────────┼──────────────────┼───────────────────────────┤
│ "아침 브리핑 │ "PPT 만들 때 │ "엔지니어 관점에서 │
│ 생성해줘" │ 항상 이 가이드 │ 이 PRD 리뷰해줘" │
│ │ 따라서 만들어" │ │
├──────────────────┼──────────────────┼───────────────────────────┤
│ 적합한 상황: │ 적합한 상황: │ 적합한 상황: │
│ 반복 프롬프트 │ 품질 기준이 있는 │ 다른 관점/페르소나 │
│ 빠른 실행 │ 복잡한 작업 │ 필요한 리뷰 작업 │
└──────────────────┴──────────────────┴───────────────────────────┘
Q: 슬래시 커맨드로 충분하지 않나요?
슬래시 커맨드는 "무엇을 해달라"는 단일 지시문입니다. 스킬은 그 이상입니다:
- 맥락 주입: 작업 시작 전에 "이 가이드를 먼저 읽어"라는 배경 지식을 제공
- 품질 기준 내장: "이 체크리스트를 반드시 따라"라는 품질 보증 장치
- 보조 파일 포함: 템플릿, 예시, 스타일 가이드 등을 함께 패키지화
- 자동 트리거: 특정 파일 유형을 다룰 때 자동으로 활성화
실제 예시 비교:
# 슬래시 커맨드: /prd
→ "PRD를 작성해줘" (프롬프트 실행)
# 스킬: prd-writer
→ SKILL.md에 정의된 PRD 작성 가이드라인을 먼저 읽음
→ 템플릿 파일(prd-template.md)을 로드
→ 체크리스트(prd-checklist.md)로 품질 검증
→ 회사의 PRD 스타일 가이드를 적용
→ 결과물을 자동으로 지정 폴더에 저장
.claude/skills/
├── prd-writer/
│ ├── SKILL.md ← 스킬 정의 (필수)
│ ├── prd-template.md ← 보조 파일 (선택)
│ └── checklist.md ← 보조 파일 (선택)
│
├── weekly-report/
│ ├── SKILL.md
│ └── report-format.md
│
└── competitor-brief/
├── SKILL.md
└── analysis-framework.md
---
name: prd-writer
description: "회사 표준에 맞는 PRD를 작성합니다. PRD, 요구사항 문서, 제품 스펙 작성 시 자동으로 활성화됩니다."
---
## 1. 역할 정의
당신은 10년 경력의 시니어 PM입니다. 다음 원칙을 따릅니다:
- 유저 문제 → 가설 → 검증 가능한 지표 순서로 사고
- 엔지니어가 바로 작업할 수 있는 수준의 구체성
- 비즈니스 임팩트를 항상 정량화
## 2. 작업 절차
PRD 작성 시 다음 순서를 따르세요:
1. 먼저 이 폴더의 prd-template.md를 읽고 구조를 파악
2. 유저에게 "해결하려는 문제"와 "성공 지표"를 반드시 확인
3. 템플릿의 각 섹션을 채우되, [PM 판단 필요] 태그 적극 사용
4. 완성 후 checklist.md의 항목으로 자체 검증
## 3. 품질 기준
- [ ] 문제 정의가 "누가 + 언제 + 어떤 상황에서"를 포함하는가?
- [ ] 성공 지표가 측정 가능한 숫자인가?
- [ ] 스코프가 MVP 수준으로 좁혀져 있는가?
- [ ] 엔지니어가 읽었을 때 바로 작업 가능한가?
- [ ] Not Doing 리스트가 명시되어 있는가?
## 4. 출력 형식
결과물은 docs/prd/ 폴더에 YYYY-MM-DD-제목.md 형식으로 저장하세요.---
name: prd-writer # 스킬 이름 (kebab-case)
description: "회사 표준..." # 스킬 설명 + 트리거 키워드
---description에 포함된 키워드가 중요합니다. Claude Code는 이 설명을 읽고 "지금 사용자의 요청에 이 스킬이 적합한가?"를 판단합니다.
목적: 회사 표준에 맞는 PRD를 일관되게 생성
# .claude/skills/prd-writer/SKILL.md
---
name: prd-writer
description: "제품 요구사항 문서(PRD)를 회사 표준에 맞게 작성합니다.
PRD, 요구사항, 제품 스펙, 기능 정의서 작성 시 활성화됩니다."
---
## 역할
당신은 데이터 드리븐 시니어 PM입니다.
## 작업 절차
1. prd-template.md를 로드하여 구조 파악
2. 사용자에게 다음을 확인:
- 해결하려는 유저 문제
- 타겟 페르소나
- 성공 지표 (OMTM)
3. 각 섹션을 작성하되:
- 문제 정의: "누가 + 언제 + 무엇을" 형식
- 가설: "만약 X를 하면 Y가 Z만큼 개선될 것이다"
- 스코프: P0/P1/P2 우선순위 매트릭스
- Not Doing: 의도적 제외 항목 명시
4. [PM 판단 필요] 태그로 사람의 결정이 필요한 지점 표시
5. checklist.md로 자체 품질 검증
## 품질 체크리스트
- 문제 정의에 정량 데이터가 있는가?
- 성공 지표가 측정 가능한가?
- 엔지니어가 바로 작업 가능한 수준인가?
- 디자이너가 와이어프레임을 그릴 수 있는 수준인가?보조 파일: prd-template.md
# [제품명] PRD — [기능명]
## 1. 문제 정의
### 유저 문제
[누가] [언제] [어떤 상황에서] [무엇이] 불편하다
### 데이터 근거
- 현재 지표: [구체적 수치]
- 유저 피드백: [인터뷰/설문 결과 요약]
## 2. 가설
만약 [솔루션]을 제공하면, [타겟 지표]가 [목표치]만큼 개선될 것이다.
## 3. 성공 지표
| 지표 | 현재값 | 목표값 | 측정 방법 |
|------|--------|--------|-----------|
| OMTM | | | |
| 보조 지표 1 | | | |
## 4. 솔루션 스코프
### P0 — 반드시 포함
### P1 — 가능하면 포함
### P2 — 다음 이터레이션
### Not Doing — 의도적 제외
## 5. 사용자 스토리
## 6. 기술 고려사항
## 7. 일정
## 8. 리스크 및 의존성목적: 주간 보고서를 자동으로 수집·정리
# .claude/skills/weekly-report/SKILL.md
---
name: weekly-report
description: "주간 보고서, 위클리 리포트, 스프린트 리뷰 문서를 생성합니다."
---
## 역할
당신은 프로젝트 진행 상황을 명확하게 전달하는 PM입니다.
## 작업 절차
1. 이번 주 작업 내역 수집:
- tasks/ 폴더에서 완료된 항목 목록화
- status/ 에서 이전 주간 보고서 읽고 진행 흐름 파악
- 커밋 로그/PR 목록에서 주요 변경사항 추출
2. 다음 주 계획 정리:
- tasks/ 에서 다음 주 마감 항목 식별
- 블로커 및 리스크 정리
3. report-format.md 템플릿에 맞춰 작성
4. 핵심 숫자(지표 변화)를 반드시 포함
## 출력 형식
파일명: status/weekly-YYYY-WNN.md
톤: 경영진이 3분 안에 읽을 수 있는 수준
## 품질 기준
- 3줄 요약(TL;DR)이 있는가?
- 모든 항목이 "완료/진행중/블로커" 상태를 가지는가?
- 다음 주 액션 아이템에 담당자가 있는가?목적: 경쟁사 분석을 표준화된 프레임워크로 수행
# .claude/skills/competitor-brief/SKILL.md
---
name: competitor-brief
description: "경쟁사 분석, 경쟁 제품 비교, 마켓 리서치 브리프를 작성합니다."
---
## 역할
당신은 베테랑 유저 리서처 겸 전략 PM입니다.
## 분석 프레임워크 (5축)
모든 경쟁사를 다음 5가지 축으로 분석:
1. **포지셔닝**: 타겟 세그먼트와 핵심 메시지
2. **기능 깊이**: 핵심 기능의 완성도와 차별점
3. **가격 전략**: 프리미엄/프리미엄/PLG 모델
4. **성장 신호**: 채용, 투자, 트래픽, 리뷰 트렌드
5. **취약점**: 유저 불만, 이탈 이유, 기술 부채
## 작업 절차
1. 경쟁사별 analysis-framework.md의 5축을 채움
2. 기회 매트릭스 생성: [경쟁사 약점] × [우리 강점]
3. So What? 한 줄 결론 도출: "이것이 우리 제품에 의미하는 바는..."
4. [PM 판단 필요] 태그로 주관적 해석 지점 명시
## 출력 형식
research/competitive/YYYY-MM-경쟁사명.md목적: 유저 인터뷰 노트를 구조화된 인사이트로 변환
# .claude/skills/interview-synth/SKILL.md
---
name: interview-synth
description: "유저 인터뷰 요약, 인터뷰 합성, FGI 분석, 사용자 조사 결과를 정리합니다."
---
## 역할
당신은 유저 리서처입니다. 공감과 객관성을 동시에 유지합니다.
## 분석 절차
1. 인터뷰 원문에서 핵심 발언(Verbatim) 추출
2. 어피니티 맵핑: 유사한 발언을 테마별로 그룹핑
3. 각 테마별:
- 빈도: N명 중 몇 명이 언급?
- 강도: 불편 정도 (1~5)
- 인용문: 대표적인 원문 발언
4. 패턴 → 인사이트 → Opportunity 순서로 상승
## 핵심 질문
각 인사이트에 대해:
- "이 문제가 해결되지 않으면 유저는 어떻게 하는가?" (대안 행동)
- "이 문제를 해결하면 어떤 지표가 움직이는가?" (비즈니스 임팩트)
- "이 인사이트에 동의하지 않는 근거는 무엇인가?" (반론)
## 출력 형식
research/interviews/synth-YYYY-MM-DD.md목적: 릴리즈 노트를 유저 관점으로 작성
# .claude/skills/release-note/SKILL.md
---
name: release-note
description: "릴리즈 노트, 업데이트 공지, 체인지로그를 작성합니다."
---
## 역할
당신은 유저 커뮤니케이션 전문가입니다.
## 작성 원칙
1. **기능이 아닌 가치를 말하라**
- ❌ "검색 알고리즘을 BM25에서 하이브리드로 변경"
- ✅ "검색 결과가 더 정확해졌습니다. 원하는 문서를 평균 40% 더 빨리 찾을 수 있습니다."
2. **Before/After로 보여줘라**
- 이전: ~하려면 ~해야 했습니다
- 이후: ~만 하면 됩니다
3. **임팩트를 숫자로**
- 가능하면 "%개선", "N초 단축" 등 정량화
## 작업 절차
1. 커밋 로그/PR 목록에서 유저 임팩트 있는 변경사항 추출
2. 각 변경사항을: Feature / Improvement / Bug Fix로 분류
3. 유저 관점의 한 줄 설명 작성
4. 가장 임팩트 큰 1~2개에 Before/After 설명 추가
## 출력 형식
content/release-notes/vX.Y.Z.mdTerminal 입력:
$ mkdir -p .claude/skills/prd-writer
Claude Code 응답:
✅ 디렉토리가 생성되었습니다: .claude/skills/prd-writer/
Terminal 입력:
$ claude code
> .claude/skills/prd-writer/SKILL.md 파일을 만들어줘.
다음 요구사항을 반영해:
1. 역할: 데이터 드리븐 시니어 PM
2. 작업 절차: 문제정의 → 가설 → 스코프 → 스토리
3. 품질 기준: 측정 가능한 지표, 엔지니어 실행 가능성
4. 트리거 키워드: PRD, 요구사항, 제품 스펙
Claude Code 응답:
📝 .claude/skills/prd-writer/SKILL.md를 생성합니다:
---
name: prd-writer
description: "PRD, 요구사항, 제품 스펙 작성 시 활성화..."
---
[... 스킬 내용 ...]
이 스킬을 적용할까요? (y/n)
> 이 스킬에 쓸 PRD 템플릿 파일도 같은 폴더에 만들어줘.
우리 회사의 PRD에는 반드시 다음이 포함되어야 해:
- 문제 정의 (데이터 근거 포함)
- 가설 (if-then 형식)
- 성공 지표 (OMTM + 보조)
- MVP 스코프 (P0/P1/P2)
- Not Doing 리스트
> 새로 만든 prd-writer 스킬을 사용해서
"모바일 앱 푸시 알림 개인화" 기능의 PRD를 작성해줘
Claude Code 응답:
🔧 prd-writer 스킬을 로드합니다...
📋 SKILL.md의 가이드라인을 따릅니다.
📄 prd-template.md 템플릿을 적용합니다.
먼저 몇 가지 확인이 필요합니다:
1. 해결하려는 유저 문제는 무엇인가요?
2. 타겟 페르소나는 누구인가요?
3. 현재 관련 지표가 있나요?
💡 PM 판단 포인트: 스킬이 질문을 던지는 것이 핵심입니다. 좋은 스킬은 바로 결과를 내놓지 않고, PM에게 "이것은 당신이 결정해야 할 부분"이라고 알려줍니다.
자주 쓰는 스킬은 스케줄 태스크로 등록하여 자동화할 수 있습니다.
> 이 weekly-report 스킬을 매주 금요일 오후 4시에 자동 실행되도록
스케줄 태스크로 만들어줘
Claude Code 응답:
📅 스케줄 태스크를 생성합니다:
taskName: weekly-report-auto
schedule: "0 16 * * 5" (매주 금요일 16:00)
description: "weekly-report 스킬을 실행하여 이번 주 진행 상황을
수집하고 status/weekly-YYYY-WNN.md 파일로 저장합니다."
생성할까요? (y/n)
| 스킬 | 스케줄 | 출력 |
|---|---|---|
| weekly-report | 매주 금 16:00 | status/weekly-YYYY-WNN.md |
| competitor-brief | 매월 1일 09:00 | research/competitive/ |
| kpi-check | 매일 09:00 | dashboard/daily-kpi.md |
| release-note | 배포 후 수동 트리거 | content/release-notes/ |
.claude/
├── skills/ ← 스킬 (복잡한 워크플로우)
│ ├── prd-writer/
│ ├── weekly-report/
│ ├── competitor-brief/
│ ├── interview-synth/
│ └── release-note/
│
├── commands/ ← 슬래시 커맨드 (단일 프롬프트)
│ ├── today.md
│ ├── status.md
│ └── standup.md
│
├── agents/ ← 커스텀 에이전트 (관점/페르소나)
│ ├── engineer-reviewer.md
│ ├── exec-reviewer.md
│ └── user-researcher.md
│
└── settings.json ← MCP 등 연동 설정
좋은 이름:
✅ prd-writer → 무엇을 하는지 명확
✅ competitor-brief → 출력물이 뭔지 알 수 있음
✅ interview-synth → 동작이 명확
나쁜 이름:
❌ analysis → 너무 모호
❌ my-skill-v2 → 버전 관리는 Git으로
❌ do-stuff → 설명 없음
프로젝트 루트/
├── .claude/
│ └── skills/ ← Git에 커밋 → 팀 전체가 사용
│ ├── prd-writer/
│ └── weekly-report/
│
└── ~/.claude/
└── skills/ ← 개인 전용 (Git 미포함)
└── my-shortcuts/
팀 공유 체크리스트:
- 프로젝트의
.claude/skills/에 넣으면 → Git push 시 팀 전원에게 배포 ~/.claude/skills/에 넣으면 → 개인만 사용description에 충분한 키워드를 넣어야 다른 팀원도 자동 트리거 가능- 보조 파일(템플릿, 체크리스트)도 함께 커밋해야 스킬이 완전히 동작
좋은 스킬의 4가지 조건:
1. 자기완결적 (Self-contained)
→ SKILL.md만 읽으면 무엇을 어떻게 하는지 완전히 이해 가능
2. PM 판단 지점 명시
→ "[PM 판단 필요]" 태그로 사람이 결정할 부분 표시
3. 품질 체크리스트 내장
→ 결과물 생성 후 자체 검증 단계 포함
4. 출력 경로 명확
→ 결과 파일이 어디에 저장되는지 명시
Terminal 입력:
> 내가 지난 2주간 Claude Code에서 가장 많이 한 요청 유형을 분석해줘.
대화 히스토리를 보고, 패턴이 보이는 작업을 카테고리별로 정리해줘.
Claude Code 응답:
📊 지난 2주 작업 패턴 분석:
1. PRD/문서 작성 (18회, 35%)
→ 매번 비슷한 구조 반복, 품질 편차 큼
→ 스킬 추천: prd-writer ⭐
2. 주간 보고서 (4회, 8%)
→ 매주 금요일 같은 형식
→ 스킬 추천: weekly-report + 스케줄 ⭐
3. 경쟁사 조사 (6회, 12%)
→ 분석 프레임워크 매번 다시 설명
→ 스킬 추천: competitor-brief ⭐
4. 데이터 분석 (8회, 15%)
→ SQL/Python 코드 생성 후 해석
→ 슬래시 커맨드로 충분
5. 기타 단발성 (15회, 30%)
→ 패턴 없음, 스킬화 불필요
💡 PM 판단 포인트: 스킬을 만들 가치가 있는 작업의 기준은 "주 2회 이상 반복 + 매번 같은 가이드라인이 필요한 작업"입니다. 단순 반복은 슬래시 커맨드로 충분합니다.
> prd-writer, weekly-report, competitor-brief
세 가지 스킬의 SKILL.md를 만들어줘.
각각 우리 회사의 기존 템플릿을 반영해야 해.
docs/templates/ 폴더에 있는 파일들을 참고해서 만들어줘.
Claude Code 응답:
📂 docs/templates/ 폴더를 분석합니다...
발견된 템플릿:
- prd-template-v3.md → prd-writer 스킬에 반영
- weekly-report-format.docx → weekly-report 스킬에 반영
- competitor-analysis-sheet.xlsx → competitor-brief 스킬에 반영
각 스킬의 SKILL.md를 생성하고, 기존 템플릿을 마크다운으로 변환하여
보조 파일로 포함하겠습니다.
[... 3개 스킬 생성 ...]
> prd-writer 스킬의 결과물이 엔지니어 피드백에서 "기술 고려사항"이
부족하다는 지적을 받았어.
이 피드백을 반영해서 스킬을 업데이트해줘.
Claude Code 응답:
📝 prd-writer/SKILL.md를 업데이트합니다:
--- 변경 사항 ---
## 작업 절차
... (기존 내용)
+ ### 추가: 기술 고려사항 섹션 강화
+ 4-1. 다음을 반드시 포함:
+ - 성능 영향도 (레이턴시, 처리량)
+ - 데이터 마이그레이션 필요 여부
+ - API 호환성 (breaking change 유무)
+ - 인프라 비용 변화 추정
+ 4-2. [PM 판단 필요] "엔지니어와 논의 후 확정" 태그 추가
이 변경을 적용할까요? (y/n)
하나의 스킬 출력이 다음 스킬의 입력이 되는 패턴:
interview-synth → competitor-brief → prd-writer
(인터뷰 합성) (경쟁 분석) (PRD 작성)
Terminal 입력:
> 1단계: research/interviews/ 폴더의 인터뷰 노트를 합성해줘 (interview-synth)
2단계: 그 결과를 바탕으로 경쟁사 3곳을 분석해줘 (competitor-brief)
3단계: 인터뷰 인사이트 + 경쟁 분석을 반영한 PRD를 작성해줘 (prd-writer)
같은 문서를 여러 관점에서 동시에 검토:
PRD 초안 → [엔지니어 에이전트] + [디자이너 에이전트] + [비즈니스 에이전트]
→ 리뷰 결과 통합
이 패턴은 스킬 + 에이전트를 조합합니다.
스킬이 "무엇을 만들지"를 정의하고,
에이전트가 "어떤 관점에서 볼지"를 정의합니다.
조건에 따라 다음 액션이 달라지는 패턴:
# .claude/skills/kpi-alert/SKILL.md
---
name: kpi-alert
description: "KPI 이상 감지 시 자동 알림 및 분석을 수행합니다."
---
## 작업 절차
1. dashboard/daily-kpi.md에서 KPI 데이터 읽기
2. 이전 7일 평균 대비 변화율 계산
3. 조건별 분기:
- 변화율 ±5% 이내: "정상" 로그만 기록
- 변화율 ±5~15%: 원인 분석 리포트 생성
- 변화율 ±15% 이상: [PM 즉시 확인 필요] 태그 + 상세 분석❌ 나쁜 예:
"PRD 작성 + 디자인 리뷰 + 엔지니어 핸드오프 + QA 체크리스트"를
하나의 스킬에 모두 담기
→ 문제: 스킬이 너무 무거워져서 실행 시간이 길고, 중간에 실패하면 처음부터 다시
✅ 좋은 예:
prd-writer → design-handoff → qa-checklist
각각 독립적인 스킬로 분리하고, 필요시 파이프라인으로 연결
❌ 나쁜 예:
description: "보고서를 작성합니다."
→ "주간 보고서 만들어줘"라고 해도 자동 트리거 안 될 수 있음
✅ 좋은 예:
description: "주간 보고서, 위클리 리포트, 스프린트 리뷰, 주간 현황을 정리합니다."
→ 다양한 표현으로 트리거 가능
❌ 나쁜 예:
"자동으로 PRD를 완성하고 Jira 티켓까지 생성"
→ PM이 검토할 기회 없이 티켓이 생성됨
✅ 좋은 예:
"PRD 초안 완성 후 [PM 판단 필요] 태그가 있는 3가지 지점을 확인하세요.
승인 후에 Jira 티켓 생성을 진행합니다."
매번 같은 PRD 구조를 처음부터 설명 (15분)
→ 품질이 세션마다 다름
→ 새 팀원에게 "우리 팀 PRD 스타일"을 구두로 전달
→ 좋은 패턴이 있어도 개인에게만 남음
"prd-writer 스킬 써서 PRD 만들어줘" (10초)
→ 항상 같은 품질 기준 적용
→ 새 팀원도 스킬 실행만으로 팀 표준 적용
→ 좋은 패턴을 스킬로 코드화하여 팀 전체에 전파
스킬 시스템이 정착되면, PM의 역할에 새로운 차원이 추가됩니다:
- 스킬 설계자: 팀의 반복 워크플로우를 식별하고 스킬로 패키지화
- 품질 기준 정의자: SKILL.md의 체크리스트가 곧 팀의 품질 기준
- 지식 코드화자: 암묵지(PM의 노하우)를 형식지(SKILL.md)로 변환
- 워크플로우 아키텍트: 스킬 조합 패턴을 설계하여 팀 생산성 극대화
💡 핵심 질문: "내가 매주 반복하는 작업 중, 스킬로 만들면 팀 전체가 혜택받을 것은 무엇인가?"
과제: 자주 사용하는 하나의 프롬프트를 스킬로 변환하세요.
1. .claude/skills/my-first-skill/ 폴더 생성
2. SKILL.md 작성 (name, description, 절차)
3. 테스트: 실제 작업에 적용하여 결과 비교
성공 기준:
- SKILL.md의 description에 트리거 키워드 3개 이상
- 작업 절차가 3단계 이상
- 품질 체크리스트 항목 3개 이상
과제: 팀에서 공유할 3개의 스킬을 만들고 Git에 커밋하세요.
1. 팀의 반복 작업 패턴 분석 (최소 2주 데이터)
2. 상위 3개를 스킬로 변환
3. 각 스킬에 보조 파일 (템플릿/체크리스트) 포함
4. Git에 커밋하고 팀에 공유
성공 기준:
- 3개 스킬 모두 보조 파일 포함
- 팀원 1명 이상이 실제 사용 후 피드백
- 피드백 반영하여 스킬 1회 이상 업데이트
과제: 3개 이상의 스킬을 연결한 End-to-End 워크플로우를 설계하세요.
1. Discovery → Definition → Delivery 중 하나의 흐름 선택
2. 각 단계에 적합한 스킬을 설계 또는 기존 스킬 활용
3. 스킬 간 입출력 인터페이스 정의
4. 전체 파이프라인 테스트 및 문서화
성공 기준:
- 3개 이상 스킬의 파이프라인 동작 확인
- 전체 수행 시간이 수동 대비 50% 이상 단축
- 팀 위키에 파이프라인 가이드 문서화
| 항목 | 슬래시 커맨드 | 커스텀 스킬 | 커스텀 에이전트 |
|---|---|---|---|
| 저장 위치 | .claude/commands/ | .claude/skills/ | .claude/agents/ |
| 파일 형식 | 단일 .md | SKILL.md + 보조 파일 | 단일 .md |
| 실행 방식 | /명령어 | 자동 감지 or 명시적 | Task 도구 |
| 복잡도 | 낮음 | 중간~높음 | 중간 |
| 적합한 작업 | 단순 반복 프롬프트 | 품질 기준 있는 복잡 작업 | 관점/페르소나 리뷰 |
| 팀 공유 | Git 커밋 | Git 커밋 | Git 커밋 |
| 스케줄 가능 | ❌ | ✅ | ❌ |
다음 단계: 이 가이드의 3.3-slash-commands.md에서 슬래시 커맨드를 먼저 만들어보고, 스킬이 필요한 복잡한 작업으로 점차 전환해보세요. 2.4-custom-subagents.md에서 에이전트까지 조합하면 PM의 완전한 자동화 인프라가 완성됩니다.
© 2026 김생근 (Sanguine Kim) | AI Agent Lead & AI Tutor 본 자료는 CC BY-NC 4.0 라이선스를 따릅니다. 교육·학술 목적 자유 이용 가능 | 상업적 이용 시 별도 라이선스 필요 강의·기업 교육·상업적 활용 문의: kimsanguine@gmail.com