"라이브러리 경험은 가져오되 그걸 만들어낸 저장 모델은 거부해. 둘은 애초에 같은 게 아니었으니까."
Bear 가 잘하는 것
Bear 는 여기서 진심으로 감탄의 대상이고 이유도 분명해. 고요한 사이드바, 즉시 검색, 폴더 때문에 씨름할 일 없음. 그냥 쓰다 보면 나중에 찾는 것도 그냥 돼. 그 라이브러리 경험이야말로 Rekindle 이 파일 하나 열어놓고 쓰는 단계를 넘어섰을 때 딱 필요한 거고. 그래서 정직하게 물어야 할 건 이거야. Bear 를 얼마나 베껴야 하지?
Bear 의 저장이 치를 값
절대 베끼면 안 되는 부분이 저장 모델이야. Bear 는 노트를 자기 데이터베이스에 master 로 둬. 그걸 Rekindle 에 들여오는 순간 vault 가 쪼개져. DB 는 이렇게 말하고 .md 파일은 저렇게 말하니까, 두 master 사이를 맞추는 일을 영원히 떠안게 되지. 이 스택 전체가 거부하는 그 화해 지옥이 바로 이거고, cwkPippa 가 계속 동기화해야 할 두 권위 대신 진실 하나와 다시 지을 수 있는 미러를 택한 이유이기도 해.
Bear 모델 DB 가 master, 파일은 export -> 화해할 두 master
Rekindle 모델 파일이 master, 인덱스는 파생 -> 하나의 master, 다시 짓는 뷰
# 라이브러리 UX 는 양쪽 다와 맞아. 둘 중 하나만
# 네 vault 를 쪼개고 화해 문제를 떠넘길 뿐이지.경험을 가져, 저장 모델 말고
핵심은 라이브러리 경험과 자기 DB 저장 모델이 떼어놓을 수 있다는 깨달음이야. 사이드바도, 즉시 검색도, 폴더 때문에 씨름할 일 없는 것도 전부 뷰거든. master 데이터베이스 위에서만큼이나 순수 파일 위 파생 인덱스에서도 잘 계산돼. 그게 Obsidian 이 서 있는 자리고. Bear 의 고요한 라이브러리 느낌을, 파일이 정본인 저장 위에, Rekindle 이 이미 올라선 그 CM6 엔진 위에 얹은 거지. 그래서 Rekindle 은 경험만 가져오고 저장 모델은 두고 왔어.
이건 이름 붙여둘 만한 일반적인 수야. 어떤 앱에 감탄할 때, 네가 원하는 경험과 그걸 우연히 만들어낸 아키텍처를 떼어놔. 보통 둘은 같은 게 아니거든. 경험을 얻겠다고 아키텍처까지 베끼는 게, 원한 적도 없는 문제를 물려받는 지름길이야.