In English.
자주 묻는 질문
LLM Wiki Newsroom에 대해 자주 묻는 질문입니다. Claude Code용 멀티에이전트 위키 프레임워크죠. 전체 그림은 README(영문) 나 소개 페이지 를 보세요.
LLM Wiki Newsroom이 뭔가요?
지식 문서를 서로 연결된, 사람이 읽을 수 있는 마크다운 위키로 바꿔 주는 오픈소스 프레임워크입니다. 신문사 편집국을 본떠 다섯 역할로 나눈 AI 편집국이 이 일을 맡습니다. 기사·메모·PDF를 폴더에 넣고 명령어 하나를 실행하면, 에이전트가 문서를 읽고 인물·개념·관계를 뽑아 서로 링크된 페이지로 정리합니다. RAG를 대신하는, 지속되고 구조화된 대안이며, Claude Code를 주 대상으로 설계했습니다.
RAG와 어떻게 다른가요?
RAG는 질문할 때마다 원문 조각을 다시 긁어모아 답변에 끼워 넣습니다. LLM Wiki Newsroom은 대신 지식을 미리 구조화해 쌓아 둡니다. 소스를 한 번 위키 페이지로 정리해 두고, 위키링크와 백링크 색인으로 서로 엮고, 모순은 질문 시점이 아니라 문서를 넣는 순간 표시하고, 새 소스를 넣을 때마다 기존 페이지를 보강합니다. 그래서 검색할 때는 날것의 조각이 아니라 이미 정리된 페이지 몇 개만 읽습니다. 본 프로젝트와 유사한 개념을 위챗/텐센트 팀이 독립적으로 만들고 성능을 측정한 논문도 있습니다. 여러 문서를 오가며 답해야 하는 질의응답 벤치마크 세 개에서 벡터 기반 RAG와 그래프 기반 RAG를 모두 앞섰다고 보고합니다(arXiv 2605.25480). 해당 논문의 시스템을 측정한 결과이지 본 프로젝트를 측정한 것은 아니지만, 이 접근이 통한다는 방증은 됩니다.
“Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki” (arXiv 2605.25480) 논문과는 어떤 관계인가요?
그 자체로 읽어볼 만한 좋은 논문입니다. WeChat/Tencent 팀의 연구로, 검색을 추론으로 재조명합니다. 문서를 잘게 잘라 질문마다 비슷한 조각 몇 개를 유사도로 꺼내 붙이는 대신, 소스를 서로 연결된 위키로 엮어 두고 에이전트가 그 안을 돌아다니며 답을 맞춰 갑니다. 한 페이지를 읽고, 링크를 따라 관련 페이지로 넘어가고, 모자라면 다시 검색하는 식으로 여러 번 오갑니다. 근거가 여러 문서에 흩어져 있어 조각으로 자르면 그 사이 관계가 사라지는 멀티홉 질문에서 특히 효과가 큽니다. HippoRAG 2·LightRAG·GraphRAG를 기준선으로, 멀티홉 질의응답 데이터셋 세 개(HotpotQA·MuSiQue·2WikiMultiHopQA)에서 최고 성능(SOTA)을 보고했고 F1을 2~8점 끌어올렸습니다. 가장 쓸모 있는 대목은 ablation입니다. 다회 순회를 빼면 위키 구조를 뺄 때보다 F1 손실이 약 두 배라, 문서를 어떻게 쪼개느냐보다 어떻게 순회하느냐가 더 중요하다는 뜻입니다. 본 프로젝트는 논문과는 별개로 개발하였는데 같은 구조에 이른 것뿐입니다. 논문의 구현체가 아니고 논문에서 제시하는 수치도 본 프로젝트를 잰 값이 아닙니다. 다만 위키 구조가 청크 검색을 앞선다는 유력한 외부 근거는 됩니다. 논문의 순회 우선 결과를 보고 본 프로젝트 그라운드 사다리(GROUND Ladder) 기능을 넣었습니다.
API 키가 필요한가요?
‘API 키가 필요 없다’는 말은 절반만 맞습니다. 위키를 만드는 파이썬 도구(그래프 생성기·린트·로컬 검색)는 외부 API 키 없이 내 컴퓨터에서 전부 돕니다. 다만 읽고 쓰는 에이전트 자체는 Claude Code로 돌아가니, 그건 각자 자기 키를 물려 써야 합니다(BYOK). 정리하면, 도구는 로컬 우선이고 어떤 언어 모델을 쓰느냐는 여러분의 Claude Code에 달려 있습니다.
어떤 AI 에이전트에서 돌아가나요?
Claude Code가 주력이자 완전 지원 대상으로, 아홉 개 슬래시 명령어와 연쇄 갱신·연상 탐색 같은 고급 기능이 다 돌아갑니다. Codex와 Gemini CLI는 AGENTS.md와 GEMINI.md를 통해 기본 수준으로 지원합니다. 자연어로 지시해 핵심 정리 워크플로는 쓸 수 있지만, Claude Code 전용 기능은 빠집니다.
안드레이 카파시의 LLM Wiki와 관련이 있나요?
네. 안드레이 카파시가 공유한 LLM Wiki gist에 구현을 하나 붙여본 게 출발이었습니다. 소스 문서, 에이전트가 만든 위키, 에이전트의 운영 규칙을 각각 다른 계층으로 두는 3계층 패턴을 따르고, 문서 하나를 넣으면 관련 페이지 10~15개가 갱신된다는 그의 아이디어를 구현합니다. 대부분의 구현보다 한발 더 나간 부분은 스스로 진화하는 저작 지침과, 검수를 따로 맡는 다섯 역할 편집국입니다.
‘글 쓴 에이전트가 검수는 안 한다’는 게 무슨 뜻인가요?
위키 페이지를 쓰는 에이전트와 검수하는 에이전트를 컨텍스트가 격리된 별도 인스턴스로 둡니다. 검수하는 쪽은 완성된 초안과 채점 기준(루브릭)만 봅니다. 글쓴이의 사고 과정이나 중간 메모는 못 봅니다. 한 에이전트가 자기 글을 자기가 채점하면 아무래도 후하게 봐주는데, 그 편향을 줄이려는 겁니다. 게시는 규칙대로 도는 파이썬 검사(린트)와 사람이 하는 검수, 양쪽을 다 통과해야 열립니다. 이건 이 프로젝트가 검증 중인 설계 가설이지, 엄밀하게 측정된 결과는 아직 아닙니다.
쓰는 쪽과 보는 쪽을 나눌 값어치가 있나요?
늘 그렇지는 않습니다. 검수를 따로 돌리면 에이전트 하나가 같은 맥락에서 자기 글을 자기가 볼 때보다 토큰도 시간도 더 듭니다. 빠르게 쓰고 버리는 결과물이라 틀려도 다시 하면 그만인 작업은 하나로 충분합니다. 나눌 값을 하는 건 밖에 공개되고, 쌓이고, 나중에 그 위에 뭔가를 더 얹는 작업입니다. 여기서는 그럴듯한데 틀린 페이지 하나가 조용히 모두가 인용하는 근거로 굳어 버리니까요. 위키가 바로 그런 경우입니다. 오늘 쓴 페이지가 내일 입력으로 들어가니, 오류 하나가 오류 하나로 끝나지 않습니다.
다섯 역할이 전부 따로 도는 LLM인가요?
아닙니다. 남이 쓴 초안을 두고 LLM이 독립적으로 판단을 내리는 자리는 데스크 하나뿐입니다. 교열은 LLM이 아니라 규칙대로 도는 파이썬 검사(린트)입니다. 링크가 깨졌는지, 인용이 붙어 있는지, 구조를 지켰는지는 코드로 확정할 수 있으니까요. 기자와 칼럼니스트는 성격이 다른 글쓰기를 맡고, 편집장은 작업 조율(오케스트레이션)과 게시 결정을 합니다. 그러니까 핵심은 에이전트를 몇 개 두느냐가 아니라, 쓰는 쪽과 보는 쪽의 컨텍스트를 따로 두는 데 있습니다.
‘스스로 진화하는 저작 지침’이 뭔가요?
같은 검수 지적이 반복되면, 시스템이 자기 저작 규칙을 고치는 안을 스스로 만듭니다. 그리고 바꾸기 전과 후를 어느 쪽이 바뀐 버전인지 모르게 나란히 비교해서, 실제로 점수가 오를 때만 그 변경을 남깁니다. 이때 검증에 쓰는 실패 사례는 매번 새것으로 갈아끼워서, 규칙이 같은 시험 문제에만 익숙해지는 것(overfit)을 막습니다. 늘 처음 보는 사례로 확인하는 셈이죠. 그래서 시간이 지나면 위키만이 아니라 위키를 만드는 지침도 좋아집니다. 이 루프는 아직 실험 단계고, 효과도 아직 제대로 측정한 게 아닙니다.
실무에 바로 쓸 만큼 검증됐나요?
공개 레포는 아이디어와 재현 가능한 작은 예제로 봐 주세요. ‘AI에서 오픈소스란 무엇인가’ 논쟁을 담은 노드 15개짜리 영어 예제가 들어 있을 뿐, 검증을 마친 제품이 아닙니다. 쓰는 쪽과 검수하는 쪽의 분리나 자기진화 루프 같은 차별점도 풀린 주장이 아니라, 만든 사람이 측정 중인 가설로 제시합니다. 새 프로젝트이고, 설계상 한계에 대해 정직하려고 합니다.
모순 추적이 뭔가요?
새로 넣은 문서가 기존 주장과 충돌하면, 그 불일치를 조용히 뭉개지 않고 문서를 넣는 순간 기록합니다. 모순은 전용 페이지로 따로 빠지는데, 전체 요약에서 주제별 분석으로, 다시 충돌하는 원본 주장으로 내려가는 순서로 정리됩니다. 그래서 하나로 평균 낸 답 대신, 소스들이 어디서 왜 엇갈리는지를 볼 수 있습니다.
위키가 커져도 일관성이 유지되나요? 변경되거나 오래된 정보는 어떻게 처리하나요?
일관성은 두 가지 방법으로 지킵니다. 소스를 새로 넣거나 바꾸면 그 페이지만 고치지 않고 관련된 기존 페이지들까지 잇따라 고쳐, 주장과 링크를 최신 상태로 맞춥니다. 여기에 더해 reground 루프가 주기적으로 소스가 아니라 이미 발행된 위키 페이지들을 다시 읽습니다. 그래서 개요나 허브, 모순 페이지 같은 파생 페이지가 지금 상태와 어긋나지 않았는지 확인하고 바로잡습니다. 소스만 검사해서는 놓치는, 오래되거나 어긋난 관계를 잡기 위한 장치입니다. 파이썬 검사도 오래된 항목과 모순을 기계적으로 표시합니다. 솔직히 이건 대규모에서 검증됐다기보다, 그 문제를 겨냥해 만든 단계입니다. 공개된 예제가 작고, 한번 뜬 문제를 해결됐다고 자동으로 닫아 주는 기능 같은 건 아직 만드는 중이라, 대규모에서의 일관성은 아직 검증 중인 가설로 봐 주시면 됩니다.
한국어로 쓸 수 있나요?
WIKI_LANG=ko로 켜는 선택형 한국어 모드가 있습니다. 페이지 본문과 문서 상단 메타데이터(frontmatter)의 값을 한국어로 바꿔 줍니다. 다만 그 메타데이터의 키와 문서 구조를 나타내는 표기(## Summary, [fact] 같은 것)는 도구가 그대로 찾아 써야 해서 일부러 영어로 남깁니다. ‘완전 한국어’는 아니라는 뜻이죠. 그러니까 한국어 모드는 문서 구조 표기가 아니라 본문 글을 한국어로 바꿔 줍니다. 레포에 들어 있는 예제도 전부 영어입니다.
설치 전에 결과를 볼 수 있나요?
레포에 담긴 예제는 GitHub Wiki로 공개돼 있어서, clone 없이 생성된 페이지를 읽어 볼 수 있습니다. 인터랙티브 지식 그래프(페이지는 노드, 링크는 엣지, 비슷한 주제끼리 자동으로 묶음)는 clone 후 graph 폴더를 띄우고 브라우저에서 graph.html을 열면 로컬에서 돕니다.
옵시디언에서 쓸 수 있나요?
네. 위키는 페이지끼리 위키링크로 이어진 일반 마크다운 파일이라, 옵시디언이 그대로 읽습니다. 위키 폴더를 옵시디언 볼트로 열면 페이지와 백링크, 그래프 뷰가 변환 없이 바로 동작합니다. 옵시디언 플러그인은 아닙니다. 옵시디언은 결과물을 읽고 둘러보는 한 가지 방법이고, 위키를 만들고 관리하는 일은 Claude Code가 같은 폴더에서 합니다. 다른 마크다운 편집기로 열어도 되지만, 링크된 노트와 그래프는 옵시디언에서 바로 쓸 수 있습니다.
내 데이터가 외부로 나가나요?
위키는 내 컴퓨터에서 버전관리되는 순수 마크다운 파일로 저장되고, 빌드·린트·로컬 검색 도구는 내용을 외부로 보내지 않습니다. 네트워크를 타는 유일한 부분은 에이전트 자체입니다. Claude Code로 돌아가니, 에이전트가 읽고 쓰는 텍스트는 다른 Claude Code 사용과 똑같이 여러분의 Claude Code 세션을 거칩니다.
더 궁금한 점이 있으면 GitHub 에서 이슈나 디스커션을 남겨 주세요.