2026년 6월 Foundry 물결은 또 다른 월간 다이제스트가 아닙니다. “멋진 에이전트 구축"에서 “통치된 엔터프라이즈 시스템으로 에이전트 운영"으로의 성숙 전환을 표시합니다. 그 구분은 어떤 단일 기능보다 중요합니다.
원문: https://devblogs.microsoft.com/foundry/whats-new-in-microsoft-foundry-june-2026/
세 가지 업데이트가 전환을 정의합니다. 첫째, Microsoft 365 Copilot 및 Teams로의 에이전트 게시가 GA에 도달하여 배포를 사용자 정의 통합 프로젝트에서 의견이 반영된 배포 레인으로 이동시킵니다. 둘째, Toolboxes는 도구 검색 및 루틴을 포함한 더 강력한 발견 및 실행 제어를 얻었습니다. 셋째, 관찰 가능성과 최적화가 사후 고려가 아닌 의도적인 폐쇄 루프가 되었습니다.
내 의견: 이것이 릴리스에서 가장 중요한 패턴입니다. 추적, 평가, 최적화, 통제된 롤아웃은 비결정론적 시스템을 위한 최소 실행 가능 운영 모델을 형성합니다. 그 조각 중 하나만 가지고 있다면, 텔레메트리나 튜닝은 있지만 거버넌스는 없는 것입니다.
Foundry 내부의 Claude GA도 전략적이지만, 주로 모델 품질 때문은 아닙니다. 더 큰 가치는 엔터프라이즈 통합입니다: Entra 인증, RBAC, 청구 연속성, 정책 정렬. 직접 모델 엔드포인트에서 Foundry로 이동하는 팀은 이를 공급자 교체가 아닌 운영 통합으로 프레임해야 합니다.
Autopilot 에이전트는 유망하지만, 조직은 냉정한 아키텍처 선택으로 접근해야 합니다. Teams의 공유 공간 협업은 생산성을 잠금 해제할 수 있지만, 아이덴티티, 권한, 책임 복잡성을 빠르게 높입니다. 광범위한 배포 전에 범위 제한과 엄격한 승인 체크포인트로 시작하세요.
실용적 권장사항:
- 이미 파일럿 중이라면, 기능 확장보다 계측을 우선시하세요. 먼저 GenAI 추적을 연결하세요. 그런 다음 일반 모델 메트릭이 아닌 비즈니스 결과에 연결된 평가자 스위트를 구축하세요. 그 후에야 최적화 루프와 프로모션 워크플로를 실행해야 합니다.
- Toolbox 중심 에이전트의 경우, 카탈로그가 성장함에 따라 컨텍스트 노이즈와 잘못된 도구 선택 위험을 줄이기 위해 일찍 도구 검색을 활성화하세요.
- 메모리 사용 에이전트의 경우, TTL 및 보존 정책을 사전에 정의하세요. 수명 주기 제어 없는 메모리는 규정 준수 부채가 됩니다.
제가 내릴 수 있는 가장 독단적인 결론은 이것입니다: Foundry는 이제 “어떤 모델을 선택할까?“보다는 “에이전트 행동을 관리형 수명 주기로 실행할 수 있을까?” 에 더 가깝습니다. 두 번째 질문에 잘 대답하는 팀은 모델 변동에 쉽게 적응할 것입니다. 모델 순위에 고정된 팀은 매 분기마다 취약한 스택을 계속 재구축할 것입니다.
6월의 릴리스는 한 가지를 명확히 합니다. Foundry는 AI 시스템을 위한 운영 플랫폼이 되고 있으며, 단지 개발 툴킷이 아닙니다. 구축하기 더 어려운 제품이며, 채택하기에는 훨씬 더 가치 있는 제품입니다.
