EDB Semantic Layer, Postgres 내부에 에이전트 접근 규칙 적용
AWS는 프롬프트 지침이 아니라 데이터베이스 권한이 에이전트의 데이터 읽기 범위를 관리하도록 하는 EDB semantic layer 가이드를 공개했다. 11월 3일 공개된 이 예제는 EDB Postgres AI를 소프트웨어 에이전트 호스팅 및 연결을 위한 AWS 서비스인 Amazon Bedrock AgentCore와 연결한다. 핵심 제안은 구체적이다. 비즈니스 정의를 운영 데이터 가까이에 유지하고, 쿼리가 실행되는 지점에서 접근을 강제하자는 것이다.
시맨틱 레이어는 비즈니스 용어를 데이터베이스 구조 및 계산과 연결한다. 여기서는 도구를 호출하는 에이전트를 구축하는 프레임워크인 Strands Agents를 사용해 에이전트가 고객 활동 관련 질문에 답한다. 쟁점은 유연한 쿼리 생성과 신뢰할 수 있는 통제 사이의 균형이다. 어시스턴트는 질문을 해석할 충분한 자유가 필요하지만, 데이터베이스 소유자는 접근 범위에 예측 가능한 한계를 두어야 한다.
분산 소스를 쿼리하는 데이터 가상화 플랫폼 Denodo와의 비교는 EDB의 접근 방식을 이해하는 데 도움이 된다. 두 솔루션 모두 에이전트에 비즈니스 맥락을 제공하지만, 서로 다른 데이터 아키텍처를 중심으로 그 맥락을 구성한다. 개발자와 엔터프라이즈 구매자에게 당면한 질문은 정의와 권한이 어디에 존재해야 하는지, 그리고 누가 이를 유지해야 하는지다.
EDB semantic layer는 데이터베이스 의미를 발견 가능하게 만든다
이번 변화는 기존 데이터베이스 정의를 외부 에이전트가 활용할 수 있게 하는 통합 패턴이다.
agentic semantic layer 가이드는 EDB의 AIDB 데이터베이스 확장 기능과 AWS에서 실행되는 에이전트를 결합한다. 고객 예제는 네 개의 테이블과 데이터베이스 객체로 표시되는 저장 쿼리인 파생 뷰를 사용한다. 비즈니스 설명은 데이터베이스 주석에서 가져오며, 관련 레코드를 연결하는 제약 조건인 외래 키가 조인 관계를 제공한다.
AWS에 따르면, 이 예제는 프롬프트와 에이전트 코드는 그대로 유지한 채 데이터베이스 자격 증명만 변경한다. 제한된 역할은 보호된 Social Security number 열을 검색할 수 없다. 이는 유의미한 차이다. 어시스턴트가 답변을 작성하기 전에 데이터베이스가 해당 접근 시도를 거부하기 때문이다.
이는 여전히 공급업체가 작성한 참조 예제다. 엔터프라이즈 전반의 신뢰성에 관한 독립적 증거를 제시하기보다, 제안된 구현 방식과 샘플 동작을 보고한다. 독자는 배포 준비성에 관한 결론을 내리기 전에 이러한 주장을 구분해야 한다.
EDB 문서는 데이터베이스 구조와 설명을 검색 가능한 형태로 색인화하는 기반 semantic knowledge base를 설명한다. 고객 레코드를 임베딩하는 대신 테이블, 뷰, 열, 주석을 색인화한다. 유사도 매칭에 사용되는 수치 표현인 임베딩은 에이전트가 자연어 질문을 통해 관련 데이터베이스 객체를 찾도록 돕는다.
이 구분은 평가에서 중요하다. 올바른 구조를 찾는다고 해서 생성된 계산이 정확하다는 뜻은 아니다. 이는 모델이 쿼리를 구성할 수 있는 더 나은 재료를 제공한다. 팀은 여전히 답변을 승인된 비즈니스 결과와 대조해야 한다.
EDB semantic layer에 대한 설명을 찾는 사람에게 유용한 출발점은 발견과 강제의 분리다. 설명은 에이전트가 데이터의 의미를 판단하도록 돕는다. 권한은 제안된 쿼리가 해당 데이터에 접근할 수 있는지를 결정한다.
이 배치는 소유권도 바꾼다. 데이터베이스 주석은 개발자만 가끔 참고하는 문서가 아니라 에이전트의 작업 맥락 일부가 된다. 부정확한 설명은 오해를 부르는 애플리케이션 인터페이스와 마찬가지로 주의를 기울여야 한다.
단위 금액인지 주문 총액인지 이름만으로 알 수 없는 가상의 구매 필드를 생각해 보자. 두 해석 모두 유효한 산술 연산을 뒷받침한다. 하지만 비즈니스 정의에 맞는 것은 하나뿐이므로, 실행에 성공했다는 사실만으로는 오류를 식별할 수 없다.
이 때문에 이 아키텍처는 샘플 데이터세트를 넘어 관련성이 있다. 그 가치는 팀이 모호한 데이터베이스 관례를 유지 관리되고 발견 가능한 정의로 전환할 수 있는지에 달려 있다. 에이전트 연결은 그 작업을 사라지게 하는 대신 선행 조건으로 드러낸다.
데이터베이스 소유자는 에이전트 업무의 일부를 떠안는다
의미를 Postgres로 옮기면 데이터베이스 팀이 답변 품질에 직접적인 역할을 맡게 된다.
즉각적인 부담은 스키마, 보고 정의, 접근 정책을 소유한 사람들에게 돌아간다. 애플리케이션 팀은 어시스턴트의 지침을 개선할 수 있지만, 표현만으로 합의되지 않은 비즈니스 정의를 해결할 수는 없다.
영업과 재무가 활성 고객을 서로 다르게 정의한다고 가정해 보자. 한쪽은 최근 구매를 기준으로 삼고, 다른 쪽은 정상 상태의 계정을 요구한다. 별다른 단서 없이 어느 한 해석을 선택하는 에이전트는 조직 내 기반 정의보다 더 확정적인 것처럼 보이는 답변을 내놓는다.
정의를 데이터 가까이에 유지하면 이 불일치를 해소할 장소가 생긴다. 그렇다고 어느 부서가 옳은지를 결정해 주지는 않는다. 여전히 누군가는 정의를 승인하고, 적용 범위를 설명하며, 변경을 관리할 권한을 가져야 한다.
이 때문에 아키텍처와 함께 운영 부담도 주목할 필요가 있다. 이 패턴을 채택하는 팀은 데이터베이스 의미에 관한 지속적인 편집 작업을 예상해야 한다. 설명을 검토하는 일은 소프트웨어 에이전트가 소비하는 인터페이스를 유지하는 일부가 된다.
테이블 간 관계에도 같은 원리가 적용된다. 기술적으로 유효한 연결이 질문에 필요한 비즈니스 관계를 자동으로 표현하는 것은 아니다. 구매자는 기존 데이터베이스 구조가 보고 요구를 반영하는지, 아니면 애플리케이션 트랜잭션만 지원하는지 물어야 한다.
이 차이는 고객에게 여러 주소, 계정 소유자 또는 과거 분류가 있을 때 드러난다. 현재 영업 구역에 관한 질문은 주문 발생 당시 영업 구역에 관한 질문과 다른 해석을 필요로 한다. 어느 답변도 문서화되지 않은 가정에 의존해서는 안 된다.
이는 EDB 구현의 보고된 실패 사례가 아니라 평가 시나리오다. 더 강력한 스키마 발견도 비즈니스 판단이 필요한 지점을 보여 준다. 유용한 파일럿은 그러한 가정이 바뀔 때 답변도 달라지는 질문을 의도적으로 포함해야 한다.
인력 측면의 함의는 명확하다. 에이전트 팀은 이미 보고 관련 분쟁을 해결하는 사람들에게 접근할 수 있어야 한다. 그렇지 않으면 애플리케이션 개발자가 정의할 권한이 없는 지표의 비공식 소유자가 될 위험이 있다.
따라서 엔터프라이즈 구매자는 에이전트 시연과 함께 유지 관리 프로세스도 평가해야 한다. 변경된 정의는 누가 승인하는가? 어떤 애플리케이션이 이에 의존하는가? 어시스턴트가 오래된 해석을 사용하고 있다는 사실을 조직은 어떻게 발견하는가?
엔지니어링 팀에게는 검색 가능한 지식 베이스가 그러한 결정의 근거를 보존하는 데 도움이 될 수 있다. 데이터베이스 정의와 지원 문서는 서로 다른 시스템에 있더라도 관련된 목적을 수행한다.
단기적인 부담은 신뢰할 수 있는 파일럿을 준비하는 일이다. 장기적인 부담은 조직적이다. 애플리케이션, 보고 요구 사항, 인력이 변해도 비즈니스 정의를 일관되게 유지해야 한다. 이 아키텍처는 그 책임을 더 가시화하며, 누군가 이를 맡을 때에만 유용하다.
검토된 쿼리는 유연한 에이전트에 안정적인 기준을 제공한다
반복되는 비즈니스 질문에는 사용자가 서로 다른 표현으로 질문하더라도 재사용 가능한 쿼리 로직이 필요하다.
EDB는 검색 가능한 자연어 설명과 정의된 매개변수를 결합한 이름 있는 쿼리인 semantic aliases를 문서화한다. alias는 결과를 조회하는 쿼리인 단일 읽기 전용 SELECT를 포함해야 한다. EDB는 alias 생성 및 실행 시 이 제한을 검증한다고 말한다.
아키텍처 측면의 함의는 고정된 보고 인터페이스와 무제한 쿼리 생성 사이의 중간 경로다. 사용자는 익숙한 요청을 대화식으로 표현할 수 있고, 시스템은 참조할 수 있는 기존 쿼리를 보유한다.
가상의 지역별 매출 보고서에서 검토된 로직은 보고 기간, 고객 분류, 취소된 주문의 처리 방식을 이미 지정할 수 있다. 이러한 결정은 사용자가 요청을 표현하는 방식이 바뀌어도 유지되어야 한다.
이는 매번 모델에 모든 결정을 재구성하도록 요청하는 것과 다르다. 익숙한 로직을 재구성하면 변형이 발생할 기회가 하나 더 생긴다. 재사용은 검토자가 검사할 수 있는 더 작고 구체적인 대상을 제공한다.
하지만 저장된 쿼리만으로 해석 문제가 해결되지는 않는다. 에이전트는 여전히 적절한 쿼리를 식별하고 적합한 매개변수를 제공해야 한다. 분기 활동 요청이 아무런 표시 없이 최신 역년 분기 요청으로 바뀌어서는 안 된다.
이로 인해 별개의 평가 질문이 생긴다. 시스템은 의도한 비즈니스 질문을 인식했는가? 올바른 기간과 범위를 선택했는가? 반환된 설명은 쿼리가 측정한 내용을 정확히 설명했는가?
좋은 데이터베이스 결과는 그 연결 고리의 일부만 다룬다. 어시스턴트는 올바른 레코드를 검색하고도 이를 잘못 요약할 수 있다. 반대로 유창한 설명은 인접한 질문에 답한 쿼리를 감출 수 있다.
실무적인 대응은 반복 요청을 위한 기준 답변을 유지하는 것이다. 팀은 표현, 날짜, 사용자 권한을 바꾸면서 생성된 답변을 이러한 기준과 비교할 수 있다. 이는 사용자가 실제로 마주할 동작을 검증한다.
검토된 로직은 더 명확한 변경 프로세스도 만든다. 비즈니스가 정의를 변경하면 유지 관리자들은 관련 쿼리를 식별하고 영향을 받는 출력을 평가할 수 있다. 공유된 기준이 없으면 동등한 정의가 여러 에이전트 애플리케이션에서 서로 달라질 수 있다.
이 이점에는 경계가 있다. 매우 탐색적인 질문은 기존 쿼리 카탈로그를 넘어서는 해석을 여전히 요구한다. 구매자는 명확한 일치 항목이 없을 때 시스템이 어떻게 동작하는지, 특히 명확화를 요청하는지를 평가해야 한다.
중요한 제품 동작은 정직한 불확실성이다. 모호한 요청을 식별하는 도구는 사용자가 방향을 바로잡을 기회를 제공한다. 부적절한 정의를 자신 있게 선택하는 도구는 그 결정을 숨긴다.
따라서 EDB의 접근 방식은 재사용 가능한 의미와 쿼리 로직을 구성하는 방법으로 평가하는 것이 가장 적절하다. 그 유용성은 검색 품질, 매개변수 처리, 검토 관행이 함께 작동하는지에 달려 있다. 이들 어느 것도 다른 사례의 성공적인 시연만으로 추정해서는 안 된다.
Denodo는 데이터베이스 로컬 의미의 경계를 부각한다
EDB vs Denodo 비교의 핵심은 데이터 배치와 운영 책임이다.
AWS의 이전 data virtualization architecture는 Denodo를 사용해 Amazon Aurora, Amazon Redshift, 온프레미스 PostgreSQL 데이터베이스 전반의 고객 정보를 연결한다. 데이터 가상화는 공유 쿼리 레이어를 통해 분산 소스를 제시한다. 이 가이드는 비즈니스 뷰와 접근 정책을 Denodo에 배치한다.
반면 EDB 예제는 운영 Postgres 데이터베이스 내부에 의미를 둔다. 이 비교가 성능 우위를 입증하는 것은 아니다. 비즈니스 정의가 어디에 속하는지를 결정하기 위한 서로 다른 출발 조건을 보여 준다.
관련 데이터가 이미 한곳에 모여 있는 팀이라면, 데이터베이스 내부 정의를 검토할 가치가 있다. 조직적 매력은 분명하다. 기존 데이터베이스 관리자는 답변을 구성하는 객체를 익숙한 위치에서 살펴볼 수 있다.
고객 정보가 서로 독립적인 시스템에 걸쳐 있는 팀이라면 핵심 문제는 더 넓다. 시스템 간 식별자, 의미, 권한을 조정해야 한다. 에이전트 인터페이스를 추가한다고 해서 이러한 통합 결정이 사라지는 것은 아니다.
따라서 유용한 EDB 대 Denodo 비교는 비즈니스 질문의 경계에 관한 것이다. 조직이 이미 운영하는 거버넌스 적용 데이터베이스만으로 답할 수 있는가? 아니면 답변에 여러 소스 간의 조정이 필요한가?
한 가상의 고객 관리자에게 어떤 고객이 갱신 관리가 필요한지 묻는 상황을 생각해 보자. 구매 이력만으로는 충분하지 않을 수 있다. 계약 상태, 미해결 지원 사례, 계정 담당자는 각각 답변에 영향을 줄 수 있다.
이러한 기록이 다른 곳에 있다면, 데이터베이스 중심의 파일럿은 그 한계를 드러내야 한다. 그렇지 않으면 이용 가능한 기록에 대한 성공적인 답변이 완전한 계정 평가로 오인될 수 있다. 누락된 소스는 기술적 성공으로 위장된 비즈니스 위험이 된다.
분산형 접근 방식도 자체적인 평가 부담을 안는다. 소스를 연결한다고 해서 정의가 서로 일치한다는 사실이 자동으로 확립되지는 않는다. 구매자는 시스템이 충돌하는 식별자와 보고 기간을 어떻게 조정하는지도 계속 검토해야 한다.
두 접근 방식 모두에서 핵심 긴장은 같다. 유연한 에이전트에는 유지 관리되는 의미와 강제 가능한 접근 제어가 필요하다. 아키텍처 선택은 그러한 책임이 모이는 위치를 결정할 뿐, 이를 없애지는 않는다.
이 때문에 커넥터 수 역시 불완전한 구매 기준이다. 커넥터는 정보로 가는 경로를 만든다. 하지만 연결된 모든 소스에서 특정 질문이 합의된 의미를 갖는다는 점까지 보장하지는 않는다.
팀은 대표적인 비즈니스 요청과 그 전체 종속성을 사용해 아키텍처를 비교해야 한다. 소스 소유자, 승인된 계산 방식, 접근 제한, 예상되는 설명을 포함하라. 이는 에이전트 기능에 대한 일반적인 논의보다 더 많은 것을 보여 준다.
EDB에게 기회는 기존 데이터베이스 구조를 에이전트를 위한 신뢰할 수 있는 기반으로 만드는 데 있다. 경계 역시 분명하다. 조직은 그 기반이 사용자가 실제로 묻는 질문을 어디까지 포괄하는지 확립해야 한다.
권한은 여전히 Postgres에 도달하는 ID에 달려 있다
데이터베이스 접근 규칙은 쿼리가 적절한 역할로 실행될 때에만 의도한 사용자를 보호한다.
EDB의 MCP server는 에이전트가 외부 도구를 호출하는 표준 인터페이스인 Model Context Protocol을 사용한다. 문서에 따르면 도구 호출은 인증된 Postgres 역할로 실행된다. 이후 데이터베이스 권한이 해당 역할이 실행할 수 있는 작업을 결정한다.
이는 프로덕션 팀에 구체적인 검토 지점을 만든다. 애플리케이션 경계에서 사람을 인증하는 일과 하위 데이터베이스 ID를 선택하는 일은 별개의 책임이다. 검토자는 사용자별 접근에 관한 주장을 받아들이기 전에 두 가지를 모두 추적해야 한다.
가상의 공유 보고 계정은 이 문제를 잘 보여 준다. 모든 요청이 해당 계정으로 데이터베이스에 도달한다면, 데이터베이스 규칙은 그 계정의 권한을 평가한다. 개인화된 애플리케이션 인터페이스 자체가 개인화된 데이터베이스 강제를 확립하는 것은 아니다.
그렇다고 공유 계정이 항상 부적절하다는 뜻은 아니다. 그 권한은 의도된 서비스 경계와 일치해야 한다는 의미다. 범위가 좁은 보고 지원 도우미는 서로 다른 접근 권한을 가진 사용자를 지원하는 도우미와 요구사항이 다르다.
PostgreSQL의 row security policies는 역할이 접근할 수 있는 레코드를 제한한다. 적용 가능한 정책 없이 활성화하면 행 보안은 기본적으로 거부된다. 다만 슈퍼유저와 BYPASSRLS 권한을 가진 역할은 이러한 제한을 우회하며, 테이블 소유자도 일반적으로 강제 준수를 요구받지 않는 한 이를 우회한다.
이러한 문서화된 예외는 에이전트 연결을 테스트할 때 중요하다. 관리 계정을 사용한 시연은 일반 사용자 간 격리를 입증할 수 없다. 평가자는 실제 요청 경로에서 유효 역할과 그 권한을 확인해야 한다.
열 제한과 행 제한도 서로 다른 질문에 답한다. 민감한 필드를 숨긴다고 해서 다른 고객의 레코드에 접근할 수 없다는 점이 확립되는 것은 아니다. 설득력 있는 평가는 애플리케이션이 약속하는 접근 차원을 테스트해야 한다.
그 평가는 대체 질문을 통한 접근 시도도 포함해야 한다. 민감한 필드를 직접 요청하는 것은 유용하지만, 비즈니스 요청은 허용된 속성을 예상치 못한 방식으로 결합할 수 있다. 검토자는 애플리케이션이 무엇을 반환하는지와 제한을 어떻게 설명하는지 살펴봐야 한다.
권한 강제는 답변의 정확성까지 확립하지는 않는다. 역할은 에이전트가 잘못 결합한 레코드를 읽을 권한을 가질 수 있다. 보안 평가와 분석 평가를 구분하고, 각각에 대한 증거를 유지해야 한다.
읽기 전용 접근도 비슷한 수준의 정밀함이 필요하다. 쓰기를 막으면 에이전트가 해당 경로를 통해 변경할 수 있는 범위는 제한된다. 하지만 권한이 있는 결과에 특정 맥락에서 애플리케이션이 표시해서는 안 되는 정보가 포함되는지를 결정하지는 않는다.
이러한 단서는 주장을 기각하는 것이 아니라 그 범위를 정의한다. 데이터베이스 강제는 검토자가 구체적으로 점검할 대상을 제공한다. 검토자는 지원 도우미가 밝히는 의도에만 의존하지 않고 역할, 권한, 정책, 실행된 쿼리를 검토할 수 있다.
남은 과제는 애플리케이션이 의도한 ID로 해당 강제 지점에 일관되게 도달하는지 검증하는 것이다. 이는 배포 책임이며, 승인 증거에서 확인할 수 있어야 한다.
ID 격리, 정의 변경, 재현 가능한 답변을 지켜보라
다음으로 유용한 증거는 거버넌스가 사용자, 정의, 요청량의 변화에도 유지되는지를 보여 줄 것이다.
향후 몇 달 동안 구매자는 이러한 차원을 연결하는 평가에 주목해야 한다. 익숙한 질문을 추가로 시연하는 것보다 아키텍처의 경계를 중심으로 설계된 테스트가 더 많은 정보를 제공한다.
첫 번째 신호는 배포된 요청 경로 전반의 ID 격리다. 서로 다른 권한을 가진 사용자가 적절히 다른 결과를 받는다는 증거를 찾아야 한다. 증거는 단순히 인터페이스에 다른 이름을 표시하는 데 그치지 않고, 실제 유효 데이터베이스 역할을 식별해야 한다.
격리 테스트에는 사용자의 권한 밖에 있는 작업 시도와 그에 따른 데이터베이스 동작이 포함되어야 한다. 일관된 강제는 해당 아키텍처의 근거를 강화한다. 설명되지 않는 자격 증명 공유는 사용자별 거버넌스에 관한 주장을 약화시킨다.
두 번째 신호는 정의 변경이 답변에 미치는 방식이다. 비즈니스 지표는 애플리케이션 수명 동안 거의 항상 그대로 유지되지 않는다. 팀은 정의를 업데이트한 뒤 지원 도우미의 후속 해석을 검증하는 시연을 찾아야 한다.
의미 있는 증거에는 전환 자체가 포함된다. 지원 도우미는 수정된 의미를 사용하는가? 검토자는 이전 답변을 뒷받침한 정의를 식별할 수 있는가? 영향을 받는 기준 답변은 명시적인 절차를 통해 업데이트되는가?
성공적인 변경 처리는 유지 관리되는 데이터베이스 객체 가까이에 의미를 두어야 한다는 주장을 강화한다. 불명확한 소유권이나 오래된 해석은 단순한 공동 배치만으로는 일관성을 제공하지 못한다는 점을 보여 준다.
세 번째 신호는 대표적 사용 환경에서의 재현 가능한 정확성이다. 평가는 질문 표현, 사용자 권한, 동시 활동량을 달리해야 한다. 구매자는 조건이 최초 시연과 달라져도 시스템이 여전히 유용한지 확인해야 한다.
그렇다고 모든 비즈니스 질문을 벤치마크 경쟁처럼 다룰 필요는 없다. 기대되는 동작의 명시된 집합이 필요하다는 뜻이다. 올바른 계산, 적절한 거부, 이해하기 쉬운 제한, 수용 가능한 응답 시간은 각각 증거를 갖춰야 한다.
EDB semantic layer를 운영 측면에서 이해하려는 팀에게 이러한 신호는 실용적인 의사결정 프레임워크를 제공한다. 이는 아키텍처 제안을 파일럿이 답할 수 있는 질문으로 바꾼다.
또한 어느 플랫폼이 승리할지에 관한 근거 없는 전망도 피한다. 가장 강력한 구현은 데이터 배치, ID 요구사항, 조직의 정의 유지 능력에 달려 있다. 데이터베이스 중심 접근 방식은 이러한 조건에 따라 평가되어야 한다.
팀이 이미 신뢰성 있게 답하는 비즈니스 질문으로 시작한 다음, 그 정의, 예상 결과, 접근 경계를 문서화하라. 지원 도우미의 설명을 신뢰하지 않고도 검토자가 결과를 재현할 수 있을 만큼 충분한 정보를 제공하라. 적절히 제한된 ID로 동일한 요청을 실행하고, 응답과 함께 데이터베이스 동작을 점검하라. 다음으로 관련 정의를 변경하고 답변이 승인된 변경을 따르는지 확인하라. EDB semantic layer를 특정 운영 가설을 시험하는 데 사용하라. 즉, 조직이 쿼리 시점에 접근을 강제하면서도 공유된 의미를 유지할 수 있다는 가설이다. 파일럿을 확대하기 전에 모든 중요한 답변과 모든 중요한 거부를 설명할 수 있는지 물어보라.
