지식 그래프
개체(Entity)와 관계(Relation)를 그래프 구조로 표현한 지식 표현 체계.
— 시맨틱 웹, 검색 엔진, 엔터프라이즈 데이터 관리 분야의 공통 개념
문서와 테이블에 흩어진 사실을 예쁘게 연결하겠다는 꿈으로 시작하지만, 현실에서는 “이 고객사 이름이 이 법인명이 맞나요?”를 하루 종일 묻는 데이터 청소 프로젝트가 된다. 그래프는 아름답고 원천 데이터는 늘 진흙탕이다
1. 개요
지식 그래프(Knowledge Graph)는 사람, 조직, 제품, 장소, 개념 같은 개체를 노드로 두고, 이들 사이의 관계를 엣지로 연결해 지식을 표현하는 구조다. 예를 들어 “React는 JavaScript 라이브러리다”, “Next.js는 React 기반 프레임워크다” 같은 사실을 문장으로만 저장하지 않고, React, JavaScript, 라이브러리, Next.js를 각각 노드로 만들고 관계를 연결한다. 이 구조 덕분에 단순 키워드 검색보다 “무엇이 무엇과 어떻게 연결되어 있는가”를 추적하기 쉬워진다. 검색 엔진, 추천 시스템, 사내 데이터 카탈로그, Graph RAG 같은 인공지능 검색 시스템에서 핵심 기반으로 자주 등장한다.
2. 노드와 엣지로 보는 세계
지식 그래프의 기본 단위는 노드(Node)와 엣지(Edge)다. 노드는 개체를 뜻하고, 엣지는 개체 사이의 관계를 뜻한다. “TypeScript는 JavaScript의 상위 집합이다”라는 문장을 그래프로 바꾸면 TypeScript와 JavaScript가 노드가 되고, “상위 집합이다”라는 관계가 엣지가 된다. 이 구조는 사람이 보기에도 직관적이고, 기계가 탐색하기에도 좋다. 특정 노드의 주변을 따라가면 연관 개념을 찾을 수 있고, 두 노드 사이의 경로를 찾으면 숨은 관계를 설명할 수 있다. 그래서 지식 그래프는 검색 결과에 맥락을 붙이거나, LLM이 답변할 때 참고할 구조화된 배경 지식으로 자주 쓰인다.
3. 온톨로지와 현실 데이터의 충돌
문제는 “어떤 노드를 만들고 어떤 관계를 허용할 것인가”를 정하는 순간부터 시작된다. 이를 온톨로지 또는 스키마 설계라고 부르는데, 말은 멋있지만 실무에서는 명칭 표준화 회의의 늪이다. “고객”, “거래처”, “파트너”가 같은 개념인지 다른 개념인지, “소유한다”와 “관리한다”를 다른 관계로 둘지 같은 관계로 둘지 정해야 한다. 이 결정을 대충 하면 그래프는 빠르게 커지지만 질의 결과는 믿을 수 없게 된다. 반대로 너무 엄격하게 설계하면 데이터 입력이 느려지고 운영자가 지친다. 지식 그래프는 기술 문제이면서 동시에 조직의 언어를 정리하는 문제다.
4. 관련 밈 및 드립
4.1. Wikidata 보고 자신감 얻었다가 사내 데이터 보고 침묵
공개 지식 그래프 사례를 보고 “우리도 금방 만들 수 있겠는데?”라고 생각했다가, 사내 엑셀과 문서에 같은 대상이 다섯 가지 이름으로 적힌 현실을 보고 조용히 일정을 다시 산정하는 상황을 가리킨다.
4.2. 선이 많으면 똑똑해 보인다
그래프 시각화에서 노드와 선이 화면을 가득 채우면 왠지 고급 AI 시스템처럼 보인다. 하지만 실제로는 너무 많은 관계가 오히려 탐색을 방해하고, 중요한 연결과 잡음이 뒤섞여 사람이 읽을 수 없는 털실 뭉치가 되기도 한다.
5. 여담
- Google 검색의 전환점: Google Knowledge Graph는 검색어를 단순 문자열이 아니라 실제 세계의 개체로 이해하려는 시도였다. “Apple”이 과일인지 회사인지 문맥으로 구분하는 식의 검색 품질 개선에 큰 영향을 줬다.
- 그래프 DB와는 다르다: 지식 그래프는 데이터 표현 방식이고, 그래프 데이터베이스는 이를 저장하고 질의하는 구현 수단이다. 둘은 자주 같이 쓰이지만 같은 말은 아니다.
- LLM 시대의 재평가: LLM이 문장을 잘 만들수록, 오히려 검증 가능한 구조화 지식의 중요성이 커졌다. 그 결과 지식 그래프는 RAG와 함께 다시 주목받고 있다.