LLM Wiki 적용 배경
안드레 카파시(Andrej Karpathy)가 공유한 LLM Wiki를 보고, 내 기획 업무에 적용해본 기록이다. 나는 기획자이고 개발자가 아니다. 코드는 한 줄도 쓰지 않았고, 에이전트와 대화하면서 위키 운영 규칙(스키마)을 v0.1부터 v0.5까지 다듬었다. 아직 운영 전, 설계를 마친 단계다.
나는 LLM Wiki를 적용하기 전부터 옵시디언에 기획 폴더를 만들어 쓰고 있었다. 기획서 원문을 저장하고, 그 기획서에 대한 분석과 내 개인 평가를 붙여서 DB로 보관했다. 내 것뿐 아니라 다른 사람들의 기획서도, 회의록도 같이 기록했다.
index로 최대한 모든 자료를 묶어보려고 했지만 쉽지 않았다. 자료는 쌓이는데 서로 연결되는 느낌을 받지 못했다. 기획서 하나하나의 분석은 깊은데, "이런 접근을 쓴 기획들 모아줘" 같은 건 안 됐다. 그냥 폴더 안의 외딴 문서들이었다. 그러던 중 스터디에서 처음 카파시의 LLM Wiki 개념을 배웠고, 내 기획 업무에 적용해보기로 했다.
진행 방법과 도구
사용 도구: 클로드 코드, 레오(Hermes 기반 기획 에이전트), 옵시디언, 서브에이전트.
LLM Wiki가 뭔지
처음엔 "자료를 잘 검색하려고 정리하는 건가?" 했는데, 들어보니 그게 다가 아니었다.
내가 이해한 바로는 이렇다. 보통의 검색(흔히 RAG라고 부른다)은 물어볼 때마다 자료를 찾아와 읽고 그 자리에서 답을 새로 만든다. 그렇게 만든 답은 따로 남지 않아서, 비슷한 질문을 또 하면 또 처음부터다. LLM Wiki는 여기서 한 발 더 간다. 자료를 넣는 그 순간 AI가 "이게 사용자의 일에 무슨 의미인지"까지 미리 분석해서 답을 적어둔다. 나중에 질문이 오면 그 적어둔 답을 꺼내 쓰고, 새로운 답은 추가로 위키에 반영한다. 그래서 위키가 쌓일수록 답이 점점 나아진다.
자료를 캐비닛에 분류해 넣어두는 게 아니라, 미리 읽고 "나라면 이걸 어떻게 쓸까"까지 정리해 둔 사서를 두는 셈이다. 내가 쓰던 방식과 비슷한데 훨씬 확장되고 정교했다. 그래서 내 기획 에이전트 '레오'(Hermes)와 함께 해보기로 했다.
첫 시도와 시행착오
레오에게 내 기존 DB를 바탕으로 위키를 만들게 했다. 레오는 열심히 했는데 결과가 이상했다. 기획자료, 리서치, 아이디어, 업무 Task, 유튜브, 에세이까지 온갖 폴더를 다 빨아들여 한 위키에 욱여넣었다. 기획용 위키인데 제작·인프라 자료까지 섞인 짬뽕이었다.
게다가 레오가 정리한 위키는 매우 간략한 축약본이었다. 그래서 물어봤다. "어? 위키는 그냥 원문 검색용으로, 토큰 낭비 안 하려고 간략하게 정리하는 거야?" 아니라고 했다. 그래서 클로드와 같이 LLM Wiki를 공부했다. "클로드야, 네가 교수님이 되어서 나에게 LLM Wiki를 강의하고 질문도 해줘. 내가 전부 이해할 수 있게."
Ingest, Query, Lint의 이해
사실 처음엔 LLM Wiki의 3대 동작인 Ingest(자료 넣기), Query(질의), Lint(점검)가 뭔지 정확히 이해가 안 됐다. 클로드를 교수 삼아 묻고 답하길 반복하니 그제야 셋이 한 몸이라는 게 보였다.
· Ingest: 자료를 넣으면서 이해하고 사용자 쓰임에 맞는 답을 미리 써두는 일
· Query: 그 써둔 답을 꺼내 쓰고, 답이 좋으면 더 낫게 다시 적어두는 일
· Lint: 답들이 서로 안 맞거나, 빠지거나 오래된 건 없는지 주기적으로 점검하는 일
이 셋이 계속 돌아야 위키가 살아있고, 하나라도 빠지면 죽는다. 이걸 이해하고 나니 레오가 만든 위키가 왜 문제인지 보였다. 레오가 한 건 분석이 아니라 요약 박제였고, 도메인 경계 없이 다 합쳐서 위키의 핵심인 연결이 죽어 있었다.
다시 시작하기
이번엔 위키의 하네스인 스키마를 먼저 만들어서 3대 동작을 명확히 지정하고 가기로 했다. 그런데 막상 스키마를 적어보려니 뭘 적어야 할지 막막했다. 그래서 내가 늘 쓰는 방법을 썼다.
비개발자인 나는 무에서 창조하는 걸 잘 못한다. 그래서 항상 모방에서 시작한다. 나는 늘 에이전트에게 이렇게 말한다.
"내가 OO를 만들고 싶어. 전 세계에 분명 1명은 비슷하게라도 쓰고 있을 거야. 깃헙이든 웹이든 유튜브든 다 검색해서, 내가 벤치마킹할 만한 걸 찾아줘."
이번에도 카파시의 원본 gist, 스터디장님이 주신 스키마 가이드, 깃헙에 올라온 다른 스키마들을 모았다. 거기서부터 시작했다.
에이전트(레오)가 만든 잘못된 위키는 정리하기로 하고, 기획 전용 위키를 처음부터 다시 설계했다. 큰 결정은 세 가지였다.
· 제작용 위키와 분리하고, 지금 필요한 기획 위키만 만든다
· 내가 이미 22편의 기획을 분석하며 쓰던 평가 기준을 그대로 '렌즈'라는 이름으로 박는다
· 기획서 원문 / 분석 토론 상세본 / 위키 결론을 3개 층으로 나눈다 (디테일은 잃지 않고, 위키는 날카롭게)
이 과정에서 한 가지가 눈에 들어왔다. 내가 늘 쓰던 4개 평가 기준이, 알고 보니 카파시가 말한 '렌즈'와 같은 거였다. 새로 배운 게 아니라 내가 이미 하던 걸 이름 붙여 정리한 것이었다.
스키마 개선 과정
한 번에 완성하지 않았다. 내가 피 드백을 던지면 클로드가 고치고, 또 던지면 또 고쳤다.
· "에이전트 이름(레오) 박지 말고 어떤 에이전트든 쓰게 일반화해줘"
· "패턴 승급 기준이 뭔지 모르겠어" → 직감(가설)이 3편에서 발견되면 정식 패턴으로 올리는 규칙으로 정리
· "기획은 시간이 지난다고 낡는 게 아니잖아? 6개월 지나면 버리는 규칙은 이상해" → 시간 기반 폐기 규칙을 없애고, 거꾸로 "그동안 내 안목이 자랐으니 옛 기획을 새 기준으로 다시 분석해볼까?"를 제안하는 규칙으로 뒤집음
· "기획서는 민감 정보야" → 민감정보 규칙 추가
서브에이전트를 통한 검증
설계가 끝났을 때, 내가 만든 거라 내 사각지대가 있을 것 같았다. 그래서 내 맥락을 모르는 별도의 AI(서브에이전트) 둘을 띄워 검증시켰다.
"이 스키마만 보고, 다른 맥락 없이 네가 운영자라고 가정해. 뭐가 막히는지 진단만 해줘. 고치지는 마."
결과가 날카로웠다. 꽤 많은 부분을 수정하고 다 메워서 v0.5로 마감했다.
결과와 배운 점
솔직히 이 위키는 아직 운영 전, 설계를 마친 단계다. "주 N시간 절약" 같은 수치는 아직 없다. 이번에 남길 수 있는 건 결과물보다 과정 쪽이다.
무엇이 달라졌는지 (전 → 후)
· 자료 상태: 외딴 문서들, 연결 안 됨 → 기획을 가로지르는 패턴 라이브러리 설계
· 위키 운영 규칙: 없음(에이전트가 즉흥 처리해 짬뽕) → Ingest/Query/Lint 규칙이 박힌 스키마 v0.5
· 검증: 내 직감뿐 → 서브에이전트 검증을 거침
· 내 분석법: 머릿속에만 있던 것 → '렌즈'로 글로 정리
남은 건 스키마 와 페이지 양식 다섯 가지(작품/패턴/개념/의사결정/캐릭터)다.
돌아보면 이번에 내가 한 건 거창한 게 아니었다. 남이 만든 걸 찾아 흉내 내고, 에이전트와 같이 고치고, 못 미더운 부분은 다른 에이전트에게 검증시킨 것. 비개발자인 내가 부족함을 메우는 방식이 대략 이렇다.
중간에 두 번 막혔다. 한 번은 Ingest/Query/Lint가 뭔지 몰라서, 한 번은 패턴 승급 기준 같은 개념이 와닿지 않아서. 둘 다 클로드를 교수 삼아 묻고 답하면서 풀었다. 처음 만든 위키가 통째로 짬뽕이 됐을 때는 좀 허탈했는데, 그 실패 덕분에 3대 동작을 제대로 이해하게 된 것 같다.
막힐 때마다 클로드를 교수로 세우는 프롬프트를 자주 썼다.
"넌 지금부터 AI 전문가 교수님이야. 나를 학생이라고 생각하고 강의해줘. 그리고 내가 제대로 이해했는지 확인할 수 있게 중간중간 질문도 해줘."
도움 받은 글
· 안드레 카파시 LLM Wiki (원본 gist)
· write-post: AI 작업 로그를 사례글로 만들어주는 스킬 (GitHub, daht-mad/write-post)
· 스터디장 Giacomo님이 공유해주신 LLM Wiki 스키마 가이드
· 스터디장 엔지니어H님이 공유해주신 스터디 자료
