바이브 코딩, AI Agent 계의 락스타 안드레 카파시(Andrej Karpathy)의 "LLM 위키"라는 개념이 소개된지 2주가 넘었습니다.
처음 카파시의 LLM 위키라는걸 접했을 때 그리 어려운 개념은 아니라고 생각했습니다. 파편화된 문서, 메모, 일정 등을 LLM으로 분류하고 상호 연관관계를 파악해 위키 형태(구조적 md 파일)로 저장해두겠다는 것이니까요. 실제로 위키에 파일을 등록하면 결과가 md 파일로 등록되고, 위키 폴더를 옵시디언에서 읽어와 그래프 형태로 볼 수도 있습니다.
그리고 LLM 위키라는 것이 완전히 새로운 개념은 아니기도 합니다. 제가 지난번 커뮤니티에 RAG 관련된 글을 올렸을 때, "향상된 LLM 성능 자체를 활용하는 것이 더 효과적"이라는 조언이 댓글로 달렸을 정도였으니까요.
다만 현재 LLM 성능이 굉장히 향상되고, 이를 입맛대로 활용하기 좋은 도구 환경(스킬, 하네스 등) 갖춰진 상태에서 카파시의 제안은 매우 시의적절하고, 직관적이고, 보편적인 기술에 기초하기 때문에 사람들이 주목할 만 하다고 봅니다. 비록 카파시의 후광효과가 있긴 하지만요.
저는 주로 메모 관리나 개인적으로 만드는 클로드 코드 프로젝트, 그리고 업무에 사용되는 문서/일정/task 관리에 LLM 을 사용하려고 짬짬이 테스트를 해보고 있습니다. 그래서 카파시의 LLM 위키가 저한테도 정말로 효과적일지 몇 가지 실험을 해보고 싶었습니다.
첫째, LLM 위키가 RAG 보다 성능이 더 나을까?
둘째, LLM 위키가 내 요구사항을 구현하기에 적합한 기술인가?
셋째, LLM 위키를 어떤 형태로 구현해야 편리하면서도 효율적인 지식베이스 관리툴로 만들 수 있을까?
특히 메모나 개인 프로젝트, 업무에 사용되는 파일들을 분류하고 내용을 검색하는 방법이 필요해서, 기존에는 전통적인 의미 기반 검색 방법인 RAG 를 이리저리 만져봤습니다. 하지만 RAG 는 AI Agent 에 붙여서 사용하기에는 기술적으로도 복잡하고, 원하는 성능을 위해 튜닝해야 할 것도 많지요. 하지만 "LLM 위키"를 사용한다면? 과연 기존 RAG 를 사용하는 것보다 간편하게 내 요구사항을 만족할 수 있을까? 이 점을 확인하기위해 LLM 위키 스킬을 직접 구현하고 테스트 해봤습니다.
준비 과정
카파시의 LLM 위키의 초안은 아래 링크에 있는, llm-wiki 라는 지침 파일로 되어 있습니다.
- https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
이것만으로도 동작은 하지만, 보통 이걸 자신의 요구사항에 맞게 수정해서 사용하는 것 같습니다. 저는 LLM 위키를 제가 실험적으로 해보는 여러 클로드 코드 프로젝트에 적용하기 쉽도록 스킬 형태로 만들었습니다. 카파시의 초안을 바탕으로 테스트를 하면서 제가 원하는 기능을 추가하고 기본적인 오류들을 수정했습니다. 테스트는 Gemini CLI 에서 진행했습니다.
- https://github.com/godstale/llm-wiki
그리고 RAG 검색 대조군을 만들기 위해 준비를 했습니다. 제가 개인적으로 RAG 를 만들어서는 성능, 안정성 등을 담보할 수 없으니... NotebookLM 에 동일한 파일을 업로드하고 같은 질문을 해서 답변을 확인하는 방식으로 비교했습니다.
테스트를 위한 원본 파일(raw 파일)은 제가 가진 Google Keep 메모 파일들입니다. 이 파일들은 Google Keep 에서 백업 받아 약 500 개가 넘는 json 텍스트 파일로 되어 있고, 개별 파일들은 상호 연관 관계에 대한 고려 없이 작성된 독립된 메모입니다. 메모의 사이즈도 간단한 한 두 줄의 텍스트부터 책 한 챕터의 분량까지 다양합니다.
테스트 설계
이제 이 파일들을 업로드 후 테스트를 위해 테스트 케이스를 작성했습니다. 500+ 개의 메모에 대한 검색과 추론, 답변이 적절한지 테스트 했습니다.
1. 기본 검색
- 파일 하나에 들어있는 내용을 물어보는 간단한 질문은 어느쪽이든 잘 처리하기 때문에 비교가 무의미
2. 의미 기반 검색 + 추론
- 매우 간단한 단어와 여기에서 파생되는 맥락을 감안해서 검색할 수 있는지를 테스트
- 메모에서 연관 관계를 바탕으로 여러 시도를 했지만 대부분은 잘 수행을 해서... 특별히 어려운 문제를 선택
- 예를 들어, 메모 중 "조선 삼대 명주", "화이트 와인"에 대한 내용을 담고 있는 메모가 있습니다. 이때 "주변에 추천할만한 술을 찾아줘" 라는 질문을 해서 "술"이라는 의미를 기반으로 내용을 검색할 수 있는지 확인합니다. 검색 결과를 바탕으로 사용자 질문에 대한 답변을 생성하는지 확인니다. 단순 키워드 검색으로는 결과가 너무 많아 확인이 힘들 것 같은 질문입니다.
3. 기타 3~4개의 파일에 나누어 담겨진 내용을 모두 확인 + 추론을 통해 답변을 생성
- 테스트를 위해 미리 작성된 텍스트 파일을 500+ 메모에 포함
- https://github.com/godstale/LLM-WiKi/tree/main/test
- 질문지
- 베트남 여행 잔여 예산 계산 : 4개 파일의 숫자를 모두 읽고 산술 추론해야 정답 도출 가능
- AI 개인 프로젝트 기술 격차 분석 : 4개 파일의 내용을 종합해서 추론
- 트레킹 장비 부족 분석 : 3개 파일의 세부 내용을 모두 확인 후 재구성
- 이번 주 집중 작업 스케줄 최적화 : 4개 파일의 내용을 종합해서 추론
- 회의 일정 조정 (캘린더 + 회의실 + 연락처 고려) : 4개 파일의 내용을 종합해서 추론
테스트 결과 종합
LLM wiki/RAG 둘 다 500 개가 넘는 메모를 처리하는데 별 부족함이 없었고 대부분 답변도 유사하게 나왔습니다.
- 테스트 결과는 너무 길어서... 아래 링크를 참고하세요.
- https://github.com/godstale/LLM-WiKi/blob/main/test/Test_Result.md
- 2 번 테스트 "주변에 추천할만한 술을 찾아줘" 라는 질문에
- LLM 위키는 "조선 삼대 명주", "리즐링 와인", "위키의 맛집 및 모임 기록"에서 발췌해서 답변 함. 특히 술과는 직접적인 관련이 없는 맛집 메모에서 특정 상황에 맞는 술(맥주)을 추천함.
- 반면 NotebookLM 답변은 "리즐링 화이트와인이 짧게 기록... 구체적으로 추천할 만한 술에 대한 정보가 없습니다"
- 3 번 테스트는 3~4개의 파일의 내용을 바탕으로 답변을 위한 추론이 포함되어야 함
- 답변 자체는 다르지만 LLM 위키 / NotebookLM 둘 다 핵심 내용을 포함하고 있으므로 유사한 성능
- 답변의 세부 내용에서 LLM 위키가 좀 더 나은듯 하지만 주관적인 견해이며, 큰 차이는 아니라 판단됨
그래서, 테스트를 해보니 LLM 위키가 쓸만하더냐?
- 개인 규모의 지식 베이스 구축할 때 충분한 성능
- (메모나 자료정리, AI Agent 프로젝트에서 산출물/메모리 관리 등에 적합해 보임)
- RAG 를 Agent 에 붙이기 위해 구현/설정/튜닝을 하는거 보다 LLM 위키를 사용하는 것이 간단하고 효율적
- NotebookLM(RAG) 와 단순 비교해도 뒤떨어지지 않는 성능. 하지만 NotebookLM 이 쓸모 없다가 아니라, 상호 보완하는 관계로 사용하면 좋을 듯
- (유튜브 영상 요약과 같이 NotebookLM 으로 전처리된 데이터 -> LLM 위키로 저장)
- 특히 LLM 위키를 내 입맛에 맞게 수정하기 좋음. 이미 생성된 위키를 정리/확장도 손쉬움. 그냥 LLM 시키면 됨.
- 하지만 느림. 500+ 메모를 위키에 등록하는데 20분 넘게 걸림...
- 위키 검색에도 시간이 꽤 걸림.
- 일반 메모 앱 처럼 사용자가 원할 때 즉각적인 응답을 주기 어려움
이런점은 감안해야 합니다
- 처음 데이터를 처리할 때 notebooklm 대비 시간이 꽤 걸리는 편
- 위 테스트는 Gmail/캘린더/TODO/메모와 같은 개인 데이터로 진행 했음
- 복잡한 수식이나 이미지가 담긴 전문적인 리포트, 산출물 처리는 모르겠음...
- 이런 자료는 RAG 도 해결하기 쉽지 않은 문제라 생각함
- 업무용으로 활용하기 위해서는 검색의 맥락이 복잡하고 데이터가 방대해서
- [팀 구조/업무 프로세스/프로젝트 관리...] 와 같은 정보와 결합해야 하지 않을까
- 따라서 온톨로지나 기타 기법들이 적용되어야 효율성을 판단할 수 있을 것 같음
- (이 부분은 개인적으로 관심있는 주제라 추후 테스트 해 볼 예정)
제 개인적으로는 "LLM 위키" 가 굉장히 만족스러웠습니다. 어떤 클로드 코드 프로젝트를 하든 기본 스킬로 설치해서 Agent 가 중간중간 만드는 데이터나 결과물을 관리하는데 좋을 것 같습니다. 그리고 위키 데이터는 백업하거나 다른 프로젝트에서 생성한 위키를 가져와 합치기도 용이합니다. 이런 용도로 만든 wiki-hub 스킬이 있는데, 요건 내용을 보강해서 추후 포스트를 올리겠습니다.
- https://github.com/godstale/WiKi-Hub
그리고 업무용으로도 확장할 수 있도록 LLM 위키 + 온톨로지 기능도 구현해서 테스트 해 볼 예정입니다. 테스트가 끝나면 결과를 포스트로 올리겠습니다!!
저는 업무랑 일상 따로 나누고 또 제가 조사한 정제한 내용들을 나눠서 쓰고 있고 요즘 바이브 코딩하면서 직면한 문제들, 또 해당 문제들을 어떻게 해결했는지도 자동으로 기록하게 해서 중간 중간에 생각 정리해야 할 때 claude나 codex 연결해서 물어보고 있는데 꽤 실용적이고 제가 원하는 답변을 바로 바로 받을 수 있어서 너무 잘 쓰고 있습니다.
아직 데이터가 그렇게 쌓이진 않아서 시도는 안해봤는데, 온톨리지 구성하실 때 graphify 한번 보시는걸 추천드립니다.
graphify 가 유툽에 추천이 많더라구요. 제가 생각하고 있는 방향과는 좀 다르긴 한데, 참고해서 온톨로지 기능 확장을 해보겠습니다!
이것만 맞게 진행해도 쓸만하죠. 각자 맞는 방식을 찾아보는게 좋죠.