"코드는 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 으로 흘러 나가고, 거기서 다시 흘러 들어오는 일은 없어야 해.