안드레 카파시가 LLM Wiki 개념을 제시한 것을 보고, LLM이 직접 위키를 쓰고 이어서 관리하게 두는 방식을 IT·AI 뉴스를 스크랩해서 정리하는 데 적용해봤습니다. 신문 기사 하나를 넣으면 관련 페이지 10~15개가 알아서 갱신되고 백링크로 엮이는 게 신기해서 몇 달을 그렇게 굴렸습니다.
근데 스크랩 한 소스가 1,000건을 넘어가니 위키가 걷잡을 수 없이 불어나기 시작했어요. 새 뉴스가 기존 페이지를 덮어쓰고, 비슷한 문서가 중복으로 쌓이고, 출처끼리 안 맞는 내용이 조용히 뒤섞였습니다. 결정적으로 LLM한테 "네가 쓴 거 네가 검토해"라고 시키면 자기가 쓴 거라고 대충 통과시키더라고요.
그래서 좀 특이한 구조로 풀었는데 공유합니다. 요즘 "에이전트가 실수할 때마다 규칙을 진화시킨다"라고 하잖아요. 저는 그걸 뉴스 위키 저작 지침에 적용해본 케이스입니다.
구조 : 신문사 편집국을 흉내 냄
소스 문서를 읽어서 사람이 읽을 수 있는 연결형 마크다운 위키로 엮는 파이프라인인데, 역할을 다섯으로 나눴습니다(편집장·기자·칼럼니스트·데스크·교열). 근데 멀티에이전트라고 다 자율은 아니에요. 실제로 LLM이 독립적으로 판단하는 자리는 데스크(검수) 하나뿐입니다. 나머지는 성격이 다른 글쓰기 작업이거나, LLM이 아니라 규칙대로 도는 파이썬 린트(tools/lint.py), 흐름 잇는 오케스트레이션이고요. 자율 실행이 토큰만 5~10배 태우고 컨텍스트 놓치는 걸 피하려고, 자율성보다 결정론과 컨텍스트 격리에 무게를 뒀습니다.
핵심 1 : 쓰는 쪽과 검수하는 쪽을 따로 두기
위키가 불어나는 걸 잡는 핵심은 컨텍스트 격리였습니다. 데스크(검수)는 결과물이랑 채점 기준(루브릭)만 보고, 글쓴이가 무슨 생각으로 썼는지는 못 봅니다. 자기가 쓴 거 자기가 검수하면 아무래도 후하게 봐주잖아요. 그걸 구조적으로 막으려는 거예요. 여기에 정량 린트가 문서가 불어나거나 중복되거나 정처 없이 늘어지는 걸 기계적으로 걸러냅니다. 여기 "Claude Skills로 블로그 검토 프로세스 만들기" 글 봤는데 결이 비슷하더라고요. 저는 "검수자에겐 초안만 보여준다"는 격리를 좀 더 세게 적용하였습니다.
핵심 2 : "실수하며 진화하는 규칙"을 좀 더 엄밀하게
아까 말한 "에이전트가 실수할 때마다 규칙을 진화시킨다"를 한 발 더 나가보았습니다. 데스크가 반복해서 잡아내는 결함을 가이드라인 강화로 자기진화시키는데, 자칫 잘못하면 고정된 시험 문제에 overfit되거든요. 자기가 만든 피드백으로 자기를 고치니 있던 패턴만 되풀이하는 함정에 빠질 수 있습니다. 그래서 효과를 잴 때는, 개선에 한 번도 안 쓴 새 실패 사례를 매번 따로 빼서 그걸로만 채점합니다. 늘 처음 보는 문제로 확인하는 셈이에요. 솔직히 이 로테이션이 아직 완벽하진 않은 게 한계고, 자기진화가 진짜 품질을 올리는지도 아직 제대로 측정한 게 아니라 실험 중인 가설입니다.
그 외 두 가지
출처끼리 안 맞는 부분은 덮지 않고 따로 모순 페이지로 빼둡니다. 그냥 뭉개면 나중에 위키가 조용히 틀린 내용으로 굳어버리더라고요.
저장은 마크다운 + git, 파이썬 도구는 전부 로컬입니다.
clone하면 API 키 없이 예제 그래프를 바로 재현할 수 있어요. 다만 에이전트 자체는 Claude Code로 도니까 그건 각자 키 물려 써야 하고요(BYOK).
공개 레포는 이 구조를 영어 기사 15노드짜리 예제로 재현해둔 겁니다(clone하면 그래프까지 그대로 재현돼요). 위에서 말한 한국 뉴스 인스턴스는 2,300노드쯤까지 커졌는데 그건 따로 비공개라 구분해서 봐주세요.
"토큰 절약을 위해 범위부터 좁히는" 쿼리 로직이 궁금하시면
tools/query.py보시면 됩니다.
writer≠reviewer가 정말 wiki 품질을 높이고 있는지, 자기진화 루프가 실제로 도움이 되는지 아직 확신은 없습니다. 비슷하게 Claude Code로 위키나 메모리 굴려보신 분들, 불어나는 문제랑 검수 문제 어떻게 푸셨는지 반론이든 경험이든 듣고 싶어요.
