AI에게 '관계'를 가르치는 법, 온톨로지 이야기

지식그래프와 그래프RAG(GraphRAG)가 다시 화두로 떠올랐습니다. LLM의 환각을 잡고 검색 정확도를 끌어올릴 방법으로 여러 기업이 지식그래프에 눈을 돌리면서, 그 밑바탕에 있는 오래된 개념 하나가 함께 소환됐습니다. 바로 온톨로지(Ontology)입니다. 한동안 시맨틱웹 시절의 유물처럼 여겨지던 개념인데, 왜 하필 LLM 시대에 다시 추론의 열쇠로 불려 나온 걸까요.

이유를 짚기 전에 한 장면을 떠올려 보겠습니다. LLM 기반 챗봇에게 "A팀이 이번 규정 개정의 적용 대상인가"를 물었더니, 문장은 그럴듯한데 관계를 잘못 이어 엉뚱한 답을 내놓습니다. A팀이 어느 본부 소속이고, 그 본부가 어떤 규정 체계 아래 있는지를 '따져' 봐야 하는데, 모델은 그 연결을 건너뛴 것입니다. AI는 아는 것이 이렇게나 많은데, 왜 '따져 보는' 데는 약할까요. 이 글에서는 온톨로지가 무엇인지부터 시작해, 그것이 데이터의 가시성과 활용성을 어떻게 높이는지, 그리고 그 힘이 AI의 추론과 어떻게 맞닿는지를 하나씩 살펴보겠습니다. 이야기를 이끌어가기 위해 '가계도'를 예시로 세워 두겠습니다. 이름을 늘어놓은 명단과, 관계가 그려진 가계도의 차이. 그 차이가 오늘 이야기의 전부라고 해도 좋습니다.

온톨로지란 무엇인가

온톨로지라는 말은 원래 철학에서 왔습니다. '존재론', 즉 세상에 무엇이 존재하며 그것들이 어떤 범주로 나뉘는지를 다루는 분야입니다. 정보과학은 이 말을 빌려 와 조금 실용적인 뜻으로 바꿔 씁니다. 온톨로지란, 어떤 영역의 개념들과 그 사이의 관계·규칙을 컴퓨터가 이해할 수 있게 명시한 지식 체계입니다. 쉽게 말해, 사람이 머릿속에서 당연하게 알고 있는 "이건 이런 것이고, 저것과는 이렇게 연결된다"를 기계가 읽을 수 있는 형태로 적어 둔 것입니다.

온톨로지는 대체로 다섯 가지 요소로 이뤄집니다.

• 클래스(class): 개념의 틀입니다. '직원', '부서', '규정' 같은 범주가 여기 해당합니다.
• 인스턴스(instance): 그 틀에 들어가는 실제 개체입니다. '김대리', '인사팀'처럼 구체적인 대상입니다.
• 속성(attribute): 개체가 지닌 특성입니다. 직원의 입사일, 부서의 코드 같은 값입니다.
• 관계(relation): 개념과 개념을 잇는 연결입니다. '소속된다', '적용받는다', '보고한다' 같은 것들입니다.
• 규칙(공리, axiom): 항상 참으로 두는 전제입니다. "부서에 소속된 직원은 그 부서가 따르는 규정을 함께 따른다" 같은 문장이 규칙입니다.

여기서 온톨로지를 흔히 헷갈리는 개념인 분류체계(taxonomy)와 구분해 두는 것이 좋겠습니다. 분류체계는 계층만 다룹니다. 상위-하위로 갈래를 나눈 폴더 트리를 떠올리면 됩니다. 반면 온톨로지는 계층에 더해 관계와 규칙까지 담습니다. 폴더 트리가 "무엇이 무엇 아래에 있는가"만 말한다면, 온톨로지는 "누가 누구의 어떤 관계이며, 그래서 무엇이 성립하는가"까지 말합니다. 이 차이를 앞으로의 비유로 옮기면 이렇습니다. 분류체계가 폴더 트리라면, 온톨로지는 가계도입니다. 가계도에는 이름만 있는 게 아니라 부모-자식, 형제, 혼인 같은 관계선이 그어져 있고, "형제의 자녀는 조카"라는 규칙이 함께 살아 있습니다.

데이터베이스·태그와 무엇이 다른가

그렇다면 이미 데이터를 잘 저장하고 있는 데이터베이스가 있는데, 온톨로지가 왜 또 필요하냐는 질문이 자연스럽게 나옵니다. 답의 실마리는 '저장'과 '의미 명시'가 서로 다른 일이라는 데 있습니다. 데이터베이스의 테이블과 스키마는 데이터를 담는 그릇입니다. 온톨로지는 그 데이터가 무슨 뜻이고 서로 어떻게 이어지는지를 밖으로 드러내는 층입니다. 한쪽은 그릇이고, 다른 쪽은 그 위에 겹쳐 놓는 의미의 지도인 셈입니다.

관계형 데이터베이스에도 물론 관계가 있습니다. 다만 그 관계는 대체로 조인 키(join key) 안에 암묵적으로 숨어 있습니다. 예를 들어 '고객이 상품을 주문한다'는 사실을 생각해 보겠습니다. 관계형 DB에서 이 사실은 주문 테이블에 놓인 고객 외래키와 상품 외래키로만 존재합니다. '주문한다'는 행위 자체는 어디에도 이름으로 적혀 있지 않습니다. 그 의미는 테이블 구조를 아는 사람의 머릿속에, 혹은 쿼리를 짜는 개발자의 관행 속에 있습니다.

온톨로지는 숨겨져 있는 이 관계를 가장 잘 보이는 곳으로 끌어올립니다. '주문한다'라는 관계를 그 자체로 하나의 대상으로 명시하고, 어떤 클래스와 어떤 클래스를 잇는지, 어떤 규칙이 따라붙는지를 함께 적어 둡니다. 태그 방식과도 다릅니다. 태그는 개체에 꼬리표를 다는 데 그치지만, 온톨로지는 꼬리표들 사이의 연결까지 정의합니다. 관계가 숨어 있느냐, 드러나 있느냐. 이 작은 차이가 큰 차이를 만듭니다. 관계가 밖으로 나와 있어야 사람도 기계도 그 관계를 따라가며 '따져 볼' 수 있기 때문입니다.

온톨로지가 데이터 '가시성'을 높이는 방식

많은 조직이 겪는 오래된 골칫거리가 있습니다. 같은 대상을 시스템마다 다르게 부르는 문제입니다. A시스템은 '고객'이라 부르고, B시스템은 같은 사람을 '거래처'라 부릅니다. 어느 쪽도 틀리지 않았지만, 두 데이터를 나란히 놓으면 이것이 같은 대상인지 기계는 알 방법이 없습니다. 이름이 다르니 그저 남남입니다. 데이터는 분명히 있는데, 서로가 서로를 못 보는 상태. 이것이 사일로(silo)입니다.

온톨로지는 여기에 공통의 어휘와 의미를 제공합니다. '고객'과 '거래처'가 실은 동일한 개념을 가리킨다고 명시하고, 각 시스템의 표현을 그 공통 개념에 연결해 둡니다. 그러면 흩어져 있던 데이터가 하나의 지도 위에 올라옵니다. 서로 다른 이름으로 흩어져 있던 조각들이, 같은 대상을 가리키는 하나의 점으로 모이는 것입니다. 일반적인 데이터 표준화가 이름의 형식을 맞추는 일이라면, 온톨로지가 하는 일은 그보다 한 겹 위에서 '이 이름과 저 이름이 같은 뜻'이라는 의미의 정합을 잡아 주는 일에 가깝습니다.

여기서 왜 이것이 중요한지가 드러납니다. 데이터가 '보이게' 되면 세 가지가 달라집니다. 먼저 필요한 데이터를 찾을 수 있습니다. 이름이 달라도 같은 개념으로 묶여 있으니 검색이 개념 단위로 됩니다. 다음으로 신뢰할 수 있습니다. 이 데이터가 무엇을 뜻하는지, 어디서 왔는지가 의미 위에서 분명해집니다. 마지막으로 재사용할 수 있습니다. 한 부서가 정의한 개념을 다른 부서가 그대로 가져다 쓸 수 있습니다. 데이터를 더 쌓는 것보다, 이미 쌓인 데이터를 서로 보이게 만드는 일이 먼저인 경우가 실제 현장에는 훨씬 많습니다. 온톨로지는 바로 그 '보이게 만들기'를 맡습니다.

'활용성'을 높이는 방식: 추론으로 숨은 사실을 꺼낸다

가시성이 데이터를 보이게 하는 일이라면, 활용성은 그 데이터로 무엇을 할 수 있느냐의 문제입니다. 온톨로지의 진짜 힘은 여기서 나옵니다. 바로 저장돼 있지 않은 사실을 계산해 내는 능력, 추론(inference)입니다.

우선 관계 기반 질의와 추론을 구분해 두겠습니다. 관계 기반 질의는 이미 그려진 관계선을 따라가며 답을 찾는 일입니다. "김대리가 속한 부서는?"처럼, 존재하는 연결을 그래프에서 탐색하는 것입니다. 추론은 여기서 한 걸음 더 나아갑니다. 명시적으로 적어 두지 않은 사실을, 규칙을 적용해 새로 도출합니다.

점층적으로 예를 들어 보겠습니다. 온톨로지에 이런 정보가 있다고 하겠습니다. 'A팀은 개발본부에 소속된다.' '개발본부는 C규정의 적용 대상이다.' 그리고 규칙이 하나 있습니다. '어떤 조직에 소속된 하위 조직은 상위 조직이 따르는 규정을 함께 따른다.' 이제 "A팀은 C규정 적용 대상인가"를 물으면, 데이터 어디에도 'A팀-C규정'이라는 연결이 직접 적혀 있지 않은데도 답이 나옵니다. 규칙을 타고 관계를 이어 붙여 새 사실을 만들어 낸 것입니다. 이것이 전이적 추론입니다.

가계도 비유로 돌아가 보겠습니다. 가계도에 '사촌'이라는 관계를 일일이 적어 두지 않아도 됩니다. '부모의 형제의 자녀는 사촌'이라는 규칙 하나만 있으면, 한 번도 만난 적 없는 사촌이 누구인지 가계도가 알려 줍니다. 온톨로지의 추론이 하는 일이 정확히 이것입니다. 저장돼 있지 않은 사실을, 관계와 규칙으로 계산해 꺼내 놓습니다.

다만 한 가지는 분명히 못 박아 두겠습니다. 이 추론은 규칙에 근거한 연역입니다. 앞에 놓인 사실과 규칙에서 논리적으로 따라 나오는 결론을 이끌어 내는 것이지, 없는 미래를 점치거나 통계적으로 넘겨짚는 예측이 아닙니다. 온톨로지 추론의 강점은 바로 이 엄밀함에 있습니다.

그렇다면 AI와 어떻게 연결되나 — LLM의 빈틈

LLM은 이미 방대한 데이터를 학습하고 이 세상의 상당 부분을 알고 있는 모델인데, 왜 조직도나 규정 사이의 관계 같은 단순한 질문을 틀릴까요? 답은 LLM이 작동하는 방식 자체에 있습니다. LLM은 다음에 올 말을 확률적으로 잇는 패턴 매칭 기계입니다. "A팀은 C규정을"이라는 문장 뒤에 "적용받습니다"가 올 확률이 높으면 그렇게 씁니다. 하지만 그것이 A팀의 소속과 규정 체계를 실제로 '따져 본' 결과인지는 보장되지 않습니다. 명시적 관계와 규칙을 밟아 도출한 결론이 아니라, 그럴듯한 말의 흐름을 이어 붙인 것에 가깝기 때문입니다. 환각과 근거 부재가 여기서 생깁니다. 그럴듯하지만 근거를 대라면 대지 못하는 답 말입니다.

물론 LLM의 언어 능력은 놀랍습니다. 방대한 지식을 유연하게 끌어와 자연스러운 문장으로 풀어내는 능력은 어떤 기술도 따라오지 못했습니다. 하지만 '왜 그런가'를 규칙에 따라 따지고 그 경로를 근거로 제시하는 일에는 취약합니다. 아는 것은 많은데 따져 보는 데는 약하다는, 글머리에서 던진 그 질문의 정체가 바로 이것입니다. LLM은 명단을 아주 잘 읽는 모델이지만, 명단만으로는 사촌을 추론할 수 없습니다. 관계선이 그려진 가계도가 따로 필요한 것입니다.

온톨로지가 AI 추론을 끌어올리는 세 가지

그 가계도 역할을 온톨로지가 맡습니다. 온톨로지가 AI의 추론을 끌어올리는 방식은 크게 세 가지로 정리할 수 있습니다.

가장 먼저 짚을 것은 명시적 관계와 규칙의 제공입니다. 온톨로지는 개념 사이의 관계와, 그로부터 추론 가능한 규칙을 가장 잘 보이는 곳으로 드러내 둔 지식 체계입니다. LLM이 확률로 넘겨짚어야 했던 부분을 온톨로지는 확정된 사실과 규칙으로 뒷받침합니다. 모델이 추측 대신 근거와 추론 위에서 답하게 되는 것입니다.

두 번째는 설명가능성과 환각 억제입니다. 온톨로지의 추론은 관계 경로를 따라 이뤄지므로, 답이 어떤 경로로 나왔는지 되짚을 수 있습니다. "A팀 → 개발본부 → C규정"이라는 경로가 그대로 남습니다. 답의 출처를 추적할 수 있으니 틀린 답을 걸러 내고 맞는 답을 신뢰할 근거가 생깁니다. 근거 없이 그럴듯하기만 한 답, 즉 환각이 끼어들 여지가 줄어듭니다.

세 번째는 검색 정확도의 보완입니다. 최근 주목받는 그래프RAG가 여기에 해당합니다. 기존 RAG(검색증강생성)는 질문과 문서의 의미적 유사도로 관련 자료를 찾아 LLM에 붙여 줍니다. 그런데 유사도만으로는 "말은 비슷한데 관계는 엉뚱한" 자료를 끌어오기 쉽습니다. 여기에 관계 그래프를 더하면, 단순히 닮은 문서가 아니라 실제로 연결된 맥락을 함께 가져올 수 있습니다. 유사도 검색의 빈틈을 관계가 메우는 셈입니다.

지식그래프와 온톨로지를 LLM에 결합해 환각을 줄이고 검색 품질을 높이려는 프로젝트가 산업 전반에서 활발히 시도되고 있습니다. 프로젝트마다 성과의 편차가 크기 때문에 정량적인 수치를 제시하기는 어렵지만, 분명한 것은 수치가 아니라 방향입니다. 확률적 언어 능력에 명시적 관계·규칙을 더한다는 이 결합이, 신뢰할 수 있는 AI를 만드는 유력한 길로 자리잡아 가고 있습니다.

한계와 오해 — 온톨로지도 만능은 아닙니다

물론 온톨로지에 대해 회의적인 시각도 존재합니다. 실무에서 온톨로지에 대한 가장 흔한 회의론은 "무겁다"는 것입니다. 개념과 관계, 규칙을 제대로 정의하려면 도메인 전문가의 손이 많이 가고, 결과물의 품질이 전문가의 역량에 달려 있습니다. 한 번 잘 만들어 두어도 조직과 규정, 업무가 바뀌면 스키마도 함께 진화시켜야 합니다. 관리를 놓으면 현실과 어긋난 낡은 지도가 되기 쉽습니다. 처음부터 모든 것을 담으려다 과설계에 빠지는 위험도 있습니다. 정작 쓰이지도 않을 관계까지 촘촘히 정의하느라 비용만 키우는 경우입니다.

다만 최근 흐름은 이 무게를 덜어 내는 쪽으로 움직이고 있습니다. 처음부터 완결된 거대 온톨로지를 짓기보다, 꼭 필요한 핵심 개념과 관계만 담은 경량 온톨로지에서 시작하는 접근이 늘고 있습니다. 아예 LLM 자체를 활용해 문서에서 개념과 관계 후보를 뽑아내 초안을 자동으로 만들고, 사람은 검수만 하는 방식도 확산되고 있습니다. AI가 온톨로지 구축을 돕고, 그 온톨로지가 다시 AI의 추론을 돕는 선순환인 셈입니다.

데이터를 '정돈'하고 '의미'를 부여한다는 것

한 걸음 물러나 큰 그림에서 보면, 지금까지의 이야기는 하나의 흐름 위에 놓입니다. 데이터를 믿고 쓸 수 있게 정돈하는 일(거버넌스), 그 위에 관계와 의미를 부여하는 일(그래프·온톨로지), 그리고 그렇게 다듬어진 데이터를 AI가 곧바로 쓸 수 있게 만드는 일. 온톨로지는 이 흐름의 한가운데, 데이터에 '의미'를 부여하는 자리에 있습니다.

온톨로지는 이름이 달라도 같은 개념을 하나로 묶어 흩어진 데이터를 보이게 하고(가시성), 저장돼 있지 않은 사실을 관계와 규칙으로 계산해 꺼냅니다(활용성). 그리고 바로 그 명시적 관계와 규칙이 LLM이 확률적 짐작을 넘어 근거 위에서 '따져 보게' 만드는 재료가 됩니다. 물론 만들고 유지하는 비용이 들고, LLM을 대신하는 것이 아니라 보완한다는 점도 잊어서는 안 됩니다. 온톨로지는 답을 대신 내주는 도구가 아니라, AI가 스스로 답을 따지도록 판을 깔아 주는 토대입니다.

처음의 가계도로 돌아가 보겠습니다. 이름을 아무리 길게 늘어놓아도, 명단만으로는 만난 적 없는 사촌을 알 수 없습니다. 하지만 관계선이 그려진 가계도는 적어 두지 않은 사실까지 알려 줍니다. 지금 AI에게 정말 필요한 것도 더 많은 데이터가 아니라 관계와 의미가 그려진 지도입니다. 그러니 이런 질문을 한번 던져 보시길 권합니다. 우리 조직의 데이터에는 LLM이 참조할 수 있는 '관계'가 어딘가에 명시돼 있나요? 아니면 여전히 누군가의 머릿속과 JOIN 관계 안에만 숨어 있나요? 그 답을 확인하는 것이 AI가 아는 것을 넘어 '따져 보게' 만드는 첫걸음입니다.