AI 시대의 PR, 작성자와 리뷰어의 역할

요즘 기능 하나를 개발하는 흐름은 이렇다. 설계 문서를 쓰고, 설계에 맞춰 작업을 나누고, AI가 작업마다 설계 문서를 읽어 구현한 뒤 PR을 만든다. PR이 열리면 AI 리뷰어가 코멘트를 달고, 그중 납득되는 것은 다시 AI가 반영한다.

이렇게 일하면서 내가 올리는 PR은 하루 2~3개에서 4~5개 정도로 늘었다. 정확히 센 건 아니지만 체감상 두 배쯤이고, 팀원들도 비슷해 보인다. 문제는 그만큼 내가 리뷰해야 할 PR도 늘었다는 점이다. 예전에는 PR 하나에 30분에서 한 시간을 썼는데, 아침마다 두 배로 쌓이는 PR에 그 시간을 계속 쓸 수는 없었다. 마침 AI 리뷰어가 코딩 컨벤션, 하위 호환성, 성능 문제를 꽤 잘 잡아 줬다. 그래서 점점 간단히 훑어보고 바로 approve를 누르게 됐다.

그러다 보니 이런 질문이 생겼다. AI가 대부분을 봐 준다면 내 approve는 무엇을 보증하는 걸까? 그리고 리뷰어가 그 역할을 제대로 하려면 PR 작성자는 무엇을 준비해야 할까?

이 글에서는 그 두 질문에 대해 지금까지 정리한 답을 소개한다.

비슷한 고민을 먼저 한 팀

답을 찾던 중에 카카오페이 기술 블로그의 「PR을 더 느리게 만들기 위한 고민」을 읽었다. 이 팀도 AI를 도입한 뒤 1인당 PR이 두 배로 늘었지만, 머지까지 걸리는 시간은 여전히 반나절이었다고 한다. 코드를 만드는 속도는 AI가 해결했는데, 코드를 이해하는 속도는 여전히 사람에게 묶여 있었던 것이다.

그래서 이 팀은 리뷰를 빠르게 하는 대신 리뷰하기 쉬운 PR을 만드는 쪽을 택했다. 설계 문서에서 작업을 분해해 subtask 하나를 PR 하나로 만들었다. PR 템플릿에는 “왜 해야 하나요?”와 “한계와 트레이드오프” 항목을 넣었다. AI 리뷰어가 예외 처리나 동시성 같은 구조적인 문제를 먼저 훑고, 사람은 비즈니스 판단과 최종 승인을 맡았다. 리네임이나 포맷팅처럼 확인만 하면 되는 PR과 설계 판단이 필요한 PR을 같은 무게로 보지 않는다는 기준도 세웠다.

읽어 보니 내가 이미 하고 있는 것도 있었고, 아직 하지 않은 것도 있었다.

PR을 쪼개는 일은 이미 하고 있었다

설계 단계에서는 TechDoc이라는 이름으로 문서를 두 벌 만든다. 사람들에게 공유할 문서와 AI가 읽을 문서다. AI가 먼저 스펙을 파악해 정리하면, 내가 그걸 읽고 이해한 다음 TechDoc을 쓴다. 검수하다가 스펙이 부실해 결정이 필요한 부분이 보이면 기획과 논의하고, 추가된 스펙을 다시 반영한다.

설계가 끝나면 AI로 작업을 나눈다. 크기는 티셔츠 사이징으로 잡는다. 작업 규모를 XS부터 XXL 같은 상대적인 크기로 추정하는 방법인데, 헷갈리지 않게 4~5개 사이즈만 쓴다. S 하나가 PR 하나가 되고, 테스트 코드를 빼고 300줄 안팎이 되도록 한다. M은 PR이 3개를 넘지 않게 하고, 되도록 대부분을 S로 쪼갠다.

쪼개는 순서는 평소에 사람이 개발하던 방식과 같다. 피처 개발이라면 스키마, API별 작업, 부가 기능 순이다. 다만 API 하나를 더 쪼개야 할지는 개발 전에 대략적인 감만 있고 확실하게는 모른다. 이 부분은 아직 AI의 판단에 어느 정도 기대고 있다. 작업이 나뉘면 병렬로 해도 되는지, 앞 작업이 끝나야 하는 의존 관계인지 따져서 워크트리를 만들고 개발한다.

카카오페이의 “1 subtask = 1 PR”과 거의 같은 방식이다. 작게 쪼개는 건 이미 되고 있었다.

PR 본문도 AI가 다 써 준다

개발이 끝나면 draft PR을 만들고 본문을 쓴다. 본문은 다섯 섹션으로 나뉜다.

섹션	쓰는 내용
Motivation	왜 이 기능을 개발해야 하는지. 기능 스펙이나 기술적인 한계
Modification	코드를 어떻게 수정했는지. 코드를 읽기 전에 먼저 읽으면 도움이 된다
Result	이렇게 개발해서 어떤 목적을 이루는지
Analyzing queries	어떤 쿼리가 얼마나 나가는지. JPA를 쓰면 놓치기 쉬운 N+1을 여기서 검토한다
Regression Test	기존 코드에 영향이 있는지, 따로 테스트가 필요한지. 하위 호환성을 보는 섹션이다

이 다섯 섹션은 PR 스킬로 AI가 충분히 잘 채운다. 지금까지는 사람이 끼어들 부분이 없었다.

그런데 카카오페이 템플릿과 나란히 놓고 보면 빠진 칸이 하나 있다. 한계와 트레이드오프다. 다섯 섹션은 전부 코드를 보면 쓸 수 있는 내용이다. 무엇을 검토했다가 버렸는지, 어떤 한계를 알고도 받아들였는지는 코드에 남지 않는다.

AI 코멘트를 그대로 받으면 생기는 일

이 칸이 왜 필요한지는 실제로 받았던 코멘트 하나로 설명할 수 있다.

개발자가 테스트할 때 로컬에서 수동으로 돌리는 엑셀 리포트 기능이 있다. 이 기능의 PR에 AI 리뷰어가 동시성을 고려해야 한다며 분산 락을 걸자는 코멘트를 달았다. 동시에 실행되면 문제가 생길 수 있다는 지적 자체는 틀리지 않다.

하지만 현실적으로 거기까지 갈 필요는 없었다. 누군가 가끔 수동으로 돌리는 기능이고, 분산 락을 걸면 개발자가 로컬에서 이 기능을 돌리기 위해 Redis 운영 환경 연결까지 챙겨야 한다. 막으려는 위험보다 새로 생기는 불편이 더 컸다.

예전이라면 이런 코멘트는 반영하는 비용 때문에 자연스럽게 걸러졌다. 락을 붙이는 작업 자체가 부담이었으니까. 지금은 코드를 작성하는 비용이 0에 가깝다. AI에게 “반영해 줘”라고 하면 몇 분 만에 끝난다. 그래서 코멘트를 받는 대로 반영하기 쉬워졌고, 그렇게 쌓인 변경은 리뷰어가 읽어야 할 양을 늘리고 당장 필요 없는 복잡도를 코드에 남긴다.

그래서 “이게 지금 필요한가?”를 묻는 일은 PR 작성자의 몫이라고 본다. 반영하지 않기로 했다면 그 판단을 PR 본문에 남긴다.

## 한계 & 트레이드오프
- 동시 실행 방지(분산 락)는 적용하지 않았다.
  - 이 기능은 개발자가 로컬에서 수동으로 실행한다.
  - 락을 걸면 로컬 실행에도 Redis 연결이 필요해진다.
  - 스케줄러로 자동 실행하게 되면 다시 검토한다.

리네임이나 단순한 CRUD처럼 판단할 게 없는 PR이라면 이 칸은 “없음”으로 둔다. 그러면 리뷰어는 칸이 비어 있는지만 보고도 빠르게 넘길 PR인지, 시간을 들여 볼 PR인지 가를 수 있다.

그래서 리뷰어는 무엇을 보는가

하위 호환성, N+1, 네이밍, 팀에서 정한 컨벤션은 AI 리뷰어가 먼저 본다. 사람이 이 항목들을 1순위로 다시 확인하지 않아도 된다. 물론 AI가 아무 말도 하지 않았다고 문제가 없다는 뜻은 아니다. AI는 후보를 넓게 찾아 주고, 머지에 대한 책임은 여전히 approve를 누른 사람에게 있다.

리뷰어가 시간을 들여 볼 곳은 작성자가 남긴 판단이다. 작성자가 왜 이 선택을 했는지, 그 이유가 납득되는지 본다. 이 설계가 지금 요구사항에 맞는지, 요구사항이 바뀌었을 때 팀이 감당할 수 있는 방식으로 고치거나 되돌릴 수 있는지도 본다.

엑셀 리포트 PR이라면 리뷰어는 “락이 없다”를 지적하는 대신 “개발자가 로컬에서 수동으로만 돌린다”는 전제가 맞는지를 확인한다. 운영에서 자동으로 호출하는 경로가 있다면 작성자의 판단은 틀린 것이고, 전제가 맞다면 락 없이 가는 선택에 동의하면 된다. 그러면 내 approve는 “이 판단에 동의한다”는 뜻이 된다.

아직 정하지 못한 것

카카오페이 글은 여기서 한 걸음 더 나간다. AI 리뷰만으로 머지할 수 있는 PR을 팀 규칙으로 정하고, 리뷰어의 역할을 “모든 코드를 읽는 사람”에서 “트레이드오프에 동의하는 사람”으로 바꾸자는 것이다. 그 팀도 아직 시도하기 전이다.

우리 쪽에도 남은 숙제가 있다. PR을 어떤 기준으로 쪼갤지는 여전히 개발 전의 감과 AI의 판단에 기대고 있다. 트레이드오프를 PR 본문에 남기는 방식이 실제로 리뷰를 얼마나 바꾸는지도 아직 확인하지 못했다.