문서를 잘게 쪼개 벡터 데이터베이스에 넣는 RAG 방식은 단순 질문에는 잘 맞습니다. 하지만 에이전트가 여러 문서를 건너다니며 근거를 조합해야 하는 순간부터 맥락이 쉽게 끊깁니다.

어떤 문서가 최신인지 알아야 할 때가 있습니다. 한 정책이 다른 문서의 어떤 개념과 연결되는지도 봐야 합니다. 같은 용어가 부서마다 어떻게 다른지까지 따라가야 합니다. 이 정보를 단락 임베딩만으로 처리하면 에이전트가 그럴듯하지만 틀린 답을 만들기 쉽습니다.

LLM Wiki는 이 문제를 문서 구조 쪽에서 풉니다. 비정형 문서를 위키처럼 다시 구성하고 엔티티와 관계를 링크로 연결합니다. 에이전트가 따라갈 지식 지도를 만드는 방식입니다.

벡터 검색만으로 놓치는 것

기존 RAG는 문서를 단락 단위로 쪼갠 뒤 검색합니다. 질문과 가장 가까운 조각을 찾는 데는 유용합니다. 문제는 그 조각이 문서 전체에서 어떤 위치에 있고 어떤 다른 개념과 이어지는지까지 항상 보존하지는 못한다는 점입니다.

예를 들어 사내 정책 문서에서 “승인"이라는 단어를 찾았다고 해보겠습니다. 그 승인이 예산 승인인지 보안 승인인지 바로 알기는 어렵습니다. 어떤 팀의 최신 절차인지, 이전 버전과 무엇이 달라졌는지도 따로 봐야 합니다. 에이전트는 검색된 조각만 보고 답을 만들다가 맥락을 잘못 붙일 수 있습니다.

문서가 많아질수록 이 문제는 커집니다. 비슷한 단어가 여러 문서에 흩어져 있고 오래된 문서와 최신 문서가 함께 검색됩니다. 그러면 모델은 어느 쪽을 기준으로 삼아야 할지 흔들립니다.

LLM Wiki는 문서를 연결된 페이지로 바꿉니다

LLM Wiki는 사내 문서를 위키백과처럼 구조화하는 방식에서 출발합니다. 문서 안의 주요 엔티티를 뽑고 관련 개념과 문서를 하이퍼링크로 연결합니다.

에이전트 입장에서는 검색 결과가 단순 텍스트 조각으로 끝나지 않습니다. 한 페이지에서 관련 부서와 정책, 용어 정의와 변경 이력으로 이동합니다. 필요한 정보를 링크를 따라가며 좁혀가므로 다단계 추론에서 빠지는 정보가 줄어듭니다.

위키 구조는 문서의 계층도 함께 보존합니다. 상위 정책과 하위 절차, 예외 규칙과 담당 조직이 한 흐름 안에 놓입니다. 에이전트가 답변을 만들 때 “이 문장이 어디에 속한 정보인지"를 더 잘 판단합니다.

검색 범위와 비용도 줄어듭니다

구조화된 위키는 검색 엔진과 결합했을 때 효과가 더 큽니다. 단순 키워드 검색이나 벡터 검색에만 의존하지 않고 페이지 간 연결과 메타데이터를 함께 사용해 탐색 범위를 좁힙니다.

예를 들어 특정 부서의 최신 문서만 보게 할 수 있습니다. 승인된 문서만 대상으로 삼거나 특정 제품군과 연결된 페이지부터 탐색하게 만들 수도 있습니다. 엔지니어가 이런 필터링 규칙을 정의해 두면 에이전트가 불필요한 문서를 덜 읽습니다.

읽는 문서가 줄면 LLM API 호출 비용도 줄어듭니다. 더 중요한 건 답변 품질입니다. 검색 범위가 좁아지면 모델이 서로 다른 문서를 억지로 섞어 답하는 위험도 줄어듭니다.

운영에서는 업데이트 관리가 핵심입니다

사내 지식은 계속 바뀝니다. 조직 개편이나 정책 변경, 제품 업데이트가 생기면 문서도 함께 달라집니다. LLM Wiki가 오래된 상태로 남으면 에이전트는 최신처럼 보이는 낡은 답을 내놓습니다.

그래서 버전 관리가 필요합니다. 문서 변경 이력과 승인 상태, 마지막 업데이트 시점과 폐기된 페이지 여부를 추적해야 합니다. 에이전트가 답을 만들 때 어떤 버전의 지식을 기준으로 삼았는지도 남겨야 합니다.

이 구조가 있으면 운영자가 문제를 추적하기 쉽습니다. 답변이 틀렸을 때 프롬프트만 의심하지 않습니다. 어떤 페이지와 어떤 링크를 따라가다 잘못된 근거를 가져왔는지 확인합니다.

지식 베이스가 에이전트의 실행 환경입니다

에이전트 성능은 모델만으로 결정되지 않습니다. 모델이 읽는 지식 베이스의 구조가 답변 품질을 크게 좌우합니다. 문서가 흩어져 있고 최신성을 알 수 없으면 좋은 모델도 불안정하게 움직입니다.

LLM Wiki는 문서를 예쁘게 정리하려는 도구가 아닙니다. 에이전트가 근거를 따라가고 최신 문서를 구분하게 만드는 운영 구조에 가깝습니다. 필요한 범위만 읽게 만드는 장치이기도 합니다.

단순한 텍스트 뭉치를 연결된 지식망으로 바꾸는 작업입니다. 이 작업이 되어 있어야 에이전트가 사내 문서를 실제 업무 지식처럼 씁니다.

핵심 정리

  • 단순 벡터 검색은 문서 조각을 찾는 데 유용하지만 문서 간 관계와 최신성까지 안정적으로 보존하지는 못합니다.
  • LLM Wiki는 엔티티와 문서, 정책과 변경 이력을 링크로 연결해 에이전트가 근거를 따라가며 탐색하게 만듭니다.
  • 운영 환경에서는 검색 구조만큼 버전 관리와 승인 상태 관리가 중요합니다. 그래야 에이전트 답변의 신뢰성이 유지됩니다.