핵심 요약
AI 코딩 에이전트가 실패하는 지점은 코드 생성보다 세션, 권한, 터미널 명령 관리에서 더 자주 터집니다.
GitHub가 2026년 6월 3일 공개한 VS Code Copilot May releases는 그래서 중요합니다. 이번 업데이트는 “Copilot이 답변을 더 잘한다”는 식의 기능 추가가 아닙니다. VS Code 안에서 여러 에이전트 세션을 띄우고, 원격 머신에서 오래 도는 작업을 추적하고, BYOK 모델의 토큰 사용량을 확인하고, 위험한 터미널 명령을 실행하기 전에 한 번 더 판단하게 만드는 작업 환경 업데이트입니다.
한 줄로 요약하면 이렇습니다. VS Code의 AI 코딩은 채팅창에서 코드 조각을 받는 경험을 지나, 여러 에이전트 작업을 운영하는 작은 관제실로 이동하고 있습니다.
이미지 출처: Visual Studio Code Docs, “Use the Agents window”. 첫 번째 본문 이미지이며 카드 썸네일로도 VS Code 에이전트 작업면의 핵심을 바로 보여줄 수 있다.
무슨 일이 있었나
GitHub Changelog의 2026년 6월 3일 공지는 VS Code Copilot의 v1.120부터 v1.123까지, 2026년 5월과 6월 초에 배포된 변화를 묶어 설명합니다. 핵심 축은 세 가지입니다.
첫째, Agents window가 VS Code Stable에 preview로 들어왔습니다. 기존 Chat view가 “현재 코드 편집 중에 AI를 부르는 곳”이었다면, Agents window는 “여러 프로젝트와 여러 세션을 한 화면에서 관리하는 곳”에 가깝습니다. 공식 문서는 이 창을 agent-first workflow용 전용 VS Code 창이라고 설명합니다. 세션 목록, 커스터마이징 패널, 대화 영역, 변경 파일 패널이 나뉘어 있어 에이전트의 작업 상태와 결과물을 한꺼번에 확인할 수 있습니다.
둘째, remote agents와 Agent Host Protocol, 줄여서 AHP가 전면에 나왔습니다. Agents window는 SSH나 dev tunnel을 통해 원격 머신에 연결할 수 있고, 연결되면 VS Code CLI를 원격에 설치해 에이전트 host 프로세스를 띄웁니다. 세션은 원격에서 계속 돌 수 있고, 클라이언트가 끊겼다가 다시 붙어도 같은 작업을 이어 볼 수 있습니다. 노트북을 닫아도 고성능 워크스테이션이나 사내 개발 서버에서 에이전트가 테스트를 계속 돌리는 시나리오가 열리는 셈입니다.
셋째, BYOK와 터미널 안전 기능이 확장됐습니다. GitHub는 air-gapped BYOK, custom endpoint provider, provider별 모델 피커, BYOK token visibility, reasoning effort controls, utility model 선택 기능을 이번 묶음에 포함했습니다. 동시에 terminal output compression, command risk assessment, 민감 입력을 LLM에 보내지 않는 터미널 처리, VSCODE_AGENT 환경 변수도 추가했습니다.
| 변화 | 개발자에게 보이는 의미 | 팀이 정해야 할 기준 |
|---|---|---|
| Agents window | 여러 에이전트 세션과 변경 파일을 한 화면에서 관리 | 세션 이름, 작업 범위, 완료 기준 |
| Remote agents / AHP | 원격 머신에서 장시간 작업을 계속 실행 | SSH/dev tunnel 인증, 접근 가능한 repo 범위 |
| BYOK token visibility | 자체 API 키 모델의 실제 토큰 사용량 확인 | 개인 키 허용 여부, 비용 추적 방식 |
| Command risk assessment | 터미널 명령 실행 전 위험도와 설명 확인 | 자동 승인 범위, 금지 명령, 로그 보관 |
| Sensitive prompts stay in terminal | 비밀번호·PIN·인증코드를 LLM에 보내지 않음 | 비밀값 입력 절차와 교육 |
사람들이 실제로 겪는 문제
개발자가 AI 코딩 도구를 쓰면서 가장 먼저 겪는 문제는 “모델이 똑똑한가”가 아닙니다. 어느 순간부터는 작업이 너무 많아집니다.
한 세션은 테스트를 고치고, 다른 세션은 문서를 정리하고, 또 다른 세션은 UI 회귀를 잡습니다. 각 세션은 파일을 바꾸고, 터미널을 실행하고, 로그를 읽고, 브라우저를 열어 확인합니다. 문제는 이 모든 작업이 한 채팅창 안에 묻히면 사람이 무엇을 승인해야 하는지 놓치기 쉽다는 점입니다.
Agents window는 이 문제를 UI로 풀려는 시도입니다. 공식 문서 기준으로 세션 목록은 프로젝트별 작업을 모아 보여주고, Changes panel은 에이전트가 만든 변경 파일을 따로 보여줍니다. diff view에서 변경을 확인하고, 필요하면 파일 안에 피드백을 달아 에이전트에게 다시 수정하게 할 수도 있습니다. 즉 대화 로그를 끝까지 뒤지는 대신, “무슨 파일이 바뀌었고 무엇을 검증해야 하는가”를 작업 단위로 보는 구조입니다.
BYOK도 같은 맥락입니다. VS Code의 언어 모델 문서는 자체 API 키로 외부 모델이나 로컬 모델을 붙일 수 있다고 설명합니다. Copilot 플랜이나 GitHub 로그인 없이도 chat 기능과 일부 utility task에 BYOK 모델을 쓸 수 있고, Ollama 같은 로컬 모델을 통해 오프라인 시나리오도 구성할 수 있습니다. 다만 semantic search, inline suggestions, embedding 의존 기능은 GitHub 계정이 필요한 것으로 문서가 구분합니다.
이미지 출처: Visual Studio Code Docs, “AI language models in VS Code”. BYOK와 모델 선택이 별도 개발자 포털이 아니라 VS Code 작업면 안으로 들어왔다는 점을 보여준다.
이 차이는 회사 환경에서 큽니다. 개인 개발자는 “내 키로 더 싼 모델을 써볼까”에 관심이 있지만, 기업은 “누가 어떤 키로 어떤 repo 문맥을 보냈는가”를 봐야 합니다. BYOK가 편해질수록 비용과 데이터 경계도 개인 설정에 흩어질 수 있습니다. AI 코딩 비용이 모델 가격표보다 컨텍스트 관리와 더 강하게 연결된다는 흐름은 AI 코딩 비용을 줄이는 다음 방법: CodeGraph가 말하는 코드 그래프의 역할에서도 이어서 볼 수 있습니다.
왜 중요한가
이번 업데이트의 핵심은 “VS Code 안에 기능이 많아졌다”가 아닙니다. 개발자의 일하는 단위가 바뀌고 있다는 점입니다.
예전의 AI 코딩은 한 파일 옆에서 보조자가 제안을 내는 방식이었습니다. 지금의 에이전트는 저장소를 읽고, 여러 파일을 고치고, 터미널 명령을 실행하고, 브라우저로 결과를 확인합니다. 작업 단위가 커질수록 사람의 역할은 직접 타이핑에서 운영과 검증으로 이동합니다.
그래서 세션 관리가 생산성의 핵심이 됩니다. 어떤 작업을 local folder isolation으로 둘지, 어떤 작업을 worktree isolation으로 분리할지, 어느 세션을 remote machine에서 돌릴지, 어떤 세션은 중간에 멈추고 사람이 diff를 볼지 정해야 합니다. 공식 문서도 worktree isolation이 메인 워크스페이스와 변경을 분리하고, folder isolation은 파일에 직접 변경을 적용한다고 구분합니다.
보안도 같은 이유로 중요해집니다. Agents window는 workspace trust 상태를 메인 VS Code와 공유합니다. 신뢰하지 않은 폴더에서는 agent session을 시작하거나 계속할 수 없지만, 반대로 한 번 신뢰한 폴더에서는 에이전트가 더 넓은 권한으로 움직입니다. remote tunnel이 익명 접근을 허용하면, auto-approval 모드와 결합될 때 외부 사용자가 AI-assisted command execution을 트리거할 수 있다는 경고도 공식 문서에 들어 있습니다.
이 지점은 최근 GitHub 내부 repo 3,800개 유출과 VS Code 확장 보안 경고와 함께 봐야 합니다. 그 사건은 악성 VS Code 확장이 개발자 PC의 토큰과 설정을 훑을 수 있음을 보여줬고, 이번 업데이트는 정상적인 AI 에이전트도 IDE, 터미널, 원격 세션, API 키를 더 깊게 연결한다는 점을 보여줍니다. 편의성이 커진 만큼 관리 표면도 넓어졌습니다.
어떻게 써야 하나
개인 개발자라면 먼저 Agents window를 “큰 작업용 창”으로 분리해 보는 것이 좋습니다. 짧은 질문, 코드 한 줄 설명, 문법 확인은 기존 Chat view가 더 빠릅니다. 반대로 리팩터링, 테스트 보강, 접근성 수정, 마이그레이션처럼 파일이 여러 개 바뀌는 작업은 Agents window가 더 잘 맞습니다.
시작 명령은 단순합니다.
# VS Code에서 전용 에이전트 창 열기
code --agents
# 원격 머신을 브라우저 Agents window에서 쓰려면 터널 실행
code tunnel
VS Code 안에서는 Command Palette에서 Chat: Open Agents Window를 실행할 수 있습니다. 브라우저에서 확인하려면 https://insiders.vscode.dev/agents를 열고, 원격 호스트에서 실행 중인 dev tunnel에 연결하는 흐름입니다.
팀 단위로는 다음 체크리스트부터 정하는 편이 안전합니다.
- 에이전트 작업은 issue, branch, worktree 단위로 이름을 붙인다.
- 위험한 작업은 folder isolation보다 worktree isolation을 기본값으로 둔다.
- BYOK는 개인 키 허용 여부, 허용 provider, 로그·비용 책임자를 먼저 정한다.
- air-gapped BYOK를 쓴다면 GitHub 인증 없이 되는 기능과 안 되는 기능을 문서화한다.
- remote agents는 SSH 또는 인증된 dev tunnel만 허용하고, 익명 tunnel은 금지한다.
- auto-approval은 테스트·lint처럼 반복 명령에 한정하고, 배포·삭제·권한 변경 명령은 수동 승인한다.
- 에이전트가 실행한 명령과 변경 파일은 PR 템플릿이나 리뷰 체크리스트에 남긴다.
BYOK를 쓸 때는 모델 선택을 “성능 취향”으로만 보면 안 됩니다. reasoning effort를 높이면 품질이 올라갈 수 있지만 지연 시간과 비용이 늘 수 있습니다. utility model을 따로 지정하면 commit message나 요약 같은 가벼운 작업에는 싼 모델을 쓰고, 실제 구현 세션에는 더 강한 모델을 쓰는 식의 분리가 가능합니다. 이번 GitHub 공지가 token visibility를 강조한 이유도 여기에 있습니다. 에이전트 작업의 비용은 질문 횟수가 아니라 컨텍스트, 도구 호출, 재시도, 출력 길이에서 나옵니다.
리스크와 한계
이번 업데이트는 preview 기능이 많습니다. Agents window 자체가 preview이고, command risk assessment도 experimental입니다. 즉 회사 표준 워크플로우로 바로 박아 넣기보다는 파일 변경 추적, 터미널 승인, 비용 로그가 실제로 충분한지 작은 팀에서 먼저 확인해야 합니다.
이미지 출처: Visual Studio Code Docs, “Trust and safety”. 에이전트가 터미널 명령을 실행할 때 사용자가 어느 지점에서 권한을 판단해야 하는지 보여준다.
두 번째 리스크는 BYOK의 책임 분산입니다. GitHub 계정 없이도 BYOK chat을 쓸 수 있다는 점은 air-gapped나 로컬 모델 환경에는 장점입니다. 하지만 조직 입장에서는 비용과 데이터 전송 책임이 Copilot 구독 관리 밖으로 빠질 수 있습니다. 개인 키로 연결한 모델이 어느 지역에서 처리되는지, 입력된 저장소 문맥이 provider 정책상 어떻게 보관되는지 확인해야 합니다.
세 번째 리스크는 터미널 명령의 과신입니다. AI가 위험도를 붙인다고 해서 명령이 안전해지는 것은 아닙니다. rm, chmod, git push --force, cloud CLI, database migration, 배포 trigger처럼 외부 상태를 바꾸는 명령은 여전히 사람이 맥락을 봐야 합니다. VS Code의 trust and safety 문서도 AI 생성 출력은 검토가 필요하며, 에이전트가 파일 읽기, 코드 편집, 터미널 명령, 외부 서비스 호출을 할 수 있다고 전제합니다.
마지막으로 remote agents는 연결 편의성과 공격 표면을 동시에 키웁니다. 원격 머신이 켜져 있고 네트워크에서 접근 가능해야 하며, dev tunnel 인증이 약하면 에이전트 세션 자체가 외부 진입점이 됩니다. 특히 자동 승인과 결합하면 “AI가 대신 일한다”가 아니라 “누군가 내 개발 환경에서 AI를 통해 명령을 실행한다”가 될 수 있습니다.
관전 포인트
앞으로 볼 지점은 세 가지입니다.
첫째, AHP가 실제로 얼마나 열릴지입니다. Agent Host Protocol이 여러 클라이언트의 세션 상태 동기화를 위한 open protocol로 자리 잡으면, VS Code 안팎의 에이전트 도구들이 같은 세션 개념을 공유할 수 있습니다. 반대로 Copilot 중심의 제한된 표면으로 남으면, 시장은 또 다른 IDE별 에이전트 섬으로 갈라질 수 있습니다.
둘째, BYOK 비용 관리가 Copilot 사용량 과금과 어떻게 만날지입니다. GitHub는 모델 피커, token visibility, utility model 선택을 넣고 있습니다. 다음 질문은 팀 관리자가 이 데이터를 예산, 보안 정책, 감사 로그로 얼마나 쉽게 묶을 수 있느냐입니다.
셋째, 터미널 위험도 평가가 실제 운영 기준으로 발전할지입니다. 지금은 experimental이지만, 개발 조직이 원하는 것은 “위험해 보입니다”라는 안내문이 아니라 정책입니다. 예를 들어 특정 repo에서는 외부 네트워크 명령 금지, 특정 branch에서는 배포 명령 금지, 특정 명령은 보안팀 승인 필요 같은 규칙이 에이전트 실행 전에 적용되어야 합니다.
결론은 단순합니다. VS Code Copilot의 이번 업데이트는 더 좋은 자동완성 소식이 아닙니다. AI 코딩을 팀의 업무 구조, 비용 구조, 보안 구조 안으로 넣는 업데이트입니다. 이제 중요한 질문은 “AI가 코드를 잘 쓰는가”에서 “어디까지 맡기고, 누가 검증하고, 어떤 비용과 권한으로 실행하게 할 것인가”로 바뀌고 있습니다.
출처와 더 읽을 거리
- GitHub Changelog — GitHub Copilot in Visual Studio Code, May releases: Agents window, remote agents, AHP, air-gapped BYOK, terminal risk assessment 등 이번 글의 직접 근거가 되는 공식 변경 내역이다.
- Visual Studio Code Docs — Use the Agents window: Agents window의 UI 구조, 세션 시작, worktree isolation, remote agents, dev tunnel, 제한 사항을 확인할 수 있는 공식 사용 문서다.
- Visual Studio Code Docs — AI language models in VS Code: BYOK, 모델 피커, 로컬 모델, Copilot Business·Enterprise 정책, GitHub 계정이 필요한 기능 범위를 확인할 수 있는 공식 문서다.
- Visual Studio Code Docs — Trust and safety: 에이전트가 파일·터미널·외부 서비스를 다룰 때 필요한 sandboxing, 승인, 네트워크 제한, AI 한계를 정리한 보안 문서다.
- GitHub Changelog — Expanded technical preview availability for the GitHub Copilot app: Agents window와 별개로 GitHub Copilot App이 parallel sessions, cloud sessions, canvases로 확장되는 흐름을 비교해 볼 수 있는 공식 공지다.
- VS Code 공식 BYOK 블로그 — Expanding Model Choice in VS Code with Bring Your Own Key: BYOK가 왜 VS Code의 모델 선택 전략으로 들어왔는지, Language Model Chat Provider API가 어떤 역할을 하는지 배경을 설명하는 공식 블로그다.