AI 코딩의 대화는 거의 다 생성 쪽에 쏠려 있다. 더 빠른 에이전트, 더 큰 컨텍스트, 더 자율적인 루프. 그런데 코드가 10배 빨리 쏟아지는 동안, 그걸 검증하는 속도는 거의 그대로다.
그래서 병목은 조용히 자리를 옮겼다. 키보드를 두드리는 일에서 “이게 맞는지 가려내는 일”로. 그리고 이건 단순히 리뷰를 더 빨리 하면 되는 문제가 아니다.
AI 코드는 다르게 틀린다
사람 코드의 실수는 대개 눈에 띈다. 오타, 빠뜨린 처리, 어설픈 구조. 표면이 고르지 않아서 “여긴 대충 썼네” 하고 의심이 든다.
AI 코드는 반대다. 변수명도 깔끔하고 구조도 멀쩡하고 주석까지 붙어 있다. 전부 매끄러워서 빠르게 승인하게 된다. 그런데 모델은 잘 풀리는 경우(happy path)를 잘 쓰는 대신, 에러 핸들러·재시도·경계 조건 같은 덜 화려한 곳에서 품질이 떨어진다. 매끄러운 표면 아래에 미묘한 오류가 숨는다. 그 “그럴듯함”이 바로 함정이다.
여기에 더 고약한 게 하나 있다. 모델이 구현과 테스트를 함께 쓰면, 둘이 같은 잘못된 가정을 공유한다. 테스트가 녹색인데 틀린 동작을 검증하고 있는 것이다. “테스트 통과 = 정상”이 더는 성립하지 않는다.
그래서 더 빨리가 아니라 다르게
핵심은 순서를 바꾸는 거다. AI 코드는 스타일이 거의 항상 멀쩡하니, 거기에 속아 진짜 봐야 할 데를 건너뛰면 안 된다.
위에서부터 본다 — 요구한 그것을 만들었나(의도), 기존 계약을 깼나(API), 입력 검증·인증은 됐나(보안), 엣지 케이스와 실패 경로는 처리됐나(행동). 테스트의 진위는 따로 의심하고, 가독성·스타일은 맨 마지막에 가볍게. 매끄러움은 정확성의 증거가 아니다.
그리고 생성이 빠른 만큼 검증에 시간을 더 써야 균형이 맞는다. 10배 빨리 쓰는데 같은 속도로 훑으면, 그 차이는 고스란히 부채로 쌓인다. 예전에 「인지 부채」에서 짚었던 그 부채다.
리뷰는 바깥 루프의 검증 게이트다
이걸 한 단계 위에서 보면 그림이 분명해진다. 지난번 「Loop Engineering」에서 진짜 새로운 건 안쪽 루프(생성)가 아니라 바깥 루프(무엇을 시키고, 검증하고, 다시 투입하나)라고 했다. 코드 리뷰는 그 바깥 루프에서 가장 중요한 검증 게이트다.
생성을 자동화할수록, 시스템 품질의 상한은 이 게이트의 품질이 결정한다. 게이트가 허술하면 빠른 생성은 빠른 사고 생산일 뿐이다. 그래서 리뷰 기준을 팀의 PR 템플릿에 박아두는 게 중요하다 — 리뷰어가 바뀌어도 사각지대가 일정해진다.
체크리스트와 PR당 10–15분 워크플로우를 한 장으로 정리한 AI 코드 리뷰 가이드를 따로 만들어 뒀다 — 실패 모드 4종부터 6계층 체크리스트까지.