AI 생성 코드는 전부 읽지 않습니다: 영향 범위·증거·롤백으로 검토하는 위험 기반 코드 리뷰 | DAKER 커뮤니티

이 영상은 Meta의 Senior Staff Software Engineer라고 소개한 John Kim이 AI 생성 코드의 리뷰 병목을 어떻게 다루는지 설명합니다. 결론은 “코드를 읽지 말자”가 아니라, 모든 변경을 같은 깊이로 읽는 방식에서 벗어나 영향 범위, 검증 증거, 롤백 가능성에 따라 리뷰 강도를 조절하자는 것입니다.

핵심 요약

• 코드 리뷰는 전부 읽기 또는 전부 맡기기의 이분법이 아니라 위험도에 따른 연속선입니다.

• 코드베이스를 나무로 보고, 공통 인프라와 핵심 상태를 다루는 trunk 코드는 깊게 검토합니다.

• 독립된 UI 컴포넌트나 기능 플래그 뒤의 leaf 코드는 테스트와 실행 증거가 충분하면 빠르게 검토합니다.

• AI에게 코드만 제출하게 하지 말고 테스트, 로그, 스크린샷, 동영상 등 “작동한다는 증거”를 PR에 포함시킵니다.

• 코드를 작성한 에이전트와 다른 독립 에이전트가 적대적으로 재검토하게 합니다.

• 병합 가능 상태와 실제 출시 가능 상태는 다릅니다. 마지막 20%는 사람이 성능, 보안, 제품 완성도와 운영 안전성을 확인합니다.

1. 리뷰 깊이는 변경량보다 Blast Radius로 결정

영상은 코드베이스를 나무에 비유합니다.

Trunk·Root 코드

• 애플리케이션 진입점

• 공통 상태와 reducer

• 네트워크, 이미지 처리, 인증, 결제 등의 공유 인프라

• 다수 기능이 의존하는 공통 모듈

이 영역의 오류는 전체 서비스로 확산될 수 있으므로 사람이 설계와 코드를 깊게 읽어야 합니다. 특히 기존 동작을 바꾸거나 데이터·보안 경계를 건드리는 변경은 높은 검토 강도가 필요합니다.

Leaf 코드

• 독립된 신규 컴포넌트

• 기존 경로와 격리된 신규 로직

• 기능 플래그 뒤에서 비활성화된 기능

• 단위·컴포넌트·스냅샷 테스트로 경계를 확인할 수 있는 변경

Leaf 코드는 코드 전체를 한 줄씩 읽기보다 테스트 결과와 UI 증거를 확인하고 이상한 부분을 훑는 방식으로 속도를 높일 수 있습니다.

검토 전에 물어볼 질문

1) 이 변경이 실패하면 어디까지 영향을 주는가?

2) 기존 사용자 경험에서 절대 바뀌면 안 되는 것은 무엇인가?

3) 문제가 생겼을 때 즉시 끄거나 되돌릴 수 있는가?

4) 핵심 데이터, 권한, 보안, 상태 관리 경로를 건드리는가?

5) 독립적으로 검증할 수 있는가?

3번의 답이 명확하고 롤백이 쉬울수록 개별 코드에 쓰는 검토 시간을 줄일 수 있습니다.

2. 리뷰는 PR 단계가 아니라 기획 단계부터 시작

AI 에이전트는 계획, 구현, 검토, 출시의 전체 과정에 참여해야 합니다. 특히 새 기능은 처음부터 기능 플래그 또는 단순 Boolean gate 뒤에서 개발해 기존 사용자 경로와 분리하는 것이 중요합니다.