Agent Bucket: 조 단위 Agent 네이티브 스토리지 버킷

AI Agent가 우후죽순처럼 쏟아져 나오는 오늘날, 개발자들은 전례 없는 속도로 상상력이 넘치는 지능형 애플리케이션을 구축하고 있습니다. 코드를 작성하는 데 도움을 주는 프로그래밍 도우미부터, 한 문장으로 영화 한 편을 생성하는 창작 도구, 그리고 항상 대기 중인 개인 지능형 비서에 이르기까지, Agent는 우리가 디지털 세계와 상호 작용하는 방식을 재구성하고 있습니다. 이러한 흐름 뒤에는 서버리스 아키텍처(예: Lambda), 대규모 언어 모델(LLM) 및 클라우드 스토리지(예: S3, TOS)를 활용하고 Vibe Coding과 결합하여 누구나 30분 안에 자신만의 AI Agent를 빠르게 구축할 수 있다는 공통된 인식이 점점 더 명확해지고 있습니다.

"사용 가능"에서 "유용"으로 나아가기 위해 Agent 개발자는 "장난감"에서 "생산 수준 애플리케이션"으로 도약하는 데 여전히 어려움을 겪고 있습니다. 비즈니스가 대규모 사용자를 향해 나아감에 따라 개발자는 매우 복잡한 문제에 직면해야 합니다. 즉, 대규모 최종 사용자를 위해 객체 스토리지에 완벽한 스토리지 솔루션을 구축하는 방법입니다. 대부분의 개발자에게 이는 기술적 장벽일 뿐만 아니라 Agent의 대규모 배포를 가로막는 장애물이기도 합니다. Agent Bucket은 AI 네이티브 스토리지 설계를 통해 다중 테넌트 시스템 구축 프로세스를 완전히 간소화하고 보다 사용자 친화적인 Agent 기능을 제공하는 것을 목표로 합니다.

억만 명의 사용자가 몰려들면 기존 객체 스토리지는 "충분하지 않습니다"

당신이 개발한 AIGC 애플리케이션이 폭발적인 인기를 얻었다고 상상해 보세요. 각 사용자는 대량의 이미지, 비디오 및 임시 파일을 생성하고 저장합니다. 개발자로서 당신은 자연스럽게 S3 및 TOS와 같이 성숙하고 확장 가능한 객체 스토리지 서비스를 선택할 것입니다. 하지만 문제가 있습니다. 어떻게 대규모 사용자를 위해 데이터를 관리할 수 있을까요?

2022년 S3 블로그 《Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3》에서는 "각 테넌트가 독립적인 S3 버킷 사용" 및 "접두사를 기반으로 격리된 공유 S3 버킷"의 두 가지 방식을 설명합니다.

각 사용자에 대해 독립적인 "버킷"을 생성합니다. 이는 사용자 수가 적을 때는 가능하지만 사용자 수가 수만, 수백만 명으로 증가하면 버킷 수가 빠르게 폭발적으로 증가하여 관리 비용과 리소스 제한이 감당하기 어려워집니다. S3는 전체 리전에 대해 총 10000개의 버킷 할당량을 제공하지만 인기 있는 AI 기능의 경우 1만 개는 턱없이 부족합니다.

AWS S3 Bucket-Per-Tenant Model

동일한 버킷 내에서 "접두사"로 사용자를 구분합니다. 이는 주류 솔루션이 되었습니다. 예를 들어 사용자 A의 파일은 모두 user-a/로 시작하고 사용자 B의 파일은 user-b/로 시작합니다. 마치 컴퓨터에서 폴더로 파일을 관리하는 것과 같습니다. 그러나 객체 스토리지에는 네이티브 폴더가 존재하지 않으며 이 솔루션은 "K-V" 스토리지 시스템에서 "공통 접두사"(Prefix)를 통해 다중 테넌트를 구분합니다.

AWS S3 Object Key Prefix-Per-Tenant Model

이러한 "버킷" 또는 "접두사" 기반 솔루션은 지난 10년 동안 널리 사용되었습니다. 하지만 다음과 같은 문제가 있습니다.

다중 테넌트 격리: 모든 사용자의 데이터가 동일한 버킷에 혼합되어 있어 한 사용자의 비정상적인 고빈도 액세스가 다른 모든 사용자에게 영향을 미쳐 "이웃 효과"를 발생시킬 수 있습니다. 성능 격리, 장애 격리는 불가능합니다.
권한 관리: 복잡한 권한 정책(IAM Policy)은 유지 관리가 어렵고 구성 오류가 발생하기 쉬워 사용자 데이터가 예기치 않게 액세스될 수 있습니다. 특히 다른 클라우드 서비스와 상호 작용해야 하는 경우 위험 노출이 더 큽니다.
비용 명확성: 각 사용자가 실제로 얼마나 많은 스토리지 공간을 소비하고 얼마나 많은 트래픽 비용을 발생시켰는지 정확히 알기가 어렵습니다. 사용량에 따라 유료 사용자에게 요금을 청구하려는 경우 청구 및 계량이 불분명해집니다.왜 이러한 기본적인 요구 사항에 대해 Agent 개발자들이 객체 스토리지에서 다소 "무겁게" 구현할까요? 그 이유는 현재 클라우드 네이티브 아키텍처에서 S3와 같은 "객체 스토리지"와 전통적인 "파일 시스템" 사이에 거대한 공백이 존재하기 때문입니다. 객체 스토리지(S3/TOS)의 본질은 "평면화"이며, 설계 의도는 대량 데이터를 간단하게 저장하는 것입니다. 마치 거대한 창고와 같아서 용량은 거의 무한하지만 논리 구조는 매우 단순합니다. 객체 스토리지는 기본적으로 고급 디렉터리 관리, 세분화된 메타데이터 제어 및 진정한 테넌트 인식을 제공하지 않습니다. 개발자가 "평면적인" S3에서 하드 코딩된 접두사 방식을 통해 "입체적인" 멀티 테넌트 파일 시스템을 시뮬레이션하려고 할 때, 우리는 실제로 "정적인 KV 스토리지"를 사용하여 "디렉터리 의미, 강력한 격리"를 가진 Agent 애플리케이션의 파일 액세스 방식을 처리하고 있습니다. 즉, Agent는 파일을 관리하고 멀티 테넌트 권한 및 격리를 해결하기 위해 추가 토큰을 소비해야 합니다. 이러한 추가 토큰 소비는 S3에서 정의한 간단한 스토리지 서비스가 Agent에게 충분히 간단하지 않다는 것을 나타냅니다.

2025년 S3 블로그 《Design patterns for multi-tenant access control on Amazon S3》에서는 S3 Access Point를 추가로 설명합니다. 이는 여러 가상 네트워크 액세스 포인트를 생성하고 각 액세스 포인트에 대해 사용자 정의된 액세스 포인트 정책을 구성하여 네트워크 스케줄링 수준에서 멀티 테넌트 시나리오에 대한 몇 가지 솔루션을 제공할 수 있음을 의미합니다.

Agent Wonderland

이상적인 Agent 개발자는 AI Agent를 개발할 때 "Agent SDK + 스토리지 + MaaS 서비스"를 기반으로 완전한 serverless Agent를 구축할 수 있습니다.

Agent는 완전한 serverless로 실행될 수 있습니다.
Vibe Coding 방식을 통해 기존 제품 기능을 조합하여 Agent를 구축할 수 있습니다.
"ADK"의 python 스크립트만 유지 관리하면 됩니다.
스토리지는 객체 스토리지를 사용합니다.
AI 기능은 豆包(Doubao)를 사용합니다.
이론적으로 ECS 또는 기타 인스턴스 유형 제품이 필요하지 않습니다.

동시에 스토리지는 다음 기능을 제공해야 합니다.

Agent는 object 의미의 스토리지(파일 저장)를 가질 수 있으며, 멀티 테넌트 액세스 기능을 제공하고, 백만 개부터 시작하여 억 단위까지 확장 가능해야 합니다.
Agent는 각 사용자에게 독립적인 공간을 제공할 수 있어야 합니다(여러 비즈니스 간에, 비즈니스 또는 uid가 중복될 수 있습니다).
Agent는 각 사용자의 대역폭을 직접 구성하고, 사용자 object 총 크기 제한을 구성할 수 있어야 합니다.
Agent는 사용자별로 청구, 모니터링, 관찰할 수 있어야 합니다.
Agent는 각 사용자의 파일에 대한 액세스 정책을 구성할 수 있어야 합니다.

Agent Bucket: AI Agent에 "멀티 테넌트 기본" 유전자 주입

이러한 어려움을 근본적으로 해결하기 위해 우리는 완전히 새로운 객체 스토리지 패러다임인 Agent Bucket을 제안합니다. 핵심 혁신은 기존의 "버킷"과 "객체" 사이에 새로운 기본 리소스 계층인 객체 집합을 도입하는 것입니다.

이 설계의 핵심 아이디어는 매우 간단합니다. 각 최종 사용자에게 전용 ObjectSet을 매칭하는 것입니다. ObjectSet을 각 사용자를 위해 특별히 제작된 "데이터 금고" 또는 "클라우드 개인 공간"으로 생각할 수 있습니다. 논리적으로는 개발자의 Bucket에 속하지만 물리적 및 관리적으로는 자체적인 "개성"과 "수명 주기"를 갖습니다.Agent Bucket은 각 버킷이 1억 개의 ObjectSet을 지원하므로, 마치 각 최종 사용자가 독립적인 저장 공간에서 '생활'하는 것처럼 수억 명의 최종 사용자에게 부담 없이 서비스를 제공할 수 있으며, 더 이상 멀티 테넌트 스토리지 관리에 어려움을 겪을 필요가 없습니다.

ObjectSet 설계 - Agent 친화적인 기능

Agent Bucket의 ObjectSet은 단순히 계층을 추가한 것이 아니라, 멀티 테넌트 시나리오에서 가장 까다로운 요구 사항을 즉시 사용 가능한 기본 기능으로 바꿉니다. 데이터 소유권이 ObjectSet 계층에서 명확해지면 과거에 구현하기 어려웠던 일련의 기능이 자연스럽게 가능해집니다.

기본 격리: ObjectSet 수준에서 각 사용자에 대해 독립적인 QPS, 대역폭 제한 및 용량 할당량을 설정할 수 있습니다. 유료 사용자의 경험이 보장되고 무료 사용자의 비정상적인 동작이 다른 사용자에게 영향을 미치지 않습니다. 이는 진정한 장애 도메인 격리이며, '이웃'이 더 이상 서로 간섭하지 않도록 합니다.
기본 권한: 각 ObjectSet은 독립적인 도메인을 가질 수 있습니다. 즉, 전체 스토리지 버킷 도메인을 노출하는 대신 사용자 A에게 user-a.yourapp.com과 같은 전용 액세스 주소를 제공할 수 있습니다. 더욱 영리한 것은 '두 개의 잠금 장치' 설계입니다. 첫 번째 잠금 장치는 클라우드 서비스 제공업체가 발급한 임시 액세스 자격 증명(STS)으로, 애플리케이션 수준의 액세스 권한을 제어합니다. 두 번째 잠금 장치는 ObjectSet의 독립적인 도메인으로, 네트워크 수준에서 액세스 요청을 사용자 자신의 데이터 공간으로 잠급니다. 이는 데이터 보안을 크게 향상시킵니다.
기본 모니터링: 모니터링 대시보드에서 더 이상 전체 버킷의 개요 데이터만 볼 수 없습니다. ObjectSet별로 모니터링 차트를 분해하여 어떤 최종 사용자가 많은 액세스를 수행하고 있는지 명확하게 파악하여 정확한 운영 및 최적화 결정을 내릴 수 있습니다.
기본 기능 하향: 과거에 버킷 수준에서만 설정할 수 있었던 정책을 이제 각 사용자로 하향할 수 있습니다. 다양한 등급의 사용자에 대해 다른 데이터 수명 주기를 설정하거나 각 ObjectSet에 대해 다른 암호화 키를 사용하여 보다 세분화되고 안전한 데이터 관리를 구현할 수 있습니다.
기본 측정: 각 사용자가 얼마나 많은 저장 공간을 사용하고 있는지 알고 싶으십니까? 스토리지 비용을 각 사용자에게 정확하게 할당하고 싶으십니까? 이제 매우 쉽습니다. Agent Bucket은 각 ObjectSet의 용량과 사용량을 자동으로 통계하여 청구 및 분할을 명확하게 합니다.
기본 청구: 개발자는 비용 할당을 쉽게 구현하여 스토리지에서 발생하는 비용을 각 최종 사용자에게 정확하게 다시 할당할 수 있습니다. 예를 들어 A, B, C와 같은 다양한 사용자가 실제로 발생시킨 비용 비율에 따라 차등 요금을 부과하여 Agent의 상용화를 위한 데이터 지원을 제공합니다.
기본 용량 제한: Agent의 운영 비용을 제어하기 위해 각 ObjectSet에 대해 Quota(용량 제한)를 설정할 수 있습니다. 사전 설정 값에 도달하면 시스템은 해당 사용자가 새 파일을 계속 생성하는 것을 제한하여 멀티 테넌트 시나리오에서 리소스 남용을 근본적으로 방지합니다.
기본 인텔리전스: Agent Bucket을 사용하면 Agent가 기존 파일의 단순한 '저장 및 검색' 제한에서 벗어나 Object에 기본 인텔리전스를 부여하여 Agent의 원스톱 개발을 보다 효율적으로 지원할 수 있습니다. ObjectSet은 스마트 인덱싱을 원터치로 활성화하여 Agent에 기본적으로 친숙한 다중 모드 질문 및 답변 기능을 제공하여 기존 Object CRUD의 기계적 작업을 대체합니다. Agentself 모드를 원터치로 활성화하여 벡터, 지식, 모델 및 프롬프트를 연결하여 시나리오별 하위 Agent 기능을 직접 노출하여 상위 Agent 개발자가 주요 비즈니스 워크플로 생성에 집중하고 지능형 수익 창출 효율성을 최대한 발휘할 수 있도록 지원합니다.

애플리케이션 규모 폭발로 인한 기술적 과제

Agent Bucket은 ObjectSet이라는 기본 개념을 도입하여 애플리케이션 개발자에게 수억 명의 최종 사용자 데이터를 관리하는 우아하고 효율적인 방법을 제공합니다. 각 사용자의 디지털 자산은 전용 ObjectSet에 안전하게 저장되어 격리, 청구 및 할당량 관리를 자연스럽게 구현합니다.

애플리케이션 규모가 급격히 확장됨에 따라 대규모 Set의 관리 복잡성, 격리 어려움 및 물리적 병목 현상이 동시에 나타납니다.

대규모 사용자 계층 관리 문제: 애플리케이션이 다양한 등급의 많은 사용자의 리소스와 기능을 차별적으로 관리할 때 사용자 계층 메타데이터를 직접 설계하고 구현하고 객체 스토리지 기능 스위치와 연결해야 합니다. Set의 기본 개념에서 개발자가 사용자 계층을 우아하게 관리하도록 돕는 것은 애플리케이션 배포를 가속화하는 데 중요합니다.- 단일 클러스터 용량 병목 현상: Agent Bucket은 논리적으로 무한 확장할 수 있지만, 메타데이터는 기본적으로 단일 물리 클러스터에 저장됩니다. 버킷 내 객체 총 수가 수천억 또는 수조 개에 도달하면 단일 클러스터의 물리적 용량이 극복할 수 없는 상한이 됩니다.
액세스 포인트 공유 문제: Agent의 다양한 비즈니스와 대규모 사용자는 액세스 포인트 자체에 더 큰 보안 위험과 폭발 반경을 가져옵니다. 수많은 다양한 비즈니스와 사용자의 차이점에 따라 동적 스케줄링을 수행하고 차별화된 보안, 격리 및 가속 기능을 구현하는 방법이 어려운 문제가 됩니다.

Set Tagging: 태그를 사용한 사용자 등급 관리

ObjectSet은 기본 태그 관리 방식을 제공하여 Agent 개발자가 set tagging 기능을 간단하게 사용하여 사용자 등급 관리를 완료할 수 있도록 합니다. 개발자는 정의된 각 사용자 수준에 해당하는 태그를 만들고 각 태그에 대해 다른 할당량과 특성을 활성화할 수 있습니다. 이 태그가 지정된 모든 ObjectSet은 해당 할당량과 특성을 적용합니다. V1, V2, V3의 세 가지 수준을 예로 들어 설명합니다.

V1: 기본 수준, 무료 사용자, 모든 ObjectSet의 기본 태그, 최대 1GiB의 데이터를 저장하도록 구성할 수 있으며 공용 네트워크 배포는 100mbps 대역폭을 초과할 수 없으며 단일 스트림 다운로드 속도는 1mbps로 제어됩니다.
V2: 입문 레벨 유료 회원, 최대 10GiB의 데이터를 저장하도록 구성, 공용 네트워크 배포는 10gbps 대역폭을 초과할 수 없으며 단일 스트림 다운로드 속도는 10mbps로 제어됩니다.
V3: 고급 유료 회원, 더 큰 저장 용량과 공용 네트워크 배포 할당량을 제공하는 것 외에도 추가 공용 네트워크 약한 네트워크 가속 및 고성능 미디어 가속 기능을 활성화하도록 지원합니다.

Agent 개발자는 다양한 사용자의 다양한 개발 주기에 따라 V1/V2/V3 태깅을 유연하게 사용하여 이러한 사용자가 사용할 수 있는 리소스와 부가 가치 기능을 관리할 수 있습니다.

Set Tagging 사용자 등급 관리

Set Slice: 대규모 사용자 데이터 기본 격리

Agent Bucket 내의 Set이 억 단위에 도달하고 객체 수가 수천억, 수조 단위에 도달하면 "단일 Bucket의 모든 메타데이터가 하나의 KV 클러스터에 집중됨"이라는 사실 자체가 용량과 성능 모두에 위험을 초래합니다.

Set Slice는 "논리적으로 분할하지 않고 물리적으로 분할"하는 아이디어를 제공합니다.

논리적으로는 여전히 하나의 Agent Bucket만 관리합니다.
물리적으로는 Set 및 Set 내 객체 이름의 범위에 따라 메타데이터를 여러 Slice(조각)로 나누고 각 Slice는 다른 클러스터에 저장할 수 있습니다. 여러 Set이 기본적으로 격리되고 단일 Set이 수평으로 확장됩니다.

Set Slice 물리적 분할

Set Slice는 ObjectSet 기능의 추가 확장 및 보장입니다. 기본적으로 물리적 용량의 무한 확장 문제를 해결하는 동시에 상위 ObjectSet 관리 모델의 안정성과 일관성을 보장합니다.

관리 경계 안정성: Agent Bucket의 데이터가 여러 물리적 클러스터에 걸쳐 있더라도 ObjectSet은 여전히 권한, 할당량, 청구 및 모니터링의 유일한 기본 단위입니다. 개발자가 ObjectSet에 대해 구성한 정책(예: 액세스 제어, 용량 제한)은 관련 Slice에서 자동으로 적용되므로 기본 데이터 분포에 대해 걱정할 필요가 없습니다.
단일 Set은 선형적으로 확장 가능: 특정 ObjectSet 데이터 양이 빠르게 증가하면 해당 데이터는 여러 Slice에 자연스럽게 분산됩니다. 전체 클러스터가 확장됨에 따라 해당 ObjectSet의 용량도 원활하고 선형적으로 증가하므로 개발자는 해당 ObjectSet 자체에 대해 분할 또는 마이그레이션과 같은 파괴적인 작업을 수행할 필요가 없습니다.
Set 간 리소스 격리: 다른 범위의 객체를 다른 물리적 클러스터에 배포함으로써 SetSlice는 더 높은 차원의 리소스 격리를 구현합니다. ObjectSet의 할당량 관리와 결합하여 특정 "슈퍼 대규모" ObjectSet의 데이터 증가가 단일 클러스터의 모든 리소스를 차지하여 다른 ObjectSet의 안정성에 영향을 미치는 것을 효과적으로 방지하여 전체 용량 위험을 제어할 수 있습니다.- 논리적 통일성과 호환성: 비즈니스 및 개발자에게는 기본적으로 얼마나 많은 Slice가 있든 상관없이 항상 논리적으로 통일된 Agent Bucket에 직면하게 됩니다. 버킷, ObjectSet 및 객체에 대한 모든 작업 방식은 변경되지 않아 물리적 확장이 상위 애플리케이션에 완전히 투명하게 이루어집니다.\n\n## Set AccessPoint: 각 사용자 액세스 진입점 격리\n\nAgent Bucket은 각 ObjectSet에 대해 독립적인 액세스 포인트(독립 도메인)를 활성화하고 액세스 포인트에서 차별화된 보안, 격리 및 가속 기능을 확장할 수 있도록 지원합니다. 이를 위해 시스템은 억 단위의 독립적인 액세스 포인트 스케줄링 및 차별화된 구성 기능을 지원해야 합니다.\n\n독립적인 액세스 도메인 {$apid}.tos-objectset-ap.volces.com: 2단계 보안 보호\n\n - 1단계 Obscurity(불명확성): 사용자/ObjectSet별 독립적인 하위 도메인, apid 높은 엔트로피 해싱, 매우 낮은 충돌 확률, 액세스 도메인 관점에서 특정 사용자 진입점을 추측하거나 열거할 수 없습니다.\n\n - 2단계 Containment(제한성): Agent 개발자는 sts를 사용하여 ObjectSet 수준 액세스 권한을 배포합니다. sts가 유출되더라도 액세스 범위가 특정 ObjectSet의 제한된 유효 기간 내로 제한되도록 제어할 수 있습니다.\n\n휴리스틱 스케줄링 시스템: 억 단위 도메인 스케줄링 정책 계산\n\n - 사용자/ObjectSet:tag별 차별화된 액세스 정책\n\n - 여러 사용자/ObjectSet이 자동으로 다른 공용 네트워크 진입점에 분산되어 단일 진입점 오류가 사용자 수에 미치는 영향이 제어됩니다.\n\n - 전체 지역 탄력적 스케줄링, 임의의 단일 진입점 오류/과부하가 자동으로 트래픽 패킹 및 이동을 완료합니다.\n\n - 공용 네트워크 가속 배포 유형 사용자, 공용 네트워크 전송 가속 태그를 지정하여 자동으로 가속 진입점을 스케줄링합니다.\n\n - 공용 네트워크 위험 유형 사용자, 위험 태그를 지정하여 자동으로 공용 네트워크 격리 진입점을 스케줄링하고 공용 네트워크 대역폭 할당량을 줄입니다.\n\n - 사설 네트워크 교차 도메인 유형 사용자, 교차 도메인 태그를 지정하여 자동으로 사설 네트워크 전용선 가속 경로를 스케줄링합니다.\n\n - 로컬 지역 가속기 사용자, 가속기 태그를 지정하여 자동으로 로컬 지역 가속기를 마운트합니다.\n\n\n\n## 프로그래밍 도우미에서 AI 클라우드 디스크까지, Agent Bucket의 무한한 가능성\n\nAgent Bucket은 Agent에 완벽한 솔루션을 제공하며 ObjectSet의 설계 응용 시나리오는 이뿐만이 아닙니다. 대규모 최종 사용자에게 서비스를 제공해야 하는 모든 애플리케이션으로 쉽게 확장할 수 있습니다.\n\n - 코드 저장소: 과거에는 기업이나 개인이 클라우드에 코드를 호스팅할 때 계정 격리 및 권한 제어를 위해 객체 스토리지 위에 - 모델 호스팅 플랫폼: 대규모 모델 호스팅 시나리오에서는 각 모델이 방대할 뿐만 아니라 서로 다른 버전, 가중치 및 추론 구성을 가질 수 있습니다. 각 모델에 대해 ObjectSet을 생성하면 모델 가중치, Tokenizer, 구성 파일 및 관련 평가 데이터를 동일한 공간에 패키징하여 호스팅할 수 있습니다. 운영 측면에서는 다양한 모델에 대해 차별화된 암호화 정책, 백업 정책 및 대역폭 제어를 설정할 수 있으며, 기본 측정 기능을 통해 각 모델의 실제 사용 비용을 통계적으로 파악하여 모델 차원의 청구 및 리소스 스케줄링을 위한 기반을 제공합니다.
데이터 SaaS 서비스: 대규모 최종 사용자 대상 데이터 배포 플랫폼은 종종 많은 데이터 제공업체와 동시에 연결해야 합니다. 각 당사자의 데이터 경계를 명확하게 유지하면서도 "하나의 큰 버킷이 모든 사람을 끌어내리는" 성능 위험을 피해야 합니다. Agent Bucket을 사용하면 각 데이터 제공업체가 자체 ObjectSet을 가질 수 있으며, 원시 데이터와 처리 결과를 통합 관리할 수 있습니다. 또한 독립적인 도메인 및 대역폭, QPS 할당량을 통해 다양한 제공업체에 대한 차별화된 서비스 보장 및 속도 제한을 구현하여 "하나의 플랫폼, 여러 제공업체, 서로 격리되면서도 제어 가능한 협업" 데이터 배포 인프라를 실현할 수 있습니다.