LLM Wiki의 '신문 편집국' 구조와 핵심 제원

LLM Wiki는 멀티에이전트 시스템에서 발생하는 5~10배의 토큰 낭비와 컨텍스트 유실 문제를 해결하기 위해 '신문 편집국' 구조를 도입했다. 기존의 자율 멀티에이전트가 각 에이전트에게 과도한 판단 권한을 부여해 토큰을 소모하고 작업 완료 여부를 오판하는 것과 달리, LLM Wiki는 역할별로 판단 권한을 엄격히 분리한 것이 특징이다.

시스템은 총 다섯 가지 에이전트 역할을 수행한다. 이 중 LLM이 자율적으로 판단을 내리는 역할은 '데스크(검수)' 하나뿐이다. 나머지 역할은 글쓰기 작업, 규칙 기반의 파이썬 검사(린트), 그리고 전체 작업 조율(오케스트레이션)로 구성되어 LLM의 개입을 최소화했다.

인프라 측면에서는 저장소로 마크다운(Markdown) 파일과 git을 사용하며, 파이썬 도구들은 모두 로컬 환경에서 작동한다. 에이전트 구동을 위해서는 Claude Code를 사용하며, 사용자가 직접 API 키를 입력하는 BYOK(Bring Your Own Key) 방식을 따른다. 현재 공개된 GitHub 저장소에는 15개 노드로 구성된 영어 예제가 포함되어 있으며, 실제 운영 사례로는 약 2,300개 노드 규모의 인스턴스가 존재한다.

컨텍스트 격리 및 문서 생성 파이프라인의 작동 방식

작동 방식의 핵심은 LLM의 자율 판단 범위를 최소화하고 규칙 기반의 제어 장치를 배치해 컨텍스트 오염을 막는 점이다. 문서 생성 파이프라인은 '원본 문서 읽기 $\rightarrow$ 소스 페이지 생성 $\rightarrow$ 인물·개념 초안 추출 $\rightarrow$ 주제별 개요·모순 정리·종합 페이지 구축' 순으로 진행된다.

특히 문서가 무분별하게 불어나는 '부풀림' 현상을 막기 위해 글 쓰는 역할과 판정하는 데스크 역할을 완전히 격리했다. 데스크 에이전트에게는 결과물과 채점 기준만 제공하며, 글쓴이 에이전트의 작성 의도는 전달하지 않는다. 여기에 규칙 기반 린트(Lint)를 배치해 문서의 중복이나 방향성 상실을 기계적으로 걸러낸다.

모델이 특정 피드백 패턴에 익숙해져 성능이 정체되는 오버피팅(Overfit)을 방지하기 위한 메커니즘도 포함됐다. 데스크가 결함을 잡아내 가이드라인에 반영할 때, 검증용 실패 사례를 매번 새로운 것으로 교체하여 모델이 항상 처음 보는 사례로 확인하도록 설계했다.

또한, 일반적인 RAG(검색 증강 생성)가 벡터 인덱스를 통해 정보를 검색하고 통합하는 것과 달리, LLM Wiki는 출처 간의 불일치를 덮지 않고 별도의 '모순 페이지'로 분리해 드러낸다. 이는 정보의 단순 통합보다 판단의 근거를 남기는 데 목적이 있다. 여기에 바네바 부시의 Memex 개념을 차용하여 페이지 간 연상 경로를 잇는 trail(트레일) 기능과 뜻밖의 연결을 찾는 discover 기능을 통해 사람이 직접 정보 경로를 추적할 수 있게 했다.

개발자 및 실무자를 위한 도입 고려사항

실무자가 이 프레임워크를 도입할 때 가장 먼저 고려해야 할 점은 API 비용과 제어권의 분리다. 모든 에이전트에게 자율성을 부여하는 대신, 판단 권한을 '데스크'로 단일화하고 나머지를 규칙 기반(Python)으로 처리함으로써 토큰 소모량을 제어할 수 있다. 도구(tools) 내 파이썬 코드는 로컬에서 실행되므로 별도의 API 비용이 발생하지 않지만, 에이전트 본체인 Claude Code 운용 비용은 사용자의 API 키 설정에 따라 결정된다.

언어 설정의 경우 `WIKI_LANG=ko` 옵션을 통해 본문과 문서 상단의 메타데이터(frontmatter)를 한국어로 변경할 수 있다. 다만, `## Summary`나 `[fact]`와 같은 문서 구조 표기법은 영어로 유지되므로 완전한 한국어 환경이 아님을 인지해야 한다.

결과적으로 개발자는 이 시스템을 단순한 정보 검색 도구가 아니라, LLM의 판단 결과가 마크다운 문서 형태로 누적되는 '지식 베이스 구축 도구'로 판단해야 한다. 질문할 때마다 원문을 다시 긁어모으는 RAG 방식의 지연시간과 비용 문제를, 미리 구축된 연결 문서 구조를 통해 해결하려는 시도로 볼 수 있다.