VS Code 에이전트 창의 예약 실행과 세션 관리는 편리하지만, 실제 도입 전에는 계정·플랜·작업공간·외부 변경 권한을 분리해 확인해야 합니다.
이 글은 2026년 10월 12일 기준 GitHub Changelog와 Visual Studio Code 공식 문서를 대조한 뒤, 로그인·토큰·저장소 권한 없이 세션 경계를 계산하는 자체 로컬 fixture를 실행한 기록입니다. 직접 확인한 것은 “예약 실행을 누르면 GitHub가 동작한다”가 아니라, 실행 전후에 어떤 상태를 확인하고 외부 변경을 어디에서 멈출지입니다. 실제 GitHub Copilot이나 VS Code Agents window에 로그인하지 않았으므로 계정별 가용성·플랜·기능 노출은 확인하지 않았습니다.
이번 업데이트에서 실제로 바뀐 범위
GitHub의 2026년 10월 1일 Changelog는 VS Code 1.136부터 1.140까지 9월 릴리스를 한 묶음으로 설명합니다. Agents window에서 반복 작업을 시간·일·주 단위로 예약하거나 필요할 때 실행하는 Automations가 preview로 소개됐고, 진행 중 세션에서 agent merge를 켜 검토 피드백·실패한 검사·충돌·workflow 재실행을 다루는 흐름도 preview로 표시됩니다. 세션에서 pull request 양식을 열어 제목·설명·draft 및 merge 옵션을 검토한 뒤 만들 수 있다는 점, 관련 채팅과 세션을 계층적으로 탐색할 수 있다는 점도 함께 적혀 있습니다.
여기서 “기능이 문서에 있다”와 “내 계정에서 바로 쓸 수 있다”를 나눠야 합니다. Changelog는 HydraFusion 선택, agent merge, 자동 정리, 애플리케이션 badge를 각각 preview로 표시합니다. 따라서 글의 결론은 새 버튼을 누르라는 권유가 아니라, preview 표기·플랜·로그인 방식·저장소 권한·대상 호스트를 먼저 확인하라는 체크리스트여야 합니다. 문서에 나온 기능 목록은 제품의 현재 설명이고, 이 글의 로컬 fixture는 그 운영 경계를 연습한 별도 결과입니다.
Agents window와 일반 채팅을 구분하는 법
Visual Studio Code 공식 Agents window 문서는 여러 프로젝트의 세션을 한 곳에서 추적하고 결과를 검토하는 전용 창이라고 설명합니다. 세션 목록, 사용자 지정 패널, 채팅 영역, 변경 사항 패널, 파일 패널이 별도로 보이며, 기본적으로 workspace별로 세션이 묶입니다. 반대로 한 프로젝트를 자주 편집·디버깅·테스트하는 일은 Chat view가 더 맞을 수 있습니다. 같은 제품 안의 화면이 달라지면 보이는 변경 범위와 확인해야 할 상태도 달라집니다.
시작 전에는 인증 경계부터 고정합니다. 공식 문서가 제시하는 경로는 GitHub Copilot 접근, Claude API key 또는 다른 BYOK 설정, Codex를 위한 기존 ChatGPT 로그인, Agent Host용 BYOK 모델입니다. 이 중 하나가 있다고 해서 저장소 쓰기나 원격 세션이 자동으로 안전해지는 것은 아닙니다. 로컬 폴더를 붙일 때는 workspace trust, 원격 SSH·Tunnel·WSL을 사용할 때는 원격 호스트와 도구·의존성 범위를 별도로 읽어야 합니다.
특히 Dev Container 세션은 Docker가 설치되고 실행 중인지, Docker CLI가 PATH에 있는지, 설정한 도구가 실제 컨테이너 안에서 무엇을 읽고 쓰는지를 확인해야 합니다. 로컬 작업공간·원격 작업공간·컨테이너는 같은 “에이전트 세션”이라는 이름 아래에서도 파일과 네트워크 경계가 다릅니다. 첫 실행은 빈 테스트 프로젝트와 읽기 전용 요청으로 시작하고, 승인 전에는 운영 저장소·비밀값·배포 대상에 연결하지 않는 편이 안전합니다.
예약 실행을 자동화로 착각하지 않는 체크리스트
VS Code 공식 Automations 문서는 저장된 프롬프트, 세션 구성, 일정으로 agent task를 실행한다고 안내합니다. Automations는 preview이고 설정을 켜야 사이드바에 보이며, Stable에서는 기본값이 꺼져 있을 수 있습니다. 일정에 따라 실행되는 작업에는 “실행될 것인가”와 “실행되어도 무엇을 바꿀 수 있는가”가 별개의 질문입니다. 창이 계속 열려 있어야 하는 일정과 그렇지 않은 일정이 구분될 수 있으므로, 스케줄 자체를 성공 증거로 삼으면 안 됩니다.
실무에서는 자동화 정의에 다음 항목을 함께 기록하세요. 첫째, 프롬프트가 읽을 폴더와 쓰기를 허용할 폴더입니다. 둘째, 사용하는 harness와 모델, 인증 방식, 원격 호스트입니다. 셋째, 일정·시간대·재시도·중복 실행 방지입니다. 넷째, 결과가 바뀌었을 때 사람이 확인할 보고 위치와 실패 시 중단 조건입니다. 다섯째, pull request·merge·배포 같은 외부 상태 변경을 자동으로 허용하는지 여부입니다.
GitHub Docs의 Copilot automations도 일정 실행을 설명하지만, 저장소에서 Copilot cloud agent와 automations가 허용돼야 하고 플랜과 조직 정책 조건을 충족해야 한다고 안내합니다. 이 글의 주제인 VS Code Agents window의 로컬·원격 세션과 GitHub의 cloud automation은 이름이 비슷해도 실행 위치와 권한이 다릅니다. 둘 중 하나의 문서 내용을 다른 쪽의 실제 동작으로 바꾸어 쓰면 안 됩니다.
직접 실행 결과: 계정 없는 세션 경계 fixture
실제 GitHub나 VS Code에 로그인하지 않고, 세 가지 카드를 가진 로컬 HTML fixture를 직접 작성했습니다. 입력 화면에는 예약 실행이 preview라는 표기, 세션 상태를 나누는 설명, 로컬·원격 및 읽기·쓰기 경계를 확인한다는 안내가 표시됩니다. “외부 상태 변경 없이 경계만 계산”을 켠 상태에서 계산 버튼을 누르면 결과 화면이 열리고, 예약 실행은 계정·정책 확인, 세션 상태는 완료·주의 필요 분리, 외부 변경은 읽기 전용으로 차단됐다고 표시됩니다.
이 실습에서 관찰한 것은 세 개입니다. 먼저 입력 화면이 결과 화면으로 실제 전환되는지 확인했습니다. 다음으로 결과가 각 경계를 개별적으로 설명하는지 확인했습니다. 마지막으로 네트워크 요청·로그인·API 키·GitHub 저장소 쓰기가 없는 로컬 파일에서 수행했음을 확인했습니다. 그러므로 아래 캡처와 영상은 Copilot의 실제 UI나 API 응답이 아니라, 공식 문서의 개념을 실행 전 점검표로 바꾼 자체 실습의 증거입니다.
도입 전에 분리해서 기록할 실패 조건
첫 번째 실패 조건은 인증과 기능 가용성입니다. Agents window 문서가 설명하는 로그인 방식이나 Copilot 플랜이 현재 조직에서 허용되는지, Automations 설정이 켜져 있는지, preview 기능이 계정에 노출되는지부터 확인해야 합니다. 화면에 메뉴가 보이지 않는다고 제품 전체가 지원되지 않는다고 단정해서도 안 되며, 문서에 있다고 내 계정에서 된다고 단정해서도 안 됩니다.
두 번째는 작업공간과 세션의 범위입니다. 같은 폴더를 공유하는 두 대화는 서로 다른 채팅처럼 보여도 파일을 함께 바꿀 수 있습니다. 원격 세션·Dev Container·여러 repository를 오갈 때는 실제 작업 디렉터리, branch 또는 worktree, Docker volume, SSH·Tunnel·WSL 호스트를 확인하세요. 운영 저장소에서 자동화 prompt를 먼저 시험하지 말고, 재현 가능한 작은 fixture와 별도 브랜치에서 읽기 전용 결과를 확인하세요.
세 번째는 자동 실행과 외부 변경의 경계입니다. 세션이 완료됐다는 알림, pull request가 만들어졌다는 화면, merge 옵션이 보인다는 사실은 안전한 공개나 배포를 의미하지 않습니다. 사람이 diff·테스트·권한·대상 환경을 확인하기 전에는 merge·release·deploy를 막아 두고, 자동화 결과에는 입력 프롬프트·사용 모델·실행 시각·변경 파일·실패 원인을 함께 남기는 것이 좋습니다.
실전 운영 순서와 대안
도입 순서는 작게 시작하는 것이 합리적입니다. 먼저 공식 문서에서 현재 기능, preview 표시, 지원 버전과 로그인 조건을 읽습니다. 다음으로 네트워크 요청이 없는 로컬 fixture나 빈 테스트 저장소에서 입력→결과 전환을 확인합니다. 그 후 읽기 전용 분석, 테스트 실행, branch 또는 worktree 변경처럼 영향 범위가 좁은 작업을 하나씩 붙입니다. 마지막에만 pull request 작성이나 외부 서비스 변경을 별도 승인 단계로 연결합니다.
예약 실행이 필요한데 VS Code Automations를 쓸 수 없다면 운영체제 스케줄러에서 프롬프트를 직접 실행하려고 서두르기보다, 먼저 동일한 프롬프트를 수동 실행해 입력과 결과를 고정하세요. 세션을 여러 프로젝트에서 이어 가야 한다면 작업공간별 폴더와 worktree 정책을 문서화하고, 완료 세션 정리와 보관 규칙을 정하세요. GitHub cloud automation이 더 적합한 경우에도 저장소 정책·조직 허용·플랜을 확인하고, 로컬 Agents window 기능과 동일한 것으로 설명하지 마세요.
대안의 기준은 기능 수가 아니라 책임 경계입니다. 자동화가 읽을 수 있는 파일, 쓸 수 있는 파일, 사용할 수 있는 네트워크, 승인 없이 실행 가능한 명령을 먼저 목록화합니다. 그 목록이 비어 있지 않으면 preview 기능을 켜는 것보다 권한 축소와 로그 보존이 우선입니다. 이 접근은 특정 제품을 평가하는 점수표가 아니라, 어떤 agent harness를 선택하든 재사용할 수 있는 사전 점검 순서입니다.
검증 범위와 구분
공식 자료에서 직접 확인한 내용은 GitHub Changelog의 VS Code 1.136~1.140 릴리스 범위, Agents window의 자동화·세션·환경 기능 설명, VS Code Automations의 preview·설정·일정 안내, GitHub cloud automations의 저장소·플랜·조직 정책 조건입니다. 로컬 실습에서 확인한 내용은 자체 HTML fixture의 버튼 전후 화면 전환과 세 가지 안전 경계 결과입니다.
- 확인한 사실: 공식 문서는 예약 작업, 세션 관리, 작업공간·원격 환경 연결을 설명하며 일부 기능을 preview로 표시합니다.
- 확인한 사실: 자체 fixture는 네트워크·로그인·토큰 없이 입력 상태에서 결과 상태로 전환됩니다.
- 이번 범위에 없는 것: 이 Windows 환경의 VS Code 설치, GitHub Copilot 플랜, 계정별 Agents window 노출, 자동화 일정 실행은 다루지 않았습니다.
- 이번 범위에 없는 것: 로컬 계산 결과는 GitHub·Copilot·VS Code의 실제 agent 응답이나 저장소 변경 결과가 아닙니다.
이 구분을 글에 남기는 이유는 캡처가 실제 제품 화면처럼 보일수록 독자가 실행 범위를 오해하기 쉽기 때문입니다. 제품 계정에서의 사용 경험으로 읽히지 않도록, 공식 문서가 말하는 조건과 안전한 로컬 실습의 결과를 나란히 제시해야 합니다.
공식 출처와 검증일
공식 사실은 2026년 10월 12일 다음 1차 자료를 대조했습니다. GitHub Changelog는 9월 VS Code 릴리스의 Agents window 기능과 preview 범위를 설명합니다. Visual Studio Code Agents window 문서는 세션 목록·작업공간·인증·Dev Container·Automations의 사용 전제를 설명하고, Automations 문서는 저장 프롬프트·세션 구성·일정과 설정을 설명합니다. GitHub Copilot automations 문서는 cloud agent의 플랜·조직 정책·저장소 허용 조건을 별도로 설명합니다.
- GitHub Changelog: GitHub Copilot in VS Code, September 2026 releases
- Visual Studio Code: Use the Agents window
- Visual Studio Code: Create and manage agent automations
- GitHub Docs: About Copilot automations
에이전트가 외부 상태를 바꾸기 전에 stage-only 결과와 사람 승인을 분리하는 관점은 npm stage-only 토큰과 사람 승인 경계 점검 글에서도 이어서 확인할 수 있습니다.