요약: GraphRAG와 LLM Wiki 모두 LLM을 사용하여 원시 데이터를 '증류(distill)'하며, 이 과정에서 잘못된 요약, 오래된 지식, 출처 손실, 그리고 평가의 어려움 등 유사한 문제에 직면합니다. 증류 계층이 얼마나 두꺼워야 하는지에 대한 명확한 답을 찾지 못했습니다. 만약 작게 시작한다면 LLM Wiki를 추천합니다.
저는 지속적으로 성장하는 지식 기반을 구축하는 방법을 알아내야 했기 때문에, 다시 깊이 파고들어 정리해 보았습니다. 기존 제품, 주요 방법론, 최신 논문들을 광범위하게 검색했고, AI와 대화하며 이해도를 높였습니다.
LLM 지식 기반에 대해 생각할 때, 두 가지 계열을 떠올립니다: GraphRAG와 LLM Wiki입니다. 저는 이 둘 모두를 깊이 파고들었고, 예상보다 더 많은 공통점을 발견하여 이 노트를 남기게 되었습니다. 순서는 다음과 같습니다: GraphRAG 계열, LLM Wiki 계열, 두 가지가 공유하는 문제점, 그리고 어떤 것을 선택해야 할지 설명하겠습니다.
제가 이해한 바는 다음과 같습니다.
- GraphRAG와 LLM Wiki 모두 LLM을 사용하여 원시 데이터를 '증류'하여 지식의 상위 레벨 표현(higher-level representation)을 구축합니다. 차이점은 증류되는 것의 구조입니다: 엔티티, 관계 엣지, 커뮤니티로 구성된 그래프인지, 아니면 디렉터리, 인덱스 페이지, 문서 간 링크로 구성된 위키인지를 다릅니다.
- 두 방식 모두 유사한 문제에 직면합니다: 생성된 지식의 오류, 시간이 지나면서 오래되는 지식(stale knowledge), 출처 추적 상실, 그리고 특정 사용 사례를 위한 평가의 어려움입니다 (자세한 내용은 아래 '공유 문제점' 참조). 특히 증류 계층이 얼마나 두껍거나 얇아야 하는지(원시 데이터에 얼마나 되돌아가야 하는지?)가 궁금했지만 명확한 답을 찾을 수 없었습니다.
GraphRAG 계열: 먼저 요약을 구축하여 전체를 볼 수 있게 한다
2023년: Vector RAG. 문서를 청크(chunks)로 분할하고 질문과 의미가 가장 유사한 것을 검색합니다. 이는 광범위하게 확산되었습니다. 하지만 약점도 드러났는데, 예를 들어 고유 명사나 코드 처리에 어려움을 겪습니다. 이를 기존의 키워드 검색과 결합하는 하이브리드 검색(Hybrid Search)이 일반화되었습니다.
2024년 4월: GraphRAG. Microsoft Research의 논문 "From Local to Global". Vector RAG는 "이 문서 세트의 주요 주제는 무엇인가?"와 같이 전체에 대한 질문에는 취약했습니다. GraphRAG는 LLM을 사용하여 원시 데이터에서 엔티티(entities)와 관계(relations)를 추출하고, 그래프(Graph)를 구축하며, 이를 커뮤니티(strongly related groups, 강하게 관련된 그룹)로 분할하고 미리 요약을 작성합니다. 이를 통해 전체에 대한 질문에 답변할 수 있게 되었습니다.
2024년 10월: LightRAG. 홍콩대학교(University of Hong Kong)의 HKUDS 그룹에서 발표한 논문입니다. 이 논문은 AI 및 NLP 분야의 최고 컨퍼런스인 EMNLP 2025의 Findings에 채택되었습니다. 기존 RAG는 데이터를 평면적인 텍스트(flat text)로 취급하여 문맥을 포착하는 데 어려움을 겪습니다. LightRAG는 인덱싱 및 검색 과정에 그래프(Graph)를 도입하고, 이를 벡터 검색과 결합하며, 개별 사실(individual facts)과 전체 주제(overall topics)의 두 가지 수준에서 정보를 검색합니다. 또한 증분 업데이트(incremental updates)를 지원하여 새로운 데이터가 도착해도 모든 것을 재구축할 필요가 없습니다.
2024년 11월: LazyGraphRAG. Microsoft에서 나온 개선된 버전입니다. GraphRAG는 엔티티와 관계를 추출하기 위해 LLM을 많이 사용하므로 인덱스 구축 비용이 비쌌습니다. LazyGraphRAG는 LLM의 사용을 질의(query) 시점까지 지연시키고, 인덱스는 명사구(noun phrases) 추출과 같은 가벼운 작업만 수행합니다. Microsoft 블로그에 따르면, 인덱싱 비용은 Vector RAG와 동일하며, 전체 GraphRAG의 0.1% 수준입니다 (자체 보고 수치).
2026년 1월: Relink. 최고 AI 컨퍼런스인 AAAI에 채택된 논문입니다.
이전 방법들은 그래프(Graph)가 정적이고, 불완전하며, 관련 없는 사실들(노이즈)과 혼재되어 있다는 점을 비판했습니다. 이 연구는 추론하는 과정에서 질문에 필요한 부분의 그래프만 실시간으로 구축할 것을 제안합니다. 누락된 사실은 원문 텍스트에서 채우고, 도움이 되지 않는 사실은 버립니다. 이 연구는 더 얇게 정제된(thinner distilled layer) 계층을 지향하고 있음을 보여줍니다.
검색 자체도 변화했습니다. 2025년~2026년경부터 에이전트적 검색(Agentic Search)이 확산되었습니다. 한 번 검색하는 대신, 에이전트가 검색-읽기-사고-다시 검색하는 과정을 반복합니다. 이것은 GraphRAG의 진화라기보다는, 검색을 다단계(multi-step)로 만드는 것에 관한 것이며, 그 밑단의 검색 방식은 일반적인 grep, 하이브리드 검색(Hybrid Search), 또는 GraphRAG가 될 수 있습니다.
그렇다면 밑단에 있는 검색이 반드시 GraphRAG여야 할까요? 실제로 이를 평가한 논문이 있습니다: "Do We Still Need GraphRAG?" (2026년 4월). 이는 심사되지 않은 arXiv 논문이며 인용 횟수가 적지만, 내용이 흥미롭고 평가가 재현 가능해 보여 공유하고 싶습니다. 이 논문은 GraphRAG와 일반 RAG 모두에 대해 에이전트적 검색을 실행하고 비교합니다. 격차는 많이 줄어들지만, 복잡한 다단계 추론(단일 검색으로 답변할 수 없고, 첫 번째 결과를 두 번째 및 세 번째 관련 문서 연결의 키로 사용하는 질문)의 경우 GraphRAG가 우위를 유지한다는 것이 결론이었습니다.
LLM 위키 패밀리: 인간이 읽을 수 있는 위키를 LLM이 성장시키게 하라
- 2026년 4월: LLM Wiki. Andrej Karpathy가 GitHub Gist에서 제안한 아이디어(https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). LLM이 원시 데이터(raw data)를 읽고, 인간과 에이전트 모두가 읽을 수 있는 Markdown Wiki를 구축하며 지속적으로 성장시키는 방식이다. 이 시스템은 세 개의 계층으로 구성된다: 절대 재작성되지 않는 원시 데이터, LLM이 관리하는 Wiki, 그리고 규칙이 담긴 파일(예: CLAUDE.md 또는 AGENTS.md). 작동 방식은 세 가지가 있다: 데이터 수집(ingest), 질의응답(query), 전체 검토(lint)이다. 이는 모든 질문마다 원시 데이터에서 지식을 재발견하는 일반적인 RAG(Retrieval-Augmented Generation)의 대안으로 제시되었다. GraphRAG 이후에 등장했지만, 해당 Gist에서는 GraphRAG를 언급하지 않는다.
- 2026년 6월: Google의 Open Knowledge Format (OKF) v0.1. 이 포맷은 LLM Wiki 패턴을 여러 도구가 교환할 수 있는 표준 형식으로 정립했다. Google Cloud 블로그에 따르면, 출발점은 AI 에이전트가 필요로 하는 컨텍스트가 메타데이터 카탈로그, Wiki, 공유 드라이브 등 여러 곳에 흩어져 있고 각기 다른 형식을 가지고 있다는 것이었다. 이 포맷은 간단하다. 하나의 개념(concept)은 하나의 Markdown 파일이며, 상단의 YAML(프론트매터, frontmatter)이 유형(type), 제목(title), 설명(description), 리소스(resource), 태그(tags), 타임스탬프를 담고 있다. 오직 '유형'만 필수적이다. 개념들은 일반적인 Markdown 링크로 서로 연결되어 전체가 그래프(Graph)를 형성한다. 이는 LLM Wiki의
이 숫자가 의도된 방식으로 생성되었는지(증명/attestation)? 구체적으로는 다음과 같습니다: 출처(원래 자료, 작성자 및 사용 횟수 같은 객관적 신호 포함), 생성 및 검증(누가 만들었는지와 누가 확인했는지를 분리), 상태(초안, 안정화됨, 폐기됨), stale_after(이 날짜 이후로 개념이 오래된 것으로 간주함), 그리고 Attested Computation이라는 유형을 사용하는데, 이는 특정 계산이 실제로 실행되었음을 기계적으로 확인합니다. 그들은 의도적으로 신뢰 점수를 추가하지 않았습니다. 블로그에 따르면 점수는 주관적이며 소비자마다 다르고 작성되는 순간 이미 구식이 됩니다.
공통 문제: 정제(distill)할수록 둘 다 같은 벽에 부딪힌다
두 계열 모두 메타데이터를 추가하여 다음의 문제를 해결하려고 합니다. 위에서 언급하지 않았지만, GraphRAG 역시 노드와 엣지에 메타데이터를 추가합니다. 예를 들어, Microsoft의 GraphRAG는 모든 관계(edge)에 해당 관계가 나온 텍스트 청크에 대한 참조(text_unit_ids)를 제공합니다. 또한 그 주장은 신뢰도(status)와 기간(start_date, end_date)을 가집니다 (공식 문서). LightRAG 역시 엔티티와 관계를 원래 청크 및 파일에 연결하며 2025년 3월에 인용(citation) 지원을 추가했습니다.
- 생성된 요약이나 지식이 틀리다.
- 시간이 지나면 구식이 된다. 업데이트와 차이점 반영이 어렵다.
- 출처나 증거를 추적할 수 없다.
다른 문제들도 있습니다.
- 원래 데이터의 미세한 부분이 손실된다.
- 사전 처리가 비용이 많이 든다.
- 구축할 때 미래에 어떤 정보가 필요할지 알 수 없다.
- 특정 사용 사례를 위해 평가하기 어렵다.
최악인 것은 실수가 지속된다는 것입니다. 만약 정제된 계층에 잘못된 데이터가 포함되어 있다면, 이후 검색할 때마다 그 오류가 사실로 사용됩니다.
어떤 것을 선택해야 할까: 작게 시작한다면 LLM 위키를 추천한다
그렇다면 무엇을 선택해야 할까요? 계속 조사하면서 저만의 기준을 찾았습니다.
먼저, 데이터의 규모가 있습니다. 저는 LLM Wiki는 품질과 비용 면에서 불안정해질 수 있다고 생각합니다. 왜냐하면 전체 위키를 일관되게 유지하는 작업은 문서 수가 늘어날수록 증가하기 때문입니다. Karpathy 자신도 약 100개의 소스 및 수백 페이지 정도에서는 잘 작동하지만, 더 커지면 적절한 검색 기능을 추가해야 한다고 언급했습니다. 다음으로, 개선 사항을 반복적으로 적용하기 쉬운 정도가 있습니다. 위키는 Markdown 형식이라 사람들이 읽고 수정할 수 있습니다. 그리고 복잡성입니다. GraphRAG는 인덱스 구축과 데이터 표현까지 포함하여 복잡합니다.
목표가 작게 시작하고 개선 루프를 실행하는 것이라면, 저는 LLM Wiki 계열이 이점을 가진다고 생각합니다. 데이터가 크고 관계가 복잡할 때는 GraphRAG를 고려해야 할 것 같습니다.
하지만 개선 루프에는 인간의 검토가 필요합니다. 저도 직접 LLM Wiki를 운영해봤는데, 제가 검토하는 내용을 핵심만 줄여도 따라가기 어렵습니다. 게다가 프롬프트를 더 높은 정보 밀도로 조정하면 콘텐츠를 이해할 수 없게 됩니다. 결국 질문에 답하기보다는 지시만 내리는 상사처럼 되어버립니다.
또 흥미로운 점이 하나 있습니다. 2026년 8월, OSS RAG인 RAGFlow(GitHub 스타 약 93,000개; Dify는 2026년 10월 기준 약 159,000개)가 지식 컴파일레이션 (Knowledge Compilation)이라는 기능을 출시했습니다. 이 기능은 원시 데이터로부터 트리(Tree)와 마인드맵(Mindmap)을 포함하여 그래프(Graph)와 위키(Wiki) 외의 다양한 형태로 정제된 데이터를 구축할 수 있습니다.
이것을 보면서, 정제된 레이어의 형태를 결합하고 전환하는 비용을 낮추는 기술 역시 중요할 수도 있겠다는 생각이 들었습니다.
원문은 my blog에 게시되었습니다.