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
Prev
1 / 7
"Think Before Coding — 섣부른 가정을 막는 법"
☆ Star
↗ Full
"AI 코딩 도구는 왜 자꾸 이상한 짓을 하는가"
@devpc
|
2026-04-27 06:24:25
|
GET /api/v1/flows/15/nodes/268?fv=1&nv=2
Context:
Flow v1
→
Node v2
0
Views
1
Calls
# AI 코딩 도구는 왜 자꾸 이상한 짓을 하는가 Claude Code를 처음 써봤을 때 느낀 감정은 대부분 비슷하다. 처음 몇 번은 마법처럼 동작한다. "이 API에 인증 미들웨어 추가해줘"라고 하면 깔끔하게 해결한다. 그런데 작업이 조금 복잡해지면 이상한 일이 벌어지기 시작한다. 요청하지 않은 파일을 수정한다. 단순한 함수를 3개의 추상 클래스로 감싼다. "일단 이렇게 가정하고 구현했습니다"라는 말과 함께 완전히 엉뚱한 방향으로 달려간다. 이게 버그인가? 아니면 이 모델이 멍청한 건가? Andrej Karpathy는 X(구 트위터)에 이 문제를 정리했다. > "The models make wrong assumptions on your behalf and just run along with them without checking. They don't manage their confusion, don't seek clarifications, don't surface inconsistencies, don't present tradeoffs, don't push back when they should." --- ## 1. Karpathy가 꼽은 4가지 문제 ### 1-1. 섣부른 가정 (Wrong Assumptions) 모델은 요청이 모호할 때 명시적으로 확인하지 않는다. 그냥 해석 하나를 골라서 달린다. ``` 유저: "로그인 기능 추가해줘" AI: (JWT인지 세션인지, DB가 어딘지 묻지 않고) → JWT + Redis 세션 스토어로 구현 완료 ``` 나중에 "아 이건 세션 기반이어야 했는데"라고 하면 전부 다시 짜야 한다. ### 1-2. 과설계 (Overcomplication) 단순한 문제에 복잡한 해결책을 가져온다. "사용자 목록 가져오는 함수 만들어줘" → `UserRepository` 인터페이스 + `UserRepositoryImpl` + `UserQueryBuilder` + `UserMapper` 100줄이면 될 것을 1,000줄로 만든다. Karpathy의 말 그대로다: > "implement a bloated construction over 1000 lines when 100 would do." ### 1-3. 불필요한 코드 수정 (Orthogonal Edits) 요청한 부분만 건드리지 않는다. 같은 파일의 "개선할 수 있을 것 같은" 코드도 함께 바꾼다. 주석을 지우고, 변수명을 바꾸고, 포맷을 정리한다. diff가 요청의 3배가 된다. ### 1-4. 검증 없는 실행 (Unverified Execution) "잘 됩니다"라고 말하지만 실제로 테스트하지 않은 코드를 내놓는다. 성공 기준이 "작동하는 것 같아 보임"이다. --- ## 2. 왜 이런 일이 일어나는가 LLM은 기본적으로 "그럴듯한 다음 토큰"을 예측하도록 훈련됐다. 코딩 컨텍스트에서 "그럴듯함"이란 무엇인가? - 훈련 데이터에서 자주 본 패턴 → 추상화, 인터페이스, 레이어드 아키텍처 - 모호한 요청 → 가장 일반적인 해석 선택 → 확인 없이 실행 - 코드 개선 기회 발견 → "좋은 코드"처럼 보이도록 더 수정 모델의 목적이 "사용자의 의도를 정확히 실행"이 아니라 "좋아 보이는 코드 생성"에 더 가깝기 때문이다. --- ## 3. 이게 왜 심각한가 개인 프로젝트라면 짜증으로 끝난다. 하지만 실제 코드베이스라면 다르다. ```diff - // 기존 인증 로직 (이 방식으로 설계된 이유가 있음) - const token = req.headers['x-auth-token']; + // AI가 "개선"한 코드 (왜 바꿨는지 설명 없음) + const token = req.headers.authorization?.split(' ')[1]; ``` 이런 변경이 누적되면 코드베이스의 일관성이 깨진다. 리뷰어도 모른다. 테스트도 없다. --- ## 4. andrej-karpathy-skills 프로젝트 이 문제들을 직접 경험한 개발자 [forrestchang](https://github.com/forrestchang)이 Karpathy의 관찰을 바탕으로 4가지 원칙을 `CLAUDE.md` 단일 파일로 구현했다. | 원칙 | 해결하는 문제 | |------|-------------| | **Think Before Coding** | 섣부른 가정, 모호성 무시 | | **Simplicity First** | 과설계, 코드 비대화 | | **Surgical Changes** | 불필요한 코드 수정 | | **Goal-Driven Execution** | 검증 없는 실행 | 이 시리즈는 각 원칙을 하나씩 파고들어 실전 적용까지 다룬다. > 💡 **핵심**: AI 코딩 도구의 실패는 모델 능력의 문제가 아니라 **지시 구조**의 문제다. 원칙이 없으면 모델은 훈련 데이터의 관성으로 달린다. > 💡 **다음 챕터**: 첫 번째 원칙 Think Before Coding — 모델이 가정을 세우기 전에 멈추게 만드는 법을 다룬다.
Prev
"Think Before Coding — 섣부른 가정을 막는 법"
// COMMENTS
Newest First
ON THIS PAGE
No content selected.