지식 그래프란? 예시로 쉽게 알아보는 가이드

지식 그래프는 지식을 의미 있는 관계로 연결된 대상들로 표현해요. 사람, 책, 프로젝트, 아이디어는 노드가 되고, 이들 사이의 연결은 엣지가 돼요. 예를 들어, 마야는 현장 노트를 썼고, 현장 노트는 도시 원예를 다뤄요. 이 세 개의 노드와 이름이 붙은 두 개의 관계는 작은 지식 그래프를 이뤄요. 단순히 관련 단어를 나열한 목록이 아니에요.

간단한 예시: 대상, 연결, 질문

그 가상의 작가와 책, 주제가 담긴 독서 노트를 떠올려 보세요. 정보를 문장으로 적을 수도 있고, 이들 사이의 관계를 명확하게 나타낼 수도 있어요:

Maya → wrote → Field Notes
Field Notes → discusses → Urban Gardening

이제 마야에서 시작해 연결을 따라가 보세요. 마야의 책은 어떤 주제를 다루나요? 이번에는 도시 원예에서 시작해 보세요. 어떤 책들이 이 주제를 다루고, 그 책들은 누가 썼나요?

이것이 지식 그래프의 바탕이 되는 실용적인 아이디어예요. 어떤 대상이 무엇과 어떻게 연결되어 있는지를 보존하므로, 사람이나 소프트웨어가 흩어진 텍스트에서 연결 관계를 다시 구성하는 대신 그 연결을 따라갈 수 있어요.

“지식”이라는 말이 중요해요. Maya와 Field Notes를 잇는 선만으로는 알 수 있는 게 별로 없어요. 선에 wrote라는 라벨을 붙이면 구체적인 사실을 나타내요. 라벨을 reviewed로 바꾸면 다른 사실을 나타내게 돼요.

지식 그래프의 구성 요소

엔터티: 설명의 대상

개체는 노드로 표현되는 특정 대상이나 개념이에요. 사람, 조직, 장소, 사건, 문서 또는 주제가 될 수 있어요. 이 예시에서 Maya는 사람, Field Notes는 책, 도시 정원 가꾸기는 주제예요.

대상 자체와 표시 이름을 구분하세요. 노트북에 Maya라는 이름을 가진 사람이 두 명 있다면, 레이블이 같다는 이유만으로 둘을 하나로 합치지 마세요. 반대로 “Maya”와 “Maya — 저자”는 같은 사람을 가리킬 수도 있어요. 어떤 기록들이 같은 대상을 나타내는지 판단하는 것도 유용한 그래프를 만드는 과정의 일부예요.

관계: 개체를 연결하는 요소

엣지는 노드를 연결해요. 엣지의 유형은 관계를 나타내며, 예를 들어 wrote, works-for, depends-on 또는 discusses가 있어요.

방향도 중요해요. “Maya가 Field Notes를 썼다”와 “Field Notes가 Maya를 썼다”는 같은 말이 아니에요. 문장처럼 소리 내어 읽을 수 있는 라벨을 선택하세요. 문장이 어색하다면 모델이 명확하지 않다는 신호인 경우가 많아요.

속성: 대상이나 연결에 대한 세부 정보

속성은 개체나 관계를 설명해요. 예시로 삼은 가상의 책에는 제목과 독서 상태를 기록할 수 있어요. Maya의 경우에는 표시 이름을 기록할 수 있어요.

어떤 정보를 속성으로 둘지, 별도 노드로 만들지 고민되나요? 첫 프로젝트라면 다른 항목을 그 정보에 연결하고 싶은지 생각해 보세요. 독서 상태는 속성으로 두어도 되지만, 여러 책을 하나의 주제로 연결하고 싶다면 그 주제는 별도 노드로 만드는 게 좋아요.

트리플: 진술을 하나씩

트리플은 사실을 주어–술어–목적어 형태로 표현해요. Maya → wrote → Field Notes의 경우:

• 주어: 마야—문장 첫머리에 나오는 개체예요.
• 서술어: 썼다—문장에서 명시하는 관계예요.
• 목적어: 현장 노트—그 관계가 향하는 대상이에요.

트리플은 모델을 이해하는 간결한 표현 방식이에요. 노트 앱에서 작업할 때 모든 연결을 이 표기법으로 작성할 필요는 없어요. 이름을 붙인 관계로도 같은 기본 개념을 표현할 수 있어요.

개발자는 여러 방식으로 구현할 수 있어요. Esri는 속성 그래프와 RDF 그래프를 구분해요. 속성 그래프는 노드와 관계에 키-값 형태의 속성을 붙이는 반면, RDF는 트리플로 진술을 표현해요. ‘지식 그래프’라는 용어가 특정한 하나의 저장 형식을 뜻하는 것은 아니에요.

스키마와 온톨로지: 공통 용어 체계

스키마는 모델에서 사용하는 개체와 관계의 유형을 정의해요. 우리의 독서 그래프에서는 다음을 허용할 수 있어요:

Person → wrote → Book
Book → discusses → Topic

온톨로지는 의미를 형식화하며, 유형 간의 추가적인 관계를 정의할 수도 있어요. Graphwise는 온톨로지를 의미에 관한 계약이라고 설명해요. 그래프 개발자와 소프트웨어를 포함한 사용자 사이의 계약이죠.

규모가 작은 노트 모음이라면 크고 정형화된 모델 대신 소수의 용어로 시작하세요. 각 관계가 무엇을 의미하는지 적어 두세요. discusses는 책이 어떤 주제를 상당한 비중으로 다룬다는 뜻인가요, 아니면 단순히 언급한다는 뜻인가요? 일관성이 있어야 이렇게 만들어진 연결의 의미를 파악할 수 있어요.

지식 그래프 사례: Google과 Wikidata

Google 지식 그래프

Google 지식 그래프는 검색 결과에 정보가 표시되기 때문에 익숙한 예시예요. IBM의 소개 글에서는 사람들이 검색한 내용을 바탕으로 정보를 제공한다고 설명하며, Freebase, Wikipedia, CIA World Factbook 등을 정보 출처로 명시해요.

단어와 그 단어가 가리키는 개체를 구분하는 것은 유용해요. IBM은 기업 Apple과 과일 사과를 예로 들어 스키마, 개체의 정체성, 맥락이 의미를 구분하는 데 어떻게 도움이 되는지 설명해요. 검색 시스템이 올바른 대상에 관한 정보를 반환하려면 이런 구분이 필요해요.

Wikidata

Wikidata는 Wikipedia와 연계된 개방형 지식 그래프예요. 이 글을 작성하는 시점을 기준으로 IBM의 개요 자료에 따르면, 300개 언어에 걸쳐 120 million개가 넘는 항목이 있어요.

개인 노트와는 규모가 크게 다르지만, 기본 개념은 익숙해요. 개체를 설명하고 그 설명들을 서로 연결하는 거예요. 하나의 주제는 독립된 항목으로서만 유용한 것이 아니에요. 그 주제의 연결 관계는 다른 항목에 맥락을 제공해요.

이 예시들이 그래프에 세상 전체를 담아야 한다는 뜻은 아니에요. 하나의 연구 질문이나 한 팀의 프로젝트를 다루는 그래프에도 같은 구성 요소를 활용할 수 있어요.

지식 그래프와 데이터베이스, 마인드맵, 벡터 저장소 비교

이 도구들은 겹치는 부분이 있지만, 정보를 정리하는 목적은 서로 달라요. 가장 유용한 비교 기준은 어떤 도구가 무조건 더 나은지가 아니라, 어떤 질문에 답하고 싶은지예요.

지식 그래프는 데이터베이스의 반대 개념이 아니에요

지식 그래프는 지식을 표현하는 방식을 뜻해요. 데이터베이스는 데이터를 저장하고 조회하는 기술이에요. 그래프 데이터베이스는 서로 연결된 데이터를 중심으로 설계되어 지식 그래프를 지원할 수 있어요.

관계형 데이터베이스도 관계를 표현해요. 차이는 “테이블로는 대상을 서로 연결할 수 없다”는 데 있는 게 아니라, 그 연결을 어떻게 모델링하고 탐색하느냐에 있어요. Esri는 그래프 데이터베이스가 명시적으로 저장된 관계에 초점을 맞춘다는 점을 강조해요. 특히 여러 연결을 거쳐야 하는 질문을 다룰 때 이런 점이 중요해요.

독서 상태를 간단히 관리하는 목록이라면 표만으로도 충분할 수 있어요. 궁금한 점을 따라 책에서 저자로, 저자에서 주제로, 다시 다른 책으로 반복해서 탐색하게 된다면 그래프 모델을 고려해 볼 만해요.

마인드맵은 개략적으로 표현하고, 지식 그래프는 관계를 명시해요

일반적인 마인드맵은 하나의 중심 아이디어에서 가지를 뻗어요. 지식 그래프는 서로 다른 관계 유형을 사용해 여러 가지에 걸쳐 있는 개체들을 연결할 수 있어요. “내 연구 계획의 일부”와 “이 사람이 작성함”이 서로 구별되지 않는 선으로 표현되어서는 안 돼요.

프로젝트에 어떤 개념을 포함할지 아직 고민 중이라면, 스케치부터 시작하는 게 좋을 수 있어요. 이런 계획 작업에는 노션용 마인드맵 제작 도구가 적합해요. 재사용할 수 있는 관계는 나중에 정의할 수 있어요.

벡터 유사도와 명시적 관계는 서로 다른 질문에 답해요

관련 있어 보이는 구절을 찾는 것과 기록된 연결을 찾는 것은 달라요. “도시 원예와 유사한 텍스트”와 “‘도시 원예’에 명시적으로 연결된 책”은 서로 다른 결과를 낼 수 있어요.

두 접근 방식은 함께 사용할 수 있어요. IBM은 검색을 위해 그래프 데이터를 벡터화하는 Wikidata 관련 구현 사례를 설명해요. 그래프가 유사도 검색을 대체해야 하는 것은 아니며, 유사도 검색이 모든 관계의 의미를 제공하는 것도 아니에요.

지식 그래프는 어떤 용도로 사용하나요?

검색 및 질의응답

지식 그래프는 검색 시스템이 단어뿐 아니라 개체와 맥락도 활용할 수 있게 해줘요. 앞서 든 독서 예시에서는 주제에서 책으로, 책에서 저자로 이어지는 연결을 따라가며 “어떤 저자들이 도시 원예를 다루나요?”라는 질문에 답할 수 있어요.

추천

IBM은 지식 그래프가 구매 행동을 기반으로 한 소매업의 상품 추천과 참여도를 기반으로 한 엔터테인먼트 콘텐츠 추천을 지원한다고 설명해요. 두 사례의 공통점은 서로 연결된 정보를 활용해 관련 항목을 찾아낸다는 거예요.

간단한 개인 활용 사례로는 공통 주제를 통한 연결을 활용해 ‘다음에 읽을 책’ 목록을 만드는 방법이 있어요. 추천 이유도 쉽게 이해할 수 있어요. 아직 읽지 않은 이 책이 이미 선택한 책들과 연결된 주제를 다루기 때문이에요.

데이터 통합

서로 다른 출처에서 같은 대상을 다르게 설명할 수 있어요. 그래프는 공통된 정체성과 어휘를 통해 이런 설명들을 연결할 수 있어요.

연구 노트에는 “Maya”, 독서 목록에는 “Maya — 저자”라고 적혀 있고, 인터뷰 페이지에서도 같은 사람을 언급한다고 생각해 보세요. 이 언급들이 같은 사람을 가리킨다는 것을 파악하면, 책과 인터뷰가 별개의 기록으로 남는 대신 한 사람을 통해 연결돼요.

RAG와 AI

검색 증강 생성(RAG)은 언어 모델에 검색한 맥락 정보를 제공해 질문에 답할 수 있도록 도와줘요. 그래프 기반 검색은 명시적인 관계를 활용해 이 맥락 정보를 구성할 수 있어요.

Brian Curry의 지식 그래프 가이드는 AI 애플리케이션에서 얻을 수 있는 이점으로 관계 순회와 추적 가능한 연결을 소개해요. 저희 GraphRAG 설명에서는 이러한 검색 패턴을 더 자세히 살펴봐요.

개인 지식 그래프: 내 노트에서 시작하기

개인 지식 그래프는 이러한 아이디어를 메모, 프로젝트, 독서 목록, 사람, 개념 등 여러분의 자료에 적용해요. 시작하는 데 기업용 데이터 파이프라인은 필요하지 않아요.

노션 워크스페이스에는 이미 그래프 구조가 있어요:

• 페이지는 노드예요.
• 멘션과 백링크는 참조를 통해 페이지를 연결해요.
• 데이터베이스 관계는 이름이 지정된 필드를 통해 레코드를 연결해요.
• 상위 페이지와의 관계는 계층 구조를 나타내요.

이 연결들이 모두 같은 의미를 담고 있는 것은 아니에요. 어떤 페이지에서 책을 언급했다고 해서 반드시 그 책을 추천하거나 요약하거나 프로젝트에 활용하는 것은 아니에요. 연결의 의미를 명확히 하려면 노션 데이터베이스 관계에 의미가 드러나는 이름을 붙이세요. 노션 백링크를 사용해 참조를 따라 이동한 다음, 주변 내용을 읽어 해당 참조가 있는 이유를 파악하세요.

Obsidian 보관함은 위키 링크로 노트를 연결해요. 여기서도 모델링에 관해 같은 질문을 던질 수 있어요. 링크가 단순히 어딘가를 가리키기만 하나요, 아니면 노트가 그 관계를 설명하나요? 노션과 Obsidian 비교에서는 두 환경 중 무엇을 선택할지 더 폭넓게 다뤄요.

여기서 알아두면 좋은 차이가 있어요. 서로 연결된 노트는 그래프를 이루고, 정형화된 지식 그래프는 여기에 명시적이고 일관된 의미 체계를 더해요. 연결된 노트로 시작해 점차 정형화된 지식 그래프를 강화해 나갈 수 있어요.

IVGraph는 기존 연결 관계를 살펴볼 수 있도록 노션 페이지, 백링크와 멘션, 데이터베이스 관계를 인터랙티브 3D 그래프로 보여줘요. 이 글 작성 시점에는 노드 500개까지 무료이며, 노션 로그인을 통한 읽기 전용 접근 권한을 사용해요.

시각화를 통해 구조를 살펴볼 수 있지만, 관계의 의미를 정의하는 작업까지 대신해 주지는 않아요. 워크스페이스 중심의 단계별 안내는 노션 지식 그래프 가이드를 참고하세요.

작은 지식 그래프를 만드는 방법

정말 답을 찾고 싶은 질문부터 시작해 보세요. “내가 아는 모든 것을 정리하기”는 검증하기 어려워요. “어떤 읽기 자료가 이 프로젝트에 참고가 될까?”라고 물으면 구체적인 목표가 생겨요.

1. 범위를 좁게 정해요. 읽기 목록 하나나 프로젝트 하나를 사용해요. 첫 버전에는 관련 없는 자료를 넣지 않아요.
2. 개체 유형에 이름을 붙여요. 이 예시에서는 프로젝트, 읽기 자료, 주제를 사용해요. 실제 개체마다 별도의 레코드나 노트를 만들어요.
3. 관계를 정의해요. Reading → informs → Project와 Reading → discusses → Topic을 사용해 보세요. 각각의 관계를 쉬운 영어로 정의해요.
4. 속성은 목적에 맞게 추가해요. 읽기 상태 같은 세부 정보는 읽기 자료에 담아둬요. 여러 읽기 자료를 연결해야 하는 주제는 별도의 개체로 만들어요.
5. 중복된 개체를 정리해요. “정원 연구”와 “정원 가꾸기 연구 프로젝트”가 같은 프로젝트를 가리키는지 판단해요. 이름이 비슷하다는 이유만으로 레코드를 합치지 않아요.
6. 맥락을 담아 연결을 추가해요. 읽기 자료가 프로젝트에 정보를 제공하는 이유를 기록해요. 중요한 주장을 뒷받침하는 구절이나 출처도 보관해요.
7. 처음의 질문을 검증해요. 프로젝트에서 시작해 연결된 읽기 자료를 따라간 다음, 각 자료의 주제를 살펴봐요. 모든 연결을 설명할 수 있나요?
8. 확장하기 전에 다듬어요. 의미가 모호한 관계의 이름을 바꾸고, 오류를 수정하고, 빠진 연결을 추가해요. 또 다른 유용한 질문에 답하기 위해 필요할 때 그래프를 확장해요.

자료를 더 추가하기 전에 이 간단한 품질 체크리스트를 활용하세요:

• 각 노드는 식별할 수 있는 대상을 나타내나요?
• 각 관계를 명확한 문장으로 읽을 수 있나요?
• 비슷한 관계에 일관된 이름을 붙였나요?
• 중요한 주장을 뒷받침하는 근거를 찾을 수 있나요?
• 연결을 따라가면 처음 던진 질문의 답을 얻을 수 있나요?

가장 큰 다이어그램을 만드는 것이 목표는 아니에요. 이해하고 신뢰하며 다시 활용할 수 있는 연결 관계를 구축하는 것이 목표예요.

자주 묻는 질문