Locale ko · en

에이전트 시대의 작은 PR — GitHub Stacked PRs와 Copilot 스택 세션

By PapaCoder · Published 4 Aug 2026

Summary

2026-07-30 퍼블릭 프리뷰. 에이전트 산출물을 메가 PR이 아니라 의존 레이어 스택으로 나누고, gh-stack·Copilot stacked sessions로 리뷰 가능하게 만드는 방법.

코딩 에이전트가 하루에도 몇 개씩 PR을 열어 주는 팀은 이미 많습니다. 문제는 “속도”가 아니라 한 장의 거대한 diff입니다. 리뷰어는 스키마 마이그레이션과 UI 폴리시를 같은 화면에서 보게 되고, CI는 한 번에 다 깨지거나 다 통과하고, “어디부터 머지하지?”가 팀 합의가 됩니다.

핵심 한 줄: 2026-07-30 GitHub가 Stacked pull requests를 퍼블릭 프리뷰로 내놓으면서, 에이전트 산출물의 기본 단위를 “한 방 PR”이 아니라 의존 관계가 있는 작은 PR 스택으로 바꿀 수 있는 네이티브 길이 생겼습니다. Copilot 앱의 stacked sessions는 그 스택을 세션 단위로 이어 붙입니다.

왜 중요한가

에이전트 워크플로의 병목은 생성보다 검수입니다. 한 PR에 인증 골격 + API + UI + 테스트가 섞이면:

  • 리뷰어는 “레이어별로” 승인할 방법이 없고, LGTM이 곧 전체 승인입니다.
  • 중간에 하나만 고치고 싶어도 리베이스 지옥이거나 “그냥 새로 열어”가 됩니다.
  • 보안/데이터 마이그레이션처럼 먼저 내려야 하는 레이어가 UI 잡음에 묻힙니다.

스택은 각 PR이 아래 레이어 브랜치를 base로 잡습니다. 리뷰어는 해당 레이어 diff만 보고, 스택 맵으로 전체 위치를 확인합니다. 병렬로 다른 레이어를 리뷰할 수 있고, 준비된 레이어부터 묶어 머지할 수 있습니다. 브랜치 보호·필수 체크는 그대로 적용됩니다 (Changelog).

에이전트 관점에서는 “한 프롬프트 = 한 메가 커밋” 유혹을 제품이 구조적으로 꺾어 줍니다. gh-stack skill을 쓰면 Copilot 같은 코딩 에이전트가 스택을 직접 열고 관리할 수 있다고 문서·변경 로그가 명시합니다.

기존 방식과 비교하면

접근장점비용
단일 거대 PR단순리뷰·롤백·부분 머지 불가능에 가깝다
수동 멀티 PR + 리베이스레이어 분리 가능브랜치 base 관리가 사람이 하는 일
Graphite 등 외부 스택 도구성숙한 스택 UX별도 제품·권한·학습 비용
GitHub 네이티브 스택github.com / CLI / 모바일 / 에이전트 스킬퍼블릭 프리뷰(변경 가능), merge queue 연동은 점진 롤아웃

과거에는 “스택 쓰려면 Graphite 쓰자”가 흔한 답이었습니다. 이번 프리뷰의 의미는 GitHub 자체가 에이전트 시대의 PR 단위를 스택으로 인정했다는 쪽에 가깝습니다. 이미 Graphite에 만족하는 팀은 당장 옮길 필요는 없고, “에이전트 PR이 너무 커서 리뷰가 붕괴한다”는 팀에게는 네이티브 옵션이 생겼다는 정도로 보는 게 정직합니다.

PapaCoder에서 이전에 다룬 Copilot Code Review Skills + MCP가 리뷰 쪽 에이전트라면, 이번 주제는 생성 쪽 산출물을 어떻게 자르느냐입니다. 둘은 보완 관계입니다.

코드 / 설정 예시

공식 퀵스타트 기준 CLI 흐름은 대략 다음과 같습니다 (퍼블릭 프리뷰·명령은 바뀔 수 있음).

# CLI extension
gh extension install github/gh-stack

# 에이전트가 쓸 skill (Copilot 등)
gh skill install github/gh-stack

# 첫 레이어
gh stack init feature/auth-schema

# 작업 후 다음 레이어 추가
gh stack add feature/auth-api

# PR 생성·스택 링크
gh stack submit

# 상태 확인
gh stack view

개념적으로 스택은 이렇게 생깁니다.

main
  └─ PR#1  feature/auth-schema     (schema only)
       └─ PR#2  feature/auth-api   (API against #1)
            └─ PR#3  feature/auth-ui (UI against #2)

리뷰어가 PR#2를 열면 #2의 레이어 diff만 보입니다. 머지 시에는 아래부터 연속된 구간을 한 번에 내릴 수 있고, 위쪽만 남기면 자동으로 rebase/retarget됩니다. merge queue를 쓰는 저장소에서는 스택이 순서대로 큐에 들어가며, 큐 한도에 걸리면 연속 merge group으로 쪼개질 수 있습니다 (Merging stacked PRs).

Copilot 앱 쪽 stacked session은 “기존 세션 작업 위에 새 세션을 올리고, 그 세션이 별도 PR을 아래 PR을 향해 연다”는 UX입니다. GitHub 엔지니어 워크스루에서는 레거시 React 현대화 PR 위에 react-bootstrap 제거 PR을 스택으로 올린 사례가 나옵니다 (Stacked sessions blog).

실무에서 쓰는 법

  1. 레이어 경계를 먼저 적는다. 예: (1) 스키마/계약 (2) 서버 (3) 클라이언트 (4) 관측/문서. 에이전트에게 “한 번에 다 해”보다 “스택 레이어 1만”이 리뷰 가능합니다.
  2. 에이전트에게 gh-stack skill을 깐다. 문서 튜토리얼도 Copilot CLI + skill 조합을 전제로 합니다 (Stack AI-generated code).
  3. 아래 레이어 CI가 빨개지면 위를 키우지 않는다. 스택은 의존 사슬입니다. 위만 고치다 보면 결국 메가 PR과 같은 고통이 돌아옵니다.
  4. 부분 머지를 팀 규칙으로 합의한다. “스키마+API까지는 오늘, UI는 내일”이 제품 기능으로 가능해졌습니다.
  5. 프리뷰·롤아웃을 가정한다. 변경 로그 기준 전 저장소 롤아웃은 “앞으로 며칠”, merge queue 지원은 “앞으로 몇 주”에 걸친 점진 배포입니다. 오늘 안 보이면 조직/저장소 타이밍일 수 있습니다.

처음 gh stack submit을 돌렸을 때, 예전에 손으로 base branch만 꼬아 두던 멀티 PR보다 “스택 맵이 한눈에 보이는” 쪽이 리뷰 대화 시작점을 바꿔 줬습니다. 반대로 skill 없이 에이전트에게만 “스택으로 열어”라고 하니 일반 PR 두 개만 덩그러니 열린 적도 있어, 도구 설치가 프롬프트보다 먼저라는 교훈이 남았습니다.

시니어 엔지니어 시선

스택은 은탄환이 아닙니다.

  • 잘못된 레이어 경계면 리뷰는 작아 보여도 의미 없는 쪼개기입니다. “파일 수”가 아니라 “롤백·승인 단위”로 자르세요.
  • 올거나 전무 머지(gh stack merge의 선택 구간) 는 보호 규칙과 맞물립니다. 큐/필수 리뷰어가 빡센 팀은 하위 레이어부터 초록을 만드는 습관이 필요합니다.
  • 에이전트 스택 ≠ 사람 리뷰 면제. 레이어가 작아질수록 “각 레이어의 의도”를 PR 본문에 적는 규율이 더 중요해집니다.
  • Graphite 등 기존 스택 문화가 있는 조직은 마이그레이션 ROI를 따지세요. 네이티브의 가치는 도구 통일·에이전트 skill·모바일까지 같은 모델에 있다는 점입니다.

Cursor에서 쓰는 법

Cursor 사용자는 Copilot 앱 stacked session UI를 그대로 쓰진 않더라도, 같은 규율을 GitHub 쪽에 적용할 수 있습니다.

  • Cursor Agent / Cloud Agent가 연 PR이 커지기 시작하면, 후속 프롬프트를 “이 브랜치 위에 스택 레이어로 …”로 바꾸고 gh stack CLI를 에이전트 도구/훅에 노출하세요.
  • 규칙 파일(AGENTS.md / 프로젝트 룰)에 예를 넣습니다: “스키마·공개 API·UI를 한 PR에 섞지 말 것. 가능하면 gh stack.”
  • Cursor에서 플랜을 먼저 쓰고(Plan), 레이어마다 세션을 나누는 패턴은 Copilot stacked sessions와 정신적으로 같습니다. 차이는 GitHub가 그 결과를 네이티브 스택으로 받아 준다는 점입니다.
  • 이미 PapaCoder처럼 draft/human publish 두 문을 쓰는 팀은, “에이전트는 초안·스택까지, 사람은 레이어 승인·머지”로 권한을 나누면 사고 반경이 줄어듭니다.

FAQ

Q. 퍼블릭 프리뷰인데 프로덕션에 써도 되나요?
A. 공식 문서가 subject to change를 명시합니다. 실험 레포·내부 도구부터 파일럿하고, 필수 경로에는 롤백 플랜을 두세요.

Q. merge queue와 같이 쓰이나요?
A. 지원이 점진 롤아웃 중입니다. 큐에 들어가면 순서 유지·상단 레이어 eject 연동 등 큐 규칙이 적용됩니다. 아직 안 보이면 롤아웃 타이밍을 확인하세요.

Q. Graphite를 버리고 가야 하나요?
A. 필수는 아닙니다. 에이전트 skill·GitHub 네이티브 UX가 필요한지, 기존 스택 도구 투자이 큰지로 ROI를 보시면 됩니다.

Q. 에이전트가 자동으로 좋은 레이어를 자를까요?
A. 아니요. 레이어 설계는 여전히 사람(또는 사람이 적은 템플릿)의 몫입니다. 스택은 실행 장치입니다.

Q. 이전 Copilot 코드 리뷰 글과 뭐가 다른가요?
A. 그 글은 리뷰 에이전트(Skills/MCP) 쪽이고, 이 글은 생성 산출물의 PR 구조입니다.

소스

마치며

앞으로 팀의 기본 단위는 “에이전트 한 번의 산출물”이 아니라 리뷰 가능한 레이어가 될 가능성이 큽니다. 스택이 그 문법을 GitHub 안으로 끌어온 셈입니다. 다음 실험은 단순합니다. 이번 주 가장 큰 에이전트 PR 하나를 골라, 스키마·서버·UI 세 장으로 다시 열어 보세요 — 리뷰 대화가 어떻게 바뀌는지가 곧 답입니다.

Related posts

More in Ai Agents →

Comments

Checking sign-in…

No comments yet.