들어가며 — "코딩은 최고인데 왜 승진 안 됩니까?"
Senior Engineer 5년차:
> "기술은 팀 최고예요. 코드 품질도 탑이에요. 근데 Staff 승진 패킷에서 매번 떨어져요."
답: **Staff+ 레벨은 글로 평가된다**. 당신이 쓴 Design Doc, Postmortem, RFC, 블로그, 메모가 당신의 영향력. 코드 1만 줄보다 잘 쓴 Design Doc 한 장이 승진에 유리하다.
구글의 유명한 내부 연구: **Staff+ 레벨의 글쓰기 시간 비중은 30~50%**. "개발자"라기보단 "기술 작가".
이 글은:
1. **Design Doc** — 구조, 템플릿, 실패 사례
2. **RFC 프로세스** — Rust/Python/Node 비교
3. **기술 블로그** — Julia Evans, Dan Luu, Stratechery 해부
4. **기술서** — O'Reilly, Manning, 자가 출판
5. **컨퍼런스 발표** — CFP부터 발표까지
6. **Staff+ 승진 패킷**
7. **AI 시대 글쓰기** — Claude/Copilot 활용법
8. **한글 vs 영어** — 한국 개발자 전략
을 다룬다. Season 3 Episode 7. 지난 편에서 OSS 메인테이너의 README를 이야기했는데, 그 위로 **개발자의 모든 글**을 포괄한다.
Chapter 1: Design Doc — 코드 쓰기 전 쓰는 글
1.1 Design Doc이란
Google이 1999년경부터 정착시킨 문화. 복잡도 있는 코드 쓰기 전 **4~30페이지 문서 작성 + 리뷰**.
**목적**:
- 생각을 명료화 (글로 못 쓰면 이해 못 한 것)
- 더 나은 리뷰어 의견 수집
- 조직 학습 (미래에 검색 가능)
- 신입 온보딩 교재
1.2 Google의 Design Doc 템플릿
1. Title
2. Author(s) + Date + Status
3. Summary (1 paragraph, 해결 문제 + 제안)
4. Background (용어, 현재 시스템, 문제)
5. Goals / Non-Goals
6. Design Overview (그림 + 주요 컴포넌트)
7. Detailed Design
- Data Model
- API
- 알고리즘
- 에러 처리
8. Considered Alternatives (대안 2-3개 + 비교 + 왜 선택 안 함)
9. Cross-cutting Concerns (보안, 프라이버시, 성능, 비용, 관측)
10. Rollout Plan (단계, 롤백, 마이그레이션)
11. Open Questions
12. Appendix (Raw data, 벤치마크)
1.3 좋은 Design Doc의 특징
1. **문제부터 시작**: 무엇이 왜 문제인가. "마이크로서비스를 도입하자"가 아니라 "배포 시간이 45분 → 사용자 불만"
2. **측정 가능한 목표**: "더 빠르게"가 아니라 "p99 < 200ms"
3. **대안 비교 솔직**: "우리 것만 좋아"가 아니라 "A는 빠르지만 비용 2배, B는 싸지만 복잡도 높음"
4. **반대 의견 반영**: FAQ 섹션에 "이렇게 생각하실 수 있는데..."
5. **숫자로 근거**: 벤치마크, 비용 추정, QPS 추정
1.4 나쁜 Design Doc의 흔한 실수
- **"What"만 있고 "Why" 없음**: 무엇을 할지만, 왜 하는지 빠짐
- **분량 너무 많음**: 50페이지 → 아무도 안 읽음
- **분량 너무 적음**: 1페이지 → 세부 사항 누락
- **용어 혼란**: 같은 개념을 다른 이름으로
- **결론 없음**: 논의만 하고 결정 없음
1.5 리뷰 받기
**리뷰어 선택**:
- 직접 영향 받는 팀의 Tech Lead
- Cross-functional (Security, SRE)
- Staff+ 엔지니어 (전체 방향 체크)
**리뷰 기간**: 1~4주. 짧으면 피드백 부족, 길면 타이밍 놓침.
**피드백 처리**:
- 모든 코멘트에 응답 (동의/부분 동의/반대)
- 주요 변경은 변경 로그에 기록
- 해결 안 되는 이슈는 Open Questions에
1.6 실제 사례 — Amazon의 Narrative
Amazon은 6-page narrative memo. 구조 덜 엄격하지만:
- 서술형 문장 (bullet 금지)
- 구체적 데이터
- 반대 의견 선제 대응 (FAQ)
- 고객 관점
**Jeff Bezos의 평가 기준**:
> "A great memo reads like it was written by a good journalist covering a complex story."
Chapter 2: RFC — 커뮤니티 단위 결정
2.1 RFC가 필요한 순간
- 여러 팀/조직에 영향
- 파괴적 변경 가능성
- 장기 방향에 중요
- 외부 커뮤니티 합의 필요
Design Doc은 팀/조직 내부. RFC는 **더 넓은 커뮤니티 + 공식 프로세스**.
2.2 Rust의 RFC 프로세스
1. **Discussion**: Rust Internals forum에서 아이디어 브레인스토밍
2. **PR 제출**: `rust-lang/rfcs` 저장소에 Markdown PR
3. **커뮤니티 토론**: 수 주~수 개월
4. **Final Comment Period (FCP)**: 10일간 최종 의견
5. **Merge or Postpone**: Core team 합의
**공개된 예시**: async/await, GAT(Generic Associated Types), const generics.
2.3 Python의 PEP
- **PEP 1**: 프로세스 자체
- **PEP 8**: 스타일 가이드
- **PEP 20**: Zen of Python
- **PEP 8016**: Steering Council 모델
PEP은 Rust보다 더 공식적. 유명한 PEP:
- PEP 492 (async/await 추가)
- PEP 572 (Walrus operator :=)
- PEP 657 (Fine-grained error locations)
2.4 Node.js의 TSC
Node는 RFC 대신 **TSC(Technical Steering Committee)** 투표 + Collaborator 합의.
- 작은 변경: Collaborator PR
- 큰 변경: TSC 회의 + 투표
2.5 IETF RFC vs Project RFC
**혼동 주의**: IETF RFC (인터넷 표준, HTTP/TCP 등)와 프로젝트 RFC는 다름.
- IETF: 인터넷 표준 문서. 영구 번호. 예: RFC 9110 (HTTP/1.1)
- Project RFC: 개별 프로젝트 제안서.
2.6 RFC 쓸 때의 팁
1. **원샷 완벽 지양**: 초안 공개, 피드백 반영 여러 버전
2. **동기 설명 충분**: "왜 지금, 왜 이 방식"
3. **Alternative considered**: 반드시
4. **Migration path**: 파괴적 변경이면 마이그레이션 경로
5. **Backwards compatibility**: 호환성 명시
Chapter 3: 기술 블로그 — 장기 자산
3.1 왜 블로그인가
Staff+ 엔지니어의 공통점: 블로그. 이유:
- **글쓰기 연습**: 가장 저렴한 훈련
- **사고 정리**: 쓰면서 이해 깊어짐
- **네트워크**: 독자 → 동료 → 기회
- **검색 유인**: Google 타고 기회 옴
- **승진 증거**: 외부 영향력
3.2 블로그 유형
**1) Deep-dive 타입**: 한 주제에 1만 자. 예: Julia Evans의 "How does a database work?"
**2) Notes 타입**: 배운 것 빠르게 정리. 예: Simon Willison의 weblog.
**3) Opinion 타입**: 업계 분석. 예: Stratechery (Ben Thompson), Overreacted (Dan Abramov).
**4) Tutorial 타입**: Step-by-step. 예: Josh Comeau, Kent C. Dodds.
**5) Newsletter 타입**: 정기 큐레이션. 예: Pointer, TLDR.
3.3 Julia Evans 분석
- 2013년 블로그 시작
- 특징: **만화 같은 기술 설명** ("zines")
- 주제: Linux, Systems, Debugging
- 수입: Zines 판매 ($20~$40), Ruby Central 컨설팅
- 2022년 Stripe 퇴사 → 전업 작가
**교훈**: 전문 영역 + 독특한 스타일 = 팬덤.
3.4 Dan Luu 분석
- Stack/Hardware/Performance 전문
- 특징: 긴 글(1~3만 자), 논문 수준 리서치
- "Why are computers slow?" 등 deep research
- 연간 20개 글 남짓
- 수입: 주로 본업 (Microsoft → Twitter → 현재)
**교훈**: 희귀 주제 + 깊이 = 권위.
3.5 Stratechery (Ben Thompson)
- 테크 비즈니스 분석 blog + podcast
- **$12/월 구독** 모델로 독립
- 연 수백만 달러 추정
- "Aggregation Theory" 같은 프레임워크 제시
**교훈**: 뉴스를 쫓지 않고 분석 프레임워크를 만듦.
3.6 블로그 시작하기
**플랫폼 선택**:
- **자체 호스팅**: Next.js + Vercel, Astro, Hugo (이 블로그처럼)
- **Medium**: 쉬움, 발견 쉬움, 하지만 통제 못 함
- **Substack**: 뉴스레터 + 블로그 결합
- **dev.to**: 개발자 커뮤니티
- **Hashnode**: 커스텀 도메인 무료
**자체 호스팅 권장**: 장기 자산은 본인 소유여야.
3.7 글감 찾기
- **본인이 최근 배운 것** (가장 좋음 — 설명하면 각인)
- **자주 받는 질문**
- **잘못 알려진 것 바로잡기**
- **업계 논쟁에 의견 보태기**
- **Deep-dive 한 주제** (다른 블로그/논문 10개 + 자기 경험)
3.8 발행 주기
- **주 1~2회**: 너무 바쁨, 품질 저하
- **월 1~2회**: 지속 가능, 품질 유지
- **분기 1개**: 깊이 있는 long-form
**일관성 > 양**. 매주 허덕이기보다 월 1편 양질.
3.9 SEO와 배포
**SEO**:
- 제목에 키워드
- Description 메타
- H2/H3 구조
- 내부 링크 (관련 글)
- 이미지 alt
**배포**:
- Twitter/X
- Hacker News (적절한 시간대: 평일 미국 오전)
- Reddit (관련 서브)
- LinkedIn (업계 독자)
- 슬랙 커뮤니티
Chapter 4: 기술서 출간
4.1 출판사 선택
**O'Reilly**:
- 업계 최고 브랜드 ("동물 책")
- 선인세 $10K~$30K
- 로열티 10~15%
- 편집 엄격, 브랜드 활용
- 출간까지 1~2년
**Manning**:
- 실용서 중심
- Early Access Program (MEAP): 미완성도 판매
- 독자 피드백 빠름
- O'Reilly보다 문턱 낮음
**Pragmatic Bookshelf**:
- 프로그래머 대상
- 기술적 깊이
- 저자 친화적 조건
**Packt**:
- 빠른 출간, 다작
- 품질 편차 큼
**Self-publishing (Leanpub, Gumroad)**:
- 로열티 80~95%
- 완전 통제
- 마케팅도 본인 몫
4.2 책 쓰는 시간
현실: **평균 1000~1500시간**. 18개월 기준으로 주 15시간 (평일 저녁 + 주말).
**$30K 선인세**를 시간당 환산하면 $20~$30. 본업보다 훨씬 적음.
**왜 쓰는가?**: 돈이 아니라 **브랜드, 권위, 커리어**. 책 저자 타이틀은 평생 갑.
4.3 성공 사례 — DDIA (Designing Data-Intensive Applications)
- Martin Kleppmann 저
- O'Reilly 2017년
- 20만 부+ 판매
- 실리콘밸리 면접 준비 필독서
- 저자는 케임브리지 리서처 + 여러 컨설팅
**비결**: 한 분야(분산 시스템)의 결정판.
4.4 성공 사례 — Rust 관련 책들
- The Rust Programming Language (무료 + 유료 출판)
- Rust for Rustaceans (Jon Gjengset)
- Programming Rust (O'Reilly)
- Zero to Production in Rust (Luca Palmieri, self-publish)
**교훈**: 공식 책 + 심화 + 응용의 조합.
4.5 글의 진화 경로
블로그 글 → 시리즈 → eBook → 종이책
↓
컨퍼런스 발표 → 강의 → 북
블로그가 반응 좋으면 확장. **빅뱅 출간보다 점진적 성장**.
Chapter 5: 컨퍼런스 발표
5.1 왜 발표인가
- 블로그의 20배 임팩트 (집중된 청중)
- YouTube로 영구 자산
- 네트워크 폭발적 확장
- 승진 패킷의 큰 무기
5.2 CFP (Call for Proposal)
- 발표 제목 + 초록 제출
- 합격률 5~20% (유명 컨퍼런스)
- **초록의 질이 합격 좌우**
**좋은 초록**:
1. 구체적 제목 ("우리가 X를 Y로 전환하며 배운 것")
2. 문제 + 해결 + 교훈
3. 청중 Takeaway 명시
4. 발표자 크레덴셜
5.3 한국의 주요 컨퍼런스
- **FEConf**: 프론트엔드
- **JSConf Korea**: JavaScript
- **파이콘 한국**: Python
- **SIF (Samsung Innovation Forum)**
- **NHN FORWARD**
- **NAVER DEVIEW**
- **Kakao if(kakao)**
- **우아콘**: 배민
- **Toss PLANET**
5.4 글로벌 컨퍼런스
- **KubeCon** (CNCF): K8s/cloud-native
- **Strange Loop** (2023 종료): deep CS
- **QCon**: 실무 중심
- **RustConf, GopherCon, PyCon, RubyConf**
- **JSConf, React Summit, Next.js Conf**
- **Monktoberfest**: 개발자 문화/커리어
5.5 발표 준비
**8~12주 전**:
- 초록 제출
- 초안 슬라이드
**6주 전**:
- 내부 리허설 (동료 2~3명)
- 데모 스크립트
**2주 전**:
- 외부 리허설 (유사 커뮤니티)
- 타임 체크
**당일**:
- 1시간 일찍 도착
- 장비 테스트
- 백업 노트북
5.6 슬라이드 디자인
- **1 아이디어 = 1 슬라이드**
- 텍스트 최소 (발표자가 말하게)
- 폰트 28pt+
- 고해상도 스크린샷
- 복잡한 아키텍처는 여러 단계로 빌드업
5.7 Q&A 다루기
- 답 모르면 "좋은 질문인데 확실치 않다, 나중에 공유" OK
- 논쟁적 질문: 감정 배제
- 긴 질문: 요약 후 답변
5.8 성공 사례 — Bryan Cantrill (Oxide CTO)
- Sun Microsystems에서 DTrace 공동 개발
- 발표가 이야기 형식, 유머 강함
- "Scheduling Policy Hang" 류 기술 드라마
- YouTube 조회수 수십만+
**교훈**: 기술 + 스토리텔링.
Chapter 6: Staff+ 승진 패킷
6.1 Google Promo Packet
- 10~50페이지
- 매니저 + 본인이 공동 작성
- 4~7명 Peer review
- Calibration committee 심사
6.2 구성
1. **Summary**: 한 줄 추천
2. **Impact**: 6~12개월 동안의 주요 기여
3. **Complexity**: 기술 난이도
4. **Scope**: 팀 → 조직 → 회사 레벨
5. **Leadership**: 멘토링, 인터뷰, 외부
6. **Feedback**: Peer 코멘트
6.3 각 기여를 서술하는 포맷 (STAR)
**S**ituation: 맥락
**T**ask: 내 책임
**A**ction: 내가 한 행동
**R**esult: 측정 가능한 결과
**예**:
> "[S] 결제 시스템 p99 800ms로 사용자 이탈률 12%.
> [T] Staff Eng로 성능 개선 오너십.
> [A] 분산 캐시 도입 + 쿼리 최적화 + async 처리.
> [R] p99 150ms, 이탈률 5% 감소, 매출 $2M 증가."
6.4 Scope의 중요성
- **Senior**: 팀 문제 해결
- **Staff**: 팀을 넘어 영향
- **Senior Staff**: 조직 전체
- **Principal**: 회사 전체
같은 프로젝트도 "혼자 만들었다" vs "5개 팀과 협업해 표준화" 설명 차이.
6.5 Peer Feedback 요청
- 다양한 시각 (상/하/동급)
- 구체적 사례 부탁
- 양보다 질
6.6 떨어진 후
- 매니저와 솔직한 대화
- Gap 파악 (Impact? Leadership? Writing?)
- 6개월 계획 수립
- 다음 사이클 재도전
Chapter 7: AI 시대의 글쓰기
7.1 AI로 하지 말 것
- **전체 글 생성**: 금방 들키고, 개성 없음
- **대충 출력 복붙**: 할루시네이션 위험
- **내 생각 없이 의존**
7.2 AI로 하면 좋은 것
**1) 아이디어 브레인스토밍**:
"이 Design Doc 주제로 대안 3가지만 제안해줘. 장단점 포함."
**2) 구조 피드백**:
"이 블로그 초안의 논리 구조 약점을 지적해줘."
**3) 문법/어색함 교정**:
"이 문장을 자연스러운 영어로 다듬어줘. 원래 뜻 유지."
**4) 예상 질문**:
"이 RFC에 기술 리드가 할 수 있는 반론 5개."
**5) 요약 작성**:
"긴 포스트의 TL;DR 3줄."
7.3 AI를 쓸 때의 윤리
- **공개**: "이 글 초안은 AI 도움 받았음" 선언
- **사실 검증**: AI 출력은 반드시 확인
- **개성 유지**: 본인 문체 우선
7.4 Copilot in Writing
- VS Code에서 Markdown도 자동완성
- 문장 완성, 불릿 생성
- **주의**: 문장을 끝맺어 주되, 의미는 본인 결정
7.5 Claude/GPT 활용 워크플로우
1. 나: 초안 쓰기
2. AI: 구조 피드백
3. 나: 수정
4. AI: 문법/표현 다듬기
5. 나: 최종 확인, 개성 복원
6. AI: 제목 10개 제안 → 나: 1개 선택
Chapter 8: 한글 vs 영어
8.1 한글만 쓸 때
**장점**:
- 한국 독자 100% 소화
- 감정, 뉘앙스 자유
- 커뮤니티 더 가까움
**단점**:
- 글로벌 기회 제한
- 세계적 브랜드 어려움
8.2 영어만 쓸 때
**장점**:
- 글로벌 독자
- 해외 채용/컨설팅 유리
- 영어 실력 향상
**단점**:
- 한국 독자 감소
- 초기 어려움
8.3 한영 병행 전략
**옵션 A: 영어 원본 → 한글 번역 요약**
**옵션 B: 한글 원본 → 영어 짧은 요약**
**옵션 C: 주제별 언어 구분** (로컬 이슈 한글, 글로벌 이슈 영어)
이 블로그처럼 **완전 이중 언어**도 가능하지만 품 많이 듦.
8.4 한국 개발자의 영어 글쓰기 팁
- **단문 중심**: 복잡한 관계사절 회피
- **능동태**: "We decided to..." > "It was decided that..."
- **명료함 > 화려함**: 어려운 단어 ≠ 좋은 글
- **교정 도구**: Grammarly, Claude, DeepL Write
8.5 한글 블로그 좋은 예
- 박재성 (자바지기)
- 김영한 (인프런 강의 + 블로그)
- 우아한형제들 기술 블로그
- 카카오 테크 블로그
- 토스 테크 블로그
- 당근 기술 블로그
8.6 영어 글 한국 개발자 좋은 예
- **Dan Luu** (영상 인터뷰, Twitter)
- **Evan You** (Vue 창시자, 중국계지만 글로벌)
- **김재진 / Jake Seo 등 해외 활동 한국 개발자 소수**
한국 개발자 영어 블로그 활성화는 아직 여지 큼.
Chapter 9: 좋은 Documentation
9.1 Divio의 4가지 문서 유형
[Divio Documentation System](https://documentation.divio.com/)이 제안:
1. **Tutorials**: 배우기 위해 (초심자 대상)
2. **How-to guides**: 특정 작업 완수
3. **Reference**: 정확한 기술 정보
4. **Explanation**: 배경, 왜
**4가지를 섞으면 혼란**. 분리해서 작성.
9.2 좋은 README
- **Hero**: 뭐 하는 프로젝트인지 1줄
- **Install**: 3줄 이내 시작
- **Quickstart**: 코드 예시
- **Badges**: CI, 버전, 라이선스
- **Table of Contents**: 긴 경우
- **Contributing, License, Acknowledgments**
9.3 Changelog
- **Keep a Changelog** 스타일
- Added / Changed / Deprecated / Removed / Fixed / Security
- 사용자 중심 표현 ("Breaking: ..." 명시)
9.4 API 문서
- **OpenAPI/Swagger** 자동 생성
- 예시 요청/응답 필수
- 에러 코드 전체
- 레이트 리밋 명시
Chapter 10: 글쓰기 근력 키우기
10.1 매일 100단어
중요한 건 **일관성**. 매일 100단어 = 1년에 36,500단어 ≈ 블로그 30~40편.
10.2 읽기 = 쓰기
좋은 글 읽기. 분석하며 읽기. "이 문장을 왜 이렇게 썼을까" 생각하기.
**추천 읽기**:
- Paul Graham essays (간결함)
- Dan Luu (깊이)
- Julia Evans (명료함)
- Simon Willison (꾸준함)
10.3 피드백 받기
- 같은 글 쓰는 동료
- Discord/Slack 글쓰기 채널
- 가족/친구 (비전문가가 이해하는지)
10.4 퇴고의 기술
**1차**: 의미가 통하는가
**2차**: 구조가 명료한가
**3차**: 단어가 정확한가
**4차**: 리듬이 자연스러운가
**최소 하루 묵힌 후** 다시 읽기.
Chapter 11: 글쓰기 안티패턴 10가지
1) "왜"를 빼먹음
무엇을 할지만 적고, 왜 하는지 없음. **"Why" 먼저, "What" 나중**.
2) Jargon 남발
독자가 모르는 용어 설명 없이 사용. **첫 등장 때 설명**.
3) 수동태 과다
"결정되었다"보다 "팀이 결정했다". 주체 명확.
4) Bullet 남용
모든 문장이 bullet. 서사 없음. **서술형 문단이 논리를 강제**.
5) Hedge 말
"maybe", "perhaps", "might". 자신감 부족. **확실하면 단언**.
6) 불필요한 서론
"이 글에서는 이러이러한 것들을 다룰 예정입니다"는 나쁜 서론. **바로 핵심**.
7) 그림 없음
아키텍처 다이어그램, 시퀀스 다이어그램 없음. **Excalidraw/Mermaid 활용**.
8) 결론 없음
논의만 길게, "그래서 뭐?"가 없음. **Call to action 또는 takeaways**.
9) 교정 생략
오타, 문법 오류. 신뢰 깎임. **발행 전 2회 읽기**.
10) Audience 혼선
초심자를 위한 글인지 전문가용인지 불명확. **첫 단락에 명시**.
Chapter 12: 12항목 글쓰기 체크리스트
- [ ] **제목**: 구체적, 검색 가능
- [ ] **첫 단락**: 왜 읽어야 하는지 명확
- [ ] **목차**: 긴 글이면 필수
- [ ] **Why → What → How 순서**
- [ ] **그림/다이어그램**: 복잡한 개념마다
- [ ] **코드 예시**: 실제로 돌아가는
- [ ] **대안 논의**: 선택하지 않은 이유
- [ ] **숫자**: 추측 대신 측정
- [ ] **Takeaways**: 독자가 뭘 얻었는가
- [ ] **참고 문헌**: 원본 링크
- [ ] **교정**: 맞춤법, 링크
- [ ] **SEO 메타데이터**: Description, OG image
마치며 — 글쓰기는 엔지니어링 스킬
원칙 1: 쓰는 것 = 생각하는 것
글로 못 쓰면 이해 못 한 것. Einstein: "If you can't explain it simply, you don't understand it well enough."
원칙 2: 자주 쓴다 > 잘 쓴다
완벽주의 버리기. 첫 100편은 어색해도 계속. 복리 효과.
원칙 3: 다양한 형식
Design Doc, RFC, Blog, Book, Talk — 형식별 근육. 한 가지만 잘하면 한계.
원칙 4: 피드백이 가장 빠른 성장
동료/독자 피드백 적극 요청. 부끄러움 이기기.
원칙 5: 진정성 > 유려함
가식 없는 경험담이 최고의 콘텐츠. 실패담 공유 망설이지 말기.
원칙 6: 원본을 읽어라
- [On Writing Well - William Zinsser](https://www.goodreads.com/book/show/53343.On_Writing_Well)
- [Designing Data-Intensive Applications - Martin Kleppmann](https://dataintensive.net/)
- [Writing docs as a developer - Julia Evans zines](https://wizardzines.com/)
- [Design Docs at Google - Malte Ubl](https://www.industrialempathy.com/posts/design-docs-at-google/)
- [Staff Engineer's Path - Tanya Reilly](https://noidea.dog/)
- [Storytelling with Data - Cole Knaflic](https://www.storytellingwithdata.com/)
다음 글 예고 — "개발자 재정 완전 가이드: 연봉, 스톡옵션, RSU, 401k, 창업 자금까지"
Season 3 Ep 8은:
- 연봉 협상의 과학 (Levels.fyi, Blind 활용)
- RSU vs Stock Option: 행사 시점, 세금
- ESOP과 한국 세법
- 401k / IRA (미국), 퇴직연금 (한국)
- 스타트업 지분 — Vesting Cliff, Exit 시나리오
- 부동산 vs 주식 vs 회사 지분
- 미국 진출 시 세무 (H1B, L1 비자 이슈)
- FIRE (Financial Independence Retire Early)
- 창업 시 자금 흐름과 희석
- 40대 개발자의 재정 계획
다음 글에서.
현재 단락 (1/402)
Senior Engineer 5년차: