#그래프 DB ≠ 지식 그래프 — 상자는 살 수 있지만 보석은 살 수 없다

← 전체 목차 · 이전: 고립된 데이터와의 작별 — 지식 그래프란 무엇인가 · 다음: AI는 어떻게 애플(회사)과 사과(과일)를 구분하는가

전형적인 오해의 현장: 상사나 고객이 제품 소개서를 가리키며 "우리가 이 그래프 데이터베이스를 샀으니 우리 회사 지식 그래프도 구축된 셈이지?"라고 말한다.

핵심 비유: 물건을 담는 예쁜 상자를 샀다고 해서 그 상자에 담길 보석을 이미 소유한 것은 아니다.

#그래프 DB가 제공하는 것은 무엇인가

그래프 데이터베이스는 데이터를 담는 컨테이너이며 저장과 조회 두 가지 능력을 제공한다.

• 내부적으로 노드, 관계, 속성으로 데이터를 저장한다.
• 연결선을 따라 고속으로 탐색하는 데 특히 강하다.

능력 목록에 의미(semantic)와 관련된 항목이 하나도 없다는 점에 주목할 것 — 뒤의 경계선을 위한 복선이다.

#그물 모양 ≠ 그래프

전형적인 그래프 구조 업무 데이터 두 가지:

1. 택배 거점의 물류 네트워크
2. 회사 내부의 누가 누구에게 보고하는 권한 구조

이 데이터들은 분명 그물 모양의 그래프 구조지만 곧바로 지식 그래프라 부를 수 없다. 이유는 그것들이 흔히 단순한 업무 연결만 기록할 뿐 통일된 의미 표준을 세우지 않았고 지식 모델링의 목표도 없기 때문이다.

#지식 그래프가 관심을 두는 것은 「컨테이너 안에 표현된 의미 내용」이다

경계선은 세 질문으로 명확히 정의된다.

노드:  이 노드가 도대체 어떤 객관적 사물인가?
연결선: 그 연결선이 도대체 무슨 확실한 의미를 대표하는가?
접합:  서로 다른 시스템의 데이터를 어떻게 정확히 이어 붙이는가?

#규범과 거버넌스: 세 가지 구체적 실무 문제

이 문제들이 지식 그래프의 핵심 세 항목으로 귀납된다.

1. 개념 정의
2. 엔티티 병합
3. 데이터 출처 추적

그리고 우선순위 판단: 이 문제들을 해결하는 것이 어느 회사의 데이터베이스 제품을 살지 결정하는 것보다 훨씬 더 중요하다.

#역질문: 지식 그래프를 반드시 그래프 DB에 넣어야 하는가

답은 마찬가지로 부정이다 — 보석을 반드시 그 특정한 상자에 넣어야 하는 것은 아니다. 그래프 DB는 마침 이런 그물 모양 관계를 담고 조회하기에 매우 적합할 뿐이며, 지식 그래프의 매우 좋은 실무 적용 방안 중 하나이지 유일한 조건은 절대 아니다.

#철수가 영희를 팔로우한다: 「그래프 데이터」에서 「지식 그래프」로 가는 분수령

상태 A — 그저 그래프 데이터일 뿐

시스템 기록: 사용자 철수 --팔로우--> 사용자 영희
그래프 DB에 저장하면 「철수가 또 누구를 팔로우했는지」를 빠르게 조회할 수 있다
→ 이것은 그저 그래프 데이터일 뿐이다

상태 B — 진짜 지식 그래프

1. 엔티티 병합: 이 철수 = 다른 플랫폼의 작가 철수(같은 사람)임을 식별
2. 의미 한정: 「팔로우」라는 동작이 이번 달 1일에 발생했음을 명확히
3. 도메인 교차 연관: 철수를 그의 회사, 그가 산 제품, 그가 쓴 글과 전부 연관
4. 증거 출처: 이 정보들이 「알고리즘 추론」인지 「사람 심사」를 거친 것인지 명확히 기록
→ 데이터가 완전한 의미 정의와 증거 출처를 갖췄을 때 비로소 진짜 지식 그래프로 진화한다

#두 층의 독립된 작업

기술 선택과 지식 모델링은 언제나 두 층의 독립된 작업이다.

결론: 돈으로 기성 데이터베이스 소프트웨어는 살 수 있지만, 고품질 지식 그래프는 영원히 직접 살 수 없다 — 그것은 반드시 당신이 한 걸음씩 모델링하고 추출하고 거버넌스해야 만들어진다.

#판정 절차: 손에 든 것이 그래프 데이터인가 지식 그래프인가

0. 먼저 자신이 어느 층을 하고 있는지 물을 것
   기술 선택(어디에 저장하고 어떻게 조회할까)과 지식 모델링(어떻게 표현하고 연결할까)을
   따로 기안하고, 한 층의 완성도로 다른 층의 진도를 보고하지 말 것.

1. 노드에 「객관적 사물」 검사
   노드 몇 개를 무작위로 골라 묻는다: 이것이 현실의 무엇을 지칭하는가?
   답이 「어느 테이블의 한 행」밖에 안 된다면 아직 의미가 없다.

2. 연결선에 「확실한 의미」 검사
   간선 몇 개를 무작위로 골라 묻는다: 이 간선이 무슨 관계를 대표하는가? 통일된 정의가 있는가?
   같은 관계가 서브시스템마다 다르게 불린다면 통일된 의미 표준이 없는 것이다.

3. 엔티티 병합(진위 가리기)
   동명이인 / 플랫폼을 넘나드는 동일 주체 사례를 찾아,
   시스템이 「이 철수」와 「저 작가 철수」가 같은 사람인지 판정할 수 있는지 확인한다.

4. 관계에 시간과 출처를 보완
   중요한 관계마다 채운다: 몇 년에 시작해 몇 년에 끝났는가,
   어느 업무 시스템에서 추출되었는가.

5. 모든 사실에 증거 라벨을 붙일 것
   알고리즘 추론인지 사람 심사인지 표기해
   하류가 신뢰도별로 등급을 나눠 사용할 수 있게 한다.

6. 도메인 교차 연관 검증을 한 번 할 것
   한 주체를 기점으로 그의 회사, 산 제품, 쓴 글을 꿰어
   시스템을 넘어 통하는지 본다. 통하지 않으면 접합층이 아직 없는 것이다.

7. 마지막에야 저장으로 돌아올 것
   지식 규모가 작다 → 평범한 텍스트 파일
   데이터량이 크다 → 전통 관계형 DB 또는 의미 시스템 전용 아키텍처
   그물 관계 조회가 밀집 → 그래프 DB(좋은 방안이지만 유일한 조건은 아니다)

#핵심 통찰

1. 컨테이너는 내용을 만들지 않고, 구매는 지식을 만들지 않는다 — 그래프 DB가 납품하는 것은 저장과 조회 능력이고 지식 그래프가 납품하는 것은 의미와 증거다. 전자는 계약으로 바꿀 수 있고 후자는 모델링과 거버넌스로만 바꿀 수 있다. "상자와 보석" 비유의 전부다.
2. "데이터가 그물 모양"은 필요조건일 뿐 충분조건이 아니다 — 택배 물류 네트워크, 회사 보고 권한 구조는 표준적인 그래프 구조이지만 단순한 업무 연결만 기록할 뿐 통일된 의미 표준과 모델링 목표가 없으므로 여전히 그래프 데이터일 뿐이다.
3. 그래프 데이터와 지식 그래프를 가르는 판정 기준은 선택 체크리스트가 아니라 세 질문이다 — 노드가 어떤 객관적 사물인가, 연결선이 무슨 확실한 의미인가, 시스템을 넘나드는 데이터를 어떻게 정확히 이어 붙이는가. 이 셋에 답하지 못하면 어느 회사 DB로 바꿔도 그래프가 되지 않는다.
4. 지식 그래프의 진짜 작업량은 거버넌스에 있지 저장에 있지 않다 — 개념 정의, 엔티티 병합, 데이터 출처 추적 세 가지가 "어느 제품을 살지"보다 훨씬 중요하다. 프로젝트 일정에서 예산과 공수를 선택에만 몰아넣으면 중심을 잘못 잡은 것이다.
5. 모든 간선에 한정어가 있어야 지식이 된다 — 같은 「철수가 영희를 팔로우한다」라도 시간(이번 달 1일), 엔티티 정합(작가 철수 = 철수), 도메인 교차 연관, 출처 표기(알고리즘 추론 / 사람 심사)를 더해야 데이터에서 지식으로 바뀐다. 무엇 하나가 빠져도 그래프 데이터로 되돌아간다.
6. 증거 출처는 그래프의 일급 시민이다 — "이 정보가 알고리즘 추론인지 사람 심사를 거친 것인지"를 의미 정의와 나란히 진화 조건으로 두었다는 것은, 신뢰도가 사후에 덧붙이는 메타데이터가 아니라 모델링 시점에 남겨야 할 필드임을 뜻한다.
7. 저장 방안은 「그래프」라는 단어가 아니라 지식 규모가 결정해야 한다 — 규모가 작으면 텍스트 파일, 크면 관계형 DB나 의미 시스템 전용 아키텍처. 그래프 DB는 매우 좋은 실무 적용 방안이지만 **"유일한 조건은 아니다"**라고 명시적으로 판정된다.
8. 기술 선택과 지식 모델링은 독립된 두 공정이며, 병행할 수도 순차적으로 할 수도 있지만 서로를 대신할 수는 없다 — 한쪽을 끝내고 다른 쪽이 완료되었다고 선언하는 것이 바로 "그래프 DB를 샀으니 그래프가 구축되었다"의 병소다.

#엔지니어링 실전 Tips

• 의미 표준을 먼저 세우고 데이터를 부을 것: "통일된 의미 표준"과 "지식 모델링의 목표"가 그래프 데이터와 그래프의 분수령이다. 표준이 없는 상태에서 많이 부을수록 후기 병합 비용이 커진다.
• 엔티티 중의성 해소를 일회성 세정이 아니라 상설 절차로: 동명이인은 가장 예를 들기 쉬운 경우일 뿐이고, 플랫폼을 넘나드는 계정과 시스템을 넘나드는 주체도 지속적으로 동일 엔티티인지 판정해야 한다.
• 관계에는 일률적으로 시간 구간을 담을 것: 협력 관계의 "몇 년 시작 몇 년 종료"는 엔티티 병합과 나란히 놓인 거버넌스 문제이며, 관계의 유효 기간은 주석이 아니라 모델링 필드다.
• 출처 시스템은 구체적 업무 시스템까지 소급 가능해야 한다: "이 사실이 어느 업무 시스템에서 추출되었는가"의 소급 입도는 시스템 단위여야지 "데이터 웨어하우스에서 왔다" 같은 뭉뚱그린 표현이면 안 된다.
• 추론과 사람 심사를 구분해 따로 다룰 것: 알고리즘이 추론한 연관과 사람이 심사한 연관은 구분 가능하고 각각 조회 가능해야 한다.
• 저장 선택으로 모델링 진도를 보증하지 말 것: 보고할 때 "컨테이너가 준비됨"과 "보석이 산출됨"을 명확히 구분할 것 — 바로 이 지점에서 서두의 대화가 뒤집혔다.
• 소규모 지식에 과도하게 무거운 인프라를 올리지 말 것: 규모가 매우 작을 때는 "평범한 텍스트 파일에 저장"해도 되며, 클러스터에 쓰는 것보다 의미 정의에 정력을 쓰는 편이 이득이다.