resume-review

name	resume-review
description	Use when 이력서 PDF를 받아 A-Z 분석이 필요할 때. 멘토 전용 분석 리포트 + 멘토링 코칭 전략을 생성. "이력서 리뷰", "이력서 분석", "이력서 피드백", "이력서 봐줘", "이력서 첨삭", "resume review" 트리거.

/resume-review — A-Z 이력서 분석 스킬

Overview

이력서/경력기술서를 PARIS 프레임워크 기반으로 체계적으로 분석하여, 멘토 전용 분석 리포트 + 멘토링 코칭 전략을 생성한다.

핵심 원칙: 출력물은 멘토가 읽고 멘토링에 활용하는 용도. 직접적이고 판단 중심의 톤. 부드러운 포장 불필요.

When to Use

• 멘티가 이력서 PDF를 공유했을 때
• 이력서 첨삭 멘토링 전 사전 분석이 필요할 때
• "이력서 리뷰해줘", "이력서 분석해줘", "이력서 봐줘"

When NOT to use:

• 이력서가 아닌 일반 문서 리뷰
• 멘티에게 직접 보여줄 피드백 레터 작성 (톤이 다름)

Input

• PDF 파일 경로 (필수)
• 지원 포지션 정보 (선택 — 없으면 이력서 내용에서 추론)

Architecture

PDF 읽기
    ↓
[Phase 1] META        — 기본 정보 + 경력 수준 판정
    ↓
[Phase 2] 30초 테스트   — 채용담당자의 첫인상 시뮬레이션
    ↓
[Phase 3] PARIS 진단   — 섹션별 심층 분석 + Before/After
    ↓
[Phase 4] CROSS-CUT   — 횡단 관점 점검 (일관성, 포커스, 레드플래그)
    ↓
[Phase 5] 종합 리포트   — 스코어카드 + 멘토링 코칭 전략

---

Phase 1: META — 기본 정보 파악

PDF를 읽고 다음을 출력한다:

### META 정보
- **이름**:
- **지원 포지션** (명시 또는 추정):
- **경력 수준**: 신입 / 주니어(1~3년) / 미드(3~5년) / 시니어(5년+)
- **문서 구성**: 이력서만 / 이력서+경력기술서
- **총 페이지 수**:

문서 구성 자동 분기

문서 구성	분석 전략
이력서만	이력서 내에서 PARIS 전체를 진단
이력서+경력기술서	이력서 = 요약/첫인상 관점, 경력기술서 = 깊이/디테일 관점. 두 문서 간 일관성 체크 추가

경력 수준별 해석 눈높이

분석 프레임워크는 경력 수준에 관계없이 동일하게 적용한다. PARIS 항목이 X로 나오는 것 자체가 "현재 위치"를 보여주는 유용한 정보다.

단, 해석과 멘토링 코칭의 눈높이는 조절한다:

경력 수준	기대하는 것	관대하게 볼 것	X가 나왔을 때 해석
신입/부트캠프	태도, 성장 가능성, 학습 과정	기술적 깊이, 정량적 성과	"아직 작성법을 모르는 것. 코칭으로 채울 수 있음"
주니어(1~3)	주도적 문제 해결 1~2건, 명확한 포지셔닝	아키텍처 판단, 조직 영향력	"경험은 있는데 표현이 부족. 끌어내기 코칭"
미드(3~5)	기술적 깊이 + 설계 판단력, 정량적 성과	리더십, 조직 전략	"이 레벨에서 이게 빠지면 경쟁력 약화"
시니어(5+)	아키텍처 의사결정, 조직 임팩트, 기술 리더십	—	"시니어라면 반드시 있어야 할 항목"

---

Phase 2: 30초 테스트 — 채용담당자의 첫인상

이력서 첫 페이지만 보고 다음에 답한다:

### 30초 테스트

| 항목 | 판정 | 상세 |
|------|------|------|
| **정체성** | O/X | "이 사람은 _____ 개발자다" — 빈칸이 채워지는가? |
| **포커스** | O/X | 지원 포지션과 이력서 내용이 일치하는가? |
| **후킹** | O/X | 30초 안에 "면접 보고 싶다"는 생각이 드는가? |
| **가독성** | O/X | 정보가 시각적으로 잘 정리되어 있는가? |

- **한 줄 인상**: 채용담당자가 이 이력서를 한 마디로 어떻게 기억할지
- **판정**: PASS / WEAK / FAIL

---

Phase 3: PARIS 진단 — 섹션별 심층 분석

3-1. 자기소개 / Summary

기술적 역량은 프로젝트 섹션의 몫이다. 자기소개는 **"나는 어떤 사람인가"**를 보여주는 공간.

#### 자기소개 진단

| 항목 | 판정 | 상세 |
|------|------|------|
| 나의 강점이 드러나는가 | O/X | |
| 일하는 방식이 드러나는가 | O/X | |
| 가치관/태도가 드러나는가 | O/X | |
| 다른 사람 이름으로 바꿔도 성립하는가 | Yes=문제 | |
| 지원 포지션과 불일치하는 내용 | 있음/없음 | |

**진단**: [구체적 피드백]

**Before** (현재):
> [현재 자기소개에서 문제되는 부분 인용]

**After** (제안):
> [개선된 버전 예시]

**개선 근거**: [왜 이렇게 바꿔야 하는지]

3-2. 프로젝트 (각 프로젝트별 반복)

#### 프로젝트: [프로젝트명] ([기간])

**포지션 관련도**: 상/중/하 — [근거]

| PARIS | 판정 | 근거 (이력서 원문 인용 필수) |
|-------|------|---------------------------|
| **P** (Problem) | O/△/X | "[이력서 원문 인용]" → 이에 근거하여 O/△/X 판정. |
| **A** (Action) | O/△/X | "[이력서 원문 인용]" → 이에 근거하여 O/△/X 판정. |
| **R** (Result) | O/△/X | "[이력서 원문 인용]" → 이에 근거하여 O/△/X 판정. |
| **I** (Impact) | O/△/X | "[이력서 원문 인용]" → 이에 근거하여 O/△/X 판정. |
| **S** (Self-reflection) | O/△/X | "[이력서 원문 인용]" 또는 "해당 내용 없음" → 이에 근거하여 판정. |

**판정 근거 규칙**: 각 PARIS 항목의 근거에 반드시 이력서 원문을 인용하거나, "해당 내용 없음"을 명시한다. 판정만 있고 근거가 없으면 안 된다.

**진단**: [구체적 피드백]

**Before** (현재):
> [현재 프로젝트 설명에서 가장 개선이 필요한 부분 인용]

**After** (제안):
> [PARIS 구조로 재작성한 버전]

**개선 근거**: [왜 이렇게 바꿔야 하는지]

프로젝트 관련도가 "하"인 경우: "이 프로젝트를 축소하거나 제거하는 것을 권장"을 명시한다. 단, 삭제가 아닌 대체 프레이밍(다른 관점으로 재서술)이 가능한지도 검토한다.

3-3. 스킬 섹션

#### 스킬 진단

| 항목 | 판정 | 상세 |
|------|------|------|
| 지원 포지션 핵심 기술이 가장 먼저 오는가 | O/X | |
| 포지션과 무관한 기술의 비중 | __% | |
| 5초 안에 "이 사람은 ____ 개발자" 판단 가능한가 | O/X | |
| 기술명 나열인가, 맥락이 있는가 | 나열/맥락 | |

**진단**: [구체적 피드백]

**Before/After**: [필요시 재구성 예시]

3-4. 경력 / 교육 / 활동 / 자격증

#### 기타 섹션 진단
- 학력/교육 섹션 중복 여부:
- 자격증 날짜 오류 (미래 날짜에 "취득 예정" 미표기 등):
- 활동/수상의 포지션 관련성:
- 불필요하게 공간을 차지하는 섹션:

**진단**: [구체적 피드백]

3-5. 경력기술서 (있는 경우에만)

경력기술서가 포함된 경우, 추가로 다음을 진단한다:

#### 경력기술서 진단

**이력서와의 일관성**:
- 이력서 bullet과 경력기술서 내용이 대응되는가:
- 이력서에서 언급했으나 경력기술서에 없는 항목:
- 경력기술서에만 있고 이력서에 반영 안 된 좋은 내용:

**프로젝트별 PARIS 심화 분석**: (각 프로젝트에 대해 3-2와 동일 구조 적용)

**이슈 해결 사례 평가** (있는 경우):

| 이슈 | 문제→원인→해결→결과 구조 | 깊이 | 면접 질문 유발력 |
|------|-------------------|------|-----------|
| [이슈명] | 완전/부분/없음 | 상/중/하 | 상/중/하 |

**분량 적정성**:
| 경력 수준 | 이력서 권장 | 경력기술서 권장 | 현재 |
|---------|---------|-----------|------|
| (해당 수준) | _p | _p | _p |

---

Phase 4: CROSS-CUT — 횡단 관점 점검

### 4-1. 일관성 (Consistency)
- 자기소개 정체성 ↔ 프로젝트 내용 일치 여부:
- 스킬 섹션 기술 ↔ 프로젝트 실제 사용 여부:
- 시간순 논리성:

### 4-2. 포커스 (Focus)
- 지원 포지션과 무관한 내용 비중: __%
- "방향을 못 정했구나" 인상 여부:
- 과감히 빼야 할 섹션/프로젝트:

### 4-3. 스토리텔링 (Storytelling)
- 이력서 전체에서 하나의 서사가 느껴지는가:
- "이 사람은 ___ 문제를 풀어온 사람이다" 요약 가능 여부:
- 성장의 궤적 (시간에 따라 역할/기술/임팩트가 커지는가):

### 4-4. 레드 플래그 (Red Flags)
- [ ] 설명 없는 공백 기간
- [ ] 기술 스택-포지션 심각한 불일치
- [ ] "팀장" 표기만 있고 구체적 리더십 사례 없음
- [ ] 검증 불가한 과장 수치
- [ ] 오탈자, 날짜 오류, 깨진 링크
- [ ] 민감 정보 노출

---

Phase 5: 종합 리포트

5-1. 스코어카드

| 항목 | 점수 (1~5) | 경력 수준 기준 | 코멘트 |
|------|----------|-------------|--------|
| 포지셔닝 명확성 | | [이 경력 수준에서 기대하는 바] | |
| 자기소개 매력도 | | [이 경력 수준에서 기대하는 바] | |
| 프로젝트 PARIS 완성도 | | [이 경력 수준에서 기대하는 바] | |
| 기술적 깊이 | | [이 경력 수준에서 기대하는 바] | |
| Impact 전달력 | | [이 경력 수준에서 기대하는 바] | |
| 성장 가능성 전달 | | [이 경력 수준에서 기대하는 바] | |
| 가독성/구조 | | [이 경력 수준에서 기대하는 바] | |
| 포커스/일관성 | | [이 경력 수준에서 기대하는 바] | |
| **종합** | **/5** | | |

**"경력 수준 기준" 컬럼 작성 규칙**: Phase 1에서 판정한 경력 수준의 눈높이를 반영한다. 예: 신입이면 "기술적 깊이: 신입은 깊이보다 학습 과정이 드러나면 충분" / 미드이면 "기술적 깊이: 설계 판단과 트레이드오프 설명이 있어야 함". 이 컬럼이 있어야 점수의 근거가 투명해진다.

점수 기준:

• 5: 면접에서 꼭 만나보고 싶음
• 4: 괜찮은 인상, 면접 가능
• 3: 보통, 경쟁에서 밀릴 수 있음
• 2: 아쉬움이 많음, 대폭 수정 필요
• 1: 근본적 재작성 필요

5-2. Top 3 강점

이 이력서에서 가장 매력적인 포인트:
1. **[강점]**: [근거]
2. **[강점]**: [근거]
3. **[강점]**: [근거]

5-3. 우선순위별 개선사항

반드시 긴급도 순서로 정렬:

#### 🔴 즉시 수정 (이것만 고쳐도 확 달라짐)
1. [피드백] — 가이드 섹션 [X-X] 참고
   **Before**: [현재]
   **After**: [제안]

2. [피드백]
   **Before**: [현재]
   **After**: [제안]

#### 🟡 권장 수정 (여유 있으면 반드시)
1. [피드백] — 가이드 섹션 [X-X] 참고
2. [피드백]

#### 🟢 선택 수정 (있으면 좋지만 필수 아님)
1. [피드백]

🔴 즉시 수정 항목에는 반드시 Before/After 예시를 포함한다.

5-4. 멘토링 코칭 전략

#### 멘토링 코칭 전략

**근본 원인 (한 문장)**:
> "[이 이력서의 근본적 문제를 한 문장으로 요약. 예: '백엔드 포지션인데 백엔드 프로젝트가 0개이고, 모든 경험을 나열하여 정체성이 사라진 것이 핵심 문제']"

**이 멘티의 현재 위치**:
- PARIS 중 가장 약한 항목:
- 가장 먼저 채워야 할 것:

**1회차 멘토링 권장 흐름**:
1. [바텀업 시작] 가장 큰 문제점 _개를 짚는다:
   - [문제 1] → 가이드 섹션 [X-X]로 유도
   - [문제 2] → 가이드 섹션 [X-X]로 유도
2. [탑다운 착지] 근본 원인을 연결:
   - "[한 문장 요약]"
3. [과제 설정] 2회차까지 수정해올 것:
   - [ ] [과제 1]
   - [ ] [과제 2]
   - [ ] [과제 3]

**멘티에게 던질 핵심 질문**:
- "[질문 1]" — 이 질문의 의도: [자각 유도 포인트]
- "[질문 2]" — 이 질문의 의도: [자각 유도 포인트]

---

기준 문서 연결

분석 시 docs/이력서_멘토링_가이드.md를 참조하여 다음과 연결한다:

가이드 섹션	분석에서의 활용
1-1. 함께 일하고 싶은 동료	4가지 자질(Logic/Skill/Teamwork/Attitude) 중 어떤 것이 드러나는지
1-2. AI 시대 본질적인 것	"기술을 왜 선택했는지"가 드러나는지
1-3. 태도와 마인드셋	성장 흔적, 회고가 있는지
2-1. 창고 vs 요리	나열형인지 스토리형인지
2-2. 채용담당자의 시선	두괄식, 포커스, 가독성
3-1. PARIS	프로젝트별 5단계 진단 기준
3-2. 자기소개 작성법	강점/일하는 방식/가치관 중심 진단
3-3. 프로젝트 작성법	포지션 관련도, 체크포인트
3-4. 스킬 섹션 작성법	포커스, 깊이 vs 산만함

---

Hard Rules

1. 동일 프레임워크: 경력 수준에 관계없이 Phase 1~5 전체를 동일하게 적용한다. 해석의 눈높이만 조절.
2. 멘토 톤: 직접적, 판단 중심. "아쉽습니다" 대신 "X가 없다. 이유는 ~. 이렇게 고쳐야 한다."
3. Before/After 완전 포함: 🔴 즉시 수정 항목 모두에 Before/After 예시를 포함한다. 하나라도 빠지면 안 된다. 각 PARIS 진단에도 Before/After를 포함한다. Before는 이력서 원문을 정확히 인용하고, After는 멘티가 바로 참고할 수 있는 구체적 수준으로 작성한다.
4. 강점 먼저: 매 섹션에서 잘한 점을 먼저 언급하고, 그 다음 개선점을 말한다.
5. 가이드 연결: 개선사항에는 docs/이력서_멘토링_가이드.md의 관련 섹션 번호를 참조한다.
6. 재료 존중: 멘티의 경험 자체를 부정하지 않는다. "재료가 나쁜 게 아니라 요리법을 바꾸면 된다."
7. 구체적 피드백: "좋습니다", "아쉽습니다"로 끝내지 않는다. 반드시 "왜"와 "어떻게"를 포함.

Usage

/resume-review /path/to/resume.pdf
/resume-review /path/to/resume.pdf --position "Node.js 백엔드 개발자"