Build a semantic layer for agentic AI on AWS with Strategy Mosaic and Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Strategy Mosaic은 Amazon Redshift와 Amazon Aurora의 C360 데이터를 두 연결 모델로 통합하고, 지표 정의와 사용자별 보안을 의미 계층에서 관리해 Amazon Bedrock AgentCore의 AI 에이전트에 제공한다.

📌 핵심 요약

• Mosaic은 속성·계층·팩트·지표로 구성되는 차원형 의미 계층이며, 하나의 정의를 MCP, Trino 기반 JDBC/ODBC, XMLA, REST로 제공한다. 글의 기준 버전은 MCP 서버를 통한 Mosaic 접근이 기본 제공되기 시작한 Strategy One의 2026년 3월 릴리스다.
• C360 예제는 Amazon Redshift의 구매·상품 데이터를 Purchase 모델로, Amazon Aurora PostgreSQL-compatible의 고객·주소·신용카드·리워드 데이터를 Customer 모델로 구성한다. Customer와 Time 속성으로 모델을 연결하고 소스별 쿼리 결과를 Mosaic에서 결합하므로 ETL이나 별도의 세 번째 데이터 사본이 필요하지 않다.
• Mosaic은 기본 지표, 이름 있는 필터를 사용하는 고급 지표, 집계 수준을 고정하는 수준 한정자, 다른 지표를 조합하는 복합 지표로 업무 정의를 표현한다. 대표 질문은 평생 지출액 기준 상위 20명 중 리워드 프로그램에 가입하지 않은 고객을 찾는 것이다.
• Amazon Bedrock AgentCore에서 실행되는 Strands 에이전트는 Anthropic Claude Sonnet 4.6으로 질문을 해석하고 Mosaic MCP 엔드포인트를 직접 호출한다. Mosaic은 사람 사용자를 나타내는 OAuth 2.0 토큰을 확인하고 Use MCP Server 권한, 인증된 모델 제한, 사용자별 RLS·OLS를 적용한다.
• 모델별 실행 방식에는 소스로 쿼리를 보내는 live pushdown과 Mosaic 내부 큐브를 사용하는 in-memory가 있다. 제공된 본문은 모델 연결 설명 도중 끝나므로 실행 방식의 선택 기준, 전체 인증 구현 절차, Apache Ossie 내보내기의 세부 내용은 확인할 수 없다.

🧩 주요 포인트

1. Customer와 Time에 선언한 모델 연결이 소스 간 결합 범위를 결정하므로, 에이전트의 C360 분석 가능 범위는 데이터 소스의 접근 가능 여부뿐 아니라 의미 모델 설계에 달려 있다.
2. 지표·필터·집계 수준과 RLS·OLS를 Mosaic에 두므로, 업무 계산과 접근 통제의 기준을 에이전트 프롬프트에서 분리하고 여러 소비 경로에 같은 정의를 제공할 수 있다.
3. 사람 사용자 신원의 전달과 인증된 모델 제한이 MCP 접근을 통제하며, live pushdown과 in-memory의 선택은 별도 검토가 필요하다. 제공된 본문만으로는 실행 방식의 성능 차이나 선택 기준을 판단할 수 없다.

🧠 상세 정리

1. 연속 기고에서 Mosaic이 맡는 의미 계층

이 글은 AWS에서 동일한 고객 360(C360) 문제를 서로 다른 의미 계층으로 해결하는 연속 기고의 세 번째 사례로, Strategy의 Zhili Cheng, George Earle, Kyler K와 공동 작성됐다. 첫 글은 Amazon Aurora와 Amazon Redshift 위에 Stardog 지식 그래프를 구축했고, 두 번째 글은 Denodo 데이터 가상화로 바꾸면서 온프레미스 PostgreSQL까지 소스를 확장했다. 이번 사례의 Mosaic은 속성·계층·팩트·지표를 사용하는 차원형 모델이며, RDF·IRI·SPARQL을 사용하는 Stardog이나 VQL 뷰를 구성하는 Denodo와 모델링 방식이 다르다. Mosaic에서는 연결 모델이 소스 통합의 단위가 되며, 조인과 지표 정의 및 호출자별 행·열 필터는 에이전트 프롬프트가 아니라 의미 계층 안에 위치한다. 글은 앞선 Stardog 기고의 의미 계층 아키텍처에 익숙한 독자를 전제로 설명을 이어간다.

2. 하나의 정의를 여러 도구에 제공하는 방식

Mosaic은 하나의 의미 모델 정의를 네 가지 기본 프로토콜로 제공한다. AI 에이전트는 MCP를 사용하고, SQL 클라이언트는 Trino 기반 JDBC/ODBC를 사용하며, Power BI와 Excel은 XMLA로, 맞춤형 애플리케이션은 REST로 접근한다. 지원 소스에는 Snowflake와 Databricks 같은 클라우드 웨어하우스, Amazon RDS·Oracle·SQL Server 같은 운영 데이터베이스, Amazon Athena·Trino·SAP HANA 같은 분석 엔진과 Salesforce 같은 SaaS가 포함된다. 따라서 연결 모델 방식의 적용 범위는 이 예제의 Amazon Redshift와 Amazon Aurora 조합에 한정되지 않는다. 글은 같은 관리된 정의를 Power BI, Tableau, 노트북, 맞춤형 앱에 제공하고 Apache Ossie 형식으로 내보내는 방법도 학습 목표로 제시하지만, 제공된 본문에는 그 구현 설명이 없다. 설명의 기준은 MCP 서버를 통한 Mosaic 접근이 기본 제공되기 시작한 Strategy One의 2026년 3월 릴리스다.

3. 모델·속성·계층과 업무 지표의 표현

Mosaic Schema는 중앙에서 관리하는 기업 모델이고, Mosaic Models는 Mosaic Studio에서 제공하는 셀프서비스·AI 지원 모델링 경로이며, 이 예제는 Mosaic Models를 사용한다. 모델은 물리 테이블 위에 속성·지표·계층·보안 규칙을 정의하는 최상위 구성물로, 속성은 조인에 쓰는 ID 형식과 사람이 읽는 표시 형식 등을 함께 가질 수 있다. 이 구조를 통해 Mosaic은 Carolyn Inworth 같은 이름을 내부 cid로 해석하며, 계층은 Category에서 Department로 또는 Address에서 City와 State로 이어지는 관계를 표현한다. 팩트는 숫자 열이고 지표는 이를 집계하는 정의이며, 본문은 Purchase Amount = price * quantity를 기본 지표의 예로 든다. 고급 지표는 Purchase Amount > 500이라는 조건을 가진 [Large Orders] 같은 이름 있는 필터를 참조하고, 수준 한정자 {~+, !Customer+}는 질의의 분할 방식과 관계없이 집계 단위를 Customer로 고정한다. 복합 지표는 다른 지표들을 수식으로 조합하므로, 계산·조건·집계 단위를 의미 계층에서 명시할 수 있다.

4. C360 데이터 구성과 상위 고객의 미가입 여부

예제의 스키마는 Stardog의 C360 Knowledge Kit에서 가져와 조정했으며, 앞선 기고와 같은 엔터티·키·대표 질문을 유지한다. 소매 조직의 운영 데이터인 고객 기록·주소·신용카드·리워드 가입 정보는 Amazon Aurora PostgreSQL-compatible에 있고, 주문·상품·상품 분류·공급업체 정보는 Amazon Redshift에 있다. 두 데이터베이스가 공유하는 cid는 Aurora의 customer 테이블에서는 기본 키지만 Redshift의 purchase 테이블에서는 일반 열이며, 서로 다른 엔진 사이에는 이를 연결하는 SQL 제약 조건이 없다. 따라서 고객과 주문을 함께 분석하려면 이 식별자의 대응 관계를 별도로 처리해야 하며, Mosaic은 물리적으로 저장한 엔진 간 조인 대신 모델 연결로 이를 해결한다. 대표 질문은 평생 지출액 기준 상위 20명 중 아직 리워드 프로그램에 가입하지 않은 고객을 찾는 것으로, Aurora의 고객·가입 정보와 Redshift의 지출 집계에 의미 계층의 순위 및 필터 정의를 함께 적용해야 한다.

5. 두 모델의 연결과 소스별 쿼리 실행

Purchase 모델은 Amazon Redshift에, Customer 모델은 Amazon Aurora PostgreSQL-compatible에 각각 연결되며, 두 모델은 Customer와 Time 속성을 통해 결합된다. Mosaic은 질의 시 서로 다른 엔진의 원시 행을 직접 연합하는 대신 소스마다 쿼리를 계획하고 해당 소스의 네이티브 SQL로 필요한 집계를 실행한다. 이어서 각 소스가 반환한 중간 결과를 Mosaic 엔진에서 연결 속성에 따라 결합하므로, ETL이나 별도의 세 번째 데이터 사본 없이 두 영역을 함께 조회한다. 예를 들어 Wisconsin의 지출 상위 고객을 묻는 경우에는 address의 주 정보와 purchase의 지출 정보가 각각 필요하며, 모델 연결이 두 결과를 함께 해석할 기준을 제공한다. 소스 두 개에 접근할 수 있다는 사실만으로 결합이 가능해지는 것은 아니며, 모델 작성자가 선언한 연결이 있어야 에이전트가 그 관계를 따라갈 수 있다는 점이 핵심 제약이다.

6. AgentCore와 Strands의 요청 처리 경로

참조 아키텍처는 클라이언트에서 에이전트로 들어오는 인증 경로와 에이전트에서 데이터로 나가는 조회 경로를 구분한다. 인바운드에서는 클라이언트가 사용자 질문을 Amazon Bedrock AgentCore Gateway로 보내고, Gateway가 기업 IdP를 기준으로 사람 사용자를 식별하는 JWT를 검증한 뒤 Strands 에이전트가 있는 AgentCore runtime으로 전달한다. 에이전트는 Amazon Bedrock의 Anthropic Claude Sonnet 4.6을 호출해 질문을 해석하고 조회를 계획한다. 아웃바운드에서는 에이전트의 MCP 도구가 HTTPS로 https://<env-domain>/collaboration/mcp/mosaic 엔드포인트에 직접 연결하고 Authorization: Bearer 헤더에 OAuth 2.0 접근 토큰을 담는다. Mosaic은 해당 호출을 처리하면서 연결된 Purchase·Customer 모델에 맞춰 소스별 SQL을 생성하고, Amazon Redshift와 Amazon Aurora가 그 SQL에 응답한다.

7. 사람 사용자 신원을 유지하는 접근 통제

Mosaic은 전달받은 OAuth 2.0 접근 토큰을 자체에 포함된 OAuth 인가 서버로 검증하고, 호출자를 Strategy 사용자로 식별한다. 이어 Use MCP Server 권한과 인증된 모델만 접근할 수 있다는 제한을 적용한 뒤, 해당 사용자의 행 수준 보안인 RLS와 객체 수준 보안인 OLS에 따라 행·열 접근을 평가한다. 본문이 강조하는 조건은 Mosaic에 도달하는 토큰이 서비스 계정이 아니라 실제 사람 사용자를 나타내므로, RLS와 OLS가 그 사용자의 신원을 기준으로 종단 간 적용된다는 점이다. AWS Secrets Manager는 호출 사이에 사용자의 갱신 토큰을 보관하지만, 전체 신원 전달 절차를 다룬다고 예고한 후속 절의 내용은 제공된 범위에 없다. 기존 Mosaic Schema가 있는 조직은 모델 속성을 그 스키마에 매핑해 차원·객체 ACL·RLS를 상속할 수 있으며, 글은 이미 관리되는 스키마가 있다면 이를 초기에 연결하도록 권한다.

8. 모델 구축 순서와 제공된 설명의 한계

구축은 Mosaic Studio의 Design Center에서 각 소스의 데이터셋과 조인을 정의하고, 속성·계층을 구성한 다음, 업무 로직을 담는 지표를 작성하는 세 단계로 진행된다. Purchase 내부에는 purchase.pid = product.id, product.dept = category.id, product.brand = vendor.id와 분류 상위 관계를 위한 category.parent = category.id가 선언된다. Customer 내부에는 customer.location = address.id, customer.cid = credit_card.cid, customer.cid = rewards_account.cid가 정의되며, 두 모델 사이에 물리적 조인을 만들지는 않는다. 실행 방식은 모델별로 소스에 쿼리를 보내는 live pushdown과 Mosaic 내부 큐브에서 답을 구하는 in-memory로 구분된다. 다만 제공된 본문은 모델 경계에 따른 도메인 소유권을 설명하기 시작한 지점에서 끊겨 있어, 실행 방식의 구체적인 선택 기준이나 이후 구축 절차까지 확인할 수는 없다.

🧾 핵심 주장 / 시사점

• 의미 계층의 역할은 업무 용어 설명을 넘어, 소스 간 결합 관계와 집계 단위 및 접근 통제를 실행 가능한 규칙으로 고정하는 데 있다.
• 같은 정의를 여러 프로토콜로 제공하는 구조에서는 에이전트와 분석 도구가 계산 기준을 공유할 수 있지만, 소스 간 분석 범위는 선언된 모델 연결에 의해 제한된다.
• 사용자별 보안의 성립 조건과 실행 방식의 적합성은 구분해 검토해야 한다. 본문은 사용자 신원에 따른 통제 구조를 설명하지만, live pushdown과 in-memory의 성능 비교 근거는 제공하지 않는다.

✅ 액션 아이템

• C360의 Purchase·Customer 모델에 필요한 Customer와 Time 연결 및 지표·필터·집계 수준 정의를 검토한다.
• Mosaic MCP 접근에서 사람 사용자의 OAuth 2.0 신원과 Use MCP Server 권한, 인증된 모델 제한, RLS·OLS 적용을 확인한다.
• live pushdown과 in-memory의 선택 기준은 제공된 본문으로 판단할 수 없으므로 추가 설명을 확인한 뒤 결정한다.

❓ 열린 질문

• 평생 지출액 기준 상위 20명 중 리워드 프로그램 미가입 고객을 찾을 때 Mosaic의 지표·필터·집계 수준은 구체적으로 어떻게 정의되는가?
• Amazon Bedrock AgentCore에서 Mosaic까지 사람 사용자의 OAuth 2.0 신원을 전달하고 RLS·OLS를 유지하는 전체 인증 구현 절차는 무엇인가?
• 에이전트의 C360 조회에서 live pushdown과 in-memory를 선택하는 기준과 성능 차이는 무엇인가?