최근 AI 커뮤니티에서 가장 자주 회자되는 키워드 중 하나가 안드레 카파시(Andrej Karpathy)가 던진 ‘LLM Wiki’다. 사람이 정보를 일일이 분류하고 링크를 거는 전통적인 PKM(개인 지식 관리)이 점점 한계를 드러내고, AI가 스스로 문서를 읽고 구조화하며 지식 베이스를 키워나가는 방향으로 무게중심이 옮겨가고 있다는 이야기다.
여기에 n8n 같은 노드 기반 자동화 파이프라인을 결합해 조건 검색과 AI 분석을 자동화하는 실험들도 활발하다. 이런 흐름을 바라보다 문득 한 가지 질문이 떠올랐다. “텍스트 위키 + 자동화 파이프라인” 만으로 금융 시장처럼 복잡한 도메인의 2차·3차 전이 영향을 제대로 추적할 수 있을까?
이 글은 어떤 제품을 출시하겠다는 선언이 아니다. 그저 “이런 시각도 가능하지 않을까?” 라는 아이디에이션 차원의 메모에 가깝다. LLM Wiki와 그래프 DB라는 서로 다른 두 흐름을 한 화면 위에 올려놓고 보면 어떤 그림이 그려지는지를 적어보았다.
텍스트 위키가 잘 못하는 일
Obsidian이나 마크다운 기반 LLM 위키는 사람이 읽고 탐색하기에 더할 나위 없이 좋은 UX를 제공한다. 노트 사이를 자유롭게 이동하고, 그래프 뷰로 전체 맥락을 한눈에 보는 경험은 분명한 매력이다.
그런데 시장이라는 도메인은 본질적으로 거미줄처럼 얽힌 엔터티의 집합이다. 종목, 섹터, 테마, 거시 지표가 서로 영향을 주고받고, 한 사건의 파급 효과는 1차에서 끝나지 않는다. 어떤 부품 공급망에 병목이 생기면 그 영향이 2단계, 3단계 떨어진 기업의 마진에까지 시계열로 번진다. 이런 연쇄 반응을 단순한 텍스트 링크와 LLM 요약만으로 안정적으로 계산하기는 쉽지 않다.
또 하나의 약점은 환각(Hallucination)이다. LLM이 생성한 관계가 위키 안에 자연스럽게 녹아 들어가면 사람 입장에서는 진짜인지 가짜인지 구분하기가 점점 어려워진다. 검증되지 않은 관계가 누적될수록 위키 자체의 신뢰도가 흔들린다.
그래프 DB로 한 발 더 들어가 본다면
그래서 한 번 가정해본 그림은 이렇다. 지식의 표층은 여전히 위키 형태로 두되, 그 아래에 Neo4j 같은 그래프 DB를 시스템 오브 레코드(System of Record)로 깔아두는 구조다. 모든 관계는 정해진 온톨로지 규칙을 통과해야 그래프에 적재되고, 관계마다 유효 시점(validAt)과 신뢰도 점수(confidence)가 함께 기록된다.
이렇게 되면 몇 가지 일이 가능해진다.
- 특정 시점 기준으로 “그 당시 우리는 무엇을 알고 있었는가” 라는 스냅샷 질의가 가능해진다.
- 한 이벤트의 K-hop 전이 경로를 그래프 알고리즘으로 명시적으로 계산할 수 있다.
- 신뢰도 임계값 미만인 관계는 자동으로 검수 큐로 보내 환각 누적을 통제할 수 있다.
- 온톨로지에 정의되지 않은 라벨/관계 타입은 입력 단계에서 거부되어 데이터 품질이 일정하게 유지된다.
요점은 그래프 DB가 만능이라는 것이 아니라, “읽기 좋은 위키”와 “계산 가능한 그래프”가 서로 다른 문제를 푼다는 것이다. 양쪽을 굳이 하나로 합치지 않고, 각자 잘하는 영역을 분담시키는 쪽이 현실적이다.
발굴 · 계산 · 설명, 세 레이어로 쪼개보면
이 그림을 조금 더 구체적으로 그려보면, 시스템을 세 개의 레이어로 나누는 발상에 도달한다. 각 레이어가 다른 도구와 짝을 이룬다고 가정하면 다음과 같다.
| 레이어 | 역할 | 대표 도구 | 출력 |
|---|---|---|---|
| 발굴 | 외부 데이터/뉴스/지표 수집과 1차 필터링 | n8n 류의 노드형 파이프라인 | 날것의 후보 데이터 |
| 계산 | 수집 데이터를 그래프에 적재하고 전이 경로 계산 | Neo4j + 온톨로지 | 구조화된 관계와 영향도 |
| 설명 | 그래프 결과를 사람이 읽기 쉬운 형태로 풀어줌 | LLM + Obsidian 류 위키 UX | 리서치 노트, 브리핑 |
이렇게 보면 LLM Wiki와 그래프 DB는 경쟁 관계가 아니라, 같은 워크플로의 다른 위치를 맡는 도구가 된다. 발굴이 부실하면 계산할 재료가 없고, 계산이 빈약하면 설명이 공허해진다. 반대로 설명 레이어가 약하면 아무리 좋은 그래프 결과도 사용자에게 닿지 못한다.
상상해본 어떤 하루의 워크플로
이런 구조가 실제로 동작한다면 사용자의 하루는 어떻게 흘러갈까. 어디까지나 사고 실험이지만, 대략 이런 시나리오가 가능하지 않을까 싶다.
- 오후 4시 — 자동 발굴: 장 마감과 함께 파이프라인이 돌아 사전에 정의한 조건(예: 박스권 돌파 + 외인 매수 전환)을 만족하는 후보군을 수집한다.
- 오후 5시 — 그래프 계산: 발굴된 종목의 공급망과 테마 연관성을 추적해, 거시 변수와 어떻게 연결되는지를 K-hop 단위로 계산한다.
- 오후 8시 — 입체적 탐색: 사용자는 잘 정돈된 마크다운 리포트를 읽다가 특정 키워드를 클릭한다. 그 순간 옆 패널의 그래프 뷰가 움직이며 관계가 시각적으로 펼쳐진다.
- 오후 9시 — 자연어 질의: “특정 거시 변수가 급등했을 때 이 종목 마진이 어떻게 반응했는지” 같은 질문을, 텍스트가 아닌 그래프에 누적된 시계열 위에서 바로 묻고 답을 받는다.
핵심은 사용자가 보는 인터페이스가 여전히 “위키처럼 부드럽다”는 것이다. 무거운 그래프 질의나 시계열 계산은 뒤에서 조용히 돌고, 표면에 드러나는 것은 사람 친화적인 노트와 링크다.
이 시각이 답이라기보다는, 하나의 보기
물론 이 그림이 정답은 아니다. 그래프 DB를 들여놓는 순간 운영 비용이 올라가고, 온톨로지 설계라는 만만치 않은 숙제가 생긴다. 잘못 설계하면 데이터는 쌓이는데 사용자가 손에 잡히는 가치를 못 느끼는 “차가운 그래프”가 되기 쉽다. 반대로 LLM Wiki만으로도 충분한 도메인이 분명히 있다.
다만 시장처럼 관계와 시계열이 본질인 도메인에서는, “위키냐 그래프냐”의 양자택일보다 둘을 한 워크플로 안에서 분담시키는 시각이 의외로 자연스럽게 들어맞는다는 점은 짚어둘 만하다. LLM Wiki 흐름을 흥미롭게 보고 있던 분이라면, 그 옆자리에 그래프 DB를 한 번쯤 같이 올려놓고 그림을 다시 그려보는 것도 재미있는 사고 실험이 될 것 같다.
결국 어떤 도구를 쓰느냐보다, 어떤 문제를 어떤 층위에서 풀려고 하는가가 먼저다. 이 글이 그 층위를 한 번 다시 바라보는 작은 계기가 되었으면 한다.