Andrej Karpathy가 공유한 LLM 코딩 가이드라인을 Claude Code 작업에 직접 적용해봤다. 플러그인까지 설치했고, 2~3일 관찰했다.
결론부터 말하면 플러그인 효과는 드라마틱하지 않았어요. 그보다 원칙 4개를 읽고 나서 제가 Claude Code한테 요청하는 방식이 달라진 게 더 컸거든요.
Karpathy 4원칙이 뭔지부터
Andrej Karpathy는 X(구 트위터)에서 LLM으로 코딩할 때 흔히 빠지는 함정들을 정리한 가이드라인을 공유한 적 있어요. 4개 원칙으로 구성돼 있는데, 각각 이름이 있습니다.
하나씩 Karpathy가 직접 말한 내용 기준으로 정리할게요.
1. Think Before Coding
Karpathy는 “Don’t assume. Don’t hide confusion. Surface tradeoffs.”라고 했어요.
구현 전에 가정을 명시하고, 해석이 여러 개라면 하나를 골라 진행하지 말고 선택지를 사람한테 보여줘라. 더 단순한 방법이 있으면 그냥 만들지 말고 먼저 말하라는 내용이에요.
적용 후 실제로 달라진 점은… 솔직히 이 부분에서 눈에 띄는 변화는 적었어요. Claude Code가 원래도 모호한 요청엔 질문을 좀 하는 편이라서 이전이랑 비교가 잘 안 됐거든요.
2. Simplicity First
Karpathy는 “Minimum code that solves the problem. Nothing speculative.”라고 했어요.
요청하지 않은 기능 추가 금지, 한 번 쓰고 말 코드에 추상화 레이어 끼워넣기 금지. 200줄로 짤 수 있는 걸 50줄로 줄일 수 있으면 다시 써라는 원칙이에요.
적용 후 실제로 달라진 점은 이게 제일 체감이 됐어요. 설치 전에는 “이 기능 추가해줘”라고 하면 관련 유틸 함수, 헬퍼 클래스까지 알아서 만들어주는 경향이 있었거든요. 설치 후에는 “이 helper 함수 지금 정말 필요합니까?” 하는 확인 질문이 더 자주 나왔어요. 처음엔 귀찮았는데, 돌이켜보면 실제로 불필요한 코드가 줄었어요.
다만 이게 플러그인 덕분인지, 아니면 제가 원칙을 읽고 나서 요청 자체를 더 좁게 하게 된 건지는 구별이 안 됩니다. 2~3일 관찰이라 단정하기도 어렵고요.
위는 Simplicity First 원칙 적용 후 Claude Code가 불필요한 함수 생성 여부를 먼저 물어보는 화면입니다.
3. Surgical Changes
Karpathy는 “Touch only what you must. Clean up only your own mess.”라고 했어요. 그리고 이런 말도 덧붙였어요: “Every changed line should trace directly to the user’s request.”
내 변경으로 생긴 고아 코드(쓰지 않는 import 등)는 직접 정리하되, 원래부터 있던 죽은 코드는 건드리지 말고 언급만 하라는 원칙이에요.
적용 후 실제로 달라진 점은 파일 수정 시 요청 범위 밖에 있는 코드에 대해서 “이거 죽은 코드인 것 같은데 삭제할까요?” 식으로 물어보는 경우가 생겼어요. 이전에는 관련 없는 코드도 같이 정리해주는 경우가 있었는데 지금은 먼저 확인하더라고요.
4. Goal-Driven Execution
Karpathy는 태스크를 검증 가능한 목표로 변환하라고 했어요. 예시도 직접 들었는데, “버그 고쳐”가 아니라 “버그 재현 테스트 작성 후 통과시켜”로 요청하라는 식이에요.
이건 Claude Code 설정보다 제가 요청을 어떻게 쓰느냐의 문제라서, 의식하기 시작한 것만으로도 달라진 느낌이 있었어요. “이것도 해줘 저것도 해줘” 대신 “이 문제만 정확히 해결해줘”로요.
위는 Goal-Driven Execution 원칙을 적용해 검증 기준을 포함해서 요청한 프롬프트 예시 화면입니다.
적용 전후 비교
수치로 비교할 수 있는 데이터는 없어요. 2~3일 관찰이라 통계 내기도 어렵고, 플러그인 효과와 요청 방식 변화를 분리하는 것도 현실적으로 불가능했거든요. 대신 체감 차이를 정리해봤어요.
| 항목 | 적용 전 | 적용 후 |
|---|---|---|
| 기능 요청 시 코드 양 | 유틸 함수·헬퍼 클래스 자동 포함 | 필요 여부 먼저 확인 질문 |
| 파일 수정 범위 | 요청 밖 코드도 함께 정리 | 범위 밖은 삭제 여부 물어봄 |
| 내 요청 방식 | “이것도 저것도 해줘” | “이 문제만 정확히 해결해줘” |
| 변화 원인 | — | 플러그인인지 습관 변화인지 불명확 |
솔직히 말하면
Karpathy 4원칙을 읽고 나서 가장 먼저 든 생각은, 이게 AI 코딩 도구 설정 얘기가 아니라 사람이 AI를 쓰는 습관에 대한 얘기라는 거였어요.
플러그인은 Claude 동작에 원칙을 심어주는 용도지만, 실제로 제일 크게 달라진 건 제가 요청을 짜는 방식이었거든요. Karpathy가 말한 “목표를 검증 가능하게 정의하라”는 결국 사람이 해야 하는 일이고, AI한테 시스템으로 강제할 수 있는 부분은 제한적이에요.
그리고 솔직하게 한 가지 더 — 이 변화가 Karpathy 원칙 덕분인지, 아니면 “의식적으로 원칙을 생각하면서 쓰는 것” 자체의 효과인지는 아직도 모르겠어요.
위는 andrej-karpathy-skills 플러그인 설치 완료 후 Claude API 콘솔에서 확인한 적용 상태 화면입니다.
Karpathy 4원칙 — 한 줄 요약
- Think Before Coding — 가정을 명시하고 선택지를 먼저 보여줘라 (Karpathy)
- Simplicity First — 요청하지 않은 건 만들지 마라 (Karpathy)
- Surgical Changes — 내 변경으로 생긴 것만 정리해라 (Karpathy)
- Goal-Driven Execution — 검증 가능한 목표로 바꿔서 요청해라 (Karpathy)
62일차 기준으로 이 원칙들이 Claude Code 사용 방식에 가장 직접적인 영향을 준 가이드라인이에요. 코딩을 잘 몰라도 이 4개 원칙을 요청 방식에 적용하는 건 할 수 있거든요.
아직도 플러그인 효과가 얼마나 됐는지는 모르겠어요. 근데 원칙 읽은 건 확실히 도움이 됐어요.
썸네일: Bernd 📷 Dittrich on Unsplash