Microsoft가 엔터프라이즈 규모에서 AI 에이전트를 출시하는 방법 Marco Casalaina, Microsoft Core AI 제품 부사장 인터뷰
개요
Microsoft는 엄청난 규모로 운영 중이다. 현재 80,000개 이상의 기업이 Microsoft Foundry — AI 에이전트와 애플리케이션을 구축, 배포, 실행하는 플랫폼 — 위에서 개발하고 있다. Microsoft 자체 코파일럿도 동일한 플랫폼에서 실행되며, Microsoft 365 Copilot 단독으로도 2천만 명 이상의 사용자에게 서비스되고 있고 자체 에이전트의 월간 활성 사용률은 연초 대비 6배 성장했다.
이 규모에서 에이전트를 실제로 출시하는 것이 어떤 것인지 이해하기 위해, 우리는 Marco Casalaina과 이야기를 나눴다. 그는 이 시스템을 프로덕션에서 운영하면서 팀이 배운 것, 그로 인한 엔지니어링 과제, 그리고 엔터프라이즈 AI의 방향에 대해 설명했다.
이 글에서 배울 수 있는 것들:
- 프로토타입 에이전트가 프로덕션에서 살아남지 못하는 이유
- 프로덕션 에이전트 하네스(harness)에 들어가는 것, 그리고 Microsoft가 컨텍스트를 핵심으로 보는 이유
- Foundry를 뒷받침하는 두 가지 엔지니어링 아이디어: 서브에이전트로서의 검색, 그리고 에이전트에게 자체 정체성과 행동 공간 부여
- Microsoft가 루브릭 기반 평가와 자동 개선 루프로 프로덕션 에이전트를 평가하는 방법
- 다른 팀을 위한 교훈과 다음 방향
에이전트가 프로덕션에 도달했을 때 무엇이 망가지는가
프로덕션 에이전트는 프로토타입에서는 보이지 않는 이유로 실패한다. 모델은 거의 문제가 되지 않는다. 망가지는 것은 모델 주변의 모든 것 — 에이전트가 검색하는 데이터, 호출하는 도구, 실제 사용자를 처리하는 방식, 주변 세계가 변화함에 따라 품질이 저하되는 방식이다.
Marco는 이 전환을 이렇게 표현했다:
"우리는 AI의 질의응답 단계를 벗어나고 있습니다. 2026년에는 음성을 프론트엔드로 사용하는 고객의 수가 크게 증가하고 있어, 챗봇 시대도 벗어나고 있습니다."
과거의 형태는 챗봇이었다. 사용자가 타이핑하면 에이전트가 타이핑으로 답하고, 질문에만 답할 수 있었다. 새로운 형태는 사용자를 대신해 의미 있는 작업을 수행하는 에이전트다. 회의를 예약하고, 분석을 실행하고, 이메일을 보내고, 티켓을 제출한다. 프론트엔드가 음성일 수 있기 때문에 사용자가 아예 타이핑하지 않을 수도 있다.
이 전환이 엔지니어링 문제를 다르게 만든다. 챗봇이 틀린 답을 반환하는 것은 나쁜 경험이다. 에이전트가 잘못된 행동을 취하는 것은 비즈니스 사고다. "출시할 수 있는" 수준의 기준이 이동했다.
첫 번째 프로토타입은 쉽다. 오후에 vibe-coding으로 만들 수 있다. 모델은 똑똑하고, 테스트 프롬프트가 작동하며, 데모는 인상적이고, 파일럿이 일주일 만에 출시된다.
프로덕션에서 균열이 생긴다. 실제 사용자들은 예상하지 못한 것들을 질문한다. 에이전트가 의존하는 문서들이 오래된다. 평가 데이터셋에서 한 번도 나타나지 않았던 새로운 엣지 케이스가 등장한다. 모델 업데이트가 에이전트의 동작을 미묘하게 변경하는데, 고객이 불만을 제기하기 전까지 아무도 알아채지 못한다. 정체성 통제 없이는 에이전트가 공유 시스템 주체로 실행되며 무언가 잘못됐을 때 감사 추적이 없다. 가드레일 없이는 해서는 안 되는 말을 자신 있게 한다. 관측 가능성 없이는 품질이 개선되고 있는지 악화되고 있는지 알 수 없다.
Marco가 공유한 핵심 교훈: "하네스가 모델만큼 중요하다."
프로덕션 에이전트 하네스에 들어가는 것
1. 추론 레이어 (Inference Layer)
하네스가 모델에 접근하는 단일 인터페이스다. 모델 자체는 하네스 외부에 있고 교체 가능하다. Foundry는 OpenAI, Anthropic, xAI, DeepSeek, Microsoft의 MAI 패밀리 등 11,000개 이상의 모델을 지원한다.
2. 에이전트 런타임 (Agent Runtime)
오케스트레이션 루프, 도구 호출, 대화 상태, 프로토콜을 처리해 모델을 에이전트로 만든다. 루프의 모든 단계가 모델을 거쳐야 하는 건 아니다. 데이터베이스 조회나 전용 추출 모델은 모델에게 같은 작업을 요청하는 것보다 더 빠르고, 저렴하며, 신뢰할 수 있다.
3. 관측 가능성 및 거버넌스 레이어
에이전트가 프로덕션에 들어가면 조직은 모든 프로젝트에서 실행 중인 모든 에이전트를 단일 뷰로 볼 수 있어야 한다: 상태 점수, 토큰 사용량, 지연 지표, 드리프트 감지. 이 레이어 없이는 회귀가 보이지 않고 비용이 통제되지 않는다. Microsoft의 경우 Foundry Control Plane이 이 역할을 한다.
4. 정체성 레이어 (Identity Layer)
에이전트가 조직 내에서 실제 행동을 취하기 시작하면 자체 정체성이 필요하다. 오동작하는 에이전트는 오동작하는 직원과 동일한 접근 제어로 제한돼야 한다. Microsoft는 Entra(기업 정체성 플랫폼)를 확장해 에이전트를 새로운 주체 클래스로 처우한다.
5. 컨텍스트 레이어 (Context Layer)
다른 레이어들이 에이전트가 실행될 수 있게 하는 반면, 컨텍스트는 올바르게 실행될 수 있게 한다. 컨텍스트 없는 에이전트는 환각을 일으킬 수 있다. 무언가 대답하겠지만 잘못된 방식으로, 그리고 에이전트 자신도 모르고 있는 방식으로. Marco는 에이전트에게 실제로 작동하는 데 필요한 컨텍스트를 제공하는 것이 팀이 해결하고 있는 가장 어려운 문제 중 하나라고 명시했다.
에이전트를 위한 컨텍스트 레이어 구축
컨텍스트가 어디에나 있다는 것이 어려운 점이 아니다. 엔터프라이즈는 엄청난 양의 컨텍스트를 보유하고 있다. 어려운 점은 컨텍스트가 어디에나 있다는 것이다 — SharePoint와 위키의 비정형 문서, OneLake와 데이터 웨어하우스의 정형 테이블, Outlook/Teams/Word 같은 생산성 앱. 어떤 단일 검색 방법도 이 모두에 도달할 수 없다.
지난 2년간의 표준 답인 클래식 RAG는 그렇게 설계되지 않았다. 클래식 RAG는 원샷 패턴이다. 사용자 질문을 가져와 임베딩하고, 단일 인덱스를 검색하고, 상위 k 결과를 반환하고, 모델에 전달한다. 질문이 모호하거나, 코퍼스가 이질적이거나, 올바른 답이 소스를 결합해야 하거나, 첫 번째 검색이 빈 결과를 반환하면 실패한다. RAG가 잘 작동하지 않으면 전체 에이전트가 잘 작동하지 않는다.
해결책은 검색을 시스템이 반복할 수 있는 것으로 처우하는 것이다 — 에이전트가 작업을 반복하는 것과 같은 방식으로. 쿼리를 계획하고, 소스를 시도하고, 결과를 평가하고, 첫 번째가 빈 결과를 반환하면 다른 소스를 시도하고, 발견한 것을 결합한다.
Microsoft의 답은 컨텍스트 레이어 자체를 서비스 집합으로 출시하는 것이다 — Microsoft IQ:
- Foundry IQ: 비정형 데이터
- Fabric IQ: 정형 데이터 (OneLake)
- Web IQ: 실시간 웹 검색
- Work IQ: Microsoft 365 생산성 표면 (이메일, 캘린더, 문서, Teams)
각 IQ는 에이전트가 MCP를 통해 호출하는 헤드리스 서비스다.
서브에이전트로서의 검색 (Retrieval-as-a-Subagent)
프로덕션 컨텍스트 레이어의 기술적 아이디어는 검색을 에이전틱 루프로 래핑하는 것이다. 하나의 인덱스에 대해 하나의 쿼리를 실행하고 상위 k를 반환하는 단일 함수 호출 대신, 검색 자체가 소형 에이전트가 된다. 어떤 소스를 쿼리할지 계획하고, 쿼리를 실행하고, 원래 질문에 대한 결과를 평가하고, 반환할지 쿼리를 정제할지 다른 소스를 시도할지 결정한다.
Foundry IQ에서 특히 주목할 점: 반복이 소진되면 답변을 강요하는 대신 구조화된 "모릅니다"를 반환한다. 클래식 RAG에는 폴백이 없어 그럴듯한 것을 환각한다. Foundry IQ는 호출 에이전트에게 검색이 실패했다는 명확한 신호를 준다.
같은 논리가 도구에도 적용된다. 도구 몇 개를 가진 에이전트는 프롬프트에 모두 나열할 수 있다. 수십 개를 가진 에이전트는 그럴 수 없다. 해결책: 에이전트가 필요할 때 올바른 도구를 검색해 가져오고 호출한다 — 이것이 Foundry의 도구 검색이며, OpenAI와 Anthropic의 에이전트들도 수렴한 패턴이다.
정체성과 행동 공간 (An Identity and a Place to Act)
검색은 에이전트에게 올바른 정보를 가져다준다. 하지만 정보만으로는 작업을 완료할 수 없다. 에이전트가 고객이 불만족스럽다는 것을 알더라도, 사과 이메일을 작성하고 주문을 환불해야 한다.
이를 책임감 있게 하려면 에이전트는 두 가지가 필요하다:
- 조직이 볼 수 있는 정체성 — 모든 행동이 익명이거나 정체성을 빌린 사용자에게 귀속된다면 감사 추적이 무너진다
- 행동할 수 있는 표면 — 에이전트가 디렉토리에 존재하지만 이메일을 보내거나 문서를 업데이트할 방법이 없다면 작업을 수행하지 않는 것이다
Microsoft의 경우, Entra를 통해 에이전트가 이름이 있는 디렉토리 항목을 가질 수 있고, 조직도에서 관리자에게 보고하며, 자체 메일박스를 소유할 수 있다.
가드레일은 도구 경계에 위치해야 한다. 에이전트는 도구 출력과 검색된 문서도 읽는데, 그 중 어느 것이든 사용자가 타이핑하지 않은 지시를 포함할 수 있다 — 이것이 간접 프롬프트 인젝션이 작동하는 방식이다. Foundry는 모델이 이미 가진 안전성에 추가해 도구 호출과 도구 응답 수준에서 자체 분류기를 실행한다.
프로덕션 에이전트 평가
대부분의 팀은 평가를 출시 전 체크박스로 처우한다. 그러나 에이전트는 비결정론적이다. 동일한 프롬프트가 동일한 모델에 대해 다른 응답을 생성할 수 있고, 공급자가 업데이트를 출시하면 모델 자체가 변하며, 에이전트가 검색하는 데이터는 매일 변한다.
루브릭 기반 평가 (Rubric-Based Evaluation)
일반적인 메트릭(근거성, 일관성, 작업 완료)은 상한선이 있다. 에이전트가 작동하는지는 알 수 있지만, 올바르게 작동하는지는 알 수 없다.
예: 레스토랑 예약 에이전트. 일반적인 메트릭은 에이전트가 예약 도구를 성공적으로 호출하고 예약을 반환했다고 말해준다. 하지만:
- 사용자가 "두 명이서 내일"이라고만 말했을 때 원하는 시간을 물어봤는가?
- 오후 6시 슬롯이 사용 가능하다고 주장하기 전에 예약 시스템에서 확인했는가?
- 예약 후 세부 사항을 사용자에게 확인했는가?
루브릭은 에이전트가 보여야 하는 특정 동작에 대한 예/아니오 질문이다. 에이전트를 소유한 팀이 작성하므로 에이전트가 실제로 해야 하는 것을 반영한다.
자동 개선 루프: Foundry의 Agent Optimizer는 루브릭이 실패했을 때 에이전트 자체를 자동으로 개선할 수 있다 — 시스템 프롬프트를 재작성하거나, 에이전트가 도구를 사용하는 방식을 조정하거나, 에이전트가 우선시하는 소스를 변경한다. 여러 후보를 병렬로 생성하고, 루브릭에 대해 각각을 점수화하고, 최선을 새 에이전트 버전으로 승격한다. 에이전트를 측정하는 동일한 루프가 이제 에이전트를 개선한다 — 자기 개선 루프가 된다.
다른 팀을 위한 핵심 교훈
- 검색은 에이전틱이어야 한다 — 검색 레이어 호출은 플래너 기반, 다중 소스, 재시도 가능한 서브에이전트를 숨겨야 하며 하나의 나쁜 조회에서 복구할 수 있어야 한다
- 행동하는 에이전트는 조직이 인식하는 정체성을 가져야 한다 — 컴플라이언스 검토를 통과하는 감사 추적과 함께
- 가드레일은 도구 경계에 위치해야 한다 — 모델의 경계에만 있는 것이 아니라
- 평가는 출시 후에 끝나지 않는다 — 에이전트와 함께 실행되며, 루브릭은 에이전트의 역할이 진화함에 따라 진화한다
중요한 현실: Anthropic이 Claude Opus 4.8을 출시했을 때, Microsoft의 GitHub Copilot CLI 팀은 출시 전에 하네스를 재조정하고 평가를 다시 실행해야 했다. 모델은 데이터베이스 버전처럼 업그레이드할 수 없다.
핵심 요약 (20줄)
- Microsoft Foundry는 80,000+ 기업, M365 Copilot 2천만 사용자를 지원하는 AI 에이전트 플랫폼
- 핵심 교훈: "하네스가 모델만큼 중요하다" — 모델 주변의 모든 것이 프로덕션을 결정한다
- AI는 챗봇 → 행동 에이전트 시대로 전환 중. 틀린 답 vs 잘못된 행동의 비즈니스 리스크가 다르다
- 프로덕션 에이전트 하네스 5계층: 추론(Inference), 런타임, 관측성, 정체성, 컨텍스트
- Foundry는 OpenAI/Anthropic/xAI 등 11,000개 이상의 모델 지원 — 모델 교체 가능성이 핵심
- 모델은 DB 버전처럼 업그레이드 불가 — Claude Opus 4.8 출시 시 GitHub Copilot CLI 팀이 하네스 재조정 필요했음
- 컨텍스트 레이어가 에이전트가 "올바르게" 실행되게 한다 — 다른 레이어들은 "실행"만 보장
- 클래식 RAG는 원샷이라 회복 불가 — Foundry IQ는 검색을 서브에이전트 루프로 처우
- Foundry IQ: 반복 소진 시 환각 대신 구조화된 "모릅니다" 반환
- 도구 검색: 모든 도구를 프롬프트에 나열하는 대신 필요할 때 동적으로 찾는다 — OpenAI/Anthropic도 같은 방향으로 수렴
- Microsoft IQ 4개 서비스: Foundry IQ(비정형), Fabric IQ(정형), Web IQ(웹), Work IQ(M365)
- 에이전트는 조직이 인식하는 정체성(Entra)이 필요 — 익명 행동은 규제 환경에서 불가
- 가드레일은 도구 경계에 위치해야 함 — 간접 프롬프트 인젝션 방어
- 연속 평가(Continuous Evaluation): 프리-쉽 체크박스가 아닌 실시간 트래픽 모니터링
- 루브릭 기반 평가: 일반 메트릭이 아닌 유스케이스별 구체적 행동 검사
- 레스토랑 예약 예시: 도구 호출 성공 ≠ 올바른 동작. 맥락 질문, 가용성 확인, 세부사항 확인이 별도 루브릭
- Agent Optimizer: 루브릭 실패 시 자동 프롬프트 재작성/모델 교체로 자기 개선 루프 구현
- 평가가 에이전트를 측정하고 개선하는 동일한 루프가 됨
- 향후 방향: 개발자 전용 기능이 일반 사용자 도구로 넘어오는 패턴 가속화
- 자기 개선 에이전트: 전역/로컬 메모리 + 스킬 + 사용자 학습이 결합되는 방향