이력서/경력기술서 작성 가이드

핵심 철학: 프로젝트는 "참여 기록"이 아닌 "문제 해결 보고서"

1. 핵심 원칙

세 줄 요약

1. 프로젝트는 문제 → 판단 → 실행 → 성과의 일관된 구조로 작성
2. 상위 20% 프로젝트만 남기고, 나머지는 과감히 정리 (5~6개가 이상적)
3. 기술 스택은 성과를 설명하기 위한 수단으로만 사용

시니어 레벨 필수 요소

핵심 마인드셋

2. STAR+I 프레임워크

구조 개요

[프로젝트명] (기간: YYYY.MM - YYYY.MM, N개월)
> 한 줄 요약: 핵심 가치 + 정량적 임팩트

역할: 백엔드 리드 / 결제 모듈 담당 / 1인 개발 등
기술 스택: Java 17, Spring Boot 3.x, Redis, AWS...

[STAR+I 상세]
├── S (Situation): 상황/배경/제약
├── T (Task): 과제/목표
├── A (Action): 기술적 의사결정 (Why & How) ⭐
├── R (Result): 정량적 성과
└── I (Impact): 비즈니스/조직적 효과

문장 템플릿

"[제약/문제](S) 속에서 [기술적 의사결정](A)으로 [정량적 성과](R) 달성,
[비즈니스/운영 효과](I)"

예시:

"API Limit 25k 제약(S) 속에서 우선순위 큐 기반 가격조정 로직 설계(A)로 핵심 상품 대응률 90% 달성(R), 운영팀 수작업 완전 제거(I)"

Action (기술적 의사결정) - 핵심

시니어 면접의 핵심은 "왜 Kafka를 썼나?"가 아니라 **"왜 RabbitMQ나 SQS를 안 쓰고 Kafka를 썼나?"**입니다.

의사결정 패턴 템플릿:

[선택한 방식]:
→ Why: [이유/근거]
→ Why Not: [고려했으나 기각한 대안과 이유] ⭐ 필수
→ Trade-off: [감수한 단점과 완화 방안]

상세 가이드: references/star-detailed.md 참조

3. 8년차 시니어 전략

기술적 트레이드오프 & 의사결정 근거

시니어는 정답만 맞히는 사람이 아니라 **'선택의 이유'**를 아는 사람

• ❌ "A 기술을 썼다"
• ✅ "B와 A를 비교했으나, 당시 트래픽 패턴과 리소스 제약을 고려하여 A를 선택"

팀/조직 영향력

8년차는 혼자 잘하는 것을 넘어 팀 전체의 생산성을 높여야

• 코드 리뷰 문화 정착
• 신규 입사자 온보딩 문서화
• 공통 모듈 개발
• 주니어 멘토링

비즈니스 언어 소통

기술 용어를 모르는 동료에게 어떻게 설명하고 설득했는지

4. 최종 판단 기준 (Trade-off Rule)

선택의 충돌 상황에서 적용하는 최종 기준

1. 조직/비즈니스 영향 > 기술 난이도
2. 재사용/확산 가능성 > 단발성 성과
3. 설명이 길어지는 프로젝트는 대표작이 아니다

5. 작성 체크리스트

프로젝트별

• 한 줄 요약이 비즈니스 임팩트를 포함하는가?
• Situation에서 조직의 손실이 명확한가?
• Action에서 "왜 이 방식인지" + "Why Not" 설명했는가? ⭐
• Result에 최소 1개 이상 정량 지표가 있는가?
• Impact가 개인을 넘어 조직 레벨인가?

전체 문서

• 프로젝트 수가 5~6개 이내인가?
• 상위 20% 기준으로 선별했는가?
• 기술 스택이 성과 설명의 수단으로만 사용되었는가?
• 각 프로젝트가 서로 다른 역량을 보여주는가?

6. 문서 간 역할 분리

writing-guide (이 문서) - 마스터
├── 모든 원칙, STAR+I, 시니어 톤 정의
│
create-resume-document - 이력서 특화
├── writing-guide 참조 + 이력서 고유 내용 (2-3페이지)
│
write-career - 경력기술서 특화
├── writing-guide 참조 + 경력기술서 고유 내용 (5페이지+)

참조 문서 (상세 가이드)

관련 스킬

• /create-resume-document: 이력서 작성 (2-3페이지)
• /write-career: 경력기술서 작성 (5페이지+, 기술적 깊이)
• /export: PDF/PPT 내보내기

관련 문서

• docs/career/my_career_data.md: 원본 데이터 (SSOT)