On this page
Karpathy가 설명하기 전에 이미 만들어 놓았다
Andrej Karpathy가 LLM 기반 지식 관리 시스템 패턴을 발표했는데, 이미 몇 달째 운영하고 있던 시스템과 놀라울 정도로 같았어요. 비교에서 알게 된 것들을 공유해요.
2026년 4월 초, Andrej Karpathy가 “LLM Knowledge Bases” 패턴을 발표했을 때 이상한 경험을 했어요. “새롭고 흥미롭다”가 아니라 “이건 내 시스템인데, 한 번도 본 적 없는 사람이 설명하고 있다”였거든요. 3계층 아키텍처, 점진적 컴파일, 인덱스 파일, LLM이 모든 관리 작업을 하는 것까지 — 정확히 같은 패턴을 몇 달째 운영하고 있었어요. 저는 이걸 3B(Brandon’s Binary Brain)라고 부르는데, 6개 프로젝트 전반의 작업 방식의 근간이에요.
이 글은 Karpathy의 아이디어를 요약하는 글이 아니에요. 그건 그의 gist를 읽으면 돼요. 이건 비교예요: 추상적인 패턴을 실제 운영 시스템에 매핑할 때 무엇이 드러나는지, 그리고 차이점이 진짜 중요한 것에 대해 무엇을 알려주는지에 대해서요.
Karpathy의 프레임워크 30초 정리
Karpathy는 세 가지 계층을 설명해요:
- 원시 소스 — 아티클, 논문, 레포, 이미지. 불변. LLM이 읽기만 하고 수정하지 않아요.
- 위키 — LLM이 생성한 마크다운 파일 디렉토리. 요약, 엔티티 페이지, 개념 페이지, 상호 참조. LLM이 이 계층을 완전히 소유해요.
- 스키마 — LLM에게 위키의 구조와 따라야 할 워크플로우를 알려주는 설정 파일 (CLAUDE.md, AGENTS.md).
핵심 인사이트: 위키는 영속적이고 복리로 쌓이는 산출물이에요. 매 쿼리마다 원시 문서에서 답을 다시 도출하는 RAG와 달리, 위키는 지식을 한 번 컴파일하고 최신 상태를 유지해요. LLM이 인간들이 위키를 포기하게 만드는 관리 작업을 담당하는 거예요.
3B: 같은 패턴, 다른 선택
3B는 Karpathy의 세 계층에 깔끔하게 매핑되지만, 구현 선택에서 의미 있는 차이가 있어요.
| Karpathy의 계층 | Karpathy의 구현 | 3B의 구현 |
|---|---|---|
| 원시 소스 | raw/ 디렉토리 (불변) | journals/ (임시, 롤업됨) |
| 위키 | 위키 디렉토리의 엔티티/개념 페이지 | knowledge/ — 원자적 Zettelkasten 엔트리 |
| 스키마 | 단일 스키마 파일 (CLAUDE.md) | CLAUDE.md + PROJECT-CONFIG + skills + rules |
첫 번째 차이점은 표에서 이미 보여요: “원시”로 뭘 취급하느냐?
차이점 1: 임시 저널 vs. 불변 소스
Karpathy는 원시 소스를 영구적으로 취급해요. 아티클을 클리핑해서 raw/에 넣으면 영원히 남아요. 위키는 거기서 파생돼요.
3B에서 원시 계층은 세션 저널이에요 — 작업 세션에서 무슨 일이 있었는지 기록하는 일일 로그예요. 명시적으로 임시적이에요. 주간 저널은 월간 요약으로 롤업되고, 월간 요약은 분기별로 롤업돼요. 일일 엔트리는 영구적으로 남지만, 중간 롤업은 집계 후 정리돼요.
왜 차이가 나냐면: Karpathy는 주제를 연구하고 있어요. 그의 원시 소스는 외부적 — 논문, 아티클, 데이터셋이에요. 참조 자료로서 영구적인 가치가 있어요. 저는 6개 프로젝트에 걸쳐 소프트웨어를 만들고 있어요. 제 원시 입력은 세션 활동 — 뭘 했고, 뭐가 깨졌고, 뭘 배웠는지예요. 세션 자체가 지식이 아니라, 추출된 인사이트가 지식이에요. 저널은 처리 단계이지 진실의 소스가 아니에요.
차이점 2: 위키 페이지 vs. 원자적 노트
Karpathy의 위키는 엔티티와 개념 페이지를 사용해요 — 새 소스가 추가될 때 잠재적으로 길어지는 문서예요. “transformer 아키텍처” 엔티티 페이지는 수개월에 걸쳐 20편의 논문 내용이 쌓일 수 있어요.
3B는 Zettelkasten 스타일의 원자적 노트를 사용해요. 파일당 하나의 개념. 작고, 집중적이고, 재사용 가능해요. “PostgreSQL advisory locks”에 대한 지식 엔트리는 일반적인 PostgreSQL 페이지로 자라지 않아요. 좁은 범위를 유지해요. PostgreSQL MVCC에 대해 배우면, 그건 related: 링크가 있는 별도 엔트리가 돼요.
트레이드오프는 명확해요:
- 위키 페이지는 탐색이 쉬워요. “transformers” 페이지를 찾으면 모든 게 거기 있어요.
- 원자적 노트는 연결이 쉬워요. 단일 엔트리가 느슨하게 관련된 정보의 뒤죽박죽이 되지 않으면서 여러 맥락에 참여할 수 있어요.
200개 이상의 지식 엔트리에서, 원자적 노트를 선택하길 잘했다고 느껴요. 엔트리들이 프론트매터 related: 필드를 통해 서로 연결되고, 각각이 하나의 질문에 답해요. Karpathy의 접근법은 하나의 주제에 대한 깊은 연구에 더 잘 맞을 수 있어요. 원자적 접근법은 백엔드, DevOps, 보안, AI/ML, 프론트엔드를 넘나드는 프로젝트 간 전문 지식에 더 잘 맞아요.
차이점 3: 직접 컴파일 vs. 세션 파이프라인
Karpathy의 워크플로우: raw/에 소스를 넣고, LLM에게 처리하라고 하면, 위키가 업데이트돼요.
3B의 워크플로우: 세션 작업 → 저널이 내용 기록 → /wrap이 지식 후보 추출 → 사용자 승인 → 엔트리 생성 또는 보강.
Human-in-the-loop 단계는 의도적이에요. 세션 중에 관찰 내용을 버퍼 파일에 쌓고, 세션 끝에 /wrap이 버퍼와 대화 이력을 분석해서 추출 임계값(5가지 기준 중 최소 2개 충족: 놀라움, 재발성, 함정, 전이 가능성, 의사결정?)을 적용하고 승인을 위해 후보를 제시해요.
초기에 완전 자율 추출을 시도했었어요. 문제는 노이즈였어요. LLM이 당연한 패턴(“git status로 변경 확인”)과 진짜 인사이트(“PostgreSQL MVCC는 INSERT-then-UPDATE가 WAL에 원시 PII를 남긴다”)를 함께 추출했거든요. 임계값 게이트와 사용자 승인이 인사이트를 잃지 않으면서 노이즈를 제거했어요.
완전히 동의하는 부분
차이점에도 불구하고, 핵심 메커니즘은 동일해요:
인덱스 파일이 동작해요. 두 시스템 모두 _index.md 파일로 내용을 카탈로그해요. Karpathy는 “중간 규모(~100개 소스, ~수백 페이지)에서 놀라울 정도로 잘 동작하고” 임베딩 기반 RAG 인프라가 필요 없다고 보고해요. 3B는 11개 카테고리에 걸친 200개 이상의 지식 엔트리에서 이를 확인해요. LLM이 인덱스를 읽고, 관련 파일을 찾고, 깊이 들어가요. 벡터 데이터베이스가 필요 없어요.
LLM이 관리하는 상호 참조가 복리로 쌓여요. 모든 3B 지식 엔트리에는 프론트매터에 related: 링크와 지식이 적용된 시점과 장소를 기록하는 when_used: 추적이 있어요. 이 링크들은 Claude가 작성하고 유지해요. 시간이 지나면서 그래프가 가장 가치 있는 부분이 돼요 — 개별 엔트리가 아니라 엔트리 간의 연결이요.
건강 검사가 필수예요. Karpathy는 “린팅”이라고 불러요. 3B에는 깨진 링크와 오래된 참조를 위한 /doc-audit, 프론트매터 일관성을 위한 validate:dates, 매 /wrap 세션의 프론트매터 건강 검사가 있어요. 이것들 없이는 엔트로피가 이겨요. 죽은 링크가 쌓이고, 엔트리들이 서로 모순되고, 지식 기반이 조용히 열화돼요.
출력물을 다시 저장해야 해요. Karpathy: “좋은 답변은 위키에 새 페이지로 저장할 수 있다.” 이건 정확히 3B의 보강 티어가 하는 거예요 — 쿼리가 새로운 인사이트를 만들면, 관련 지식 엔트리에 추가돼요. 탐색이 복리로 쌓여요.
Karpathy의 패턴에 없는 것
Karpathy의 gist는 지식을 축적하고 쿼리하는 시스템을 설명해요. 지식을 퍼블리싱하는 시스템은 설명하지 않아요.
3B에는 완전한 퍼블리케이션 파이프라인이 있어요: 지식 엔트리가 블로그에 동기화되고, 참조 형식에서 서사 형식으로 확장되고, 한국어로 번역되고, 배포돼요. 블로그는 Karpathy의 패턴에 없는 네 번째 계층이에요 — 개인적으로만 참조하는 게 아니라 공유할 수 있는 형태로 정제된 지식이에요.
이게 중요한 이유는 간결한 지식 엔트리를 공유 가능한 포스트로 확장하는 행위가 내가 실제로 이해하는 것과 이해한다고 착각하는 것을 직면하게 만들기 때문이에요. “PostgreSQL advisory locks가 동시 배치 작업을 방지한다”를 불릿 포인트로 쓰면 지식처럼 느껴져요. 그걸 언제 사용하는지, row-level locks와 어떻게 다른지, 잘못하면 어떻게 되는지를 풀어서 쓰면 — 거기서 빈 구멍이 드러나요. 블로그는 단순한 출력 채널이 아니라 자기 이해에 대한 정직함 검증이에요.
Karpathy에게 배운 것
gist를 읽으면서 생각하지 못했던 아이디어 두 가지가 떠올랐어요:
위키 콘텐츠에서 Marp 슬라이드 덱. 3B 엔트리에서 프레젠테이션을 생성해 본 적이 없는데, 아이디어가 매력적이에요. “ECS autoscaling patterns”에 대한 지식 엔트리가 수작업 없이 10장짜리 기술 프레젠테이션이 될 수 있어요.
지식 기반에서 합성 데이터 생성. Karpathy가 미래 방향으로 언급한 것: 위키로 LLM을 파인튜닝해서 컨텍스트 윈도우가 아닌 가중치에 데이터를 “알게” 하는 거예요. 3B에는 이미 파인튜닝 파이프라인(별도 프로젝트를 위한 LoRA 어댑터)이 있고, 지식 기반이 학습 데이터 소스가 될 수 있어요.
핵심 교훈
Karpathy는 일반적인 패턴을 설명했어요. 3B는 구체적인 인스턴스예요. 패턴이 동작하는 건 아키텍처가 영리해서가 아니라, LLM이 모든 인간이 유지하는 지식 기반을 죽이는 관리 부담을 흡수하기 때문이에요.
중요한 선택은 만들지 말지가 아니라, 원자적 단위가 뭐냐예요. Karpathy는 위키 페이지를 선택했어요. 저는 Zettelkasten 노트를 선택했어요. 둘 다 동작해요. 도메인에 대해 어떻게 생각하는지에 맞는 단위를 고르세요: 하나의 주제에 대한 깊은 연구에는 페이지, 여러 프로젝트에 걸친 전문 지식에는 원자적 노트가 맞아요.
시작하고 싶다면, Karpathy의 gist가 올바른 출발점이에요. LLM 에이전트에 붙여넣고, 도메인에 대해 알려주고, 시스템이 진화하게 하세요. 스키마는 바뀔 거예요. 컨벤션은 달라질 거예요. 그게 정상이에요. 제 CLAUDE.md는 열두 번 다시 작성됐어요. 지식 엔트리는 영구적이에요. 스캐폴딩은 일회용이에요.