← 목록으로

TIR

VS Code 1.138 에이전트 세션 업데이트와 Dev Container 사용기

· 14분 읽기

RELEASE NOTES★★★★☆

원작자 Visual Studio Code

아침에 요즘 제일 많이 쓰는 VS Code 1.138 릴리즈 노트를 열었는데, 에디터·터미널 항목이 하나도 없었어요. VS Code는 에디터에서 에이전트로 나아가고 있습니다. 처음부터 끝까지 Agents 얘기였어요.

원래 코덱스, 클로드, 제미나이 등 일꾼 넷이 각자 다른 건물에 있어요. 병렬로 AI들을 돌리고, 한 AI를 병렬로 돌리기도 하죠. 하지만 간혹 누가 지금 손 놓고 나를 기다리는지 보려면 건물을 하나씩 돌아야 하고, 건물마다 공구함(MCP·확장·터미널)도 따로, “이거 해도 돼?” 묻는 방식도 따로죠. 지금 공구함은 개인적으로 다 통일해놓은 상태예요. 그런데 VS Code의 이번 업데이트가 이 일꾼들을 한 건물에 모아두는 “에이전트 사무소”를 만들었네요?!


🎯 VS Code의 에이전트 세션 기능 적용결과

  • 1.138은 에이전트 세션 릴리즈예요. 에이전트를 내 PC가 아니라 프로젝트의 Dev Container 안에서 돌리고, Codex를 Copilot/ChatGPT 어느 구독으로든 쓰고, 끝난 세션은 자동으로 치웁니다.
  • 설정 10개를 켜고 직접 돌려본 결과, Dev Container 즉 Docker 안에서 AI들이 병렬로 일하며 결과를 테스트하고, 원래 코드에 영향이 없게 작업한 뒤 커밋·PR을 할 수 있는 기능이 정말 좋았어요. 단 Codex로 갈아타기는 Copilot Pro 안의 기능이라 조금 불편했어요.
  • 혼자 한 번에 한 가지 작업만 하는 흐름에서는 체감이 크지 않지만, 여러 AI 일꾼을 동시 감독하는 멀티 에이전트 환경에선 확실히 매력적인 방향이라고 느꼈어요.

📋 릴리즈에 들어 있는 것

한 줄로 줄이면 “에이전트를 현장 컨테이너로 보내고, Codex는 구독을 넘나들고, 끝난 세션은 치운다”예요. 직접 써본 것만 적으면 이렇습니다.

기능 설정 상태
에이전트 세션을 폴더의 Dev Container 안에서 실행 chat.agentHost.devContainer.enabled 점진 배포 (기본 꺼짐)
Codex를 Copilot ↔ ChatGPT 구독 사이에서 대화 유지한 채 전환 chat.agentHost.codexAgent.enabled · chat.editor.codex.preferAgentHost stable 기본 꺼짐
ChatGPT 앱 ↔ VS Code 사이에서 같은 Codex 세션 이어가기 (위와 같음)
세션에서 바로 PR 만들기 (제목·설명·draft·머지 옵션 한 폼) chat.agentMerge.enabled (Agent Merge만)
PR 머지되면 “완료 처리할래?” 제안 chat.agentSessions.archiveNudge.enabled Preview
N일 뒤 자동 완료 / 삭제 chat.agentSessions.autoArchiveMergedSessionsAfterDays · ...autoDeleteArchivedMergedSessionsAfterDays 기본 꺼짐
로컬 폴더·GitHub·Cloud 저장소를 한 목록에서 고르기 sessions.chat.unifiedWorkspacePicker.enabled Experimental

이게 다 되는 이유는 밑에 Agent Host Protocol(AHP)이라는 게 깔렸기 때문이에요. 에이전트 하네스(도구·승인·세션을 감싸는 껍데기)를 별도 프로세스로 돌리는 구조라서, 위 기능들이 전부 새로 생긴 “Agents 창” 안에서만 돌아요. 릴리즈 노트 항목마다 “(Agents window only)“가 붙어 있는 게 그래서예요.


VS Code가 왜 “Agents 창”을 만들었을까요?

옛날 (각 앱을 따로 굴릴 때):

 [Codex]   [Claude Code 터미널]   [Antigravity]   [Copilot]
   사무실 A        사무실 B             사무실 C         사무실 D
   자기 도구        자기 도구            자기 도구         자기 도구
   자기 승인규칙     자기 승인규칙         자기 승인규칙      자기 승인규칙
        ↑              ↑                  ↑               ↑
        └──── 내가 사무실마다 걸어다니며 맡긴 업무 확인 ────┘

1.138 (Agents 창 통합):

 현장 사무소 (Agents 창)
 ┌ 일꾼:        Copilot · Claude · Codex · Cloud   ← 한 번에 통합
 ├ 공구함 하나:  VS Code 도구 + 확장 + MCP + git
 ├ 승인 규칙 하나: Default / Allow all
 └ 게시판 하나:  세션 목록 · 뱃지 · PR 폼 · 정리
   ↑ 창 두 개, ChatGPT 앱에서도 같은 일꾼을 봄 (AHP)

흩어져 있던 일꾼들을 한 사무소에 모으고 공구함과 승인 규칙, 게시판을 통일한 셈이죠. Dev Container·PR 폼·세션 정리·뱃지가 전부 그 방 안에 있는 이유입니다.

그럼 언제 이게 낫냐. 일꾼 3~4명을 동시에 다른 일에 붙여놓고 감독할 때, 그리고 벤더 상관없이 같은 MCP·같은 승인 규칙으로 묶어야 할 때예요. 회사에서 정책 하나로 통제해야 하는 경우도 여기 들어가고요 (번들에 chat.agentHost.otel.*, *.policy 설정이 수십 개 있는 이유가 그거예요).

반대로 한 번에 한 가지 일만 하거나, Claude Code 플러그인·Codex 앱 computer use·Antigravity 브라우저처럼 각 앱의 고유 기능이 필요하면 지금처럼 각 앱을 켜는 게 나아요. 저는 아직 후자인데, 전자가 필요한 날이 멀지 않은 것 같긴 합니다.

🐳 그런데 Dev Container는 뭔가요?

한 줄로, 프로젝트가 돌아가는 데 필요한 환경을 통째로 담은 Docker 컨테이너예요. 어떤 OS에 어떤 언어 몇 버전, 어떤 도구를 깔아둘지를 .devcontainer/devcontainer.json 파일 하나에 적어두면, VS Code가 그 파일대로 컨테이너를 만들고 그 안에서 작업하게 해줍니다.

왜 이런 게 필요하냐면, “내 PC에선 되는데 남의 PC에선 안 되는” 문제 때문이에요. 이 블로그만 해도 Node 22가 필요한데, 다른 프로젝트는 Node 18을 쓰고, 회사 PC와 집 PC의 설치 상태가 다르죠. 환경을 파일로 적어두면 어느 PC에서든 같은 컨테이너가 만들어지니까 그 차이가 사라집니다. GitHub Actions 같은 CI도 결국 Ubuntu 컨테이너에서 돌기 때문에, 배포 환경과 똑같은 곳에서 미리 돌려볼 수 있다는 장점도 있어요.

원래는 Dev Containers: Reopen in Container로 VS Code 창 자체를 컨테이너 안으로 전환하는 방식이었어요. 이번 1.138은 창은 로컬에 두고 에이전트만 그 컨테이너 안으로 보내요. 그래서 파일 탐색기·터미널은 내 PC 그대로인데, 에이전트가 실행하는 npm run build는 컨테이너 안의 Node로 돌아요.

devcontainer.json에 들어가는 건 다섯 가지 정도예요. 어떤 이미지로 시작할지(image, Microsoft가 언어별로 미리 만들어 둔 게 있어요), 컨테이너 만든 직후 한 번 돌릴 명령(postCreateCommand, 보통 의존성 설치), 컨테이너 안 포트를 내 브라우저로 연결(forwardPorts), 특정 폴더를 내 PC 폴더 대신 별도 볼륨으로 쓰기(mounts), 컨테이너 안에 자동으로 깔 확장(customizations.vscode.extensions).


🛠️ 직접 켜고 테스트해본 과정

settings.json에 관련 핵심 설정 10개를 추가하고 VS Code를 완전히 재시작했어요. (codexAgent.enabled 등 일부 실험 옵션은 리로드만으로는 적용되지 않아서 완전 재시작이 필수입니다.)

"chat.agentHost.devContainer.enabled": true,
"chat.agentHost.codexAgent.enabled": true,
"chat.editor.codex.preferAgentHost": true,
"chat.agentHost.allowSignedOutWhenUsable": true,
"chat.agentMerge.enabled": true,
"chat.agentSessions.archiveNudge.enabled": true,
"chat.agentSessions.autoArchiveMergedSessionsAfterDays": 7,
"sessions.archiveSessionConfetti": true,
"sessions.showApplicationBadge": true,
"sessions.chat.unifiedWorkspacePicker.enabled": true

Step 1 — Agents 창 열기 ✅

Ctrl+Shift+P → Open Agents Window로 전용 창을 열었습니다. 창이 열리자마자 외부 터미널에서 돌리던 Claude Code 세션을 상단 배너가 자동으로 감지해 가져오는 모습이 꽤 흥미로웠어요.

첫 로컬 세션 — PowerShell 출력과 외부 세션 배너

Step 2 — Dev Container 세션 연결하기 ✅

테스트를 위해 블로그 레포에 .devcontainer/devcontainer.json을 새로 작성했어요.

여기서 가장 중요한 포인트는 mounts 설정입니다! 처음엔 이 설정을 빼먹었다가 컨테이너 안에서 실행된 npm ci가 제 로컬 Windows용 node_modules를 Linux용 패키지로 덮어써 버리는 바람에 로컬 빌드가 깨지는 일을 겪었어요. node_modules를 컨테이너 전용 볼륨으로 떼어놔야 로컬 쪽이 안 다쳐요.

{
  "name": "blog (Astro)",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "mounts": [
    "source=blog-node_modules,target=/workspaces/blog/node_modules,type=volume"
  ],
  "postCreateCommand": "sudo chown node:node node_modules && npm ci",
  "forwardPorts": [4321],
  "customizations": {
    "vscode": {
      "extensions": ["astro-build.astro-vscode"]
    }
  }
}

여기까지 오는 데 두 번 헤맸어요.

  1. 서브메뉴 우회: 신규 세션 목록에서 폴더 이름 오른쪽 끝에 있는 > 화살표를 클릭해야 Use Dev Container 선택창이 나옵니다. 그냥 폴더명을 누르면 로컬 세션으로 시작해 버려요.
  2. 승인 대기 멈춤: 컨테이너 세션은 터미널 명령마다 승인을 묻는데, “생각” 상태로 14분을 기다리다 멈춘 줄 알고 ⏹를 눌렀어요. 에이전트 호스트 로그를 보니 그게 거부(reject)로 들어가 있더라고요.
03:15:21 Tool started: bash
03:15:21 Requesting confirmation for tool call   ← 승인 대기
04:35:57 Aborting session… Permission response: result=reject

서브메뉴 — Use Local / Use Dev Container

권한을 Allow all로 바꾸고 새 세션을 만드니까 그제야 돌았어요.

확인 항목 로컬 세션 Dev Container 세션
node -v v22.18.0 v22.23.2
pwd D:\dev\blog /workspaces/blog
/etc/os-release 없음 Debian GNU/Linux 13 (trixie)
셸 PowerShell bash
npm run build 성공 성공 — 73개 페이지 정상 빌드 완료

성공 — v22.23.2, /workspaces/blog, Debian 13, 빌드 성공

Node 버전이 다르니까 내 PC가 아니라 컨테이너에서 빌드한 게 맞아요. 에디터와 탐색기는 로컬 그대로인데 에이전트만 컨테이너에 가 있는 게, 써보니 생각보다 깔끔하네요. 옛날 방식(Dev Containers: Reopen in Container)은 창 자체가 컨테이너로 들어가서 로컬 다른 폴더가 안 보였는데, 이건 그 불편이 없어요.

Step 3 — Codex 갈아타기 ❌ Copilot Pro 기능에 포함

Copilot ˅ 드롭다운을 열었더니 Copilot · Claude · Codex · 클라우드 네 개가 있는데, Copilot 빼고 전부 “업그레이드” 배지가 붙어 있었어요. 번들 문구는 [Upgrade to GitHub Copilot Pro] to use this agent. 릴리즈 노트는 “Copilot 구독 또는 ChatGPT 구독으로 쓴다”고만 했지, Free 플랜에선 하네스 자체가 잠겨 있다는 말은 없었어요.

Pro는 Codex 하네스를 여는 열쇠고, 모델 사용료는 따로예요. ChatGPT 쪽 모델을 고르면 ChatGPT 구독 한도에서, Copilot 쪽 모델을 고르면 Pro의 월 크레딧에서 빠집니다. 학생 팩에 Pro 무료가 들어 있어서 그걸로 열어보려 했는데, 학생 계정의 Pro로는 타사 에이전트 접근 권한이 안 열렸어요. 음…아무래도 결제한 Pro와 학생 Pro가 같은 게 아닌 것 같아요.


❓ 하다가 궁금했던 것들

Q. 매번 Agents 창을 열어야 하는가? 이 기능들은 그래요. 대신 Use Dev Container는 한 번 고르면 폴더에 붙어 있어서 Use Local로 돌리기 전까지 그 폴더의 새 세션은 계속 컨테이너에서 돕니다.

Q. Dev Container로 돌리는 게 의미가 있나? 블로그 프로젝트엔 솔직히 별로예요. 쓸모가 있는 건 ① 에이전트가 위험한 걸 할 때(컨테이너 밖 폴더·PATH·전역 npm·자격증명에 손 못 댐) ② CI(Ubuntu)와 같은 환경에서 push 전 검증(Linux는 대소문자 구분이라 Windows에선 되고 배포에서 깨지는 걸 잡음) ③ 프로젝트마다 도구 버전이 다를 때.

Q. 그럼 Agents 창은 언제 쓰는 거죠? Docker 안에서 돌리는 건가요? Codex도 결제해야 하나요? 아래는 하다가 헷갈렸던 것들이에요.

제가 생각한것 판정 Agents 창의 결과
Agents 창 = 일꾼 여럿 붙여놓고 병렬 감독할 때 ✅
하네스를 설계해야 할 때 ❌ 하네스는 VS Code가 이미 만들어 둔 것. 고르기만 함
Agents 창 = Docker 안에서 돌리는 것 ❌ 기본은 로컬. Dev Container는 그 안의 옵션 하나
Copilot이 메인이라 Pro 결제 ✅ 학생 팩 Pro는 무료지만, 그걸로는 Codex·Claude 에이전트가 안 열림
Codex도 따로 결제해야 ❌ Pro는 Codex 하네스를 여는 열쇠. 모델 사용료는 Copilot 크레딧 또는 이미 있는 ChatGPT 구독
Codex 기록은 로컬에 남는다 ✅ ~/.codex/sessions/에 JSONL. chat.agentHost.codexAgent.codexHome 설명대로 CLI·앱과 같은 폴더를 써서 앱 ↔ VS Code 이어가기가 되는 것

✅ 이번 걸 통해 해본 것

  • Agents 창 열기, 외부 세션(터미널 Claude Code) 목록에서 확인
  • Dev Container를 이해하고 세션에서 npm run build — 컨테이너 node로 빌드되는 것 확인
  • 통합 워크스페이스 피커, Mark as Done
  • 릴리즈 노트 설정 ID를 번들과 대조해서 오타 2개 찾기

📝 3줄 요약

  1. VS Code 1.138은 여러 AI 에이전트를 통합 관리하는 “Agents 창”과 Dev Container 연동이 핵심입니다.
  2. 에이전트만 Docker 컨테이너에 보내면 내 PC를 안 건드리고 테스트·빌드를 돌릴 수 있어요.
  3. 한 번에 한 가지 일만 하는 사람한텐 아직 별로고, 에이전트 여럿을 굴리는 사람한텐 꽤 큰 업데이트예요!

💡 마무리하며

에디터 릴리즈 노트에 에디터 얘기가 한 줄도 없다니, VS Code가 어디로 가는지 확실히 보였어요. 에이전트를 “채팅창”이 아니라 “감독해야 할 일꾼 여럿”으로 보기 시작한 거예요. 다음은 Dev Container 를 활용해 오픈소스를 기여하는 경험을 해보고, Agents 창이 그때 어떤 의미가 있는지 확인해보려고 합니다.