CoreWeave agentic AI 출시, inference 로그가 다시 학습 데이터로

AI 요약

• 무슨 일: CoreWeave가 2026년 5월 28일 agentic AI 통합 기능을 공개했습니다.
  • 구성 요소는 Serverless RL, production inference, W&B Weave observability, W&B Skills와 MCP server입니다.
• 핵심 주장: production agent의 실행 기록을 관측하고 평가한 뒤 다시 post-training 신호로 되돌리는 폐쇄 루프입니다.
• 숫자: CoreWeave는 local H100 환경 대비 RL 비용 최대 40% 절감, training 약 1.4배 가속을 주장했습니다.
• 주의점: 발표는 full-stack 운영 방향을 보여주지만, 품질·guardrail·lock-in·실제 비용은 팀별 production trace로 검증해야 합니다.

CoreWeave는 2026년 5월 28일 agentic AI 통합 기능을 공개했습니다. 발표문은 training, inference, observability, reinforcement learning을 한 폐쇄 루프로 묶어 production agent가 실제 사용자 시나리오에서 배운 내용을 다음 버전의 개선 신호로 되돌린다고 설명합니다. GPU cloud 회사가 새 모델을 내놓은 사건이 아니라, agent가 실패한 기록을 다시 학습과 평가 인프라로 연결하겠다는 운영 제품 발표입니다.

CoreWeave가 붙인 이름은 superintelligence loop입니다. 표현은 거창하지만 제품 설명에서 확인되는 구조는 더 구체적입니다. Agent를 먼저 production inference에 올리고, W&B Weave로 품질·비용·latency·safety 신호를 모읍니다. 그 뒤 Serverless RL로 multi-turn agent task를 post-train하고, W&B Skills와 MCP server로 coding agent가 실험과 평가 도구를 직접 다루게 합니다. 발표문은 이 네 가지를 “single closed loop”로 묶었습니다.

출처: CoreWeave.

이번 발표가 AI 개발자에게 닿는 이유는 agent 성능 경쟁의 기준을 모델 이름에서 production trace로 옮기기 때문입니다. 2025년과 2026년의 coding agent 발표들은 plan, sandbox, browser, PR, merge 같은 실행 표면을 빠르게 확장했습니다. CoreWeave의 발표는 그 다음 병목을 겨냥합니다. agent가 실제 업무에서 어떤 tool call을 실패했는지, 어떤 prompt가 비용을 키웠는지, 어떤 multi-step workflow에서 latency가 누적됐는지 관측하지 못하면 더 큰 GPU를 붙여도 reliability는 고정되지 않습니다.

CoreWeave 발표문은 기존 방식의 문제를 offline evaluation으로 설명합니다. agent를 배포하기 전에 labeled dataset으로 여러 달 평가하고, 품질·정확도·비용·style 지표가 기준에 들어오면 그제야 production inference로 보낸다는 절차입니다. CoreWeave는 이 방식이 느리고, eval dataset이 실제 사용자 시나리오를 모두 덮을 수 없어서 agent failure를 막기 어렵다고 주장합니다. 이 문장은 agent 팀이 이미 겪는 문제와 맞닿아 있습니다. test set은 항상 production traffic보다 작고, tool 환경은 배포 뒤에 더 자주 바뀝니다.

CoreWeave가 제시한 첫 번째 조각은 Serverless RL입니다. solution page는 RL을 agent가 environment와 상호작용하고 reward 또는 penalty를 받아 장기 보상을 최대화하는 행동을 학습하는 절차로 설명합니다. CoreWeave는 이 작업이 advanced하고 GPU-intensive라 대부분의 enterprise에는 접근하기 어려웠다고 적었습니다. 이번 발표에서는 infrastructure provisioning 없이 multi-turn agentic task에 대해 LLM을 post-train하는 서비스로 포장했습니다.

숫자도 붙었습니다. CoreWeave는 press release에서 Serverless RL이 local H100 GPU 환경과 비교해 비용을 최대 40% 줄이고 training을 약 1.4배 빠르게 하며 quality loss가 없다고 주장했습니다. 이 수치는 CoreWeave가 직접 제시한 비교 조건입니다. 따라서 독자는 “모든 RL 작업에서 비용이 40% 줄어든다”가 아니라 “CoreWeave가 local H100 환경 대비 그렇게 측정했다고 발표했다”로 읽어야 합니다. 실제 팀의 차이는 rollout environment, reward design, traffic volume, failed run 재시도 비용에서 갈립니다.

두 번째 조각은 production inference입니다. CoreWeave는 inference를 controllable, continuously running workload로 설명하고, runtime flexibility와 system health monitoring을 강조했습니다. Agentic AI solution page에는 더 직접적인 문장이 있습니다. CoreWeave는 agentic AI를 “inference that runs in loops”라고 정의합니다. 일반적인 request-response와 달리 agent는 plan을 세우고, retrieval을 호출하고, tool을 실행하고, 다시 판단합니다. 한 단계의 p95 latency가 작아 보여도 다섯 단계가 이어지면 사용자 경험과 비용은 곱으로 누적됩니다.

세 번째 조각은 W&B Weave입니다. W&B Weave product page는 agent와 AI application을 evaluate, monitor, iterate하는 도구라고 설명하고, “one line of code”로 시작한다고 홍보합니다. 페이지의 지표 범주는 quality, cost, latency, safety입니다. W&B는 OpenAI, Anthropic, Cohere, LangChain, LlamaIndex, OpenTelemetry, MCP 같은 integration도 나열합니다. CoreWeave 발표에서 Weave는 agent production behavior를 RL과 improvement loop로 넘기는 관측 계층입니다.

관측 계층이 중요한 이유는 agent failure가 단일 stack trace로 남지 않는 경우가 많기 때문입니다. 코딩 agent가 잘못된 package를 설치하거나, customer support agent가 retrieval 결과를 잘못 고르거나, data agent가 SQL을 세 번 고친 끝에 비용을 크게 쓰는 상황은 모두 “모델 응답이 나빴다”로 묶기 어렵습니다. Trace에는 prompt, model, tool call, retrieval result, latency, token usage, user feedback, safety event가 함께 남아야 합니다. CoreWeave가 Weave를 앞세우는 이유는 GPU 공급만으로 이 정보를 만들 수 없기 때문입니다.

네 번째 조각은 W&B Skills와 MCP server입니다. W&B Skills page는 coding agent가 실험 추적, model management, tracing, evaluation, monitoring을 다룰 수 있게 한다고 설명합니다. CoreWeave 발표문도 같은 방향으로 말합니다. general-purpose coding agent를 AI researcher와 agent builder로 바꿔 W&B 도구에 접근시키고, MCP server가 data 접근과 experiment 실행 자원을 제공한다는 구조입니다. 이 대목은 Claude Code나 Codex의 workflow와 직접 비교됩니다. agent가 code만 고치는 것이 아니라 eval run과 experiment bookkeeping까지 맡는다는 뜻입니다.

CoreWeave의 제품 방향은 2025년 Weights & Biases 인수 이후 더 선명해졌습니다. AI Business 인터뷰는 이번 기능이 CoreWeave의 2025년 W&B 인수와 연결된다고 설명했습니다. 같은 기사에서 새 package는 serverless RL, inference, observability를 묶어 agent task용 post-training stack을 만든다고 정리했습니다. CoreWeave의 Corey Sanders는 회사가 GPU-as-a-service보다 “AI cloud”라는 용어를 선호한다고 답했습니다. 여기서 AI cloud는 GPU, storage, orchestration, observability, inference, post-training까지 세로로 묶인 stack입니다.

이 방향은 hyperscaler와 neocloud 모두에게 압박을 줍니다. AWS Bedrock, Azure AI Foundry, Google Vertex AI는 모델 접근, orchestration, governance를 이미 제공합니다. Together AI, Fireworks, DeepInfra 같은 inference provider는 open model serving의 가격과 latency를 경쟁합니다. LangSmith, Arize Phoenix, Braintrust, Datadog은 LLM 관측성과 평가를 별도 제품으로 팝니다. CoreWeave는 이 조각들을 “agent reliability loop”라는 하나의 인프라 이야기로 묶으려 합니다.

CoreWeave가 inference 성능을 계속 앞세우는 점도 같은 맥락입니다. 2026년 4월 1일 CoreWeave는 MLPerf Inference v6.0 결과를 발표했습니다. 해당 발표는 DeepSeek-R1과 GPT-OSS-120B를 기준 모델로 언급했습니다. 5월 11일에는 Moonshot AI Kimi K2.6 benchmark를 공개했습니다. CoreWeave는 이 benchmark에서 output speed와 price-performance 1위를 주장했습니다. 이번 agentic AI 발표는 그 benchmark 메시지를 “빠른 serving”에서 “빠른 개선 루프”로 확장합니다.

다만 benchmark와 production agent는 같은 문제가 아닙니다. Benchmark는 통제된 조건에서 tokens per second, throughput, price-performance를 비교합니다. Production agent는 prompt routing, tool availability, data freshness, retry policy, user interruption, authorization, audit log를 함께 다룹니다. CoreWeave가 말하는 폐쇄 루프가 실제로 도움이 되려면 production trace가 reward로 바뀌는 과정이 투명해야 합니다. 잘못 분류된 failure가 RL signal로 들어가면 agent는 더 빠르게 나빠질 수도 있습니다.

Guardrail도 발표문의 빈칸입니다. CoreWeave는 observability, security, audit visibility를 강조하지만, agent가 unauthorized behavior로 흐르거나 adversarial user interaction에 노출될 때 어떤 policy가 RL 개선 루프를 멈추는지는 고객 설계에 많이 남아 있습니다. AI Business 인터뷰에서도 critical failure와 guardrails가 질문으로 나왔습니다. Sanders는 guardrails와 controls, Weave observability, Serverless RL feedback을 묶어 답했지만, 규제 산업의 승인 경계나 human review threshold까지 세부 정책으로 제시한 것은 아닙니다.

Migration 관점에서는 한 가지 실무 단서가 있습니다. AI Business 인터뷰에서 Sanders는 W&B가 multi-cloud tooling이고, CoreWeave inference platform이 OpenAI standard APIs를 사용한다고 말했습니다. 이 설명이 맞다면 이미 다른 환경에서 OpenAI-compatible endpoint를 쓰는 팀은 일부 serving path를 옮기기 쉽습니다. 하지만 observability, data retention, reward pipeline, model artifact, private tool environment까지 함께 옮기는 문제는 API 호환성보다 큽니다. Agent reliability loop는 endpoint 교체가 아니라 운영 체계 교체에 가깝습니다.

개발팀이 이번 발표에서 가져갈 질문은 세 가지입니다. 첫째, 현재 agent의 실패 기록이 trace로 남는지 확인해야 합니다. prompt와 final answer만 저장하면 tool failure와 latency 누적을 고칠 수 없습니다. 둘째, eval dataset과 production traffic 사이의 차이를 별도 지표로 봐야 합니다. offline score가 높은 agent가 실제 사용자 작업에서 실패하는 이유는 대부분 dataset 밖의 tool state와 permission state에 있습니다. 셋째, RL이나 fine-tuning을 붙이기 전에 reward와 rollback 기준을 정해야 합니다.

커뮤니티 반응은 아직 얕습니다. Hacker News와 GeekNews에서 큰 토론은 확인하지 못했고, Reddit의 r/CRWV 글은 공식 investor news 링크를 공유하며 주식 관점의 기대를 붙인 수준이었습니다. 기술 커뮤니티가 아직 product detail보다 산업 방향을 보고 있다는 뜻입니다. CoreWeave가 OpenAI, Anthropic, Meta, Microsoft 같은 대형 수요와 연결된 compute 회사라는 점 때문에 시장은 “GPU 공급자”의 software stack 확장을 먼저 읽습니다.

한국 개발자와 AI 제품팀에게는 이 발표가 당장 CoreWeave를 써야 한다는 신호보다 체크리스트에 가깝습니다. Agent를 production에 올린다면 trace schema, eval ownership, model rollout, cost budget, safety event, human review, rollback을 하나의 루프로 묶어야 합니다. CoreWeave는 이 루프를 자사 cloud와 W&B 도구로 제품화하고 있습니다. 같은 루프를 LangSmith와 Kubernetes, Braintrust와 자체 inference, Datadog과 hyperscaler 조합으로 만들 수도 있습니다. 비교 기준은 vendor name보다 trace가 실제 개선 신호로 바뀌는지입니다.

이번 발표의 실질적 의미는 CoreWeave가 GPU 임대 회사의 경계를 넘고 있다는 점입니다. GPU를 얼마나 많이 확보했는지보다, agent가 실패한 production 기록을 누가 학습 가능한 데이터로 바꾸는지가 다음 인프라 경쟁의 과제가 됩니다. CoreWeave의 답은 inference, Weave, Serverless RL, Skills, MCP server를 묶은 폐쇄 루프입니다. 이 답이 충분한지는 아직 production 사례가 더 필요합니다. 그래도 2026년 5월 28일의 발표는 agent 운영 경쟁이 “모델을 어디에서 호출하나”에서 “실패한 호출을 어떻게 다시 학습시키나”로 이동하고 있음을 보여주는 분명한 사건입니다.