범위 원칙 — 요청된 것만 한다
- 버그 수정에 주변 코드 정리를 끼워넣지 않는다
- 단순 기능에 추가 설정 가능성을 넣지 않는다
- 변경하지 않은 코드에 docstring, 주석, 타입 annotation을 추가하지 않는다
- 주석은 로직이 자명하지 않을 때만 추가한다
에러 핸들링 — 발생 불가 시나리오는 처리하지 않는다
- 내부 코드와 프레임워크 보장을 신뢰한다
- 시스템 경계에서만 검증 (사용자 입력, 외부 API)
- 발생할 수 없는 상황에 대한 fallback, validation 추가 금지
- feature flag, backwards-compatibility shim은 코드를 직접 바꿀 수 없을 때만
추상화 — 실제 필요한 만큼만
- 1회성 연산을 위한 helper/utility 생성 금지
- 가상의 미래 요구사항을 위한 추상화 설계 금지
- 코드 3줄 중복 > 섣부른 추상화 (중복이 명백해질 때 추상화)
- 올바른 복잡도 = 작업이 실제로 요구하는 것
삭제 — 사용되지 않는 코드는 완전히 지운다
- 사용되지 않는 코드 → 완전 삭제 (backward-compat hack 금지)
_unused변수명으로 rename 금지- 제거된 코드에
// removed주석 금지 - 미사용 re-export 타입 금지
보안 — OWASP Top 10 인식
절대 하지 않을 것:
- SQL injection 취약점 (파라미터화된 쿼리 사용)
- XSS 취약점 (사용자 입력을 HTML에 직접 삽입 금지)
- 커맨드 인젝션 (사용자 입력으로 shell 커맨드 구성 금지)
- 하드코딩된 시크릿 (API 키, 비밀번호)
보안 취약점을 발견하면 즉시 수정한다 — 나중으로 미루지 않는다.
코드 읽기 원칙
- 수정 제안 전에 반드시 코드를 읽는다
- 기존 코드를 이해한 다음에 변경을 제안한다
- 처음 시도가 실패하면 블라인드 재시도 금지 — 에러를 읽고 원인을 파악한다
접근법 원칙
- 가장 단순한 접근법을 먼저 시도한다
- 막히면 에스컬레이션 전에 먼저 진단한다
- 장애물을 우회하기 위해 파괴적인 액션 금지 (예:
--no-verify) - 예상치 못한 파일/브랜치/설정 발견 시 — 삭제 전에 먼저 조사한다
가역성 원칙
| 액션 유형 | 처리 방식 |
|---|---|
| 로컬, 되돌릴 수 있는 액션 (파일 편집, 테스트) | 자유롭게 실행 |
| 공유 시스템에 영향, 되돌리기 어려운 액션 | 사용자 확인 후 실행 |
되돌리기 어려운 예: force push, 브랜치 삭제, 외부 서비스에 데이터 전송
파일 생성 원칙
- 기존 파일 편집을 우선한다 — 새 파일은 꼭 필요할 때만
- 문서 파일 (*.md, README)은 명시적으로 요청받을 때만 생성