VS Code 1.140 Agent Host 사용법: Copilot·Codex 세션과 원격 작업 관리

10월 02, 2026

VS Code 1.140은 AI 코딩 기능을 단순한 채팅 패널에서 장시간 작업을 관리하는 실행 환경으로 확장했다. 핵심은 에이전트 세션을 전용 프로세스인 Agent Host가 소유하고, 편집기나 Agents 창은 그 세션을 보고 조작하는 클라이언트가 되는 구조다. 이 변화 덕분에 Copilot·Claude·Codex 같은 서로 다른 하네스를 같은 방식으로 선택하고, 로컬 폴더·Git 워크트리·Dev Container·원격 호스트 중 작업 위치를 구분할 수 있다.

하지만 새 기능을 켰다고 자동으로 안전해지는 것은 아니다. 워크트리는 코드 변경을 분리할 뿐 보안 샌드박스가 아니며, 원격 위임은 파일을 알아서 복사하지 않는다. 예약 자동화도 컴퓨터와 Agent Host가 계속 실행 중이어야 한다. 이 글은 VS Code 1.140에서 무엇이 달라졌는지부터 실제 설정 순서, 세 가지 활용 예시, 권한과 문제 해결까지 한 흐름으로 정리한다.

한눈에 보는 핵심

선택 항목	결정하는 것	처음 권장값
Session Target	Copilot·Claude·Codex·Local 등 어떤 하네스가 세션을 실행할지	일반 코딩은 Copilot, 특정 제공자 흐름이 필요하면 Claude 또는 Codex
Workspace	명령과 파일 변경이 일어나는 위치	작은 작업은 Folder, 독립 변경은 New Worktree
Execution environment	로컬·컨테이너·SSH/터널 호스트 중 실제 도구가 실행될 환경	프로젝트 의존성이 복잡하면 Dev Container
Permissions	명령, 파일 변경, 네트워크 작업에 사람 승인이 필요한 범위	첫 실행은 Manual permissions

에이전트 호스트가 로컬 작업 공간, 격리 컨테이너, 원격 서버로 작업을 배치하고 사람이 변경 내용을 검토하는 구조를 표현한 개념도 — Agent Host는 세션을 관리하고, 실제 파일·명령 작업은 선택한 로컬·컨테이너·원격 환경에서 실행된다.

Agent Host는 기존 채팅과 무엇이 다른가

Agent Host는 VS Code 확장 호스트와 분리된 전용 프로세스다. 세션, 채팅, 터미널, 변경 집합의 상태를 Agent Host가 보유하고 클라이언트는 이를 동기화한다. 따라서 같은 세션을 여러 VS Code 창에서 보거나, Agent Host가 살아 있는 동안 창을 닫았다가 다른 창에서 이어갈 수 있다. 원격 환경에서는 Agent Host가 소스 코드와 개발 도구 가까이에 있고, 로컬의 Agents 창은 화면과 제어 역할을 맡는다.

여기서 하네스와 실행 환경을 구분해야 한다. 하네스는 모델 호출, 도구 사용, 컨텍스트와 코드 변경을 조정하는 런타임이다. 실행 환경은 명령과 파일 변경이 실제로 일어나는 장소다. 예를 들어 Codex 하네스를 선택하면서 로컬 폴더를 사용할 수도 있고, Copilot 하네스를 원격 Dev Container에서 실행할 수도 있다. Dev Container는 별도 하네스가 아니라 실행 환경 선택이다.

VS Code 공식 문서는 처음 시작할 때 일반 코딩 작업에는 Copilot, VS Code 확장 도구가 꼭 필요하면 Local, 제공자별 워크플로가 필요하면 Claude 또는 Codex, 독립된 GitHub 저장소 작업과 PR 반환이 목적이면 Cloud를 선택하도록 안내한다. 모델과 하네스의 이름이 비슷해도 같은 개념은 아니다.

설정 순서: 첫 세션부터 안전하게 시작하기

1. VS Code 1.140으로 업데이트한다

이번 글의 기준 버전은 2026년 9월 30일 공개된 Stable 1.140이다. 메뉴에서 Check for Updates를 실행한 뒤 버전을 확인한다. 조직이 최소 버전을 정책으로 강제하는 경우 Chat이나 Agents 창에 설치 버전과 요구 버전이 표시될 수 있다.

2. Agents 창을 연다

제목 표시줄의 Open in Agents, 명령 팔레트의 Chat: Open Agents window, 또는 터미널의 code --agents를 사용할 수 있다. Agents 창은 여러 프로젝트와 세션을 배정·추적하는 데 초점이 있고, 편집기 안 Chat 보기는 현재 코드를 보며 대화하는 데 더 적합하다.

3. 하네스와 작업 위치를 따로 고른다

새 세션에서 Session Target을 선택한 다음 Workspace를 정한다. 현재 폴더의 미커밋 변경을 직접 다뤄야 하고 매 단계 승인을 받고 싶다면 Folder가 단순하다. 변경을 현재 작업과 분리하려면 New Worktree를 고른다. 다만 공식 문서상 워크트리 세션은 Allow all을 사용하며, 워크트리 자체는 보안 경계가 아니다. 신뢰하지 않는 명령이나 비밀정보 접근을 막는 용도로 해석하면 안 된다.

4. 프로젝트 도구가 중요하면 Dev Container를 사용한다

Node.js·Python·데이터베이스 CLI 등 프로젝트별 의존성이 많다면 폴더 메뉴에서 Use Dev Container를 선택한다. Agent Host와 명령이 컨테이너 안에서 실행되므로 호스트에 도구를 반복 설치하지 않아도 된다. 원격 SSH·Tunnel·WSL 호스트의 Dev Container도 지원하지만 Docker가 실행 중이고 프로젝트에 Dev Container 구성이 있어야 한다.

5. 첫 작업은 검증 가능한 요청으로 보낸다

“이 기능을 완성해 줘”보다 범위, 금지사항, 확인 명령, 산출물을 함께 적는다. 예를 들면 다음과 같다.

인증 흐름을 검토하고 실패 원인을 정리한다.
파일은 수정하지 않는다.
관련 테스트와 로그 위치를 찾고, 근거가 있는 항목만 보고한다.
마지막에 수정이 필요한 파일 후보와 검증 명령을 제안한다.

먼저 읽기 전용 조사로 구조를 확인한 뒤 구현 세션을 분리하면 불필요한 광범위 수정과 권한 요청을 줄일 수 있다.

VS Code 1.140 채팅 입력창에서 Copilot 하네스를 선택한 공식 화면 — VS Code 1.140의 하네스 선택 화면. 출처: Microsoft Visual Studio Code 1.140 릴리스 노트, 2026년 10월 2일 확인.

활용 예시 1: 두 저장소의 기능을 한 세션에서 맞추기

프런트엔드와 API 저장소를 함께 바꿔야 한다면 1.140의 multi-folder sessions를 사용할 수 있다. 메인 채팅은 API 저장소에서 스키마를 변경하고, peer chat은 프런트엔드 저장소에서 타입과 화면을 수정하도록 나눈다. 각 채팅은 자기 폴더의 터미널, 변경, PR, Agent merge 상태를 사용하므로 서로 다른 체크아웃의 변경이 섞이는 위험을 줄인다.

이 기능은 실험 단계이며 Settings 화면에 항목이 보이지 않는다. 사용자 범위 settings.json에서 하네스별 설정을 켠다.

Copilot: chat.agentHost.copilotAgent.multiRootEnabled
Claude: chat.agentHost.claudeAgent.multiRootEnabled
Codex: chat.agentHost.codexAgent.multiRootEnabled

새 세션부터 설정이 적용되며 Agent Host를 재시작할 필요는 없다. 현재 UI에는 peer chat의 폴더를 직접 고르는 화면이 없으므로 메인 채팅에 저장소나 워크트리를 명확히 지정해야 한다. 예를 들어 “현재 세션에 peer chat을 만들고, 두 번째 저장소의 새 워크트리에서 타입 변경만 처리하라”고 요청한다.

완료 확인: 세션 목록에서 각 채팅의 폴더·브랜치·PR을 따로 확인하고, 두 저장소의 테스트를 독립적으로 실행한 다음 통합 계약이 맞는지 사람이 검토한다.

활용 예시 2: 원격 Linux 장비에 무거운 검증 맡기기

로컬 노트북에서 빌드가 오래 걸리거나 운영체제별 검증이 필요하면 SSH 또는 인증된 dev tunnel로 원격 호스트를 연결한다. 원격 장비는 켜져 있고 네트워크에서 접근 가능해야 한다. Agents 창은 원격 장비에 VS Code CLI를 자동 설치·실행하며, 실제 명령은 원격 Agent Host가 있는 환경에서 수행된다.

1.140의 실험적 원격 위임을 사용하려면 chat.remoteAgentHostsEnabled와 chat.remoteSessions.tools.enabled를 켠다. 그러면 에이전트가 list_agent_hosts로 호스트와 자원을 확인하고, create_remote_session으로 운영체제·메모리·CPU 조건에 맞는 세션을 시작하며, get_remote_session과 send_remote_message로 상태와 결과를 주고받을 수 있다.

중요한 제약이 있다. 원격 위임 도구는 현재 작업 공간을 자동 복제하거나 복사하지 않는다. 저장소 작업이라면 대상 호스트에 이미 있는 신뢰된 폴더 또는 새 Git 워크트리를 지정해야 한다. 조정하는 Agents 창도 메시지가 오가는 동안 열리고 연결된 상태여야 하며, 원격 세션의 최종 답변은 자동 전달되지 않는다.

완료 확인: 승인 화면에서 실제 선택된 호스트·폴더·워크트리를 확인하고, 원격 세션이 보고한 버전이나 테스트 결과를 원본 로그와 대조한다. 익명 접근을 허용하는 터널은 사용하지 않는다.

활용 예시 3: 매일 변경 요약을 자동화하기

Agents 창의 Automations는 저장한 프롬프트, 세션 구성, 일정으로 작업을 실행한다. Stable에서는 점진 배포 중이며 chat.automations.enabled가 기본적으로 꺼져 있을 수 있다. 처음에는 Schedule을 Manual로 두고 Run now로 결과를 검토한 뒤 Daily 또는 Weekly로 바꾸는 편이 안전하다.

예시는 “지난 24시간 커밋을 기능·수정·유지보수로 나누고 문서화가 필요한 변경만 표시하며 파일은 수정하지 말라”는 읽기 전용 작업이다. 이름, 프롬프트, Workspace 또는 No workspace, 하네스, 모델, 권한, 격리 방식을 차례로 정한다. 자동화는 파일을 읽고 명령을 실행하거나 권한에 따라 수정도 할 수 있으므로, 무인 실행 전에 permission level을 반드시 확인한다.

로컬 자동화는 클라우드 예약 서비스처럼 항상 실행되는 것이 아니다. Agent Host 기반 일정은 Agent Host 프로세스가 실행 중이어야 하고, 다른 일정은 VS Code 창이 열려 있어야 한다. 컴퓨터가 잠자기 상태가 되면 예정 시각을 놓칠 수 있으며, 중단 뒤 catch-up run이 일어날 수 있지만 모든 누락 실행이 재생된다고 기대해서는 안 된다. 같은 자동화는 한 번에 한 세션만 실행된다.

권한·비용·보안에서 놓치기 쉬운 점

워크트리는 보안 샌드박스가 아니다. 브랜치와 작업 디렉터리를 분리하지만, 에이전트가 접근 가능한 자격증명·네트워크·호스트 파일의 범위까지 자동 차단하지 않는다.
Dev Container도 구성에 따라 권한이 달라진다. 호스트 소켓, 홈 디렉터리, 비밀정보를 과도하게 마운트하면 격리 효과가 줄어든다.
터널은 인증을 요구해야 한다. 익명 터널과 자동 승인 조합은 제3자가 명령 실행을 유도할 위험을 키운다.
하네스마다 인증과 과금 방식이 다르다. Copilot 구독, ChatGPT 기반 Codex 로그인, Claude API 키 또는 조직 정책을 혼동하지 말고 세션 시작 전 제공자와 모델을 확인한다.
확장 도구는 항상 보이지 않는다. Agent Host 세션에서 확장이 제공하는 도구는 해당 확장이 실행 중인 편집기 창의 채팅에서만 이용 가능한 경우가 있다.
MCP 설정 위치가 달라질 수 있다. Agent Host는 작업 공간의 .mcp.json과 사용자 범위 ~/.copilot/mcp-config.json을 읽는다. 기존 .vscode/mcp.json은 VS Code가 전달하지만 대화형 입력 변수가 필요한 서버는 전달되지 않을 수 있다.

GitHub Copilot 앱의 로컬 실행 권한 자체를 더 세밀하게 제한하려면 스택핀치의 GitHub Copilot 앱 로컬 샌드박스 설정 가이드도 함께 참고할 수 있다. Agent Host의 세션 구조와 로컬 샌드박스 정책은 서로 다른 층의 통제다.

자주 막히는 상황과 해결 순서

Agents 창에 원하는 하네스가 없다

GitHub, ChatGPT 또는 제공자 계정 로그인이 완료됐는지 확인한다. GitHub 로그인 없이 Codex를 쓰는 실험 경로는 관련 설정을 켜고 Agents 창 계정 메뉴에서 ChatGPT에 로그인해야 한다. 같은 모델명이 여러 제공자에 있으면 모델 선택기에서 제공자를 함께 확인한다.

Multi-folder 설정을 켰는데 기존 세션이 그대로다

설정은 새 세션에 적용된다. 기존 세션을 억지로 바꾸지 말고 새 세션을 만들고, 메인 채팅에 peer chat이 사용할 폴더 또는 워크트리를 명시한다.

원격 호스트가 보이지 않는다

SSH 접속 가능 여부나 dev tunnel의 실행·인증 상태를 먼저 확인한다. 호스트가 켜져 있어도 네트워크에서 접근할 수 없으면 목록에 연결되지 않는다. 브라우저 Agents 창을 사용한다면 호스트 바의 Online/Offline 상태도 확인한다.

예약 자동화가 실행되지 않았다

chat.automations.enabled, Enabled 상태, 로컬 시간대, Agent Host 또는 VS Code 창 실행 여부, 컴퓨터 절전 상태를 순서대로 확인한다. History에서 실패 세션과 승인 대기 요청을 확인한 뒤에만 재실행한다.

변경이 너무 넓거나 서로 충돌한다

관련 작업과 독립 작업을 구분한다. 같은 결과물의 조사·검토는 peer chat으로, 별도 결과물은 independent session으로 만든다. 파일 변경이 필요한 병렬 시도는 각자 새 워크트리를 사용하고, 최종 선택은 테스트·diff·진단 결과를 사람이 비교한다.

마무리: 세션, 위치, 권한을 각각 결정하라

VS Code 1.140의 중요한 변화는 “어떤 모델이 더 좋은가”보다 에이전트 작업을 어디에서, 어떤 세션 관계로, 어떤 승인 수준으로 실행할지를 분리해서 고를 수 있게 된 점이다. 처음에는 Folder와 Manual permissions로 작은 검증 작업을 수행하고, 변경 분리가 필요하면 New Worktree, 의존성 격리가 필요하면 Dev Container, 별도 자원이 필요하면 인증된 원격 호스트로 확장하는 순서가 안전하다.

실험 기능인 multi-folder sessions와 remote delegation은 강력하지만 폴더 선택, 복제, 결과 전달을 자동으로 해결하지 않는다. 자동화 역시 첫 실행을 수동으로 검토한 뒤 일정에 올려야 한다. 결국 Agent Host는 책임을 없애는 기능이 아니라, 여러 에이전트와 실행 환경의 책임 경계를 더 분명하게 관리하기 위한 기반이다.

공식 자료

자료 확인일: 2026년 10월 2일. Preview·Experimental 기능은 배포 범위와 설정이 바뀔 수 있으므로 사용 중인 VS Code 버전의 공식 문서를 다시 확인하세요.

Read this guide in English

이 블로그 검색

스택핀치