Build a semantic layer for agentic AI on AWS with AtScale and Amazon Bedrock AgentCore
Quick Summary
AtScale은 Amazon Redshift Serverless의 C360 데이터를 SML 기반 차원 모델로 정의하고, Amazon Bedrock AgentCore의 Strands 에이전트와 BI 도구가 동일한 지표 정의와 접근 제어를 사용하도록 연결한다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약
AtScale은 Amazon Redshift Serverless의 C360 데이터를 SML 기반 차원 모델로 정의하고, Amazon Bedrock AgentCore의 Strands 에이전트와 BI 도구가 동일한 지표 정의와 접근 제어를 사용하도록 연결한다.
📌 핵심 요약
- 이번 글은 Stardog와 Denodo를 사용한 앞선 사례의 고객 360(C360) 패턴을 AtScale로 구현하며, 단일 배포 모델을 SQL, XMLA, MCP로 제공해 에이전트와 BI 도구가 같은 정의에서 같은 계산 결과를 얻도록 한다.
- AtScale은 쿼리마다 하나의 엔진에 네이티브 SQL을 보내므로 분석 데이터를 Amazon Redshift Serverless에 통합한다. 운영 원장인 Amazon Aurora PostgreSQL의 데이터는 AWS Database Migration Service 또는 Amazon Aurora zero-ETL to Amazon Redshift로 복제한다.
- Semantic Modeling Language(SML)는 Git에서 버전 관리하는 개방형 YAML 명세다. 데이터셋, 차원, 계층, 팩트, 측정값, 계산, 관점, 행 보안을 정의하며, AtScale의 자율 집계 관리는 쿼리 패턴에 따라 웨어하우스에 요약 테이블을 구체화한다.
- Amazon Bedrock의 Anthropic Claude Sonnet 4.6은 질문을 해석하고 쿼리를 계획·작성하며, Amazon Bedrock AgentCore는 Strands 에이전트를 실행한다. 조인, 지표 정의, 호출자별 행·열 필터는 프롬프트가 아니라 AtScale 의미 계층에 둔다.
- AgentCore Gateway는 사용자 JWT를 검증하고 AtScale MCP 서버로 도구 호출을 전달하며, AgentCore Identity는 송신 경로에 자격 증명을 주입한다. AtScale은 토큰을 검증하고 호출자의 역할에 따라 접근을 통제하며, 에이전트 자체에는 토큰을 노출하지 않는다.
🧩 주요 포인트
- SQL·XMLA·MCP가 단일 AtScale 모델을 공유하므로, 에이전트와 BI 도구의 지표 해석 및 계산 결과를 일치시키는 기반이 된다.
- AtScale의 쿼리당 단일 엔진 실행 방식은 Amazon Redshift Serverless로의 사전 데이터 통합과 Amazon Aurora PostgreSQL 복제 경로를 아키텍처의 전제로 만든다.
- 쿼리 계획은 Claude Sonnet 4.6, 업무 정의와 접근 통제는 AtScale, 자격 증명 처리는 AgentCore Gateway·AgentCore Identity가 담당해 각 구성 요소의 책임을 구분한다.
🧠 상세 정리
1. 같은 C360 문제를 차원 모델로 구현
이 글은 AWS에서 의미 계층을 구축하는 연재의 세 번째 사례로, 첫 글의 Stardog 지식 그래프와 두 번째 글의 Denodo 데이터 가상화 플랫폼에 이어 AtScale을 적용한다. 세 사례는 고객 360(C360)이라는 동일한 업무 패턴을 유지하지만, AtScale은 트리플 그래프나 뷰 집합 대신 차원·계층·측정값으로 의미 모델을 구성한다. 모델은 개방형 YAML 명세인 Semantic Modeling Language(SML)로 작성하고 Git에서 버전 관리하며, 하나의 배포 모델을 SQL, XMLA, MCP로 동시에 노출한다. 이에 따라 Strands 에이전트와 기업이 기존에 사용하는 BI 도구가 동일한 정의를 바탕으로 같은 계산 결과를 얻는다는 것이 글의 핵심 주장이다. 설명의 기준 버전은 AtScale C2026.7이며, 구체적인 도구 이름과 엔드포인트는 AtScale 문서를 기준으로 삼는다.
2. 분석 데이터의 위치와 복제 전제
예제의 소매 기업은 고객 기록, 주문, 상품, 리워드 가입 정보를 여러 시스템에 보유하고 있으며, 업무 사용자는 각 사실이 어느 시스템에 있는지 몰라도 통합 질문을 할 수 있기를 원한다. 앞선 Stardog와 Denodo 사례가 쿼리 시점에 두 엔진을 연합하는 것과 달리, AtScale은 차원 쿼리를 네이티브 웨어하우스 SQL로 계획해 쿼리마다 하나의 엔진으로 보낸다. 따라서 이번 구성에서는 교차 엔진 데이터를 상류 단계에서 통합하고, 모든 분석용 C360 데이터를 Amazon Redshift Serverless에 둔다. Amazon Aurora PostgreSQL은 운영 원장으로 유지하며, AWS Database Migration Service 또는 Amazon Aurora zero-ETL to Amazon Redshift를 이용하는 복제 경로가 분석 사본을 최신 상태로 유지한다. 에이전트가 조회하는 대상은 이 Redshift 테이블들에 매핑된 단일 AtScale 모델이다.
3. 테이블 관계와 대표 고객 질문
Amazon Redshift의 예제 스키마는 customer, address, credit_card, rewards_account, purchase, product, category, vendor의 여덟 테이블로 구성된다. 고객과 구매는 cid, 구매와 상품은 pid, 상품과 카테고리는 dept로 연결되며, 분석 데이터가 한 웨어하우스에 있으므로 조인은 네이티브 SQL로 내려보낸다. 대표 질문은 ‘생애 누적 지출 기준 상위 20명 고객 중 아직 리워드 프로그램에 가입하지 않은 고객은 누구인가’로, Denodo 사례에서도 사용했던 요청을 그대로 가져온 것이다. 이 질문은 고객 프로필, 주소, 구매 이력, 가입 상태라는 네 논리 엔터티를 함께 사용하면서 고객별 한 행의 결과를 요구한다. 같은 질문을 유지하는 목적은 연재 독자가 서로 다른 의미 계층으로 동일한 업무 요청을 처리하는 방식을 비교할 수 있게 하는 데 있다.
4. SML 구성 요소와 자율 집계
SML에서 모델은 데이터셋, 차원, 팩트, 지표를 참조하고 AtScale 쿼리 엔진을 통해 제공하는 최상위 산출물이며, 각 SML 객체는 별도 YAML 파일로 표현된다. 차원은 고객·상품·날짜처럼 관련 속성을 묶고, 그 안의 계층은 연도·분기·월·일과 같이 속성을 단계적으로 조직한다. 팩트는 차원과 키로 연결되는 측정 가능한 이벤트 데이터셋이며, 측정값의 예로는 매출을 나타내는 SUM(price * quantity)가 제시되고 계산은 다른 측정값을 참조하는 파생 공식이다. 관점은 특정 역할이나 그룹에 공개할 차원과 측정값의 부분집합을 정하며, 행 보안은 호출자의 신원이나 속성에 따라 반환할 행을 필터링한다. 자율 집계 관리는 여러 소비자의 쿼리 패턴을 관찰해 비용이 충분히 큰 패턴의 요약 테이블을 웨어하우스에 구체화하고, 이후 일치하는 쿼리를 해당 집계로 투명하게 라우팅한다.
5. 사용자 질문에서 Redshift 조회까지
런타임 아키텍처는 사용자 요청을 받는 수신 경로와 의미 모델을 조회하는 송신 경로로 나뉜다. 수신 경로에서는 클라이언트가 AgentCore Gateway를 통해 질문을 보내고, Gateway가 기업 IdP를 기준으로 사용자의 JWT를 검증한 뒤 Strands 에이전트를 호스팅하는 AgentCore runtime으로 요청을 전달한다. 에이전트는 Amazon Bedrock의 Claude Sonnet 4.6을 호출해 질문을 해석하고 쿼리를 계획한다. 송신 경로에서는 AtScale MCP 서버를 Gateway의 MCP 대상으로 등록해 도구 호출을 중계하고, AgentCore Identity가 해당 구간에서 자격 증명을 주입한다. AtScale 엔진은 토큰을 검증하고 호출자를 AtScale 역할에 대응시킨 다음 배포된 C360 모델에 대한 쿼리를 계획하며, 요청은 Redshift 방향으로 내려가고 결과는 반대 경로로 돌아온다. 의미 모델이 사용하는 데이터의 기준은 Aurora에서 상류 복제로 갱신되는 Redshift 분석 사본이다.
6. 인증 정보와 업무 규칙의 책임 분리
AtScale MCP 서버의 제품 내 엔드포인트는 <atscale-host>/mcp이며, 개발 및 단일 신원 시나리오용 bearer token과 운영 경로용 OAuth 2.0 access token을 지원한다. 운영 경로의 access token은 AtScale에 포함된 Keycloak 인스턴스가 발급하고, AtScale 엔진은 이를 검증해 호출자의 역할을 판별한다. 글은 사람 사용자의 신원이 기업 IdP와 AgentCore Identity를 거쳐 AtScale로 이어지고, 쿼리 시점에 RBAC, 행 보안, 관점이 적용되는 구조를 설명 대상으로 삼는다. 조인, 지표 정의, 호출자별 행·열 필터는 프롬프트가 아니라 의미 계층에 있으므로, 모델은 해당 업무 정의를 소유하지 않은 채 쿼리를 계획한다. Gateway와 Identity가 런타임 경계에서 토큰을 관리하고 에이전트에는 토큰을 보이지 않게 하며, 에이전트는 대화와 도구 호출의 조정에 집중하도록 설계한다.
7. 데이터셋과 일곱 차원 구성
C360 모델 구축은 Redshift 테이블에 대응하는 데이터셋, 차원·계층과 이들 사이의 조인, 업무 논리를 표현하는 측정값·계산의 세 단계로 소개된다. 각 데이터셋은 물리 연결, 스키마, 테이블, 노출할 열을 선언하며, Design Center의 시각적 화면이나 텍스트 편집기 중 어느 쪽으로 작성해도 Git에는 같은 SML YAML 파일이 남는다. 모델의 일곱 차원은 dim_customer, dim_address, dim_rewards, dim_product, dim_category, dim_date, dim_vendor로 설명되며, 고객·주소·가입 정보와 상품·카테고리·날짜·공급업체 분석을 담당한다. dim_customer는 location 키로 dim_address에, cid로 dim_rewards에 연결되고, dim_product는 dim_category를 통해 상품 속성을 계층화한다. dim_rewards는 가입 고객마다 한 행을 가지며 account_id와 create_date를 포함하고 고객 차원에 연결되므로, 한 번도 가입하지 않은 고객은 가입 속성이 null로 나타난다.
8. 상품 계층 표현과 제공된 설명의 범위
AtScale의 계층 기능은 상품과 카테고리의 관계를 간결하게 표현하며, 모델 쿼리는 재귀 SQL 공통 테이블 식 없이 product → category → parent category 경로를 탐색할 수 있다고 설명한다. 이때 LLM에는 조인 그래프 대신 하나의 차원 경로가 제공되며, 제시된 dim_product.yml 예시는 product_category 계층에 department, category, product 수준을 선언한다. 예시 YAML은 category 데이터셋의 dept_name과 id, product 데이터셋의 id를 수준별 키로 사용하고, brand와 product_name을 보조 속성으로 둔다. 다만 제공된 원문은 이 예시 뒤의 ‘Facts and measures’ 설명이 시작되는 지점에서 잘려 있어, 실제 팩트·측정값 구현이나 이후 실행 절차는 확인할 수 없다. 도입부는 AtScale MCP 서버의 Gateway 등록, 신원 전달, AtScale Helm chart와 AtScale K8S Blueprints를 이용한 Amazon EKS 배포도 다룰 대상으로 예고하지만, 제공된 본문에는 해당 세부 절차가 포함되어 있지 않다.
🧾 핵심 주장 / 시사점
- 이 구성에서 의미의 일관성을 제공하는 중심은 SML 모델이다. 에이전트와 BI 도구가 같은 모델을 사용하므로 업무 지표를 각 소비자에 별도로 정의할 필요를 줄이는 방향이다.
- 쿼리 시점의 단일 엔진 실행은 상류 데이터 통합과 연결된다. 따라서 Redshift 분석 사본을 최신 상태로 유지하는 복제 경로가 C360 조회 구성의 중요한 전제다.
- 제공된 원문은 아키텍처와 모델 구성 원칙을 설명하지만 측정값 구현 도중에 끝난다. 예고된 전체 구축 과정을 실제로 검증할 수 있는 자료 범위와 구분해 읽어야 한다.
✅ 액션 아이템
- AtScale 단일 모델을 SQL·XMLA·MCP로 공유해 에이전트와 BI 도구의 지표 정의를 일치시키는 구성 검토.
- Amazon Redshift Serverless의 분석 데이터 통합과 Amazon Aurora PostgreSQL의 복제 경로 검토.
- AgentCore Gateway·AgentCore Identity의 자격 증명 처리와 AtScale의 역할별 접근 통제 연결 확인.
❓ 열린 질문
- SQL·XMLA·MCP로 제공하는 단일 AtScale 모델에서 에이전트와 BI 도구의 동일한 계산 결과를 어떻게 확인할 수 있는가?
- Amazon Aurora PostgreSQL에서 Amazon Redshift Serverless로 복제할 때 AWS Database Migration Service와 Amazon Aurora zero-ETL to Amazon Redshift 중 어떤 경로를 선택할 것인가?
- AgentCore Gateway·AgentCore Identity를 거친 사용자 신원을 AtScale의 역할과 어떻게 연결할 것인가?