"코드는 git 으로 다니고, 상태는 API 로 다녀. 동기화 폴더는 둘 다 아냐."
절대 안 섞여야 하는 두 레일
Recall 은 같은 코드를 두 호스트에서 돌리고, 각 호스트는 다른 live 상태를 들고 있어. 그 사이를 옮기는 채널은 정확히 둘이고, 그 둘을 혼동하는 건 분산 시스템을 중독시키는 고전적 방법이야:
- 코드는 git 으로 움직여. 개발 노트북에서 편집하고, private repo 에 push 하고, 각 호스트가 독립적으로 pull 해. 모든 호스트가 같은 커밋된 코드로 수렴해. git 이 배포 채널이야.
- 상태는 API 로 움직여. executor 가 인증된 API 호출로 control plane 에 결과를 제출해. control plane 의 DB 가 런타임 상태가 권위 있는 유일한 곳이야. API 가 상태 채널이야.
그게 다야. 레일 둘. 그리고 규칙은 세 번째 것 — 파일 동기화 서비스, 공유 폴더, export 된 Markdown 파일 — 은 코드 채널도 상태 채널도 아니라는 거야. Recall 은 이걸 명시해: 파일 동기화랑 생성된 Markdown 은 배포도 런타임-상태 transport 도 아냐.
왜 동기화 폴더가 함정이야
너무 편해 보여. 두 호스트가 같은 동기화 폴더를 볼 수 있으니, 거기에 상태를 떨궈서 복제하게 하면 되잖아? 안 돼 — 동기화 서비스는 진실의 원천이 절대 가지면 안 되는 딱 한 가지를 줘: 어느 사본이 진짜인지에 대한 모호함. 두 호스트가 같은 파일을 쓰고, 동기화가 conflict 사본을 만들고, 이제 '진실' 이 둘인데 어느 게 이기는지 규칙이 없어. 더 나쁘게, 오래된 동기화 사본은 새것과 똑같아 보여 — 커밋된 전이도, 버전도, 수락도 없거든. 소유자 없는 DB 야. 그렇게 한 호스트에선 '완료' 고 다른 호스트에선 영영 'pending' 인 job 이 생겨.
Markdown 은 export 지 model 이 아냐
같은 규율이 사람이 읽는 산물에도 적용돼. Recall 은 읽을 수 있는 Markdown transcript 를 생성해 — 근데 그 Markdown 은 진짜 데이터의 하류인 export 야. 절대 진실로 되먹임 안 돼. 검색은 Markdown 을 안 읽어; DB 의 구조화된 타임스탬프 segment 를 읽어. export 를 입력으로 만드는 순간, 손으로 편집하거나 오래된 파일이 현실을 조용히 다시 쓰는 loop 를 만든 거야. export 는 엄격히 하류로 유지해: 상태는 Markdown 으로 흘러 나가고, 절대 거기서 다시 흘러 들어오지 않아.