GitHub Copilot app에서 에이전트가 만든 코드를 검토하려고 VS Code를 열 때, 작업 배경까지 다시 설명해야 한다면 도구를 옮기는 데 드는 수고가 커집니다. GitHub Blog가 소개한 세션 이어가기 기능은 이 연결을 유지하는 데 초점을 맞춥니다. 앱에서 진행하던 세션을 VS Code로 열면 대화와 코드 변경 사항, 작업 맥락을 이어서 확인하고 직접 수정하거나 로컬에서 실행할 수 있습니다.
핵심은 파일을 가져오는 것에 그치지 않는다는 점입니다. 에이전트가 어떤 요청을 받았고 어떤 계획과 대화를 거쳐 코드를 바꿨는지 확인하면서, 개발자가 평소 사용하는 편집기에서 검토를 계속할 수 있습니다. 반복적인 구현은 Copilot에 맡기고 세부 조정과 실행 결과 확인은 직접 하는 작업에 특히 연결하기 좋은 흐름입니다.
세션과 함께 넘어오는 대화, 변경 사항, 작업 디렉터리
원문에 따르면 Copilot app의 세션에서 Open in VS Code를 선택하면 해당 세션에 연결된 worktree를 사용해 프로젝트가 열립니다. VS Code의 Copilot 사이드바에는 기존 세션이 표시됩니다. 지원하는 편집기나 VS Code 설치본이 여러 개 제시된다면 사용할 환경을 선택합니다.
이때 이어지는 요소는 세 가지입니다. 첫째는 작업 요청과 계획, 대화를 포함한 세션 맥락입니다. 둘째는 에이전트가 바꾼 파일과 줄을 확인할 수 있는 변경 내역입니다. 셋째는 세션이 사용하던 분리된 작업 디렉터리인 worktree입니다. 새 대화에 이전 내용을 붙여 넣거나 다른 폴더로 파일을 복사하는 절차 없이 기존 작업을 이어가는 구조입니다.
worktree를 이해할 때는 같은 저장소의 작업을 별도 디렉터리에서 다룬다고 생각하면 도움이 됩니다. 다만 작업 디렉터리가 분리되어 있다는 사실이 코드 실행의 안전성까지 보장하지는 않습니다. 의존성 설치나 개발 서버 실행에 앞서 저장소의 실행 지침과 필요한 환경 설정을 확인하는 일은 여전히 필요합니다.
같은 GitHub 계정과 저장소 권한부터 확인하기
원문이 제시하는 준비 조건은 Copilot app 설치와 로그인, VS Code 설치, 두 도구에서의 동일한 GitHub 계정 사용입니다. 이어서 검토할 코드 변경 사항이 있는 Copilot app 세션도 필요합니다. 저장소에서 작업하고 변경 사항을 push할 권한이 있는지도 확인해야 합니다.
- 계정: 개인 계정과 학교·회사 계정을 함께 사용한다면 두 도구가 같은 계정에 연결되어 있는지 확인합니다.
- 작업 대상: 이어가려는 세션의 저장소와 요청 내용을 먼저 읽고, 다른 프로젝트의 작업을 열지 않았는지 확인합니다.
- 편집기: 여러 VS Code 설치본을 사용한다면 프로젝트에 필요한 확장과 실행 환경을 갖춘 쪽을 선택합니다.
- 권한: 저장소 접근 권한과 push 권한을 구분하고, 실제 변경을 올릴 수 있는 범위를 확인합니다.
이 안내는 VS Code 탐색, 통합 터미널 사용, Git 브랜치와 pull request 작업에 익숙한 사용자를 전제로 합니다. 학생이나 Git 입문자라면 변경 파일 확인, 커밋, push가 각각 어떤 상태를 만드는지 먼저 구분하는 편이 좋습니다. 편집기에서 파일을 저장한 것과 원격 저장소의 pull request에 변경 사항을 올린 것은 서로 다른 단계입니다.
제공된 원문에는 요금제별 제공 범위, 사용량 한도, 최소 지원 버전이나 지역별 조건이 구체적으로 나와 있지 않습니다. 따라서 모든 계정에서 같은 방식으로 사용할 수 있다고 단정하기보다, 자신의 앱에서 해당 메뉴가 제공되는지와 현재 계정의 이용 조건을 확인해야 합니다. 기능 설명만으로 추가 비용의 유무를 판단해서도 안 됩니다.
VS Code를 열면 먼저 변경 내역을 읽는다
세션을 열었다면 바로 추가 작업을 요청하기보다 Source Control에서 변경된 파일을 확인합니다. 파일별로 어떤 줄이 추가되거나 삭제됐는지 읽고, 처음 맡긴 문제와 실제 구현이 일치하는지 살펴봅니다. 대화가 보존되어 있어도 구현이 정확하다는 보장은 없으므로 일반적인 코드 리뷰와 같은 기준을 적용해야 합니다.
- 요청한 문제가 실제로 해결되는가?
- 이름 짓기, 파일 배치, 오류 처리 방식이 저장소의 관례와 맞는가?
- 빈 입력, 실패 응답, 경계값처럼 놓치기 쉬운 상황을 처리하는가?
- 바뀐 동작을 확인할 테스트가 있으며, 기대하는 결과를 제대로 검사하는가?
- 요청과 관계없는 파일이나 동작까지 수정하지 않았는가?
기존 대화는 구현 의도를 파악하는 데 도움이 됩니다. 예를 들어 새 보조 함수를 추가하지 않고 기존 함수를 바꾼 이유가 불분명하다면, 같은 사이드바에서 그 선택과 영향을 받는 동작을 설명해 달라고 요청할 수 있습니다. 설명을 읽은 뒤에는 실제 호출 위치와 변경 내역을 대조해야 합니다. 에이전트의 설명은 검토를 돕는 자료이며, 코드와 테스트를 대신하는 증거는 아닙니다.
특히 연구용 코드라면 결과를 계산하는 경로가 바뀌었는지, 개발 도구라면 기존 명령의 입력과 출력이 유지되는지처럼 프로젝트 목적에 맞는 질문을 추가하는 것이 좋습니다. 화면이 정상적으로 보이는지만 확인해서는 계산 결과나 API 동작의 변화를 놓칠 수 있습니다.
직접 고칠 부분과 Copilot에 다시 맡길 부분을 나누기
구현을 이해했다면 VS Code에서 파일을 직접 수정할 수 있습니다. 오류 메시지 한 줄을 다듬거나 변수 이름을 명확하게 바꾸고, 빠진 테스트 사례를 추가하는 일처럼 원하는 결과가 분명한 작업에 적합합니다. 원문에 따르면 이러한 수동 수정은 세션의 기존 worktree에 쌓이므로 파일을 다른 디렉터리로 옮기거나 브랜치를 다시 만들 필요가 없습니다.
여러 파일을 확인해야 하는 변경이나 반복적인 수정은 Copilot에 이어서 요청할 수 있습니다. 예를 들어 직접 바꾼 화면 문구에 대한 테스트를 추가하도록 요청하면서, 관련 없는 컴포넌트는 수정하지 말라는 범위를 함께 지정할 수 있습니다. 같은 세션을 이어가므로 앞선 대화를 다시 구성하는 부담을 줄일 수 있지만, 후속 작업의 대상과 기대 결과는 구체적으로 적는 편이 검토하기 쉽습니다.
수동 편집과 에이전트 요청을 번갈아 사용할 때는 요청 전후의 변경 내역을 비교하는 습관이 유용합니다. 방금 직접 고친 부분이 유지되는지, 테스트를 추가하는 과정에서 구현까지 불필요하게 바뀌지 않았는지 확인합니다. 세션이 연결되어 있다는 편의와 별개로 최종 변경 범위를 판단하는 책임은 검토하는 사람에게 남습니다.
로컬 실행은 저장소가 정한 검증 절차로 진행한다
원문은 VS Code 통합 터미널에서 의존성 설치, 테스트, lint, 개발 서버 실행을 진행하는 흐름을 제시합니다. 웹 앱 예시에는 npm install, npm test, npm run lint, npm run dev가 등장하지만, 이는 모든 저장소에 그대로 적용할 명령 목록은 아닙니다. 실제 프로젝트의 README와 설정을 읽고 사용하는 패키지 관리자와 검증 명령을 선택해야 합니다.
연구자는 실행 환경과 입력 데이터가 기존 실험 조건에 맞는지, 학생은 과제에서 요구하는 실행 방식과 제출 조건에 맞는지 함께 확인할 수 있습니다. 개인 프로젝트에서도 필요한 환경 변수와 외부 서비스 연결을 파악한 뒤 실행하는 편이 실패 원인을 구분하기 쉽습니다. 설치 성공, 테스트 통과, 실제 기능 확인은 각각 따로 확인할 결과입니다.
화면을 바꾸는 작업이라면 개발 서버가 안내하는 로컬 주소를 열어 직접 사용해 봅니다. VS Code 환경이 지원한다면 통합 브라우저에서 확인할 수도 있습니다. 요청한 화면만 보는 데 그치지 말고 화면 크기를 바꿔 보거나 로딩 중, 데이터 없음, 오류 발생 상태를 확인하면 주변 동작의 문제를 찾는 데 도움이 됩니다.
테스트가 실패했을 때는 실패 메시지와 관련 변경 파일을 함께 검토합니다. Copilot에 수정을 요청하더라도 어떤 명령에서 어떤 결과가 나왔는지 전달하고, 수정 후에는 해당 검증을 다시 수행해야 합니다. 테스트를 실행해 달라는 요청을 보낸 것과 테스트가 실제로 통과한 것은 구분해야 합니다.
기존 pull request로 이어지는지 확인하며 push하기
원문은 VS Code가 세션에 연결된 worktree와 브랜치를 열기 때문에, 해당 브랜치를 push하면 그 작업을 추적하던 pull request가 갱신된다고 설명합니다. 완성한 파일을 별도 checkout으로 복사하거나 pull request와 수동으로 다시 연결하는 절차를 줄일 수 있다는 뜻입니다.
커밋하기 전에는 최종 변경 내역을 다시 확인합니다. 현재 브랜치와 원격 저장소가 의도한 대상인지 살피고, 작업과 무관한 파일이나 로컬 설정이 포함되지 않았는지 검토합니다. 커밋과 push는 VS Code의 Source Control 또는 통합 터미널에서 진행할 수 있으며, 저장소가 정한 브랜치 사용 방식과 커밋·리뷰·승인 절차를 따라야 합니다.
push 완료는 리뷰나 병합 완료를 뜻하지 않습니다. 원격 pull request에 예상한 커밋과 변경 사항이 반영됐는지 확인하고, 필요한 검사 결과와 리뷰를 별도로 살펴야 합니다. 세션 이어가기는 개발 작업의 연결을 돕는 기능이며, 저장소의 승인 절차를 대신하는 기능으로 해석해서는 안 됩니다.
어떤 개발 작업에서 전환 수고를 줄일 수 있나
이 흐름의 가치는 앱에서 시작한 일을 편집기에서 마무리하는 빈도에 달려 있습니다. 개인 개발자가 에이전트에 반복적인 구현을 맡긴 뒤 로컬 디버깅과 세부 수정을 자주 한다면, 대화를 다시 설명하고 작업 위치를 맞추는 수고를 줄일 여지가 있습니다. 학생은 구현 이유를 질문하면서 변경 내역을 읽는 데, 연구자는 수정된 코드의 배경을 확인하고 로컬 실험으로 검증하는 데 활용할 수 있습니다.
반대로 이미 VS Code 안에서 요청부터 검증까지 처리하고 있다면 앱을 거치는 단계가 반드시 이득인 것은 아닙니다. 비교할 대상은 기능 수보다 실제 작업 과정입니다. 동일한 유형의 작은 변경을 기준으로 작업 맥락을 다시 설명한 횟수, 파일이나 브랜치를 정리하는 데 든 수고, 검토 중 발생한 혼선을 살펴보면 자신에게 필요한 연결인지 판단하기 쉽습니다.
처음 확인할 작업으로는 변경 범위가 분명하고 검증 방법이 있는 버그 수정이나 화면 문구 조정이 적합합니다. 앱에서 세션을 열고, VS Code에서 기존 대화를 확인하고, 직접 한 부분을 수정한 뒤 관련 검증을 실행하는 흐름을 따라가 봅니다. push까지 진행한다면 예상한 pull request가 갱신되는지도 확인합니다. 이 과정에서 계정이나 권한 문제와 코드 자체의 문제를 구분해 두면 이후 작업에서도 같은 혼선을 줄일 수 있습니다.
업무 저장소나 비공개 연구 자료를 다룬다면 데이터 처리와 접근 권한도 별도로 확인해야 합니다. 제공된 원문만으로는 대화나 코드의 보존 기간, 학습 사용 여부, 조직별 허용 정책을 판단할 수 없습니다. 자신의 계정과 조직에 적용되는 공식 조건을 확인한 범위에서 사용하는 것이 적절합니다.
출처와 검증
이 글은 GitHub Blog가 2026년 10월 19일 공개한 안내를 바탕으로 세션 이동과 코드 검토, 로컬 검증, pull request 갱신 과정을 정리했습니다. 원문이 설명하는 사용 흐름과 별개로 요금제, 지원 버전, 사용량 제한, 데이터 처리 조건은 실제 계정에 적용되는 최신 공식 안내에서 확인해야 합니다. 개별 환경에서의 작동 여부는 해당 세션과 저장소를 통해 검증할 수 있습니다.
원문: GitHub Blog — How to continue a GitHub Copilot app session in VS Code