'문법'과 '대화' — 온톨로지와 지식그래프의 차이

관계를 담는 그래프, 의미의 규칙을 정의하는 온톨로지. 둘의 차이와 용도, 함께 썼을 때의 힘을 단계적으로 살펴봅니다.

최근 데이터 업계에서는 세 단어가 부쩍 자주 등장합니다. 그래프DB, 지식그래프(Knowledge Graph), 그리고 온톨로지(Ontology)입니다. 생성형 AI가 데이터를 '이해'하려면 결국 관계와 맥락이 필요하다는 인식이 퍼지면서, 이 개념들이 함께 묶여 오르내리고 있습니다. 그런데 정작 이야기를 나눠 보면 세 용어가 뒤섞여 쓰이는 경우가 많습니다. 그래프DB를 도입했다는 이야기가 어느새 지식그래프를 만들었다는 이야기로 넘어가고, 온톨로지는 "그 어렵고 학술적인 것" 정도로 뭉뚱그려집니다. 관심은 큰데 개념은 흐릿한 상태인 셈입니다.

이 혼동은 단순히 용어를 헷갈리는 문제로 그치지 않습니다. 세 개념의 층위를 구분하지 못하면 "우리 문제에는 무엇을 써야 하는가"라는 실무 판단이 곧바로 막히기 때문입니다. 그래프DB만 깔면 될 일에 온톨로지 설계까지 끌어들여 비용을 키우거나, 반대로 의미의 일관성이 절실한 프로젝트에 그래프만 얹어 놓고 왜 효과가 없는지 고민하는 경우를 현장에서 종종 봅니다. 그래서 이번 글에서는 그래프부터 차근차근 짚고, 지식그래프와 온톨로지의 같고 다름, 각각의 용도, 그리고 함께 썼을 때의 이점까지 단계적으로 살펴보겠습니다.

왜 표가 아니라 그래프인가

먼저 그래프라는 데이터 모델부터 짚어야 합니다. 우리가 오랫동안 데이터를 담아 온 그릇은 표, 즉 관계형 데이터베이스(RDB)였습니다. 행과 열로 이뤄진 표에 데이터를 넣고, 여러 표를 이어 붙일 때는 JOIN을 씁니다. 고객 표와 주문 표를 고객번호로 연결하는 식입니다. 정형화된 데이터를 정확하게 다루는 데 이만한 방식이 없습니다.

문제는 관계가 깊어질 때 생깁니다. "이 고객의 친구의 친구가 최근에 산 상품"처럼 연결을 여러 단계 타고 들어가야 하는 질문을 떠올려 보겠습니다. 표 구조에서는 이런 질문에 답하기 위해 JOIN을 겹겹이 쌓아야 하고, 단계가 하나 늘 때마다 비용이 가파르게 불어납니다. 과거에는 이런 다단계 관계 탐색이 워낙 비싸서 아예 시도하지 않거나, 별도의 배치 처리로 우회하는 경우가 많았습니다.

하지만 이제는 접근이 달라졌습니다. 그래프DB는 관계 자체를 데이터의 1급 정보로 다룹니다. 데이터를 노드(node, 점)로, 노드 사이의 연결을 엣지(edge, 선)로 표현하고, 각각에 속성을 붙입니다. '김철수'라는 노드와 '소설책 A'라는 노드가 '구매했다'라는 엣지로 이어지는 식입니다. 관계가 데이터 구조 안에 직접 새겨져 있으니, 연결을 몇 단계 타고 들어가도 그 관계를 따라가기만 하면 됩니다. JOIN을 새로 계산하는 것이 아니라, 이미 놓인 길을 걷는 셈입니다.

그래서 그래프DB는 관계 탐색이 곧 문제의 핵심인 영역에서 강점을 발휘합니다. 누가 누구와 연결돼 있는지가 중요한 소셜 네트워크, "이 상품을 산 사람이 함께 산 상품"을 찾는 추천, 정상적이지 않은 거래 흐름을 관계의 패턴으로 잡아내는 사기 탐지 등이 대표적입니다. 다만 여기서 미리 선을 하나 그어 두겠습니다. 그래프DB는 어디까지나 그래프 데이터를 효율적으로 담고 다루는 그릇입니다. 지식그래프는 그 그릇 위에 담기는 내용물에 가깝습니다. 둘을 같은 것으로 여기는 데서 첫 번째 혼동이 시작됩니다.

지식그래프란 무엇인가

그렇다면 그릇에 담기는 내용물, 지식그래프란 무엇일까요. 핵심은 그래프에 의미가 입혀졌다는 데 있습니다. 앞서 본 노드와 엣지는 그 자체로는 그저 점과 선입니다. 여기에 "이 점은 인물이고, 저 점은 영화이며, 둘을 잇는 선은 출연 관계다"라는 유형이 부여될 때, 비로소 지식그래프가 됩니다.

쉽게 말해 지식그래프는 단순한 점-선의 뭉치가 아니라, 무엇과 무엇이 어떤 관계인지가 명시된 그래프입니다. 영문법의 주어 - 동사 - 목적어처럼 '인물 - 출연 - 영화', '고객 - 구매 - 상품'으로 표현되니, 엔티티(개체)의 유형과 관계의 유형이 분명합니다. 그래서 기계가 "이 연결이 무슨 뜻인지"를 어느 정도 해석할 수 있습니다.

가장 널리 알려진 사례는 구글의 지식그래프입니다. 검색창에 유명한 인물이나 영화를 입력하면 결과 오른쪽에 생년월일, 대표작, 관련 인물이 정리된 정보 패널이 뜹니다. 이것은 웹페이지를 단순히 나열한 것이 아니라, '이 인물은 누구이며 무엇과 어떻게 연결되는가'를 의미 단위로 엮어 둔 지식그래프가 뒷받침하는 결과입니다. 특정 개체를 중심으로 관련된 사실들이 관계로 이어져 하나의 작은 지식망을 이루는 것입니다.

정리하면, 지식그래프는 실제로 존재하는 개체들과 그 관계를 의미 단위로 연결해 놓은 데이터의 지도입니다. 여기서 강조할 것은 '실제로 존재하는'이라는 대목입니다. 지식그래프에 담기는 것은 '김철수', '소설책 A'처럼 구체적인 개체, 곧 실제 데이터입니다. 이 점을 기억해 두면, 이어서 살펴볼 온톨로지와의 경계가 훨씬 또렷해집니다.

온톨로지란 무엇인가 — '문법과 사전'의 등장

이제 세 번째 개념, 온톨로지 차례입니다. 지식그래프가 실제 개체들의 지도라면, 온톨로지는 그 지도를 그릴 때 지켜야 할 규칙집입니다. 온톨로지는 특정 영역에 존재하는 개념과 관계, 그리고 그것들이 따라야 할 규칙을 형식적으로 정의한 체계입니다.

여기서 하나의 비유를 세워 보겠습니다. 언어에는 문법과 사전이 있습니다. 사전은 어떤 단어가 무엇을 뜻하는지 정의하고, 문법은 그 단어들을 어떻게 조합할 수 있는지를 규정합니다. '주어 다음에는 서술어가 온다', '이 명사는 이런 동사와 어울린다' 같은 약속입니다. 우리가 매일 주고받는 실제 대화는 이 문법과 사전을 바탕으로 성립합니다. 데이터의 세계에도 이런 규칙집이 필요합니다. 무엇을 무엇이라 부르고, 어떤 개념이 존재하며, 그것들 사이에 어떤 관계가 가능한지를 정의하는 규칙집, 그것이 바로 온톨로지입니다.

조금 더 구체적으로 들여다보겠습니다. 온톨로지는 대체로 다음과 같은 요소로 이뤄집니다.

• 클래스(class): 개념의 유형. 예를 들어 '사람', '회사', '상품' 같은 범주입니다.
• 속성(property): 개념이 가지는 특성이나 관계. '사람은 생년월일을 가진다', '사람은 회사에 소속된다'처럼 정의합니다.
• 제약(constraint): 지켜야 할 규칙. '사람은 하나의 생년월일만 가진다', '회사에 소속되려면 반드시 사람이어야 한다' 같은 조건입니다.

이런 개념을 컴퓨터가 다룰 수 있는 형태로 표현하기 위해 발전해 온 흐름이 이른바 시맨틱 웹(Semantic Web) 계보입니다. 데이터를 '주어 - 동사 - 목적어'의 삼중 구조로 표현하는 RDF, 개념과 관계를 정교하게 정의하는 언어인 OWL 등이 여기에 속합니다. 이 표준들을 깊이 파고들 필요는 없습니다. 중요한 것은 이들이 모두 "데이터에 대한 약속을 기계가 이해하게 만든다"는 목적을 공유한다는 점입니다.

여기서 온톨로지의 본질이 드러납니다. 온톨로지는 데이터 그 자체가 아닙니다. 데이터에 대한 약속입니다. '김철수'라는 구체적 개체는 온톨로지에 담기지 않습니다. 온톨로지에 담기는 것은 '사람이라는 개념이 존재하고, 사람은 회사에 소속될 수 있다'는 규칙입니다. 이 약속이 있기에 추론(inference)이 가능해집니다. 가령 온톨로지에 '개발자는 직원의 하위 개념'이라고 정의돼 있다면, '김철수는 개발자'라는 사실 하나만으로 시스템은 '김철수는 직원'이라는 사실을 스스로 이끌어 냅니다. 명시적으로 적어 두지 않은 지식이 규칙으로부터 도출되는 것입니다.

왜 두 개념이 자꾸 헷갈릴까요

그런데 이 지점에서 자연스러운 의문이 듭니다. 정의가 이렇게 다른데 왜 두 개념은 실무에서 그토록 자주 뒤섞일까요. 몇 가지 이유가 겹쳐 있습니다.

가장 먼저, 둘 다 '관계'와 '의미'를 다룹니다. 지식그래프도 관계를 표현하고 온톨로지도 관계를 정의하니, 표면적인 키워드가 겹쳐 보입니다. 또한 온톨로지 역시 그래프 형태로 표현되는 경우가 많습니다. 개념과 개념을 관계로 잇다 보면 그림이 지식그래프와 닮게 그려지는 것입니다. 여기에 더해, 실제 시스템에서는 온톨로지와 지식그래프가 하나의 그래프DB 안에 함께 존재하는 경우가 흔합니다. 규칙 층과 데이터 층이 물리적으로 같은 저장소에 담겨 있으니, 겉보기에는 구분이 잘 되지 않습니다.

결국 혼동의 진짜 원인은 하나로 모입니다. 둘이 서로 다른 층위(layer)에 있다는 사실을 놓치기 때문입니다. 이 '층위'라는 열쇠를 손에 쥐면 나머지 차이는 자연스럽게 풀립니다. 다음 섹션에서 그 층위를 정면으로 갈라 보겠습니다.

무엇이 다른가 — 데이터의 층 vs 규칙의 층

앞서 세운 문법 비유를 다시 불러오겠습니다. 온톨로지는 언어의 문법과 사전입니다. 지식그래프는 그 문법으로 실제로 쓰인 문장들입니다. 문법은 "주어와 서술어가 어떻게 결합하는가"라는 규칙이고, 문장은 "김철수가 책을 샀다"라는 실제 발화입니다. 규칙은 문장이 지켜야 할 틀을 제공하고, 문장은 그 틀 안에서 살아 움직입니다.

이것을 데이터의 언어로 옮기면 이렇습니다.

• 온톨로지 = 스키마/규칙의 층입니다. '사람', '상품'이라는 개념이 존재하고 그 사이에 '구매'라는 관계가 가능하다는 정의입니다. 추상적이며, 개체 하나하나를 담지 않습니다.
• 지식그래프 = 인스턴스/데이터의 층입니다. '김철수가 분석책 A를 구매했다'처럼 실제 개체와 그 연결로 채워집니다. 구체적이며, 규칙이 허용하는 관계들이 실제로 실현된 결과입니다.

두 층을 나란히 놓으면 차이가 한눈에 들어옵니다.

마지막에 주목할 필요가 있습니다. 온톨로지 없이도 지식그래프를 만드는 것은 얼마든지 가능합니다. 개념 유형을 엄밀히 정의하지 않은 채, 그저 개체와 개체를 관계로 이어 붙이기만 해도 형태상으로는 지식그래프가 됩니다. 다만 그때의 '의미'는 어디까지나 암묵적입니다. '구매'라는 엣지가 정확히 무엇을 뜻하는지, 어떤 개체 사이에만 허용되는지가 규칙으로 못 박혀 있지 않다면, 그 의미는 사람이 머릿속으로 짐작할 뿐 시스템이 보증하지는 못합니다. 이 차이가 실제 용도에서 어떻게 갈라지는지 이어서 보겠습니다.

용도의 차이 — 어디에 무엇이 강한가

층위가 다르니 잘하는 일도 다릅니다. 실무에서 무엇을 먼저 손에 쥐어야 할지 판단할 때, 다음 구분이 도움이 됩니다.

지식그래프가 강한 곳은 탐색과 연결입니다. 흩어져 있던 데이터를 관계로 이어 붙여, 키워드로는 도달하기 어려운 답을 찾아냅니다. 추천, 통합 검색, 여러 소스에 나뉜 정보를 하나의 개체 중심으로 모아 보는 작업이 여기에 해당합니다. "이 고객과 연결된 모든 것을 보여 달라" 같은 질문에 강합니다.

온톨로지가 강한 곳은 표준화와 일관성입니다. 개념과 관계를 명확히 정의해 두면, 여러 시스템이 같은 용어를 같은 의미로 쓰게 됩니다. 데이터가 규칙에 맞는지 검증하고, 명시되지 않은 사실을 규칙으로부터 자동으로 추론하는 일도 온톨로지의 몫입니다. 의미의 정합성이 핵심인 곳에서 힘을 냅니다.

가상의 상황으로 풀어 보겠습니다. 한 회사에 세 개의 시스템이 있다고 해 보겠습니다. 영업 시스템은 어떤 개체를 '거래처'라 부르고, 회원 시스템은 같은 대상을 '가입자'라 부르며, CS 시스템은 '고객'이라 부릅니다. 이름이 셋으로 갈라져 있으니, 데이터를 아무리 그래프로 이어 붙여도 시스템은 이 셋이 같은 존재라는 것을 알지 못합니다. 여기서 온톨로지가 "거래처·가입자·고객은 모두 '고객'이라는 하나의 개념"이라고 의미를 묶어 줍니다. 그리고 지식그래프가 그 정의를 바탕으로, 세 시스템에 흩어진 실제 개체들을 하나의 고객으로 실제로 연결합니다. 규칙이 의미를 정하고, 데이터가 그 의미를 실현하는 협업 구도입니다.

함께 쓰면 무엇이 좋아지는가

그렇다면 두 개념을 함께 쓸 때 얻는 것은 무엇일까요. 왜 지금 이 조합이 중요해지는지부터 짚어야 합니다.

데이터가 늘어날수록 '연결'만으로는 부족해지기 때문입니다. 초기에는 개체 몇 개를 관계로 잇는 것만으로도 충분해 보입니다. 하지만 개체가 수십만, 수백만으로 불어나고 데이터를 만들어 내는 시스템이 여럿으로 늘어나면, 같은 관계가 시스템마다 조금씩 다른 뜻으로 쓰이기 시작합니다. 이때 필요한 것이 의미의 일관성입니다. 연결의 양이 아니라 연결의 의미가 문제가 되는 것입니다.

여기서 온톨로지와 지식그래프는 서로의 빈자리를 채웁니다. 온톨로지는 지식그래프에 의미의 뼈대를 줍니다. 어떤 개념이 존재하고 어떤 관계가 허용되는지를 규칙으로 세워, 데이터가 제멋대로 흩어지지 않게 잡아 줍니다. 반대로 지식그래프는 온톨로지에 살아 있는 데이터를 채웁니다. 추상적인 규칙만으로는 아무것도 답하지 못하지만, 그 규칙을 따르는 실제 개체들이 들어차면 비로소 질문에 답할 수 있게 됩니다.

이 조합이 만들어 내는 가장 큰 이점이 추론입니다. 앞서 본 상속 규칙을 다시 떠올려 보겠습니다. 온톨로지에 '자회사 관계는 이어진다'는 규칙이 정의돼 있고, 지식그래프에 'A사는 B사의 자회사', 'B사는 C사의 자회사'라는 사실이 담겨 있다면, 시스템은 누구도 직접 입력하지 않은 'A사는 C사의 손자회사'라는 관계를 스스로 도출합니다. 데이터에 명시되지 않은 지식이 규칙과 데이터의 결합에서 새로 태어나는 것입니다.

그 결과 데이터를 다루는 방식 자체가 달라집니다. 검색과 질의가 단순한 '키워드 매칭'을 넘어 '의미 기반'으로 올라섭니다. '고객'이라는 단어가 없는 문서라도, 그것이 의미상으로 고객과 연결된 정보라면 함께 찾아낼 수 있습니다. 여러 시스템에 흩어진 데이터를 통합할 때도 훨씬 견고해집니다. 개별 데이터가 무엇을 뜻하고 서로 어떻게 이어지는지를 가시적으로 볼 수 있게 된다는 의미입니다. 이러한 가시성이 확보되어야 사람도, 그 위에서 일하게 될 AI도 데이터를 헤매지 않고 제대로 읽어 낼 수 있습니다.

흔한 오해 세 가지

여기까지 왔다면 실무에서 자주 마주치는 오해들을 정리해 볼 수 있습니다. 세 가지가 특히 흔합니다.

• 오해 1: "그래프DB만 도입하면 지식그래프가 된다." 앞서 그은 선을 다시 확인할 대목입니다. 그래프DB는 그릇이고 지식그래프는 그 안의 내용물입니다. 그래프DB를 설치했다는 것은 지식을 담을 준비를 마쳤다는 뜻일 뿐, 개체와 관계에 의미를 부여하고 실제로 채워 넣는 일은 그다음의 과제입니다.
• 오해 2: "온톨로지는 학술적이고 지나치게 복잡하다." 시맨틱 웹의 정교한 표준들을 떠올리면 그렇게 느껴질 수 있습니다. 하지만 모든 온톨로지가 완벽하고 방대할 필요는 없습니다. 핵심 개념 몇 개와 그 사이의 관계만 정의하는 작고 실용적인 온톨로지부터 시작해, 필요에 따라 키워 가는 접근이 오히려 현실적입니다.
• 오해 3: "지식그래프만 있으면 온톨로지는 필요 없다." 규모가 작을 때는 맞는 말처럼 들립니다. 그러나 데이터가 커지고 시스템이 늘어날수록, 규칙 층이 없다는 사실이 서서히 비용으로 돌아옵니다. 같은 관계가 서로 다른 뜻으로 쓰이고, 데이터 품질을 검증할 기준이 없어 오류가 조용히 쌓입니다. 규칙의 부재는 처음에는 보이지 않다가 나중에 청구서로 날아옵니다.

도입 전에 짚어야 할 것들

물론 이 두 가지를 갖췄다고 모든 데이터 문제가 풀리는 것은 아닙니다. 오히려 도입 전에 냉정하게 따져야 할 지점들이 있습니다.

가장 먼저 온톨로지 설계의 난이도입니다. 개념과 관계를 정의한다는 것은 곧 조직 안의 여러 이해관계자가 용어의 의미에 합의한다는 뜻입니다. 이 합의 자체가 만만치 않은 일이며, 한 번 만들어 두고 끝나지도 않습니다. 사업이 바뀌면 규칙도 손봐야 하니 유지보수 부담이 따릅니다. 지식그래프 쪽도 마찬가지입니다. 흩어진 데이터를 관계로 잇고 그 품질을 관리하는 데는 지속적인 손이 들어갑니다. 관계가 잘못 연결되면 지식그래프는 잘못된 지도가 되고, 그 위의 추론은 그럴듯한 오답을 낳습니다.

무엇보다 이 모든 것이 실효를 내려면 조직 차원의 데이터 거버넌스가 앞서야 합니다. 데이터가 어디서 와서 어떻게 흐르고, 무엇이 표준이며 품질이 어떻게 관리되는지가 정돈돼 있지 않은 상태에서 그래프와 온톨로지만 얹으면, 정돈되지 않은 데이터 위에 그럴듯한 껍데기를 씌우는 데 그치기 쉽습니다. 규칙과 데이터는 그것을 떠받치는 토대가 튼튼할 때 비로소 힘을 냅니다.

결론 — 규칙과 데이터가 만나는 자리

처음의 문법 비유로 돌아가 보겠습니다. 문법만 있고 아무도 말을 하지 않으면 언어는 죽은 규칙에 그칩니다. 반대로 문법 없이 소리만 오가면 서로 알아들을 수 없는 소음이 됩니다. 어느 하나만으로는 언어가 성립하지 않습니다. 데이터도 다르지 않습니다. 세 개념을 층위로 다시 압축하면 이렇습니다. 그래프DB는 데이터를 담는 그릇이고, 지식그래프는 그 안에 채워진 실제 데이터이며, 온톨로지는 그 데이터가 따라야 할 규칙입니다. 규칙과 데이터가 만날 때, 비로소 데이터에 '의미'가 작동하기 시작합니다.

새로운 기술의 이름을 먼저 좇기보다, 지금 우리 조직이 겪는 문제가 '연결'의 문제인지 '일관성'의 문제인지부터 구분해 보시길 권합니다. 흩어진 데이터를 이어 붙여 새로운 답을 찾는 것이 급하다면 지식그래프가 먼저이고, 여러 시스템이 같은 말을 서로 다르게 쓰는 것이 골칫거리라면 온톨로지가 먼저입니다. 그리고 데이터가 커질수록 결국 둘은 함께 가게 됩니다. 다만 그 여정에는 설계와 거버넌스라는 만만찮은 숙제가 따른다는 점도 잊지 않아야 합니다. 데이터에 의미의 층위를 부여하는 일은 한 번의 도입이 아니라, 규칙과 데이터를 함께 가꿔 가는 긴 작업이기 때문입니다.