의미 계층

한 줄로 말하면

의미 계층(semantic layer)은 여러 데이터베이스에 흩어진 같은 대상을 하나의 개념·관계·규칙으로 묶어 주는 중간층이야. 에이전트가 표 이름과 열 이름을 보고 즉석에서 추측하는 대신, 회사가 합의한 의미를 통해 데이터를 질의하게 해.

비유로 이해하기

서로 다른 나라의 지도를 한 장에 겹친다고 생각해 보자. 한 지도에는 customer, 다른 지도에는 cid가 적혀 있어도, 의미 계층은 둘이 같은 사람을 가리키는 공통 표지를 붙여 줘. 에이전트는 각 지도에 따로 길을 묻는 대신 이 공통 지도를 보고 답을 찾을 수 있지.

여기까지가 비유야. 실제 의미 계층은 데이터를 새 창고로 옮기는 지도 이미지가 아니야. 원래 데이터는 각 시스템에 남고, 개념과 관계를 원본의 행에 연결하는 매핑과 질의 변환 규칙이 그 사이에서 작동해.¹

정확한 정의

의미 계층은 기업 데이터의 온톨로지 기반 관점이야. 온톨로지는 업무에서 중요한 개념·관계·속성·규칙을 선언하고, 매핑은 그 개념이 각 데이터 원본의 어떤 행과 열에 대응하는지 적어. 에이전트가 계층을 질의하면 계층은 필요한 원본 시스템에 SQL을 실행하고 결과를 공통 의미로 조합해.¹

이 구조의 핵심은 세 가지야.

1. 공통 개념과 식별자: 서로 다른 원본의 같은 대상을 하나의 안정적인 식별자로 연결해.
2. 재사용하는 규칙: 큰손 고객처럼 여러 분석에서 반복되는 파생 개념을 매 쿼리마다 다시 쓰지 않고 규칙으로 둬.
3. 의미에 붙은 통제: 어떤 역할이 어떤 그래프나 민감한 속성을 볼 수 있는지 데이터 의미 모델 안에서 함께 관리해.

Stardog의 구현에서는 이 모델이 지식 그래프로 표현돼. 개체는 안정적인 IRI를 갖고, 관계를 따라 질의하는 SPARQL을 사용해. 원본에 저장하지 않는 가상 그래프도 만들 수 있어서, Aurora·Redshift·Athena 같은 외부 시스템의 행을 질의 시점에 가져오는 연합 구조를 구성할 수 있어.¹

왜 중요한가

에이전트 분석의 위험은 SQL 문법을 틀리는 데만 있지 않아. 서로 다른 시스템이 고객과 매출을 다르게 정의하는데도, 에이전트가 문법적으로는 맞는 질의를 만들어 서로 충돌하는 숫자를 내놓을 수 있다는 데 있어. 의미 계층은 이 문제를 모델의 말솜씨가 아니라 데이터 구조와 업무 규칙의 문제로 다뤄.¹

그래서 에이전트의 역할도 좁아져. 에이전트는 질문을 이해하고 계층을 호출한 뒤 결과를 자연어로 설명해. 어떤 데이터를 연결할지, 공통 식별자로 어떻게 조인할지, 큰손 고객 같은 파생 사실을 어떻게 계산할지는 의미 계층이 맡는 식이야.¹

실제 예시

AWS 글의 고객 360 예시에서는 고객 프로필과 주소가 Aurora에 있고, 주문 합계와 상품 정보가 Redshift에 있어. 두 데이터베이스는 같은 고객을 가리키는 cid 값을 공유하지만, 서로 다른 엔진에 있어서 그 관계를 SQL 외래 키로 선언할 수는 없어.¹

의미 계층은 두 원본의 식별자에서 같은 고객 IRI를 만들도록 매핑해. 그러면 에이전트는 “위스콘신의 큰손 고객은 누구고 무엇을 샀나?”라는 질문을 받을 때, 고객 정보와 주문 정보를 하나의 고객 개념 아래에서 연결할 수 있어. 데이터베이스에 데이터를 복사해 세 번째 저장소를 만들지 않고, 질의 시점에 각 원본에서 가져온 결과를 공통 식별자로 합치는 방식이야.¹

이 예시에서 큰손 고객은 어느 테이블의 한 열에 이미 적힌 값이 아니야. 여러 데이터와 업무 규칙에서 도출되는 개념이야. 그 규칙을 온톨로지에 한 번 선언하면 대시보드·노트북·보고서가 각자 다른 기준을 복사해 쓰면서 결과가 갈라지는 일을 줄일 수 있어.¹

RAG와는 어떻게 다른가

RAG는 답이 문서의 문장에 있을 때 강해. 정책 문서·매뉴얼·지원 티켓에서 관련 문단을 찾아 모델의 입력에 붙이는 구조지. 반면 의미 계층은 여러 시스템의 살아 있는 레코드를 조인하고, 업무 규칙을 일관되게 적용하고, 데이터 접근 정책을 지켜야 하는 분석 질문을 다뤄.¹

둘은 경쟁 관계가 아니야. “환불 정책이 무엇인가?”처럼 문서의 설명을 찾아야 하는 질문에는 RAG가 필요하고, “정책상 환불 대상인 주문은 어느 고객의 매출에 포함되는가?”처럼 문서 규칙과 구조화된 기록을 함께 봐야 하는 질문에는 두 구조를 같은 에이전트에서 조합할 수 있어. 다만 이 조합의 구체적인 정확도나 비용은 이 자료만으로 단정할 수 없어.

헷갈리지 말아야 할 점

• 의미 계층은 데이터 웨어하우스와 같은 말이 아니야. 원문 데이터를 새 저장소로 모으는 대신, 원본에 있는 의미와 매핑을 질의 경로에 둬.
• 의미 계층은 모델의 상식이 아니야. 모델이 업무 정의를 저절로 아는 게 아니라, 온톨로지와 규칙을 사람이 설계해 제공하는 구조야.
• 지식 그래프와 항상 같은 말도 아니야. 의미 계층을 지식 그래프로 구현할 수 있지만, 이 글의 핵심은 그래프 제품명이 아니라 공통 개념·식별자·규칙·접근 통제를 질의 앞에 두는 역할이야.¹
• RAG를 대체하지 않아. 텍스트 근거와 구조화된 업무 데이터를 다루는 방식이 다르므로, 질문의 답이 어디에 있는지에 따라 선택이 달라져.
• 원본 데이터의 품질을 자동으로 고치지 않아. 같은 식별자가 실제로 같은 대상을 가리키는지, 업무 규칙이 합의됐는지, 접근 정책이 맞는지는 여전히 설계와 운영의 문제야. 의미 계층은 그 합의를 재사용 가능한 형태로 드러내는 장치야.

관련 문서

• 문서 검색을 모델 답변과 연결하는 구조: RAG
• 에이전트가 도구·권한·검증과 함께 움직이는 작업 흐름: agentic workflow
• 그래프 질의를 SQL 표 위에 얹는 다른 접근: PGQ와 property graph

남은 질문들

• 공통 식별자가 원본마다 다르거나 누락될 때, 의미 계층은 어떤 품질 기준으로 연결을 거부해야 할까?
• 업무 규칙이 바뀌었을 때 온톨로지 변경과 과거 분석 결과의 재현성을 어떻게 함께 보장할까?
• 의미 계층을 실제 서비스에 붙였을 때 질의 지연시간과 운영 비용은 ETL·웨어하우스 방식과 어떻게 달라질까?
• 같은 의미 모델을 여러 에이전트가 사용할 때, 질의 결과와 접근 권한을 어떻게 독립적으로 검증할까?

각주

1. AWS Machine Learning Blog, “Build a semantic layer for agentic AI on AWS with Stardog and Amazon Bedrock AgentCore”. ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷ ↩︎⁸ ↩︎⁹ ↩︎¹⁰