코드 리뷰를 AI에게 넘기라는데, 나는 아직 못 하겠다

AI가 코드를 쓰는 속도는 계속 빨라지는데, 그 코드를 읽는 내 속도는 그대로다.

요즘 개발에서 제일 느린 구간은 코드를 쓰는 AI가 아니라 그 코드를 확인하는 나였다.

리뷰는 AI에게 ?

이 병목을 두고 요즘 자주 들리는 답이 있다. 1차 코드 리뷰는 AI에게 맡기고 사람은 정말 중요한 부분만 본다는 것이다. 커뮤니티에서만 도는 말이 아니다. Microsoft도 AI 에이전트와 함께 개발하는 팀이 새로 지켜야 할 규칙으로 같은 이야기를 꺼냈다.

Don't let code review become a bottleneck

When small teams can ship hundreds of PRs every month, staying close to the codebase requires deliberate effort. Start using and trusting agentic code review tools like CCR, shifting first-pass code reviews to agents, and keeping humans in the loop for architectural oversight.

코드 리뷰가 병목이 되게 두지 마라

작은 팀이 한 달에 PR을 수백 개씩 내보낼 수 있게 되면, 코드베이스를 계속 파악하는 데 의도적인 노력이 필요하다. CCR 같은 에이전트 기반 코드 리뷰 도구를 쓰고 신뢰하기 시작하라. 1차 코드 리뷰는 에이전트에게 넘기고 아키텍처 감독에는 사람이 계속 관여하라.

출처: Jay Parikh, Introducing Command Line, and the new rules for builders

모르는 코드를 배포할 수 있을까 ?

개인 프로젝트라면 이 방식도 괜찮다고 생각한다. 그런데 실무는 다르다. 어떤 코드가 들어갔는지 모르는 상태로 배포하는 게 정말 가능할까? 나는 아직 그렇게는 못 하겠다. 그래서 리뷰를 넘기는 대신 질문을 바꿔 봤다.

사람이 확인하는 병목을 어떻게 줄일 수 있을까?

전에는 IntelliJ에서 파일을 돌아다녔다

IntelliJ가 익숙해서 AI가 작성한 코드를 IntelliJ에서 직접 확인했다. 이 파일 저 파일을 오가며 바뀐 곳을 찾아 읽었다.

문제는 코드 자체보다 읽는 순서였다. AI가 어떤 의도로 이 코드를 썼는지, 어디서부터 읽어야 흐름이 이어지는지 정해져 있지 않아서 코드를 이해하고 확인하는 데 시간이 더 걸렸다.

읽기 쉽게 쓰게 하고, 순서대로 설명하게 한다

지금은 두 가지를 바꿨다.

읽기 쉬운 코드로 쓰게 한다

매번 프롬프트로 부탁하는 대신 /implement-readable-code라는 스킬로 만들어 두었다. 핵심은 세 가지다.

• 실제 흐름부터 읽는다: 코드를 쓰기 전에 요구사항, 호출하는 곳, 테스트, 옆에 있는 비슷한 구현을 먼저 확인한다.
• 가장 작은 해결책을 고른다: 요구사항에 없는 기능은 빼고, 이미 있는 코드와 패턴을 먼저 재사용하고 그래도 안 될 때만 새로 쓴다.
• 이름과 책임을 먼저 정한다: 메서드 하나는 일 하나만 하고 data, process, handle 같은 흐릿한 이름 대신 도메인 용어를 쓴다.

읽는 시간이 줄어드는 이유는 단순하다. 코드가 적으면 읽을 게 적다. 이미 아는 패턴을 재사용하면 새로 이해할 게 적다. 이름이 의도를 말해 주면 본문을 다 열어 보지 않아도 흐름이 보인다.

작성한 코드를 순서대로 설명하게 한다

구현이 끝나면 작성한 코드를 전부 의도와 함께 설명하게 한다. 이것도 같은 스킬의 마지막 단계로 넣었다. 설명은 코드가 실행되는 순서를 따른다.

바뀐 코드를 실제로 보여주고 왜 필요한지 붙인다. 생략 부호나 "비슷하게 수정" 같은 요약으로 넘어가는 건 허용하지 않는다. 이제 설명을 위에서 아래로 읽으면 실행 순서를 그대로 따라갈 수 있다.

물론 모든 상황에 맞는 방법은 아니다. 새 프로젝트를 시작해서 코드를 한꺼번에 많이 만든다면, 모든 변경을 순서대로 설명받는 게 오히려 비효율적일 수 있다.

그런데 실무 대부분은 이미 있는 프로젝트에 기능을 추가하거나 동작을 수정하거나 오류를 고치는 일이다. 이 범위에서는 확인하는 시간이 줄어든 게 확실히 느껴진다.

AI 코드 리뷰는 어디에 쓸까 ?

그렇다고 AI 코드 리뷰를 쓰지 않는 건 아니다. 사람이 읽는 일을 대신하게 두지 않을 뿐이다.

내가 놓치기 쉬운 곳을 맡긴다

설명을 순서대로 다 읽고 이해해도 놓치는 부분은 생긴다. 흐름을 따라 읽다 보면 정상적으로 동작하는 경로에 눈이 먼저 가고 값이 비어 있거나 범위 끝에 걸리는 경우는 지나치기 쉽다.

그래서 AI 리뷰는 정상 흐름에서 벗어난 경로를 중심으로 검증하게 한다.

• NULL이나 빈 값: 조회 결과가 없거나 필수 값이 비어 있을 때 NullPointerException으로 멈추지 않는지
• 경계값: 자정처럼 날짜가 바뀌는 시점이나 마지막 페이지에서 <와 <= 차이로 데이터가 빠지거나 겹치지 않는지
• 중복 요청: 버튼을 두 번 누르거나 재시도로 같은 요청이 다시 들어왔을 때 데이터가 두 번 저장되지 않는지
• 일부 실패: 여러 건을 처리하다 중간에 하나가 실패했을 때 앞의 작업만 반영된 채 남지 않는지

새 세션에서 리뷰한다

• 구현한 세션이 아닌 새 세션에서 시작한다: 코드를 쓴 AI는 자기가 세운 가정을 그대로 믿기 쉽다.
• 구현한 AI의 설명은 넘기지 않는다: 그 설명을 근거로 삼으면 같은 착각을 한 번 더 할 뿐이다.

읽고 배포 !

Microsoft 글이 틀렸다고 생각하지는 않는다. 한 달에 PR이 수백 개씩 나오는 팀이라면 사람이 모든 줄을 읽는 방식은 버티기 어렵다. 나도 언젠가는 1차 리뷰를 AI에게 넘기게 될지도 모른다.

다만 지금 내가 줄여야 할 건 확인 자체가 아니라 확인에 드는 시간이었다. AI가 읽기 쉽게 쓰고 순서대로 설명하게 만들면, 사람이 읽는 과정을 빼지 않고도 병목은 줄어든다.