Transcript
00:00:00GitHub에서 수년 만에 가장 큰 업데이트를 발표했습니다. 대규모 PR을 더 관리하기 쉬운
00:00:05조각으로 나누는 완전히 새로운 방식인 스택 PR(Stacked PR)인데요. 이번 영상에서는 이것이 정확히 무엇이고
00:00:10왜 사용해야 하는지 다뤄보겠습니다. 스택 PR은 강력하면서도 꽤 단순한 개념입니다. 큰 코드 변경 사항을
00:00:21서로 의존하는 더 작은 풀 리퀘스트 체인으로 나누는 것이죠. 각각 독립적으로 리뷰하고 병합할 수 있습니다.
00:00:26스택을 구성하려면 동일한 저장소에 2개 이상의 풀 리퀘스트가 있어야 하며, 가장 처음 또는
00:00:31가장 아래에 있는 풀 리퀘스트는 트렁크, 즉 일반적으로 main과 같은 저장소의 기본 브랜치를 타겟으로 삼고
00:00:37그 이후의 각 풀 리퀘스트는 이전 PR을 타겟으로 삼습니다. 이렇게 하면 각 브랜치가 아래쪽 브랜치를
00:00:42기반으로 빌드되는 의존성 체인이 형성됩니다. 공유 타입이나 데이터베이스 스키마 같은 기초적인 변경 사항은
00:00:48하위 브랜치에 들어가고, API 라우트나 UI 컴포넌트처럼 거기에 의존하는 코드는
00:00:53상위 브랜치에 들어갑니다. 이렇게 생각하실지도 모릅니다. '원래도 이렇게 할 수 있었잖아?'라고요.
00:00:58main에 PR을 올린 다음, 그 PR에 다시 두 번째 PR을 올리는 식으로 원하는 만큼 PR을 체인으로 엮을 수 있었죠.
00:01:04그것은 완전히 사실입니다. Git 자체의 관점에서는 스택 PR이라는 개념이 따로 존재하지 않으며
00:01:09여전히 PR을 데이지 체인 방식으로 엮는 것에 불과하니까요. GitHub 내부에서만 스택 PR이 실제로
00:01:16의미를 갖습니다. 하지만 엄청난 장점들을 가져다주죠. 기술과 AI 트렌드를 빠르게 파악하고 싶으시다면
00:01:22Better Stack을 구독해 주세요. 스택 PR을 사용하려면 GitHub CLI를 설치하는 것이 가장 좋습니다.
00:01:27이를 통해 `gh stack init`을 실행한 다음 새 스택을 선언할 수 있습니다.
00:01:33이제 텍스트 편집기로 이동하여 여러 PR을 스택으로 쌓는 예제를 살펴보겠습니다.
00:01:38가장 먼저 할 일은 `gh stack init setup-database`를 실행하는 것입니다. 이 경우
00:01:44PR 또는 브랜치의 이름은 `setup-database`가 됩니다. 이것이 이제 main을 가리키게 될
00:01:50기본 PR이 됩니다. 그런 다음 변경 작업을 수행할 수 있습니다. 데모를 위해 리드미 파일에만
00:01:54변경 사항을 넣어보겠습니다. 데이터베이스를 구현했다고 적고, `git add`와
00:01:59`git commit`을 수행하면 됩니다. 여기의 모든 과정은 표준 git과 같습니다. 다음 변경 작업 세트로
00:02:04전환할 준비가 되면 `gh stack add`를 실행하고 다음 브랜치를 지정하면 됩니다. 그런 다음 더 많은 변경 작업을 수행하여
00:02:10API 엔드포인트를 만듭니다. 여기에 추가적인 포인트를 좀 더 넣고 싶을 수 있겠죠. 이 변경 사항도 커밋합니다.
00:02:16그런 다음 두 번째 변경 사항도 추가합니다. 그리고 나서 다시 커밋합니다. 예상하셨듯이
00:02:20브랜치당 여러 개의 커밋을 만들 수 있습니다. 마지막으로 `gh stack add setup-frontend`를 실행하고
00:02:25여기서 변경 작업을 한 번 더 수행합니다. 그리고 다시 `git add`와 `git commit`을 합니다. 이제 모든 변경 사항이 마음에 들고
00:02:31해당 브랜치들을 한 번에 GitHub에 푸시하고 싶다면
00:02:36명령어 하나만 실행하면 됩니다. 바로 `gh stack submit`입니다. 그러면 미니 CLI UI가 나타나서 스택 내의
00:02:42각 PR을 확인하며 필요에 따라 제목과 설명을 추가할 수 있습니다. 혹은 각 항목에서
00:02:48다음 버튼을 누르기만 하여 세 개의 PR을 한 번에 제출할 수도 있습니다. 보시다시피 세 개의 PR 모두,
00:02:55즉 setup database, API, frontend가 단일 명령어로 스택 형태로 GitHub에 푸시되었습니다.
00:03:02사실 GitHub CLI 없이도 이 모든 작업을 수행할 수 있습니다. 구식 방식으로
00:03:07main에서 PR1로, 다시 PR1에서 PR2로 PR들을 수동으로 연결하면 됩니다. 그러면 전부 푸시했을 때
00:03:14GitHub가 이를 스택으로 인식합니다. CLI를 사용하면 이 과정을 훨씬 쉽게 관리할 수 있을 뿐입니다. 자, Git 자체에서는
00:03:20아무것도 바뀌지 않았음을 기억하세요. 작업 중인 스택에 포함되지 않은 완전히 다른 브랜치를 체크아웃하고 싶다면
00:03:24그렇게 했다가 나중에 스택 내의 브랜치로 다시 돌아오면 됩니다.
00:03:29이제 GitHub로 직접 이동해 보면, 3개의 PR이 각각 풀 리퀘스트로
00:03:34생성된 것을 확인할 수 있습니다. 그리고 이 PR들이 스택에 연관되어 있음을 알려주는 작은 스택 아이콘도
00:03:39표시되는 것을 볼 수 있습니다. 가장 상단에 있는 테일(tail) PR을 열어보면,
00:03:45아래쪽에 '스택 병합(merge stack)' 버튼이 있고 관련 UI가 표시되는 것을 볼 수 있습니다. 스택의 일부인
00:03:49모든 개별 PR을 확인할 수 있죠. 이를 하나씩 확인하며 승인할 수도 있습니다. 하지만 이 모든 내용이 만족스럽다면
00:03:54'스택 병합'을 클릭하기만 하면 해당 PR들이 전부 동시에 main으로 병합됩니다.
00:03:59또한 스택에 대한 참조가 이제 GitHub 전체에 통합되어 있는 것을 눈치채실 수 있습니다.
00:04:03풀 리퀘스트 페이지나 풀 리퀘스트 목록 페이지에서 이를 확인할 수 있죠.
00:04:09GitHub 워크플로우 같은 곳에서도 볼 수 있으며, 사실상 애플리케이션 전체에서 확인할 수 있습니다.
00:04:14따라서 대규모 PR을 다루고 있고 이를 별도의 세그먼트로 쉽게 분할해야 할 때,
00:04:18개별 PR이 main에 병합되기를 기다렸다가 직접 리베이스와 병합 작업을 수행할 필요가 없습니다.
00:04:23그냥 긴 스택 하나를 생성하면 GitHub가 UI 내에서 이 모든 것을 완벽하게 관리할 수 있도록 준비되어 있습니다.
00:04:28그리고 CLI는 이 모든 것을 자동으로 관리할 수 있는 아주 멋진 방법입니다. 이에 대해
00:04:33온라인에서 압도적으로 긍정적인 반응이 이어지고 있습니다. 특히 AI와 함께 사용할 때
00:04:38이 기능이 정말 강력한 무기가 될 수 있다고 생각합니다. 에이전틱 루프를 설계하고
00:04:43에이전트가 몇 시간 동안 실행되도록 둘 때 말이죠. 거대한 PR을 하나만 만들거나 완전히 분리된
00:04:48수많은 PR을 만드는 대신, 이제 에이전트가 스택 PR을 생성하고 모든 작업을 서로 연결할 수 있습니다.
00:04:54이번 영상이 유익하셨기를 바랍니다. 스택 PR에 대해 어떻게 생각하시는지 댓글로 남겨주시고,
00:04:58Better Stack을 구독하여 최신 기술 및 AI 소식을 놓치지 마세요.
00:05:02시청해주셔서 감사합니다. 그럼 다음 영상에서 뵙겠습니다.