이번 업데이트에서 실제로 달라진 것

v0.32.0의 가장 눈에 띄는 변화는 사이드바 통합입니다. 기존에는 AI Toolkit과 Microsoft Foundry 확장을 따로 관리해야 했는데, 이번 버전부터 Foundry 사이드바 패널이 AI Toolkit의 My Resources 뷰로 합쳐졌습니다. 로컬 리소스(모델·에이전트·툴)와 Foundry 원격 리소스가 하나의 트리에서 보입니다.
공식 블로그에 따르면, Foundry 사이드바는 2026년 6월 1일부로 완전히 종료됩니다(출처: Microsoft Tech Community, 2026.03.17). 지금 Foundry 확장을 사이드바 중심으로 쓰고 있다면 6월 전에 AI Toolkit 기반으로 워크플로를 옮겨둬야 합니다.

두 번째 변화는 Create Agent 뷰의 신설입니다. 이전까지는 에이전트를 만들려면 각 기능을 따로 찾아야 했는데, 이제 하나의 진입점에서 “코드 기반 생성”과 “노코드 UI 기반 생성” 중 하나를 선택할 수 있습니다. 세 번째는 Agent Builder 자체에 여러 개선이 들어온 것인데, 이 중 MCP Tool Approval이 이번 포스팅에서 가장 주목해야 할 기능입니다. 이유는 뒤에서 설명합니다.

▲ 목차로 돌아가기

Agent Builder, 노코드 경로의 진짜 범위

공식 문서(code.visualstudio.com/docs/intelligentapps/agentbuilder)에는 “코드 없이 에이전트를 만들 수 있다”고 나와 있습니다. 실제로 노코드 경로에서 할 수 있는 건 프롬프트 에이전트(Prompt Agent) 생성입니다. 시스템 프롬프트를 작성하고 MCP 툴을 연결하고 응답을 테스트하는 과정은 UI만으로 가능합니다.

하지만 코드 기반 Hosted Agent를 만들려면 얘기가 달라집니다. Python 또는 TypeScript로 에이전트 코드를 작성해야 하고, Azure AI Foundry SDK를 다뤄야 하며, GitHub Copilot을 통한 코드 생성을 이용하더라도 최소한의 코딩 맥락은 필요합니다. 공식 문서에 명시된 대로, 코드 기반 경로에서는 Node.js 또는 Python 환경이 반드시 설치돼 있어야 하고, MCP 서버를 직접 scaffold할 때는 npm install -g npx 또는 Python의 uv가 필요합니다.

정리하면 이렇습니다. 기존 MCP 서버를 연결해서 프롬프트 에이전트를 만드는 것까지는 노코드입니다. MCP 서버를 직접 만들거나 배포 가능한 에이전트를 코드로 제어하는 건 노코드가 아닙니다. 이 차이를 처음부터 알고 시작해야 헛시간을 줄일 수 있습니다.

▲ 출처: VS Code 공식 문서(code.visualstudio.com/docs/intelligentapps), 2026.03 기준

▲ 목차로 돌아가기

MCP Tool Approval — 보안 사고 이후 나온 기능

이번 업데이트에서 MCP Tool Approval이 추가됐습니다. 공식 발표에는 “에이전트 실행 중 MCP 툴 호출에 대해 자동 승인 또는 수동 승인을 설정할 수 있다”고 나와 있습니다(출처: Microsoft Tech Community, March 2026 Update). 대부분의 리뷰가 이걸 단순 편의 기능으로 소개하는데, 실제로는 좀 다른 맥락이 있습니다.

MCP가 가진 구조적 위험 중 하나는 “툴 설명이 사용자 승인 이후에도 변경될 수 있다”는 점입니다. AI가 특정 툴이 “A를 한다”고 인식하고 승인했더라도, 악성 MCP 서버가 나중에 툴 설명을 바꿔 “B를 시키는” 상황이 실제로 발생했습니다. 보안 연구자들은 이를 ‘rug pull’이라고 부릅니다. Tool Approval의 수동 승인 모드를 켜두면 이런 상황에서 AI가 툴을 자동으로 호출하는 것을 막을 수 있습니다.

Tool Approval 설정 방법은 간단합니다. Agent Builder 실행 후 MCP 툴 설정 영역에서 Auto 또는 Manual을 선택하면 됩니다. 개발 단계에서는 Auto로 두고 빠르게 테스트하다가, 외부 API나 DB에 접근하는 툴이 포함되면 Manual로 전환하는 게 현실적인 운영 방식입니다.

▲ 목차로 돌아가기

Extension Host 충돌 — 노코드가 막히는 딱 한 지점

MCP 서버를 scaffold하고 Agent Builder에서 F5로 디버그를 시작했더니, VS Code 자체가 멈추는 경험을 한 개발자 보고가 나왔습니다. Visual Studio Magazine의 실사용 리포트(2026.03.10)에서 이 문제가 구체적으로 기록됐습니다. 원인은 VS Code의 단일 Extension Host 프로세스 아키텍처에 있습니다.

VS Code는 모든 확장을 하나의 프로세스(extension host)에서 실행합니다. Agent Builder가 모델 엔드포인트에 연결을 시도하다 타임아웃되면, 이 프로세스 전체가 블로킹됩니다. GitHub Copilot을 포함한 다른 모든 확장이 함께 응답을 멈춥니다. 이 증상은 “Agent Builder 패널에 스피너만 뜨고 Copilot이 침묵하는” 형태로 나타납니다.

중요한 건, Agent Builder 자체와 MCP 서버 기능은 별개라는 점입니다. MCP 서버가 실제로 작동하는지 확인할 때는 Agent Builder 대신 MCP Inspector(브라우저 기반 JSON 인터페이스)를 쓰는 게 더 안정적입니다. 서버가 정상 동작하는 걸 MCP Inspector로 먼저 확인한 뒤, Copilot Chat의 mcp.json에 등록해서 사용하면 Agent Builder 없이도 동일한 기능을 씁니다.

▲ 목차로 돌아가기

GitHub Copilot 통합과 Foundry 사이드바 종료 예고

v0.32.0에서 또 하나의 큰 변화는 GitHub Copilot과의 통합 강화입니다. Create Agent 뷰에서 “코드 기반 에이전트 생성” 경로를 선택하면, Copilot이 템플릿 기반으로 에이전트 코드를 생성해줍니다. 에이전트 평가와 배포에도 동일한 Microsoft foundry skill을 씁니다. 공식 블로그 표현대로 “GitHub Copilot for Azure에서 쓰는 것과 같은 소스”를 사용하며, AI Toolkit이 이 skill을 자동으로 설치·업데이트합니다.

실용적으로 이걸 어떻게 활용하냐 하면, 기존에는 새 에이전트 프로젝트를 시작할 때 boilerplate 코드를 직접 짜야 했는데, 이제는 Create Agent 뷰에서 “Scaffold a project” 또는 “Generate a multi-agent workflow”를 선택하면 Copilot이 구조를 만들어 줍니다. 실제로 사용해 보면 시작점은 편하지만, 생성된 코드가 Azure AI Foundry SDK에 강하게 의존하기 때문에 다른 클라우드 환경으로 포팅할 때는 수작업이 필요합니다.

Foundry 사이드바 종료 일정은 놓치기 쉬운 부분입니다. 2026년 6월 1일부로 Foundry 확장의 독립 사이드바가 사라집니다(출처: Microsoft Tech Community, March 2026 Update). 기능 자체는 AI Toolkit 사이드바로 통합됐으니 기능 손실은 없지만, 지금 Foundry 사이드바를 기반으로 자동화 스크립트나 내부 가이드를 만들어 두셨다면 정리가 필요합니다.

▲ 목차로 돌아가기

직접 검증 가능한 수치 3가지

① MCP 툴 스키마 1개당 평균 200 토큰 소비

MCP 서버에 연결하면 해당 서버가 제공하는 모든 툴의 스키마가 LLM 컨텍스트 윈도우에 올라갑니다. 툴 1개당 평균 약 200 토큰이 소비됩니다(출처: andrewbaker.ninja, MCP 분석 리포트, 2026.03). GitHub나 Notion 같은 중간 규모 MCP 서버는 40개 안팎의 툴을 제공하므로, 연결 직후 약 8,000 토큰이 컨텍스트에 차 있는 상태로 시작합니다. MCP 서버 3개를 동시에 연결하면 작업 시작 전에 이미 20,000~30,000 토큰이 소모됩니다. 컨텍스트 비용이 오르고 실제 추론에 쓰일 공간이 줄어드는 직접적인 원인입니다.

② GPT-5.4 mini, AI Toolkit에서 쓰면 Codex 할당량의 30%만 차감

OpenAI 공식 발표(2026.03.17) 기준, Codex 환경에서 GPT-5.4 mini를 사용하면 GPT-5.4 전체 모델 할당량의 30%만 차감됩니다(출처: Reddit r/codex, OpenAI 공식 할당량 페이지). AI Toolkit 0.32.0은 Model Catalog에 GPT-5.4 mini를 지원합니다. 반복 코딩 작업이 많은 워크플로에서는 GPT-5.4 대신 mini를 쓰는 것만으로 동일 예산에서 약 3배 더 많은 요청이 가능합니다.

③ UTCP, MCP 대비 복잡한 워크플로에서 네트워크 왕복 88% 감소

MCP의 경쟁 프로토콜인 UTCP(Universal Tool Calling Protocol)의 독립 벤치마크에 따르면, 복잡한 멀티스텝 워크플로에서 MCP 대비 실행 속도 60% 향상, 토큰 68% 절감, 네트워크 왕복 88% 감소가 확인됐습니다(출처: UTCP 팀 공식 발표, 2026.01). Tool Approval 기능이 추가된 건 MCP의 보안 문제를 완화하는 데 도움이 되지만, MCP의 구조적 성능 오버헤드 자체는 Tool Approval로 해결되지 않습니다. 프로덕션 환경에서 레이턴시가 중요하다면, AI Toolkit의 모델 연결에 MCP를 쓸지 네이티브 Function Calling을 쓸지 실측이 필요합니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

VS Code AI Toolkit 0.32.0은 분명 이전보다 편해졌습니다. 사이드바가 통합됐고, 에이전트 진입점이 명확해졌으며, MCP Tool Approval이 생겼습니다. 그런데 “노코드로 에이전트 만든다”는 말을 그대로 믿고 시작하면 금방 막힙니다. 노코드가 가능한 범위는 프롬프트 에이전트 수준에서 멈추고, MCP 서버를 직접 만들거나 Hosted Agent를 배포하는 순간 코딩 영역으로 들어갑니다.

Tool Approval 기능은 편의 기능이 아닙니다. 2025년에 실제로 터진 MCP 보안 사고들의 흐름을 같이 보면, 이건 사실상 필수 통제 장치로 봐야 합니다. 외부에서 가져온 MCP 서버를 Auto로 두는 건 신뢰도 확인 없이 npm 패키지를 설치하고 sudo로 실행하는 것과 비슷한 위험을 갖습니다.

Agent Builder의 Extension Host 충돌 문제는 아직 해결되지 않았습니다. 하지만 이걸 우회하는 방법이 있고, MCP 서버 자체는 독립적으로 잘 작동합니다. 막혔을 때 당황하지 말고 MCP Inspector로 돌아가면 됩니다. 솔직히 말하면, 지금 단계에서 AI Toolkit의 가장 안정적인 사용 흐름은 Agent Builder보다 Copilot Chat + mcp.json 직접 연결 방식입니다.

📚 본 포스팅 참고 자료

1. AI Toolkit for VS Code — March 2026 Update (Microsoft Tech Community, 2026.03.17)
2. Build agents and prompts in AI Toolkit — VS Code 공식 문서
3. AI Toolkit for Visual Studio Code — VS Code Marketplace
4. Hands On: Building an MCP Server with VS Code AI Toolkit’s New Tool Catalog (Visual Studio Magazine, 2026.03.10)
5. The Rise and Relative Fall of MCP: What Every AI User Needs to Know in 2026 (andrewbaker.ninja, 2026.03.22)