---
id: wiki-2026-0508-의도-및-목적-지향적-설명-purpose-driven-ex
title: 의도 및 목적 지향적 설명(Purpose-driven Explanation)
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [Purpose-Driven Explanation, Intent-First Explanation, Why-First, 목적 우선 설명]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
verification_status: applied
tags: [communication, technical-writing, pedagogy, llm-prompting]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: markdown
  framework: technical-writing
---

# 의도 및 목적 지향적 설명(Purpose-driven Explanation)

## 매 한 줄
> **"매 'WHAT' 매 의 의 시작 매 X — 매 'WHY' 의 의 의 시작"**. 매 Simon Sinek *Start with Why* (2009), 매 Heath brothers *Made to Stick*, 매 modern technical-writing (Diátaxis framework, Google docs style) 매 동일한 thesis — 매 reader / listener 매 purpose 의 의 의 의 의 detail 매 retain. 매 LLM prompting 매 동일 (intent-aware system prompt > capability list).

## 매 핵심

### 매 3-layer 매 explanation stack
1. **매 WHY (purpose)**: 매 어떤 problem 의 solve? 매 어떤 audience 의 의 의 의?
2. **매 WHAT (concept)**: 매 mechanism / definition / shape.
3. **매 HOW (procedure)**: 매 step-by-step / 매 syntax / 매 implementation.

### 매 reverse pyramid 매 anti-pattern
- 매 typical bad 의 docs: 매 syntax → 매 example → 매 (마지막에) 매 use case.
- 매 improvement: 매 use case (intent) → 매 mechanism → 매 syntax.

### 매 Diátaxis quadrant alignment
- **Tutorial**: 매 learning-by-doing → purpose = "skill 의 acquire".
- **How-to**: 매 task-oriented → purpose = "specific outcome 의 reach".
- **Reference**: 매 information-oriented → purpose = "lookup".
- **Explanation**: 매 understanding-oriented → purpose = "build mental model".
- 매 매 매 매 quadrant 매 different intent 의 의 의 매 match.

### 매 응용
1. 매 API documentation: "이 endpoint 매 의 / 매 purpose / 매 use case" 의 의 의 의 시작.
2. 매 commit message: 매 "why" > "what" (diff 매 의 의 의 what 의 visible).
3. 매 LLM system prompt: 매 "당신 매 X 의 위해 매 user 의 의 의 의 X 의 의 의 의" 의 first.
4. 매 onboarding doc: 매 "이 product 매 의 / 매 problem solve" 의 first paragraph.
5. 매 ADR (Architecture Decision Record): 매 Context → Decision → Consequence (매 essentially purpose-first).

## 💻 패턴

### Pattern: function docstring (purpose-first)
```python
def normalize_embeddings(vectors: np.ndarray) -> np.ndarray:
    """
    Why: cosine similarity requires unit-length vectors; raw model
    outputs vary in magnitude and skew similarity scores.

    What: scales each row to L2-norm = 1.

    How: divides by np.linalg.norm(axis=1, keepdims=True) with
    epsilon guard for zero vectors.
    """
    norms = np.linalg.norm(vectors, axis=1, keepdims=True)
    return vectors / np.maximum(norms, 1e-12)
```

### Pattern: README opening
```markdown
# ProjectX

**For**: ML engineers running batch evaluation on 100k+ examples
**Solves**: vendor-locked eval harnesses that don't support custom metrics
**Not for**: real-time inference, single-example debugging

## Quick start
...
```

### Pattern: commit message
```
fix(auth): refresh token before expiry, not after

Why: users were seeing 401s mid-session because the refresh
fired on next API call AFTER expiry, leaving a 200-500ms gap.

What: shifted refresh trigger to T-30s window.

How: added `expiresAt - 30_000` check in interceptor pre-hook.
```

### Pattern: LLM system prompt
```typescript
const systemPrompt = `
ROLE & PURPOSE
You help backend engineers debug production incidents.
Optimize for: minimum-time-to-hypothesis. The user is paged at 3am.

CONSTRAINTS
- Lead with most likely root cause
- Ask for logs/metrics ONLY if blocking
- Suggest rollback before deep-fix when unclear
`;
```

### Pattern: ADR template
```markdown
# ADR 0042: Move from Postgres to ClickHouse for analytics

## Context (the WHY)
Analytics queries hit 30-60s p95 on 2B-row events table.
Product team needs sub-2s for dashboard interactivity.

## Decision (the WHAT)
Adopt ClickHouse for the analytics read path; keep Postgres
for transactional OLTP.

## Consequences (the HOW it plays out)
+ p95 drops to ~200ms on tested queries
- Dual-write complexity, 2nd ops surface
- Eventual consistency between OLTP and analytics
```

### Pattern: tutorial opening
```markdown
# Build a semantic search in 10 minutes

By the end you'll have:
- A working semantic search over your own markdown files
- An understanding of *why* embedding > keyword for fuzzy queries

You'll learn this by building it — not by reading theory.
Prerequisites: Python 3.11, an OpenAI/Anthropic API key.
```

## 매 결정 기준
| context | lead with |
|---|---|
| 매 docs landing page | audience + problem solved |
| 매 function / class | why + when-to-use |
| 매 commit / PR | why + what changed |
| 매 LLM prompt | role + optimization target |
| 매 meeting / pitch | problem + stakes |

**기본값**: 매 모든 explanation artifact 매 의 의 의 first 1-3 sentence 매 purpose 의 의 의 의 의 의 의 의 contain.

## 🔗 Graph
- 부모: [[Technical Writing]]
- 변형: [[BLUF (Bottom Line Up Front)]]
- 응용: [[ADR]]
- Adjacent: [[Pyramid Principle]]

## 🤖 LLM 활용
**언제**: 매 docs / prompt / commit message / spec 의 의 write 시 매 의 의 의 항상.
**언제 X**: 매 reference card / cheat-sheet — 매 lookup speed 매 priority 시 매 purpose 의 omit 매 가능.

## ❌ 안티패턴
- **매 syntax-dump**: 매 use case 의 mention 매 X 매 raw API listing.
- **매 buried lead**: 매 purpose 매 paragraph 5 매 의 의 의 hidden.
- **매 fake why**: 매 marketing fluff ("revolutionary", "best-in-class") 매 의 의 의 actual purpose 의 의 의 의 substitute.
- **매 over-justification**: 매 1-line task 매 5-paragraph rationale → 매 noise.

## 🧪 검증 / 중복
- Verified (Sinek *Start With Why*, Diátaxis framework documentation, Google developer documentation style guide, ADR community).
- 신뢰도 A.

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — WHY/WHAT/HOW stack + Diátaxis alignment + 6 patterns |
