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

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Denodo의 데이터 가상화 계층과 Amazon Bedrock AgentCore를 연결해 AWS와 온프레미스에 분산된 고객 데이터를 복제 없이 조회하고, 사용자별 권한을 적용하는 에이전트용 Customer 360 구성을 설명한다.

📌 핵심 요약

• 이전 글의 Stardog 기반 의미 계층을 Denodo Platform으로 바꾸고, Amazon Aurora의 고객 프로필과 Amazon Redshift의 주문 이력에 온프레미스 PostgreSQL의 rewards_account를 결합한다.
• 서로 다른 엔진의 고객·주문·리워드 데이터를 공통 식별자 cid로 조회 시점에 연결한다. 대표 질문은 평생 구매액 기준 상위 20명 중 리워드 프로그램에 가입하지 않은 고객을 찾는 것이다.
• Amazon Bedrock의 기반 모델이 질의를 계획하고 VQL을 작성하며, AgentCore에 호스팅된 Strands 에이전트는 AgentCore Gateway를 통해 Denodo MCP Server를 호출한다. 조인·지표 정의·사용자별 접근 필터는 의미 계층에서 관리한다.
• AgentCore Identity의 On-Behalf-Of 토큰 교환은 사용자 신원을 Denodo 대상의 범위 제한 토큰으로 전달한다. Denodo Virtual DataPort는 토큰을 독립적으로 검증하고 역할을 확인하며, Global Security Policy는 호출자별 행 필터와 열 마스킹을 조회 시점에 적용한다.
• Denodo Design Studio에서 원본 테이블에 대응하는 6개 base view를 만들고, 고객 단위의 customer_360 derived view와 재사용 가능한 lifetime_customer_value metric view를 구성하는 흐름을 제시한다. 제공된 본문은 base view와 Denodo Assistant의 작성 지원을 설명하던 중 끝난다.

🧩 주요 포인트

1. cid 연결을 의미 계층에 한 번 정의 → 엔진 간 외래 키나 이를 구축하는 ETL 없이 분산된 고객 정보를 조회 시점에 결합하고 여러 소비자가 재사용할 수 있다.
2. customer_360과 lifetime_customer_value의 역할 분리 → 고객 통합 구조와 구매액 계산 정의를 따로 관리하면서 여러 고객 뷰에서 같은 지표를 참조할 수 있다.
3. 사용자 신원 전달과 Denodo의 독립적인 권한 평가 결합 → 에이전트의 데이터 조회에도 호출자별 접근 제한을 적용할 수 있으나, 제공된 본문만으로 후속 정책 설정과 배포 절차 전체를 확인할 수는 없다.

🧠 상세 정리

1. Denodo로 확장하는 에이전트용 의미 계층

글은 에이전트형 AI가 운영 시스템, 분석용 웨어하우스, SaaS, 다른 클라우드와 온프레미스에 흩어진 최신 기업 데이터에 통제된 방식으로 접근해야 한다는 요구에서 출발한다. 이전 글은 Amazon Aurora와 Amazon Redshift 위에 Stardog 지식 그래프를 구성했지만, 이번에는 같은 Customer 360 패턴에 Denodo Platform을 사용한다. Denodo는 분산 데이터를 복제 없이 실시간으로 조회하는 AI 데이터 계층으로 소개되며, 에이전트는 Denodo의 SQL 방언인 VQL로 질의한다. 또 하나의 변화는 온프레미스 PostgreSQL이 추가되어 데이터 연합의 범위가 Amazon VPC 밖으로 넓어진다는 점이다. 기반 모델은 질의를 계획하지만 조인, 지표 정의, 호출자별 행·열 필터는 프롬프트가 아니라 의미 계층에서 관리한다. 글은 AWS 배포 방식으로 완전 관리형 서비스 Agora와 Amazon EC2 또는 Amazon EKS의 자체 관리 설치도 예고하지만, 제공된 본문에는 그 상세 절차가 나오지 않는다.

2. 고객·주문·리워드 데이터를 세 환경에 배치

예제는 이전 글의 Stardog C360 Knowledge Kit와 동일한 전자상거래 소매업체 모델을 사용하며, 고객 이탈 이해와 리워드 프로그램 자동 가입 대상 식별이라는 두 활용 사례를 유지한다. 스키마 자체는 바뀌지 않고 rewards_account 테이블의 위치만 Amazon Aurora에서 온프레미스 PostgreSQL로 이동한다. PostgreSQL 호환 Amazon Aurora에는 고객 프로필을 담는 customer, 주소를 담는 address, 카드 정보를 담는 credit_card가 있다. Amazon Redshift에는 주문 이력인 order와 상품 정보인 product가 있으며, 온프레미스 PostgreSQL의 rewards_account에는 고객별 리워드 계정 정보가 있다. 글은 이 배치를 예외적인 상황으로 보지 않고, 기업 데이터가 온프레미스나 CRM 같은 SaaS 또는 다른 클라우드에 존재하는 상황을 대표하는 예제로 설명한다. Denodo가 기본 지원하는 수백 개의 다른 데이터 소스로 확장하는 내용은 후속 절에서 다룬다고 안내하지만, 해당 절은 제공된 본문에 포함되지 않는다.

3. cid를 기준으로 조회 시점에 수행하는 연합

세 환경을 연결하는 공통 식별자는 정수형 cid이며, Aurora의 customer에서는 기본 키이고 Redshift의 order와 온프레미스 rewards_account에서는 외래 키가 아닌 일반 열이다. Aurora 내부에서는 customer.location이 address.id를 참조하는 정수형 외래 키이므로 고객 프로필과 주소를 연결할 수 있다. 반면 서로 다른 엔진을 가로지르는 외래 키나 이를 만드는 ETL 작업은 없어서, 구매 이력과 리워드 가입 상태를 결합하는 답변은 조회 시점에 cid를 맞춰야 한다. 대표 질문인 ‘평생 구매액 기준 상위 20명 중 아직 리워드 프로그램에 가입하지 않은 고객은 누구인가’에 답하려면 세 환경의 정보가 모두 필요하다. Denodo는 실행 시점에 Aurora와 Redshift에 어떤 처리를 넘기고 온프레미스에서 무엇을 가져올지 결정한 뒤 결과를 결합한다. 원본 데이터를 엔진 사이에 옮기지 않으면서도 의미 계층의 연결 정의를 한 번 선언해 여러 소비자가 재사용하는 것이 이 구성의 핵심이다.

4. VDP와 세 가지 뷰가 맡는 역할

Denodo는 의미 계층을 데이터 가상화 플랫폼으로 구현하며, 중심 엔진인 Denodo Virtual DataPort, 즉 VDP에 의미 계층 객체를 저장하고 VQL 실행과 접근 정책 평가를 수행한다. Design Studio는 이러한 객체를 정의하는 브라우저 기반 작성 도구이며, base view는 원본의 물리 테이블·API·파일을 VDP의 논리 뷰에 대응시킨다. derived view는 하나 이상의 base view나 다른 derived view를 대상으로 작성한 VQL 질의이고, 이 글의 customer_360이 여기에 해당한다. metric view는 lifetime_customer_value 같은 업무 지표를 한 번 정의해 다른 derived view가 참조하도록 하므로, 지표의 정의를 개별 질의와 분리한다. VQL은 ANSI 계열 SQL에 데이터 소스를 표현하는 DDL과 의미 지표 뷰 구문 등 Denodo 고유 요소를 더한 언어이며, 에이전트가 도구를 사용할 때 필요한 구문은 스킬로 제공된다고 설명한다. Global Security Policy는 특정 태그가 붙은 뷰나 열에 적용되는 실행 시점 접근 규칙으로, 호출자별 행 필터와 열 마스킹을 담당한다.

5. 사용자 요청에서 모델의 질의 계획까지

참조 아키텍처는 사용자 요청이 들어오는 경로와 에이전트의 도구 호출이 나가는 경로를 구분해 설명한다. 수신 경로에서는 클라이언트가 Amazon Bedrock AgentCore Gateway를 통해 사용자의 요청을 보내며, Gateway는 사람 사용자를 식별하는 JWT를 기업의 신원 제공자에 대조해 검증한다. 검증된 요청은 Strands 에이전트 프로세스를 호스팅하는 Amazon Bedrock AgentCore runtime으로 전달된다. 에이전트는 Amazon Bedrock의 기반 모델을 호출해 프롬프트를 해석하고 질의를 계획하며, 이 예제에서 사용하는 모델은 Anthropic Claude Sonnet 4.6이다. 이 역할 분담에서 모델은 질문을 데이터 조회로 바꾸는 계획을 맡고, 실제 데이터 연결 구조와 업무 지표 및 접근 제한은 Denodo의 의미 계층이 맡는다. AgentCore는 특정 프레임워크나 모델에 한정되지 않고 에이전트를 구축·연결·최적화하는 플랫폼으로 소개되며, 이 구성에서는 실행 환경과 인증·자격 증명 처리에 관여한다.

6. 토큰 교환과 Denodo의 독립적인 권한 평가

송신 경로에서도 AgentCore Gateway가 에이전트의 도구 호출을 중계하며, Denodo MCP Server를 Gateway의 MCP target으로 등록해 기업 데이터 요청을 해당 서버로 보낸다. 요청이 Denodo에 도착하기 전에 AgentCore Identity는 On-Behalf-Of 토큰 교환으로 사용자의 수신 토큰을 같은 사용자를 나타내면서 Denodo를 대상으로 하는 범위 제한 접근 토큰으로 바꾼다. Denodo MCP Server는 교환된 토큰을 bearer 자격 증명으로 받아들이고, VQL 요청을 JDBC를 통해 VDP로 전달한다. VDP는 토큰을 독립적으로 검증하고 호출자에 대응하는 Denodo 역할을 확인한 다음 접근 정책을 적용하고 세 데이터 소스에 대한 연합 질의를 계획한다. 아래로는 VQL 요청이 전달되고 위로는 결과 집합이 반환되며, 각 원본 엔진은 VDP의 연합 최적화기가 다시 작성한 네이티브 SQL을 처리한다. 행·열 제한은 호출자별로 조회 시점에 적용된다고 설명하지만, 제공된 부분에는 개별 정책의 구체적인 정의나 토큰 교환 설정 예제가 없다.

7. base view에서 고객 뷰와 공통 지표로 확장

Denodo의 의미 모델은 단일 파일이나 객체가 아니라 base view, derived view, metric view와 태그가 함께 업무상 의미 있는 데이터를 제공하는 구성이다. 글은 먼저 각 원본 테이블의 base view를 만들고, 이를 cid로 고객 단위에서 연결하는 customer_360 derived view를 구성한 다음, 필요한 질의에서 결합할 수 있는 lifetime_customer_value metric view를 정의하는 세 단계 흐름을 제시한다. 실제 모델링은 Design Studio의 시각적 화면에서 소스를 캔버스에 배치하고 연결 관계를 그리는 방식으로 진행한다고 설명한다. 필드 이름이나 자료형도 양식에서 변경할 수 있으며, cust_ref를 customer_id로 매핑하는 예시가 제시된다. 뒤에서 다룰 보안 정책을 연결하는 작업 역시 같은 UI에서 수행한다. metric view는 이를 참조하는 derived view와 나란히 관리되므로, 두 팀이 같은 원본 데이터로 서로 다른 고객 뷰를 만들더라도 동일한 지표 정의를 사용할 수 있다.

8. 6개 base view와 태그·키 설정

Aurora의 customer 테이블을 base view로 만들 때는 Design Studio에서 해당 커넥터와 스키마를 지정하고, VDP가 열 정보를 조사해 물리 열과 논리 열을 일대일로 대응시키도록 한다. 이 단계의 base view는 원본 데이터를 변환하지 않으며, customer의 ssn과 credit_card의 card_num에는 나중에 Global Security Policy가 연결될 pii_sensitive 태그를 붙인다. cid는 aurora_customer의 기본 키이자 redshift_order와 postgres_rewards_account의 연결 필드로 지정하고, 원본 메타데이터에서 기본 키를 추론할 수 없으면 base view 정의에 직접 설정한다. 같은 과정을 반복하면 aurora_customer, aurora_address, aurora_credit_card, redshift_order, redshift_product, postgres_rewards_account의 6개 base view가 만들어진다. Denodo Assistant는 자연어 설명으로 VQL 정의 후보를 제안하며, 개발자는 저장 전에 같은 캔버스에서 검토하고 후속 프롬프트로 필터·조인·필드 매핑을 반복 조정할 수 있다. 제공된 본문은 이 작성 지원에 적용되는 거버넌스와 자료형 규칙을 언급하던 중 끊기므로, 이후 구현 내용까지 확인된 것으로 해석할 수는 없다.

🧾 핵심 주장 / 시사점

• 이 구성은 모델이 연결 관계와 지표 계산을 매번 새로 정하기보다, Denodo에 정의된 업무 의미를 바탕으로 질의를 계획하도록 역할을 나눈다.
• 온프레미스 rewards_account의 추가는 Customer 360의 데이터 배치 범위를 넓히지만, 공통 식별자 cid와 조회 시점의 연합이라는 결합 원리는 유지한다.
• 사용자 신원을 Denodo까지 전달하고 VDP에서 다시 검증하는 구조는 데이터 접근 제한을 실제 질의 실행 지점에서 평가하게 한다. 다만 제공된 본문은 상세 정책 설정과 배포 검증까지 보여주지는 않는다.

✅ 액션 아이템

• Amazon Aurora·Amazon Redshift·온프레미스 PostgreSQL의 cid 연결과 상위 20명 중 리워드 미가입 고객 조회에 필요한 데이터 대응 관계 확인.
• customer_360의 고객 통합 구조와 lifetime_customer_value의 구매액 계산 정의를 분리해 재사용하는 구성 검토.
• On-Behalf-Of 토큰 교환과 Global Security Policy의 호출자별 접근 제한 설정은 제공된 본문에 없는 후속 설명 확인 필요.

❓ 열린 질문

• 평생 구매액 기준 상위 20명 중 리워드 미가입 고객을 찾을 때 lifetime_customer_value는 customer_360과 구체적으로 어떻게 결합되는가?
• On-Behalf-Of 토큰 교환으로 전달된 사용자 신원은 Denodo 역할에 어떤 규칙으로 연결되는가?
• Global Security Policy의 호출자별 행 필터와 열 마스킹은 어떤 구체적인 정책으로 설정되는가?