팔란티어 뉴스를 보고 이 글을 찾아오셨다면
최근 팔란티어(Palantir)라는 이름을 뉴스에서 자주 접하셨을 겁니다. 대부분은 주가나 정부 계약 관련 소식이지만, 회사 이름과 함께 낯선 단어 하나가 꼭 따라붙습니다. 바로 “온톨로지(Ontology)”입니다.
이 글은 주식 이야기가 아닙니다. 팔란티어를 실제로 운영하는 실무자의 입장에서, 온톨로지가 기술적으로 무엇이고 왜 중요한지를 정리한 글입니다.
사전적 정의의 함정
‘온톨로지’를 검색하면 가장 먼저 나오는 건 철학 용어입니다. “존재론” — 세상에 무엇이 존재하는지, 그 존재들이 어떤 범주로 나뉘는지를 다루는 철학의 한 분야죠. 이 정의를 그대로 들고 팔란티어의 온톨로지를 이해하려 하면 오히려 헷갈립니다.
컴퓨터 과학, 특히 기업 데이터 분야에서 말하는 온톨로지는 훨씬 실용적인 개념입니다. 철학적 사유의 대상이 아니라, 회사가 다루는 실제 업무를 소프트웨어가 이해할 수 있는 형태로 옮겨놓은 모델입니다.
실무 정의: 회사의 현실을 소프트웨어가 이해하는 지도로
풀어서 설명하면 이렇습니다. 온톨로지는 회사 안에 존재하는 것들(고객, 주문, 제품, 설비 같은 “객체”)과, 그것들 사이의 관계(이 고객이 이 주문을 냈다, 이 제품이 이 설비에서 생산됐다), 그리고 그 위에서 일어나는 행동(주문을 승인한다, 재고를 이동한다)을 하나의 구조로 정리해놓은 것입니다.
한마디로 정리하면: 온톨로지는 회사의 현실(객체·관계·행동)을 소프트웨어와 AI가 이해할 수 있게 옮겨놓은 지도입니다.
테이블로 볼 때와 온톨로지로 볼 때
이 차이를 가장 잘 보여주는 예시가 흔한 업무 데이터, 예를 들어 주문-고객-제품-배송입니다.
일반적인 관계형 데이터베이스(RDB)에서는 이 정보가 각각 별도의 테이블에 저장돼 있습니다. 고객 테이블, 주문 테이블, 제품 테이블, 배송 테이블이 따로 존재하고, 이들을 연결하려면 외래키를 따라가며 조인(JOIN)을 해야 합니다. 사람은 이 관계를 SQL 쿼리로 매번 새로 설계해야 하고, AI 입장에서는 이 테이블들이 서로 어떤 의미로 연결되는지 전혀 알 수 없습니다.
온톨로지 관점에서는 이 그림이 달라집니다.
graph LR
A[고객 Object] -->|주문했다| B[주문 Object]
B -->|포함한다| C[제품 Object]
B -->|배송된다| D[배송 Object]
D -->|담당한다| E[배송기사 Object]고객, 주문, 제품, 배송은 각각 독립된 테이블이 아니라 “객체(Object)”가 되고, 그 사이의 화살표는 미리 정의된 “관계(Link)”가 됩니다. 이렇게 정의해두면 “이 고객이 최근 주문한 제품 중 배송이 지연된 게 있는지” 같은 질문이, 매번 새로운 SQL을 짜는 게 아니라 이미 정의된 관계를 따라가는 탐색이 됩니다.
이 매핑을 조금 더 구체적으로 보면 이렇습니다. 데이터베이스 안에서는 TB_CUSTOMER, TB_ORDER, CUST_ID, ORDER_DT처럼 기술적인 이름이 쓰이지만, 온톨로지에서는 이걸 각각 고객(Customer), 주문(Order), 고객 ID, 주문일처럼 실제 업무에서 쓰는 용어로 다시 정의합니다. 단순히 이름만 바꾸는 게 아니라 각 항목에 설명을 붙이고, 코드값이나 속성값도 별도의 객체로 정의해서 의미를 부여합니다. 그 결과 조인으로만 존재하던 테이블 간 연결이 “고객이 주문한다”, “주문이 제품을 포함한다”처럼 사람이 이해하는 업무 관계로 승격됩니다.
왜 지금 이게 중요한가
요즘 기업들은 코딩·문서 요약 같은 개인 생산성 AI는 빠르게 도입하고 있습니다. 그런데 “우리 회사 데이터를 넣고 물어보면 알아서 분석해주는 AI”는 생각보다 잘 작동하지 않습니다. 이유는 간단합니다. LLM은 언어는 잘 이해하지만, 회사 내부의 고객, 주문, 제품 같은 테이블이 실제로 무엇을 의미하고 서로 어떻게 연결되는지는 전혀 모르기 때문입니다.
온톨로지는 이 간극을 메우는 방법입니다. 데이터에 “의미”를 미리 입혀두면, AI는 테이블 이름과 컬럼을 추측하는 대신 이미 정의된 객체와 관계를 따라 정확한 답을 찾을 수 있습니다.
실무에서 느낀 것
운영을 맡게 된 프로젝트에는 이미 여러 온톨로지가 구축되어 있었고, 이를 활용한 화면도 상당히 만들어져 있는 상태였습니다. 다만 보안상의 이유로 외부 AI를 연결할 수 없어서, 그동안은 온톨로지가 AI와 결합했을 때 실제로 어떤 성능을 내는지 확인해볼 기회가 없었습니다.
최근 외부 AI가 개인 사용자에게도 열리면서, 팔란티어의 Ontology MCP를 통해 기존 온톨로지를 활용한 분석을 직접 시도해봤습니다. 그런데 막상 해보니 예상과 달랐습니다. 이미 만들어진 온톨로지의 오브젝트·속성 이름이 비즈니스 용어로 잘 정리되어 있지 않았고, 관계(Link)도 지나치게 많은데 각각이 어떤 의미인지 명확하지 않아서, 실무자인 저조차 이걸 보고 분석하기가 쉽지 않았습니다. AI가 찾아준 결과도 만족스럽지 못했습니다.
이 경험에서 얻은 교훈은 분명했습니다. 온톨로지를 설계할 때는 처음부터 기술 용어가 아니라 실제 업무에서 쓰는 비즈니스 용어로 모델링해야 하고, 관계도 무작정 단계를 늘리기보다 화면 설계와 모델링을 함께 반복하면서 꼭 필요한 만큼만 구성해야 한다는 걸 절감했습니다. 온톨로지 설계 자체를 도와주는 기능이 있으면 좋겠다는 생각도 들었습니다 — 테이블을 넣으면 필드를 비즈니스 용어로 먼저 제안해주고, 사람이 확인·수정할 수 있게 하고, 관계도 함께 제안해주는 식으로요. 여기서 한 가지 더 중요하게 느낀 건, 이름을 영문 우선으로 정의하고 국문은 보조로 붙이는 방식이 AI 성능에도 실제로 도움이 된다는 점이었습니다. 이런 시행착오에서 얻은 원칙들을 앞으로 후배들과 표준으로 공유해서, 같은 실수를 반복하지 않도록 만드는 것이 지금의 목표입니다.
마무리
온톨로지는 철학 용어를 컴퓨터 과학에 억지로 끌어온 것이 아니라, “회사의 현실을 AI가 이해할 수 있게 만드는 방법”이라는 아주 실용적인 문제에서 출발한 개념입니다. 다음 글에서는 이 개념이 실제로 챗봇형 기업 AI가 왜 한계에 부딪히는지와 어떻게 연결되는지 다뤄보겠습니다.