카파시: LLM이 내 위키를 대신 쓴다
10분

카파시: LLM이 내 위키를 대신 쓴다

X/Twitter Andrej Karpathy LLM Knowledge Bases ↗

카파시가 LLM으로 개인 지식베이스를 구축하는 7단계 워크플로우를 공개했습니다.

raw 데이터를 수집하면 LLM이 .md 위키로 자동 컴파일하고, 질의 결과가 다시 위키를 확장합니다.

실전 적용 시 수동 대비 5~9배 빠르고, 숙련자조차 놓치는 정보의 20%를 추가로 발견합니다.

아직 노션에 직접 정리하고 있습니까?
카파시는 LLM이 위키를 씁니다.

카파시는 최근 토큰 대부분을 코드가 아닌 지식 조작에 씁니다. 문서를 직접 작성하지 않습니다. LLM이 대신 씁니다. "최신 LLM은 이 작업에 꽤 능숙하다"고 카파시는 밝혔습니다.

노션, 컨플루언스에 직접 정리하는 방식과 다릅니다. LLM이 raw 자료를 읽고 스스로 위키를 만듭니다. 이 방식이 실제 기업 지식에 적용되면 어떤 결과가 나올까요? 10년, 15,161개 노트 규모에서 실측한 데이터가 있습니다.

기업 현장에서 지식 관리는 오래된 병목입니다. 회의록, 시장 조사, 경쟁사 분석은 쌓이지만 활용되지 않습니다. LLM이 이 병목을 해소하는 수준에 도달했습니다.

카파시의 방식은 개인 연구용으로 시작됐습니다. 지금 실험하지 않으면 경쟁사가 먼저 내재화합니다.

카파시 워크플로우는 7개 레이어로 구성됩니다. 단순한 "AI에게 정리 맡기기"가 아닙니다. 데이터 수집부터 품질 점검까지 닫힌 루프를 형성합니다. 아래 개념도는 전체 흐름과 복리 축적 구조를 보여줍니다.

① Raw 수집 아티클 · 논문 이미지 저장 ② LLM 컴파일 요약 · 백링크 개념 분류 자동화 ③ Wiki · Obsidian 지식 축적 · 통합 열람 ◀ 복리 축적의 중심 ▶ ④ Q&A 에이전트 RAG 없이 2초 13,750 노트 검색 ⑤ Output .md · 슬라이드 그래프 출력 지식 복리 축적 루프 (탐구할수록 깊어짐) ⑥ Linting (건강 점검) 불일치 감지 · 빈 항목 보완 · 신규 아티클 제안 ⑦ Extra Tools: CLI 검색 엔진 등 에이전트 도구 추가 가능
카파시 LLM 지식베이스 7레이어 워크플로우

첫째, 지식 관리의 주체가 사람에서 LLM으로 바뀝니다. raw/ 폴더에 아티클, 논문, 이미지를 수집합니다. LLM이 이를 읽고 .md 파일 위키로 컴파일합니다. 위키에는 요약, 백링크, 개념 아티클, 교차 링크가 포함됩니다. 카파시는 위키를 직접 수정하는 경우가 거의 없다고 밝혔습니다.

둘째, RAG(회사 내부 문서를 AI에 연결하는 방식) 없이도 동작합니다. 카파시는 40만 단어 규모에서 별도 구축 없이 LLM 인덱스 파일로 운영합니다. 실전 검증에서 13,750개 노트를 2초 내에 검색했습니다. 구조화된 메타데이터가 있으면 RAG는 마지막 수단입니다.

셋째, 질의 결과가 다시 위키를 확장합니다. 에이전트에게 질문하면 .md 파일, 슬라이드, 그래프 형태로 답변이 출력됩니다. 이 출력을 위키에 저장합니다. 탐색할수록 지식베이스가 깊어지는 구조입니다. 카파시는 이를 "내 탐색이 항상 누적된다"고 표현했습니다.

넷째, LLM이 위키 품질을 스스로 점검합니다. Linting 프롬프트를 실행하면 불일치 데이터를 찾고, 빈 항목을 웹 검색으로 보완합니다. 새로운 아티클 후보도 제안합니다. 위키가 쌓일수록 제안의 질이 높아집니다.

다섯째, 거버넌스가 있어야 규모가 커져도 품질이 유지됩니다. 카파시 시스템은 약 100개 문서, 40만 단어 규모입니다. 1만 5천 개 이상의 노트로 확장하면 LLM 자율만으로는 품질을 보장하기 어렵습니다. 스키마, 분류 체계, 감사 정책이 갖춰져야 LLM의 자유로운 생성과 품질 보장을 동시에 달성합니다. 이를 "Governed Autonomy(관리된 자율)"라고 부릅니다.

카파시 원형 규모: ~100문서, 40만 단어 스키마 없음 · LLM이 주 저자 Q&A Agent: 위키 기반 질의 지식 루프: 반자동 강점: 빠른 시작, 단일 주제 깊이 한계: 15,000+ 문서에서 품질 보장 어려움 LLM 자율 + Governed Autonomy 규모: 15,000+ 문서 (150배) 스키마 v5.4 · 27개 분류 · 20개 정책 Q&A: 수동 대비 5배 빠름, +25% 발견 지식 루프: 완전 자동 (항상 닫힘) 강점: 대규모 · 품질 보장 · 복리 성장 전제: 과거 거버넌스 투자가 필수 LLM 자율 + 거버넌스 = 품질 보장
카파시 원형 vs Governed Autonomy 비교 (출처: projectresearch.co.kr, 2026)

여섯째, 속도 이점보다 완전성 이점이 더 큽니다. Q&A는 수동 대비 약 5배 빠릅니다. 그런데 진짜 가치는 속도가 아닙니다. 숙련자가 파일명 검색으로 찾지 못하는 문서를 20% 추가로 발견합니다. 이는 능력의 문제가 아닙니다. 복합 분류 태그, 고객 별칭, 다른 디렉터리 연결은 구조적으로 수동 탐색이 불가합니다.

1
Obsidian 설치 후 raw 폴더를 만듭니다.
Obsidian을 무료로 설치합니다. 관심 주제 하나를 정하고 raw/ 폴더를 생성합니다. Obsidian Web Clipper 확장으로 관련 아티클 5개를 .md로 저장합니다. (30분)
2
Claude에게 위키 초안 작성을 지시합니다.
raw/ 폴더 내용을 Claude에 붙여넣고 다음 프롬프트를 실행합니다. "이 파일들을 읽고 핵심 개념별 .md 아티클을 작성해줘. 각 아티클에 요약, 관련 파일 목록, 핵심 포인트 3개를 포함해." (1시간)
3
위키에 실제 업무 질문을 던집니다.
생성된 위키를 Claude에 붙여넣고 실제 의사결정이 필요한 질문을 합니다. 출력 결과를 wiki/ 폴더에 저장해 다음 질의의 입력으로 활용합니다. (30분)
4
분류 체계를 먼저 정의합니다.
문서 유형, 주제 분류, 고객/프로젝트 태그를 미리 설계합니다. 이 거버넌스가 없으면 규모가 커질수록 위키 품질이 떨어집니다. Claude에게 "이 문서들의 분류 체계를 5개 기준으로 제안해줘"라고 물어보는 것으로 시작합니다. (30분)

LLM이 없는 사실을 위키에 추가할 수 있습니다. 환각(hallucination)으로 인해 잘못된 정보가 위키에 섞일 수 있습니다. 중요한 수치나 고유명사는 원본 파일과 대조해야 합니다. 위키를 맹신하면 의사결정 오류로 이어집니다.

위키 품질은 raw 데이터 품질에 달려 있습니다. 불분명하거나 불완전한 자료를 넣으면 위키도 불완전합니다. "쓰레기를 넣으면 쓰레기가 나온다"는 원칙은 LLM 지식베이스에도 적용됩니다.

규모가 커지면 거버넌스 없이는 유지가 불가합니다. 카파시 방식은 소규모(약 40만 단어)에서 효과적입니다. 그 이상으로 확장하려면 스키마와 분류 체계가 선행되어야 합니다. 과거의 거버넌스 투자가 미래 자동화의 품질을 결정합니다.

닫힌 루프가 없으면 복리 효과는 없습니다. 수동 지식 축적은 "시간 나면 한다"로 끝납니다. 자동 루프가 없으면 탐구 결과가 위키에 돌아오지 않습니다. 1년 뒤 지식 자산 격차는 이 차이에서 발생합니다.

지식은 모으는 것이 아니라 컴파일하는 것입니다. 거버넌스를 갖춘 조직이 더 좋은 컴파일러를 씁니다.

창업자/CEO: 팀의 시장 조사를 raw 폴더 형식으로 표준화합니다. 분류 체계를 먼저 설계하고, 주간 위키 업데이트를 에이전트에게 맡기는 파일럿을 이번 달 시작합니다.
팀장: 팀원들의 인사이트를 raw 파일로 수집하고 LLM에게 주간 정리를 지시합니다. 회의 전 에이전트에게 위키 질의를 먼저 실행합니다.
임원: 경쟁사 분석, 산업 리포트를 raw 폴더에 축적합니다. 전략 회의 전 에이전트가 즉시 관련 인사이트를 제공하는 구조를 만듭니다.
  • Karpathy, A. (2026, April). LLM Knowledge Bases [Post]. X/Twitter. (원문 보기 ↗)
  • Project Research. (2026, April). Karpathy의 LLM과 Obsidian 지식 결합 [Article]. projectresearch.co.kr. (원문 보기 ↗)
라운드테이블
G
골드 · 창업자
저 이 워크플로우 바로 따라했어요. raw 폴더에 PDF, 유튜브 트랜스크립트 쌓고 LLM한테 .md 위키 만들라고 시켰더니 진짜로 됐어요. 수동 대비 5~9배 빠르다는 말이 과장이 아니에요.
N
네이비 · 시니어 엔지니어
raw 데이터 품질이 관건이에요. 쓰레기 넣으면 쓰레기 나옵니다. 데이터 수집 파이프라인 설계에 먼저 1주. 이 부분이 빠진 설명이에요.
G
골드 · 창업자
그건 맞아요. 근데 완벽한 데이터 기다리다 시작 못 하는 것보다 불완전한 raw로 시작해서 점점 개선하는 게 낫더라고요. 카파시도 질의 결과가 다시 위키를 확장한다고 했잖아요.
P
퍼플 · 마케터
"숙련자조차 놓치는 정보의 20%를 추가로 발견"한다는 부분이 제일 인상적이었어요. 이건 마케팅 리서치에 바로 쓸 수 있겠다 싶었어요. 경쟁사 분석을 이 방식으로 하면 구조가 완전히 달라질 것 같아요.
R
레드 · 저널리스트
"20% 추가 발견"은 어떤 조건에서 나온 숫자예요? 도메인마다 다를 텐데 이걸 일반화하면 사람들이 맹목적으로 믿을 수 있어요.
W
화이트 · 조직장
숫자 논쟁 전에 일단 써보고 싶은데, 7단계 중 1단계인 raw 폴더 세팅부터 막혀요. 회사 자료를 어디까지 LLM한테 줘도 되는지 보안 기준이 없거든요.
B
블랙 · 중견기업 임원
조직 지식이 사람 머릿속에만 있으면 리스크입니다. 퇴사하면 끝이에요. 이 워크플로우로 지식을 구조화해두면 온보딩 시간이 줄고 의사결정 속도가 올라갑니다.
W
화이트 · 조직장
그 얘기는 알겠는데, 팀에서 누가 이걸 관리해요? 담당자를 정해야 하는데 다들 이미 바쁘다고 하거든요.
N
네이비 · 시니어 엔지니어
자동화 파이프라인 세팅하면 관리 부담이 줄어요. 주기적 크롤링, LLM 컴파일, 위키 업데이트를 스케줄러로 돌리면 됩니다. 초기 세팅 3일, 이후는 거의 자동이에요.
B
블랙 · 중견기업 임원
3일이면 충분합니다. 바빠서 못 한다는 말은 이 작업의 ROI를 아직 모르는 거예요.