월요일 아침, 식품 유통 회사의 영업팀장이 묻습니다. “새봄마트 이번 주 미출고 주문이 몇 건이지?” 담당자는 ERP에서 주문 목록을 내려받고, 창고 엑셀과 품목 코드를 맞춰 보고, 배송 기사 단톡방에서 오늘 실린 물건을 확인합니다. 30분이 지나서야 “세 건입니다”라는 답이 나옵니다.

같은 질문을 사내 AI 챗봇에 해도 답은 나오지 않습니다. AI는 이 회사에서 ’미출고’가 무슨 뜻인지, 주문과 출고 기록이 어떻게 이어지는지 모르기 때문입니다. 팔란티어가 이 문제에 내놓은 답이 ’온톨로지(Ontology)’입니다.

온톨로지: 철학 용어에서 제품의 한 층으로

온톨로지는 원래 ’존재론’이라는 철학 용어입니다. 컴퓨터과학에서는 1993년 스탠퍼드의 토머스 그루버가 내린 정의가 널리 쓰입니다. 그는 온톨로지를 “개념화의 명시적 명세(an explicit specification of a conceptualization)“라고 불렀습니다. 풀어 쓰면, 어떤 분야에 무엇이 있고 그것들이 서로 어떤 관계인지를 모두가 같은 뜻으로 쓰도록 약속해 적어 둔 것입니다.

팔란티어의 온톨로지는 이 개념을 실제 제품으로 만든 것입니다. 공식 문서는 온톨로지를 “조직을 위한 운영 계층(operational layer)“이라고 정의합니다. 회사가 가진 데이터 표, 모델 같은 디지털 자산 위에 한 층을 얹고, 이를 공장·설비·제품 같은 물리적 대상이나 고객 주문·금융 거래 같은 개념과 하나하나 연결한다는 뜻입니다. 문서는 많은 경우 온톨로지가 조직의 ‘디지털 트윈’, 즉 회사를 그대로 옮겨 놓은 디지털 복제본 역할을 한다고 설명합니다.

팔란티어는 연차 보고서에서 온톨로지를 자사 플랫폼의 “심장”이라고 부릅니다. 또 공식 문서에서는 온톨로지가 “단순히 데이터가 아니라 기업의 결정을 표현한다”고 강조합니다. 이 차이가 이 글 전체의 핵심입니다. 데이터를 잘 정리하는 도구는 많지만, 그 데이터로 내리는 결정과 그 결정의 실행까지 한 모델에 담으려는 시도는 드뭅니다.

네 가지 부품: 객체, 속성, 링크, 액션

팔란티어 문서는 온톨로지를 우리에게 익숙한 표(데이터셋)에 빗대어 설명합니다. 앞의 식품 유통 회사로 옮기면 이렇습니다.

엑셀·데이터베이스에서는 온톨로지에서는 식품 유통 회사의 예
시트(표) 하나 객체 유형(object type) 거래처, 주문, 품목, 재고 로트
행 한 줄 객체(object) 새봄마트, 주문 번호 0915-031
열 속성(property) 결제 조건, 거래처 등급, 담당 영업사원
칸 하나의 값 속성 값 “월말 결제”, “A등급”
VLOOKUP·조인 링크 유형(link type) 거래처와 주문, 주문과 품목
(해당 없음) 액션 유형(action type) 출고 확정, 단가 변경 승인

객체 유형은 현실의 대상이나 사건을 정의한 틀입니다. ’거래처’라는 유형을 만들면 새봄마트처럼 거래처 목록의 한 줄 한 줄이 그 유형의 객체가 됩니다.

속성은 그 대상의 특징이고, 링크는 대상 사이의 관계입니다. 거래처 하나에 주문이 여러 건 달리고, 주문 하나에 품목이 여러 개 들어가는 식입니다. 링크가 정의돼 있으면 “이 거래처의 주문 → 그 주문의 품목 → 그 품목의 재고”를 쿼리 없이 클릭으로 따라갈 수 있습니다.

엑셀에 없는 마지막 줄이 액션입니다. 팔란티어 문서는 액션을 “사용자가 정한 로직에 따라 하나 이상의 객체를 한 번에 바꾸는 단일 트랜잭션”이라고 정의합니다. 문서의 예시는 직원의 직책을 바꾸는 ‘직원 배치’ 액션입니다. 새 직책을 정해진 양식으로 입력받고, 새 관리자와의 관계를 자동으로 연결하고, 전·현 관리자에게 알림을 보내며, 인사팀만 실행할 수 있게 검증합니다.

식품 유통 회사라면 ‘출고 확정’ 액션을 이렇게 정의할 수 있습니다. 입력값은 주문, 차량, 출고 수량입니다. 실행 조건은 재고가 주문 수량 이상이고 실행하는 사람이 창고 담당자일 것입니다.

실행하면 재고가 차감되고, 주문 상태가 ’출고 완료’로 바뀌고, 거래처에 출고 알림이 나가고, ERP에도 같은 내용이 반영됩니다. 여기에 “유통기한 7일 이내 재고부터 배정한다” 같은 계산 규칙은 함수로 붙입니다.

네 가지 부품: 객체, 속성, 링크, 액션 관련 장면
AI 생성 이미지

팔란티어는 객체와 링크를 기업의 “명사”, 액션을 “동사”라고 부릅니다. 명사만 있으면 현재 상태를 볼 수 있을 뿐이고, 동사가 붙어야 일이 됩니다. 사람이나 AI가 판단 로직을 거쳐 명사와 동사를 엮으면 “새봄마트 주문 0915-031을 오후 2시 차량으로 출고 확정한다” 같은 완전한 문장이 만들어진다는 것이 팔란티어의 설명입니다.

’현실의 지도’라는 비유

온톨로지를 흔히 ’현실의 지도’에 비유합니다. 지하철 노선도를 떠올리면 이해가 쉽습니다.

노선도는 실제 거리나 선로 모양이 정확하지 않습니다. 대신 역 이름과 환승 관계만큼은 틀림없습니다. 노선도의 목적이 “어디서 갈아타야 하나”라는 결정을 돕는 데 있기 때문입니다. 온톨로지도 회사의 모든 데이터를 그대로 옮기지 않고, 결정에 필요한 대상과 관계를 골라 정확하게 그립니다.

다만 온톨로지는 종이 지도와 두 가지가 다릅니다. 첫째, 원천 시스템이 바뀌면 지도가 따라 바뀝니다. ERP에 새 주문이 들어오면 온톨로지의 주문 객체도 갱신됩니다.

둘째, 지도 위에서 바로 행동할 수 있습니다. 액션을 실행하면 그 결과가 ERP나 창고 시스템에 다시 기록됩니다. 팔란티어 문서는 이렇게 행동까지 닫히는 고리가 “운영 시스템과 분석 시스템을 가르는 차이”라고 설명합니다.

팔란티어는 모든 업무상 결정을 네 가지 요소로 나눠 봅니다.

요소 뜻 식품 유통 회사의 예
데이터 결정에 쓰이는 정보 주문, 재고 수량, 유통기한
로직 결정을 평가하는 규칙과 계산 유통기한 임박 재고 우선 배정, 수요 예측
액션 결정의 실행 출고 확정, 발주 요청
보안 결정이 회사 규칙을 지키는지 보장 원가는 구매팀만, 출고 확정은 창고 담당자만

공식 문서의 다른 예도 같은 구조입니다. 항공사라면 항공편, 기체, 승무원 명단, 운항 일정 최적화 모델을 온톨로지에 담습니다. 병원이라면 환자, 간호사 근무표, 의료 소모품, 병상 가동률을 담습니다. 업종마다 명사와 동사는 달라도 뼈대는 같습니다.

AI 에이전트 시대에 다시 주목받는 이유

대규모 언어 모델(LLM)은 말은 잘 알아듣지만 우리 회사의 구조는 모릅니다. 도입부의 질문이 막힌 것도 그래서입니다. ’미출고’가 주문 상태 값 중 무엇을 뜻하는지, 어느 표의 어느 열을 봐야 하는지 알려 주지 않으면 AI는 추측할 수밖에 없습니다. 온톨로지는 AI에게 세 가지를 줍니다.

첫째는 어휘입니다. 거래처, 주문, 미출고 같은 말이 정확히 무엇을 가리키는지 정의돼 있으니 AI가 회사의 말을 알아듣습니다.

둘째는 관계입니다. “배송이 늦어진 품목 때문에 영향받는 거래처 주문”처럼 여러 단계를 건너야 하는 질문도 정의된 링크를 따라가면 답이 나옵니다. 셋째는 울타리입니다. AI가 무언가를 바꾸려면 사람과 똑같이 정해진 액션을 거쳐야 하고, 그 액션에 걸린 검증 규칙과 권한을 그대로 적용받습니다.

사내 문서를 찾아 답하는 AI는 검색 증강 생성(RAG)이라는 방식을 주로 쓰는데, 이 원리는 사내 규정에 묻고 답하는 AI에서 다룹니다. 팔란티어는 2026년 4월 블로그에서 온톨로지가 에이전트를 RAG의 “데이터 중심적 한계” 너머로 데려간다고 주장했습니다. 문서를 찾아 읽는 데서 그치지 않고, 데이터와 계산 로직과 액션을 모두 AI가 쓸 수 있는 ’도구’로 내준다는 뜻입니다. 연차 보고서도 AIP가 조직의 액션과 업무 절차를 “사람과 LLM 에이전트가 쓰는 도구”로 바꾼다고 설명합니다.

같은 글에 나오는 가상의 의료기기 제조사 사례는 AI에게 권한을 넘기는 순서를 잘 보여 줍니다. 공급업체 문제로 원자재가 모자라자, AI 에이전트가 온톨로지 안의 재고·생산·주문 데이터와 배분 모델을 써서 대체 생산 계획을 제안합니다. 기본 설정에서 AI는 계획을 ’준비’만 하고 최종 실행은 사람이 검토한 뒤에 합니다. 기록이 쌓여 믿을 만하다고 판단된 반복 업무부터 사람 검토 없이 실행하도록 범위를 조금씩 넓힙니다.

권한 관리도 같은 틀 안에서 이뤄집니다. 팔란티어 문서에 따르면 에이전트가 도구를 쓸 수 있는지는 데이터 접근 권한과 같은 보안 체계로 판단되며, 에이전트는 사용자나 프로젝트의 권한 범위를 물려받습니다. 영업팀원이 원가를 볼 수 없다면 그 팀원이 부리는 AI도 원가를 볼 수 없습니다.

AI 에이전트 시대에 다시 주목받는 이유 관련 장면
AI 생성 이미지

한계와 비용도 함께 봐야 합니다

온톨로지는 저절로 생기지 않습니다. 흩어진 원천 시스템을 객체와 링크로 옮기는 일은 업무와 데이터를 모두 아는 사람이 해야 하는 판단 작업이라, 도입 초기에는 팔란티어의 현장 배치 엔지니어가 주도하는 경우가 많습니다. 또 팔란티어의 온톨로지는 대개 원천 데이터를 자체 저장소에 색인해 두고 그 사본으로 움직입니다. 한 번 깊이 들이면 다른 도구로 옮기기 어렵다는 뜻이기도 합니다.

실제로 2026년 6월 팔란티어 고객 행사에서 한 고객사 관계자가 “오픈소스 그래프 데이터베이스나 OpenAI·Anthropic으로 비슷한 것을 만들어 보고 싶다”며 “팔란티어는 개방적이지 않다”고 말한 사실이 UBS 보고서를 통해 알려졌습니다. 반대로 팔란티어는 온톨로지가 데이터 위에 이름만 붙인 얇은 ’의미 계층(semantic layer)’이 아니라, 데이터·로직·액션·보안을 함께 묶은 시스템이라 얇은 의미 계층으로는 구현할 수 없다고 강조합니다.

설계에서 흔한 실수는 너무 많이 그리는 것입니다. 링크 하나하나가 누군가 따라갈 길이고, 그 관계가 틀리거나 오래되면 곧바로 잘못된 결정으로 이어집니다. 회사의 모든 데이터를 모델링하려 들기보다 자주 내리는 결정에 쓰이는 대상과 관계부터 정확하게 그리는 편이 낫습니다.

중소기업이 배울 점: 엑셀로 시작하는 ‘우리 회사 온톨로지’

팔란티어를 들이지 않아도 온톨로지의 생각은 가져올 수 있습니다. 무엇이 있고, 서로 어떻게 이어지고, 누가 무엇을 바꿀 수 있는지를 먼저 적는 것입니다. 식품 유통 회사를 예로 순서를 정리하면 다음과 같습니다.

  1. 결정 하나를 고릅니다. 예를 들어 “오늘 오후 차량에 어떤 주문부터 싣나”처럼 매일 반복되고 틀리면 비용이 큰 결정이 좋습니다.
  2. 그 결정에 나오는 명사를 적습니다. 대개 5~7개면 충분합니다. 거래처, 주문, 주문 품목, 품목, 재고 로트, 배송이 여기에 해당합니다.
  3. 명사마다 고유 번호(키)를 정합니다. 거래처 코드는 한 곳에서만 발급합니다. “㈜새봄마트”, “새봄마트 본점”, “새봄” 같은 표기가 섞여 있다면 이 단계에서 하나로 정리합니다.
  4. 관계를 적습니다. 거래처 하나에 주문 여러 건(1:N), 주문과 품목은 여러 개 대 여러 개(N:N)라서 ’주문 품목’이라는 중간 대상을 둡니다.
  5. 동사를 적습니다. 누가, 어떤 조건에서, 무엇을 바꾸는지 한 줄로 씁니다. “출고 확정: 창고 담당자, 재고가 주문 수량 이상일 때, 재고 차감과 주문 상태 변경.”
  6. 권한을 적습니다. 영업은 판매 단가를 보지만 원가는 못 보는 식으로, 대상과 속성별로 볼 수 있는 사람을 정합니다.
  7. 용어집을 한 장 만듭니다. ‘매출’, ‘미출고’, ’반품’처럼 부서마다 뜻이 다르게 쓰이는 말을 하나로 정의합니다.

이렇게 정리한 결과는 아래 같은 표 한 장이 됩니다.

객체 키 주요 속성 연결되는 객체
거래처 거래처 코드(C-0001) 등급, 결제 조건, 담당 영업사원 주문
주문 주문 번호 주문일, 납품 요청일, 상태 거래처, 주문 품목, 배송
품목 품목 코드 규격, 보관 온도, 판매 단가 주문 품목, 재고 로트
재고 로트 로트 번호 수량, 유통기한, 창고 위치 품목
배송 배송 번호 차량, 출발 시각, 기사 주문

엑셀을 쓰는 회사라면 시트를 객체별로 나누고, 시트끼리는 이름이 아니라 코드로만 연결하는 것부터 시작하면 됩니다. 거래처명으로 VLOOKUP을 거는 습관만 없애도 표기 차이 때문에 조회가 빠지는 오류를 막을 수 있습니다. 이 표는 나중에 데이터베이스나 업무 툴을 만들 때 그대로 설계서가 되고, AI 챗봇이나 자동화를 붙일 때 AI에게 건네줄 어휘집이 됩니다. 업무 절차를 문서로 정리하는 일과 짝을 이루는 작업이라, 자동화보다 매뉴얼이 먼저인 이유와 함께 읽으면 좋습니다.

팔란티어의 온톨로지는 수많은 엔지니어가 오랜 시간 다듬은 제품이지만, 출발점은 소박합니다. 우리 회사에 무엇이 있고, 그것들이 어떻게 이어지며, 누가 어떤 조건에서 무엇을 바꿀 수 있는지를 정확히 적는 일입니다. AI를 들일 때 이 한 장이 있으면 AI에게 우리 회사를 무엇으로, 어떻게 설명할지가 훨씬 분명해집니다.

이렇게 정리한 객체 목록을 실제 업무 도구로 옮기는 과정은 맞춤 업무 툴 개발에 소개해 두었습니다.

참고한 자료