온톨로지의 속을 열어봅니다 — 트리플부터 추론 엔진까지

트리플·클래스·공리·추론 엔진·SPARQL까지, 온톨로지가 데이터를 어떻게 '이해'로 바꾸는지 그 속을 초심자도 따라올 수 있게 하나씩 살펴봅니다.

여러분의 시스템에 "고객이 몇 명인가요?"라고 물으면 대부분 즉시 답이 돌아옵니다. 그런데 "이 고객과 저 주문은 어떤 관계인가요?", "이 부서가 저 부서의 상위 조직인가요?"라고 물으면 시스템은 대개 침묵합니다. 값은 분명히 그 안에 들어 있는데도 말입니다. 이 간극을 한 문장으로 요약하면 이렇습니다. 기계는 데이터를 읽을 수는 있지만, 이해하지는 못합니다. 읽는 것과 이해하는 것은 전혀 다른 일입니다.

앞선 글들에서 온톨로지가 무엇인지, 그리고 왜 지금 다시 필요한지를 살펴봤습니다. 이번에는 한 걸음 더 들어갑니다. 그 '읽기'와 '이해' 사이의 간극을 실제로 메우는 기술의 속을 직접 열어 보겠습니다. 트리플이라는 최소 단위부터 추론 엔진까지, 온톨로지가 데이터를 이해로 바꾸는 부품들을 하나씩 뜯어봅니다.

'읽기'와 '이해' 사이의 간극

먼저 우리가 익숙한 세계에서 출발해 보겠습니다. 관계형 데이터베이스(RDB)의 표는 행과 열로 이뤄져 있습니다. 고객 테이블에 '김철수', '영업1팀'이라는 값이 들어 있다고 해 보겠습니다. 기계는 이 값을 정확히 조회하고, 정렬하고, 합계를 냅니다. 하지만 딱 거기까지입니다. '김철수'가 사람이라는 것도, '영업1팀'이 조직이라는 것도, 둘 사이에 '소속'이라는 관계가 있다는 것도 기계는 스스로 알지 못합니다. 값을 글자로 나열할 뿐, 그 글자가 무엇이고 서로 어떻게 얽히는지는 모르는 상태입니다.

관계를 잇는 도구가 아예 없는 것은 아닙니다. RDB에는 JOIN이 있습니다. 하지만 JOIN은 사람이 미리 "이 열과 저 열을 연결하라"고 지정해야 작동합니다. 어떤 테이블을 어떤 키로 이을지 설계자가 알려 주지 않으면 데이터베이스는 아무것도 연결하지 못합니다. 기계가 관계를 아는 것이 아니라, 사람이 아는 관계를 기계에 대신 적어 주는 셈입니다.

이 차이가 왜 지금 중요할까요? 검색 결과를 사람이 눈으로 읽고 판단하던 시절에는 '읽기'만으로 충분했습니다. 하지만 AI에게 판단과 실행의 상당 부분을 맡기는 시대에는 사정이 다릅니다. AI가 데이터를 스스로 해석하고 관계를 따라가며 결론을 내려야 한다면, 데이터는 '읽히는' 수준을 넘어 '이해되는' 수준이어야 합니다. 온톨로지는 바로 이 '이해'를 기계에 심으려는 시도입니다. 지금부터 그 부품들을 하나씩 열어 보겠습니다.

왜 지금, 다시 온톨로지인가

온톨로지는 새로운 개념이 아닙니다. 뿌리를 따지면 수십 년 전 지식 표현 연구까지 거슬러 올라갑니다. 그런데 오래된 이 개념이 최근 몇 년 사이 다시 수면 위로 떠올랐습니다.

가장 큰 계기는 생성형 AI, 특히 LLM(Large Language Model)의 확산입니다. LLM은 방대한 텍스트에서 통계적 패턴을 학습해 '그럴듯한' 답을 확률적으로 생성합니다. 놀랍도록 유창하지만, 그 유창함이 곧 정확함은 아닙니다. 사실과 다른 내용을 자신 있게 만들어 내는 '환각(hallucination)' 문제가 대표적입니다. 여기서 명시적 규칙과 검증된 관계를 담은 지식 구조, 즉 온톨로지와 지식그래프(knowledge graph)가 확률적 추론을 보완하는 장치로 다시 주목받게 됐습니다. 검색으로 근거를 보강하는 그래프RAG(Graph RAG)가 논의되는 흐름도 같은 맥락입니다.

또 하나의 계기는 Agentic AI입니다. 사람의 지시를 한 번 받아 답만 내놓는 것이 아니라, AI가 스스로 여러 단계를 계획하고 도구를 호출하며 일을 처리하는 방식입니다. 이렇게 자율성이 커질수록 AI가 딛고 설 데이터의 '이해 가능성'이 중요해집니다. 관계를 따라가고, 규칙에 따라 결론을 내리려면 데이터에 의미와 규칙이 명시돼 있어야 하기 때문입니다. 오래된 기술이 새 기술의 필요 때문에 다시 호출된 셈입니다. 그렇다면 그 '이해'는 구체적으로 어떤 부품으로 만들어질까요? 가장 작은 조각부터 보겠습니다.

최소 단위: 트리플(Triple)과 RDF

앞에서 표는 관계 자체를 값으로 적지 못한다는 한계를 봤습니다. 그렇다면 관계를 어떻게 데이터로 표현할 수 있을까요? 온톨로지의 출발점은 데이터를 표가 아니라 문장으로 적는 것입니다.

그 문장의 형식이 바로 트리플(triple)입니다. 이름 그대로 세 요소로 이뤄집니다. 주어(subject) — 술어(predicate) — 목적어(object). 우리가 쓰는 "누가 / 무엇을 / 어찌한다"와 똑같은 구조입니다. "김철수는 영업1팀에 소속된다"라는 문장을 그대로 데이터로 적을 수 있는 것입니다. 표에서는 '소속'이 열 이름으로만 존재했다면, 트리플에서는 '소속'이라는 관계 자체가 하나의 값이 됩니다.

이렇게 트리플로 지식을 표현하는 표준 틀을 RDF(Resource Description Framework, 자원 기술 프레임워크)라고 부릅니다. 아래는 사람이 읽기 쉬운 표기법으로 적은 트리플 두 개입니다.

  :김철수  :소속  :영업1팀 .    # 김철수는 영업1팀에 소속된다
 :영업1팀 :속함  :영업본부 .   # 영업1팀은 영업본부에 속한다  

각 줄이 하나의 문장, 즉 하나의 사실입니다. 첫 줄은 사람과 팀의 관계를, 둘째 줄은 팀과 본부의 관계를 담고 있습니다. 눈여겨볼 점은 이 두 문장이 '영업1팀'이라는 공통 요소로 자연스럽게 이어진다는 것입니다. 트리플을 계속 쌓으면 점들이 선으로 이어지는 그물, 곧 그래프가 됩니다. 아직은 우리가 문장을 하나씩 손으로 적고 있을 뿐이지만, 여기까지가 기계가 '글자'를 정확히 적는 단계입니다.

이름표의 힘: IRI·네임스페이스와 어휘 재사용

트리플로 문장을 적을 수 있게 됐습니다. 그런데 여기서 초심자가 자주 막히는 질문이 하나 있습니다. 위 예시의 :김철수는 대체 '어느' 김철수일까요? 세상에는 동명이인이 많고, 시스템마다 같은 대상을 다르게 부릅니다. 이 문제를 풀지 못하면 트리플을 아무리 쌓아도 서로 연결되지 않습니다.

그래서 RDF는 모든 대상에 IRI(Internationalized Resource Identifier)라는 전역 이름표를 붙입니다. 쉽게 말해 웹 주소(URL)처럼 생긴, 전 세계에서 유일한 고유 식별자입니다. http://example.com/emp/1024 같은 형태로 '이 김철수'를 딱 하나로 특정합니다. 매번 긴 주소를 적기 번거로우니 앞부분을 : 같은 약칭(네임스페이스)으로 줄여 쓸 뿐, 속뜻은 전역 이름표입니다.

이 이름표의 진짜 힘은 연결에 있습니다. A시스템의 '고객'과 B시스템의 '거래처'가 사실 같은 대상이라면, 둘에 같은 IRI를 부여하는 순간 두 데이터는 별도 작업 없이 서로 이어집니다. 나아가 이름표를 매번 새로 만들 필요도 없습니다. 사람·조직·상품 같은 흔한 개념은 이미 잘 정리된 공개 어휘가 있습니다. 웹 콘텐츠 표준 어휘인 schema.org, 사람과 인맥을 기술하는 FOAF(Friend of a Friend) 등이 대표적입니다. 남이 잘 만들어 둔 바퀴를 재사용하면 바퀴를 다시 발명할 필요가 없는 것과 같이, 공개 어휘를 잘 사용하면 이름표를 하나씩 만드는 수고를 덜 수 있습니다.

여기까지도 우리는 여전히 '글자'를 다루고 있습니다. 다만 같은 글자를 모두가 같은 것으로 읽도록 약속을 맞추는 단계입니다. 이 약속만으로도 사일로에 흩어져 있던 데이터를 이름표 하나로 이어 붙일 여지가 생깁니다. 서로 다른 시스템의 데이터를 억지 JOIN 없이 잇는 첫 실마리인 셈입니다.

뼈대 세우기: 클래스·인스턴스·속성

이름표로 개별 대상을 정확히 가리킬 수 있게 됐습니다. 이제 그 대상들을 종류별로 묶고 구조를 세울 차례입니다. 여기서 세 가지 개념이 등장합니다.

• 클래스(class): 개념 또는 유형입니다. '고객', '주문', '부서'처럼 개별 대상이 아니라 그 대상들이 속하는 범주입니다.
• 인스턴스(instance): 그 유형에 속하는 실제 개체입니다. 'ID 1024 김철수'는 '고객' 클래스의 인스턴스입니다.
• 속성(property): 대상이 지닌 특징이나 관계입니다.

클래스와 인스턴스의 차이는 사전에 빗대면 쉽습니다. 클래스는 사전의 표제어('고객'이라는 항목)이고, 인스턴스는 실제로 매장에 걸어 들어온 살아있는 사람입니다. 클래스는 개념이고, 인스턴스는 사례입니다.

또한 클래스는 계층을 이룰 수 있습니다. '단골고객'은 '고객'의 하위 클래스(subclass)입니다. 정리하면 '고객'(클래스) 아래 '단골고객'(하위 클래스)이 있고, 그 안에 'ID 1024 김철수'(인스턴스)가 놓이는 식입니다.

속성은 다시 둘로 나뉩니다. 대상과 대상을 잇는 객체 속성(object property)(예: 김철수 —소속→ 영업1팀), 그리고 대상에 값을 붙이는 데이터 속성(datatype property)(예: 김철수 —나이→ 34)입니다. 관계냐 값이냐의 구분입니다.

여기까지가 낱낱의 '글자'를 모아 뜻을 담는 '단어'를 갖추는 단계입니다.

규칙을 새기다: RDFS에서 OWL로

단어를 갖췄으니, 이제 그 단어에 '뜻'을 붙일 차례입니다. 단어만으로는 기계가 여전히 의미를 모르기 때문입니다. 이 뜻을 새기는 언어에는 표현력이 다른 두 층이 있습니다.

첫 번째 층은 RDFS(RDF Schema)입니다. RDFS는 비교적 소박합니다. "이것은 클래스다", "이것은 저것의 하위 클래스다", "이 속성의 주어는 사람 유형이다" 정도의 기본 뼈대를 세웁니다. 유형과 계층을 정의하는 단계라고 보면 됩니다.

두 번째 층은 OWL(Web Ontology Language, 웹 온톨로지 언어)입니다. OWL은 RDFS가 못 하는 정교한 규칙까지 표현합니다. 이 규칙을 온톨로지 세계에서는 공리(axiom)라고 부릅니다. 공리란 "항상 참으로 성립하는 규칙"을 기계가 알아들을 수 있게 명시한 문장입니다. 사람에게는 굳이 말할 필요 없는 '상식'을 기계에게는 하나하나 적어 줘야 하는데, 그 상식을 명시적 규칙으로 새긴 것이 공리입니다.

예를 들어 사람이라면 "부서에 소속됐다면 그 부서의 상위 조직에도 소속된 것"이라는 상식을 압니다. 하지만 기계는 이 상식을 스스로 갖고 있지 않습니다. OWL은 이런 상식을 규칙으로 적어 넣게 해 줍니다. RDFS에서 OWL로 올라가는 것은, 표현할 수 있는 '뜻'의 정교함이 한 계단 높아지는 것입니다. 비유로 말하면, '단어'에 '뜻'이 붙기 시작하는 단계입니다. 그렇다면 그 규칙은 구체적으로 어떤 모습일까요?

속성에 성격을 부여하다: 전이·대칭·역·함수

OWL이 심는 '상식' 중에서도 특히 강력한 것이, 속성 자체에 성격을 부여하는 규칙입니다. 이 성격들이 뒤에 나올 추론 엔진의 연료가 되므로, 규칙을 먼저 말하고 곧바로 사례로 시연해 보겠습니다.

• 전이적(transitive) 속성: A—B, B—C가 성립하면 A—C도 성립합니다. '포함' 관계가 그렇습니다. "서울은 한국에 포함되고, 한국은 아시아에 포함된다"면 규칙에 따라 "서울은 아시아에 포함된다"가 따라 나옵니다.
• 대칭적(symmetric) 속성: A—B가 성립하면 B—A도 성립합니다. "한국은 중국과 국경을 접한다"면 "중국도 한국과 국경을 접한다"가 자동으로 성립합니다.
• 역(inverse) 속성: 방향이 반대인 두 속성을 짝지어 줍니다. '소속'의 역은 '구성원'입니다. "김철수가 영업1팀에 소속됐다"면 "영업1팀은 김철수를 구성원으로 둔다"가 함께 성립합니다.
• 함수적(functional) 속성: 한 대상에 값이 하나뿐임을 뜻합니다. "한 사람의 주민등록번호는 하나"라는 규칙이 그렇습니다.

여기서 핵심은, 이 성격들이 단순한 메모가 아니라 기계가 결론을 끌어내는 근거가 된다는 점입니다. '전이적'이라고 한 번 선언해 두면, 기계는 포함 관계가 나올 때마다 그 규칙을 적용해 새로운 사실을 만들어 냅니다. 비유로 돌아오면, '뜻'에 '상식'이 붙는 단계입니다. 이제 이 연료에 불을 붙일 차례입니다.

절정: 추론 엔진이 '적지 않은 사실'을 알아낸다

지금까지 우리는 이름표를 정하고, 트리플로 사실을 적고, 클래스로 뼈대를 세우고, 속성에 성격을 부여했습니다. 이 모든 조각이 모이는 지점이 바로 추론 엔진(reasoner)입니다. 온톨로지가 '읽기'에서 '이해'로 넘어가는 결정적 순간이 여기입니다.

추론 엔진이 하는 일을 한 문장으로 말하면 이렇습니다. 명시적으로 적혀 있지 않은 사실을, 이미 있는 규칙으로부터 끌어내는 것. 실제로 어떻게 작동하는지 앞에서 만든 조각으로 시연해 보겠습니다. 우리가 가진 것은 다음 세 가지뿐입니다.

• 사실 1: :김철수 :소속 :영업1팀 (김철수는 영업1팀 소속)
• 사실 2: :영업1팀 :하위조직 :영업본부 (영업1팀은 영업본부의 하위 조직)
• 규칙: '소속'은 조직 계층을 따라 전이된다 (전이적 속성)

사람은 이 셋을 보면 곧바로 "그럼 김철수는 영업본부 소속이기도 하다"고 압니다. 추론 엔진도 똑같이 합니다. 전이 규칙을 적용해 우리가 한 번도 입력하지 않은 사실 :김철수 :소속 :영업본부를 스스로 만들어 냅니다. 이렇게 규칙으로부터 논리적으로 따라 나오는 결론을 엔테일먼트(entailment, 논리적 귀결)라고 부릅니다. 데이터에 답이 적혀 있지 않아도, 규칙만 제대로 새겨 두면 기계가 답을 도출한다는 사실입니다.


대개 "데이터가 아주 많이 주고 AI가 알아서 관계를 파악하도록 하면 되지 않느냐"고 생각하는 경우가 많습니다. 그렇지 않습니다. 데이터를 아무리 산더미처럼 쌓아도, "소속은 조직 계층을 따라 전이된다"는 규칙을 명시하지 않으면 기계는 김철수가 영업본부 소속이라는 것을 끝내 알지 못합니다. 이해는 데이터의 양에서 저절로 솟아나지 않습니다. 의미와 규칙을 명시적으로 새겨 넣을 때 비로소 생깁니다. 추론은 데이터를 새로 넣는 작업이 아니라, 이미 있는 규칙에서 결론을 끌어내는 작업이라는 점을 기억해 두시면 됩니다.

한 바퀴 돌려보기: 작은 사례로 전체 스택 살펴보기

부품을 하나씩 봤으니, 이제 이것들이 어떻게 한 몸으로 움직이는지 처음부터 끝까지 이어 보겠습니다. 소규모 유통사의 '고객·주문·부서' 영역을 살펴보겠습니다.

① 빈 상태에서 이름표부터 정합니다. 우리 회사의 대상들에 IRI를 부여합니다. 고객 '이영희'는 :cust1024, 55번째 주문은 :ord55, 부서 '영업1팀'은 :sales1, 그 상위인 '영업본부'는 :salesHQ로 정합니다. 사람이라는 개념은 공개 어휘를 재사용해도 됩니다.

② 트리플로 사실을 적습니다.

  :cust1024 :주문함    :ord55 .    # 이영희가 ord55를 주문했다  :ord55    :담당부서  :sales1 .   # 이 주문의 담당 부서는 영업1팀이다  :sales1   :하위조직  :salesHQ .  # 영업1팀은 영업본부의 하위 조직이다  

③ 클래스와 계층을 세웁니다. :cust1024는 '고객' 클래스의 인스턴스이고, '단골고객'은 '고객'의 하위 클래스라고 선언합니다. :sales1, :salesHQ는 '부서' 클래스에 넣습니다.

④ 속성에 성격을 부여합니다. '담당부서'가 조직 계층을 따라 전이되도록, '하위조직'을 전이적 속성으로 선언합니다.

⑤ 추론 엔진을 돌립니다. 그러면 우리가 적지 않은 사실이 도출됩니다. 담당 부서가 계층을 타고 올라가, :ord55 :담당부서 :salesHQ(55번째 주문의 담당 부서는 영업본부이기도 하다)가 새로 생깁니다.

작은 세계지만, 글자(이름표)에서 시작해 단어(클래스)와 상식(공리·속성 성격)을 거쳐 스스로 알아내기(추론)까지, 한 화면에서 이어지는 것을 눈으로 확인할 수 있습니다. 남은 것은 이렇게 만들어진 그물에 질문을 던지는 일입니다.

질문하는 법: SPARQL과 '열린 세계 가정'

그물을 세웠으니 이제 물어봐야 합니다. 온톨로지·RDF 데이터에 질문을 던지는 표준 질의어는 SPARQL(스파클)입니다. RDB에 SQL이 있다면, 그래프에는 SPARQL이 있는 셈입니다. SPARQL의 매력은 관계를 그대로 물을 수 있다는 데 있습니다. 앞서 만든 세계에 "영업본부 소속인 주문을 모두 찾아라"라고 물어보겠습니다.

  SELECT ?주문 WHERE {    ?주문 :담당부서 :salesHQ .   # 담당 부서가 영업본부인 주문을 찾아라  }  

이 SPARQL에 의해 :ord55 :담당부서 :salesHQ라는 결과가 나타납니다. "55번째 주문의 담당 부서는 영업본부이기도 하다"라는 사실은 추론 엔진이 전이 규칙으로 도출한 것이고, 우리가 직접 입력한 적이 없습니다. 그런데도 이 질의는 :ord55를 결과로 잡아냅니다. 사람이 미리 연결을 지정해야 했던 JOIN과의 차이가 여기서 드러납니다.

온톨로지를 깊게 살펴보려는 분이라면 한 걸음 더 짚어야 할 개념이 하나 있습니다. 바로 열린 세계 가정(OWA, Open World Assumption)입니다. RDB는 닫힌 세계 가정(CWA, Closed World Assumption)을 따르는데, 이는 "데이터에 없으면 거짓"으로 간주하는 것입니다. 어떤 고객의 전화번호가 테이블에 없으면, 그 고객은 전화번호가 '없는' 것으로 처리됩니다. 반면 온톨로지는 열린 세계를 가정합니다. "적혀 있지 않다고 해서 거짓인 것은 아니다"라고 봅니다. 전화번호가 없으면 '전화번호가 없다'가 아니라 '아직 모른다'로 취급합니다.

쉽게 말해 OWA는 모르는 것과 없는 것을 구별합니다. 이것이 왜 좋을까요? 현실의 데이터는 언제나 불완전하기 때문입니다. 세상의 모든 사실이 우리 데이터베이스에 다 들어와 있을 리 없습니다. "적히지 않았으니 없다"고 단정하는 시스템은 불완전한 데이터를 다룰 때 위험한 결론을 내립니다. 반면 "아직 모른다"고 정직하게 인정하는 전제는, 계속 새 사실이 들어오는 AI 환경에 훨씬 잘 맞습니다. OWA는 기계에게 더 정직한 출발점을 줍니다.

온톨로지는 어떻게 만들어지는가 — 탑다운·바텀업

지금까지 메커니즘을 살펴봤으니 이제 현실적인 질문이 남습니다. 이 온톨로지는 대체 누가, 어떻게 만들까요? 접근법은 크게 둘로 나뉩니다.

• 탑다운(top-down): 도메인 전문가가 상위 개념부터 논리적으로 설계해 내려오는 방식입니다. 체계가 깔끔하지만, 초기 설계에 시간이 많이 들고 현실 데이터와 어긋날 위험이 있습니다.
• 바텀업(bottom-up): 이미 쌓인 데이터에서 패턴을 귀납해 개념을 끌어올리는 방식입니다. 현실에 밀착하지만, 자칫 지저분하고 일관성이 떨어질 수 있습니다.

실무에서는 둘을 섞습니다. 앞서 이야기한 것처럼 공개 어휘를 재사용하면 처음부터 모든 것을 만들 필요도 없습니다. 완벽한 상위 온톨로지를 처음부터 그리려는 쪽보다 좁은 도메인 하나부터 작게 시작한 쪽이 오래 살아남는 경우가 많습니다. 온톨로지는 한 번 만들고 끝나는 조형물이 아니라, 도메인과 함께 자라는 유기체에 가깝기 때문입니다.

그래서 정말 '이해'하는가 — 한계와 오해

지금까지 온톨로지의 장점을 이야기했으니, 이제 균형을 맞출 차례입니다. 온톨로지는 모든 문제를 푸는 만능열쇠가 아닙니다. 냉정하게 한계를 짚어 두겠습니다.

가장 먼저, 구축과 유지보수 비용이 만만치 않습니다. 의미와 규칙을 하나하나 명시하는 작업은 곧 사람의 노력입니다. 도메인은 끊임없이 변하므로 온톨로지도 계속 손봐야 하고, 어떤 온톨로지도 도메인을 완결적으로 담아내지는 못합니다. 둘째, 온톨로지는 LLM의 대체재가 아니라 보완재입니다. 자연어의 유연함과 방대한 패턴은 LLM이 앞서고, 명시적 규칙과 검증 가능한 관계는 온톨로지가 앞섭니다. 어느 하나로 다른 하나를 대체하려는 접근은 대개 실망으로 끝납니다.

무엇보다 추론 엔진은 마법이 아닙니다. 새겨 넣은 규칙 이상을 알지 못합니다. '전이적'이라고 선언하지 않은 관계는 아무리 데이터를 쌓아도 전이되지 않습니다. 즉 온톨로지가 만들어 내는 '이해'는 결국 사람이 미리 심어 둔 의미와 규칙의 그림자입니다. 이것은 온톨로지의 약점이자, 동시에 그것을 신뢰할 수 있는 이유이기도 합니다. 결과가 규칙으로 설명되므로, 왜 그런 결론이 나왔는지 되짚을 수 있기 때문입니다.

정돈에서 의미로: 'AI Ready Data'와의 접점

한 가지 렌즈를 마지막으로 얹어 보겠습니다. 지금까지 본 트리플·클래스·공리·추론은 결국 데이터에 '의미'를 부여하는 일이었습니다. 그런데 이 의미는 허공에 세울 수 없습니다. 이름표가 제각각이고, 표준이 없고, 품질이 들쭉날쭉한 데이터 위에 아무리 정교한 온톨로지를 얹어도 사상누각이 됩니다. 의미를 부여하기 전에, 데이터가 먼저 정돈돼 있어야 합니다. 메타데이터 관리, 데이터 표준, 데이터 품질, 흐름(리니지) 관리 같은 데이터 거버넌스가 그 토대입니다.

이 두 층이 만나서 만들어지는 것이 바로 엔코아가 제시하는 AI Ready Data입니다. AI가 곧바로 활용할 수 있도록 의미와 맥락이 정돈된 데이터라는 뜻입니다. 거버넌스로 데이터를 정돈하고, 그 위에 온톨로지로 의미를 얹으면, AI가 관계를 따라가며 스스로 이해하고 일할 수 있는 상태가 됩니다. 이렇게 데이터 사이의 관계와 맥락을 데이터 맥락 지도로 만들어, AI에게 "이 데이터가 무엇이고 서로 어떻게 얽히는지"를 알려줄 수 있습니다. 오늘 우리가 뜯어본 온톨로지의 개념은 바로 이 지도를 그리는 연장이었던 것입니다.

읽는 기계에서 이해하는 기계로

처음의 질문으로 돌아가 보겠습니다. "이 고객과 저 주문은 어떤 관계인가요?"에 침묵하던 시스템 말입니다. 이 글을 관통한 답은 분명합니다. 기계는 스스로 이해하지 않습니다. 우리가 의미와 규칙을 명시적으로 새겨 넣을 때 비로소 이해가 생깁니다. 온톨로지가 데이터를 '읽기'에서 '이해'로 끌어올리는 방식은, 어떠한 마법이 아니라 이름표 → 트리플 → 클래스·공리 → 속성 성격 → 추론 → 질의로 이어지는 한 줄의 설계였습니다. 이 부품들은 따로 노는 것이 아니라 하나의 사슬로 맞물려 우리가 적지 않은 사실까지 끌어냅니다.

물론 그 대가는 있습니다. 의미를 새기는 데는 사람의 손과 시간이 듭니다. 추론 엔진도 우리가 심은 규칙 이상은 알지 못합니다. 그럼에도 이 명시성은 곧 신뢰성입니다. 결론이 규칙으로 설명되기에, 우리는 왜 그런 답이 나왔는지 되짚을 수 있습니다.

그래서 마지막으로 드리고 싶은 제안은 이것입니다. 지금 다루는 데이터가 '읽히기만' 하는지, 아니면 '이해까지' 되는지 한번 살펴보시기 바랍니다. 값은 잘 조회되는데 정작 관계와 의미를 물었을 때 막힌다면, 병목은 데이터의 양이나 품질이 아니라 의미에 있는 것입니다. 그때 읽는 기계를 이해하는 기계로 바꾸는 첫걸음으로써 온톨로지가 답이 될 수 있습니다.