이 글은 편의상 반말로 작성되었습니다.
문서화는 예전부터 중요하게 생각했던 개념이고, 지금도 이에 대한 관심을 꾸준히 가지고 있다.
특히 2024년 구요한 교수님의 세션을 보고 큰 영감을 얻었고, 마크다운으로 개인 문서를 관리하는 것이 대세가 되겠다는 생각이 들어
Obsidian과 AI Agent를 기반으로 개인 문서 관리를 해 오고 있었다.
하지만 솔직히 말하면 이를 제대로 쓰고 있다고 하기는 힘들었던 것 같다. 꾸준히 이를 기록하고 요약해서 압축시키는 것은 어느 정도 했지만, 이를 Graph나 태그를 활용하여 엮거나, 우선순위를 두는 등 진정한 Second Brain으로 작동하지는 않고 있었다. 이런 관계 기반 문서화는 많은 곳에서 강조되었지만 나에게 와 닿지 않은 부분이기도 했다.
물론 이 상태에서도 내 문서는 적지 않은 지식을 담고 있었다고 생각한다. 하지만 최근 3개월 정도 사이에 내 문서에 큰 영향을 준 두 가지가 있었다. 하나는 Karpathy가 던진 LLM Wiki라는 개념이고, 다른 하나는 AI 트렌드를 따라가기 위해 시작한 TLDR 뉴스레터다.
이 두 가지는 내 Obsidian과 정보 소비 방식을 꽤 많이 바꿔 놓았고, 더 나아가서 내 Obsidian Vault의 밀도도 높이는 계기가 되었다.
이번 글에서는 이에 대해 간단히 적어 보려고 한다.
LLM Wiki
LLM Wiki의 아이디어는 단순하다. 노트를 사람만 쓰는 게 아니라, LLM에게도 직접 읽고 쓸 수 있는 공간을 주자는 것이다. 대신 사람이 쓴 원본과 AI가 만지는 영역을 명확히 분리한다. Karpathy가 제안한 원래 흐름은 새 문서가 들어오면 그걸 읽어 정리하고(Ingest), 질문이 들어오면 그 정리본 기반으로 먼저 답하고(Query), 주기적으로 위키 자체의 정합성을 점검하는(Lint) 세 개의 루프를 도는 것이다.
이 개념이 공개된 이후 수많은 파생 도구와 오픈소스가 만들어졌다. 하지만 이것저것 살펴봐도 결국 가치 있는 건 원본 개념 그 자체라는 생각이 들었다. 그래서 남이 만든 도구를 따라가기보다, Karpathy의 Gist를 기준으로 내 Obsidian에 맞게 발전시키는 방향을 선택했다.
사람이 본문을 결정한다
가장 먼저 정한 원칙은 사용자 원문은 사용자의 의견과 표현을 우선하는 것이다. 물론 지금 AI는 문서를 상당히 잘 작성하지만, 장황하거나 알아볼 수 없는 글을 쓰는 경우도 많고 결국 아직까지는 사람의 손을 거쳐야 그것이 온전히 내 지식과 의견이 된다고 생각한다. 그래서 크게 2가지 영역으로 나누었다.
- Raw 레이어 — 내가 주체적으로 쓰는 모든 노트. 온전히 내 소유다. 여기에는 블로그처럼 외부 공개용으로 작성하는 글도 포함된다.
- LLM-Managed 레이어 — AI만의 노트 공간. 여기서는 AI가 자유롭게 노트를 만들고 고치고 지울 수 있다. 나도 최대한 개입하지 않고 자유도를 부여한다.
핵심은, AI가 자유롭게 손댈 수 있는 건 LLM-Managed 레이어뿐이라는 것이다. 내 원본 노트에 대해서는 Frontmatter(제목·태그 같은 메타데이터) 정도만 승인 없이 정리하게 하고, 본문을 고치거나 파일을 옮기는 등 중추적인 작업은 전부 내 승인을 거치게 했다. AI가 “이 부분 이렇게 보강하면 어떨까” 하고 제안은 할 수 있지만, 실제 반영 여부는 내가 결정한다.
Frontmatter는 승인 없이 바로 AI가 작업하고 Lint로 수정하게 하는 것이 관계 기반 문서를 형성하는 데 더 효율적이라 생각하여 풀어 두었다.
Hub와 Registry
LLM Wiki를 관리하다 보니 더 체계적인 작업 공간을 형성하기 위해 Hub와 Registry라는 개념을 만들게 되었다.
- Hub는 한 주제 영역의 진입점 역할을 하는 페이지다. 예를 들어 “Agent Engineering”이나 “RAG” 같은 큰 주제마다 Hub가 하나씩 있고, 그 주제와 관련된 흩어진 내 노트들을 링크로 엮어서 지도처럼 보여 준다. 어떤 주제에 대해 내가 뭘 적어 뒀는지 한눈에 들어오는 목차이자 네비게이션인 셈이다.
- Registry는 바로 꺼내 쓸 수 있는 모음집이다. 기준은 두 가지 경우로 정했다.
- 즉시 사용 가능한 도구·오픈소스 목록 (예: 보안 도구 모음, K8s 셀프호스팅 도구 모음)
- 누구나 지켜야 할 원칙이나 체크리스트 (예: 보안 점검 체크리스트)
여기서 중요하게 생각한 규칙이 몇 가지 있었다. 먼저 같은 내용을 내 원본 노트와 Registry 양쪽에 중복으로 두지 않게 했다. 둘 중 하나만 원본이고, 나머지는 링크로 참조만 한다. 복사를 허용하면 한쪽만 고치고 다른 쪽은 옛날 내용으로 남는 Stale 이슈가 생기기 때문에 최대한 Single Source of Truth를 유지하려고 했다. 또한, Registry의 기준을 최대한 명확하게 잡으려고 노력했는데, 이를 명확하게 잡지 않으면 Registry와 Hub의 개념이 모호해지고 오히려 의도치 않은 혼란이 생길 수 있기 때문이다.
세 개의 루프
실제 운영은 앞서 말한 세 개의 루프로 돌아간다.
- Ingest — 새 노트를 쓰거나 의미 있는 수정을 하면, AI가 그걸 읽고 관련 Hub에 연결하고, 전체 인덱스의 요약을 갱신하고, 작업 기록을 한 줄 남긴다.
- Query — “내가 X에 대해 뭘 적어 뒀더라?” 하고 물으면, 먼저 Hub와 인덱스를 뒤지고 필요하면 원본 노트까지 읽어서 답을 합성해 준다. 흩어진 메모를 일일이 찾아다니지 않아도 된다.
- Lint — 주기적으로 위키 정합성 체크를 돌린다. 필수 메타데이터가 빠졌거나, 태그가 제각각이거나(
k8s와Kubernetes처럼), 깨진 링크나 방치된 노트 등을 찾도록 하였다.
작업 기록은 한 번의 작업당 한 줄 원칙으로 정했다. 여러 줄로 만들 이유가 크게 없기도 했고, 언제 무엇을 했는지 타임라인 정도만 파악하면 충분하다고 생각했다.
무엇이 좋았나
직접 LLM Wiki를 도입해 보니 생각보다 얻은 게 많았다.
- 우선 이 체계를 갖추는 과정 자체가 방치돼 있던 노트를 전부 다시 들여다보는 강제 계기가 되었다. 처음에는 단순히 태그와 형식을 맞추는 목적으로 시작했는데, 결국 내용 자체를 다듬고 개선하는 데까지 이어졌다. 이전에 적었던 수많은 노트도 이 과정에서 공격적으로 정리하여 대부분을 정리할 수 있었다.
- 메모로 남겨 두었지만 영구적인 노트로 남기기엔 애매했던 것들, 예를 들면 단순 도구 목록 같은 것들을 Registry로 넘길 수 있었다. 덕분에 내 노트에는 진짜 내 생각과 판단이 밀도 있게 남고, 잡다한 관리 부담은 AI 영역으로 빠지는 효과가 생겼다.
TLDR 뉴스레터와의 전쟁
스타트업 Founding Engineer로 일하다 보니 AI 트렌드를 따라가는 건 선택이 아니라 필수다. 그래서 고른 게 TLDR.AI였다. 이왕 하는 김에 다양한 경험을 간접적으로라도 쌓고 싶어서 무작정 마케팅, 보안 같은 다른 분야 뉴스레터도 전부 구독했다.
장점은 명확했다. 이것만 봐도 된다는 것. X에 올라오는 중요 트렌드는 대부분 다뤄 주고, 유용한 오픈소스도 다수 소개된다. 덕분에 더 이상 링크드인 피드를 들여다보지 않아도 될 정도가 되었다. 25년 이후 링크드인에서 원문을 퍼나르는 방식으로 본인 PR을 하거나 딱 봐도 AI로 생성된 컨텐츠가 대거 돌아다니는 것을 좋게 보지 않았는데, 이를 대폭 줄일 수 있어서 좋았다. (물론 이로 인해 내 링크드인 활동도 줄어들긴 했다.)
문제는 정보량이었다. 유용한 정보만큼이나 가십, 잘못된 정보, 개인 수준의 작업물 같은 불필요한 정보도 너무 많았다. 이걸 모르지는 않았기 때문에 처음에도 거르기 위한 필터를 만들었지만, 정작 내 기준 자체가 명확하지 않았다. 무엇이 나에게 진짜 중요한지를 정의하지 못한 채 막연하게 시작하다 보니, 한참을 걸러 내고도 정보가 여전히 넘쳤다.
기준을 만들기 위해서는 부딪혀 보는 수밖에 없었다. 고통스럽지만 5~6주치 뉴스레터를 Claude와 함께 하나하나 읽어 나가면서 기준을 세우고 개념을 흡수했다. 이 과정이 단순히 정보를 거르는 작업은 아니었다. 매 글마다 “이게 왜 중요한가, 나에게 적용되는가”를 따지다 보니 자연스럽게 내 판단 기준이 또렷해졌다. 또 뉴스레터를 계속 읽다 보니 출처는 다 다르지만 모두가 다루는 주제나 인사이트가 있어서 그것을 묶기 시작했다. 그 결과 Agentic Engineering 관련 큰 토픽 3개와 기타 인사이트들을 어느 정도 정리할 수 있었다.
6월 초부터 다시 만든 기준을 바탕으로 접근 방식을 바꿨다. 중복되는 내용은 과감히 Cut하고, 이미 기본기는 흡수된 상태였기 때문에 훨씬 더 보수적으로 기준을 잡았다. 정말 인사이트가 있는 글만 내 눈까지 도달하도록 필터를 다시 썼다. 이걸 적용한 뒤에는 일주일에 100개도 넘게 확인해야 했던 링크 수가 30개 정도로 크게 줄었다. 확인할 링크의 밀도도 올라갔고, 개별 링크를 판단할 때도 이전보다 기준이 명확해져 Cut하거나 Action Item을 잡는 시간이 줄어들었다.
지금도 노이즈를 계속 줄여 나가고 있다. Loop Engineering이나 AEO 전략처럼 본질은 예전 그대로인데 이름만 바꿔 다시 등장하는 Bias들이 있고, 내 환경과는 아무 상관 없는 CVE가 중요한 것처럼 표시되기도 한다. 이런 것들을 하나씩 걷어 내면서 필터를 다듬는 중이다.
변화
이 두 가지 변화가 완전히 장점만 가지고 있다고 할 수는 없다.
LLM Wiki를 도입하면서 세부적인 것들은 점점 AI 영역으로 위임하게 되었고, 자연스럽게 내가 직접 머릿속에 들고 있는 비중은 줄었다. TLDR 뉴스레터를 읽으면서도 비슷한 걸 느꼈다. AI가 발전하면서 온갖 방법론과 찬반 논쟁이 난무한다. 특히 보안 쪽은 공격자도 AI를 쓸 수 있기 때문에 공격 기법이 훨씬 다양해지고 주기도 짧아졌다. 이런 걸 하나하나 다 따라잡는 건 애초에 불가능하다. 그래서 내 노트에는 세부 구현보다 변하지 않는 일반론 위주로 남기게 되었다.
이렇게 디테일한 내용의 비중이 떨어지는 것은 분명 단점일 수 있다. 솔직히 지금 상태에서 고난이도 기술 면접을 본다면 디테일에서 막혀 떨어지지 않을까 싶기도 하다.
하지만 그 대신 큰 그림을 보고, 여러 역할을 넘나들며, 일반론적으로 사고할 수 있게 되었다. 명백한 Trade-off다. 그리고 적어도 현재 나의 위치에서는 이 방향이 맞다고 생각한다. 팀원들과 함께 개발·인프라·기획까지 골고루 생각해야 하는 환경에서는, 모든 디테일을 머리에 이고 있는 것보다 필요할 때 빠르게 끌어다 쓸 수 있는 체계를 갖추는 게 더 중요하다. 정보가 너무나도 포화된 AI 시대에 이런 과부하를 줄이는 것이 중요하기도 하고, 제너럴리스트로서 할 수 있는 것도 분명히 많아졌다고 느낀다. 그리고 결국 정말 중요한 CS 개념이나 예전에 했던 DevOps 지식은 현재 회사에서도 어떻게든 다시 마주치고 있어서, 큰 걱정을 하고 있지는 않다.
마치며
결국 이번 변화의 핵심은 AI에게 조금 더 문서화의 영역을 위임하고, 무엇을 기억할지를 내가 전부 짊어지지 않아도 되게 만든 것이었다. 사실 이전까지 내 Obsidian이 투박한 형태로 남아 있었던 이유 중 하나는 내가 모든 문서를 직접 다 관리하려 했기 때문인 것 같다. 그리고 그것을 유지했다면 TLDR 같은 뉴스레터를 다 소화하지 못했을 것 같다. 이 2가지는 세부 사항을 AI 레이어로 넘기고 나는 큰 그림과 판단에 집중하는 모델로 바꾸는 계기가 되었다. 그리고 정보의 홍수 속에서 나는 기준만 다듬고, 과부하를 줄여 나가고 있다. 지금으로서는 나름 합리적인 방식이라고 생각한다.
물론 지금의 시스템과 노트도 완전하지 않고 계속 손봐야 한다. 하지만 이것은 온전한 문서를 유지하기 위해 계속 감수해야 할 비용이다. 앞으로도 계속 Obsidian 노트의 밀도를 높이고, 플러그인/기법 등을 적극적으로 검토해서 활용도와 접근성을 높여서 정말로 Second Brain으로서의 활용도를 높여 나가야겠다.