노트 3,000개를 정리하다 실패한 이야기 — PKM 번아웃
노트가 3,000개를 넘긴 어느 날, 나는 Obsidian을 열기가 무서워졌다. PKM 번아웃의 증상과 정리 실패, 그리고 시스템을 다시 살린 복구 과정을 솔직하게 적은 에세이.
노트가 3,000개를 넘긴 어느 날, 나는 Obsidian을 열기가 무서워졌다.
정확히는 왼쪽 사이드바의 노트 개수 카운터가 무서웠다. 3,142라는 숫자가 떠 있었다. 그 숫자를 보는 순간, 머릿속에 떠오른 건 뿌듯함이 아니라 빚 독촉장에 가까운 감각이었다. 저 안에 정리되지 않은 게 몇 개나 될까. 연결되지 않은 고아 노트는. 다시는 안 열어볼 단편은. 나는 그날 Obsidian을 닫고 사흘간 열지 않았다.
이 글은 그 사흘과, 그 뒤로 두 달간 이어진 PKM 번아웃에 대한 기록이다. 자랑할 이야기는 아니다. 다만 같은 곳을 향해 노트를 쌓고 있는 누군가에게, 이 길의 끝에 무엇이 있는지 미리 보여주고 싶었다.
어쩌다 3,000개까지 쌓였나
처음부터 3,000개를 목표로 한 사람은 없다. 나도 그랬다.
시작은 건강했다. 2년 전, 나는 흩어진 메모를 한곳에 모으려고 Obsidian을 켰다. 책 발췌, 회의 메모, 코드 스니펫, 블로그 아이디어 — 하루 두세 개씩 떨어지는 단편을 그냥 받아 적었다. 처음 6개월은 좋았다. 노트가 500개쯤 됐을 때, 검색 한 번으로 반년 전 메모가 튀어나오는 경험은 작은 마법 같았다.
문제는 그다음이었다. 노트가 자산처럼 느껴지기 시작하면서, 나는 개수 자체를 성과로 착각했다. 매일 노트를 만들지 않으면 그날 하루를 놓친 기분이 들었다. PKM 커뮤니티의 "every day a note" 같은 구호가 불안을 부추겼다. PKM 스택 전체 공개에 적었던 것처럼, 나는 수집을 멈추는 법을 배우지 못한 채로 도구만 늘려갔다.
1,500개를 넘기면서 연결 강박이 붙었다. 새 노트를 만들 때마다 "이건 어디에 연결되지?"를 먼저 물었다. 연결할 곳을 못 찾으면 억지로 만들었다. 그래프 뷰는 점점 별이 빽빽한 밤하늘처럼 보였지만, 정작 나는 그 그래프에서 아무것도 읽어내지 못했다. 아름답고, 무의미했다.
번아웃이 온 신호 세 가지
돌이켜보면 번아웃은 어느 날 갑자기 온 게 아니었다. 세 가지 증상이 천천히 자라고 있었는데, 나는 그걸 생산성으로 착각했다.
첫째, 나는 검색만 했다. 글을 쓰려고 노트를 열면, 관련 노트를 찾기만 하다가 시간이 다 갔다. 3,000개 중에서 지금 필요한 한 개를 고르는 비용이, 그냥 처음부터 다시 쓰는 비용보다 커졌다. 노트가 글을 돕는 게 아니라, 노트를 뒤지는 일이 글을 막았다.
둘째, 새 노트를 만드는 게 무서웠다. 단편 하나가 떠올라도, "이걸 또 어딘가에 연결하고 분류해야 한다"는 생각이 먼저 들면서 손이 멈췄다. 수집이 부담이 되는 순간, PKM은 이미 망가진 거였다. 나는 아이디어를 Obsidian 대신 카톡 나에게 보내기에 던지기 시작했다 — 내 시스템을 피해서.
셋째, 연결 강박이 사고를 대체했다. 노트를 생각하기 위해 쓰는 게 아니라, 링크를 채우기 위해 썼다. Andy Matuschak의 Evergreen Notes는 "노트는 생각의 도구"라고 말하지만, 내 노트는 어느새 생각을 미루는 도구가 돼 있었다. 연결은 많은데, 결론은 없었다.

정리하려다, 더 망가뜨렸다
사흘 만에 Obsidian을 다시 열었을 때, 나는 대청소를 결심했다. 3,000개를 주말 이틀에 다 정리하겠다고 마음먹었다. 지금 생각하면 그게 가장 큰 실수였다.
토요일 아침, 나는 폴더를 새로 짜고 노트를 옮기기 시작했다. 한 개를 옮기면 연결이 깨졌고, 깨진 링크를 고치다 보면 또 다른 노트가 눈에 들어왔다. "이건 합쳐야겠다", "이건 지워야겠다" — 그렇게 세 시간을 쏟았는데, 정리한 노트는 고작 40개였다. 산수를 해봤다. 이 속도면 3,000개를 정리하는 데 225시간. 주 13시간 빌더의 시간으로는 4개월이 넘는다.
그 계산 앞에서 나는 주저앉았다. 그리고 더 나쁜 일이 일어났다 — 반쯤 옮긴 폴더 구조 때문에, 시스템이 이전보다 더 엉망이 됐다. 원래는 지저분하지만 익숙한 집이었는데, 이제는 공사 중인 폐가가 됐다. 나는 정리하려다 내가 알던 지도까지 잃었다.
이때 깨달았다. 3,000개를 정리하는 건 불가능한 게 아니라, 애초에 잘못된 목표였다는 걸. 문제는 노트가 더러운 게 아니라, 내가 전부 정리해야 한다고 믿는 것이었다.
시스템을 다시 살린 복구 과정
대청소를 포기한 게 복구의 시작이었다. 나는 정반대로 갔다.
먼저, 공사 중이던 폴더 구조를 git으로 되돌렸다. 익숙한 폐가보다는 지저분한 옛집이 나았다. 그다음, 가장 중요한 결정을 내렸다 — 3,000개를 정리하지 않기로 했다. 대신 과거는 아카이브에 통째로 묻고, 오직 지금부터 만드는 노트에만 규칙을 적용했다.
구체적으로는 이렇게 했다.
_Archive/폴더 하나를 만들어 기존 노트 전부를 넣었다. 검색은 여전히 되니까 잃어버린 게 아니다. 다만 눈앞에서 치웠다. 카운터가 3,142에서 0에서 다시 시작하는 것처럼 보이는 것만으로도 숨이 쉬어졌다.- 새 노트는 "글이 될 것 같은가?"라는 한 가지 질문만 통과시켰다. Zettelkasten 실전 적응기에서 영구 노트 기준을 좁힌 것과 같은 원리다. 단순 메모는 받아만 적고 연결하지 않는다.
- 연결은 나중에, 글을 쓸 때만 한다. 노트를 만들 때 링크를 강박적으로 채우는 습관을 버렸다. 연결은 글이라는 출력이 생길 때 자연스럽게 따라오게 뒀다.
한 달 뒤, 새 노트는 80개였다. 3,000개일 때보다 훨씬 적은데, 글은 더 잘 나왔다. 핵심은 분명했다 — 덜 모으니 더 보였다.
다시 망가지지 않기 위한 원칙 세 가지
같은 번아웃을 두 번 겪고 싶지 않아서, 예방 원칙 세 가지를 정했다. 거창하지 않다. 다만 나를 다시 망가뜨리지 않을 만큼은 단단하다.
원칙 1 — 개수는 성과가 아니다. 노트 카운터를 대시보드에서 숨겼다. 측정해야 할 건 노트 개수가 아니라 노트에서 나온 글의 개수다. 모으는 양이 아니라 빼내는 양을 본다.
원칙 2 — 정리는 한 번에 하지 않는다. 대청소는 영원히 금지다. 대신 글을 쓸 때 그 주제의 노트 5개만 정리한다. 정리는 이벤트가 아니라 부산물이어야 한다. 산처럼 쌓아두고 한 번에 치우려는 순간, 다시 주저앉는다.
원칙 3 — 시스템이 부담되면, 시스템이 틀린 거다. 노트를 만드는 게 무서워지면, 그건 내가 게으른 게 아니라 규칙이 무거운 것이다. 그럴 땐 규칙을 덜어낸다. 도구가 나를 부리기 시작하면, 도구를 의심한다.
다음 계획
지금은 새 시스템으로 두 달째다. 아직 완전히 회복됐다고는 못 한다 — 가끔 _Archive/를 열어볼 때면 3,000개의 죄책감이 슬쩍 돌아온다. 그래도 Obsidian을 열기가 무섭지는 않다. 그것만으로 큰 진전이다.
다음 6개월엔 아카이브 3,000개를 정리하는 게 아니라, 천천히 잊는 실험을 해볼 생각이다. 1년 넘게 검색에 한 번도 안 걸린 노트는 정말 필요했던 걸까. 같은 맥락에서 분류 체계 전반을 점검하려고 PARA 방법론 1년 회고도 따로 쓰는 중이다. 어쩌면 거기서 덜어내기의 다음 답을 찾을지도 모른다.
노트는 나를 도우려고 있는 거지, 내가 노트를 섬기려고 있는 게 아니다. 3,000개를 쌓고 나서야 그 당연한 문장을 몸으로 알았다. 늦었지만, 안 것이 다행이다.
관련 글
PARA 방법론 1년 적용 솔직 후기 — 남긴 것과 버린 것
Tiago Forte의 PARA를 1년 그대로 따라 한 뒤, 좋았던 3가지·안 맞았던 3가지를 솔직히 적었다. Inbox 추가와 Archives 시간 기준 — 두 군데를 깎아낸 1인 빌더의 PKM 적응기와 다음 계획.
Zettelkasten 실전 적응기 — 내가 바꾼 3가지
제텔카스텐 원본을 그대로 쓰면 1인 빌더는 번아웃한다. 영구 노트 비중 축소·Index Note 도입·Claude로 Fleeting Note 대체 — 3가지 변형으로 정착시킨 적응기.
Claude MCP + Obsidian — AI가 내 노트를 직접 쓴다
Claude를 MCP로 Obsidian에 연결해, AI가 내 노트를 직접 읽고 쓰게 만든 기록. 일요일 정리 워크플로우, 처음에 깨진 것들, 주 5시간을 주 1시간으로 줄인 실제 변화까지 1인칭으로 적은 buildlog.