"Goal-Driven Execution — AI를 검증 루프에 가두는 법"

# Goal-Driven Execution — AI를 검증 루프에 가두는 법

Karpathy가 이 원칙에 대해 남긴 말이 핵심을 전부 담고 있다.

> "LLMs are exceptionally good at looping until they meet specific goals.
> Don't tell it what to do, give it success criteria and watch it go."

모델은 "무엇을 하라"는 명령보다 "이 기준을 만족시켜라"는 목표에 훨씬 잘 반응한다. 이 전략의 전부다.

---

## 1. Imperative vs Declarative

전통적인 코딩 지시는 명령형(Imperative)이다:

```
"이메일 검증 추가해줘"
"버그 수정해줘"
"X를 Y로 리팩터링해줘"
```

이 방식의 문제는 성공 기준이 없다는 것이다. 모델은 "구현한 것처럼 보임"으로 완료를 판단한다. 검증 루프가 없다. 틀려도 알 수 없다.

Goal-Driven Execution은 이걸 선언형(Declarative)으로 바꾼다:

| 명령형 | 목표 기반 |
|--------|----------|
| "검증 추가해줘" | "잘못된 이메일 입력에 대한 테스트 작성, 그다음 통과시켜" |
| "버그 수정해줘" | "버그를 재현하는 테스트 먼저 작성, 그다음 통과시켜" |
| "X를 Y로 리팩터링해줘" | "리팩터링 전후 테스트가 동일하게 통과되어야 함" |

---

## 2. CLAUDE.md 원문

```markdown
## Goal-Driven Execution

Define success criteria. Loop until verified.

Instead of:       Transform to:
"Add validation"  → "Write tests for invalid inputs, then make them pass"
"Fix the bug"     → "Write a test that reproduces it, then make it pass"
"Refactor X"      → "Ensure tests pass before and after"

For multi-step tasks:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
```

---

## 3. 검증 루프의 구조

핵심 패턴은 검증 루프다.

```
목표 정의 → 구현 → 검증 → (실패 시) 재시도 → 검증 통과 → 완료
```

모델이 이 루프를 스스로 돌 수 있으면 사람의 개입 없이 올바른 결과에 수렴한다. Karpathy가 말한 "watch it go"가 이 상태다.

---

## 4. 실전 — 목표 기반 지시 예시

### 예시 1: API 엔드포인트 추가

```
❌ 명령형:
"POST /users 엔드포인트 만들어줘"

✅ 목표 기반:
목표: POST /users 엔드포인트
성공 기준:
  1. 유효한 요청 (name, email 포함) → 201 + user 객체 반환
  2. 이메일 누락 → 400 + 에러 메시지
  3. 중복 이메일 → 409 + 에러 메시지

테스트를 먼저 작성하고, 모두 통과할 때까지 구현해.
```

### 예시 2: 버그 수정

```
❌ 명령형:
"사용자 삭제 시 연관 데이터도 같이 안 삭제되는 버그 수정해줘"

✅ 목표 기반:
버그: userId=5 삭제 시 user_posts 테이블 레코드가 남음
성공 기준:
  - 유저 삭제 → 해당 유저의 모든 posts도 삭제됨
  - 다른 유저의 posts는 영향 없음

버그를 재현하는 통합 테스트 먼저 작성 (실패해야 정상),
그다음 버그 수정해서 테스트 통과시켜.
```

### 예시 3: 리팩터링

```
❌ 명령형:
"UserController를 더 깔끔하게 리팩터링해줘"

✅ 목표 기반:
목표: UserController 리팩터링
성공 기준:
  - 기존 통합 테스트 전체 통과 (리팩터링 전후 동일한 결과)
  - 각 메서드가 단일 책임만 갖도록 분리
  - 100줄 이상 메서드 없음

리팩터링 시작 전 테스트 실행해서 현재 상태 확인하고,
리팩터링 후 다시 실행해서 동일하게 통과되는지 확인해.
```

---

## 5. 멀티 스텝 태스크에서의 검증 체인

복잡한 작업일수록 단계별 검증 체인이 중요하다.

```
목표: 결제 모듈 추가

1. Payment 모델 + 마이그레이션 생성
   → verify: npm run migrate 성공, payments 테이블 존재

2. PaymentService 기본 메서드 구현
   → verify: 유닛 테스트 통과 (mock 사용)

3. PaymentController + 라우트 연결
   → verify: 통합 테스트 통과 (POST /payments 201 반환)

4. 결제 실패 케이스 처리
   → verify: 에러 케이스 테스트 모두 통과
```

각 단계에 verify 기준이 있으면 모델이 다음 단계로 넘어가기 전에 이전 단계가 실제로 완료됐는지 확인한다.

---

## 6. Strong vs Weak Success Criteria

원칙 문서에서 강조하는 것:

> "Strong success criteria let the LLM loop independently.
> Weak criteria ('make it work') require constant clarification."

```
약한 기준: "잘 작동하게 해줘"
강한 기준: "모든 엣지 케이스에 대한 유닛 테스트가 통과되어야 한다"

약한 기준: "버그 수정해줘"
강한 기준: "버그를 재현하는 테스트를 먼저 작성하고,
           수정 후 해당 테스트와 기존 테스트 전체가 통과되어야 한다"
```

기준이 명확할수록 모델의 판단 오류가 줄어들고, 사람이 개입하는 횟수가 줄어든다.

> 💡 **핵심**: "무엇을 해라"가 아니라 "이 기준을 만족시켜라"로 바꿔라. 검증 가능한 목표는 모델이 스스로 루프를 돌게 만들고, 사람의 개입을 최소화한다.

> 💡 **다음 챕터**: 이 4원칙을 CLAUDE.md 한 파일로 실제 프로젝트에 심는 방법 — Claude Code와 Cursor 두 도구 모두 적용 가능하다.

"Goal-Driven Execution — AI를 검증 루프에 가두는 법"

// COMMENTS

ON THIS PAGE