#고립된 데이터와의 작별 — 지식 그래프란 무엇인가

← 전체 목차 · 이전: Claude Code는 왜 코드 검색에 RAG를 쓰지 않는가 · 다음: 그래프 DB ≠ 지식 그래프

평범한 데이터베이스를 열어 서로 독립된 세 건의 데이터를 본다고 하자: 「철수」「어느 테크 회사」「어떤 프로그래밍 강의」.

이 세 줄의 마른 텍스트만으로는 그들 사이에 무슨 일이 있었는지 전혀 알 수 없다.

• 철수가 이 강의를 샀는가?
• 아니면 이 회사가 이 강의를 개발했는가?
• 또는 철수가 이 회사에서 이 강의를 가르쳤는가?

세 가능성은 완전히 다른 세 업무 사실에 대응하는데, 데이터 자체는 한 글자도 말해 주지 않는다. 초점을 고립된 객체에 두면 사물의 전모를 보기 어렵다.

지식 그래프는 본질적으로 그래프 구조로 지식을 조직하고 표현하는 기술이다.

#3요소: 노드 · 간선 · 속성

#① 노드 = 엔티티

거대한 그물의 각 교차점을 노드라 하며 현실 세계의 엔티티를 대표한다. 엔티티의 범위는 직관보다 넓다.

장소와 개념도 엔티티다 — "눈에 보이고 만질 수 있는 것"만 노드가 되는 것이 아니다.

#② 간선 = 관계

노드를 잇는 선을 간선이라 하며 엔티티 간의 관계를 나타낸다: 재직 중(사람 → 회사), 생산(회사 → 제품/강의), 위치(엔티티 → 장소), 투자(조직 → 조직).

최소 삼원 구조: 엔티티 A —— 간선(관계) —— 엔티티 B.

#③ 속성 — 노드에도 있고, 간선에도 있다

가장 간과되기 쉬우면서 가장 중요한 지점: 속성은 노드의 전유물이 아니며 간선도 속성을 지닐 수 있다.

이렇게 하면 "누가 누구와 관계가 있는가"만이 아니라 "그 관계의 구체적 디테일"까지 온전히 기록된다. 바꿔 말해 간선 속성은 한 단락의 관계를 불리언 값에서 생명주기를 가진 하나의 사실로 승급시킨다.

#왜 관계를 이토록 강조하는가

실제 업무 시나리오에서 많은 복잡한 문제의 답은 어느 한 객체의 단일 필드 안에 있지 않고 관계를 따라 한 겹씩 찾아 들어가야 한다.

#대조 실험: 다단계 조회, 그래프 vs 테이블 DB

전형적인 2단계 공급망 문제: "이 회사의 어떤 제품들이 같은 공급업체의 부품을 사용했는가?"

조회 경로: 회사 ──(산하 제품)──> 제품 ──(대응 공급업체)──> 공급업체

이 단락이 논증의 지지점이다 — 그래프의 우위는 저장 우위가 아니라 관계를 일급 시민으로 승격시킨 데서 오는 조회 경로 우위다.

#「지식」이라는 두 글자의 무게: 관계에는 도메인 의미가 있어야 한다

지식 그래프라는 이름에 「지식」이 들어 있다는 것은, 그래프 안의 노드와 간선이 아무렇게나 이어진 것이 절대 아니며 특정 도메인의 의미를 갖춰야 한다는 뜻이다.

• 「철수 재직 중 회사」
• 「회사 생산 강의」

이것은 완전히 다른 두 업무 로직이다. 시스템이 이 관계 유형들을 명확히 구분해야만 다음을 할 수 있다.

1. 복잡한 규칙 추론
2. 경로 조회
3. 어떤 결론의 데이터 출처 추적(소급)

#개념 경계: 벡터 검색 ≠ 지식 그래프

벡터 검색의 가치를 부정하는 것이 아니라, 그것을 자동으로 지식 그래프로 승격시키는 것을 거부하는 것이다.

#구축 절차: 네 단계

1. 정의
   당신의 업무 도메인에 어떤 유형의 엔티티와 관계가 필요한지 확정한다

2. 추출
   구조화된 데이터베이스나 비구조화 텍스트에서
   구체적인 사실 데이터를 추출한다

3. 엔티티 정합과 중복 제거
   같은 현실 객체를 가리키는 여러 이름을 같은 노드로 병합한다

4. 적재(출처와 함께)
   데이터를 「출처, 추출 시각, 신뢰도」와 함께 저장한다

4단계의 세 필드 — 출처 + 추출 시각 + 신뢰도 — 가 바로 "어떤 결론의 데이터 출처를 추적"할 수 있게 하는 전제다.

#가장 뒤집히기 쉬운 단계: 엔티티 정합

네 단계 중 오직 3단계에만 **"극도로 오류가 나기 쉽다"**는 판단이 붙는다.

전형적 실패 — 원본 데이터에서 같은 회사가 세 개의 다른 이름으로 쓰인 경우:

세 이름이 같은 엔티티 노드로 병합되지 않음
  → 시스템이 서로 다른 세 회사가 존재한다고 인식
  → 그래프를 크게 만들수록 안의 잘못된 연결이 많아짐
  → 최종적으로 제공하는 정보가 완전히 신뢰 불가

이 사슬의 방향에 주목할 것: 규모는 해약이 아니라 증폭기다. 정합이 제대로 되지 않은 상태에서 그래프를 키우면 오류만 더 많아진다.

#핵심 목적은 그림을 그리는 것이 아니다

지식 그래프는 엔티티, 관계, 속성을 유기적으로 조직해 조회 가능한 네트워크를 이루는 지식 표현 방식이다.

• ❌ 컴퓨터 대형 화면에 빽빽하고 멋져 보이는 관계도를 그리기 위한 것이 아니다
• ✅ 컴퓨터 시스템이 "누가 누구와, 어떤 구체적 업무 관계로, 어느 시점에 연결되었는가"에 정확하고 빠르게 답할 수 있게 하기 위한 것이다

이 한 문장이 앞의 세 복선을 동시에 회수한다: 「누가 누구와」= 노드, 「어떤 구체적 업무 관계로」= 도메인 의미가 있는 간선, 「어느 시점에」= 간선 속성.

#핵심 통찰

1. 고립된 객체를 아무리 온전히 저장해도 업무 문제에 답할 수 없다 — 「철수 / 테크 회사 / 프로그래밍 강의」 세 건이 전부 사실이지만 강의를 샀는지, 열었는지, 가르쳤는지는 도출되지 않는다. 정보량은 객체 안이 아니라 객체 사이에 있다. "데이터는 다 있는데 무슨 일이 있었는지 설명이 안 되는" 모든 시나리오에는 명시적 관계 모델링이 빠져 있다.
2. 그래프의 진짜 우위는 조회 경로이지 저장 형식이 아니다 — 테이블 DB도 JOIN 조회를 할 수 있다. 차이는 관계가 조회 시점에 임시로 조립되는가, 아니면 바닥 설계에서부터 핵심 데이터 모델로 표현되어 있는가다. 전자는 단계가 번거롭고 효율이 낮으며, 후자는 "지도를 보며 경로를 찾는 것처럼 직접적"이다.
3. 간선 속성이 「한 단락의 관계」를 생명주기를 가진 사실로 바꾼다 — 「철수 — 재직 중 — 회사」만 기록하면 관계가 있다는 것만 알 뿐이다. 시작 시각, 종료 시각, 직위명을 더해야 "그가 2021년에 어디 있었고 당시 직위가 무엇이었는지"에 답할 수 있다. 시간 차원은 노드가 아니라 간선에 붙으며, 그래프 모델링에서 가장 놓치기 쉬운 한 걸음이다.
4. 「지식」의 문턱은 도메인 의미이지 데이터량이 아니다 — 노드와 간선을 아무렇게나 이어서는 절대 안 된다. 「재직 중」과 「생산」은 완전히 다른 업무 로직이며, 관계 유형을 명확히 구분해야만 규칙 추론, 경로 조회, 출처 소급이 성립한다. 유형 구분이 없는 연결선은 그냥 그림이지 지식 그래프가 아니다.
5. 글자 유사도는 논리적 연관이 아니다 — 문서를 잘게 부수어 벡터 검색을 하면 시스템이 얻는 것은 "어느 두 단락이 닮았는가"이지 "누가 누구와 무슨 관계인가"가 아니다. 판정 기준은 하나뿐이다 — 명확하고 논리적인 관계 정의가 있는가.
6. 엔티티 정합이 구축 절차에서 유일하게 지목된 고위험 단계다 — 그 오류는 현장에서 에러를 내지 않고 조용히 하나의 엔티티를 셋으로 찢어 놓은 뒤 이후의 모든 연관에서 지속적으로 잘못된 연결을 만들어낸다.
7. 정합하지 않은 그래프에서 규모는 오류 증폭기다 — "그래프를 크게 만들수록 잘못된 연결이 많아지고 최종적으로 제공하는 정보가 완전히 신뢰 불가해진다"는 인과 사슬은, 정합 품질을 규모 확장 이전에 해결해야 하며 사후 보완 비용이 규모에 따라 초선형으로 증가함을 뜻한다.
8. 출처(출처 / 추출 시각 / 신뢰도) 보존이 신뢰도의 전제 조건이다 — 4단계는 "손 가는 대로 기록"이 아니다. 이 세 필드가 없으면 "어떤 결론의 데이터 출처 추적"이 물리적으로 불가능하고, 그래프가 답할 때 검증 가능한 근거를 댈 수도 없다.

#엔지니어링 실전 Tips

• 「2단계 문제」를 요구 판정 기준으로 쓸 것: 회사 → 제품 → 공급업체 같은 2단계 사슬이 그래프 가치의 검증 도구다. 손에 든 문제가 1단계로 끝난다면 그래프의 수익이 아직 드러나지 않는다.
• 관계 유형이 데이터 적재보다 먼저다: 구축 절차의 첫 단계가 "어떤 유형의 엔티티와 관계가 필요한지 확정"이지 데이터를 먼저 붓는 것이 아니다. 유형이 정해지지 않으면 규칙 추론과 경로 조회를 논할 수 없다.
• 장소와 개념도 엔티티로 만들 것: 장소를 노드의 문자열 속성으로 강등시키면 「위치」 간선과 위치 기반 경로 조회를 전부 포기하는 것이다.
• 시간 정보를 노드에 밀어 넣지 말 것: 직위, 시작 시각, 종료 시각은 간선 속성이다. 사람이나 회사의 노드 속성에 넣으면 한 사람이 두 회사에 차례로 재직하는 순간 모델이 무너진다.
• 정합을 세정 단계가 아니라 품질 관문으로 취급할 것: 규모 확장 전에 「약칭 / 정식 명칭 / 영문 약칭」 같은 동일 엔티티의 다중 표기를 수렴시킬 것.
• 모든 사실에 소급 3종 세트를 남길 것: 출처, 추출 시각, 신뢰도. 그래프를 "단언 더미"에서 "질의하고 검증할 수 있는 단언"으로 바꾸는 유일한 수단이다.
• 「시각화 = 성과」라는 착각을 경계할 것: 목적은 대형 화면에 빽빽하고 멋진 관계도를 그리는 것이 아니다. 보기 좋은 것과 시스템이 정확하고 빠르게 답하는 것은 별개다.