AI 에이전트가 클라우드 인프라를 다시 설계하게 만드는 이유
클라우드를 사용하는 주체가 달라지고 있습니다
2024년 1,700만 달러 규모의 시리즈 A 단계였던 Modal은 Latent Space가 이번 인터뷰를 공개한 2026년 7월에는 3억5,500만 달러 규모의 시리즈 C를 마친 회사로 소개됩니다. 불과 2년 사이 투자 규모만 커진 것은 아닙니다. Modal이 풀고 있다고 설명하는 문제도 개발자의 불편을 줄이는 데서 AI 에이전트가 직접 사용할 수 있는 클라우드를 만드는 데까지 넓어졌습니다.
이번 글에서 살펴볼 자료는 AI 엔지니어링 전문 팟캐스트 Latent Space가 2026년 7월 8일 공개한 Why AI Infrastructure must evolve for Agent Experience입니다. 진행자인 swyx와 Vibhu가 Modal 공동창업자이자 최고기술책임자(CTO)인 Akshat Bubna와 약 58분간 나눈 대화입니다.
다만 제공된 원문에는 인터뷰의 상세 대화가 도입부까지만 담겨 있습니다. 이후 기술 항목은 Latent Space가 함께 공개한 에피소드 소개와 타임스탬프를 기준으로 살펴보겠습니다. 개별 기능의 성능이나 상용화 수준까지 확인됐다고 단정하지는 않겠습니다.
이 대화는 간단하지만 중요한 변화를 다룹니다.
기존 클라우드는 사람인 개발자를 위해 만들어졌지만, 이제는 AI 에이전트가 클라우드를 직접 사용하기 시작한다는 변화입니다.
사람에게 불편한 인프라는 에이전트에게 막힌 길이 됩니다
기존 개발자는 문서를 읽고 YAML 같은 설정 파일을 해석하며, 대시보드를 오가면서 장애 원인을 추론할 수 있습니다. 사용하기 불편해도 빠진 맥락을 머릿속에서 보충합니다. 명령이 실패하면 로그를 읽고 검색한 뒤 설정을 고쳐 다시 실행합니다.
AI 에이전트는 다릅니다. 코드를 작성하는 데서 그치지 않고 실제 작업까지 끝내려면 아래 과정을 반복해야 합니다.
- 코드를 작성합니다.
- 실행할 환경을 준비합니다.
- 코드를 실행합니다.
- 출력과 오류를 확인합니다.
- 환경이나 코드를 바꿉니다.
- 다시 실행합니다.
필요한 정보가 여러 문서와 화면에 흩어져 있거나, 사람이 의미를 해석해야만 다음 단계로 넘어갈 수 있다면 에이전트의 작업은 쉽게 멈춥니다. 사람에게는 번거로운 개발자 경험에 그치지만, 에이전트에게는 작업 성공률을 좌우하는 제약입니다.
Modal이 말하는 에이전트 경험(Agent Experience)은 이 반복 고리를 짧고 명확하게 만드는 일로 이해할 수 있습니다. 개발자 경험이 사람이 도구를 편하게 쓰도록 만드는 것이라면, 에이전트 경험은 기계가 인프라를 예측 가능한 방식으로 조작하도록 만드는 데 가깝습니다.
Kubernetes보다 출발점이 문제입니다
Akshat Bubna는 Modal의 출발점을 워크플로 오케스트레이션(workflow orchestration, 여러 작업의 실행 순서와 자원을 관리하는 방식)의 불편에서 찾습니다. 이런 제품이 왜 사용하기 어려운지 파고들자 Kubernetes 위에서 운영해야 한다는 문제가 드러났다고 설명합니다.
Kubernetes는 컨테이너로 묶인 프로그램을 여러 서버에 배치하고 운영하는 강력한 시스템입니다. Bubna의 지적은 이것이 급격하게 늘었다 줄어드는 작업과 사용자별 이미지 구성에 처음부터 맞춰진 도구가 아니라는 데 있습니다. 인터뷰에서 그는 Kubernetes가 버스트성(burstiness, 짧은 시간에 연산 수요가 폭발하는 특성)에 맞지 않고, 사용자 정의 이미지 처리와 개발자 경험도 좋지 않았다고 회고합니다.
전통적인 웹 서비스는 비교적 꾸준히 요청을 받습니다. AI 작업은 한동안 조용하다가 수많은 GPU가 갑자기 필요해질 수 있습니다. 모델을 불러와 추론한 뒤 작업이 끝나면 자원이 다시 필요 없어지기도 합니다. 연구자가 여러 실험을 동시에 돌리거나 에이전트가 대량의 작업 환경을 잠깐 생성할 때는 변동 폭이 더 커집니다.
Modal은 이 문제를 해결하려고 먼저 새로운 런타임(runtime, 프로그램이 실제로 실행되는 기반 환경)을 만들었고, 이후 AI 작업에 필요한 클라우드 기능으로 확장했다고 설명합니다. Modal이 ChatGPT 등장 전부터 GPU를 추가했다는 대목도 눈에 띕니다. 공개된 자료만으로 당시의 사업적 판단 과정까지 알 수는 없지만, AI 애플리케이션의 실행 형태가 기존 웹 서비스와 다르다는 문제를 비교적 일찍 포착한 듯합니다.
에이전트 클라우드를 구성하는 여러 층
Latent Space의 소개에는 Modal이 제공하거나 논의한 기술이 폭넓게 등장합니다. 서버리스 함수(serverless function, 서버를 직접 관리하지 않고 코드를 실행하는 방식), 코드 장식자 기반 인프라(decorator-based infrastructure, 코드에 간단한 표시를 붙여 실행 환경을 선언하는 방식), 샌드박스, 영구 저장소, 네트워크로 연결된 컨테이너, 다중 노드 학습 등이 포함됩니다.
처음 접하면 기능이 지나치게 많아 보입니다. 저는 이를 세 층으로 나누어 봅니다.
첫째는 에이전트가 이해하기 쉬운 조작 방식입니다. 복잡한 설정 파일과 운영 화면 대신 코드와 명확한 인터페이스로 자원, 환경, 실행을 다룰 수 있어야 합니다. Modal이 강조하는 프로그램 방식의 인프라는 에이전트가 사람의 화면 조작을 흉내 내지 않고 구조화된 명령으로 클라우드를 사용한다는 의미입니다.
둘째는 빠르게 만들고 없앨 수 있는 실행 환경입니다. 샌드박스는 각 작업을 격리된 공간에서 실행합니다. 호텔에서 투숙객마다 방을 새로 내주듯 에이전트마다 독립된 환경을 제공하고, 일이 끝나면 정리합니다. 한 에이전트의 오류나 위험한 코드가 다른 작업과 시스템 전체로 번지는 범위를 제한하는 데도 도움이 됩니다.
셋째는 GPU를 효율적으로 깨우고 연결하는 기반 기술입니다. 소개에 언급된 탄력적 추론(elastic inference)은 요청량에 맞춰 모델 실행 자원을 늘리거나 줄이는 방식입니다. GPU 스냅샷(snapshotting)은 실행 상태를 저장했다가 복원해 준비 시간을 줄이려는 접근으로 이해할 수 있습니다. 콜드 스타트(cold start)는 쉬고 있던 실행 환경을 처음 깨울 때 생기는 지연입니다. AI 서비스의 수요가 불규칙할수록 이 준비 시간이 사용자 경험과 비용에 영향을 줍니다.
DeFlash, 추측 디코딩(speculative decoding, 작은 예측을 활용해 모델의 문장 생성을 빠르게 하는 기법), Auto Endpoints도 소개됩니다. 제공된 상세 대화가 이 부분까지 포함하지 않았기 때문에 각 기술의 성능이나 Modal만의 구현 차이는 이 자료만으로 판단하기 어렵습니다. 기능의 이름보다 중요한 것은 불규칙한 AI 요청을 빠르고 안정적으로 처리하면서 사용자가 최적화의 복잡성을 직접 떠안지 않게 하려는 방향입니다.
왜 강화학습에 10만 개의 샌드박스가 필요할 수 있을까
에피소드 소개에서 가장 눈에 띄는 숫자는 강화학습 롤아웃(RL rollout)에 10만 개의 샌드박스가 필요할 수 있다는 설명입니다. 롤아웃은 모델이 어떤 행동을 선택했을 때 이후에 무슨 일이 벌어지는지 여러 차례 실행해 보는 과정입니다.
코딩 에이전트를 훈련한다고 생각해 보겠습니다. 에이전트가 코드 수정안을 만들면 실제 저장소와 비슷한 환경에서 코드를 실행하고 테스트해야 합니다. 한 번의 답변을 채점하는 것으로는 충분하지 않습니다. 서로 다른 문제와 환경에서 많은 시도를 동시에 수행하고, 각각의 결과를 격리해 수집해야 합니다.
이때 샌드박스는 단순한 보안 기능을 넘어 학습 데이터를 생산하는 실험실이 됩니다. 대규모 강화학습에서는 모델 연산뿐 아니라 실행 환경을 얼마나 빠르게 공급하고 회수하는지가 전체 처리량을 좌우할 가능성이 있습니다.
다만 10만 개라는 수치를 모든 고객에게 필요한 일반적 규모로 읽어서는 안 됩니다. 소개문은 가능한 사례를 설명할 뿐입니다. 동시 실행 기준인지 누적 생성량인지, 필요한 시간과 자원량이 얼마인지는 제공된 자료에서 확인되지 않습니다. 투자자는 인상적인 최대 숫자보다 실제 고객 작업에서 반복되는 사용량, 자원 이용률, 단위 비용을 확인해야 합니다.
코드보다 관측 가능성이 중요해지는 이유
사람이 코드를 작성하던 때에는 문제가 생기면 작성자가 의도를 설명할 수 있었습니다. 에이전트가 코드를 만들고 실행하는 환경에서는 사람이 모든 코드를 미리 읽는 방식이 확장되기 어렵습니다. 인터뷰 소개도 관측 가능성(observability, 시스템 내부에서 무슨 일이 일어나는지 출력과 기록으로 파악하는 능력)이 코드 읽기보다 중요해질 수 있다고 짚습니다.
관측 대상은 단순한 성공과 실패에 그치지 않습니다. 어떤 코드가 실행됐는지, 어떤 도구와 네트워크에 접근했는지, 얼마만큼의 연산 자원을 썼는지, 어느 단계에서 실패했는지, 재시도는 어떻게 이뤄졌는지를 함께 봐야 합니다.
제품의 무게중심도 코드 편집 화면에서 실행 과정의 통제와 추적으로 옮겨갈 수 있습니다. 에이전트가 자율적으로 일할수록 사람은 모든 행동을 직접 수행하는 운영자보다 허용 범위를 정하고 예외를 처리하는 감독자에 가까워집니다.
빠른 실행만으로는 프로덕션 에이전트가 되지 않습니다
Latent Space는 실제 서비스에서 쓰이는 에이전트에 강한 가드레일(guardrail, 행동 범위를 제한하는 안전장치)이 필요하다고 소개합니다. 샌드박스의 의미도 이 지점과 이어집니다.
샌드박스를 빠르게 생성할 수 있다는 사실만으로 안전이 보장되지는 않습니다. 작업별로 파일 접근, 네트워크 연결, 자격 증명, 실행 시간, 비용 한도를 다르게 설정해야 합니다. 연구용 에이전트와 고객 정보를 다루는 업무 에이전트는 필요한 환경과 위험이 다릅니다. 소개문이 범용 샌드박스를 넘어 특화된 샌드박스와 강한 제한 장치를 언급하는 이유입니다.
공개된 자료만으로 Modal의 구체적인 보안 정책이나 사고 대응 수준까지 알 수는 없습니다. 다만 방향은 분명합니다. 에이전트 인프라 회사의 경쟁력은 실행 속도뿐 아니라 실패했을 때 피해 범위를 얼마나 작게 가두는가에서도 나올 가능성이 높습니다.
17개 클라우드를 묶는 전략이 주는 기회와 부담
Modal은 17개 클라우드 제공자의 자원을 묶은 용량 풀(capacity pool)을 운영하는 것으로 소개됩니다. 여러 클라우드의 자원을 하나의 서비스처럼 제공하는 슈퍼클라우드(supercloud) 전략입니다.
AI 연산 수요는 GPU의 종류, 지역, 시간대, 공급 상황에 따라 크게 달라질 수 있습니다. 여러 공급자의 자원을 하나의 인터페이스로 제공하면 고객은 개별 클라우드와 계약하고 운영하는 부담을 덜 수 있습니다. Modal은 공급처별 차이를 뒤로 숨긴 채 사용자가 필요한 실행 환경을 요청하면 적절한 자원을 공급하는 추상화 계층을 지향하는 것으로 보입니다.
그만큼 어려운 운영 문제도 안고 있습니다. 공급자마다 네트워크, 하드웨어, 장애 특성, 가격 체계가 다릅니다. 여러 공급자를 연결한다고 자동으로 동일한 품질이 만들어지지는 않습니다. 사용 편의성과 자원 조달력은 장점이 될 수 있지만, 복잡한 공급망을 안정적으로 운영하면서 충분한 마진도 남길 수 있음을 증명해야 합니다.
소개에 등장하는 사설 IPv6, RDMA(원격 직접 메모리 접근, 여러 서버가 낮은 지연으로 데이터를 주고받는 기술), 네트워크형 샌드박스, 다중 노드 학습을 보면 Modal은 단일 컨테이너 실행을 넘어 여러 컴퓨터가 긴밀하게 협력하는 작업까지 다루려 합니다. 다만 기능의 존재와 대규모 고객 환경에서의 안정성은 별개의 문제입니다. 실제 이용 사례와 운영 지표를 따로 봐야 합니다.
투자자는 기능 목록보다 반복되는 수요를 봐야 합니다
이 자료에서 제가 가장 눈여겨보는 대목은 개별 최적화 기술보다 AI가 클라우드의 구매자와 사용 방식을 동시에 바꾼다는 주장입니다.
전통적인 클라우드의 주요 사용자는 개발팀이었습니다. 에이전트가 직접 실험을 만들고 코드를 실행하며, 결과를 확인하고 다시 시도한다면 인프라 사용량을 일으키는 주체가 소프트웨어 자체로 넓어집니다. 사람 한 명이 하루에 몇 차례 실행하던 작업을 여러 에이전트가 병렬로 반복할 수도 있습니다.
이 가설이 맞다면 에이전트 인프라는 기존 개발 도구에 새 이름을 붙인 제품이 아닙니다. 실행 횟수, 환경 생성 빈도, 관측 데이터, 정책 집행의 중요성이 함께 커질 수 있습니다. 특히 연구 자동화, 모델 후속 학습, 코딩 에이전트, 오디오·영상·로봇·생명과학용 사용자 정의 모델처럼 실행 환경이 복잡한 영역에서 먼저 가치를 드러낼 가능성이 있습니다.
가장 강한 반론도 분명합니다. vLLM과 SGLang 같은 공개 소프트웨어, 기존 대형 클라우드, GPU 임대 사업자가 비슷한 기능을 제공하면 인프라 기능은 빠르게 범용화될 수 있습니다. 고객이 편리한 추상화에 추가 비용을 지불할지, 규모가 커진 뒤 직접 운영으로 전환할지도 확인해야 합니다.
Modal이 열거한 기술 범위가 넓다는 사실은 양면적입니다. 하나의 편리한 인터페이스 뒤로 복잡성을 감추는 깊은 제품이 될 수도 있고, 너무 많은 작업을 동시에 지원하다 핵심 고객과 구매 이유가 흐려질 수도 있습니다. 3억5,500만 달러의 대규모 투자 유치는 성장 가능성을 보여주는 신호일 수 있으나, 그 자체로 제품의 방어력이나 사업 성과를 입증하지는 않습니다.
창업자와 투자자에게 남는 질문
AI 애플리케이션 창업자가 이 대화에서 읽어야 할 메시지는 모델 선택만으로 제품이 완성되지 않는다는 사실입니다. 에이전트가 실제 업무를 수행한다면 실행 환경, 실패 복구, 관측, 권한 통제, 비용 한도도 제품 설계에 포함됩니다. 초기에는 외부 인프라를 활용하더라도 어떤 부분이 고객 가치와 직접 연결되는지, 어느 지점부터 자체 최적화가 필요한지 구분해야 합니다.
인프라 창업자라면 에이전트를 사람과 같은 사용자로 가정해서는 안 됩니다. 문서를 잘 쓰는 것만으로는 부족합니다. 에이전트가 호출할 수 있는 명확한 인터페이스, 예측 가능한 오류, 충분한 실행 맥락, 빠른 재시도 경로가 필요합니다. 사람에게 좋은 개발자 경험과 에이전트에게 좋은 경험은 많이 겹치지만 완전히 같지는 않습니다.
투자자는 다음 항목을 확인해야 합니다.
- 에이전트 작업이 실제로 새로운 인프라 사용량을 만들고 있는가
- 고객이 단순 GPU 임대보다 높은 비용을 지불하는 기능은 무엇인가
- 샌드박스 생성 속도와 규모가 실제 작업 성공률에 어떤 영향을 주는가
- 여러 클라우드의 자원을 묶으면서도 안정성과 마진을 유지할 수 있는가
- 오픈소스 추론 도구와 대형 클라우드가 제공하기 어려운 차별점이 남는가
- 관측과 가드레일이 부가 기능이 아니라 고객의 전환 비용과 신뢰를 만드는가
이번 Latent Space 인터뷰가 모든 답을 주지는 않습니다. 대신 AI 인프라를 보는 질문을 바꿉니다. 어떤 GPU를 얼마나 보유했는지만 따질 게 아니라, 에이전트가 스스로 코드를 쓰고 실행하는 시대에는 어떤 클라우드 구조가 필요한지 물어야 합니다.
저는 이 변화의 핵심이 속도 하나에 있다고 보지 않습니다. 에이전트가 더 많은 일을 맡을수록 실행 환경은 더 빨리 준비되어야 합니다. 동시에 더 잘 격리되고, 더 자세히 관측되며, 더 엄격하게 제한되어야 합니다. Modal이 제시하는 에이전트 경험의 의미도 여기에 있습니다.
투자자가 지켜볼 대상은 화려한 기능의 개수가 아닙니다. 에이전트의 반복 작업을 더 성공적으로 만들면서, 그 과정에서 생기는 복잡성과 위험을 고객 대신 지속적으로 감당할 수 있는가. 이 질문이 에이전트 클라우드의 독립적인 시장과 장기적인 사업 방어력을 가를 것입니다.