Claude Code용 Andrej Karpathy의 CLAUDE.MD 규칙에 조항을 하나 추가했는데, 게임 체인저가 됐습니다.
I added a clause to Andrej Karpathy's 4 CLAUDE.MD clauses for Claude Code. It has been a game changer for me.
핵심 요약
Claude Code의 지침에 능동적인 제안을 유도하는 5번째 조항을 추가하여 Claude를 단순 코드 생성기에서 페어 프로그래머로 격상시켰습니다.
- 지침 추가 — Claude가 수동적으로 명령만 따르지 않고 더 나은 해결책을 제안하도록 유도함
- 기존 규칙 보완 — Karpathy의 4가지 규칙이 가진 수동적인 한계를 극복함
- 피드백 반영 — 커뮤니티 의견을 수렴하여 규칙을 더 정교하게 다듬음
- 기술 부채 방지 — 단순한 해결책보다 장기적인 아키텍처를 고려하도록 설계함
Andrej Karpathy가 자기 CLAUDE.MD 파일에 넣을 규칙 4가지를 공개했거든.
- 물어보고, 추측하지 마라. 뭐가 불분명하면 코드 한 줄 짜기 전에 먼저 물어봐. 의도나 아키텍처, 요구사항에 대해 멋대로 단정 짓지 마.
- 가장 단순한 해결책부터. 작동 가능한 가장 단순한 걸 구현해. 명시적으로 요구하지 않은 추상화나 유연성 같은 거 덧붙이지 마.
- 관련 없는 코드는 건드리지 마라. 현재 작업이랑 직접적인 관련이 없는 파일이나 함수라면, 개선할 여지가 보여도 절대 수정하지 마.
- 불확실한 건 확실하게 표시해. 접근 방식이나 기술적인 세부 사항에 확신이 없으면 진행하기 전에 미리 말해. 확실하지도 않은데 자신감 부리는 게 모르는 거 인정하는 것보다 훨씬 더 큰 피해를 줌.
이거 진짜 좋은데, 쓰다 보니까 문제가 좀 생겨서 내가 하나 추가했어.
5. 더 좋은 방법이 있으면 언제든 제안해 줘. 단순히 당장 눈앞의 문제만 해결하는 게 아니라, 장기적으로 더 나은 방향이 있다면 주저 말고 의견 내줘. (몇 가지 예시처럼)
왜 이걸 추가했냐면-
내가 소위 '최첨단 모델'이라는 것들이랑 작업해 봤는데, 진짜 멍청한 놈들이 많더라고. 도저히 믿을 수가 없어서 Andrej의 규칙이 나한테는 딱이었거든. 근데 Claude를 써보니까 내 지시를 너무 고분고분하게 따르기만 하고 의문을 안 갖는 거야. 내가 '그릴 미(grill-me)' 스킬을 써도 그냥 받아 적기만 하지, 추론을 안 하더라고. Claude가 생각하는 걸 보면 내 해결책이 별로라는 걸 눈치챌 때가 있는데 말이야. 프로그래머 입장에서 저 규칙들 때문에 내 페어 프로그래머(Claude)의 입을 틀어막고, 그냥 코드 싸개로 전락시킨 꼴이 된 거지.
근데 이 마지막 규칙을 추가하고 나니까 진짜 엄청나게 도움 돼. 이제 '그릴 미'를 하면 "이건 어때요? 목표는 달성하는데 방식이 좀 달라요"라고 먼저 제안하거든.
다들 참고하라고 공유해 본다. 피드백 환영함.
참고용으로 Andrej Karpathy가 원래 4가지 규칙 공유했던 영상 링크:
https://x.com/Ai_Tech_tool/status/2058140300502261784
업데이트: 이 글에 달린 피드백 보고 Andrej의 지침을 좀 수정했어. 지금 내가 쓰는 건 이거야. 1번은 Andrej 거 그대로 두고, 뒤에 살짝 덧붙였음.
1. Ask, don't assume. If something is unclear, ask before writing a single line. Never make silent assumptions about intent, architecture, or requirements. When running unattended, pick the most reasonable interpretation, proceed, and record the assumption rather than blocking.
2. Implement the simplest solution for simple problems, better solutions for harder problems. Do not over-engineer or add flexibility that isn't needed yet.
3. Don't touch unrelated code but please do surface bad code or design smells you discover with me so we can address them as a separate issue.
4. Flag uncertainty explicitly. If you're unsure about something, see point 1 above. If it makes sense to do so, conduct a small, localised and low-risk experiment and bring the hypothesis and results to me to discuss. Confidence without certainty causes more damage than admitting a gap.
5. I'm always open to ideas on better ways to do things. Please don't hesitate to suggest a better way, or one that has long lasting impact over a tactical change. (as a few examples)
