RAG의 한계를 넘는 'LLM Wiki' 전략: 검색을 추론으로 전환하는 방법

최근 LLM 기반 서비스의 표준으로 자리 잡은 RAG(Retrieval-Augmented Generation)는 구현이 쉽고 효율적이지만, 근본적인 구조적 한계를 가지고 있습니다. 바로 문서를 임의의 길이로 자르는 '청킹(Chunking)' 과정에서 지식 간의 유기적인 맥락과 관계가 완전히 단절된다는 점입니다.

전형적인 RAG는 사용자의 질문과 벡터 유사도가 높은 조각 몇 개를 가져와 컨텍스트에 붙입니다. 하지만 "A 문서의 조건과 B 문서의 제약 사항을 조합해 C라는 결론을 도출하라"는 식의 멀티홉(Multi-hop) 질문이 들어오면, 시스템은 필요한 조각들을 모두 가져오지 못하거나, 가져왔더라도 조각들 사이의 논리적 연결 고리를 찾지 못해 엉뚱한 답을 내놓기 일쑤입니다. 이는 벡터 검색이 '의미적 유사성'에만 의존하고 '논리적 연결성'을 고려하지 않기 때문입니다.

이번에 소개할 'LLM Wiki' 접근법은 검색을 단순한 '조각 찾기'가 아니라, 구조화된 지식 그래프를 능동적으로 탐색하는 '추론 과정'으로 재정의합니다. 이는 데이터를 파편화하는 대신, 서로 연결된 마크다운 위키 형태로 지식을 축적하고 에이전트가 이를 네비게이션하게 만드는 전략입니다. 단순한 데이터베이스 조회가 아니라, 지식의 지도 위에서 최적의 경로를 찾아가는 과정으로의 전환을 의미합니다.

핵심 주장과 근거

이 방식의 핵심은 데이터를 벡터 데이터베이스에 흩뿌리는 것이 아니라, 인간이 위키피디아를 읽듯 상호 연결된 마크다운 페이지(Linked Markdown Pages) 형태로 구축하는 것입니다. 에이전트는 단순히 검색 결과 상위 K개를 읽는 수동적 존재가 아니라, 페이지 내의 링크를 따라가며 필요한 정보를 스스로 찾아 나서는 능동적 탐색자가 됩니다.

논문(arXiv:2605.25480)에서 제시하는 주요 메커니즘과 그 근거는 다음과 같습니다.

1. 지식의 컴파일 (Compilation)

단순히 텍스트를 저장하는 것이 아니라, 원본 문서를 양방향 링크가 포함된 위키 페이지로 변환합니다. 이 과정에서 단순한 텍스트 추출을 넘어, 문서 간의 논리적 위계와 참조 관계를 명시적으로 정의합니다. 이렇게 하면 검색의 최소 단위가 의미 없는 '청크'가 아니라, 논리적 완결성을 가진 '페이지'가 됩니다. 페이지 간의 링크는 지식의 관계망을 형성하며, 이는 LLM이 정보의 맥락을 추적하는 이정표 역할을 합니다. 이는 기존 RAG가 겪던 '맥락 단절' 문제를 구조적으로 해결하는 장치가 됩니다.

2. 표준 도구셋의 정의

에이전트가 지식 베이스를 효율적으로 탐색할 수 있도록 세 가지 명확한 도구를 부여합니다.

• Search (검색): 위키 내에서 관련 키워드나 주제가 포함된 페이지를 찾습니다. 초기 진입점을 찾는 용도입니다.
• Read (읽기): 특정 페이지의 전체 내용을 읽어 상세 정보를 파악합니다. 현재 위치한 페이지의 지식을 흡수하는 과정입니다.
• Link (링크 따라가기): 페이지 내에 명시된 링크를 따라 관련 페이지로 이동합니다. 이것이 바로 '추론으로서의 검색'을 가능케 하는 핵심 기제입니다.

3. 자기 교정 메커니즘 (Error Book)

위키 구조를 생성하다 보면 LLM의 특성상 링크가 잘못 걸리거나 의미적 모순이 발생할 수 있습니다. 이를 해결하기 위해 'Error Book'이라는 개념을 도입합니다. 에이전트가 탐색 중 발견한 구조적 오류나 내용적 불일치를 스스로 기록하고, 이를 기반으로 위키 구조를 지속적으로 수정하게 함으로써 지식 베이스의 품질을 점진적으로 높입니다. 이는 정적인 DB와 달리 지식 베이스 자체가 스스로 진화하는 피드백 루프를 갖게 됨을 의미합니다.

벤치마크 성능 분석 (논문 주장치)

논문은 복잡한 추론이 필요한 멀티홉 QA 벤치마크인 HotpotQA, MuSiQue, 2Wiki 등에서 기존 RAG 기반 모델들보다 F1 스코어를 2.0에서 8.1까지 향상시켰다고 밝히고 있습니다. 특히 주목할 점은 다음과 같습니다.

• AuthTrace 벤치마크: 여러 문서를 엮어 추론해야 하는 이 테스트에서 정확도 1위를 기록했습니다. 이는 흩어진 정보 조각을 모으는 능력보다, 정보 간의 관계를 따라가는 능력이 복잡한 질문 해결에 훨씬 유리함을 입증한 결과입니다.
• 멀티홉 QA 강점: 질문의 답이 단일 문서가 아닌 여러 문서의 연결 고리에 있을 때, LLM Wiki 방식은 기존 방식보다 훨씬 안정적으로 정답에 도달합니다.

어디까지 확인됐나

가장 주목해야 할 부분은 어떤 요소가 실제로 성능을 끌어올렸는지 분석한 Ablation Study(요소 제거 실험) 결과입니다. 특정 기능을 제거했을 때 발생하는 F1 스코어의 손실 정도를 통해 각 요소의 기여도를 확인할 수 있습니다.

이 결과는 실무적으로 매우 중요한 시사점을 줍니다. 단순히 '잘 짜인 위키 구조'를 만드는 전처리 과정보다, '에이전트가 정보를 얼마나 효율적으로 순회(Traversal)하며 읽느냐' 하는 런타임 전략이 성능에 두 배 가까운 영향을 미친다는 사실입니다. 즉, 데이터의 형태보다 에이전트의 탐색 알고리즘과 지침이 더 중요하다는 뜻입니다.

실무적 응용: 읽기 사다리 (GROUND Ladder)

이러한 '순회'의 중요성을 실제 구현에 적용하기 위해, 에이전트가 정보를 읽어 들이는 수준을 5단계로 나눈 '읽기 사다리' 개념이 제안되었습니다. 이는 무작정 전체를 읽어 토큰을 낭비하는 대신, 정보의 구체성과 필요성에 따라 단계적으로 접근하는 전략적 읽기 방식입니다.

1. 의존성 확인 (Dependencies): 페이지가 명시적으로 적어둔 의존성 항목을 먼저 확인합니다. 해당 페이지를 이해하기 위해 먼저 읽어야 할 다른 페이지가 무엇인지 파악하는 단계입니다.
2. 인덱스 탐색 (Index): 페이지의 목차나 인덱스를 통해 필요한 핵심 섹션이 존재하는지 빠르게 스캔합니다.
3. 계산된 링크 (Computed Links): 빌드 과정에서 미리 계산되어 연결된 핵심 링크들을 확인하여 지식의 지름길을 찾습니다.
4. 콘텐츠 검색 (Content Search): 페이지 내의 구체적인 텍스트 내용을 키워드 기반으로 검색하여 필요한 부분만 추출합니다.
5. 전체 탐색 (Full Scan): 위키 전체 또는 해당 페이지의 모든 내용을 정밀하게 읽어 분석합니다.

중요한 점은 이 단계가 1번부터 5번까지 순차적으로 진행되는 것이 아니라는 점입니다. 에이전트가 "현재 확보한 근거로는 답을 내기 부족하다"는 신호를 감지했을 때만, 그 부족함의 성격에 맞는 적절한 단계로 즉시 점프하여 정보를 보충합니다. 예를 들어, 핵심 개념은 알지만 세부 수치가 부족하다면 즉시 4단계(콘텐츠 검색)로 이동하는 식입니다. 이는 추론의 정확도를 유지하면서도 컨텍스트 윈도우의 낭비를 줄이고 지연 시간을 최적화하는 실무적인 장치가 됩니다.

반론과 빈칸

이 방식이 RAG의 완전한 대체제가 되기 위해서는 여전히 검증되지 않았거나 해결해야 할 현실적인 과제들이 남아 있습니다.

1. 전처리 비용과 컴파일 오버헤드

기존 RAG는 텍스트를 단순히 자르고 임베딩하여 벡터 DB에 넣는 선형적인 과정만 거치면 됩니다. 하지만 LLM Wiki는 문서를 분석해 양방향 링크를 생성하고 지식 그래프를 구축하는 '컴파일' 과정이 필수적입니다. 이 과정에서 LLM을 이용한 구조 분석 작업이 대량으로 발생하며, 이는 상당한 API 호출 비용과 전처리 시간으로 이어집니다. 데이터가 한 번 구축되면 변하지 않는 정적 문서라면 문제가 없으나, 실시간으로 업데이트되는 문서의 경우 컴파일 오버헤드가 서비스의 전체 지연 시간(Latency)에 심각한 영향을 줄 수 있습니다.

2. 대규모 확장성(Scalability)의 불확실성

현재 논문과 오픈소스 구현체에서 보여준 결과는 특정 벤치마크와 상대적으로 규모가 작은 지식 저장소 수준에서의 결과입니다. 문서의 양이 수만, 수십만 페이지로 늘어났을 때 에이전트가 링크를 따라가는 '순회' 과정에서 발생하는 지연 시간과 토큰 소모량을 어떻게 제어할 것인지에 대한 정량적인 데이터가 부족합니다. 특히 순회 횟수가 늘어날수록 LLM의 추론 시간이 선형적으로 증가하며, 이는 사용자 경험(UX) 측면에서 치명적인 응답 속도 저하를 야기할 수 있습니다.

3. 동적 업데이트와 링크 무결성

데이터가 수정될 때마다 관련된 링크들을 어떻게 실시간으로 갱신할 것인가 하는 문제입니다. 단순한 텍스트 수정이 위키 전체의 링크 구조 변경을 야기할 수 있으며, 이 과정에서 발생할 수 있는 '깨진 링크'나 잘못된 연결로 인한 환각(Hallucination)을 제어하는 방안이 더 정교하게 설계되어야 합니다. 단순 벡터 검색은 데이터가 바뀌면 다시 임베딩하면 그만이지만, 위키 방식은 지식의 '관계'를 재정의해야 하므로 갱신 복잡도가 훨씬 높습니다.

4. 에이전트의 제어 가능성과 결정론적 동작

'순회'가 성능의 핵심이라는 것은, 역설적으로 에이전트의 프롬프트 설계나 모델의 추론 능력에 따라 성능 편차가 매우 클 수 있음을 의미합니다. 에이전트가 링크를 잘못 선택해 길을 잃거나, 특정 페이지 사이에서 무한 루프에 빠지는 현상을 어떻게 방지할 것인지에 대한 가드레일 설계가 필요합니다. 또한, 동일한 질문에 대해 매번 다른 탐색 경로를 거쳐 다른 답을 내놓을 가능성이 있어, 기업용 서비스에서 요구하는 결정론적인 동작(Deterministic behavior)을 보장하기 어렵다는 점도 고려해야 합니다.

직접 확인할 질문

이 기술을 실제 프로젝트에 도입하거나 실험해보고 싶다면, 무작정 구현에 들어가기 전 다음의 체크리스트를 통해 적용 가능성을 냉정하게 판단하시기 바랍니다.

• 내 데이터가 정말로 '멀티홉' 추론을 요구하는가?
  • 사용자의 질문이 "A의 가격은 얼마인가?" 같은 단순 사실 확인인지, 아니면 "A의 가격 정책과 B의 할인 조건을 조합했을 때, C 고객이 받을 최종 혜택은 무엇인가?"처럼 여러 문서의 정보를 유기적으로 엮어야 하는 케이스가 주를 이루는지 분석하십시오. 단순 검색 위주의 서비스라면 LLM Wiki의 복잡성은 오히려 낭비가 됩니다.
• 지식의 구조가 정적인가, 아니면 매우 동적인가?
  • 한 번 구축하면 업데이트 빈도가 낮은 기술 문서, 사내 표준 규정, 제품 매뉴얼 형태라면 초기 컴파일 비용을 감수할 가치가 충분합니다. 하지만 실시간 뉴스, 실시간 로그 데이터, 혹은 매시간 변경되는 상품 정보처럼 변동성이 극심한 데이터라면 이 방식의 오버헤드가 이점보다 훨씬 클 것입니다.
• 현재 RAG 시스템의 실패 원인이 정확히 '청킹' 때문인가?
  • 단순히 정답률이 낮은 것이 아니라, LLM이 "관련 정보가 부족하다"고 답변하거나, 가져온 조각들이 서로 연결되지 않아 논리적 도약이 발생하는 사례가 빈번한지 확인하십시오. 만약 문제의 핵심이 '정보의 파편화'에 있다면 LLM Wiki가 확실한 대안이 될 수 있습니다.
• 에이전트의 '읽기 전략'을 정교하게 설계할 리소스가 있는가?
  • 단순히 툴을 제공하는 것을 넘어, '읽기 사다리'와 같이 어떤 순서로 정보를 탐색하고, 언제 다음 단계로 점프할지에 대한 정교한 시스템 프롬프트(System Prompt)를 설계하고 A/B 테스트를 수행할 수 있는 엔지니어링 리소스가 있는지 확인하십시오.
• 토큰 비용과 지연 시간을 감당할 수 있는 비즈니스 모델인가?
  • 순회 기반 방식은 필연적으로 쿼리당 LLM 호출 횟수를 증가시킵니다. 단일 요청에 대해 발생하는 평균 호출 횟수와 그로 인한 응답 시간 증가를 서비스 수준 협약(SLA) 범위 내에서 수용할 수 있는지, 그리고 증가하는 토큰 비용이 서비스 매출이나 효율성 개선으로 상쇄되는지 검토하십시오.