온톨로지 다시 보기: 시맨틱 웹의 좌절에서 AI 에이전트의 업무 지도까지

온톨로지란 무엇인가: 개념·속성·관계·규칙

이 글은 '온톨로지의 허와 실' 시리즈의 1편(원리편)이다. 요즘 AI 에이전트(AI Agent) 이야기에 온톨로지(Ontology)가 다시 자주 나온다. 그런데 정작 온톨로지가 무엇인지, 왜 한 번 잊혔다가 돌아왔는지는 잘 설명되지 않는다. 이번 편은 그 원리를 정리한다.

W3C의 OWL 2 개요 문서글는 온톨로지를 '특정 분야를 다루면서 사용자 공동체가 함께 쓰는, 형식을 갖춘 용어 모음'이라고 정의한다. 용어의 뜻은 온톨로지 안의 다른 용어와 맺는 관계로 정해진다. OWL 2 온톨로지는 클래스(개념), 속성, 개체(실제 대상), 데이터 값으로 이뤄진다. 쉽게 풀면 '고객', '계약', '운전기사' 같은 개념(클래스)이 있고, 개념마다 '가입일', '면허 종류' 같은 속성이 붙는다. 그리고 '운전기사는 차량을 운행한다' 같은 관계가 개념들을 잇는다. 여기에 '이런 조건이면 저런 결론이 따른다'는 규칙이 더해진다.

규칙이 왜 중요한지는 Thoughtworks 글글의 예가 잘 보여 준다. 언어 모델은 문서를 읽고 '운전기사가 차량을 운행한다'는 것까지는 짐작할 수 있다. 하지만 이 회사에서는 특정 통관 자격이 없는 운전기사를 국제 노선에 배정할 수 없다는 규칙은 알 길이 없다. 그런 규칙은 사람들 머릿속과 정책 문서, 부서의 관행에 흩어져 있을 뿐, 기계가 따져 볼 수 있는 곳에는 없다. 온톨로지는 바로 이 '업무의 뜻과 규칙'을 기계가 읽을 수 있는 형태로 옮겨 적는 일이다.

스키마·분류 체계·시맨틱 레이어·지식 그래프와 무엇이 다른가

온톨로지는 비슷해 보이는 여러 도구와 자주 헷갈린다. Thoughtworks 글글은 스키마, 통제 어휘(분류 체계), 시맨틱 레이어, 온톨로지, 지식 그래프를 하나의 연속선 위에 놓는다. 한쪽 끝은 '데이터를 어떻게 저장하나', 가운데는 '그 데이터가 무슨 뜻인가', 반대쪽 끝은 '기계가 무엇을 추론하고 행동할 수 있나'다. 한 단계 올라갈수록 표현력은 커진다. 대신 비용과 관리 부담이 늘고, 책임지고 돌볼 사람도 더 필요해진다.

각각을 짧게 정리하면 이렇다. 데이터베이스 스키마는 표·열·키로 데이터를 어떻게 담을지 정한다. 분류 체계는 쓸 용어를 정해 두고 상하위로 묶는다. 시맨틱 레이어(Semantic Layer)는 '매출', '활성 고객' 같은 지표와 용어의 정의를 회사 전체에서 통일한다. 같은 글에 따르면 시맨틱 레이어는 현업에서 가장 넓게 쓰이는 층일 수 있다. 하지만 정의를 표준화할 뿐 에이전트가 따라갈 관계와 논리는 담지 않으므로, 표현력 축에서는 아래에 놓인다.

가장 헷갈리는 것은 온톨로지와 지식 그래프(Knowledge graph)다. 같은 글글의 구분이 명쾌하다. 온톨로지는 설계도(클래스·관계·규칙)이고, 지식 그래프는 그 설계도에 실제 데이터를 채운 것이다. 에이전트가 실제로 질의하는 대상도 지식 그래프다. LLM·지식 그래프 로드맵 논문논문은 지식 그래프가 (주어 개체, 관계, 대상 개체) 꼴의 트리플로 사실을 저장한다고 정리한다. 아래 표는 다섯 가지 도구가 무엇을 담는지 비교한 것이다.

시맨틱 웹은 왜 기업 현장에 널리 퍼지지 못했나

온톨로지가 처음 주목받은 무대는 시맨틱 웹이었다. 웹의 내용을 기계가 더 잘 다룰 수 있게 만드는 것이 목표였다글. 표준은 실제로 남았다. RDF는 모든 정보를 '주어-술어-목적어'의 세 요소로 된 트리플로 적는다. 같은 대상이 여러 트리플에 등장하면서 정보가 그래프로 이어지고, 이 그래프는 SPARQL이라는 질의어로 묻는다글. RDF 입문서글는 schema.org 어휘로 웹 페이지에 기계가 읽을 정보를 붙이거나, 데이터를 Wikidata에 연결하는 쓰임을 예로 든다. OWL은 2004년 첫 판이 나왔고, 2012년에는 OWL 2가 W3C 권고안이 됐다글.

그런데 기업 안으로 들어오면 이야기가 달라진다. 첫째, 배울 것이 많다. OWL 2 문서글만 봐도 교환용 필수 문법인 RDF/XML 외에 Turtle, OWL/XML, Manchester 같은 여러 표기법이 있다. 의미는 SROIQ라는 기술 논리(1차 논리의 일부)에 기대어 정의된다. 추론기는 클래스끼리 모순이 없는지, 한 클래스가 다른 클래스에 포함되는지를 따져 주는 강력한 장치다. 하지만 이를 다루려면 전용 도구와 질의어, 논리 지식을 갖춘 사람이 있어야 한다. Thoughtworks 글글은 이를 '번역 간극'이라 부른다. 온톨로지 엔지니어는 형식 체계는 알지만 업무를 모르고, 현업 전문가는 업무는 알지만 형식 모델링을 모른다. 둘 사이를 인터뷰로 오가며 지식을 옮기면 느리고 손실이 크다.

둘째 함정은 전사 단일 모델이다. 같은 글글은 온톨로지가 현실을 묘사하기 때문에, 무엇이든 내놓기 전에 전부를 모델링하고 싶은 유혹이 생긴다고 지적한다. 그런 프로젝트는 1년쯤 지나 흐지부지되기 쉽다. 이 글은 전사 마스터 모델을 '바다를 끓이려는' 함정에 깔끔한 이름을 붙인 것일 뿐이라고 표현한다.

셋째이자 가장 과소평가되는 문제는 유지 관리다. 규정이 바뀌고, 조직이 개편되고, 제품이 달라지는 속도를 손으로 고치는 모델은 따라가지 못한다. 구축은 한 번으로 끝나지만 현실과 맞추는 일은 끝이 없다. 그런데 기존 방식에서는 프로젝트가 끝나면 주인도 사라진다. 글글은 책임자와 정기 점검이 없으면 모델이 두 분기 안에 낡는다고 말하며, 이를 '기술의 옷을 입은 거버넌스 문제'라고 부른다. 대안으로는 온톨로지를 프로젝트가 아닌 제품으로 다루라고 권한다. 기존 방식은 가치를 내기까지 12~24개월이 걸리지만, 제품 방식은 반복마다 4~8주를 잡는다. 정리하면 표준이 부족했던 것이 아니다. 배울 것이 많고, 범위가 넘치고, 돌볼 조직이 없어서 현장에 뿌리내리기 어려웠다.

왜 다시 뜨나: LLM과 에이전트에게 업무 지도가 필요하다

분위기를 바꾼 것은 LLM(대규모 언어 모델)이다. LLM·지식 그래프 로드맵논문은 LLM의 약점을 이렇게 꼽는다. 지식이 파라미터 속에 암묵적으로 들어 있고, 환각(Hallucination)을 일으키고, 확률에 기대 결정하며, 블랙박스이고, 특정 분야나 새 지식이 부족하다. 반대로 지식 그래프는 구조화돼 있고, 정확하고, 해석할 수 있고, 분야 지식을 담기 좋다. 다만 만들기 어렵고 늘 불완전하다. 이 로드맵은 둘을 엮는 길을 세 갈래로 정리했다. 지식 그래프로 LLM을 보강하는 길, LLM으로 지식 그래프 작업(구축 포함)을 돕는 길, 둘이 서로를 돕는 길이다.

이 약점은 에이전트가 업무 시스템을 건드리고 회사를 대신해 행동하는 지금 더 크게 드러난다. Thoughtworks 글글은 에이전트가 문서는 읽어도 회사의 운영 논리는 갖고 있지 않아서 결국 벽에 부딪힌다고 말한다. 온톨로지 근거 RAG(검색 증강 생성)인 OG-RAG논문는 이 간극을 검색 단계에서 메운다. 일반 RAG는 분야와 무관한 임베딩으로 비슷한 문장 조각을 찾는다. OG-RAG는 먼저 문서를 분야 온톨로지에 맞춰 하이퍼그래프로 정리한다. 하이퍼엣지는 관련된 사실 여러 개를 한 번에 묶는 연결이다. 그다음 질문에 답하는 데 필요한 최소한의 묶음만 골라 LLM에게 건넨다. 농업·뉴스 분야 평가에서 이 방식은 네 가지 LLM에 걸쳐 정확한 사실의 재현율을 55%, 답의 정확성을 40% 높였다. 사용자 연구에서는 답을 근거에 연결하는 시간이 30% 줄었고, 미리 정한 규칙을 적용하는 추론 과제에서는 정확도가 27% 높았다.

에이전트의 행동을 제약하는 쪽으로는 엔터프라이즈 에이전트 연구논문가 있다. 이 연구는 역할·분야·상호작용의 세 층 온톨로지로 에이전트를 묶는다. 저자들은 지금의 기업 시스템이 입력 쪽(컨텍스트 조립, 도구 찾기, 거버넌스 기준)만 온톨로지로 제약하고 출력은 검사하지 않는 '비대칭'을 지적한다. 그래서 답변·추론·규정 준수를 출력 쪽에서도 검증하는 틀을 제안했다. 다섯 산업과 세 LLM으로 1,800회 실행한 실험에서, 온톨로지와 결합한 에이전트는 지표 정확도와 역할 일관성에서 유의미하게 앞섰다. 효과는 LLM이 학습 데이터로 잘 모르는 분야에서 가장 컸다. 베트남 현지화 분야에서는 향상 폭이 영어 분야의 2배였다.

다만 온톨로지가 곧 가드레일(Guardrail)은 아니다. Thoughtworks 글글은 온톨로지가 에이전트에게 '무엇이 허용되는지'를 알려 주지만, 그것은 지식일 뿐 강제가 아니라고 선을 긋는다. 규칙은 결정적으로 동작하는 실행기가 실제로 확인하고 그 결과를 따를 때, 그리고 확인했다는 사실을 보여 줄 수 있을 때 효력이 생긴다. 많은 운영 규칙은 형식 공리보다 정책 엔진에 두는 편이 맞다고도 했다. 또 검색 품질은 설계도가 아니라 실제 데이터로 채운 그래프에서 나온다. 따라서 Entity Resolution(같은 대상 찾아 합치기)과 관계 추출을 얼마나 잘하느냐가 품질의 상한을 정한다.

LLM이 구축 비용을 줄여 줄까

시맨틱 웹 시절 가장 큰 비용은 사람이 일일이 개념을 뽑고 관계를 적는 일이었다. 이제는 이 초안 작업을 LLM에게 맡기는 흐름이 뚜렷하다. OntoEKG논문는 작업을 두 단계로 나눈 파이프라인이다. 먼저 기업의 비정형 문서에서 핵심 클래스와 속성을 뽑고, 다음으로 이를 논리적인 상하위 계층으로 세운 뒤 표준 RDF로 내보낸다. 데이터·금융·물류 분야 문서로 만든 평가 세트에서, 데이터 분야 기준 퍼지 매칭 F1 0.724를 얻었다. 동시에 저자들은 범위를 어디까지 잡을지 정하는 일과 계층 추론에서 한계가 드러났다고 밝혔다.

그래서 현실적인 그림은 'LLM이 쓰고 사람이 고른다'다. Thoughtworks 글글은 기존 스키마, API 정의, 위키에서 LLM 파이프라인으로 분류 초안을 뽑으라고 권한다. 그러면 전문가의 일은 정의를 쓰는 것에서 초안을 검토하고 다듬는 것으로 바뀐다. 하지만 같은 글은 이것이 구축만 빠르게 할 뿐 유지 관리에는 아무 도움이 되지 않는다고 못 박는다. 앞에서 본 세 번째 실패 이유는 LLM이 와도 그대로 남는다는 뜻이다.

설비 정비 기록을 다룬 Plant Memory논문는 사람의 검토를 설계 한가운데 둔 예다. 이 시스템은 SAP 정비 작업 지시서에서 규칙 기반으로 먼저 사실을 뽑고, LLM은 선택적인 '두 번째 독자'로만 쓴다. LLM이 규칙 추출과 다르게 읽으면 결과를 덮어쓰지 않고, 그 사실의 검토 우선순위만 올린다. 모든 사실에는 신뢰도, 근거가 된 원문, 검증 상태가 붙는다. 기술자는 검토 대기열에서 사실을 확인하고, 새 용어가 나타나면 온톨로지 변경 제안을 승인하거나 거절한다. 이렇게 검증한 그래프는 사람에게는 웹 앱으로, AI 에이전트에게는 MCP(모델 컨텍스트 프로토콜) 서버로 제공된다. 다만 평가에 쓴 데이터는 작업 지시서 400건을 합성한 것이므로, 결과를 실제 공장에서의 성능으로 읽어서는 안 된다.

요즘 어디로 가고 있나: 근거를 보이는 답, 검사기를 의심하는 연구

최근 연구는 두 방향으로 읽힌다. 하나는 온톨로지를 근거로 삼아 답이 '어디까지 확실한지'를 함께 보여 주는 방향이다. OA-RAG논문는 형식 추론과 LLM 추론을 섞는 에이전트로, 온톨로지의 논리 구조와 사람이 붙인 설명을 함께 쓴다. 답마다 근거로 쓴 온톨로지 관찰과 근거 수준(함의됨·뒷받침됨·관련됨·무관함)을 보고하는 것이 특징이다. 대규모 온톨로지 세 개로 만든 벤치마크와 여섯 가지 의료 질의응답 과제에서, 비교한 방법 가운데 전체 성능이 가장 좋았다. 근거 수준이 강할수록 대체로 정확도도 높았다. 다만 이는 벤치마크 결과이며 실제 진료 성능을 뜻하지 않는다. 의료처럼 결과가 사람에게 직접 영향을 주는 분야에서는 최종 판단을 사람이 해야 한다.

다른 하나는 온톨로지 자체를 의심하는 방향이다. 지식 그래프 위에서 답하는 에이전트를 온톨로지 기반 검사기로 감싸는 사례가 늘고 있다. 검사기 연구논문는 그 밑에 깔린 '형식 스키마는 믿을 만한 심판'이라는 가정을 직접 시험했다. 연구진은 세 종류의 온톨로지를 비교했다. 사람이 다듬은 큐레이션 온톨로지, LLM이 만든 온톨로지, 데이터에서 뽑은 스키마다. 각각을 프롬프트 맥락으로, 검사기로, 또는 둘 다로 썼다. 그리고 공개 그래프와 10억 개 가까운 트리플을 가진 비공개 그래프에서, 검사기가 무엇을 잡고 무엇을 잘못 지적하는지 셌다. 결과는 꽤 냉정하다. 공개된 그대로 쓴 큐레이션 스키마가 자기 데이터와 모순되는 경우가 있었다. UniProt에서는 큐레이션 온톨로지가 다른 두 방식보다 맞는 답을 틀렸다고 더 많이 지적했다. 실제 에이전트 답변에서 그 지적의 정확도는 무작위로 지적할 때보다 아주 조금 나은 수준이었다.

두 흐름을 겹쳐 보면 메시지가 분명하다. 온톨로지는 에이전트의 답과 행동에 근거를 붙이는 데 쓸모가 있다. 하지만 효과는 그 온톨로지가 현재 데이터와 맞게 관리되고 있는지에 달려 있다. 비싸게 큐레이션했다는 사실만으로 좋은 심판이 되지는 않는다.

허와 실의 첫 판단 기준: 온톨로지가 필요한 문제인가

Thoughtworks 글글은 첫 결정이 '포부'가 아니라 '진단'이어야 한다고 말한다. 물어야 할 것은 '온톨로지를 갖고 싶은가'가 아니라 '눈앞의 문제를 푸는 최소한의 의미 구조는 무엇인가'다. 같은 글은 대부분의 조직이 실제 필요보다 높은 층까지 올라가려 한다고 본다. 잘 관리된 시맨틱 레이어와 규율 있는 메타데이터만으로도 분석과 검색에서 얻을 가치의 상당 부분을 얻는다는 것이다. 온톨로지가 비용만큼 값을 하는 곳은 더 좁다. 여러 단계를 건너 추론해야 하는 질문, 제약 조건의 자동 검사, 평평한 모델로는 표현할 수 없는 여러 분야의 통합이다.

판단에 쓸 질문을 다섯 가지로 정리할 수 있다. 첫째, 지금 시스템이 답하지 못하는 구체적인 질문(역량 질문)을 현업이 적어 낼 수 있는가. 같은 글은 이 질문 목록을 예산을 주는 관문으로 삼고, 질문마다 의사결정이나 금액을 연결하라고 권한다. 현업이 질문을 내놓지 못한다면 의미 구조가 없는 것이 아니라 가치가 불분명한 것이다. 둘째, 답을 얻으려면 여러 개념을 건너는 관계를 따라가야 하는가, 아니면 '매출'의 정의만 맞추면 되는가. 후자라면 시맨틱 레이어나 잘 정리된 표로 충분하다. 셋째, 위반하면 안 되는 규칙을 기계가 확인해야 하는가. 그렇다면 그 확인을 실제로 수행할 실행기나 정책 엔진까지 함께 설계해야 한다. 넷째, LLM이 그 분야를 잘 모르는가. 엔터프라이즈 에이전트 연구논문의 결과처럼, 사내 고유 용어나 현지화된 분야일수록 온톨로지의 효과가 커질 수 있다. 다섯째, 용어가 바뀔 때 누가 결정하는지, 원천 시스템과 얼마나 자주 맞출지 정해 둔 담당자가 있는가글.

흔한 실수도 짚어 둔다. 회사 전체를 한 번에 모델링하려는 것, LLM이 초안을 만들었으니 유지 관리도 해결됐다고 믿는 것, 온톨로지를 넣었으니 가드레일이 생겼다고 여기는 것, 큐레이션 온톨로지의 검사 결과를 그대로 믿는 것이다. 마지막 실수는 검사기 연구논문가 경고했듯 에이전트가 맞는 답을 '고치게' 만드는 역효과를 낼 수 있다.

더 공부하려면, 그리고 2편으로

처음이라면 Thoughtworks 글글부터 읽기를 권한다. 스키마에서 지식 그래프까지 이어지는 연속선, 온톨로지 프로그램이 실패하는 이유, 온톨로지를 제품처럼 다루는 법이 한 글에 모여 있다. 표준이 궁금하면 RDF 입문서글의 트리플 예제와 OWL 2 개요글의 구조 설명을 차례로 보면 된다. 연구 쪽은 다음 순서를 권한다. 먼저 LLM·지식 그래프 로드맵논문으로 큰 지도를 잡는다. 이어서 OG-RAG논문와 엔터프라이즈 에이전트 연구논문로 검색과 행동 제약을 실제로 어떻게 설계하는지 본다. 마지막으로 검사기 연구논문로 균형을 잡는다.

이번 편의 결론은 이렇다. 온톨로지는 '틀'로서 여전히 쓸모가 있지만, 그 가치는 실제 데이터로 채우고 계속 맞춰 가는 운영에서 나온다. 그렇다면 다음 질문이 남는다. 온톨로지를 정적인 지식 지도에 머물게 하지 않고, 데이터 위에서 승인·배정·주문 변경 같은 실제 업무 행동을 실행하는 운영 계층으로 만들면 무엇이 달라질까? 그때 유지 관리와 책임 문제는 풀릴까, 아니면 더 무거워질까? 2편에서는 팔란티어가 온톨로지를 '데이터 위에 행동을 얹는 운영 계층'으로 바꾼 방식을 이 질문들로 살펴본다.