온톨로지와 메모리 시스템 (10/13) — GraphDB는 어떤 문제를 해결하는가
온톨로지를 그렸다면, 이제 저장 방식이 문제다
지난 글에서 온톨로지는 "무엇이 무엇과 어떤 관계를 맺는가"를 정리하는 언어라고 설명했다. 사람, 프로젝트, 개념, 작업, 감정, 기록 같은 것들은 혼자 존재하지 않는다. 서로 연결되면서 의미가 생긴다.
문제는 여기서 시작된다. 머릿속에서는 분명히 연결되어 있는데, 막상 저장하려고 하면 대부분 폴더나 표 형태로 눌러 담게 된다. 사람/, 프로젝트/, 아이디어/ 폴더를 나누고, 노트 앱에서는 태그를 달고, 데이터베이스에서는 행과 열을 만든다. 처음에는 잘 정리된 것처럼 보인다. 그런데 연결이 많아질수록 이상한 느낌이 생긴다. 분명히 알고 있는 것을 찾기가 어려워지고, 관계를 설명하려면 같은 내용을 여러 곳에 반복해서 적어야 한다.
GraphDB는 바로 그 지점에서 등장한다. 이 도구는 "데이터를 많이 넣는 법"보다 "연결된 세계를 연결된 채로 저장하는 법"에 가깝다.
GraphDB는 데이터를 점과 선으로 다룬다
GraphDB를 이해하는 가장 쉬운 방법은 지하철 노선도를 떠올리는 것이다. 역만 따로 모아 둔다고 노선도가 되지 않는다. 어느 역이 어느 역과 연결되는지, 그 연결이 몇 호선인지, 환승인지, 급행이 서는지까지 함께 있어야 실제로 쓸 수 있다.
GraphDB에서는 보통 세 가지를 중심으로 생각한다.
첫째는 노드(node)다. 존재하는 대상을 뜻한다. 사람, 문서, 책, 개념, 회사, 프로젝트, 사건 같은 것이 노드가 된다. 쉽게 말해 "이 세계에 있는 것"이다.
둘째는 엣지(edge) 또는 관계선이다. 한 노드와 다른 노드를 잇는 선이다. 하지만 단순한 선이 아니다. "작성했다", "참고한다", "반박한다", "같은 프로젝트에 속한다", "영향을 받았다"처럼 의미가 담긴 연결이다.
셋째는 relationship다. 많은 설명에서 edge와 비슷하게 쓰이지만, 학습할 때는 "선의 존재"와 "선의 의미"를 구분해서 생각하면 이해가 쉬워진다. edge가 연결 자체라면, relationship는 그 연결이 왜 존재하는지 설명하는 이름표다. A -> B가 아니라 A가 B를 인용했다, A가 B를 담당한다, A가 B 이후에 일어났다처럼 읽히는 문장이 되는 것이다.
예를 들어 보자.
노드: "독서 메모", "프로젝트 X", "회의 기록", "김팀장"relationship: "참고한다", "파생되었다", "결정했다", "요청했다"
그러면 다음처럼 읽을 수 있다.
- 독서 메모가 프로젝트 X를 참고한다
- 회의 기록이 프로젝트 X의 방향에서 파생되었다
- 김팀장이 회의 기록의 결정을 요청했다
이 방식의 핵심은 "정보를 따로 저장한 뒤 사람이 머릿속에서 다시 엮는 것"이 아니라, 애초에 엮인 상태로 저장한다는 데 있다.
폴더는 왜 금방 답답해지는가
폴더 구조는 트리다. 부모 하나 아래에 자식이 내려가는 구조다. 이 방식은 "한 가지 기준으로 분류"할 때 강하다. 예를 들어 영수증을 연도별로 정리하거나, 사진을 여행별로 보관하거나, 계약서를 회사별로 모을 때는 폴더가 아주 효율적이다.
하지만 실제 지식은 한 부모만 갖고 살지 않는다. 하나의 메모가 동시에 여러 맥락에 걸친다. 어떤 회의 메모는 프로젝트 A에도 속하고 고객 B와도 관련 있고, 동시에 예산 문제, 채용 이슈, Q3 전략과도 연결된다. 폴더에 넣는 순간 질문이 생긴다. 이 메모를 어디에 둬야 하지?
복사해서 여러 폴더에 넣으면 동기화 문제가 생긴다. 한 파일만 수정했는데 나머지는 오래된 내용으로 남는다. 한 곳에만 두고 나머지는 링크로 적으면, 결국 링크를 적는 수고를 사람이 떠안게 된다. 결국 폴더는 "위치"는 잘 관리하지만 "관계"는 잘 관리하지 못한다.
Second Brain이 커질수록 중요한 것은 위치보다 맥락이다. 이 메모가 어디 저장되어 있는가보다, 무엇과 연결되어 있는가가 더 중요해진다.
테이블은 왜 설명은 잘하지만 연결은 불편한가
테이블은 폴더보다 한 단계 더 정교하다. 행과 열을 이용해 속성을 깔끔하게 정리할 수 있다. 문서명, 작성자, 작성일, 프로젝트, 상태 같은 정보는 표에서 매우 잘 다뤄진다.
문제는 관계가 다대다로 늘어날 때다. 한 문서가 여러 프로젝트와 연결되고, 한 프로젝트가 여러 사람과 연결되고, 한 사람이 여러 역할을 동시에 맡기 시작하면 표는 점점 보조 테이블을 늘려야 한다.
예를 들어 이런 식이다.
documentsprojectspeopledocument_project_linksproject_people_linksdocument_people_links
관계가 늘수록 표는 점점 "정리된 세계"가 아니라 "분해된 세계"가 된다. 데이터베이스 입장에서는 정확하지만, 사람이 사고하기에는 멀어진다. "김팀장이 관여했고, 전략 변경 이후에 생겼고, 이전 분기의 실패 기록을 참고한 문서"를 알고 싶은데, 이를 위해 여러 표를 조인하며 돌아다녀야 한다.
즉 테이블은 개체의 속성을 다루는 데 강하지만, 관계 자체가 1급 시민이 되는 순간 점점 번거로워진다. GraphDB는 바로 그 관계를 중앙으로 끌어올린다.
GraphDB가 실제로 해결하는 문제
GraphDB를 써야 하는 이유를 한 문장으로 줄이면 이렇다. "무엇이 있는지"보다 "무엇이 어떻게 연결되는지"가 더 중요한 문제를 풀기 위해서다.
예를 들어 개인 지식 관리에서는 이런 질문이 자주 생긴다.
"이 아이디어는 어디서 시작됐지?" "이 프로젝트에 영향을 준 사람과 문서는 무엇이지?" "내가 반복해서 참조하는 개념 묶음은 무엇이지?" "같은 문제를 다른 말로 적어 둔 노트는 없나?"
이런 질문은 단순 검색보다 관계 탐색에 가깝다. 키워드 하나를 찾는 것이 아니라, 연결 경로를 따라가며 맥락을 복원하는 작업이다. GraphDB는 이 경로 탐색을 자연스럽게 다룬다.
업무에서도 비슷하다. 고객사, 담당자, 이슈, 계약, 회의, 결정, 후속 작업이 얽혀 있는 상황을 생각해 보자. 표로도 저장할 수는 있다. 하지만 "이 결정이 왜 내려졌는가"를 추적하려면 결국 사람은 사건의 연결망을 복원해야 한다. GraphDB는 그 복원 과정을 별도 추론이 아니라 저장 구조 자체로 지원한다.
추천 시스템도 좋은 예다. "이 사용자가 이 영화를 봤으니 비슷한 영화를 추천하자" 수준을 넘어, "비슷한 감독", "같은 배우", "비슷한 취향의 다른 사용자", "최근 선호 장르 변화"를 함께 보려면 관계가 중심이 된다. 이런 문제에서 GraphDB는 단순 목록이 아니라 연결 패턴을 다룬다.
Second Brain 관점에서 보면 더 분명해진다
Second Brain을 단순한 노트 창고로 보면 폴더와 표만으로도 어느 정도 버틸 수 있다. 하지만 Second Brain을 "생각의 재료가 다시 만나 새로운 의미를 만드는 구조"로 보면 얘기가 달라진다.
메모 한 장의 가치는 그 메모 자체에만 있지 않다. 두 달 전 독서 메모가 오늘의 프로젝트 판단과 연결될 때 가치가 생기고, 예전 실패 기록이 현재 의사결정의 경고등이 될 때 가치가 생긴다. 결국 지식 시스템이 해야 할 일은 저장보다 재연결에 가깝다.
GraphDB는 이 재연결을 우연에 맡기지 않게 해 준다. "연결될 법한 것"을 사람이 계속 기억하고 있어야 하는 부담을 줄이고, 관계를 구조로 남긴다. 그래서 GraphDB는 저장 기술이라기보다 기억 보조 기술에 가깝다.
자주 생기는 오해
첫 번째 오해는 "GraphDB는 시각화 도구다"라는 생각이다. 물론 그래프 구조는 시각화와 잘 어울린다. 하지만 본질은 그림이 아니다. 본질은 저장과 질의의 단위가 관계 중심이라는 점이다. 예쁘게 보이는 연결망 그림은 결과물일 뿐, 핵심은 아니다.
두 번째 오해는 "모든 데이터를 GraphDB로 옮겨야 한다"는 생각이다. 그렇지 않다. 회계 장부, 주문 내역, 로그 집계처럼 정형 속성과 대량 집계가 중심인 데이터는 여전히 테이블이 더 적합한 경우가 많다. GraphDB는 만능 대체재가 아니라, 관계가 복잡한 영역에 특히 강한 도구다.
세 번째 오해는 "링크만 잘 걸면 GraphDB와 같다"는 생각이다. 일반 노트 앱에서도 문서끼리 링크를 걸 수 있다. 하지만 링크는 종종 문서 본문 속 텍스트에 묻혀 있고, 관계의 종류를 구조적으로 다루기 어렵다. "관련 있음" 정도는 표현할 수 있어도, "원인이다", "반박한다", "업데이트한다", "같은 사람의 다른 주장이다"처럼 관계 의미를 일관되게 쌓아 가기는 쉽지 않다.
네 번째 오해는 "GraphDB를 쓰면 자동으로 똑똑해진다"는 기대다. 그래프 구조는 온톨로지가 어느 정도 잡혀 있을수록 힘을 발휘한다. 무엇을 노드로 보고, 어떤 관계 이름을 쓸지, 어느 정도 단위로 쪼갤지를 생각하지 않으면 그래프도 결국 복잡한 낙서가 된다. 좋은 그래프는 좋은 분류와 좋은 관계 언어 위에 선다.
그래서 GraphDB는 어떤 순간에 필요해지는가
대개는 저장량이 많아져서가 아니라, 질문의 성격이 바뀔 때 필요해진다.
처음에는 "어디 있지?"를 묻는다. 이 단계에서는 폴더가 잘 먹힌다. 그다음에는 "무슨 속성이 있지?"를 묻는다. 이 단계에서는 테이블이 강하다. 하지만 어느 순간부터 "무엇과 왜 연결되지?"를 묻게 된다. 바로 그때 그래프적 사고가 필요해진다.
그래서 GraphDB를 이해한다는 것은 새로운 데이터베이스 제품 하나를 배우는 일이 아니다. 지식을 바라보는 중심을 파일에서 관계로, 항목에서 맥락으로 옮기는 일에 가깝다.
맺음말
온톨로지가 세상을 읽는 틀이라면, GraphDB는 그 틀을 무너지지 않게 저장하는 방식이다. 폴더는 깔끔하지만 한 줄로만 내려가고, 테이블은 정확하지만 연결을 분해한다. GraphDB는 그 사이에서 "관계를 잃지 않는 저장"을 목표로 한다.
Second Brain을 오래 운영할수록 중요한 것은 메모 수집량이 아니라, 서로 멀리 떨어진 생각들이 다시 만날 수 있느냐다. GraphDB는 그 재회를 구조적으로 돕는 도구다.
다음 글에서는 이렇게 저장된 관계 구조를 실제 질문과 작업 흐름 안으로 어떻게 끌어오는지, 그리고 그 지점에서 LangChain이 왜 필요한지를 이어서 살펴보겠다.
참고 자료
- graph database, knowledge graph, relationship modeling 기본 개념
- Neo4j를 포함한 그래프 데이터베이스 입문 자료 전반
시리즈 전체 안내: 시리즈 목차
댓글
댓글 쓰기