태어날 때부터 canonical

"Pippa Go 대화는 승격을 기다리는 폰 초안이 아냐. 첫 숨부터 진짜 백엔드 대화야."

모바일 클라이언트를 짓는 두 방식 — 하나는 함정

모바일 대화가 어디 사는지에 대한 심상 모델이 둘 있고, 그 선택이 전부를 빚어:

초안-후-업로드 (함정): 폰이 로컬 대화를 소유하고, 그게 백엔드로 내보내지기 전까진 '진짜'야. 백엔드는 sync 대상, 폰이 정한 것의 복사본.
태어날 때부터 canonical (Pippa Go): 대화가 바로 첫 턴부터 일급 백엔드 대화야. 폰은 절대 '진짜 그것'을 소유 안 해 — 백엔드가 이미 소유한 대화를 위해 표현하고 캡처해.

초안-후-업로드 모델은 자연스러워 보이고 슬로모션 재앙이야. 폰이 권위 있는 복사본을 쥐는 순간, 어긋날 수 있는 진실의 출처 둘, 도중에 실패할 수 있는 승격 단계, 아무도 쓰기 싫은 병합 로직이 생겨. 태어날 때부터 canonical 은 애초에 폰을 권위로 두지 않음으로써 그걸 전부 삭제해.

'태어날 때부터 canonical'이 사주는 것

대화가 즉시 canonical 이니까, 모든 백엔드 보장을 공짜로 물려받아 — 언젠가가 아니라 첫 턴부터:

완전한 컨텍스트 리플레이. 백엔드가 미래 어느 턴을 위해서든 전체 대화를 재구성할 수 있어. 항상 가지고 있었으니까.
브랜치 의미론. 대화를 다른 어떤 것과 같은 기계로 브랜치하고 탐색할 수 있어. 그게 다른 어떤 것 그 자체니까.
내구성 있는 ground truth. 대화가 첫 턴부터 백엔드의 append-only 로그에 살아. 잃을 수도 있는 폰에만 존재하는 구간이 없어.

트랙 2 의 폰 로컬 outbox 는 이거랑 안 부딪혀. outbox 는 내구성 있는 캡처 — 날아가는 중인 입력의 폰 쪽 대기 구역. 대화 자체는 백엔드에서 canonical 이야. 내구 저장소 둘, 다른 일 둘: outbox 는 들어가는 길의 질문을 지키고; canonical 로그는 도착한 대화를 소유해.

모델이 답하는 질문

어떤 모바일 클라이언트든 물어: '지금 폰이 호수에 빠지면, 대화 상태가 뭐야?' 초안-후-업로드 아래선, 아직 승격 안 된 건 사라져 — 폰이 진실이었으니까. 태어날 때부터 canonical 아래선, 백엔드에 닿은 모든 턴이 온전하고 outbox 에 아직 있는 모든 질문이 알려진 pending 캡처야; 권위 있는 어떤 것도 폰 전용이었던 적이 없어. 그 답이, 클라이언트가 뇌 되기를 거부하는 핵심 전부야.

Code

두 모델, 하나의 호수 테스트·text

초안-후-업로드                      태어날 때부터 CANONICAL
  폰 = 진짜 대화                     백엔드 = 진짜 대화
  백엔드 = 나중 복사본                폰    = 캡처 + 표현

  폰이 호수에:                       폰이 호수에:
    승격 안 된 턴 = 사라짐             배달된 턴 = 백엔드에 안전
    두 출처가 어긋날 수 있음           pending 턴 = 알려진 캡처
    승격이 도중 실패 가능              권위 있는 건 폰 전용이었던 적 없음

// 태어날 때부터 canonical 은 두-출처 문제를 '처리'하지 않아.
// 애초에 두 번째 출처를 안 만들어.

Exercise

같은 챗 기능의 두 설계에 '폰이 호수에' 테스트를 적용해: 하나는 폰이 업로드 전까지 대화를 쥐는, 하나는 모든 턴이 즉시 백엔드에서 canonical 인. 각각에 대해, 폰이 사용 도중 사라질 때 정확히 뭐가 살아남고 뭐가 잃어지는지 적어. 그다음 두 번째 설계가 절대 안 써도 되는 승격/병합 코드를 짚어.

Hint

초안-후-업로드 설계는 '승격이 도중 실패하면?' 이랑 '양쪽 다 바뀌었으면?' 에 답해야 해 — 태어날 때부터 canonical 설계는 절대 안 마주치는 질문들. 폰이 권위였던 적이 없으니까. 진실의 출처를 삭제하면 그 버그 부류 전체가 삭제돼.