Build a semantic layer for agentic AI with EDB Postgres AI and Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

EDB Postgres AI의 AIDB 확장으로 운영 Postgres 안에 의미 계층을 만들고, Amazon Bedrock AgentCore에서 실행하는 에이전트가 MCP를 통해 업무 의미와 데이터 접근 권한을 반영한 C360 질의에 활용하는 구성을 설명한다.

📌 핵심 요약

• Strands Agents 에이전트는 Amazon Bedrock AgentCore에서 실행되며, Amazon Bedrock의 Anthropic Claude를 계획과 질의 작성에 사용한다. EDB Postgres AI의 SemKB는 스키마와 COMMENT ON 설명을 함께 색인하고, 외래 키에서 조인 관계를 파악한다.
• C360 예제는 customers, locations, products, purchases의 네 테이블과 big_spender 뷰로 구성된다. 고객의 주는 locations.state에 있으며, purchases.price는 단가가 아닌 주문 총액이다. 이를 quantity와 다시 곱하면 최상위 고객의 지출액이 올바른 $27,991.66 대신 $502,529로 계산된다.
• big_spender는 250달러를 초과하는 주문이 한 번 이상 있는 고객으로 정의한다. COMMENT ON으로 의미를 설명한 뷰에 이 정의를 모으고, big_spenders_by_state 같은 semantic alias로 반복 질문에 사용할 읽기 전용 SELECT를 등록한다.
• AgentCore Gateway는 Amazon Cognito의 JWT와 Cedar 정책으로 접근을 제어하고, ALB를 통해 AIDB의 MCP 서버에 직접 연결한다. AgentCore Identity가 Postgres 역할 자격 증명을 HTTP Basic 인증에 주입하며, Postgres GRANT·열 단위 권한·행 수준 보안이 실제 데이터 접근을 집행한다.
• c360_kb는 bge-small-en-v1.5-f16 모델과 Live 모드로 생성한다. 여러 SemKB가 있으면 검색 시 kb_name을 명시해야 하며, 변경 처리 방식은 Live·Background·Disabled 중 선택한다. AgentCore 추적은 CloudWatch로, 설정된 AIDB SQL 실행 추적은 Postgres의 aidb_otel 스키마로 수집된다.

🧩 주요 포인트

1. 업무 의미를 운영 Postgres에 배치 → COMMENT ON, 외래 키, 뷰, semantic alias를 함께 활용해 purchases.price의 오해를 줄이고 big_spender 정의를 일관되게 재사용한다.
2. MCP 연결과 데이터 권한을 계층별로 집행 → AgentCore Gateway는 도구 호출을 통제하고 Postgres GRANT와 행 수준 보안은 데이터 접근을 제한하므로, 같은 프롬프트·도구 목록·에이전트 코드에서도 호출자 역할에 따라 결과가 달라질 수 있다.
3. SemKB는 데이터가 아닌 스키마를 색인 → Live·Background·Disabled에 따른 변경 반영 방식과 복수 SemKB의 kb_name 지정이 검색 운영의 핵심 조건이며, CloudWatch와 aidb_otel은 각각 에이전트 활동과 SQL 실행을 관찰하는 경로를 제공한다.

🧠 상세 정리

1. 운영 Postgres 안에 배치하는 의미 계층

글은 EDB Postgres AI의 AIDB 확장으로 운영 Postgres 데이터베이스 안에 의미 계층을 만들고, Amazon Bedrock AgentCore에서 실행하는 Strands Agents 에이전트가 이를 조회하는 C360 구성을 소개한다. 앞선 연재에서는 같은 패턴을 Stardog의 지식 그래프, Denodo의 데이터 가상화 플랫폼, AtScale의 차원 모델, Strategy Mosaic의 연결 모델로 구현했다. 여기서도 에이전트에 필요한 요소는 질의를 계획하고 작성하는 모델, 데이터의 업무 의미를 알려 주는 계층, 실행과 신원·접근을 관리하는 런타임의 세 가지다. 모델은 Amazon Bedrock의 Anthropic Claude이며 가용성은 AWS Region에 따라 달라지고, 실행 환경은 AgentCore runtime이다. 이번 구성의 차이는 스키마와 업무 정의를 SemKB에 함께 색인하고, 접근 통제를 권고성 시스템 프롬프트가 아닌 Postgres의 권한 체계로 집행한다는 점이다.

2. C360 데이터 모델과 검증할 업무 질문

예제 데이터는 Stardog C360 Knowledge Kit에서 가져와 단일 EDB Postgres AI 인스턴스의 전용 c360 스키마에 적재하며, 네 테이블과 하나의 파생 뷰로 구성한다. customers에는 고객 식별자와 이름, 이메일, ssn, 전화번호, 주소 참조 등이 있고, locations에는 도시·주·우편번호가 저장된다. products는 상품과 가격 정보를 담고, purchases는 고객·상품 외래 키와 구매 날짜, 수량, 가격을 연결하며, big_spender 뷰는 고객별 주와 고액 주문 정보를 제공한다. 물리적 관계는 고객이 특정 주소에 살고 구매를 하며 각 구매가 상품을 참조하는 일반적인 Postgres 조인 구조다. 에이전트에 제시하는 질문은 지출액 기준 상위 10명과 거주 주, 주별 big spender 수, 고객 10명의 거주 주, 판매 수량 상위 10개 상품이다. 고객 5명의 Social Security number를 요청하는 질문도 제시되지만, 제공된 본문에는 이를 이용한 권한별 재실행 결과가 포함되어 있지 않다.

3. 열 이름만으로 알 수 없는 세 가지 업무 의미

의미 계층이 해결하려는 첫 번째 문제는 고객의 주 정보가 customers 행에 직접 들어 있지 않다는 점으로, customers.location 외래 키를 따라 locations.state를 찾아야 한다. 두 번째는 purchases.price가 상품 단가가 아니라 고객이 해당 주문 전체에 지불한 금액이라는 사실이며, 이 구분은 집계 결과를 크게 바꾼다. 원문은 이를 단가로 오해해 quantity를 다시 곱하면 최상위 고객의 지출액이 $27,991.66이 아니라 $502,529로 계산된다고 설명한다. 세 번째는 big spender가 열 이름에서 자연스럽게 도출되는 속성이 아니라 업무에서 정한 용어라는 점이다. 글은 이 정의를 뷰와 COMMENT ON VIEW에 담아 에이전트, 대시보드, 질의가 같은 기준을 읽도록 구성하며, 각각의 소비자가 고액 고객의 의미를 따로 정의할 필요를 줄인다.

4. AgentCore에서 AIDB까지 이어지는 인증과 요청 경로

사용자는 Amazon Cognito에서 인증받아 발급된 JWT를 Bearer 토큰으로 AgentCore Gateway에 전달하며, Gateway의 인바운드 JWT 인가 구성은 Cognito discovery URL을 기준으로 토큰을 검증한다. 이어 Cedar 정책이 토큰의 클레임을 평가해 해당 사용자를 대신하는 에이전트가 호출할 수 있는 도구를 결정하고, 요청은 AgentCore runtime으로 전달된다. 에이전트는 Amazon Bedrock의 Claude로 계획과 응답을 구성하고, 의미 계층이 필요할 때 Gateway를 통해 MCP 도구를 호출한다. 외부 연결 경로에서는 HTTPS 리스너와 AWS Certificate Manager 인증서를 갖춘 ALB가 Amazon EC2 인스턴스의 edb-endpoints 서버 앞에 위치하며, ALB URL을 Gateway의 MCP 대상에 등록한다. AgentCore Identity는 Postgres 역할 자격 증명을 보관하고 매번 나가는 요청에 HTTP Basic 인증으로 주입하므로, 에이전트 코드는 해당 자격 증명을 직접 보지 않는다. AIDB가 제공하는 SemKB·semantic alias·읽기 전용 테이블에 대한 실제 데이터 접근은 Postgres 역할, 열 단위 GRANT, 행 수준 보안으로 통제한다.

5. 직접 MCP 연결과 두 관측 경로

AIDB의 edb-endpoints HTTP 서버는 HTTP Basic 인증을 사용하는 streamable HTTP MCP를 지원하므로, AgentCore Gateway가 이를 MCP 서버 대상으로 직접 취급할 수 있다. 따라서 ALB를 통과하는 연결에 별도의 변환 계층이나 AWS Lambda가 필요하지 않으며, 원문은 앞선 Denodo 사례도 같은 ALB 패턴을 사용했다고 설명한다. 관측 경로는 에이전트 측과 데이터베이스 측으로 나뉘어, AgentCore는 도구 호출, 대규모 언어 모델 호출, 토큰 사용량 추적을 CloudWatch Transaction Search로 보낸다. AIDB는 SQL 실행의 OpenTelemetry 추적을 Postgres 내부 aidb_otel 스키마의 행으로 기록해 일반 SQL로 조회할 수 있게 한다. 다만 데이터베이스가 해당 추적을 기록하도록 먼저 설정되어 있어야 하므로, 글의 설명은 구성 조건이 충족된 상태에서의 관측 기능을 전제로 한다.

6. COMMENT ON과 뷰로 업무 정의 작성

구축 절차는 AIDB가 설치·활성화되어 있고 C360의 CSV 네 개가 기본 키와 외래 키를 갖춘 c360 스키마에 적재되어 있다는 전제에서 시작한다. 의미 계층이 원본 데이터와 같은 데이터베이스에 있으므로 별도 시스템을 배포하거나 별도 카탈로그를 동기화할 필요 없이 SQL로 정의한다. 작성 작업은 COMMENT ON 설명, 설명이 붙은 업무 용어 뷰, 반복 질문을 담는 semantic alias의 세 가지이며, 원문은 이 가운데 주석이 가장 단순하면서 text-to-SQL 정확도 개선 효과가 크다고 설명한다. 예제 주석은 purchases.price가 미국 달러 기준 주문 총액임을 명시하고, purchases.cid와 customers.location의 조인 대상 및 주 정보의 위치를 알려 주며, customers.ssn이 열 단위 권한을 요구하는 민감 정보라고 설명한다. big_spender 뷰는 주문 금액이 250달러를 초과하는 행을 고객과 주소에 조인한 뒤 고객·이름·주별로 묶어 주문 수와 최대 주문액을 계산한다. 여기에 250달러 초과 주문이 한 번 이상 있는 고객이라는 설명과 관련 질문에는 이 뷰를 사용하라는 주석을 붙여 업무 정의를 한곳에 둔다.

7. SemKB 생성과 스키마 변경 반영

SemKB는 데이터 행이 아니라 Postgres 스키마를 색인하며, 테이블·뷰·열의 정의와 COMMENT ON 설명을 함께 임베딩해 에이전트가 자연어로 검색하도록 한다. 예제는 aidb.create_semantic_kb로 c360_kb를 만들고, 대상 스키마를 c360, 모델을 bge-small-en-v1.5-f16, auto_processing을 Live로 지정한다. 이 모델은 AIDB AMI에 포함된 로컬 llama.cpp 임베딩 모델이며, 하나의 KB는 모든 항목이 같은 벡터 공간에 놓이도록 하나의 임베딩 모델을 사용한다. AMI에는 public 스키마를 대상으로 하는 기본 semkb가 이미 있으므로 c360_kb를 추가하면 두 KB가 존재하고, 이후 모든 aidb.semantic_kb_search 호출에 kb_name을 명시해야 한다. Amazon Bedrock의 Amazon Titan Text Embeddings 같은 원격 모델을 쓰려면 aidb.create_model로 등록한 이름을 SemKB의 model 매개변수에 전달한다. 변경 처리 방식은 이벤트 트리거로 반응하는 Live, 작업자가 비동기로 처리하는 Background, aidb.refresh_semantic_kb() 호출을 기다리는 Disabled이며, SemKB는 외래 키도 탐색해 의미로 발견할 수 있는 조인 관계로 반영한다.

8. 반복 질문을 재사용하는 semantic alias

semantic alias는 이름과 자연어 설명을 갖춘 매개변수화 가능한 읽기 전용 SELECT로, SemKB가 스키마 메타데이터와 함께 색인하는 재사용 단위다. 에이전트는 질문의 의미로 alias를 찾고 필요한 매개변수를 전달해 호출하며, 데이터 접근 통제가 적용된 답을 반환받는 방식으로 활용한다. 예제는 aidb.create_semantic_alias를 사용해 big_spenders_by_state를 등록하고, big spender 수를 주별로 집계해 많은 순서로 보여 준다는 설명을 붙인다. 실제 질의는 c360.big_spender를 state로 묶어 고객 수를 계산하고, 집계값의 내림차순과 주 이름 순서로 정렬하며, 이 예제의 매개변수 목록은 비어 있다. alias는 테이블·뷰와 함께 SemKB 색인에 놓이고 에이전트에는 도구로 나타나므로, 이미 정의된 업무 의미를 반복 질문에서 다시 활용하는 text-to-SQL 구성 요소가 된다. 제공된 본문은 이후의 전체 text-to-SQL 설명을 안내하는 문장에서 끝나며, 실제 에이전트 실행 결과나 역할별 응답 비교까지 제시하지는 않는다.

🧾 핵심 주장 / 시사점

• 질의가 실행 가능한지만 확인해서는 업무 정확성을 보장할 수 없다. purchases.price의 사례는 열의 의미를 잘못 해석하면 정상적으로 실행되는 SQL도 지출액을 크게 왜곡할 수 있음을 보여 준다.
• 업무 정의를 뷰에 두고 COMMENT ON과 semantic alias로 연결하면, 의미 검색과 반복 질의가 같은 정의를 공유한다. big_spender는 이러한 재사용 구조를 보여 주는 예다.
• AgentCore의 도구 호출 통제와 Postgres의 데이터 접근 통제는 서로 다른 지점에서 작동한다. 원문은 역할에 따른 결과 차이를 설명하지만, 제공된 범위에는 그 차이를 입증하는 실행 결과가 없어 구성 설명과 실증 결과를 구분해서 읽어야 한다.

✅ 액션 아이템

• purchases.price를 주문 총액으로 해석하고, C360 지출액 집계에서 quantity를 다시 곱하는 오류 여부를 확인한다.
• big_spender의 250달러 초과 주문 기준을 뷰와 COMMENT ON에 반영하고, 반복되는 주별 집계에 big_spenders_by_state를 활용한다.
• 복수 SemKB 검색의 kb_name 지정과 Live·Background·Disabled의 변경 반영 방식을 확인하고, Postgres GRANT와 행 수준 보안에 따른 역할별 데이터 접근을 검증한다.

❓ 열린 질문

• purchases.price를 주문 총액으로 해석했을 때 최상위 고객의 지출액은 $27,991.66으로 재현되는가?
• 같은 프롬프트·도구 목록·에이전트 코드에서 Postgres GRANT와 행 수준 보안은 호출자 역할별 결과를 어떻게 달라지게 하는가?
• c360_kb의 스키마 변경 반영에는 Live·Background·Disabled 중 어떤 방식이 적합하며, 복수 SemKB 검색에서 kb_name은 일관되게 지정되는가?