AI가 코드를 빨리 만들자 사람은 코드를 읽지 않기 시작했다
모든 PR을 두 명 이상이 읽던 팀에서 사람의 리뷰가 거의 사라졌다. AI 리뷰어 세 명을 더 붙였는데도 남은 문제는 무엇이었을까?
- 모든 PR을 작성자와 동료가 검토하던 한 팀은 새 제품의 배포 속도를 높이려고 리뷰를 선택 사항으로 바꿨고, 몇 달 뒤 사람의 검토가 거의 사라졌다.
- 여러 AI가 서로의 코드를 검수해도 누가 설계 의도와 실패 조건을 이해하고 책임지는지는 해결되지 않는다.
- 결제·권한·데이터·배포처럼 실패 비용이 큰 변경은 사람 리뷰를 의무화하고, 제출자는 코드를 설명·방어·유지할 수 있어야 한다.
5개월 전까지 한 개발팀의 모든 PR은 최소 두 사람이 읽었다. 코드를 만든 개발자가 먼저 확인하고, 한 명 이상의 동료가 다시 검토했다. 새 제품을 시작하면서 운영 중인 서비스가 없다는 이유로 코드 리뷰를 선택 사항으로 돌렸다.
초기에는 대부분의 PR이 여전히 검토를 받았다. 하지만 몇 시간 기다리던 변경을 몇 분 안에 배포하는 경험이 반복되자 리뷰를 건너뛰는 일이 늘었다. 몇 달 뒤 사람의 코드 리뷰는 거의 사라졌다.
팀은 서로 다른 지시를 받은 세 AI 에이전트가 코드를 검토하고 결과를 합치는 단계도 만들었다. 문제는 결함을 찾는 도구의 수가 아니었다. 작성자가 에이전트가 만든 코드를 이해하고, 다른 개발자가 그 변경을 함께 설명할 수 있는지가 흐려졌다.
리뷰를 선택 사항으로 만들면 가장 바쁜 날의 규칙이 된다
선택 사항인 절차는 시간이 남을 때만 작동한다. 출시 일정이 가까워지고 PR 수가 늘어나면 가장 먼저 생략된다. AI는 코드를 쓰는 시간을 줄이지만 읽고 판단하는 속도까지 같은 비율로 높이지는 않는다.
한 숙련 개발자는 다른 사람의 AI 생성 PR이 1,000~2,000줄에 이르고 반복 코드와 기본적인 문제가 남아 있다고 호소했다. 가장 많은 지지를 받은 대응은 리뷰어가 문제를 대신 하나씩 고치는 것이 아니었다. 작성자가 자기 코드를 먼저 읽지 않았다면 리뷰 준비가 되지 않은 PR로 돌려보내라는 것이었다.
병목은 코드 생성에서 검토 가능한 변경을 만드는 과정으로 이동한다. 큰 변경을 의도별로 나누고, 왜 이 파일을 바꿨는지 설명하고, 실패 조건을 테스트로 고정하는 시간은 여전히 필요하다.
AI 리뷰 세 개를 붙여도 책임자는 생기지 않는다
자동 리뷰는 반복 코드, 누락된 테스트, 흔한 보안 실수, 타입 오류와 범위 이탈을 빠르게 찾는다. 같은 변경을 다른 모델과 지시로 검수하면 한 모델이 놓친 문제도 보완할 수 있다.
그러나 세 에이전트가 승인했다고 해서 세 사람이 코드를 이해한 것은 아니다.
| 사람이 답해야 할 질문 | 자동 리뷰만으로 부족한 이유 |
|---|---|
| 어떤 사업 문제를 해결하는가 | 저장소 밖의 우선순위와 고객 영향은 코드만으로 확정하기 어렵다 |
| 왜 이 구조를 선택했는가 | 여러 구현 가운데 장기 유지보수에 적합한 구조를 고르는 일은 팀의 판단이다 |
| 실패하면 어떤 데이터가 손상되는가 | 운영 상태와 복구 순서를 알아야 한다 |
| 누가 장애를 고칠 수 있는가 | 생성 모델은 온콜 책임과 조직 기억을 갖지 않는다 |
| 언제 되돌려야 하는가 | 고객 영향과 운영 지표에 맞춘 기준이 필요하다 |
자동 리뷰는 사람 리뷰 앞의 필터로 두는 편이 맞다. 기계적인 문제를 먼저 제거해 사람이 설계, 권한, 데이터와 복구 가능성에 집중하게 해야 한다.
코드를 만들었지만 설명하지 못하는 상태가 늘어난다
2026년 공개된 한 실험은 AI 코딩 보조를 사용한 참가자가 자신이 구현한 코드에 관한 기술 질문에 답하는 능력이 비교군보다 12.5% 낮았다고 보고했다. 코드 완성과 코드 이해는 같은 지표가 아니었다.
Anthropic이 약 40만 개의 Claude Code 세션을 분석한 결과에서는 사람이 계획 결정의 약 70%를 내렸지만 실행 결정에서는 약 20%만 맡았다. 무엇을 만들지는 사람이 정하고, 어느 파일을 어떻게 바꿀지는 에이전트가 결정하는 분업이다. 결과가 빨리 나오는 만큼 구현 세부를 사람이 다시 따라잡는 절차가 필요하다.
GraalVM 프로젝트의 정책은 AI를 사용해도 기존 리뷰·테스트·라이선스·코드에 대한 책임이 그대로라고 명시한다. 제출자는 변경 전체를 검토하고 이해해야 하며, 질문에 답하거나 변경을 유지할 수 없다면 기여가 거절될 수 있다.
모든 코드를 같은 강도로 읽을 필요는 없다
변경의 실패 비용에 따라 검토 강도를 나눠야 한다.
| 변경 등급 | 예시 | 사람 리뷰 기준 |
|---|---|---|
| 낮음 | 문서, UI 문구, 격리된 테스트, 내부 개발 도구 | 자동 검사 통과 후 작성자 확인으로 병합 가능 |
| 보통 | UI 상태, 내부 API, 비핵심 배치 작업 | 한 명이 의도·경계 조건·테스트를 확인 |
| 높음 | 인증, 권한, 결제, 공개 API, 데이터 마이그레이션 | 도메인 담당자 포함 두 명 이상이 검토 |
| 매우 높음 | 삭제, 암호화, 접근 제어, 되돌릴 수 없는 외부 행동 | 실행 계획·롤백·관측 지표까지 승인한 뒤 배포 |
줄 수만으로 위험을 판단해서는 안 된다. 설정 한 줄이 인증 체계를 무력화할 수 있고, 자동 생성된 테스트 500줄은 운영 동작을 바꾸지 않을 수 있다. 권한, 돈, 데이터, 공개 인터페이스와 복구 가능성을 먼저 본다.
PR 작성자가 설명해야 할 네 가지
- 의도: 어떤 문제를 해결하며 하지 않는 일은 무엇인가.
- 핵심 경로: 입력이 어디로 들어와 어떤 상태를 바꾸는가.
- 실패 조건: 어떤 입력·권한·네트워크·데이터 상태에서 깨지는가.
- 복구 방법: 배포 뒤 무엇을 보고 언제 되돌릴 것인가.
작성자가 네 가지를 자기 말로 설명하지 못하면 PR은 아직 리뷰 준비가 끝나지 않은 것이다. AI에게 요약문을 만들게 할 수는 있지만 리뷰어의 질문에 답하고 수정 결정을 내릴 사람은 제출자여야 한다.
속도를 유지하려면 리뷰를 없애는 대신 변경 단위를 줄인다. 구현 전에 위험 등급을 정하고, 한 가지 의도만 담은 작은 변경을 만든 뒤 자동 검사로 기계적인 결함을 제거한다. 작성자가 diff를 읽고 설명을 남기면 위험 등급에 맞는 사람이 설계와 실패 조건을 본다.
코드 리뷰가 지키는 것은 코드보다 팀의 기억이다
리뷰는 버그를 잡는 절차만이 아니다. 누가 이 구조를 이해하는지, 왜 이런 선택을 했는지, 장애가 나면 어디서 시작해야 하는지를 팀 안에 공유하는 과정이다.
AI가 코드 생산을 빠르게 할수록 이 역할은 더 중요해진다. 사람이 읽지 않은 코드는 당장 테스트를 통과할 수 있다. 하지만 장애가 생겼을 때 설명할 사람이 없다면 생성에서 아낀 시간이 그대로 복구 비용이 된다.
AI가 코드를 작성해도 PR에 이름을 올린 사람이 의도·실패 조건·복구 방법을 설명해야 한다. 설명할 수 없는 변경은 아직 완료된 코드가 아니다.
자주 묻는 질문
AI가 만든 코드는 모두 사람이 줄마다 읽어야 하나?
아니다. 문서·격리된 테스트처럼 위험이 낮은 변경은 자동 검사와 작성자 확인으로 충분할 수 있다. 인증·권한·결제·데이터 마이그레이션·삭제처럼 실패 비용이 큰 변경은 사람 리뷰를 의무화해야 한다.
AI 코드 리뷰 여러 개를 사용하면 사람 리뷰를 대체할 수 있나?
자동 리뷰는 반복 코드와 누락된 테스트를 찾는 필터로 유용하다. 그러나 설계 의도, 운영 영향, 롤백 기준과 유지보수 책임을 맡을 사람까지 만들어 주지는 않는다.
AI가 만든 PR의 작성자는 무엇을 설명해야 하나?
변경의 의도, 핵심 실행 경로, 실패 조건, 배포 뒤 복구 방법을 자기 말로 설명할 수 있어야 한다. 네 가지를 설명하지 못하면 아직 리뷰 준비가 끝나지 않은 변경이다.
AI 시대에 코드 리뷰 속도를 높이는 가장 현실적인 방법은 무엇인가?
큰 변경을 한 가지 의도씩 나누고, 자동 검사로 기계적인 결함을 먼저 제거한 뒤 사람이 위험한 경계와 실패 조건에 집중하는 방식이 가장 현실적이다.