프롤로그: AI에게 질문만 할 것인가, AI와 지식을 쌓을 것인가

AI 대화는 왜 자산이 되지 못하는가

우리는 이제 모르는 것이 생기면 검색창보다 먼저 AI를 연다. 보고서 초안을 부탁하고, 책을 요약하게 하고, 코드 오류를 묻고, 사업 아이디어를 검토한다. 답변은 빠르고 그럴듯하다. 때로는 놀랄 만큼 유용하다.

그런데 며칠 뒤 같은 일을 다시 시작하면 이상한 일이 벌어진다. 우리는 또 같은 배경을 설명한다. "이 프로젝트는 이런 목표가 있고, 지난번에는 이런 선택지를 검토했고, 결국 이 방향을 골랐어." AI는 친절하게 다시 듣는다. 하지만 우리 입장에서는 반복이다.

ChatGPT 대화 기록은 남아 있다. Claude Code나 Cursor 같은 에이전트 세션도 흔적을 남긴다. 그러나 그것은 대부분 "그때 무엇을 답했는가"의 기록이다. 다음 작업에 바로 재사용할 수 있는 지식 구조는 아니다. 같은 프로젝트의 배경, 이전 판단, 버린 선택지, 트레이드오프, 회의에서 합의한 내용은 새 세션마다 다시 주입해야 한다.

이 비용을 이 책에서는 컨텍스트 재주입 비용이라고 부르겠다. AI를 오래 쓸수록 이 비용은 작지 않다. 하루에 몇 번, 여러 프로젝트에서, 여러 도구를 오가며 반복된다. 더 큰 문제는 우리가 무엇을 이미 알고 있는지조차 점점 흐려진다는 점이다.

AI는 답변을 잘 만든다. 하지만 답변이 곧 지식 자산이 되지는 않는다.

매번 처음부터 시작하는 사람

AI에게 질문만 하는 사람은 매번 처음부터 시작한다.

어제 읽은 논문을 오늘 다시 설명해야 한다. 지난주 고객 인터뷰에서 얻은 통찰을 새 채팅창에 다시 붙여 넣어야 한다. 지난달 사업 전략 회의에서 버린 선택지를 다시 검토한다. AI는 지치지 않지만, 사람은 지친다.

이 방식은 겉보기에는 생산적이다. 질문하면 답이 나오기 때문이다. 그러나 지식은 축적되지 않는다. 대화는 쌓이지만 구조는 생기지 않는다. 파일은 늘어나지만 지도가 생기지 않는다. 수십 개의 링크와 PDF와 회의록이 있어도 "그래서 내가 이 주제에 대해 무엇을 알고 있지?"라는 질문에는 쉽게 답하지 못한다.

많은 사람이 이 문제를 노트앱으로 해결하려 한다. Notion, Obsidian, Google Docs, 사내 위키, 북마크 도구를 쓴다. 처음에는 열심히 정리한다. 폴더를 만들고, 태그를 붙이고, 링크를 건다. 하지만 시간이 지나면 정리가 밀린다. 새 자료는 계속 들어오고, 기존 문서는 낡는다. 비슷한 페이지가 중복되고, 예전 결론과 새 결론이 충돌한다.

문제는 도구가 아니다. 유지보수 비용이다. 지식 관리에서 가장 어려운 일은 기록을 시작하는 것이 아니라 계속 살아 있게 만드는 것이다.

파일 업로드와 RAG가 해결하지 못하는 것

물론 AI 도구도 발전했다. 파일을 업로드하면 요약해준다. NotebookLM 같은 도구는 여러 자료를 기반으로 답변한다. 검색형 AI는 웹을 뒤져 최신 정보를 가져온다. RAG는 원문에서 관련 조각을 찾아 답변에 붙이는 방식으로 기업 지식 검색에 널리 쓰인다.

이 도구들은 유용하다. 특히 원문을 빠르게 찾고, 여러 문서에서 관련 내용을 뽑아 답을 만드는 데 강하다. 하지만 이 책이 다루는 문제와는 조금 다르다.

파일 업로드는 대개 세션 단위다. 오늘 올린 파일을 읽고 오늘 답한다. 그 답변이 내 장기 지식 체계에 자동으로 통합되지는 않는다. NotebookLM이나 검색형 AI도 원문을 잘 찾아주지만, 시간이 지날수록 내 지식을 정리하고 연결하고 갱신하는 운영 체계는 아니다.

RAG도 마찬가지다. RAG는 Retrieval-Augmented Generation의 약자로, 질문이 들어오면 문서에서 관련 조각을 검색해 답변에 참고시키는 방식이다. 이 방식은 많은 문서에서 필요한 근거를 찾는 데 강하다. 하지만 질문할 때마다 원문 조각을 다시 불러온다. 조각, 즉 청크 단위로 가져오기 때문에 넓은 맥락이 잘릴 수 있다. 무엇보다 "내가 이미 무엇을 알고 있는가"에 대한 지도는 자동으로 자라지 않는다.

검색은 답을 찾는다. 위키는 지식을 축적한다. 이 차이가 중요하다.

LLM Wiki라는 전환

Andrej Karpathy가 제안한 LLM Wiki 아이디어는 단순하지만 강력하다. AI를 "질문에 답하는 존재"로만 쓰지 말고, "원문을 읽고 위키를 유지보수하는 지식 관리자"로 쓰자는 것이다.¹

여기서 위키는 사람이 손으로 하나하나 작성하는 노트 모음이 아니다. 원문 자료를 넣으면 LLM이 읽고, 핵심 내용을 정리하고, 관련 개념 페이지를 만들고, 기존 페이지를 갱신하고, 서로 링크한다. 새 자료가 들어오면 새 페이지 하나만 만드는 것이 아니라 이미 있던 여러 페이지를 함께 고친다. 모순을 발견하면 표시하고, 오래된 주장을 찾고, 출처 없는 내용을 점검한다.

핵심은 역할의 전환이다.

기존 방식에서는 사람이 노트를 관리하고 AI에게 질문한다. LLM Wiki에서는 사람이 자료를 고르고 방향을 정하며, AI가 위키를 관리한다. 사람은 편집장이고, AI는 지치지 않는 지식 관리 실무자다.

이 구조는 특정 제품이 아니다. 하나의 패턴이다. 복잡한 SaaS가 없어도 된다. 기본 구조는 단순하다.

• raw/: 원문을 보관하는 공간이다. 웹 문서, PDF, 회의록, 책 챕터, 고객 인터뷰, 유튜브 자막이 들어간다. 원문은 수정하지 않는다.

• wiki/: AI가 만든 지식층이다. 개념, 인물, 프로젝트, 책, 논문, 의사결정 페이지가 Markdown으로 쌓인다.

• CLAUDE.md 또는 AGENTS.md: AI에게 주는 운영 규칙이다. 어떤 형식으로 페이지를 만들지, 출처를 어떻게 남길지, 모순을 어떻게 처리할지 적는다.

• index.md와 log.md: 전체 지도를 보여주고, 어떤 일이 있었는지 기록한다.

그리고 이 위에서 세 가지 루틴이 돈다. 새 자료를 넣는 ingest, 위키에 질문하는 query, 위키의 건강을 점검하는 lint다. 여러 실전 사례에서도 이 세 루틴이 LLM Wiki 운영의 기본 축으로 반복된다.²

지식은 답변이 아니라 페이지로 남아야 한다

AI 시대의 지식 관리는 질문을 잘하는 기술만으로 끝나지 않는다. 좋은 질문은 중요하다. 하지만 더 중요한 것은 좋은 질문과 답변이 사라지지 않게 만드는 것이다.

예를 들어 한 스타트업 대표가 고객 인터뷰 20개를 AI에게 요약시켰다고 하자. 그 요약이 채팅창에만 남아 있다면 다음 달 제품 기획 회의에서는 다시 찾아야 한다. 반대로 LLM Wiki에 들어가면 상황이 달라진다.

고객 인터뷰 원문은 raw/에 남는다. AI는 wiki/customers/나 wiki/projects/에 고객군별 페이지를 만들고, 반복되는 불만을 개념 페이지로 정리한다. "가격 저항", "온보딩 실패", "기능 요청", "경쟁사 비교" 같은 페이지가 생긴다. 이후 새 인터뷰가 들어오면 기존 페이지가 갱신된다. 어떤 주장이 몇 명의 고객에게서 나왔는지, 어느 시점 이후 바뀌었는지 추적할 수 있다.

이제 질문은 달라진다.

"이 인터뷰 요약해줘"가 아니라 "지난 3개월간 온보딩 실패 패턴이 어떻게 바뀌었지?"라고 묻는다. AI는 단발 요약자가 아니라 누적된 지식의 안내자가 된다.

개인에게도 마찬가지다. 일기와 회고, 독서 노트, 건강 기록, 공부 자료, 글쓰기 아이디어가 위키로 쌓이면 나에 대한 장기 패턴을 볼 수 있다. 연구자에게는 논문과 개념의 지도, 작가에게는 책 기획용 자료망, 팀에게는 살아 있는 내부 위키가 된다.

복리로 쌓이는 사람

이 책의 핵심 문장은 단순하다.

AI에게 매번 물어보는 사람은 매번 처음부터 시작한다.
AI와 함께 위키를 쌓는 사람은 지식이 복리로 쌓인다.

복리라는 말은 과장이 아니다. 지식은 연결될 때 가치가 커진다. 블로그 글 하나, 회의록 하나, 책 챕터 하나는 작은 단위다. 하지만 그것이 개념 페이지와 프로젝트 페이지와 의사결정 기록으로 연결되면 다음 작업의 출발점이 높아진다.

처음에는 위키에 페이지가 몇 개뿐이다. 그래서 효과가 작아 보인다. 하지만 자료가 들어올수록 같은 질문에 대한 답이 더 좋아진다. 새 자료가 기존 페이지를 두껍게 만들고, 기존 페이지가 새 질문의 맥락이 된다. 질문의 답변이 다시 페이지로 저장되면 다음 질문은 그 위에서 시작한다.

이것이 LLM Wiki의 복리 효과다.

반대로 대화 기록만 쌓는 방식은 단리도 되기 어렵다. 대화는 많아지지만 재사용 비용도 함께 커진다. 검색해서 찾을 수는 있지만, 구조화되어 있지 않으면 다시 읽고 다시 판단해야 한다.

이 책에서 만들 것

이 책은 Obsidian 사용법 책이 아니다. Obsidian은 좋은 도구다. Markdown 파일을 다루기 쉽고, 링크와 그래프를 볼 수 있으며, 로컬 파일 기반이라 LLM Wiki와 잘 맞는다. 하지만 핵심은 Obsidian이 아니다.

이 책은 AI 시대의 지식 관리 운영체제를 만드는 책이다. Markdown과 폴더 구조, schema 파일, AI 에이전트를 결합해 개인과 팀이 함께 운영할 수 있는 지식 위키를 만드는 법을 다룬다.

앞으로 우리는 다음 질문에 답할 것이다.

• raw 자료와 wiki 지식층을 어떻게 나눌 것인가

• AI에게 어떤 운영 규칙을 줄 것인가

• 웹 문서, PDF, 회의록, 책, 유튜브 자막을 어떻게 ingest할 것인가

• 개념 페이지, 인물 페이지, 프로젝트 페이지, 의사결정 기록을 어떻게 설계할 것인가

• 위키에 어떻게 질문하고, 좋은 답변을 다시 지식으로 저장할 것인가

• 오래된 주장, 모순, 중복, 출처 없는 내용을 어떻게 점검할 것인가

• 개인의 두 번째 뇌를 팀 위키, 제품 문서, 리서치 DB로 어떻게 확장할 것인가

처음부터 완벽한 시스템을 만들 필요는 없다. 작은 폴더 하나, 원문 몇 개, schema 파일 하나로 시작하면 된다. 중요한 것은 AI에게 답변만 요구하는 습관에서 벗어나는 것이다.

AI는 더 이상 일회성 답변 기계로만 남을 필요가 없다. 제대로 된 구조를 주면, AI는 우리가 읽은 것과 판단한 것과 배운 것을 정리하고 연결하는 지식 관리자가 될 수 있다.

이제 질문은 이것이다.

AI에게 계속 물어보기만 할 것인가.
아니면 AI와 함께, 시간이 지날수록 강해지는 두 번째 뇌를 만들 것인가.

참고

¹Andrej Karpathy, LLM Wiki

²Karpathy 아이디어를 한 달 굴려보고 만든 LLM 위키 오픈 소스