Post

2026년 4월 25일 AI 뉴스 요약: AWS는 Frontier Agents와 추론 추천으로 에이전트 운영층을 상품화하고, Google은 Gemini Enterprise Agent Platform으로 메모리·거버넌스·보안을 묶으며, Meta는 Graviton 대규모 도입으로 agentic AI용 CPU 다변화를 선언하고, NVIDIA·DeepSeek는 1M 컨텍스트 장기 추론 인프라 경쟁을 본격화한다

· ai-daily-news
#ai #news #aws #frontier-agents #aws-security-agent #aws-devops-agent #sagemaker #inference-recommendations #nvidia-aiperf #google #gemini-enterprise-agent-platform #agent-platform #agent-runtime #memory-bank #agent-identity #meta #aws-graviton #deepseek #deepseek-v4 #nvidia #blackwell #long-context #agentic-ai #operations

오늘의 AI 뉴스

배경

2026년 4월 25일 KST 기준으로 오늘의 AI 뉴스를 길게 읽어 보면, 어제의 주제가 “누가 더 강한 모델을 냈는가”였다면 오늘의 주제는 훨씬 더 운영적입니다. 이제 시장의 중심 질문은 단순히 모델 벤치마크가 아닙니다.

그 모델과 에이전트를 실제 서비스 안에서 얼마나 오래, 얼마나 싸게, 얼마나 안전하게, 얼마나 추적 가능하게, 얼마나 큰 조직 단위로 굴릴 수 있는가.

오늘 공식 발표들은 이 질문에 서로 다른 레이어에서 답합니다.

  • AWS는 Security Agent와 DevOps Agent를 정식 출시하면서, 에이전트를 “보조 도구”가 아니라 몇 시간~며칠 동안 돌아가는 운영 파트너로 정의했습니다.
  • AWS는 동시에 SageMaker AI의 optimized generative AI inference recommendations를 내놓으며, 좋은 모델을 고르는 일보다 좋은 추론 구성을 자동으로 찾는 일이 더 중요해지고 있음을 보여 줬습니다.
  • Google은 Gemini Enterprise Agent Platform을 발표하며, 에이전트 개발 플랫폼의 핵심이 모델 API가 아니라 메모리, 런타임, 정체성, 게이트웨이, 위협 탐지, 관측성까지 포함한 통합 운영면이라는 점을 분명히 했습니다.
  • Meta는 AWS Graviton 코어 수천만 개 규모 도입을 발표하며, agentic AI 시대의 병목이 GPU만이 아니고, CPU·메모리 대역폭·추론 주변 처리까지 포함한 컴퓨트 포트폴리오 전략이 중요하다고 선언했습니다.
  • NVIDIA는 DeepSeek-V4-Pro / Flash를 Blackwell과 GPU-accelerated endpoint 위에서 바로 쓰는 흐름을 공개하며, 이제 오픈 계열 장기 컨텍스트 모델 경쟁의 핵심이 “모델 공개”가 아니라 1M 토큰을 실제로 감당하는 서빙 스택으로 넘어가고 있음을 보여 줬습니다.
  • DeepSeek 공식 사이트 역시 V4 프리뷰를 웹·앱·API에 공개했고 agent 능력이 크게 향상됐다고 전면에 걸었습니다. 즉 모델 회사도 이제 더 이상 “좋은 답변”만이 아니라 장기 에이전트 실행 적합성을 직접 팔고 있습니다.

겉으로 보면 오늘 뉴스는 각기 다른 카테고리처럼 보일 수 있습니다. AWS의 보안/운영 에이전트, SageMaker의 추론 최적화, Google의 엔터프라이즈 플랫폼, Meta의 인프라 파트너십, NVIDIA의 장기 컨텍스트 서빙, DeepSeek의 새 플래그십 모델. 하지만 이걸 한 번에 놓고 보면 아주 선명한 한 문장이 나옵니다.

AI 경쟁의 중심이 다시 한 단계 이동했다. 이제 승부는 모델 공개가 아니라, 장기 실행형 에이전트를 위한 운영체제·추론 경제성·거버넌스·컴퓨트 설계·오픈 배포 경로를 누가 더 잘 갖추느냐에 달려 있다.

오늘 글은 이 흐름을 단순 링크 모음으로 끝내지 않고 아래 질문에 답하는 방식으로 정리합니다.

  1. 오늘 공식 발표에서 정확히 무엇이 나왔는가
  2. 왜 이 뉴스를 따로 읽지 말고 하나의 흐름으로 읽어야 하는가
  3. 개발자, 플랫폼팀, 보안팀, 운영팀에게 각각 무슨 의미가 있는가
  4. 향후 제품 설계에서 무엇이 달라져야 하는가
  5. 지금 이번 주, 이번 달, 이번 분기에 무엇을 해야 하는가

오늘의 핵심 한 문장

2026년 4월 25일의 AI 뉴스는 시장이 프런티어 모델 경쟁 다음 단계인 ‘에이전트 운영 경쟁’으로 넘어갔음을 보여 주며, AWS는 자율 운영 에이전트와 추론 자동 최적화를, Google은 엔터프라이즈 제어면을, Meta는 CPU 다변화 인프라 전략을, NVIDIA·DeepSeek는 1M 컨텍스트 장기 추론 실행력을 전면에 내세우고 있습니다.

한눈에 보는 Top News

  • AWS Security Agent와 AWS DevOps Agent가 GA에 들어가며, 에이전트가 실제 보안 테스트와 SRE 운영의 장기 실행형 주체로 상품화되기 시작했다.
    Security Agent는 침투 테스트를 수주 단위에서 수시간 단위로 압축하고, DevOps Agent는 최대 75% MTTR 감소, 80% 빠른 조사, 94% root cause accuracy를 제시했다.

  • AWS SageMaker AI의 inference recommendations는 추론 최적화가 더 이상 수작업 성능 튜닝이 아니라 자동화된 플랫폼 기능이어야 함을 보여 준다.
    비용/지연/처리량 목표를 고르면 SageMaker가 후보 구성 축소, 최적화 적용, AIPerf 기반 실측, 배포 가능한 추천까지 내준다.

  • Google Gemini Enterprise Agent Platform은 에이전트 시대의 핵심이 모델 API가 아니라 런타임·메모리·정체성·게이트웨이·보안·관측성이라는 사실을 선명하게 보여 준다.
    Agent Runtime, Memory Bank, Agent Identity, Agent Registry, Agent Gateway, Agent Security 대시보드가 핵심이다.

  • Meta의 AWS Graviton 대규모 도입은 agentic AI 인프라에서 CPU가 다시 전략 자산이 되고 있음을 의미한다.
    Meta는 수천만 개의 Graviton 코어를 도입해 AI용 컴퓨트 소스를 다변화하고, CPU 집약적 agentic workload를 더 효율적으로 받치려 한다.

  • NVIDIA와 DeepSeek는 1M 컨텍스트 시대의 실제 배포 경쟁을 시작했다.
    DeepSeek-V4-Pro는 1.6T total / 49B active, Flash는 284B total / 13B active, 두 모델 모두 1M 컨텍스트를 지원하고 Blackwell·vLLM·SGLang·NIM 위 즉시 배포 경로가 열렸다.

  • 오늘 발표들의 공통 메시지는 분명하다.
    앞으로 강한 AI 제품은 더 좋은 모델 한 개만으로 나오지 않는다. 장기 실행형 agent runtime, 메모리, 보안 게이트웨이, 최적화된 추론 스택, CPU/GPU 조합 전략, 오픈 배포 경로를 함께 가진 팀이 이긴다.

왜 오늘 뉴스를 함께 읽어야 하나

오늘 발표들을 한 개씩 보면 각각 “서비스 출시”, “플랫폼 기능 추가”, “파트너십”, “인프라 튜닝”, “새 모델”처럼 보입니다. 하지만 사실은 모두 같은 방향으로 움직입니다. 적어도 여섯 가지 큰 변화가 동시에 일어나고 있습니다.

1. 에이전트의 경쟁 단위가 ‘대화’에서 ‘업무 완주’로 이동한다

AWS가 frontier agents를 설명하는 방식은 중요합니다. 이들은 단순히 질문에 답하는 도우미가 아니라, 목표를 받고 며칠 동안 돌아가며 결과를 내는 시스템으로 정의됩니다. Google Agent Platform도 multi-day workflow, persistent memory, observability, identity를 전면에 둡니다. 즉 업계 전체가 에이전트를 이제 채팅 UX가 아니라 업무 런타임으로 보고 있습니다.

2. 모델 성능 다음 병목은 추론 구성이 된다

좋은 모델을 고른 뒤에도 실제 배포에는 수많은 선택지가 남습니다.

  • 어느 GPU 인스턴스를 쓸 것인가
  • 어느 서빙 컨테이너를 쓸 것인가
  • speculative decoding을 켤 것인가
  • tensor parallelism을 어느 정도로 잡을 것인가
  • throughput과 latency 중 무엇을 우선할 것인가
  • 컨텍스트가 길어질 때 KV cache 비용을 어떻게 감당할 것인가

SageMaker와 NVIDIA의 오늘 발표는 이 병목을 정면으로 다룹니다. 즉 이제 AI 운영의 실전 승부는 모델 선정 이후에 시작됩니다.

3. 거버넌스는 더 이상 옵션이 아니다

Google이 Agent Identity, Registry, Gateway, Threat Detection을 묶어 낸 것은 매우 상징적입니다. 이유는 분명합니다. 에이전트 수가 늘어날수록 조직은 다음 질문에 즉시 답해야 하기 때문입니다.

  • 이 에이전트는 누구인가
  • 무엇에 접근하는가
  • 어떤 정책 아래 동작하는가
  • 어떤 이상행동을 보였는가
  • 어떤 로그가 남는가
  • 누가 승인했는가

이 질문에 답하지 못하면 에이전트는 제품이 아니라 리스크가 됩니다.

4. agentic AI 인프라는 GPU만의 문제가 아니다

Meta의 발표는 오늘 뉴스에서 특히 중요합니다. 많은 사람이 agentic AI 인프라를 GPU 숫자 경쟁으로만 이해하지만, 실제 운영에서는 CPU가 담당하는 일이 많습니다.

  • 스케줄링
  • 데이터 전처리
  • 도구 호출 조정
  • 검색/인덱싱 보조
  • 시스템 서비스
  • 오케스트레이션 상태 관리
  • 추론 주변 처리

Meta가 AWS Graviton 코어를 수천만 개 단위로 가져가는 이유는, AI 시대의 인프라가 GPU 하나로 끝나지 않기 때문입니다. agentic AI는 CPU 집약적 조정 계층을 크게 키웁니다.

5. 장기 컨텍스트는 모델 기능이 아니라 시스템 설계 문제다

DeepSeek-V4와 NVIDIA의 설명을 같이 보면 아주 중요한 사실이 드러납니다. 1M 토큰 컨텍스트는 “모델이 된다”는 문장만으로는 아무 의미가 없습니다. 진짜 질문은 다음입니다.

  • KV cache를 얼마나 줄였는가
  • per-token FLOPs를 얼마나 낮췄는가
  • prefill/decode 분리를 어떻게 하는가
  • 어떤 하드웨어에서 어느 수준 tokens/sec가 나오는가
  • 어떤 serving recipe가 있는가
  • tool calling과 reasoning이 실제로 유지되는가

즉 장기 컨텍스트 경쟁은 이제 PR 숫자가 아니라 배포 가능한 구조의 경쟁입니다.

6. 플랫폼 회사들은 모두 ‘에이전트 운영체제’를 노리고 있다

AWS는 frontier agents와 SageMaker로, Google은 Agent Platform으로, NVIDIA는 endpoints·NIM·recipe 생태계로, Meta는 컴퓨트 포트폴리오로 각자의 방식으로 같은 자리를 노립니다. 그 자리는 단순 모델 판매가 아니라 에이전트 운영체제의 기반층입니다.

1) AWS Frontier Agents GA: 에이전트가 보안팀과 SRE팀의 실전 동료가 되기 시작했다

오늘 AWS 발표에서 가장 직접적이고 강한 메시지는 AWS Security Agent와 AWS DevOps Agent의 일반 출시입니다. 이 발표는 “에이전트가 어떤 일을 할 수 있는가”보다 “어떤 조직 기능을 실제로 대체·보강할 수 있는가”를 보여 줍니다.

무엇이 발표됐나

AWS 공식 발표 기준 핵심은 다음과 같습니다.

  • AWS Security Agent의 on-demand penetration testing이 GA에 들어갔다.
  • AWS DevOps Agent도 GA에 들어갔다.
  • AWS는 이 둘을 re:Invent에서 공개한 frontier agents의 첫 실전 사례로 설명한다.
  • frontier agents의 정의는 세 가지다: 독립적으로 목표를 수행하고, 대량 동시 작업을 처리하며, 몇 시간에서 며칠 동안 지속적으로 실행된다는 점이다.
  • Security Agent는 소스코드, 아키텍처 다이어그램, 문서를 읽고 취약점을 찾고 exploit chain을 시도하며 실제 리스크를 검증한다고 설명한다.
  • AWS는 고객 사례에서 침투 테스트 시간이 weeks to hours, HENNGE는 90% 이상 시간 단축, Bamboo Health는 기존 도구가 못 찾던 findings를 발견했다고 밝혔다.
  • DevOps Agent는 AWS·Azure·온프레 환경을 포함해 telemetry, code, deployment data를 상호 연관해 root cause를 찾는다고 설명한다.
  • preview 고객은 up to 75% lower MTTR, 80% faster investigations, 94% root cause accuracy, 3~5x faster incident resolution을 보고했다고 한다.
  • WGU는 특정 장애 분석에서 예상 2시간이 걸릴 작업을 28분에 끝냈다고 밝혔다.

왜 중요한가

첫째, 에이전트가 드디어 ‘설명’이 아니라 ‘완료’ 중심으로 팔리기 시작했다

그동안 많은 AI 제품은 결국 이렇게 귀결됐습니다.

  • 잘 설명해 준다
  • 초안을 잘 써 준다
  • 후보를 잘 제안해 준다

물론 이것도 가치가 있습니다. 하지만 오늘 AWS는 한 단계 더 나아갑니다. Security Agent와 DevOps Agent는 각각 침투 테스트 완료, 장애 원인 분석과 복구 지원 완료라는 운영 결과를 판다. 이건 아주 큰 변화입니다.

이제 AI의 판매 단위가 점점 “좋은 답변”에서 “실제 업무 결과”로 바뀌고 있다는 뜻이기 때문입니다.

둘째, frontier agent의 핵심은 자율성이 아니라 지속성이다

AWS 설명에서 정말 중요한 단어는 autonomy보다 persistent입니다. 에이전트가 진짜 가치가 있으려면 단순히 스스로 생각하는 것이 아니라, 중간에 멈추지 않고 긴 워크플로를 이어가야 합니다.

보안 테스트와 SRE 운영은 원래도 이런 특성을 가집니다.

  • 조사할 표면이 넓다
  • 가설을 세우고 검증해야 한다
  • 도구를 여러 번 바꿔 써야 한다
  • 중간 결과를 다시 해석해야 한다
  • 최종적으로 증거를 남겨야 한다

즉 이 영역은 원래부터 에이전트 친화적이었습니다. AWS는 그 점을 가장 먼저 상품화했습니다.

셋째, 보안과 운영이 에이전트 도입의 첫 실전 무대가 되는 이유가 분명해졌다

보안과 운영은 AI에게 어려운 영역이지만 동시에 빨리 가치가 나는 영역이기도 합니다.

  • 데이터가 비교적 구조화되어 있다
  • 절차가 명확하다
  • 성공 조건이 비교적 측정 가능하다
  • 도구와 로그가 풍부하다
  • 실패 비용이 크기 때문에 자동화 가치가 크다

이런 특성 때문에 보안과 운영은 앞으로도 에이전트 도입의 최전선이 될 가능성이 큽니다.

넷째, 사람을 대체하기보다 사람의 대기행렬을 줄이는 방향이 현실적이다

오늘 발표를 과장해서 읽으면 “보안 엔지니어와 SRE가 필요 없어지는가?” 같은 결론으로 흘러갈 수 있습니다. 하지만 더 현실적인 해석은 다릅니다.

  • 사람이 하기엔 너무 오래 걸리던 조사를 빠르게 해 준다
  • 사람이 놓치기 쉬운 연결고리를 먼저 좁혀 준다
  • 대응 우선순위를 더 빨리 정할 수 있게 해 준다
  • 사람의 병목을 줄인다

즉 frontier agent의 진짜 가치는 완전 대체보다 고급 인력의 대기열 압축에 있습니다.

개발자와 운영팀에게 의미

1. 앞으로 중요한 것은 프롬프트보다 실행 경계 설계다

보안 에이전트와 운영 에이전트는 자유롭게 아무 행동이나 해서는 안 됩니다. 그래서 핵심 설계 질문은 다음과 같습니다.

  • 어떤 툴을 호출할 수 있는가
  • 어느 단계까지 자동 실행 가능한가
  • 어떤 증거가 있어야 다음 단계로 넘어가는가
  • 사람이 개입해야 하는 문턱은 무엇인가
  • 실패하면 어떻게 중단하고 보고하는가

즉 에이전트 설계는 점점 prompt craft보다 권한·정책·증거 흐름 설계가 중요해집니다.

2. 장기 실행형 agent UX가 표준이 된다

사용자 인터페이스도 달라집니다. 단순 채팅창으로는 부족합니다.

  • 현재 조사 단계
  • 읽은 데이터
  • 시도한 액션
  • 성공/실패한 검증
  • 사람 승인 대기
  • 최종 보고서

이런 요소가 보여야 진짜 실무 도구가 됩니다.

운영 포인트

  • 보안/운영 agent는 read-only와 write-action 권한을 엄격히 분리해야 한다.
  • root cause 제안뿐 아니라 근거 로그를 함께 남겨야 한다.
  • false positive/false confidence 관리 기준을 먼저 세워야 한다.
  • agent 결과를 사람이 검토하고 재학습하는 루프가 필요하다.
  • “얼마나 빨라졌는가”보다 “얼마나 더 많은 사건을 처리하게 됐는가”를 KPI로 봐야 한다.

한 줄 평

오늘 AWS 발표는 에이전트가 드디어 생산성 보조를 넘어 보안과 운영의 실제 완료형 업무로 진입하고 있음을 보여 준다.

2) SageMaker AI inference recommendations: 이제 추론 최적화는 사람이 아니라 플랫폼이 대신해야 한다

오늘 발표 중 실무적으로 가장 큰 의미를 가질 수 있는 것은 사실 SageMaker의 inference recommendations일 수 있습니다. 화려한 모델 출시만큼 주목받진 않지만, 실제 비용과 속도는 여기서 갈리기 때문입니다.

무엇이 발표됐나

AWS 공식 설명의 핵심은 다음과 같습니다.

  • 사용자는 자신의 generative AI 모델을 가져온다.
  • 성능 목표를 하나 선택한다: cost 최적화, latency 최소화, throughput 최대화.
  • SageMaker는 모델 아키텍처, 크기, 메모리 요구를 분석해 실험할 후보 구성을 줄인다.
  • 최대 세 개의 인스턴스 타입을 비교할 수 있다.
  • 시스템은 목표에 맞춰 speculative decoding, kernel tuning, tensor parallelism 같은 기법을 자동 적용한다.
  • 벤치마크는 NVIDIA AIPerf로 실 GPU 위에서 수행된다.
  • 결과로 TTFT, inter-token latency, P50/P90/P99 latency, throughput, cost projection이 포함된 ranked recommendation을 반환한다.
  • AWS는 이 과정이 기존의 2~3주 수작업을 수시간 단위로 줄인다고 설명한다.
  • 실제 예시로 GPT-OSS-20B에서 EAGLE 3.0 speculative decoding 적용 후 같은 latency에서 2배 tokens/s를 보여 줬다.
  • benchmarking rigor를 위해 AWS는 AIPerf에 multi-run confidence reporting, adaptive convergence, early stopping 기여를 했다고 밝혔다.

왜 중요한가

첫째, 추론은 이제 모델 선택보다 더 복잡한 의사결정 공간이 됐다

AI 팀이 실제로 시간을 태우는 곳은 종종 모델 선정이 아닙니다. 오히려 그 다음입니다.

  • 어떤 인스턴스를 쓸까
  • 같은 모델인데도 어떤 container 조합이 더 나을까
  • 긴 컨텍스트에선 메모리 병목이 어디서 터질까
  • tail latency를 잡으려면 어느 정도 여유 자원이 필요할까
  • throughput 목표를 세우면 품질이나 안정성은 얼마나 희생될까

이 문제는 사람이 경험으로만 풀기엔 너무 커졌습니다. SageMaker의 메시지는 명확합니다.

이제 추론 최적화는 수작업 장인 기술이 아니라 자동화된 검색 문제여야 한다.

둘째, cost/latency/throughput은 동시에 최고가 될 수 없다는 현실을 플랫폼이 전면에 올렸다

이 발표에서 가장 좋은 부분은 사용자가 하나의 목표를 선택하게 한다는 점입니다. 실무적으로 매우 정직한 설계입니다.

  • latency를 줄이면 비용이 늘 수 있다
  • throughput을 극대화하면 tail latency가 악화될 수 있다
  • cost를 낮추면 순간 부하 대응력이 떨어질 수 있다

즉 추론 운영은 언제나 trade-off 설계입니다. 많은 팀이 아직도 이 세 가지를 다 얻을 수 있다고 기대하는데, 현실은 그렇지 않습니다. SageMaker는 이 사실을 제품 인터페이스에 반영했습니다.

셋째, benchmark의 품질이 제품 경쟁력이 되는 시대다

AWS가 AIPerf 개선까지 강조한 것은 중요한 신호입니다. 이제 AI 시장은 “가장 빠른 숫자 하나”를 내세우는 단계에서 벗어나고 있습니다. 실제 조직은 다음을 원합니다.

  • 결과가 반복 측정에도 비슷한가
  • 분산이 얼마나 되는가
  • 언제 benchmark를 멈춰도 되는가
  • 특정 workload에서만 잘 나오는 착시는 아닌가

즉 추론 엔지니어링에서 측정의 신뢰성이 차별화 포인트가 됩니다.

넷째, AI 제품의 이익률은 모델이 아니라 서빙 구성에서 결정될 가능성이 커졌다

같은 모델이라도 서빙 구성이 다르면 비용과 성능이 크게 달라집니다. 특히 아래 제품은 더 그렇습니다.

  • 코딩 에이전트
  • 장기 리서치 에이전트
  • 문서 분석 자동화
  • 대화형 고객지원
  • 실시간 멀티모달 인터랙션

이런 워크로드는 모두 응답 속도와 단가가 바로 UX와 매출에 연결됩니다. 그래서 추론 최적화는 이제 인프라의 뒷단 작업이 아니라 제품 전략 그 자체입니다.

플랫폼팀에게 의미

1. representative workload가 없으면 최적화도 없다

SageMaker가 input/output token distribution과 concurrency를 강조하는 이유는 분명합니다. 실제 사용 패턴이 없는 benchmark는 아무 의미가 없기 때문입니다.

2. 추론 엔지니어링은 기능 출시 이후가 아니라 출시 전 기본 설계가 된다

그동안 많은 팀은 먼저 내고 나중에 튜닝했습니다. 앞으로는 반대가 될 가능성이 큽니다. AI 기능은 출시 전에 최소한 다음을 알아야 합니다.

  • 어느 성능 목표가 우선인가
  • 현재 구성이 어느 정도 비용을 먹는가
  • 컨텍스트가 길어질 때 병목은 어디인가
  • fallback configuration은 무엇인가

운영 포인트

  • cost/latency/throughput 중 우선순위를 먼저 문서화하라.
  • 단일 benchmark 수치보다 분산과 재현성을 보라.
  • 추론 비용은 token 단가보다 successful task당 비용으로 계산하라.
  • 장기 컨텍스트 워크로드는 KV cache와 tail latency를 별도 추적하라.
  • benchmark 결과와 실제 배포 구성을 최대한 가깝게 붙여라.

한 줄 평

오늘 SageMaker 발표는 AI 운영의 진짜 본체가 모델이 아니라 추론 경제성 최적화라는 사실을 다시 확인시켜 준다.

3) Google Gemini Enterprise Agent Platform: 에이전트 시대의 진짜 제품은 거버넌스가 붙은 런타임이다

Google의 Gemini Enterprise Agent Platform 발표는 오늘 뉴스의 중심축 중 하나입니다. 이 발표는 엔터프라이즈 AI가 왜 단순 모델 API 묶음이 될 수 없는지 아주 잘 보여 줍니다.

무엇이 발표됐나

Google Cloud 공식 발표에서 눈에 띄는 포인트는 다음과 같습니다.

  • Gemini Enterprise Agent Platform은 Vertex AI의 진화형으로 소개됐다.
  • 목표는 agents를 build, scale, govern, optimize 하는 단일 플랫폼이다.
  • Agent Studio와 업그레이드된 ADK를 통해 low-code와 code-first 경로를 모두 제공한다.
  • ADK는 매월 Gemini 모델에서 6조 토큰 이상이 처리된다고 밝혔다.
  • Agent Runtime은 sub-second cold starts, seconds 단위 provisioning, multi-day workflows를 지원한다.
  • Memory Bank와 Memory Profiles로 장기 메모리를 유지한다.
  • Agent Sessions와 custom session IDs로 내부 시스템 기록과 세션을 연결한다.
  • WebSocket 기반 bidirectional streaming으로 오디오/비디오까지 실시간 처리한다.
  • Agent Identity는 각 agent에 고유 암호학적 ID를 부여한다.
  • Agent Registry는 승인된 agent/tool/skill의 중앙 카탈로그 역할을 한다.
  • Agent Gateway는 보안 정책과 Model Armor를 적용하는 중앙 연결 지점이다.
  • Agent Anomaly Detection, Threat Detection, Security Command Center 기반 Agent Security 대시보드가 제공된다.
  • Agent Simulation, Evaluation, Observability, Optimizer까지 포함해 테스트·관측·개선 루프를 제공한다.
  • PayPal, L’Oréal, Comcast, Color Health, Gurunavi 등 실사용 사례를 함께 제시했다.

왜 중요한가

첫째, 이제 에이전트 플랫폼의 핵심은 모델이 아니라 ‘운영면’이다

Google 발표를 보면 모델 얘기도 당연히 나오지만, 진짜 긴 설명은 다른 곳에 있습니다.

  • runtime
  • memory
  • identity
  • gateway
  • registry
  • threat detection
  • observability
  • optimization

이게 중요합니다. 조직이 실제로 필요로 하는 것은 모델에 붙는 API key가 아니라, 대규모 agent fleet를 통제할 수 있는 운영면이기 때문입니다.

둘째, 에이전트는 이제 세션이 아니라 장기 지속 객체가 된다

Memory Bank, multi-day workflow, custom session ID, persistent session mapping은 같은 메시지를 던집니다.

에이전트는 더 이상 “질문 하나 처리하고 사라지는 응답기”가 아닙니다. 이제는 다음과 같은 장기 객체가 됩니다.

  • 고객 기록을 기억하는 고객지원 agent
  • 거래 패턴을 기억하는 재무 agent
  • 승인 이력을 기억하는 운영 agent
  • 업무 히스토리를 기억하는 사내 assistant

이 변화는 매우 큽니다. 시스템 설계 전체를 바꾸기 때문입니다.

셋째, agent identity가 독립 개념으로 등장한 것은 매우 중요하다

Agent Identity에 고유 cryptographic ID를 부여한다는 설명은 상징성이 큽니다. 이건 사실상 “에이전트도 이제 조직 안에서 계정과 책임의 주체가 된다”는 뜻입니다.

인간 직원은 계정이 있고, 역할이 있고, 권한이 있고, 로그가 남습니다. 에이전트도 비슷한 방향으로 가기 시작했습니다. 앞으로는 다음이 더 흔해질 수 있습니다.

  • agent별 역할 기반 정책
  • agent별 접근권한
  • agent별 audit trail
  • agent별 anomaly detection
  • agent별 owner와 lifecycle 관리

즉 agent는 코드 조각이 아니라 관리 대상 identity가 됩니다.

넷째, “관측 가능성”이 에이전트 제품의 1급 기능이 된다

Google이 Agent Observability와 trace visualizations를 강하게 밀고 있는 것은 정확합니다. 에이전트가 실전에 들어가면 결국 묻게 되는 질문은 항상 같습니다.

  • 왜 이런 결론이 나왔나
  • 어느 단계에서 실패했나
  • 어떤 툴 호출이 문제였나
  • 어느 prompt/state가 잘못됐나
  • 어떤 agent가 이상 행동을 했나

즉 observability는 디버깅 도구가 아니라 신뢰의 전제입니다.

다섯째, 엔터프라이즈 AI는 결국 agent sprawl과의 싸움이다

Agent Registry와 Gateway가 중요한 이유는 조직 안에 agent가 늘어날수록 무질서가 빨리 오기 때문입니다.

  • 누가 만든 agent인지 모른다
  • 어떤 툴을 쓰는지 모른다
  • 비슷한 agent가 중복된다
  • 정책이 다 다르다
  • 누가 승인했는지 모른다
  • 장애가 나도 owner를 찾기 어렵다

Google은 이 문제를 미리 플랫폼 레이어로 해결하려 합니다.

개발자와 엔터프라이즈 아키텍트에게 의미

1. agent 개발은 이제 application development + IAM + observability + security engineering의 결합이다

프롬프트만 잘 쓴다고 끝나지 않습니다. 실제 agent platform 시대의 개발자는 다음을 다뤄야 합니다.

  • state design
  • identity design
  • policy enforcement
  • event streaming
  • memory lifecycle
  • evaluation automation
  • risk telemetry

2. 장기 메모리는 기능이자 리스크다

Memory Bank는 굉장히 강력하지만 동시에 위험합니다. 기억이 길어질수록 personalization은 좋아지지만, 다음도 커집니다.

  • 잘못된 기억 누적
  • 개인정보 리스크
  • 편향된 행동 고착
  • 예전 컨텍스트가 현재 판단을 오염시키는 문제

즉 memory는 그냥 넣으면 좋은 게 아니라, 수명과 검증 정책이 필요합니다.

운영 포인트

  • agent별 owner, identity, permission, audit scope를 처음부터 정의하라.
  • observability 없는 agent는 production에 올리지 마라.
  • memory는 저장만이 아니라 만료·수정·정정 정책이 필요하다.
  • registry 없는 agent ecosystem은 빠르게 혼란에 빠진다.
  • evaluation은 출시 전 한 번이 아니라 실시간 운영 루프로 돌려야 한다.

한 줄 평

Google의 오늘 발표는 에이전트 플랫폼의 핵심이 모델 호출이 아니라 ‘운영 가능한 주체’를 만드는 시스템이라는 점을 가장 명확하게 보여 준다.

4) Meta + AWS Graviton: agentic AI 시대의 CPU는 다시 전략 자산이 된다

오늘 Meta의 발표는 겉으로 보면 파트너십 뉴스지만, 실제로는 AI 인프라 철학에 관한 아주 중요한 힌트를 줍니다.

무엇이 발표됐나

Meta 공식 발표 기준 핵심은 다음과 같습니다.

  • Meta는 AWS와의 계약을 통해 수천만 개의 AWS Graviton 코어를 도입한다.
  • Meta는 세계 최대 수준의 Graviton 고객 중 하나가 된다고 밝혔다.
  • 첫 배치는 tens of millions of cores 규모이며, 이후 확장 여지도 열어 둔다.
  • 목적은 agentic AI workload를 뒷받침할 compute diversification이다.
  • Meta는 agentic AI를 “reason, plan, execute complex tasks” 하는 시스템으로 설명한다.
  • AWS 측 발언에서는 Graviton5가 높은 data processing과 bandwidth를 통해 다음 세대 agentic AI에 필요한 기반을 제공한다고 밝혔다.
  • Meta는 자체 데이터센터와 커스텀 하드웨어, 외부 클라우드 파트너를 함께 쓰는 portfolio approach를 인프라 원칙으로 제시했다.

왜 중요한가

첫째, AI 인프라의 숨은 병목이 CPU라는 사실을 대형 플레이어가 공개적으로 인정했다

GPU가 중요하다는 건 누구나 압니다. 하지만 agentic AI는 GPU 외 영역을 크게 키웁니다.

  • task orchestration
  • queue handling
  • tool invocation
  • networking
  • memory services
  • data processing
  • retrieval and ranking side work
  • session and workflow state

Meta의 오늘 발표는 이 영역이 충분히 중요해서 수천만 개의 CPU 코어 수준으로 전략을 다시 짜야 한다는 점을 보여 줍니다.

둘째, agentic AI는 ‘추론 칩 수’보다 ‘전체 시스템 균형’이 중요하다

Meta가 말한 portfolio approach는 상당히 현실적입니다.

  • 일부 workload는 자체 커스텀 실리콘이 더 맞을 수 있다
  • 일부는 클라우드 CPU가 더 효율적일 수 있다
  • 일부는 GPU 중심이 맞고
  • 일부는 데이터 이동 비용과 네트워크 토폴로지가 더 중요할 수 있다

즉 AI 인프라는 더 이상 “GPU 많이 사면 끝”이 아닙니다. agentic AI는 시스템 전체 밸런스를 요구합니다.

셋째, 대규모 에이전트 실행은 결국 CPU-intensive control plane을 필요로 한다

이건 실무적으로 매우 중요합니다. 에이전트가 많아질수록 GPU 추론 자체보다 주변 컨트롤 플레인이 커집니다.

  • 각 에이전트의 상태를 추적해야 한다
  • 도구 연결을 관리해야 한다
  • 이벤트를 라우팅해야 한다
  • 승인 흐름을 기다리고 재개해야 한다
  • 로그를 적재하고 검색해야 한다
  • 사용자별 정책을 적용해야 한다

이 레이어는 CPU와 메모리 대역폭, 네트워크 효율에 민감합니다. Meta는 오늘 사실상 이 레이어를 공개적으로 강조했습니다.

넷째, 클라우드-자체 인프라 혼합 전략이 더 보편화될 가능성이 커졌다

Meta 정도 규모의 회사가조차 “우리는 전부 직접 하지 않는다”고 말합니다. 이는 시장 전체에 시사점을 줍니다.

앞으로 더 많은 조직이 다음 구조를 취할 수 있습니다.

  • 핵심 워크로드는 자체 인프라
  • burst나 특정 CPU-heavy 작업은 클라우드
  • 특정 서빙이나 실험은 관리형 서비스
  • 장기적으로는 포트폴리오 기반 최적화

즉 단일 인프라 신앙은 점점 덜 현실적이 됩니다.

플랫폼 리더에게 의미

1. AI capacity planning에 CPU 계층을 다시 넣어야 한다

많은 조직이 GPU 수요 예측은 하지만, CPU 계층을 대충 보는 경우가 많습니다. 앞으로는 에이전트 런타임 때문에 CPU 쪽 계산이 더 중요해질 수 있습니다.

2. 오케스트레이션 비용을 과소평가하면 안 된다

장기 실행형 agent는 inference call 몇 번으로 끝나지 않습니다. orchestration 자체가 꽤 비싼 시스템 활동이 됩니다.

운영 포인트

  • AI 인프라 계획에서 GPU 외 CPU·메모리·네트워크를 따로 추적하라.
  • agent runtime 비용과 model inference 비용을 분리해 측정하라.
  • workload별로 자체 인프라와 클라우드의 역할을 나눠 보라.
  • control plane 과부하가 사용자 체감 성능을 무너뜨릴 수 있음을 전제로 설계하라.
  • 대규모 agent 운영에선 “추론 비용”보다 “조정 비용”이 빨리 커질 수 있다.

한 줄 평

Meta의 오늘 발표는 agentic AI 시대의 인프라 경쟁이 GPU 대수 경쟁을 넘어 CPU·대역폭·포트폴리오 설계 경쟁으로 이동하고 있음을 보여 준다.

5) NVIDIA + DeepSeek V4: 1M 컨텍스트 시대의 승부는 ‘길게 읽는다’가 아니라 ‘길게 돌린다’에 있다

오늘 가장 기술적으로 흥미로운 축은 NVIDIA가 공개한 DeepSeek-V4 배포 흐름입니다. 이 발표는 긴 컨텍스트 모델 경쟁이 이제 숫자 자랑이 아니라 실제 서빙 구조 싸움이라는 사실을 명확히 보여 줍니다.

무엇이 발표됐나

NVIDIA 공식 기술 블로그와 DeepSeek 공식 사이트를 종합하면 다음이 핵심입니다.

  • DeepSeek는 DeepSeek-V4-Pro와 DeepSeek-V4-Flash를 공개했다.
  • Pro는 1.6T total parameters / 49B active parameters, Flash는 284B total / 13B active다.
  • 두 모델 모두 1M token context window를 지원한다.
  • NVIDIA는 최대 384K output length까지 DeepSeek API 문서를 통해 가능하다고 설명했다.
  • DeepSeek-V4는 V3.2 대비 per-token inference FLOPs 73% 감소, KV cache memory burden 90% 감소를 주장한다.
  • 핵심 구조는 CSA, DSA, HCA를 결합한 hybrid attention이다.
  • NVIDIA는 DeepSeek-V4-Pro를 GB200 NVL72에서 150 tokens/sec/user 이상의 out-of-the-box 테스트를 제시했다.
  • Blackwell B300용 vLLM recipe, SGLang recipe, multinode prefill/decode disaggregation, speculative decoding, tool calling, reasoning 지원 경로가 공개됐다.
  • DeepSeek는 공식 사이트에서 “V4 preview version released”, “world-class reasoning performance”, “agent capability significantly improved”, “web/app/API上线”를 내세웠다.
  • NVIDIA는 이를 build.nvidia.com hosted endpoint와 NIM day-0 다운로드 경로로 바로 사용할 수 있게 연결했다.

왜 중요한가

첫째, 장기 컨텍스트 경쟁의 본질은 메모리와 주의(attention) 경제성이다

1M 토큰이 왜 어려운지는 간단합니다. 문맥이 길어질수록 비용이 폭발하기 때문입니다. 그래서 DeepSeek-V4가 강조하는 포인트는 모델 IQ보다도 다음입니다.

  • FLOPs reduction
  • KV cache reduction
  • hybrid attention design
  • serving recipes
  • disaggregated inference path

즉 긴 컨텍스트 모델은 이제 “길게 읽을 수 있다”보다 길게 읽으면서도 돌아간다가 더 중요합니다.

둘째, long-context agent는 단순 챗봇과 완전히 다른 시스템 요구를 만든다

NVIDIA가 왜 DeepSeek-V4를 agentic workflows와 함께 설명하는지 눈여겨봐야 합니다. 에이전트는 보통 다음을 한꺼번에 쌓습니다.

  • system instruction
  • retrieved docs
  • tool outputs
  • code and logs
  • intermediate reasoning traces
  • long-term memory summaries

즉 장기 컨텍스트는 agent의 선택 기능이 아니라 거의 필수 기능이 되어 가고 있습니다. 그래서 long-context 모델 경쟁은 agent 플랫폼 경쟁과 직접 연결됩니다.

셋째, 모델 공개만으로는 의미가 없고 day-0 serving path가 중요해졌다

이번 발표가 진짜 중요한 이유는 DeepSeek-V4가 단순히 공개됐다는 사실이 아닙니다. NVIDIA는 곧바로 다음을 연결했습니다.

  • hosted endpoints
  • NIM download path
  • vLLM recipes
  • SGLang recipes
  • multinode serving
  • Blackwell/Hopper tuning paths

즉 이제 오픈 모델 생태계도 “weights를 공개했다”에서 끝나지 않습니다. 진짜 경쟁은 얼마나 빨리 usable serving stack이 붙느냐입니다.

넷째, active parameters 중심의 효율 경쟁이 더 중요해진다

DeepSeek-V4-Pro는 total parameters가 어마어마하지만 active parameters는 49B입니다. Flash는 13B active입니다. 이건 단순 숫자 장난이 아닙니다. agentic inference 경제성에서 중요한 것은 총 파라미터보다 실제 추론 경로에 참여하는 비용 구조이기 때문입니다.

앞으로 오픈 계열 모델 경쟁은 더 자주 이런 식으로 읽어야 합니다.

  • total vs active parameters
  • context window
  • KV cache burden
  • tokens/sec at target latency
  • real serving recipe availability

다섯째, open model 생태계는 다시 강한 선택지가 되고 있다

NVIDIA가 DeepSeek-V4를 OpenClaw/NemoClaw, AI-Q Blueprint, Data Explorer Agent 같은 오픈/준오픈 harness와 연결한 점도 중요합니다. 이건 곧 다음을 뜻합니다.

  • 오픈 모델이 장기 컨텍스트 agent의 핵심 옵션이 된다
  • 기업은 proprietary frontier model만 보지 않아도 된다
  • 인프라와 서빙을 잘 다루는 팀에게 선택지가 늘어난다
  • 모델 경쟁의 무게중심이 일부 다시 오픈 생태계로 이동할 수 있다

개발자에게 의미

1. 1M 컨텍스트를 쓰기 전에 먼저 구조를 바꿔야 한다

긴 컨텍스트 모델이 있다고 해서 무작정 모든 걸 한 프롬프트에 넣는 것은 좋은 설계가 아닙니다. 오히려 더 중요해지는 것은 다음입니다.

  • 어떤 정보를 계속 들고 갈 것인가
  • 어떤 정보는 요약해서 memory로 보낼 것인가
  • 어떤 정보는 retrieval로 늦게 가져올 것인가
  • prefill/decode 병목을 어떻게 줄일 것인가

2. long-context agent는 infra-aware application design을 요구한다

모델이 길게 읽을수록 애플리케이션도 바뀌어야 합니다.

  • 세션 구조
  • 로그 축약 전략
  • memory summarization
  • 툴 결과 저장 포맷
  • 대화 중 불필요한 반복 제거

운영 포인트

  • 긴 컨텍스트는 기능이 아니라 비용 구조임을 전제로 설계하라.
  • total parameter보다 active parameter와 serving recipe를 보라.
  • long-context agent는 retrieval·summary·cache 전략 없이 제품화하지 마라.
  • KV cache 비용과 tail latency를 함께 측정하라.
  • 오픈 모델을 볼 때는 모델 카드보다 deployment path가 더 중요하다.

한 줄 평

NVIDIA와 DeepSeek의 오늘 흐름은 1M 컨텍스트 시대의 승부가 모델 숫자보다 장기 추론을 실제로 굴리는 시스템 설계에서 난다는 점을 명확히 보여 준다.

6) 오늘 뉴스의 공통 구조: 모델 전쟁 다음은 ‘에이전트 운영 전쟁’이다

이제 오늘 발표들을 한 번 더 묶어 보면 적어도 일곱 가지 변화가 동시에 보입니다.

변화 1. 에이전트는 부가기능이 아니라 독립 제품이 된다

AWS Security Agent, DevOps Agent는 이 흐름의 시작입니다. 에이전트는 이제 모델을 감싼 기능이 아니라 직접적으로 팔리는 운영 주체가 됩니다.

변화 2. 추론 튜닝은 플랫폼 기본 기능이 된다

SageMaker 발표는 추론 최적화가 더 이상 SRE 몇 명의 장인기술로 남아 있을 수 없음을 보여 줍니다. 앞으로는 AI 플랫폼이 이 문제를 대신 풀어야 합니다.

변화 3. 에이전트의 핵심은 메모리와 런타임이다

Google Agent Platform은 장기 메모리, multi-day runtime, session mapping을 핵심으로 둡니다. agent는 stateless request-response 위에 얹는 장난감이 아닙니다.

변화 4. 거버넌스는 agent identity 문제로 발전한다

Identity, Registry, Gateway, Threat Detection이 등장한 순간부터 agent는 단순 코드가 아니라 정책 대상 객체가 됩니다.

변화 5. AI 인프라는 CPU/GPU/네트워크/메모리의 포트폴리오 설계가 된다

Meta의 Graviton 도입은 AI 인프라의 control plane이 다시 중요해졌음을 보여 줍니다.

변화 6. 장기 컨텍스트는 새로운 경제성 전쟁을 만든다

DeepSeek-V4는 길게 읽는 모델이 아니라, 길게 읽으면서도 FLOPs와 KV cache를 줄이는 모델로 자신을 포지셔닝합니다. 이것이 앞으로 long-context 경쟁의 본체가 됩니다.

변화 7. 오픈 모델 경쟁은 다시 살아난다

NVIDIA가 day-0 endpoints, NIM, vLLM, SGLang 경로를 붙이면서 오픈 모델도 즉시 실전 후보가 됩니다. 이는 폐쇄형 frontier model만이 답이 아니라는 뜻입니다.

7) 개발자에게 오늘 뉴스가 의미하는 것

오늘 발표들은 개발자에게 꽤 직접적인 숙제를 줍니다. 제 판단으로는 아래 열두 가지가 특히 중요합니다.

1. 이제 프롬프트보다 런타임 설계가 중요하다

좋은 agent를 만들려면 문장 몇 줄보다 다음이 더 중요합니다.

  • 상태를 어디에 둘 것인가
  • 툴 호출을 어떻게 제한할 것인가
  • 승인 지점을 어디에 둘 것인가
  • 실패를 어떻게 재개할 것인가

2. long-running workflow를 기본 전제로 해야 한다

AI는 더 이상 한 번 답하고 끝나는 기능이 아닙니다. 하루 이상 이어지는 작업을 가정해야 합니다.

3. observability가 없으면 agent는 디버깅할 수 없다

에이전트는 내부적으로 복잡한 결정을 내립니다. trace, event, tool log, policy decision이 없으면 운영이 불가능합니다.

4. inference budget을 미리 계산해야 한다

요즘 AI 기능은 출시 후 비용을 보면 늦습니다. 모델 선택, context length, latency target, concurrency target을 초기에 잡아야 합니다.

5. CPU 비용도 함께 봐야 한다

agent runtime은 GPU 추론만 먹는 게 아닙니다. orchestration layer가 크게 커집니다.

6. identity와 permission은 기능이 아니라 설계의 일부다

에이전트가 무엇을 볼 수 있고 무엇을 할 수 있는지는 product requirement 문서에 처음부터 들어가야 합니다.

7. memory는 저장이 아니라 lifecycle 문제다

무엇을 기억하고 언제 잊을지, 잘못 기억했을 때 어떻게 수정할지 설계해야 합니다.

8. benchmark literacy가 더 중요해진다

지금부터는 벤치마크를 볼 때 다음을 함께 읽어야 합니다.

  • active parameters
  • TTFT
  • tokens/sec
  • P99 latency
  • context scaling cost
  • serving recipe availability

9. 오픈과 폐쇄를 이념으로 보지 말아야 한다

업무마다 다릅니다. 일부는 GPT-5.5류가 맞고, 일부는 DeepSeek/Gemma 같은 오픈 모델이 더 맞을 수 있습니다.

10. agent platform 없이 agent product를 많이 만들수록 더 위험해진다

공용 런타임, 권한 체계, 로깅, 평가, 비용관리 없이 agent가 늘어나면 곧 기술 부채가 폭발합니다.

11. 보안과 SRE는 AI 도입이 가장 빨리 ROI를 낼 수 있는 분야다

오늘 AWS가 그걸 보여 줬습니다. 구조화된 반복 고급노동이 있는 곳이 AI 에이전트와 가장 잘 맞습니다.

12. AI 앱의 차별화는 모델이 아니라 workflow ownership에서 나온다

누가 더 좋은 모델을 쓰는가보다, 누가 더 좋은 실행 워크플로·정책·메모리·통제구조를 갖는가가 더 중요해지고 있습니다.

8) 역할별로 보면 무엇이 달라지나

프런트엔드 엔지니어

  • 단순 채팅 UI보다 작업 상태 UI가 중요해진다.
  • 승인 대기, 툴 실행, 로그, 재시도, 실패 복구를 보여 줘야 한다.
  • agent가 며칠 동안 도는 구조라면 progress visibility가 필수다.

백엔드 엔지니어

  • stateful runtime, queue, retry, idempotency, policy enforcement가 핵심 역량이 된다.
  • 세션과 메모리를 분리하고, 툴 호출 로그를 구조화해야 한다.
  • inference와 orchestration 비용을 분리 계측해야 한다.

플랫폼팀

  • 공용 agent runtime을 제공할지 결정해야 한다.
  • model routing, evaluation, security gateway, cost controls를 공용 계층으로 올려야 한다.
  • observability와 registry가 없는 agent 개발은 빠르게 통제 불능이 된다.

보안팀

  • agent identity와 permission matrix 정의가 중요해진다.
  • reverse shell, suspicious reasoning, data leakage 같은 이상행동 탐지 구조가 필요하다.
  • semi-autonomous 구조를 먼저 채택하는 편이 현실적이다.

PM과 리더

  • AI 기능을 “답변”이 아니라 “업무 결과”로 정의해야 한다.
  • KPI도 정확도보다 완료율, 처리량, 리드타임, 재작업률로 이동한다.
  • vendor selection은 모델 점수표보다 운영면 성숙도로 봐야 한다.

9) 제품팀과 운영팀을 위한 실전 운영 포인트

오늘 뉴스에서 바로 뽑을 수 있는 운영 체크리스트를 정리하면 다음과 같습니다.

A. 제품팀

  • 이 기능은 답변형인가 실행형인가 먼저 정하라.
  • 실행형이면 승인 단계와 취소/중단 흐름을 먼저 설계하라.
  • 결과만 보여 주지 말고 근거와 진행 상태를 같이 보여 줘라.
  • agent별 owner와 목적을 명확히 하라.

B. 플랫폼팀

  • 공용 memory/runtime/registry/gateway를 둘지 결정하라.
  • inference benchmark를 정기 작업으로 운영하라.
  • long-context workload는 별도 비용모델로 계산하라.
  • CPU control plane 부하를 따로 모니터링하라.

C. 보안팀

  • agent identity를 IAM 체계와 연결하라.
  • high-risk tool은 별도 approval을 두라.
  • prompt injection뿐 아니라 suspicious tool path, data egress, reverse shell 같은 행위를 보라.
  • 보안 agent의 false positive triage capacity를 함께 준비하라.

D. 데이터팀

  • memory와 retrieval에 들어갈 데이터 lifecycle을 정하라.
  • 장기 세션에서 어떤 데이터가 유지되고 어떤 데이터가 만료되는지 정책을 세워라.
  • representative workload dataset 없이는 추론 최적화도 하지 마라.

E. 경영진

  • AI 비용을 월별 GPU 총액만 보지 말고 task당 성공비용으로 보라.
  • agent 도입을 개별 PoC가 아니라 포트폴리오로 관리하라.
  • 모델보다 운영면이 더 빠르게 차별화되는 시장이라는 점을 받아들여라.

10) 한국 시장과 한국어 서비스에 주는 시사점

오늘 흐름은 한국 시장에도 꽤 직접적인 의미가 있습니다.

1. 한국 기업은 agent governance 수요가 특히 크다

국내 기업은 승인 체계와 문서 흐름, 메신저·시트·ERP가 복잡한 경우가 많습니다. 그래서 Google Agent Platform류의 identity, registry, gateway 개념이 특히 중요합니다.

2. HR·재무·운영 자동화에서 ROI가 빨리 날 수 있다

보안/SRE가 대표 사례지만, 국내 SaaS와 백오피스 앱에서도 비슷한 패턴이 나올 수 있습니다.

  • 반복 보고서
  • 승인 전 서류 정리
  • VOC 분류
  • 운영 이상 징후 분석
  • 문서 검색/정리

3. 추론 비용 민감도가 높기 때문에 SageMaker류 접근이 더 중요하다

한국 B2B SaaS는 보통 가격 압박이 크고 운영팀이 작습니다. 따라서 inference optimization 자동화는 단순 편의가 아니라 생존성 문제입니다.

4. 로컬/오픈 모델 활용도 현실적 선택지가 된다

DeepSeek-V4나 Gemma 4 같은 계열은 한국어 서비스에서도 비용·보안·지연 측면에서 매력적일 수 있습니다. 다만 long-context 서빙 구조를 제대로 감당할 수 있어야 합니다.

5. CPU-heavy orchestration을 무시하면 안 된다

작은 팀일수록 GPU만 계산하고 runtime orchestration 부하를 놓치기 쉽습니다. 오늘 Meta 발표는 이 함정을 잘 보여 줍니다.

11) 이번 주, 이번 달, 이번 분기에 바로 할 일

이번 주에 할 일

  1. 현재 만들고 있는 AI 기능을 답변형/실행형으로 나눠라.
  2. 실행형 기능의 승인 지점과 툴 권한 표를 만들어라.
  3. 대표 workload 20개를 뽑아 input/output token 분포를 측정하라.
  4. CPU orchestration 비용과 GPU inference 비용을 분리 계측하라.
  5. long-context가 필요한 업무와 retrieval로 충분한 업무를 구분하라.

이번 달에 할 일

  1. 사내 공용 agent registry 초안을 만들어라.
  2. 최소 1개의 장기 실행형 워크플로를 실전 수준으로 설계하라.
  3. inference benchmark 자동화 파이프라인을 구축하라.
  4. memory retention / correction / expiry 정책을 문서화하라.
  5. high-risk agent용 audit trace 스키마를 정의하라.

이번 분기에 할 일

  1. 공용 agent runtime과 gateway 계층 도입 여부를 결정하라.
  2. model portfolio 전략을 세워라: frontier, cost-efficient, open, local.
  3. 보안·운영·백오피스 분야에서 완료형 agent 2~3개를 실제 배포하라.
  4. task당 성공비용, 완료율, MTTR, 승인리드타임 같은 KPI를 정착시켜라.
  5. 오픈 모델 long-context serving 역량을 한 번은 직접 검증해 둬라.

12) 앞으로 반복될 레퍼런스 아키텍처 6가지

오늘 발표들을 단순 뉴스가 아니라 설계 패턴으로 읽으면, 앞으로 반복될 레퍼런스 아키텍처가 꽤 선명하게 보입니다.

패턴 A. 완료형 운영 에이전트 아키텍처

AWS Security Agent와 DevOps Agent가 가장 잘 보여 준 구조입니다.

구성요소는 대체로 다음과 같습니다.

  • 장기 실행 가능한 agent runtime
  • 코드·문서·아키텍처 다이어그램·텔레메트리 같은 다양한 입력
  • root cause/attack chain 탐지를 위한 reasoning layer
  • 툴 호출과 검증 루프
  • 증거 수집 및 보고서 산출
  • 사람 승인 또는 최종 검토 단계

이 구조는 보안과 SRE뿐 아니라 다음 업무에도 반복될 수 있습니다.

  • 감사 준비
  • 컴플라이언스 점검
  • 백오피스 마감 작업
  • 장애 사후 분석
  • 운영 이상 징후 triage

핵심은 이 agent가 단순 요약기가 아니라 “작업을 끝내는 조정자”라는 점입니다.

패턴 B. 목표 지향형 추론 최적화 아키텍처

SageMaker 발표는 다음 구조를 제시합니다.

  1. 모델 등록
  2. representative workload 정의
  3. 성능 목표 선택(cost / latency / throughput)
  4. 후보 구성 축소
  5. 자동 최적화 적용
  6. 실측 benchmark
  7. ranked recommendation
  8. 곧바로 deployable artifact 생성

이 구조의 중요한 점은 사람의 직관이 아니라 자동 탐색 + 실측 근거가 중심이라는 것입니다. 앞으로 모델 수가 많아질수록, 그리고 context·tool use·multimodality가 섞일수록 이 패턴은 사실상 필수에 가까워질 수 있습니다.

패턴 C. 엔터프라이즈 agent control plane 아키텍처

Google Agent Platform은 다음 그림을 거의 완성형으로 보여 줍니다.

  • build surface(Studio / ADK)
  • runtime
  • memory bank
  • sessions
  • identity
  • registry
  • gateway
  • threat / anomaly detection
  • observability
  • simulation / evaluation / optimizer

중요한 것은 agent가 하나씩 있을 때는 이 구조가 과해 보여도, 다섯 개를 넘고 열 개를 넘기기 시작하면 이 control plane이 없이는 운영이 금방 무너진다는 점입니다.

패턴 D. CPU+GPU 포트폴리오 인프라 아키텍처

Meta의 Graviton 발표는 AI 인프라가 다음과 같이 갈 가능성을 보여 줍니다.

  • GPU는 추론/학습의 핵심 엔진
  • CPU는 orchestration, data handling, system service, session state, retrieval 보조
  • 네트워크와 memory bandwidth는 long-context와 multi-agent coordination의 병목 해결
  • 클라우드와 자체 인프라를 workload별로 혼합 운영

즉 agentic AI 인프라는 단일 accelerator-centric 구조보다 시스템 균형 구조가 더 중요해집니다.

패턴 E. long-context serving architecture

DeepSeek-V4와 NVIDIA가 보여 준 구조의 핵심은 다음입니다.

  • hybrid attention
  • reduced KV cache
  • reduced per-token FLOPs
  • prefill/decode 분리
  • multi-node serving recipe
  • tool calling / reasoning / spec decoding 연계
  • hosted endpoints + self-hosted NIM 경로

이 구조는 앞으로 긴 리서치, 거대한 코드베이스, 대규모 문서 QA, 장기 컴퓨터 사용 agent에 폭넓게 쓰일 수 있습니다.

패턴 F. 오픈 모델 즉시 실전 투입 아키텍처

오픈 모델이 강해져도 서빙과 운영이 따라붙지 않으면 기업 채택이 어렵습니다. 오늘 NVIDIA 흐름은 그 간극을 줄이는 패턴입니다.

  • 공개 모델 가중치
  • Day-0 API endpoint
  • NIM / vLLM / SGLang recipe
  • 유명 harness와의 연결 가이드
  • 특정 하드웨어용 최적화 경로
  • 추론 경제성 스토리

이 구조가 자리 잡으면 오픈 모델은 실험용이 아니라 production candidate가 됩니다.

13) 실패하는 팀들의 공통 패턴

오늘 발표들이 보여 주는 성공 서사를 뒤집어 보면, 실제 현장에서 자주 보게 될 실패 패턴도 명확합니다.

실패 패턴 1. 챗봇을 에이전트라고 부른다

긴 system prompt와 몇 개의 function call만 붙여 놓고 에이전트라고 부르는 경우가 많습니다. 하지만 실제 완료형 agent에 필요한 것은 다음입니다.

  • 상태 유지
  • 장기 실행
  • 승인지점
  • 오류 복구
  • 증거 보존
  • 운영 로그
  • owner와 permission model

이 중 절반도 없으면 그건 대개 agent가 아니라 조금 복잡한 챗봇입니다.

실패 패턴 2. inference budget을 출시 후에 본다

팀은 종종 모델 품질에만 집중하고, 추론 비용과 latency를 나중에 봅니다. 하지만 장기 컨텍스트와 tool loop가 붙는 순간 구조가 굳어 버립니다. 그때 가서 최적화를 시작하면 이미 너무 늦습니다.

실패 패턴 3. observability 없이 production에 올린다

에이전트는 내부 과정이 길고 복잡합니다. trace가 없으면 문제를 재현할 수 없고, 재현이 안 되면 개선도 안 됩니다. 운영 관점에서 observability 없는 agent는 거의 블랙박스 운영입니다.

실패 패턴 4. memory를 기능으로만 보고 리스크로 보지 않는다

장기 메모리는 personalization을 올려 주지만 동시에 다음 리스크를 만듭니다.

  • 오래된 사실의 고착
  • 개인정보 누적
  • 잘못된 선호 추론
  • 예전 맥락이 현재 판단을 오염시키는 현상

따라서 memory는 저장소가 아니라 정책 문제입니다.

실패 패턴 5. CPU orchestration 비용을 무시한다

GPU 예산만 계산하고 control plane을 대충 잡으면, 실제 서비스가 커졌을 때 오케스트레이션 레이어가 먼저 흔들립니다. 오늘 Meta 발표는 이 함정이 결코 작은 문제가 아님을 보여 줍니다.

실패 패턴 6. long-context를 retrieval 설계 대체재로 착각한다

1M 컨텍스트 모델이 있더라도 모든 것을 매번 다 넣는 방식은 비용도 비싸고 응답도 흔들리기 쉽습니다. long-context는 retrieval, summarization, cache 전략을 없애는 기술이 아니라 그것들과 함께 설계해야 하는 기술입니다.

실패 패턴 7. open vs closed를 이념으로만 선택한다

오픈 모델은 통제력과 비용면에서 장점이 있지만 운영 복잡도가 커질 수 있습니다. 폐쇄형 frontier model은 성능과 완성도가 좋을 수 있지만 비용·잠금(lock-in)·통제 이슈가 있습니다. 업무 특성을 보지 않고 이념으로 고르면 금방 후회합니다.

실패 패턴 8. KPI를 여전히 “정답률” 하나로 잡는다

완료형 agent에서 중요한 것은 다음입니다.

  • task completion rate
  • retry rate
  • human takeover rate
  • approval latency
  • successful task당 비용
  • evidence completeness
  • time to resolution

정답률만 보면 실제 운영 가치를 놓칩니다.

14) 도메인별로 보면 오늘 뉴스는 어떻게 읽혀야 하나

1. 보안 제품과 보안 운영

AWS Security Agent 흐름은 보안 분야가 AI의 가장 빠른 실전 전장 중 하나임을 보여 줍니다. 특히 중요한 것은 발견량이 아니라 remediation throughput입니다.

  • 더 많이 찾는 것
  • 더 빨리 분류하는 것
  • 더 빨리 고치는 것
  • 증거와 책임을 남기는 것

이 네 가지를 함께 다뤄야 합니다.

2. SRE / 플랫폼 운영

DevOps Agent는 운영팀이 반복적으로 하는 다음 종류의 일을 잘 겨냥합니다.

  • 로그/메트릭/배포이력 상관분석
  • 장애 원인 후보 축소
  • 변경 이력과 장애 시점 연결
  • 임시 완화 방안 제안
  • 사후 분석 초안 작성

즉 SRE는 가장 먼저 ROI를 체감할 수 있는 직군일 수 있습니다.

3. B2B SaaS와 백오피스 앱

한국 기업 SaaS, HR, 회계, 운영툴 관점에서는 Google Agent Platform식 control plane과 SageMaker식 cost optimization이 특히 중요합니다. 이 분야는 화려한 창의성보다 다음이 더 중요하기 때문입니다.

  • 반복성
  • 추적성
  • 승인 흐름
  • 비용 예측 가능성
  • 보안 경계

4. 개발자 도구

NVIDIA + DeepSeek 흐름은 코딩 에이전트 시장에도 시사점이 큽니다.

  • 거대한 저장소 전체 읽기
  • 장기 작업 유지
  • 많은 툴 호출
  • 실행 로그 축적
  • cost-sensitive serving

즉 개발자 도구는 앞으로 long-context serving 품질과 agent runtime 품질이 함께 경쟁력을 좌우할 것입니다.

5. 온프레/하이브리드 엔터프라이즈

Meta의 CPU 다변화와 Google의 governance, NVIDIA의 오픈 모델 서빙 경로를 같이 보면, 향후 대기업은 하이브리드 전략을 더 자주 택할 수 있습니다.

  • 민감 데이터는 내부
  • burst inference는 클라우드
  • 일부 오픈 모델은 사내 배치
  • 일부 frontier API는 제한 업무에만 사용

6. 스타트업

스타트업은 모든 걸 직접 만들면 안 됩니다. 오늘 발표가 주는 가장 현실적인 조언은 다음과 같습니다.

  • runtime은 가능한 한 공용화하라
  • benchmark는 자동화하라
  • 비용 목표를 먼저 정하라
  • memory와 audit 설계를 너무 늦게 미루지 마라
  • open/closed 모델을 workload별로 섞어라

15) 무엇을 측정해야 하나: KPI의 재설계

오늘 흐름을 실제 운영으로 가져가려면 측정 항목이 바뀌어야 합니다.

성능 KPI

  • task completion rate
  • time to first useful action
  • total task completion time
  • P95/P99 latency
  • tool call success rate
  • root cause identification time

비용 KPI

  • successful task당 총 비용
  • inference token cost vs orchestration cost
  • context length별 비용 증가율
  • fallback model 사용률
  • cache / memory reuse로 절감한 비용

운영 KPI

  • approval lead time
  • human takeover rate
  • suspend/resume success rate
  • anomaly detection rate
  • incident reduction rate
  • false positive 처리 소요시간

거버넌스 KPI

  • identity 없는 agent 비율
  • registry 미등록 tool 사용 비율
  • audit trail 누락 비율
  • policy violation 탐지 건수
  • owner 미지정 agent 수

품질 KPI

  • evidence completeness
  • user trust score
  • rework rate
  • correction frequency
  • domain-specific benchmark score

이제 AI 프로젝트는 메시지 수나 활성 사용자 수만으로 평가하기엔 너무 복잡해졌습니다. 완료형 agent 시대의 KPI는 훨씬 운영적이어야 합니다.

16) 도입 전에 반드시 던져야 할 질문 30개

전략과 제품

  1. 이 기능은 답변형인가, 실행형인가
  2. 실행형이라면 어디서 사람이 개입해야 하는가
  3. 이 agent의 성공 기준은 무엇인가
  4. 이 기능은 몇 분짜리 작업인가, 며칠짜리 작업인가
  5. 같은 업무를 얼마나 반복 수행할 것인가

런타임과 상태

  1. 상태는 어디에 저장할 것인가
  2. 무엇을 장기 기억으로 남길 것인가
  3. 기억은 언제 만료되는가
  4. 중단된 작업은 어떻게 재개되는가
  5. 동일한 작업의 중복 실행을 어떻게 방지하는가

권한과 보안

  1. 어떤 툴은 읽기 전용인가
  2. 어떤 툴은 쓰기 권한을 가지는가
  3. high-risk action은 무엇인가
  4. agent마다 독립 identity가 필요한가
  5. 어떤 이상행동을 탐지해야 하는가

추론과 비용

  1. cost/latency/throughput 중 무엇이 제일 중요한가
  2. representative workload는 준비되어 있는가
  3. context length가 늘어날 때 비용이 얼마나 증가하는가
  4. fallback model은 무엇인가
  5. GPU 외 orchestration 비용은 얼마나 되는가

long-context와 retrieval

  1. 정말 1M 컨텍스트가 필요한가
  2. retrieval로 해결 가능한가
  3. 어떤 정보는 항상 세션에 남겨야 하는가
  4. 어떤 정보는 요약만 남겨야 하는가
  5. prefill/decode 병목을 측정하고 있는가

운영과 조직

  1. owner는 누구인가
  2. agent registry는 있는가
  3. 관측성과 trace는 충분한가
  4. 출시 후 evaluation은 어떻게 계속 돌릴 것인가
  5. 실패했을 때 agent를 즉시 끌 수 있는가

17) 리스크도 같이 봐야 한다

오늘 뉴스가 보여 주는 방향이 분명히 강력하긴 하지만, 리스크도 같이 봐야 합니다.

1. 과잉 자율화 리스크

에이전트가 더 오래, 더 많이, 더 스스로 행동할수록 잘못된 액션이 커질 수 있습니다. 따라서 “얼마나 자율적인가”보다 “어디서 멈추는가”가 중요합니다.

2. 에이전트 스프롤

플랫폼이 쉬워질수록 작은 agent가 우후죽순 생깁니다. registry와 owner 체계가 없으면 곧 통제 불능이 됩니다.

3. 벤치마크 착시

DeepSeek-V4의 장기 컨텍스트, AWS의 자동 최적화, Google의 운영면 모두 인상적이지만, 각 조직의 실제 workload와는 다를 수 있습니다. 내부 eval 없이는 숫자만 믿으면 안 됩니다.

4. 비용 착시

더 효율적인 모델이나 더 나은 tuning이 나와도, agent 사용량 자체가 늘어나면 총비용은 오히려 더 커질 수 있습니다.

5. 보안 이중용도 문제

보안 에이전트는 방어에도 쓰이지만 공격에도 쓰일 수 있습니다. 따라서 capability 확장은 항상 제한 배포와 감사 구조를 동반해야 합니다.

6. 벤더 잠금

identity, gateway, runtime, memory, benchmark, serving이 한 벤더에 너무 강하게 묶이면 나중에 이동 비용이 크게 늘 수 있습니다.

7. 메모리 오염

장기 기억을 가진 agent는 personalization과 함께 잘못된 기억의 누적, 오래된 정보의 고착이라는 문제도 함께 가집니다.

18) 벤더별 전략 차이도 읽어야 한다

AWS

AWS는 오늘 매우 선명합니다.

  • frontier agents로 완료형 실행을 판다
  • SageMaker로 추론 최적화를 자동화한다
  • 결국 고객이 agent workload를 AWS 위에서 안전하고 싸게 운영하게 만든다

즉 AWS는 모델 회사라기보다 AI 운영 인프라 회사의 포지션을 강화하고 있습니다.

Google

Google은 Agent Platform으로 control plane을 잡으려 합니다.

  • memory
  • runtime
  • identity
  • gateway
  • security
  • observability

즉 Google은 엔터프라이즈에서 agent fleet의 운영체제를 노립니다.

Meta

Meta는 오늘 직접 agent platform을 파는 대신, AI 시대의 거대한 시스템이 어떤 컴퓨트 철학을 가져야 하는지 보여 줍니다. 이는 장기적으로 자체 생태계를 더 강하게 받치는 기반 메시지입니다.

NVIDIA

NVIDIA는 여전히 실리콘만 파는 회사가 아니라는 점을 반복해서 증명하고 있습니다.

  • endpoints
  • NIM
  • recipes
  • open model integration
  • harness examples

즉 NVIDIA는 model deployment super-layer를 노리고 있습니다.

DeepSeek

DeepSeek는 공식 사이트 문구만 봐도 포지션이 분명합니다.

  • world-class reasoning
  • improved agent capability
  • web/app/API release

즉 단순 오픈 모델이 아니라 agent-friendly frontier open model로 자신을 포지셔닝하고 있습니다.

19) 석의 맥락에서 오늘 뉴스가 특히 중요한 이유

석처럼 여러 웹앱을 운영하고, 앞으로 HR 시스템을 포함한 실무형 앱을 배포하려는 관점에서는 오늘 뉴스가 단순 업계 동향이 아닙니다. 꽤 직접적인 제품 전략 힌트가 됩니다.

1. HR 시스템은 frontier IQ보다 workflow reliability가 더 중요하다

인사 시스템에서 중요한 것은 다음입니다.

  • 권한
  • 승인
  • 로그
  • 문서 추적
  • 반복 업무 자동화
  • 비용 통제

즉 오늘 Google과 AWS가 보여 준 control plane / execution plane이 더 직접적으로 중요합니다.

2. 앱별로 AI를 따로 붙이면 곧 관리 비용이 폭발한다

여러 웹앱을 운영할 계획이라면 공용 agent runtime, 공용 eval, 공용 permission model이 필요해질 가능성이 높습니다. 오늘 Google Agent Platform 흐름이 바로 그 방향입니다.

3. 작은 팀일수록 추론 자동 최적화가 더 중요하다

직접 GPU tuning 전문가를 두기 어렵다면, SageMaker류 자동화 또는 그에 준하는 내부 자동화가 점점 더 중요해집니다.

4. 장기적으로는 open model 역량도 반드시 축적해야 한다

초기에는 frontier API가 편할 수 있지만, 장기 운영·비용·보안까지 생각하면 DeepSeek/Gemma 계열을 다룰 수 있는 능력도 분명 자산이 됩니다.

5. agent governance는 나중 문제가 아니다

특히 HR과 업무형 SaaS는 권한과 기록이 핵심입니다. 따라서 identity, registry, audit, approval을 제품 초기부터 설계하는 편이 훨씬 낫습니다.

20) 앞으로 90일 안에 가장 많이 반복될 시나리오 5가지

시나리오 A. 강한 모델보다 강한 런타임이 먼저 승부를 가르는 경우

많은 팀은 여전히 모델 비교표를 먼저 봅니다. 하지만 실제로는 비슷한 수준의 모델을 두고 다음에서 승부가 갈릴 가능성이 큽니다.

  • 어느 쪽이 장기 실행을 더 안정적으로 다루는가
  • 어느 쪽이 승인과 audit을 붙이기 쉬운가
  • 어느 쪽이 state recovery와 observability가 더 좋은가
  • 어느 쪽이 tool integration을 덜 깨지게 하는가

즉 앞으로 90일 안에 시장에서 자주 볼 장면은 “모델은 비슷한데 운영면이 더 좋은 쪽이 이기는 상황”일 수 있습니다.

시나리오 B. 추론 단가 때문에 에이전트 설계를 다시 뜯는 경우

처음에는 좋은 모델 하나로 빠르게 붙여도 됩니다. 문제는 사용량이 올라간 다음입니다.

  • 문서 길이가 길어진다
  • tool output이 누적된다
  • memory가 늘어난다
  • long-context 비용이 급상승한다
  • 동시성 요구가 커진다

이때 SageMaker류 자동 최적화나 자체 benchmark 체계가 없는 팀은 설계를 뒤늦게 다시 뜯게 될 수 있습니다.

시나리오 C. governance가 없어서 agent 확장이 멈추는 경우

에이전트 하나는 쉽습니다. 다섯 개도 쉽습니다. 문제는 그다음입니다.

  • 누가 owner인지 헷갈린다
  • 같은 agent가 중복된다
  • 어떤 tool이 승인됐는지 모른다
  • 로그가 흩어진다
  • incident가 나도 책임 주체가 अस्पष्ट해진다

그래서 registry, identity, gateway 같은 control plane이 없는 팀은 agent가 늘수록 속도가 느려질 가능성이 큽니다.

시나리오 D. CPU/오케스트레이션 병목이 예상보다 빨리 드러나는 경우

메타의 발표는 대형 기업 이야기처럼 보이지만, 작은 팀도 같은 문제를 축소판으로 겪습니다.

  • 큐와 세션 관리가 느리다
  • tool routing이 병목이 된다
  • 로그와 이벤트 적재가 밀린다
  • 여러 agent가 동시에 돌면 control plane이 흔들린다

즉 GPU만 늘려서는 해결되지 않는 병목이 의외로 빨리 드러날 수 있습니다.

시나리오 E. 오픈 모델이 생각보다 더 빨리 실전 후보가 되는 경우

DeepSeek-V4 같은 계열에 day-0 serving recipe가 붙기 시작하면, 많은 팀이 다음 결론에 도달할 수 있습니다.

  • 모든 high-end workload를 폐쇄형 API로만 돌릴 필요는 없다
  • 일부는 오픈 모델+좋은 서빙 스택이 더 낫다
  • 장기적으로는 혼합 포트폴리오가 유리하다

이 변화는 특히 비용과 통제에 민감한 기업에서 더 빨리 나타날 수 있습니다.

21) 조직이 지금 작성해 두면 좋은 정책 문서 10개

오늘 뉴스의 흐름은 결국 문서화 과제를 줍니다. 실제 운영 전에 아래 문서가 없으면 agent 도입이 금방 막히거나 위험해질 수 있습니다.

1. Agent Permission Matrix

  • 어떤 agent가 어떤 시스템을 읽을 수 있는가
  • 어떤 agent가 어떤 시스템에 쓸 수 있는가
  • 어떤 액션은 반드시 승인 대상인가

2. Memory Lifecycle Policy

  • 어떤 정보가 장기 기억에 들어가는가
  • 얼마나 보관하는가
  • 사용자가 정정 또는 삭제를 요청하면 어떻게 반영하는가

3. Inference Optimization Standard

  • 성능 목표 우선순위
  • benchmark 주기
  • representative workload 정의
  • 회귀 발생 시 대응 기준

4. Agent Identity & Ownership Policy

  • agent 등록 방식
  • owner 지정 방식
  • 비활성화 기준
  • 접근권한 검토 책임자

5. Audit Trail Standard

  • 어떤 로그를 남길 것인가
  • 어떤 로그는 마스킹할 것인가
  • 얼마나 오래 보관할 것인가
  • incident 시 어떤 이벤트를 우선 확보할 것인가

6. Human-in-the-Loop Standard

  • 어떤 단계에서 사람이 승인해야 하는가
  • 승인 거부 시 어떻게 롤백되는가
  • 승인 없이 허용되는 행동 범위는 어디까지인가

7. Long-Context Usage Guideline

  • 언제 긴 컨텍스트를 쓰는가
  • 언제 retrieval이 더 적절한가
  • context budget을 초과하면 어떻게 축약하는가

8. Model Portfolio Policy

  • 어떤 업무에 어떤 모델을 쓰는가
  • fallback 모델은 무엇인가
  • 오픈/폐쇄형 선택 기준은 무엇인가

9. Incident Response for Agents

  • agent가 잘못된 행동을 했을 때 누구에게 알릴 것인가
  • 에이전트를 즉시 끄는 절차는 무엇인가
  • 어떤 로그와 산출물을 보존해야 하는가

10. Cost Guardrail Policy

  • task당 비용 상한
  • 사용자/팀별 사용량 한도
  • context explosion을 막는 제한
  • 오케스트레이션 비용 임계치 경보

이 문서들은 재미없어 보이지만, 결국 agent 운영은 여기서 갈립니다.

22) 지금 흔히 나오는 오판 10가지

오판 1. “좋은 모델이면 agent도 잘 된다”

아닙니다. agent는 모델 품질 외에 상태, 툴, 권한, 재개, 관측성, 비용이 함께 받쳐줘야 합니다.

오판 2. “long-context가 retrieval을 대체한다”

아닙니다. 대부분의 경우 retrieval, memory summary, context selection이 더 중요해집니다.

오판 3. “GPU만 충분하면 된다”

아닙니다. Meta가 공개적으로 말했듯 CPU와 bandwidth, control plane이 매우 중요합니다.

오판 4. “관측성은 나중에 붙이면 된다”

아닙니다. trace가 없으면 production에서 문제 원인을 알 수 없습니다.

오판 5. “open model은 아직 실전이 멀다”

아닙니다. serving path와 recipes가 같이 나오기 시작하면 오픈 모델은 빠르게 실전 후보가 됩니다.

오판 6. “완전 자율이 곧 더 좋은 제품이다”

아닙니다. 특히 보안, 운영, 백오피스에서는 semi-autonomous 구조가 더 현실적입니다.

오판 7. “에이전트는 UX 문제다”

절반만 맞습니다. agent는 UX이면서 동시에 runtime / infra / IAM / observability 문제입니다.

오판 8. “벤치마크 점수가 높으면 바로 도입해도 된다”

아닙니다. 내부 workload eval 없이는 실제 가치를 모릅니다.

오판 9. “작은 팀은 control plane이 필요 없다”

초기에는 그럴 수 있습니다. 하지만 agent가 늘어나면 작은 팀일수록 control plane 부재의 고통이 더 큽니다.

오판 10. “비용 문제는 성장한 뒤 고민하자”

AI는 초기에 설계하지 않으면 나중에 구조를 뜯어야 하는 비용이 더 큽니다.

23) 결론

2026년 4월 25일의 AI 뉴스는 단순한 “새 기능 모음”이 아닙니다. 오늘 발표들은 모두 같은 사실을 각자의 언어로 말하고 있습니다.

이제 AI 시장의 다음 승부는 모델 지능 자체보다, 그 지능을 얼마나 오래·싸게·안전하게·통제 가능하게 굴릴 수 있느냐에 달려 있다.

AWS는 frontier agents와 SageMaker inference recommendations로 실행과 최적화의 자동화를, Google은 Agent Platform으로 메모리·정체성·게이트웨이·위협 탐지·관측성의 통합을, Meta는 Graviton 대규모 도입으로 agentic AI용 CPU 포트폴리오 전략을, NVIDIA와 DeepSeek는 V4와 Blackwell 경로로 1M 컨텍스트 장기 추론의 실전 배포성을 보여 줬습니다.

그래서 오늘 가장 중요한 결론은 이것입니다.

  • 더 좋은 모델만으로는 부족하다
  • 더 좋은 에이전트 데모만으로도 부족하다
  • 운영체제처럼 굴릴 수 있는 agent runtime이 필요하다
  • 추론 경제성을 자동으로 최적화할 수 있어야 한다
  • identity·registry·gateway·security가 붙어야 한다
  • CPU/GPU/메모리/네트워크까지 포함한 인프라 포트폴리오가 필요하다
  • long-context와 open model도 실제 서빙 경로가 있어야 의미가 있다

오늘 발표들을 하나의 문장으로 요약하면 이렇습니다.

AI의 다음 경쟁은 모델 전쟁이 아니라 에이전트 운영 전쟁이다.

소스 링크

  • AWS launches frontier agents for security testing and cloud operations
    https://aws.amazon.com/blogs/machine-learning/aws-launches-frontier-agents-for-security-testing-and-cloud-operations/

  • Amazon SageMaker AI now supports optimized generative AI inference recommendations
    https://aws.amazon.com/blogs/machine-learning/amazon-sagemaker-ai-now-supports-optimized-generative-ai-inference-recommendations/

  • Introducing Gemini Enterprise Agent Platform
    https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform

  • Meta Partners With AWS on Graviton Chips to Power Agentic AI
    https://about.fb.com/news/2026/04/meta-partners-with-aws-on-graviton-chips-to-power-agentic-ai/

  • Build with DeepSeek V4 Using NVIDIA Blackwell and GPU-Accelerated Endpoints
    https://developer.nvidia.com/blog/build-with-deepseek-v4-using-nvidia-blackwell-and-gpu-accelerated-endpoints/

  • DeepSeek 공식 사이트
    https://www.deepseek.com/

댓글