"Think Before Coding — 섣부른 가정을 막는 법"

# Think Before Coding — 섣부른 가정을 막는 법

"구현 시작하기 전에 한 번 생각해봐" — 사람한테 하는 말 같지만, AI에게도 같은 말이 필요하다.

모델에게 아무런 지침 없이 태스크를 주면 모델은 즉시 코드를 쓰기 시작한다. 확인 없이 해석하고, 가정을 숨기고, 결과물만 내놓는다. 그래야 "도움이 되는 것처럼 보이기" 때문이다.

Think Before Coding 원칙은 이 즉각 반응 패턴을 명시적으로 차단한다.

---

## 1. 원칙의 4가지 규칙

| 규칙 | 설명 |
|------|------|
| **State assumptions explicitly** | 불확실한 것은 가정으로 명시, 추측하지 않음 |
| **Present multiple interpretations** | 모호한 요청은 해석 여러 개를 제시하고 선택 요청 |
| **Push back when warranted** | 더 단순한 방법이 있으면 먼저 말함 |
| **Stop when confused** | 무엇이 불명확한지 명시하고 질문 |

---

## 2. CLAUDE.md 원문

andrej-karpathy-skills에서 이 원칙은 다음과 같이 구현된다.

```markdown
## Think Before Coding

Don't assume. Don't hide confusion. Surface tradeoffs.

- **State assumptions explicitly**: If uncertain, ask rather than guess
- **Present multiple interpretations**: When ambiguity exists, show options
- **Push back when warranted**: If a simpler approach exists, say so first
- **Stop when confused**: Name what's unclear and ask for clarification
```

단 6줄이다. 하지만 이 6줄이 모델 행동을 근본적으로 바꾼다.

---

## 3. 실전 비교 — CLAUDE.md 없을 때 vs 있을 때

### CLAUDE.md 없이 요청했을 때

```
유저: "사용자 데이터 캐싱 기능 추가해줘"

AI:   Redis를 사용해서 구현했습니다.
      - RedisClient.ts 생성
      - UserService.ts에 캐시 레이어 추가
      - TTL: 1시간으로 설정
      (... 코드 100줄 ...)
```

Redis가 프로젝트에 없을 수도 있다. 메모리 캐시로도 충분할 수 있다. 묻지 않았다.

### Think Before Coding 적용 후

```
유저: "사용자 데이터 캐싱 기능 추가해줘"

AI:   구현 전에 두 가지 해석이 가능합니다.

A) 인메모리 캐시 (Node.js Map / LRU-cache 라이브러리)
         → Redis 없이 바로 가능, 서버 재시작 시 초기화됨

B) Redis 캐시
         → 영속성·공유 가능, Redis 설치 필요

현재 package.json에 Redis 관련 패키지가 없어서 확인이 필요합니다.
      A로 진행할까요, 아니면 Redis를 추가할까요?
```

같은 요청인데 결과가 완전히 다르다.

---

## 4. 이 원칙이 효과를 내는 이유

모델에게 "질문하라"는 지시를 주면 모델은 질문하는 것이 올바른 행동이라고 인식한다. 훈련 중 "즉시 도움이 되는 모습"으로 학습된 관성을 명시적 지침으로 오버라이딩하는 것이다.

```
기본 행동:    태스크 수신 → 즉시 구현
지침 적용:    태스크 수신 → 가정 확인 → 모호성 표면화 → 구현
```

특히 **"push back when warranted"** 규칙이 강력하다. 모델이 더 단순한 방법을 알면 먼저 제안하게 된다.

```
유저: "이 기능을 전략 패턴으로 리팩터링해줘"

AI:   현재 분기가 2개뿐이어서 전략 패턴을 적용하면
      오히려 복잡해질 수 있습니다.
      단순 if/else로도 충분할 것 같은데, 어떻게 생각하시나요?
      전략 패턴으로 진행하시겠습니까?
```

---

## 5. 주의점 — 과도한 질문 문제

이 원칙을 너무 엄격하게 적용하면 모든 사소한 결정에도 질문한다.

```
유저: "console.log를 logger로 바꿔줘"

AI:   어떤 logger 라이브러리를 사용할까요? winston인가요, pino인가요?
      log level은 어떻게 설정할까요? 파일로도 저장할까요?
      로그 포맷은 JSON으로 할까요, 텍스트로 할까요?
```

karpathy-skills는 이 점을 Tradeoff Note로 명시한다:

> "These guidelines bias toward caution over speed. For trivial tasks, use judgment — not every change needs the full rigor."

단순한 작업까지 질문 루프에 가두지 않는 것이 중요하다. 이 원칙은 **비자명한(non-trivial) 작업**에서 진가를 발휘한다.

> 💡 **핵심**: "생각하고 코딩"은 사람에게도 기본이다. 모델에게도 명시적으로 요구해야 한다. 가정을 숨기지 말고, 모호성을 표면에 드러내도록 강제하는 것이 첫 번째 원칙이다.

> 💡 **다음 챕터**: Simplicity First — 왜 모델은 100줄로 될 것을 1,000줄로 만드는가, 그리고 어떻게 막는가.

"Think Before Coding — 섣부른 가정을 막는 법"

// COMMENTS

ON THIS PAGE