Evaluations | The .NET Blog

Model router evals는 너무 많은 팀이 건너뛰는 단계다

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

이 게시물은 자동으로 번역되었습니다. 원본 버전은 여기를 클릭하세요.

자동 모델 라우팅은 멋져 보이지만, 결국 그것이 내 workload에 정말 맞는 선택임을 증명해야 한다는 사실을 깨닫는 순간 인상이 달라진다.

그래서 새로운 model router evaluation repo가 유용하다.

이 repo는 팀이 정말 중요한 질문에 대해 더 구체적으로 답할 수 있게 해 준다.

라우팅이 품질을 유지하는가?
비용을 개선하는가?
지연 시간에는 어떤 영향을 주는가?
model subset을 제한하면 무엇이 달라지는가?

원문은 올바른 질문을 던진다

원문에서 특히 마음에 드는 점은 model router를 당연히 좋은 것으로 취급하지 않는다는 것이다.

대신 불편하지만 맞는 질문을 던진다.

“내 prompts에 대해, model router가 자동 선택한 model이 내가 다른 선택지로 고를 단일 model과 같거나 더 나은가?”
“정말 end to end로 비용을 절감하고 있는가, 아니면 그냥 지출 위치만 옮기고 있는가?”

이것이 정확히 올바른 태도다.

자동 라우팅은 매력적이지만, 여전히 system decision이다. 그리고 system decision은 감탄할 대상이 아니라 측정해야 할 대상이다.

이 repo가 처음 보이는 것보다 더 중요한 이유

한 수준에서는 이것은 그냥 evaluation repo다.

다른 수준에서는 성숙의 신호다.

즉, 자동 라우팅을 도입하고 싶다면 다음을 더 규율 있게 테스트할 방법을 제공한다는 뜻이다.

품질
비용
지연 시간
subset trade-off
model distribution behavior

이것은 보기 좋은 branding을 가진 black box로 routing을 다루는 것보다 훨씬 낫다.

내 생각

이것은 AI platform이 더 필요로 하는 유형의 tooling을 잘 보여 준다. 더 많은 magic이 아니라, 그 magic을 신뢰하기 전에 검증할 더 많은 방법이다.

그것이 팀이 검증되지 않은 가정 위에 비싼 신뢰를 쌓지 않도록 하는 방법이다.

원문: How to run evals for the model router

AI 개발의 어려운 부분은 이제 접근이 아니다. 올바른 모델을 제대로 운영하는 일이다

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 원문은 여기를 클릭하세요.

강력한 model에 접근할 수 있다는 것만으로 충분했던 시기는 이미 지났다.

이 새로운 Foundry guide to managing models, cost and quality가 정확히 짚어낸 부분이 바로 그것이다.

이제 진짜 과제는 운영이다.

각 workload에 맞는 model 선택
자신의 data로 검증
latency와 지출 관리
upgrade와 regression risk 관리

진지한 팀이 잘해야 하는 것은 바로 이것이다.

원문은 문제를 정확하게 정의한다

원문에서 나온 한 문장이 이 변화를 아주 잘 포착한다.

“오늘날 AI systems를 만드는 가장 어려운 부분은 더 이상 capable model에 접근하는 것이 아니다. 실제 application의 전체 lifecycle 동안 올바른 model을 선택하고, 검증하고, 최적화하고, 운영하는 방법을 아는 것이다.”

정확한 진단이다.

너무 많은 팀이 아직도 model selection이 핵심 결정이라고 생각한다.

그렇지 않다.

더 큰 문제는 model operation이다.

어떤 workload에 어떤 model을 쓸 것인가?
quality는 어떻게 확인할 것인가?
받아들일 수 있는 cost shape는 무엇인가?
새로운 model이 나오거나 오래된 model이 drift하면 어떻게 할 것인가?
실제 workflow를 깨지 않고 change를 어떻게 테스트할 것인가?

이제 그것이 진짜 engineering work이다.

왜 이 Foundry 글이 유용한가

이 글이 좋은 이유는, 경험 많은 platform engineer가 실제로 생각해야 하는 방식으로 AI systems를 이야기하기 때문이다.

“가장 똑똑한 model을 고르고 끝” 같은 식이 아니다.

capability, latency, cost, safety, governance, upgrade pressure 같은 trade-off 아래서 살아가는 system으로 본다.

그것은 benchmark-driven optimism보다 훨씬 유용하다.

가장 중요한 변화는 criteria-first 사고다

원문은 model catalog를 열기 전에 success criteria를 정의하라고 권한다.

그건 팀이 채택할 수 있는 가장 중요한 습관 중 하나라고 생각한다.

catalog를 먼저 열면 reputation에 기대게 된다.

criteria를 먼저 정의하면 workload reality에 기대게 된다.

그게 더 건강한 과정이다.

왜냐하면 benchmark를 이기는 model이 반드시 다음도 이기는 것은 아니기 때문이다.

당신의 prompts
당신의 latency budget
당신의 cost guardrails
당신의 governance requirements

그 차이가 성숙한 AI engineering의 시작점이다.

multi-model 이야기가 진짜 장점이 되고 있다

또 하나 마음에 드는 점은 model-agnostic framing이다.

이 글은 Foundry를 하나의 model destination이 아니라 다음을 아우르는 operating surface로 제시한다.

Microsoft models
partner models
open-source models
post-trained variants
routing과 optimization strategies

이것이 중요한 이유는 model flexibility가 이제 사치가 아니기 때문이다. risk management의 일부다.

quality가 바뀌고, price가 움직이고, quota가 제한되면 팀은 선택지가 필요하다.

cost control은 부차적인 문제가 아니다

이 글은 cost를 architecture concern으로 다루는 점에서도 맞다.

이건 “나중에 최적화하자"는 문제가 아니다.

기본값으로 모든 task를 가장 heavy한 model에 보내면 demo에서는 훌륭하게 동작할 수 있지만, production economics 앞에서는 무너질 수 있다.

그래서 다음 항목들이 많은 사람이 생각하는 것보다 더 중요하다고 본다.

routing
batching
caching
provisioned throughput
quota management

cost discipline을 system design의 일부로 다루는 팀은, 나중에 정리하는 일로 보는 팀보다 훨씬 오래 간다.

내 생각

이 Foundry 글은 경험 많은 engineer가 실제로 운영해야 하는 방식으로 AI systems를 이야기하기 때문에 유용하다.

demo로서가 아니라. 일회성 prototype으로서가 아니라. leaderboard 관광으로서가 아니라.

workload, constraints, trade-offs, 지속적인 변화를 위한 operating systems로서 말한다.

우리는 그 수준의 대화로 계속 올라가야 한다.

그리고 production AI systems를 만든다면, 팀이 일찍 내면화해야 할 mindset이 바로 이것이다.

원문: A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry

Foundry의 observability-to-ROI 이야기는 진지한 에이전트 플랫폼에 꼭 필요한 것이다

Emiliano Montesdeoca — Mon, 25 May 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 원문은 여기를 클릭하세요.

AI agents가 production에서 살아가려면 observability는 logs와 traces에서 끝나면 안 된다.

그래서 Foundry의 새로운 observability-to-ROI 이야기가 중요하게 느껴진다.

진짜 메시지는 “대시보드를 더 만들었다"가 아니다.

진짜 메시지는 진지한 agent platform이 지속적인 operating loop를 필요로 한다는 점이다:

무엇이 일어났는지 trace한다
그것이 좋은지 evaluate한다
손봐야 할 부분을 optimize한다
결과를 business value와 연결한다

이것은 흔한 platform식 수사보다 훨씬 강한 이야기다.

원문 article의 핵심 문장이 모든 것을 말해준다

원문은 agent를 만드는 모든 팀이 주목해야 할 한 줄로 시작한다:

“AI agent를 배포하는 것은 쉬운 부분이다. production에서 그것을 정확하고, 안전하고, 책임 있게 유지하는 것이 팀이 막히는 지점이다.”

정확한 말이다.

우리는 이미 “agent가 뭔가 멋진 일을 하게 만들 수 있을까?“가 핵심 질문이던 단계를 지났다.

더 어렵고 더 가치 있는 질문은:

real users, real tools, real costs와 상호작용하기 시작한 뒤에도 그 시스템을 운영할 수 있느냐는 것이다.

Foundry는 바로 그 대화를 앞으로 밀어내고 있다.

이것이 또 다른 agent demo보다 중요한 이유

많은 AI agent 발표는 여전히 creation에 초점을 맞춘다. agent를 만들고, tools를 연결하고, tasks를 라우팅하고, interface를 내놓는다.

그건 다 괜찮다.

하지만 운영상의 질문들이야말로 대부분의 serious system을 지속 가능하게 만들거나, 비싼 실험으로 전락시키는 지점이다:

production에서 agent가 실제로 무엇을 하고 있는가?
올바른 일을 했는가?
시간이 갈수록 더 나빠지고 있는가?
창출하는 가치에 비해 너무 비싼가?
어떤 configuration change가 실제로 quality를 개선했는가?

그래서 나는 Foundry 발표가 일반적인 feature roundup보다 더 중요하다고 생각한다. 단순한 agent creation story가 아니라, Agent DevOps loop를 정의하려 하기 때문이다.

네 부분으로 된 loop가 여기서 진짜 product다

이 article은 platform을 사실상 네 가지 capability로 정리한다:

Trace
Evaluate
Monitor
Optimize

이게 맞는 형태다.

실제로 agent production workload를 진지하게 다루려는 platform이라면, 결국 이 네 가지 모두가 필요하다고 본다.

tracing만으로는 부족하다.

evaluation만으로는 부족하다.

증거 없는 optimization은 그저 추측일 뿐이다.

그리고 telemetry 없는 ROI 논의는 대부분 연극이다.

interoperability 측면이 특히 똑똑하다

발표의 가장 강한 선택 중 하나는 Foundry가 모든 agent가 하나의 framework에서만 만들어질 거라고 가정하지 않는다는 점이다.

원문은 tracing과 evals가 다음 영역까지 확장된다고 명시한다:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
OpenTelemetry를 통한 custom frameworks

이것은 중요하다.

platform lock-in은 원래 유용했던 operations story를 덜 매력적으로 만드는 가장 빠른 방법 중 하나이기 때문이다.

팀이 framework 선택을 유지하면서도 production-grade telemetry와 evaluation surface를 얻을 수 있다면, 마찰은 크게 줄어든다.

rubric evaluation은 사람들이 예상하는 것보다 더 중요해질 수 있다

rubric evaluator 부분도 짚고 넘어갈 만하다.

나는 이것이 전체 post에서 가장 실용적인 추가 기능 중 하나라고 본다.

왜냐하면 “좋다"는 것은 맥락에 따라 달라지기 때문이다.

이 article은 rubric evaluation이 “agent의 intended behavior에서 context-aware evaluation criteria를 생성한다"고 말한다. 바로 이런 방향이 필요하다.

일반적인 quality scoring도 유용하다.

하지만 결국 teams는 자신들의 기준으로 agents를 점수화해야 한다:

tone
task completion
policy adherence
latency expectations
cost boundaries
domain-specific business rules

여기서 evaluation은 학문적으로 흥미로운 수준을 넘어 operationally meaningful해진다.

ROI는 가장 불편한 부분이고, 그래서 중요하다

발표의 ROI 부분이 중요하다고 생각하는 것도 바로 그 질문이 불편하기 때문이다.

원문은 직접 묻는다:

“이 agent는 그 비용만큼의 가치가 있는가?”

이 질문은 AI 대화에서 자주 피해진다.

하지만 이게 맞는 질문이다.

platform이 cost, task completion, time saved, production traces를 한곳에서 실제로 연결할 수 있다면, engineering과 leadership 모두에게 훨씬 더 나은 공통 언어를 제공한다.

솔직히 말해, 그런 공통 언어는 지금 매우 필요하다.

내 생각

이 batch에서 가장 나은 platform-level 발표 중 하나다. agents를 만드는 것보다 운영하는 것에 초점을 맞추고 있기 때문이다.

그리고 어려운 일은 바로 거기서 진짜 시작된다.

앞으로 2년 동안 가장 강한 AI platform은 더 많은 models나 더 많은 demos에 접근할 수 있는 것만으로 결정되지 않을 것이다. 팀이 behavior를 추적하고, 결과를 평가하고, 안전하게 optimize하고, evidence로 비용을 정당화할 수 있게 도와주는 platform이 강할 것이다.

Foundry의 이 이야기는 정확히 그 방향으로 움직이려 한다.

그래서 진지하게 받아들일 가치가 있다.

원문: Build 2026: From observability to ROI for AI agents on any framework