Post

2026년 5월 15일 AI 뉴스 요약: OpenAI는 Codex를 모바일·원격 SSH·훅·토큰으로 확장하고 ChatGPT는 민감 대화의 맥락 인식을 강화했으며, Anthropic은 Claude for Small Business로 중소기업 업무 자동화를 패키지화했고, Google은 Genkit Middleware와 ADK로 운영형 에이전트 스택을 다듬었고, AWS는 브라우저 거버넌스·실시간 음성·MCP 보안을 연결했으며, NVIDIA는 SAP용 신뢰 런타임·로컬 Hermes·대규모 RL 인프라로 에이전트 실행 계층 전반을 밀어 올렸다

2026-05-15 11:40 · ai-daily-news

오늘의 AI 뉴스

배경

2026년 5월 15일 KST 기준으로 지난 48시간 안팎의 공식 발표들을 묶어 보면, 오늘의 AI 시장은 더 이상 “어떤 모델이 더 똑똑한가” 하나로 정리되지 않습니다. 지금 경쟁의 중심은 훨씬 더 아래층으로 내려가 있습니다. 구체적으로는 다음 질문들이 실제 제품 경쟁력을 가르는 층으로 떠올랐습니다.

에이전트를 어디서, 어떤 권한으로, 얼마나 오래 돌릴 것인가
사람이 자리를 비운 동안에도 작업이 안전하게 계속 움직이게 하려면 어떤 제어면이 필요한가
에이전트가 웹, 문서, 회계도구, 브라우저, 로컬 파일, 사내 시스템까지 만질 때 누가 경계를 강제하는가
중소기업과 대기업, 로컬과 클라우드, 텍스트와 음성처럼 서로 다른 운영 환경에 맞는 패키징은 어떻게 달라져야 하는가
장기적으로는 인간이 만든 정답 데이터가 아니라 경험 기반 학습과 시뮬레이션을 받쳐 줄 인프라가 어떤 구조로 가야 하는가

오늘 나온 공식 자료는 각각 다른 층에서 이 질문에 답합니다. OpenAI는 Codex를 장소에 묶이지 않는 에이전트 컨트롤 플레인으로 확장했고, 동시에 ChatGPT는 민감 대화의 위험 신호를 한 턴이 아니라 대화의 흐름 전체에서 읽는 안전 계층을 강화했습니다. Anthropic은 중소기업이 이미 쓰는 회계·결제·CRM·디자인 툴 안으로 Claude를 넣는 패키지화를 택했습니다. Google은 미들웨어와 장기 실행 상태 머신을 통해 에이전트 시스템을 프롬프트 묶음이 아니라 운영 가능한 애플리케이션으로 설명했습니다. AWS는 브라우저 거버넌스, 실시간 음성 스택, MCP/A2A 보안이라는 세 개의 실전 운영 문제를 한꺼번에 꺼냈습니다. NVIDIA는 SAP 같은 시스템 오브 레코드 안에서 움직이는 신뢰 런타임, 로컬 상시 실행 에이전트, 차세대 강화학습 인프라까지 에이전트 컴퓨트의 양끝을 모두 밀었습니다.

이 흐름을 한 문장으로 정리하면 이렇습니다. AI의 경쟁축이 모델 성능 그 자체에서, 모델을 실제 업무 환경 안에 배치하고 통제하고 확장하는 실행 계층 전체로 이동하고 있다는 것입니다. 이제 모델은 중요한 출발점이지만, 실제 도입과 확산은 다음 조합에서 갈립니다.

런타임 경계
승인 흐름
상태 저장
휴먼 인 더 루프 위치
커넥터와 권한 상속
브라우저·문서·음성 같은 입출력 특화 스택
로컬과 클라우드를 잇는 실행 전략
감사 로그와 레지스트리
경험 기반 학습을 위한 장기 인프라

특히 오늘의 발표들은 AI 업계가 “데모 가능한 에이전트”에서 “운영 가능한 에이전트”로 건너가고 있음을 보여 줍니다. 멋진 브라우저 자동화 화면, 화려한 추론 데모, 벤치마크 점수 하나만으로는 더 이상 충분하지 않습니다. 실제 고객과 개발팀, 보안팀, 운영팀이 묻는 질문은 훨씬 구체적입니다.

폰으로도 장기 작업을 승인하고 방향을 바꿀 수 있는가
위험 신호가 여러 대화에 흩어져 있을 때도 안전하게 반응할 수 있는가
회계·마케팅·영업·계약 업무를 이미 쓰는 도구 안에서 실제로 끝내 줄 수 있는가
에이전트의 재시작과 며칠짜리 대기 상태를 시스템적으로 버틸 수 있는가
브라우저가 사내 정책 바깥 사이트로 새지 않게 묶을 수 있는가
MCP 서버와 A2A 에이전트가 늘어날수록 중앙 통제가 가능해지는가
로컬에서 24/7 돌아가는 에이전트가 스스로 스킬을 쌓되, 신뢰 가능한 경계를 유지할 수 있는가
미래의 에이전트는 경험을 통해 더 똑똑해질 텐데, 그 학습 루프를 떠받칠 인프라는 무엇인가

오늘 뉴스는 바로 이 질문들에 대한 공식 공급자들의 답변 묶음입니다. 그래서 오늘은 단순히 “새로운 기능이 나왔다”는 날이 아니라, 에이전트 운영체제의 설계 원칙이 한 단계 더 또렷해진 날로 읽는 편이 맞습니다.

오늘의 핵심 한 문장

2026년 5월 15일의 AI 뉴스는 OpenAI가 Codex를 모바일·원격 환경까지 확장해 비동기 작업 제어면을 넓히고 ChatGPT의 안전 계층을 대화 흐름 단위로 고도화했으며, Anthropic이 중소기업용 업무 패키지로 에이전트 상용화를 밀어 넣고, Google이 미들웨어와 장기 실행 상태 머신으로 에이전트 애플리케이션의 표준 구조를 정리하고, AWS가 브라우저 거버넌스·실시간 음성·MCP/A2A 보안 운영을 구체화하고, NVIDIA가 엔터프라이즈 런타임 보안·로컬 상시 에이전트·대규모 RL 인프라를 함께 밀어 올리면서 AI 경쟁의 무게중심이 모델에서 실행·제어·운영 계층으로 더 강하게 이동한 날로 요약된다.

한눈에 보는 Top News

OpenAI — Work with Codex from anywhere: Codex가 ChatGPT 모바일 앱으로 들어오며 장기 실행 작업의 승인, 방향 수정, 결과 검토를 폰에서 이어갈 수 있게 됐다. Remote SSH, Hooks GA, 프로그램용 토큰, HIPAA 지원 로컬 사용 확대까지 함께 발표됐다.
OpenAI — 민감 대화의 맥락 인식 강화: ChatGPT가 한 턴이 아니라 여러 메시지·여러 대화에 걸쳐 드러나는 위험 신호를 더 잘 감지하도록 safety summaries와 안전 추론을 강화했다.
Anthropic — Claude for Small Business 출시: QuickBooks, PayPal, HubSpot, Canva, Docusign, Google Workspace, Microsoft 365에 Claude를 넣고 15개 워크플로와 15개 스킬을 묶어 중소기업용 업무 자동화 패키지를 발표했다.
Google — Genkit Middleware 공개: 에이전트 앱에 Retry, Fallback, Tool Approval, Skills, Filesystem 같은 미들웨어 훅을 붙이는 공식 구조를 발표했다.
Google — ADK 장기 실행 에이전트 패턴 제시: 상태 머신, 영속 세션, 웹훅 재개, 서브에이전트, 골든 eval을 통해 몇 주짜리 프로세스를 처리하는 에이전트 구조를 구체화했다.
AWS — Bedrock AgentCore Browser에 Chrome enterprise policies 지원: 에이전트 브라우저의 웹 접근 범위와 브라우저 동작을 기업 정책으로 통제하고, custom root CA 인증서로 내부 서비스 접속 장벽도 낮췄다.
AWS — Stream Vision Agents + Amazon Nova 2 Sonic 실시간 음성 패턴 제시: speech-to-speech 모델, 저지연 스트리밍, 자동 재연결, 멀티링구얼 지원을 묶어 프로덕션급 음성 에이전트 구성을 정리했다.
AWS + Cisco — MCP·A2A·Agent Skill 보안 제어면 강화: AI Registry와 Cisco AI Defense 연동으로 등록·가시성·자동 스캔·컴플라이언스 추적을 함께 다루는 모델을 제시했다.
NVIDIA + SAP — Specialized Agent용 신뢰 런타임 강화: SAP Business AI Platform에 NVIDIA OpenShell을 넣어 파일시스템·네트워크 정책과 감사 훅을 갖춘 엔터프라이즈 런타임 계층을 강화했다.
NVIDIA — Hermes 로컬 상시 실행 에이전트 강조: self-evolving skills, contained sub-agents, 로컬 Qwen 3.6, DGX Spark를 묶어 항상 켜진 개인용/현장형 에이전트 방향을 선명하게 밀었다.
NVIDIA + Ineffable Intelligence — 차세대 RL 인프라 공동 설계: 경험 기반 학습을 대규모로 돌리기 위한 interconnect, memory bandwidth, serving, simulation 루프 최적화를 공동 탐색한다고 밝혔다.

오늘 뉴스가 말하는 10개의 큰 흐름

1. 에이전트는 이제 “답변 생성기”보다 “지속 작업자”에 가깝다

OpenAI의 모바일 Codex, Google의 장기 실행 ADK, NVIDIA의 Hermes는 서로 다른 제품처럼 보이지만, 공통 메시지는 분명합니다. 에이전트는 더 이상 한 번 호출하고 끝나는 도구가 아니라 시간에 걸쳐 계속 움직이는 작업자가 되고 있습니다. 이 변화는 UI만의 변화가 아닙니다. 실행 시간, 승인 타이밍, 상태 복원, 휴먼 개입 구조까지 모두 다시 설계해야 함을 뜻합니다.

2. 안전성은 모델 필터가 아니라 실행 경계와 문맥 해석에서 나온다

OpenAI의 민감 대화 안전 개선과 AWS의 브라우저 정책, NVIDIA OpenShell, AWS/Cisco의 레지스트리 모델은 모두 같은 결론으로 이어집니다. AI 안전은 단순 금칙어 필터가 아니라 누가 무엇을 언제 어떤 맥락에서 어디까지 실행할 수 있는가를 체계적으로 다루는 문제입니다.

3. 미들웨어와 정책 계층이 AI 앱의 핵심 경쟁력이 된다

Google Genkit Middleware는 아주 중요한 시그널입니다. 프롬프트만으로는 운영형 앱을 만들 수 없고, retry·fallback·tool approval·filesystem scoping 같은 계층이 표준 부품이 되어야 한다는 뜻입니다. AI 앱은 점점 웹 프레임워크처럼 기본 정책 부품과 훅 구조를 중심으로 발전할 가능성이 큽니다.

4. 중소기업 시장은 “모델 성능”보다 “업무 패키지” 언어로 열린다

Anthropic의 발표는 AI 상용화의 가장 현실적인 방향 중 하나를 보여 줍니다. 작은 회사는 범용 모델의 가능성보다 이번 주 월마감, 송장 추심, 급여 준비, 캠페인 실행처럼 실제 업무가 끝나는 경험에 반응합니다. 이는 앞으로 B2B AI가 더 강하게 버티컬 패키지화될 신호입니다.

5. 브라우저는 다시 중요한 AI 런타임 표면이 된다

AgentCore Browser의 정책 지원은 브라우저를 단순 도구 호출 표면이 아니라 기업 정책이 관통해야 하는 실행 환경으로 재정의합니다. 에이전트가 웹에서 행동하는 순간, 허용 도메인·다운로드·비밀번호 저장·사설 CA 신뢰 체계가 모두 보안 설계의 일부가 됩니다.

6. 실시간 음성은 미디어 시스템과 AI 시스템의 결합 문제다

AWS의 음성 글은 voice agent가 단순히 “말하는 모델” 문제가 아니라는 점을 다시 보여 줍니다. 반응성, WebRTC, 재연결, 세션 수명, 함수 호출, 다국어 경험이 모두 품질을 좌우합니다. 음성은 여전히 다음 큰 인터페이스지만, 실제 구현은 텍스트보다 훨씬 시스템적입니다.

7. 레지스트리와 자동 스캔 없이는 에이전트 확장이 곧 혼란이 된다

MCP·A2A·Agent Skill이 늘어날수록 문제는 모델이 아니라 자산 관리가 됩니다. AWS/Cisco의 글은 AI 보안이 공급망 보안과 서비스 카탈로그 관리에 빠르게 가까워지고 있음을 보여 줍니다.

8. 로컬 에이전트와 대규모 학습 인프라는 동시에 중요해진다

NVIDIA는 같은 시점에 Hermes 같은 로컬 상시형 에이전트와 David Silver의 RL 인프라 협업을 함께 밀었습니다. 이는 미래가 한 방향으로만 가지 않는다는 뜻입니다. 사용자 가까이서 돌아가는 에이전트와 훨씬 더 똑똑한 정책을 학습시키는 초대형 인프라가 함께 발전합니다.

9. “기억”은 이제 개인화 기능이 아니라 안전 기능이기도 하다

OpenAI의 safety summaries는 매우 흥미롭습니다. 메모리나 컨텍스트 보존이 단순한 개인화 UX가 아니라, 드물지만 치명적인 위험을 식별하기 위한 안전 장치로도 설계될 수 있다는 뜻입니다. 앞으로 장기 컨텍스트는 생산성뿐 아니라 책임 있는 응답에서도 중요해집니다.

10. AI의 성숙은 결국 운영 설계 문서의 밀도로 드러난다

오늘 공식 발표들은 대체로 덜 화려하지만 더 실무적입니다. 상태 머신, 툴 승인, 인증서, 브라우저 정책, 레지스트리, 세션 저장, 감사, 하드웨어 프로파일 같은 단어가 전면에 나옵니다. 이는 시장이 초기 흥분을 지나 운영 밀도와 제어 가능성을 중심으로 성숙하고 있다는 신호입니다.

1) OpenAI — Work with Codex from anywhere

무엇이 발표됐나

OpenAI는 Work with Codex from anywhere를 통해 Codex를 ChatGPT 모바일 앱 안으로 넣고, 데스크톱이나 원격 개발 환경에서 돌아가는 작업을 폰에서도 이어서 관리할 수 있게 했습니다. 단순 원격 뷰어가 아닙니다. 공식 설명에 따르면 사용자는 모바일에서 다음을 직접 수행할 수 있습니다.

활성 스레드 확인
결과물 검토
승인이 필요한 명령 승인
모델 변경
진행 방향 수정
새 작업 시작
프로젝트 컨텍스트와 플러그인 상태 확인

핵심은 작업이 실행되는 장소와 작업을 감독하는 장소를 분리했다는 점입니다. 코드, 자격증명, 파일, 권한은 여전히 원래 머신에 남아 있고, 폰으로는 스크린샷, 터미널 출력, diff, 테스트 결과, 승인 요청 같은 제어 정보만 흘러옵니다. OpenAI는 이를 위해 trusted machine을 공용 인터넷에 직접 노출하지 않는 secure relay layer를 언급했습니다.

여기에 함께 붙은 확장도 의미가 큽니다.

Remote SSH GA: 관리형 원격 환경이나 devbox에 직접 연결
Programmatic access tokens: CI, release workflow, 내부 자동화를 위한 범위 제한 토큰
Hooks GA: 비밀정보 스캔, validator 실행, 대화 로깅, memory 생성, 저장소/디렉터리별 커스터마이징
HIPAA-compliant local use: ChatGPT Enterprise 로컬 환경에서의 적격 지원 확대

핵심 팩트

OpenAI는 Codex 주간 사용자가 400만 명을 넘었다고 밝혔다.
모바일 경험은 단순 알림 수신이 아니라 live state를 이어받아 작업을 이어가는 구조다.
사용자의 파일, 자격증명, 권한은 작업이 실행되는 원래 머신에 남는다.
업데이트는 스크린샷, 터미널 출력, diff, 테스트 결과, 승인 요청 형태로 실시간 동기화된다.
Remote SSH는 SSH 설정에 있는 호스트를 데스크톱 앱이 자동 감지해 프로젝트와 스레드를 열 수 있다고 설명한다.
Hooks는 이제 GA이며 보안/검증/로그/메모리/리포별 커스터마이징 계층으로 소개됐다.
Programmatic access tokens는 Enterprise/Business 중심 자동화 토큰으로 제시됐다.

왜 중요한가

이 발표의 진짜 의미는 “이제 폰에서도 Codex를 쓸 수 있다”에 있지 않습니다. 더 본질적인 의미는 에이전트의 실행 시간과 인간의 주의 시간 사이의 간격을 메우는 제어면이 생겼다는 데 있습니다.

장기 실행 작업의 가장 흔한 병목은 모델 성능이 아닙니다. 실제로는 다음과 같은 사람의 개입 타이밍이 더 중요합니다.

두 개의 접근법 중 하나를 선택해야 하는 순간
destructive action 전 승인해야 하는 순간
추가 컨텍스트를 넣어 주어야 하는 순간
테스트 실패를 보고 우선순위를 바꿔야 하는 순간
회의 직전 요약만 먼저 받고 싶어지는 순간

그동안 이런 제어는 대개 작업이 돌아가는 그 머신 앞에 앉아 있을 때만 자연스러웠습니다. OpenAI는 이를 깨고 에이전트 협업을 장소 독립형으로 만든 것입니다. 이건 작은 편의 기능처럼 보이지만, 장기적으로는 AI 협업 UX의 기본 문법이 될 가능성이 큽니다.

또 하나 중요한 것은, OpenAI가 모바일 확장과 동시에 Remote SSH·Hooks·Programmatic token을 같이 꺼냈다는 점입니다. 이는 Codex를 단순 소비자 기능이 아니라 개인 개발 환경, 관리형 원격 환경, 엔터프라이즈 자동화, 컴플라이언스 경계를 가로지르는 작업 플랫폼으로 키우고 있다는 신호입니다. 다시 말해 Codex는 이제 모델 호출기라기보다 작업 스레드, 권한, 검사 훅, 원격 런타임을 품은 에이전트 운영 계층에 가까워지고 있습니다.

개발자에게 의미

첫째, AI 작업을 동기식 인터랙션으로만 설계하면 곧 한계에 부딪힌다는 점입니다. 사용자가 입력하고 곧바로 응답받는 UX는 여전히 중요하지만, 실제 가치가 큰 작업은 점점 더 오래 걸립니다. 버그 조사, 리팩터링, 문서 합성, 지원 이슈 정리, CI 수정, 릴리스 준비 같은 작업은 시간이 필요합니다. 따라서 좋은 AI 개발 도구는 “빨리 답하는 능력”뿐 아니라 “오래 일하는 동안 올바른 순간에 사용자를 다시 끌어오는 능력”이 필요합니다.

둘째, 승인 UX가 제품 핵심으로 승격된다는 점입니다. 승인 버튼이 귀찮은 보안 장식이 아니라, 장기 실행 작업을 지속시키는 리듬의 일부가 됩니다. 잘 설계된 승인 UX는 작업을 멈추지 않게 하고, 나쁜 승인 UX는 결국 사용자를 Full Access 모드로 몰아갑니다.

셋째, 훅과 토큰은 에이전트 확장을 위한 플랫폼화 장치입니다. 훅은 사실상 로컬 정책 엔진에 가깝고, 프로그램용 토큰은 에이전트를 CI/CD나 운영 자동화와 연결하는 안전한 손잡이입니다. 개발자는 이를 통해 단순 대화 UI를 넘어 리포별 검사, 민감정보 방지, 커스텀 워크플로를 제품에 녹일 수 있습니다.

넷째, 로컬/원격 경계가 사용자 경험에서 희미해진다는 점입니다. 데스크톱, Mac mini, devbox, managed remote environment가 모두 하나의 live state 경험 안으로 들어오면, 사용자는 “어디서 돌고 있는가”를 덜 신경 쓰게 됩니다. 대신 제품팀은 그 뒤에서 권한, 네트워크, 파일, 세션 동기화를 훨씬 더 정교하게 다뤄야 합니다.

운영 포인트

제어 데이터와 실행 데이터 분리: 모바일에는 스레드 상태, 승인, 로그, diff만 보내고 실제 자격증명과 파일은 원래 환경에 남기는 구조가 바람직하다.
승인 우선순위 설계: 사용자가 폰에서 처리할 수 있는 승인과 반드시 데스크톱 검토가 필요한 승인을 구분해야 한다.
중간 산출물 압축: 스크린샷, 테스트 결과, diff를 너무 많이 보내면 오히려 사용자가 피로해진다. 요약 계층이 필요하다.
원격 환경 수명 관리: SSH 대상 devbox나 장기 실행 작업이 orphan 상태가 되지 않도록 session lifecycle 관리가 필요하다.
훅 표준화: secret scan, validator, repo-specific rules를 조직 표준 훅으로 배포하면 품질을 일관되게 만들 수 있다.
승인 이력 로그: 누가 어떤 작업에 어떤 시점에 승인했는지 남겨야 신뢰와 복구가 가능하다.

더 깊은 해석

이번 발표는 AI 개발 도구의 중심이 IDE 패널에서 멀티디바이스 작업 운영체제로 이동하고 있음을 보여 줍니다. IDE 안의 코드 생성만으로는 길게 가기 어렵습니다. 실제 시장은 점점 다음 조합을 원합니다.

작업은 백그라운드에서 오래 돌아가고
사용자는 여러 장소에서 개입하고
정책은 훅과 승인으로 관통하며
환경은 로컬·원격·엔터프라이즈를 넘나들고
결과는 diff와 테스트 중심으로 검토되는 구조

이 관점에서 보면 OpenAI의 발표는 모바일 기능 추가가 아니라 에이전트 협업의 시간 구조를 재편하는 시도입니다. 코딩 에이전트가 더 강력해질수록 사람은 점점 더 “직접 타이핑하는 개발자”라기보다 “작업 감독자, 정책 승인자, 방향 결정자” 역할을 하게 됩니다. 오늘 OpenAI는 그 역할 전환에 맞는 인터페이스를 내놓은 셈입니다.

실전 질문

우리 팀의 AI 작업은 사용자가 자리에 없을 때도 자연스럽게 계속 흐르는가?
승인 요청은 적시에 오고, 모바일에서도 처리 가능한 수준으로 압축되어 있는가?
훅을 통해 리포별 정책과 검사 규칙을 일관되게 강제하고 있는가?
원격 개발 환경과 로컬 환경을 사용자가 하나의 작업 컨텍스트처럼 느끼게 할 수 있는가?

2) OpenAI — 민감 대화의 맥락 인식 강화

무엇이 발표됐나

OpenAI는 Helping ChatGPT better recognize context in sensitive conversations를 통해, ChatGPT가 위험 신호를 한 문장이나 한 턴이 아니라 대화 전체의 흐름과 여러 대화 사이의 안전 관련 문맥에서 더 잘 읽을 수 있도록 안전 업데이트를 공개했습니다. 초점은 자살·자해·타인 위해 같은 acute high-risk 시나리오입니다.

핵심 메커니즘으로 OpenAI는 safety summaries를 설명합니다. 이는 일반 개인화 메모리가 아니라, 드물지만 심각한 안전 우려가 생길 때만 제한적으로 생성되는 짧고 사실 중심의 안전 요약입니다. 이 요약은 별도 안전 추론 모델에 의해 생성되며, 좁은 범위로 제한되고, 제한된 시간 동안만 유지되고, 심각한 안전 우려가 관련될 때만 사용된다고 밝혔습니다.

핵심 팩트

OpenAI는 문맥이 민감 대화에서 단일 메시지 못지않게 중요하다고 설명한다.
safety summaries는 일반 기억이나 개인화 기능이 아니라 안전 관련 문맥만을 다루는 제한적 메커니즘으로 소개됐다.
이 작업은 정신건강 전문가, 법심리·자살 예방·자해 전문가 자문을 받았다고 밝혔다.
내부 평가에서 긴 단일 대화 시나리오의 safe-response 성능이 자살·자해 사례에서 50%, 타인 위해 사례에서 16% 향상됐다고 설명했다.
여러 대화에 걸친 평가에서 GPT‑5.5 Instant 기준 타인 위해 52%, 자살·자해 39% 개선 수치를 제시했다.
safety summaries 품질 평가는 4,000개 이상 평가에서 safety relevance 4.93/5, factuality 4.34/5를 기록했다고 밝혔다.
일상적 대화에서는 응답 품질 저하가 유의미하게 나타나지 않았다고 설명했다.

왜 중요한가

AI 업계는 종종 “메모리”를 생산성이나 개인화 기능으로만 이야기합니다. 하지만 OpenAI의 이번 발표는 장기 컨텍스트가 안전 시스템의 일부가 될 수 있음을 보여 줍니다. 이건 매우 중요한 방향 전환입니다.

실제 위험 상황은 대개 한 번에 노골적으로 드러나지 않습니다. 오히려 다음처럼 서서히 드러납니다.

처음엔 모호한 절망감 표현
다음엔 간접적인 도움 요청
이후엔 구체적 방법에 가까운 질문
또는 서로 다른 대화에서 단편적으로 나타나는 위험 신호

단일 턴만 보면 무해하거나 모호한 요청도, 앞뒤 문맥과 결합하면 의미가 완전히 달라집니다. 따라서 더 안전한 시스템을 만들려면, 단순히 입력 텍스트 한 번을 분류하는 방식으로는 한계가 있습니다. OpenAI는 이를 공식적으로 인정하고 문맥 연결형 안전 추론을 전면에 올렸습니다.

또 하나 중요한 점은 이 발표가 “더 많이 기억한다”가 아니라 “안전 관련 문맥만 제한적으로 사용한다”고 선을 그었다는 것입니다. 이는 장기 컨텍스트가 가져올 수 있는 프라이버시 우려를 의식한 설계로 읽힙니다. 즉, OpenAI는 메모리 확대와 안전 강화를 같은 방향으로 밀지 않고, 안전 목적의 좁은 메모리 계층을 따로 설명하고 있습니다.

개발자에게 의미

첫째, 안전성은 단발성 분류기의 문제가 아니다는 점입니다. 민감 시나리오는 보통 상태 변화와 맥락 누적의 문제입니다. 따라서 장기 컨텍스트를 다루는 제품일수록 안전 계층도 상태 기반으로 설계해야 합니다.

둘째, 메모리 기능을 설계할 때 목적별 분리가 중요하다는 점입니다. 사용성 메모리, 개인화 메모리, 안전 메모리, 컴플라이언스 기록은 같은 저장소에 섞는 순간 복잡성과 리스크가 함께 커집니다. OpenAI의 설명은 좁은 목적의 사실 요약을 별도 설계하는 방향성을 보여 줍니다.

셋째, 전문가 참여가 안전 품질을 실질적으로 바꾼다는 점도 중요합니다. 자살 예방, 법심리, 자해 분야의 외부 전문가가 어떤 신호를 봐야 하는지, 얼마 동안 어떤 문맥을 봐야 하는지 자문했다는 사실은, 고위험 도메인에서 안전 규칙을 단순히 모델 팀 내부에서만 설계해서는 부족하다는 점을 상기시킵니다.

넷째, 평가 설계가 바뀌어야 한다는 점입니다. 한 턴 기준 refusal 정확도만 측정하면 이런 개선은 잘 보이지 않습니다. 실제로는 여러 턴, 여러 세션, 위험 신호의 점진적 강화 같은 평가가 필요합니다. OpenAI가 다중 대화 평가를 별도로 공개한 이유도 여기에 있습니다.

운영 포인트

목적 제한 메모리: 안전 메모리는 일반 개인화 메모리와 분리하고 사용 범위를 명확히 제한해야 한다.
보존 기간 정책: 어떤 문맥을 얼마나 오래 고려할지 시간 경계를 명시해야 한다.
사실성 우선: 요약은 해석보다 사실 중심이어야 하고, 과잉 추론이 최소화되어야 한다.
고위험 분야 전문가 검토: 내부 정책만으로는 놓치기 쉬운 신호를 외부 전문가와 함께 보정해야 한다.
일상 대화 영향 측정: 안전 강화가 일반 대화 품질을 해치지 않는지 별도 평가가 필요하다.
감사 가능성: 왜 특정 응답이 더 조심스러워졌는지 내부적으로 설명 가능한 흔적을 남겨야 한다.

더 깊은 해석

OpenAI의 이번 발표는 에이전트 시대의 안전이 단순한 콘텐츠 필터링을 넘어 상태 인식형 거버넌스로 이동하고 있음을 보여 줍니다. 이는 이후 biology, cyber 같은 다른 고위험 영역에도 영향을 줄 가능성이 큽니다. 왜냐하면 그런 영역도 맥락 누적과 의도 변형이 중요하기 때문입니다.

한편 이 발표는 제품 전략 측면에서도 시사점이 있습니다. 장기 세션, 멀티스레드, 멀티디바이스 경험을 강화할수록 사용자는 더 풍부한 문맥을 남기게 됩니다. 그 문맥은 생산성에 도움이 되지만, 동시에 안전 계층이 더 세심하게 다뤄야 할 대상이 됩니다. 즉, 장기 기억을 키우는 제품일수록 장기 안전 설계를 같이 키워야 한다는 뜻입니다.

실전 질문

우리 제품의 안전 시스템은 한 턴만 보고 판단하고 있지 않은가?
메모리와 안전 문맥을 목적별로 분리해 설계하고 있는가?
여러 세션에 걸친 위험 누적을 평가할 수 있는 테스트셋이 있는가?
전문가가 봤을 때 우리의 안전 요약은 사실 중심이고 과잉 추론이 없는가?

3) Anthropic — Claude for Small Business

무엇이 발표됐나

Anthropic은 Introducing Claude for Small Business를 통해 중소기업을 위한 업무 자동화 패키지를 공식 발표했습니다. 제품 포지셔닝은 분명합니다. Claude를 별도 AI 툴로 배우게 하기보다, 중소기업이 이미 쓰는 도구 안으로 Claude를 넣어 실제 반복 업무를 처리하게 한다는 전략입니다.

Anthropic이 제시한 연결 도구는 다음과 같습니다.

Intuit QuickBooks
PayPal
HubSpot
Canva
Docusign
Google Workspace
Microsoft 365

그리고 이 위에 15개의 ready-to-run agentic workflows와 15개의 skills를 얹었습니다. 예시로는 payroll planning, month-end close, invoice chasing, business pulse, campaign preparation, contract review, lead triage, tax-season organizer 등이 언급됩니다. 중요한 점은 Anthropic이 모든 실행은 사용자가 시작하고, 발송·게시·지급 전에는 승인한다고 명시했다는 것입니다.

여기에 PayPal과 함께 하는 무료 교육 과정 AI Fluency for Small Business, 미국 여러 도시를 도는 SMB Tour, 비영리/지역기관과의 파트너십까지 붙였습니다. 즉 이번 발표는 단순 기능 출시가 아니라 도입 패키지 전체에 가깝습니다.

핵심 팩트

Claude for Small Business는 Claude Cowork 내부 toggle install 방식으로 설명됐다.
15 workflows + 15 skills를 제공한다고 밝혔다.
QuickBooks, PayPal, HubSpot, Canva, Docusign, Google Workspace, Microsoft 365 연결을 전면에 내세웠다.
대표 시나리오로 payroll, month-end close, invoice chasing, campaign prep, business pulse, contract review 등을 제시했다.
사용자가 계획을 승인하고, 전송·게시·지급 전 최종 통제를 유지하는 구조를 강조했다.
Team/Enterprise 플랜에서는 기본적으로 고객 데이터를 학습에 사용하지 않는다고 재확인했다.
교육 과정, 현장 투어, 소상공인·CDFI 파트너십까지 함께 발표했다.

왜 중요한가

이 발표는 AI 상용화의 가장 현실적인 방향 하나를 보여 줍니다. 중소기업은 대기업처럼 AI 전담팀을 두고 커스텀 워크플로를 설계하기 어렵습니다. 그래서 이 시장에서 이기는 제품은 대개 다음 조건을 만족해야 합니다.

이미 쓰는 툴 위에 얹힌다
해야 할 일이 사전에 패키징돼 있다
승인 구조가 직관적이다
데이터 경계가 기존 권한 모델을 따른다
교육과 도입 지원이 함께 온다

Anthropic은 이번에 정확히 이 다섯 가지를 겨냥했습니다. 이건 단순히 SMB 시장 진입이 아니라, 에이전트를 “업무 묶음” 단위로 판매하는 모델의 본격화로 봐야 합니다. 사용자는 “Claude가 뭘 할 수 있지?”보다 “오늘 야근해야 할 급여 준비와 월마감을 대신 줄여 줄 수 있나?”에 반응합니다.

또한 Anthropic은 실행 전 승인 구조를 강하게 유지했습니다. 이는 B2B AI 시장에서 여전히 완전 자율보다 강한 보조 + 명확한 승인이 더 현실적인 상용화 모델임을 보여 줍니다. 중소기업은 인력과 여유가 부족하지만, 그렇다고 결제·계약·급여를 블랙박스 에이전트에 넘기고 싶어 하지는 않습니다.

개발자에게 의미

첫째, 커넥터보다 업무 패키지가 더 중요한 제품 언어라는 점입니다. 커넥터는 수단이고, 사용자는 결과를 삽니다. 따라서 AI 제품 설명도 “QuickBooks와 연결됩니다”보다 “이번 주 현금흐름을 보고 급여 계획과 미수금 리마인드를 한 번에 준비합니다”가 더 강합니다.

둘째, 승인 구조는 SMB에서도 핵심이라는 점입니다. 많은 팀이 중소기업 시장을 “설정은 적고 자동화는 세게”로만 생각하지만, 실제로는 신뢰를 얻는 쪽이 먼저입니다. Anthropic은 인간이 시작하고 승인하는 패턴을 전면에 둠으로써 도입 문턱을 낮췄습니다.

셋째, AI 도입에는 교육이 제품 못지않게 중요하다는 점입니다. 사용자가 어떤 업무에 AI를 써야 하는지 모르고, 어떤 데이터를 연결해도 되는지 불안해하면 기능은 묻힙니다. Anthropic이 AI Fluency 과정을 같이 붙인 것은 제품-교육 결합이 점점 더 중요해지고 있음을 보여 줍니다.

넷째, 권한 상속이 신뢰의 핵심입니다. “직원이 QuickBooks에서 못 보던 걸 Claude를 통해 우회해서 볼 수 없다”는 원칙은 단순한 보안 문구가 아니라 제품 신뢰의 바닥입니다. B2B AI 제품은 기존 SaaS 권한 모델을 훼손하는 순간 빠르게 거부감을 부릅니다.

운영 포인트

기존 권한 상속 보장: 원 시스템에서 보지 못하는 데이터는 AI를 통해서도 못 보게 해야 한다.
부분 실패 처리: QuickBooks는 성공했지만 PayPal 동기화가 실패하는 경우의 UX를 미리 설계해야 한다.
승인 전 미리보기 품질: 발송·게시·지급 전 보여 주는 계획 요약이 짧고 명확해야 한다.
업무 시즌성 관리: 월말·분기말·세금 시즌처럼 사용량이 몰리는 순간을 버틸 구조가 필요하다.
도구 간 데이터 정합성: 각 커넥터의 타임라인과 동기화 지연이 다를 때 무엇을 진실 소스로 볼지 정해야 한다.
온보딩 단순화: 너무 많은 스킬을 노출하면 중소기업 사용자는 오히려 시작을 못 한다. 추천형 entry point가 중요하다.

더 깊은 해석

Anthropic은 이번에 단순한 제품 출시가 아니라 에이전트 시장의 패키징 방정식을 내놓았습니다.

사용자는 자기 도구 안에 AI가 들어오길 원한다.
AI는 범용 능력보다 반복 업무 묶음으로 제시될 때 구매 이유가 선명해진다.
신뢰는 자율성보다 승인과 권한 상속에서 나온다.
교육과 현장 지원 없이는 실제 도입이 느리다.
파트너 생태계는 단순 마케팅 채널이 아니라 도메인 컨텍스트 공급원이다.

이 모델은 앞으로 다른 벤더들에게도 빠르게 복제될 가능성이 높습니다. 회계용 패키지, 영업 운영 패키지, 리걸 패키지, 의료 운영 패키지, 개발 릴리스 패키지처럼 도메인별 ready-made AI workflows 경쟁이 심화될 수 있습니다.

실전 질문

우리 제품은 “기능 목록”이 아니라 “완결된 업무 묶음” 언어로 설명되고 있는가?
승인 구조를 넣었을 때도 충분히 빠른 경험을 제공하는가?
각 커넥터의 진실 소스와 부분 실패 처리 방식을 명확히 정의했는가?
교육과 도입 지원을 제품 밖 문제로 밀어내고 있지는 않은가?

4) Google — Genkit Middleware

무엇이 발표됐나

Google은 Announcing Genkit Middleware: Intercept, extend, and harden your agentic apps를 통해 Genkit에 미들웨어 계층을 공식 도입했습니다. 이 발표의 핵심은 아주 명확합니다. 운영형 에이전트 앱은 강한 모델과 신중한 프롬프트만으로는 부족하다는 것입니다. 실제로 필요한 것은 retry, fallback, human approval, observability, filesystem scoping 같은 정책 계층입니다.

Genkit은 generate() 호출 내부의 tool loop를 세 층으로 가로채는 훅 구조를 제시합니다.

Generate hook: tool-loop iteration 단위
Model hook: model API call 단위
Tool hook: tool execution 단위

그리고 Google은 바로 쓸 수 있는 pre-built middleware로 다음을 제시했습니다.

Retry
Fallback
Tool Approval
Skills
Filesystem

단순 기능 나열 같지만, 사실상 이는 에이전트 앱의 정책 엔진 표준 부품을 공개한 것에 가깝습니다.

핵심 팩트

Genkit은 TypeScript, Go, Dart에서 미들웨어를 지원하고 Python은 추후 지원 예정이라고 밝혔다.
Retry는 transient model errors에 대해 exponential backoff with jitter를 적용한다.
Fallback은 특정 에러 코드에서 대체 모델로 전환한다.
Tool Approval은 allow-list 밖의 도구 실행을 interrupt로 만들고 사람 승인을 거쳐 재개하게 한다.
Skills middleware는 SKILL.md를 스캔해 시스템 프롬프트에 주입하고, 필요 시 use_skill 툴을 노출한다.
Filesystem middleware는 root directory를 벗어나지 못하도록 path safety를 강제한다.
Dev UI에서 middleware 실행과 설정을 시각적으로 추적할 수 있다고 설명했다.

왜 중요한가

Genkit Middleware는 작아 보이지만 매우 전략적인 발표입니다. 지금 많은 팀이 에이전트 앱을 만들 때 실제로 겪는 어려움은 모델 API를 부르는 데 있지 않습니다. 더 힘든 것은 다음입니다.

quota나 일시 장애가 났을 때 어떤 재시도 정책을 쓸 것인가
어떤 도구는 바로 실행하고 어떤 도구는 사람이 승인해야 하는가
리포나 워크스페이스 루트를 어떻게 제한할 것인가
특정 팀 규칙, 금지어, 감사 로깅, 회복 정책을 어디에 넣을 것인가
모델 호출과 툴 호출 사이의 실행 흐름을 어떻게 추적할 것인가

이런 요구를 매번 앱 코드에 직접 넣으면 곧 복잡성이 폭발합니다. Google은 이를 해결하기 위해 프롬프트 바깥의 정책 부품을 표준화하고 있습니다. 이는 AI 개발이 점점 전통적인 애플리케이션 프레임워크에 가까워지고 있음을 보여 줍니다.

특히 Tool Approval과 Filesystem은 매우 상징적입니다. 이것은 Google조차 에이전트 앱에서 핵심 문제가 “답변 품질”만이 아니라 실행 권한과 경계 제어라고 보고 있다는 뜻입니다. 다시 말해 운영형 AI 앱의 핵심은 모델과 UI만이 아니라 미들웨어로 구현되는 정책층입니다.

개발자에게 의미

첫째, 프롬프트에 모든 정책을 우겨 넣는 방식은 한계가 분명하다는 점입니다. 경쟁사 언급 금지, 내부 가격 노출 금지, 특정 툴 승인 필요, 특정 경로 접근 제한 같은 규칙은 모델에게 예절로 부탁할 일이 아니라 시스템적으로 강제해야 합니다.

둘째, Tool loop 자체가 제품 설계 단위가 된다는 점입니다. 그동안 많은 개발자는 generate()를 “한 번 모델 부르기” 정도로 생각했지만, 에이전트 앱에서는 모델 호출과 툴 실행이 여러 번 오가며 하나의 루프를 이룹니다. 정책도 이 루프 어디에 걸 것인지에 따라 의미가 달라집니다.

셋째, 미들웨어는 팀 간 공통 자산이 된다는 점입니다. 보안팀은 tool approval과 filesystem 정책을, 플랫폼팀은 retry와 fallback을, 제품팀은 custom content filter나 context injector를 표준 패키지로 공유할 수 있습니다.

넷째, 기본 부품이 생기면 에이전트 앱 품질의 바닥선이 올라간다는 점입니다. 모든 팀이 각자 재시도/대체/승인/파일 접근을 새로 짜는 대신, 더 높은 수준의 도메인 설계에 집중할 수 있습니다.

운영 포인트

정책 위치를 명확히 구분: generate-level, model-level, tool-level에서 각각 무엇을 다룰지 기준을 세워야 한다.
interrupt UX 표준화: 승인 중단 후 재개 흐름이 사용자와 개발자 모두에게 일관되어야 한다.
filesystem root 최소화: 모델이 접근 가능한 디렉터리 범위를 좁게 시작하는 편이 안전하다.
fallback 전략 명시화: quota 초과, latency spike, provider 장애 때 어떤 대체 경로를 쓸지 정해 둬야 한다.
middleware ordering 관리: retry가 content filter를 감싸는지, 그 반대인지에 따라 결과가 달라진다.
trace 수집: 어떤 미들웨어가 어느 호출에서 개입했는지 관측 가능해야 디버깅이 쉬워진다.

더 깊은 해석

Genkit Middleware는 사실상 AI 앱용 서버 미들웨어 문화의 시작점처럼 읽힙니다. 웹 프레임워크 세계에서 logging, auth, rate limit, caching, error handling이 공통 미들웨어가 된 것처럼, AI 앱도 곧 다음을 기본 부품으로 여기게 될 수 있습니다.

retry/backoff
provider fallback
human approval
audit logging
memory injection
tool permissioning
filesystem/network scope
content policy filter
model cost/latency instrumentation

즉 앞으로의 AI 프레임워크 경쟁은 누가 더 많은 모델을 붙이느냐보다, 누가 더 좋은 정책 훅과 운영 기본기를 제공하느냐에서 갈릴 가능성이 큽니다. Google은 이번 발표로 그 방향을 아주 선명하게 보여 줬습니다.

실전 질문

우리 앱의 정책은 프롬프트에만 들어가 있고 시스템 계층에는 없는가?
tool execution 전후에 어떤 훅을 넣어야 하는지 팀 공통 기준이 있는가?
retry/fallback/approval/filesystem scoping을 표준 부품으로 재사용하고 있는가?
trace를 보면 어느 미들웨어가 어떤 결정을 바꿨는지 설명 가능한가?

5) Google — ADK 장기 실행 에이전트 패턴

무엇이 발표됐나

Google은 Build Long-running AI agents that pause, resume, and never lose context with ADK를 통해 장기 실행 에이전트를 만드는 공식 패턴을 상세히 제시했습니다. 예시는 신입 직원 온보딩 코디네이터지만, 핵심은 특정 도메인이 아니라 구조입니다.

Google이 제시한 세 가지 구조적 전환은 다음과 같습니다.

durable memory schema
event-driven dormancy gate
multi-agent delegation

이 구조 아래에서 ADK는 상태 머신, ToolContext.state, persistent SQLite/Cloud SQL sessions, webhook-based resume, sub-agent delegation, golden eval을 연결합니다. 즉, 에이전트는 더 이상 긴 대화 기록을 들고 다니는 챗봇이 아니라 상태를 가진 백그라운드 프로세스로 정의됩니다.

핵심 팩트

Google은 stateless chatbot 패턴의 한계로 context pollution, token cost explosion, idle time hallucinations를 지적했다.
예시 상태는 START, WELCOME_SENT, DOCUMENTS_SIGNED, IT_PROVISIONED, HARDWARE_DELIVERED, COMPLETED다.
agent instruction은 current_step, new_hire_details, pending_signals 같은 상태 변수를 직접 읽는다.
tool 호출마다 ToolContext.state를 통해 상태를 원자적으로 갱신한다.
session_service_uri를 통해 SQLite/Cloud SQL에 영속 세션을 둘 수 있다고 설명했다.
webhook endpoint로 document_signed, hardware_delivery 같은 외부 이벤트를 받아 에이전트를 다시 깨운다.
IT provisioning은 별도 sub-agent로 위임하는 구조를 예시로 들었다.

왜 중요한가

이 발표는 오늘 나온 자료 중에서도 특히 구조적 가치가 큽니다. 왜냐하면 많은 팀이 여전히 장기 워크플로를 “길어진 채팅”으로 구현하려 하기 때문입니다. 하지만 현실의 업무는 그보다 훨씬 더 워크플로 엔진에 가깝습니다.

예를 들어 HR 온보딩, invoice dispute, procurement approval, partner contract review, hardware shipping, sales sequence는 모두 이런 특징을 가집니다.

며칠 또는 몇 주에 걸친 idle time
외부 시스템 이벤트 대기
단계별 상태 전이
부분 완료와 보류
사람 승인과 팀 간 핸드오프
프로세스 재시작 가능성

이런 플로우를 채팅 로그만으로 운영하면 모델은 쉽게 헷갈리고, 비용은 불어나고, 재시작은 취약해집니다. Google은 이 문제를 정면으로 다뤄 대화와 상태를 분리하라고 말합니다. 이건 장기 실행 에이전트의 가장 중요한 설계 원칙 중 하나입니다.

개발자에게 의미

첫째, 대화는 UI이고 상태는 시스템의 진실이라는 점입니다. 현재 단계, 대기 중 신호, 완료된 액션, 남은 승인 항목은 채팅 기록에서 추론할 일이 아니라 별도 상태로 저장해야 합니다.

둘째, tool 호출이 체크포인트 역할을 하게 설계해야 한다는 점입니다. Google 예시에서 send_welcome_packet이 끝나는 순간 상태가 WELCOME_SENT로 저장되기 때문에, 그 직후 컨테이너가 죽어도 복원 가능합니다. 많은 에이전트 앱이 이 지점을 놓쳐서 “모델은 응답했지만 상태는 안 남았다”는 모순에 빠집니다.

셋째, webhook-based resume가 핵심 인터페이스가 된다는 점입니다. 문서 서명, 하드웨어 배송, 결제 승인, 계약 체결 같은 사건은 사용자 메시지가 아니라 외부 이벤트입니다. 따라서 장기 실행 에이전트는 외부 시스템과의 이벤트 연결을 1급 시민으로 다뤄야 합니다.

넷째, sub-agent는 유행어가 아니라 컨텍스트 품질 도구입니다. 한 에이전트가 모든 것을 다 알고 다 하게 하면 프롬프트와 상태가 빠르게 비대해집니다. 특정 단계나 특정 도메인 책임을 분리하는 편이 더 운영 친화적입니다.

다섯째, 평가도 멀티데이 시나리오로 바뀌어야 합니다. idle time, duplicate webhook, out-of-order event, server restart 같은 현실적 실패를 평가에 넣지 않으면 프로덕션에서 빠르게 무너집니다.

운영 포인트

상태 전이 표 문서화: 허용된 상태와 전이를 명시적으로 문서로 관리해야 한다.
idempotent resume: 같은 webhook이 두 번 와도 같은 상태로 안정적으로 수렴해야 한다.
세션 보존 정책: 몇 주짜리 세션을 언제 expire할지 정해야 한다.
state schema versioning: 장기 실행 중인 세션이 있는 상태에서 스키마가 바뀔 때 마이그레이션 계획이 필요하다.
하위 에이전트 권한 분리: 서브에이전트는 필요한 최소 도구만 갖게 해야 한다.
상태·채팅·툴 로그 분리 관측: 세 가지를 한데 섞으면 원인 파악이 어려워진다.
휴먼 오버라이드 경로: 사람이 현재 step을 강제로 수정하거나 수동 완료 처리할 수 있는 관리자 경로가 필요하다.

더 깊은 해석

Google의 발표는 AI 에이전트가 사실상 워크플로 엔진 + 정책 런타임 + LLM 추론기의 결합물로 수렴하고 있음을 보여 줍니다. 이 관점은 중요합니다. 에이전트를 여전히 프런트엔드 기능처럼만 보면, 배포 이후 곧 아래와 같은 질문에 막히게 됩니다.

현재 이 에이전트는 어디까지 왔는가
왜 지금은 아무것도 하지 않고 대기 중인가
어떤 외부 신호를 기다리는가
무엇이 이미 완료되었고 무엇이 아직 미완료인가
재시작 후 어디서부터 이어질 것인가
누가 언제 어떤 승인으로 상태를 바꿨는가

좋은 장기 실행 에이전트는 결국 이 질문들에 답할 수 있어야 합니다. Google은 이를 코드와 아키텍처 수준으로 풀어 보여 줬습니다. 오늘 나온 다른 발표들과 연결하면 의미가 더 커집니다. OpenAI는 장기 작업을 멀리서 감독하게 하고, Google은 장기 작업이 기술적으로 깨지지 않게 하는 구조를 보여 줍니다. 둘을 합치면 비동기 AI 협업의 제품/플랫폼 양면이 보입니다.

실전 질문

우리 에이전트의 현재 단계는 채팅 기록이 아니라 명시적 상태로 저장되는가?
tool 호출과 상태 저장이 원자적으로 연결되는가?
webhook 재개는 idempotent한가?
몇 주 뒤 다시 깨워도 같은 업무 맥락을 정확히 복원할 수 있는가?

6) AWS — Bedrock AgentCore Browser의 Chrome enterprise policies와 custom root CA

무엇이 발표됐나

AWS는 Control where your AI agents can browse with Chrome enterprise policies on Amazon Bedrock AgentCore를 통해 AgentCore Browser가 Chrome enterprise policies와 custom root CA certificates를 지원한다고 발표했습니다. 이 기능은 겉보기엔 작아 보여도, 실제 엔터프라이즈 도입에서는 매우 중요합니다.

AWS가 문제로 짚은 지점은 분명합니다.

unrestricted web access는 보안 위험이 크다
에이전트가 승인되지 않은 도메인으로 이동할 수 있다
브라우저 패스워드 매니저에 자격증명을 저장할 수 있다
승인된 워크플로 바깥으로 파일을 다운로드할 수 있다
사설 CA를 쓰는 내부 서비스는 HTTPS 검증 실패로 접속이 막힐 수 있다

즉, 브라우저를 에이전트의 범용 눈과 손으로 쓰기 시작하는 순간, 브라우저는 곧 정책 적용이 필요한 운영 표면이 됩니다.

핵심 팩트

AWS는 unrestricted browser access가 unauthorized domain navigation, password manager use, off-workflow download 문제를 낳을 수 있다고 밝혔다.
AgentCore Browser는 Chrome enterprise policies 지원을 추가했다.
custom root CA certificates 지원을 통해 private CA 기반 내부 서비스 접속 문제를 완화한다고 설명했다.
공식 문맥은 granular control over browser behavior and connectivity에 맞춰져 있다.

왜 중요한가

브라우저 기반 에이전트는 많은 사람이 기대하는 AI의 핵심 사용처입니다. 웹앱을 열고, 버튼을 누르고, 폼을 채우고, 대시보드를 읽고, 사내 툴을 넘나드는 일은 실제 업무와 아주 가깝습니다. 하지만 바로 그 이유 때문에 브라우저는 가장 위험한 실행 환경 중 하나가 됩니다.

사람이 브라우저를 쓸 때는 무의식적 상식이 작동합니다. 수상한 사이트를 피하고, 다운로드를 조심하고, 사내 시스템과 공용 웹을 구분합니다. 에이전트는 이런 상식을 기본으로 가지지 않습니다. 따라서 조직은 다음을 시스템적으로 강제해야 합니다.

어느 도메인까지 갈 수 있는가
어떤 브라우저 동작을 허용할 것인가
어떤 인증서를 신뢰할 것인가
무엇을 저장해도 되는가
다운로드는 어디로 흘러가도 되는가

AWS의 이번 발표는 이 현실을 정면으로 다룹니다. 이는 에이전트 브라우징을 데모에서 운영으로 끌고 가려면, 브라우저 자동화 라이브러리만으로는 부족하고 기업 브라우저 정책 수준의 통제가 필요하다는 뜻입니다.

개발자에게 의미

첫째, 브라우저는 단순 툴이 아니라 정책 엔드포인트라는 점입니다. 많은 개발자가 브라우저 자동화를 기능 구현 관점으로만 보지만, 실제 기업 환경에선 허용 사이트, 인증서 신뢰, 세션 저장, 다운로드 경로까지 모두 설계 대상입니다.

둘째, 사내 서비스 연결 문제는 보안과 사용성의 교차점이라는 점입니다. private CA를 쓰는 내부 서비스에 에이전트가 접속해야 할 때, 인증서 체인이 막히면 실제 도입이 멈춥니다. 반대로 아무 인증서나 느슨하게 허용하면 위험해집니다. custom root CA 지원은 이 두 가지 사이의 실무적 다리를 놓습니다.

셋째, 브라우저 행위 제한은 네트워크 제한과 별개 층이라는 점입니다. 네트워크 egress를 막는 것만으로는 충분하지 않을 수 있습니다. 브라우저 동작 자체에 대한 정책이 필요합니다.

넷째, 에이전트 브라우징은 결국 엔터프라이즈 브라우저 관리 문제와 만난다는 점입니다. 앞으로 브라우저형 에이전트가 퍼질수록 보안팀, 엔드포인트팀, 플랫폼팀이 같은 테이블에 앉아야 할 일이 많아질 것입니다.

운영 포인트

허용 도메인 정책: 브라우저 기반 에이전트가 닿을 수 있는 사이트 범위를 역할별로 좁게 정의해야 한다.
다운로드 통제: 파일 다운로드가 필요한 경우 저장 경로와 후속 처리 정책을 같이 설계해야 한다.
인증서 신뢰 체계 관리: private CA 사용 시 root CA 배포와 갱신 절차를 운영 표준으로 두어야 한다.
세션·자격증명 저장 정책: 브라우저에 무엇을 저장하게 할지 명확히 제한해야 한다.
감사 로그: 어떤 URL에 접근했고 어떤 파일을 내려받았고 어떤 정책이 이를 허용/차단했는지 남겨야 한다.
브라우저와 비브라우저 툴 경계: 브라우저로 처리할 일과 API 툴로 처리할 일을 구분하는 것이 위험 감소에 도움이 된다.

더 깊은 해석

오늘의 AWS 발표는 브라우저 에이전트가 앞으로 갈 길을 잘 보여 줍니다. 초기에 브라우저 에이전트는 “사람 대신 클릭해 준다”는 데모적 매력으로 주목받았습니다. 하지만 엔터프라이즈가 실제로 원하는 것은 그보다 더 구체적입니다.

내가 허용한 시스템 안에서만 움직일 것
사내 인증 체계를 이해할 것
감사 가능한 흔적을 남길 것
외부 웹과 내부 웹을 안전하게 구분할 것
정책을 우회하지 못할 것

즉 브라우저 자동화는 점점 브라우저 거버넌스 문제로 진화합니다. 이 관점에서 보면 AWS의 기능 추가는 작은 옵션이 아니라, 브라우저 기반 에이전트가 프로덕션에 들어가기 위한 필수 바닥공사 중 하나입니다.

실전 질문

우리 브라우저형 에이전트는 어디까지 갈 수 있는지 명확한 도메인 경계가 있는가?
사내 private CA 서비스에 접속할 필요가 있을 때 인증서 신뢰 체계를 안전하게 관리하고 있는가?
다운로드, 자격증명 저장, 세션 지속성 정책이 역할별로 구분되어 있는가?
브라우저 로그를 보안 감사와 운영 디버깅 모두에 활용할 수 있는가?

7) AWS — Stream Vision Agents + Amazon Nova 2 Sonic 실시간 음성 패턴

무엇이 발표됐나

AWS는 Real-time voice agents with Stream Vision Agents and Amazon Nova 2 Sonic에서 Stream의 Vision Agents 오픈소스 프레임워크와 Amazon Bedrock, Amazon Nova 2 Sonic을 결합해 프로덕션급 실시간 음성 에이전트를 빠르게 구축하는 패턴을 제시했습니다. 글은 음성 에이전트를 “모델 하나 붙이면 끝나는 기능”이 아니라, 여러 지연 특성과 실패 모드가 얽힌 시스템 문제로 설명합니다.

AWS가 문제로 정의한 난이도는 다음과 같습니다.

speech-to-speech 모델 오케스트레이션
low-latency audio streaming
connection lifecycle 관리
web, mobile, desktop across consistent UX
function calling
automatic reconnection
multilingual support

즉 이 발표는 음성 에이전트를 단순 인터페이스가 아니라 실시간 미디어 시스템 + 추론 시스템의 결합물로 다룹니다.

핵심 팩트

AWS는 production-grade voice agent가 자연스럽고 responsive하게 느껴지려면 복잡한 엔지니어링이 필요하다고 설명한다.
Stream Vision Agents는 오픈소스 프레임워크로 소개됐다.
Amazon Nova 2 Sonic은 speech-to-speech foundation model로 실시간 양방향 오디오 스트리밍과 native turn detection, function calling capability를 제공한다고 설명됐다.
자동 재연결, 멀티링구얼 음성 지원, 코드 예시가 포함된다고 밝혔다.
핵심 과제는 AI 파이프라인 자체보다도 WebRTC/세션/네트워크/브라우저 차이를 다루는 인프라 부담이라고 강조한다.

왜 중요한가

실시간 음성은 오랫동안 “다음 큰 AI 인터페이스”로 예고됐지만, 실제 서비스 품질을 맞추기는 매우 어렵습니다. 이유는 단순합니다. 텍스트는 몇 초 늦어도 어느 정도 용서받지만, 음성은 300ms, 500ms, 1초 수준의 미세한 지연도 사용자 경험에 바로 드러납니다. 말 끊김, 재연결 지연, turn-taking 오류, 발화 중간 끼어들기 실패는 곧바로 인지됩니다.

AWS의 글이 중요한 이유는 이 현실을 숨기지 않는다는 점입니다. 음성 에이전트의 진짜 난제는 모델이 아니라 종종 다음에 있습니다.

네트워크 상태 변화
session timeout
재연결 논리
브라우저/모바일 호환성
오디오 스트림과 함수 호출 타이밍
대화 리듬 유지

즉 음성 에이전트 경쟁력은 “말을 잘한다”보다 흔들리는 환경에서도 자연스럽게 대화를 이어 간다에서 갈립니다. AWS는 이를 관리형 모델과 오픈소스 프레임워크 결합 패턴으로 설명합니다.

개발자에게 의미

첫째, 음성 에이전트는 인프라 프로젝트라는 점입니다. 많은 팀이 모델만 고르면 된다고 생각하지만, 실제로는 스트리밍, turn detection, reconnect, client compatibility가 절반 이상입니다.

둘째, speech-to-speech 통합 구조는 파이프라인 복잡도를 줄일 수 있다는 점입니다. 전통적 STT→LLM→TTS 분리 파이프라인은 각 단계마다 지연과 오류 누적이 발생합니다. Nova 2 Sonic 같은 구조는 이를 줄이며 더 자연스러운 턴 전환을 노릴 수 있습니다.

셋째, 함수 호출과 음성은 밀접하게 연결된다는 점도 중요합니다. 음성 에이전트가 실제 가치를 내려면 단순 대화보다 예약 확인, 계정 조회, 검색, 요약 같은 도구 호출이 필요합니다. 이때 도구 호출 타이밍과 발화 흐름이 어긋나면 UX가 무너집니다.

넷째, 멀티플랫폼 일관성이 필수입니다. 웹에서는 잘 되는데 모바일 네트워크에서 자주 끊기거나 데스크톱에서 마이크 상태가 달라지면 사용자 신뢰가 빠르게 떨어집니다.

운영 포인트

지연 예산 분해: 캡처, 업로드, 추론, 함수 호출, 오디오 재생까지 구간별 지연을 따로 측정해야 한다.
graceful degradation: 연결 품질이 나빠질 때 텍스트 fallback이나 단순 응답 모드 전환을 준비해야 한다.
세션 생명주기 관리: 재연결 시 무엇을 기억하고 무엇을 버릴지 정책이 필요하다.
언어별 품질 관측: 멀티링구얼일수록 언어별 WER/지연/turn accuracy를 따로 봐야 한다.
함수 호출 피드백 설계: 도구 호출이 길어질 때 사용자가 침묵으로 느끼지 않게 중간 피드백을 줘야 한다.
클라이언트 테스트 매트릭스: 브라우저/OS/모바일 조합별 음성 성능 차이를 정기적으로 측정해야 한다.

더 깊은 해석

실시간 음성은 AI를 훨씬 더 인간적인 인터페이스로 만들어 주지만, 동시에 훨씬 더 무자비한 품질 시험장이기도 합니다. 텍스트 UI에서는 사용자가 모델 추론을 어느 정도 기다려 줍니다. 음성에서는 그렇지 않습니다. 잠깐의 망설임도, 겹말 처리 실패도, 재연결 지연도 어색함으로 크게 체감됩니다.

그래서 음성 에이전트는 결국 모델 경쟁이 아니라 미디어 시스템 설계 경쟁으로 흘러갑니다. 누가 더 자연스럽게 마이크 입력을 받고, 누가 더 튼튼하게 스트림을 유지하고, 누가 더 빠르게 끊김을 복구하고, 누가 더 매끄럽게 도구 호출을 음성 대화 속에 숨기느냐가 중요해집니다. AWS의 이번 글은 음성 에이전트가 왜 엔지니어링 조직 전체의 문제인지 잘 보여 줍니다.

실전 질문

우리는 음성 에이전트 품질을 모델 응답 시간만으로 평가하고 있지 않은가?
재연결과 네트워크 저하 상황에서의 UX가 설계돼 있는가?
함수 호출이 길어질 때 사용자가 어색함을 느끼지 않도록 중간 상태를 표현하고 있는가?
클라이언트별 음성 성능 차이를 데이터로 보고 있는가?

8) AWS + Cisco — MCP·A2A·Agent Skill 보안 제어면

무엇이 발표됐나

AWS는 Cisco와 함께 Securing AI agents: How AWS and Cisco AI Defense scale MCP and A2A deployments를 통해, 조직 안에서 급격히 늘어나는 MCP 서버, A2A 에이전트, Agent Skill을 어떻게 가시화하고 스캔하고 거버넌스할지에 대한 모델을 제시했습니다. 핵심 조합은 AI Registry + Cisco AI Defense입니다.

AWS가 정리한 배경은 현실적입니다.

MCP는 2024년 11월 이후 급속히 확산됐다.
A2A는 2025년 4월 이후 에이전트 간 직접 통신을 열었다.
Agent Skill까지 등장하면서 구성 요소 수가 폭증했다.
조직은 이제 수십~수백 개의 MCP 서버와 에이전트를 다루게 된다.
수동 리뷰는 속도를 못 따라가고, SOX/GDPR 같은 컴플라이언스 요구는 감사 흔적을 요구한다.

AI Registry는 이 구성 요소들을 단일 control plane에 등록하고 발견하게 하며, Cisco AI Defense는 등록 시점 자동 스캐닝을 수행하는 구조로 설명됩니다.

핵심 팩트

AWS는 visibility gap, security bottleneck, compliance risk를 세 가지 핵심 문제로 지목했다.
MCP servers, AI agents, Agent Skills가 ad-hoc하게 늘어나면 누가 무엇을 쓰는지 파악하기 어렵다고 설명했다.
AI Registry는 모든 MCP server, AI agent, Skill을 unified registration and discovery로 묶는 control plane으로 소개됐다.
Cisco AI Defense integration은 자동 security scanning을 제공한다고 밝혔다.
수동 검토가 몇 주씩 배포를 늦출 수 있다고 설명했다.
감사 실패는 규제 노출을 키우며 정량화도 어렵다고 지적했다.

왜 중요한가

이 발표는 AI 보안 담론의 중심을 다시 잡아 줍니다. 많은 팀이 아직도 AI 보안을 “프롬프트 인젝션을 막을까?”, “금칙어를 걸까?” 수준에서 생각합니다. 물론 그것도 중요합니다. 하지만 조직에서 더 먼저 문제 되는 것은 종종 다음입니다.

승인되지 않은 MCP 서버가 프로덕션에 붙어 있다
서드파티 도구가 어떤 데이터에 접근하는지 중앙에서 모른다
A2A 에이전트가 서로 무엇을 호출하는지 추적하지 못한다
Skill이 언제 추가·변경되었는지 기록이 없다
보안 검토 병목 때문에 현업은 몰래 우회 경로를 쓴다

이건 전형적인 자산 관리와 공급망 관리 문제입니다. 그리고 규모가 커질수록 모델 위험보다 더 빠르게 폭발합니다. AWS/Cisco의 발표는 에이전트 생태계가 성숙할수록 AI 보안이 AppSec, IAM, SBOM류 사고방식과 결합될 수밖에 없음을 보여 줍니다.

개발자에게 의미

첫째, 에이전트 구성 요소를 코드와 동등한 자산으로 취급해야 한다는 점입니다. MCP 서버, agent card, skill package, connector, policy file은 그냥 부속물이 아닙니다. 이들 각각이 공격면이자 컴플라이언스 대상입니다.

둘째, 배포 전 자동 스캔이 기본값이 되어야 한다는 점입니다. 컨테이너 이미지나 패키지 의존성을 스캔하듯, 에이전트 구성 요소도 등록 시점에 점검해야 합니다. 수동 검토는 속도를 못 따라갑니다.

셋째, 가시성 없는 정책은 존재하지 않는 정책과 다르지 않다는 점입니다. 보안팀이 무엇이 붙어 있는지 모르면 어떤 규칙도 적용할 수 없습니다. registry는 거버넌스의 전제 조건입니다.

넷째, A2A 통신은 새로운 내부 API 표면이라는 점입니다. 사람-도구 인터랙션보다 감시가 더 어렵고, 권한 위임이 더 복잡합니다. 앞으로는 ए이전트 간 호출 체인 자체가 주요 감사 대상이 될 가능성이 큽니다.

운영 포인트

등록되지 않은 자산 차단 원칙: registry에 없는 MCP/A2A/Skill은 운영망에 못 붙게 해야 한다.
스캔 결과 상태 통일: approved, blocked, pending review, exception 같은 공통 상태 언어가 필요하다.
호출 추적성 확보: 어떤 에이전트가 어떤 MCP 툴을 언제 어떤 권한으로 불렀는지 남겨야 한다.
변경 감지: 버전 변경, OAuth scope 변경, exposed tool list 변경은 재심사 트리거가 되어야 한다.
예외 경로 최소화: 임시 우회 승인 경로가 많아질수록 제어면이 무너진다.
현업 self-service와 보안 자동화 균형: 너무 막으면 우회가 생기고, 너무 열면 통제가 사라진다. registry + auto scan이 균형점이 될 수 있다.

더 깊은 해석

에이전트의 확산은 역사적으로 마이크로서비스, SaaS, 오픈소스 패키지 확산과 비슷한 패턴을 따를 가능성이 높습니다. 초반에는 민첩성이 전부처럼 보입니다. 누구나 쉽게 툴을 붙이고 능력을 확장할 수 있으니 생산성이 폭발합니다. 하지만 어느 순간부터 “우리가 지금 뭘 운영 중인지 아무도 정확히 모른다”는 상태가 옵니다. 그 순간 성장의 비용이 커집니다.

AWS/Cisco의 메시지는 바로 그 전환점에 필요한 것입니다. AI를 많이 도입하는 조직보다 AI를 많이 도입하면서도 무엇이 어디에 붙어 있는지 보이는 조직이 장기적으로 유리합니다. 앞으로 에이전트 거버넌스는 선택 기능이 아니라 플랫폼 경쟁력의 한 축이 될 가능성이 큽니다.

실전 질문

우리 조직의 MCP 서버·A2A 에이전트·스킬은 중앙 목록으로 보이는가?
신규 자산 등록 시 자동 스캔과 승인 상태 부여가 되는가?
에이전트 간 호출 흐름까지 추적 가능한가?
보안팀과 현업팀이 같은 상태 언어로 협업하고 있는가?

9) NVIDIA + SAP — Specialized Agent용 신뢰 런타임

무엇이 발표됐나

NVIDIA는 NVIDIA and SAP Bring Trust to Specialized Agents에서 SAP와의 협업 확대를 발표하며, SAP Business AI Platform 안에 NVIDIA OpenShell을 임베드한다고 밝혔습니다. OpenShell은 autonomous AI agents를 안전하게 개발·배포하기 위한 오픈소스 runtime으로 설명되며, SAP 엔지니어들이 NVIDIA와 함께 공동 설계하며 오픈소스 프로젝트에 기여한다고 했습니다.

OpenShell이 제공하는 핵심은 다음과 같습니다.

isolated execution environments
filesystem and network layer policy enforcement
infrastructure-level containment
runtime hardening
enterprise identity integration
auditing and governance hooks

또한 SAP Business AI Platform 안에서 OpenShell은 모든 SAP AI agent의 runtime security layer가 되며, Joule Studio에서 만든 custom agent에도 적용됩니다. NVIDIA는 역할을 이렇게 나눠 설명합니다.

OpenShell: “이 행동을 안전하게 실행할 수 있는가?”
Joule Studio runtime: “이 행동이 일어나야 하는가?”

핵심 팩트

SAP는 OpenShell을 SAP Business AI Platform에 임베드한다고 밝혔다.
SAP 엔지니어가 OpenShell 오픈소스 코드베이스 공동 개발에 참여한다고 설명했다.
OpenShell은 isolated execution environment, filesystem/network policy enforcement, infrastructure-level containment를 제공한다고 소개됐다.
SAP AI agents와 Joule Studio custom agents에 runtime security layer로 적용된다고 밝혔다.
NVIDIA NemoClaw reference blueprint가 Joule Studio에 직접 제공될 예정이라고 설명했다.

왜 중요한가

이 발표는 엔터프라이즈 AI에서 가장 어려운 질문 중 하나를 정면으로 다룹니다. 시스템 오브 레코드 안에서 움직이는 에이전트를 어떻게 믿을 것인가?

SAP는 finance, procurement, supply chain, manufacturing처럼 실제 돈과 운영이 걸린 시스템입니다. 이런 영역에서 에이전트는 단순 추천을 넘어서 기록, 승인, 데이터 접근, 프로세스 실행을 건드릴 수 있습니다. 이때 신뢰는 추상적 윤리 문구가 아니라 다음 조합에서 나옵니다.

실행 경계
네트워크/파일시스템 정책
역할·권한 인식
감사 로그
애플리케이션 레벨 승인
인프라 레벨 격리

NVIDIA와 SAP는 바로 이 점을 건드리고 있습니다. 특히 should this action happen at all?과 can this action safely execute?를 분리한 설명은 매우 중요합니다. 제품·비즈니스 로직 레벨의 적합성 판단과, 인프라·런타임 레벨의 안전 실행 판단은 서로 다른 문제입니다. 둘 중 하나만 있어도 충분하지 않습니다.

개발자에게 의미

첫째, 애플리케이션 정책과 런타임 정책을 분리해야 한다는 점입니다. 어떤 액션이 비즈니스 룰상 허용되는지와, 실제로 그 액션이 파일시스템/네트워크/권한 경계 안에서 안전하게 수행되는지는 다른 층입니다.

둘째, 엔터프라이즈 에이전트는 시스템 오브 레코드 문법을 이해해야 한다는 점입니다. 일반 SaaS보다 훨씬 더 엄격한 승인, 역할, 데이터 경계, 컴플라이언스를 다뤄야 합니다. SAP 같은 환경은 이를 극단적으로 보여 줍니다.

셋째, 오픈소스 runtime hardening이 플랫폼 경쟁력으로 떠오른다는 점입니다. OpenShell은 단순 SDK가 아니라 agent runtime 자체를 표준화하려는 시도에 가깝습니다. 이는 앞으로 다른 엔터프라이즈 플랫폼에도 유사한 요구가 생길 수 있음을 시사합니다.

넷째, reference blueprint의 가치도 큽니다. NemoClaw 같은 구조가 Joule Studio에 직접 제공되면, 개발팀은 매번 보안 scaffolding을 처음부터 짤 필요가 줄어듭니다.

운영 포인트

비즈니스 승인과 런타임 허용 분리: “해야 하는 일인가”와 “해도 안전한가”를 다른 레이어에서 판정해야 한다.
시스템 오브 레코드 접근 최소화: finance/procurement 데이터에 닿는 agent는 최소 권한 원칙을 강하게 적용해야 한다.
감사 훅 표준화: 누가 어떤 agent로 어떤 SAP 객체에 접근했는지 일관된 로그 구조가 필요하다.
policy drift 방지: 앱 레벨 정책과 런타임 레벨 정책이 서로 어긋나지 않게 change management가 필요하다.
sandbox 범위 검증: custom agent가 예상보다 넓은 파일/네트워크 범위를 보지 않는지 정기적으로 확인해야 한다.
enterprise identity 통합: agent identity, human identity, delegated permission을 명확히 연결해야 한다.

더 깊은 해석

NVIDIA와 SAP의 협업은 AI 시장의 가치가 점점 더 애플리케이션 레이어로 이동하고 있음을 보여 줍니다. Jensen Huang이 종종 말하는 AI 5-layer cake 관점에서, 실제 경제적 가치는 애플리케이션 레이어에서 발생합니다. 그런데 그 레이어는 단순히 모델을 얹는다고 열리지 않습니다. 특히 SAP처럼 핵심 비즈니스 시스템 위에서는 신뢰 가능한 실행 환경이 선행 조건입니다.

이 발표는 앞으로 엔터프라이즈 AI 플랫폼이 어떤 구조로 진화할지 힌트를 줍니다.

모델
오케스트레이션
애플리케이션 정책
런타임 격리
감사와 정체성 통합

이 다섯 층이 같이 맞물려야 실제 업무 자동화가 가능해집니다. NVIDIA와 SAP는 그중 런타임과 애플리케이션 정책의 경계면을 특히 선명하게 드러냈습니다.

실전 질문

우리 엔터프라이즈 에이전트는 “해야 하는가”와 “안전하게 실행 가능한가”를 분리해 판단하는가?
시스템 오브 레코드에 닿는 agent의 권한 범위는 최소화되어 있는가?
런타임 정책과 비즈니스 정책이 따로 버전 관리되고 있는가?
감사자가 봤을 때 agent action chain을 재구성할 수 있는가?

10) NVIDIA — Hermes와 로컬 상시 실행 에이전트

무엇이 발표됐나

NVIDIA는 Hermes Unlocks Self-Improving AI Agents, Powered by NVIDIA RTX PCs and DGX Spark를 통해 Hermes Agent와 로컬 상시 실행 에이전트 흐름을 강하게 밀었습니다. 발표는 Hermes를 단순 agent framework가 아니라 reliability와 self-improvement를 동시에 겨냥한 로컬 에이전트 운영 레이어로 설명합니다.

NVIDIA가 강조한 Hermes의 네 가지 특징은 다음과 같습니다.

Self-Evolving Skills
Contained Sub-Agents
Reliability by design
Same model, better results through stronger orchestration

여기에 로컬 실행용 모델로 Alibaba의 Qwen 3.6 계열을 붙였습니다. 공식 설명에 따르면 Qwen 3.6 35B는 약 20GB 메모리 수준에서 이전 세대 120B 모델을 넘어서는 지능을, 27B dense model은 훨씬 큰 400B급 이전 세대와 맞먹는 정확도를 지향합니다. 하드웨어 측면에서는 RTX GPU와 DGX Spark를 로컬 에이전트 실행의 핵심 기반으로 제시했습니다.

핵심 팩트

NVIDIA는 Hermes가 3개월도 안 돼 GitHub star 14만 개를 넘겼다고 밝혔다.
OpenRouter 기준 가장 많이 쓰이는 agent라는 점을 언급했다.
Hermes는 messaging app 연동, local file/app access, 24/7 실행을 지원한다고 설명했다.
self-evolving skills, contained sub-agents, reliability by design, stronger orchestration을 차별점으로 제시했다.
Qwen 3.6 35B는 약 20GB memory footprint로 이전 세대 120B 대비 강점을, 27B는 이전 세대 400B급 대비 경쟁력을 주장했다.
DGX Spark는 128GB unified memory와 1 petaflop AI performance를 강조했다.

왜 중요한가

이 발표는 로컬 AI 담론을 단순 privacy/offline 논의에서 한 단계 앞으로 밀어냅니다. 핵심은 항상 켜져 있고, 작업을 나누고, 배운 것을 저장하고, 다음 작업에 다시 쓰는 에이전트가 로컬에서도 충분히 현실적인 타깃이 되었다는 점입니다.

지금까지 로컬 AI는 두 극단 사이에서 자주 논의됐습니다.

“클라우드 없이도 돌아간다”는 이상
“그래도 성능이 부족하다”는 회의

NVIDIA의 메시지는 그보다 실무적입니다. 좋은 로컬 에이전트 경험은 단순히 모델 하나를 로컬에서 돌리는 것이 아니라,

적절한 모델 크기 선택
낮은 지연의 하드웨어
작업을 쪼개는 서브에이전트 구조
스스로 스킬을 저장하고 다듬는 메커니즘
지속 세션을 감당하는 오케스트레이션

의 조합에서 나온다는 것입니다. 즉 로컬 AI의 경쟁력은 곧 로컬 에이전트 운영체제의 경쟁력입니다.

개발자에게 의미

첫째, 로컬 에이전트는 inference 문제가 아니라 orchestration 문제라는 점입니다. 파일 접근, 메시징 연동, 스킬 축적, 하위 작업 분리, 24/7 세션 관리는 단순 모델 API 호출과는 완전히 다른 영역입니다.

둘째, contained sub-agent 패턴은 로컬에서 특히 강하다는 점입니다. 로컬 모델은 컨텍스트 창과 메모리, 동시 작업 수에서 제약이 있을 수 있으므로, 짧게 사라지는 서브에이전트가 복잡성을 줄이는 데 유리합니다.

셋째, self-evolving skill은 장기 사용성을 바꾼다는 점입니다. 사용자가 반복 작업을 시킬수록 더 나아지는 구조는, 전통적인 “매번 새로 묻는 챗봇”과 다릅니다. 잘 설계되면 개인화된 자동화 계층으로 발전할 수 있습니다. 반대로 잘못 설계되면 품질이 나빠진 스킬이 누적될 수 있으므로 관리 체계가 필수입니다.

넷째, 하드웨어가 곧 사용자 경험이라는 점입니다. 서버 인프라에서는 사용자가 추론 하드웨어를 의식하지 않아도 되지만, 로컬 에이전트에서는 응답성, 동시 실행 수, 발열, 전력, 지속 실행 안정성이 모두 체감됩니다.

운영 포인트

스킬 저장소 버전 관리: agent가 스스로 만든 스킬을 언제 승인·폐기·롤백할지 체계가 필요하다.
로컬 권한 최소화: 파일, 앱, 메시징 접근은 작업 유형별로 좁게 나눠야 한다.
장기 세션 청소: 상시 실행 agent는 맥락 누수, stale memory, 잘못된 습관이 쌓이기 쉬우므로 정리 정책이 필요하다.
장비 프로파일링: 어떤 GPU/메모리 조합에서 어떤 모델과 스킬셋이 안정적인지 표준 프로파일을 만드는 편이 좋다.
설명 가능한 행동 이력: 에이전트가 어떤 스킬을 생성했고 언제 어떤 파일을 읽고 썼는지 보여 줘야 한다.
서브에이전트 범위 고정: contained sub-agent가 실제로도 제한된 도구와 컨텍스트만 갖는지 확인해야 한다.

더 깊은 해석

NVIDIA가 Hermes를 통해 보여 주는 그림은 “AI PC”보다 더 구체적입니다. 이것은 사실상 agentic computer 비전입니다. 개인 워크스테이션 위에 항상 켜진 작업 계층이 하나 더 생기고, 그 계층이 사용자의 파일, 앱, 메신저, 아이디어, 반복 작업을 이어받아 꾸준히 정제해 가는 그림입니다.

이 비전이 실현되면 로컬 에이전트는 단순 보조 도구가 아니라, 운영체제와 애플리케이션 사이의 새로운 레이어가 될 수 있습니다. 다만 이를 위해서는 지능만큼이나 신뢰가 중요합니다. 사용자는 로컬 에이전트가 무엇을 배웠고, 무엇을 저장했고, 어떤 권한으로 움직였는지 이해할 수 있어야 합니다. 결국 로컬 AI의 승부는 프라이버시 슬로건보다 설명 가능한 지속 자동화에서 갈릴 가능성이 큽니다.

실전 질문

우리 로컬 AI 전략은 단순 on-device inference에 머물러 있지 않은가?
스킬 축적과 서브에이전트 구조를 제품적으로 어떻게 통제할 것인가?
로컬 권한 모델과 행동 이력 노출이 함께 설계되어 있는가?
장시간 켜 둔 에이전트의 맥락 부패를 어떻게 다룰 것인가?

11) NVIDIA + Ineffable Intelligence — 차세대 RL 인프라

무엇이 발표됐나

NVIDIA는 David Silver가 이끄는 Ineffable Intelligence와 함께 NVIDIA, Ineffable Intelligence Team Up to Build the Future of Reinforcement Learning Infrastructure를 발표했습니다. 메시지는 명료합니다. 다음 세대 AI는 인간이 이미 알고 있는 것을 압축해서 답하는 시스템을 넘어, 경험을 통해 새로운 지식을 발견하는 superlearners 쪽으로 가야 하며, 이를 위해서는 완전히 다른 인프라 루프가 필요하다는 것입니다.

공식 설명에서 핵심 차이는 pretraining과 RL의 데이터 흐름 차이입니다.

pretraining: 고정된 인간 데이터셋이 흘러감
RL: 시스템이 act, observe, score, update를 계속 반복하며 데이터를 즉석 생성함

이 구조는 interconnect, memory bandwidth, serving, simulation, training loop 전체에 다른 요구를 던집니다. NVIDIA는 기술 작업을 Grace Blackwell에서 시작하고 향후 Vera Rubin 플랫폼도 탐색한다고 밝혔습니다.

핵심 팩트

David Silver는 “인간이 이미 아는 것을 아는 AI”를 넘어 “새로운 지식을 스스로 발견하는 AI”가 다음 과제라고 말했다.
NVIDIA는 RL workload가 fixed human dataset이 아니라 on-the-fly generated experience를 다룬다고 설명했다.
tight loops는 interconnect, memory bandwidth, serving에 압력을 준다고 밝혔다.
학습 데이터는 인간 언어와 다른 richer experience가 될 수 있으며, novel architectures and algorithms가 필요할 수 있다고 언급했다.
기술 협업은 Grace Blackwell에서 시작되고 Vera Rubin도 향후 탐색 대상으로 제시됐다.

왜 중요한가

오늘의 다른 발표가 주로 “현재의 에이전트를 어떻게 운영할 것인가”에 집중했다면, 이 발표는 “미래의 에이전트를 어떤 학습 체계로 더 유능하게 만들 것인가”를 다룹니다. 그래서 직접적인 제품 뉴스 같지 않아 보여도, 장기적으로는 오히려 매우 중요합니다.

지금의 많은 에이전트는 여전히 인간이 만든 문서, 코드, 대화, 정책을 바탕으로 작동합니다. 하지만 자율성이 더 커지고, 더 긴 과제를 더 적게 감독받으며 해결하려면, 모델은 점점 더 실행 결과와 피드백으로부터 정책을 개선하는 능력이 필요해질 가능성이 큽니다. RL은 그 핵심 후보입니다.

그리고 RL의 병목은 알고리즘만이 아닙니다. 실제로는 시뮬레이션, 경험 생성, 평가, 서빙, 업데이트가 빠르게 돌 수 있는 인프라가 중요합니다. NVIDIA와 Ineffable의 협업은 바로 이 병목을 인프라 관점에서 겨냥합니다.

개발자에게 의미

첫째, 향후 agent quality는 inference-only 관점으로 설명하기 어려워질 수 있다는 점입니다. 제품팀이 직접 RL을 돌리지 않더라도, 모델 공급자의 학습 방식이 바뀌면 장기 과제 수행 능력, 복구 능력, 전략 탐색 능력에 큰 차이가 생길 수 있습니다.

둘째, 시뮬레이션 환경의 가치가 커집니다. 경험 기반 학습이 중요해질수록, 안전하게 실패하고 보상받을 수 있는 환경을 얼마나 잘 만들 수 있는지가 핵심이 됩니다.

셋째, 운영 로그가 미래 학습 자산이 될 수 있습니다. 오늘의 제품 실패, tool misuse, dead-end workflow는 단순 bug report가 아니라 장기적으로는 학습 신호 후보가 될 수 있습니다.

넷째, 하드웨어·서빙·학습 스택의 경계가 다시 가까워진다는 점도 중요합니다. RL의 효율은 모델 코드만으로 결정되지 않고 전체 시스템 파이프라인에 달려 있습니다.

운영 포인트

평가 환경 축적: 실제 사용자 피해 없이 반복 실험할 수 있는 시뮬레이션 환경을 자산으로 쌓아야 한다.
실패 분류 체계: 어떤 실패가 단순 장애이고 어떤 실패가 향후 학습 가치가 있는지 구분해야 한다.
reward proxy 설계: 제품 품질과 학습 신호를 연결하는 중간 보상 개념이 필요할 수 있다.
관측성 강화: 행동, 결과, 점수, 복구 과정을 구조적으로 수집해야 한다.
비용 곡선 이해: RL 기반 개선은 pretraining과 다른 비용 구조를 만들 수 있으므로 인프라 전략이 달라질 수 있다.

더 깊은 해석

NVIDIA가 같은 시기에 OpenShell, Hermes, RL 인프라를 함께 말하는 것은 우연이 아닙니다. 이는 에이전트 시대의 경쟁이 세 층에서 동시에 벌어진다는 뜻입니다.

현재의 업무에 안전하게 들어가는 런타임
사용자 가까이서 상시 실행되는 로컬 에이전트
미래의 더 강한 정책을 학습시키는 대규모 인프라

이 세 층은 따로 놀지 않습니다. 더 나은 RL 인프라는 더 유능한 에이전트를 만들고, 더 많이 배포된 에이전트는 더 풍부한 실패 유형과 시뮬레이션 과제를 드러냅니다. 장기적으로는 제품 운영과 모델 학습의 거리도 다시 가까워질 수 있습니다.

실전 질문

우리는 에이전트 실패를 단순 버그로만 보고 있지 않은가?
시뮬레이션 친화적인 평가 환경을 얼마나 확보하고 있는가?
장기적으로 모델 공급자의 RL 전략 변화가 우리 제품 로드맵에 어떤 영향을 줄지 보고 있는가?
운영 로그를 미래 학습 자산 후보로 저장할 준비가 되어 있는가?

오늘 발표들을 하나의 시스템으로 묶어 보면

오늘의 공식 발표는 각자 다른 제품 이야기처럼 보이지만, 사실상 하나의 에이전트 시스템 스택을 다른 층에서 채우고 있습니다. 이걸 한 장의 아키텍처 그림처럼 정리하면 더 선명해집니다.

1. 사용자 접점 계층

여기서는 사용자가 AI를 어떤 표면에서 만나는지가 중요합니다.

OpenAI 모바일 Codex는 폰을 에이전트 제어면으로 만든다.
Anthropic SMB는 회계·결제·CRM·디자인 툴 안으로 AI를 넣는다.
AWS 음성 패턴은 실시간 대화 인터페이스를 구축한다.

즉 사용자 접점은 더 이상 “웹 챗창 하나”가 아닙니다. 모바일, 기존 업무 툴, 음성 채널이 모두 주요 entry point가 됩니다.

2. 오케스트레이션 계층

여기서는 작업을 어떻게 쪼개고 이어 가는지가 중요합니다.

Google ADK는 상태 머신, 서브에이전트, 웹훅 재개를 표준 구조로 제시한다.
NVIDIA Hermes는 contained sub-agent와 self-evolving skill로 로컬 오케스트레이션을 보여 준다.
OpenAI Codex는 장기 작업의 인간 개입 리듬을 다듬는다.

이 계층의 핵심은 “모델이 얼마나 잘 답하느냐”보다 작업이 얼마나 잘 이어지느냐입니다.

3. 정책·미들웨어 계층

여기서는 모델과 툴 사이에 어떤 규칙을 넣을지가 중요합니다.

Google Genkit Middleware는 retry, fallback, tool approval, filesystem, skills를 표준화한다.
OpenAI Hooks는 저장소별 검사·비밀정보 스캔·메모리 생성·로그를 가능하게 한다.
Anthropic은 승인 기반 실행과 권한 상속을 강조한다.

이 계층은 AI 앱의 품질 바닥선을 결정합니다.

4. 실행 경계 계층

여기서는 실제로 어디까지 허용되는지가 중요합니다.

AWS AgentCore Browser는 browser behavior와 connectivity를 정책으로 묶는다.
NVIDIA OpenShell은 filesystem/network containment를 런타임 수준에서 강제한다.
OpenAI의 Codex 구조는 자격증명과 파일을 원래 머신에 남겨 두고 제어 정보만 전달한다.

이 계층이 약하면 에이전트가 강해질수록 위험 반경도 같이 커집니다.

5. 자산·거버넌스 계층

여기서는 무엇이 등록되고 감사되는지가 중요합니다.

AWS/Cisco는 AI Registry와 자동 스캔으로 MCP/A2A/Skill을 제어한다.
Anthropic은 SMB용 데이터 권한 상속과 승인 흐름을 신뢰의 바닥으로 둔다.
SAP/NVIDIA는 엔터프라이즈 identity와 governance hooks를 강조한다.

결국 AI 거버넌스는 모델 가드레일보다 더 넓은 범위를 다루게 됩니다.

6. 학습·컴퓨트 계층

여기서는 현재와 미래의 지능을 어떻게 떠받칠지가 중요합니다.

NVIDIA Hermes는 로컬 실행 하드웨어와 오케스트레이션을 결합한다.
NVIDIA/Ineffable은 대규모 RL 인프라를 통해 future superlearner 방향을 노린다.

이는 로컬과 클라우드, inference와 learning이 서로 대체재가 아니라 보완재라는 점을 보여 줍니다.

이 아키텍처 관점에서 보면 오늘의 뉴스는 흩어진 발표가 아니라, 에이전트 산업이 어디를 표준화하고 어디서 차별화될지를 보여 주는 지도입니다.

개발자에게 의미: 오늘 바로 가져갈 18가지 설계 교훈

장기 실행 작업은 모바일 제어면을 전제로 설계하는 편이 좋다.
사용자는 항상 같은 머신 앞에 있지 않다.
승인 UX는 보안 장식이 아니라 생산성 구조다.
너무 잦으면 우회가 생기고, 너무 약하면 신뢰가 무너진다.
메모리는 개인화 기능이면서 동시에 안전 기능이 될 수 있다.
다만 목적별로 분리해야 한다.
중소기업 시장은 범용 모델보다 완결된 업무 패키지를 산다.
커넥터는 수단이고 결과가 제품이다.
에이전트 앱에는 정책 미들웨어가 기본 내장돼야 한다.
retry, fallback, approval, scoping이 빠진 앱은 곧 취약해진다.
긴 대화 기록은 상태 저장의 대체물이 아니다.
단계와 대기 신호는 별도 상태 스키마로 빼야 한다.
webhook resume은 옵션이 아니라 장기 실행의 핵심 인터페이스다.
외부 세계는 대화가 아니라 이벤트로 변한다.
브라우저 자동화는 곧 브라우저 거버넌스 문제다.
허용 도메인, 인증서, 다운로드 정책이 함께 따라온다.
실시간 음성은 모델보다 네트워크와 세션 설계가 먼저 무너질 수 있다.
latency budget과 reconnect 전략이 필수다.
MCP/A2A/Skill은 에이전트 생태계의 소프트웨어 공급망이다.
등록·스캔·감사 없이 확장하면 반드시 병목이 온다.
애플리케이션 정책과 런타임 정책은 분리해 설계해야 한다.
should와 can은 다른 질문이다.
로컬 에이전트 경쟁력은 모델보다 오케스트레이션과 신뢰 UX에서 나온다.
장시간 사용성을 증명해야 한다.
self-evolving skill은 강력하지만 운영 통제가 없으면 위험하다.
버전관리와 검토 체계가 필요하다.
서브에이전트는 유행어가 아니라 컨텍스트 예산 관리 도구다.
특히 로컬과 장기 세션에서 효과가 크다.
운영 로그는 장기적으로 학습 자산이 될 수 있다.
단순 디버깅 로그로만 버리면 아깝다.
평가는 멀티턴·멀티세션·멀티데이 시나리오를 포함해야 한다.
실제 실패는 대부분 거기서 발생한다.
엔터프라이즈 도입의 핵심은 모델이 아니라 시스템 오브 레코드와의 신뢰 관계다.
SAP, QuickBooks, PayPal, internal web 모두 같은 문제를 다른 얼굴로 보여 준다.
AI 제품은 점점 프레임워크 경쟁이 아니라 운영 스택 경쟁으로 간다.
모델 성능과 별개로 운영 기본기에서 승부가 난다.

운영 포인트: AI 팀과 플랫폼 팀이 점검해야 할 20가지

권한과 경계

읽기 / 쓰기 / 실행 / 네트워크 / 브라우저 접근 권한을 분리했는가?
브라우저 허용 도메인과 다운로드 정책이 역할별로 다른가?
private CA 내부 서비스에 대한 신뢰 체계를 안전하게 관리하는가?
로컬 에이전트의 파일/앱 접근 범위가 설명 가능하게 정의돼 있는가?

상태와 재개

장기 실행 플로우의 단계가 별도 상태로 저장되는가?
동일 webhook 재전송에 대해 idempotent한가?
server restart나 scale-to-zero 이후에도 세션이 복원되는가?
장기 세션 만료와 정리 정책이 있는가?

승인과 감사

사람 승인이 필요한 툴과 자동 허용 툴을 구분했는가?
승인 전 미리보기의 품질이 충분히 높은가?
누가 어떤 action plan을 승인했는지 남는가?
agent-to-agent 호출까지 감사 흔적을 남길 수 있는가?

커넥터와 자산 관리

모든 MCP 서버, Skill, agent card가 registry에 등록되는가?
신규 자산은 자동 스캔을 거치는가?
커넥터 권한 상속이 원 시스템의 IAM과 일치하는가?
버전 변화나 scope 변화가 재심사 트리거가 되는가?

입출력 품질

음성은 first audio latency, reconnect rate, turn completion latency를 따로 재는가?
문서·회계류 데이터는 구조 정합성과 출처 역추적을 확보하는가?

학습과 지속 개선

실패를 단순 예외가 아니라 학습 후보 데이터로 분류할 수 있는가?
평가 환경이 멀티데이·멀티채널·부분 실패 시나리오를 포함하는가?

역할별로 읽는 오늘의 뉴스

1. 코딩 에이전트 팀

오늘 OpenAI와 Google, NVIDIA의 발표를 함께 읽으면 코딩 에이전트의 승부처가 분명해집니다. 더 좋은 코드 생성만으로는 부족합니다. 사용자는 이제 다음을 묻습니다.

자리를 비워도 계속 일하는가
중간 승인과 방향 전환이 자연스러운가
리포 규칙과 보안 훅이 자동으로 적용되는가
로컬/원격 환경을 매끄럽게 넘나드는가
diff와 테스트 결과를 감독하기 쉬운가

즉 코딩 에이전트 팀은 모델 업그레이드 못지않게 작업 지속성, 승인 UX, 정책 훅, 원격 런타임을 제품 핵심으로 봐야 합니다.

2. SMB SaaS 팀

Anthropic 발표는 중소기업용 AI를 만드는 팀에게 꽤 직접적입니다. 기능을 많이 붙이는 것보다, 회계·영업·마케팅·계약 같은 실제 업무 묶음을 더 좁고 강하게 만드는 편이 낫습니다. SMB 사용자는 범용 자유도보다 일 하나가 끝나는 경험에 더 큰 가치를 둡니다.

3. 엔터프라이즈 플랫폼 팀

Google ADK, Genkit Middleware, AWS Registry, SAP OpenShell은 모두 플랫폼팀의 역할이 커지고 있음을 보여 줍니다. 각 현업이 제각각 agent를 붙이기 시작하면, 결국 필요해지는 공통 계층은 다음과 같습니다.

영속 세션 저장소
webhook resume 인프라
tool approval 서비스
registry + scanning
audit/logging
policy middleware
identity delegation

이 공통 계층 없이 현업별 실험이 커지면 곧 혼란이 옵니다.

4. 보안·컴플라이언스 팀

오늘의 발표는 보안팀에게도 중요한 시그널입니다. AI 보안은 이제 prompt filtering만의 문제가 아닙니다. 브라우저 정책, 런타임 containment, registry visibility, skill scanning, safety context handling까지 모두 포함하는 혼합 문제입니다. 보안팀은 agent를 별도 장르로 보기보다, 애플리케이션 보안 + 공급망 보안 + IAM + endpoint control의 연장선에서 보는 편이 더 실무적일 수 있습니다.

5. 음성 제품 팀

AWS의 음성 글은 음성 에이전트가 왜 종종 과대평가와 과소설계를 동시에 겪는지 잘 보여 줍니다. 말 잘하는 모델보다 중요한 것은 재연결, turn handling, 네트워크 적응, 함수 호출 타이밍입니다. 음성 팀은 model QA만큼 media-system QA를 중시해야 합니다.

6. 로컬 AI 제품 팀

NVIDIA Hermes는 로컬 AI를 개인 생산성 도구 이상의 계층으로 끌어올립니다. 로컬 AI 제품 팀은 단순 실행 가능성보다 항상 켜진 상태에서의 안정성, 스킬 축적 관리, 권한 가시성, 장비별 예측 가능한 성능을 더 큰 차별화 포인트로 봐야 합니다.

7. 연구·장기 전략 팀

Ineffable 협업은 당장 제품 기능이 아니어도 중요합니다. 미래의 agent quality가 경험 기반 학습과 더 긴 학습 루프에 좌우될 수 있기 때문입니다. 지금부터 시뮬레이션 가능한 환경, reward proxy, 실패 로그 구조화에 투자하는 팀이 이후 전환기에 유리할 수 있습니다.

30일 실행 로드맵: 오늘 뉴스에서 바로 행동으로 옮길 것들

1주차 — 가시성 확보

현재 조직 안의 agent, MCP server, skill, connector, browser automation flow를 목록화한다.
장기 실행 업무 중 채팅 기록에 상태를 숨겨 둔 흐름을 찾아낸다.
브라우저형 agent가 있다면 어떤 도메인에 접근 가능한지 실제로 적는다.
음성/문서/회계류 AI에서 병목이 모델인지 입출력 계층인지 구분한다.

2주차 — 최소 통제면 구축

신규 MCP/A2A/Skill 등록 절차를 만든다.
destructive tool에 대한 승인 interrupt 기준을 세운다.
장기 실행 플로우 하나에 명시적 상태 스키마를 도입한다.
브라우저 접근 범위와 다운로드 정책을 최소한으로라도 정의한다.
로컬 에이전트가 있다면 파일/앱 권한 범위를 좁힌다.

3주차 — 대표 워크플로 정교화

하나의 대표 시나리오를 깊게 다듬는다. 예를 들면 다음 중 하나다.

버그 조사형 코딩 에이전트: 모바일 승인 + 훅 + diff 리뷰
HR/재무 온보딩형 장기 실행 에이전트: 상태 머신 + webhook resume
SMB 회계 업무 패키지: QuickBooks/결제/CRM 연결 + 승인 구조
브라우저 기반 사내 운영 에이전트: 허용 도메인 정책 + 내부 CA 신뢰
실시간 음성 에이전트: reconnect + function calling + multilingual QA

4주차 — 평가와 회고 체계화

happy path 외에 idle time, restart, duplicate webhook, denied approval, blocked domain, poor network를 넣는다.
상태/로그/감사/승인 기록을 분리 관측해 본다.
어떤 실패가 학습 신호 후보인지 분류한다.
다음 달 플랫폼화할 공통 미들웨어와 정책 부품을 추린다.

작은 팀을 위한 현실적 권고

작은 팀에게 오늘의 발표들은 너무 거대해 보일 수 있습니다. 하지만 핵심 교훈은 오히려 단순합니다.

첫째, 하나의 중요 워크플로부터 시작하라는 것입니다. 모든 업무를 agent화하려 하지 말고, 가장 반복적이고 가치가 큰 흐름 하나를 골라 상태·승인·감사를 제대로 설계하는 편이 낫습니다.

둘째, 권한과 승인을 너무 늦게 생각하지 말라는 것입니다. 작은 팀일수록 “일단 돌아가게 하고 나중에 보자”가 유혹적이지만, agent는 나중에 경계를 덧붙이기가 훨씬 어렵습니다.

셋째, 문서와 로그를 남겨라는 것입니다. state key, approval rule, allowed domain, connector ownership, skill review 기준을 짧게라도 적어 두면 미래 비용이 크게 줄어듭니다.

넷째, 로컬과 클라우드를 싸움으로 보지 말라는 것입니다. 민감 데이터와 즉시성은 로컬이, 대규모 관리와 연결성은 클라우드가 더 낫습니다. 분업이 현실적입니다.

다섯째, 평가를 기능 뒤가 아니라 기능 옆에 둬라는 것입니다. agent는 예상 밖 상황에서 진짜 실력이 드러납니다. 따라서 예외 상황을 처음부터 설계에 포함해야 합니다.

오늘 뉴스가 던지는 전략적 질문

우리 제품의 경쟁력은 아직도 모델 선택에서만 나온다고 믿고 있지 않은가?
장기 실행 작업을 사용자가 자리를 비운 동안도 계속 흐르게 만드는 구조가 있는가?
도메인 패키지 없이 범용 챗 인터페이스만 내놓고 있지 않은가?
브라우저·문서·음성 같은 고난도 입출력 계층을 너무 단순한 모델 문제로 보고 있지 않은가?
MCP/A2A/Skill 생태계 확장을 거버넌스 없이 받아들이고 있지 않은가?
로컬 에이전트의 신뢰 UX를 하드웨어 마케팅 뒤로 밀고 있지 않은가?
운영 로그와 실패 데이터를 미래 학습 자산으로 재해석할 준비가 되어 있는가?

결론

오늘의 AI 뉴스는 겉으로 보면 주제가 넓게 흩어져 있습니다. 모바일 Codex, 민감 대화 안전, 중소기업용 워크플로, Genkit 미들웨어, 장기 실행 상태 머신, 브라우저 정책, 실시간 음성, MCP/A2A 보안, SAP용 신뢰 런타임, 로컬 Hermes, 대규모 RL 인프라까지 한 번에 나오기 때문입니다.

하지만 이 조각들을 한데 놓으면 방향은 오히려 매우 선명합니다.

에이전트는 더 오래 일할 것이다.
더 많은 도구와 시스템에 연결될 것이다.
더 많은 사람의 자리를 대신하기보다, 더 많은 사람의 감독 아래 오래 움직일 것이다.
따라서 더 강한 경계, 더 명시적인 상태, 더 세밀한 승인, 더 나은 거버넌스가 필요해질 것이다.
그리고 장기적으로는 더 나은 에이전트를 만들기 위한 학습 인프라도 같이 진화할 것이다.

OpenAI는 작업 제어면과 안전 문맥을, Anthropic은 업무 패키지화를, Google은 정책 계층과 장기 실행 구조를, AWS는 브라우저·음성·보안 운영을, NVIDIA는 엔터프라이즈 런타임·로컬 상시형 agent·미래 학습 인프라를 각각 밀어 올렸습니다. 이 발표들은 서로 경쟁하면서도 동시에 하나의 공통된 산업 전환을 증명합니다.

결국 오늘의 AI 뉴스는 이렇게 요약할 수 있습니다. 이제 AI의 진짜 경쟁은 모델을 얼마나 잘 만들었느냐보다, 그 모델을 실제 업무 안에 얼마나 오래, 안전하게, 통제 가능하게, 그리고 확장 가능하게 넣느냐의 경쟁입니다. 오늘은 바로 그 실행 계층 경쟁이 한층 더 구체적인 이름과 구조를 얻은 날이었습니다.

심화 해설: 오늘 뉴스를 실제 제품 설계에 대입하면

아래 내용은 오늘 발표를 단순 뉴스 요약이 아니라, 실제 제품팀·플랫폼팀·보안팀이 바로 가져다 쓸 수 있는 설계 언어로 다시 풀어 쓴 것입니다. 오늘의 발표들은 모두 “에이전트를 더 똑똑하게 만들었다”기보다 “에이전트를 더 오래, 더 안전하게, 더 운영 가능하게 만들었다”는 점에서 연결됩니다. 그래서 실무자가 읽을 때는 벤더 이름보다 우리 시스템의 어떤 층과 정확히 대응되는가를 보며 읽는 편이 훨씬 유익합니다.

1. OpenAI 모바일 Codex를 내부 개발 플랫폼 관점에서 읽으면

많은 개발 조직은 에이전트 도구를 여전히 “IDE 안의 스마트 기능” 정도로 소비합니다. 하지만 OpenAI가 폰에서 승인·방향 수정·스레드 확인·실시간 산출물 검토를 가능하게 한 순간, Codex는 IDE 위젯이 아니라 분산 작업 감독 계층으로 성격이 바뀝니다.

이 변화는 내부 개발 플랫폼 팀에 몇 가지 직접적 숙제를 던집니다.

long-running task를 표준 전제로 둘 것인가
승인을 모바일 친화적으로 압축할 것인가
작업 산출물을 diff/test/log/summary로 계층화할 것인가
로컬과 원격 개발 환경을 같은 사용자 경험으로 보이게 만들 것인가
리포별 정책 훅을 누가 관리할 것인가

예를 들어 팀이 대규모 모노레포에서 버그 조사형 에이전트를 도입한다고 가정해 보겠습니다. 사용자는 출근 전 “결제 모듈에서 간헐적으로 타임아웃 나는 원인 좀 찾아 봐”라고 요청합니다. 에이전트는 브라우저 재현, 로그 탐색, 관련 코드 경로 추적, flaky test 재실행, 의심 커밋 범위 축소 같은 일을 두 시간 동안 할 수 있습니다. 이때 실전에서 중요한 것은 모델이 세 줄 더 좋은 코드를 쓰는 것이 아닙니다. 오히려 다음이 더 중요합니다.

30분 뒤 폰으로 “원인 후보가 두 개입니다. 어떤 가설부터 더 파고들까요?”를 물어볼 수 있는가
패키지 설치, 원격 fetch, production-like config 접근 같은 민감 행동을 폰에서 승인 가능한가
중간 로그 500줄 대신 요약과 diff 중심으로 보여 주는가
사용자가 회의실에 들어가기 전에 “가설 A가 더 유력, 재현 성공, 최소 수정안은 이렇다”를 먼저 전달할 수 있는가

즉 모바일 제어면은 편의성보다 작업 연속성의 문제입니다. 이를 이해한 팀은 에이전트를 더 잘 배치할 수 있습니다.

2. OpenAI 안전 문맥 강화를 고객지원·헬스케어·교육 서비스 관점에서 읽으면

민감 대화에서의 context-aware safety는 일부 팀에게는 먼 이야기처럼 보일 수 있습니다. 하지만 실제로는 멀지 않습니다. 고객지원, 코칭, 정신건강 인접 서비스, 교육 보조, 청소년용 앱, 커뮤니티 운영 도구처럼 장기 대화가 발생하는 제품이라면 거의 모두 같은 질문을 받게 됩니다.

위험 신호가 한 번에 드러나지 않으면 어떻게 할 것인가
여러 세션에 나뉜 단서가 의미를 바꿀 때 시스템은 무엇을 볼 것인가
일반 개인화 메모리와 안전 메모리를 어떻게 분리할 것인가
과잉 반응 없이 드문 고위험 신호만 더 세심하게 다룰 수 있는가

오늘 OpenAI 발표를 제품 설계 언어로 번역하면, 핵심은 목적별 문맥 계층화입니다. 사용자가 좋아하는 말투를 기억하는 메모리와, 고위험 신호를 좁고 짧게 보존하는 메모리는 같은 저장소·같은 수명·같은 접근 규칙으로 다루면 안 됩니다.

예를 들어 교육용 AI 튜터라면 다음처럼 구분할 수 있습니다.

학습 개인화 메모리: 약한 장기 보존, 학습 스타일/진도 추적
세션 작업 메모리: 현재 과제/문제 해결 상태
안전 메모리: 제한된 기간의 고위험 징후 요약, 엄격한 접근 제한
감사 메모리: 특정 응답이 왜 보수적으로 바뀌었는지 내부 설명을 위한 기록

이 분리가 없으면, 메모리 기능은 편리해질수록 위험도 같이 커집니다. 반대로 잘 분리하면 장기 대화의 품질과 안전을 동시에 끌어올릴 수 있습니다.

3. Anthropic SMB 패키지를 vertical SaaS 전략 관점에서 읽으면

Claude for Small Business는 “중소기업용 AI를 출시했다”는 뉴스로 끝내기엔 아깝습니다. 이 발표는 사실상 vertical SaaS 제품팀을 향한 강한 신호입니다. 사용자 가치는 범용 챗 인터페이스에서 나오지 않고, 반복 업무 패키지에서 나온다는 것을 대형 벤더가 공공연히 인정한 셈이기 때문입니다.

vertical SaaS 팀은 여기서 다음 질문을 뽑아낼 수 있습니다.

우리 제품에서 고객이 매달 혹은 매주 반드시 반복하는 업무 묶음은 무엇인가
그 업무는 어떤 데이터 소스 조합을 필요로 하는가
승인 전 미리보기는 어떤 포맷이 가장 신뢰를 주는가
실행 후 누가 어떤 결과를 어디서 확인하게 할 것인가
failure/partial failure를 어떻게 사용자에게 설명할 것인가

예를 들어 HR SaaS라면 다음과 같은 패키지가 가능합니다.

채용 공고 초안 + 인터뷰 패널 정리 + 캘린더 발송 패키지
입사 전 문서 체크 + 장비 요청 + 첫 주 일정 생성 패키지
월간 인원 변동 브리핑 + 리스크 플래그 + 매니저 체크인 질문 생성 패키지

회계 SaaS라면 다음이 가능합니다.

월마감 준비 패키지
현금흐름 점검 패키지
세금 시즌 자료 정리 패키지
미수금 추심 패키지

핵심은 기능을 많이 노출하는 게 아니라, 사용자가 “이 버튼 하나로 이번 주 고된 일 하나가 실제로 끝난다”는 느낌을 받게 만드는 것입니다. Anthropic은 이 제품 언어를 매우 선명하게 보여 줬습니다.

4. Genkit Middleware를 AI 플랫폼 표준화 관점에서 읽으면

Genkit Middleware 발표는 웹 프레임워크 세계에서 인증 미들웨어, 로깅 미들웨어, 캐시 미들웨어가 표준화되던 초기 시점과 비슷한 느낌을 줍니다. 아직 많은 AI 팀은 policy logic을 프롬프트나 앱 코드에 흩뿌려 넣고 있습니다. 하지만 그 방식은 다음 순간 빠르게 망가집니다.

팀이 늘어나고
도구가 늘어나고
리포가 늘어나고
모델 공급자가 늘어나고
장애 시 fallback 요구가 생기고
human approval이 필요한 tool이 늘어나고
추적과 감사를 요구받을 때

미들웨어 표준화는 결국 플랫폼 팀의 생산성을 크게 끌어올립니다. 예를 들어 조직 공통 미들웨어 팩을 만들 수 있습니다.

org/retry-default
org/tool-approval-finance
org/filesystem-readonly-secrets
org/content-filter-sensitive-data
org/model-fallback-low-latency
org/audit-log-hook

이런 공통 부품이 생기면 각 제품팀은 도메인 로직에 집중할 수 있고, 보안·플랫폼팀은 반복적으로 같은 요구를 개별 리뷰하지 않아도 됩니다. 오늘의 Google 발표는 결국 AI 개발의 재사용 계층을 어디에 둘 것인가에 대한 답입니다.

5. ADK 장기 실행 패턴을 백엔드 설계 언어로 옮기면

Google ADK 글의 가장 중요한 미덕은 에이전트 문제를 다시 백엔드 문제로 번역해 준다는 점입니다. durable state, webhook, resume, sub-agent, database session, runner, golden eval 같은 키워드는 사실 전통적인 분산 시스템 설계 언어와 친합니다. 이 점을 이해하면 장기 실행 에이전트를 더 덜 신비롭게, 더 정확하게 설계할 수 있습니다.

예를 들어 procurement 승인 에이전트를 만든다고 생각해 보겠습니다. 이 플로우에는 대개 다음이 들어갑니다.

요청 생성
매니저 승인 대기
예산 확인
법무 검토 대기
공급업체 회신 대기
PO 생성
완료 보고

이를 긴 채팅으로 구현하면 거의 반드시 무너집니다. 대신 다음처럼 설계해야 합니다.

상태 전이 표를 문서화한다.
각 툴은 상태를 원자적으로 바꾼다.
외부 시스템 회신은 webhook으로 받는다.
사람이 개입해야 하는 단계는 interrupt로 분리한다.
재시작 이후에도 어느 단계인지 DB에서 곧바로 안다.
모든 step 전환은 별도 로깅한다.

즉 장기 실행 에이전트는 종종 “LLM이 붙은 workflow engine”입니다. 이 framing은 실무에서 매우 중요합니다.

6. AgentCore Browser 정책을 내부 도구 자동화 관점에서 읽으면

브라우저형 에이전트는 데모가 잘 나오기 때문에 조직이 쉽게 혹합니다. 하지만 프로덕션에서는 곧 이렇게 묻게 됩니다.

agent가 생산 DB 관리자 콘솔에 갈 수 있는가
내부 위키와 외부 웹을 자유롭게 넘나들어도 되는가
브라우저가 다운로드한 CSV가 어디에 남는가
로그인 세션이나 브라우저 저장소가 오래 유지돼도 되는가
사내 CA를 쓰는 툴에 붙을 때 신뢰 체인을 어떻게 관리할 것인가

이 질문들에 답하지 못하면 브라우저형 에이전트는 보안 검토 문턱을 넘지 못합니다. AWS의 발표는 브라우저 자동화를 보안 검토 친화적으로 만드는 최소 구성 요소가 무엇인지 보여 줍니다. 내부 운영 도구 자동화를 꿈꾸는 팀이라면 지금부터라도 브라우저 접근을 다음 세 부류로 나눠 보는 편이 좋습니다.

완전 차단되어야 하는 사이트
읽기 전용으로만 접속 가능한 사이트
특정 워크플로 안에서만 제한적으로 조작 가능한 사이트

이런 분류 없이는 브라우저형 에이전트의 가치가 커질수록 위험도 같이 커집니다.

7. 실시간 음성 발표를 실제 고객경험 관점에서 읽으면

많은 제품팀이 voice agent를 기획할 때 처음부터 “자연스러운 대화”를 목표로 씁니다. 하지만 실제 배포에서 사용자가 겪는 문제는 보통 더 저수준입니다.

첫 응답이 늦다
중간에 끊긴다
네트워크가 흔들리면 세션이 망가진다
도구 호출 중 침묵이 길어진다
끼어들기가 잘 안 된다
모바일에서 유독 성능이 나쁘다

AWS와 Stream의 글은 이 현실을 비교적 정직하게 말합니다. voice agent는 대개 “말을 잘하는 모델”보다 “흔들리는 연결 상태에서도 대화를 유지하는 시스템”이 더 중요합니다. 따라서 음성 제품팀은 다음과 같은 지표 체계를 가져야 합니다.

first audio latency
reconnection success rate
turn completion latency
barge-in recovery quality
function call wait masking quality
language-switch stability
packet loss resilience

이 지표가 없는 음성 에이전트 팀은 사용자 불만을 모델 품질 문제로 오판하기 쉽습니다.

8. AWS/Cisco 레지스트리 모델을 조직 확장 관점에서 읽으면

초기에는 모든 팀이 “한두 개 MCP 서버쯤이야”라고 생각합니다. 하지만 실제로는 유용한 서버 하나가 생기면, 팀마다 자기 도메인에 맞는 서버와 스킬을 붙이기 시작합니다. 그러면 몇 달 안에 이런 상태가 옵니다.

비슷한 목적의 MCP 서버가 중복 배포된다
누가 소유자인지 모른다
어떤 scope를 요구하는지 정리되지 않는다
특정 agent가 어떤 서버를 쓰는지 중앙에서 모른다
deprecation도 안 된다

AI Registry 같은 구조는 관료주의가 아니라 확장 가능한 self-service의 전제입니다. 무엇이 보이는지 알아야 자동 승인을 붙일 수 있고, 무엇이 승인된 자산인지 알아야 현업이 안심하고 조합할 수 있기 때문입니다. 결국 registry는 속도를 늦추는 도구가 아니라, 더 큰 속도를 안전하게 버티게 하는 도구입니다.

9. SAP + OpenShell 발표를 ERP/업무시스템 자동화 관점에서 읽으면

ERP, 회계, 조달, 공급망 시스템에 agent를 들이려는 팀은 대부분 같은 벽에 부딪힙니다. 단순 챗 UI는 쉽지만, 실제 행동 가능한 agent가 되려면 아래 두 질문을 동시에 만족해야 합니다.

비즈니스 룰상 해도 되는가
기술적/보안적으로 실행해도 되는가

이 둘은 같지 않습니다. 예를 들어 procurement 변경이 규정상 허용돼도, runtime 관점에서 잘못된 파일시스템 접근이나 과도한 네트워크 권한이 열려 있다면 안전하지 않습니다. 반대로 runtime은 완벽히 격리돼 있어도, 비즈니스 룰상 잘못된 action이면 역시 안 됩니다. NVIDIA와 SAP가 should/can을 분리한 것은 바로 이 이유 때문입니다. ERP 자동화에 뛰어드는 팀일수록 이 구분을 초기에 명확히 해 두는 편이 좋습니다.

10. Hermes 발표를 개인 업무 운영체제 관점에서 읽으면

로컬 에이전트에 대한 기대는 종종 과장되거나 반대로 지나치게 축소됩니다. NVIDIA가 Hermes를 통해 보여 준 것은 그 중간의 더 현실적인 그림입니다. 사용자는 결국 다음을 원합니다.

내 파일과 앱을 다룰 수 있고
오래 켜 둬도 안정적이며
반복 작업을 배워서 점점 수고를 줄이고
어떤 스킬이 쌓였는지 보여 주며
필요할 때 세분화된 하위 작업자로 나눠서 처리하는 것

이건 단순 챗봇도 아니고, 단순 스크립트 자동화도 아닙니다. 오히려 개인용 운영 레이어에 가깝습니다. 로컬 AI 제품은 여기서 차별화 포인트를 찾아야 합니다.

11. RL 인프라 협업을 미래 제품 품질 관점에서 읽으면

대부분의 제품팀은 오늘 당장 RL 파이프라인을 돌리지 않습니다. 하지만 RL 인프라 발표가 중요한 이유는, 앞으로 agent quality의 한 축이 경험으로부터 전략을 개선하는 능력이 될 수 있기 때문입니다. 만약 모델 공급자가 더 강한 experience loop를 학습에 집어넣기 시작하면, 제품팀이 기대할 수 있는 기본 agent 능력도 바뀝니다.

그때 준비된 팀은 어떤 팀일까요? 대개 이런 팀입니다.

실패 로그가 잘 구조화돼 있고
시뮬레이션 가능한 테스트 환경이 있으며
reward proxy 후보를 생각해 봤고
장기 작업 품질을 단발 응답 품질과 분리해 측정하는 팀

즉 RL 뉴스는 연구팀만의 뉴스가 아니라, 제품 평가 체계의 미래를 미리 보여 주는 뉴스이기도 합니다.

뉴스별 실전 적용 시나리오 11선

시나리오 1. 모바일 감독형 버그 해결 워크플로

OpenAI Codex 모바일 확장을 가장 직접적으로 쓸 수 있는 장면은 장기 버그 조사입니다. 예를 들어 결제 실패율이 갑자기 상승했고, 원인이 코드 변경인지 외부 API 응답 저하인지 불명확하다고 가정합시다. 데스크톱에서 에이전트에게 조사 작업을 맡긴 뒤 사용자는 이동합니다. 에이전트는 로그를 스캔하고, 관련 모듈을 읽고, 브라우저에서 재현을 시도하고, 테스트를 돌립니다. 이때 사용자가 폰에서 할 수 있어야 하는 핵심은 세 가지입니다.

작업 방향 전환: “이 경로보다 API timeout 쪽을 더 봐 줘.”
제한 명령 승인: “이 패키지 설치는 승인.”
중간 요약 검토: “원인 후보 두 개를 5줄로 압축해 줘.”

이 패턴이 자리 잡으면 코딩 에이전트는 더 이상 데스크톱 정주형 도구가 아니라, 이동 중에도 계속 운영되는 비동기 파트너가 됩니다.

시나리오 2. 다중 대화 안전 보강이 필요한 지원 챗봇

고객지원 봇이 환불 문제, 계정 분쟁, 감정적 불만을 장기적으로 처리한다고 생각해 봅시다. 대부분의 대화는 평범하지만, 드물게 사용자는 여러 세션에 걸쳐 불안정한 신호를 드러낼 수 있습니다. 이때 한 세션만 보면 애매하지만, 여러 대화의 누적 맥락을 보면 escalation이 필요한 상황이 있습니다. OpenAI의 safety summary 모델은 이런 제품에 다음 원칙을 줍니다.

일반 기억과 안전 기억을 분리하라
안전 기억은 제한된 사실만 보존하라
고위험 징후가 있을 때만 모델 응답의 보수성을 높여라
사람 검토가 필요한 threshold를 명확히 정의하라

시나리오 3. 소규모 회계·영업팀용 AI 패키지

Anthropic 모델을 자체 제품에 응용한다면 가장 쉬운 출발점은 “다기능 도우미”가 아니라 “한 덩어리 업무 끝내기”입니다. 예를 들어 미수금 추심 패키지를 만든다고 하면 다음 단계로 구성할 수 있습니다.

회계 데이터와 결제 데이터 대조
연체 금액과 우선순위 분류
고객별 톤 차등 적용된 초안 생성
발송 전 승인
발송 후 응답 대기 상태 전환
후속 reminder 자동 준비

이 정도만 해도 사용자는 AI를 ‘멋진 기능’이 아니라 ‘실제 업무 시간 절감 수단’으로 보기 시작합니다.

시나리오 4. 공통 미들웨어 패키지 도입

Genkit Middleware를 조직에 적용할 때 가장 먼저 만들면 좋은 것은 범용 제품 기능이 아니라 조직 공통 안전 부품입니다. 예를 들면 다음 세 개만 있어도 체감이 큽니다.

모든 destructive tool을 interrupt로 바꾸는 ToolApproval 미들웨어
quota 초과 시 더 저렴하거나 더 빠른 모델로 떨어지는 Fallback 미들웨어
워크스페이스 밖 경로 접근을 막는 Filesystem 미들웨어

이 세 부품만 잘 표준화해도, 개별 팀은 매번 같은 오류를 반복하지 않게 됩니다.

시나리오 5. 멀티데이 승인 워크플로

Google ADK 패턴은 HR 온보딩뿐 아니라 구매 승인, 계약 검토, 대금 지급 전 점검 같은 업무에도 그대로 들어갑니다. 예를 들어 대금 지급 전 점검 에이전트는 다음 상태 머신을 가질 수 있습니다.

START
INVOICE_RECEIVED
APPROVAL_PENDING
PAYMENT_SCHEDULED
PAYMENT_SENT
COMPLETED

각 단계는 사람이나 외부 시스템 이벤트를 기다립니다. 이 구조를 먼저 세워 두면, 이후 어느 모델을 붙이든 안정성은 크게 달라집니다.

시나리오 6. 사내 웹앱 자동화의 보안 경계 구축

AgentCore Browser 정책 지원은 사내 운영툴 자동화에서 특히 유용합니다. 예를 들어 CS 운영 에이전트가 내부 CRM과 외부 배송사 포털을 오가야 한다면, 다음처럼 경계를 만들 수 있습니다.

내부 CRM 도메인: 읽기·기록 제한 허용
배송사 포털: 특정 워크플로에서만 접근
임의 외부 사이트: 전면 차단
파일 다운로드: 중앙 저장소로만 허용

이렇게 설계하면 브라우저형 에이전트의 생산성은 유지하면서 위험 반경을 크게 줄일 수 있습니다.

시나리오 7. 실시간 상담 보조 에이전트

AWS 음성 패턴은 상담/예약/내부 헬프데스크에 잘 맞습니다. 예를 들어 음성 에이전트가 예약 가능 시간을 확인해야 할 때, 중요한 것은 모델이 예약 API를 부를 수 있는가가 아니라 그 기다림을 얼마나 자연스럽게 덮는가입니다. “잠시 확인하겠습니다” 같은 filler도 UX 일부가 됩니다. voice agent 팀은 function call latency masking을 제품 기능으로 봐야 합니다.

시나리오 8. MCP 서버 확산 전 registry 도입

조직이 MCP를 도입하기 전이라면 오히려 지금이 registry를 넣기 가장 좋은 시기입니다. 자산 수가 적을 때 소유자, 버전, scope, 승인 상태, deprecation 정책을 정해 두면 이후 혼란을 크게 줄일 수 있습니다. 반대로 이미 수십 개가 생긴 뒤에는 정리 비용이 매우 커집니다.

시나리오 9. ERP 액션 전 runtime 검증

SAP/OpenShell에서 배울 수 있는 가장 실용적인 패턴은 “계획”과 “실행 가능성”을 분리하는 것입니다. 예를 들어 agent가 공급업체 지급 조건을 수정하려 할 때,

비즈니스 규칙 엔진은 이 수정이 규정상 가능한지 본다.
런타임 정책 엔진은 이 agent가 그 시스템 엔드포인트와 파일/네트워크 범위에 접근해도 안전한지 본다.

둘 중 하나라도 실패하면 실행되지 않아야 합니다.

시나리오 10. 로컬 상시형 개인 에이전트

Hermes류 로컬 agent를 실제로 쓴다면, 가장 가치가 큰 지점은 “대화”가 아니라 “반복 정리”입니다. 예를 들어 개발자의 로컬 agent는 다음을 꾸준히 할 수 있습니다.

반복되는 릴리스 체크리스트 초안 준비
자주 쓰는 터미널 작업을 skill로 저장
문서 정리와 이슈 라벨링 보조
회의 후 TODO 구조화

이때 중요한 것은 지능의 과시가 아니라 누적 효율입니다.

시나리오 11. RL 친화적 평가 자산 구축

Ineffable 협업을 실무에 연결하면, 지금 당장 할 수 있는 일은 거창한 학습이 아니라 평가 환경 정리입니다. 예를 들어 고객지원 agent라면 다음과 같은 시뮬레이션 환경을 만들어 둘 수 있습니다.

정상 사용자 요청 흐름
모호한 정보가 주어지는 흐름
partial tool failure
delayed external response
contradictory user correction
policy violation attempt

이런 자산은 지금은 평가용이지만, 나중에는 더 강한 경험 기반 개선 루프의 바탕이 될 수 있습니다.

아키텍처 청사진: 오늘 뉴스가 가리키는 8개 레이어

레이어 1. Intent Capture Layer

사용자가 어디서 agent를 부르는가를 다룹니다. 모바일, 음성, 기존 SaaS UI, IDE, 메신저가 모두 여기 속합니다. OpenAI와 Anthropic, AWS의 발표는 서로 다른 entry point를 보여 줍니다. 이 레이어의 핵심 질문은 “사용자가 AI를 새 화면에서 배우게 할 것인가, 아니면 원래 있던 화면 안으로 넣을 것인가”입니다.

레이어 2. Context & Safety Layer

안전 관련 맥락, 작업 맥락, 개인화 맥락을 목적별로 어떻게 분리·유지할 것인가가 핵심입니다. OpenAI의 safety summaries는 이 레이어에서 매우 중요한 사례입니다. 향후 이 레이어는 personalization memory와 safety memory를 분리하는 구조로 발전할 가능성이 큽니다.

레이어 3. Orchestration Layer

상태 머신, tool loop, sub-agent delegation, approval interrupt, resume trigger가 위치합니다. Google ADK와 Genkit, NVIDIA Hermes가 여기에 직접 대응합니다. 이 레이어에서 잘못 설계하면 좋은 모델도 불안정해집니다.

레이어 4. Policy Middleware Layer

Retry, fallback, content filters, filesystem scope, tool approval, repo hook, cost/latency budgeting 같은 정책 부품이 위치합니다. 오늘 Google Genkit 발표는 이 층을 표준화하기 시작한 대표 사례입니다.

레이어 5. Runtime Boundary Layer

Filesystem/network/browser/domain restrictions, secret handling, root CA trust, isolated execution environment가 위치합니다. AWS AgentCore Browser와 NVIDIA OpenShell이 여기에 해당합니다. 에이전트가 실제 행동할수록 이 층의 중요성은 기하급수적으로 커집니다.

레이어 6. Asset Governance Layer

MCP, A2A, Skill, connector, agent card를 등록·스캔·승인·감사하는 층입니다. AWS/Cisco의 AI Registry가 대표적입니다. 이 층이 없으면 생태계는 늘어날수록 통제 불능이 됩니다.

레이어 7. Experience I/O Layer

음성, 문서, 브라우저, ERP, 디자인툴, 결제툴 같은 도메인 입출력 최적화가 이 층입니다. AWS 음성, Anthropic SMB, SAP/NVIDIA가 보여 준 방향이 여기에 속합니다. 실제 가치 창출은 이 층에서 가장 많이 발생합니다.

레이어 8. Compute & Learning Layer

로컬 GPU, DGX Spark, Grace Blackwell, Vera Rubin, inference/runtime/runtime cost, future RL training pipeline이 여기 속합니다. NVIDIA 발표 두 개는 이 층의 현재와 미래를 함께 비춥니다. 로컬과 초대형 학습 인프라가 동시에 중요해지는 이유도 이 층에서 설명됩니다.

이 8개 레이어를 팀의 시스템 지도에 겹쳐 보면, 어떤 부분은 이미 있고 어떤 부분은 비어 있는지 금방 보입니다. 오늘 뉴스의 실질적 가치는 바로 이 레이어별 공백을 자각하게 만든다는 데 있습니다.

자주 망가지는 실패 패턴 16가지

상태를 채팅 기록 속에 숨긴다.
며칠짜리 워크플로는 거의 반드시 깨진다.
승인을 제품 후반부에 덧붙인다.
UX도 나빠지고 보안도 약해진다.
브라우저 접근을 네트워크 허용/차단 정도로만 본다.
도메인·다운로드·인증서 정책을 놓치기 쉽다.
모델 응답 지연만 보고 음성 품질을 판단한다.
실제 병목은 재연결과 오디오 파이프라인일 수 있다.
MCP 서버를 소수 실험이라고 생각하고 레지스트리를 미룬다.
확산이 시작되면 나중에 정리 비용이 훨씬 크다.
self-evolving skill을 무관리 상태로 둔다.
시간이 지날수록 품질 드리프트가 생길 수 있다.
runtime boundary 없이 애플리케이션 정책만 믿는다.
should 판단만 있고 can 판단이 없으면 위험하다.
일상 대화와 안전 대화에 같은 메모리 정책을 쓴다.
프라이버시·오탐·과잉 반응 문제가 함께 커진다.
tool 호출과 상태 갱신을 분리한다.
실패 순간 복구가 어렵다.
fallback 전략이 없다.
quota 초과나 provider 장애가 곧 서비스 장애가 된다.
partially successful workflow를 성공으로만 표시한다.
사용자는 어디서 깨졌는지 모른 채 신뢰를 잃는다.
오디오/브라우저/문서 같은 고난도 I/O를 단순 모델 기능으로 다룬다.
팀이 문제를 잘못 진단하게 된다.
로컬 에이전트 권한을 처음부터 넓게 준다.
사용자 신뢰가 빠르게 무너진다.
운영 로그를 학습·평가 자산으로 재사용하지 않는다.
같은 실패를 반복한다.
모바일 제어면 없이 장기 실행 작업을 설계한다.
사용자는 결국 에이전트를 덜 믿고 덜 맡기게 된다.
도입 교육을 제품 밖 문제로 밀어낸다.
특히 SMB 시장에서는 기능이 있어도 사용이 늘지 않는다.

90일 실행 계획

0~30일: 보이는 것부터 만들기

조직 내 agent, MCP, connector, browser flow, long-running workflow 현황을 목록화한다.
가장 중요한 워크플로 하나를 골라 상태 전이 표를 만든다.
destructive tool approval 기준을 작성한다.
브라우저 허용 도메인과 다운로드 정책의 초안을 만든다.
음성/문서/회계류 I/O 중 병목 지점을 구분한다.

31~60일: 최소 플랫폼 만들기

공통 middleware 패키지를 2~3개 만든다.
registry 또는 자산 카탈로그의 최소판을 도입한다.
장기 실행 세션 저장소를 프로덕션 수준으로 전환한다.
승인 로그와 상태 전이 로그를 분리 수집한다.
로컬 에이전트가 있다면 스킬 저장소 버전관리 체계를 만든다.

61~90일: 대표 시나리오를 제품화하기

대표 워크플로 하나를 golden scenario 중심으로 고도화한다.
idle time, duplicate event, blocked domain, denied approval, reconnect failure를 테스트한다.
도메인 패키지 형태의 entry point를 만든다.
사람이 개입해야 하는 순간을 데이터로 재조정한다.
운영 실패를 분류하고 향후 학습 신호 후보 체계를 만든다.

이 90일 계획의 핵심은 모든 것을 한 번에 완성하는 것이 아니라, 가시성 → 통제면 → 대표 제품화의 순서로 밑바닥을 깔아 가는 데 있습니다.

팀별 체크리스트

A. 코딩 에이전트 도입 팀

장기 실행 작업을 기준으로 UX를 설계했는가?
모바일 승인과 중간 요약이 있는가?
훅으로 비밀정보 스캔, 테스트, 스타일 규칙을 강제하는가?
작업 결과가 diff/test 중심으로 검토 가능한가?
네트워크/패키지 설치/원격 fetch 권한이 분리돼 있는가?

B. SMB 업무 자동화 팀

기능이 아니라 업무 묶음으로 설명되는가?
승인 전 미리보기가 짧고 명확한가?
기존 권한 상속이 깨지지 않는가?
월말/세금 시즌 같은 부하 몰림을 대비했는가?
교육과 온보딩이 제품 경험에 포함돼 있는가?

C. 장기 실행 에이전트 팀

상태 전이 표가 존재하는가?
세션 저장소가 durable한가?
webhook resume이 idempotent한가?
사람이 강제로 상태를 고칠 수 있는 관리자 경로가 있는가?
서브에이전트 권한이 분리돼 있는가?

D. 브라우저형 에이전트 팀

허용 도메인 목록이 있는가?
다운로드 정책이 있는가?
브라우저 세션 저장 정책이 있는가?
내부 CA 신뢰 체계를 안전하게 관리하는가?
접근 로그를 감사용으로 남기는가?

E. 음성 에이전트 팀

first audio latency를 따로 재는가?
reconnect failure를 따로 추적하는가?
function call 동안의 silence masking이 설계돼 있는가?
모바일/웹/데스크톱의 품질 차이를 관찰하는가?
packet loss와 poor network에서 graceful degradation이 있는가?

F. 보안·플랫폼 팀

MCP/A2A/Skill registry가 있는가?
신규 자산 자동 스캔이 있는가?
runtime boundary와 app policy가 분리돼 있는가?
audit trail이 agent-to-agent 경로까지 이어지는가?
exception workflow가 과도하게 많지 않은가?

G. 로컬 AI 팀

스킬 저장소 검토·승인·폐기 정책이 있는가?
로컬 파일/앱 권한을 작업별로 최소화했는가?
상시 실행 세션 청소 정책이 있는가?
하드웨어별 지원 프로파일을 명확히 정의했는가?
행동 이력을 사용자가 볼 수 있는가?

H. 연구·평가 팀

멀티데이 평가 시나리오가 있는가?
실패 로그를 구조화해 저장하는가?
시뮬레이션 환경 자산이 있는가?
reward proxy 후보를 고민해 봤는가?
inference 평가와 long-horizon task 평가를 분리하는가?

마지막 정리: 오늘 이후의 경쟁 구도

오늘의 발표를 가장 짧게 정리하면 “에이전트가 제품이 되는 과정”이라고 할 수 있습니다. 하지만 조금 더 정확하게 말하면, 에이전트가 운영체계화되는 과정입니다. 이제 경쟁은 모델 레벨, 프롬프트 레벨에서 멈추지 않습니다. 다음과 같은 층위에서 동시에 벌어집니다.

사용자가 어디서 agent를 부르는가
agent가 얼마나 오래 맥락을 유지하는가
사람 승인을 어떤 리듬으로 받는가
어떤 정책이 tool loop를 감싸는가
브라우저/파일/네트워크 경계를 무엇이 강제하는가
어떤 connector와 skill이 등록·스캔·감사되는가
로컬과 클라우드의 분업을 어떻게 설계하는가
장기적으로 학습 가능한 실패 신호를 어떻게 쌓는가

오늘 OpenAI, Anthropic, Google, AWS, NVIDIA는 각각 이 스택의 다른 면을 드러냈습니다. 이 조합을 이해한 팀은 “새 기능을 따라간다”를 넘어서, 어떤 층을 직접 구축하고 어떤 층은 플랫폼에 기대야 하는지를 더 선명하게 판단할 수 있습니다.

이 점에서 오늘은 단순한 뉴스의 날이 아니라, 에이전트 산업의 설계 문법이 조금 더 명확해진 날입니다. 앞으로 좋은 AI 제품은 더 똑똑한 답변만으로는 부족합니다. 더 길게 일하고, 더 좁게 권한을 쓰고, 더 잘 이어받고, 더 잘 감사되고, 더 쉽게 승인받고, 더 적절한 순간에 사람을 다시 부를 수 있어야 합니다. 오늘의 공식 발표들은 모두 바로 그 방향을 가리키고 있습니다.

측정해야 현실이 보인다: 뉴스별 추천 KPI와 운영 알람

오늘 나온 발표들은 전부 운영형 AI를 향하고 있기 때문에, 읽고 나서 바로 해야 할 일은 “어떤 지표로 이 층을 볼 것인가”를 정하는 것입니다. 지표가 없으면 팀은 문제를 모델 탓으로 돌리거나, 반대로 보안 탓으로만 돌리기 쉽습니다. 아래 KPI는 오늘 발표를 실제 운영 지표로 번역한 버전입니다.

1. 모바일/장기 실행 코딩 에이전트 KPI

task continuation rate: 사용자가 자리를 비운 뒤에도 작업이 중단 없이 계속된 비율
approval turnaround time: 승인 요청부터 사용자 승인/거절까지 걸린 시간
mid-task redirection rate: 사용자가 중간에 방향 전환을 주고 작업이 성공적으로 반영된 비율
diff review acceptance rate: 에이전트 제안 diff가 최종 채택된 비율
background task abandonment rate: 작업이 장기화되면서 사실상 버려진 비율

이 지표가 낮다면 원인은 대개 모델 능력 부족이 아니라 승인 UX, 요약 품질, 모바일 상호작용 밀도에 있습니다.

2. 민감 대화 안전 KPI

context-sensitive safe response rate: 누적 문맥이 중요한 케이스에서 안전 응답 비율
false escalation rate: 평범한 대화를 과도하게 위험으로 보는 비율
cross-session signal detection rate: 여러 세션에 걸친 위험 신호 포착률
safety summary factuality score: 요약의 사실 정확도
ordinary conversation regression score: 안전 기능 도입 후 일반 대화 품질 저하 여부

안전 기능은 강해도 문제고 약해도 문제입니다. 따라서 오탐과 미탐을 같이 보는 지표 세트가 필요합니다.

3. SMB 업무 패키지 KPI

workflow completion rate: 사용자가 시작한 업무 패키지가 실제 완료까지 이어진 비율
approval-before-send acceptance rate: 발송/지급/게시 전 제안안의 승인율
time saved per workflow: 기존 수작업 대비 절감 시간
partial failure incidence: 커넥터 간 불일치로 부분 실패가 난 비율
connector trust score: 권한/정합성 문제로 인한 이탈 혹은 지원 티켓 발생률

SMB 시장에서는 “정확도”보다 “이번 주 실제로 시간을 줄였는가”가 더 큰 지표일 수 있습니다.

4. 미들웨어/정책 층 KPI

fallback hit rate: 대체 모델로 전환된 비율
retry recovery rate: 재시도로 정상 복구된 비율
tool interrupt rate: 승인 인터럽트가 걸린 비율
policy violation prevention count: 미들웨어가 사전에 막아 낸 위험 행동 수
middleware tracing coverage: 각 실행에서 어떤 미들웨어가 개입했는지 추적 가능한 비율

미들웨어 품질은 “존재하는가”보다 “언제 실제로 구해 줬는가”를 봐야 합니다.

5. 장기 실행 에이전트 KPI

resume success rate: pause 이후 정확한 상태로 재개된 비율
duplicate event idempotency rate: 중복 이벤트가 들어와도 정상 수렴한 비율
state transition accuracy: 허용된 전이만 일어난 비율
orphaned session count: 아무도 모르게 남아 버린 세션 수
human takeover efficiency: 사람이 수동 개입해 정상 마감까지 걸린 시간

이 지표가 없으면 장기 실행 에이전트는 “대충 되는 듯 보이다가 가끔 이상해지는 시스템”으로 남습니다.

6. 브라우저형 에이전트 KPI

blocked-domain trigger count: 차단된 도메인 접근 시도 수
approved-domain success rate: 허용된 사이트에서 정상 완료 비율
download policy violation count: 비정상 다운로드 시도 수
internal CA connection success rate: 사설 CA 내부 서비스 접속 성공률
browser action audit completeness: 브라우저 행동 로그의 완전성

브라우저는 특히 보안 위반 수와 정상 업무 수행률을 같이 봐야 합니다. 차단이 많다고 무조건 좋은 것도, 적다고 좋은 것도 아닙니다.

7. 실시간 음성 에이전트 KPI

first audio latency
turn completion latency
reconnection recovery time
function-call masking satisfaction: 도구 호출 대기 시간 동안 사용자가 체감한 품질
multilingual turn stability
network degradation survival rate

음성에서는 “모델이 대답했는가”보다 “대화 흐름이 깨지지 않았는가”가 핵심입니다.

8. 레지스트리/거버넌스 KPI

registered asset coverage: 전체 agent/MCP/Skill 중 registry에 등록된 비율
scan-before-use coverage: 사용 전 자동 스캔을 거친 자산 비율
exception path frequency: 우회 승인 경로가 쓰인 빈도
ownership completeness: 소유자·버전·scope·만료일 정보가 채워진 비율
audit query time: 특정 agent 경로를 재구성하는 데 걸리는 시간

거버넌스 시스템은 종종 “있다”고만 말하고 실제 커버리지를 측정하지 않습니다. 이 지표를 봐야 진짜 수준이 보입니다.

9. 로컬 에이전트 KPI

skill reuse rate: 저장된 스킬이 실제로 재사용된 비율
skill rollback count: 잘못된 스킬을 폐기/롤백한 횟수
long-session drift incidents: 오래 켜 둔 세션에서 품질 드리프트가 감지된 횟수
local action explainability score: 사용자가 “왜 이 행동을 했는가”를 이해할 수 있는 정도
hardware performance floor: 최소 지원 장비에서의 응답성 기준 충족률

로컬 에이전트는 지능의 피크보다 장시간 사용성의 바닥선이 더 중요합니다.

10. RL/평가 자산 KPI

simulation coverage: 핵심 워크플로 중 시뮬레이션 가능한 비율
failure taxonomy completeness: 실패 유형 분류표의 커버리지
log-to-eval conversion rate: 운영 실패 로그가 평가셋으로 전환된 비율
long-horizon task score: 단발성 응답이 아니라 긴 작업 완주 성능
environment reset cost: 반복 평가 환경을 리셋하는 데 드는 비용과 시간

이 지표들은 아직 대부분의 팀에 없지만, 앞으로 점점 더 중요해질 것입니다.

Build vs Buy 판단 프레임: 오늘 뉴스를 기준으로 무엇을 직접 만들고 무엇을 빌려 쓸 것인가

에이전트 스택이 복잡해질수록 모든 것을 직접 만드는 팀은 오히려 느려질 수 있습니다. 오늘 발표를 기준으로 보면, build와 buy의 경계는 다음처럼 생각할 수 있습니다.

직접 만들 가치가 큰 영역

1. 도메인 상태 머신

장기 실행 흐름의 상태 정의, 승인 포인트, 예외 처리 규칙은 업무의 본질과 맞닿아 있습니다. 이 부분은 외부 플랫폼이 기본 틀을 제공하더라도, 최종 설계는 직접 가져가는 편이 경쟁력이 큽니다.

2. 도메인 패키지 UX

Anthropic이 보여 준 것처럼 사용자가 진짜 사는 것은 업무 묶음입니다. 이 묶음의 명명, 입력 폼, 승인 미리보기, 결과 보고 구조는 고객 이해의 깊이와 연결되므로 직접 설계할 가치가 큽니다.

3. 공통 정책 미들웨어 중 조직 특화 규칙

Genkit 같은 프레임워크가 기본 retry/fallback을 주더라도, 우리 조직의 secret policy, 특정 리포 규칙, 승인 절차, 감사 로깅 형태는 직접 만드는 편이 좋습니다.

4. 평가 자산과 실패 taxonomy

시뮬레이션 시나리오, golden eval, long-horizon failure set은 장기적으로 매우 강한 방어력이 됩니다. 특히 RL 시대를 생각하면 더 그렇습니다.

빌려 쓰는 편이 유리한 영역

1. 원격 세션/모바일 제어 인프라

OpenAI가 보여 준 secure relay, live state sync, cross-device continuity 같은 영역은 구현 난도가 높습니다. 직접 만드는 팀은 유지 비용을 과소평가하기 쉽습니다.

2. 브라우저 엔터프라이즈 정책 적용 기반

Chrome enterprise policy 지원, CA trust chain, managed browser runtime은 엔드포인트·보안 지식이 많이 들어갑니다. 검증된 기반을 쓰는 편이 낫습니다.

3. 대규모 registry/scanning 프레임워크

MCP/A2A/Skill 등록과 자동 스캔 계층은 플랫폼으로 묶일수록 이점이 큽니다. 처음부터 전부 독자 구현할 이유는 적습니다.

4. 음성 스트리밍 기반

실시간 음성의 하부 스트리밍 스택은 직접 구축 비용이 상당합니다. 차별화는 상위 도메인 경험과 tool orchestration에서 만들고, 하부 인프라는 검증된 패턴을 활용하는 편이 현실적입니다.

Build/Buy가 갈리는 질문 10개

이 기능이 고객에게 직접 보이는 차별화인가?
도메인 이해가 깊어질수록 가치가 커지는 부분인가?
한번 만들어 놓으면 여러 팀이 재사용할 수 있는가?
보안·감사 요구가 매우 강한가?
구현보다 운영 유지비가 더 큰 영역인가?
공급자가 이미 안정된 기본기를 제공하는가?
우리 팀이 실패해도 감당 가능한 영역인가?
벤더 종속보다 속도가 더 중요한 시점인가?
이 자산이 장기적으로 평가/학습 자산으로도 이어지는가?
고객이 돈을 지불하는 이유와 직접 연결되는가?

이 질문에 답해 보면, 어디를 플랫폼에 기대고 어디를 직접 가져갈지 훨씬 선명해집니다.

도메인별 적용 지도

1. 개발 생산성 도메인

오늘 뉴스에서 가장 직접적으로 도움 되는 것은 OpenAI Codex 모바일 확장, Google Genkit Middleware, Google ADK 상태 머신입니다. 개발 생산성 팀은 여기서 세 가지 제품 방향을 동시에 잡을 수 있습니다.

비동기 작업형 코딩 에이전트
리포 정책 훅이 강한 에이전트
오래 걸리는 개발 작업을 서브에이전트와 체크포인트로 분해하는 구조

예를 들어 “legacy module migration assistant” 같은 제품을 만든다면, 모바일 승인·repo hook·stateful task decomposition이 모두 필요합니다.

2. 회계·재무 도메인

Anthropic SMB, SAP/OpenShell, AWS Registry 모델이 특히 중요합니다. 회계·재무 영역은 사람이 승인해야 할 액션이 많고, 데이터 권한이 민감하며, 감사 추적이 필수입니다. 따라서 이 도메인에서는 범용 agent보다 다음이 더 중요합니다.

업무 패키지화
강한 승인 흐름
시스템 오브 레코드와의 신뢰 경계
registry 기반 자산 관리
실행·계획 분리

3. 인사·운영 도메인

Google ADK의 온보딩 예시는 HR에 매우 직접적입니다. 입사, 장비 지급, 계약 갱신, 휴가 승인, 교육 이수, 평가 주기 관리 같은 업무는 모두 state machine 친화적입니다. 이 도메인에서는 long-running orchestration이 곧 제품 경쟁력입니다.

4. 고객지원 도메인

OpenAI의 safety context와 AWS voice stack이 함께 중요합니다. 고객지원은 장기 대화, 감정적 맥락, 다양한 채널, 빠른 응답 기대가 함께 존재합니다. 따라서 안전 메모리와 음성 세션 품질을 따로 설계해야 합니다.

5. 내부 IT/헬프데스크 도메인

브라우저형 에이전트, registry, runtime boundary가 모두 중요합니다. 내부 시스템 접근이 많고, private CA나 사내 포털 접속이 흔하기 때문에 AWS AgentCore Browser류 기능의 가치가 큽니다.

6. 로컬 생산성 도메인

NVIDIA Hermes는 개발자, 크리에이터, 연구자, 운영자 개인용 자동화에 잘 맞습니다. 특히 반복적인 파일 정리, 로컬 툴 연동, 개인 workflow 축적이 중요한 도메인에 유리합니다.

7. 연구 자동화 도메인

RL 인프라 발표는 연구 자동화에도 중요합니다. 실험 계획, 환경 시뮬레이션, 반복 평가 루프가 많은 도메인은 장기적으로 experience-based improvement의 혜택을 크게 받을 수 있습니다.

8. ERP/공급망 도메인

SAP/OpenShell은 이 도메인의 핵심입니다. 에이전트가 실제로 재고, 발주, 조달, 공급망 이슈를 건드리는 순간 런타임 containment와 app policy의 분리가 필수입니다.

40개의 점검 질문

전략

우리 제품의 핵심 가치는 모델 성능인가, 워크플로 완결성인가?
고객이 가장 자주 반복하는 업무 묶음은 무엇인가?
장기 실행이 필요한 작업을 단발성 채팅으로 처리하려 하고 있지 않은가?
로컬과 클라우드 중 무엇을 어디에 배치할지 원칙이 있는가?
우리 팀은 어떤 층에서 차별화하고 어떤 층은 플랫폼에 기대야 하는가?

UX

사용자 승인 피로도는 어느 정도인가?
모바일에서 처리 가능한 승인과 아닌 승인을 구분했는가?
결과 보고는 diff/log/raw data가 아니라 행동 가능한 요약으로 제공되는가?
음성 대기 시간 동안의 경험을 설계했는가?
업무 패키지 entry point가 직관적인가?

상태 관리

현재 단계가 명시적 상태값인가?
상태 전이 표가 존재하는가?
중복 이벤트에 안전한가?
재시작 후 복원되는가?
사람이 상태를 수동 수정할 수 있는가?

정책

destructive tool approval 기준이 있는가?
filesystem scope가 강제되는가?
fallback 기준이 정의돼 있는가?
브라우저 허용 도메인 목록이 있는가?
안전 메모리와 일반 메모리가 분리돼 있는가?

거버넌스

모든 MCP/A2A/Skill이 등록되는가?
소유자가 명확한가?
자동 스캔이 있는가?
예외 승인 절차가 통제되는가?
감사팀이 이해할 수 있는 로그 구조인가?

운영

orphan session이 몇 개인지 아는가?
장기 세션 만료 기준이 있는가?
partial failure를 어떻게 사용자에게 설명하는가?
private CA 접속 실패 시 운영자가 어디를 봐야 하는가?
로컬 스킬 품질 드리프트를 어떻게 감지하는가?

평가

멀티데이 시나리오가 평가셋에 있는가?
blocked domain 시나리오가 있는가?
reconnect failure 시나리오가 있는가?
cross-session safety 시나리오가 있는가?
human takeover efficiency를 재는가?

장기 학습

실패 로그를 구조화해 저장하는가?
시뮬레이션 가능한 환경이 있는가?
reward proxy를 생각해 본 적 있는가?
long-horizon task quality를 따로 보나?
오늘의 운영 데이터를 내일의 개선 자산으로 바꿀 파이프라인이 있는가?

이 질문 목록은 조직의 현재 성숙도를 빠르게 자가 진단하는 데 유용합니다.

아주 짧은 최종 요약

오늘 발표들을 한 줄씩만 다시 압축하면 이렇습니다.

OpenAI Codex 모바일: 에이전트와 협업하는 시간 구조를 바꿨다.
OpenAI 안전 맥락: 메모리를 안전 계층으로 재정의했다.
Anthropic SMB: AI를 범용 도구가 아니라 업무 패키지로 팔기 시작했다.
Google Middleware: 운영형 AI 앱의 정책 부품을 표준화했다.
Google ADK: 장기 실행 에이전트를 워크플로 엔진 문법으로 옮겼다.
AWS Browser Policy: 브라우저형 에이전트를 엔터프라이즈 정책 아래 넣기 시작했다.
AWS Voice: 음성 에이전트가 미디어 시스템 문제임을 다시 확인시켰다.
AWS/Cisco Registry: 에이전트 생태계의 공급망 보안을 공식 의제로 올렸다.
NVIDIA/SAP: 시스템 오브 레코드 위 agent의 신뢰 런타임을 밀었다.
NVIDIA Hermes: 로컬 상시형 에이전트 운영체제의 방향을 보여 줬다.
NVIDIA/Ineffable: 미래의 agent 능력이 경험 기반 학습 인프라에 달려 있음을 드러냈다.

이 요약을 종합하면, 오늘은 모델 뉴스의 날이 아니라 에이전트 실행 계층의 날이었습니다.

실무 플레이북 6종

플레이북 1. 코딩 에이전트를 팀 표준 도구로 만들기 위한 최소 조건

코딩 에이전트는 데모는 쉽고 팀 표준화는 어렵습니다. 표준 도구가 되려면 단순히 코드 제안 품질이 아니라 조직적 신뢰를 얻어야 합니다. 오늘 OpenAI와 Google 발표를 바탕으로 보면, 최소 조건은 다음 여섯 가지입니다.

장기 실행 전제
작업이 3분 이상 걸리면 이미 동기식 Q&A 도구가 아니라 장기 실행 도구로 설계해야 합니다.
모바일/원격 승인 가능성
사용자는 항상 개발 머신 앞에 있지 않습니다. 승인 병목이 데스크톱에 묶이면 에이전트 활용이 줄어듭니다.
리포 정책 자동 적용
훅, 미들웨어, 검증 스크립트로 secret scan, test gate, style gate, protected path를 강제해야 합니다.
diff 중심 결과 검토
장황한 설명보다, 어떤 파일이 어떻게 바뀌고 어떤 테스트가 통과/실패했는지가 핵심입니다.
권한 단계화
읽기, 워크스페이스 쓰기, 패키지 설치, 네트워크, git push를 분리하지 않으면 팀 차원의 채택이 어렵습니다.
중간 요약 능력
에이전트가 장시간 일할수록 사용자는 모든 로그를 읽지 않습니다. 요약 품질이 곧 협업 품질입니다.

실전에서는 보통 모델을 먼저 바꾸려는 유혹이 큽니다. 하지만 팀 도입률을 가장 크게 바꾸는 것은 의외로 approval turnaround, diff review clarity, repo hook reliability 같은 운영 지표입니다. 오늘 OpenAI의 모바일 Codex와 Google의 middleware는 바로 이 지점을 건드립니다.

플레이북 2. SMB AI 제품을 “기능 목록”에서 “업무 패키지”로 바꾸는 방법

Anthropic의 Small Business 발표는 SMB 제품팀에게 사실상 템플릿을 제공합니다. 이를 실무적으로 번역하면 다음 5단계 플레이북이 나옵니다.

1단계: 반복 업무 하나를 고른다

좋은 후보는 다음 조건을 동시에 만족합니다.

매주 또는 매월 반복된다
데이터가 여러 도구에 흩어져 있다
사람이 주로 복붙·정리·초안 작업을 한다
최종 승인자는 여전히 사람이다

2단계: 도구보다 결과물을 먼저 정의한다

예를 들어 “QuickBooks 연동”이 아니라 “이번 달 close packet 초안 자동 준비”를 결과물로 정의합니다.

3단계: 승인을 흐름의 끝이 아니라 구조의 일부로 넣는다

SMB 사용자는 시간을 아끼고 싶지만 통제권을 버리진 않습니다. 발송·지급·게시 같은 순간은 승인 이벤트로 노출해야 합니다.

4단계: 부분 실패를 설명한다

회계 데이터는 맞는데 결제 데이터 동기화가 늦는 상황은 흔합니다. 부분 실패를 숨기면 신뢰를 잃고, 드러내면 오히려 신뢰를 얻습니다.

5단계: 교육을 제품 안으로 가져온다

Anthropic이 AI Fluency를 붙인 이유가 이것입니다. SMB 사용자는 기능을 이해하지 못해서가 아니라, “언제 쓰면 되는지”를 몰라서 안 쓰는 경우가 많습니다.

이 다섯 단계만 잘 지켜도 SMB AI 제품은 범용 챗 UI보다 훨씬 빠르게 실제 업무 시간을 줄이는 방향으로 갈 수 있습니다.

플레이북 3. 장기 실행 에이전트 설계 리뷰 순서

Google ADK 발표를 팀 리뷰 체크리스트로 바꾸면, 긴 워크플로를 설계할 때 아래 순서가 가장 효율적입니다.

1. 상태 전이 표부터 만든다

화면이나 프롬프트보다 먼저 어떤 상태가 있는가를 적습니다. 시작, 대기, 승인 필요, 외부 이벤트 대기, 완료, 실패, 수동 개입 필요 같은 상태를 먼저 정의합니다.

2. 각 상태에서 허용되는 행동을 적는다

예를 들어 DOCUMENTS_SIGNED 상태에서만 IT provisioning tool을 부를 수 있게 합니다. 상태별 허용 행동을 명확히 하면 hallucinated step을 크게 줄일 수 있습니다.

3. 외부 이벤트를 찾는다

어떤 단계가 사람 메시지가 아니라 webhook이나 시스템 이벤트로 재개되는지 분리합니다. 이 분리가 없으면 결국 폴링이 남발되거나 채팅 기록이 비대해집니다.

4. 사람 개입 지점을 찾는다

모든 단계에 human-in-the-loop가 필요한 것은 아닙니다. 그러나 필요한 단계는 명확해야 합니다.

5. 복구 시나리오를 만든다

컨테이너 재시작, 중복 이벤트, 외부 시스템 장애, 승인 지연, 수동 수정 같은 복구 경로를 미리 적어 둡니다.

많은 팀이 이 순서를 뒤집어 UI나 프롬프트부터 만듭니다. 하지만 그 방식은 대부분 장기 실행에서 깨집니다. Google의 발표는 상태와 세션을 먼저 잡으라고 말하고 있습니다.

플레이북 4. 브라우저형 에이전트의 최소 보안 기준

브라우저 자동화는 편리하지만 위험합니다. AWS 발표를 바탕으로 한 최소 기준은 다음과 같습니다.

허용 도메인 목록이 있다
차단 도메인 정책이 있다
다운로드 경로와 보존 정책이 있다
private CA 기반 내부 서비스 접속 정책이 있다
브라우저 자격증명 저장 정책이 있다
브라우저 행동 로그가 남는다
읽기 전용 접근과 쓰기 접근이 구분된다
비브라우저 API로 대체 가능한 작업은 굳이 브라우저로 하지 않는다

이 기준을 못 맞추면 브라우저형 에이전트는 초반 PoC 이후 엔터프라이즈 검토 문턱에서 멈출 가능성이 큽니다.

플레이북 5. 실시간 음성 에이전트 품질 개선 순서

음성 에이전트는 종종 잘못된 순서로 최적화됩니다. 모델을 바꾸기 전에 먼저 봐야 할 것은 다음 순서입니다.

first audio latency
reconnect behavior
turn boundary handling
function-call silence masking
client/device compatibility
multilingual stability
model response quality

즉 모델은 중요하지만, 실무에서 가장 먼저 무너지는 부분은 대개 시스템 계층입니다. AWS와 Stream의 발표는 그 점을 잘 보여 줍니다.

플레이북 6. registry 도입을 늦추지 말아야 하는 이유

AWS/Cisco 모델은 조직이 왜 초기에 registry를 넣어야 하는지 설명합니다. 에이전트 자산은 생각보다 빨리 늘어납니다. 그리고 늘어난 뒤에는 되돌리기 어렵습니다. registry가 필요한 이유를 한 문장으로 요약하면 이렇습니다. 보여야 자동화할 수 있고, 자동화돼야 확장이 버틴다.

보이지 않으면 승인도 수동이다
수동이면 속도가 느리다
속도가 느리면 우회가 생긴다
우회가 생기면 shadow agent가 늘어난다
shadow agent가 늘어나면 감사가 불가능해진다

따라서 registry는 속도를 늦추는 게 아니라, 더 큰 속도를 장기적으로 가능하게 만드는 장치입니다.

벤더별 신호를 경쟁 구도로 읽기

OpenAI의 신호

OpenAI는 오늘 두 방향을 동시에 보여 줬습니다. 하나는 Codex를 통해 작업 제어면을 넓히는 방향이고, 다른 하나는 ChatGPT를 통해 문맥 기반 안전 계층을 정교화하는 방향입니다. 즉 OpenAI는 생산성과 안전을 각각 따로 확장하는 것이 아니라, 장기 문맥을 더 많이 다루는 제품일수록 안전 설계도 같이 커져야 한다는 신호를 보냅니다. 장기적으로는 이것이 ChatGPT 생태계 전체의 기본 문법이 될 가능성이 있습니다.

Anthropic의 신호

Anthropic은 범용 모델 경쟁을 넘어 업무 패키지 시장을 본격적으로 열고 있습니다. Claude for Small Business는 엔터프라이즈 계약과는 다른 축입니다. 이는 “작은 조직도 agentic workflow를 살 준비가 되어 있다”는 가설에 베팅하는 것으로 읽힙니다. 이 시장이 열리면 vertical SaaS와의 협력·경쟁도 더 치열해질 수 있습니다.

Google의 신호

Google은 모델보다 프레임워크와 운영 구조를 통해 영향력을 넓히고 있습니다. Genkit Middleware와 ADK 장기 실행 패턴은 결국 개발자들이 Google식 agent architecture를 자연스럽게 받아들이게 만드는 도구입니다. 이는 플랫폼 잠금이 아니라 설계 문법 잠금에 가깝습니다. 프레임워크를 채택한 팀은 이후 Google 생태계 자산과 더 잘 맞물릴 가능성이 높습니다.

AWS의 신호

AWS는 agent를 “인프라 위에서 돌려야 하는 실제 시스템”으로 가장 강하게 밀고 있습니다. 브라우저 정책, 음성 인프라, MCP/A2A 레지스트리와 보안 자동화는 모두 운영 중심 주제입니다. AWS의 강점은 여기서 분명합니다. 모델 경쟁보다는 운영 계층을 안전하고 관리 가능하게 만드는 기본기를 전면에 내세웁니다.

NVIDIA의 신호

NVIDIA는 application trust runtime, local agent computer, RL infrastructure를 한꺼번에 얘기합니다. 이는 NVIDIA가 단순 칩 회사가 아니라 agent 시대의 compute + runtime + reference architecture company가 되려 한다는 신호로 읽힙니다. OpenShell, NemoClaw, Hermes, RL pipeline 같은 단어를 함께 보면 방향이 분명합니다.

지금 시작하면 좋은 내부 문서 8종

오늘 뉴스가 보여 준 성숙도를 따라가려면, 제품 코드보다 먼저 문서가 필요한 경우가 많습니다. 특히 다음 8종 문서는 큰 비용 대비 효과가 큽니다.

Agent State Transition Spec
상태명, 전이 조건, 재개 조건, 실패 조건, 수동 개입 경로를 적는다.
Tool Permission Matrix
툴별로 읽기/쓰기/네트워크/승인 여부를 표로 정리한다.
Browser Access Policy
허용 도메인, 차단 도메인, 다운로드 정책, 인증서 신뢰 규칙을 적는다.
Connector Ownership Register
누가 어느 커넥터를 소유하고, 어떤 scope를 쓰고, 언제 재검토할지 적는다.
Skill Governance Guide
스킬 생성, 검토, 배포, 폐기, rollback 기준을 적는다.
Voice Session Quality Spec
latency budget, reconnect UX, fallback flow를 정리한다.
Safety Memory Policy
어떤 안전 문맥을 얼마나 오래, 어떤 목적에 한해 보존할지 적는다.
Failure Taxonomy for Agents
tool failure, policy denial, stale context, duplicate event, partial success, hallucinated step 같은 실패 유형을 구조화한다.

문서를 먼저 적는다고 속도가 느려지는 게 아닙니다. agent 시스템에서는 오히려 문서가 없으면 같은 실패를 계속 반복하게 됩니다.

오늘 뉴스가 남긴 가장 실용적인 결론 12가지

에이전트는 길게 일하므로 모바일 감독이 중요해진다.
장기 문맥은 생산성 기능이면서 안전 기능이기도 하다.
SMB 시장은 기능보다 업무 패키지를 산다.
AI 앱은 미들웨어 표준화 단계에 들어섰다.
상태 머신 없는 장기 실행 agent는 결국 무너질 가능성이 높다.
브라우저형 agent는 엔터프라이즈 정책을 먹어야 한다.
실시간 음성은 대화 모델이 아니라 스트리밍 시스템의 문제이기도 하다.
MCP/A2A/Skill은 점점 소프트웨어 공급망처럼 관리돼야 한다.
시스템 오브 레코드 위 agent는 runtime boundary와 app policy를 동시에 가져야 한다.
로컬 에이전트는 신뢰 UX와 스킬 거버넌스가 관건이다.
미래의 더 강한 agent 품질은 경험 기반 학습 인프라와 연결될 수 있다.
결국 승부는 모델 자체보다 실행 계층 전체에서 난다.

이 12가지는 오늘 발표들의 공통분모입니다. 개별 벤더 이름을 빼고 봐도 성립합니다. 그래서 더 중요합니다.

자주 받게 될 질문과 짧은 답변

Q1. 지금 가장 과대평가된 것은 무엇인가?

A. “좋은 모델이면 운영 문제도 자연스럽게 풀린다”는 기대입니다. 오늘 발표들은 오히려 그 반대를 보여 줍니다. 좋은 모델일수록 더 긴 작업, 더 많은 툴, 더 민감한 데이터에 닿게 되고, 그 결과 운영 문제는 더 커집니다.

Q2. 지금 가장 과소평가된 것은 무엇인가?

A. 승인 UX와 상태 관리입니다. 실제 도입률은 종종 모델보다 이 둘이 좌우합니다.

Q3. 왜 모바일 감독이 중요한가?

A. 장기 실행 작업은 사람이 항상 책상 앞에 없다는 사실을 전제로 해야 하기 때문입니다.

Q4. 왜 SMB는 패키지형이 잘 맞는가?

A. 작은 조직은 자유도보다 즉시 효용이 큰 업무 묶음을 선호하기 때문입니다.

Q5. 왜 middleware가 중요한가?

A. 앱 코드와 프롬프트에 흩어진 정책을 재사용 가능한 부품으로 끌어올리기 때문입니다.

Q6. 왜 상태 머신을 먼저 생각해야 하나?

A. 장기 실행에서 채팅 기록은 진실 소스가 되기 어렵기 때문입니다.

Q7. 브라우저형 에이전트는 왜 보안팀을 일찍 불러야 하나?

A. 허용 도메인, 인증서, 다운로드, 세션 저장 같은 문제는 뒤늦게 붙이기 어렵기 때문입니다.

Q8. 실시간 음성은 왜 항상 생각보다 어려운가?

A. 사용자가 즉각적 자연스러움을 기대하기 때문에 작은 지연과 끊김도 크게 느껴지기 때문입니다.

Q9. registry는 왜 초기에 넣어야 하나?

A. 자산 수가 늘어난 뒤에는 ownership과 scope를 되돌리기가 훨씬 어렵기 때문입니다.

Q10. 로컬 에이전트는 왜 다시 중요해지나?

A. 민감 데이터, 낮은 지연, 개인 workflow 축적이라는 장점이 있기 때문입니다.

Q11. RL 인프라 뉴스가 왜 제품팀에도 중요한가?

A. 미래의 기본 agent 능력이 경험 기반 학습으로 크게 달라질 수 있기 때문입니다.

Q12. 오늘 뉴스의 공통 핵심은?

A. 모델 자체보다 실행 계층이 경쟁력이 되고 있다는 점입니다.

회의실에서 바로 쓸 수 있는 안건 템플릿

제품팀 주간 회의 안건

우리 제품에서 가장 먼저 패키지화할 수 있는 반복 업무는 무엇인가?
사용자가 자리를 비운 상태에서도 진행돼야 하는 작업은 무엇인가?
승인 이벤트는 어디서 발생하며, 너무 잦지는 않은가?
결과 보고는 사용자가 실제로 이해할 수 있는 단위인가?
도메인 패키지 이름을 기능이 아니라 결과 중심으로 바꿀 수 있는가?

플랫폼팀 주간 회의 안건

공통 middleware로 묶을 수 있는 정책은 무엇인가?
어떤 long-running workflow가 채팅 로그에 상태를 숨기고 있는가?
registry 대상 자산의 범위를 어디까지 볼 것인가?
세션 저장소와 로그 구조는 충분히 durable한가?
fallback/approval/filesystem scoping의 조직 표준은 무엇인가?

보안팀 주간 회의 안건

브라우저형 agent의 허용 도메인 정책은 준비됐는가?
MCP/A2A 자산 중 shadow deployment는 없는가?
private CA 접속 정책은 agent 사용을 가정해 검토되었는가?
runtime boundary와 app policy의 책임 경계는 분명한가?
감사 시나리오를 실제로 재구성해 보았는가?

운영팀 주간 회의 안건

orphan session은 얼마나 쌓이고 있는가?
partial failure는 어떤 유형이 많은가?
reconnect failure나 blocked domain은 어떤 조건에서 많이 나는가?
사람 takeover가 자주 필요한 지점은 어디인가?
로그에서 반복되는 failure signature는 무엇인가?

연구/평가팀 주간 회의 안건

long-horizon task 평가셋이 있는가?
cross-session safety 평가를 할 수 있는가?
failure taxonomy는 충분히 세분화돼 있는가?
운영 로그가 평가셋으로 전환되는가?
시뮬레이션 환경의 reset 비용은 감당 가능한가?

다음 분기에 가장 유력한 후속 흐름

오늘 발표를 기반으로 보면 다음 분기에는 아래 흐름이 더 강해질 가능성이 큽니다.

1. 에이전트용 전용 제어면 확산

모바일, 메신저, 대시보드, 승인 센터를 통해 장기 실행 작업을 감독하는 전용 UI가 더 많이 나올 것입니다.

2. 도메인 패키지 경쟁 심화

회계, 영업, 채용, 법무, 조달처럼 반복 업무가 뚜렷한 분야에서 ready-to-run workflow 경쟁이 커질 가능성이 높습니다.

3. 정책 미들웨어 표준화

Retry, approval, scoping, audit 같은 부품이 거의 모든 주요 프레임워크의 기본 문법이 될 수 있습니다.

4. browser governance 고도화

단순 브라우저 자동화를 넘어 domain policy, cert trust, download control, identity delegation까지 포함한 브라우저 런타임 경쟁이 심화될 수 있습니다.

5. registry와 scan의 기본화

MCP/A2A/Skill이 늘어날수록 등록과 스캔은 선택 기능이 아니라 기본 기능이 될 가능성이 큽니다.

6. local agent + enterprise runtime 양극 성장

개인 워크스테이션용 상시형 로컬 에이전트와, SAP/ERP 같은 엔터프라이즈용 강한 런타임이 동시에 성장할 것입니다.

7. 경험 기반 평가 강화

단발성 응답 평가보다 long-running, tool-using, resume-capable task 평가가 더 중요해질 가능성이 큽니다.

이 예측은 전부 오늘 발표의 직접 연장선에 있습니다. 그래서 꽤 현실적입니다.

정말 마지막 한 문단

오늘의 뉴스는 모두 같은 말을 다른 언어로 하고 있습니다. OpenAI는 협업 시간 구조를, Anthropic은 상용화 패키징을, Google은 프레임워크 문법을, AWS는 운영 통제를, NVIDIA는 런타임과 컴퓨트를 말합니다. 서로 다른 회사지만 결론은 하나입니다. 이제 AI는 똑똑한 답변을 만드는 산업을 넘어, 통제 가능한 실행을 설계하는 산업으로 이동하고 있다는 것입니다. 이 이동을 먼저 이해하는 팀일수록, 앞으로의 agent 경쟁에서 더 유리한 출발점을 가질 가능성이 높습니다.

소스 링크

OpenAI — Work with Codex from anywhere
https://openai.com/index/work-with-codex-from-anywhere/
OpenAI — Helping ChatGPT better recognize context in sensitive conversations
https://openai.com/index/chatgpt-recognize-context-in-sensitive-conversations/
Anthropic — Introducing Claude for Small Business
https://www.anthropic.com/news/claude-for-small-business
Google Developers Blog — Announcing Genkit Middleware: Intercept, extend, and harden your agentic apps
https://developers.googleblog.com/announcing-genkit-middleware-intercept-extend-and-harden-your-agentic-apps/
Google Developers Blog — Build Long-running AI agents that pause, resume, and never lose context with ADK
https://developers.googleblog.com/build-long-running-ai-agents-that-pause-resume-and-never-lose-context-with-adk/
AWS Machine Learning Blog — Control where your AI agents can browse with Chrome enterprise policies on Amazon Bedrock AgentCore
https://aws.amazon.com/blogs/machine-learning/control-where-your-ai-agents-can-browse-with-chrome-enterprise-policies-on-amazon-bedrock-agentcore/
AWS Machine Learning Blog — Real-time voice agents with Stream Vision Agents and Amazon Nova 2 Sonic
https://aws.amazon.com/blogs/machine-learning/real-time-voice-agents-with-stream-vision-agents-and-amazon-nova-2-sonic/
AWS Machine Learning Blog — Securing AI agents: How AWS and Cisco AI Defense scale MCP and A2A deployments
https://aws.amazon.com/blogs/machine-learning/securing-ai-agents-how-aws-and-cisco-ai-defense-scale-mcp-and-a2a-deployments/
NVIDIA Blog — NVIDIA and SAP Bring Trust to Specialized Agents
https://blogs.nvidia.com/blog/sap-specialized-agents/
NVIDIA Blog — Hermes Unlocks Self-Improving AI Agents, Powered by NVIDIA RTX PCs and DGX Spark
https://blogs.nvidia.com/blog/rtx-ai-garage-hermes-agent-dgx-spark/
NVIDIA Blog — NVIDIA, Ineffable Intelligence Team Up to Build the Future of Reinforcement Learning Infrastructure
https://blogs.nvidia.com/blog/ineffable-intelligence-reinforcement-learning-infrastructure/