article · 2026-08-14
같은 ‘온톨로지’라는 말을 하면서도, 우리는 다른 레이어를 보고 있었다
DB schema, knowledge graph, semantic layer는 서로 다른 질문에 답한다
DB schema, knowledge graph, semantic layer는 서로 다른 질문에 답한다
“이미 데이터가 구조화되어 있는데, 왜 온톨로지가 필요한가요?”
그때 나는 이 질문이 가리키는 전제를 충분히 이해하지 못했다. 나는 고객, 계약, 주문, 담당자 같은 현실의 개념과 관계를 먼저 떠올렸다. 반면 이 질문은 테이블, 컬럼, PK와 FK가 이미 정리된 시스템을 전제로 하고 있었다. 둘 다 ‘구조’를 말하지만, 내가 보고 있던 구조와 질문 속의 구조가 같지 않았다.
나는 한동안 이 차이를 충분히 분리하지 못했다. Ontology를 말하면서 knowledge graph를 상상했고, 질문을 던진 사람은 DB schema와 데이터 통합을 전제로 하고 있었다. 그래서 대화가 겉으로는 이어져도, 내가 답하려는 질문은 원래 질문과 조금 비켜가 있었다.
이 글은 그 혼선을 정리하려는 시도다. Ontology, knowledge graph, semantic layer를 완벽하게 하나의 정의로 고정하려는 글은 아니다. 대신 실제 시스템을 만들 때, 세 단어가 각각 어떤 문제를 풀고 어떤 문제를 풀지 못하는지 구분해 보려 한다.
“구조화되어 있다”는 말만으로는 충분하지 않다
CRM에는 customer_no가 있다. 청구 시스템에는 account_id가 있다. 고객 지원 도구에는 user_key가 있다.
각 시스템의 데이터는 이미 잘 정리돼 있을 수 있다. 컬럼의 타입도 정해져 있고, 중복도 관리하며, 조인도 가능하다. 이 상태에서 “온톨로지가 필요하다”고 말하면, 당연히 이런 반문이 나온다.
이미 schema가 있는데, 무엇을 더 만들자는 건가요?
DB schema가 답하는 질문은 분명하다.
어떤 값을 저장하는가?
어느 테이블의 어느 컬럼에 있는가?
값의 형식과 제약은 무엇인가?
어떤 키로 연결할 수 있는가?
이것만으로도 매우 중요하다. 하지만 schema만으로 세 시스템의 키가 같은 현실의 대상을 가리키는지까지 자동으로 합의되지는 않는다.
예를 들어 customer_no = 29331, account_id = A-109, user_key = u_9931이 실제로 같은 사람이나 같은 고객 조직과 연결되는지 생각해 보자. 더 나아가 계정과 고객, 계약과 구독, 고객 문의와 주문은 각각 어떤 관계인지도 생각해 보자. 컬럼은 값을 담는다. 반면 업무는 그 값이 무엇을 뜻하는지, 무엇과 연결될 수 있는지를 요구한다.
여기서부터 ‘구조화된 데이터’와 ‘공유된 의미’는 다른 말이 된다.
Ontology는 그래프가 아니라, 현실을 읽는 약속에 가깝다
Stanford의 Ontology Development 101은 ontology를 특정 영역의 용어와 그 용어 사이 관계에 대한 명시적 형식화로 설명한다. 그 목적에는 공통된 이해를 공유하고, 도메인 지식을 재사용하며, 도메인에 대한 가정을 드러내는 일이 포함된다. 또한 ontology 설계는 처음부터 완성되는 작업이 아니라, 그것을 사용할 과업을 기준으로 반복하는 과정이다. Stanford Protégé — Ontology Development 101
조금 더 실무적인 말로 바꾸면 ontology는 다음과 같은 합의다.
Customer는 무엇인가?
Account는 Customer와 같은 것인가, Customer가 가질 수 있는 별도 대상인가?
Subscription은 어떤 상태를 가질 수 있는가?
SupportCase는 누구와 무엇에 연결되는가?
이 질문은 데이터베이스의 물리적 설계보다 앞선다. 테이블이 한 개인지 여러 개인지와 별개로, 팀이 Customer라는 말을 어디까지 같은 뜻으로 쓸지를 정한다. 서로 다른 시스템에서 customer, account, user라는 이름이 등장해도, 그것들이 동의어인지 상하위 개념인지 전혀 다른 대상을 뜻하는지 명시할 수 있다.
W3C의 OWL 2 Primer가 class, property, individual을 구분하는 이유도 여기에 있다. Customer라는 종류, hasSubscription이라는 관계, 그리고 실제 특정 고객이라는 개별 대상을 다른 층위에서 표현해야 하기 때문이다. OWL은 이런 관계를 풍부하게 표현하고 그 관계에 관한 추론을 지원하도록 설계된 언어다. W3C — OWL 2 Web Ontology Language Primer
따라서 ontology를 ‘그래프 데이터베이스에 넣을 노드 목록’으로만 이해하면 중요한 부분이 빠진다. 더 중요한 것은 노드의 모양이 아니라, 무엇을 같은 개념으로 볼지와 어떤 관계가 성립할 수 있는지에 대한 약속이다.
Knowledge graph는 그 약속 위에 쌓인 현재의 사실이다
그러면 knowledge graph는 무엇일까.
가장 단순하게 보면, knowledge graph는 개별 대상과 사실을 연결해 둔 그래프다. 고객 A는 계정 B를 가진다, 계정 B에는 구독 C가 있다, 고객 A가 문의 D를 열었다처럼 실제 인스턴스와 관계를 연결한다.
[Customer: Acme]
│ hasAccount
▼
[Account: A-109]
│ hasSubscription
▼
[Subscription: S-204]
│ isRelatedTo
▼
[SupportCase: C-817]
여기서 ontology는 대상의 종류와 가능한 관계를 설명한다. knowledge graph는 지금 시스템 안의 고객, 계정, 구독, 문의가 실제로 어떻게 연결되는지를 담는다.
둘은 대체 관계가 아니다. Stanford의 지식 그래프 강의 노트도 자동으로 획득한 지식을 쌓는 상향식 접근과 schema·ontology를 만드는 하향식 접근이 서로 보완될 수 있다고 설명한다. 특히 기업 데이터 통합에서는 schema와 ontology가 중심 역할을 하기도 한다. Stanford CS520 — What is a Knowledge Graph?
그래서 “온톨로지를 만들자”는 말만으로는 아직 구현 방법이 정해지지 않는다. 어떤 팀은 먼저 핵심 개념과 관계를 정의한 뒤 그래프를 채울 수 있다. 다른 팀은 여러 데이터 소스에서 사실을 모으고, 충돌이 반복되는 지점부터 공통 모델을 정교화할 수 있다. 어느 쪽이든 목적이 먼저다. 검색을 개선하려는지, 추천을 하려는지, 운영 화면에서 하나의 고객 맥락을 보여 주려는지에 따라 필요한 표현의 깊이가 달라진다.
Semantic layer는 여러 시스템이 같은 약속으로 일하게 만드는 자리다
현장에서 혼란이 가장 자주 생기는 지점은 여기다. Ontology가 개념의 약속이라면, semantic layer는 그 약속을 실제 데이터와 도구가 사용할 수 있게 연결하는 자리로 볼 수 있다.
예를 들어 운영자가 “이번 달 갱신 위험이 높은 고객”을 보고 싶다고 하자. 이 문장에는 단순한 SQL 컬럼명이 없다. 고객은 CRM의 고객일 수도 있고 청구 계정 기준일 수도 있다. 갱신은 계약 종료일, 구독 상태, 결제 실패 이력과 함께 봐야 할 수 있다. 위험은 지원 문의 증가, 사용량 하락, 담당자 판단을 결합한 규칙일 수 있다.
semantic layer는 이 업무 언어를 데이터 자산에 연결한다.
업무 질문
“갱신 위험이 높은 고객은 누구인가?”
↓
공유 개념과 계산 기준
Customer / Subscription / RenewalRisk
↓
소스 데이터와 매핑
CRM / Billing / Product analytics / Support
↓
화면, 분석, 자동화
여기서 semantic layer는 단일 표준 용어가 아니라 운영상의 구분이다. Ontology가 ‘무엇을 뜻하는가’를 정한다면, semantic layer는 그 뜻이 데이터 소스와 조회·분석·업무 화면에서 일관되게 작동하게 만든다. 그래서 데이터 모델, 매핑, 권한, 계산 규칙, API와 함께 나타나는 경우가 많다.
이 구분을 하면 “우리는 ontology가 있다”는 말도 더 정확해진다. 개념 사전만 있는가. 여러 시스템의 레코드를 그 개념에 매핑했는가. 현재 사실을 그래프로 연결했는가. 아니면 그 위에서 사람이 질문하고 행동할 수 있는 운영 모델까지 만들었는가. 같은 단어 아래 서로 다른 성숙도가 숨어 있을 수 있다.
Triple 형식은 같아도, 출발점과 검증은 달랐다
돌이켜 보면 내가 몰랐던 차이는 더 구체적이었다. 나는 문서에서 subject, predicate, object 형태의 triple을 추출하고 연결하는 작업을 먼저 떠올렸다. RDF에서 triple은 두 resource 사이의 관계를 표현하는 기본 문장이며, triple의 집합은 graph가 된다. W3C — RDF 1.1 Primer
예를 들어 문장에서 다음 사실을 얻을 수 있다.
[GPU 가격] ── 상승했다 ──> [2026년 2분기]
이런 triple을 많이 모으면 대상과 관계를 탐색할 수 있는 knowledge graph를 만들 수 있다. NLP의 Open Information Extraction은 자연어 텍스트에서 사실을 추출해 <subject, predicate, object> triple로 표현하는 과업으로 정의된다. Hohenecker et al. — Open Information Extraction
내가 익숙했던 흐름은 이쪽이었다.
문서·웹·리포트
↓ triple 추출·정규화
knowledge graph
↓ 개념과 관계를 기준으로 구조화
조회 가능한 semantic layer
↓
검색·비교·추천·질의
Semantic Atlas를 처음 상상할 때도 마찬가지였다. 다양한 출처에서 model, benchmark, task, metric에 대한 사실을 뽑아 graph로 연결하고, 그 구조를 semantic layer로 다시 조회하는 방식이다. 데이터를 구조화한 결과가 다시 질의와 비교의 기준이 되는, 양방향의 흐름이었다.
하지만 그 질문이 놓인 데이터·시스템 맥락은 반대 방향에서 시작한다. CRM의 customer_no, 청구 시스템의 account_id, 지원 도구의 user_key처럼 이미 존재하는 운영 시스템의 DB schema, field, entity를 하나의 domain model 아래에서 해석하고 연결하는 일이다. Ontology-based data access 연구에서는 이 구조를 ontology, 여러 data source, 그리고 둘 사이 mapping의 세 구성요소로 설명한다. Daraio et al. — Ontology-based data access
기존 DB schema·API·이벤트 로그
↓ source-to-domain mapping
공통 domain model
↓
semantic layer
↓
여러 시스템을 가로지르는 조회·분석·운영 화면
여기서 중요한 수정이 있다. 현장의 ontology 기반 통합도 table과 row를 ontology concept와 instance로 매핑하고, 그 결과를 triple graph로 만들 수 있다. IT benchmarking의 ontology 기반 통합 연구는 relational schema를 ontology concept에, table row를 ontology instance에 매핑하는 과정을 구체적으로 보인다. Pfaff & Krcmar — Ontology for Semantic Data Integration
학술적으로도 이 구분은 낯설지 않다. Description Logic 기반 OBDA에서는 개념 모델을 나타내는 TBox와, 개별 instance에 대한 assertion을 나타내는 ABox를 구분한다. 다만 현장에서는 이 둘과 mapping, graph를 묶어 모두 ontology라고 부르기도 한다. 그래서 용어의 경계보다 지금 어떤 산출물을 만들고 어떤 오류를 막으려는지 확인하는 편이 더 중요하다. Daraio et al. — Ontology-based data access
그러므로 triple을 구조화하는 일과 ontology 기반 통합은 완전히 분리된 두 세계가 아니다. 둘 다 graph와 triple을 쓸 수 있다. 차이는 출발점과 검증 단위에 있다.
| 관점 | Knowledge graph에서 semantic layer를 만든다 | 기존 DB schema를 semantic layer로 엮는다 |
|---|---|---|
| 주된 입력 | 문서·웹페이지·리포트에서 얻은 문장과 사실 | DB, API, 이벤트 로그에 이미 있는 record와 field |
| 설계 순서 | fact 추출 → graph 구조화 → semantic query | source schema 분석 → domain mapping → semantic query |
| 먼저 묻는 질문 | 어떤 entity와 relation을 문장에서 추출할 것인가? | 서로 다른 ID와 field가 같은 업무 개념을 뜻하는가? |
| 핵심 검증 | 추출 사실이 원문 근거와 일치하는가? entity와 relation을 올바르게 정규화했는가? | source field·record가 target concept·property와 올바르게 대응하는가? |
| 핵심 산출물 | provenance를 가진 fact graph와 조회 모델 | canonical domain model, mapping 규칙, 필요하면 가상 또는 물리적 graph |
| 대표적 실패 | 같은 문장을 다른 관계로 추출하거나, 근거가 불명확하다 | 같은 고객·상태·매출을 시스템마다 다르게 해석한다 |
따라서 이번 경험을 “학술 용어를 개발자 언어로 바꾸지 못했다”라고만 정리하면 반쯤만 맞다. 내가 먼저 구분했어야 했던 것은 semantic layer에 도달하는 두 방향이었다. 나는 추출한 fact를 graph로 구조화해 semantic layer를 만드는 방향을 알고 있었다. 질문이 출발한 맥락은 이미 있는 schema의 의미와 식별자를 맞춰 semantic layer로 엮는 방향이었다. 전자는 추출 정확도와 provenance가, 후자는 mapping 정확도와 개념 정렬이 핵심 품질 기준이 된다.
그 뒤에야 번역이 가능해진다. “공통 의미 체계가 필요하다”가 아니라, “CRM의 customer_no와 청구 시스템의 account_id를 같은 customer domain model 아래에서 해석할 규칙이 필요하다”라고 말할 수 있다. 개념 하나를 공부할 때도 학술 용어, 데이터 엔지니어링 용어, 제품의 업무 언어를 함께 적어 둘 이유가 여기에 있다.
Palantir가 말하는 ontology는 한 단계 더 운영 쪽으로 확장된다
Palantir Foundry는 ontology를 디지털 자산과 현실의 대상을 연결하는 운영 레이어로 설명한다. 그 안에는 object, property, link 같은 semantic 요소뿐 아니라 action, function, dynamic security 같은 kinetic 요소도 포함된다. Palantir Foundry — Ontology architecture
Customer를 이해한다
↓
Customer의 계약·사용량·문의 맥락을 함께 본다
↓
조건을 충족하면 담당자가 갱신 리스크를 검토한다
↓
권한을 가진 사람이 할인 승인 또는 지원 escalation을 실행한다
다만 여기에는 구분이 필요하다. Palantir의 정의는 일반적인 ontology의 유일한 정의가 아니다. 제품 아키텍처가 ontology를 중심으로 데이터, 권한, 애플리케이션 행동까지 묶는 방식이다. 즉 ontology 자체가 곧 action engine이라는 뜻은 아니다. 제품은 개념 모델 위에 실행과 보안을 붙여, 조직이 실제로 움직일 수 있는 운영 레이어로 확장한 것이다.
이 차이를 놓치면 두 가지 오해가 생긴다. 하나는 “ontology를 만들면 자동으로 시스템이 행동한다”는 기대다. 다른 하나는 “그 정도까지 하지 않으면 ontology가 아니다”라는 오해다. 둘 다 아니다. 개념의 합의, 사실의 연결, 실행의 설계는 연결되어 있지만 서로 다른 일을 한다.
회의에서 먼저 확인해야 할 한 문장
온톨로지 논의가 시작될 때, 나는 이제 이렇게 묻는 편이 낫다고 생각한다.
지금 말씀하신 ‘구조화’는 DB schema가 정리되어 있다는 뜻인가요? 아니면 여러 시스템이 같은 도메인 개념과 관계를 공유한다는 뜻인가요?
이 질문 하나로 논의의 출발점이 달라진다.
| 지금 필요한 것 | 먼저 풀어야 할 문제 | 산출물의 예 |
|---|---|---|
| DB schema | 저장·조회·무결성 | 테이블, 컬럼, PK/FK, 제약 조건 |
| Ontology | 공통 개념과 관계 | 용어 정의, 클래스, 관계, 제약 |
| Knowledge graph | 개별 사실의 연결 | entity, relation, provenance가 연결된 그래프 |
| Semantic layer | 여러 시스템에서의 일관된 활용 | 매핑, 공통 지표, 조회 모델, API·권한 규칙 |
| Operational layer | 사람이 결과를 행동으로 바꾸는 흐름 | action, 승인 단계, 워크플로우, audit |
이 표는 표준 분류 체계가 아니라, 실제 제품 논의에서 누락된 질문을 찾기 위한 작업용 지도다. 한 레이어를 잘 만들었다고 다음 레이어가 자동으로 생기지는 않는다.
가령 데이터 팀이 schema를 정리해도, 고객 성공 팀과 재무 팀이 활성 고객을 다르게 정의하면 분석 결과는 여전히 충돌한다. 반대로 개념 정의가 좋아도, 소스 데이터와의 매핑과 식별자 해소가 없으면 실제 화면에서 어떤 고객의 맥락도 보여 줄 수 없다. 그리고 그래프가 연결되어 있어도, 누가 어떤 조건에서 어떤 action을 실행할 수 있는지가 없다면 운영은 바뀌지 않는다.
결국 ontology는 ‘그래프’보다 먼저 조직의 언어를 다룬다
Semantic Atlas를 고민하며 내가 처음 붙잡았던 것은 AI model을 비교할 수 있는 ontology였다. 모델의 성능, 비용, 입력 조건, 과업 적합도를 기록하면 목적에 맞는 모델을 찾을 수 있을 것이라고 생각했다.
그런데 비교를 시작하려면 먼저 task, quality, latency, suitable 같은 단어가 무엇을 뜻하는지 합의해야 했다. ‘토픽 분석’도 VOC에서는 고객의 잠재 의도를 찾아야 할 수 있고, 논문 분석에서는 주요 객체 사이 논리 구조를 보존해야 할 수 있다. 이름이 같다고 같은 과업이 아니었다.
사용자가 무엇을 알고 싶고, 그 답을 바탕으로 무엇을 하려는지부터 묻지 않으면 개념 모델은 장식이 되기 쉽다. 목적이 있어야 기준이 생기고, 기준이 있어야 어떤 데이터와 관계를 연결할지 정할 수 있다.
Ontology는 데이터를 더 멋지게 보이게 하는 그래프가 아니다. 조직이 현실을 어떤 단위로 읽고, 어떤 사실을 연결하며, 어떤 행동으로 이어 갈지를 합의하는 언어다. DB schema는 그 언어를 저장한다. Knowledge graph는 현재의 사실을 연결한다. Semantic layer는 여러 시스템이 그 언어로 일하게 한다. 그리고 운영 레이어는 그 이해를 행동으로 바꾼다.
다음에 비슷한 대화를 하게 된다면, 나는 먼저 물어야겠다. 지금 말하는 것은 문서에서 fact를 추출해 graph로 구조화하는 일인가, 운영 시스템의 entity와 field를 같은 domain model로 정렬하는 일인가, 아니면 두 작업을 연결하는 일인가. 그 답을 상대의 기술 언어로 한 번 더 말할 수 있을 때, 이 단어는 추상적인 유행어가 아니라 실제 시스템의 빈칸을 찾아내는 도구가 된다.