AI 변경을 동료가 리뷰할 수 있는 PR로 쪼개기

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

AI는 작성자가 동료의 읽는 순서를 정하기도 전에 큰 변경을 만들 수 있다. 그렇다고 결과의 책임까지 사라지지는 않는다. 회사에서 돌아가는 코드는 공동의 자산이며, 변경을 제출하는 사람은 팀이 이해할 수 있는 리뷰 경로를 만들어야 한다.

커밋과 PR을 구성하는 일도 작업에 포함해야 한다. 구현과 테스트가 있다는 이유만으로 생성된 변경이 곧바로 리뷰 가능한 것은 아니다.

작업 기록을 리뷰어의 읽는 순서로 다시 만든다

작업 중간의 커밋은 좋은 복구 지점이지만 모두 최종 리뷰 기록이 될 필요는 없다. 나는 브랜치 작업이 끝나면 변경을 한곳에 모은 뒤, 리뷰어가 중간 시행착오를 전부 재생하지 않아도 되도록 의미가 이어지는 단위로 커밋을 다시 구성하는 편이다.

한 파일이 여러 작업 커밋에서 반복해 바뀌었다면 관련 변경을 최종 기록 한곳에 모을 때 더 읽기 쉬울 수 있다. 기능 전에 필요한 리팩터링이나 패키지 이동은 별도 브랜치와 PR로 먼저 합칠 수도 있다. 기계적인 이동이 실제 동작 변경을 가리지 않게 하기 위해서다.

이 작업은 기록을 예쁘게 꾸미려는 것이 아니다. PR은 머지 뒤에도 남는다. 지금의 동료가 변경을 이해하게 하고, 미래의 작업자가 왜 바뀌었는지 찾게 해준다.

200개나 500개 파일 변경은 과도한 범위를 보여 주는 예시일 뿐, 모든 커밋과 PR에 적용할 숫자 기준이 아니다. 일관된 기계적 변경은 파일이 많을 수 있고, 열 개 파일만 바꿔도 서로 다른 관심사를 섞을 수 있다.

작게 요청했다고 생각했는데 변경이 매우 넓어졌다면 먼저 범위를 다시 본다. 한 세션에서 여러 일을 함께 시켰을 가능성이 있다. 동작 변경, 선행 리팩터링, 마이그레이션을 각각 이해하고 전달할 수 있다면 브랜치와 PR도 나눈다.

작업 맥락이 세션에 남아 있을 때 에이전트의 도움을 받을 수 있다. 변경을 분류하고, 커밋과 브랜치를 다시 만들고, 진행 과정을 담은 PR 설명을 쓰게 한다. 다만 그 분류가 말이 되는지 확인하고 최종 경계를 정하는 책임은 작성자에게 남는다.

혼자 소유한 토이 프로젝트라면 거친 기록을 받아들일 수 있다. 여러 사람이 운영하는 프로덕션 코드는 다른 사람이 이해하고 장애에 대응해야 하므로 더 신중해야 한다.

결제, 정산, 금융이나 높은 트래픽을 받치는 영역처럼 장애가 즉시 사업 손실로 이어지는 곳은 기준이 더 높다. 생성된 테스트가 있어도 장애를 완전히 막는다고 보장할 수는 없다. 리뷰 가능한 범위, 이해되는 커밋, 충분한 PR 설명이 계속 필요한 이유다.

중요한 것은 누가 각 줄을 타이핑했느냐가 아니다. 누가 변경을 설명할 수 있고, 동료가 어떻게 검토하며, 머지 뒤에 조직이 유지보수할 수 있는가다. AI가 코드 생성 비용을 낮춰도 이해할 수 없는 변경의 비용까지 없애 주지는 않는다.