AI가 쏟아내는 거대 PR, 리뷰어는 왜 지쳐가는가

한 개발자가 자신의 블로그에 "제발 거대한 PR을 그만 보내달라"는 제목의 글을 올렸다. 요지는 단순하다. AI 코딩 에이전트가 이슈 하나를 통째로 처리해 수천 줄짜리 변경을 한 번에 만들어내면서, 그 결과물을 사람 손으로 검토해야 하는 리뷰어와 메인테이너의 부담이 급격히 늘고 있다는 것이다. 글쓴이는 AI가 산업에 큰 도움이 되는 도구라는 점은 인정하면서도, 지금의 사용 방식이 코드 리뷰라는 협업 절차에는 오히려 부채가 되고 있다고 토로한다.

작은 PR은 원래 작성자가 아니라 리뷰어를 위한 것이었다

글의 핵심 주장은 작은 PR의 목적에 대한 오해를 짚는 데 있다. 흔히 "이 변경은 전체를 다 넣지 않으면 동작하지 않는다", "부분만 올리면 코드가 아무 일도 하지 않는다"는 이유로 큰 PR을 정당화한다. 하지만 글쓴이는 작은 PR의 목적이 애초에 '완결된 작은 기능'을 만드는 데 있지 않았다고 반박한다. 작은 단위로 나누는 이유는 리뷰어가 소화하고, 검토하고, 이해할 수 있는 크기로 일을 쪼개기 위해서다. 부분만 올린 코드가 그 자체로 아무것도 하지 않아도 상관없다. 오히려 그것이 정상이라는 것이다.

작은 PR은 관행적으로 '작성하기 쉬워서'가 아니라 '읽는 사람을 위해서' 요구되어 왔다. 이 구분은 AI 시대에 특히 중요하다. 에이전트가 이슈 전체를 한 번에 처리할 수 있게 되면서, 작성 비용은 사실상 0에 수렴했지만 검토 비용은 그대로 사람에게 남았기 때문이다. 작성이 쉬워졌다고 해서 병합 단위까지 커져야 할 이유는 없다.

이해 비용은 코드 길이에 따라 지수적으로 늘어난다

글쓴이는 실증 데이터는 없다고 분명히 밝히면서도, 코드를 완전히 이해하는 데 드는 시간이 코드 줄 수에 비례하는 것이 아니라 지수적으로 증가한다고 추정한다. 근거를 제시한 주장은 아니지만 실무 감각으로는 공감하기 어렵지 않다. 변경된 줄이 늘어날수록 그 사이의 상호작용, 부작용, 맥락의 조합이 함께 폭발하기 때문이다. 기능 하나를 통째로 배포하려는 편의가 리뷰어의 시간을 몇 배로 잡아먹는 구조라면, 그 편의의 비용은 다른 사람이 대신 치르고 있는 셈이다.

주석에 대한 지적도 같은 맥락이다. 함수 단위의 문서화, 즉 jsdoc·rustdoc·javadoc 같은 형식화된 문서는 환영하지만, is_logged_in 같은 변수 하나에 다섯 줄짜리 설명을 붙이는 것은 불필요하다는 것이다. 변수 이름이 잘 지어졌다면 대개 설명 없이도 의미가 전달되고, 설명이 필요할 만큼 이름이 나쁘다면 주석을 다는 대신 이름을 고치는 편이 낫다. 코드의 가독성을 문서가 아니라 코드 자체로 확보하라는, 오래된 원칙의 재확인이다.

"AI로 읽으면 된다"는 반론의 허점

글쓴이는 "그냥 AI로 파악하면 되지 않느냐"는 이른바 AI 최대주의자들의 반론도 정면으로 다룬다. AI가 만든 코드를 다시 AI에게 먹여 이해시키는 것은 토큰 낭비이며, "리뷰에는 다른 모델을 쓴다"고 답한다면 애초에 왜 사람에게 리뷰를 맡겼느냐는 물음이 남는다. 그가 제안하는 대안은 간단하다. AI를 쓸 것이라면 그 AI로 먼저 변경을 사람이 검토할 수 있는 조각으로 나눠 두고, 사람이 검토를 마친 뒤에 다시 AI 검토를 돌리라는 것이다. 순서를 뒤집자는 제안이다.

비교 대상으로 그는 React의 등장을 든다. React가 나왔을 때 우리는 "React는 작성이 빠르고 읽기 쉬우니까"라는 이유로 더 큰 PR을 받아들이지 않았다. 도구가 생산성을 높였다고 해서 협업의 단위 기준을 흔들지는 않았다는 것이다. 그렇다면 AI에 대해서만 예외를 둘 이유도 없다는 논리다.

한국 실무 현장에 주는 시사점

이 글은 데이터가 아니라 한 메인테이너의 경험과 답답함에 기반한 주장이라는 한계가 분명하다. 지수적 이해 비용도 어디까지나 추정이고, 조직마다 리뷰 문화와 도구 사정은 다르다. 그럼에도 짚는 지점은 유효하다. AI 도입으로 코드 작성 속도가 빨라진 팀일수록, 리뷰 부하가 특정 인원에게 조용히 몰리고 있지 않은지 점검할 필요가 있다. 작성과 검토의 비용 균형이 깨지면 결국 리뷰가 형식화되고 품질 게이트가 무너진다.

실무적으로는 PR 크기에 대한 팀 규칙을 명시하고, 에이전트에게 기능 전체가 아니라 검토 가능한 단위로 변경을 쪼개도록 지시하는 워크플로가 현실적인 대응이 된다. 글 말미의 냉소적인 한마디, 즉 "혹시 리뷰어가 중간에 포기하고 승인하도록 일부러 거대한 PR을 보내는 것이냐"는 물음은 농담의 형식을 빌렸지만, 큰 변경이 사실상 검토를 무력화한다는 위험을 정확히 겨냥한다. AI가 만든 속도의 이득을 팀 전체가 누리려면, 그 속도가 리뷰 단계에서 병목이나 품질 저하로 되돌아오지 않도록 설계하는 일이 함께 가야 한다.