--- name: resume description: PDF 이력서를 읽고 경력기술서 생성, 채용 트렌드 기반 평가, 프로젝트 코드 기반 보강, 자동 개선 루프까지 수행한다. allowed-tools: Read, Bash, AskUserQuestion, WebSearch, WebFetch, Glob, Grep, Agent, Edit, Write argument-hint: " | review | improve | enrich [target-score] | match

" --- # Resume — 경력 기술서 생성 / 평가 / 개선 / 코드 기반 보강 ## 명령어 | 명령 | 설명 | |------|------| | `/resume ` | PDF → 경력 기술서 Markdown 생성 | | `/resume review ` | 6축 평가 + 구체적 피드백 | | `/resume improve ` | 평가 기반 개선된 경력 기술서 생성 | | `/resume enrich [target-score]` | 프로젝트 경로를 하나씩 받아 코드 분석 -> 보강 -> 평가 -> 자동 개선 (반복). target-score 미지정 시 22점(A등급) 기본값 | | `/resume match

` | 채용 공고(JD) 대비 이력서 매칭 분석 — 키워드 커버리지·강조 포인트·갭 도출 | | `/resume` | 사용법 안내 | ## 인수 없이 호출 `$ARGUMENTS`가 비어 있으면 사용법 출력: ``` 경력 기술서 도구 ────────────────── /resume PDF -> 경력 기술서 생성 /resume review 채용 트렌드 기반 평가 /resume improve 평가 반영 개선본 생성 /resume enrich [target-score] 프로젝트 경로를 받아 코드 분석 -> 보강 (반복, 기본 목표 22점) /resume match

채용 공고(JD) 대비 이력서 매칭 분석 예시: /resume ~/Downloads/이력서.pdf /resume review ~/Downloads/이력서.pdf /resume improve ~/Downloads/이력서.pdf /resume enrich 25 /resume match ~/Downloads/이력서.pdf https://www.wanted.co.kr/wd/230021 ``` ## 명령 파싱 `$ARGUMENTS`에서 첫 단어를 확인한다: - `review` -> review 모드. 나머지를 PDF 경로로 사용 - `improve` -> improve 모드. 나머지를 PDF 경로로 사용 - `enrich` -> enrich 모드. 두 번째 단어가 숫자면 target-score로 사용 (예: `enrich 25`), 아니면 22점(A등급, 기본값) 사용. 프로젝트 경로는 대화 중 AskUserQuestion으로 받음 - `match` -> match 모드. 두 번째 단어를 PDF 경로, 나머지를 JD 입력(URL 또는 텍스트)으로 사용. JD가 비어 있으면 AskUserQuestion으로 다시 받음 - 그 외 -> generate 모드. 전체를 PDF 경로로 사용 PDF 경로에 "찾아봐", "찾아줘" 등이 포함되면 해당 키워드로 `~/Downloads/`에서 파일을 검색한다. ## 공통: PDF 읽기 `Read` 도구로 PDF를 읽는다. - 파일이 없으면 `~/Downloads/`에서 키워드로 검색 시도 - PDF가 아닌 바이너리(.make, .docx 등)면 "PDF로 내보내기 후 다시 시도" 안내 --- # 모드 1: generate (기본) PDF 내용을 분석하여 경력 기술서를 Markdown으로 작성하고 `~/IdeaProjects/경력기술서.md`에 저장한다. 같은 경로에 기존 파일이 있으면 timestamp 백업 후 새로 작성한다 (상세는 "출력 경로 규칙" 섹션 참고). ## 출력 구조 ```markdown # 경력 기술서 ## 인적 사항 | 항목 | 내용 | |------|------| | 이름 | {이름} | | 연락처 | {연락처} | | 이메일 | {이메일} | ## 경력 요약 총 경력 N년 M개월. {팩트 기반 2-3문장. 숫자와 결과물로 구성한다 — "열정/적극/도전" 같은 추상어 대신 정량적 사실을 쓴다.} ## 경력 사항 ### 1. {회사명} | {직책} (YYYY.MM ~ YYYY.MM, N년 M개월) **주요 업무** - {업무}: {구체적 내용과 성과} **핵심 성과** - {정량적 성과 — 수치 필수} ## 프로젝트 상세 ### {프로젝트명} | 항목 | 내용 | |------|------| | 기간 | YYYY.MM ~ YYYY.MM | | 소속 | {회사명} | | 역할 | {역할} | | 기술 스택 | {기술 나열} | **개요**: {1-2문장} **담당 업무**: {기술적 기여} **성과**: {정량적 성과} ## 기술 스택 | 분류 | 기술 | |------|------| | Language | ... | | Framework | ... | ## 자격/교육/학력 ``` ## 작성 원칙 1. **성과 중심**: "~를 담당했다" 대신 "~를 구현하여 {수치} 개선했다" 2. **액션 동사**: 설계, 구축, 개발, 최적화, 도입, 리드 등으로 시작 3. **수치화**: 원본에 수치가 있으면 반드시 포함한다. 원본에 없는 수치는 만들지 않는다 — 필요하면 `[TODO N]` 빈칸으로 남긴다 4. **최신순 정렬**: 가장 최근 경력/프로젝트가 먼저 5. **일관된 톤**: 경어 없이 간결체 ("~했다" / "~함") 6. **원본 충실**: PDF에 있는 정보만 사용한다. 추론이 필요한 경우 `[추정: 근거]` 태그로 출처를 명시한다 — 이력서 신뢰도는 한 번 무너지면 회복이 어렵다 7. **기술 키워드**: 정확한 명칭 사용 (React, Spring Boot 등) 8. **개인정보 제외**: 주민번호·상세 주소·가족 정보는 출력하지 않는다 — 이력서가 외부에 유출될 때 신원 도용 위험이 있다 --- # 모드 2: review PDF를 읽고 **6축 평가 프레임워크**로 채점 + 구체적 피드백을 제공한다. 타겟 직무·도메인이 있으면 채용 시장 트렌드를 검색해 평가 가중치를 조정한다. ## 0단계: 타겟 직무 컨텍스트 수집 (선택) 이력서 평가는 어떤 직무를 노리는지에 따라 가중치가 달라진다. 예를 들어 AI 백엔드 직무는 "의사결정 근거"·"문제 해결 스토리" 축이 더 중요하고, 신규 시장 진입 직무는 "커리어 내러티브"가 더 중요하다. **진행:** 1. AskUserQuestion으로 타겟 정보를 받는다 (사용자가 "건너뛰기"를 선택하면 일반 평가만 수행): - 직무 (예: AI 백엔드, Python 백엔드, 데이터 엔지니어) - 도메인 (예: 헬스케어, 핀테크, 커머스, 도메인 무관) - 경력 레벨 (예: 주니어 ~3년, 미들 3~7년, 시니어 7년+) 2. WebSearch로 트렌드 조회 (병렬 2~3개 쿼리): - "{직무} {경력레벨} 채용 {올해} 핵심 스택" - "{도메인} {직무} 채용 공고" (도메인 지정 시) - "{직무} 자주 묻는 질문 인터뷰" (선택) 3. 검색 결과에서 추출: - **공통 요구 키워드** (예: LangChain, Vector DB, MSA, K8s) - **자주 묻는 경험 유형** (대용량 트래픽, RAG 파이프라인, 장애 대응 등) - **차별화 포인트** (오픈소스 기여, 사내 발표, 멘토링 등) 4. 추출한 컨텍스트를 다음 단계 6축 평가에 가중치로 반영한다: | 추출 항목 | 영향 받는 축 | 반영 방식 | |----------|-------------|---------| | 공통 요구 키워드 | 축 1·2 (임팩트·의사결정) | 키워드 보유 시 +0.5점, 미보유 시 피드백에 "이 키워드 보강 권장" 명시 | | 자주 묻는 경험 유형 | 축 4 (문제 해결) | 매칭되는 경험이 이력서에 있으면 +0.5점, 없으면 "이 경험 유형이 자주 묻힘" 안내 | | 차별화 포인트 | 축 5 (영향 범위) | 보유 시 +0.5점 | 가중치 적용 후 각 축은 5점을 초과할 수 있으므로, 최종 점수는 5점으로 캡한다 (총점은 30점 유지). **출력 포맷에 컨텍스트 표기:** review 출력 상단에 타겟 컨텍스트 박스를 추가한다: ``` 타겟 컨텍스트 ──────────────────────────────────────── 직무: AI 백엔드 (미들, 3~7년) 도메인: 헬스케어 (선택), AI/LLM 스타트업 (선택) 검색된 핵심 키워드: LangChain, RAG, FastAPI, Vector DB, K8s 자주 묻는 경험: 대용량 데이터 처리, MLOps 파이프라인 ──────────────────────────────────────── ``` 이 단계를 건너뛰면 컨텍스트 박스 없이 일반 6축 평가만 출력한다. ## 6축 평가 프레임워크 각 축을 5점 만점으로 채점한다. 총점 30점. ### 축 1: 정량적 임팩트 (Measurable Impact) "이 사람이 들어오면 어떤 수치적 변화가 있을까"를 판단하는 근거. **채점 기준:** - 5점: 모든 프로젝트에 구체적 수치 (응답시간 3초→0.4초, 비용 40% 절감 등) - 4점: 대부분 프로젝트에 수치 있음. 일부 정성적 표현 - 3점: 절반 정도 수치 있음 - 2점: 수치 거의 없음. "대폭", "향상" 같은 모호한 표현 위주 - 1점: 수치 전무. 전부 "~를 담당했다" 식 **확인 항목:** - [ ] 성능 개선 수치 (응답시간, 처리량, TPS 등) - [ ] 비용 절감 수치 (서버 비용, 인건비, 시간 절약) - [ ] 규모 수치 (데이터 건수, 사용자 수, 트래픽) - [ ] 품질 수치 (에러율, 가용성, 테스트 커버리지) **피드백 생성 규칙:** - 수치 없는 모든 "대폭/향상/개선/최적화" 표현을 찾아서 나열 - 각각에 대해 "이것을 숫자로 바꾸면 이런 형태" 예시를 제시 예) "쿼리 응답속도 대폭 개선" → "쿼리 응답속도 N초 → N초로 X% 개선" ### 축 2: 의사결정 근거 (Technical Decision Making) 시니어와 주니어를 가르는 핵심. "왜 이 기술/패턴/아키텍처를 선택했는지" 설명 능력. **채점 기준:** - 5점: 주요 기술 선택마다 대안 비교 + 선택 근거 명시 - 4점: 핵심 기술 선택에 근거 있음 - 3점: 일부 기술에만 선택 이유 언급 - 2점: 기술 나열만 있고 선택 근거 없음 - 1점: 기술명만 태그처럼 붙어있음 **확인 항목:** - [ ] 기술 선택 시 비교한 대안이 언급되는가 (A 대신 B를 선택한 이유) - [ ] 아키텍처 결정의 트레이드오프가 설명되는가 - [ ] 패턴 적용 이유가 문제 상황과 연결되는가 - [ ] 인프라/DB 선택 근거가 요구사항과 연결되는가 **피드백 생성 규칙:** - 기술 스택이 나열만 된 곳을 찾아 나열 - 각각에 "왜 이 기술?" 질문 + 예시 답변 형태 제시 예) "PostgreSQL + BigQuery 분리" → "왜 단일 DB가 아닌 분리? 예: 실시간 조회(P95 < 200ms)는 PostgreSQL, 수억 row 집계는 BigQuery — 분석 쿼리 비용 70% 절감" ### 축 3: 규모 컨텍스트 (Scale Context) 같은 기술도 규모에 따라 난이도가 다름. 읽는 사람이 난이도를 가늠할 수 있는지. **채점 기준:** - 5점: 모든 프로젝트에 규모 명시 (사용자, QPS, 데이터량, 팀 크기) - 4점: 대부분 프로젝트에 규모감 있음 - 3점: 일부만 규모 언급 - 2점: 규모 정보 거의 없음 - 1점: 규모 전혀 없음. 개인 프로젝트와 구분 불가 **확인 항목:** - [ ] 동시 사용자 수 또는 DAU - [ ] 초당 요청량 (QPS/RPS/TPS) - [ ] 총 데이터량 또는 일일 처리량 - [ ] 팀 규모 및 본인의 역할 범위 - [ ] 서비스 가용성 요구사항 (SLA) **피드백 생성 규칙:** - 규모 정보 없는 프로젝트를 나열 - "이 프로젝트의 규모감을 추가하면" 예시 제시 예) "지표 모니터링 서비스" → "일 N명 사용, 동시 쿼리 N건, 월 N건 리포트 생성" ### 축 4: 문제 해결 스토리 (Problem → Diagnosis → Solution) 프로덕션 운영 경험의 증거. 모든 시스템은 문제가 생기는데 그 이야기가 있는지. **채점 기준:** - 5점: 구체적 장애/문제 사례 + 원인 분석 + 해결 + 재발 방지까지 - 4점: 문제 해결 사례 있으나 재발 방지 없음 - 3점: "문제가 있어서 해결했다" 수준. 진단 과정 불명확 - 2점: 간접적 언급만 ("성능 최적화 수행") - 1점: 전무. 전부 "구축했다/개발했다"만 있음 **확인 항목:** - [ ] 장애 대응 사례 (서비스 다운, 데이터 유실, 성능 저하 등) - [ ] 성능 병목 발견 → 원인 분석 → 해결 과정 - [ ] 레거시 코드 문제 진단 → 리팩토링 과정 - [ ] 예상치 못한 기술적 도전과 극복 과정 - [ ] 모니터링/관측성 도입 사례 **피드백 생성 규칙:** - "구축/개발/구현"만 있는 프로젝트를 찾아 나열 - 각 프로젝트에서 "이런 문제가 있었을 법한데" 질문 형태로 유도 예) "100만건+ Excel 처리 — OOM 발생한 적 없었나요? 있었다면 그 해결 과정이 매우 좋은 소재입니다" ### 축 5: 영향 범위 (Scope of Influence) 경력 3년 이상이면 개인 코드 너머의 영향력이 보여야 함. **채점 기준:** - 5점: 팀/조직 차원 영향 + 후배 성장 기여 + 기술 문화 주도 - 4점: 팀 영향 있음 (코드 리뷰, 표준 도입 등) - 3점: 간접적 팀 영향 (GitHub Action 같은 도구 제공) - 2점: 개인 구현 위주. 팀 언급 거의 없음 - 1점: 완전히 개인 작업. 협업 증거 없음 **확인 항목:** - [ ] 코드 리뷰 주도 경험 - [ ] 주니어 멘토링 / 온보딩 기여 - [ ] 기술 의사결정 리드 (팀 내 아키텍처 결정) - [ ] 팀 생산성 향상 기여 (도구, 프로세스, 문화) - [ ] 타 팀 협업 경험 (프론트, 데이터, 기획 등) - [ ] 사내 기술 공유/발표 **피드백 생성 규칙:** - 팀/조직 관련 언급이 없는 프로젝트를 나열 - "이 프로젝트에서 팀에 미친 영향을 추가하면" 제안 예) "Template Method Pattern 도입 — 이 패턴을 팀에 제안한 과정, 다른 팀원이 새 데이터 타입을 쉽게 추가할 수 있게 된 결과를 포함하면 영향 범위가 넓어집니다" ### 축 6: 커리어 내러티브 (Career Story) 이력서 전체가 하나의 이야기로 읽히는지. 프로젝트 카탈로그 vs 성장 스토리. **채점 기준:** - 5점: 커리어 흐름이 자연스럽고 성장 방향이 명확 - 4점: 대체로 연결되나 일부 공백 - 3점: 개별 프로젝트는 좋으나 연결고리 부족 - 2점: 프로젝트 나열. 왜 이 순서인지 불명확 - 1점: 단절. 이전 경력과 현재가 연결 안 됨 **확인 항목:** - [ ] 이전 회사 → 현재 회사 전환 이유/맥락이 읽히는가 - [ ] 기술적 성장 방향이 보이는가 (점점 심화 or 확장) - [ ] 도메인 전문성 축적이 보이는가 - [ ] 소개/요약이 경력 전체를 아우르는가 - [ ] 공백 기간이 있으면 설명되는가 **피드백 생성 규칙:** - 경력 간 단절 구간을 찾아 지적 - 소개 문단이 실제 경력과 일치하는지 검증 - "커리어 흐름을 강화하려면" 제안 ## review 출력 포맷 ``` 경력 기술서 평가 ════════════════════════════════════════ 총점: {N}/30 ┌─────────────────────┬────┬──────────────────────────────┐ │ 평가 축 │ 점수│ 한줄 요약 │ ├─────────────────────┼────┼──────────────────────────────┤ │ 1. 정량적 임팩트 │ N/5│ {핵심 문제 한줄} │ │ 2. 의사결정 근거 │ N/5│ {핵심 문제 한줄} │ │ 3. 규모 컨텍스트 │ N/5│ {핵심 문제 한줄} │ │ 4. 문제 해결 스토리 │ N/5│ {핵심 문제 한줄} │ │ 5. 영향 범위 │ N/5│ {핵심 문제 한줄} │ │ 6. 커리어 내러티브 │ N/5│ {핵심 문제 한줄} │ └─────────────────────┴────┴──────────────────────────────┘ 등급: {S/A/B/C/D} ──────────────────────────────────────── 상세 피드백 ──────────────────────────────────────── ### 축 1: 정량적 임팩트 — {N}/5 **발견된 문제:** - "{원문 인용}" → 숫자 없음 - "{원문 인용}" → 숫자 없음 **개선 예시:** - AS-IS: "{현재 문장}" TO-BE: "{개선 문장 — 숫자 포함}" (축 2~6 동일 구조 반복) ──────────────────────────────────────── 우선순위 액션 (TOP 3) ──────────────────────────────────────── 1. {가장 임팩트 큰 개선사항} 2. {두 번째} 3. {세 번째} 이 피드백을 반영한 개선본을 원하시면: /resume improve <같은 pdf 경로> ``` ## 등급 기준 | 등급 | 점수 | 의미 | |------|------|------| | S | 27-30 | 즉시 면접 요청 수준 | | A | 22-26 | 서류 통과 가능. 부분 보강 필요 | | B | 16-21 | 경쟁력 있으나 약점 명확. 보강 권장 | | C | 10-15 | 서류 탈락 위험. 전면 개선 필요 | | D | 6-9 | 구조부터 재작성 필요 | --- # 모드 3: improve PDF를 읽고, review 평가를 **내부적으로 먼저 수행**한 뒤, 평가 결과를 반영한 **개선된 경력 기술서**를 생성한다. 결과는 `~/IdeaProjects/경력기술서_improved_YYYYMMDD-HHMMSS.md`에 새 파일로 저장한다 (원본 보존, 상세는 "출력 경로 규칙" 섹션 참고). ## 실행 흐름 ### 1단계: 내부 평가 review 모드와 동일한 6축 평가를 수행한다. (출력하지 않음) ### 2단계: 개선 원칙 적용 평가에서 발견된 문제를 아래 원칙으로 개선한다: **원칙 A — 숫자 보강 (축 1 개선)** - 원본에 수치가 있으면 반드시 포함 - 원본에 수치가 없지만 맥락에서 추론 가능한 경우: → `[추정]` 태그를 붙이고 근거 제시 → 예: "100만건+ 데이터 처리 [추정: Excel 행 제한 1,048,576 기반]" - 추론도 불가능한 경우: → `[TODO]` 태그 + "이 수치를 채워주세요" 빈칸 제시 → 예: "쿼리 응답속도 [TODO N]초 → [TODO N]초로 개선" **원칙 B — 의사결정 보강 (축 2 개선)** - 주요 기술 선택에 "왜?" 한 문장 추가 - 원본에서 유추 가능한 경우 근거 작성 - 유추 불가능한 경우 `[TODO: 왜 X 대신 Y를 선택했는지]` 표시 **원칙 C — 규모 보강 (축 3 개선)** - 원본에 있는 규모 정보 모두 포함 - 없는 경우 `[TODO]` + 채울 항목 제시 → 예: "동시 사용자 [TODO N]명, 일일 처리량 [TODO N]건" **원칙 D — 문제 해결 유도 (축 4 개선)** - 기존 프로젝트 내용에서 문제 해결 가능성이 보이면 질문 형태로 유도 - `[TIP]` 태그로 구분 → 예: "[TIP] 100만건 Excel 처리 시 OOM 이슈가 있었다면 해결 과정을 추가하세요" **원칙 E — 영향 범위 확장 (축 5 개선)** - 팀 영향이 보이는 부분 강화 - `[TIP]` 태그로 팀 관련 내용 추가 유도 **원칙 F — 내러티브 연결 (축 6 개선)** - 소개 문단을 팩트 기반으로 리라이트 - 경력 간 연결고리 보강 - 공백 경력 확장 ### 3단계: 개선 기술서 출력 generate 모드와 동일한 포맷으로 출력하되: - `[추정]` 태그가 있는 수치는 볼드 처리 - `[TODO]` 는 채워야 할 빈칸으로 명확히 표시 - `[TIP]` 은 기술서 본문과 분리하여 각 섹션 끝에 배치 ### 4단계: 개선 요약 출력 기술서 끝에 다음을 추가: ``` ──────────────────────────────────────── 개선 반영 요약 ──────────────────────────────────────── 적용된 개선: N건 - 축 1 (정량적 임팩트): {N}건 수치 보강 - 축 2 (의사결정 근거): {N}건 선택 근거 추가 - ... TODO 항목: N건 - {항목 1}: {어디에 있는지} - {항목 2}: {어디에 있는지} TIP: N건 - {제안 1} - {제안 2} 확인 필요 항목을 채워서 다시 /resume improve 하면 더 높은 점수를 받을 수 있습니다. ``` --- # 모드 4: enrich 프로젝트 소스코드를 분석하여 경력기술서의 해당 섹션을 **코드 근거 기반**으로 보강하고, 6축 평가를 돌려 **목표 점수**에 도달할 때까지 자동 개선한다. **목표 점수 결정:** - 인자로 숫자가 들어오면 그 점수를 사용 (예: `/resume enrich 25` → 25점/30점) - 인자가 없으면 22점(A등급)을 기본값으로 사용 - 유효 범위는 6~30점. 범위 밖이면 사용자에게 다시 물어본다 — 너무 낮으면 보강이 의미 없고, 너무 높으면 도달 불가능해 무한 반복 위험이 있기 때문 ## 전제 조건 - 경력기술서 파일: `~/IdeaProjects/경력기술서.md` (없으면 "먼저 `/resume `로 기술서를 생성하세요" 안내) ## 실행 흐름 ``` 0단계: 경력기술서 읽기 + 프로젝트 섹션 목록 추출 | 1단계: AskUserQuestion으로 프로젝트 경로 받기 | 2단계: 프로젝트 <-> 경력기술서 섹션 매칭 | 3단계: 프로젝트 코드 분석 (6축 관점) | 4단계: 경력기술서 해당 섹션 보강 | 5단계: 6축 평가 실행 | +-- 목표점수 미만 --> 자동 개선 --> 재평가 (최대 3회) | +-- 목표점수 이상 --> 결과 저장 | 6단계: AskUserQuestion — "다음 프로젝트가 있나요?" | +-- 경로 입력 --> 2단계로 돌아감 +-- "완료" 선택 --> 7단계: 전체 리포트 출력 ``` ### 0단계: 경력기술서 읽기 + 프로젝트 목록 추출 1. `~/IdeaProjects/경력기술서.md`를 Read로 읽는다 2. "## 프로젝트 상세" 섹션에서 `### {프로젝트명}` 패턴을 모두 추출한다 3. 현재 기술서에 포함된 프로젝트 목록을 사용자에게 보여준다: ``` 경력기술서 로드 완료 ──────────────────────────────────────── 현재 등록된 프로젝트: 1. AI 연구 시스템 2. 외부 대조군 시스템 (ECA API) 3. 임상 유전체 통합 진료 지원 시스템 4. 지표 모니터링 서비스 5. Python 코드 품질 자동 검증 GitHub Action ──────────────────────────────────────── ``` ### 1단계: 프로젝트 경로 받기 AskUserQuestion으로 프로젝트 소스코드 경로를 받는다. 질문: "보강할 프로젝트의 소스코드 경로를 입력하세요." 설명: "프로젝트의 git 저장소 경로를 입력하면 코드를 분석하여 경력기술서를 보강합니다. 절대경로 또는 ~ 상대경로 모두 가능합니다." - 경로가 유효하지 않으면 "해당 경로에 프로젝트가 없습니다. 다시 입력해주세요." 후 재질문 - 경로 내에 소스코드 파일이 없으면 동일하게 재질문 ### 2단계: 프로젝트 <-> 섹션 매칭 프로젝트 경로의 디렉토리명과 경력기술서의 프로젝트 섹션을 매칭한다. - 경로명 기반 매칭: `eca-api` -> "외부 대조군 시스템 (ECA API)" - 매칭 실패 시 AskUserQuestion으로 어떤 프로젝트 섹션과 연결할지 확인: 질문: "이 프로젝트는 경력기술서의 어떤 프로젝트에 해당하나요?" 선택지: 0단계에서 추출한 프로젝트 목록 + "새 프로젝트로 추가" ### 3단계: 프로젝트 코드 분석 Agent 도구로 프로젝트를 분석한다. 6축 각각에 필요한 정보를 추출: **[축 1] 정량적 임팩트 소스:** - 설정 파일에서 수치 (타임아웃, 배치 크기, 캐시 TTL, 워커 수 등) - 테스트 코드에서 성능 기대값 - 로그/모니터링 설정에서 임계값 - README/문서에서 성능 관련 기술 **[축 2] 의사결정 근거 소스:** - 의존성 파일 (requirements.txt, build.gradle, package.json)에서 기술 선택 - 설정 파일에서 아키텍처 패턴 (비동기, 캐싱, 큐 등) - 코드 주석에서 "왜" 관련 설명 - ADR(Architecture Decision Records) 문서 - git log에서 주요 아키텍처 변경 커밋 **[축 3] 규모 컨텍스트 소스:** - DB 스키마/마이그레이션에서 테이블 규모 힌트 - 설정의 커넥션 풀 크기, 워커 수 - 페이지네이션/배치 크기 설정 - 인프라 설정 (Dockerfile, k8s manifest, Cloud Run config) - CI/CD 파이프라인 구조 **[축 4] 문제 해결 스토리 소스:** - git log에서 "fix", "hotfix", "bugfix", "resolve", "optimize" 포함 커밋 - 코드의 에러 핸들링 패턴 (retry, circuit breaker, fallback) - 성능 최적화 흔적 (캐싱, 인덱스, 배치 처리) - 모니터링/알림 설정 **[축 5] 영향 범위 소스:** - 공유 라이브러리/유틸 모듈 - 코드 리뷰 관련 설정 (CODEOWNERS, PR 템플릿) - 문서화 수준 (README, API docs, 주석) - 테스트 커버리지 설정 - 린터/포매터 설정 **[축 6] 커리어 내러티브 소스:** - 프로젝트 README에서 목적/배경 - git log --oneline의 첫 커밋 ~ 최근 커밋으로 프로젝트 기간 파악 - 주요 기능 변경 이력 **분석 방법:** ``` Glob으로 프로젝트 구조 파악: - **/requirements.txt, **/build.gradle.kts, **/package.json - **/Dockerfile, **/docker-compose.yml, **/*.yaml (k8s) - **/README.md - **/.github/** Grep으로 핵심 패턴 검색: - 설정값: "timeout", "batch_size", "max_workers", "pool_size", "cache", "ttl" - 아키텍처: "celery", "redis", "async", "await", "queue" - 문제 해결: "retry", "fallback", "circuit", "rate_limit" Bash로 git 이력 분석: - git log --oneline -50 (최근 50개 커밋) - git log --oneline --grep="fix\|optimize\|refactor" (문제 해결 커밋) - git shortlog -sn (기여자 분포) - git log --format="%ai" --reverse | head -1 (첫 커밋 날짜) Read로 핵심 파일 읽기: - 메인 설정 파일 - 핵심 서비스/도메인 코드 (최대 5개 파일) - 인프라 설정 ``` ### 4단계: 경력기술서 보강 분석 결과를 경력기술서의 해당 프로젝트 섹션에 반영한다. **보강 규칙:** - 코드에서 직접 확인한 정보: 그대로 반영 - 코드에서 유추 가능한 정보: `[코드 근거: {파일명}]` 태그 + 반영 - 코드에 없지만 경력기술서에 있는 기존 내용: 유지 - 코드에도 경력기술서에도 없는 정보: 추가하지 않음 **보강 대상 (축별):** 1. 정량적 임팩트: 설정값 기반 수치 추가, "대폭/향상" -> 구체적 수치 2. 의사결정 근거: 의존성/설정에서 유추한 기술 선택 이유 추가 3. 규모 컨텍스트: 인프라 설정에서 유추한 규모 정보 추가 4. 문제 해결 스토리: git log의 fix 커밋에서 문제 해결 사례 추출 5. 영향 범위: 공유 코드, 문서화 수준에서 팀 영향 추출 6. 커리어 내러티브: 프로젝트 기간, 목적 보강 ### 5단계: 6축 평가 (해당 섹션만) review 모드의 6축 평가 프레임워크를 해당 프로젝트 섹션에만 적용한다. 총점 30점 기준. ### 5-1단계: 자동 개선 루프 목표: 사용자 지정 점수 (인자에서 받은 값, 미지정 시 22점/30점 — A등급) 최대 반복: 3회 ``` 평가 결과에서 가장 낮은 축 식별 | v 해당 축의 피드백 규칙에 따라 개선 | v 경력기술서 해당 섹션 수정 | v 재평가 | +-- 목표점수 미만 & 반복 < 3 --> 다시 개선 +-- 목표점수 이상 OR 반복 = 3 --> 종료 ``` **개선 우선순위:** 1. 정량적 임팩트 (가장 빠르게 점수 올릴 수 있음) 2. 규모 컨텍스트 3. 의사결정 근거 4. 문제 해결 스토리 5. 영향 범위 6. 커리어 내러티브 ### 5-2단계: 프로젝트별 결과 저장 + 간단 리포트 1. **백업 먼저**: 보강 직전 `~/IdeaProjects/경력기술서_backup_YYYYMMDD-HHMMSS.md`로 현재 상태를 복사 2. `~/IdeaProjects/경력기술서.md`에 보강된 내용을 Edit으로 저장 (in-place 업데이트) 3. 간단 리포트 출력: ``` enrich 완료: {프로젝트명} ════════════════════════════════════════ 분석한 프로젝트: {경로} 매칭된 섹션: {경력기술서 프로젝트명} 코드에서 추출한 정보: - 설정/수치: {N}건 - 기술 선택 근거: {N}건 - 규모 정보: {N}건 - 문제 해결 사례: {N}건 - 팀 영향 증거: {N}건 평가 결과: - 초기 점수: {N}/30 ({등급}) - 개선 반복: {N}회 - 최종 점수: {N}/30 ({등급}) ``` ### 6단계: 다음 프로젝트 확인 AskUserQuestion으로 다음 프로젝트를 받는다. 질문: "다음으로 보강할 프로젝트가 있나요?" 설명: "프로젝트 소스코드 경로를 입력하거나, 모든 프로젝트 보강이 끝났으면 '완료'를 선택하세요." 선택지: - "완료 — 전체 리포트 출력" (첫 번째) - 자유 입력 (경로 직접 입력) - 경로를 입력하면 -> 2단계로 돌아감 - "완료"를 선택하면 -> 7단계로 진행 ### 7단계: 전체 리포트 모든 프로젝트 보강이 끝난 뒤 전체 결과를 출력한다. ``` enrich 전체 완료 ════════════════════════════════════════ 보강한 프로젝트: {N}개 ──────────────────────────────────────── 1. {프로젝트명} ({경로}) 초기: {N}/30 ({등급}) -> 최종: {N}/30 ({등급}) 2. {프로젝트명} ({경로}) 초기: {N}/30 ({등급}) -> 최종: {N}/30 ({등급}) (프로젝트별 반복) ──────────────────────────────────────── 전체 축별 평균 점수: 1. 정량적 임팩트: {N}/5 2. 의사결정 근거: {N}/5 3. 규모 컨텍스트: {N}/5 4. 문제 해결: {N}/5 5. 영향 범위: {N}/5 6. 내러티브: {N}/5 코드 근거 태그 목록: - [코드 근거: {파일}] {내용 요약} - ... 저장됨: ~/IdeaProjects/경력기술서.md ``` --- # 모드 5: match 채용 공고(JD) 대비 이력서 매칭을 분석한다. PDF 이력서와 JD(URL 또는 본문 텍스트)를 받아 **JD 키워드 커버리지**, **강조해야 할 경험**, **갭(누락된 요구 사항)**을 도출해 지원 전략을 제시한다. ## 입력 - PDF 이력서 경로 (``) - JD 입력: URL 또는 본문 텍스트 ## 실행 흐름 ``` 0단계: PDF 이력서 읽기 | 1단계: JD 텍스트 확보 - URL이면 WebFetch로 가져오기 - 본문 텍스트면 그대로 사용 - 비어 있으면 AskUserQuestion으로 다시 받기 | 2단계: JD 구조화 추출 | 3단계: 이력서 매칭 분석 | 4단계: 매칭 리포트 생성 | 5단계: 파일 저장 + 다음 단계 안내 ``` ### 1단계: JD 텍스트 확보 — URL 처리 노트 - URL이 인증 필요(로그인 필수 페이지) 또는 동적 렌더링 사이트(예: 일부 채용 플랫폼)면 WebFetch 결과가 빈 본문일 수 있다. 이 경우 사용자에게 JD 본문을 직접 붙여넣어 달라고 요청한다 — 임의 추측은 분석을 망친다 - 한 회사 한 공고가 원칙. 여러 공고 비교는 각각 별도 호출로 진행한다 ### 2단계: JD 구조화 추출 — 출력 스키마 JD 본문에서 다음 정보를 추출해 내부 변수로 저장한다 (사용자에게 보여주기 전 단계): ```yaml 회사: "{회사명 or '미상'}" 직무: "{직무명}" 경력_요건: "{N년 이상 / 무관 등}" must_have: - "{필수 요구 사항}" nice_to_have: - "{우대 사항}" 핵심_기술: ["Python", "FastAPI", ...] 책임: - "{업무}" ``` JD에 명시되지 않은 항목은 비워둔다 — 추측으로 채우면 갭 분석이 왜곡된다. ### 3단계: 이력서 매칭 분석 각 JD 항목에 대해 이력서 본문을 검색하고 다음 형태로 정리한다: ```yaml - 항목: "{JD 요구 사항}" 유형: "must_have" | "nice_to_have" | "기술" | "책임" 매칭: "직접" | "간접" | "없음" 근거: "{이력서 인용 — 직접/간접 매칭 시}" 메모: "{개선 제안 — 강조 권장 / 갭 보강 필요}" ``` **매칭 분류 기준:** - **직접**: 이력서에 동일 키워드·기술·경험이 명시됨 - **간접**: 동등한 경험이 다른 표현으로 있음 (예: JD "MSA" ↔ 이력서 "마이크로서비스 분리") - **없음**: 이력서에 관련 흔적이 없음 ### 4단계: 매칭 리포트 포맷 ``` JD 매칭 분석 ════════════════════════════════════════ 회사: {회사명} 직무: {직무명} 경력 요건: {요건} ──────────────────────────────────────── 종합 매칭률 ──────────────────────────────────────── Must-have: {N}/{전체} ({퍼센트}%) Nice-to-have: {N}/{전체} ({퍼센트}%) 핵심 기술: {N}/{전체} ({퍼센트}%) 종합 등급: {S/A/B/C/D} S (Must 90%+ & 기술 80%+): 즉시 지원 권장 A (Must 75%+ & 기술 70%+): 지원 가능, 일부 강조 필요 B (Must 60%+): 지원 가능하나 갭 보강 권장 C (Must 40~60%): 갭 큼, 보강 후 지원 D (Must <40%): 직무 매칭 낮음, 다른 공고 검토 권장 ──────────────────────────────────────── ✅ 강조해야 할 경험 (이력서에 있으나 묻혀있는 것) ──────────────────────────────────────── 1. {JD 항목} ← 이력서의 "{근거 인용}" 강조 추천 액션: {어떻게 강조할지 — 위치 이동, 수치 추가, bullet 분리 등} 2. ... ──────────────────────────────────────── ⚠️ 갭 — JD에는 있는데 이력서에 없는 것 ──────────────────────────────────────── 1. {갭 항목} (유형: {must_have/nice_to_have/기술}) 영향도: {높음/중간/낮음} 대응 옵션: {보강 제안 — 관련 경험 발굴, 학습 권고, 또는 우회 표현} 2. ... ──────────────────────────────────────── 🔧 이력서 수정 추천 (Top 3) ──────────────────────────────────────── 1. {가장 임팩트 큰 수정} 2. ... 3. ... 다음 단계: - 이력서 보강은 /resume improve 또는 /resume enrich - 다른 공고와 비교는 /resume match {다음 JD} ``` ### 5단계: 저장 + 사용자 안내 매칭 리포트를 `~/IdeaProjects/jd-match-{회사명}-YYYYMMDD.md`로 저장한다. 회사명을 추출하지 못한 경우 `jd-match-YYYYMMDD-HHMMSS.md`를 사용한다 (출력 경로 규칙 섹션 참고). 저장 후 핵심 요약(매칭률·등급·Top 3 수정안)만 콘솔에 출력하고, 상세 리포트는 파일에서 확인하도록 안내한다. ## match 모드 작성 원칙 - 추측 금지 — JD에 명시된 항목과 이력서에 있는 텍스트만 비교한다. 이력서·JD 양쪽에 없는 항목으로 갭을 만들지 않는다 - 매칭률은 절대 평가가 아닌 상대적 참고 — 이력서 한 장으로 표현되지 않는 경험이 있을 수 있다. 사용자가 인터뷰에서 보완할 수 있다는 점을 리포트 끝에 안내한다 - 회사명·직무명을 정확히 추출하기 어려우면 빈 칸으로 두고 사용자에게 확인을 요청한다 — 잘못된 회사명은 파일명·검색 모두를 어지럽힌다 --- ## 공통 주의사항 - 코드·PDF에서 직접 확인한 정보를 반영한다. 간접 정보는 `[코드 근거: {파일}]` 또는 `[추정: 근거]` 태그로 출처를 명시한다 — 이력서 신뢰는 한 번 무너지면 회복이 어렵다 - 개인정보(주민번호·상세 주소·가족 정보)는 출력에서 제외한다 — 이력서가 외부에 유출될 때 신원 도용 위험이 있다 - 입력 이력서 언어를 따라 출력 언어를 결정한다 (영문 입력 → 영문 출력, 국문 입력 → 국문 출력) - PDF 읽기 실패 시 사용자에게 파일 경로 재확인을 요청한다 - 비-PDF 입력(.docx·.make 등)은 "PDF로 내보내기 후 다시 시도해주세요"로 안내한다 - enrich 모드에서 프로젝트 경로가 없으면 사용자에게 경로를 다시 입력받는다 - enrich 모드에서 경력기술서.md가 없으면 먼저 `/resume ` 실행을 안내한다 - 자동 개선 루프(enrich)는 최대 3회로 제한해 무한 루프를 방지한다 - 결과물 저장 경로는 모드별로 통일한다 (아래 "출력 경로 규칙" 섹션 참고) --- ## 출력 경로 규칙 기본 디렉토리: `~/IdeaProjects/` | 모드 | 저장 경로 | 백업 정책 | |------|----------|---------| | generate | `경력기술서.md` | 같은 경로에 기존 파일이 있으면 `경력기술서_backup_YYYYMMDD-HHMMSS.md`로 백업 후 새로 작성 | | review | 저장 없음 — 콘솔 출력만 | — | | improve | `경력기술서_improved_YYYYMMDD-HHMMSS.md` | 새 파일로 생성 (원본 유지) | | enrich | `경력기술서.md` (in-place 업데이트) | 매 보강 직전 `경력기술서_backup_YYYYMMDD-HHMMSS.md`로 자동 백업 | | match | `jd-match-YYYYMMDD-HHMMSS.md` (회사명 있으면 `jd-match-{회사명}-YYYYMMDD.md`) | 새 파일로 생성 | **버전 보존 이유:** - improve는 평가 기반 자동 재작성이라 결과가 매 회 달라질 수 있다 — 원본을 보존해야 비교·롤백이 가능하다 - enrich는 in-place 업데이트지만 잘못된 보강이 발생할 경우 직전 상태로 되돌릴 수 있어야 한다 **디렉토리 부재 시:** `~/IdeaProjects/`가 없으면 사용자에게 생성 여부를 확인하거나 다른 저장 경로를 입력받는다. **timestamp 형식:** Bash `date +%Y%m%d-%H%M%S`로 생성 (예: `20260502-013047`).

resume

Install this skill

Comments