그날의 cutover

"교체는 merge 가 아냐. 정체성 수술이야. 순서대로, 돌아갈 길을 깔고."

한 아침, 순서대로

2026-09-13 에 레플리카는 리허설을 졸업했어. cutover 는 하나의 순서 있는 수술로 돌았고, 그 순서가 곧 레슨이야. 검증된 백업이 먼저(두 히스토리의 git 번들, 데이터와 서포트 아카이브, 설치된 3.1.0 번들), 그다음 레포 이어 붙이기 — Swift 트리를 기존 Rekindle 레포에 merge 커밋으로 합치는데 첫 parent 가 Tauri head 라서 두 히스토리가 같은 방에 남는 거야 — 그다음 정체성 통일, 그다음 각 Mac 의 일회성 데이터 변환(해시 검증된 백업에서, 원본은 아카이브로), 그다음 설치, 그다음 Firelink 의 버전 기록, 그다음 가족 정합과 fleet 배포. 다음 단계가 착륙하기 전까지 모든 단계는 되돌릴 수 있고, 되돌릴 수 없는 단계에 이르면 돌아가는 길은 이미 기록돼 있어. 아카이브된 3.1.0 번들과 아카이브된 데이터 루트가 그거야.

정체성은 주소의 목록이야

아무도 안 즐거워하는데 건너뛸 수 없는 부분이 있어. 앱의 정체성은 이름이 아냐. 머신이 그 앱을 알아보는 모든 주소지. cutover 테이블은 그걸 전부 뒤집어야 했어. 번들 id(com.cwk.rekindle), 설치된 앱 경로, 데이터 루트(~/cwk-dbs/rekindle-db/), 서포트와 캐시 디렉터리, Keychain 서비스 네임스페이스, URL 스킴, 그리고 — 가족이 실제로 대화하는 통로인 — Pippa host kind 와 brain-control app id 도 전부 rekindle 로. 임시였던 Kindling 정체성은 살아 있는 런타임 전부에서 빠졌어. 역사 문서들은 쓰일 때의 이름을 그대로 간직해. 역사를 다시 쓰는 건 다른 수술이고, 아무도 그걸 주문하지 않았거든.

버전이 3.1.0 에서 4.0.0 으로 뛴 이유

버전은 레플리카 프로그램 내내 0.0.0 에 박혀 있었어. 제품이 아직 번호를 벌지 못했으니까. 그러다가 minor 가 착지할 곳을 훌쩍 넘는 점프를 했지. 가족의 버전 계약이 일한 거야. 구현 교체에 일회성 데이터 변환이 붙으면 그건 MAJOR 변경이고, 사람이 보는 버전은 태그에서 추론하는 게 아니라 릴리스 주인(Firelink)이 써. 빌드 번호, git 커밋, 스키마 개정은 전부 자기 레일에서 자라. 제품 버전은 다른 질문에 답해 — 사용자가 방금 뭘 돌리기로 동의했지? 2026-09-13 의 답은 이거야. 같은 제품, 새 엔진, 그리고 네 데이터는 같이 왔어.

Code

cutover 의 순서 — 다음 단계가 착륙하기 전까진 전부 되돌릴 수 있어·text

1. 검증된 백업      git 번들(두 히스토리), 데이터 아카이브,
                    설치된 3.1.0 앱 번들
2. 레포 이어 붙이기  merge 커밋, 첫 parent = Tauri head
                    -> 두 히스토리가 남는다
3. 정체성 통일      번들 id, 데이터 루트, 서포트 디렉터리, Keychain
                    네임스페이스, URL 스킴, Pippa host kind
4. 일회성 변환      Mac 마다, 해시 검증된 백업에서, 원본은 아카이브
5. 설치 + 버전      Firelink 가 4.0.0 을 쓰고, 가족이 정합된다

# 돌아가는 길은 필요해진 다음에 조립하는 게 아니라, 필요해지기 전에 아카이브해.

Exercise

네 머신의 앱 하나를 골라서 OS 가 그 앱을 알아보는 주소를 전부 나열해봐. 번들 id, Application Support 경로, 캐시, 키체인 항목, URL 스킴, 로그인 항목. (힌트: ~/Library 가 답의 대부분이야.) 이제 그 앱을 재작성으로 교체한다고 상상해 봐. 어떤 주소를 유지하고 어떤 걸 퇴역시킬 거고, 첫날 새 것이 삐걱거리면 돌아가는 길은 뭐야?

Hint

목록은 생각보다 길어 — 그게 레슨이야. 구 버전에 대한 계획이 '휴지통에 아직 있어' 라면, 그건 돌아가는 길이 아니라 희망이야.