A blog writing guide that explains technology through analogies and storytelling centered on "Why"
Core Philosophy
Things You Must Never Do
❌ "A는 B이다. C는 D이다. E는 F이다." (단순 나열)
❌ 정의부터 시작하는 백과사전식 설명
❌ 논리적으로 맞지 않는 억지 비유
❌ 독자가 왜 이걸 알아야 하는지 모른 채 진행
Things You Must Always Do
✅ "왜 이게 필요한가?"부터 시작
✅ 독자가 아는 것 → 모르는 것으로 연결 (비유)
✅ 문제 상황 공감 → 해결책 제시 → 그 이유 설명
✅ 비유는 논리적 정확성 검증 후 사용
Post Structure Template
Step 1: Hook Introduction (Capturing the Reader's Interest)
Pattern A: Start with a Problem Situation
"여러분은 이런 경험이 있으신가요? [구체적 상황 묘사]"
"어느 날, [문제 발생]. 원인을 찾아보니..."
Pattern B: Start with a Question
"왜 [기술/개념]이 필요할까요?"
"[기술 A]와 [기술 B]의 진짜 차이는 뭘까요?"
Pattern C: Correcting a Misconception
"많은 개발자들이 [개념]을 [잘못된 이해]로 알고 있습니다. 하지만..."
"'[용어]'라는 이름 때문에 오해하기 쉽지만, 실제로는..."
Pattern D: Start with a Real Example
"지난 주, 프로덕션에서 [문제]가 발생했습니다. 6시간의 디버깅 끝에..."
"면접에서 이런 질문을 받았습니다. '[질문]' 어떻게 대답하시겠어요?"
Step 2: Developing the Body
Structure: Why → What → How
## 왜 필요한가? (Why)
- 이 기술/개념이 해결하는 문제
- 없으면 어떤 고통이 있는지
- 비즈니스/개발 관점의 필요성
## 핵심 개념 (What)
- 비유로 직관적 이해 제공
- 정확한 정의와 동작 원리
- 다른 개념과의 관계/차이점
## 실제 적용 (How)
- 코드 예시 또는 설정 방법
- 주의사항과 Best Practice
- 실제 사용 사례
Step 3: Summary and Conclusion
## 정리
> **핵심**: [한 문장으로 요약]
- 포인트 1
- 포인트 2
- 포인트 3
## 더 알아보기
- [심화 질문 1]?
- [심화 질문 2]?
- [관련 개념]과의 연결은?
Analogy Writing Guide
Conditions for a Good Analogy
- Logical Correspondence: Each element of the analogy corresponds 1:1 with the actual concept
- Familiarity: A situation/object the reader already knows well
- Acknowledging Limitations: Explicitly state the parts the analogy cannot explain
Proven Analogy Patterns
| Technical Concept | Analogy | Correspondence |
|---|---|---|
| Blocking I/O | Restaurant Counter | Waiting for the next customer until the order is complete = Occupying a Thread |
| Non-blocking I/O | Pager | Notifying when the food is ready = Callback/Event |
| Index | Book Index | Flipping through pages without an index vs. finding it directly with the index |
| Thread Pool | Bank Teller Window | Number of windows = Number of Threads, Line = Queue |
| Cache | Frequently Used Books on the Desk | No need to go all the way to the study (DB) |
| Load Balancer | Amusement Park Line Guide | Guiding to the shortest line |
| Transaction | Bank Transfer | All succeed or all are canceled |
| Middleware | Airport Security Checkpoint | A gateway that requests pass through before reaching their destination |
Checklist When Writing Analogies
□ 이 비유의 각 요소가 실제 개념과 정확히 대응하는가?
□ 비유가 오히려 오해를 불러일으키지 않는가?
□ 독자가 이 비유 상황을 경험해본 적 있는가?
□ 비유의 한계점을 명시했는가?
Example of Stating Analogy Limitations
> 물론 이 비유에는 한계가 있습니다. 실제 [기술]에서는 [비유와 다른 점]이 있기 때문입니다. 하지만 [핵심 개념]을 이해하는 데는 충분합니다.
Patterns for Explaining "Why"
Pattern 1: Problem → Pain → Solution
## 문제 상황
"기존 방식에서는 [문제]가 있었습니다."
## 그래서 뭐가 불편한데?
"이로 인해 [구체적 고통/비효율]이 발생합니다."
## 그래서 등장한 것이
"[기술/개념]은 이 문제를 [방법]으로 해결합니다."
Pattern 2: Historical Context
## 탄생 배경
"[연도], [상황]에서 [인물/조직]이 [기술]을 만들었습니다."
## 왜 그때 필요했나?
"당시에는 [시대적 제약/요구사항]이 있었기 때문입니다."
## 현재의 의미
"지금도 [핵심 원리]는 여전히 유효합니다. 왜냐하면..."
Pattern 3: Necessity Through Comparison
## A 방식 (기존)
- 장점: ...
- 단점: [이 부분이 문제]
## B 방식 (새로운)
- [A의 문제]를 해결
- 트레이드오프: ...
## 언제 뭘 써야 하나?
- A가 적합한 상황: ...
- B가 적합한 상황: ...
Visualization Guide
Using Mermaid Diagrams
Flowchart (Explaining a Process)
```mermaid
flowchart LR
A[요청] --> B{조건}
B -->|Yes| C[처리 A]
B -->|No| D[처리 B]
C --> E[응답]
D --> E
**시퀀스 다이어그램 (상호작용 설명)**
```markdown
```mermaid
sequenceDiagram
participant Client
participant Server
participant DB
Client->>Server: 요청
Server->>DB: 쿼리
DB-->>Server: 결과
Server-->>Client: 응답
**비교표 (개념 대조)**
```markdown
| 구분 | 방식 A | 방식 B |
|------|--------|--------|
| 특징 | ... | ... |
| 장점 | ... | ... |
| 단점 | ... | ... |
| 적합한 상황 | ... | ... |
Code Example Rules
## 코드 예시 작성 순서
1. 먼저 개념을 비유/설명으로 이해시킨다
2. "코드로 보면 이렇습니다" 로 연결
3. 코드 제시
4. 코드의 각 부분이 개념과 어떻게 대응하는지 설명
Writing Checklist
Introduction Verification
□ 첫 문장에서 독자의 관심을 끄는가?
□ "왜 이 글을 읽어야 하는지" 3문단 내에 드러나는가?
□ 대상 독자가 공감할 문제/상황으로 시작하는가?
Body Verification
□ "왜" → "무엇" → "어떻게" 순서를 따르는가?
□ 비유가 논리적으로 정확한가?
□ 단순 나열이 아닌 인과관계로 연결되는가?
□ 독자가 이미 아는 것에서 모르는 것으로 연결하는가?
□ 코드/다이어그램이 설명을 보완하는가?
Conclusion Verification
□ 핵심 내용을 한 문장으로 요약했는가?
□ 독자가 다음에 뭘 해야 할지/알아야 할지 제시했는가?
□ 심화 학습 방향을 안내했는가?
Overall Verification
□ 글 전체를 처음부터 끝까지 읽었을 때 논리적 흐름이 자연스러운가?
□ 전문 용어를 처음 사용할 때 정의를 제공했는가?
□ 이 글을 읽은 독자가 "왜"를 설명할 수 있게 되었는가?
Example: Before & After
Before (Simple Listing)
## Redis란?
Redis는 인메모리 데이터 저장소입니다. Key-Value 구조를 사용합니다.
다양한 데이터 타입을 지원합니다. String, List, Set, Hash 등이 있습니다.
싱글 스레드로 동작합니다. 빠른 성능을 제공합니다.
After (Why + Analogy)
## 왜 Redis가 필요할까?
데이터베이스에서 같은 데이터를 반복해서 읽어오는 상황을 상상해보세요.
마치 **도서관에서 책을 빌릴 때마다 서고 깊숙이 들어가는 것**과 같습니다.
자주 보는 책이라면 **책상 위에 두고 바로 꺼내 보는 게** 훨씬 빠르겠죠?
Redis가 바로 그 "책상"입니다.
- **서고 (디스크 DB)**: 용량 크지만 느림
- **책상 (Redis)**: 용량 작지만 빠름
자주 접근하는 데이터를 Redis에 두면, 매번 느린 DB까지 가지 않아도 됩니다.
> "그런데 왜 싱글 스레드인데 빠른 거예요?"
여기서 또 다른 비유가 필요합니다. [계속...]
Writing Process
1. 주제 선정
- 독자가 "왜"를 궁금해할 만한 주제인가?
2. 핵심 질문 정의
- 이 글을 읽은 독자가 답할 수 있어야 할 질문은?
3. 비유 설계
- 핵심 개념을 설명할 비유는?
- 비유가 논리적으로 정확한가?
4. 구조 설계
- 도입: 어떤 문제/질문으로 시작?
- 본론: 왜 → 무엇 → 어떻게
- 정리: 핵심 요약과 다음 단계
5. 시각화 계획
- 다이어그램이 필요한 부분은?
- 코드 예시가 필요한 부분은?
6. 초안 작성 → 검토 → 수정
Common Mistakes
1. Logical Fallacies in Analogies
❌ "Redis는 냉장고입니다" (왜 냉장고? 차갑다는 것 외에 연결점 없음)
✅ "Redis는 책상 위 메모지입니다" (빠른 접근, 임시 저장, 용량 제한 대응)
2. Explaining Only "What" Without "Why"
❌ "인덱스는 B-Tree 구조로 되어 있습니다."
✅ "색인 없이 두꺼운 책에서 단어를 찾으려면 처음부터 넘겨야 합니다.
인덱스가 있으면 바로 해당 페이지로 갈 수 있죠.
DB 인덱스도 마찬가지입니다."
3. Ignoring the Reader's Level
❌ "당연히 알겠지만 CAS 연산은..."
✅ "CAS(Compare-And-Swap)는 [간단한 설명]. 처음 들어보셔도 괜찮습니다."
If you write a tech blog following this guide, readers can read while feeling **"Ah, so that's why this is needed."**