Microsoft Build 2026

01 / 19

오늘은 흩어져 있는 에이전트를 하나하나 들여다보고, 또 하나하나 더 좋게 만드는 이야기를 해보려고 합니다. 핵심은 딱 한 문장이에요. 모든 에이전트를 보고, 모든 에이전트를 개선한다.

02 / 19

Any agent, any cloud: Foundry + OpenTelemetry

안녕하세요, Microsoft Foundry Observability 팀의 Hanchi Wang입니다. 저와 Nagkumar Arkalgud가 함께, 어떤 프레임워크로 만들든 어떤 클라우드에서 돌리든 표준화된 추적을 얻는 방법을 보여드리겠습니다.

03 / 19

오늘 다룰 내용

먼저 간단히 여쭤볼게요. 여러분 중에 에이전트를 만들거나 운영하시는 분들, 손 한번 들어주시겠어요? 그리고 그 에이전트가 전부 같은 언어, 같은 프레임워크, 같은 클라우드에서 돌아가는 분들만 손을 그대로 들고 계세요. 대부분 손이 내려가시죠. 오늘은 바로 그 파편화된 텔레메트리 문제를, Foundry와 OpenTelemetry 표준으로 어떻게 하나로 묶는지 데모로 풀어가겠습니다.

04 / 19

현실은 멀티 프레임워크, 멀티 클라우드

실제 현장은 이렇습니다. 어떤 팀은 반복이 빠른 Foundry Prompt Agent를 쓰고, 백엔드 팀은 익숙한 LangGraph를, 또 어떤 팀은 이미 Gemini를 쓰니까 Google ADK를 고르죠. 그러다 보면 Azure, AWS, GCP, GitHub에 프레임워크도 대시보드도 제각각인 에이전트가 흩어집니다. 그러다 프로덕션에서 첫 오답이 나오면, 임원은 물어봐요. 어느 에이전트가 그랬고, 왜 그랬고, 앞으로 어떻게 막을 거냐고요.

05 / 19

한 곳에서 답하기 — Foundry Observability

그 질문들에 한 곳에서 답하는 방법을 보여드리겠습니다. 모든 에이전트를 하나의 프레임워크, 하나의 클라우드로 다시 쓰는 게 아니라, 기존 로직은 그대로 두고 코드 몇 줄로 OpenTelemetry만 붙이는 거예요. 오늘 보여드리는 기능은 전부 Foundry에서 실제로 동작하고, 마지막에 공유할 저장소로 그대로 재현하실 수 있습니다.

06 / 19

복잡한 멀티 에이전트로 가기 전에 간단한 것부터 시작하죠. 제가 자란 시안은 중국의 유명한 관광지인데, 친구들이 여행 추천을 자주 물어봐서 시안 여행 전문가 에이전트를 만들었어요. 코드가 필요 없는 Foundry Prompt Agent에 여행 노트 PDF를 올리고 시스템 프롬프트만 넣으니 몇 분 만에 완성됐습니다. '2명이서 3일, 역사와 음식 중심으로' 이렇게 물으면 상세한 일정을 돌려주죠. 더 흥미로운 건, Foundry가 이 동작을 OpenTelemetry 트레이스로 자동으로 남긴다는 겁니다. invoke-agent 스팬 아래로 여행 노트를 가져오는 툴 실행, 즉 전형적인 RAG 패턴이 보이고, 이어서 LLM 호출까지 지연 시간과 토큰 사용량을 그대로 확인하고 대화를 재생해 볼 수 있어요.

07 / 19

그럼 이건 Foundry 네이티브 에이전트에서만 되는 걸까요? 다른 곳에서 도는 에이전트도 똑같은 관측 경험을 얻을 수 있는지, 이제 동료 Nagkumar와 함께 멀티 에이전트, 멀티 클라우드 구성으로 넘어가 보겠습니다.

08 / 19

하나로 이어지는 엔드투엔드 트레이스

아키텍처를 보시면, 사용자는 Foundry의 오케스트레이터와 대화하고, 오케스트레이터는 도시별로 알맞은 전문가 에이전트에게 넘겨줍니다. 이 전문가들은 각각 다른 프레임워크와 클라우드에서 돌아가지만, 모두 GenAI 규약을 따르는 OpenTelemetry 트레이스를 내보내기 때문에 Foundry가 이걸 하나의 통합 트레이스로 꿰어줍니다. 여러 클라우드에 걸쳐 있는데도 하나의 시스템처럼 느껴지는 이유가 바로 이겁니다.

09 / 19

Microsoft Agent Platform

이걸 큰 그림에서 보면 이렇습니다. 개발자가 일하는 GitHub에서 코드, 프롬프트, 스킬, 평가 정의를 만들고, Foundry에서 실행하면서 여러분의 데이터 즉 IQ로 그라운딩하고 최적화합니다. 이 모든 걸 Azure가 글로벌 규모로 떠받치고, Agent 365와 Entra, Purview로 거버넌스를 채우죠. 그리고 완성된 에이전트는 클릭 한 번으로 M365, Teams, M365 Copilot의 사용자에게 배포됩니다.

10 / 19

플랫폼이 맞물려 돌아가는 방식

Microsoft가 특별한 건, 이 조각들을 따로따로가 아니라 서로 맞물려 돌아가는 하나의 시스템으로 엮어낸다는 점입니다. 개발부터 실행, 거버넌스, 배포까지 자연스럽게 이어지죠.

11 / 19

로그를 넘어, 트레이스로

그리고 에이전트를 제대로 이해하려면 단순한 로그만으로는 부족합니다. 어떤 판단을 거쳐 그 답이 나왔는지 흐름을 보여주는 트레이스가 필요하죠.

12 / 19

지속적인 학습 루프

에이전트는 한번 만들고 끝나는 게 아니라 계속 배워야 합니다. 요청을 처리할수록 알맞은 트레이스와 데이터가 다시 학습 루프로 흘러 들어가, 에이전트도 사람도 함께 나아지게 만드는 거죠.

13 / 19

이제 세 클라우드를 다 봤으니, 이게 프로덕션에서 왜 중요한지 이야기해 보겠습니다. 트레이스를 한곳에서 보는 것도 좋지만 진짜 가치는 운영에 있어요. 라우팅이 맞는 전문가를 골랐는지, 검색이 약한 컨텍스트를 준 건 아닌지, 지연이 콜드 스타트인지 네트워크인지 모델 때문인지를 빠르게 답할 수 있어야 하죠. 그래서 루프는 단순합니다. 에이전트 코드에 OpenTelemetry를 붙이고, 실제 트래픽으로 디버깅하고 평가하고 최적화하고, 플릿 단위 가시성으로 대규모까지 관리하는 겁니다.

14 / 19

여기서 끝이 아닙니다

시간 관계상 다 못 보여드리지만, 나중에 꼭 확인해 보실 기능들이 더 있습니다. 여러분의 에이전트에 맞춰 평가 계획을 만들어 주는 Rubric evaluator, 프롬프트나 모델, 툴을 바꿔가며 자동으로 개선하는 Agent optimization, 그리고 Agent 365 관측 네이티브 지원이요. 또 OpenTelemetry의 GenAI 규약을 권장하지만, 이미 다른 형식을 쓰신다면 갈아타기 쉽지 않다는 걸 알기에 OpenInference와 OpenLLMetry도 함께 지원합니다.

15 / 19

이 주제를 더 깊게 파고 싶으시면 Build 기간에 관련 세션이 여럿 준비돼 있습니다. 6월 2일과 3일에 걸쳐, ROI 관점의 관측부터 오픈소스 에이전트 거버넌스, 핸즈온 랩, 프로토타입에서 프로덕션까지, Agent 365, 그리고 Azure Monitor 연동까지 이어지니 관심 가는 세션을 챙겨 보세요.

16 / 19

여정의 모든 단계를 함께합니다

여러분의 여정을 처음부터 끝까지 함께하겠습니다. ai.azure.com에서 Microsoft Foundry로 바로 시작하실 수 있고, 오늘 세션 코드는 aka.ms/build26-DEM341에서 받으실 수 있어요. 그리고 aka.ms/ai/discord로 커뮤니티에도 꼭 합류해 주세요.

17 / 19

감사합니다

코드 저장소는 이 링크나 QR 코드로 바로 받으실 수 있습니다. 저희가 Foundry로 제공하는 관측 경험의 넓이와 깊이가 정말 자랑스러운데요, 원하는 대로 만들고, 필요한 곳에서 실행하고, 그 모두를 한 화면에서 관측하세요. 어떤 에이전트든, 어떤 클라우드든, 하나의 관측 화면으로. 감사합니다.

18 / 19

세션 진행 구성 (내부용)

여기서부터는 발표 진행을 위한 내부용 정리입니다. 인트로와 프레이밍 5분, 관측이 기본 탑재된 새 에이전트를 만드는 1막, 프로덕션에서 쌓인 신호로 평가하고 최적화해 새 기준선을 만드는 2막, 그리고 Agent optimizer로 대규모까지 끌어올리는 3막으로 흐름을 잡아두었습니다.

19 / 19

어떤 에이전트든, 어떤 클라우드든 하나의 관측 화면에서