CoreWeave 에이전트 플랫폼 공개, 학습과 추론을 한 루프로

AI 요약

• 무슨 일: CoreWeave가 2026년 5월 28일 W&B와 통합한 에이전트 AI 플랫폼을 발표했습니다.
  • 구성은 Serverless RL, CoreWeave 추론, W&B Weave 관측·평가, W&B Skills, W&B MCP입니다.
• 의미: GPU 클라우드가 모델 호스팅을 넘어 에이전트 개선 루프를 제품으로 묶기 시작했습니다.
• 주의점: 발표는 통합 방향을 제시했지만 가격, SLA, 실제 RL 운영 비용은 프로젝트별로 확인해야 합니다.

CoreWeave가 2026년 5월 28일 투자자 사이트와 제품 페이지를 통해 에이전트 AI 플랫폼을 공개했습니다. 발표문 제목은 "자율 에이전트 개선을 위해 학습과 추론 사이의 간극을 닫는다"는 문장으로 시작합니다. 새 플랫폼은 CoreWeave AI Cloud의 추론, Serverless RL, W&B Weave, W&B Models, W&B Skills를 한 흐름으로 묶습니다. GPU 클라우드 회사가 단순히 더 빠른 인스턴스를 파는 대신, 에이전트가 실패한 실행 로그를 다시 평가와 강화학습으로 돌리는 운영 경로를 팔기 시작했다는 점이 이번 발표의 읽을거리입니다.

이번 뉴스는 CoreWeave가 W&B를 인수한 뒤 처음으로 내놓은 통합형 에이전트 메시지입니다. W&B는 실험 추적과 모델 평가로 알려진 도구였고, CoreWeave는 NVIDIA GPU를 대규모로 제공하는 클라우드 인프라 회사였습니다. 두 회사가 합쳐졌을 때 개발자들이 예상한 조합은 "학습은 W&B, 배포는 CoreWeave" 정도였습니다. 이번 발표는 그보다 좁고 구체적인 방향을 잡았습니다. 대상은 일반 ML 파이프라인 전체가 아니라, 긴 실행 경로와 도구 호출을 가진 autonomous agent입니다.

에이전트 제품에서 학습과 추론의 분리는 비용 문제로 바로 드러납니다. 챗봇은 한 번의 응답 품질을 측정하면 어느 정도 비교가 됩니다. 코딩 에이전트, 데이터 분석 에이전트, 운영 자동화 에이전트는 다릅니다. 입력은 자연어 하나여도 내부에서는 검색, 코드 실행, API 호출, 권한 승인, 재시도, 실패 로그가 이어집니다. 사용자가 "성공"이라고 느끼는 결과는 모델 출력 하나가 아니라 실행 전체의 비용, 시간, 오류 회복, 감사 가능성으로 결정됩니다.

CoreWeave가 잡은 고리는 이 전체 실행 경로입니다. 발표문은 플랫폼의 첫 축으로 Serverless RL을 제시합니다. CoreWeave 문서에서 Serverless RL은 Ray와 Kubernetes 기반의 강화학습 작업을 서버리스 방식으로 돌리는 제품입니다. 개발자는 클러스터를 직접 오래 붙잡고 관리하기보다, RL 작업을 정의하고 필요한 GPU 자원을 받아 실행하는 방식에 가깝습니다. 에이전트가 실제 사용자 환경에서 남긴 실행 데이터를 다시 reward signal이나 평가 세트로 바꾸려면, 추론 로그와 학습 작업 사이를 사람이 수동으로 옮기는 과정이 병목이 됩니다.

두 번째 축은 CoreWeave 추론입니다. CoreWeave Inference 문서는 OpenAI-compatible endpoint, model catalog, BYOW deployment, traffic splitting, autoscaling, budget alerts를 내세웁니다. 여기서 BYOW는 Bring Your Own Weights입니다. 기업이 자체 fine-tuned 모델이나 open-weight 모델을 배포하고, 트래픽 일부만 새 버전으로 보내거나 예산 한도를 설정하는 운영 방식입니다. 에이전트 팀에는 이 기능이 단순 편의 기능이 아닙니다. 모델 A와 모델 B의 평균 점수보다, 실제 작업 플로우에서 어느 모델이 더 적은 도구 호출과 더 낮은 실패율을 내는지가 비용표를 바꿉니다.

세 번째 축은 W&B Weave입니다. W&B 문서에서 Weave는 LLM 앱의 trace, evaluation, production monitoring, human annotation을 다룹니다. 특히 production monitoring 문서는 실제 운영 트래픽에서 latency, cost, feedback, custom metric을 추적하고 online evaluation을 붙이는 흐름을 설명합니다. 이 항목은 에이전트 개발팀이 이미 겪는 문제와 맞닿아 있습니다. 테스트 데이터셋에서 pass rate가 높아도, 운영 환경에서는 내부 API 응답 지연, 권한 오류, 잘못된 tool schema, 사용자 승인 거부 때문에 실패가 납니다.

W&B MCP 서버와 W&B Skills도 같은 방향으로 배치됩니다. W&B MCP 페이지는 LLM이 W&B의 experiment, model, artifact, evaluation 정보를 도구처럼 조회할 수 있게 한다고 설명합니다. 에이전트가 자신의 실행 결과를 평가하고 다음 실험을 고르는 데 필요한 메타데이터를 W&B 쪽에서 직접 가져올 수 있다는 뜻입니다. W&B Skills는 반복되는 domain task를 LLM이 수행할 수 있게 묶는 패키지형 기능으로 소개됩니다. 단순한 프롬프트 저장소가 아니라, 특정 작업을 실행 가능한 단위로 포장하려는 시도에 가깝습니다.

CoreWeave 발표가 흥미롭다는 표현만으로는 부족합니다. 더 구체적으로 말하면, 이 발표는 AI 인프라의 상품 단위를 GPU 시간에서 "개선 가능한 에이전트 운영 루프"로 넓힙니다. 기존 클라우드 비교는 H100 수량, 네트워크 대역폭, 시간당 가격, 예약 가능성에 머무르기 쉬웠습니다. 에이전트 서비스에서는 여기에 trace 보존 기간, 평가 자동화, replay 가능성, traffic splitting, 실패 샘플링, human annotation 비용이 붙습니다. 모델이 한 번 틀린 뒤 같은 실수를 줄이는 경로가 제품 기능으로 관리되는지 여부가 인프라 선택 기준이 됩니다.

AWS, Google, Microsoft도 에이전트 운영을 인프라 계층에서 잡으려 합니다. AWS는 Bedrock AgentCore와 브라우저, 코드 실행, 메모리, gateway 같은 구성 요소를 내세웁니다. Google은 Vertex AI Agent Engine과 Gemini Enterprise, Antigravity 계열 도구를 통해 모델과 워크플로우를 묶습니다. Microsoft는 Azure AI Foundry, GitHub Copilot, 에이전트 개발 도구를 같은 생태계로 연결합니다. CoreWeave의 차별점은 hyperscaler가 아니라 GPU 특화 클라우드라는 출발점과 W&B라는 실험·평가 도구를 직접 품었다는 점입니다.

이 차이는 장점과 한계를 동시에 만듭니다. 장점은 에이전트 개선의 비용 중심이 GPU 학습과 GPU 추론에 있을 때 CoreWeave가 더 직선적인 메시지를 낼 수 있다는 점입니다. 자체 모델을 들고 있고, inference endpoint를 바꾸며, trace와 평가를 한 곳에서 보려는 팀에는 W&B 통합이 설득력을 가집니다. 한계는 엔터프라이즈 업무 시스템과 권한 경계입니다. 에이전트가 Salesforce, ServiceNow, Jira, 내부 데이터베이스를 호출하는 순간 문제는 GPU만으로 풀리지 않습니다. IAM, 데이터 거버넌스, 사내 승인 정책, 감사 로그의 책임이 남습니다.

개발자 입장에서 바로 달라지는 부분은 추론 API 선택지가 하나 늘었다는 수준이 아닙니다. 에이전트 제품을 운영하려면 최소 네 가지 로그가 필요합니다. 첫째, 입력과 출력입니다. 둘째, 중간 도구 호출과 실패 원인입니다. 셋째, 사용자의 승인·거부·수정 피드백입니다. 넷째, 배포된 모델 버전과 비용입니다. CoreWeave와 W&B 조합은 이 네 가지를 같은 개선 루프에 넣겠다고 말합니다. 실제 도입 판단은 이 로그들이 프로젝트 보안 요구와 데이터 보존 정책을 만족하는지부터 시작해야 합니다.

이번 발표에서 아직 숫자로 확인되지 않은 영역도 있습니다. 발표문은 통합 플랫폼의 방향과 구성 요소를 설명하지만, 모든 구성의 가격표를 한 장으로 제시하지는 않습니다. Serverless RL의 실제 비용은 GPU 종류, episode 길이, rollout 수, reward model 사용 여부, checkpoint 저장량에 따라 달라집니다. Weave 관측 비용도 trace 양, annotation volume, retention 정책에 영향을 받습니다. "학습과 추론을 한 루프로 묶는다"는 제품 문장은 매력적이지만, 구매 결정에서는 한 번의 작업 성공률과 평균 토큰 비용보다 전체 episode당 비용을 계산해야 합니다.

보안 관점에서는 W&B MCP가 양면성을 가집니다. MCP 서버가 experiment, artifact, evaluation을 LLM 도구로 노출하면 에이전트가 실험 결과를 빠르게 조회할 수 있습니다. 동시에 내부 모델 기록, 실패 로그, 고객 데이터가 포함된 trace에 접근하는 새 경로가 생깁니다. 팀은 MCP tool scope, 읽기 전용 권한, 프로젝트별 접근 제어, 외부 모델로 전송되는 컨텍스트 범위를 확인해야 합니다. 에이전트가 "다음 실험을 고르기 위해" 민감한 artifact 이름과 평가 샘플을 프롬프트에 넣는 순간, 관측 도구는 실행 권한의 일부가 됩니다.

제품 팀이 먼저 볼 지표는 벤치마크 점수보다 회귀 방지입니다. 예를 들어 고객 지원 에이전트가 환불 정책을 잘못 적용했다면, 해당 trace를 수집하고, 실패 원인을 라벨링하고, 새 평가 케이스로 넣고, 수정된 프롬프트나 모델을 제한 트래픽에 배포해야 합니다. 이 과정이 Jira 티켓, 스프레드시트, 수동 로그 export로 흩어지면 개선 속도는 느려집니다. CoreWeave가 말하는 training-to-inference gap은 바로 이 수동 경로입니다. 발표의 실무 가치는 이 경로를 얼마나 덜어내는지로 평가해야 합니다.

한국 개발팀에는 두 가지 질문이 남습니다. 첫째, 자체 모델이나 open-weight 모델을 운영할 이유가 있는가입니다. OpenAI, Anthropic, Google 모델 API만 쓰는 팀은 CoreWeave의 GPU 추론과 Serverless RL 이점을 크게 느끼지 못할 수 있습니다. 둘째, 에이전트 실패 데이터가 충분히 쌓이는가입니다. 하루 수십 건 수준의 내부 도우미라면 대규모 RL 루프보다 프롬프트, tool schema, 승인 UX 개선이 더 저렴합니다. 반대로 수천·수만 episode가 반복되는 코딩, 분석, 고객 응대, 운영 자동화라면 trace 기반 평가와 제한 배포가 비용을 줄일 수 있습니다.

CoreWeave의 이번 발표는 "더 큰 모델" 발표가 아닙니다. 새 foundation model 이름도, 단일 벤치마크 1위도 없습니다. 대신 모델이 실제 서비스에서 틀린 뒤 그 실패를 어떤 데이터와 실행 경로로 고칠 것인지 묻습니다. 에이전트 AI가 데모에서 운영으로 넘어갈수록 이 질문은 더 자주 나옵니다. 한 번의 응답보다 한 달 동안 누적된 실패 로그, 비용, 승인 기록, 모델 교체 이력이 구매 기준이 됩니다. CoreWeave와 W&B는 그 기준을 GPU 클라우드 안으로 끌어오려 합니다.

그래서 이번 뉴스를 읽을 때 제품명보다 루프를 봐야 합니다. CoreWeave Inference가 실행하고, Weave가 관측하고, W&B MCP와 Skills가 실험 지식과 작업 단위를 노출하고, Serverless RL이 개선 작업을 돌립니다. 각 조각은 이미 시장에 경쟁 제품이 있습니다. LangSmith, Braintrust, Arize Phoenix, hyperscaler의 agent platform, 자체 Ray 클러스터가 모두 비교 대상입니다. CoreWeave가 해결해야 할 문제는 기능 목록의 길이가 아니라, 이 조각들이 실제 운영 데이터에서 끊기지 않는지입니다.

2026년의 에이전트 인프라 경쟁은 모델 API 호출을 어디에 보내느냐보다 실패를 어디에 남기고 어떻게 고치느냐로 좁혀지고 있습니다. CoreWeave의 발표는 그 경쟁에서 GPU 공급자가 관측성과 평가 도구를 인수해 직접 운영 루프를 만들겠다는 선언입니다. 개발팀이 지금 할 일은 발표 문구를 그대로 받아들이는 것이 아닙니다. 에이전트 episode당 비용, 실패 라벨링 방식, MCP 권한, traffic splitting 기준, 데이터 보존 정책을 체크리스트로 놓고, "학습과 추론이 정말 같은 루프에 들어오는가"를 검증하는 일입니다.