LLM Wiki로 블로그 챗봇 구현하기
2026년 7월 29일
최근 블로그 글과 제가 작성한 정보들을 바탕으로 질문에 답하는 LLM 기반 챗봇을 만들어보려고 했습니다. 처음에는 블로그 글과 정보를 임베딩하여 벡터 DB에 저장하고, 사용자의 질문을 기반으로 관련 문서를 검색하는 일반적인 RAG 방식으로 구현했습니다.
하지만 실제로 가지고 있는 데이터의 양과 특성을 생각해보니 벡터 DB와 임베딩을 사용하는 것이 오히려 과한 설계라는 생각이 들었습니다. 제가 가진 정보는 수많은 문서가 대규모로 쌓여 있는 데이터가 아니라, 블로그에 작성한 비교적 적은 수의 글과 그 안에 담긴 개인적인 경험과 생각들이었습니다. 그렇다면 굳이 문서를 임베딩하고 유사도를 계산하지 않고, LLM이 문서 구조를 직접 탐색하도록 만들 수 있지 않을까라는 생각이 들었습니다.
이런 방법을 찾던 중 LLM Wiki라는 개념을 알게 되었습니다. LLM Wiki는 지식을 단순히 검색 대상으로 만드는 대신 LLM이 위키의 문서와 구조를 탐색하면서 필요한 정보를 스스로 찾아가는 방식으로 지식을 구성합니다.
이번 글에서는 이러한 LLM Wiki의 접근 방식이 기존 RAG와 어떤 차이가 있는지 살펴보고, 이를 바탕으로 제가 블로그 챗봇을 어떻게 구현했는지 정리하고자 합니다.
LLM Wiki가 무엇인가?
LLM은 학습 시점 이후의 정보나 모델의 파라미터에 충분히 반영되지 않은 외부 지식에 대해 정확한 답변을 제공하기 어렵습니다. 이를 보완하기 위해 외부 지식을 검색하여 LLM의 컨텍스트로 제공하는 RAG가 활용됩니다. 기존의 많은 RAG 시스템은 외부 문서를 청크로 분할하고 임베딩한 뒤, 벡터 유사도를 기반으로 관련 정보를 검색하는 방식에 의존했습니다. 하지만 이러한 방식은 검색 문제를 주로 의미적 유사도 매칭 문제로 다루기 때문에 단일 홉의 정보 검색에는 효과적이지만 여러 엔티티 간의 관계를 추적하거나 속성을 비교하고 여러 문서에 흩어진 정보를 연결해야 하는 복잡한 다중 홉 질문에는 한계가 있습니다.
홉(hop)이란 정보를 얻기 위해 거쳐가는 관계의 수를 의미합니다.
그래서 LLM Wiki는 검색을 단순한 정보 매칭이 아니라 추론 과정으로 다루는 접근을 구체화한 개념입니다. 구조화된 지식 공간을 탐색하고 문서를 읽은 뒤, 현재까지 얻은 정보가 답변에 충분한지 스스로 판단합니다. 정보가 부족하다면 다시 관련 문서를 탐색하고 읽는 과정을 반복하며 필요한 근거를 구성합니다. 쉽게 말하면 디렉토리 안의 문서들을 스스로 탐색하면서 알맞은 정보를 찾아 읽고, 필요한 정보가 더 있다면 다시 다른 문서를 찾아가는 것입니다.
이를 통해 하나의 문서에서 정보를 찾는 것을 넘어 여러 문서에 흩어진 정보를 연결하거나 문서 간의 관계를 추적해야 하는 질문에도 대응할 수 있습니다. 이러한 방식은 제가 만들고자 했던 챗봇에 적합했습니다. 제 경험이나 목표에 대한 정보가 여러 주제의 글에 흩어져 있기 때문에 단순히 특정 경험이나 목표가 있는지를 묻는 질문뿐만 아니라 여러 글과 정보들을 조합해야 답할 수 있는 질문도 처리해야 하기 때문입니다.
어떻게 구현할까?
이론을 실제 서비스에 적용하기 위해, 먼저 블로그의 글과 정보를 에이전트가 탐색하기 쉬운 형태로 재구성했습니다. 단순히 문서를 검색하는 것이 아니라, 문서 자체에 구조와 관계를 부여하고 LLM이 이를 따라가며 필요한 정보를 찾도록 하는 것이 핵심입니다.
데이터 구조화
모든 글은 마크다운으로 관리하고, 각 문서에 메타데이터와 문서 간 링크를 추가했습니다.
문서의 메타데이터에는 글에 대한 설명과 관련된 주제를 태그로 추가했습니다. 또한 글의 내용과 관련된 다른 글은 링크로 연결하여 문서 간의 관계를 명시했습니다. 그리고 모든 글의 제목과 링크를 index.md에 정리했습니다. index.md는 에이전트가 전체 지식 공간을 탐색하기 위한 시작점 역할을 합니다.
이렇게 문서를 구성함으로써 에이전트는 단순히 본문 내용의 유사도를 기준으로 문서를 찾는 것이 아니라, 문서의 메타데이터와 링크, 디렉토리 구조를 이용해 어떤 문서를 탐색할지 결정할 수 있습니다.
Search와 Read 도구
이러한 지식 구조를 탐색하기 위해 두 가지 도구가 필요합니다.
search:index.md나 태그를 검색해 후보 문서를 식별합니다. 단순 본문 검색 이전에 구조화된 신호를 먼저 봅니다.read: 선택된 문서의 본문과 메타데이터를 읽습니다. 이때 문서 내 포함된 다른 링크 정보를 수집하여 다음 탐색의 후보군으로 삼습니다.
위 두 가지 도구를 활용하여 질문 -> 검색 -> 문서 -> 답변을 하는 것이 아니라 질문 -> search -> read -> 정보 확인 -> 추가적인 search&read -> 답변을 하게 됩니다.
LangGraph를 이용한 탐색 과정
이 탐색 과정은 LangGraph를 사용하여 구현했습니다. 에이전트는 먼저 질문을 분석하고 search를 통해 관련 문서를 찾습니다. 이후 read를 통해 문서의 내용을 확인하고, 현재까지 수집한 정보만으로 질문에 답할 수 있는지 판단합니다.
정보가 충분하다면 탐색을 종료하고 답변을 생성합니다. 반대로 정보가 부족하다면 현재 읽은 문서에서 발견한 링크나 관련 정보를 바탕으로 다시 search 또는 read를 수행합니다. 이 과정을 반복하면서 답변에 필요한 정보를 하나씩 수집합니다. 다만 LLM이 계속해서 도구를 호출하는 것을 방지하기 위해 최대 도구 호출 횟수를 설정하고, 해당 횟수에 도달하면 탐색을 종료하도록 했습니다.
이 과정에서 중요한 것은 복잡한 검색 알고리즘을 별도로 구현하는 것이 아니라 마크다운 문서에 메타데이터와 링크를 부여하여 LLM이 탐색할 수 있는 지식 공간을 만들고, LangGraph를 통해 필요한 정보를 찾을 때까지 탐색하도록 한 것**입니다.
마치며
이번에 블로그 챗봇을 구현하면서 느낀 점은 LLM 서비스를 만든다고 해서 항상 복잡한 검색 기술이 필요한 것은 아니라는 것이었습니다.
처음에는 블로그의 글과 정보를 벡터 DB에 저장하고 임베딩 유사도를 기반으로 검색하는 일반적인 RAG 구조를 선택했습니다. 하지만 데이터의 규모와 특성을 다시 살펴보면서 현재 필요한 것은 많은 데이터를 빠르게 검색하는 시스템보다 LLM이 필요한 정보를 스스로 찾아갈 수 있는 구조가 답변의 정확도가 올라갈 것이라 판단했습니다.
이번 구현을 통해 단순히 LLM에게 더 많은 데이터를 제공하는 것보다 LLM이 데이터를 어떻게 찾아가고 어떤 정보를 연결할 수 있도록 만들 것인가가 중요하다는 점을 확인할 수 있었습니다. 앞으로도 LLM 서비스를 구현할 때 새로운 기술을 무조건 추가하기보다는 해결하려는 문제에 필요한 만큼의 구조를 설계하는 것을 우선해야겠다는 생각이 들었습니다.
마지막으로 챗봇이 궁금하신 분은 아래 메일로 연락주세요. 2주간 유효한 채팅방을 생성해드립니다. E-Mail: keepmhwn@gmail.com