주중을 시작하는 주말 아침 주간 AI #27입니다.
이번 주는 Microsoft Build 2026을 중심으로 에이전트 플랫폼의 운영 기준이 한 단계 올라간 주였습니다. Foundry는 런타임, 도구, 메모리, 지식 접지, 모델, 관측성, 거버넌스를 한 번에 묶는 방향을 분명히 했고, GitHub Copilot App과 Copilot SDK 1.0은 개발 에이전트 경험을 독립 실행형 작업대로 밀어 올렸습니다. OpenAI Codex와 Microsoft Scout는 에이전트가 개발자를 넘어 지식 노동과 업무 조율까지 확장되는 흐름을 보여줬고, Cosmos 3, Gemma 4 12B, Mellum2, Nemotron 3 Ultra는 로컬·오픈 모델 경쟁을 더 실용적인 배치 문제로 바꿨습니다. 동시에 실패 모드 분류, 권한 모델, 컨텍스트 설계, 사용량 기반 과금 이슈가 겹치며 프로덕션 에이전트의 핵심이 "무엇을 할 수 있나"에서 "어떻게 통제하며 반복 개선할 것인가"로 이동하고 있습니다.
주말 아침 AI #27
주요 뉴스
Microsoft Foundry Build Edition: 프로덕션 에이전트 플랫폼 확장
Microsoft Build 2026에서 Foundry는 에이전트 런타임, Toolboxes, Voice Live, 메모리, Foundry IQ, Managed Compute, MAI 모델, ASSERT, ACS, Agent Optimizer, ROI 추적까지 한 번에 묶었습니다. 단일 기능 업데이트라기보다 “에이전트를 만들고, 실행하고, 관측하고, 거버넌스하고, 개선하는” 전체 수명주기를 한 플랫폼으로 수렴시키려는 발표입니다.
Microsoft는 엔터프라이즈 AI의 핵심을 모델 접근성이 아니라 GitHub, Microsoft IQ, Foundry, Agent 365, Teams, Microsoft 365로 이어지는 통합 운영 체계로 정의했습니다. 모델·데이터·도구·정책·관측성·인간 감독이 따로 놀면 데모는 가능해도 실제 업무 시스템으로 확장되기 어렵다는 메시지가 분명합니다.
Microsoft Scout 공개: 항상 켜져 있는 개인 에이전트
Microsoft는 Autopilot이라는 새 범주의 에이전트를 소개하고 첫 제품으로 Scout를 공개했습니다. Scout는 사용자의 대기 명령을 기다리는 챗봇이 아니라 자체 identity를 가진 배경 실행 에이전트로, 조직 정책과 권한 안에서 업무 조율·리스크 감지·후속 작업을 지속적으로 처리하는 방향을 제시합니다.
GitHub Copilot App: 에이전트 네이티브 데스크톱 경험
GitHub Copilot App이 기술 프리뷰로 제공되며, 여러 저장소의 세션, 이슈, PR, 백그라운드 자동화를 한 My Work 화면에서 다루는 데스크톱 작업대가 등장했습니다. Copilot이 IDE 기능에서 벗어나 "진행 중인 에이전트 작업을 관리하는 클라이언트"로 확장되는 중요한 신호입니다.
Codex for every role, tool, and workflow
OpenAI는 Codex가 개발 도구를 넘어 분석가, 마케터, 운영 담당자, 디자이너, 연구자 같은 비개발 직군으로 넓어지고 있다고 발표했습니다. 역할별 플러그인, Sites, annotations를 통해 Codex를 코드 작성기가 아니라 반복 지식 업무를 처리하는 범용 작업 계층으로 확장하려는 흐름입니다.
ChatGPT memory Dreaming: 더 나은 개인화 메모리 구조
OpenAI는 saved memories 위에서 작동하는 Dreaming 기반 메모리 아키텍처를 강화했습니다. 사용자가 직접 요약을 검토·수정할 수 있게 하면서도, 오래된 정보의 부패를 줄이고 선호·제약·시간 흐름을 더 잘 반영하려는 방향이라 장기 개인화 에이전트의 중요한 기반 기술로 볼 수 있습니다.
NVIDIA Cosmos 3: 물리 AI를 위한 오픈 옴니모델
Cosmos 3는 세계 생성, 물리 추론, 행동 생성을 하나의 Mixture-of-Transformers 구조로 통합한 모델입니다. 로봇, 자율주행, 창고 안전, 스마트 공간처럼 "토큰"보다 움직임·원인·공간 관계가 중요한 영역에서 합성 데이터 생성과 행동 예측을 한 모델로 다루려는 시도가 본격화됐습니다.
에이전트 AI 실패 모드 분류 v2: 레드팀 1년의 교훈
Microsoft 보안팀은 에이전트 공급망 침해, 목표 하이재킹, 에이전트 간 신뢰 상승, 컴퓨터 사용 에이전트 특유의 공격면 등 새 실패 모드를 정리했습니다. MCP와 플러그인 생태계가 커질수록 자연어 지시·도구 정의·GUI 조작 자체가 공급망과 권한 경계가 된다는 점을 보여줍니다.
새로운 도구/서비스
Microsoft Agent Framework at Build 2026: Agent Harness, Hosted Agents, CodeAct
Microsoft Agent Framework는 AutoGen과 Semantic Kernel의 수렴 이후 1.0 기반 위에 Agent Harness, context compaction, human-in-the-loop, 파일·셸 도구, MCP 연동, 멀티스텝 워크플로를 더했습니다. 에이전트 프레임워크가 "채팅 클라이언트 래퍼"에서 장기 실행 소프트웨어 런타임으로 이동하고 있습니다.
Agent Optimizer in Foundry Agent Service
Agent Optimizer는 호스팅된 에이전트를 기준 평가하고, 실패 지점을 바탕으로 프롬프트·스킬·모델 후보를 생성한 뒤 같은 태스크셋으로 재평가해 배포 가능한 후보를 추천합니다. 운영 추적과 평가 결과를 개선 제안으로 연결한다는 점에서 수작업 프롬프트 튜닝을 Agent DevOps 루프로 바꾸는 기능입니다.
Foundry Managed Compute: 오픈 모델 실행을 Foundry 안으로
Foundry Managed Compute는 지역 GPU 용량과 인프라 관리를 직접 떠안지 않고 오픈 모델 추론·파인튜닝을 Foundry 제어면에서 다루는 경로를 제공합니다. 모델 선택지가 늘수록 운영 병목은 모델 호출보다 배포 위치, 용량, 비용, 규정 준수로 옮겨가는데, 그 문제를 플랫폼 계층에서 흡수하려는 움직임입니다.
Copilot SDK가 1.0.0에 도달하며 여러 언어 SDK, remote session, tracing diagnostics, MCP OAuth token storage, canvas runtime 같은 기능이 정리됐습니다. Copilot을 사내 도구·워크플로·커스텀 에이전트에 임베드하려는 팀에게는 실험용 베타가 아니라 추적할 만한 공식 기반이 생긴 셈입니다.
Gemma 4 12B: 로컬 멀티모달 에이전트를 위한 개발자 가이드
Gemma 4 12B는 LiteRT-LM 기반 데스크톱·온디바이스 실행과 OpenAI 호환 로컬 API 서버를 전면에 내세웠습니다. LM Studio, Ollama, Google AI Edge 앱, LiteRT-LM CLI로 이어지는 배포 경로가 넓어지면서 로컬 에이전트 실험의 장벽이 더 낮아졌습니다.
JetBrains Mellum2: 12B MoE 텍스트·코드 모델
Mellum2는 12B 파라미터 Mixture-of-Experts 모델이지만 토큰당 2.5B만 활성화해 낮은 지연시간과 높은 처리량을 노립니다. 라우팅, RAG, 요약, 서브에이전트, 사내 배포 같은 반복 호출 작업에 맞춘 모델이라 “작지만 잘 배치되는 모델” 경쟁을 보여줍니다.
NVIDIA Nemotron 3 Ultra, Ollama Cloud 제공
Nemotron 3 Ultra는 550B 전체 파라미터, 55B active 구조와 1M 토큰 컨텍스트를 앞세운 오픈 모델입니다. 장기 실행 에이전트, 코딩 에이전트, deep research처럼 수백 번의 도구 호출과 긴 작업 이력이 필요한 워크플로를 겨냥합니다.
학습 자료
OpenAI: 신뢰할 수 있는 제3자 평가를 위한 플레이북
OpenAI는 에이전트 평가에서 모델 이름만 비교하는 방식이 불충분하다고 설명합니다. harness, 도구 접근, 예산, compaction, retry, scoring, contamination, reward hacking까지 평가 조건을 명시해야 결과가 실제 capability인지, 특정 하네스의 산물인지 구분할 수 있습니다.
Claude Code dynamic workflows: 작업별 하네스를 즉석에서 만들기
Claude Code의 dynamic workflows는 기본 코딩 하네스 위에 작업별 멀티에이전트 흐름을 생성·재사용하는 방식입니다. 연구, 보안 분석, 코드 리뷰처럼 단순 파일 편집보다 복잡한 태스크는 모델보다 하네스 설계가 성능을 좌우한다는 점을 잘 보여줍니다.
Anthropic은 내부에서 수백 개 스킬을 운영하며 라이브러리 레퍼런스, 제품 검증, 데이터 분석, 팀 자동화, 스캐폴딩, 코드 품질, 배포, 런북, 인프라 운영처럼 스킬 유형을 분류했습니다. 특히 검증 스킬이 결과 품질에 가장 직접적인 영향을 준다는 관찰은 팀 단위 에이전트 도입에 실용적입니다.
AI observability vs monitoring
Twilio 글은 기존 모니터링과 AI 관측성을 구분해 설명합니다. 에러율·지연시간만 보는 방식으로는 에이전트의 판단, 도구 선택, 프롬프트 드리프트, 비용 급증을 잡기 어렵기 때문에 trace, eval, groundedness, task outcome까지 같이 봐야 합니다.
답하지 말아야 할 때를 아는 AI 지원 에이전트 만들기
고객 지원 에이전트의 핵심은 많은 답을 만드는 것이 아니라 에스컬레이션, 권한 부족, 위험 요청, 불확실한 케이스를 구분하는 것입니다. "응답 생성"보다 “거절·보류·사람 연결” 정책을 먼저 설계해야 실제 지원 품질과 리스크가 함께 관리됩니다.
Microsoft Foundry Hosted Agent를 GitOps와 GitHub Tasks로 운영하기
Foundry Hosted Agent를 코드, 배포, 태스크 추적과 함께 운영하는 실전 흐름을 보여주는 자료입니다. 에이전트를 포털에서 만든 설정값이 아니라 버전 관리되는 소프트웨어 산출물로 취급해야 운영·감사·롤백이 쉬워진다는 점이 핵심입니다.
C#에서 Microsoft Agent Framework와 SharpVector로 로컬 RAG 구성하기
Build5Nines 글은 C# 개발자가 로컬 벡터 저장소와 Microsoft Agent Framework를 연결해 RAG를 구성하는 경로를 다룹니다. 클라우드 검색 인프라 없이도 작은 지식 베이스와 에이전트 흐름을 실험할 수 있어 .NET 팀의 학습 진입점으로 좋습니다.
인사이트
Auth0는 장기 API 키나 사람용 OAuth 흐름이 비결정적 에이전트에는 맞지 않는다고 지적합니다. 에이전트 권한은 capability 단위, 짧은 수명, 실행 계획 기반, 고위험 작업의 human-in-the-loop 승인, 중앙 감사 정책으로 설계해야 합니다.
O’Reilly 글은 컨텍스트를 문서 더미가 아니라 컴파일 가능한 규칙 구조로 다루자는 관점을 제시합니다. 코드 생성이 풍부해질수록 희소해지는 것은 문법이 아니라 아키텍처 경계와 "무엇을 생성하면 안 되는가"를 자동화하는 능력이라는 메시지가 강합니다.
코딩 에이전트 시대에는 코드베이스 구조 자체가 프롬프트가 됩니다. 수직 슬라이스처럼 관련 코드가 가까이 있고 한 기능의 전체 흐름이 작은 컨텍스트에 들어오는 구조는 토큰 비용, 지연시간, 환각 가능성을 동시에 줄입니다.
Copilot 사용량 기반 과금 충격: 긴 세션과 큰 컨텍스트의 비용
GitHub Copilot의 AI Credits 기반 과금이 시작되며 긴 도구 호출 세션, 큰 prompt payload, compaction 없는 반복 디버깅이 비용을 빠르게 태우는 사례가 나왔습니다. 앞으로 에이전트 사용성은 결과 품질뿐 아니라 세션 분할, 컨텍스트 압축, 저비용 모델 라우팅, 사용량 가시성까지 포함해야 합니다.
코드베이스가 프롬프트라면, 스킬은 팀 운영 지식의 패키지다
이번 주 여러 글의 공통점은 "모델에게 더 길게 설명하라"가 아니라 팀의 빌드·테스트·검증·배포 방식을 재사용 가능한 스킬과 하네스로 외부화하라는 것입니다. 에이전트 성능은 모델 단품보다 좋은 작업 환경을 얼마나 버전 관리하느냐에 가까워지고 있습니다.
OpenAI 평가 플레이북이 말하는 것: 점수보다 조건이 중요하다
에이전트 벤치마크는 harness, budget, tool access, retry, compaction, scoring에 따라 결과가 크게 달라집니다. "어느 모델이 이겼는가"만 보는 조직은 잘못된 구매·도입 판단을 내릴 수 있고, 앞으로는 평가 리포트도 실험 조건과 실패 검토를 제품 스펙처럼 읽어야 합니다.