AI-ready Data의 다음 기준, Semantic Layer와 Ontology

 



AI가 데이터를 다루는 환경은 빠르게 넓어지고 있습니다.

기업은 데이터 플랫폼을 구축하고 여러 업무 시스템을 연결하면서 AI가 활용할 수 있는 데이터의 폭을 키워 왔습니다. AI도 문서를 요약하거나 질문에 답하던 단계를 지나, 업무 데이터를 근거로 판단하고 실행을 지원하는 방향으로 움직이고 있습니다.

문제는 데이터에 접근할 수 있다고 해서 AI가 그 데이터를 이해하는 것은 아니라는 점입니다.

AI가 업무에서 데이터를 제대로 활용하려면 그 값이 무엇을 의미하는지, 어떤 업무와 연결되어 있는지, 어떤 기준으로 해석해야 하는지를 함께 알아야 합니다.

‘매출’이라는 한 단어만 봐도 그렇습니다. 조직과 기준에 따라 주문 기준 매출일 수도 있고, 출고 기준 매출이나 회계 인식 기준 매출일 수도 있습니다. 사람은 업무 경험과 대화를 통해 이런 차이를 메우지만, AI는 정의되지 않은 의미를 스스로 일관되게 판단하기

어렵습니다.

AI-ready Data를 준비한다는 것은 그래서 단순히 데이터를 정돈하고 품질을 높이는 데서 멈추지 않습니다.

AI가 데이터의 의미와 관계를 같은 기준으로 이해하고 활용할 수 있도록, 업무 문맥까지 함께 설계하는 일입니다.

AI Agent는 데이터의 의미를 필요로 한다

요즘 AI는 스스로 업무 절차를 밟아가는 Agent 형태로 바뀌고 있습니다. 사용자의 요청을 읽고, 필요한 데이터를 찾고, 관련 시스템을 불러오고, 다음 단계를 제안합니다. 이때 AI에게 필요한 것은 데이터 접근 권한만이 아닙니다. 어떤 데이터가 그 업무에 쓰이는지, 어떤 기준으로 해석해야 하는지, 어떤 정보와 엮어 판단해야 하는지를 알아야 합니다.

데이터가 여러 시스템에 흩어져 있어도 의미와 관계가 정리돼 있으면 AI는 업무 맥락 안에서 그 데이터를 활용할 수 있습니다. 반대로 데이터가 있어도 의미가 정의돼 있지 않으면 같은 질문에도 매번 다른 기준으로 답이 나옵니다. ‘고객’만 해도 영업에서는 거래 이력이 있는 기업을, 마케팅에서는 캠페인에 반응한 잠재 고객까지, 서비스에서는 계약 이후 지원 대상을 가리킵니다.

AI Agent가 업무를 돕는 환경에서는 데이터의 양과 접근성만큼이나 의미와 해석 기준이 중요해집니다. 그 작업은 기업이 사용하는 비즈니스 언어를 하나의 기준으로 정리하는 데서 출발합니다.

Semantic Layer는 AI가 참조하는 비즈니스 언어를 일관되게 정리한다

Semantic Layer는 데이터와 사용자, 그리고 AI 사이에 놓여 비즈니스 용어와 지표의 의미를 공통으로 정의하는 층입니다.

데이터가 여기저기 흩어져 있어도 AI가 같은 용어와 지표를 같은 기준으로 참조하게 해줍니다. 앞서 본 ‘매출’처럼 기준이 분명하지 않으면 AI는 어떤 값을 골라야 할지 갈팡질팡합니다.

이를 위해 Semantic Layer는 지표와 용어, 계산식, 테이블 간 조인 관계를 하나의 기준으로 정의합니다. 권한이나 거버넌스 기준은 제품과 아키텍처에 따라 직접 관리하기도 하고, 데이터 플랫폼 정책과 연동하기도 합니다. 예전에는 BI 대시보드의 숫자를 맞추기 위한 공통 정의가 주된 역할이었습니다. AI Agent가 등장하면서 이제는 AI가 기업 데이터를 해석할 때 기대는 비즈니스 언어의 기준으로 쓰임이 넓어지고 있습니다.

그렇다면 이 역할은 어떤 형태로 구현될까요? Semantic Layer는 꼭 정해진 제품 한 가지로 구현되는 것은 아닙니다. 지표·용어·계산식·조인·권한 기준을 정의하거나 연동해 여러 도구와 AI가 함께 쓰도록 제공하는 구조라면, 형태가 무엇이든 그 역할을 할 수 있습니다. 실제로는 Power BI Semantic Model, LookML, dbt Semantic Layer, Cube, Snowflake Semantic Views, Databricks Metric Views 같은 모습으로 나타납니다. 다만 제품마다 지원 범위가 달라 지표 정의와 관계 모델링, 권한 집행을 모두 동일하게 지원한다고 보기는 어렵습니다.

Ontology는 기업의 업무 개체·관계·규칙을 구조화한다

Semantic Layer가 비즈니스 언어와 해석 기준을 정리한다면, Ontology는 업무 개체와 그 속성, 개체끼리의 관계, 그리고 지켜야 할 제약과 규칙을 구조로 묶습니다. 기업 데이터는 테이블 하나에 갇혀 있지 않습니다.

고객은 계약으로 이어지고, 계약은 다시 상품과 주문, 청구로 이어집니다. 매출은 이런 업무 이벤트가 회계 인식 기준을 거쳐 나옵니다. 제조 현장이라면 설비와 공정, 품질, 장애 이력이 서로 긴밀하게 연결됩니다.

AI가 데이터를 업무 맥락에서 읽으려면 이 연결을 알아야 합니다. 고객 정보만 들여다보는 것이 아니라, 그 고객이 어떤 상품을 계약했고 어떤 채널로 유입됐으며 어떤 서비스 이력을 가졌는지까지 이어서 봐야 합니다.

Ontology는 고객·계약·상품·채널·정책·이벤트 같은 개체가 각각 무엇을 뜻하는지 정의하고, 그 속성과 관계, 제약과 규칙을 구조로 정리합니다.

AI가 “최근 매출이 왜 줄었는지 찾아줘”라는 요청을 받았다고 해봅시다. 매출 데이터만으로는 답이 나오지 않습니다. 상품별 판매 흐름, 고객군 변화, 계약 조건, 채널 성과, 재고나 공급 이슈까지 이어서 봐야 원인이 잡힙니다.

Ontology는 AI가 이 관계를 따라 데이터를 읽도록 돕는, 말하자면 기업의 업무 세계를 그린 지도입니다.

그런데 이 지도를 이야기하다 보면 비슷한 용어들이 자꾸 끼어듭니다. Semantic Layer, Semantic Model, Ontology, Knowledge Graph는 실무에서 거의 같은 뜻처럼 뒤섞여 쓰이지만, 막상 무엇을 어디까지 만들지 정할 때는 이 구분이 중요해집니다. 맡는 역할이 서로 다르기 때문입니다.

Semantic Layer는 데이터의 의미와 해석 기준을 정리하는 계층입니다. Semantic Model은 특정 분석 영역의 지표와 차원을 정의한 모델입니다.

Ontology는 그 의미를 가진 업무 개체와 속성, 관계, 규칙을 구조로 묶은 의미 모델입니다.

Knowledge Graph는 이 모델을 바탕으로 실제 데이터 인스턴스와 관계를 연결해 탐색하고 추론할 수 있는 그래프로 구현한 형태에 가깝습니다.

이들의 관계를 정리하면 다음과 같습니다. 다만 실제 구현에서는 개념들이 딱 떨어지게 나뉘기보다 일부 기능이 겹쳐 나타나기도 합니다. Knowledge Graph가 반드시 Semantic Layer를 거쳐야만 만들어지는 것도 아닙니다.

원천 데이터와 업무 지식·규칙을 곧장 연결해 구성할 수도 있습니다. 그래도 Semantic Layer의 표준 지표·용어 정의를 참조하면 AI가 활용할 때 해석의 일관성이 높아집니다.



AI-ready Data는 의미 체계 설계로 진화한다

그동안 기업의 데이터 전략은 데이터를 잘 모으고 저장하고 분석하는 데 힘을 쏟아 왔습니다.

데이터웨어하우스에서 데이터레이크, 레이크하우스로 이어진 흐름은 데이터 활용 수준을 크게 끌어올렸습니다.

그런데 이 모든 단계의 밑바탕에는 ‘데이터는 사람이 해석한다’는 전제가 깔려 있었습니다.

AI가 직접 데이터를 읽고 쓰는 환경이라면, 여기에 한 단계가 더해져야 합니다.

이제는 데이터가 정확한지만 아니라 지표와 용어, 관계 정의가 서로 어긋나지 않는지도 챙겨야 합니다.

핵심 지표를 표준화하고, 업무 용어를 정비하고, 주요 개체 사이의 관계를 정의하고, AI가 어떤 데이터를 어떤 권한과 규칙 아래 사용할 수 있는지까지 정해 둬야 합니다. 지표의 의미는 현업의 업무 기준과 닮아 있고, 개체 간 관계는 실제 업무 프로세스와 맞물려 있습니다.

그래서 이 일은 데이터팀 혼자 풀 과제가 아니라, 데이터 조직과 현업 부서, IT 조직이 함께 기준을 잡아야 하는 전략 과제입니다.

Semantic Layer와 Ontology가 이 전환을 떠받칩니다. Semantic Layer는 AI가 참조할 비즈니스 언어를 정리하고, Ontology는 그 언어가 실제 업무 개체와 관계, 규칙 속에서 어떻게 이어지는지를 구조로 보여줍니다. 질문의 무게중심도 옮겨가고 있습니다.

“AI가 접근할 데이터가 있는가”에서 “AI가 이해할 수 있는 의미 체계가 갖춰져 있는가” 로 말입니다.

결국 던져야 할 질문은 분명합니다.

AI-ready Data의 다음 단계는 바로 이 지점, AI가 업무 맥락 안에서 데이터를 이해하도록 의미와 관계를 정리하는 데서 시작됩니다.

댓글

이 블로그의 인기 게시물

곧 만나는 FabriX 2.0, AX 블로그 팔로우 EVENT

Transforming SoC Verification with Claude Code

The Actionable Agent, Brity Automation