resume-writer

name	resume-writer
description	한국 IT 백엔드 시니어 이력서 작성·갱신 스킬. 회사·직무 맞춤 이력서를 task/ 폴더의 실제 구현 기록 기반으로 작성하며 PR 톤·내부 명칭 노출·본인 비기여 어필 같은 누적 함정을 피해 면접관 5초 인상에 통과하는 카드를 만든다. 사용자가 "이력서 작성", "이력서 갱신", "이력서 다듬어줘", "OO 회사 이력서", "resume", "Summary 손봐줘", "카드 정리", "이 bullet 빼자" 같이 요청하면 무조건 호출한다. 단순 1회성 문장 다듬기 외에 카드 단위 변경·재구성·검증이 들어가는 모든 이력서 작업에 적용.

이력서 작성 스킬

The Insight

좋은 이력서는 면접관 컨텍스트 안에서 읽힌다. 작성자에게 익숙한 코드명·내부 약어·구조 설명이 면접관에게는 노이즈다.

이력서는 사용자 본인이 평소 쓰는 담백한 톤이 가장 검증된 자산이다. AI가 task 문서를 풀어내려는 욕심이 함정을 누적시킨다. 기존 이력서를 base 로 잡고 공고 매칭만 얹는 방향이 거의 항상 맞다.

작성 원칙 — 3대 함정 회피 + 5초 인상 두 축

작성 과정에서 매번 깨지는 함정은 다음 셋이다:

1. PR 톤 — "직접 / 주도 / 단독 / 본인" 같은 자기 강조 표현이 자랑 톤으로 읽힘
2. 내부 명칭 노출 — 코드명, ADR 번호, 슬래시 명령, 라이브러리 함수명이 컨텍스트 없이 등장
3. 본인 비기여 어필 — 팀 작업이나 기존 자산을 본인 기여로 풀어 써 면접에서 자폭

각 카드는 동시에 면접관 5초 인상의 두 축을 통과해야 한다:

1. 이해 가능성 — 지원 회사의 도메인을 모르는 면접관도 5초 안에 "무엇을 한 작업인지" 그림이 그려지는가? 도메인 친숙 독자에게만 친절한 부연·약어·전제 표현은 노이즈다.
2. 적용 가능성 (transferability) — 면접관이 "우리 팀 와서 이런 것도 바로 적용해서 잘 하겠구나" 가 자연스럽게 떠오르는가? 그 경험이 지원 회사의 어떤 문제에 옮겨질 수 있는가 가 (명시 안 해도) 머리에 그려져야 한다.

두 축이 함께 작동해야 한다. 이해 가능성만 좋으면 "잘 정리된 이력서" 에 머무르고, 적용 가능성만 강조하면 "공고 따라쓴 느낌" 으로 신뢰를 잃는다.

토스 이력서 가이드 핵심

• 폭넓은 프로젝트 ❌, 구체적으로 만든 기능과 해결한 문제 ✓
• 기술 선택 이유, 대안 비교, 트레이드오프
• 본인이 직접 측정·검증한 수치만 사용
• "왜 이 기술이어야만 했나"

Recognition Pattern

다음 상황에서 호출:

• 특정 회사/직무 맞춤 이력서 작성·갱신
• 회사별 강조 포인트 변경 (카드 추가/제거/다듬기)
• Summary·자기소개 단락 작성·재작성
• 이미 분석 문서(interview/)가 있으면 그것 활용

---

빈출 함정과 회피 룰 (반드시 숙지)

함정은 4개 카테고리로 묶인다. 매 카드를 만들기 전·후로 점검한다.

A. 톤 — 자기 강조 / AI 티

함정 1 — PR 톤 어휘

금지 어휘 리스트:

금지	대체
직접 구현 / 직접 만들어 / 직접 설계	"구현", "맡아 진행", 또는 그냥 동사형
단독 구현	"1인 구현" 도 약함. 그냥 "구현"
주도 / 도입을 주도	"도입", "맡아", "진행"
본인 주도 + 팀 전파	"팀에 전파해 후속 X가 동일 구조 위에 얹히도록 정리"
본인 작성·유지 N개	"N개 추가" 또는 "N개 작성·유지" (본인 강조 빼기)
한 호흡에 / 깊이 있게	추상 자랑 톤. 빼거나 사실로

자가 점검 grep:

grep -nE "직접|단독|주도|본인 주도|본인 작성|본인이 [가-힣]+(을|를) (구축|도입|설계|구현|주도)" <file>

매치 0건이 목표. 메타 인용(스킬 룰 자체 설명)은 예외. 더 많은 변환 표는 references/tone-conversion.md 참조.

함정 2 — AI 티 표현

매끄러워 보이지만 면접관에겐 AI 티 나는 추상 표현:

• "한 축의 커리어로 이어져 왔고" → 빼거나 사실 진술로
• "상태가 시간에 따라 변하는 도메인을 다중 서버에서 일관되게 유지" → 너무 학술적
• "자연스럽게 매핑된다고 봅니다" → 추상. 구체 어휘로
• "두 경험을 발판으로" → 자연스러우나 자주 쓰면 AI 톤
• "본질적으로 / 결국은 / 즉" 접속사 남발
• "두 팀을 잇는 설계 자산으로 정착" / "작업 결을 보여주는 보조 경험" → 통째 제거

룰: 사용자 본인이 평소 쓰는 톤(기존 이력서)에 없는 표현은 의심. 사용자가 쓸 법한 단어로만 작성.

B. 사실 정확성 — 내부 명칭 / 비기여 / 정량

함정 3 — 내부 명칭 / 코드명 / 메서드명 노출

면접관은 본인 회사 컨텍스트가 없다. 코드명·ADR 번호·슬래시 명령·라이브러리 함수명은 빼거나 일반 표현으로 풀어 쓴다.

원칙: 이력서에 등장하는 코드명은 면접관이 클릭해서 검색해 봐도 의미 통할 만한 것만. 회사 내부 명명 규칙은 거의 항상 빼는 게 안전.

Sub-rule — 메서드명 / API 호출 → 행위 동사로 치환:

면접관이 메서드 시그니처를 모르면 멈춤. 행위(동사) 표현으로 바꾸면 한 호흡에 읽힘.

메서드/API 명 ❌	행위 표현 ✓
refreshAll 도중 NPE	"갱신 중 NPE"
기존 데이터를 clear 한 후	"기존 데이터를 비운 후"
StampedLock writeLock 으로 읽기 차단	"갱신 시 읽기를 차단하는 락"
@ExtendWith 선언만으로 자동 구성	"한 줄 선언만으로 자동 구성"
JUnit Extension 으로 표준화	"JUnit 확장 메커니즘으로 표준화"
tryReadLock 2.5초 타임아웃	(이력서엔 빼고 면접 답변용 보존)

판별 룰: 클래스명·메서드명·어노테이션이 보이면 "이게 면접관 모니터에 그대로 떠도 5초 안에 의미 잡히나?" 자문. No → 행위로 치환. 알고리즘명(Welford Online 등 학술 일반명)은 예외 OK.

상세 변환 표 케이스별: references/tone-conversion.md 참조.

함정 4 — 본인 비기여 어필 (자폭 위험)

검증 라운드를 작성 전에 반드시 진행한다. 사용자 한 줄씩 점검:

• "이 표현 본인이 직접 한 작업인가?"
• "이 패턴 본인이 도입했나, 기존 자산을 절용·확장했나?"
• "이 수치 본인이 측정했나?"

본인 기여 3분법:

• 본인 도입·구축: 명확히 어필 OK
• 기존 패턴 절용·확장: "팀에 자리 잡은 X 패턴을 운영하며 / 적용하면서" 톤. "도입"으로 쓰면 안 됨
• 팀 작업 일부: 어필 빼거나 "팀 활동" 으로 묘사. 본인 카드에 넣지 말 것

자폭 사례 (실제 발생):

• "JMH 마이크로벤치마크로 58배 개선" — 본인 측정 아님. 면접에서 깊이 들어가면 답변 불가
• "AFTER_COMMIT + Dead Letter Store + 스케줄러 재시도" — 메타 플랫폼팀 작업. 본인은 깊이 모름
• "447개 테스트로 커버리지 51%" — 측정 단위 미명시 시 "전체를 본인이?" 오해

룰: 작성자가 "이거 본인 기여 맞나?" 확신 없으면 사용자에게 한 줄씩 묻는다. 추측 금지.

함정 5 — 정량 자폭 (측정 단위 미명시)

수치 옆에 측정 단위가 없으면 면접에서 깊이 들어갈 때 답변 못 함.

자폭 위험 표현	안전한 표현
커버리지 4% → 51% 향상	"447개 테스트 작성·유지로 담당 모듈 커버리지 4% → 51%"
25% 단축	"같은 규모 신규 상품 N종 평균 비교 4주 → 3주"
토큰 75% 절감	"분석 5개 영역 통합 호출 적용으로 토큰 75% 절감"

본인 측정 아닌 수치는 빼는 게 안전.

함정 6 — "정량 자랑" vs "임팩트 본질"

수치가 있다고 무조건 어필 강하지 않다. 의사결정 난이도와 결과의 본질을 구분해야 한다.

약한 정량 어필 ❌	강한 임팩트 본질 ✓
"토큰 75% 절감 — 5번 호출을 1번 호출로 통합"	알고리즘·아키텍처 의사결정의 정량 결과
"60컷 일괄 생성 구조 개편 — 부분 실패 처리 단순화"	분산 시스템 일관성 / 동시성 의사결정 결과
단발성 PoC 결과 ("MVP 구현 완료")	운영 단계 진입 / 실제 사용자 가치 (운영 사례 링크)
측정 단위 미명시 정량	"담당 모듈 기준 X% → Y%" / "동일 규모 N건 평균"

룰: 정량을 어필하기 전에 자문 — "이 의사결정이 어려웠는가? 단순 변경이라면 작성자도 면접관도 'so what?' 으로 흘려본다." 어렵지 않은 변경은 본문에서 빼고 운영 사례 / 전 과정 자동화 / 도메인 본질 임팩트 같은 강한 어필로 대체.

실 사례: AI 웹툰 카드에서 "토큰 75% 절감", "60컷 일괄 생성 구조 개편" 두 bullet 제거 → "전 과정 자동화" + "운영 채널 연재 중" 운영 사례로 대체. 정량은 줄었지만 임팩트 본질이 훨씬 강해짐.

C. 카드 구조 — 분량 / 묶기 / 부연

함정 7 — 카드 분량 비대·역전

매번 발생하는 패턴: 메인 카드 8 bullet, 보조 카드 1 bullet → 우선순위 역전.

가이드:

• 메인 카드: 주요 업무 3-5 bullet + 주요 성과 3-5 bullet
• 보조 카드: 1-3 bullet 주요 업무, 주요 성과 생략 가능
• 소속 회사 짧게: 신규 구축이 아니라 운영자 입장이면 1-3 bullet

점검: 모든 카드가 비슷한 분량인지 보고, 공고 매칭 1순위가 가장 큰지 확인. 매칭 약한 카드가 분량 큰 게 가장 흔한 실수.

함정 8 — 한 bullet 에 두 업무 묶기

면접관은 bullet 1개를 한 호흡에 읽는다. "A 적용 및 B 도입" 처럼 접속사로 두 업무를 묶으면 한쪽이 묻히고, 임팩트 강도가 평균값으로 떨어진다.

금지 패턴:

• "X 적용 및 Y 도입"
• "A 구축 + B 운영"
• "C 설계 + D 개선"

룰: 한 bullet = 한 업무. 두 업무를 같이 보여주고 싶다면 bullet 을 2개로 분리한다. 분리했을 때 한쪽이 약해 보이면 그건 원래 약한 업무 — 빼야 한다는 신호.

실 사례: AI 웹툰 카드의 "도메인·트랜잭션 경계를 분리한 3계층 아키텍처 적용 및 요청·프로젝트 단위 로그 추적 기반 운영 관찰성 도입" → 두 업무 묶임 + 둘 다 어필 강도 약함 → 통째로 제거.

함정 9 — 도메인 지식 의존 표현·부연

면접관이 본인 회사 도메인 (슬롯 메커닉, 베팅 체결, 웹툰 제작 단계 등) 에 익숙하다는 전제로 부연을 달면, 도메인 지식이 없는 면접관에겐 노이즈가 된다. 함정 3 (코드명 노출) 와 다른 점: 코드명이 아니라 자연어 부연이라 알아채기 어렵다.

판별 질문:

• 이 부연을 지원 회사 도메인을 모르는 사람이 읽었을 때, 앞 문장이 더 이해되는가? 아니면 새 정보 부담만 늘어나는가?
• 앞 헤드 키워드만으로 핵심이 이미 전달되는가?

금지 패턴:

• 헤드 키워드가 충분히 설명적인데 도메인 단계·내부 분류로 길게 부연
• 슬롯 메커닉 / 베팅 상품 분류 / 웹툰 제작 공정 같은 도메인 종속 분류를 원래 그대로 노출
• 면접관이 "이게 뭐지?" 멈춰서 추측해야 하는 부연

룰: 부연을 추가하기 전 자문 — "앞 표현만으로 핵심이 전달되는가? 그렇다면 부연은 빼는 게 낫다."

실 사례: AI 웹툰 카드 "(작품 기획 → 캐릭터/배경 → 각색 → 글콘티 → 이미지 컷 → 말풍선 편집 6단계)" → 앞 헤드 ("캐릭터·배경·이미지 컷·말풍선 제작까지 전 과정 자동화") 만으로 이미 충분 → 부연 통째 제거.

D. 메타 — 욕심 통제

함정 10 — Task 폴더 풀어내기 욕심

가장 누적되는 함정. task 문서가 풍부해서 모든 ADR·구조·인사이트를 이력서에 옮기려 함. 결과: 면접관 친화 톤 깨짐, 분량 비대, 코드명 노출.

룰: task 폴더는 면접 답변 준비 자료. 이력서엔 2-3개 핵심 어필 포인트만. 나머지는 본인이 머리에 두고 면접에서 답변.

---

반드시 보존할 좋은 패턴

패턴 1 — 회사 → 팀 → 프로젝트 3단계 구조

[Company]
  [Team — team-desc 한 문단]
    [Project — 주요 업무 / 주요 성과 / 사용한 기술]
    [Project — ...]

team-desc 는 "이 팀이 무엇을 하는지" 한 문단으로 제3자 시각에서 풀어 쓴다. 면접관이 "이 사람이 어떤 환경에서 일했나" 를 5초에 잡을 수 있게.

패턴 2 — "주요 업무 / 주요 성과 / 사용한 기술" 3블록

원티드·넥슨 등 한국 이력서 표준 포맷. 면접관 스캔 효율 가장 좋음.

<div class="block-label">주요 업무</div>
<ul>...</ul>

<div class="block-label">주요 성과</div>
<ul>...</ul>

<div class="tech-line"><span class="label">사용한 기술:</span> ...</div>

패턴 3 — 트러블슈팅 4블록 (문제 / 원인 / 해결 + 검증 / 결과)

면접관이 "어떻게 모니터링?", "어떻게 검증?" 같은 후속 질문이 자연스럽게 떠오르도록 흐름 설계.

[문제]    어떤 현상이 발생했고 어떻게 인지했는가
[원인]    어떻게 분석해 어떤 구조로 식별했는가
[해결]    어떤 계획을 세우고 어떻게 검증했는가
[결과]    무엇이 달라졌고 재발 방지는 어떻게 했는가

배치 — 메인 카드 내부 sub-section 권장:

별도 project 카드로 분리하면 카드가 비대해지고 면접관이 "별개 작업?" 오해 가능. 같은 팀·기간에 발생한 트러블슈팅은 메인 카드 안에 <div class="block-label">트러블슈팅 — X 해결</div> 로 sub-section 추가.

같은 컨텍스트의 여러 트러블슈팅은 sub-section 을 누적 (예: "트러블슈팅 — 다중 서버 캐시 NPE", "트러블슈팅 — 시뮬레이터 OOM" 두 sub-section 한 카드 안). 면접관이 "이 한 팀에서 다음 두 장애를 해결했구나" 한 호흡에 인지.

별도 카드 분리는 트러블슈팅이 그 자체로 큰 프로젝트 (예: 1년 이상 운영 안정화 TF) 일 때만.

해결 라인은 문제와 직접 인과 있는 작업만:

해결 라인에 "이 trouble 해결과 무관한 본인 기여" 를 끼워 넣으면 어필 흐림. 트러블슈팅 4블록의 해결은 이 문제를 풀기 위해 한 것 으로 좁힘. 다른 좋은 작업은 주요 성과로 따로 빼기.

실 사례: NPE 트러블슈팅의 해결에 "캐시 데이터 인터페이스 추상화" 가 있었는데 → 그건 별개 리팩터링이라 NPE 와 직접 인과 없음 → 빼고 락 도입만 남김.

패턴 4 — 헤드 키워드 + 짧은 설명

긴 줄글 bullet ❌ → 굵은 헤드 키워드 — 짧은 설명 패턴 ✓.

- **다중 서버 캐시 정합성** — 트랜잭션 커밋 후 메시지 브로커로 변경
  전파, 캐시 데이터 인터페이스 추상화, 갱신 중 일관성 보장 락 추가

면접관이 헤드 키워드만 스캔하면 5초 안에 카드 핵심 다 잡힘.

패턴 5 — 운영 사례 강조 블록

가장 강한 어필 포인트. "MVP에서 끝나지 않고 실제 운영 중인 결과물" 은 면접관에게 신뢰성 끝판왕.

<div class="block-label">운영 사례</div>
<ul>
  <li>본 도구로 제작된 X가 [@channel](URL)에서 실제 연재 중</li>
</ul>

본인이 운영자 아니어도 "본 도구로 만든 결과물" 사실 진술로 충분.

패턴 8 — Nested sub-bullet 으로 기간 임팩트 가시화

장기 작업 (예: "1년 점진 리팩터링") 의 결과물이 여러 개일 때, top-level bullet 여러 개로 나열하면 "이게 다 같은 작업인가?" 인식 어려움. 부모 헤드 bullet + 하위 sub-bullet 들 구조로 묶으면 "이 기간 동안 무엇을 했는가" 한 눈에 보임.

<li>슬롯 엔진 1년 점진 리팩터링 — 팀에 전파해 후속 슬롯이 동일 구조 위에 얹히도록 정리
  <ul style="list-style:none; padding-left:14px; margin-top:2px;">
    <li>단일 템플릿 + 핸들러 패턴 — ...</li>
    <li>윈 로직 데코레이터 체인 — ...</li>
    <li>테스트 환경 표준화 — ...</li>
    <li>생산성 개선 — 6주 → 4주 단축</li>
  </ul>
</li>

적용 기준:

• 같은 큰 작업의 하위 결과물이 3개 이상일 때
• 부모 bullet 헤드만 봐도 큰 그림 파악되고, sub-bullet 으로 들어가면 디테일 보임
• "1년 동안 뭘 개선했나" / "재고 시스템 6개월 안정화" 같은 시간성·범위성 묶음

주의: 1단 nesting 까지만. 2단 이상은 시각 부담. 그 이상 깊이 있는 작업은 별도 카드로 분리.

패턴 6 — 명사형 어미

"~을 담당했습니다" → "~ 담당"
"~을 도입하였습니다" → "~ 도입"
"~을 구축하였습니다" → "~ 구축"

bullet 끝을 명사형으로 통일하면 가독성 + 압축 효과.

패턴 7 — 공고 매칭 가시화 (transferability 어필)

각 카드 작성 후 자문 — "이 경험이 지원 회사의 어떤 요건/문제에 어떻게 옮겨지는가? 카드에 그 매핑이 (직접 명시 안 해도) 면접관 머리에 자연스럽게 그려지는가?"

잘 매핑되는 경우 — 면접관이 "아 이거 우리 팀 와서도 쓰겠네" 가 떠오름:

• "디자이너 협업 — 시각·로직 영역 디렉터리 분리해 동시 수정 충돌 제거" → 다중 클라이언트(앱·키오스크·온라인 주문) 백엔드의 도메인 분리 설계로 매핑
• "다중 서버 캐시 정합성 — 트랜잭션 커밋 후 메시지 브로커로 변경 전파" → 매장·POS·앱 데이터 정합성 시나리오로 매핑
• "Step 격리·재시작 가능한 배치" → 정산·주문 데이터 야간 배치 운영 시나리오로 매핑

매핑이 약한 경우 — "이 경험을 왜 우리한테?" 라는 갭:

• 게임 슬롯 RTP 시뮬레이션 → 푸드빌 도메인에 직접 매핑 어려움 (이런 카드는 보조로 짧게)
• 특정 회사 한정 컴플라이언스 → 매핑 안 됨

룰: 메인 카드 N개를 결정할 때 공고 매칭이 가장 잘 되는 것부터 분량 큰 메인으로 둔다. 공고와 거리 먼 경험은 보조 카드로 짧게. 카드 본문 작성 시 도메인 단어를 일반화 (예: "슬롯 상품 N종 출시 사이클" → "동일 규모 신규 상품 출시 사이클") 해두면 면접관이 본인 도메인으로 자동 치환해 읽는다.

자가 점검 — 카드별로: "지원 회사 도메인 모르는 면접관이 이 카드를 읽고, 5초 안에 우리 팀 어떤 작업에 적용 가능한지 떠올릴 수 있는가?"

---

Summary 작성 가이드

이력서 최상단 Summary 는 1순위 시선 집중 영역. 3 단락 구조 권장.

1단락 — 경력 + 도메인 + 가치관/태도

• 총 경력 + 주요 도메인 (게임/베팅/AI 등 일반화된 표현)
• 본인이 무게 두는 가치 (구체 어휘로 — "끈질기게", "오래 살아남는 코드" 등)
• 금지: "다양한 도메인을 직접 설계해왔습니다" 같은 자기 PR. "다양한 도메인 설계 경험" 사실 진술로.

2단락 — 현재 활동 (필요 시)

• 본 이력서 외 활동: 사이드 프로젝트, AI 도구 워크플로 정착, 학습 기록 저장소 등
• 금지: "한 축의 커리어로 이어져" 같은 추상 어미

3단락 — 지원 동기 + 매칭 (선택)

• 지원 회사 도메인이 본인 경험과 어떻게 매핑되는지 1-2 문장
• 금지: 공고 키워드 그대로 복사. 본인 어휘로 재해석

Summary 자가 점검

• "다중 서버 캐시 정합성과 운영 장애 분석을 깊이 있게 다뤄왔습니다" 같이 학술적이거나 자기 평가형 표현 → 사실 진술로 ("다중 서버 데이터 정합성, 운영 장애 분석 경험")
• AI / 사이드 활동 단락이 메인 경력보다 길지 않게 — 메인 경력이 메인이어야 함
• 1단락 Summary 가 함정 1, 2, 3 (PR 톤 / 내부 명칭 / 비기여) 점검에서 모두 통과하는지 확인

---

사용자 제안 처리 프로토콜 (필수)

세션 중 사용자가 표현·문구를 직접 제안하는 경우가 자주 있다 (예: "X bullet 을 Y 로 바꿔줘", "Z 톤으로 가자"). 이때 곧이곧대로 그대로 반영하지 않는다. 사용자 표현도 SKILL 룰을 통과해야 한다.

처리 흐름

1. 사용자 제안을 받으면, 먼저 SKILL 의 함정 110 + 패턴 18 + 5초 인상 두 축으로 점검
2. 점검 결과 한 항목이라도 위반·중복·약점이 발견되면, 사용자에게 점검 결과를 짧게 알리고 보정안 제안
3. 사용자가 보정안 동의 또는 원안 고수 결정
4. 결정 후 적용

자주 빠지는 케이스

사용자 제안 패턴	SKILL 점검 시 자주 걸리는 함정
"이 bullet 을 X 로 바꿔줘"	함정 1 (PR 톤), 함정 3 (코드명), 함정 5 (정량 단위), 사용한 기술 라인과 중복
"Y 표현이 더 자연스럽지 않을까"	함정 2 (AI 티), 함정 9 (도메인 의존), 5초 이해 가능성
"이거 더 강조하자"	함정 4 (비기여 자폭), 함정 7 (분량 비대)
"수치 추가하자"	함정 5 (단위 미명시), 함정 6 (정량 자랑 vs 본질)
"한 단락으로 묶자" / "합치자" / "한 bullet 으로"	함정 8 (한 bullet 두 업무) 자동 트리거 — 사용자가 묶자고 해도 합쳐서 정보 3개 이상이면 sub-bullet 구조 권장. 단순 합치기는 정보 욱여 넣기로 빠지기 쉬움
"이거랑 이거 분리하자"	함정 4 (비기여 자폭) — 분리한 한쪽이 약하면 빼야 한다는 신호
"이거 빼버리자"	빼는 결정은 OK 가 많지만, 빈 bullet 자리에 보강 필요 여부 점검 (함정 7 분량)

적용 형식

사용자 제안 그대로 적용하지 말고, 다음 한 단계 거쳐서 응답:

사용자 제안: "X 로 바꿔줘"

→ SKILL 점검: [어떤 축에서 어떤 위반/중복 발견]

→ 보정안: "X' 로 가는 게 어떨까요? 이유: ..."

→ 사용자 결정 후 적용

위반 없으면 짧게 통과 표시 후 적용:

SKILL 점검 통과 — 적용

예외: 사용자가 "그냥 그대로 가자" / "내 표현 그대로 적용" 처럼 명시적으로 점검 생략을 지시하면 그대로 적용. 단 명시적 지시 없이는 점검 의무.

메타 학습

이 프로토콜이 무너지는 경우는 작성자가 "사용자가 한 말이니 맞겠지" 로 점검을 건너뛸 때다. 사용자 본인 표현이라도 한국 IT 시니어 백엔드 이력서 룰을 위반할 수 있다 (특히 분량 비대·중복·정량 자폭). 점검 의무는 사용자 톤에 무관하게 항상 작동한다.

특히 "묶자/합치자" 류 제안은 함정 8 자동 트리거. 사용자의 의도는 보통 "두 짧은 bullet 을 하나로 통합" 인데, 단순 합치기는 정보 3-4개를 한 bullet 에 욱여 넣어 정보 밀도 폭발 + 5초 이해 가능성 깨짐. 합칠 정보가 3개 이상이면 sub-bullet 구조 또는 분리 유지 가 정답. 단일 bullet 에 묶는 건 정보 1-2개 한정.

실 사례 (이번 세션): "포인트 잔액·이력 분리" + "동시성 정합성" 두 bullet → 사용자 "한 단락으로 묶자" → 작성자 점검 없이 단순 합쳐 정보 4개 (잔액·이력 분리 / postBalance·delta 페이로드 / 시점별 추적·감사 / 비관적 락) 한 bullet 압축 → 가독성 폭발 → 사용자 지적 후 sub-bullet 구조로 재설계.

---

실행 단계 (강화판)

Step 0 — 입력 확인 + 사용자 톤 파악 (필수)

다음을 모두 확인. 없으면 진행 전 요청.

• 지원 회사명 / 직무
• 개인 정보 (이름, 이메일, 전화번호, GitHub)
• 기존 이력서 파일 경로 — 매우 중요. 사용자 본인이 평소 쓰는 톤이 가장 검증된 base
• 강조하고 싶은 경험 / 제외할 내용
• 출력 형식 (HTML / MD / PDF)

기존 이력서가 있다면 base 로 사용한다. task 폴더를 풀어내려는 욕심을 버리고, 사용자 톤 위에 공고 매칭만 얹는다.

Step 1 — [병렬] 직무 분석 + task 탐색

- interview/{회사}-{직군}.md 읽기 (없으면 사용자에게 공고 URL 요청 후 직접 분석)
- task/ 4개 팀 README 읽기
- 사용자 기존 이력서(있으면) 읽기 — 톤 파악
- (대상 회사가 다른 회사 이력서를 참고하라고 했으면) 그 PDF/HTML도 읽기

Step 2 — 검증 라운드 (반드시 사용자와 1:1)

작성 전 점검. 건너뛰면 자폭 누적된다.

각 어필 포인트마다 함정 4 의 3분법으로 분류:

분류	표기 톤
본인 도입·구축	"도입", "구축", "설계 및 구현"
기존 패턴 절용·확장	"팀에 자리 잡은 X 패턴을 운영하며", "적용하면서"
팀 작업 일부	어필 빼거나 팀 활동 묘사

다음 항목들은 거의 항상 검증 필요:

• 캐시 정합성 패턴 (PostCommitUpdateEventListener + Fanout 등)
• Lock·동시성 제어 (StampedLock 등)
• Outbox / AFTER_COMMIT 패턴
• 추상 클래스 도입 / 리팩터링
• 측정 수치 (X% 단축, N배 향상, 커버리지 %)
• 테스트 개수 (본인 작성? 팀 누적?)
• AI 도구 사용 표현 (단독 / 협업 / 검토)
• 기간 정량 ("X일 / Y주")

검증 결과를 transcript.txt 에 기록.

근거 grep 점검 — 매 어필 표현마다:

이력서에 적힌 모든 어필 표현 (특히 시스템 구축·구조 어필) 은 task 폴더에 grep 으로 근거 있어야 함. 0건이면 자폭 위험.

# 어필 표현의 핵심 단어로 task 폴더 grep
grep -rln "<핵심 단어>" /path/to/task/<팀명>/

실 사례: "로깅 시스템 구축으로 운영 효율화" → task/nsc-slot/ 에 "로깅 시스템", "운영 효율화" 0건 → 근거 없는 어필 → 제거.

Step 3 — 이력서 구조 설계

• 경력 순서: 최신순(역시간순)
• 카드 우선순위: 공고 매칭 1순위 카드가 분량 가장 큼 (역전 금지 — 함정 7)
• 메인 카드 N개: 면접에서 깊이 파고들 2-3개 — 충분히 답변 가능한 깊이가 있는 것만
• 보조 카드: 짧게. 1-3 bullet
• 제외 대상: 공고 무관 / 본인 비기여 / 측정 단위 없는 정량

사용자 확인 받기 (선택적).

Step 4 — 작성 (HTML / MD / PDF)

출력 형식 결정

• HTML 단독 (현재 권장): 직접 PDF 변환. MD 동시 작성 불필요
• HTML + MD: 사용자가 원하면. 단 두 포맷 동기화 비용 큼
• PDF 자동 변환: Chrome headless 가 가장 안정적

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --headless --disable-gpu --no-pdf-header-footer \
  --print-to-pdf=resume/{name}.pdf \
  "file:///absolute/path/to/{name}.html"

HTML 표준 구조

@page { size: A4; margin: 18mm 20mm; }
font-family: 'Noto Sans KR', -apple-system, ...;
-webkit-print-color-adjust: exact;

<header>
  <h1>이름</h1>
  <div class="contact">...</div>
  <div class="summary">
    <p>1단락 — 경력 + 도메인 + 가치관/태도</p>
    <p>2단락 — 현재 활동 (필요 시)</p>
    <p>3단락 — 지원 동기 + 매칭 (선택)</p>
  </div>
</header>

<section class="skills"> ... </section>

<section class="experience">
  <div class="company">
    <div class="company-name">회사명</div>
    <div class="company-meta">기간 | 정규직 | 직군</div>
  </div>

  <div class="team">
    <div class="team-name">팀명</div>
    <div class="team-period">기간</div>
    <div class="team-desc">팀 소개 한 문단</div>
  </div>

  <div class="project">
    <div class="project-title">프로젝트명</div>
    <div class="project-period">기간</div>
    <div class="block-label">주요 업무</div>
    <ul>...</ul>
    <div class="block-label">주요 성과</div>
    <ul>...</ul>
    <div class="tech-line">사용한 기술: ...</div>
  </div>
</section>

<section class="education"> ... </section>
<section class="etc"> ... </section>

HTML 작성 주의: 백틱(`...`) 은 markdown 문법이라 HTML 에서 강조되지 않는다. 코드명·키워드 강조는 <strong> 또는 <code> 태그 사용.

카드 유형별 미니 템플릿: references/card-templates.md 참조.

파일명 규칙

resume/{회사명-케밥}-resume-{직군}.html
resume/{회사명-케밥}-resume-{직군}.pdf

Step 5 — 자가 점검 (필수)

작성 후 다음 grep / 검사 필수.

# PR 톤 어휘 (함정 1)
grep -nE "직접|단독|주도|본인 [가-힣]+|혼자|최초" <file>

# 내부 명칭 (함정 3)
grep -nE "ADR-[0-9]+|/(planning|plan-and-build|build-with-teams)" <file>

# AI 티 표현 (함정 2)
grep -nE "한 축의 커리어|두 팀을 잇는|작업 결을 보여주는|본질적으로" <file>

# 측정 단위 미명시 정량 (함정 5)
grep -nE "[0-9]+%|[0-9]+배|[0-9]+ → [0-9]+" <file>
# → 매치마다 측정 단위·범위 함께 명시되어 있는지 수동 확인

# 마크다운 함정
grep -c "§" <file>     # = 0 이어야 함
# ~ 취소선 위험은 paragraph 단위로 별도 검사

면접관 5초 인상 두 축 자가 점검 (카드별)

grep 으로 잡히지 않는다. 카드를 한 번씩 다시 읽으며 두 질문을 통과하는지 확인.

1. 이해 가능성 — "지원 회사 도메인을 전혀 모르는 면접관이 이 카드를 읽고, 5초 안에 무엇을 한 작업인지 그림이 그려지는가?"
   • 도메인 친숙 독자만 이해할 부연·약어·전제가 있으면 일반화 또는 제거 (함정 9 참조)
   • 헤드 키워드만으로 핵심이 전달되는 카드면 뒤 부연은 빼는 게 낫다
2. 적용 가능성 (transferability) — "이 카드를 읽은 면접관 머리에 '우리 팀 와서 이런 것도 바로 적용 가능하겠구나' 가 떠오르는가?"
   • 안 떠오르면: 카드를 보조로 내리거나, 도메인 표현을 한 단계 더 일반화 (패턴 7 참조)
   • 떠오르긴 하는데 약하면: 헤드 키워드를 지원 회사 도메인에 옮길 수 있는 추상 표현으로 손봄

Step 6 — 외부 비평 (권장, 1차 작성 후)

oh-my-claudecode:critic 또는 general-purpose agent 호출. 명시적 컨텍스트:

• "한국 IT 시니어 백엔드 이력서 전문가 시각"
• "면접관 5초 인상 + 30초 인상 시나리오로 평가"
• "PR 톤 / 내부 명칭 / AI 티 / 분량 역전 / 미기여 어필 / 정량 자폭 / 도메인 의존" 7축 점검
• 점수(10점) + 우선순위 개선 5건 권장

자가 점검은 자기가 짠 글에 관대하다. 외부 시각 1회는 거의 항상 새로운 함정을 잡아낸다.

Step 7 — transcript.txt 저장

[작성일] YYYY-MM-DD
[지원] 회사 / 직무

[읽은 파일]
- interview/...
- task/...
- 기존 이력서: resume/...
- 참고 이력서(다른 회사): ...

[검증 라운드 결과]
- 항목 N — 본인 도입 ✓ / 기존 절용 △ / 팀 작업 ❌
- ...

[critic 비평 결과 (있으면)]
- 점수 / 핵심 지적

[자가 점검 통과 여부]
- PR 톤 / 내부 명칭 / AI 티 / 측정 단위 / 마크다운 함정: 매치 N건 → 0건 처리 완료
- 면접관 5초 인상 두 축: 카드별 통과 여부

[후속 작업 메모]
- task 문서 수정 필요 (있으면)
- 다음 라운드에서 보강할 카드

---

절대 하지 말 것

• task 폴더 내용 그대로 옮기기 — 면접관 컨텍스트 무시. 풀어내고 단순화
• 추측으로 수치 만들기 — 본인 측정 아니면 빼거나 사용자에게 묻기
• 사용자 의견 그대로 복붙 — 사용자 표현도 SKILL 룰 통과해야 함. 점검 → 보정안 제안 → 동의 후 적용. "사용자 제안 처리 프로토콜" 섹션 참조
• CSS·헤더 너무 자주 갈아엎기 — 디자인 자체는 검증된 base 사용
• PDF 변환 빼먹기 — HTML 작성 후 즉시 PDF 변환 (제출 가능 상태). 단 사용자가 "누적 후 한 번에" 지시하면 보류
• 외부 비평 생략 — critic agent 1회는 거의 항상 가치 있음
• 분량 비대 메인 카드 — 8 bullet 넘으면 압축 신호
• 모든 ADR / 구조를 본문에 풀기 — 2-3개 핵심 어필만. 나머지는 면접 답변용
• HTML 에서 백틱(`...`) 으로 강조 — markdown 문법이라 렌더링 안 됨. <strong> 사용

---

참고

• 한국 표준 이력서 포맷: 원티드, 넥슨, 토스 — "주요 업무 / 주요 성과 / 사용한 기술" 3블록
• 본인 평소 톤이 검증 자산: 기존 이력서가 있으면 그것을 base 로
• 외부 비평: oh-my-claudecode:critic Opus 모델
• PDF 변환: Chrome headless --print-to-pdf
• 카드 템플릿: references/card-templates.md
• 톤 변환 표: references/tone-conversion.md

이 스킬만 따라가면 깔끔한 이력서가 나오도록 함정 회피 룰을 빠짐없이 박았다. 새 작성 세션에서 누적 함정이 발견되면 이 스킬에 추가해 다음 작성에서 같은 실수 안 나게 한다.