🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

신뢰할 수 있는 에이전틱 분석을 위해 Aurora와 Amazon Redshift의 데이터를 이동하지 않고 Stardog 의미 계층으로 통합하고, AgentCore에서 실행되는 AI 에이전트가 일관된 비즈니스 규칙과 권한에 따라 고객 360 질문에 답하도록 구성하는 방법을 설명한다.

📌 핵심 요약

• 생성형 AI 에이전트는 다단계 작업을 계획하고 스키마를 해석하며 SQL을 작성할 수 있지만, 서로 다른 시스템이 고객·매출 같은 개념을 다르게 정의하면 기술적으로 유효하면서도 잘못되거나 상충하는 답을 만들 수 있다.
• 의미 계층은 기업의 개념, 관계, 속성, 규칙과 원천 데이터의 매핑을 한 번 정의하고, 에이전트의 질의를 실행 시점에 각 시스템의 SQL로 변환해 데이터 이동이나 ETL 없이 실시간으로 결합한다.
• Stardog는 온톨로지, 안정적인 엔터티 식별자, 추론 규칙, 데이터 제약 조건을 지식 그래프로 구성하며, SPARQL 질의와 가상 그래프를 통해 Aurora와 Amazon Redshift 같은 외부 원천을 연합한다.
• 고객 360 사례에서는 Aurora의 고객·주소 정보와 Amazon Redshift의 주문 데이터를 공통 고객 식별자로 연결하고, ‘고액 구매자’ 같은 파생 개념을 재사용 가능한 규칙으로 정의해 여러 분석에서 같은 결과를 보장한다.
• 안정적인 운영에는 언어와 계획을 담당하는 모델 계층, 데이터의 의미와 거버넌스를 담당하는 의미 계층, 인증·호스팅·도구 자격 증명·확장을 담당하는 에이전트 런타임 계층이 함께 필요하다.

🧩 주요 포인트

1. 생성형 AI 에이전트는 다단계 작업을 계획하고 스키마를 해석하며 SQL을 작성할 수 있지만, 서로 다른 시스템이 고객·매출 같은 개념을 다르게 정의하면 기술적으로 유효하면서도 잘못되거나 상충하는 답을 만들 수 있다.
2. 의미 계층은 기업의 개념, 관계, 속성, 규칙과 원천 데이터의 매핑을 한 번 정의하고, 에이전트의 질의를 실행 시점에 각 시스템의 SQL로 변환해 데이터 이동이나 ETL 없이 실시간으로 결합한다.
3. Stardog는 온톨로지, 안정적인 엔터티 식별자, 추론 규칙, 데이터 제약 조건을 지식 그래프로 구성하며, SPARQL 질의와 가상 그래프를 통해 Aurora와 Amazon Redshift 같은 외부 원천을 연합한다.
4. 고객 360 사례에서는 Aurora의 고객·주소 정보와 Amazon Redshift의 주문 데이터를 공통 고객 식별자로 연결하고, ‘고액 구매자’ 같은 파생 개념을 재사용 가능한 규칙으로 정의해 여러 분석에서 같은 결과를 보장한다.
5. 안정적인 운영에는 언어와 계획을 담당하는 모델 계층, 데이터의 의미와 거버넌스를 담당하는 의미 계층, 인증·호스팅·도구 자격 증명·확장을 담당하는 에이전트 런타임 계층이 함께 필요하다.

🧠 상세 정리

1. 기업 분석의 다음 단계인 에이전틱 분석

기업 분석은 정기 보고서에서 대시보드로, 다시 셀프서비스 BI로 발전하며 비즈니스 질문과 신뢰할 수 있는 답 사이의 시간을 줄여 왔다. 그러나 셀프서비스 BI도 데이터 엔지니어가 해당 질문에 맞는 모델을 미리 만들어 두어야 했고, 준비되지 않은 데이터에 대해서는 인간 분석가가 계속 병목으로 남았다. 생성형 AI 에이전트는 데이터를 단순히 시각화하는 대신 질문을 해석하고, 질의를 작성하고, 결과를 평가한 뒤 필요하면 수정과 반복을 수행한다. 원문은 이처럼 각 비즈니스 사용자가 분석 요청 대기열을 거치지 않고 실시간으로 도움받는 변화를 ‘에이전틱 분석’으로 설명한다.

2. 핵심 난제는 모델보다 분산된 데이터의 의미

기반 모델은 이미 다단계 워크플로를 계획하고 스키마를 추론하며 주니어 분석가 수준으로 SQL을 작성할 수 있지만, 기업 분석의 더 어려운 문제는 모델 아래에 있는 데이터다. 고객 관계 관리 시스템과 청구 시스템은 같은 ‘고객’을 서로 다른 레코드와 기준으로 표현할 수 있고, 지역 조직마다 ‘매출’을 계산하는 방식도 다를 수 있다. 이런 분절된 데이터에 에이전트를 직접 연결하면 SQL 문법은 정확하더라도 답이 잘못되거나 서로 충돌하고, 결과의 근거를 설명하기 어려워진다. 동일한 질문에 두 에이전트가 다른 숫자를 제시하는 순간 사용자의 신뢰가 약해질 수 있으므로, 공통 의미와 규칙을 먼저 제공해야 한다.

3. 서로 다른 데이터 저장소를 유지한 채 함께 추론하기

기업 데이터는 목적에 따라 여러 AWS 데이터 시스템에 나뉘어 있다. 운영 레코드는 Amazon Aurora를 비롯한 관계형 데이터베이스에, 분석 이력은 Amazon Redshift에, 비정형 데이터는 Amazon S3에 저장되고 Amazon Athena 등으로 조회될 수 있다. Apache Iceberg 같은 개방형 테이블 형식도 여러 분석 서비스가 읽을 수 있는 형태로 사용되며, 각 저장 계층은 담당 데이터와 워크로드에 맞게 최적화되어 있다. 원문은 기업이 이러한 구조를 계속 유지할 가능성이 높다고 보고, 데이터를 하나의 저장소로 강제 이전하기보다 에이전트가 여러 원천을 숙련된 분석가처럼 동시에 이해하고 질의하도록 만드는 것을 과제로 제시한다.

4. RAG와 의미 계층이 담당하는 서로 다른 역할

기반 모델이 언어를 담당한다면 데이터 애플리케이션은 사실을 제공하며, 둘을 연결하는 익숙한 방법으로 검색 증강 생성이 사용된다. RAG는 정책 문서, 설명서, 지원 티켓처럼 답이 검색 가능한 텍스트 안에 있을 때 관련 구절을 모델 문맥에 제공하는 데 효과적이다. 반면 실시간 레코드를 여러 시스템에서 조인하고, 동일한 비즈니스 규칙을 적용하며, 행이나 열 수준의 접근 정책까지 지켜야 하는 분석 질문에는 RAG만으로 충분하지 않다. 의미 계층은 고객의 정의, 주문과 고객의 관계, 고액 구매자나 고위험 계정의 기준, 각 사실의 소유 시스템과 지표 계산법을 제공하며 RAG를 대체하는 것이 아니라 상호 보완한다.

5. 온톨로지와 매핑으로 구성되는 의미 계층

의미 계층은 기업 데이터에 대한 온톨로지 기반의 관점으로, 비즈니스에 중요한 개념과 관계, 속성, 규칙을 명시한다. 각 원천의 테이블 행이 이러한 개념에 어떻게 대응하는지는 매핑으로 선언하며, 에이전트는 개별 데이터베이스 구조 대신 의미 계층을 질의한다. 계층은 질의를 실행 시점에 원천 시스템별 SQL로 변환하고 필요한 결과를 결합하므로, 실제 데이터는 기존 시스템에 그대로 남아 있다. 이에 따라 ETL로 별도의 통합 사본을 만들지 않고도 의미를 한 번 정의해 여러 에이전트와 도구가 재사용할 수 있으며, 원천이 변할 때 중복 데이터 파이프라인을 계속 동기화해야 하는 부담도 줄일 수 있다.

6. Stardog 지식 그래프와 연합 질의의 구조

Stardog 방식에서는 온톨로지와 엔터티별 안정적인 식별자, 새로운 사실을 도출하는 규칙, 온톨로지에 맞춰 데이터를 검증하는 제약 조건이 결합되어 지식 그래프를 이룬다. 데이터는 테이블의 행이 아니라 연결된 비즈니스 엔터티 그래프로 표현되고, 각 엔터티는 IRI라는 URL 형태의 고유 식별자를 갖는다. 질의에는 W3C 표준 기반 언어인 SPARQL이 사용되며, 이름 있는 그래프는 자체 IRI를 가진 그래프의 부분집합이자 접근 제어 단위로 기능한다. 가상 그래프는 내용을 Stardog에 저장하지 않고 Aurora나 Amazon Redshift 같은 외부 시스템에서 매핑에 따라 필요할 때 가져오며, 원문의 연합 구조는 원천별 가상 그래프의 집합으로 구현된다.

7. 모델·의미·런타임의 세 계층

신뢰할 수 있고 비즈니스 맥락을 이해하는 에이전트는 모델, 의미, 에이전트 런타임이라는 세 계층이 함께 작동해야 한다. 모델 계층은 사용자의 언어를 이해하고 계획과 질의를 작성하지만 기업 고유의 규칙은 알지 못하며, 의미 계층은 온톨로지와 연합 데이터로 관련 사실을 찾고 공통 식별자를 기준으로 원천별 결과를 연결한다. ‘고액 구매자’ 같은 데이터 추론은 프롬프트에서 임시로 처리하지 않고 Stardog 규칙 안에 유지되며, 모델은 질문을 해석하고 도구를 호출한 뒤 결과를 자연어로 설명하는 좁은 역할을 맡는다. 런타임 계층은 요청 수신, 인증, 도구 자격 증명, 확장과 운영 거버넌스를 담당하며, 이 글에서는 이러한 기능을 관리형으로 묶어 제공하는 AgentCore를 사용한다.

8. 고객 360 사례에서 드러나는 통합과 거버넌스

고객 360 사례에서는 고객 프로필, 주소, 신용카드, 보상 정보가 운영 데이터베이스에 있고 주문, 상품, 범주, 공급업체 정보는 분석용 데이터 웨어하우스에 존재한다. 사용자가 ‘위스콘신의 최고 지출 고객은 누구인가’라고 물으면 에이전트는 Aurora의 고객·주소 정보와 Amazon Redshift의 주문 총액을 안정적인 고객 식별자로 연결해야 한다. 의미 계층은 양쪽 고객 레코드를 공통 정체성에 매핑하고 ‘고액 구매자’ 같은 파생 사실을 온톨로지 규칙으로 정의해, 대시보드와 보고서마다 기준이 중복되거나 달라지는 문제를 막는다. 또한 이름 있는 그래프를 통해 역할별로 읽을 수 있는 범위를 달리하고, 사회보장번호나 카드 번호 같은 민감 속성에는 보호 정책을 적용하여 허가받지 않은 사용자에게 기본적으로 마스킹된 값을 제공할 수 있다.

🧾 핵심 주장 / 시사점

• 에이전트의 분석 신뢰성은 더 강한 모델만으로 확보되지 않으며, 동일한 비즈니스 개념과 계산 규칙을 모든 질의에 일관되게 적용하는 의미 계층에 크게 좌우된다.
• 가상 그래프와 실행 시점 질의 변환은 데이터의 물리적 위치를 유지하면서도 여러 시스템을 공통 의미로 연결하므로, 통합 데이터 사본과 지속적인 ETL 동기화에 대한 의존을 줄인다.
• 운영 가능한 분석 에이전트는 답을 생성하는 기능뿐 아니라 역할별 데이터 노출, 민감 속성 보호, 요청 인증, 도구 자격 증명 관리와 같은 거버넌스를 전체 구조에 포함해야 한다.

✅ 액션 아이템

• 에이전트 질문 처리 전에 고객·매출 같은 핵심 개념을 Stardog 의미 계층에서 통일해 공통 엔터티 식별자와 규칙을 고정한다.
• Aurora와 Amazon Redshift를 데이터 이동이나 ETL 없이 Stardog 가상 그래프로 연합해 고객 360 질의를 실시간으로 결합하도록 SPARQL 변환 경로를 구현한다.
• 모델 계층, 의미 계층, AgentCore 기반 런타임 계층의 책임을 분리해 언어·계획, 거버넌스, 인증·도구 자격 처리 흐름을 함께 점검한다.

❓ 열린 질문

• 공통 고객 식별자 기준을 Aurora 키와 Redshift 키 중 어디에 맞춰 잡으면 파생 개념 결과 일관성을 유지할 수 있는가?
• 고액 구매자 같은 재사용 규칙을 만들 때 충돌이 생기면 어떤 우선순위 기준으로 규칙을 조정하는 것이 적절한가?
• AgentCore 에이전트가 SQL 변환 시 권한·데이터 제약 위반을 빠르게 감지하려면 어떤 로그와 지표를 결합해 판단해야 하는가?