[AWS SUMMIT 2025] Amazon Bedrock을 활용한 생성형AI기반 SaaS서비스 구축

들어가며

Amazon Bedrock을 활용한 생성형AI기반 SaaS서비스 구축

🎙️서호성 솔루션즈 아키텍트

🎙️김진아 솔루션즈 아키텍트

🗂️ 세션 토픽: 애플리케이션 및 비즈니스 현대화

이번 칼럼에서는 Amazon Bedrock을 활용한 생성형AI기반 SaaS서비스 구축 세션에서 소개된 내용을 정리하였습니다. 구체적으로는 멀티테넌트 환경에서 아키텍처 패턴(Pool/Silo)을 제시하고, 테넌트 온보딩, 데이터 파티셔닝, 그리고 강력한 격리를 구현하는 방법을 상세히 다룹니다. 또한, 테넌트별 사용량을 추적하여 비용을 계산하고, 다른 테넌트의 과도한 사용으로 인한 성능 저하(노이즈 네이버 문제)를 방지하는 기법도 함께 소개되었습니다.

1. 멀티테넌트 생성형 AI 아키텍처

멀티테넌트 환경에서 생성형 AI 기반 SaaS 서비스 구축을 위해 두 가지 아키텍처 패턴이 제시됩니다.

• 사일로 (Silo)

테넌트별 전용 리소스를 제공하는 방식으로, 높은 성능과 강한 격리를 제공합니다. 프리미엄 티어에 적용됩니다.

• 풀 (Pool)

테넌트 간 공용 리소스를 제공하는 방식으로, 비용 이점을 제공합니다. 베이직 티어에 적용됩니다.

이러한 아키텍처는 테넌트의 입력 프롬프트와 컨텍스트 정보를 사용하여 테넌트 고유 데이터를 보강하고, Bedrock의 LLM 모델로부터 테넌트에 특화된 신뢰성 높은 응답을 얻는 것을 목표로 합니다.

베이직 티어 아키텍처 (풀 모델 기반)

• 설계 목표
  • 비용 부담 없이 쉽게 사용해 볼 수 있도록 경제적인 운영에 초점을 맞춥니다.
• 주요 특징
  • 리소스 공유를 기반으로 구성되며, RAG(Retrieval Augmented Generation)만 사용하도록 설계됩니다.
  • Fine-tuning은 테넌트별 모델 재사용이 어렵고 호스팅 비용이 높아 프리미엄 티어에만 적용됩니다.
  • 데이터 소스는 S3를 풀 모델로 공유하며, 테넌트별 전용 프리픽스를 제공하여 데이터를 분리합니다.
  • Knowledge Base는 데이터를 벡터로 변환하며, 테넌트별로 제공됩니다.
  • 벡터 스토어는 Amazon OpenSearch Serverless를 사용하며, 하나의 리소스를 공용으로 사용하고 풀 컬렉션 내에서 테넌트별 인덱스를 관리합니다.
  • 테넌트 요청은 API Gateway와 풀 컴퓨팅을 거쳐 Knowledge Base에서 벡터 데이터를 검색합니다.
  • 이 데이터로 보강된 프롬프트를 Bedrock의 LLM에 전송하여 응답을 얻습니다.
  • 에이전트도 풀 모델로 테넌트 요청에서 컨텍스트 정보를 확인하여 테넌트의 리소스와 Knowledge Base에 접근합니다.
• 확장성 및 격리 보장
  • 리소스를 공유하더라도 테넌트의 격리와 확장성은 보장해야 합니다.

프리미엄 티어 아키텍처 (사일로 패턴 기반)

• 설계 목표
  • 더 많은 비용을 지불하는 사용자에게 더 높은 성능과 강력한 격리를 제공합니다.
• 주요 특징:
  • 모든 서비스에 대해 사일로 패턴의 전용 리소스를 제공합니다.
  • RAG뿐만 아니라 Fine-tuning도 전용으로 제공합니다.
  • S3는 테넌트 전용으로 제공하며, 수집된 데이터를 Knowledge Base를 통해 벡터로 변환합니다.
  • 벡터 스토어의 OpenSearch Serverless 컬렉션과 인덱스를 전용으로 제공합니다.
  • 테넌트의 벡터 변환 및 검색 요청은 전용 API와 사일로 컴퓨팅을 거쳐 테넌트의 Knowledge Base에서 처리합니다.
  • 에이전트 역시 전용 워크로드를 제공하고 전용 리소스와 연동하며 Knowledge Base를 통해 검색 작업을 수행합니다.
• 최적화된 환경 제공
  • 최적화된 전용 환경을 제공합니다.

온보딩 과정

멀티테넌시 구현을 위해 테넌트 온보딩이 중요합니다. 

온보딩은 컨트롤 플레인에 해당하며, 새로운 테넌트의 데이터와 리소스를 생성합니다. 

베이직 티어 가입 시 온보딩을 통해 테넌트 정보가 저장되고, Knowledge Base와 테넌트별 인덱스 프리픽스가 프로비저닝됩니다.

프리미엄 티어 가입 시 온보딩을 통해 전용 리소스들이 생성됩니다. 

온보딩 자동화를 통해 일관되고 안정적인 테넌트 관리와 빠른 서비스 확장에 대응할 수 있습니다.

2. 테넌트 격리

SaaS에서 테넌트 격리는 필수입니다. 격리 구현은 테넌트 온보딩에서 시작되며, 온보딩에서 서비스 권한을 설정하고 이를 이용하여 테넌트 격리를 구현합니다.

베이직 티어 격리

• Knowledge Base
  • 테넌트별로 제공됩니다. 풀 모델 S3(테넌트 프리픽스 접근)와 OpenSearch Serverless 풀 컬렉션(테넌트 자신의 인덱스 접근)에 대한 격리를 구현해야 합니다. 온보딩 과정에서 Knowledge Base의 서비스 롤에 해당 테넌트 인덱스만 접근할 수 있는 권한을 AWS IAM 정책으로 설정하여 강하게 보장합니다.

• 풀 컴퓨팅
  • 컴퓨팅 자원을 공유하므로 실행 역할을 사전에 설정할 수 없습니다. 런타임 시에 테넌트별 임시 자격 증명을 생성하여 리소스 접근 제어로 격리를 구현합니다. 테넌트가 인증 후 테넌트 ID가 포함된 JWT 토큰을 API 요청에 담아 보내면, API 게이트웨이의 오소라이저 람다가 실행되어 테넌트 ID로 Knowledge Base ID를 조회합니다. 이 오소라이저 람다는 AWS STS(Security Token Service)를 통해 Knowledge Base ID로 속성 기반 역할을 설정하여 임시 자격 증명을 발급합니다. 이 임시 자격 증명은 풀 컴퓨팅 서비스에서 Bedrock 호출을 위한 클라이언트를 생성하는 데 사용되어, 자신의 Knowledge Base에만 접근할 수 있도록 합니다.

• 풀 에이전트
  • 워크로드를 공유하므로 런타임 격리가 적용됩니다. 인증 후 테넌트 ID가 포함된 JWT 토큰을 API 요청에 담아 보내면, 오소라이저 람다가 토큰을 검증하고 Knowledge Base ID를 조회합니다. 이 정보로 속성 기반 역할을 설정하여 STS로 특정 테넌트로 범위가 제한되는 임시 자격 증명을 생성합니다. 이 임시 자격 증명은 컴퓨팅 서비스를 통해 풀 에이전트로 전달되고, 에이전트는 이 자격 증명으로 Bedrock 클라이언트를 생성하여 해당 테넌트의 Knowledge Base에 접근합니다. 이러한 동적인 격리 방식은 DynamoDB나 S3와 같은 다른 리소스에도 동일하게 적용될 수 있습니다.

프리미엄 티어 격리

전용 리소스를 사용하더라도, 자동으로 격리를 보장하는 것은 아닙니다. 다만 격리를 쉽게 할 수 있습니다. 핵심 영역은 Knowledge Base와 컴퓨팅 환경입니다. 프리미엄 티어는 온보딩 시 리소스의 실행 역할을 사전에 설정하여 세밀한 격리가 가능합니다. 에이전트도 테넌트 전용으로 사용하므로 동일하게 실행 역할을 사전 설정하여 리소스 접근을 제어합니다.

• Knowledge Base

전용 OpenSearch Serverless 컬렉션을 사용합니다. Knowledge Base의 서비스 롤에 전용 컬렉션과 사용 가능한 파운데이션 모델이 결정되고, 전용 S3 접근 권한도 설정됩니다. OpenSearch Serverless 컬렉션에는 데이터 접근을 설정하여 사용 가능한 테넌트를 결정하고, Knowledge Base 서비스 롤을 설정하여 해당 테넌트의 Knowledge Base만 접근을 허용합니다.

• 사일로 컴퓨팅

테넌트 전용으로 사용하며, 온보딩 시 설정한 실행 역할을 이용해 전용 컴퓨팅에서 생성한 Bedrock 클라이언트로 Knowledge Base를 호출합니다. 사일로 환경에서의 격리는 간단합니다.

• 사일로 에이전트

전용 에이전트는 온보딩 시점에 테넌트 역할이 설정되고, 이 역할을 통해 에이전트는 자신의 Knowledge Base만 이용하도록 격리됩니다.

AWS IAM 서비스 활용

AWS는 멀티테넌트 환경에서 AWS IAM 서비스를 사용하여 강력한 리소스 격리 메커니즘을 제공합니다3. 가능한 IAM 서비스를 사용하여 격리를 구현하는 것이 권장됩니다.

3. 테넌트 별 비용 추적

테넌트별로 비용을 부과하기 위해 사용량 측정 및 비용 산정 기준을 고민해야 합니다. 일반적으로 아키텍처 영역 전체를 살펴보고 비용이 가장 많이 발생할 만한 서비스나 영역(예: LLM 사용)을 선택하여 사용량을 산정하고 비용을 추적하는 내용에 대한 소개가 있었습니다. 많은 비용이 발생할 수 있는 부분은  LLM(파운데이션 모델) 사용 부분입니다. 또한 스토리지 부분도 많은 비용을 차지할 수 있습니다.

Bedrock 사용량

Foundation Model과 상호 작용하며 소비한 입출력 토큰을 기반으로 비용을 계산합니다. Bedrock 비용은 온디맨드로 사용 시 토큰 사용량에 따라 부과됩니다. 컴퓨팅 서비스(EC2 등), Knowledge Base, 에이전트 구성 요소가 Foundation Model과 상호 작용하며 소비한 토큰 수를 확인하고 집계합니다. 테넌트별 토큰 사용량에 Bedrock 비용을 곱해 테넌트별 Bedrock 사용 비용을 파악합니다.

스토리지 사용량

아키텍처에서 많은 비용을 차지하는 부분입니다. 주기적으로 스토리지 사용량을 어떤 기준으로 수집하고 테넌트 비용을 계산할지 살펴봐야 합니다.

• 베이직 티어 (공유 OpenSearch): OpenSearch Serverless는 데이터 저장량, 인덱싱, 검색/쿼리 리소스 기준으로 비용을 측정합니다. 테넌트별 인덱스 아래 있는 데이터 양으로 사용량을 계산할 수 있습니다. Metric Manager와 같은 커스텀 코드를 통해 테넌트 식별 정보(인덱스 이름으로 기록)와 사용량(데이터 양)을 CloudWatch에 로깅합니다. 검색/쿼리 비용은 테넌트 요청에 따라 발생하며, Knowledge Base에서 OpenSearch 검색 요청 시 검색 작업 시간을 측정하여 비용 계산에 반영할 수 있습니다.
• 프리미엄 티어 (전용 리소스): 전용 리소스는 테넌트 ID에 대한 태그를 지정하여 AWS 비용 보고서에서 별도로 비용을 확인할 수 있습니다.

사용량 수집 및 기록 방법

• 컴퓨팅 영역: 테넌트 요청 시 API 게이트웨이를 통해 백엔드 서비스로 전달되고, 백엔드 서비스에서 Bedrock을 호출합니다. Bedrock API 응답에 소비한 토큰 수가 포함됩니다. 이 토큰 수를 파악해 테넌트별로 로깅합니다. Metric Manager와 같은 라이브러리를 만들어 테넌트 식별 정보(API 요청 시 전달받는 인증 토큰에서 파악)와 토큰 사용량을 함께 기록하고 CloudWatch에 로깅합니다.
• Knowledge Base: 데이터를 Knowledge Base로 구축할 때 인베딩 생성 및 Knowledge Base 사용 시 내부적으로 LLM을 호출합니다. Knowledge Base는 내부적으로 LLM을 호출하기 때문에 API 응답에 토큰 수가 포함되지 않습니다. Bedrock 수준에서 로깅을 활성화하면 자동으로 기록된 로그에서 토큰 사용량을 파악할 수 있습니다. Bedrock 호출 로그 메시지에 특정 상호 작용의 소비 토큰 수가 포함됩니다. 로그에 포함된 아이덴티티(예: 작업 수행 식별자, 임시 자격 증명 이름에 포함된 테넌트 ID)를 활용해 로그를 필터링하여 테넌트별 사용량을 집계합니다.
• 에이전트: 세부 작업(전처리, 오케스트레이션, 후처리) 수행 시 LLM을 호출합니다. 에이전트 활용 시 트레이스를 활성화하면 각 세부 작업 수행 시 트레이스 메시지를 보내며, 이 메시지 내에 토큰 수가 포함됩니다. Metric Manager를 활용하여 테넌트별 소비 토큰 수를 기록합니다.

4. 테넌트 사용량 제한

Saas  서비스를 사용하다보면, 노이즈 네이버(Noisy Neighbor) 문제가 발생할 수 있는데요. 하나의 테넌트의 과도한 사용으로 인해 다른 테넌트의 성능에 부정적인 영향을 미치는 문제를 말하는 것입니다. 
테넌트들에게 일관된 서비스 품질을 제공하기 위해선 이 문제를 방지하기 위한 스로틀링(throttling)이 필요합니다.

API Gateway 단 스로틀링

API Gateway는 Usage Plan을 통해 초당 요청수나 하루 처리 요청수를 제한할 수 있습니다.
이는 티어별로 적용 가능하지만, 단순히 요청 수나 속도만 제한한다는 한계가 있습니다.

토큰 사용량 계획 제한 (커스텀 구현)

하루에 테넌트가 사용할 수 있는 토큰 수를 제한하는 방법입니다.
이는 API Gateway의 Usage Plan만으로는 해결할 수 없으므로, 직접 토큰 사용량을 집계하고 제한을 넘는지 파악해야 합니다.

방법 : 

• 비용 계산을 위해 기록했던 CloudWatch 로그를 주기적으로 확인하여 테넌트의 누적 토큰 사용량을 집계하고 기록합니다. (예: Lambda 함수 사용)
• 테넌트별 토큰 제한을 조회하여 현재까지 소비한 토큰 수와 제한을 비교합니다.
• API Gateway에 붙어 있는 Lambda Authorizer를 통해 이 요청이 제한을 넘는지에 따라 허용할지 거부할지를 결정합니다.

마무리하며

Amazon Bedrock 기반의 생성형 AI SaaS 서비스를 성공적으로 구축하기 위해서는 멀티 테넌트 아키텍처 설계, 강력한 데이터 격리 구현, 체계적인 테넌트별 비용 측정 및 산정, 그리고 노이즈 네이버 문제 방지를 위한 사용량 제한 메커니즘 구축이 필수적임을 알수 있었습니다.

 AWS IAM 서비스는 격리 구현에 매우 유용하며, 테넌트 식별 정보는 사용량 집계 및 비용 산정의 핵심입니다. 서비스의 특성과 비즈니스 요구사항에 맞춰 적절한 아키텍처 패턴 (풀 또는 사일로)을 선택하고, 제시된 가이드라인을 참고하여 안정적이고 확장 가능한 SaaS 솔루션을 구축해야 성공적으로 서비스를 구축할 수 있습니다.

글 │ │메가존클라우드, AI&Data 부문 / AI & Data Ops, 박준범 Team Leader