데모와 운영 사이
에이전트 데모는 만들기 쉽습니다. 노트북에서 프레임워크 하나 설치하고, 도구 몇 개 붙이고, 모델을 부르면 됩니다.
운영은 다릅니다. 사용자마다 격리된 실행 환경이 필요하고, 도구가 늘어날수록 연결 관리가 복잡해집니다. 어제 대화를 기억해야 하고, 모델을 바꿨을 때 품질이 떨어지지 않았는지 알아야 합니다.
Build 2026의 Foundry 발표는 거의 전부가 이 빈칸에 관한 것이었습니다.
세션마다 샌드박스: Hosted agents
Foundry 블로그에 따르면 Hosted agents에서는 세션마다 전용 컴퓨트, 메모리, 파일 시스템을 가진 샌드박스가 할당됩니다.
코드를 실행하거나 파일을 다루는 에이전트라면 이게 필수입니다. 사용자 A의 세션에서 만든 파일이 사용자 B의 세션에 보이면 안 되니까요. 지금까지는 컨테이너를 세션마다 띄우는 장치를 직접 만들어야 했습니다.
Responses API와 Invocations 프로토콜도 지원합니다. 발표 당시 상태는 "7월 초 정식 출시 예정"이었습니다.
프레임워크가 안정 버전이 됐다
Microsoft Agent Framework에서 안정 버전이 된 구성 요소는 세 가지입니다.
- 스킬·메모리·미들웨어를 갖춘 에이전트 하네스
- GitHub Copilot SDK와 Claude Agent SDK 연동
- Magentic-One을 포함한 다중 에이전트 오케스트레이션
Claude Agent SDK와의 연동이 안정 범위에 들어갔다는 점이 흥미롭습니다. 마이크로소프트가 자기 프레임워크 안에서 다른 회사의 에이전트 SDK를 정식으로 받아들인 겁니다. 파일 시스템 도구, 메모리 도구, 딥 리서치 에이전트는 아직 공개 프리뷰입니다.
도구를 한 엔드포인트로: Toolboxes
Toolboxes는 공개 프리뷰입니다. 블로그는 이를 "모든 종류의 도구를 위한 하나의 관리형 엔드포인트"라고 설명합니다.
에이전트가 쓰는 도구가 MCP 서버, REST API, 함수, 검색 인덱스로 흩어져 있으면 연결 설정과 인증이 도구마다 따로 놉니다. 하나의 엔드포인트로 묶으면 에이전트 쪽 코드는 단순해지고, 접근 통제도 한곳에서 할 수 있습니다. 스킬과 도구 검색도 프리뷰로 함께 나왔습니다.
메모리는 세 종류
메모리는 공개 프리뷰이고, 세 가지로 나뉩니다.
| 종류 | 기억하는 것 |
|---|---|
| 절차 메모리 | 일을 어떻게 했는지, 무엇이 통했는지 |
| 사용자 메모리 | 사용자의 선호와 정보 |
| 세션 메모리 | 지금 대화의 맥락 |
절차 메모리에 대한 초기 수치가 있습니다. Tau-bench에서 기준선에 가까운 비용으로 성공률이 7~14%p 올랐다고 합니다. 같은 실수를 반복하지 않는 것만으로 성공률이 오른다는 뜻으로 읽힙니다. 다만 초기 결과이고, 벤치마크와 실제 업무는 다를 수 있습니다.
품질을 재는 도구들
평가 쪽 발표도 셋입니다.
- Rubric 평가기(공개 프리뷰): 에이전트의 맥락에 맞춰 평가 기준을 자동으로 만듭니다.
- Agent Optimizer(곧 공개 프리뷰): Foundry의 평가 도구를 운영 서비스 안에서 바로 돌립니다.
- 다른 프레임워크 추적·평가(공개 프리뷰): LangChain 등으로 만든 에이전트에도 Foundry의 추적과 평가를 붙입니다.
Rubric 평가기가 특히 실용적으로 보입니다. 에이전트 평가에서 가장 시간이 드는 일은 "좋은 답이 무엇인가"를 정하는 일입니다. 이 기준의 초안을 자동으로 만들어 준다면, 사람은 검토와 수정에 집중할 수 있습니다.
마지막 단계: 사용자 앞에 내놓기
Foundry에서 만든 에이전트를 Teams와 Microsoft 365 Copilot에 바로 게시하는 기능은 6월 정식 출시 예정이었습니다.
직원들이 이미 쓰는 도구 안으로 에이전트를 넣는다는 점에서, 마이크로소프트가 가장 강한 부분입니다. 별도 웹 앱을 만들어 사람들에게 쓰라고 권하는 것보다 도입이 훨씬 쉽습니다.
남는 질문
발표를 다 읽고 나면 질문 하나가 남습니다. 이 기능들을 쓰려면 얼마나 Foundry에 묶여야 하는가.
다른 프레임워크로 만든 에이전트도 추적하고 평가할 수 있다는 점은 좋은 신호입니다. 하지만 Hosted agents, Toolboxes, 메모리를 함께 쓰면 자연스럽게 Foundry 중심 구조가 됩니다. 에이전트 코드는 프레임워크 중립으로 두고, 실행 환경만 Foundry를 쓰는 식으로 경계를 정해 두는 편이 나중에 덜 아플 것 같습니다.
