| name | write-portfolio |
| description | 포트폴리오(10-15페이지) 기술 백서 작성이 필요할 때 |
포트폴리오 작성
핵심 원칙: 8년차 포트폴리오는 '작품집'이 아니라 '기술 백서(White Paper)' "무엇을 만들었나"가 아니라 "어떤 문제를 해결했고, 비즈니스에 어떤 임팩트를 줬나"
면접 친화적 포트폴리오 원칙
목표: 공격적/방어적 표현 대신 프로젝트 스토리텔링에 집중
| ❌ 피해야 할 표현 | ✅ 권장 표현 |
|---|---|
| "Why NOT" (선택 안 한 이유) | "기술적 배경" (맥락 설명) |
| "피한 안티패턴" | "설계 원칙" |
| "실패 경험" (부정적 프레이밍) | "개선 과정" (성장 스토리) |
문제-해결-결과 (PSR) 프레임워크
모든 프로젝트 설명은 3줄 이내로 PSR 구조 적용
[문제] 비즈니스/기술적 문제 상황 (1줄)
[해결] 적용한 기술과 접근 방식 (1줄)
[결과] 정량적 성과와 비즈니스 임팩트 (1줄)
예시:
[문제] 200만 건 데이터 복합 검색 시 10초+ 타임아웃 발생
[해결] Elasticsearch 역색인 기반 검색 구조로 전환, 인덱싱 전략 최적화
[결과] 응답 시간 1초 이내 달성, 사용자 이탈률 감소
이력서 vs 경력기술서 vs 포트폴리오
| 항목 | 이력서 | 경력기술서 | 포트폴리오 |
|---|---|---|---|
| 목적 | 경력 요약 | 프로젝트별 성과 상세 | 기술적 맥락 + 아키텍처 시각화 |
| 분량 | 1-2페이지 | 5-10페이지 | 10-15페이지 (PDF) |
| 초점 | What (무엇을 했나) | How (어떻게 했나) | Why (왜 그렇게 결정했나) + 시각화 |
| 핵심 요소 | 경력/기술스택 | STAR 기반 성과 | 아키텍처 다이어그램 + 기술적 맥락 |
| 대상 | HR/채용담당자 | 면접관 | 테크 리드/CTO |
| 상세도 | 1줄 요약 | 5-10줄 상세 | 그 이상 + 다이어그램 |
포트폴리오가 답해야 할 질문
- 이 개발자는 복잡한 문제를 구조화할 수 있는가?
- 기술 선택에 일관된 기준이 있는가?
- 조직·비즈니스 관점에서 신뢰 가능한 판단자인가?
결론: "코드를 잘 짜는 사람"이 아니라 **"이 사람에게 맡기면 시스템이 망가지지 않는다"**를 증명
포트폴리오 구조 (10-15페이지)
1. Executive Summary (1페이지)
└── 기술적 정체성 + 판단 기준 문장 + 핵심 역량 3-4개 + 대표 성과
2. Key Projects (6-8페이지)
└── 핵심 프로젝트 2-3개 (Case Study 형식)
├── 아키텍처 다이어그램 (Before/After)
├── 프로젝트 배경 (Business Context)
├── 문제-해결-결과 (PSR 구조, 각 3줄 이내)
├── 기술적 맥락 (선택한 기술과 그 배경)
├── 개선 과정 (시행착오 → 성장)
└── 정량적 성과 (측정 방법 포함)
3. Technical Decision Archive (2페이지)
├── 주요 기술 선택 근거 (Decision Log)
└── 설계 원칙 (일관된 기술 철학)
4. Organization Contribution (1-2페이지)
├── 조직 기여 & 루틴 개선 (반복 업무 제거, 자동화)
└── Bus Factor 최소화 (내가 빠져도 유지되는 구조)
5. Tech Leadership (1-2페이지)
├── 코드 리뷰 문화, TDD 도입, 멘토링
├── 협업 사례 (팀 간 조율)
└── 위임과 조직화 (팀 역량 성장)
섹션별 작성 가이드
1. Executive Summary (1페이지)
기술적 정체성 (2-3문장)
Java/Spring 기반 8년차 백엔드 개발자로,
이커머스 플랫폼에서 대용량 데이터 파이프라인과 검색 시스템을 설계·구현해왔습니다.
'자동화·단순화·지표화'를 핵심 원칙으로,
운영 비용과 장기 유지보수를 우선 고려하여 설계합니다.
판단 기준 문장 (Anchor Statement) - 필수
모든 기술 선택은 ① 운영 리스크 감소 → ② 자동화 가능성 → ③ 조직 확장성 우선순위로 판단합니다.
이 한 줄이 이후 모든 Decision Log의 기준점(anchor)이 됩니다.
Core Competencies (3-4개)
| 역량 | 설명 | 대표 성과 |
|---|---|---|
| 대용량 데이터 파이프라인 | 200만+ 레코드 수집/정제/적재 | 데이터 풀 20배 확대 |
| 검색 시스템 최적화 | Elasticsearch 기반 성능 튜닝 | TPS 1500% 향상 |
| 운영 자동화 (Zero Ops) | ChatOps로 운영 업무 자동화 | 반복 업무 40% → 0% |
2. Key Projects (6-8페이지)
프로젝트 선정 기준
| 기준 | 설명 |
|---|---|
| 임팩트 | 비즈니스 성과가 정량적으로 측정 가능한 프로젝트 |
| 난이도 | 단순 CRUD가 아닌, 기술적 의사결정이 필요했던 프로젝트 |
| 역할 | "참여"가 아닌 "설계/구현/리드"한 프로젝트 |
| 최신성 | 최근 2-3년 내 프로젝트 우선 |
프로젝트 서술 프레임 (Case Study 형식)
┌─────────────────────────────────────────────────────────────┐
│ 1. 아키텍처 다이어그램 (필수) │
│ - Before/After 시스템 구성도 │
│ - 8년차는 말보다 도식화된 설계도로 실력 증명 │
│ → /svg-diagram 또는 /mermaid-diagram 사용 │
├─────────────────────────────────────────────────────────────┤
│ 2. 프로젝트 배경 (Business Context) │
│ - 비즈니스 상황과 기술적 요구사항 │
│ - 조직/운영 맥락 (팀 구성, 리소스 제약) │
├─────────────────────────────────────────────────────────────┤
│ 3. 문제-해결-결과 (PSR 구조, 각 3줄 이내) │
│ - [문제] 비즈니스/기술적 문제 상황 │
│ - [해결] 적용한 기술과 접근 방식 │
│ - [결과] 정량적 성과와 비즈니스 임팩트 │
├─────────────────────────────────────────────────────────────┤
│ 4. 기술적 맥락 (Technical Context) │
│ - 선택한 기술과 그 배경 │
│ - 기존 인프라/팀 역량을 고려한 결정 │
│ - "왜 이 기술이 우리 상황에 적합했는가" │
├─────────────────────────────────────────────────────────────┤
│ 5. 개선 과정 (Improvement Journey) │
│ - 초기 접근 → 문제 발견 → 개선 적용 │
│ - 시행착오를 통해 얻은 인사이트 │
│ - 성장 스토리로 표현 (부정적 프레이밍 지양) │
├─────────────────────────────────────────────────────────────┤
│ 6. 정량적 성과 │
│ - 반드시 숫자로 표현 (속도, 비용, 인력, 매출 등) │
│ - 측정 방법 명시 (APM, 부하 테스트, Jira 티켓 등) │
│ - ROI 환산 (비용 절감액, 매출 기여도) │
└─────────────────────────────────────────────────────────────┘
3줄 작성 원칙
모든 설명은 최대 3줄로 제한하여 면접에서 확장 설명할 여지를 남김
| 항목 | 1줄 | 2줄 | 3줄 |
|---|---|---|---|
| 문제 | 상황 요약 | - | - |
| 해결 | 핵심 기술/접근법 | 구현 방식 | - |
| 결과 | 주요 성과 수치 | 비즈니스 임팩트 | 부가 효과 |
| 기술적 맥락 | 선택 이유 | 팀/인프라 고려 | Trade-off |
아키텍처 다이어그램 작성
시각화 도구 선택:
| 도구 | 용도 | 명령어 |
|---|---|---|
| SVG 직접 생성 | 계층 구조, Before/After 비교, 정교한 레이아웃 | /svg-diagram |
| Mermaid | 플로우차트, 시퀀스, ER 다이어그램 | /mermaid-diagram |
다이어그램 저장 위치:
docs/career/portfolio/
├── portfolio.md # 포트폴리오 본문
└── images/
├── data-pipeline-before.svg # Before 아키텍처
├── data-pipeline-after.svg # After 아키텍처
└── search-flow.svg # 검색 플로우
3. Technical Decision Archive (2페이지)
Decision Log 템플릿
## Decision: [결정 사항]
### Context
- 당시 상황과 제약 조건
### Options
- A: [선택지 1] → 장단점
- B: [선택지 2] → 장단점
- C: [선택지 3] → 장단점
### Decision
- 선택한 옵션과 이유
### Trade-off
- 포기한 것과 대안
### Result
- 실제 결과
설계 원칙 (Design Principles)
일관된 기술 철학을 보여주는 섹션
| 원칙 | 적용 사례 |
|---|---|
| 적정 기술 선택 | 이벤트 규모에 맞춰 Kafka 대신 단순 큐 활용, 운영 복잡도 최소화 |
| 필요 시점 추상화 | 최소 3곳에서 사용될 때만 공통화, 불필요한 복잡도 방지 |
| 운영 우선 설계 | 장애 대응/모니터링을 고려한 설계, 새벽 장애 방지 |
4. Organization Contribution (1-2페이지)
Bus Factor 최소화 (내가 빠져도 유지되는 구조)
CTO/리드 관점: '이 사람이 없을 때도 시스템이 굴러가는가'
| 항목 | 내용 |
|---|---|
| 문서화 | 모든 운영 자동화 스크립트에 README + Runbook 작성 |
| 온보딩 | 신규 인원도 1주 내 운영 가능하도록 가이드 체계화 |
| 의존성 제거 | 특정 개인 의존 작업 0건 달성 |
5. Tech Leadership (1-2페이지)
협업 사례 (Collaboration)
기술적 결정이 팀/조직과 어떻게 조율되었는지
| 상황 | 접근 방식 | 결과 |
|---|---|---|
| TDD 도입 제안 | 핫픽스 빈도 감소 데이터 제시 | PM 합의 도출, 팀 도입 |
| 성능 최적화 우선순위 | APM 데이터 기반 병목 시각화 | 비즈니스 임팩트 기반 우선순위 합의 |
팀 역량 성장 (Team Enablement)
개인 성과보다 팀 전체의 역량 향상에 기여
| 영역 | 접근 방식 | 효과 |
|---|---|---|
| 성능 최적화 | Slow Query 가이드 문서화 | 팀 단위 자발적 개선 문화 |
| 코드 품질 | 리뷰 가이드라인 제정 | 팀원 간 상호 리뷰 정착 |
| 운영 대응 | Runbook 체계화 | 온콜 로테이션 가능 |
Technical Skills (숙련도 표현)
단순 나열이 아닌, 숙련도와 맥락을 함께 표현
| 영역 | 기술 | 숙련도 | 맥락 |
|---|---|---|---|
| Core | Java 17, Spring Boot 3.x | ★★★★★ | 8년간 주력, 프로덕션 운영 |
| Search | Elasticsearch 7.x/8.x | ★★★★☆ | 200만 건 인덱싱, 쿼리 최적화 |
| Data | MySQL, Redis | ★★★★★ | 트랜잭션 설계, 분산 락 |
숙련도 기준
| 등급 | 의미 |
|---|---|
| ★★★★★ | 설계/리딩 가능 (아키텍처 결정권) |
| ★★★★☆ | 독립 구현 가능 (가이드 없이 프로덕션 배포) |
| ★★★☆☆ | 운영/활용 가능 (기존 시스템 유지보수) |
타겟별 커스터마이징 전략
동일한 경험도 대상에 따라 강조점이 달라야 합니다.
| 타겟 | 강조 포인트 | 축소/생략 |
|---|---|---|
| 스타트업 | 빠른 실행력, 운영 자동화, 적은 리소스로 임팩트 | 대규모 트래픽 경험 |
| 대기업/네카라 | 대용량 처리, 시스템 설계, 협업 프로세스 | 개인 프로젝트 |
| 이커머스 도메인 | 주문/결제/검색 최적화, Dynamic Pricing | 타 도메인 경험 |
| 데이터 플랫폼팀 | 파이프라인, ES/Kafka, 배치 최적화 | CRUD 비즈니스 로직 |
| 테크 리드/매니저 | 조직 기여, 멘토링, 프로세스 개선 | 개인 기술 깊이 |
실행 단계
Step 1: 데이터 준비
# 원본 데이터 확인
cat docs/career/my_career_data.md
# 기존 경력기술서 확인
cat docs/career/career_portfolio.md
Step 2: 프로젝트 선정 (2-3개)
- 임팩트 큰 프로젝트 선별
- 각 프로젝트별 Decision Log 작성
- 아키텍처 다이어그램 준비
Step 3: 다이어그램 생성
# SVG 직접 생성 (정교한 레이아웃)
/svg-diagram
# Mermaid 생성 (플로우/시퀀스)
/mermaid-diagram
Step 4: 포트폴리오 작성
- Executive Summary 작성 (판단 기준 문장 포함)
- Key Projects Case Study 작성
- Technical Decision Archive 정리
- Organization Contribution + Tech Leadership 정리
Step 5: 저장 및 내보내기
# 저장 위치
docs/career/portfolio/portfolio.md
# PDF 내보내기
/export
체크리스트
포트폴리오 완성도 검증
- Executive Summary에 기술적 정체성이 명확한가?
- 판단 기준 문장(Anchor Statement)이 있는가?
- 핵심 프로젝트가 2-3개로 선별되었는가?
- 각 프로젝트에 아키텍처 다이어그램이 포함되었는가?
- 문제-해결-결과(PSR) 구조가 3줄 이내로 작성되었는가?
- 정량적 성과 + 측정 방법이 포함되어 있는가?
- Decision Log가 포함되어 있는가?
- 10-15페이지 내외로 정리되었는가?
면접 친화성 검증
- 공격적/방어적 표현 대신 프로젝트 스토리텔링인가?
- 기술적 맥락이 배경 설명으로 작성되었는가?
- 개선 과정이 성장 스토리로 표현되었는가?
- 이력서/경력기술서보다 상세하게 작성되었는가?
시니어 차별화 검증
- 기술 선택에 대한 맥락/배경이 설명되어 있는가?
- 내가 없어도 운영 가능한 구조(Bus Factor 최소화)가 드러나는가?
- 개인 성과가 아닌 조직/팀 성과로 귀결되는가?
피해야 할 실수
| ❌ 피해야 할 것 | ⭕ 해야 할 것 |
|---|---|
| 기술 스택 나열에 집중 | 성과 없는 기술은 의미 없음 |
| 모든 프로젝트 나열 | 임팩트 큰 2-3개만 선별 |
| "참여했습니다" 표현 | "설계/구현/리드했습니다"로 역할 명확화 |
| 정성적 성과만 기술 | 반드시 숫자로 정량화 |
| CRUD 토이 프로젝트 | 비즈니스 임팩트 있는 실무 프로젝트 |
관련 스킬
/writing-guide: STAR+I 작성 원칙, 시니어 톤/create-resume-document: 이력서 작성 (2-3페이지, 세트 생성)/write-career: 경력기술서 작성 (5페이지+)/svg-diagram: SVG 아키텍처 다이어그램 생성/mermaid-diagram: Mermaid 다이어그램 생성/export: PDF 내보내기
문서 세트 구조
포트폴리오는 이력서/경력기술서와 함께 세트로 작성
| 문서 | 분량 | 목적 | 대상 |
|---|---|---|---|
| 이력서 | 2-3페이지 | 빠른 스크리닝 | 인사/채용담당 |
| 경력기술서 | 5페이지+ | 상세 역량 검증 | 실무 면접관 |
| 포트폴리오 | 10-15페이지 | 기술 의사결정/리더십 | Tech Lead/CTO |
포트폴리오 특화 내용
경력기술서에서 다루지 않는 시니어 차별화 요소
| 항목 | 이력서 | 경력기술서 | 포트폴리오 |
|---|---|---|---|
| 성과 설명 | 1줄 | 5-10줄 | PSR 구조 + 다이어그램 |
| 기술 선택 | 제외 | 1-2줄 | Decision Log (상세) |
| 기술적 맥락 | 제외 | 제외 | 배경/맥락 설명 (3줄) |
| 개선 과정 | 제외 | Lesson Learned | 성장 스토리 (시행착오 → 개선) |
| 리더십 | 제외 | 제외 | 협업 사례, 팀 역량 성장 |
| 조직 기여 | 제외 | 제외 | Bus Factor 최소화 |
| 아키텍처 | 제외 | 간단 포함 | Before/After 시각화 |