techeer-sv/career-skills/hiring-sim-resume-redteam

이력서 레드팀 리뷰 (면접관 감점 포인트 적발)

이력서를 가장 비판적인 면접관의 눈으로 읽고, 라이브 면접에서 파고들리거나 감점될 지점만 골라낸다. 합격/탈락 스크리닝이 아니라, "어디서 깎이고 어디서 털리는가"를 포렌식으로 적발하는 레드팀 렌즈다.

핵심: 이력서에 적힌 글·수치·링크를 액면 그대로 믿지 않는다. 포트폴리오는 표·대시보드로 내부 대조가 되지만, 이력서는 글 기반이라 대조할 근거가 이력서 안에 없다. 그래서 밖에서 근거를 끌어온다 — 수치는 규모 추정·리서치로, 첨부된 GitHub 코드·블로그는 직접 읽어 대조한다.

이 리뷰의 독자는 면접관/평가자다 — 남(외부 후보)의 이력서·공개 레포를 본다는 가정. 산출은 "지원자님 이렇게 고치세요"가 아니라 감점 판정 + 면접에서 검증·반증하는 법이다.

언제 쓰나 / 안 쓰나

쓴다: 이력서 제출 전 마지막 검증, "면접관이 뭘 물어볼까"가 궁금할 때, 수치·GitHub·블로그가 붙은 기술 이력서, 내 이력서 허점을 스스로 먼저 찾고 싶을 때. 안 쓴다: 초안 뼈대만 있어 검증할 근거가 없을 때(→ hiring-prep-doc-feedback), 합격 여부만 알고 싶을 때(→ hiring-sim-resume-review), 단순 오탈자 교정.

핵심 엔진 — Cartesian Doubt (방법적 회의)

cartesian-doubt의 의심 사다리와 네 규칙을 이력서용으로 차용한다. 원리: 액면(주장)과 검증된 사실을 분리하고, 하중을 받는 주장만 실제로 대조한다. 회의는 리스크에 비례해서만 올린다(사소한 걸 다 의심하는 건 분석 마비이지 엄밀함이 아니다).

의심의 사다리

네 규칙 → [검증됨 / 모순 / 가정 / 불명] 라벨

각 핵심 주장에 라벨을 붙이고 검증됨만 강점으로 인정한다. ① 증거(명석·판명하지 않으면 사실로 안 받음) ② 분석(항목→주장→수치로 쪼갬) ③ 순서(확실한 것부터) ④ 열거(모든 항목·모든 링크 커버, 못 본 것은 "미확인").

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 <repo> /tmp/rt-<name> — 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로 저장.

감점 유형 카탈로그

9번은 "틀린 것"이 아니라 "손해 보는 것". 감점과 별개 축으로, 각 밋밋한 항목은 면접관이 문제→해결(기술 판단)→정량 성과 중 빈 곳을 심화 질문으로 캐서 변별하는 지점이다(답하면 강점, 못 하면 레시피 수준). 근거는 실제 한 것만.

10번도 "틀린 것"이 아니라 "경쟁에서 밀리는 것" — 감점과 별개 축(📉)으로 빼서, 없는 역량·얕은 깊이를 신입 눈높이로 보정해 보고한다.

심각도 기준

🔴 High  — 신뢰도를 직접 훼손. 라이브 면접에서 거의 확실히 걸리고, 답 못하면 치명적.
           (수치 비현실 · 코드–주장 불일치 · 심각한 취약점 · 기여도 과장 · 명백한 과장)
🟠 Med   — 논리·용어·인과가 헐거움. 파고들면 흔들리는 것.
🟡 Low   — 문구·표기·형평. 꼼꼼한 면접관만 보는 것.

출력 포맷

# 이력서 레드팀 리뷰 — 면접관 감점 포인트
 
## 총평
[2~3문장. 이력서의 강점 컨셉과, 그 컨셉을 스스로 배신하는 가장 큰 감점 축 1~2개.]
 
## 심각도 요약
🔴 High N · 🟠 Med N · 🟡 Low N · [밋밋] N · [역량공백] N
검증 커버리지: 항목 N · GitHub 링크 M/M · 블로그 링크 M/M · 규모 리서치 [수행/불가]
 
## 감점·오류 (심각도 순)
-🔴 **<한 줄 제목>** — 위치: <이력서 항목> · 엔진: <A/B/C>
  -문제: <근거 인용 — 리서치 결과 / 코드 파일·라인 / 블로그 원문 vs 이력서 주장>
  -라벨: [검증됨 / 모순 / 가정 / 의심 / 불명]
  -감점 이유(면접관): ▶ "<최악의 후속질문>"
  -면접 검증: <이 주장을 세션에서 확인·반증하는 법 — 링크 열게 하기·라이브 설명/데모 요청·diff 대조>
[반복 · 심각도 높은 순]
 
## 🎣 밋밋해서 손해 보는 지점 (면접관이 물어볼 심화 = 후보 변별점)
-**<항목>** — 빈 곳: <문제 맥락 / 기술 판단 근거 / 정량 성과 중 없는 것>
  -▶ 심화 질문: "<이걸 물으면 시니어 감각 vs 레시피 수준이 갈리는 질문>"
 
## 📉 포지션 시장 기대 역량 공백 (직군 기준 · 거짓 아님 = 경쟁 약점)
-🟠/🟡 **<역량>** — [공백/부분] · 직군: <백엔드 등>
  -시장 기대: <왜 대부분 공고가 이걸 원하나>
  -이력서 현황: <없음 / 성과만 있고 과정 없음 등>
  -▶ 확인 질문: "<이걸 물으면 실체가 드러나는 질문>" · 보완: <신입 눈높이에서 이력서를 어떻게 강화하나>
 
## 면접 검증 우선순위 (이 후보를 만나면)
1.[실체가 갈리는 검증부터 — 링크 열기·수치 근거·개념 깊이 순]

주의사항 (반드시 지킨다)

• 날조 금지. 모순은 근거를 인용할 수 있을 때만 보고한다(리서치 결과 · 코드 파일/라인 · 블로그 원문). 근거 없이 "이상하다"고 쓰지 않는다.
• 불명은 불명으로. 접근 불가 링크·미확인 규모는 "미확인"으로 표기하고 부정적으로 추측하지 않는다(사설 레포를 "구현 안 했을 것"이라 단정 금지).
• 회의는 리스크에 비례. 대표 셀링 포인트·핵심 수치에 화력을 집중한다(scalpel, not lifestyle).
• 경력 눈높이. 신입/주니어에게 시니어 설계를 요구하지 않는다. 단 과장·수치 비현실·코드–주장 불일치·기여도 과장은 경력 무관 감점.
• 역량 공백은 '없음'이지 '거짓'이 아니다. 엔진 D 공백은 감점(오류)과 분리해 📉 축으로 보고하고, 신입 눈높이로 심각도를 보정한다. "이력서에 근거 없음 → 확인·보완 대상"이지 "능력 없음"으로 단정하지 않는다.
• 감점에 검증법을 붙인다. 막연히 깎지 말고 각 감점에 "면접에서 어떻게 확인/반증하나"(링크 열기·라이브 설명·근거 질문)를 붙인다.
• GitHub 대조는 코드 리뷰가 목적이 아니다. "주장과 실제의 일치 + 기본 품질·보안"만 본다. 스타일 트집이 아니라 면접에서 털릴 지점.
• 링크 접근: 공개 레포·블로그만. 인증 필요·403·삭제는 "접근 불가"로.
• 개인정보(연락처·주소)는 평가하지 않는다.

연결 스킬