카카오페이 기술 블로그의 「PR을 더 느리게 만들기 위한 고민」을 읽었다. 글에서 오래 머문 부분은 PR을 빨리 통과시키는 방법이 아니라, 어떤 변경에서 의도적으로 멈춰야 하는지를 정하는 대목이었다.

글은 AI로 코드가 빨리 만들어진 뒤 병목이 코드를 작성하는 곳에서 이해하고 판단하는 곳으로 옮겨갔다고 설명한다. 그래서 리뷰를 무조건 빨리 끝내기보다, 사람이 판단해야 하는 변경과 자동 검증으로 빠르게 확인할 수 있는 변경을 나누고 고민할 시간을 PR 이전으로 옮긴다.

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

PR 본문이 의사결정 문서라는 말

참고 글은 이를 “PR 본문이 의사결정 문서다”라고 정리했다. 변경 파일과 테스트 결과만 나열하는 체크리스트에서 벗어나 다음 내용을 PR에 담는 방식이다.

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

이 중 작성자에게 가장 먼저 필요한 것은 작업을 지금 해야 하는 이유다. AI가 구현 비용을 낮췄다고 해서 할 수 있는 변경을 모두 지금 해야 하는 것은 아니다. 이유를 쓰는 과정에서 작업의 필요성이 약하다는 사실을 발견할 수도 있다.

나머지는 리뷰어가 코드를 읽기 전에 설계 의도를 이해하도록 돕는다. 플랜과 구현 과정에서 나온 선택이 PR에 남으면 리뷰어는 diff에서 맥락부터 복원하지 않아도 된다. AI가 제안한 방법을 택하지 않았더라도 거절한 근거를 답해 두면, 그 대화도 구현 이유를 설명하는 기록이 된다.

실무에서는 작업 문서가 먼저였다

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

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

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

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

작업 문서를 바탕으로 잘 작성한 PR은 다시 다음 문서의 재료가 된다. 여러 PR을 모아 릴리즈 노트를 만들 때는 최종 사용자가 겪는 변화를 중심으로 다시 정리하고, 위키를 갱신할 때는 나중에 변경 이유와 테스트 범위를 찾을 수 있는 기록으로 다듬는다. 같은 내용을 복사하는 것은 아니지만 출발점은 하나의 작업 문서다. AI가 초안을 만들더라도 독자에 맞게 덜어내고 사실을 확인하는 일은 사람이 한다.

처음 만든 작업 문서를 잘 쓰는 일은 문서 하나를 완성하는 것이 아니라, 뒤에 이어질 문서의 재료를 정돈하는 일이다. 배경과 결정이 정확하면 PR과 릴리즈 문서에서도 이유를 다시 추측하거나 빠진 내용을 뒤늦게 복원할 일이 줄어든다.

사람이 집중해서 볼 곳도 달라졌다

AI는 코드와 문서를 함께 읽으며 변경 범위를 요약하고, 코딩 규칙 위반이나 예외 처리와 테스트 누락 가능성을 먼저 찾는다. 플랜과 실제 구현이 달라진 곳도 비교할 수 있다. 이 검토를 먼저 거치면 사람이 반복해서 확인할 항목을 처음부터 모두 찾는 부담은 줄어든다.

사람은 그 결과를 바탕으로 이 기능이 요구사항에 맞는지, 상태 전이와 데이터 처리가 도메인 규칙에 맞는지, 선택한 설계의 비용을 감수할 수 있는지를 더 오래 본다. 코드도 계속 읽지만 읽는 목적이 단순한 누락 찾기에서 결정의 적합성을 확인하는 쪽으로 옮겨간다.

AI의 검토 결과는 승인이 아니라, 사람이 판단할 범위를 좁혀 주는 자료다. AI의 질문이 미처 쓰지 않은 근거를 꺼내게 할 수는 있지만, 기술적으로 맞는지와 실제 요구사항에 맞는지에 대한 책임까지 넘겨주지는 않는다.

속도를 늦출 곳은 PR 이전이다

참고 글에서 가장 중요하게 읽은 문장은 “책임의 위치를 PR 올리기 전으로 이동해야 합니다”였다.

모든 변경을 오래 붙잡자는 뜻은 아니다. 영향 범위가 작고, 정해진 규칙을 반복하며, 자동 검증으로 결과를 분명하게 확인할 수 있는 변경은 빠르게 진행할 수 있다. 반대로 비즈니스 규칙, 데이터 마이그레이션, 권한, 외부 API 계약처럼 되돌리기 어렵거나 선택지가 여러 개인 변경은 작업 문서와 플랜 단계에서 한 번 더 멈춘다.

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

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