# 스택형 풀 리퀘스트에 대하여 큰 코드 변경 내용을 독립적으로 검토하고 병합할 수 있는 더 작은 종속 끌어오기 요청 체인으로 분할합니다. > \[!NOTE] 이 기능은 공개 미리 보기로 제공되며 변경될 수 있습니다. ## 스택형 끌어오기 요청 정보 누적 끌어오기 요청은 동일한 리포지토리에 있는 두 개 이상의 끌어오기 요청입니다. 여기서는 다음과 같습니다. * 첫 번째 또는 아래쪽 끌어오기 요청은 스택의 트렁크(일반적으로 리포지토리의 기본 분기) `main`를 대상으로 하지만 릴리스 분기와 같은 모든 분기일 수 있습니다. * 각 후속 풀 리퀘스트는 바로 아래 풀 리퀘스트의 브랜치를 대상으로 합니다. ```text ┌── feat/frontend → PR #3 (base: feat/api-endpoints) ← top ┌── feat/api-endpoints → PR #2 (base: feat/auth-layer) ┌── feat/auth-layer → PR #1 (base: main) ← bottom main (default base branch) ``` 스택된 브랜치는 종속성 체인을 이루며, 각 브랜치는 바로 아래 브랜치를 기반으로 합니다. 공유 형식 및 데이터베이스 스키마와 같은 기본 변경 내용은 하위 분기로 이동하며, API 경로 및 UI 구성 요소와 같이 해당 요소에 의존하는 코드는 더 높은 분기로 이동합니다. 스택의 각 끌어오기 요청은 하나 이상의 커밋에 대한 개별적인 검토 가능한 변경을 나타냅니다. 각 끌어오기 요청을 독립적으로 검토하고 반복할 수 있으며, 각 요청은 해당 계층의 차이와 해당 분기와 그 아래 분기 간의 변경 내용만 표시합니다. **핵심 원칙:** 한 계층의 코드가 다른 계층의 코드에 종속된 경우 종속성은 동일한 분기 또는 하위 분기에 있어야 합니다. 지금까지 작업한 내용을 바탕으로 하는 별개의 작업을 시작할 때는 새 브랜치를 만드세요. 예를 들어, 백엔드 작업에서 프런트엔드 작업으로 전환할 때, 핵심 로직에서 테스트로 옮겨 갈 때, 또는 현재 브랜치가 이미 검토하기에 충분히 큰 경우입니다. ## 왜 GitHub 스택형 풀 리퀘스트를 사용할까요 ### 하나의 변경을 완료하고 다음으로 바로 이동 누적 끌어오기 요청을 사용하면 여전히 열려 있는 끌어오기 요청 위에 새 끌어오기 요청을 열 수 있습니다. 대규모 프로젝트 중에 다음 변경 내용은 아직 병합되지 않은 작업에 따라 달라질 수 있습니다. 스택을 사용하여 병합되기를 기다리는 대신 계속 빌드할 수 있습니다. 포커스가 있는 변경 내용이 포함된 스택의 각 끌어오기 요청에서 검토자는 큰 끌어오기 요청 대신 각 계층에 대해 작은 차이(diff)를 볼 수 있습니다. 더 작은 풀 리퀘스트는 검토가 더 빠르고, 대충 훑어보게 될 가능성이 더 낮으며, 오래 방치되어 병합 충돌이 생길 가능성도 더 낮습니다. ### 대용량 개발에 적합 AI 에이전트를 사용하여 많은 코드를 한 번에 생성하는 경우 스택은 각 변경 사항을 진행할 수 있는 위치를 제공합니다. 에이전트는 하나의 작업을 완료한 다음, 이를 기반으로 하는 다음 작업을 시작합니다. 해당 시퀀스는 스택에 직접 매핑됩니다. 각 요청은 아래와 같이 작업당 하나의 끌어오기 요청입니다. 스택을 사용하면 관련 없는 변경 내용을 단일 분기에 결합하는 대신 해당 종속성을 명시적으로 기록할 수 있습니다. ### GitHub에서 스택형 pull request를 사용할 때의 장점 누적 끌어오기 요청이 없으면 큰 변경 내용이 더 작고 종속적인 끌어오기 요청으로 나누면 추가 작업이 생성됩니다. * **분기 관리.** 서로 의존하는 pull request들 전반에서 브랜치를 리베이스하고 동기화된 상태로 유지하는 일은 번거롭고 오류가 발생하기 쉽습니다. * **규칙 및 CI.** 분기 보호 규칙 및 CI 검사는 종종 체인의 아래쪽 끌어오기 요청에 대해서만 트리거되므로 나머지의 실제 상태를 알기 어렵습니다. * **컨텍스트를 검토합니다.** 스택의 나머지 부분의 컨텍스트에서 단일 변경 내용을 검토하면 검토 품질이 저하됩니다. 누적 끌어오기 요청은 각 계층을 작게 유지하면서 끌어오기 요청 체인을 연결된 단위로 처리하여 이러한 문제를 해결합니다. #### 재배정 리베이스는 스택을 다룰 때 가장 까다로운 부분이며, GitHub가 이를 자동으로 처리해 줍니다. 풀 리퀘스트에서 서버 측 연쇄 리베이스를 실행할 수 있으며, 또는 GitHub CLI의 `gh stack` 확장 프로그램을 사용해 로컬 연쇄 리베이스를 실행할 수 있습니다. 스택 아래쪽에서 끌어오기 요청을 병합하면 나머지 분기가 자동으로 다시 기반이 되어 다음 끌어오기 요청이 기본 기본 분기를 대상으로 합니다. ## 스택형 pull request를 어디에서 사용할 수 있나요? 누적 끌어오기 요청은 다음에서 사용할 수 있습니다. * GitHub CLI * GitHub 웹사이트 * GitHub Mobile * 웹후크, REST API 및 GraphQL을 통한 프로그래밍 방식 지원 * 에이전트의 경우 `gh-stack` 스킬을 통해 > \[!NOTE] > > * 스택형 풀 리퀘스트를 사용하려면 모든 브랜치가 동일한 리포지토리에 있어야 합니다. 교차 포크 스택은 지원되지 않습니다. > * 누적 끌어오기 요청은 .에서 GitHub Desktop지원되지 않습니다. ### GitHub CLI에서 GitHub CLI의 `gh stack` 확장은 로컬 개발 워크플로를 담당합니다. 올바른 종속성 순서로 분기를 만들고 추적하고, 분기를 다시 기반으로 유지하고, 분기를 푸시하고, 끌어오기 요청을 만들고 연결하고, 레이어 간을 탐색할 수 있습니다. [누적 끌어오기 요청 CLI 명령](/ko/pull-requests/reference/stacked-prs-cli-commands)을(를) 참조하세요. ### GitHub 웹 사이트에서 끌어오기 요청이 스택의 일부인 경우 다음이 표시됩니다. * 끌어오기 요청의 맨 위에 있는 스택 아이콘 으로, 보고 있는 레이어를 나타내는 숫자가 있습니다. * 병합 상자에 스택 맵이 나타납니다. 스택의 모든 끌어오기 요청과 해당 상태를 표시하며 한 번의 클릭으로 모든 계층으로 이동할 수 있습니다. 트렁크(기본 기본 분기)는 아래쪽에 있으며 스택의 각 끌어오기 요청은 아래 끌어오기 요청의 분기를 대상으로 합니다. ### 웹후크, REST API 및 GraphQL을 통한 프로그래밍 방식 지원 누적 끌어오기 요청은 프로그래밍 방식으로 사용할 수 있으므로 사용자 고유의 도구, 자동화 및 대시보드에 통합할 수 있습니다. * **웹후크는** 이벤트 페이로드에 `stack` 개체를 포함 `pull_request` 하므로 끌어오기 요청이 연결되거나 스택 내에서 이동하거나 스택을 떠날 때 자동화가 응답할 수 있습니다. * **REST API는** 끌어오기 요청의 스택 멤버 자격을 읽고 스택을 나열, 만들기, 확장 및 디졸브할 엔드포인트를 제공합니다. * **GraphQL API는** 스택을 쿼리하기 위한 끌어오기 요청과 끌어오기 요청의 위치에 읽기 전용 `stack` 필드를 노출합니다. ## 규칙, CI 및 병합 ### 규칙 및 CI 적용 스택형 풀 리퀘스트는 GitHub Actions 워크플로를 지원합니다. 스택의 끌어오기 요청에 대한 병합 요구 사항은 일반적으로 아래쪽 끌어오기 요청의 기본 분기에 의해 결정됩니다 `main`. * CODEOWNER 승인과 같은 분기 보호 규칙은 기본 분기를 직접 대상으로 하지 않는 중간 스택 끌어오기 요청도 스택의 모든 끌어오기 요청에 적용됩니다. * 기본 분기 실행에서 끌어오기 요청에 의해 트리거되는 CI 검사는 맨 아래 요청뿐만 아니라 스택의 모든 끌어오기 요청에 대해 실행됩니다. 이렇게 하면 스택의 모든 레이어가 병합되기 전에 동일한 품질 표시줄을 충족합니다. ### 병합 전체 스택, 단일 끌어오기 요청 또는 여러 끌어오기 요청에 걸쳐 있는 스택의 일부를 병합할 수 있습니다. 전체 스택은 한 번에 병합할 필요가 없지만 끌어오기 요청은 아래쪽에서 위로 병합해야 합니다. * 맨 위 풀 리퀘스트를 병합하여 전체 스택을 한 번에 병합합니다. 그 아래의 모든 풀 리퀘스트에는 그것이 함께 포함됩니다. * 스택 중간의 풀 리퀘스트를 병합해 스택의 일부를 병합합니다. 아래의 끌어오기 요청도 병합되고 위의 끌어오기 요청은 열린 상태로 유지되며 스택의 기본 분기를 자동으로 다시 대상으로 지정합니다. 스택은 병합 커밋, 스쿼시 및 재베이스 병합 메서드를 지원하며 병합 큐를 인식합니다. 결과 커밋 기록은 아래에서 시작하여 각 끌어오기 요청을 개별적으로 병합하는 것과 같습니다. > \[!NOTE] > API를 통해 병합하고 스택형 풀 리퀘스트를 사용하려는 경우, 스택용 새 병합 API로 업데이트해야 합니다. > [끌어오기 요청에 대한 REST API 엔드포인트](/ko/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously)을(를) 참조하세요. ## 다음 단계 * [누적 끌어오기 요청에 대한 빠른 시작](/ko/pull-requests/get-started/stacked-prs-quickstart?utm_source=docs-pr-stacks-quickstart\&utm_medium=docs\&utm_campaign=stacked-prs-gtm-public-preview-2026) * [조직에 누적 끌어오기 요청 롤아웃](/ko/pull-requests/tutorials/roll-out-stacked-prs?utm_source=docs-roll-out-pr-stacks\&utm_medium=docs\&utm_campaign=stacked-prs-gtm-public-preview-2026)