# AI 코드는 읽기 쉬워도 틀릴 수 있다

> Requirement trace, invariant, trust boundary, deletion과 ownership review

- Canonical: https://learning.reopt.ai/en/courses/ai-code-quality/lessons/cq-m1-concept
- Language: en
- HTML: https://learning.reopt.ai/en/courses/ai-code-quality/lessons/cq-m1-concept

---

[AI code quality, verification & debugging](/en/courses/ai-code-quality) 1. Intent 중심 코드 리뷰 1 / 9

# AI 코드는 읽기 쉬워도 틀릴 수 있다

Requirement trace, invariant, trust boundary, deletion과 ownership review
Concept 45 XP 9 min

AI 생성 코드는 일관된 이름과 익숙한 패턴 때문에 review confidence를 과도하게 높입니다. Diff를 위에서 아래로 읽기 전에 변경 의도, acceptance, 데이터·권한 경계, 실패 모드와 관측 증거를 먼저 매핑해야 합니다.
리뷰 순서는 Intent→Risk→Evidence→Code 각 요구가 어느 코드와 test로 증명되는지, 각 trust boundary가 어떻게 강제되는지, 새 추상화가 실제 복잡성을 줄이는지 확인합니다. 설명할 owner가 없는 코드와 필요 이상의 dependency는 삭제 후보입니다.

| Review 층 | 핵심 질문 | 증거 |
| Intent | 어떤 acceptance를 구현하나? | 요구→diff→test 추적 |
| Risk | 권한·data·money·concurrency 경계는? | negative path·threat |
| Evidence | 구현과 독립된 oracle은? | contract·property·E2E |
| Maintainability | 누가 이해·운영·삭제할 수 있나? | owner·docs·simple diff |

- 1 요구 추적 Acceptance마다 코드·test·telemetry 위치를 연결합니다.

- 2 위험 표면 입력·권한·데이터·외부 호출·동시성·실패 경계를 표시합니다.

- 3 삭제 질문 불필요한 abstraction·dependency·fallback·중복을 먼저 줄입니다.

- 4 Owner 확인 설계 이유와 운영 실패를 설명할 사람이 있는지 확인합니다.

실무에 남길 기준

- 스타일·패턴 일치는 요구 충족이나 안전의 증거가 아니다
- AI가 작성한 코드에는 “왜 이 복잡성이 필요한가”를 더 엄격하게 묻는다
- 리뷰가 이해하지 못한 코드를 테스트 통과만으로 승인하지 않는다

Got it · Continue

---

Site guide for agents: https://learning.reopt.ai/llms.txt · Sitemap: https://learning.reopt.ai/sitemap.xml · Contact: https://learning.reopt.ai/contact