Bear 의 경험, Bear 의 저장은 아니고

"라이브러리 경험은 가져. 그걸 만들어낸 저장 모델은 거부해. 둘은 애초에 같은 게 아니었어."

Bear 가 잘하는 것

Bear 는 여기서 진짜로 감탄받고, 이유가 좋아. 고요한 사이드바, 즉시 검색, 폴더 마찰 없음 — 그냥 쓰면, 나중에 찾는 게 그냥 돼. 그 라이브러리 경험이 Rekindle 이 single-file 모드를 넘어 자랐을 때 딱 원하는 거야. 그래서 정직한 질문은: Bear 를 얼마나 베껴야 해?

Bear 의 저장이 치를 값

절대 안 베껴야 할 부분이 저장 모델이야. Bear 는 노트를 자기 데이터베이스에 master 로 둬. 그걸 Rekindle 에 들여오면 vault 가 쪼개져. DB 는 이걸 말하고, .md 파일은 저걸 말하고, 이제 두 master 사이 화해를 영원히 소유해. 그게 스택 전체가 거부하는 바로 그 reconcile-hell — cwkPippa 가 동기화 유지되는 두 권위 대신 하나의 진실과 다시 지을 수 있는 미러를 가진 그 이유.

Bear 모델        DB 가 master, 파일은 export      -> 화해할 두 master
Rekindle 모델    파일이 master, 인덱스는 파생     -> 하나의 master, 다시 짓는 뷰

# 라이브러리 UX 는 둘 다와 호환돼. 둘 중 하나만
# 네 vault 를 쪼개고 화해 문제를 건네.

경험을 가져, 저장 모델 말고

핵심 깨달음은 라이브러리 경험과 own-DB 저장 모델이 분리 가능하다는 거야. 사이드바, 즉시 검색, 폴더 마찰 없음은 전부 뷰야 — master 데이터베이스에서만큼이나 순수 파일 위 파생 인덱스에서도 잘 계산돼. 그게 Obsidian 스위트 스팟이야. Bear 의 고요한 라이브러리 느낌을, file-canonical 저장 위에, Rekindle 이 이미 선 그 CM6 엔진 위에. 그래서 Rekindle 은 경험을 가져가고 저장은 두고 와.

이건 이름 붙일 가치 있는 일반 수야. 앱을 감탄할 때, 원하는 경험을 그걸 우연히 만들어낸 아키텍처와 분리해. 보통 같은 게 아니고, 경험을 얻으려 아키텍처를 베끼는 게 원한 적 없는 문제를 상속하는 방법이야.

Code

경험은 저장 모델과 분리 가능해·text

모델              저장                                 귀결
----------------  -----------------------------------  --------------------------
Bear 모델         DB 가 master, 파일은 export          화해할 두 master
Rekindle 모델     파일이 master, 인덱스는 파생         하나의 master, 다시 짓는 뷰

라이브러리 UX (사이드바, 즉시 검색, 폴더 마찰 없음) 는
둘 다와 호환 — 뷰고, 어느 쪽에서든 계산 가능해.

# 그러니 UX 는 Bear 에서, 저장은 vault 에서 가져오고,
# 네 데이터를 쪼갤 그 한 가지만 거부해.

Exercise

느낌을 베끼고 싶은 앱을 골라. 두 목록을 써. (1) 네가 실제로 원하는 경험 (뷰, 상호작용), (2) 거기 도달하려 그 앱이 한 아키텍처 선택. (2) 의 각 항목에 대해, 그게 (1) 에 진짜로 필요한지 물어. 대부분 아닐 거고 — 네 invariant 를 깰 것들이 딱 거부할 것들이야.

Hint

경험은 '즉시 검색', '폴더 마찰 없음', '고요한 사이드바' 같은 것. 아키텍처는 '노트가 사설 SQLite master 에 산다'. 둘째는 첫째를 얻는 한 방법이지 유일한 방법이 아니고 — 네 진실의 원천을 쪼갠다면 너한텐 틀린 방법이야.