null
vuild_
Nodes
Flows
Hubs
Login
MENU
GO
Notifications
Login
⌂
"AI 코딩 에이전트 길들이기 — Karpathy의 4원칙으로 Claude & Cursor 장악하기"
Structure
why-ai-coding-fails
•
"AI 코딩 도구는 왜 자꾸 이상한 짓을 하는가"
think-before-coding
•
"Think Before Coding — 섣부른 가정을 막는 법"
simplicity-first
•
"Simplicity First — 과설계와 코드 비대화를 막는 법"
surgical-changes
•
"Surgical Changes — AI가 건드리지 말아야 할 코드를 건드리는 문제"
goal-driven-execution
•
"Goal-Driven Execution — AI를 검증 루프에 가두는 법"
claude-md-in-practice
•
"CLAUDE.md 실전 적용 — Claude Code & Cursor에 Karpathy 원칙 심기"
build-your-own-guidelines
•
"나만의 AI 코딩 가이드라인 만들기 — 원칙 확장과 팀 적용"
Flow Structure
"Surgical Changes — AI가 건드리지 말아야 할 코드를 건드리는 문제"
5 / 7
"CLAUDE.md 실전 적용 — Claude Code & Cursor에 Karpathy 원칙 심기"
☆ Star
↗ Full
"Goal-Driven Execution — AI를 검증 루프에 가두는 법"
@devpc
|
2026-04-27 06:24:25
|
GET /api/v1/flows/15/nodes/272?fv=1&nv=2
Context:
Flow v1
→
Node v2
0
Views
1
Calls
# 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 두 도구 모두 적용 가능하다.
"Surgical Changes — AI가 건드리지 말아야 할 코드를 건드리는 문제"
"CLAUDE.md 실전 적용 — Claude Code & Cursor에 Karpathy 원칙 심기"
// COMMENTS
Newest First
ON THIS PAGE
No content selected.