Models | The .NET Blog

Claude Opus 4.8이 Foundry에서 이용 가능해진 것은 모델 선택이 플랫폼 기능이 되고 있다는 또 다른 신호

Emiliano Montesdeoca — Mon, 15 Jun 2026 00:00:00 +0000

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

어느 시점부터 모델 이용 가능성 발표는 특정 모델 자체만으로는 더 이상 흥미롭지 않게 됩니다.

플랫폼 스토리를 강화하기 때문에 흥미로워집니다.

그렇게 나는 Claude Opus 4.8이 Microsoft Foundry에 도입되는 것을 봅니다.

모델도 중요하지만, 더 큰 이야기가 더 중요합니다

네, Claude Opus 4.8은 그 자체로 중요한 모델 업데이트입니다.

하지만 더 유용한 신호는 Foundry가 하나의 관리되는 운영 표면 아래에서 진정한 모델 선택을 계속 확장하고 있다는 것입니다.

이것은 중요합니다. 왜냐하면 팀들에게 더 많은 여유를 주기 때문입니다:

모델을 워크로드와 매칭하기
비용과 기능의 균형 맞추기
모델 품질이나 가격이 변할 때 유연성 유지하기
거버넌스와 배포 규칙을 한 곳에서 유지하기

그 부분이 나에게 더 중요한 부분입니다.

플랫폼 사고에 이것이 왜 중요한가

당신의 AI 플랫폼이 하나의 모델 공급업체가 영원히 지배적으로 유지될 때만 잘 작동한다면, 당신은 실제로 탄력적인 플랫폼을 가지고 있지 않습니다.

당신은 좋은 마케팅이 있는 의존성을 가지고 있습니다.

따라서 Foundry가 또 다른 진정한 모델 옵션을 추가할 때마다, 흥미로운 질문은 단순히 “이 모델이 좋은가?“가 아닙니다.

다음과 같은 질문도 있습니다:

이것이 내 아키텍처의 유연성을 증가시키는가?
이것이 공급업체 종속성 압박을 줄이는가?
이것이 워크로드 특정 라우팅을 더 현실적으로 만드는가?

그것이 모델 이용 가능성이 전략적으로 유용해지는 수준입니다.

내 생각

이것은 하나의 특정 모델 마일스톤보다는 Foundry가 진정한 다중 모델 플랫폼처럼 계속 행동하는 것에 관한 것입니다.

그것이 더 큰 이야기입니다.

그리고 Foundry가 그 이야기를 강화할수록, 팀들이 단순히 반응하는 대신 모델 선택을 운영할 수 있는 곳으로서 더 신뢰성 있게 됩니다.

원본 글: Claude Opus 4.8 이제 Microsoft Foundry에서 이용 가능합니다

Microsoft Foundry 2026년 5월: 내가 정말 주의 깊게 볼 업데이트들

Emiliano Montesdeoca — Wed, 27 May 2026 00:00:00 +0000

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

월간 플랫폼 요약은 금방 기능 과부하로 이어질 수 있다.

그래서 What’s New in Microsoft Foundry | May 2026의 짧은 버전은 이렇다. 이 플랫폼은 실제 AI 시스템에서 가장 중요한 영역을 정확히 더 깊게 다루고 있다.

내가 주목할 흐름은 다음과 같다.

trace 기반 평가
더 넓은 모델 선택
더 강력한 에이전트 도구
더 나은 관리형 격리와 비용 가시성
Foundry Local을 통한 로컬 AI의 지속적인 모멘텀

이것은 밀도 높은 요약이므로, 개수보다 패턴이 더 중요하다

원문에는 개별 항목이 많다.

그건 괜찮지만, 이런 종류의 글을 기능별로 읽는 것이 최선이라고는 생각하지 않는다.

더 나은 질문은: 플랫폼이 어떤 방향을 분명히 강화하고 있는가? 이다.

그리고 내 답은 이렇다.

Foundry는 모델 카탈로그뿐 아니라 에이전트 주변의 운영 계층에서도 점점 더 강해지고 있다.

그것은 아주 좋은 신호다.

가장 중요한 주제는 trace 기반 평가다

전체 요약에서 하나의 주제를 고르라면, 아마 trace 기반 평가일 것이다.

왜일까? 평가 이야기를 다음과 같이 바꾸기 때문이다.

정적인 데이터셋을 구축한다
벤치마크를 실행한다
그것이 프로덕션을 반영하길 기대한다

에서 더 현실적인 것으로 바꾼다.

실제 동작을 관찰한다
실제 trace를 평가한다
시스템이 실제로 무엇을 하는지에서 배운다

이것은 프로덕션 AI에 훨씬 더 성숙한 모델이다.

모델 폭은 중요하지만, 운영 가능할 때만 그렇다

Grok, DeepSeek, Fireworks, reinforcement fine-tuning과 관련된 추가 기능은 모두 각자의 방식으로 유용하다.

하지만 나에게 더 중요한 점은 단순히 또 하나의 model이 추가됐다는 사실이 아니다.

모델 폭이 다음과 함께 결합되고 있다는 점이 중요하다.

운영 가시성
평가 도구
거버넌스 표면
배포 일관성

이것이 모델 생태계가 혼란으로 변하는 것을 막는다.

Foundry Local은 반복해서 나타나는 전략적 신호가 되고 있다

내가 무시하지 않을 또 다른 점은 Foundry Local이 이제 Foundry 이야기의 진지한 일부로 얼마나 자주 등장하는가 하는 점이다.

이것은 Microsoft가 더 이상 로컬 AI를 주변 실험으로 보지 않는다는 뜻이다.

그것은 더 넓은 플랫폼 서사의 일부가 되고 있다.

개인정보 보호
디바이스 로컬 추론
하드웨어 이동성
엣지 배포
하이브리드 운영 모델

이 점은 주목할 만하다.

내 생각

세부 사항도 중요하지만, 더 큰 패턴이 더 중요하다.

Foundry는 에이전트, 평가, 모델, 로컬 런타임, 거버넌스가 더 자연스럽게 연결되는 플랫폼을 향해 계속 움직이고 있다.

내가 가장 중요하게 보는 것은 바로 그 방향이다.

그리고 이 요약은 많은 작은 개별 발표보다도, 그 방향을 한곳에서 더 쉽게 보이게 해 준다.

원문: What’s new in Microsoft Foundry | May 2026

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