---
name: episode-mining
description: 자기소개서 초안 작성 전 단계에서 사용할 에피소드를 체계적으로 발굴하고 정리합니다. 경험 소재를 인수분해하여 직무별로 분류하며, 프로젝트 폴더를 지정하면 파일 기반 자동 추출도 가능합니다.
argument-hint: "[직무명] [프로젝트 폴더 경로(선택)]"
disable-model-invocation: true
---

# 에피소드 발굴 스킬

자기소개서에 활용할 에피소드를 체계적으로 발굴·정리·분류한다.

---

## 참조 문서 사용법

이 파일은 **진입 지침과 전체 워크플로우**만 설명한다.
상세 기준은 아래 문서를 필요할 때만 펼쳐본다.

- 파일 스캔 상세 기준: [references/project-scan-guide.md](references/project-scan-guide.md)
- 창의/혁신/개선 문항 보강: [references/creative-problem-solving.md](references/creative-problem-solving.md)
- 사례 구조 참고: [references/episode-examples.md](references/episode-examples.md)
- 에피소드 인벤토리 양식: [assets/episode_inventory.md](assets/episode_inventory.md)
- 마스터 자소서 베이스 양식: [assets/MASTER_cover_letter.md](assets/MASTER_cover_letter.md)

---

## 워크플로우 분기

사용자가 **프로젝트 폴더 경로를 제공**했으면 → **Mode A (파일 스캔)** 진입
폴더 경로 없이 호출 시 → **Mode B (대화 기반)** = 기존 Step 0부터 진행

---

## Mode A: 프로젝트 파일 스캔

사용자가 프로젝트 폴더를 지정하면, 파일에서 자소서 소재를 자동 추출한다.

상세 가이드: [references/project-scan-guide.md](references/project-scan-guide.md)

### A-1. 파일 탐색

폴더 내 주요 파일을 탐색한다:
- README.md / 프로젝트 소개 문서
- 설계 문서, 이슈 분석 문서 (docs/ 폴더)
- 보고서, 발표 자료 (.md, .txt, .pptx)
- 의존성 파일 (package.json, requirements.txt 등)
- 인프라 파일 (Dockerfile, docker-compose, CI/CD 설정, nginx 등)
- 커밋 로그 / PR 내역 (git 저장소인 경우)
- 코드 구조 (폴더/파일명으로 아키텍처 파악)

기본 원칙은 **문서·로그 우선, 코드 보완**이다:
- 1차 스캔: README, 설계 문서, 보고서, git 로그에서 에피소드 후보를 빠르게 찾는다
- 2차 스캔: 후보가 나온 모듈만 코드에서 확인하여 설계 판단, 예외 처리, 성능/운영 포인트를 보완한다
- 코드 정독은 기본값이 아니다. **자소서 가치가 높은 후보 모듈**에만 제한적으로 적용한다

### A-2. 에피소드 단서 추출

파일에서 14항목 인수분해에 해당하는 정보를 자동 매핑한다:

| 자동 추출 가능 | 사용자 확인 필요 |
|---|---|
| 목표(1), 기간(3), 기술스택 | 팀 구성(2), 본인 역할(4) |
| 문제 현상(6), 해결 시도(9) | 근본 원인 탐색 과정(7,8) |
| 시도 성격(10) | 기여도, 감정, 배운 점(13) |
| 정량적 성과 단서(11) | 외부 평가(12), 직무 적용(14) |

### A-2.5. 기술 심화 추출

에피소드 매핑 후, **7대 기술 카테고리**로 추가 추출한다 (IT/이공계 직무 필수):

이 단계의 목적은 코드 리뷰 자체가 아니라, **문서/로그에 드러나지 않은 숨은 강점**을 보완하는 것이다.
예를 들어 설계 판단, 예외 처리, 성능 최적화, 테스트/운영 자동화처럼 자소서에 설명 가능한 포인트를 우선 찾는다.

| 카테고리 | 탐색 대상 |
|---|---|
| **T0 핵심 기능 구현** | 소스 코드, "feat:" 커밋, README 기능 목록 |
| **T1 아키텍처 설계** | 설계 문서, README 구조도, 패키지 구조 |
| **T2 트러블슈팅** | 이슈 분석 문서, "fix:" 커밋 |
| **T3 성능 최적화** | 벤치마크, 성능 관련 문서/커밋 |
| **T4 인프라/DevOps** | Dockerfile, docker-compose, CI/CD 설정 |
| **T5 API/인터페이스** | API 문서, Swagger, 라우팅 코드 |
| **T6 기술 선택 근거** | 기획 문서, 기술 비교 문서, 의존성 파일 |

각 카테고리에서 발견된 단서는 **내용, 근거 파일, 기술적 복잡도, 사용자 확인 필요 항목, 자소서 활용**을 정리한다.

상세 가이드: [references/project-scan-guide.md](references/project-scan-guide.md) 의 "기술 심화 추출 레이어" 섹션

### A-3. 빈칸 + 기술 심화 질문 생성

파일로 파악 불가능한 항목에 대해 **맞춤형 질문**을 생성한다:
- "이 프로젝트에서 본인이 맡은 역할은 무엇이었나요?"
- "README에 'OO 문제를 해결했다'고 되어 있는데, 구체적으로 어떻게 원인을 찾았나요?"
- "이 프로젝트에서 가장 짜증났거나 당황했던 순간이 있었나요?"
- "정량적 성과(처리 속도 개선, 오류율 감소 등)를 수치로 말할 수 있나요?"

기술 심화 질문도 함께 생성한다:
- "[발견한 기능/모듈]을 직접 설계·구현하셨나요?"
- "[발견한 이슈/버그 수정]에서 원인을 본인이 분석하셨나요?"
- "기술 선택 시 어떤 대안을 검토하고 왜 이 기술을 선택했나요?"
- "CI/CD나 인프라 구성에 본인이 관여한 부분이 있나요?"
- "이 개선이 사용자나 운영자에게 왜 중요했나요?"
- "시간, 비용, 레거시 같은 제약 때문에 포기하거나 조정한 부분이 있었나요?"

코드에서만 발견한 포인트는 바로 확정하지 말고, 반드시 아래 둘 중 하나를 확인한다:
- "이 판단이나 구현을 본인이 직접 주도했나요?"
- "면접에서 이 선택 이유를 1분 안에 설명할 수 있나요?"

> 질문은 **감정 기반 접근**으로 구성한다 (Step 0-1 참조)
> "성과가 뭐였나요?" 대신 → "가장 힘들었던 부분이 뭐였어요?"

### A-4. 에피소드 + 기술 디테일 초안 조립

파일 단서 + 사용자 답변을 합쳐 **14항목 인수분해 + 기술 디테일**을 완성한다.

### A-5. 포트폴리오 보강 제안

현재 프로젝트에 **없지만 추가하면 자소서 소재가 되는 것**을 제안한다.
성능 측정, 모니터링, 테스트 코드, 보안, 캐싱, DB 최적화, 배포 자동화 등 10개 영역을 점검하여 보강 방법과 예상 소요 시간을 안내한다.

상세 가이드: [references/project-scan-guide.md](references/project-scan-guide.md) 의 "포트폴리오 보강 가이드" 섹션

이후 Step 3(카테고리 분류)로 넘어간다.

---

## Mode B: 대화 기반 발굴

프로젝트 폴더 없이 호출된 경우, 대화로 에피소드를 발굴한다.

### Step 0: 에피소드 발굴 전략

인수분해(Step 2) 이전에, 먼저 경험을 폭넓게 떠올리는 단계이다.

#### 0-1. "성과"가 아니라 "문제·감정"으로 기억을 소환하기

> "특별한 성과가 있었나요?" 라고 물으면 대부분 "없다"고 답한다.
> "성과"라는 단어가 주는 부담감 때문이다.

아래 질문으로 접근하면 기억이 훨씬 잘 떠오른다:
- "그 일 하면서 제일 **짜증났던 장면**이 뭐였어?"
- "제일 **당황했던 순간**은?"
- "제일 **행복했던/뿌듯했던 순간**은?"
- "자주 반복돼서 **비효율적이라 느꼈던 업무**는?"
- "동료/상사로부터 **칭찬받았던 구체적 상황**은?"

감정에 연결된 기억은 쉽게 잊히지 않으므로, 감정 키워드로 먼저 떠올린 뒤 구체적 상황으로 확장한다.

##### 올바른 대화법 (AI가 질문할 때의 원칙)

에피소드를 끌어내는 질문에는 **올바른 방법과 잘못된 방법**이 있다:

**❌ 잘못된 질문:**
- "특별한 일 없었어?" → "없었어..." (부담감 유발)
- "성공했던 경험이 뭐야?" → "없는 것 같아..." (강박 유발)

**✅ 올바른 질문:**
- "어떤 부분이 힘들었어?" → "왜 힘들었어?" → "그래서 어떻게 했어?"
- WHY → WHAT → HOW **꼬리물기**로 에피소드를 구체화한다
- 상대방의 답변에서 **키워드를 잡아서** 다음 질문으로 연결한다

> **에피소드 정리표의 함정**: 빈칸을 채워야 한다는 강박이 오히려 사고를 제한한다.
> 먼저 **자유롭게 경험을 열거**한 뒤, 이후에 인수분해 틀에 담는 순서가 효과적이다.

#### 0-2. 시간대별 업무 열거법

출근부터 퇴근까지 했던 일을 시간순으로 나열하면 놓쳤던 에피소드가 보인다:
- 고객 응대, 물건 진열, 위생 관리, 일일 매출 정산, 시재 오차 확인 등
- 편의점을 떠올리면 "고객 응대"만 생각하지만, 실제로는 결품 관리, 발주, 매대 배치, 시간대별 상품 교체 등 훨씬 다양한 일을 했다

#### 0-3. 이해관계자 다양화

같은 경험도 **조연(이해관계자)을 바꾸면** 완전히 다른 에피소드가 된다:
- 고객 → 동료 → 상사 → 협력사/외부 파트너 → 후임/후배
- 예: 학원 보조 업무 → 학부모 응대 에피소드 vs 강사진 협업 에피소드 vs 학생 관리 에피소드

#### 0-4. 에피소드 정황 비틀기

진부한 관점을 탈피하는 전략:

| 흔한 관점 | 비틀기 |
|---|---|
| 팀원 간 갈등 발생 | 오히려 사이가 좋아서 비판 없이 넘어가던 문제 |
| 외부 변수로 어려움 | 내부 프로세스의 비효율이 원인 |
| 처음부터 성공 | 실패 → 원인 분석 → 재도전으로 성공 |
| 매출 하락 매장의 문제 해결 | 매출 급등한 매장의 원인을 분석하여 타 매장에 적용 |
| 전원 반대를 설득 | 전원 찬성인데 토론 없는 분위기를 바꿈 |
| 신규 오픈 매장 활성화 | 폐업 직전까지 끝까지 책임진 경험 |
| 문제가 발생해서 해결 | **본인이 직접 문제를 제기**하여 개선 |
| 당연한 것을 당연히 수행 | **당연한 관행의 비효율을 발견**하여 개선 |

#### 0-5. 솔직한 성과 대체 표현

매출 확인이 불가한 경우, 아래처럼 대체한다:

| ❌ 가공된 표현 | ✅ 솔직한 대체 표현 |
|---|---|
| "매출 30% 상승" | "하루 평균 해당 상품 구매 고객이 3→7명으로 증가한 것을 확인" |
| "매출 대폭 증가" | "'다음에 꼭 다시 일해달라'는 담당자님 피드백에서 영향을 확인" |
| "10명 모집 성공" | "10명 권유 중 7명 승률, 2시간 뒤 추가 3명 설득" |
| "모두 찬성" | "여전히 반대하는 팀원도 있었지만, ○○하여 찬성으로 전환" |
| "내 아이디어 덕분에 성과" | "팀원들의 ○○ 노력도 보탬이 되었고, 제 아이디어로 ○○한 결과 도출" |
| "저만의 영업 노하우로" | "팀장님 판매 노하우를 벤치마킹했고, 시뮬레이션까지 해주신 격려 덕분에" |

### Step 1: 경험 브레인스토밍

지원자에게 아래 영역에서 경험을 최대한 많이 나열하도록 요청한다:
- 전공 프로젝트 (졸업작품, 캡스톤, 실험 등)
- 인턴/아르바이트/직무 경험
- 대외활동/동아리/봉사활동
- 공모전/경진대회/수상 이력
- 자격증/교육 이수
- 개인 프로젝트/사이드 프로젝트

### Step 2: 14항목 인수분해

각 경험을 아래 14가지 항목으로 분해한다:
1. 프로젝트/활동의 **목표**
2. **팀 인원 수**와 구성
3. **기간** (단기/장기)
4. **본인의 역할/직책** (팀장/팀원/담당자)
5. **선례 유무** (기존 사례가 있는 주제 vs 새로운 시도)
6. **겪은 문제 현상**
7. **근본적 문제점 탐색 과정** (어떤 시도로 원인을 찾았는지)
8. **발견한 근본 원인**
9. **해결을 위한 구체적 시도와 방법**
10. **시도의 성격** (기존 방식 개선 vs 새로운 접근)
11. **정량적 성과** (수치로 표현 가능한 것)
12. **프로젝트 결과에 대한 외부 평가**
13. **배운 점**
14. **지원 직무/사업 부문에의 적용 가능성**

> **이공계 주의사항** (참고: reference 자료):
> - 행동만 나열하지 말 것 → **태도·마인드**를 함께 드러내기
> - 전문 지식만 어필하지 말 것 → **지식+기술+태도**를 한 세트로
> - 업계 트렌드·시장 이해도를 반영하면 차별화 가능

---

## 차별화 전략 (Mode A, B 공통)

에피소드를 발굴한 후, 아래 3단계로 차별화 수준을 점검한다.

### 1단계: 관점 차별화

직무를 **소상하게** 파악한 뒤, 남들이 잘 선택하지 않는 관점인지 확인:
- 편의점 → 고객 응대(진부) vs **결품 관리·발주 최적화**(차별화)
- 음식점 → 매출 향상(진부) vs **마진율 분석·유인 메뉴 전략**(차별화)

**좋은 에피소드의 4가지 공통점:**
1. 직무적 적합성이 뛰어나다
2. 있을 법하지만 남들이 선택하지 않는 관점이다
3. 에피소드가 매우 구체적이다
4. 액션과 문제 해결력이 구체적이다

### 2단계: 창의적 문제해결 관점 추가

"창의/혁신/개선" 문항 대응 시, 에피소드에서 아래 3가지를 점검:
1. **주도적/자발적**으로 문제를 인식했는가?
2. **논리적/분석적**으로 접근했는가?
3. 해결 방법이 **참신**한가? (기존과 다른 방법론)

상세 가이드: [references/creative-problem-solving.md](references/creative-problem-solving.md)

### 3단계: 가치관 에피소드 활용

직무 에피소드가 충분하면, 하나쯤은 **인간미·가치관**을 보여주는 소재 사용 가능.

**직무 무관 에피소드 사용 조건:**
- 다른 항목에서 직무 경험이 충분히 기술되어 있을 것
- 본인만의 고유한 에피소드일 것
- 매우 구체적일 것
- 가치관·역량(주인정신, 팀워크, 끈기 등)이 명확히 드러날 것

참고 예시: [references/episode-examples.md](references/episode-examples.md)

---

### Step 3: 7대 카테고리 분류

인수분해된 경험을 아래 7가지 카테고리로 분류한다.
처음 취준하는 분은 최소 4가지(★), 경험이 많은 분은 7가지 모두 준비:

| # | 카테고리 | 비고 |
|---|---|---|
| 1 | ★ 직무 관련 성과 에피소드 (직무1) | 가장 직접적인 직무 경험 |
| 2 | 직무 관련 성과 에피소드 (직무2) | 다른 각도의 직무 경험 |
| 3 | ★ 조직 내 리더십/팀워크 에피소드 | 협업·소통·갈등 해결 |
| 4 | ★ 가치관/인성 에피소드 | 성장과정·동기 부여 소재 |
| 5 | ★ 실패 극복 에피소드 | 좌절→분석→재도전 |
| 6 | 도전 에피소드 | 새로운 영역에 뛰어든 경험 |
| 7 | 창의적 문제 해결 에피소드 | 기존과 다른 방식으로 해결 |

**공공기관 지원 시:** 직무/직렬 관련 + 조직 기여 에피소드 중심으로 선정
**사기업 지원 시:** 직무 에피소드가 많다면 하나쯤은 인간적 매력을 보여주는 소재로

### Step 4: 우선순위 및 문항 매핑

인수분해된 경험들을 아래 기준으로 분류·우선순위를 매긴다:
- **직무 유관성**: 직접적 vs 간접적 vs 무관
- **성과 유무**: 정량적 성과가 있는가?
- **기여도**: 본인 기여도 30% 이상인가?
- **디테일 자신감**: 면접에서 심화 질문에 답변할 수 있는가?

분류된 에피소드를 문항 유형별로 매핑한 뒤, **정리가 충분한 경우** 아래 문서를 만든다:

1. `episode_inventory.md`
- 우선순위가 가장 높은 권장 산출물이다.
- 발굴한 에피소드 전체 목록, 14항목 인수분해, 기술 디테일, 문항 유형별 매핑을 정리한다.
- 프로젝트/경험 탐색 결과가 어느 정도 정리되었고, 이후 문항별 작성에 재사용할 가치가 크면 생성한다.
- 빠른 탐색 단계이거나 정보가 지나치게 비어 있으면, 바로 파일을 만들기보다 먼저 후보와 빈칸만 정리해도 된다.
- 양식: [assets/episode_inventory.md](assets/episode_inventory.md)

2. `MASTER_cover_letter.md`
- 조건부 산출물이다.
- 회사/공고 비의존형 **베이스 문서**다.
- 완성 제출본이 아니라, 여러 회사 자소서에 재사용할 핵심 강점·대표 에피소드·지원동기/포부 원재료를 모은다.
- 대표 에피소드가 어느 정도 안정됐거나, 문항별 초안 작업이 일부 진행된 뒤에 생성하는 편이 좋다.
- 탐색 초반에는 만들지 않아도 된다. 사용자가 원하거나, 재사용용 베이스 문서가 실제로 필요한 시점에만 생성한다.
- 특정 회사명, 특정 공고 표현, 검증되지 않은 과장은 넣지 않는다.
- 정보가 부족하면 빈칸과 추가 확인 필요 항목을 남긴다.
- 양식: [assets/MASTER_cover_letter.md](assets/MASTER_cover_letter.md)

---

## 추가 리소스
- 에피소드 인벤토리 양식: [assets/episode_inventory.md](assets/episode_inventory.md)
- 마스터 자소서 베이스 양식: [assets/MASTER_cover_letter.md](assets/MASTER_cover_letter.md)
- 프로젝트 파일 스캔 가이드: [references/project-scan-guide.md](references/project-scan-guide.md)
- 창의적 문제해결 가이드: [references/creative-problem-solving.md](references/creative-problem-solving.md)
- 에피소드 사례집: [references/episode-examples.md](references/episode-examples.md)

## 다음 단계 연계

에피소드 정리가 완료되면:
1. **자소서 초안 작성** → `general-cover-letter` 스킬이 `episode_inventory.md`를 우선 참조하고, `MASTER_cover_letter.md`가 있으면 함께 활용하여 문항 분석·STAR 구조·톤 가이드를 적용합니다
2. **자소서 리뷰** → `/review-cover-letter [파일명]`으로 초안의 구체성·반복·표현 품질을 체계적으로 점검합니다
