거대한 AI 생성 PR을 리뷰 가능한 단위로 쪼개는 스택 PR 워크플로우

AI 에이전트에게 기능 하나를 통째로 맡기면 실제로 며칠 걸릴 작업이 순식간에 끝나지만, 그 결과물이 변경 줄 수 수천 줄짜리 풀 리퀘스트 하나로 올라오는 경우가 흔하다. 리뷰어 입장에서는 어디서부터 봐야 할지 감이 잡히지 않고, 코멘트는 여기저기 흩어지며, 결국 꼼꼼히 보지 못한 채 일단 승인하고 넘어가는 상황이 반복된다.

왜 대형 PR이 리뷰를 무너뜨리는가

한 사람이 감당할 수 있는 컨텍스트에는 한계가 있다

사람은 한 번에 파악할 수 있는 변경 범위에 한계가 있다. 데이터 모델, 서버 API, 프론트엔드 화면이 뒤섞인 대형 diff를 마주하면 리뷰어는 각 영역을 오가며 맥락을 다시 세워야 하고, 그 과정에서 놓치는 부분이 늘어난다. 결과적으로 리뷰 품질이 떨어지고, 문제가 있어도 병합 이후에야 발견되는 일이 잦아진다. 사람이 손으로 짜던 시절에는 자연스럽게 기능 단위로 커밋이 쪼개졌지만, 에이전트가 한 번에 전체 구현을 끝내버리면 이 자연스러운 분절이 사라진다는 점도 문제를 키운다.

계층별로 쪼개 순서대로 쌓는 접근

이런 문제를 다루는 방법으로 최근 주목받는 것이 "스택 PR"이다. 하나의 기능을 여러 계층으로 분해하고, 각 계층을 독립적인 작은 PR로 만들어 순서대로 쌓아 올리는 방식이다. 각 PR은 딱 하나의 관심사만 다뤄서 리뷰어가 머릿속에 통째로 담을 수 있는 크기로 유지된다.

예를 들어 쇼핑 어시스턴트에 상품 검색 기능을 추가한다고 하면, 계층을 이렇게 나눌 수 있다: 1계층은 카탈로그 타입과 시드 데이터, 검증 로직을 담당하는 데이터 모델 계층, 2계층은 검색 API 엔드포인트를 만드는 백엔드 계층, 3계층은 채팅 인터페이스와 API를 연결하는 프론트엔드 연동 계층, 4계층은 상품 카드 UI와 출처 표시 기능을 완성하는 프론트엔드 계층이다. 각 계층은 바로 아래 계층에 의존하며, 자동화된 검사도 계층마다 따로 돌아간다.

실제 적용 팁

에이전트에게 처음부터 분해를 요청하기

결과물이 나온 뒤에 큰 PR을 쪼개려고 하면 오히려 더 번거롭다. 애초에 에이전트에게 작업을 맡길 때 "이 기능을 데이터 모델, API, 프론트엔드 연동, UI 네 단계로 나눠서 각 단계를 별도 커밋으로 만들어 달라"는 식으로 분해 기준을 먼저 지시하는 편이 훨씬 수월하다.

리뷰 순서를 정해두기

스택 전체를 한 번에 훑기보다, 아래 계층(데이터 모델처럼 나머지 전부가 의존하는 부분)부터 먼저 리뷰하고 승인하는 순서를 정해두면 좋다. 기반 계층이 늦게 확정될수록 위 계층 전체를 다시 손봐야 할 위험이 커지기 때문에, 파급력이 큰 계층을 우선적으로 빠르게 리뷰받는 것이 전체 작업 속도를 좌우한다.

피드백 반영 후 스택 전체를 동기화하기

중간 계층에서 코드가 바뀌면 그 위 계층들도 함께 갱신돼야 한다. 스택을 관리하는 도구 대부분은 한 계층을 수정한 뒤 나머지 계층을 자동으로 재정렬·동기화하는 명령을 제공하므로, 이 과정을 수동으로 하나씩 맞추려 하지 말고 도구의 동기화 기능을 활용하는 편이 실수를 줄이고 반복 작업 시간도 아껴준다.

주의할 점

계층을 나누는 기준이 애매하면 오히려 역효과가 난다. "이 계층만 따로 봐도 무엇을 하는지 이해되는가"를 기준으로 나누지 않고 그냥 줄 수를 맞추기 위해 임의로 자르면, 계층 간 의존 관계가 꼬여 리뷰가 더 어려워질 수 있다. 또한 계층 수가 지나치게 많아지면 스택 자체를 관리하는 데 드는 비용이 커지므로, 보통 서너 개 계층 안에서 자연스럽게 나뉘는 경계를 찾는 것이 현실적이다. 팀 차원에서 "계층 하나는 몇 줄 이내로 유지한다"처럼 대략적인 가이드라인을 미리 정해두면, 매번 새로 기준을 고민하지 않아도 되어 도입 초기 혼란을 줄일 수 있다.

정리

AI 에이전트가 만든 대형 PR을 그대로 받아들이거나 억지로 빠르게 승인하는 대신, 계층별로 쪼개 순서대로 쌓아 올리는 스택 PR 방식을 쓰면 리뷰 부담을 실질적으로 줄일 수 있다. 핵심은 결과물이 나온 뒤 쪼개는 게 아니라, 에이전트에게 작업을 맡기는 시점부터 계층 분해를 요청하고 기반 계층을 우선 검토하는 순서를 지키는 것이다. 도구를 새로 배우는 비용보다, 이 관점 전환 자체가 팀의 리뷰 문화를 바꾸는 더 큰 변화라는 점을 기억해두면 도입이 한결 수월하다.