LabHub

블로그

개발자 글쓰기 완전 가이드: Design Doc, RFC, Blog, 책, 컨퍼런스 발표까지 (2025)

2026-04-15 · 25 분 읽기 · #writing#design-doc#rfc#tech-blog#conference-talk#documentation#staff-plus#career#communication#deep-dive

한국어English日本語

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

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의 흔한 실수

1.5 리뷰 받기

리뷰어 선택:

리뷰 기간: 1~4주. 짧으면 피드백 부족, 길면 타이밍 놓침.

피드백 처리:

1.6 실제 사례 — Amazon의 Narrative

Amazon은 6-page narrative memo. 구조 덜 엄격하지만:

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은 Rust보다 더 공식적. 유명한 PEP:

2.4 Node.js의 TSC

Node는 RFC 대신 TSC(Technical Steering Committee) 투표 + Collaborator 합의.

2.5 IETF RFC vs Project RFC

혼동 주의: IETF RFC (인터넷 표준, HTTP/TCP 등)와 프로젝트 RFC는 다름.

2.6 RFC 쓸 때의 팁

  1. 원샷 완벽 지양: 초안 공개, 피드백 반영 여러 버전
  2. 동기 설명 충분: "왜 지금, 왜 이 방식"
  3. Alternative considered: 반드시
  4. Migration path: 파괴적 변경이면 마이그레이션 경로
  5. Backwards compatibility: 호환성 명시

Chapter 3: 기술 블로그 — 장기 자산

3.1 왜 블로그인가

Staff+ 엔지니어의 공통점: 블로그. 이유:

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 분석

교훈: 전문 영역 + 독특한 스타일 = 팬덤.

3.4 Dan Luu 분석

교훈: 희귀 주제 + 깊이 = 권위.

3.5 Stratechery (Ben Thompson)

교훈: 뉴스를 쫓지 않고 분석 프레임워크를 만듦.

3.6 블로그 시작하기

플랫폼 선택:

자체 호스팅 권장: 장기 자산은 본인 소유여야.

3.7 글감 찾기

3.8 발행 주기

일관성 > 양. 매주 허덕이기보다 월 1편 양질.

3.9 SEO와 배포

SEO:

배포:

Chapter 4: 기술서 출간

4.1 출판사 선택

O'Reilly:

Manning:

Pragmatic Bookshelf:

Packt:

Self-publishing (Leanpub, Gumroad):

4.2 책 쓰는 시간

현실: 평균 1000~1500시간. 18개월 기준으로 주 15시간 (평일 저녁 + 주말).

$30K 선인세를 시간당 환산하면 $20~$30. 본업보다 훨씬 적음.

왜 쓰는가?: 돈이 아니라 브랜드, 권위, 커리어. 책 저자 타이틀은 평생 갑.

4.3 성공 사례 — DDIA (Designing Data-Intensive Applications)

비결: 한 분야(분산 시스템)의 결정판.

4.4 성공 사례 — Rust 관련 책들

교훈: 공식 책 + 심화 + 응용의 조합.

4.5 글의 진화 경로

블로그 글 → 시리즈 → eBook → 종이책
     ↓
  컨퍼런스 발표 → 강의 → 북

블로그가 반응 좋으면 확장. 빅뱅 출간보다 점진적 성장.

Chapter 5: 컨퍼런스 발표

5.1 왜 발표인가

5.2 CFP (Call for Proposal)

좋은 초록:

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

5.3 한국의 주요 컨퍼런스

5.4 글로벌 컨퍼런스

5.5 발표 준비

8~12주 전:

6주 전:

2주 전:

당일:

5.6 슬라이드 디자인

5.7 Q&A 다루기

5.8 성공 사례 — Bryan Cantrill (Oxide CTO)

교훈: 기술 + 스토리텔링.

Chapter 6: Staff+ 승진 패킷

6.1 Google Promo Packet

6.2 구성

  1. Summary: 한 줄 추천
  2. Impact: 6~12개월 동안의 주요 기여
  3. Complexity: 기술 난이도
  4. Scope: 팀 → 조직 → 회사 레벨
  5. Leadership: 멘토링, 인터뷰, 외부
  6. 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의 중요성

같은 프로젝트도 "혼자 만들었다" vs "5개 팀과 협업해 표준화" 설명 차이.

6.5 Peer Feedback 요청

6.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를 쓸 때의 윤리

7.4 Copilot in Writing

7.5 Claude/GPT 활용 워크플로우

  1. 나: 초안 쓰기
  2. AI: 구조 피드백
  3. 나: 수정
  4. AI: 문법/표현 다듬기
  5. 나: 최종 확인, 개성 복원
  6. AI: 제목 10개 제안 → 나: 1개 선택

Chapter 8: 한글 vs 영어

8.1 한글만 쓸 때

장점:

단점:

8.2 영어만 쓸 때

장점:

단점:

8.3 한영 병행 전략

옵션 A: 영어 원본 → 한글 번역 요약 옵션 B: 한글 원본 → 영어 짧은 요약 옵션 C: 주제별 언어 구분 (로컬 이슈 한글, 글로벌 이슈 영어)

이 블로그처럼 완전 이중 언어도 가능하지만 품 많이 듦.

8.4 한국 개발자의 영어 글쓰기 팁

8.5 한글 블로그 좋은 예

8.6 영어 글 한국 개발자 좋은 예

한국 개발자 영어 블로그 활성화는 아직 여지 큼.

Chapter 9: 좋은 Documentation

9.1 Divio의 4가지 문서 유형

Divio Documentation System이 제안:

  1. Tutorials: 배우기 위해 (초심자 대상)
  2. How-to guides: 특정 작업 완수
  3. Reference: 정확한 기술 정보
  4. Explanation: 배경, 왜

4가지를 섞으면 혼란. 분리해서 작성.

9.2 좋은 README

9.3 Changelog

9.4 API 문서

Chapter 10: 글쓰기 근력 키우기

10.1 매일 100단어

중요한 건 일관성. 매일 100단어 = 1년에 36,500단어 ≈ 블로그 30~40편.

10.2 읽기 = 쓰기

좋은 글 읽기. 분석하며 읽기. "이 문장을 왜 이렇게 썼을까" 생각하기.

추천 읽기:

10.3 피드백 받기

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은:

다음 글에서.

원문 보기: https://www.youngju.dev/blog/culture/2026-04-15-developer-writing-complete-guide-design-doc-rfc-blog-book-conference-talk-deep-dive-guide-2025

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다