카카오페이 기술 블로그의 「PR을 더 느리게 만들기 위한 고민」을 읽었다. AI를 쓰면서 1인당 PR 생산량은 두 배가 됐는데 머지까지 걸리는 시간은 그대로였고, 그래서 리뷰를 빨리 끝내는 대신 리뷰하기 쉬운 PR을 만드는 쪽으로 방향을 튼 기록이다.

글은 이 장면에서 시작한다.

다음 날 approve(승인)가 왔다. 코멘트는 “LGTM(Looks Good To Me, 승인) 👍” 하나. 800줄짜리 PR인데.

AI가 코드를 끝냈다는 것과 내가 그 변경을 받아들일 수 있다고 판단했다는 것은 같은 일이 아니다.

병목이 코드에서 리뷰로 옮겨갔다

AI 도입 전후로 비슷한 규모의 두 프로젝트를 비교한 대목이 있다. 1인당 일평균 PR은 0.8건에서 1.7건으로 늘었는데, PR이 열리고 머지되기까지는 여전히 다섯 시간 넘게 걸렸다. 주 리뷰어 한 명이 전체 리뷰의 63%를 맡고 있었으니 머지 시점은 그 사람의 가용성에 묶인다.

코드를 만드는 속도는 AI가 해결했지만, 코드를 이해하는 속도는 여전히 사람의 한계 안에 있습니다.

이 상태가 이어지면 리뷰는 통과 의례가 된다.

리뷰가 품질 게이트가 아니라 머지 전 형식적 절차로 변질되었습니다.

영향 범위가 넓은 공통 모듈 변경일수록 리뷰 부담이 커서 미뤄지고, 미뤄지면 충돌이 쌓이고, 결국 아무도 안 건드리는 영역이 된다. 이걸 기술부채와 구분해 리뷰부채라고 불렀다.

PR 템플릿을 체크리스트에서 의사결정 문서로

이 팀의 대응은 PR 템플릿을 바꾸는 것이었다. 변경 파일과 테스트 결과만 나열하는 체크리스트에서 벗어나 다음 내용을 PR에 담는다.

  • 해결하려는 문제와 지금 해야 하는 이유
  • 선택한 방법과 검토했지만 택하지 않은 방법
  • 한계와 감수하기로 한 비용
  • 기존 기능에 미치는 영향과 실패할 수 있는 지점
  • 리뷰어의 판단이 필요한 곳

가장 중요한 항목으로 꼽은 건 “왜 해야 하나요?”다.

“왜?”를 쓰는 행위 자체가 “이걸 지금 해야 하는가?”를 검증하는 과정입니다. (…) 이건 리뷰어가 아닌 작성자 자신에게 던지는 질문이어야 합니다.

이 항목이 왜 필요해졌는지에 대한 설명이 특히 와닿았다. 예전에는 구현 비용이 높아서 “이걸 지금 해야 하나”가 저절로 걸러졌다. 리네임이든 구조 개선이든 하루가 걸리니 시작 전에 한 번 생각하게 됐다. 지금은 30분이면 되니 그 필터가 사라졌고, 할 수 있다는 이유만으로 PR이 열린다.

나머지 항목은 리뷰어 몫이다. 그중 한계와 트레이드오프 칸의 쓰임이 재밌었다.

PR 템플릿의 “한계 & 트레이드오프” 섹션이 비어 있으면, 판단할 게 없다는 뜻이 됩니다. 채워져 있다면, 사람이 봐야 한다는 신호로 작용하게 됩니다.

칸 하나가 리뷰어에게 어디에 시간을 쓸지 알려주는 신호가 된다.

내 쪽에서는 작업 문서가 PR보다 먼저다

운영 중인 백엔드 프로젝트에서는 프로젝트 전용 개발 파이프라인 스킬을 작업 시작점으로 쓴다. 작업 개요를 설명하면 요구사항을 정리하고, 배경과 변경 대상, 제약, 테스트 항목을 담은 작업 문서를 만든다.

이 문서는 구현 전에 한 번 쓰고 끝내는 계획서가 아니다. 설계를 검토하며 비교한 다른 방법, 선택한 이유, 감수한 비용을 보탠다. 구현 중 예상과 다른 사실이 나오거나 검증 범위가 바뀌면 그것도 같은 문서에 반영한다.

작업 개요
  ↓
결정과 검증 결과가 쌓이는 작업 문서
  ↓
PR
  ↓
릴리즈 노트·위키

작업이 끝나면 AI가 이 문서와 실제 변경, 테스트 결과를 함께 읽어 PR 본문을 만든다. 무엇을 바꿨는지만 요약하는 게 아니라 처음 해결하려던 문제, 구현 중 내린 결정, 영향 범위, 남은 위험, 리뷰할 곳을 연결할 수 있다.

여러 PR을 모아 릴리즈 노트를 만들 때는 최종 사용자가 겪는 변화를 중심으로 다시 정리하고, 위키를 갱신할 때는 나중에 변경 이유와 테스트 범위를 찾을 수 있는 기록으로 다듬는다. 같은 내용을 복사하는 건 아니지만 출발점은 하나의 작업 문서다.

처음 만든 작업 문서를 잘 쓰는 일은 문서 하나를 완성하는 게 아니라, 뒤에 이어질 문서의 재료를 정돈하는 일이다.

정리된 순서도 같다.

설계 문서가 PR보다 먼저 나온다. 코드를 쓰기 전에 “왜”를 정리해야 하며 AI가 이 과정을 도와줍니다.

AI가 먼저 훑고, 사람은 다른 것을 본다

이 팀은 PR이 열리면 AI 리뷰어가 네 단계로 자동 리뷰한다. 코멘트 188개 중 코드 수정으로 이어진 건 16%였다. 낮아 보이는 수치인데, 나머지에도 값이 있다고 봤다. 근거를 대고 거절한 8%가 그대로 의사결정 기록이 됐기 때문이다.

역할이 갈린 게 숫자로 드러난다. 예외 처리 지적은 AI 44건 대 사람 4건, 질문과 토론은 AI 19건 대 사람 23건이었다.

AI는 구조적 이슈를 넓게 스캔했고, 사람은 비즈니스 맥락 기반의 질문과 토론에 집중했습니다.

내 쪽도 비슷하게 굴러간다. AI는 코드와 문서를 함께 읽으며 변경 범위를 요약하고 코딩 규칙 위반이나 예외 처리, 테스트 누락 가능성을 먼저 찾는다. 플랜과 실제 구현이 달라진 곳도 비교한다. 사람은 그 결과를 놓고 기능이 요구사항에 맞는지, 상태 전이와 데이터 처리가 도메인 규칙에 맞는지, 선택한 설계의 비용을 감수할 수 있는지를 본다. 코드도 계속 읽지만 읽는 목적이 누락 찾기에서 결정의 적합성 확인으로 옮겨간다.

AI의 검토 결과는 승인이 아니라 사람이 판단할 범위를 좁혀 주는 자료다.

AI 리뷰어는 사람을 대체하지 않습니다. 사람이 보기 전에 먼저 훑어주는 동료입니다.

느려야 할 곳에서만 멈춘다

책임의 위치를 PR 올리기 전으로 이동해야 합니다.

모든 변경을 오래 붙잡자는 뜻은 아니다. 리네임이나 포맷팅은 컨벤션대로 됐는지 확인하면 끝나고, 비즈니스 로직 변경이나 트레이드오프가 걸린 설계는 판단이 필요하다.

내가 쓰는 기준도 여기 붙는다. 선택한 이유를 내 문장으로 쓰지 못하면 구현이 아무리 빨랐어도 아직 준비가 끝나지 않은 것이다. 그때 충분히 생각하고 기록해 두면 PR이 열린 뒤 리뷰어가 맥락을 되짚는 시간은 오히려 줄어든다. PR 본문도 작업 뒤에 붙는 보고가 아니라 내 판단이 끝났는지 확인하는 자기 리뷰가 된다.

마지막 문단은 이렇다.

느려야 할 곳을 알고 그곳에서만 멈추자는 것입니다.

작업 방식이 바뀌면서 문서에 무엇을 남기고 리뷰에서 무엇을 볼지가 달라졌다. AI가 아껴 준 시간의 일부는 다음 구현이 아니라, 내가 책임질 판단을 확인하는 데 쓰려고 한다.