코드를 쓰는 속도는 AI가 크게 끌어올렸지만, 변경이 시스템 안에서 어떤 결과를 낳는지 읽어 내는 일까지 사라진 것은 아니다. 2026년 8월 공개된 ‘Reviewing code is a skill’은 코드 리뷰를 승인 절차가 아니라, 팀이 변경의 전제와 실패 경로를 함께 점검하는 숙련으로 본다.
리뷰어가 보는 대상은 몇 줄의 문법이 아니다. 새 코드가 기존 실행 순서, 배포 환경, 다른 팀의 읽기 경로와 만날 때 무엇이 달라지는지다. 그래서 좋은 리뷰는 버그를 하나 찾는 데서 끝나지 않고, 작성자와 팀이 시스템을 이해하는 방식을 바꾼다.
AI가 만든 코드는 왜 더 넓은 맥락에서 읽어야 하나
AI는 요청한 기능의 코드를 빠르게 제안한다. 그러나 저장소 밖의 제약까지 자동으로 안다고 볼 수는 없다. 원문 저자는 실제 PR 세 건에서 고급 코딩 모델을 섞어 리뷰했지만, 자신이 발견한 문제를 모델이 잡지 못했다고 적었다. 파일 잠금의 경쟁 조건, CI에 설치된 CLI 버전, 아티팩트와 체크섬을 따로 올리는 순서가 그 사례다. 같은 코드라도 운영 환경의 버전이 다르거나 읽는 쪽이 이전 형식을 전제하면, PR 화면에서는 보이지 않던 문제가 배포 뒤에 드러난다.
예를 들어 같은 설정 파일을 두 프로세스가 수정한다면, 한쪽을 백그라운드로 옮기는 변경은 성능 개선처럼 보일 수 있다. 리뷰에서는 잠금 획득 실패가 재시도로 가려지는지, 대기 때문에 시작 시간이 늘어나는지, 한 번에 묶어야 할 쓰기가 있는지를 이어서 묻는다. 코드 한 줄보다 이 질문의 순서가 문제를 찾는다.
리뷰가 실제로 하는 일은 버그 탐지만이 아니다
Google 개발자 연구는 코드 리뷰에 교육, 팀 규범 유지, 경계 관리, 사고 예방이라는 네 기대가 함께 있다고 정리했다. 2013년 연구도 결함 탐지가 주된 동기이지만, 지식 이전과 팀의 변경 인지, 대안 탐색이 중요한 결과로 나타났다고 썼다. 리뷰 댓글이 “이 변수 이름을 바꾸자”에서 멈추지 않는 이유다.
이 역할을 이해하면 리뷰 요청도 달라진다. 작성자는 변경 이유와 버리지 않은 대안을 PR 설명에 남길 수 있고, 리뷰어는 “이게 맞나” 대신 “이 실패가 나면 누가 읽고 복구하는가”를 물을 수 있다. 같은 질문이 쌓이면 저장소의 암묵지가 댓글과 테스트로 옮겨 간다.
숙련은 지적보다 질문의 축적에서 나온다
원문 저자는 리뷰 코멘트 밀도가 대략 코멘트 하나당 30~100줄이었다고 소개한다. 대부분은 버그 지적보다 맥락을 묻는 질문, 이름, 계층과 관련된 코멘트였다. 많은 코멘트가 곧 좋은 리뷰라는 뜻은 아니다. 반복해서 쓰는 질문이 실제 실패 경로를 드러내는지가 더 중요하다.
팀은 최근 리뷰에서 막힌 변경 하나를 골라 짧게 되짚어 볼 수 있다. 어떤 가정이 코드에 숨어 있었는지, 어떤 신호가 리뷰에서 보였는지, 다음 PR 설명이나 테스트에 무엇을 남길지를 기록한다. 사고가 나기 전에 잡힌 사례도 학습 재료가 된다.
AI 리뷰 도구는 이 과정에서 넓은 탐색을 돕는다. 다만 모델의 제안은 리뷰를 끝내는 판정이 아니라 다음 질문을 고르는 재료로 쓰는 편이 낫다. 최종적으로 변경을 운영할 사람은 코드가 연결되는 곳과 실패했을 때의 복구 경로를 읽을 수 있어야 한다.
출처: TypeSanitizer, “Reviewing code is a skill”; Modern Code Review: A Case Study at Google; Expectations, outcomes, and challenges of modern code review