블로그로 돌아가기
[TUTORIAL]

nashsu llm_wiki, 스타 1만 9천 개 모은 RAG 대안 구조와 한국어 실전 궁합

퀀텀점프클럽 정상록퀀텀점프클럽 정상록9분 읽기4 views
#Karpathy#AI 지식관리#RAG 대안#한국어 지원#llm_wiki

무료 자료

PDF · 무료

내 자료가 저절로 위키가 되는 오픈소스 도구 — 비개발자를 위한 쉬운 가이드

긴 글을 다 읽기 전에, 실무 가이드부터 먼저 챙겨가세요.

nashsu llm_wiki, 스타 1만 9천 개 모은 RAG 대안 구조와 한국어 실전 궁합

RAG는 물어볼 때마다 찾고, llm_wiki는 문서를 넣는 순간 미리 정리해 쌓아둡니다. 한국어 지원은 아직 확인되지 않았습니다.

nashsu/llm_wiki는 GitHub 스타 1만 9천 개를 모은 오픈소스 데스크톱 앱이에요. 흔한 RAG와는 정반대 방향에서 지식을 다루는 도구입니다. "우리도 이런 걸 써볼 만한가요?" 실무자라면 한 번쯤 품었을 질문이겠죠. 새 도구를 들이는 순간, 저 질문 뒤엔 늘 "설정이 복잡하지 않나", "우리 데이터가 어디로 새는 건 아닌가", "한국어는 되나" 같은 걱정이 줄줄이 따라붙기 마련입니다. 이 글에서는 이 앱이 RAG 대안으로서 정확히 뭐가 다른지, 실제 동작 구조는 어떤지, 그리고 한국 실무자라면 특히 놓치면 안 되는 한계까지 순서대로 짚어보겠습니다.

RAG와 다른 진짜 지점: 검색이 아니라 쓰기

대부분의 사람이 접하는 LLM과 문서의 조합은 RAG입니다. 파일 뭉치를 업로드하면 질문할 때마다 관련 조각을 찾아 답을 만드는 방식이죠. 이 구조에는 쌓이는 게 없어요. 어제 물은 질문의 결과가 오늘 다시 검색될 뿐, 지식으로 남지는 않습니다.

llm_wiki는 이 순서를 뒤집습니다. 문서를 인제스트하는 순간 LLM이 위키 페이지를 만들어 저장하고, 이후 질문에는 이미 정리된 위키를 읽는 구조죠. 비유하자면 전통 RAG는 질문을 받을 때마다 서고로 뛰어가 책을 찾아오는 조수이고, 이 방식은 책이 들어올 때마다 미리 요약 카드를 써서 상자를 채워두는 사서에 가깝습니다. 사서 쪽은 처음에 손이 더 가지만 여러 문서를 종합해야 하는 질문에서는 유리한 편이에요.

llm_wiki란: RAG처럼 질의 시점에 검색하는 대신, 문서를 넣는 시점에 LLM이 위키 페이지를 만들어 지식을 누적하는 오픈소스 데스크톱 앱이다. 데이터는 로컬 마크다운으로 저장되고, GPL-3.0 라이선스로 배포된다.

이 패턴을 처음 만든 사람은 nash_su가 아닙니다

이 부분이 자주 오해받는 지점이라 먼저 짚습니다. llm_wiki는 독자 발명이 아니라 Andrej Karpathy가 2026-04-04(오늘 기준 162일 전) 공개한 gist "LLM Wiki"의 구현체예요. 개발자 nash_su(본명 Yong Su)가 나흘 뒤인 2026-04-08(158일 전) 저장소를 만들어 데스크톱 앱 형태로 옮겼습니다.

공을 가로채는 대신, README는 원작에서 무엇을 그대로 뒀고 무엇을 바꿨는지 절 단위로 밝혀둡니다. 이 투명성 자체가 신뢰의 근거예요. Show HN에는 2026-04-06(160일 전)부터 2026-06-23(82일 전)까지 최소 12건의 별도 구현체가 올라왔고, llm_wiki는 그중 가장 많은 스타를 받은 구현일 뿐입니다.

인제스트부터 질의까지, 실제 동작 구조

문서를 읽는 방식은 LLM 호출 2단계로 나뉩니다. 1단계는 분석, 원본을 읽고 핵심 개체·개념·기존 지식과의 모순을 구조화하는 단계예요. 2단계는 생성, 그 분석을 받아 실제 위키 파일(개체 페이지·개념 페이지·index.md)을 씁니다. 원본 파일은 SHA256으로 해시해두고, 바뀌지 않은 파일은 재처리를 건너뛰어 토큰을 아끼는 구조더라고요.

질문에 답할 때는 4단계 파이프라인이 돌아갑니다. 먼저 토큰화 검색(영어 단어 분리, 중국어 CJK bigram)으로 후보를 좁히고, 켜져 있으면 벡터 검색(LanceDB)이 의미 기반으로 보강해요. 그다음 위키 링크를 따라 2홉까지 그래프를 확장하고, 마지막으로 컨텍스트 예산(위키 60%·채팅 이력 20%·인덱스 5%·시스템 15%)에 맞춰 조립합니다. README는 벡터 검색을 켰을 때 재현율이 58.2%에서 71.4%로 올랐다고 밝히지만, 측정 방법론과 데이터셋은 공개돼 있지 않아 이 수치는 검증 불가로 남겨둬야 합니다.

규모, 라이선스, 비용: 무료와 무료 아닌 것의 경계

2026-09-13 07:10 KST 기준 스타 19,097개, 포크 2,164개, 열린 이슈 259건이에요. 최근 하루 640스타가 늘었다는 언급도 있었지만, GitHub API가 제공하는 값은 누적치뿐이라 이 일간 증가폭은 이번 조사로 독립 검증하지 못했습니다.

라이선스는 GPL-3.0입니다. GitHub의 자동 판별기는 이 저장소를 NOASSERTION(판별 불가)으로 표시하는데, LICENSE 파일 원문을 직접 열어보면 GPL-3.0 전문이 그대로 담겨 있어요. 앱을 그냥 쓰는 건 제약이 없지만, 코드를 가져다 자사 제품에 통합하려면 강한 카피레프트 조항 때문에 법무 검토가 필요합니다. 앱 자체는 무료지만 LLM API 요금은 사용자 몫이고, Ollama를 붙이면 로컬 모델만으로도 돌릴 수 있는 구조예요. 최신 릴리스는 v0.6.11(2026-08-25 발행, 오늘 기준 19일 전)이고, 이 버전의 macOS 배포 자산에는 Apple Silicon용 dmg만 있고 Intel(x86_64)용은 빠져 있습니다. README는 Intel도 지원한다고 적어놓아 실제 자산과 어긋나며, 이슈 트래커에도 관련 요청이 여러 건 등록돼 있어요.

한국어 사용자가 반드시 알아야 할 한계

여기가 이 글에서 가장 중요한 대목입니다. 공식 한국어 README(README_KO.md)가 있고 전체 번역까지 돼 있어서 얼핏 한국어를 지원하는 것처럼 보여요. 하지만 README 본문이 명시하는 UI 언어는 영어와 중국어 둘뿐이고, 위키 생성 언어 설정도 "영어 또는 중국어"로 한정돼 있습니다. 검색 토크나이저 역시 영어 단어 분리와 중국어 CJK bigram만 다룬다고 적혀 있어, 한국어 형태소 처리에 대한 언급 자체가 없어요.

이 지점이 실제 한국어 지원 여부를 판단할 때 가장 먼저 봐야 할 대목입니다. 한국어 문서를 넣었을 때 인제스트와 위키 생성이 실용 수준으로 동작하는지는 공식 문서 근거로 확인이 안 되거든요. LLM 자체가 한국어를 다루니 생성은 될 가능성이 높지만, 벡터 검색을 끈 기본 상태에서는 조사가 붙는 한국어 특성상 키워드 매칭 정확도가 떨어질 위험이 있습니다. 이슈 트래커에도 한국어 관련 보고는 딱 1건("README 스크린샷 EN/JA/KO 현지화")뿐이라 실사용 사례가 사실상 쌓여 있지 않은 상태예요. 한국어 자료로 쓰려면 소량 파일럿부터 시작하는 편이 안전합니다.

커뮤니티는 왜 갈렸나: "이거 그냥 RAG야" 논쟁

Karpathy의 원작 공개 직후 열린 HN 스레드(296점, 95댓글, 2026-04-04·162일 전)는 지금도 이 패턴을 둘러싼 가장 큰 토론입니다. 가장 많이 나온 반응은 회의론이었어요. kenforthewin은 "이건 그냥 RAG다. 벡터 DB를 안 쓸 뿐이지 검색을 돕는 인덱스를 만드는 건 똑같다"고 지적했고, devmor도 비슷한 취지로 "지속 메모리 RAG일 뿐"이라고 평가했습니다.

반박도 만만치 않았습니다. darkhanakh는 "'그냥 RAG'라는 표현은 밀어내고 싶다. 흥미로운 지점은 검색이 아니라 쓰기 루프다. LLM이 위키를 직접 저작하고 백링크를 만들고 자기 출력을 되돌려 정리한다"고 맞섰어요. 여기에 우려 두 가지가 따라붙었습니다. 하나는 LLM이 LLM 글을 계속 고쳐 쓰면서 정보가 뭉개질 수 있다는 걱정(devnullbrain)이고, 다른 하나는 위키가 커질수록 정리 단계(lint)가 N×N으로 확장돼야 하는 구조적 부담(Covenant0028)이에요. 반대로 j-pb는 "위키가 죽은 컨텍스트를 확 줄여준다"며 실제 워크플로에서 얻은 효과를 전했습니다. 어느 한쪽 손을 들어주기보다, 이 정도로 의견이 갈린다는 사실 자체를 감안하고 판단하는 편이 안전해요.

우리 회사 자료에 써볼지 판단하는 법

앞의 내용을 걸러보면 이 도구가 모든 상황에 맞는 만능 해법은 아니라는 게 드러납니다. 다음 기준으로 먼저 나눠보시길 권해요.

써볼 만한 경우

  • 한 주제를 몇 주에서 몇 달에 걸쳐 파고드는 리서치성 업무
  • 원본이 영어 논문·PDF 위주(토크나이저 지원과 정확히 맞아떨어짐)
  • 클라우드 업로드가 어려워 로컬 보관이 필요한 경우(원격 LLM API를 쓰면 내용은 그쪽으로 전송됨)
  • 이미 Obsidian을 쓰고 있어 결과물을 그대로 열어볼 수 있는 경우
  • Claude Code나 Codex에 MCP로 위키를 물려 쓸 계획이 있는 경우

보류해야 할 경우

  • 한국어 문서가 자료의 대부분(파일럿 검증 없이 바로 확대하지 말 것)
  • 인텔 맥 사용자(v0.6.11에 x86_64 dmg가 없음)
  • 문서가 수만 건 이상(설계상 적정 규모는 원본 100건 수준으로 보임)
  • Azure OpenAI나 AWS Bedrock을 표준으로 쓰는 조직(연동에 별도 브리지 필요)
  • 코드를 자사 제품에 통합할 계획이 있는 경우(GPL-3.0 카피레프트)

권장 검증 순서: 한국어 원본 5~10건으로 작은 프로젝트를 만들어 인제스트 품질을 눈으로 확인하고, 벡터 검색을 켠 상태와 끈 상태의 검색 결과를 비교합니다. 이어서 그 10건 기준 실제 API 요금을 재보고, 여기까지 통과하면 그때 본 자료로 확대하는 순서가 안전해요. 가볍게 훑어볼 목적이면 원본 수 제한이 있는 NotebookLM 쪽이 더 간편할 수 있고, 로컬 검색 엔진만 필요하면 Karpathy 원작이 직접 권장한 qmd 조합도 대안입니다.

마무리

nashsu/llm_wiki는 AI 지식관리를 검색이 아니라 쓰기 관점에서 다시 짜본 시도예요. 방법론 자체는 Karpathy가 먼저 공개했고, 이 앱은 그 위에 GUI와 운영 편의를 얹은 구현체입니다. 다만 한국어 지원처럼 문서에 근거가 없는 항목은 있는 그대로 확인 불가로 남겨두는 편이 이후 도입 판단에 낫습니다. 우리 자료에 이 도구를 써볼지는 아직 정해지지 않았어요. 오늘 정리한 확인 불가 항목과 권장 검증 순서부터 팀과 함께 먼저 짚어보세요.

자주 묻는 질문 (FAQ)

Q: llm_wiki는 결국 RAG 아닌가요?

검색·생성 구조만 보면 RAG와 닮은 건 맞습니다. 다만 지식이 질의 시점이 아니라 인제스트 시점에 위키로 컴파일되어 쌓인다는 점이 다릅니다. 이 지점을 두고 HN 커뮤니티에서도 "그냥 RAG다"와 "쓰기 루프가 다르다"는 의견이 지금도 갈려 있습니다.

Q: 한국어 문서를 넣어도 괜찮을까요?

공식 문서 기준으로는 위키 생성 언어와 검색 토크나이저 모두 영어와 중국어만 명시돼 있어, 한국어 실제 품질은 확인 불가입니다. 바로 전체 자료를 옮기기보다 10건 안팎으로 파일럿을 돌려본 뒤 결정하시길 권합니다.

Q: 비용은 어느 정도 드나요?

앱 자체는 GPL-3.0으로 무료입니다. 다만 원본 문서 1건당 LLM 호출이 분석·생성 2회 이상 들어가는 구조라, 사용하는 모델과 문서 길이에 따라 API 요금이 달라집니다. 구체적인 건당 비용은 공식 문서에 수치로 나와 있지 않습니다.

참고 자료