티어-테넌트-사용자로 이어지는 3단계 계층 구조
SaaS(서비스형 소프트웨어) 운영자는 고객사별 서버 구축 비용과 단일 서버 사용 시의 데이터 유출 위험 사이에서 효율적인 접점을 찾아야 한다. 아마존 베드락 에이전트코어는 티어-테넌트-사용자로 이어지는 3단계 계층 구조의 풀 모델(Pool Model) 멀티테넌시 아키텍처로 이 문제를 해결한다.
풀 모델은 테넌트가 전용 자원을 할당받는 대신 동일한 기본 인프라와 컴퓨팅 자원을 공유하는 방식이다. 고객사별 전용 자원을 두는 격리 방식보다 자원 활용도를 극대화하여 운영 효율을 높일 수 있다. 데이터 격리는 물리적 분리가 아니라 범위가 지정된 식별자와 액세스 정책, 데이터 파티셔닝 같은 논리적 분리 기법을 통해 수행한다.
구체적인 적용 사례로 여러 클리닉과 병원을 지원하는 헬스케어 AI 에이전트 구조를 든다. 가장 상위의 티어(Tier)는 베이직이나 프리미엄 같은 요금제에 따른 기능과 서비스 품질을 정의한다. 그 아래 테넌트(Tenant)는 개별 병원이나 클리닉 단위를 의미하며, 최하위의 사용자(User)는 해당 기관에 소속된 개별 의료진이나 직원을 가리킨다. 이 3단계 계층은 지식 베이스의 문서, 메모리, 모델 접근 권한, 비용 추적의 모든 단계에서 격리 기준으로 작동한다.
이 설계 패턴은 인프라 운영 비용을 낮게 유지하면서 IAM(아이덴티티 및 액세스 관리) 수준의 강력한 데이터 격리를 구현한다. 전체 구현 코드와 상세 설정은 다음 저장소에서 확인할 수 있다.
https://github.com/aws-samples/sample-agentcore-and-multitenancy-blog
JWT와 마이크로 VM을 이용한 컴퓨팅·신원 격리
아마존 베드락 에이전트코어 런타임은 에이전트 세션이 실행되는 시점에 독립된 마이크로 VM(가상 머신)을 할당하여 컴퓨팅 환경을 격리한다. 서로 다른 테넌트의 코드가 동일한 메모리 공간을 공유하지 않도록 물리적 경계를 세워 테넌트 수준의 컴퓨팅 격리를 구현하는 방식이다. 서비스 등급에 따라 별도의 에이전트 인스턴스를 호스팅하며, 각 인스턴스는 해당 티어에 최적화된 모델과 기능을 갖춘다. 이를 통해 특정 테넌트의 작업 부하가 다른 테넌트의 성능에 영향을 주는 간섭 현상을 차단한다.
신원 확인 단계에서는 Cognito ID 토큰 기반의 JWT(JSON 웹 토큰) 인증 모델을 적용한다. Cognito ID 토큰은 런타임과 게이트웨이라는 두 개의 경계 지점에서 사용자 신원을 검증하며, 툴 람다는 하위 데이터 접근을 위해 범위가 제한된 자격 증명을 생성한다. 특히 JWT 내부에는 `tenant_id`와 `tier` 같은 테넌트 메타데이터가 커스텀 클레임 형태로 포함되어 전달된다. 에이전트 배포 단계에서 다음과 같이 JWT 인증자를 설정하면, 에이전트 코드가 실행되기 전 토큰의 유효성을 먼저 검증한다.
{
"authorizer": {
"type": "JWT",
"config": {
"issuer": "https://cognito-idp.region.amazonaws.com/user-pool-id",
"audience": ["client-id"]
}
}
}
검증된 신원은 에이전트코어 게이트웨이를 거치며 구체적인 실행 컨텍스트로 변환된다. 게이트웨이는 `X-Tier`, `X-Clinic-ID`, `X-S3-Prefix` 헤더를 생성하여 테넌트 컨텍스트를 하위 시스템으로 전파한다. 에이전트가 게이트웨이를 호출할 때 사용자의 원래 JWT를 Bearer 토큰으로 전달하면, 게이트웨이는 이를 검증한 뒤 `metadataConfiguration` 설정을 통해 대상 람다 함수로 테넌트 헤더를 넘긴다. 대상 람다는 게이트웨이의 CUSTOM_JWT 인증자를 통과한 신뢰 헤더만 읽어 동작하므로, 개별 도구마다 인증 로직을 중복 구현할 필요가 없다.
애플리케이션 필터링을 넘어선 IAM 수준의 ABAC 격리
데이터베이스 쿼리에 `WHERE` 절을 추가하는 방식의 데이터 분리는 코드 실수로 인한 타사 데이터 유출 위험이 있다. 아마존 베드락 에이전트코어는 이를 방지하기 위해 AgentCore Memory에서 계층적 네임스페이스 구조와 composite `actor_id`(여러 식별자를 조합한 통합 ID)를 사용하여 테넌트와 사용자별 대화 기록을 물리적으로 분리한다.
인프라 수준의 강제성을 확보하기 위해 TVM(Token Vending Machine) 패턴과 ABAC(Attribute-Based Access Control, 속성 기반 액세스 제어)를 도입했다. 에이전트는 실행 시점에 Tier, ClinicId, UserId라는 세 가지 세션 태그를 가진 TVM 역할을 부여받아 해당 세션의 속성에 맞는 임시 자격 증명을 획득한다. 사용자의 속성 자체가 데이터 접근을 결정하는 열쇠가 되는 방식이다.
실제 데이터 저장소인 DynamoDB에서는 `dynamodb:LeadingKeys` 조건을 통해 IAM 레벨에서 격리를 완성한다. 요청자의 세션 태그와 데이터베이스의 파티션 키가 일치할 때만 쿼리를 허용하므로, 개발자가 쿼리 문을 잘못 작성하더라도 본인 클리닉의 데이터 외에는 접근이 불가능하다. TVM 역할의 신뢰 정책은 오직 에이전트 실행 역할만이 이 역할을 수행할 수 있도록 제한하며, 세 가지 세션 태그가 모두 존재해야만 증명을 발행한다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT_ID:role/AgentExecutionRole"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:TagSession": [
"Tier",
"ClinicId",
"UserId"
]
}
}
]
}
이 설계는 데이터 격리의 책임을 애플리케이션 코드가 아닌 AWS 클라우드 인프라의 IAM 체계로 옮겨, 중앙 집중화된 정책 설정만으로 전사적인 데이터 보안 수준을 보장한다.
MCP와 Cedar 정책을 통한 서비스 등급 차별화
아마존 베드락 에이전트코어는 MCP(Model Context Protocol)를 통해 서비스 등급별 기능 제공 과정을 자동화한다. 에이전트코어 게이트웨이는 정적인 람다 함수를 MCP 표준에 맞춘 동적 도구로 변환하여 에이전트가 외부 API를 즉시 사용할 수 있게 만든다. 이를 통해 API 명세서 파싱, 인증 처리, 테넌트 컨텍스트 전파를 위해 구현해야 했던 커스텀 오케스트레이션 로직을 제거한다. 예시 솔루션에서는 `get_patient_records`와 `patient_context` 도구를 통해 환자 기록 조회와 문맥 파악 기능을 제공한다.
기능 제어는 Cedar라는 정책 전용 언어를 사용하는 AgentCore Policy 엔진이 담당한다. 이 엔진은 기본과 프리미엄 게이트웨이 모두에 ENFORCE 모드로 연결되어 요청을 실시간으로 검증한다. 개발자는 코드 수정 없이 정책 파일의 규칙만 변경하여 서비스 등급별로 접근 가능한 도구를 제한할 수 있다.
실제 Basic 티어의 경우 `patient_context` 도구의 사용 시간을 08시부터 18시까지로 제한한다. 에이전트가 `current_time` 함수를 호출해 현재 시간을 전달하면, 정책 엔진은 `request_hour` 필드를 평가하여 허용 시간 외의 요청을 즉시 거부한다. 인프라 운영자는 표준 프로토콜과 정책 엔진만으로 정교한 서비스 등급 차별화를 구현할 수 있다.
한국 B2B AI SaaS 실무자를 위한 아키텍처 시사점
SaaS 운영 시 고객사별 전용 자원 할당은 인프라 비용 상승의 주요 원인이 된다. 아마존 베드락 에이전트코어의 풀 모델은 여러 테넌트가 동일한 인프라를 공유하면서도 논리적 분리 기제를 통해 데이터 격리를 유지한다. 이는 운영 비용을 최소화하면서 Basic이나 Premium 같은 서비스 등급별로 차등화된 경험을 제공하는 효율적인 설계 방식이다.
의료나 금융처럼 데이터 유출에 민감한 산업군에서는 애플리케이션 레벨의 필터링만으로 보안 규제 대응이 어렵다. 이 아키텍처는 TVM 패턴과 ABAC 방식을 통해 런타임에 테넌트 전용 임시 자격 증명을 부여하고, DynamoDB의 `dynamodb:LeadingKeys` 조건으로 물리적 수준의 쿼리를 강제한다. 인프라 계층에서 접근을 직접 차단함으로써 코드 레벨의 필터링 누락으로 인한 데이터 노출 가능성을 제거한다.
또한, MCP 표준 도입은 외부 도구 연동 시 반복되는 API 분석과 인증 로직 구현 공수를 줄여 B2B AI 서비스의 출시 속도를 높인다. API 명세 파싱과 테넌트 컨텍스트 전파 과정을 표준화하여 특정 벤더에 종속되지 않는 환경을 구축함으로써, 실무자는 비즈니스 로직 구현에만 집중할 수 있다.
결과적으로 데이터 격리의 책임이 애플리케이션 코드가 아닌 중앙 집중화된 IAM 정책 설정으로 이동했다. 실무자는 제공된 GitHub 샘플 코드를 통해 티어-테넌트-사용자로 이어지는 3단계 계층 구조를 구현함으로써 인프라 효율과 보안성을 동시에 확보하는 설계 기준을 세울 수 있다.
인프라 비용 절감과 데이터 격리라는 상충하는 과제는 이제 개발자의 쿼리 작성 능력이 아닌 아키텍처의 설계 수준에서 해결된다. 보안은 이제 개별 기능의 구현 대상이 아니라 인프라 수준의 설정 대상이 된다.




