Agent Substrate가 줄이는 대기 비용, 복원 조건부터 확인한다

에이전트가 모델 응답이나 다음 사용자 요청을 기다리는 동안에도, 전용 실행 환경의 메모리는 계속 자리를 차지한다. 세션 수가 늘수록 실제 계산보다 대기 상태를 유지하는 비용이 커질 수 있다. Agent Substrate에서 내가 주목한 부분은 에이전트를 더 빨리 실행하는 기술보다, 쉬고 있는 실행 환경을 어디에 보관할 것인가라는 질문이다.

GeekNews에는 2026년 10월 18일 오전 9시 30분에 등록됐다. 10월 19일 확인한 최신 릴리스는 v0.5.0이며, 공개 시각은 한국 기준 10월 15일 오전 7시 22분이다. 당일 출시 소식과는 구분해야 한다. 아래 설명은 확인 시점의 main 브랜치 문서를 함께 읽은 분석이다. 프로젝트는 Apache-2.0 라이선스이며, 1.0 이전에는 하위 호환성을 보장하지 않는다고 명시한다. 프로젝트 안내

에이전트의 수명과 Pod의 수명을 나눈다

Kubernetes의 Pod는 컨테이너를 배치하고 실행하는 단위다. 에이전트마다 Pod 하나를 계속 유지하면, 일을 하지 않는 시간에도 실행 환경이 남는다. 반대로 매번 새로 시작하면 프로세스 초기화와 작업 상태 복구가 필요하다.

Substrate는 상태를 가진 작업 인스턴스를 actor, 이를 실행할 준비가 된 Pod를 worker라고 부른다. 여러 actor를 더 작은 worker 풀에 배정하고, 중단할 때 메모리와 파일 상태를 스냅샷으로 저장한다. 다음 요청이 들어오면 준비된 worker에 상태를 복원해 요청을 전달하는 구조다. 스냅샷은 나중에 복구할 수 있도록 실행 상태를 저장한 자료다. 아키텍처 설명

Kubernetes는 worker와 기반 자원을 관리하고, actor의 잦은 배정과 상태 변경은 별도 제어 계층과 PostgreSQL이 맡는다. 따라서 Pod를 덜 만들면서도 actor는 많이 등록할 수 있다. 다만 모델 추론 자체를 줄이는 기능은 아니다. 애플리케이션이 외부 모델을 기다리는 경우라면, 그 대기 환경을 유지하는 비용이 검토 대상이다.

줄어든 메모리 비용은 저장과 복원 비용으로 옮겨 간다

프로젝트 README는 약 250개 actor를 8개 Pod에 번갈아 실행하는 데모와 400ms 미만의 복원 성능을 제시한다. 이는 프로젝트가 제시한 사례와 성능 주장이다. 이 글에서는 설치나 벤치마크를 실행하지 않았으며, 우리 작업에서도 같은 지연이나 절감률이 나온다는 뜻으로 읽지 않았다. 성능 소개

메모리를 회수하려면 상태를 저장해야 한다. 상태가 크거나 중단과 복원을 자주 반복하면 저장 공간, 전송량, 복원 처리의 비용이 커질 수 있다. 준비된 worker와 제어 계층을 유지하는 비용도 남는다. 전체 actor 수만으로 비용 절감률을 계산할 수 없는 이유다.

특히 평소에는 적게 실행되다가 특정 시각에 요청이 몰리면, 작은 worker 풀은 대기열을 만든다. 나는 평균 활성 비율과 함께 동시에 깨어나는 최대 개수, 복원 뒤 첫 작업까지 걸린 시간의 상위 지연을 보겠다. 공식 벤치마크 안내도 복원 RPC의 시간, 복원 후 첫 실행까지의 시간, 실제 작업 시간을 별도 지표로 다룬다. RPC는 다른 프로세스의 기능을 호출하는 통신이다.

프로세스 복원과 업무 복구는 다르다

아키텍처 문서의 중단 과정은 명시적인 SuspendActor 호출로 시작한다. 따라서 모델을 기다린다는 이유만으로 애플리케이션의 어느 지점에서나 자동으로 멈춰도 된다고 가정하면 안 된다. 상위 실행 시스템이 중단할 시점과 다시 깨울 경로를 설계해야 한다. actor 생명주기

메모리와 파일을 보존하는 것만으로 외부 시스템의 상태까지 되돌릴 수는 없다. 가령 결제 API가 요청을 처리한 직후 응답을 받기 전에 연결이 끊기는 상황을 가정해 보자. 스냅샷으로 프로세스가 돌아와도 결제가 실행됐는지는 별도로 확인해야 한다. 중복 호출 방지 키와 처리 결과 조회 같은 업무 복구 방식이 여전히 필요하다는 것이 내 판단이다.

검증에서는 살아 있는 HTTP 요청, 연결이 끊긴 뒤 재시도, 오래 기다리는 스트림을 따로 다루겠다. 저장된 파일이 돌아오는지와 외부 요청이 올바르게 이어지는지는 서로 다른 항목이다. 게다가 아키텍처 문서 자체가 아직 구현되지 않은 설계를 포함한다고 경고한다. 복원 범위를 문서의 포괄적인 표현만으로 확정하지 않고, 선택한 릴리스와 샌드박스에서 확인해야 한다.

격리의 이점에는 통신과 권한의 제약이 붙는다

일반 Linux 컨테이너만으로 실행하는 방식은 지원하지 않는다. gVisor 또는 Cloud Hypervisor 기반 마이크로VM을 사용한다. gVisor는 애플리케이션의 시스템 호출을 별도 계층에서 처리하며, 마이크로VM은 가벼운 가상머신으로 실행 환경을 나눈다. 기존 OCI 컨테이너 이미지를 쓴다고 해서 커널 기능과 네트워크 동작까지 기존 서버와 같아지는 것은 아니다. 실행 경계

10월 19일 확인한 외부 통신 문서는 정책이 허용한 HTTP/1.1·HTTP/2 요청을 지원하고, WebSocket과 일반 TCP 연결, DNS 이외의 UDP를 차단한다고 설명한다. 따라서 WebSocket 기반 도구나 데이터베이스에 직접 연결하는 클라이언트는 그대로 옮길 수 있다고 기대하기 어렵다. 모델 API뿐 아니라 패키지 다운로드, 원격 도구, 관측 데이터 전송 경로까지 목록을 만들어야 한다.

자격 증명을 샌드박스 밖에 두고 게이트웨이에서 허용된 요청에 주입하는 설계도 눈에 띈다. 그러나 키를 읽을 수 없다는 사실과 그 권한으로 잘못된 요청을 보낼 수 없다는 사실은 다르다. 허용할 목적지와 작업 범위를 정해야 한다. 보안 문서는 사용자와 actor 사이의 인증·인가를 상위 애플리케이션의 책임으로 두며, 저장소 암호화나 일부 인가 기능 등에는 미완료 상태를 표시한다. 문서마다 구현 시점이 다를 수 있어 실제 배포 버전에서 확인할 항목이다.

작은 실험은 대기 시간이 긴 작업에서 시작한다

나는 Kubernetes를 이미 운영하고, 독립된 작업 환경이 많이 필요하며, 대기 시간이 긴 서비스부터 검토하겠다. PostgreSQL과 스냅샷 저장소, 게이트웨이까지 함께 운영할 이유가 있어야 한다. 다음은 도입 효과가 아니라 비교할 출발점이다.

작업의 성격	먼저 비교할 선택
세션이 많고 긴 대기 사이에 짧게 실행된다	상태 복원과 worker 공유를 작은 풀에서 검증한다
상태를 외부 DB에 쉽게 보관할 수 있다	작업 큐와 일회성 실행으로 충분한지 비교한다
계산이 계속되거나 동시 실행 비율이 높다	기존 전용 실행 환경의 비용과 비교한다

대표 작업 하나에서 상태 크기와 중단 빈도, 동시 활성 수를 고정해 비교하겠다. 복원 지연뿐 아니라 요청 누락·중복, 저장 비용, worker 부족 시 대기 시간도 기록한다. 인프라 비용이 줄어도 사용자가 기다리는 시간이 늘거나 복구가 불명확해지면 전환 근거가 약하다.

Substrate는 상태를 가진 실행 환경을 계속 켜 둘지, 필요할 때 복원할지 선택하는 범위를 넓힌다. 내 판단 기준은 등록 가능한 에이전트의 최대 수보다 구체적이다. 어떤 상태를 얼마 동안 내려놓을 수 있고, 다시 깨웠을 때 어떤 작업까지 안전하게 이어 갈 수 있는가. 그 답이 있는 워크로드에서 자원 절감의 의미도 확인할 수 있다.

참고 자료

• Agent Substrate — README
• Agent Substrate v0.5.0 릴리스
• Agent Substrate Architecture
• Benchmarking 안내
• 지원하는 외부 통신
• Substrate Security