저는 Karpathy의 "LLM 관리형 위키 (LLM-maintained wiki)" 패턴을 앱으로 구현한 MindBase를 구축해 왔습니다. 사용자가 노트를 작성하고 소스를 넣으면, AI가 지속적인 위키를 유지합니다 (RAG가 아니라 실제 마크다운 (Markdown) 페이지를 작성하고 업데이트합니다).

지난 7월 출시했을 때는 이를 사용하기 위해 AI 에디터와 API 키가 필요했습니다. 지난 3주 동안은 이 두 가지를 모두 제거하는 데 집중했습니다. 실제 UI와 함께 전체 시스템을 무료 로컬 모델 (local model)에서 실행하며 배운 점들을 공유합니다.

1. 소형 모델은 도구 호출 (tool calls)을 체이닝할 수 없습니다 — 그러니 요구하지 마세요

저의 첫 번째 서버 측 파이프라인은 에이전트 방식 (agentic)이었습니다. 모델이 검색을 호출하고, 페이지를 읽고, 그다음 작성하는 방식이었죠. Ollama의 qwen3:14b를 사용했을 때는 잘못된 도구 호출, 잘못된 형식의 인자 (arguments), 종료되지 않는 루프 등으로 인해 끊임없이 무너졌습니다.

해결책은 에이전트의 자율성 (agency)을 제거하는 것이었습니다. 노트 수집 (ingest), 컨텍스트 재구축 (rebuild the context), 상태 점검 (health-check), 조사 (research)와 같은 모든 위키 작업은 이제 **하나의 엄격한 JSON 스키마 (JSON schema)에 대한 단 한 번의 완성 (completion)**으로 이루어집니다. 모델에 필요한 모든 정보는 사전에 프롬프트 (prompt)에 수집되어 제공됩니다. 파싱 실패 시 에러 메시지를 첨부하여 단 한 번만 재시도합니다. 이것이 전체 에러 핸들링 (error handling)의 전부입니다.

로컬 모델은 하나의 스키마를 채우는 데 있어서는 매우 신뢰할 수 있다는 것이 밝혀졌습니다. 하지만 다음에 무엇을 할지 결정하는 데에는 불안정합니다. 그에 맞춰 설계하세요.

2. 88초간의 빈 화면: 사고 모드 (thinking-mode) 모델

qwen3와 deepseek-r1은 숨겨진 thinking 필드에 추론 과정을 스트리밍합니다. 저의 채팅 UI는 content 필드만 수집했는데, 모델이 아무도 읽지 않는 필드에서 즐겁게 추론하는 동안 content는 88초 동안 비어 있었습니다.

단 한 줄의 코드(Ollama API에서 think: false)로 응답 시간이 88.7초에서 1.1초로 단축되었습니다. 만약 로컬 모델 UI에서

Karpathy의 원래 사양(spec)에는 제 v1 버전에서 건너뛰었던 단계가 실제로 포함되어 있습니다: 바로 LLM이 글을 쓰기 전에 사용자와 핵심 요점(takeaways)에 대해 논의하는 단계입니다. 그래서 이제 모든 데이터 수집(ingest)은 핵심 요점과 제안된 업데이트 계획을 반환하며, 각 계획에는 체크박스가 포함됩니다. '적용(Apply)'을 누르기 전까지는 아무것도 작성되지 않습니다.

The approval step — takeaways and a checkbox plan, generated by qwen3:14b locally

동일한 모델, 동일한 출력물이지만, 작성 전에 계획을 보여주는 방식이 신뢰 문제(trust problem)를 거의 완벽하게 해결했습니다.

4. 두 계층을 시각화하기

이 패턴은 두 개의 계층으로 구성됩니다: 여러분의 원시 노트(raw notes, 추가 전용이며 본인 소유)와 위키(wiki, AI가 관리)입니다. v1에서는 이것이 폴더 구조에만 존재했기 때문에 새로운 사용자들이 이를 인지하지 못했습니다.

이제 모든 노트는 상태 칩(status chip)을 표시합니다: 노트가 마지막 빌드보다 최신인 동안에는 ✨ Add to wiki, 소화(digestion)된 후에는 ✓ In wiki · 2 pages라고 표시됩니다. 노트를 수정하면 다시 불이 들어옵니다.

Writing a note with the wiki-status chip, qwen3:14b running locally

제가 좋아하는 구현 세부 사항은 다음과 같습니다: 칩의 상태는 단순히 "파일 수정 시간(mtime)이 context.md보다 최신임"을 나타냅니다. 이는 빌드 파이프라인(build pipeline)이 소화되지 않은 소스를 찾기 위해 사용하는 정확히 동일한 규칙입니다. 새로운 상태를 만들지 않으므로 UI와 파이프라인이 서로 불일치할 일이 없습니다.

5. 모델 드롭다운보다 하드웨어 감지가 낫다

사용자에게 Ollama 모델을 선택하라고 요구하는 것은 사용자에게 이미 전문가가 되어달라고 요청하는 것과 같습니다. 이제 설정 마법사(setup wizard)가 RAM/CPU를 읽고 실제로 적합한 모델을 추천합니다: 8GB → llama3.2:3b, 16GB → qwen3:8b, 32GB+ → qwen3:14b. 그런 다음 설치하고, 진행 표시줄과 함께 모델을 가져오며(pull), 실제 1개 토큰 생성(one-token generation)을 통해 검증합니다 (API가 응답하는 것과 모델이 작동하는 것을 확인하는 것은 다르다는 것을 저는 아주 창피한 방식으로 배웠습니다).

현재 상황

모든 것이 디스크 상의 마크다운 (markdown) 형식이며, MIT 라이선스를 따르고, Claude Code / Cursor / 모든 MCP 클라이언트와 호환됩니다. 그리고 이제는 구독료 없이 브라우저에서 단독으로 실행할 수 있습니다.

저장소 (Repo): https://github.com/frankchu91/mindbase

만약 로컬 모델 (local models)을 실행하신다면: 백그라운드 합성 (background synthesis) 작업을 위해 현실적으로 할당할 수 있는 가장 큰 모델은 무엇인가요? 추천 표 (recommendation table)의 범위를 어디까지 확장할지 결정하려고 합니다.