AI가 쓴 이력서가 3초 만에 들키는 이유 — Planner·Generator·Evaluator 하네스

AI가 쓴 이력서가 3초 만에 들키는 이유 — Planner,Generator,Evaluator 하네스

1. 훅 & TL;DR

채용 담당자의 첫 스크린 타임은 3초다. 이 3초 동안 무엇이 걸러지는가. 최근 한 채용 담당자의 이력서 분류 로그를 들여다보면, 걸러내는 기준이 내용의 우열이 아니라 LLM 특유의 기계적 패턴에 몰려 있다. “열정적인”, “성공적으로”, “효율 37% 향상”이 첫 문단에 등장하는 이력서는 본문을 읽지 않고 다음 장으로 넘어가는 경우가 관찰된다.

이 글은 그 기계적 패턴을 AI Slop 7증상으로 진단하고, Anthropic이 공개한 하네스 설계 방법론(Prithvi Rajasekaran, “Harness Design for Long-Running Application Development”, 2026-03-24, 원문 링크)을 이력서 도메인에 이식한 오픈 소스 스킬 resume-consultant-harness의 설계 원리를 공유한다.

핵심 주장은 다음 한 문장이다. 이 스킬의 핵심 혁신은 Evaluator를 2번 돌리는 것이 아니라, 두 번째 Evaluator가 첫 번째의 critique.md를 읽지 않는다는 구조적 제약에 있다. 자기평가 편향은 단일 에이전트의 문제가 아니라, 이전 판정을 읽은 후속 평가자에게도 감염된다. S7.5는 ‘판정 감염 차단’을 파일 접근 규칙으로 인코딩한 드문 사례이다.


2. 배경: AI 이력서가 3초 만에 걸리는 이유 (AI Slop 7증상)

LLM이 생성한 이력서는 특정한 표층 패턴을 공유한다. 이 패턴은 미적 취향의 문제가 아니라 검증 가능한 기계적 지표다. 아래 7가지는 필자가 하네스 설계 과정에서 실제로 grep·정규식·빈도 분석으로 검출 가능하도록 정의한 목록이다.

  1. 금지어 과다 — 추상 형용사가 구체 사실을 대체한다. KO 예: 열정적인, 적극적인, 다양한, 풍부한, 뛰어난, 강력한, 혁신적인, 전략적인, 성공적으로, 효과적으로, 비즈니스 임팩트, 시너지, 소중한 경험. EN 예: passionate, results-driven, detail-oriented, team player, proven track record, extensive experience, seamless, synergy, leverage, spearhead.
  2. 트라이콜론 남용 — “A하고, B하며, C한” 구조가 문단마다 반복된다. 리듬이 균일해지고 고유성이 소실된다.
  3. LLM 전환어 과다또한, 나아가, 이를 통해 / Furthermore, Moreover, Thus가 bullet마다 등장한다.
  4. em-dash(—) 과용 — 영문 스타일 가이드가 한국어 문장에 과다 이식되어 한 bullet에 두 번 이상 끼어든다.
  5. 허위 정밀도효율 37% 향상, 성능 50% 개선 같은 숫자가 원본 자료·로그·PR 링크 없이 단독으로 제시된다.
  6. 자화자찬 랩업 — “본 프로젝트를 통해 성장할 수 있었습니다”, “소중한 경험” 같은 정서적 마무리가 모든 경력에 붙는다.
  7. 치환 가능성 — 문장에서 회사명을 다른 회사로 바꿔도 그대로 의미가 성립한다. 고유명사·수치·구체 동사가 없어 누구의 이력서인지 특정되지 않는다.

병기 실례 4건은 다음과 같다.

  • (1) “열정적인 백엔드 엔지니어 — a passionate backend engineer
  • (2) “성공적으로 프로젝트를 리드하여 — successfully led the project
  • (3) “효율 37% 향상 (출처 없음) — 37% efficiency improvement (no source)
  • (4) “본 프로젝트를 통해 성장할 수 있는 소중한 경험 — a precious experience that allowed me to grow

각 증상은 관찰 가능한 지표와 차단 지점을 가진다.

증상관찰 가능한 지표차단 지점
1. 금지어 과다KO/EN 금지어 grep hit 수S7 Probe 2 (hit ≤3), S7.5 재검증
2. 트라이콜론 남용“A하고 B하며 C한” 정규식 빈도S7 Probe 3, 단락당 1회 이하
3. LLM 전환어 과다또한·나아가·Furthermore 밀도S7.5 Probe 4 (≤0.3/bullet)
4. em-dash 과용bullet별 등장 횟수Style Rule 본문 조항
5. 허위 정밀도수치에 L번호·URL 부재S7.5 Probe 6 (출처 없는 수치 0건)
6. 자화자찬 랩업정서 어미 감지S7.5 Probe 7 (감성 마무리 0건)
7. 치환 가능성회사명 치환 후 의미 보존율S7.5 Probe 1 (YES 비율 ≤10%)

3. 근본 원인: 자기평가 편향 (Self-evaluation Bias)

7증상을 나열하는 것만으로는 재현적 해결이 어렵다. 표층 패턴 뒤에는 구조적 원인이 있다. Anthropic 원문은 코딩 도메인에서도 Generator가 자기 결과물을 과대평가한다는 점을 지적하며, 이를 “weight 2× where the model is weakest by default”로 대응한다고 밝힌다. 동일 세션 내에서 작성자와 평가자가 같으면, 모델은 “looks fine” 이라는 기본값으로 기울어 slop을 걸러내지 못한다.

코드 도메인은 그나마 컴파일러와 테스트 스위트가 최종 방어선 역할을 한다. 빌드가 깨지면 아무리 자기 설득이 강해도 결과가 거짓말을 할 수 없다. 반면 이력서 도메인에는 컴파일러가 없다. 실행 가능한 단위 테스트도 없다. 오로지 자연어 판단만 있다. 따라서 “이 정도면 괜찮아 보인다”는 LLM의 기본값 편향이 그대로 최종 산출물이 된다.

이 구조는 더 큰 모델을 쓴다고 해결되지 않는다. 모델 크기가 커지면 문장이 더 유려해질 뿐, 자기 결과물에 관대한 기본값 자체는 같은 세션 안에 머문다. 해법은 세션 분리와 정보 격벽에 있다. 작성자는 자기 작성물을 채점하지 않고, 평가자는 작성자의 추론 과정을 보지 않는다. 각 역할은 오직 파일을 통해서만 통신한다. 이것이 Anthropic 하네스 설계의 핵심 전제다.


4. 해법: Planner → Generator → Evaluator 3-역할 분리

Anthropic 원문의 원리는 6개 키워드로 요약된다. 역할 분리 / 파일 기반 핸드오프 / 스프린트 계약 / 루브릭 평가 / 컨텍스트 리셋 / 자기평가 편향 방지. 이 중 단 하나도 이력서 도메인에서 생략할 수 없다.

역할입력출력금기 사항
Planner사용자 요청, 기업명, JD, 원본 이력서spec.md (의도·필수 포함·루브릭)직접 이력서 작성 금지
Generatorspec.md, 스프린트 입력 파일스프린트별 산출물, generator_report.md자기 채점 금지
Evaluatorspec.md, 산출물, 원본 이력서critique.md (PASS/FAIL + 증거)재작성·리팩터링 금지

세 역할은 대화·내부 추론·스크래치패드를 절대 공유하지 않는다. 통신은 오직 다음 5개 파일로만 이루어진다. spec.md, sprint_contract.md, generator_report.md, critique.md, handoff.md. 이 규칙은 구현 편의가 아니라 설계의 뼈대다. 각 파일은 “무엇을 넘기고 무엇을 넘기지 않는가”의 명시적 계약이며, 계약에 없는 정보는 구조적으로 흐르지 않는다.

컨텍스트 리셋도 같은 원칙의 연장이다. 스프린트가 넘어갈 때 기존 세션의 컨텍스트를 컴팩션(compaction)으로 줄이는 대신, 새 서브에이전트 세션을 디스패치한다. Anthropic 원문은 컴팩션이 “판단 기억(judgment memory)을 열화시킨다”고 지적한다. 요약은 판정 근거를 흐리고, 흐린 근거는 다음 판정에 편향을 남긴다. 하네스는 이 열화 경로를 세션 분리로 차단한다.

Visual 1은 이 전체 흐름을 한 장으로 정리한다. Planner가 spec을 작성하면, Sprint Loop(S1–S7) 내부에서 Generator와 Evaluator가 sprint_contract.md·critique.md를 주고받는다. S2·S5는 사용자 확인 게이트가 붙어 자동 진행이 막힌다. S7이 PASS를 내도 자동 완료는 금지된다 — 흐름은 반드시 S7.5로 이어진다.

Visual 1 — 전체 하네스 흐름: Planner가 spec.md를 작성하고, Sprint Loop(S1–S7)를 거쳐 S7.5를 통과해야만 final_resume.md가 생성된다
Planner → Sprint Loop(S1–S7) → S7.5 → 최종 이력서. S2·S5는 사용자 확인 게이트, S7→S7.5는 자동 통과 금지.

5. 이력서 도메인 이식: 7개 스프린트 + S7.5 최종 게이트

추상 원리는 스프린트 구조로 내려와야 검증 가능해진다. resume-consultant-harness는 하나의 지원 건을 7개 스프린트로 분할한다. 각 스프린트는 독립 입력·산출물·다음 스프린트에 넘기는 파일을 가진다.

  • S1 기업 리서치 — 산출물 {기업}_기업리서치_리포트.md. 공개 정보·기업 IR·제품 페이지 기반 사실 정리.
  • S2 기업 리뷰·평판 — 전·현직자 리뷰·뉴스·이슈 집계. Evaluator가 “비권장” 판정을 내리면 사용자 확인 게이트가 닫힌다. 자동 진행이 금지되며 사용자가 명시적으로 계속 지시해야 S3으로 넘어간다.
  • S3 포지션 분석 — JD를 요건·우대·컬처 fit 셋으로 분해해 요건 매트릭스를 만든다.
  • S4 기존 이력서 분석 — 원본 이력서의 모든 bullet에 L번호(라인 포인터)를 부여한다. 이후 S7·S7.5에서 사실 검증의 기준점이 된다.
  • S5 적합성 진단 — JD 요건 × 원본 bullet의 매칭 맵. “부적합” 판정 시 사용자 확인 게이트가 닫힌다. 억지 맞춤은 데이터 조작으로 귀결되므로 게이트로 차단된다.
  • S6 채용 채널 추천 — 직접 지원·리퍼럴·헤드헌터 중 사용자가 채널을 선택한다. 채널별 톤과 포맷이 달라지므로 S7 입력에 반영된다.
  • S7 맞춤 이력서 작성 — 산출물 draft.md, generator_report.md. 이 단계에서 루브릭 Evaluator가 돌고, PASS/FAIL과 증거 기반 critique.md가 생성된다.
  • S7.5 최종 AI Slop Sweep — 스킬의 핵심 혁신. 다음 섹션에서 상세히 다룬다.

스프린트 계약(Sprint Contract)의 형식은 다음 의사 코드에 가깝다. S7을 예로 든다.

sprint: S7
inputs:
  - "{기업}_기업리서치_리포트.md"
  - JD
  - 원본 이력서
  - 포지션_분석.md
constraints:
  - "Bullet 3요소 원칙 — 고유명사 + 수치/증거 포인터(L번호) + 구체 동사"
outputs:
  - draft.md
  - generator_report.md
next: S7.5

각 스프린트 Evaluator는 해당 계약을 원문 그대로 입력으로 받는다. 계약 외 항목은 채점하지 않으며, 계약에 없는 품질 신호(예: “왠지 좋아 보인다”)는 판정 근거로 인정되지 않는다. 이 규칙이 자기평가 편향의 첫 번째 방어선이다. 두 번째 방어선이 S7.5다.


6. 차별점 1: Bullet 3요소 원칙 (Zero AI Slop 정책)

“AI slop을 쓰지 말라”는 지침은 흔하다. 문제는 구호로는 검증되지 않는다는 점이다. 이 스킬은 AI slop 금지를 기계 검증 가능한 규칙 세 개로 환원한다.

  1. 고유명사 — 회사·제품·기술·라이브러리·지표명. 예: Rails, Go, p95, L45.
  2. 수치 또는 증거 포인터 — L번호(원본 이력서 라인 포인터), 기간, 규모, 트래픽, 레이턴시, 전환율. 출처가 없는 수치는 허위 정밀도로 간주되어 탈락한다.
  3. 구체 동사전환했다, 배포했다, 제거했다, 롤백했다, 이관했다. 기여하였다, 리드했다 같은 추상 동사는 단독 사용 시 AI slop으로 판정된다.

세 요소가 모두 충족될 때에만 bullet은 “치환 불가능성 테스트”를 통과한다. 즉 회사명을 다른 회사로 바꿨을 때 문장이 더 이상 성립하지 않아야 한다. Visual 3은 이 과정을 한 장으로 보여준다.

Visual 3 — AI Slop 문구가 치환 불가능성 테스트 필터를 거쳐 고유명사 + 수치 + 구체 동사 3요소를 충족하는 bullet로 대체되는 흐름
AI Slop 문구는 치환 가능성 테스트를 통과하지 못한다. 3요소 원칙은 그 문장을 고유하게 만든다.

실제 대체 예시 2건은 다음과 같다.

  • Before (AI slop): “열정적인 백엔드 엔지니어” → After (3요소 충족): “11년차 B2B SaaS, Rails→Go 전환 완료”
  • Before (AI slop): “성공적으로 프로젝트 리드” → After (3요소 충족): “팀 4명, 6개월, p95 API 480ms→180ms (원본 이력서 L45)”

두 After 문장은 회사명을 바꿔 넣는 순간 의미가 무너진다. 이 무너짐이 곧 고유성의 증거다.


7. 차별점 2: S7.5 최종 AI Slop Sweep — 판정 감염 차단

S7에서 Evaluator가 PASS를 주어도 완료 선언은 금지된다. 이 제약이 이 스킬의 가장 독특한 설계다. S7의 PASS는 루브릭 기준 합격이지만, 합격 자체가 새로운 편향을 만든다. 같은 대화 맥락에서 루브릭이 통과되었다는 사실은 후속 판정자가 무의식적으로 “이미 통과된 글”로 간주하게 만든다. 자기평가 편향은 단일 에이전트의 문제가 아니다. 이전 판정을 읽은 후속 평가자에게도 감염된다.

resume-consultant-harness는 이 감염 경로를 파일 접근 규칙으로 인코딩한다. S7.5 Evaluator는 완전히 새로운 Agent 세션으로 디스패치되며, 입력으로 draft.md와 원본 이력서만 받는다. critique.md는 같은 폴더에 존재하지만 세션 컨텍스트에 주입되지 않는다. Visual 2가 이 구조를 시각화한다.

Visual 2 — S7 Evaluator가 생성한 critique.md를 S7.5 Evaluator가 읽지 않는 판정 감염 차단 구조. S7.5 입력은 draft.md와 원본 이력서로만 한정된다
S7.5 Evaluator는 critique.md를 읽지 않는다 — 판정 감염(judgment contamination) 차단을 파일 접근 규칙으로 인코딩.

S7.5가 수행하는 검사는 10개 프로브와 1건의 fabrication 재감사로 구성된다.

  1. 치환 테스트 — 회사명을 다른 회사로 바꾸었을 때 문장이 그대로 성립하는 bullet 비율. YES ≤10%.
  2. 금지어 grep — KO/EN 금지어 총 hit 수. ≤3.
  3. 트라이콜론 / 오프닝 동사 분포 — “A하고 B하며 C한” 패턴 빈도와 동사 다양성.
  4. LLM 전환어 밀도또한, 나아가, 이를 통해, Furthermore, Moreover 등. ≤0.3/bullet.
  5. 3요소 충족 bullet 비율 — 고유명사 + 수치/증거 + 구체 동사 셋 모두 충족. ≥80%.
  6. 출처 없는 수치 — 원본 근거가 없는 정량 주장. 0건.
  7. 감성 마무리 — “소중한 경험”, “성장할 수 있었습니다” 등. 0건.
  8. Headline 치환 불가 여부 — 이력서 제목·요약이 회사명 치환 후에도 성립하면 FAIL.
  9. 오프닝 동사 집중도 — 같은 동사로 시작하는 bullet 비율. ≤30%.
  10. 고유명사 밀도 — 전체 토큰 중 고유명사 비율. ≥5%.

11. Fabrication 재감사 (추가 1건) — 본문의 모든 수치·고유명사를 원본 이력서의 L번호와 대조한다. 매칭되지 않는 주장은 조작으로 판정한다. 10개 프로브와 병렬로 반드시 실행된다.

임계가 S7보다 엄격한 이유는 판정 감염을 이겨내기 위해서다. 같은 루브릭을 같은 임계로 돌리면 통과 편향이 그대로 재생산된다. S7.5는 세 지표를 수치로 강화한다.

지표S7 임계S7.5 임계
치환 가능 YES 비율20%10%
3요소 충족 bullet 비율70%80%
LLM 전환어 밀도0.5/bullet0.3/bullet

판정 규칙은 단순하다. 10개 프로브 + Fabrication 재감사 중 하나라도 미달이면 FAIL이다. 가중 평균·종합 판단·재량은 없다. 판정의 불연속성이 감염 전파를 물리적으로 끊어낸다. FAIL 시 Generator는 critique.md(S7.5가 새로 생성한 판정)를 근거로 재작성한다. 재작성 상한은 최대 3회이며, 3회 초과 시 사용자에게 에스컬레이션되어 하네스가 스스로 수리하려는 무한 루프를 차단한다.


8. 평가 가중치·티어·사용법·결론

루브릭은 네 축으로 구성되며, 약점 축에 2배 가중치를 준다. Anthropic 원문의 문구 “weight 2× where the model is weakest by default”를 이력서 도메인으로 직역한 결과다.

  • Honesty & Evidence (×2) — 조작·라벨 없는 주장·허위 정밀도 검출.
  • Originality & Insight (×2) — 보일러플레이트 통과 차단.
  • JD-Fit (×1) — 포지션 요건과의 매칭.
  • Craft (×1) — 문장력·구조·가독성.

티어는 3단계로 제공한다. 어떤 티어를 선택하든 S7.5는 예외 없이 필수다.

티어구성권장 모델
Full (V1)스프린트별 컨트랙트 + 스프린트별 EvaluatorSonnet 4.5
Simplified (V2)단일 Generator 세션 + 최종 Evaluator 1회Opus 4.5/4.6 (원문 준수)
Single-session같은 세션이 전 역할 연기 + 가혹 자기 채점사용자 선택

Single-session 티어에서도 S7.5는 반드시 독립 Agent 호출로 분리 실행된다. 이 분리가 티어 전체에 공통된 비협상 조항이다.

사용법은 4단계다.

  1. resume-consultant-harness 스킬을 설치한다.
  2. 기업명·JD 전문·원본 이력서를 Claude Code 세션에 제공한다.
  3. Planner가 spec.md를 작성하고, Sprint Loop(S1–S7)와 S7.5가 순차 실행된다.
  4. 산출물 final_resume.md를 수령한다.

스킬 문서 기준으로, SKILL.md 비협상 원칙 #7은 다음과 같이 기술되어 있다. “AI Slop 제로: 고유명사·수치·구체 동사 3요소를 충족하지 않는 bullet은 산출물에 포함될 수 없다. 본 조항은 모든 티어에서 비협상이며, S7.5 게이트의 근거 규범이다.” 자기평가 편향은 “더 좋은 모델”로 해결되지 않는다. 파일 접근 규칙으로 인코딩한 독립성이 해법이다. 3초 스크린에서 살아남는 이력서는 감각이 아니라 구조의 산물이다.

방법론 원문: Prithvi Rajasekaran, “Harness Design for Long-Running Application Development”, Anthropic Engineering, 2026-03-24, https://www.anthropic.com/engineering/harness-design-long-running-apps.
스킬 저장소: https://github.com/greeun/resume-consultant-harness.

댓글 달기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

위로 스크롤