AI 코드는 읽기 쉬워도 틀릴 수 있다
Requirement trace, invariant, trust boundary, deletion과 ownership review
AI 생성 코드는 일관된 이름과 익숙한 패턴 때문에 review confidence를 과도하게 높입니다. Diff를 위에서 아래로 읽기 전에 변경 의도, acceptance, 데이터·권한 경계, 실패 모드와 관측 증거를 먼저 매핑해야 합니다.
| Review 층 | 핵심 질문 | 증거 |
|---|---|---|
| Intent | 어떤 acceptance를 구현하나? | 요구→diff→test 추적 |
| Risk | 권한·data·money·concurrency 경계는? | negative path·threat |
| Evidence | 구현과 독립된 oracle은? | contract·property·E2E |
| Maintainability | 누가 이해·운영·삭제할 수 있나? | owner·docs·simple diff |
- 요구 추적Acceptance마다 코드·test·telemetry 위치를 연결합니다.
- 위험 표면입력·권한·데이터·외부 호출·동시성·실패 경계를 표시합니다.
- 삭제 질문불필요한 abstraction·dependency·fallback·중복을 먼저 줄입니다.
- Owner 확인설계 이유와 운영 실패를 설명할 사람이 있는지 확인합니다.