그의 말을 빌리자면, 현장에서 진짜 문제를 해결하려면 단순히 답변을 잘 생성하는 AI가 아니라, 해당 도메인의 지식과 맥락을 구조적으로 이해하는 AI가 필요합니다. 그리고 그 지식과 맥락을 담는 그릇이 바로 온톨로지입니다.
온톨로지 구축 방법, 데이터 사이언티스트의 실제 업무 과정 모두 공개
시가총액 3,000억 달러 돌파, 매출 137% 상승.
AI 업계에서 팔란티어가 뜨거운 관심을 받고 있습니다. 전 세계가 AI 붐에 휩싸이고 있지만, 그 중에서도 팔란티어가 주목받는 이유는 무엇일까요? 그 이면에는 온톨로지가 있습니다.
팔란티어의 CEO 알렉스 카프는 '슬롭 AI(Slop AI)'를 비판해왔습니다. 슬롭 AI란, 겉으로 보면 그럴듯해 보이지만 정작 실제 업무에는 도움이 되지 않는 AI를 말하죠.
🤖
팔란티어가 온톨로지를 핵심 경쟁력으로 삼은 이후, 많은 기업들이 온톨로지를 다시 주목하기 시작했습니다.
온톨로지란 정확히 무엇일까요?
온톨로지란 개념들 사이의 관계를 명시적으로 정의한 지식 구조입니다.
개별 개념은 그 자체로만 의미를 가집니다. 온톨로지는 개별적인 개념만 존재하는 게 아니라, 개념들 사이의 관계와 맥락까지 기계가 이해할 수 있는 형태로 구조화된 것입니다. 관계와 맥락을 바탕으로 AI가 정확하게 추론할 수 있습니다.
온톨로지의 구성 요소
온톨로지는 여러 구성 요소로 이루어지지만, 그 중 핵심은 이 세 가지입니다. 하나라도 빠지면 그저 데이터 목록에 불과해요.
Classes (클래스): 온톨로지에서 다루는 핵심 개념입니다. “무엇이 존재하는가?”를 정의하는 단계입니다. 예를 들어 설비, 센서, 공정, 직원, 고객처럼 시스템이 바라보는 대상 자체를 의미합니다.
Properties (속성/관계): 개념과 개념 사이의 연결, 혹은 개체의 속성값을 정의하는 요소입니다. 온톨로지에서 가장 중요한 부분 중 하나로, AI가 단순 데이터 저장을 넘어 관계 기반 추론을 할 수 있게 만듭니다.
Axioms (추론 규칙): 관계와 조건을 기반으로 새로운 사실을 추론하기 위한 논리 규칙입니다. 예를 들어 “모터가 과열 상태이고 공정B에서 사용 중이라면, 공정B를 중단해야 한다”, “특정 온도 이상이면 과열 상태다” 같은 규칙을 통해 AI가 단순 저장을 넘어 의미를 해석하고 판단할 수 있게 됩니다.
왜 온톨로지가 필요한 걸까?
위 질문을 보다 구체적으로 바꾸면 다음과 같습니다.
“온톨로지가 우리 비즈니스에 구체적으로 어떤 도움이 될까?”
기술에는 흥망성쇠가 있습니다. 아무리 좋다고 해도 실제로 우리 회사에 도움이 되지 않으면 쓸 이유가 없죠. 기대를 잔뜩 받다가 현장에서 외면받게 됩니다.
💥
그런데 페블러스는 온톨로지에 대한 이 열기가 오랜 시간 지속될 것이라고 예상합니다. 이유는 단순합니다. AI가 고도화될수록 온톨로지의 필요성이 함께 커지기 때문입니다. AI 성능의 한계가 모델이 아니라 데이터 구조에서 온다는 사실이 점점 명확해지고, 그 구조를 다루는 기술이 바로 온톨로지입니다.
‼️
AI가 고도화된다는 것은 실무 현장에 맞춰진 AI가 만들어진다는 뜻이기도 합니다. 신입사원같이 서툰 AI가 아니라, 실무 현장을 이해하고 있는 AI, 10년차 경력직같은 퍼포먼스를 내는 AI를 개발할 수 있는 것입니다.
온톨로지 구축 방법 7단계
그렇다면 온톨로지를 어떻게 구축해야 할까요? 총 7단계에 걸쳐 말씀드리겠습니다.
1단계: 범위 결정
온톨로지가 이미 실패한 채 시작할 수 있다는 사실, 알고 계신가요?
시작 단계에서 범위를 명확하게 정하지 않으면 방향을 잃게 됩니다. 관련된 개념을 끝없이 추가하다 보면, 온톨로지는 지나치게 많은 범위를 복잡하게 정의한 구조물이 되어버리죠.
그래서 이 단계에서 가장 먼저 해야 할 일은 ‘역량 질문(Competency Questions, CQ)’을 정의하는 것입니다. 온톨로지가 반드시 답할 수 있어야 하는 핵심 질문 목록을 미리 써두어야 합니다.
제조 AI를 예로 들면 이런 질문들입니다. 이렇게 질문 목록들을 써두면 온톨로지 전반의 기준이 됩니다.
라인 C가 멈췄을 때 연관된 공정은 무엇인가?
모터가 과열되면 어떤 점검 절차가 실행되어야 하는가?
특정 센서 값이 기준치를 초과했을 때 담당자는 누구인가?
2단계: 클래스 정의
온톨로지의 핵심은 관계입니다. 개념을 아무리 잘 정리해도 그 사이의 관계가 허술하면 AI는 추론하지 못하니까요. 그래서 이 단계의 목표는 핵심 개념을 추려내고, 그 사이의 관계를 구조화하는 것입니다.
실제로 구축된 온톨로지를 보면서 2단계에 대해 설명드리려 합니다. 외교부가 공개한 온톨로지 클래스 연관도를 볼까요? 외교부는 외교안보연구소 발간자료, 보도자료, 브리핑, 외교일지 총 4가지 데이터셋을 공개하고 있습니다. 아래 예시처럼 실제 추론이나 의사결정에 영향을 주는 개념들을 모두 열거하고, 그 사이에서 관계를 정의해야 합니다.
💻
네 가지 문서들이 각자 존재하면 "이 브리핑과 저 보도자료가 같은 사건을 다루고 있다", "이 인물이 이 국가와 연관된다"는 관계를 매번 연결 짓기가 어렵습니다. 온톨로지는 바로 이 연결을 구조화하여 의미 있게 활용할 수 있게 해요.
우선 외교부에서는 지역, 국가, 도시, 인물, 기관, 사건, 연도를 핵심 데이터(Core Ontology Class)로 구성했습니다. 민트색 원형 항목들이 코어 온톨로지 클래스인 것이죠.
이 핵심 데이터를 중심에 있는 발간자료/브리핑/보도자료/외교일지와 연결해 LOD(Linked Open Data)로 발행했습니다. 모든 화살표가 중심을 향하는 구조가 바로 이 연결 관계를 표현한 것입니다.
빨간 화살표는 SubClassOf, 즉 하위 관계를 표현하는 것입니다. 도시는 지역의 하위 개념이고, 인물은 foaf:Agent의 하위 개념이죠.
회색 화살표는 Object Property, 즉 개념 간 관계입니다. relatedCountry, hasCity, hasPosition, relatedDept처럼 관계마다 의미가 명확하게 구분되어 있습니다.
3단계: 속성 정의
또한 외교부가 이 온톨로지를 만든 목적은 결국 하나입니다.
"어떤 외교 문서가 어떤 사건과 관련 있고, 거기에 어떤 인물과 기관이 개입했으며, 어느 국가의 얘기인가?"
‘속성’ 하나하나가 바로 그 질문에 대한 답이라고 보시면 됩니다. 이 부분도 외교부 온톨로지 Property 구조를 보면 확인해보겠습니다.
맨 위의 Owl:Thing이 최상위 개념입니다. 온톨로지에서 존재하는 모든 것이 여기서 출발하고, rdfs:subClassOf 화살표로 아래 클래스들이 펼쳐집니다.
왼쪽부터 보면 발간자료, 브리핑, 외교일지, 보도자료가 클래스로 정의되어 있습니다. 각각 안에 postingDate(게시일), dataURL(원문링크), abstract(요약) 같은 속성들이 정의되어 있습니다.
공간 클래스는 geo:SpatialThing을 최상위로, mofa:Area(지역), schema:Country(국가), schema:City(도시)가 계층적으로 파생됩니다. 만약 이 중에 도시만 있고 국가와 연결이 없으면 상위 맥락으로 올라가는 추론이 불가능해집니다.
행위자 클래스는 foaf:Agent를 최상위로, foaf:Person(인물), foaf:Organization(기관), mofa:Division(부서), mofa:Position(직책)으로 나누어집니다.
foaf:Person을 자세히 보면 hasPosition(직책), relatedCountry(연관 국가), relatedEvent(연관 사건)처럼 속성이 구체적으로 정의되어 있습니다. 직책을 정의해야 같은 이름의 인물이라도 외교부 장관으로서 발언한 건지, 연구원으로서 쓴 건지에 따라 문서의 맥락, 중요도가 완전히 달라집니다. 또한 이 인물이 어느 나라와 관련된 외교 활동을 했는지를 추론하려면, 인물과 국가가 속성으로 연결되어 있어야 하죠.
눈에 띄는 속성이 있는데, 그 정체는 owl:sameAs 입니다. 여러 클래스에 공통으로 들어가 있는데, 서로 다른 온톨로지에 존재하는 두 개체가 실세계에서 동일한 대상임을 표현하기 위한 속성입니다. 예를 들어 외교부 온톨로지의 ‘김OO 외교관’과 외부 기관 데이터베이스의 ‘김OO’이 같은 사람임을 명시하는 것입니다. 같은 온톨로지 내에서뿐만 아니라, 다른 온톨로지와 연결하여 더욱 넓은 범위에서 추론이 가능한 AI를 만들 수 있는 것이죠.
💡
덧붙여 온톨로지 형태로 구조화되어 있지만, 클래스와 속성에 자연어 설명을 달아두시는 게 좋습니다. 유관 부서 외에 다른 부서와 협업하는 상황처럼 자연어 설명이 필요한 순간이 있으니까요!
4단계: 추론 규칙 정의
클래스와 관계를 정의했다면, 이제 그 관계에서 새로운 사실을 도출하는 추론 규칙(Axioms) 을 정의해야 합니다
현장에서 실제로 여러분이 지키고 계신 규칙들을 담으면 됩니다. 제조 AI를 예로 들면 이런 규칙들을 들 수 있습니다.
모터가 과열 상태이고 공정B에서 사용 중이라면 → 공정B를 중단해야 한다
공정B가 중단되면 → 라인C도 점검해야 한다
점검 매뉴얼이 존재하고 과열 조건이 충족되면 → 담당자에게 알림을 전송해야 한다
이 규칙들이 없으면 클래스와 관계가 아무리 잘 정의되어 있어도 AI는 스스로 판단을 내리지 못합니다. 데이터를 저장하는 시스템에 머물 뿐, 추론하는 시스템이 되지 못하는 거죠.
한 가지 주의할 점이 있습니다. 추론 규칙은 강력하지만 남용하면 독이 됩니다. 규칙이 많아질수록 서로 충돌하거나 예상치 못한 추론 결과가 나올 수 있거든요. 꼭 필요한 규칙만, 명확한 조건으로 정의하는 것이 중요해요!
5단계: 제약조건 설정
잘못된 데이터가 들어오는 걸 막기 위해, 추론의 신뢰도를 높이기 위해 제약 조건을 설정해주시면 좋습니다. 그래서 제약조건을 설계하기 전에 반드시 먼저 결정해야 할 것이 있습니다.
“우리의 온톨로지가 어떤 세계관 위에 서 있어야 할까?”
크게 두 가지 세계관으로 나누어지고 있습니다.
개방 세계 가정 (Open World Assumption)
명시되지 않은 건 모르는 것이다.
OWL 같은 전통적인 온톨로지 표준 언어가 따르는 방식입니다. 조금 더 자세히 풀어보자면, 시스템에 "A는 B이다"라는 명제가 없다고 해서 "A는 B가 아니다"라고 단정하지 않습니다. “알 수 없음”이라고 가능성을 열어두는 것입니다.
유연함은 장단점이 있습니다. 복잡하고 비정형적인 지식 관계를 유연하게 표현하는 데 탁월합니다. 다만 참과 거짓이 명확하게 나누어지는 기업의 일부 시스템에는 부적합할 수 있습니다.
폐쇄 세계 가정 (Closed World Assumption)
명시되지 않은 건 거짓이다.
팔란티어가 택한 방식입니다. 기업 내부의 데이터에 대해 가능성을 열어두지 않고, 이미 주어진 데이터 그 자체로 완전하다고 생각합니다. 따라서 ‘모르겠다’처럼 모호하게 답하지 않고, 참과 거짓을 명확히 처리할 수 있습니다. 이런 구조가 있으면 업무 자동화가 중단 없이 실행될 수 있습니다.
또한 팔란티어는 객체-속성-링크 기반의 관리형 스키마를 채택하여 안정적으로 운영할 수 있습니다. 변수를 최소화한 방식이라고 보시면 됩니다. 기존 소프트웨어 개발 방식(OOP)과 잘 맞아떨어져 실무 적용 속도가 빠르고요.
6단계: 인스턴스 생성
인스턴스는 클래스로 정의한 구조에 실제 값이 채워진 것입니다.
제조 AI의 온톨로지의 일부를 예를 들어보겠습니다.
온톨로지 구조: Motor - temperature (온도) - status (상태) - location (위치)
인스턴스: Motor_A12 - temperature = 95 - status = 과열 - location = 3호 라인
이처럼 실제로 인스턴스를 넣다 보면 예상치 못한 문제들이 튀어나옵니다. 모터 데이터를 넣었는데 연결해야 할 공정이 클래스로 정의되어 있지 않아서 오류가 발생합니다.
설계할 때 놓치고 있었던 보조 모터 같은 개체가 나타나 기존 클래스로는 구분이 안 되기도 합니다. temperature = 95를 과열로 정의했는데, 특정 공정에서는 95도가 정상 범위인 예외 케이스가 나오기도 합니다.
📍
여러분의 온톨로지에도 인스턴스를 넣어보세요. 만약 인스턴스를 넣었는데 오류가 났다면? 오히려 좋습니다. 실무에 투입하기 전 미리 오류를 잡아내는 것이니까요. 온톨로지 구축 방법에 따라 정교하게, 완벽하게 구축한 것 같아도, 막상 실무에서는 오류가 발생할 수 있습니다.
7단계: 품질 관리
오류를 잡아냈다면, 이제 마지막 단계입니다. 그런데 많은 분들이 여기서 방심합니다. 다 만들었다고 끝이 아닙니다. 이 단계를 건너뛰면 6개월 후에 아무도 못 씁니다.
6단계에서 인스턴스를 넣었을 때는 구조적 오류, 정합성의 오류를 발견해낼 수 있습니다. 그런데 7단계에서는 별도로 추론 테스트를 해보셔야 합니다.
데이터가 모두 들어간 상태에서 "AI가 의도한 대로 추론할 수 있는가?" 를 확인하는 작업입니다. 어쩌면 Axiom(추론 규칙)이 잘못 정의됐거나, 관계가 끊겨 있을지도 모릅니다. 제약조건이 추론을 막고 있을 수도 있고요.
과연 온톨로지만으로 충분할까요? 해답은 ‘뉴로-심볼릭’입니다.
그런데 페블러스는 이 글을 읽고 계신 분들께 한 가지 질문을 드리려 합니다.
“과연 온톨로지의만으로 충분할까요?”
AI의 거장 헨리 카우츠는 이렇게 온톨로지의 미래를 예측했습니다.
“딥러닝의 직관과 상징적 추론의 논리가 결합된 뉴로-심볼릭 AI가 미래다. 그리고 이 논리적 사고를 가능하게 하는 뇌의 지도가 바로 온톨로지다.”
뉴럴 AI가 현실의 패턴을 감지합니다. 온톨로지에서 미리 정의하지 못한 패턴까지 처리할 수 있도록 패턴을 감지합니다.
이후 클래스, 속성, 추론 규칙 등이 담긴 온톨로지를 기반으로 하여 심볼릭 AI는 실제로 실행합니다. 규칙을 읽고, 현재 데이터에 적용하고, 결론을 도출하는 주체인 것이죠.
💣
온톨로지 구축 방법에 따라 개발한 AI는 이전보다 똑똑해집니다. 그런데 알고 보면 똑똑한 것과 신뢰할 수 있는 것은 엄연히 다릅니다. 제조, 의료, 금융, 자율주행, 국방처럼 판단 실수 하나가 큰 사고로 이어지는 분야에서는 AI가 왜 그런 결론을 냈는지 설명할 수 있어야 합니다. 설명이 안 되는 AI는 현장에서 신뢰받기 어렵습니다.
🧩
온톨로지 위에 뉴로 심볼릭을 결합하면 이 문제를 해결할 수 있습니다. 규제 기관의 감사가 나왔을 때 AI의 판단 근거를 문서로 제출할 수 있는 수준이 되는 것이죠.
온톨로지와 뉴로 심볼릭에 대해 보다 심도 있게 파악하고 싶은 분들을 위해, 페블러스가 추가 콘텐츠를 준비했습니다.
페블러스에서 위 질문을 포함하여, 온톨로지와 뉴로 심볼릭에 관한 수많은 궁금증에 대해 답을 드립니다. 오늘 이 글이 시작점이었다면, 아래 허브에서 다음 단계로 나아가보세요.
오늘 소개해드린 온톨로지 구축 방법, 어떠셨나요? 위 과정대로 직접 구축해보셨는데 원하는 퀄리티가 나오지 않으셨다면, 그건 방법을 몰라서가 아닐 가능성이 높습니다. 우리 기업에 맞는 구조를 찾는 과정이 생각보다 까다롭기 때문입니다.
🔍
사실 이 글에 담은 내용은 완성형이라기보다는 시작점이라 보시면 됩니다. 실제 구축 과정에서는 기업과 기관마다 도메인이 다르고, 데이터 구조가 다르고, 풀어야 할 문제가 다릅니다. 한 장의 글로 그 모든 경우를 담기에는 한계가 있다고 생각합니다.
페블러스와 함께하는 고객사들은 그 한계를 넘어서고 있습니다. 각 기업의 도메인에 맞는 온톨로지 설계부터, 실무 데이터를 기반으로 한 검증, 뉴로 심볼릭 결합까지 함께 진행하기 때문입니다.
직접 구축해보셨는데 원하는 퀄리티가 나오지 않으셨다면, 페블러스에 문의 부탁드립니다. 페블러스 내부 전문가들이 2~3일 내에 빠르게 도와드리겠습니다.
페블러스는 단순한 데이터 정리를 넘어, 실무 현장의 복잡한 인과관계를 담아내는 AI-Ready 데이터 구축 방법론을 보유하고 있습니다. 물리 법칙과 도메인 지식을 결합한 월드 모델 설계부터, AI의 직관과 논리적 추론을 연결하는 뉴로-심볼릭 결합까지, 페블러스만의 독보적인 기술력으로 여러분의 AI를 가장 신뢰할 수 있는 전문가로 만들어 드립니다.
본 기사는 페블러스의 기획 하에 AI를 보조적으로 활용하여 작성되었으며, 페블러스의 엄밀한 감수를 거쳐 출간되었습니다.