[심층분석] AI 에이전트 수백만 개를 한 클러스터에 태운다고? 구글 엔지니어들이 공개한 Agent Substrate 뜯어보기

들어가며: 에이전트 시대의 새로운 병목

요즘 AI 에이전트 이야기 안 나오는 날이 없죠. 코딩 에이전트가 레포를 통째로 고치고, 리서치 에이전트가 브라우저를 돌리면서 자료를 모으고요. 그런데 이런 에이전트를 실제 서비스로 굴려본 분들은 공통적으로 한 가지 벽에 부딪혀요. 바로 '에이전트를 어디서, 어떻게 안전하게 실행할 것인가'라는 문제거든요.

생각해 보세요. 에이전트는 LLM이 생성한 코드를 실행하고, 셸 명령을 돌리고, 파일을 만들고 지워요. 그러니까 신뢰할 수 없는 코드를 실행하는 셈이에요. 그런 걸 내 서버에서 그냥 돌리면 큰일 나겠죠. 그래서 다들 샌드박스(sandbox)를 써요. 샌드박스라는 건, 쉽게 말해서 놀이터의 모래놀이통 같은 거예요. 그 안에서 뭘 하든 바깥으로 튀어나오지 못하게 격리된 공간이죠.

문제는 이 샌드박스가 비싸다는 거예요. 사용자 한 명당 컨테이너 하나씩 띄우면, 사용자가 만 명이면 컨테이너 만 개가 필요해요. 그런데 에이전트의 특성상 대부분의 시간은 LLM 응답을 기다리면서 '멍때리고' 있거든요. CPU도 안 쓰고 그냥 메모리만 잡아먹으면서요. 이건 마치 손님이 커피 한 잔 시켜놓고 하루 종일 자리만 차지하는 카페 같은 상황이에요.

이 문제를 정면으로 겨냥한 프로젝트가 나왔어요. 구글 내부 엔지니어들이 공개한 Agent Substrate예요. 공식 구글 제품은 아니라고 명시되어 있지만, 구글의 gVisor와 쿠버네티스 경험이 그대로 녹아 있는 프로젝트라 눈여겨볼 만해요.

Agent Substrate가 뭐냐면

한 줄로 요약하면 'AI 에이전트를 수백만 개 단위로 안전하게 실행하기 위한 런타임'이에요. 런타임이라는 건, 프로그램이 실제로 돌아가는 환경을 뜻해요. 자바 프로그램이 JVM 위에서 돌아가듯, 에이전트가 Agent Substrate 위에서 돌아가는 거죠.

README에서 밝히는 숫자가 꽤 공격적이에요.

• 일반 컨테이너 런타임 대비 10배 높은 밀도
• 샌드박스 재개(resume)에 500ms 미만
• 초당 500회 이상의 일시정지/재개 처리
• microVM과 gVisor 등 여러 샌드박스 기술을 동일한 방식으로 관리

여기서 중요한 건, 이 프로젝트가 '에이전트를 만드는 SDK'가 아니라는 점이에요. LangChain이나 Google ADK처럼 에이전트 로직을 짜는 도구가 아니에요. 이미 만들어진 에이전트를 '대규모로 돌리는 인프라'예요. 비유하자면, 요리 레시피를 알려주는 게 아니라 식당 주방 시스템을 통째로 제공하는 셈이죠. README에서도 스스로를 'low-opinion system'이라고 부르는데, 특정 프레임워크나 언어를 강요하지 않고 '리눅스에서 돌아가는 프로세스라면 뭐든 올려라'는 태도예요.

핵심 아이디어: 액터와 워커

Agent Substrate의 설계를 이해하려면 두 단어만 기억하면 돼요. 액터(actor)와 워커(worker)예요.

• 액터: 실행되어야 하는 애플리케이션이에요. 사용자 A의 코딩 에이전트, 사용자 B의 리서치 에이전트 같은 것들이죠.
• 워커: 실제로 코드를 실행할 준비가 된 실행 슬롯이에요. 쿠버네티스 Pod 위에서 돌아가는 샌드박스라고 보면 돼요.

핵심은 '액터는 많고, 워커는 적다'는 거예요. 액터가 백만 개여도 워커는 만 개일 수 있어요. 어떻게 이게 가능하냐면, 아까 말했던 '에이전트는 대부분 멍때리고 있다'는 성질을 이용하는 거예요.

호텔 비유가 딱이에요. 회원이 백만 명인 호텔이 객실을 백만 개 갖고 있을 필요는 없잖아요. 실제로 동시에 투숙하는 사람은 만 명 정도니까 만 개면 충분하죠. Agent Substrate는 호텔 프런트 역할을 해요. 액터가 '지금 일해야 해'라고 하면 빈 워커를 배정하고, 액터가 LLM 응답을 기다리는 동안엔 상태를 저장(suspend)해두고 워커를 다른 액터에게 넘겨요. 응답이 오면 다시 상태를 복원(resume)해서 이어서 일하게 하고요.

이걸 업계에서는 멀티플렉싱(multiplexing)이라고 불러요. 하나의 자원을 여러 사용자가 번갈아 쓰는 거죠. 근데 여기서 진짜 어려운 부분이 'suspend/resume이 얼마나 빠르냐'예요. 복원에 10초씩 걸리면 사용자가 매번 기다려야 하니까 실용성이 없거든요. 그래서 500ms 미만이라는 숫자가 의미 있는 거예요. 사람이 체감하기 애매한 수준까지 끌어내렸다는 뜻이니까요.

세 가지 기능 축

README를 보면 Agent Substrate가 제공하는 기능을 세 가지로 정리하고 있어요.

1. 액터 생명주기 관리

생성/삭제, 일시정지/재개를 담당해요. 에이전트 하나가 태어나서 일하고, 쉬고, 다시 일하다가, 끝나면 정리되는 전 과정이죠. 이걸 API로 일관되게 제공한다는 게 포인트예요. 샌드박스 백엔드가 gVisor든 microVM이든 상관없이 같은 명령으로 다룰 수 있어요.

2. 실시간 스케줄링

어떤 액터를 어떤 워커에 붙일지 실시간으로 결정해요. 쿠버네티스에도 스케줄러가 있지만, 그건 Pod 단위로 움직이고 수 초에서 수십 초가 걸려요. Agent Substrate는 그 위에 한 층을 더 얹어서, 이미 준비된 워커 풀에 액터를 밀리초 단위로 배정하는 거예요. 쿠버네티스가 '건물을 짓는' 역할이라면, Agent Substrate는 '이미 지어진 건물에 손님을 빠르게 안내하는' 역할이에요.

3. 트래픽 라우팅

외부에서 들어온 요청을 해당 액터가 지금 어느 워커에 있는지 찾아서 연결해줘요. 액터가 워커를 옮겨 다니니까 이 라우팅이 없으면 요청이 길을 잃겠죠. 택배 기사가 이사 간 사람의 새 주소를 자동으로 알아내는 것과 비슷해요.

보안: 제로 트러스트와 두 가지 샌드박스

'secure-by-default'라는 표현이 눈에 띄어요. 기본값이 안전하다는 뜻이에요. 보안 설정을 따로 켜지 않아도 처음부터 격리된 상태로 돌아간다는 거죠.

여기서 두 가지 샌드박스 기술을 지원한다고 했는데, 각각 뭔지 짚고 갈게요.

gVisor는 구글이 만든 애플리케이션 커널이에요. 이게 뭐냐면, 컨테이너 안의 프로그램이 리눅스 커널에 직접 시스템 콜(system call, 프로그램이 OS에게 '파일 열어줘', '네트워크 연결해줘' 하고 부탁하는 것)을 날리는 대신, 중간에 가짜 커널이 끼어들어서 대신 처리해주는 방식이에요. 진짜 커널을 직접 건드리지 못하게 하니까 커널 취약점을 통한 탈출이 훨씬 어려워져요. 대신 시스템 콜이 많은 워크로드에서는 좀 느려질 수 있어요.

microVM은 Firecracker 같은 기술이에요. 아주 작고 가벼운 가상머신을 띄우는 건데, 커널 자체를 통째로 분리해요. 가장 강력한 격리지만 gVisor보다 시작 시간과 메모리 오버헤드가 조금 더 커요.

비유하자면 gVisor는 '통역사를 사이에 두고 대화하는 것'이고, microVM은 '아예 다른 방에 넣어놓는 것'이에요. Agent Substrate는 둘 중 뭘 쓰든 같은 API로 생명주기를 관리할 수 있게 추상화해놨어요. 워크로드 성격에 따라 골라 쓸 수 있는 거죠.

네트워크 격리도 마찬가지예요. 제로 트러스트라는 건, '같은 클러스터 안에 있으니까 믿어도 되겠지'라는 가정을 아예 버리는 거예요. 액터 하나가 뚫려도 옆 액터나 컨트롤 플레인으로 못 넘어가게 막는 거죠. 에이전트가 프롬프트 인젝션에 당해서 이상한 명령을 실행하더라도 피해 범위를 그 샌드박스 하나로 가둬두는 게 목표예요.

왜 쿠버네티스 위에 얹었을까

Agent Substrate는 쿠버네티스를 버리지 않고 그 위에 올라탔어요. 이건 꽤 현실적인 선택이에요.

쿠버네티스는 노드 관리, 오토스케일링, 네트워킹, 모니터링 같은 인프라 문제를 이미 잘 풀어놨어요. 이걸 처음부터 다시 만들 이유가 없죠. 대신 쿠버네티스가 약한 부분, 그러니까 '수백만 개 단위의 초경량 워크로드를 밀리초 단위로 스케줄링하는 것'만 Agent Substrate가 담당해요. 워커 Pod의 개수는 쿠버네티스 오토스케일러가 조절하고, 그 Pod 안에서 액터를 갈아 끼우는 건 Agent Substrate가 하는 식이에요.

레포 구조를 보면 Go로 작성되어 있고, cmd, pkg, internal, manifests 같은 전형적인 쿠버네티스 생태계 프로젝트 구조를 따르고 있어요. golangci 설정에 kube-api-linter까지 붙어 있는 걸 보면, 쿠버네티스 API 컨벤션을 꽤 엄격하게 지키려는 의도가 보여요. 아마 CRD(Custom Resource Definition, 쿠버네티스에 내가 정의한 리소스 타입을 추가하는 기능)와 컨트롤러 패턴으로 구현됐을 가능성이 높아요. 즉 액터를 쿠버네티스 리소스처럼 선언하고, 컨트롤러가 그 상태를 맞춰주는 방식이죠.

재미있는 건 레포에 AGENTS.md와 CLAUDE.md, 그리고 .agents/skills 디렉터리가 있다는 거예요. 에이전트를 위한 인프라를 만들면서 개발 자체도 코딩 에이전트와 함께 하고 있다는 뜻이에요. 요즘 오픈소스 프로젝트의 트렌드를 잘 보여주는 부분이죠.

업계 맥락: 경쟁 기술과 비교

이 영역은 이미 꽤 붐비고 있어요. 각각 어떻게 다른지 비유로 풀어볼게요.

E2B, Modal 같은 SaaS형 샌드박스

API 호출 한 번으로 샌드박스를 띄워주는 서비스예요. 개발자 입장에서 제일 편해요. 마치 배달 앱으로 음식 시키는 것과 같죠. 대신 데이터가 외부로 나가고, 규모가 커지면 비용이 부담되고, 커스터마이징에 한계가 있어요. Agent Substrate는 이런 서비스의 '뒷단'을 직접 소유하고 싶은 팀을 위한 거예요. 주방을 직접 차리는 거죠.

Firecracker 단독 사용

AWS Lambda의 기반 기술이기도 한 Firecracker는 훌륭한 microVM이에요. 하지만 이건 '엔진'이지 '자동차'가 아니에요. 스케줄링, 라우팅, 생명주기 관리는 직접 만들어야 해요. Agent Substrate는 그 자동차 부분을 제공하려는 거예요.

Knative, KEDA 같은 쿠버네티스 서버리스

'요청이 없으면 0으로 줄인다'는 컨셉은 비슷해요. 하지만 이들은 Pod 단위로 스케일하기 때문에 콜드 스타트가 수 초 단위예요. 그리고 상태를 저장하고 복원하는 개념이 없어요. 에이전트는 대화 컨텍스트, 열어둔 파일, 실행 중인 프로세스 같은 상태가 있잖아요. Agent Substrate의 suspend/resume은 이 상태를 통째로 얼렸다 녹이는 거라 근본적으로 달라요.

Cloudflare Durable Objects

'액터 모델'이라는 관점에서는 가장 비슷해요. 하나의 ID에 하나의 상태 있는 인스턴스를 붙이고, 안 쓰면 잠재우는 방식이죠. 다만 Durable Objects는 JavaScript/WASM 런타임에 묶여 있어요. Agent Substrate는 임의의 리눅스 프로세스를 돌릴 수 있고, 내 쿠버네티스 클러스터에서 굴릴 수 있다는 게 차이예요.

정리하면 Agent Substrate의 포지션은 이래요. 'SaaS 샌드박스의 편의성은 포기하더라도, 자체 인프라에서 수백만 에이전트를 안전하고 싸게 돌리고 싶은 플랫폼 팀'을 겨냥한 거죠.

한국 개발자에게 주는 시사점

이런 팀이라면 눈여겨보세요

시나리오 1: AI 코딩 도구나 데이터 분석 에이전트를 서비스하는 스타트업

사용자마다 코드 실행 환경을 줘야 하는데, 지금 외부 샌드박스 서비스 비용이 매달 눈에 띄게 늘고 있다면요. 사용자 수천 명 수준을 넘어가면 자체 샌드박스 인프라의 손익분기점이 와요. 그때 처음부터 만들지 말고 Agent Substrate 같은 오픈소스를 기반으로 시작하는 게 현실적이에요.

시나리오 2: 대기업 내부 플랫폼 팀

금융, 공공 쪽은 데이터를 외부 SaaS로 못 보내는 경우가 많잖아요. 온프레미스 쿠버네티스 위에서 사내 에이전트를 안전하게 돌려야 한다면, gVisor 기반 격리와 제로 트러스트 네트워크가 기본으로 들어간 이 프로젝트가 좋은 출발점이 될 수 있어요.

시나리오 3: 교육 플랫폼

수강생마다 실습 환경을 띄워주는 서비스는 에이전트와 사용 패턴이 똑같아요. 대부분 시간은 강의 보느라 환경이 놀고 있거든요. suspend/resume 모델이 딱 맞는 사례죠.

도입 전에 고려할 점

솔직하게 말씀드릴게요. 이건 아직 초기 단계 프로젝트예요.

• 공식 구글 제품이 아니에요. 취약점 보상 프로그램 대상도 아니고, 지원이 보장되지 않아요. 프로덕션에 올리려면 직접 코드를 읽고 책임질 수 있어야 해요.
• 쿠버네티스 숙련도가 필수예요. CRD, 컨트롤러, 네트워크 정책 같은 개념이 낯설다면 진입 장벽이 높아요.
• gVisor나 microVM은 커널 기능에 의존해요. 국내 클라우드나 온프레미스 환경에서 중첩 가상화(nested virtualization) 지원이 되는지 먼저 확인해야 해요. 이게 안 되면 microVM 백엔드는 못 써요.
• 벤치마크 숫자는 구글 환경 기준일 거예요. 10배 밀도, 500ms 재개 같은 수치는 워크로드와 하드웨어에 따라 크게 달라져요. 레포에 benchmarking 디렉터리가 있으니 직접 돌려보는 걸 추천해요.

학습 로드맵

주니어 분들을 위해 순서를 제안해 볼게요.

1. 컨테이너와 격리의 기본: 도커가 어떻게 프로세스를 격리하는지, 네임스페이스와 cgroup이 뭔지부터요. 여기가 흔들리면 뒤가 다 안 보여요.
2. gVisor 직접 써보기: runsc를 설치해서 도커 런타임으로 바꿔보는 건 30분이면 돼요. '시스템 콜을 가로챈다'는 게 뭔지 몸으로 느껴보세요.
3. 쿠버네티스 Operator 패턴: kubebuilder 튜토리얼 하나만 따라 해도 Agent Substrate 코드가 훨씬 잘 읽혀요.
4. Agent Substrate demos 디렉터리: 레포에 데모가 있으니 로컬 클러스터(kind나 minikube)에 올려보세요.
5. 액터 모델 이론: Erlang이나 Akka의 액터 모델을 가볍게 훑어보면 '왜 이런 설계를 했는지'가 이해돼요.

마무리: 에이전트 인프라 전쟁의 시작

지금까지 AI 인프라 경쟁은 주로 '모델을 어떻게 빠르게 서빙하느냐'에 집중되어 있었어요. GPU 스케줄링, 추론 최적화 같은 것들이죠. 그런데 에이전트 시대에는 새로운 계층이 필요해요. 모델이 뱉은 코드를 '실행하는' 계층이요. Agent Substrate는 이 계층을 오픈소스로 표준화하려는 시도 중 하나예요.

구글이 gVisor를 오픈소스로 풀었을 때 그게 Cloud Run의 기반이 됐던 것처럼, 이 프로젝트도 언젠가 구글의 에이전트 플랫폼 뒤에 있는 기술일 가능성이 있어요. 공식 제품이 아니라고 선을 그었지만, 그래서 오히려 더 솔직한 실험 결과를 볼 수 있는 기회이기도 하고요.

몇 가지 질문을 던지면서 마칠게요.

• 여러분 팀은 지금 에이전트나 사용자 코드를 어디서 실행하고 있나요? 외부 SaaS인가요, 자체 컨테이너인가요?
• 사용자당 샌드박스 비용, 계산해 보신 적 있나요? 놀고 있는 시간이 몇 퍼센트인지도요.
• gVisor와 microVM 중 어느 쪽을 선택하시겠어요? 격리 강도와 성능 사이에서 여러분의 기준은 뭔가요?