2026년 7월 30일, 공식 GitHub 블로그는 Copilot의 "스택 세션" 작업 방식을 소개했습니다: 개발자는 동일한 저장소에 여러 의존 세션을 생성하여 다음 작업이 이전 작업의 컨텍스트와 코드 출력을 상속받고, 풀 요청을 순서대로 병합할 수 있게 합니다. 문제는 모델이 코드를 작성할 수 있느냐가 아니라, AI가 한꺼번에 너무 많은 변경을 가한 후에도 팀이 여전히 철저히 검토할 수 있느냐입니다.
왜 오래된 프로젝트에 세션 스택이 필요한가요?
GitHub의 사례는 2014년부터 이어져 온 개인 애플리케이션으로, 여전히 React 15, Less, 그리고 구형 React-Bootstrap을 사용하고 있음을 보여줍니다. 개발자들은 먼저 Copilot에게 프론트엔드 현대화를 계획하게 하고, 그 후 점진적으로 구현합니다; React-Bootstrap을 제거하면서 현재 작업 범위를 넘어서기 시작했을 때, 그녀는 원래 세션을 계속 확장하지 않았습니다. 대신 기존 작업에 대한 풀 요청을 먼저 만들고, 이전 맥락을 이어갈 새 세션을 만들었습니다.
Copilot은 세 가지 일을 수행했습니다: 현재 수정 파일을 풀 요청으로 저장하는 것; 구성 요소 교체를 위한 새로운 스택 세션을 생성하고 대기 중인 확인 일정을 생성하세요; 이전 분기를 기반으로 다음 풀 리퀘스트를 생성하세요. 이렇게 각 수정은 고유한 검토 경계를 가지면서도 명확한 의존성 순서를 유지합니다.
이 프로그램은 AI 프로그래밍에서 새로운 유형의 범위 폭주를 목표로 합니다
AI 프로그래밍은 코드 생성 비용을 줄여주지만, '대대적인 개편'을 너무 쉽게 만들어줍니다. 하나의 프롬프트가 빠르게 수만 줄의 수정, 기능 혼합, 리팩토링, 의존성 업그레이드, 스타일 조정으로 확대될 수 있습니다. 코드가 작동하더라도, 리뷰어들은 어떤 변경이 회귀를 유발하는지 판단하기 어렵습니다.
스태킹 세션은 긴 작업을 독립적으로 테스트하고 검토할 수 있는 점진적인 부분으로 나눕니다: 먼저 기본 준비 과정을 병합하고, 그에 의존하는 기능들을 병합하고; 특정 층에서 문제가 발생하면 위치를 파악하고 철수하기도 더 쉽습니다. AI 에이전트의 작업 단위를 단일 긴 대화에서 전달 관계가 있는 작은 작업 집합으로 전환시킵니다.
사용할 때 이 네 가지 체크포인트를 잊지 마세요
- 각 세션은 명확한 목표만 유지하며, 단순한 무작위 리팩토링을 피합니다.
- 하위 단계 풀 요청이 변경된 후에는 상위 계층 분기를 다시 동기화하고 충돌 문제를 처리해야 합니다.
- 테스트는 전체 스택이 끝난 후에도 일관되게 실행되기보다는 각 수정 단계에 따라 진행되어야 합니다.
- 합병의 순서는 명확해야 합니다; 상위 계층 코드 의존성이 아직 메인 브랜치에 들어가지 않은 경우, 독립적으로 재배포 가능한 코드로 혼동해서는 안 됩니다.
스태킹 세션은 개발자가 어떤 경계를 나눌지 결정하는 데 도움을 주지 않으며, 코드가 옳다는 것을 자동으로 증명하지도 않습니다. 진정한 가치는 장기 실행 코딩 에이전트가 전통적인 소프트웨어 공학의 제약을 유지한다는 점입니다: 소규모 수정, 독립적 검증, 명확한 의존성, 롤백 리뷰 등이 포함됩니다. 레거시 시스템 업그레이드와 다단계 마이그레이션의 경우, 한 번만 생성하고 완전히 완료하는 것보다 이 방법이 더 신뢰할 수 있습니다.
