AI가 생성한 거대한 pull request 하나를 검토 가능한 스택으로 전환하기

코딩 에이전트는 기능 전체를 한 번에 구현해 1,000줄이 넘는 거대한 pull request로 제출하는 경향이 있다. 이 방식은 리뷰어가 변경 사항을 파악하기 어렵게 만들고, 피드백 품질과 병합 속도를 떨어뜨리며, 결과적으로 충분히 검토되지 않은 코드가 반영될 위험을 키운다.

GitHub는 이를 해결하기 위해 stacked pull requests를 제안한다. 하나의 대형 PR을 단일 관심사에 집중한 여러 계층으로 분해하고, 각 PR이 이전 계층에 의존하도록 구성해 작고 독립적으로 검토할 수 있게 만드는 방식이다.

쇼핑 도우미에 상품 검색을 추가하는 예시는 다음과 같은 4개 계층으로 나뉜다.

• L1 feat/catalog-data: 타입이 지정된 카탈로그, 시드 데이터, 검증 및 데이터 접근 모듈을 추가하며 main을 기반으로 한다.
• L2 feat/search-api: 검증 기능을 갖춘 /api/products/search API 엔드포인트를 추가하고 L1에 의존한다.
• L3 feat/chat-grounding: 채팅 기능이 API를 호출해 실제 상품 데이터로 답변하도록 연결하며 L2에 의존한다.
• L4 feat/grounded-ui: 상품 인용 카드와 각종 UI 상태를 추가하며 L3에 의존한다.

스택을 구성할 때는 먼저 stack base를 지정해야 한다. 이후 가장 기반이 되는 작업을 스택 하단에 배치하고, 그 위에 API·기능 연결·UX처럼 의존성이 있는 작업을 순서대로 쌓는다. 이에 따라 데이터 담당자는 데이터 계층을, UI 담당자는 화면 계층을 검토하는 등 변경 영역별로 적절한 리뷰어를 지정할 수 있다.

이 구조는 에이전트가 만든 전체 구현을 수동으로 정리하고 충돌을 관리해야 했던 기존 방식보다 리뷰 범위를 명확하게 만든다. Gartner는 코딩 에이전트가 2028년까지 소프트웨어 개발 생명주기 전반에서 생산성을 50% 높일 것으로 전망한 만큼, 에이전트 활용이 늘어날수록 PR 구조를 설계하는 방식도 중요해진다.