AI에서 말하는 온톨로지란 무엇인가

정의부터, 그리고 그 정의가 왜 쓸모없는지

가장 많이 인용되는 정의는 1993년 Tom Gruber의 것입니다.

온톨로지는 **공유된 개념화(conceptualization)의 명시적 명세(explicit specification)**다.

처음 읽으면 아무것도 남지 않습니다. 저도 그랬습니다. 이 문장이 실제로 말하는 건 네 단어에 다 들어 있습니다.

개념화 — 어떤 도메인을 바라보는 방식. "주문에는 상품이 들어 있고, 주문은 취소될 수 있다" 같은 것.
명시적 — 그 방식이 사람 머릿속이나 코드 주석이 아니라, 기계가 읽을 수 있는 형식으로 적혀 있다.
명세 — 자연어 설명이 아니라 형식 언어로 적혀 있어서, 검증하거나 추론할 수 있다.
공유된 — 한 팀의 사적인 약속이 아니라 여러 시스템이 같이 쓰기로 한 것.

그래서 실무적으로는 이렇게 바꿔 읽는 편이 낫습니다. 온톨로지는 "이 도메인에 어떤 것들이 존재하고, 그것들이 서로 어떤 관계이며, 무엇이 말이 되고 무엇이 말이 안 되는지"를 기계가 읽을 수 있게 적어둔 것입니다.

용어집 → 분류체계 → 온톨로지

셋은 자주 섞여 쓰이지만 표현력이 다릅니다. 위로 갈수록 기계가 할 수 있는 일이 늘어납니다.

	담는 것	기계가 할 수 있는 일
용어집(glossary)	용어와 뜻풀이	검색, 표기 통일
분류체계(taxonomy)	용어 + 상하위 관계	상위 개념으로 묶어서 집계
온톨로지(ontology)	+ 임의의 관계, 제약, 규칙	추론 — 적히지 않은 사실 도출

마지막 줄이 핵심입니다. 온톨로지가 다른 것과 갈리는 지점은 관계를 많이 적는다는 게 아니라, 적지 않은 사실을 끌어낼 수 있다는 것입니다.

구체적으로, 커머스 도메인

RDF는 모든 지식을 주어 - 술어 - 목적어 세 칸(트리플)으로 적습니다.

:주문_1024   :주문자      :고객_77 .
:주문_1024   :포함상품    :상품_5 .
:상품_5      :분류        :노트북 .
:노트북      rdfs:subClassOf  :전자제품 .
:전자제품    rdfs:subClassOf  :공산품 .

여기까지는 분류체계입니다. 온톨로지는 여기에 규칙을 더합니다.

:주문자   a  owl:FunctionalProperty .          # 주문 하나에 주문자는 한 명뿐
:포함상품 owl:inverseOf  :포함된주문 .          # 역방향 관계는 자동으로 성립
:취소된주문  owl:disjointWith  :배송완료주문 .  # 이 둘은 동시에 참일 수 없다

이제 시스템은 아무도 적어주지 않은 것들을 스스로 결론 내립니다.

주문_1024는 공산품을 포함한다 — 노트북 ⊂ 전자제품 ⊂ 공산품을 타고 올라가서.
상품_5는 주문_1024에 포함되어 있다 — inverseOf로부터.
어떤 주문이 취소됨이자 배송완료로 들어오면 데이터가 틀렸다고 판정합니다. 검증 코드를 따로 짜서가 아니라, 논리적으로 모순이라서.

세 번째가 온톨로지의 값이 가장 잘 드러나는 자리입니다. 무결성 규칙이 애플리케이션 코드 여기저기 흩어진 if 문이 아니라, 데이터 옆에 선언으로 붙어 있습니다.

"그거 그냥 DB 스키마 아닌가요"

가장 자주 나오는 질문이고, 정당한 질문입니다. 결정적인 차이는 하나입니다. 적혀 있지 않은 것을 어떻게 해석하느냐.

	관계형 스키마	온톨로지
목적	저장 구조 정의	의미 정의
없는 데이터	거짓 (닫힌 세계 가정, CWA)	모름 (열린 세계 가정, OWA)
규칙의 역할	위반을 막는다	새 사실을 만들어낸다
스키마 변경	마이그레이션	문장 추가
범위	한 데이터베이스	기관·조직을 가로지름

고객.등급 컬럼이 NULL이면 RDB에서는 보통 "등급이 없다"로 처리합니다. 온톨로지에서는 "아직 모른다"입니다. 나중에 다른 출처에서 등급이 들어오면 모순 없이 합쳐집니다.

이 차이는 사소해 보이지만, 여러 조직의 데이터를 합칠 때 결정적입니다. 한 회사 DB 안에서만 놀 거라면 온톨로지가 주는 이점은 대부분 과합니다. 반대로 병원-보험사-제약사처럼 서로 다른 주체가 같은 개념을 다른 이름으로 부르고 있다면, 그 지점이 바로 온톨로지가 만들어진 이유입니다. 의료의 SNOMED CT나 생명과학의 Gene Ontology가 수십 년째 살아 있는 이유이기도 합니다.

LLM이 나왔는데 왜 이 옛날 얘기가 다시 나오는가

온톨로지와 시맨틱 웹은 2000년대에 크게 유행했다가 한 번 가라앉았습니다. 그런데 요즘 다시 언급됩니다. 이유는 하나로 모입니다. RAG가 잘 못 푸는 질문의 종류가 뚜렷하기 때문입니다.

일반적인 RAG는 질문을 벡터로 바꿔 비슷한 문단을 찾아옵니다. 이 방식이 구조적으로 약한 질문들이 있습니다.

다중 홉(multi-hop) 질문 — "A가 인수한 회사의 CTO가 그전에 다니던 곳은?" 답이 한 문단에 없습니다. 세 문서에 나뉘어 있고, 각 조각은 질문과 벡터 유사도가 낮습니다.
집계 질문 — "작년에 계약이 해지된 고객은 총 몇 곳인가?" 유사한 문단 상위 10개를 가져와 봐야 답이 안 나옵니다. 세는 일은 검색이 아니라 질의입니다.
전역 요약 — "이 문서 집합 전체의 주제는 무엇인가?" 어느 문단도 그 답을 담고 있지 않습니다.
부정과 제약 — "결제 실패한 적 없는 고객"은 벡터 공간에서 표현되지 않습니다.

이 넷은 전부 관계를 따라가거나 세는 작업입니다. 그래서 문서를 그래프로 만들고, 그 위에서 질의하는 접근이 다시 나왔습니다. Microsoft의 GraphRAG가 대표적입니다. 문서에서 엔티티와 관계를 추출해 그래프를 만들고, 커뮤니티 단위로 요약해두고, 질문에 따라 벡터 검색과 그래프 순회를 나눠 씁니다.

여기서 온톨로지의 자리는 이렇습니다. LLM이 문서에서 엔티티를 뽑을 때, 무엇을 뽑아야 하는지 알려주는 표적입니다. 온톨로지 없이 추출하면 대표이사, CEO, 최고경영자가 서로 다른 노드가 됩니다. 스키마를 미리 주면 세 표현이 한 관계로 정규화됩니다.

그런데 지금 도입해야 하나

정직하게 쓰겠습니다. 대부분의 팀은 필요 없습니다. OWL 추론기를 붙이는 프로젝트는 대개 비용이 이득보다 큽니다. 온톨로지 구축은 도구 문제가 아니라 합의 문제이고, 합의는 사람 시간을 아주 많이 먹습니다.

도입을 고민할 만한 신호는 이 정도라고 봅니다.

같은 개념을 팀마다 다른 이름으로 부르고 있고, 그 사전을 누구도 관리하지 않는다.
질문의 상당수가 위의 1~4번(다중 홉·집계·전역 요약·부정) 유형이고, RAG 품질이 청킹을 아무리 고쳐도 오르지 않는다.
데이터가 여러 조직을 넘나들고, 각자 자기 스키마를 못 바꾼다.

셋 중 하나도 해당하지 않는데 그래프 DB부터 도입하고 있다면, 순서가 뒤바뀐 겁니다.

그리고 대부분의 경우 온톨로지 전체가 아니라 그 앞 단계로 충분합니다. 용어 사전을 하나 만들고, 엔티티 타입 열 개와 관계 열 개를 정해 LLM 추출 프롬프트에 넣는 것. 이것도 이미 "명시적 명세"이고, 실무 효과 대부분은 여기서 나옵니다. schema.org 어휘를 그대로 빌려 쓰는 것도 좋은 출발입니다. 처음부터 직접 만들 이유가 별로 없습니다.

자주 섞이는 것들

지식그래프 ≠ 온톨로지. 온톨로지는 스키마(클래스와 규칙), 지식그래프는 그 스키마를 따르는 실제 데이터(인스턴스)입니다. 테이블 정의와 행의 관계에 가깝습니다. Wikidata는 지식그래프이고, 그 안의 속성 정의가 온톨로지 층에 해당합니다.
LLM이 온톨로지를 대체하지 않습니다. LLM은 "말이 되는 문장"을 잘 만들지만, 무엇이 참인지 검증하지는 않습니다. 온톨로지는 정확히 그 검증을 합니다. 둘은 경쟁이 아니라 다른 층입니다.
추론과 검증은 다릅니다. OWL은 새 사실을 도출하는 쪽이고, 데이터가 규격에 맞는지 확인하는 일은 SHACL이 맡습니다. "필수 필드 검사"를 하고 싶었던 거라면 필요한 건 OWL이 아니라 SHACL일 가능성이 높습니다.

정리

온톨로지는 의미를 기계가 읽을 수 있게 적어둔 것입니다. 저장 구조가 아니라 의미입니다.
분류체계와 갈리는 지점은 관계의 양이 아니라 추론 가능 여부입니다.
DB 스키마와 갈리는 지점은 없는 데이터를 "거짓"으로 볼지 "모름"으로 볼지입니다.
LLM 시대에 다시 나오는 이유는 RAG가 다중 홉·집계·전역 요약·부정 질문에 약하기 때문입니다.
그렇더라도 대부분의 팀에 필요한 건 OWL이 아니라 합의된 용어 사전 한 장입니다.

여러분의 RAG는 어떤 질문에서 무너지던가요? 그게 청킹 문제였는지 구조 문제였는지가 궁금합니다.

출처

Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition, 5(2), 199–220. — 가장 널리 인용되는 온톨로지 정의의 원문.
W3C. OWL 2 Web Ontology Language Document Overview — 클래스, 속성, FunctionalProperty, disjointWith 등 이 글에 쓴 구성요소의 규범 문서.
W3C. RDF 1.1 Concepts and Abstract Syntax — 트리플 모델과 열린 세계 가정.
W3C. Shapes Constraint Language (SHACL) — 추론이 아니라 검증을 맡는 쪽.
Edge, D. et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization — GraphRAG 논문. 구현체는 microsoft/graphrag.
Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — RAG 원 논문.
schema.org, Wikidata, SNOMED CT, Gene Ontology — 실제로 운영되는 어휘·온톨로지 사례.