온톨로지는 개념과 개념 사이의 관계를 명시적으로 정의하는 구조다. 원래 철학에서 “존재란 무엇인가”를 따지는 분야였지만, IT에서는 지식을 체계적으로 표현하는 방법으로 쓰인다. 최근 RAG의 한계가 드러나면서 온톨로지 개념이 다시 주목받고 있다.
나는 RAG 파이프라인을 운영하면서 벡터 유사도의 한계를 체감했다. 검색은 되는데 답변 품질이 기대에 못 미쳤고, 원인을 파고들다 온톨로지라는 단어를 자주 마주치게 됐다. 많이 들어봤지만 정확히 뭔지는 몰랐다. 그래서 정리해봤다.
온톨로지 개념의 출발점
클래스, 속성, 관계로 세상을 정리하는 방법
온톨로지는 철학에서 온 단어다. 그리스어 ontos(존재)와 logos(학문)의 합성어로, 원래는 “존재하는 것들의 분류”를 뜻했다. IT 분야에서는 1993년 톰 그루버가 내린 정의가 가장 많이 인용된다. “개념화의 명시적인 명세(an explicit specification of a conceptualization).” 이후 여러 연구자가 “공유된(shared)”, “형식적인(formal)”을 덧붙여 지금은 “공유된 개념화의 형식적이고 명시적인 명세”로 통용된다(출처). 한 줄로 줄이면, 특정 분야의 개념들과 그 관계를 누구나 같은 방식으로 이해할 수 있게 정리한 것이다.
도서관을 떠올리면 이해가 빠르다. 도서관에는 분류 체계가 있다. “문학”이라는 큰 범주 아래 “소설”, “시”, “수필”이 있고, 각 책은 저자, 출판연도, 장르 같은 속성을 갖는다. “소설”과 “저자”는 “~에 의해 쓰였다”라는 관계로 연결된다. 온톨로지 개념도 이와 같다.
온톨로지를 구성하는 요소는 크게 세 가지다. 클래스(Class)는 개념의 범주다. “동물”, “포유류”, “고양이”처럼 계층 구조를 이룬다. 속성(Property)은 클래스가 가진 특성이다. “고양이”는 “이름”, “나이”, “품종” 같은 속성을 갖는다. 관계(Relation)는 클래스 사이의 연결이다. “고양이는 포유류에 속한다”, “수의사는 고양이를 진료한다”처럼 개념 간 의미를 정의한다.
단순한 목록과 다른 점이 여기 있다. 온톨로지는 “고양이는 포유류다”라는 상위-하위 관계를 명시한다. 이 관계가 있으면 “포유류의 특성”을 고양이에도 적용할 수 있다. 단순히 데이터를 나열하는 게 아니라, 데이터 사이의 의미를 정의하는 것이 온톨로지 개념의 핵심이다.
스키마와 온톨로지 개념의 차이
스키마는 제약, 온톨로지는 추론
여기까지 읽으면 한 가지 의문이 생긴다. “그거 RDB 스키마랑 뭐가 다른데?” 테이블을 만들고, 컬럼을 정의하고, FK로 관계를 잡는 것도 결국 개념과 관계를 정의하는 일이니까.
겉보기에는 비슷하다. 하지만 결정적인 차이가 있다. RDB 스키마는 데이터의 저장 구조를 정의한다. “이 컬럼은 정수형이다”, “이 테이블은 저 테이블과 FK로 연결된다”는 제약 조건의 목록이다. 온톨로지는 여기서 한 단계 더 나아간다. 개념 사이의 논리적 관계를 정의하고, 그 관계에서 새로운 사실을 추론할 수 있다.
예를 들어보자. “고양이는 포유류에 속한다”와 “포유류는 동물에 속한다”를 온톨로지에 정의하면, 시스템은 “고양이는 동물이다”라는 사실을 스스로 추론한다. RDB 스키마에서는 이런 추론이 불가능하다. 고양이와 동물의 관계를 알려면 직접 JOIN 쿼리를 작성해야 한다. 스키마는 제약 조건의 평면적 목록이고, 온톨로지는 논리의 그래프다.
이 차이를 표현하는 대표적인 언어가 OWL(Web Ontology Language)이다. OWL은 클래스 간 상속, 속성 제약, 동치 관계 같은 논리 규칙을 정의할 수 있다. RDB의 DDL이 “테이블 구조”를 선언하는 언어라면, OWL은 “개념 구조와 추론 규칙”을 선언하는 언어다.
팔란티어가 온톨로지를 택한 이유
이 차이를 실무에 적용한 대표적인 사례가 팔란티어다. 팔란티어의 Foundry 플랫폼은 데이터셋 위에 온톨로지를 시맨틱 레이어로 올린다. 기존 데이터를 오브젝트, 속성, 링크로 매핑해서 조직 전체의 데이터를 하나의 의미 체계로 통합한다(출처). 팔란티어는 이를 “조직의 디지털 트윈”이라고 부른다.
흥미로운 점은 팔란티어의 온톨로지가 학술적 온톨로지(RDF/OWL)와는 다르다는 것이다. 자동으로 생성되는 지식 그래프가 아니라, 사용자가 직접 설계하는 운영 레이어에 가깝다. 그래프 DB처럼 Cypher로 질의하는 것도 아니다. 본질은 데이터 웨어하우징의 스타 스키마와 비슷하지만, 비즈니스 맥락을 데이터에 입히는 방식이 다르다. 팔란티어 온톨로지에 대해서는 별도 글에서 다룰 예정이다.
RAG에서 온톨로지 개념이 다시 주목받는 이유
유사도는 의미를 모른다
RAG는 질문을 받으면 관련 문서 청크를 검색해서 LLM에 넘긴다. 검색 기준은 벡터 유사도다. 질문과 청크를 임베딩 벡터로 변환하고, 거리가 가까운 것을 가져온다. 이 방식은 대부분의 경우 잘 작동한다.
문제는 유사도가 의미를 모른다는 점이다. “여왕”과 “왕”은 임베딩 공간에서 매우 가깝다. 벡터 거리만 보면 관련성이 높다. 하지만 실제로는 다른 개념이다. “여왕의 역할”을 물었는데 “왕의 역할”에 대한 청크가 딸려오면 답변 품질이 떨어진다. 유사하다는 것과 관련 있다는 것은 같지 않다.
청킹 품질도 영향을 준다. 전처리가 부실한 데이터, 맥락이 잘린 청크가 들어오면 LLM 성능이 아무리 좋아도 garbage in, garbage out이다. 벡터 검색은 입력 데이터의 구조를 모른다. 어떤 개념이 어떤 개념과 어떻게 연결되는지 알지 못한 채, 표면적 유사성만으로 판단한다.
온톨로지가 채우는 것
온톨로지는 벡터 검색이 놓치는 의미 관계를 명시적으로 채운다. “여왕”과 “왕”이 “군주”라는 상위 클래스에 속하지만 서로 다른 인스턴스라는 사실, “여왕”이 “왕비”와는 동의어이지만 “왕”과는 대비 관계라는 사실을 구조로 정의해둔다. 검색할 때 이 구조를 참조하면, 유사도만으로 판단할 때보다 정확한 청크를 가져올 수 있다.
이런 접근을 OG-RAG(Ontology-Grounded RAG)라고 부른다. 2024년 12월 마이크로소프트 연구팀이 발표한 방법으로, 도메인 온톨로지를 하이퍼그래프로 구성해서 RAG의 검색 단계에 통합한다(출처). 기존 RAG가 비정형 문서에서 청크를 가져오는 데 그쳤다면, OG-RAG는 온톨로지의 엔티티와 관계 정보를 함께 참조해서 맥락을 보강한다. EMNLP 2025에 관련 논문이 발표됐고, 마이크로소프트는 오픈소스로도 공개했다(출처).
온톨로지 개념이 RAG에서 주목받는 이유가 여기에 있다. 벡터 유사도는 “비슷한 것”을 찾는 데 강하고, 온톨로지는 “관련 있는 것”을 정의하는 데 강하다. 둘은 경쟁이 아니라 보완 관계다.
온톨로지 개념을 알아야 하는 이유
AI 시대의 경쟁력은 데이터의 양이 아니라 데이터의 연결에 있다. 같은 데이터를 가지고 있어도 개념 간 관계를 정의해둔 조직과 그렇지 않은 조직의 결과물은 다르다. 온톨로지는 그 연결을 만드는 방법이다.
온톨로지 개념은 어렵지 않다. 클래스, 속성, 관계. 이 세 가지로 세상을 정리하는 방법이다. 다만 그 단순한 구조가 추론을 가능하게 하고, RAG의 한계를 보완하고, 조직의 데이터를 하나의 의미 체계로 묶는다. 이름은 철학에서 왔지만, 쓰임은 철저히 실용적이다.