AI가 PR을 만든다 — 코드 리뷰는 누구의 일인가

팀에서 AI 보조 개발 도구를 본격적으로 쓰기 시작한 지 몇 달이 됐다. 처음에는 자동완성 수준이었는데, 이제는 브랜치를 따고 커밋을 쌓고 PR까지 올리는 흐름이 일상이 됐다. 그러다 연초에 팀원 한 명이 물었다. “AI가 만든 PR이면, 리뷰는 누구 기준으로 하는 거야?”

처음에는 별 생각 없이 “그냥 코드 보면 되지”라고 답했다. 그런데 그게 틀린 말은 아니지만, 뭔가 핵심을 비껴가는 답이라는 느낌이 남았다.

리뷰의 원래 역할

코드 리뷰는 버그를 찾는 일이기도 하지만, 원래는 그보다 더 많은 걸 담당했다. 작성자가 설계 결정을 다른 사람에게 설명하는 과정이었고, 팀 전체가 같은 방향을 보고 있는지 확인하는 자리였다. 무엇을 왜 이렇게 만들었는지를 코드에 기록하는 행위이기도 했다.

그런데 AI가 PR을 만들면, 이 과정에서 “설명하는 주체”가 사라진다. AI는 주어진 요구사항에 맞춰 구현을 생성하지만, 그 구현이 팀의 아키텍처 방향과 맞는지, 앞으로의 확장 가능성을 충분히 고려했는지를 스스로 판단하지는 않는다. 판단의 무게가 고스란히 리뷰어에게 넘어온다.

리뷰어가 더 많이 봐야 하는 것들

AI가 생성한 코드에서 우리가 반복적으로 발견한 패턴이 있다. 기능 자체는 잘 작동하지만, 예외 케이스 처리가 지나치게 방어적으로 작성되거나, 반대로 경계 조건을 아예 무시하는 경우다. 또 기존 코드에 있는 헬퍼 함수나 유틸리티를 모르고 비슷한 로직을 새로 만드는 경우도 많다.

이런 문제는 전통적인 리뷰에서도 발생하지만, AI가 생성한 코드에서는 더 체계적으로 나타나는 경향이 있다. 모델이 컨텍스트 윈도우 안에서만 코드를 보기 때문에, 프로젝트 전체의 관습이나 암묵적인 설계 결정을 반영하지 못한다.

그래서 우리는 리뷰 체크리스트를 조금 바꿨다. 로직의 정확성뿐 아니라, “이 코드가 팀의 기존 패턴과 일관성이 있는가”를 별도 항목으로 두기 시작했다.

책임은 여전히 사람에게 있다

AI가 PR을 만든다고 해서 책임 소재가 달라지지는 않는다. 결국 그 PR에 승인을 누르는 것은 사람이고, 그 코드가 프로덕션에 올라갔을 때 생기는 문제는 팀이 안는다. 어떤 도구를 썼느냐는 변명이 되지 않는다.

오히려 AI 도구를 쓰면서 우리가 느낀 건, 리뷰어의 역할이 줄어드는 게 아니라 성격이 달라진다는 것이다. 줄 단위의 문법 검토는 줄었지만, 설계 방향을 잡는 판단은 오히려 더 자주 요구된다. 그 판단을 잘 하려면 시스템 전체를 이해하는 사람이 여전히 필요하다.

새해 첫 주에 이 질문을 다시 떠올리게 된 건, 아마 앞으로도 이 문제가 계속 진화할 거라는 예감 때문이다.

— by slecs