Agent Substrate를 검토한다면 설치 명령보다 먼저 배포할 버전과 문서의 버전을 맞추세요. Kubernetes에서 에이전트를 격리해 실행하는 도구이지만, 개발 브랜치인 main의 문서에 적힌 완료 항목이 공개 릴리스에도 그대로 들어 있다고 볼 수는 없습니다. 특히 여러 고객에게 에이전트를 제공하는 작은 SaaS 팀이라면, 실행 환경의 격리와 고객별 접근 권한을 따로 설계해야 합니다.
확인: 2026년 10월 21일 KST · 대상: Agent Substrate v0.5.0 및 확인 시점의 개발 문서 · 검증 방식: 공식 문서·릴리스 검토. 설치·실행·보안 테스트는 하지 않았습니다. 검색과 AI 도움을 활용한 자료 기반 설명이며 운영 경험이나 성능 측정 결과가 아닙니다.
무엇을 줄이려는 프로젝트인가
Agent Substrate는 에이전트를 작성하는 Python SDK가 아니라, 에이전트 같은 상태 있는 작업을 Kubernetes 위에서 실행하는 런타임입니다. 논리적인 실행 단위인 actor와 실제 실행 자원을 제공하는 worker를 나눕니다. 모델 응답이나 사람의 승인을 기다리는 actor를 계속 메모리에 두는 대신, 상태를 저장했다가 요청에 맞춰 다시 실행하는 접근입니다.
그래서 검토할 질문은 “우리도 AI를 쓰는가”보다 “오랫동안 대기하는 상태 있는 실행 단위를 많이 운영하는가”에 가깝습니다. 사용자가 몇 명 없거나 실행 대기 비용을 아직 측정하지 않았다면, 이 구조를 추가하는 편이 반드시 유리하지는 않습니다. 이 글에서는 프로젝트가 제시하는 밀도나 재개 속도 수치를 우리 서비스의 비용 절감 효과로 환산하지 않습니다.
막 등장한 프로젝트로 소개할 수도 없습니다. 2026년 5월 20일 Google Cloud의 Agent Executor 발표에서도 Substrate가 소개됐습니다. 이번에 확인한 공개 릴리스는 v0.5.0이며, 게시 시각은 10월 15일 07:22 KST입니다. 아직 1.0 이전 버전이고, 릴리스에는 호환성을 깨는 변경 사항이 별도 표시돼 있습니다.
10월 21일 05:27 KST에 저장소의 별은 약 5.7천 개로 표시됐고, GeekNews 소개에는 2포인트가 확인됐습니다. 최근 별 증가량은 확인하지 못했습니다. 관심을 받은 흔적은 있지만, 이 수치를 품질이나 운영 안전성의 증거로 사용하지는 않습니다.
같은 보안 문서인데 표시가 달랐습니다
아래 내용은 실제 공격을 재현한 결과가 아니라 문서가 표시하는 구현 상태의 차이입니다. 비교 대상은 v0.5.0에 고정된 보안 문서와, 10월 21일 05:30 KST에 확인한 개발 브랜치의 고정 커밋 문서입니다.
- Atespace의 런타임 API 권한 검사: Atespace는 리소스를 묶는 논리적 공간입니다. v0.5.0 문서는 이 경계에서 런타임 API 권한 검사를 아직 강제하지 않는다고 설명합니다. 확인 시점의 개발 문서는 OpenFGA 기반 API 권한 검사가 통합됐다고 설명하지만, 네트워크 정책과 자원 할당량은 여전히 미완료로 표시합니다.
- 저장 암호화: v0.5.0의 해당 항목에는 저장 영역이 분리돼 있지만 암호화되지 않았다는 설명이 있습니다. 개발 문서의 표시가 달라졌어도 actor별 암호화는 여전히 향후 항목입니다. 저장 영역 분리만 보고 암호화까지 완료됐다고 읽으면 안 됩니다.
- 외부 통신의 fail-closed: 정책을 적용할 수 없을 때 통신을 차단하는 성질입니다. v0.5.0은 이를 진행 중으로 표시하고 UDP 통과를 언급합니다. 개발 문서는 완료로 표시합니다.
이 차이가 뜻하는 것은 단순합니다. v0.5.0을 배포하면서 개발 문서의 완료 표시를 근거로 도입 승인을 해서는 안 됩니다. 반대로 개발 브랜치로 옮겼다는 사실만으로 안전성 검증이 끝나는 것도 아닙니다. 문서 상태표가 구현보다 늦게 갱신될 수도 있으므로, 이것만으로 특정 기능이 반드시 없다고 단정하지 않습니다. 배포 대상, 해당 버전의 코드·설정, 필요한 통제 항목과 실제 검증 결과를 함께 확인해야 합니다.
고객 A와 actor B를 연결할지는 누가 결정할까
두 문서 모두 사람에서 actor로 이어지는 인증·권한 검사, 에이전트 등록 정보, 부모·자식 에이전트의 계보 관리는 애플리케이션의 책임으로 구분합니다. 하나의 actor 내부에서 여러 고객을 나누는 것도 런타임의 보안 경계로 취급하지 않습니다.
예를 들어 고객 A가 로그인한 뒤 다른 고객에게 속한 actor B의 식별자를 요청에 넣었다고 가정해 보겠습니다. 런타임에 격리 기능이 있다는 이유로 그 요청을 바로 전달해서는 안 됩니다. SaaS의 API가 로그인한 사용자와 소속 고객사, 요청한 actor의 관계를 확인하고 허용 여부를 결정해야 합니다. 이는 설명을 위한 가상 설계 사례이며, 특정 배포에서 접근이 허용되거나 차단됐다는 실험 결과가 아닙니다.
팀의 검토 문서에는 “Substrate가 보안을 담당한다” 대신 책임을 나눠 적는 편이 좋습니다. 고객별 actor 연결과 접근 허용은 애플리케이션, 실행 환경의 격리는 선택한 런타임 설정, 외부 서비스의 데이터 접근은 그 서비스의 권한 체계처럼 구체화하는 것입니다. 실제 경계는 사용하는 구성에 맞춰 확인해야 합니다.
설치 전에 적어 둘 세 가지 검증 질문
아래는 아직 실행하지 않은 테스트 계획입니다. 실제 고객 정보나 운영 자격 증명 대신 합성 사용자와 테스트 대상만 사용하는 별도 환경을 전제로 합니다.
- 다른 고객의 actor를 요청하면? 사용자 A의 요청에서 actor 식별자를 다른 고객의 것으로 바꿉니다. 실행에 도달하기 전에 거부되는 것을 요구 조건으로 정하고, 거부한 계층과 로그를 확인할 계획을 세웁니다.
- 대기 중에 권한을 회수하면? actor가 중지된 동안 사용자의 접근 권한을 제거한 뒤 다시 요청합니다. 과거에 시작할 수 있었다는 이유만으로 다시 실행되지 않도록, 재개 요청 시점에 어디서 권한을 확인할지 정합니다.
- 허용하지 않은 외부 목적지로 나가면? 허용 목록 밖의 테스트 목적지와 정책 적용 실패 상황을 각각 다룹니다. HTTP 요청 하나가 막힌 결과를 모든 프로토콜의 차단으로 확대하지 말고, 실제로 허용할 통신 범위를 따로 확인합니다.
이 세 가지가 통과해도 전체 보안 검증을 대신하지는 않습니다. 다만 문서의 “지원” 표시를 보고 넘어가기보다, 우리 서비스에서 반드시 거부돼야 할 요청을 먼저 정의하는 출발점이 됩니다.
작은 팀이라면 도입보다 보류 조건부터
이미 Kubernetes를 운영하며 다수의 상태 있는 에이전트가 오래 대기하는 문제를 겪는 팀이라면 제한된 파일럿을 검토할 만합니다. 반면 내부 작업 몇 개를 돌리는 수준이라면 기존 실행 환경을 유지하고, 동시 실행 수·대기 시간·자원 점유부터 관찰하는 쪽을 우선 권합니다. 일반 백그라운드 작업이면 기존 작업 큐로 충분한지도 따져볼 수 있지만, 작업 큐 자체가 신뢰할 수 없는 코드의 격리를 대신하는 것은 아닙니다.
Apache-2.0 라이선스는 인프라 운영 비용이 없다는 뜻이 아닙니다. v0.5.0 개발용 시작 안내에도 Go·kubectl·Docker와 로컬 Kubernetes 환경, PostgreSQL·rustfs 같은 구성이 등장합니다. Kubernetes와 실행 노드, 상태 저장 구성, 관측과 업그레이드 작업을 맡을 사람이 필요합니다. 이 글은 특정 클라우드 요금이나 최소 운영 사양을 검증하지 않았으므로 비용 절감액을 제시하지 않습니다.
지금 할 일은 설치가 아니라 버전별 책임표 한 장을 만드는 것입니다. 배포 후보 태그를 고정하고, 같은 태그의 보안 문서를 열어 필요한 항목을 확인한 다음, 애플리케이션이 맡을 권한 검사와 미완료 항목을 적으세요. 그 공백을 설명할 수 없으면 운영 고객을 넣는 결정을 보류하는 것이 이 글의 권고입니다.
댓글
댓글 쓰기