Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — "코딩은 최고인데 왜 승진 안 됩니까?"

Senior Engineer 5년차:

"기술은 팀 최고예요. 코드 품질도 탑이에요. 근데 Staff 승진 패킷에서 매번 떨어져요."

답: Staff+ 레벨은 글로 평가된다. 당신이 쓴 Design Doc, Postmortem, RFC, 블로그, 메모가 당신의 영향력. 코드 1만 줄보다 잘 쓴 Design Doc 한 장이 승진에 유리하다.

구글의 유명한 내부 연구: Staff+ 레벨의 글쓰기 시간 비중은 30~50%. "개발자"라기보단 "기술 작가".

이 글은:

Design Doc — 구조, 템플릿, 실패 사례
RFC 프로세스 — Rust/Python/Node 비교
기술 블로그 — Julia Evans, Dan Luu, Stratechery 해부
기술서 — O'Reilly, Manning, 자가 출판
컨퍼런스 발표 — CFP부터 발표까지
Staff+ 승진 패킷
AI 시대 글쓰기 — Claude/Copilot 활용법
한글 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의 특징

문제부터 시작: 무엇이 왜 문제인가. "마이크로서비스를 도입하자"가 아니라 "배포 시간이 45분 → 사용자 불만"
측정 가능한 목표: "더 빠르게"가 아니라 "p99 < 200ms"
대안 비교 솔직: "우리 것만 좋아"가 아니라 "A는 빠르지만 비용 2배, B는 싸지만 복잡도 높음"
반대 의견 반영: FAQ 섹션에 "이렇게 생각하실 수 있는데..."
숫자로 근거: 벤치마크, 비용 추정, 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 프로세스

Discussion: Rust Internals forum에서 아이디어 브레인스토밍
PR 제출: rust-lang/rfcs 저장소에 Markdown PR
커뮤니티 토론: 수 주~수 개월
Final Comment Period (FCP): 10일간 최종 의견
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 쓸 때의 팁

원샷 완벽 지양: 초안 공개, 피드백 반영 여러 버전
동기 설명 충분: "왜 지금, 왜 이 방식"
Alternative considered: 반드시
Migration path: 파괴적 변경이면 마이그레이션 경로
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% (유명 컨퍼런스)
초록의 질이 합격 좌우

좋은 초록:

구체적 제목 ("우리가 X를 Y로 전환하며 배운 것")
문제 + 해결 + 교훈
청중 Takeaway 명시
발표자 크레덴셜

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+ 승진 패킷

10~50페이지
매니저 + 본인이 공동 작성
4~7명 Peer review
Calibration committee 심사

6.2 구성

Summary: 한 줄 추천
Impact: 6~12개월 동안의 주요 기여
Complexity: 기술 난이도
Scope: 팀 → 조직 → 회사 레벨
Leadership: 멘토링, 인터뷰, 외부
Feedback: Peer 코멘트

6.3 각 기여를 서술하는 포맷 (STAR)

Situation: 맥락 Task: 내 책임 Action: 내가 한 행동 Result: 측정 가능한 결과

예:

"[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 활용 워크플로우

나: 초안 쓰기
AI: 구조 피드백
나: 수정
AI: 문법/표현 다듬기
나: 최종 확인, 개성 복원
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이 제안:

Tutorials: 배우기 위해 (초심자 대상)
How-to guides: 특정 작업 완수
Reference: 정확한 기술 정보
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항목 글쓰기 체크리스트

마치며 — 글쓰기는 엔지니어링 스킬

원칙 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: 원본을 읽어라

다음 글 예고 — "개발자 재정 완전 가이드: 연봉, 스톡옵션, 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대 개발자의 재정 계획

다음 글에서.