15배 토큰 청구서, AI 네이티브 클라우드의 귀환

AI 요약

• 무슨 일: DigitalOcean이 Deploy 2026에서 AI-Native Cloud와 Inference Engine 확장을 공개했습니다.
  • 핵심 주장은 agent-native workload가 인간 사용자 대비 15배 토큰, 전통 워크로드 대비 4배 CPU를 요구한다는 비용 구조입니다.
• 의미: AI 인프라 경쟁이 GPU 임대에서 라우팅, RAG, state, sandbox, agent orchestration을 묶는 운영 스택으로 이동하고 있습니다.
• 주의점: 42% 비용 절감과 월 $67,727 비교는 벤더 제공 분석입니다. 실제 팀은 자기 trace와 실패율로 재계산해야 합니다.

DigitalOcean이 2026년 4월 28일 Deploy 2026에서 AI-Native Cloud를 공개했습니다. 겉으로 보면 클라우드 회사의 제품 묶음 발표입니다. 하지만 숫자를 따라가면 더 흥미로운 이야기가 보입니다. DigitalOcean은 agentic task가 수백 번의 모델 호출, 수백 번의 데이터베이스 쿼리, 100만 개 이상의 토큰을 소비할 수 있다고 설명합니다. 또 agentic system은 비슷한 전통 워크로드보다 약 4배 많은 CPU capacity를 쓰고, 인간 사용자보다 15배 많은 토큰을 소비한다고 주장합니다.

이 문장은 AI 인프라 경쟁의 중심을 잘 보여줍니다. 지난 2년 동안 시장은 "어디서 GPU를 빌릴 것인가"에 집중했습니다. H100, H200, B200, MI300X 같은 이름이 곧 전략처럼 보였습니다. 그러나 실제 AI 제품이 production으로 들어가면 병목은 GPU 한 줄로 끝나지 않습니다. 모델 호출 앞뒤에 데이터 검색, cache, retry, tool execution, sandbox, state 저장, 권한, guardrail, tracing, 비용 라우팅이 붙습니다. 코딩 에이전트든 고객지원 에이전트든 여행 예약 에이전트든, 비용은 모델 단가표가 아니라 전체 루프에서 나옵니다.

DigitalOcean의 발표가 흥미로운 이유는 바로 이 지점을 정면으로 겨냥하기 때문입니다. 회사는 AI-Native Cloud를 infrastructure, core cloud, inference, data, managed agents의 5개 계층으로 설명합니다. 서버리스 추론, 전용 추론, 배치 추론, 모델 카탈로그, Inference Router, Knowledge Bases, Managed Weaviate, managed agents를 한 플랫폼 안에 놓겠다는 것입니다. 단일 제품의 성능 자랑보다 "AI 앱을 운영하려면 이 조각들을 따로 붙이는 비용이 너무 커졌다"는 문제 제기에 가깝습니다.

추론이 훈련보다 더 지루하고 더 비싸집니다

AI 뉴스에서는 훈련이 늘 더 크게 보입니다. 몇 개 GPU 클러스터를 썼는지, 몇 조 파라미터인지, 어느 모델이 benchmark에서 이겼는지가 눈에 잘 들어옵니다. 하지만 제품을 운영하는 팀의 청구서에는 다른 항목이 더 자주 등장합니다. 추론 호출 수, context 길이, embedding, reranking, vector database, queue, browser sandbox, 파일 저장, 로그 보관, 평가 job, 재시도, 그리고 사람이 실패를 복구하는 시간이 쌓입니다.

DigitalOcean은 이를 "inference era"라고 부릅니다. 공식 발표는 2030년 전 세계가 하루 500조 개 이상의 inference token을 처리할 것으로 전망합니다. 현재 약 50조 개에서 10배 증가한다는 주장입니다. 이 숫자는 예측이므로 그대로 믿기보다 방향을 읽는 편이 낫습니다. 중요한 것은 AI 제품의 marginal cost가 사용자 수만으로 선형 증가하지 않는다는 점입니다. 에이전트가 백그라운드에서 여러 모델을 호출하고, 각 단계마다 검색과 검증을 반복하면 사용자 한 명의 작업이 내부적으로는 수십 명의 API 사용자처럼 보일 수 있습니다.

예를 들어 여행 예약 에이전트를 생각해 보겠습니다. 사용자는 "다음 달 샌프란시스코 출장 일정을 잡아줘"라고 한 번 말합니다. 하지만 시스템은 항공편 검색, 호텔 검색, 회사 정책 확인, 캘린더 확인, 가격 비교, 결제 승인, 이메일 작성, 일정 변경 감지, 취소 정책 분석을 차례로 수행합니다. 각 단계는 모델 호출과 데이터 질의를 만듭니다. 실패하면 재시도합니다. 더 안전하게 만들려면 평가와 guardrail도 붙습니다. 사용자는 한 번 요청했지만 인프라는 긴 실행 그래프를 처리합니다.

이것이 DigitalOcean이 "GPU만 있으면 된다"는 사고를 밀어내려는 이유입니다. GPU는 필요합니다. 그러나 GPU만 빌려서는 agent loop의 상태, 데이터, 네트워크, 보안, 평가, 라우팅을 해결하지 못합니다. 반대로 hyperscaler의 수많은 서비스를 직접 조립하면 유연성은 얻지만 glue cost가 커집니다. DigitalOcean은 이 사이에서 "AI-native builder가 바로 쓸 수 있는 통합 스택"이라는 포지션을 잡고 있습니다.

5계층 스택은 포장지가 아니라 비용 구조입니다

DigitalOcean의 AI-Native Cloud는 다섯 계층으로 나뉩니다. 첫째는 infrastructure입니다. 발표는 20개 글로벌 데이터센터, NVIDIA H100, H200, HGX B300, AMD Instinct MI300X, MI350X, MI355X GPU, 400G RoCE RDMA fabric을 언급합니다. 둘째는 core cloud입니다. Kubernetes, CPU/GPU Droplets, VPC, S3 호환 object storage, block/file storage가 여기에 들어갑니다.

셋째는 inference engine입니다. 이 계층이 이번 발표의 핵심입니다. DigitalOcean은 serverless endpoints, dedicated endpoints, batch processing, model router, model catalog, bring-your-own-model, custom vLLM fork, KV-cache tuning, speculative decoding, GPU-aware scheduling을 묶습니다. 넷째는 data and learning입니다. PostgreSQL과 pgvector, Valkey, Knowledge Bases, real-time data capability가 들어갑니다. 다섯째는 managed agents입니다. open agent harness support, secure sandboxes, durable state management, agent orchestration이 핵심입니다.

이 구조를 제품 브로셔로만 보면 새로울 것이 없어 보일 수 있습니다. 클라우드 회사라면 당연히 compute, storage, database, AI product를 나열합니다. 하지만 agent-native workload에서는 이 계층 사이의 경계가 곧 비용 경계가 됩니다. 모델 호출은 inference 비용을 만들고, 검색은 vector/RAG 비용을 만들고, sandbox는 CPU와 storage 비용을 만들고, state는 database와 object storage 비용을 만들고, tracing은 observability 비용을 만듭니다. 각 계층이 다른 vendor에 흩어지면 egress, latency, auth, debugging, billing attribution이 함께 복잡해집니다.

DigitalOcean은 이를 "stitching" 문제로 표현합니다. AI 팀이 모델 provider, GPU cloud, vector database, managed PostgreSQL, queue, observability, agent framework를 따로 고르면 초기 선택지는 많아집니다. 하지만 production에서 문제가 생기면 책임 경계가 흐려집니다. 모델이 느린가, retrieval이 느린가, 네트워크 egress가 비싼가, routing rule이 잘못됐는가, batch로 보낼 수 있었던 호출을 실시간으로 처리했는가를 추적해야 합니다. DigitalOcean은 그 복잡성을 한 플랫폼 안에서 줄이겠다고 말합니다.

Inference Router는 모델 라우팅을 운영 문제로 바꿉니다

이번 발표에서 개발자가 가장 구체적으로 볼 부분은 Inference Router입니다. DigitalOcean 문서는 2026년 5월 1일 Inference Router가 public preview로 모든 사용자에게 활성화됐다고 설명합니다. 기능 설명은 단순합니다. 여러 모델을 model pool로 묶고, inference request에 대해 routing rule과 selection policy를 구성합니다. pre-built template도 있고, natural language로 custom task-matching logic을 정의할 수도 있으며, reliability를 위한 fallback도 설정합니다.

이 기능은 AI 앱의 실제 운영 방식과 맞닿아 있습니다. 한 모델을 모든 요청에 쓰는 시대는 빨리 지나가고 있습니다. 간단한 분류는 작은 open model로 충분할 수 있고, 긴 코드 분석은 더 강한 모델이 필요할 수 있습니다. 고객 대화 요약은 낮은 latency가 중요하고, 법률 문서 검토는 quality와 residency가 더 중요할 수 있습니다. 이미지, 음성, 텍스트, video generation까지 섞이면 라우팅은 if문 몇 개로 버티기 어렵습니다.

DigitalOcean은 LawVo 사례를 듭니다. 발표에 따르면 LawVo는 130개 이상의 AI agents를 운영하며 주 5억 토큰 이상을 처리하고, DigitalOcean 전환 후 코드 변경 없이 inference cost를 42% 줄였습니다. 이 수치는 vendor case study이므로 독립 검증된 benchmark로 받아들이면 안 됩니다. 하지만 어느 지점을 최적화하려는지는 분명합니다. 모델 단가가 아니라 "어떤 요청을 어떤 모델과 deployment type으로 보내는가"가 비용을 좌우한다는 것입니다.

이 흐름은 DigitalOcean만의 이야기가 아닙니다. Vercel AI Gateway, OpenRouter, LiteLLM, hyperscaler의 model router, 사내 LLM gateway가 모두 비슷한 문제를 다룹니다. 차이는 어디까지 책임지느냐입니다. 단순 gateway는 provider 호출을 추상화합니다. 더 깊은 inference platform은 model catalog, 평가, guardrail, batch, dedicated endpoint, cost policy까지 묶습니다. DigitalOcean은 여기에 database와 agent runtime까지 붙여 더 아래 계층으로 내려가려 합니다.

Knowledge Bases와 MCP는 RAG를 에이전트 도구로 만듭니다

DigitalOcean의 Knowledge Bases도 눈여겨볼 만합니다. 공식 블로그는 Knowledge Bases를 ingestion, chunking, embedding, retrieval, reranking을 처리하는 관리형 RAG 서비스로 설명합니다. 문서 쪽에서는 semantic, keyword, hybrid search, filter, retrieved chunk 검토, live code example 복사, reranking, RAG Playground 같은 기능을 언급합니다. 중요한 대목은 Knowledge Bases가 MCP tool로 노출된다는 점입니다.

RAG는 오래된 패턴이지만, 에이전트 시대에는 성격이 바뀝니다. 챗봇이 문서 몇 개를 검색해 답변하는 정도라면 retrieval 품질은 UX 문제입니다. 하지만 에이전트가 검색 결과를 바탕으로 결제, 배포, 고객 응대, 문서 수정, 코드 변경을 수행하면 retrieval은 실행 안전의 일부가 됩니다. 잘못 검색된 chunk는 잘못된 action으로 이어질 수 있습니다. 따라서 RAG는 "답변을 풍부하게 하는 부가 기능"이 아니라 agent loop의 입력 경계가 됩니다.

MCP tool로 노출된다는 것은 에이전트가 Knowledge Base를 구조화된 도구처럼 호출할 수 있다는 뜻입니다. 이는 개발자 경험을 단순화합니다. 하지만 동시에 운영 질문도 생깁니다. 어떤 에이전트가 어떤 knowledge base를 읽을 수 있는가. 검색 결과 chunk는 trace에 남는가. reranking 모델은 어떤 비용을 만들고, 실패 시 fallback은 무엇인가. 데이터 residency와 보존 정책은 어떻게 적용되는가. DigitalOcean이 AI-Native Cloud를 "한 스택"으로 묶는다면, 이런 질문의 답도 한 운영 화면에서 이어져야 합니다.

비용 비교는 흥미롭지만 그대로 믿으면 안 됩니다

DigitalOcean은 representative 1M bookings/month corporate-travel agent workload를 기준으로 자사 AI-Native Cloud 비용을 월 67,727달러로 제시했습니다. 같은 workload를 Baseten + AWS에서는 84,827달러, AWS AgentCore에서는 110,337달러로 비교합니다. 발표 문구로는 20~40% 절감입니다. 또 별도 Inference Engine 발표는 early design partner들이 최대 67% 낮은 inference cost를 보고했다고 말합니다.

이 숫자는 기사 hook으로 강합니다. 하지만 실무에서는 조심해야 합니다. 첫째, representative workload의 구성에 따라 결과는 크게 달라집니다. 모델 호출 비율, context 길이, batch 가능 비율, cache hit, vector search 빈도, region, egress, 실패 재시도, human review 비용이 모두 영향을 줍니다. 둘째, 비교 대상의 할인, enterprise commit, reserved capacity, 자체 최적화 수준에 따라 차이가 바뀝니다. 셋째, 에이전트 비용은 성공률과 함께 봐야 합니다. 싼 모델을 많이 써서 실패율이 올라가면 전체 비용은 더 비싸질 수 있습니다.

따라서 개발팀이 배울 점은 "DigitalOcean이 더 싸다"가 아닙니다. 올바른 질문은 "우리 agent run의 비용 구조를 계층별로 나누고 있는가"입니다. 모델 호출 비용만 보는 팀은 sandbox CPU, database query, embedding, reranking, observability, 실패 복구 비용을 놓칩니다. 반대로 모든 요청을 최고 모델로 보내는 팀은 라우팅으로 줄일 수 있는 비용을 놓칩니다. AI-native cloud라는 말이 의미 있으려면 이 비용을 추적하고, 라우팅하고, 실험할 수 있어야 합니다.

개발자에게는 vendor 선택보다 trace가 먼저입니다

DigitalOcean의 발표는 AI-native builder에게 매력적인 약속을 합니다. open-source model과 frontier closed model을 한 application에서 섞고, routing을 동적으로 바꾸고, Knowledge Bases와 agents를 같은 플랫폼에서 운영하라는 것입니다. 이 방향은 현실적입니다. 대부분의 production AI 팀은 앞으로 단일 모델 전략으로 오래 버티기 어렵습니다. 비용, 성능, latency, privacy, region, modality가 요청마다 다르기 때문입니다.

하지만 어떤 platform을 쓰든 먼저 필요한 것은 trace입니다. 에이전트가 한 작업을 완료하는 데 몇 번 모델을 호출하는지, 어떤 모델이 어느 단계에서 실패하는지, retrieval이 답변 품질에 얼마나 기여하는지, 어떤 호출은 batch로 미룰 수 있는지, 어떤 단계는 작은 모델로 충분한지 알아야 합니다. 이 데이터가 없으면 Inference Router도 guessing machine이 됩니다. 자연어로 routing rule을 쓰는 것은 편리하지만, 그 rule이 실제 비용과 품질을 개선하는지는 평가 job과 production telemetry로 확인해야 합니다.

이 점에서 DigitalOcean 문서의 model evaluation, agent tracing metrics, agent evaluation metrics 항목은 중요한 신호입니다. AI platform이 단순히 모델 호출 endpoint를 제공하는 시대는 끝나고 있습니다. 개발자는 call 하나가 아니라 run 전체를 봐야 합니다. "이 에이전트는 성공했는가", "어떤 단계에서 비용이 튀었는가", "fallback이 품질을 지켰는가", "RAG가 hallucination을 줄였는가", "사람이 개입한 횟수는 줄었는가"가 운영 지표가 됩니다.

조용하지만 중요한 클라우드 재편입니다

이 뉴스가 OpenAI나 Google의 모델 발표만큼 크게 소비되지 않은 것은 자연스럽습니다. AI-Native Cloud는 소비자 데모가 아니라 인프라 포지셔닝입니다. 그러나 개발자와 AI product team에게는 오히려 이런 발표가 더 오래 갑니다. 모델은 몇 달마다 바뀌지만, production stack은 한 번 잡으면 바꾸기 어렵습니다. 특히 데이터, state, observability, routing이 한 platform에 묶이면 이동 비용이 커집니다.

그래서 DigitalOcean의 전략은 양면적입니다. 한편으로는 fragmentation을 줄입니다. 작은 팀이 hyperscaler의 복잡한 서비스 조합이나 GPU cloud의 낮은 수준 인프라를 직접 다루지 않고도 AI 제품을 빨리 운영할 수 있습니다. 다른 한편으로는 새로운 통합 platform lock-in을 만듭니다. model router, knowledge base, managed agent, tracing, sandbox가 한곳에 묶이면 편리하지만, 나중에 다른 cloud나 자체 stack으로 옮길 때는 추상화의 이식성이 중요해집니다.

DigitalOcean은 open standards와 open-source technology를 강조합니다. 발표는 OpenCode, LangGraph, PostgreSQL, MySQL, pgvector, Qdrant, DeepSeek, Llama, Qwen, NVIDIA Nemotron 3 Nano Omni, Claude, GPT, Kubernetes, Cilium, S3-compatible storage를 언급합니다. 이 목록은 시장 메시지입니다. "우리는 폐쇄 생태계가 아니라 open stack으로 간다"는 신호입니다. 그러나 실제 개방성은 API 호환성, export format, tracing schema, routing rule portability, data migration 경험에서 검증됩니다.

결론은 클라우드가 다시 AI 앱 모양으로 바뀐다는 것입니다

DigitalOcean AI-Native Cloud 발표의 핵심은 "새 클라우드 상품이 나왔다"가 아닙니다. 더 큰 변화는 AI 애플리케이션의 기본 단위가 단일 request에서 long-running agent loop로 바뀌면서, 클라우드가 다시 그 모양에 맞춰 재구성되고 있다는 점입니다. 예전 SaaS 시대의 클라우드는 웹 서버, 데이터베이스, object storage, queue, CDN을 중심으로 정리됐습니다. agent-native 시대의 클라우드는 model routing, RAG, tool execution, sandbox, state, evaluation, guardrail, tracing을 기본 구성으로 요구합니다.

그런 의미에서 "15배 토큰"은 과장된 마케팅 숫자일 수 있지만, 문제의 방향은 정확합니다. 에이전트는 사용자의 한 문장을 내부적으로 긴 실행 그래프로 바꿉니다. 그 그래프의 비용을 보지 못하면 AI 제품은 demo에서는 잘 돌아가도 production에서는 손익이 흔들립니다. DigitalOcean은 그 비용 그래프를 클라우드 제품의 중심으로 끌어오려 합니다.

앞으로 봐야 할 것은 세 가지입니다. 첫째, Inference Router가 실제 mixed-model production에서 비용과 품질을 얼마나 안정적으로 개선하는가. 둘째, Knowledge Bases와 managed agents가 LangGraph, OpenCode, MCP 같은 외부 생태계와 얼마나 자연스럽게 이어지는가. 셋째, DigitalOcean의 비용 비교가 다양한 workload에서도 반복되는가. 답은 발표문이 아니라 production trace에서 나올 것입니다.

그래도 방향은 분명합니다. AI 인프라 시장의 다음 경쟁은 누가 더 많은 GPU를 보유했는가만으로 결정되지 않습니다. 누가 agent loop 전체를 더 싸고, 더 관측 가능하고, 더 바꾸기 쉽게 운영하게 만드는지가 중요해지고 있습니다. DigitalOcean의 AI-Native Cloud는 그 전환을 노골적으로 선언한 발표입니다. 모델 호출은 기능이지만, 에이전트 실행은 인프라입니다.