최근 많은 사람들이 클로드(Claude), 챗지피티(ChatGPT), 제미나이(Gemini) 같은 다양한 AI 도구를 사용하는 것이 일상이 되었습니다. 하지만 사용하는 AI 도구가 늘어날수록 우리는 늘 컨텍스트를 새로 전달해야 하는 번거로움을 겪게 됩니다. 즉, 본인의 상황과 맥락을 AI에게 매번 설명해야 했습니다.

앞서 기고한 “오늘 뭐부터 하지?” AI 비서 에이전트 만들어봤습니다에서는 흩어진 프로젝트 정보를 한곳에 모아, AI 비서가 매일 아침 프로젝트 현황과 Todo 우선 순위를 브리핑해 주는 시스템을 공유했습니다. 이러한 시스템으로 제 업무에 대한 맥락을 정리했지만, 정작 그 일을 수행하는 '나 자신'에 대한 맥락은 어떻게 효율적으로 정리할지가 고민이었죠.

당시 때마침 안드레 카파시(Andrej Karpathy)가 ‘LLM 위키’라는 아이디어를 제시했고, 그 개념을 저의 컨텍스트 정리에 적용해 보고자 했습니다. 그래서 옵시디언(Obsidian), 깃허브(GitHub), 클로드 코드(Claude Code)의 조합으로 나만의 세컨드 브레인인 LLM 위키를 구축했는데요. 이번 글에서는 그 과정과 LLM 위키 구축 경험에서 얻은 인사이트를 정리해 봤습니다.

미리 요점만 콕 집어보면?

여러 AI에게 매번 나의 상황과 맥락을 설명해야 하는 일은 결국 ‘흩어진 컨텍스트’와 '나 자신을 데이터로 다루는 시스템'이 없기 때문에 발생합니다.
옵시디언, 깃허브, 클로드 코드 CLI의 조합으로 안드레 카파시의 LLM 위키 아이디어를 제 자신만의 세컨드 브레인으로 적용해 구축해 보았습니다.
프로덕트 메이커(Product Maker)에게 개인 컨텍스트의 자산화는 단순히 일회성으로 컨텍스트를 정리하는 것에 그치지 않고, 장기적 관점에서 AI 활용의 생산성을 극대화하는 일에 가깝습니다.

나만의 LLM 위키를 만든 이유

1) 여러 곳에 흩어져 있는 컨텍스트

최근에는 다양한 AI 도구들이 저마다의 장단점을 가지고 있어, 사용자들이 여러 AI 도구를 이용하는 경우가 많습니다. 저 역시 서비스 기획이나 비즈니스 아이디어 정리는 클로드 챗의 프로젝트 기능을 사용하고, 가벼운 검색이나 이미지 생성은 챗지피티를, 코드 작업은 클로드 코드, 디자인은 클로드 디자인, 유튜브 요약과 글쓰기 보조 도구로는 제미나이 챗을 사용하고 있습니다.

이처럼 여러 AI 도구를 병행하다 보니 각 도구마다 저의 상황과 맥락을 반복해서 설명해야 했고, 컨텍스트의 일관성을 유지하기도 쉽지 않았습니다. 게다가 정보가 수집되고 정리되는 채널도 제각각이었습니다. 가벼운 메모는 구글 킵(Keep), 회의록은 노션(Notion), 업무 문서는 구글 워크스페이스(Google Workspace), 그리고 코드와 프로젝트 데이터는 깃허브(GitHub)에 흩어져 있는 식이었습니다.

2) 분산된 정보의 통합

그래서 저는 이번 LLM 위키 구축을 통해 구글 킵, 노션, 구글 스페이스, 깃허브 등 여러 곳에 흩어져 있는 모든 정보를 하나의 일관된 시스템으로 통합해 보기로 했습니다. 분산된 정보는 AI가 '나 자신'의 온전한 맥락을 파악하는 데 가장 큰 장애물이 되며, 이 상태로는 AI 에이전트의 생산성이 제한될 수밖에 없다고 생각했기 때문입니다. 따라서 모든 형태의 개인 데이터를 한곳에 모아 AI가 쉽게 접근하고 활용할 수 있는 세컨드 브레인 구축을 시작했습니다.

분산된 정보를 통합하고, 나만의 LLM 위키를 만들기 위한 도구를 고를 때 가장 중요하게 본 기준은 세 가지였습니다. 빠른 속도, 안정적인 동기화, 그리고 저의 워크플로우에 적합한 도구였습니다. 그렇게 여러 리서치와 테스트를 거쳐 결국 앞선 세 가지를 모두 만족하는 도구로 옵시디언을 선택하게 되었습니다. 사실 많은 이들이 옵시디언을 사용한다고 해서 같은 도구를 선택하고 싶진 않았습니다.

하지만 이런저런 도구를 테스트하며 꽤 많은 시간을 허비하고 나서, 결국 다른 사람들과 같은 선택을 하게 되었습니다. 결론적으로 옵시디언을 중심으로 LLM 위키를 구축하고, 백업 및 동기화는 깃허브 Private Repo, 위키 정리 작업은 클로드 코드가 처리하는 것으로 결정했습니다.

LLM 위키 구축 환경 세팅

1) 옵시디언 세팅과 핵심 플러그인

옵시디언을 설치하고 가장 먼저 한 작업은 볼트(Vault) 생성과 테마 설정이었습니다. 옵시디언에서 볼트란 노트가 저장되는 폴더를 의미합니다. 테마로는 미니멀(Minimal) 테마를 선택했는데요. 옵시디언 커뮤니티에서 가장 인기 있는 테마이기도 하고, 깔끔하면서도 플러그인을 통해 카드뷰, 갤러리뷰 같은 다양한 세팅이 가능한 테마입니다.

이후에 제가 옵시디언에 설치한 플러그인은 다음 표와 같습니다. 기본적으로 기기 간 동기화를 위한 깃(Git) 플러그인을 설치했고, 옵시디언 내에서 바로 클로드 코드를 사용하기 위한 터미널(Terminal) 플러그인도 설치했습니다. 추가로 템플릿 관리와 노트의 시각적 표현을 향상시키는 플러그인들도 설치했습니다.

아울러, 자료를 수집하는 경로도 옵시디언으로 일원화했습니다. 데스크톱 PC에서 웹 서핑하다 발견한 정보는 크롬 확장 프로그램인 ‘옵시디언 웹 클리퍼’를 통해 클릭 한 번으로 위키 볼트에 저장되도록 했습니다. 또한 모바일 기기에서도 웹 서핑이나 유튜브, 스레드, 카카오톡, 페이스북 등을 보다가 유익한 콘텐츠를 발견하면 ‘공유’ 기능을 통해 바로 옵시디언으로 전송되도록 했습니다.

만약 콘텐츠에 공유 버튼이 지원되지 않는 경우에는 화면을 캡쳐하거나, 파일을 다운로드하여 옵시디언 볼트 내 임시 폴더에 저장했습니다. 그리고 파일명에 자료를 저장한 의도를 간단히 남기고, 추후 클로드 코드가 일괄적으로 자료를 정리하도록 구성했습니다.

2) 깃허브 연동(Private Repo)

앞서 살펴본 것처럼 여러 기기에서 자료를 수집하고, 노트를 사용하기 때문에 옵시디언 볼트의 동기화가 필요합니다. 이를 위해 깃허브 Private Repo를 이용하면 레파지토리를 클라우드 백업 공간으로 활용하면서도 여러 기기에서 볼트를 동기화할 수 있습니다. 단, LLM 위키가 나의 거의 모든 데이터를 담고 있으므로 2단계 인증 등 보안을 엄격하게 관리해야 합니다.

깃허브 Private Repo를 통한 동기화 구조 <출처: ChatGPT 생성>

아이폰같은 모바일 환경에서는 직접적으로 Git 저장소를 사용할 수 없기 때문에 옵시디언 싱크나 Working Copy라는 앱을 이용해야 합니다. 여기서 저는 Working Copy를 사용하기로 했습니다. Working Copy는 클론(Clone) 기능은 무료이고 푸시(Push) 기능만 일회성 결제(약 $20)를 하면 되는데, 이는 옵시디언 싱크 구독을 1년 결제하는 것보다 장기적 비용 측면에서 저렴하다고 판단했습니다.

Working Copy 앱을 이용하려면 깃허브 개인 액세스 토큰(Personal Access Token)을 Fine-grained 권한으로 발급해 등록해야 합니다. 그러면 Working Copy로 클론한 폴더를 옵시디언 모바일에서 볼트로 열어 사용할 수 있습니다.

Working Copy 소개 <출처: https://workingcopy.app/>

3) 클로드 코드 CLI와 옵시디언 스킬 활용

옵시디언 볼트 안에서 클로드 코드, 코덱스 같은 AI 툴을 실행하면 위키의 작성과 수정, 삭제 등을 자동화할 수 있습니다. 이게 바로 LLM 위키의 핵심입니다. 즉, 사람이 직접 손으로 관리하던 이전의 위키와 달리 LLM 위키는 AI가 작성하고 관리하는 위키인 겁니다.

저는 기존부터 사용하던 웨이브 터미널(Wave Terminal)이라는CLI 툴로 클로드 코드를 실행하여 LLM 위키를 구축했습니다. 클로드 코드로 여기저기 흩어져 있는 자료를 LLM 위키에 입력하고, 그렇게 구축된 위키를 바탕으로 질문하거나, 주기적으로 위키를 정리하는 일을 모두 이 CLI 환경 안에서 처리하고 있습니다. 참고로, CLI 사용이 익숙하지 않은 분들은 클로드 데스크톱 앱에 있는 클로드 코워크(Claude Cowork)로도 동일한 작업을 할 수 있습니다.

클로드 코드를 사용할 때의 핵심은 옵시디언 볼트의 루트 디렉터리에 CLAUDE.md라는 파일을 두고, 새 세션(대화창)을 열 때마다 시스템 컨텍스트로 자동 주입되도록 만드는 것입니다. 이를 통해 CLAUDE.md가 사실상 위키 운영 매뉴얼로서 AI 작업의 일관성을 확보하는 역할을 하게 됩니다.

세션 시작 시 Hook을 통해 위키 운영 규칙과 index 즉시 참조 <출처: 작가>

다만, 가끔 AI가 CLAUDE.md에 적힌 운영 규칙을 제대로 보지 않는 경우가 있습니다. 이런 경우에는 SessionStart Hook을 걸어 세션 시작 시 강제로 운영 규칙을 주입하거나, 위키 index를 즉시 참조하도록 할 수 있습니다. 이를 통해 새로운 대화를 시작하는 경우에도 AI가 별도의 검색 없이 위키 운영 규칙과 나에 대한 질문에 즉답을 할 수 있게 됩니다.

또한 추가로 클로드 코드에 옵시디언 스킬들을 설치했습니다. 옵시디언 볼트의 일괄 작업을 돕는 obsidian-cli와 콜아웃, 임베드, 프로퍼티 같은 옵시디언 특화 문법을 다루는 obsidian-markdown, 그리고 웹페이지에서 깔끔한 본문만 추출해주는 defuddle 같은 스킬들이 있습니다. 이러한 스킬들은 옵시디언 특화 문법이나 LLM 위키 운영에 최적화된 복잡한 작업이 필요할 때 유용합니다.

LLM 위키 설계와 활용하기

1) 카테고리 설계

이제 LLM 위키 환경 세팅이 끝났으니 구조를 설계할 단계입니다. 처음부터 나에 대한 모든 컨텍스트를 한 번에 만들려고 하면 어렵습니다. 그래서 저는 다음과 같은 프롬프트를 작성하여, 클로드 코드에게 위키 구조를 설계하도록 했습니다.

내가 누구이고, 어떤 배경과 역사를 가졌으며, 어떤 사람들과 어떤 환경에 있는지, 어떤 생각과 철학을 가지고 있는지, 어떤 자산을 가지고 있는지, 어떤 것들을 메모했고, 어떤 지식과 정보를 가지고 있는지 등을 기록하고 연결할 수 있는 위키 구조가 필요하다. 안드레 카파시의 아이디어를 기반으로 나에 대한 핵심 정보들을 담을 수 있는 LLM 위키 구조를 설계해줘.

이후 클로드가 제안해 준 카테고리를 기반으로 저에게 맞는 위키 구조를 만들어 갔습니다. 현재는 나의 정체성(Identity), 생각(Thoughts), 목표(Goals), 역사(History), 사람(People), 자산(Assets), 일(Works)로 카테고리를 분류하여 사용하고 있습니다.

2) 자료 인입(Ingest)

저는 안드레 카파시의 LLM 위키 개념을 클로드 코드에 넘겨, ingest, query, lint 스킬을 만들도록 했습니다. 그중에서 /ingest는 새로 수집된 자료를 읽고, 적절한 위키 페이지로 합성하거나 연결하는 작업을 진행합니다.

자료 인입을 위해 저는 먼저 기존에 가지고 있던 노션과 구글 킵 노트를 ingest 했습니다. 즉, 노션과 구글 킵에서 백업한 파일을 raw 폴더에 넣고 /ingest 스킬을 사용했습니다. 여기에 민감 정보를 분리하는 과정을 추가했는데요. 예를 들어, 비밀번호, 카드번호, 주민등록번호 같은 정보가 위키에 무분별하게 삽입되는 것을 방지하고자 했습니다.

이를 위해 클로드 코드가 민감 정보 패턴을 정규식(Regex)으로 감지해 위키에 삽입 시 마스킹(Masking) 처리를 하도록 했습니다. 다만, 이러한 정규식 감지는 완벽하지 않기 때문에(ex. 주민번호에 공백이 들어간 경우 등) 1차적인 안전장치로만 사용하고, 다음에 살펴볼 Lint 작업으로 재점검하거나, 본인이 직접 검토해야 합니다.

3) 위키 점검 및 정리(Lint)

/lint는 위키의 상태를 점검하는 작업입니다. 민감한 데이터나 모순된 정보, 어떤 노트에서도 연결되지 않은 고아(Orphan) 페이지, 다른 노트에서 언급만 되고 실제 파일이 없는 페이지 등을 잡아줍니다. 저는 클로드의 스케쥴 기능을 활용해매일 자동으로 린트가 돌도록 했습니다.

클로드의 스케쥴 기능을 사용하면, 따로 신경 쓰지 않아도 매일 위키의 깨진 링크나 정합성 문제를 자동으로 정리할 수 있습니다. 비록 클로드가 중간에 Lint의 방향을 물어보는 경우가 있기도 하지만, 클로드의 스케쥴 기능으로 Lint 작업을 자동화하면 LLM 위키의 관리에 들어가는 비용을 줄일 수 있습니다.

4) LLM 위키의 활용

/query 스킬은 위키 전체를 컨텍스트로 깔고 AI에게 질문하는 워크플로우입니다. 이를 통해 AI에게 질문을 던졌을 때 받는 '일반론적 답변'과는 결이 다른 답변을 받을 수 있습니다. 이는 AI가 제 생각과 철학, 주어진 상황과 배경, 현재 운영 중인 비즈니스 환경, 진행 중인 프로젝트 목록과 우선순위까지 모두 알고 있기 때문입니다.

또한 LLM 위키에 옵시디언을 활용하면 그래프 뷰(Graph View) 기능을 사용할 수 있습니다. 그래프 뷰는 노트 간의 링크를 시각적으로 보여주는 기능인데요. 어떤 주제가 어떤 내용들과 연결되는지를 확인해 볼 수 있습니다.

실제 사용 후기와 한계는?

1) 컨텍스트를 이해한 AI의 답변

요즘 저는 비즈니스를 위한 법인 설립과 다양한 프로젝트를 동시에 진행하고 있습니다. 그 과정에서 결정해야 할 일이 정말 많았는데요. "지금 법인을 설립하는 게 맞을까", "동시 진행 중인 프로젝트가 너무 많은데 어디서 힘을 빼야 할까", "이 사업 라인을 잠시 보류하는 게 맞을까"처럼 답이 하나로 떨어지지 않는 질문들이 있었습니다. 그리고 LLM 위키를 활용하여 저의 철학, 직전 1년 회고, 현재 진행 중인 프로젝트의 부담, 자녀 양육 사이클까지 고려한 맞춤형 답변을 받을 수 있었습니다.

이처럼 LLM 위키를 구축하고, AI에게 나의 컨텍스트 전부 전달함으로써 AI의 답변 품질이 '일반론적인 답변'에서 '나의 상황에 최적화된 답변'으로 바뀐 것을 체감할 수 있었습니다. 아울러 이전 글에서 만들었던 AI 비서 정대리도 LLM 위키를 활용하여 저의 의사결정 도우미로서 한 단계 진화시킬 수 있었습니다.

2) LLM 위키의 한계점과 고려 사항

다만, 기대만큼 매끄럽지 않았던 부분도 있었습니다. 저의 경우에는 AI가 이미지에서 텍스트를 읽어 위키에 ingest할 때 부정확했던 사례가 많았습니다. 개인적으로 직접 손으로 쓰거나 다이어그램을 그린 메모지 사진과 노트 캡처 같은 이미지 기반 자료를 많이 가지고 있었는데요. 이런 자료를 Ingest 한 후 직접 위키를 검토해 봤을 때 사실관계가 어긋난 부분이 상당히 많았습니다. 결국 제가 직접 관련된 항목을 하나하나 확인하며 다시 손으로 고쳐야 했습니다.

아울러 위키가 점점 커질수록 그 안에 담기는 민감 정보도 더 많아진다는 문제가 있었습니다. 비록 마스킹 처리를 위한 목적이라도 비밀번호, 카드번호 같은 개인 정보를 AI에게 전부 넘겨야 하고, 민감 정보의 마스킹 처리가 제대로 됐는지도 일일이 확인하기 전까지 확신하기가 어려웠습니다.

또한 동기화를 위해 깃허브의 비공개 Repository를 사용하지만, 그렇다고 모든 보안 위험이 사라지는 것도 아니었습니다. 만약 깃허브 계정이 해킹되면 나의 모든 정보가 한꺼번에 털리는 문제가 생길 수도 있습니다. 따라서 기본적인 2단계 인증, 토큰(Token) 회전 같은 보호 장치를 반드시 설정해 두어야 합니다.

마지막으로 협업 시나리오에서도 또 다른 한계가 있었습니다. 나만의 LLM 위키에는 개인 정보가 많이 담겨 있기 때문에 팀과 공유하기가 어려웠습니다. 결국 팀과 공유할 컨텍스트는 팀 LLM 위키를 다시 만들어야 하는 이중 작업이 생기게 됩니다. LLM 위키에서는 단일 출처(Single source of truth, SSOT)를 원칙으로 표방하지만, 일부 정보는 결국 두 곳에 두게 되는 모순이 발생할 수밖에 없었습니다.

마치며

이상으로 안드레 카파시의 아이디어를 적용하여 나만의 세컨드 브레인인 LLM 위키를 만든 과정과 후기를 정리해 봤습니다. 처음에는 단순히 AI에게 매번 나의 컨텍스트를 설명하는 것이 답답해서 시작한 작업이었지만, 만들고 보니 컨텍스트 정리의 자동화와 AI 답변 품질의 향상이라는 효과를 체감할 수 있었습니다.

프로덕트 메이커의 입장에서 볼 때, LLM 위키의 구축은 단순한 일회성 프로젝트라기보다 장기적 관점에서 자신의 컨텍스트를 자산처럼 쌓아가는 과정이라고 생각합니다. 그리고 그렇게 쌓여진 나만의 컨텍스트를 통해서 AI 도구 활용의 생산성을 극대화할 수 있을 겁니다.

다만 이번에 제가 수행한 LLM 위키 구축 방식이 모두에게 정답은 아닐 것입니다. 특히 옵시디언이라는 도구는 손에 익기 전까지 학습 비용이 있고, 기기 간 동기화 방식도 다양하게 있기 때문입니다. 아울러 업무에 필요한 컨텍스트 정리의 수준도 개인마다 다르기 때문에 세컨드 브레인 구축에 있어 어떤 특정한 정답은 없다고 생각합니다.

마지막으로 한 가지 강조하고 싶은 점은 세컨드 브레인 구축 시 처음부터 완벽한 구조를 만들겠다는 욕심을 내려놔야 한다는 것입니다. 위키의 카테고리나 자동화 워크플로우, 동기화 셋업을 한꺼번에 완벽하게 만들겠다고 하다 보면 중간에 포기하게 될 수도 있기 때문이죠. 따라서 점진적으로 개선해 나간다는 느낌으로, 나만의 세컨드 브레인 구축을 시도해 보시길 바랍니다.