--- name: hiring-sim-resume-redteam description: 면접관 관점에서 이력서의 감점 요소를 적발하는 비판적 레드팀 리뷰. 이력서 수치가 현실적으로 말이 되는지 근거(규모 추정·리서치)로 검증하고, 첨부된 GitHub 링크의 실제 코드가 이력서 주장대로 구현·품질·보안이 맞는지, 블로그 링크 내용이 사실·현실적인지를 데카르트 방법적 회의로 직접 대조하고, 지원 직군(백엔드·프론트엔드·풀스택·AI·임베디드·로보틱스)의 최신 채용 기대 역량 대비 공백(없는 역량·얕은 깊이)까지 짚어 "면접관이 파고들 감점 포인트"를 심각도별로 산출합니다. PASS/REJECT 채점이 아닙니다. argument-hint: "<이력서 파일 경로 (+ 안에 첨부된 GitHub/블로그 링크)>" user-invocable: true triggers: - "이력서 감점" - "이력서 레드팀" - "이력서 검증" - "이력서 모순" - "면접관 관점 이력서" - "이력서 비판적 리뷰" - "직무 적합성 공백" - "포지션 역량 공백" --- # 이력서 레드팀 리뷰 (면접관 감점 포인트 적발) 이력서를 **가장 비판적인 면접관**의 눈으로 읽고, 라이브 면접에서 파고들리거나 감점될 지점만 골라낸다. **합격/탈락 스크리닝이 아니라, "어디서 깎이고 어디서 털리는가"를 포렌식으로 적발**하는 레드팀 렌즈다. 핵심: **이력서에 적힌 글·수치·링크를 액면 그대로 믿지 않는다.** 포트폴리오는 표·대시보드로 내부 대조가 되지만, 이력서는 **글 기반이라 대조할 근거가 이력서 안에 없다.** 그래서 **밖에서 근거를 끌어온다** — 수치는 규모 추정·리서치로, 첨부된 GitHub 코드·블로그는 직접 읽어 대조한다. 이 리뷰의 독자는 **면접관/평가자**다 — 남(외부 후보)의 이력서·공개 레포를 본다는 가정. 산출은 "지원자님 이렇게 고치세요"가 아니라 **감점 판정 + 면접에서 검증·반증하는 법**이다. ## 언제 쓰나 / 안 쓰나 **쓴다:** 이력서 제출 전 마지막 검증, "면접관이 뭘 물어볼까"가 궁금할 때, 수치·GitHub·블로그가 붙은 기술 이력서, 내 이력서 허점을 스스로 먼저 찾고 싶을 때. **안 쓴다:** 초안 뼈대만 있어 검증할 근거가 없을 때(→ `hiring-prep-doc-feedback`), 합격 여부만 알고 싶을 때(→ `hiring-sim-resume-review`), 단순 오탈자 교정. --- ## 핵심 엔진 — Cartesian Doubt (방법적 회의) `cartesian-doubt`의 **의심 사다리**와 **네 규칙**을 이력서용으로 차용한다. 원리: *액면(주장)과 검증된 사실을 분리하고, 하중을 받는 주장만 실제로 대조한다.* 회의는 **리스크에 비례해서만** 올린다(사소한 걸 다 의심하는 건 분석 마비이지 엄밀함이 아니다). ### 의심의 사다리 | 레벨 | 데카르트 | 이력서에서 | 언제 | |---|---|---|---| | **L1 감각의 기만** | 지각은 못 믿는다 | **수치가 거짓말한다** — 정량 수치를 액면으로 믿지 말고 **규모 추정(Fermi)·회사 규모 리서치**로 현실성 대조 | 항상 (모든 수치) | | **L2 꿈의 논증** | 깨어있음/꿈 구분 불가 | **글이 말하는 것 ≠ 실제 산출물** — 이력서 주장 ↔ 첨부 **GitHub 코드·블로그 실제 내용**이 일치하는가 | 링크가 있을 때 항상 | | **L3 악령** | 악의적 존재가 속인다 | **최악의 적대적 면접관** — 핵심 셀링 포인트마다 "악의적으로 파고들면 어디서 무너지나" 시뮬레이션 | 핵심 주장마다 | ### 네 규칙 → [검증됨 / 모순 / 가정 / 불명] 라벨 각 핵심 주장에 라벨을 붙이고 **검증됨만 강점으로 인정**한다. ① 증거(명석·판명하지 않으면 사실로 안 받음) ② 분석(항목→주장→수치로 쪼갬) ③ 순서(확실한 것부터) ④ 열거(모든 항목·모든 링크 커버, 못 본 것은 "미확인"). --- ## 4대 검증 엔진 (이력서 특화) ### 엔진 A · 수치 현실성 (규모 추정 + 리서치) 이력서 수치는 내부 대조가 안 되니 **밖에서 검증**한다. - **Fermi 추정**: 주장 수치를 회사 규모·트래픽·팀 크기·기간으로 역산해 물리적으로 가능한지. 예) "일 1억 건 처리"인데 서비스 MAU가 수만이면 모순 · "3명이 2주에 MSA 12개"는 비현실 · "응답 10배 개선"의 baseline이 비정상적으로 느렸던 건 아닌지. - **회사·도메인 리서치**: `hiring-common/interview-research.md` 방식으로 회사 규모·서비스 트래픽을 조사해 대조. 확인 불가면 "규모 미확인"으로(부정 추측 금지). - **기준 함정**: "성능 N배"의 baseline, "99.9% 가용성"을 어떻게 쟀는지, "대용량/실시간"의 실제 규모. - 라벨: 물리적 가능+근거 [검증됨] · 리서치와 어긋남 [모순] · 근거 없이 정밀 [가정] · 확인 불가 [불명]. ### 엔진 B · GitHub 코드 대조 (링크 첨부 시 필수) 이력서에 GitHub 링크가 있으면 **실제 코드를 읽어** 주장과 대조한다. **프로젝트 옆에 첨부된 링크를 그대로 따라간다 — 대개 조직(팀) 레포다.** 개인 계정 레포 목록·이름 검색이 아니라 **첨부 링크 자체가 정답**(개인 계정엔 팀 프로젝트가 없다). PDF면 텍스트에 URL이 안 보여도 **하이퍼링크 annotation을 추출**한다(PyMuPDF `page.get_links()`의 `uri`). 단, 파일을 하나씩 열지 않는다 — 아래 순서로 타겟 검색해 빠르고 토큰 효율적으로 해당 부분만 본다. **효율적 코드 탐색 (clone → 검색 → 해당 부분만 읽기)** 1. **얕은 클론 1회**: `git clone --depth 1 --filter=blob:none /tmp/rt-` — URL로 파일을 하나씩 읽는 것보다 압도적으로 빠르고 싸다. (기여도 확인이 필요하면 `--filter` 없이 얕은 히스토리로.) 2. **구조 먼저**: `find`/트리·README로 모듈·서비스 경계만 잡아 "어디 있을지"를 좁힌다(전수 읽기 X). 3. **주장 → 키워드 타겟 `search`(ripgrep)**: 이력서 주장에서 심볼·용어를 뽑아 검색해 **파일:라인 히트만** 얻는다. 예) SAGA→`Saga|orchestrat|compensat`, 멱등성→`idempoten|dedup|processed_event`, 분산락→`SETNX|Redisson|distributed.?lock|\.lua`, 서킷브레이커→`CircuitBreaker|resilience4j`, 어노테이션 `@Transactional|@KafkaListener`. 4. **히트 주변만 `read`**: 매치된 파일의 **해당 라인 범위만** 읽는다(전체 파일 X). 5. **기여도(핵심)**: `git shortlog -sne`로 본인 커밋 비중, 그리고 **이력서가 주장한 각 기능 커밋의 실제 author**를 확인한다 — `git log -i --grep='<기능 키워드>' --format='%an ┃ %s'` · `git log -S'<심볼>' --format='%an'`. 지원자 커밋이 그 기능과 **다른 영역**이면(예: 통계 페이지만 했는데 "무한스크롤·Tanstack 마이그레이션"을 적음) 팀 성과를 개인 성과로 적은 **기여도 과장**. 단 pair-programming·다른 커밋메시지 가능성은 후속질문으로 확인. 6. 못 찾으면 "구현 미발견"으로 기록(추측 금지). 클론 실패(사설·대용량)면 GitHub 코드 검색(UI/API) 또는 README·경로 URL로 폴백. - **구현 존재**: 이력서 주장 기능·기술(예: "Redis 멱등성 키로 중복 차단", "SAGA 오케스트레이션")이 레포에 **실제로 구현돼 있는가**. 파일·커밋으로 확인. - **구현 적합성**: 주장대로 동작하는 코드인가, 이름만 그럴듯한가(예: "분산락"이라며 단일 인스턴스 뮤텍스 · "비동기"라며 블로킹 호출). - **코드 품질·취약점**: 명백한 버그·안티패턴·보안 취약점(하드코딩 시크릿, SQL 인젝션, 미검증 입력, 레이스 컨디션)·테스트 부재. - **기여도**: 본인 커밋 비중(shortlog) + **주장한 기능 커밋의 실제 author가 본인인지**. 남이 한 최적화를 "내가 구현"으로 적었으면 기여도 과장(레드팀 핵심 적발 지점). - 사설·삭제·인증 필요 레포는 "접근 불가"로 표기하고 추측하지 않는다. ### 엔진 C · 블로그 대조 (링크 첨부 시) 블로그 링크가 있으면 `read`로 **직접 읽고** 방법적 회의를 적용한다. - **사실·현실성**: 기술적으로 말이 되는가, 수치·주장이 과장/오류는 아닌가. - **면접관이 의아해할 지점**: 개념 오용, 인과 과장("이렇게 하면 X배 빨라진다"의 근거 부재), 남의 글 짜깁기 흔적, 결론과 근거의 불일치. - **이력서 ↔ 블로그 일치**: 이력서엔 "직접 설계"인데 블로그는 튜토리얼 따라하기 수준은 아닌지. - 라벨: 사실·정확 [검증됨] · 이력서와 어긋남 [모순] · 기술 오류·과장 [의심] · 확인 불가 [불명]. ### 엔진 D · 포지션 시장 기대 역량 공백 (coverage gap) 지원 **직군이 시장에서 기대하는 베이스라인 역량**과 이력서를 대조해, **없는 것·얕은 것**을 약점으로 잡는다. 거짓(감점)이 아니라 **경쟁 공백** — "이력서에 근거가 없다 → 스크리닝에서 불리 + 면접 확인 대상"이다. - **직군 확정 → 필요한 것만 로드(토큰 효율)**: `references/position-competency-map.md`(규칙+공통+라우팅)를 읽고, **후보 직군 파일 1개만** 추가로 읽는다(예: 프론트면 `references/positions/frontend.md`). 6개 직군을 통째로 읽지 말 것. 각 항목을 **[충족(근거)/부분/공백]** 으로 매핑. - **두 종류 공백**: ① 역량 부재(언급 자체 없음) ② 깊이 공백(성과 수치만 있고 *측정·판단·개선 과정*이 없음 — 예: 부하테스트로 병목을 어떻게 찾았는지 없이 "N% 개선"만). - **최신성**: 타깃 공고가 있으면 `web_search`로 그 회사가 강조하는 역량을 조사해 보정. 없으면 맵의 일반 기준. - **눈높이**: 신입에게 대규모 실무를 요구하진 않되, 직무 핵심에 가까운데 개념·근접경험·학습흔적조차 없으면 심각도↑(🟡→🟠). "경험 없을 것"이라 단정 금지 — "이력서에 근거 없음". - 라벨: 근거로 충족 [충족] · 언급만/얕음 [부분] · 없음 [공백]. --- ## 실행 절차 ### Step 1 · 입력 수집 - **이력서 (필수)**: 경로(PDF/MD/TXT). 미제공 시 대기. DOCX는 PDF 변환 요청. - **첨부 링크 (핵심)**: 이력서 안의 GitHub·블로그·기타 URL을 전부 추출한다. **이 링크 대조가 이 스킬의 차별점**이므로 반드시 확보. 링크가 없으면 엔진 A(수치 현실성) 중심으로 진행. - **채용 공고·지원 직군 (엔진 D)**: 타깃 직군(백엔드/프론트/풀스택/AI/임베디드/로보틱스)을 이력서에서 추정하거나 묻는다. 공고가 있으면 붙여넣게 하고, 최신 기대 역량은 `web_search`로 보정한다. - 경력 수준(신입/주니어/미드/시니어)을 추정하거나 물어 눈높이를 맞춘다. ### Step 2 · 전수 열거 + 링크 추출 (규칙 4) - `Read`로 이력서 전문. **모든 항목·수치·주장**을 목록화. - 이력서 내 **모든 URL**(GitHub/블로그)을 추출해 대조 대상 목록으로. - 커버리지 기록: 항목 N개 / 링크 M개 확인 / K개 접근 불가(사유). ### Step 3 · 4대 엔진 대조 - **엔진 A** — 전 수치 현실성(Fermi + 리서치). - **엔진 B** — GitHub 링크마다 코드 대조(구현 존재·적합성·품질·기여도). - **엔진 C** — 블로그 링크마다 내용 대조(사실성·오류·이력서 일치). - **엔진 D** — 직군 기대 역량 대비 공백. `references/position-competency-map.md`(공통+라우팅) → `references/positions/<직군>.md` **1개만** 읽어 대조. ### Step 4 · Cartesian L3 (evil-demon) 각 핵심 주장에 **최악의 면접관 후속질문**을 만들고, 이력서(+근거)가 방어되는지 판정. 방어 안 되면 감점. ### Step 5 · 심각도 + 후속질문 각 finding에 심각도(🔴🟠🟡)와 **▶ 면접관 후속질문**을 붙인다. ### Step 6 · 출력 아래 **출력 포맷**으로 대화에 정리해 제시. 사용자가 원하면 `.md`로 저장. --- ## 감점 유형 카탈로그 | # | 유형 | 정의 | 신호 예시 | |---|------|------|-----------| | 1 | **수치 비현실성** (A) | 규모 추정·리서치로 물리적 불가능/과장 | 회사 규모 대비 불가능한 트래픽·처리량 · baseline이 비정상적으로 느린 "N배 개선" | | 2 | **코드–주장 불일치** (B) | 이력서 주장이 레포에 없거나 다르게 구현 | "SAGA 구현"인데 레포엔 단순 동기 호출 · "분산락"이 로컬 뮤텍스 | | 3 | **코드 품질·취약점** (B) | 버그·보안·안티패턴·테스트 부재 | 하드코딩 시크릿 · 미검증 입력 · 레이스 컨디션 · 테스트 0 | | 4 | **블로그 오류·과장** (C) | 기술 오류·근거 없는 수치·짜깁기 | 개념 오용 · "X배 빨라짐" 근거 부재 · 결론↔근거 불일치 | | 5 | **기여도 과장** | 팀 성과를 개인 성과처럼 | "내가 설계·구현"인데 커밋/역할이 미미 | | 6 | **용어 인플레** | buzzword 오용 | 큐 버퍼링을 "backpressure" · 브로커 도입에 "SPOF 제거" · "exactly-once" 오용 | | 7 | **인과 과장** | 상관/부분 기여를 전체 원인으로 | 프레임워크 교체+인덱스 최적화를 묶어 "전환해서 60%↓" | | 8 | **검증 불가 소프트 수치** | 측정 근거 없는 정밀 수치 | "생산성 3배" · "논의 80% 감소" | | 9 | **기능 나열(밋밋)** | 문제–해결–성과 없이 "구현했다"만 | 감점보다 손해 저하 → 별도 태그 `[밋밋]` | | 10 | **포지션 역량 공백** (D) | 직군 시장 기대 역량이 이력서에 없거나 얕음 | 백엔드인데 부하테스트/HA/K8s/MSA 언급 0 · AI인데 RAG 평가·eval 없음 · 성과 수치만 있고 측정 과정 없음 | > 9번은 "틀린 것"이 아니라 "손해 보는 것". 감점과 **별개 축**으로, 각 밋밋한 항목은 면접관이 `문제→해결(기술 판단)→정량 성과` 중 빈 곳을 **심화 질문으로 캐서 변별**하는 지점이다(답하면 강점, 못 하면 레시피 수준). 근거는 **실제 한 것만**. > 10번도 "틀린 것"이 아니라 "경쟁에서 밀리는 것" — 감점과 별개 축(📉)으로 빼서, 없는 역량·얕은 깊이를 신입 눈높이로 보정해 보고한다. --- ## 심각도 기준 ``` 🔴 High — 신뢰도를 직접 훼손. 라이브 면접에서 거의 확실히 걸리고, 답 못하면 치명적. (수치 비현실 · 코드–주장 불일치 · 심각한 취약점 · 기여도 과장 · 명백한 과장) 🟠 Med — 논리·용어·인과가 헐거움. 파고들면 흔들리는 것. 🟡 Low — 문구·표기·형평. 꼼꼼한 면접관만 보는 것. ``` --- ## 출력 포맷 ```markdown # 이력서 레드팀 리뷰 — 면접관 감점 포인트 ## 총평 [2~3문장. 이력서의 강점 컨셉과, 그 컨셉을 스스로 배신하는 가장 큰 감점 축 1~2개.] ## 심각도 요약 🔴 High N · 🟠 Med N · 🟡 Low N · [밋밋] N · [역량공백] N 검증 커버리지: 항목 N · GitHub 링크 M/M · 블로그 링크 M/M · 규모 리서치 [수행/불가] ## 감점·오류 (심각도 순) - 🔴 **<한 줄 제목>** — 위치: <이력서 항목> · 엔진: - 문제: <근거 인용 — 리서치 결과 / 코드 파일·라인 / 블로그 원문 vs 이력서 주장> - 라벨: [검증됨 / 모순 / 가정 / 의심 / 불명] - 감점 이유(면접관): ▶ "<최악의 후속질문>" - 면접 검증: <이 주장을 세션에서 확인·반증하는 법 — 링크 열게 하기·라이브 설명/데모 요청·diff 대조> [반복 · 심각도 높은 순] ## 🎣 밋밋해서 손해 보는 지점 (면접관이 물어볼 심화 = 후보 변별점) - **<항목>** — 빈 곳: <문제 맥락 / 기술 판단 근거 / 정량 성과 중 없는 것> - ▶ 심화 질문: "<이걸 물으면 시니어 감각 vs 레시피 수준이 갈리는 질문>" ## 📉 포지션 시장 기대 역량 공백 (직군 기준 · 거짓 아님 = 경쟁 약점) - 🟠/🟡 **<역량>** — [공백/부분] · 직군: <백엔드 등> - 시장 기대: <왜 대부분 공고가 이걸 원하나> - 이력서 현황: <없음 / 성과만 있고 과정 없음 등> - ▶ 확인 질문: "<이걸 물으면 실체가 드러나는 질문>" · 보완: <신입 눈높이에서 이력서를 어떻게 강화하나> ## 면접 검증 우선순위 (이 후보를 만나면) 1. [실체가 갈리는 검증부터 — 링크 열기·수치 근거·개념 깊이 순] ``` --- ## 주의사항 (반드시 지킨다) - **날조 금지.** 모순은 **근거를 인용할 수 있을 때만** 보고한다(리서치 결과 · 코드 파일/라인 · 블로그 원문). 근거 없이 "이상하다"고 쓰지 않는다. - **불명은 불명으로.** 접근 불가 링크·미확인 규모는 "미확인"으로 표기하고 **부정적으로 추측하지 않는다**(사설 레포를 "구현 안 했을 것"이라 단정 금지). - **회의는 리스크에 비례.** 대표 셀링 포인트·핵심 수치에 화력을 집중한다(scalpel, not lifestyle). - **경력 눈높이.** 신입/주니어에게 시니어 설계를 요구하지 않는다. 단 **과장·수치 비현실·코드–주장 불일치·기여도 과장은 경력 무관 감점**. - **역량 공백은 '없음'이지 '거짓'이 아니다.** 엔진 D 공백은 감점(오류)과 분리해 📉 축으로 보고하고, 신입 눈높이로 심각도를 보정한다. "이력서에 근거 없음 → 확인·보완 대상"이지 "능력 없음"으로 단정하지 않는다. - **감점에 검증법을 붙인다.** 막연히 깎지 말고 각 감점에 "면접에서 어떻게 확인/반증하나"(링크 열기·라이브 설명·근거 질문)를 붙인다. - **GitHub 대조는 코드 리뷰가 목적이 아니다.** "주장과 실제의 일치 + 기본 품질·보안"만 본다. 스타일 트집이 아니라 면접에서 털릴 지점. - **링크 접근:** 공개 레포·블로그만. 인증 필요·403·삭제는 "접근 불가"로. - 개인정보(연락처·주소)는 평가하지 않는다. ## 연결 스킬 | 스킬 | 관계 | |------|------| | `cartesian-doubt` | 이 스킬의 추론 엔진(의심 사다리 + 네 규칙 + evil-demon). 더 깊은 검증 시 참조 | | `hiring-sim-resume-review` | 합격/탈락 스크리닝. 이 스킬과 2단 구성(스크리닝 → 감점 적발) | | `hiring-sim-portfolio-redteam` | 포트폴리오 감점 적발. 이력서+포폴 세트로 | | `hiring-prep-doc-feedback` | 초안 단계 방향 잡기(감점 적발은 완성본 대상) | | `hiring-sim-interview` | 여기서 나온 ▶후속질문을 실제 면접 시뮬레이션 문항으로 |