hiring-prep-doc-feedback

name	hiring-prep-doc-feedback
description	이력서, 자기소개서, 포트폴리오에 대해 리서치 기반의 구조화된 피드백을 제공합니다.
user-invocable	true

취업 서류 피드백 (Hiring Doc Feedback)

채용 관련 문서(이력서, 자기소개서, 포트폴리오)를 리서치 기반 베스트 프랙티스로 검토하고, 항목별 개선 제안을 제공합니다. 특정 인물의 스타일을 모방하지 않으며, 검증된 채용 연구와 실무 기준에 근거합니다.

---

지원 문서 유형

이력서       — 경력 사항, 기술 스택, 학력, 성과 중심 문서
자기소개서   — 지원 동기, 성장 과정, 역량 스토리 중심 문서
포트폴리오   — 프로젝트 결과물, 작업물 모음 중심 문서

---

실행 절차

Step 1: 입력 수집

문서 (필수):

• "피드백받을 문서의 파일 경로를 알려주세요. (PDF, Markdown, TXT)"
• 미제공 시: "문서는 필수입니다. 파일 경로를 알려주세요." 후 대기
• DOCX 제공 시: "DOCX는 직접 읽을 수 없습니다. PDF 또는 TXT로 변환 후 다시 제공해주세요."

채용 공고 (선택, 강력 권장):

• "지원하려는 채용 공고가 있으면 내용을 붙여넣거나 URL을 알려주세요. (없으면 '없음')"
• URL 제공 시: 웹 페이지 읽기로 시도. 실패 시 "내용을 직접 붙여넣어주세요."
• 미제공 시: "공고 없이 일반 기준으로 피드백합니다. 공고가 있으면 직무 정렬 분석이 추가됩니다."

문서 유형 확인:

• 문서를 읽기 전에 유형을 판별하거나, 판별이 어려울 경우 사용자에게 확인: "이 문서는 이력서, 자기소개서, 포트폴리오 중 어느 유형인가요?"

Step 2: 문서 파싱

Read 도구로 문서를 읽는다.

• PDF의 경우 pages 파라미터 활용 (10페이지 초과 시 분할)
• 읽기 실패 시: "파일을 읽을 수 없습니다. PDF 또는 TXT 형식으로 다시 제공해주세요."

파싱 시 파악할 항목 (유형 공통):

• 전체 구조와 섹션 구성
• 분량과 밀도
• 문체와 일관성
• 지원자 경력 수준 추정 (주니어/미드/시니어)

Step 3: 채용 공고 분석 (제공 시)

공고에서 다음을 추출한다:

• 포지션명, 회사명, 경력 요건
• 필수 자격 요건 (Must-have)
• 우대 자격 요건 (Nice-to-have)
• 핵심 키워드 (직무 설명에 반복 등장하는 기술/역량 단어)
• 회사 문화/가치 관련 표현

Step 4: 1차 인상 분석 (첫인상 스캔)

이력서 — 6초 룰 적용

채용 담당자는 이력서를 평균 6초간 훑는다. 첫 스캔에서 눈에 들어오는 것만 평가한다:

• 현재/최근 직함과 회사명이 즉시 파악되는가?
• 핵심 기술 스택이 눈에 띄는가?
• 전체적인 가독성과 레이아웃이 쾌적한가?
• 즉각적인 Red Flag(공백, 오탈자, 형식 혼란)가 있는가?
• 앞부분(상단 1/3)에 가장 임팩트 있는 내용이 배치되어 있는가? (양보다 질)
• 요약/Summary가 있다면 핵심 역량이 3줄 안에 파악되는가?
• 두괄식 서술인가? (결론 → 근거 순서)

자기소개서 — 30초 스캔

• 첫 단락에서 지원자의 핵심 강점이 드러나는가?
• 지원 동기가 진정성 있게 느껴지는가?
• 전체 구성이 한눈에 파악되는가?

포트폴리오 — 첫 인상 스캔

• 대표 프로젝트가 즉시 부각되는가?
• 지원자가 어떤 사람인지 30초 내에 파악 가능한가?
• 전체 수준과 일관성이 느껴지는가?

Step 5: 구조 및 형식 피드백

문서 유형에 맞는 구조 기준으로 평가한다.

이력서 구조 체크리스트

[ ] 섹션 순서: 경력요약 → 경력 → 프로젝트 → 기술 → 학력 (경력자 기준)
[ ] 역순 연대기 (최신 항목 최상단)
[ ] 일관된 날짜 형식 (YYYY.MM 또는 YYYY년 MM월)
[ ] 글머리 기호 사용 (문단 서술 지양)
[ ] 한 페이지 기준: 경력 3년 미만. 2페이지: 경력 5년 이상
[ ] 폰트, 간격, 여백 일관성
[ ] 파일명 형식: 이름_직군_이력서.pdf

자기소개서 구조 체크리스트

[ ] 각 항목의 제목/질문이 명확히 구분되어 있는가?
[ ] 글자 수/분량 준수 여부 (공고 기준 있을 시)
[ ] 단락 전환이 자연스러운가?
[ ] 두괄식 구성 (결론을 먼저, 근거를 후에)
[ ] 중복 내용 없이 각 항목이 서로 다른 강점을 보완하는가?

포트폴리오 구조 체크리스트

[ ] 목차 또는 내비게이션 존재
[ ] 프로젝트별 섹션 구분 명확
[ ] 각 프로젝트에 역할, 기여도, 기간이 명시되어 있는가?
[ ] 링크(GitHub, 배포 URL 등)의 유효성
[ ] 시각 자료(스크린샷, 다이어그램)의 적절한 활용

Step 6: 콘텐츠 품질 피드백

정량적 성과 밀도 분석

리서치에 따르면 수치 기반 성과를 포함한 이력서는 면접 기회가 2.5배 높다. 각 항목을 분류한다:

등급	기준	예시
우수	수치 + 맥락 + 기여	"MAU 10만 서비스 API 응답 시간 40% 단축 (2.1s → 1.2s)"
보통	수치만 있거나 맥락 없음	"응답 시간 40% 단축"
부족	수치 없는 주관적 서술	"성능 개선 작업 수행"

서술 구조 평가 (사고 과정 vs 기능 나열)

채용 담당자 관점에서 가장 중요한 차별화 요소는 "사고 과정"이 드러나는 서술이다. 각 프로젝트/경험 항목을 아래 기준으로 분류한다:

등급	구조	예시
우수	[문제 인식 → 해결 과정(기술 선택 이유) → 정량적 성과]	"사용자 이탈률 원인 분석 → SSG 도입 결정 → FCP 3초에서 1.2초로 개선"
보통	[기술 적용 → 성과] (문제 맥락 부재)	"SSG를 도입하여 FCP를 1.2초로 개선"
부족	[기능 나열] (성과·맥락 없음)	"Next.js SSG 적용"

평가 포인트:

• 왜 이 작업을 했는지(문제/배경)가 서술되어 있는가?
• 기술 선택의 이유나 대안 비교가 드러나는가?
• 결과가 정량적 수치로 증명되는가?
• "함께 일하고 싶은 동료"라는 인상을 주는가? (팀 기여, 동료의 어려움 해결 등)

STAR 기법 활용도 (자기소개서/이력서 경력 서술)

S (Situation) — 배경 상황
T (Task)      — 역할과 목표
A (Action)    — 본인이 취한 구체적 행동
R (Result)    — 결과와 성과

각 서술 항목이 STAR 4요소 중 몇 개를 포함하는지 확인한다.

면접 유도성 평가

이력서/자소서는 면접의 대본이다. 면접관이 "이것 좀 더 자세히 듣고 싶다"고 느낄 만한 항목이 있는지 평가한다:

• 기술 선택의 트레이드오프가 드러나 꼬리질문을 유도하는 항목이 있는가?
• 흥미로운 문제 상황 + 구체적 성과로 호기심을 자극하는 항목이 있는가?
• 학습 흔적(블로그, 오픈소스 기여, 기술 발표 등)이 첨부되어 있는가?
• 스토리와 맥락이 있어 대화의 출발점이 될 수 있는가?

구체성 점검

• 기술 스택: "다양한 기술 사용" → 실제 기술명 명시
• 역할: "기여했다" → 구체적으로 어떤 부분을 담당했는지
• 팀 규모: 기여도 맥락을 위해 팀 구성 간략 언급 권장
• 기간: 프로젝트 소요 기간이 없으면 임팩트 가늠 어려움

Step 7: 직무 정렬 분석 (채용 공고 제공 시)

키워드 매칭

공고의 핵심 키워드와 문서 내 언급을 대조한다:

키워드	공고 중요도	문서 내 언급	비고
[키워드]	필수/우대	O/X/간접 언급	[개선 제안]

요건 커버리지

• 필수 자격 요건 대비 문서에서 증명된 비율
• 우대 자격 요건 대비 문서에서 증명된 비율
• 공고에 강조된 역량인데 문서에서 약하게 다뤄진 부분 식별

어필 포인트 정렬

공고의 요구사항과 지원자의 가장 강한 경험이 매칭되는지 확인한다. 순서/강조 방식 재배치 제안도 포함한다.

Step 8: 항목별/섹션별 상세 피드백

각 섹션 또는 항목에 대해 다음 3요소로 구성된 피드백을 제공한다:

[섹션명 또는 프로젝트명]

잘 된 점
- [구체적 강점, 문서에서 인용 포함]

아쉬운 점
- [구체적 문제점, 이유 포함]

수정 제안
Before: [현재 문장/항목]
After:  [개선된 버전]

Before/After 예시는 반드시 구체적이어야 한다. "더 구체적으로 쓰세요"와 같은 모호한 조언은 피한다.

Before/After 작성 시 반드시 [문제-해결-성과] 구조로 변환하는 예시를 포함한다:

❌ Before: "Redis를 활용한 중복 요청 제거 기능 구현" ✅ After: "동일 클라이언트의 반복 요청으로 데이터 정합성 훼손 발생 → Redis TTL 기반 멱등성 키로 중복 차단 → 정합성 훼손 0건 달성"

❌ Before: "게시판 CRUD 기능 개발" ✅ After: "실시간 알림을 위해 WebSocket 도입, 연결 끊김 문제를 재연결 로직으로 해결하여 알림 수신율 99.5% 달성"

Step 9: ATS 최적화 팁 (이력서 한정)

Applicant Tracking System에 최적화된 이력서를 위한 체크리스트:

[ ] 표, 이미지, 아이콘 사용 최소화 (ATS 파싱 오류 원인)
[ ] 섹션 헤딩은 표준 명칭 사용 (예: "경력 사항", "기술 스택")
[ ] 키워드는 원문 그대로 사용 (약어 + 풀네임 병기: "ML (Machine Learning)")
[ ] 컬럼 레이아웃 지양 (2단 이력서는 ATS에서 순서가 뒤섞일 수 있음)
[ ] 특수문자 남발 금지 (별표, 화살표 등은 ATS 파싱에 악영향)

Step 10: 결과 출력

아래 템플릿에 따라 피드백 보고서를 출력한다.

---

출력 형식 템플릿

# 취업 서류 피드백 보고서

문서 유형: [이력서 / 자기소개서 / 포트폴리오]
경력 수준 추정: [주니어 / 미드 / 시니어]
피드백 기준: [공고 기반 맞춤형 / 일반 기준]

---

## 첫인상 스캔 (6초 룰)

[전체적인 첫인상 요약 — 강점과 즉각적으로 눈에 띄는 문제점]

---

## 구조 및 형식

### 잘 된 점
- [항목]

### 개선이 필요한 부분
- [항목]: [구체적 이유와 해결 방법]

---

## 콘텐츠 품질

### 정량적 성과 밀도
- 성과 포함 항목: [X] / [전체] ([비율]%)
- 평가: [우수 / 개선 필요]
- 수치화 미흡 항목: [목록]

### STAR 기법 활용도
- 완전한 STAR 항목: [X] / [전체]
- 누락된 요소가 많은 항목: [목록 + 누락 요소]

### 서술 구조 (사고 과정)
| 항목 | 구조 등급 | 분석 |
|------|---------|------|
| [프로젝트/경험] | 우수/보통/부족 | [상세 분석] |

**[문제-해결-성과] 구조 충족률: [X]/[전체] ([비율]%)**

### 면접 유도성
- 면접관 호기심 유발 항목: [목록 또는 "없음 — 개선 필요"]
- 트레이드오프 서술: [있음/없음]
- 학습 흔적: [있음(구체적 목록)/없음]

---

## 섹션별 / 항목별 상세 피드백

### [섹션명 1]

**잘 된 점**
- [강점]: "[문서 인용]"

**아쉬운 점**
- [문제점]: [이유]

**수정 제안**
> Before: [현재 내용]
> After:  [개선 내용]

---

### [섹션명 2]

[반복...]

---

## 직무 정렬 분석 (공고 제공 시)

### 키워드 매칭 현황
| 키워드 | 중요도 | 문서 내 언급 |
|--------|--------|-------------|
| [키워드] | 필수 | O / X |

### 요건 커버리지
- 필수 요건 충족: [X] / [전체]
- 우대 요건 충족: [X] / [전체]

### 어필 포인트 재배치 제안
[공고 핵심 역량과 지원자 강점을 더 잘 연결하기 위한 순서/강조 조정 제안]

---

## ATS 최적화 팁 (이력서 한정)

- [구체적 항목]: [현재 문제점] → [개선 방법]

---

## 종합 요약 및 우선순위 액션 아이템

### 핵심 강점
1. [강점]
2. [강점]

### 우선순위 개선 과제

| 우선순위 | 항목 | 예상 임팩트 |
|---------|------|-----------|
| 1순위 | [항목] | [높음 / 중간 / 낮음] |
| 2순위 | [항목] | [높음 / 중간 / 낮음] |
| 3순위 | [항목] | [높음 / 중간 / 낮음] |

> **한 줄 요약:** [지원자의 가장 강한 부분과 가장 시급한 개선점을 한 문장으로]

---

주의사항

• 피드백은 구체적이어야 한다. "더 잘 써야 합니다" 같은 모호한 조언은 하지 않는다
• Before/After 예시를 반드시 포함한다. 수정 방향만 설명하고 예시가 없으면 피드백 가치가 반감된다
• 개인 정보(전화번호, 주소 등)는 평가하지 않는다
• 학력 자체를 평가하지 않는다. JD에 학력 요건이 있을 때만 충족 여부를 언급한다
• 확인할 수 없는 내용은 추측하지 않는다. "확인 불가" 또는 "추가 맥락이 필요합니다"로 표기한다
• 이모지는 사용자가 명시적으로 요청하지 않는 한 사용하지 않는다
• 어투는 전문적인 한국어(해요체 또는 합니다체)를 유지한다
• 채용 공고 없이 피드백 시: ATS 최적화 팁과 직무 정렬 분석 섹션은 생략하고 범용 기준으로 진행한다
• 단순 교정(맞춤법/오탈자)은 목록으로 별도 정리하되 주요 피드백과 혼용하지 않는다
• "기능 나열"과 "사고 과정 서술"의 차이를 명확히 구분하여 피드백한다
• Before/After 수정 제안 시 반드시 [문제-해결-성과] 구조로의 변환을 포함한다
• 이력서/자소서가 "면접에서 물어보고 싶게 만드는가"를 핵심 기준으로 평가한다