시스템 분리는 복잡성을 줄이는 게 아니라 옮기는 것이다
옵시디언 볼트 3개를 1개로 통합하며 배운 것
문제
옵시디언을 쓴 지 1년이 넘었다. 처음엔 하나의 볼트로 시작했다.
그러다 볼트가 셋이 됐다.
- codemon — 메인 볼트. 프로젝트 노트, 일일 기록, 아이디어
- blog — 블로그 전용. 드래프트, 발행된 글, 아이디어 메모
- share-for-bot — AI 봇과 공유하는 파일. 프롬프트, 컨텍스트, 설정
분리 과정은 자연스러웠다. 블로그 글이 20개 넘어가니까 “따로 관리하는 게 깔끔하겠다” 싶었다. 봇이 파일을 읽어야 하니까 “봇 전용 폴더를 볼트로 빼자” 싶었다.
어느 날 깨달았다. 검색이 안 된다.
타로몬 프로젝트 관련 메모를 찾으려고 했다. Cmd+O를 눌렀다. 안 나온다. 메인 볼트에 없으니 블로그 볼트를 열었다. 거기도 없다. share-for-bot을 열었다. 거기 있었다. 봇한테 보내려고 옮겨둔 거였다.
이런 일이 반복됐다:
- “slimmon API 구조 어디 적어뒀지?” → 메인에도 있고 봇 공유에도 있음 (어느 게 최신?)
- “블로그 아이디어 메모” → 메인 Inbox에도, 블로그 ideas/에도 있음
- “지난달에 적은 회고” → 세 볼트 다 뒤져야 함
iCloud 동기화도 문제였다. 세 볼트를 각각 동기화하니 간헐적으로 충돌이 생겼다. 같은 파일이 filename 2.md로 복제되는 걸 몇 번 겪었다.
분리는 자연스러웠다. 문제는 그 자연스러움이었다.
기존 접근의 한계
왜 볼트를 나눴을까? 돌이켜보면 명확한 이유가 없었다.
- “블로그 글은 따로 관리하는 게 깔끔하지 않을까?”
- “봇이 접근하는 파일은 분리해야 안전하지 않을까?”
그럴듯해 보였다. 하지만 실제로 일어난 일:
1. 검색 분산 — 가장 치명적
옵시디언의 핵심 가치는 Cmd+O(Quick Switcher)와 Cmd+Shift+F(전체 검색)다. 볼트가 나뉘면 이 두 기능이 볼트 단위로 쪼개진다. “내가 적은 모든 것”을 한 번에 검색할 수 없다. 볼트를 전환하려면 옵시디언을 닫고 다시 열거나, 여러 윈도우를 띄워야 했다.
2. 링크 단절 — 두 번째 핵심 가치 상실
옵시디언의 또 다른 핵심은 wikilink다. 문서 간 연결. 그런데 볼트가 다르면 wikilink가 작동하지 않는다. 블로그 드래프트에서 프로젝트 기술 메모를 참조하고 싶어도 링크를 걸 수 없었다. 결국 내용을 복사하거나 “메인 볼트의 XX 파일 참고”라고 텍스트로 적었다. 링크가 아니라 메모.
3. 동기화 복잡
iCloud 동기화는 폴더 단위다. 볼트 3개 = 동기화 경로 3개. 아이폰에서 볼트를 전환하는 것도 번거로웠다. 모바일에서는 볼트 하나만 열어두는 게 현실적인데, 그러면 나머지 두 볼트의 노트는 접근 자체가 안 됐다.
4. 중복 발생 — 어느 게 원본?
프로젝트 문서를 봇에게도 보여줘야 했다. 메인 볼트에 있는 파일을 share-for-bot에 복사했다. 며칠 뒤 메인에서 수정했다. share-for-bot에는 구버전이 남아 있었다. 봇은 구버전을 읽고 있었다. 이런 일이 한두 번이 아니었다.
시스템을 분리하면 복잡성이 줄어드는 게 아니다. 복잡성이 ‘시스템 사이’로 옮겨갈 뿐이다.
개별 볼트는 단순해졌다. 하지만 볼트 간 관계가 복잡해졌다. 그리고 그 복잡성은 눈에 잘 보이지 않았다. 평소엔 괜찮다가, 뭔가 찾을 때 터진다.
내가 내린 판단
통합하기로 했다. 기준은 하나였다.
“검색 한 번에 다 나와야 한다.”
PARA + Bot 구조
Tiago Forte의 PARA 방법론을 도입했다. 거기에 Bot 폴더를 추가해서 AI 봇 통신용 파일을 따로 뒀다.
BEFORE — 3개 볼트
codemon/ (메인)
├── notes/
├── projects/
└── daily/
blog/ (블로그 전용)
├── drafts/
├── published/
└── ideas/
share-for-bot/ (봇 전용)
├── prompts/
├── context/
└── config/- 검색 3번 (볼트마다 따로)
- wikilink 단절
- iCloud 충돌
AFTER — 1개 볼트, PARA + Bot
codemon/
├── 0-Inbox/
├── 1-Projects/
│ ├── blog-codemon/
│ ├── blog-coffeemon/
│ ├── tarotmon/
│ ├── slimmon/
│ └── ...
├── 2-Areas/
│ ├── Career/
│ ├── Development/
│ ├── Health/
│ └── Investment/
├── 3-Resources/
├── 4-Archive/
├── Bot/
│ ├── rodimon/
│ ├── nubimon/
│ └── _share/
└── Templates/- 검색 1번으로 전부 나옴
- wikilink 전체 연결
- iCloud 안정
핵심 결정 몇 가지:
블로그를 Projects 아래에 넣었다. 예전엔 별도 볼트였지만, 블로그도 결국 프로젝트다. 1-Projects/blog-codemon/drafts/에 드래프트를 쓰고, 발행하면 published/로 옮긴다. 아이디어는 ideas/에 던져둔다. 이 글도 거기서 시작했다.
Bot 폴더는 PARA 밖에 뒀다. 봇이 읽는 파일은 사람이 관리하는 PARA와 성격이 다르다. 메모리 파일, 스킬 정의, 공유 컨텍스트 — 이런 건 봇의 운영 데이터에 가깝다. 하지만 같은 볼트 안에 있으니 검색은 된다. wikilink도 건다. 물리적으로는 분리, 논리적으로는 연결.
0-Inbox은 최소한으로 유지한다. 뭔가 떠오르면 Inbox에 던진다. 하루에 한 번 정리해서 적절한 Projects/Areas로 옮긴다. Inbox에 파일이 10개 이상 쌓이면 정리가 밀리고 있다는 신호다.
마이그레이션
마이그레이션 자체는 하루 만에 끝났다.
- 메인 볼트에 PARA 폴더 구조를 만들었다
- 블로그 볼트의 파일을
1-Projects/blog-codemon/으로 이동했다 - share-for-bot 볼트의 파일을
Bot/으로 이동했다 - 기존 두 볼트를 삭제했다
- wikilink 깨진 거 수작업으로 정리했다 (20개 정도)
기술적으로 어려운 건 없었다. 옵시디언에서 파일 이동은 드래그 앤 드롭이다. wikilink도 옵시디언이 자동으로 업데이트해준다 (같은 볼트 내에서는).
어려웠던 건 결정이었다.
“지금 굳이 해야 하나?”, “괜히 건드렸다가 꼬이면?”, “나중에 하면 안 되나?”
이런 생각이 1주일을 끌었다. 그러다 문득 깨달았다. 마이그레이션 비용은 시간이 지날수록 올라간다. 파일이 늘고, 링크가 늘고, 습관이 굳어진다. 볼트 3개에 파일이 100개일 때 합치는 것과 500개일 때 합치는 건 완전히 다른 작업이다.
결과와 배운 점
통합 후 달라진 것:
1. Cmd+O 한 번이면 다 나온다.
“타로몬 API” → 바로 나온다. “블로그 드래프트” → 바로 나온다. “로디몬 메모리” → 바로 나온다. 어느 볼트에 있는지 고민하는 시간이 0이 됐다. 이게 생각보다 크다. 검색할 때마다 “어디 있더라?”를 한 번씩 생각하면, 하루에 수십 번의 작은 인지 비용이 쌓인다.
2. wikilink가 전부 연결된다.
블로그 드래프트에서 프로젝트 PRD를 링크 걸면 바로 간다. 프로젝트 노트에서 관련 블로그 글을 걸면 바로 온다. 그래프 뷰에서 보면 프로젝트와 블로그와 리소스가 하나의 네트워크로 연결된다. 볼트가 나뉘어 있을 때는 불가능했던 것.
3. 모바일에서도 전부 접근된다.
아이폰에서 볼트 하나만 열면 끝. 이동 중에 떠오른 아이디어를 0-Inbox에 던지면 맥에서 바로 보인다. 예전엔 “이건 어느 볼트에 넣지?”를 모바일에서 고민하다가 그냥 안 적은 적도 있었다.
4. iCloud 동기화 충돌이 사라졌다.
동기화 경로가 하나니까 충돌 날 이유가 없다. filename 2.md 같은 유령 파일도 더 이상 안 생긴다.
그리고 깨달은 것:
분리는 쉽다. 통합은 어렵다.
시스템이 커지면 자연스럽게 분리하고 싶어진다. “이건 성격이 다르니까”, “저건 따로 관리하는 게 좋겠지”라고 생각한다. 분리는 결정이 쉽다. 각자 알아서 하면 되니까.
하지만 통합은 다르다. 모든 케이스를 고려해야 한다. 충돌을 해결해야 한다. 익숙해진 방식을 바꿔야 한다. 그래서 미루게 된다.
문제는, 미룰수록 통합 비용이 올라간다는 것이다.
코드도, 조직도, 노트 시스템도 마찬가지다. 마이크로서비스를 나눌 때도, 팀을 쪼갤 때도, 노트앱을 분리할 때도. 분리할 때는 “정말 분리가 필요한가?”를 먼저 물어야 한다. 그리고 통합이 필요하다면, 지금이 가장 싼 시점이다.
생각해볼 질문
당신의 시스템에서 ‘분리’되어 있지만 사실은 ‘연결’이 필요한 것은 무엇인가?
그 분리가 복잡성을 줄이고 있는가, 아니면 눈에 안 보이는 곳으로 옮기고 있는가?