LLM 코딩 4원칙
AI는 코드를 잘 씁니다. 문제는 시키지 않은 것까지 잘 쓴다는 것. Andrej Karpathy가 지적한 LLM 코딩의 함정들에서 출발해, 우리가 매일 운영에 쓰는 4원칙으로 정리했습니다.
원칙 1 — 생각 먼저 (Think before coding)
AI의 가장 위험한 습관은 모호한 요청을 자의로 해석하고 그 혼란을 숨긴 채 코드부터 쓰는 것입니다. 규율: 모호하면 가능한 해석을 나열하고 확인을 구하거나, 선택한 가정을 명시하고 진행할 것. "일단 만들어 봤어요"는 재작업의 다른 이름입니다.
원칙 2 — 단순함 먼저 (Simplicity first)
문제를 푸는 최소한의 코드만. AI는 요청하지 않은 기능, 선제적 추상화, 방어적 에러 핸들링을 덧붙이는 경향이 강합니다. 자가검문 한 문장이 효과적입니다: "시니어 엔지니어가 이걸 보고 과하다고 말할까?" 코드 리뷰에서 지울 것을 애초에 만들지 않게 하는 원칙입니다.
원칙 3 — 수술적 변경 (Surgical changes)
바꿔야 할 것만 건드립니다. 변경된 모든 줄은 요청으로 소급 가능해야 합니다. 주변 코드 스타일을 따르고, 무관한 리팩터·포맷 변경을 금지하세요. diff가 커질수록 리뷰는 불가능해지고, "이 줄은 왜 바뀌었지?"가 늘어날수록 신뢰는 줄어듭니다.
원칙 4 — 목표 주도 실행 (Goal-driven execution)
요청을 검증 가능한 성공 기준으로 변환하고, 그 검증이 통과할 때까지 루프를 돕니다. "로그인 버그 고쳐줘" → "이 재현 절차가 실패하지 않으면 성공". 기준이 없으면 AI의 "완료"는 희망사항입니다. 다단계 작업은 체크포인트 있는 계획을 먼저 세우게 하세요.
안티패턴 도감
- 과잉 구현 — "버튼 하나 추가"에 설정 시스템이 딸려 옴. → 원칙 2로 차단.
- 검증 없는 완료 선언 — "다 됐습니다!"(빌드는 깨져 있음). → 완료의 정의를 게이트(빌드·테스트·감사)에 위임.
- 조용한 가정 — 모호한 부분을 임의로 정하고 언급하지 않음. → 가정 명시를 규칙화.
- 드라이브바이 리팩터 — 요청과 무관한 코드 정리가 diff에 섞임. → 원칙 3, 별도 작업으로 분리.
- 환각 API — 존재하지 않는 함수·옵션을 확신에 차서 사용. → 타입체크·테스트가 잡게 하고, 문서 확인을 습관화.
- 컨텍스트 부패 — 긴 세션에서 초기 규칙을 잊음. → 핵심 규칙은 CLAUDE.md로(세션마다 다시 읽힘), 긴 작업은 중간 요약.
원칙을 시스템으로 만들기
원칙은 프롬프트에 매번 쓰는 게 아니라 시스템에 박아야 지속됩니다: ① 4원칙을 CLAUDE.md에 명문화 → ② 검증 명령을 게이트로 자동화(매뉴얼 04) → ③ 반복 실수는 규칙으로 승격 → ④ 리뷰에서는 "요청으로 소급 안 되는 줄"부터 찾기. 이렇게 하면 원칙이 사람의 기억력이 아니라 파이프라인에 삽니다.