브랜치로 승격

"승격은 업로드가 아냐. 브랜치야 — 백엔드가 이미 아는 그 수를, 폰에서 태어난 대화에 겨눈 거."

빠른 질문에서 진짜 스레드로

가끔 폰에서 툭 던진 질문이 더 큰 뭔가의 시작으로 드러나 — 브랜치랑 모든 백엔드 표면을 갖춘 완전한 대화로 계속하고 싶어져. 초안-후-업로드 세계에선 이게 무서운 내보내기일 거야: 폰 상태를 포장하고, 보내고, 충실하게 재구성되길 바라기. Pippa Go 에선 거의 김빠지고, 그게 핵심이야. 폰에서 태어난 대화가 이미 canonical 이었으니까, 그걸 평범한 완전한 대화로 승격하는 건 그냥 백엔드에서의 브랜치 야 — 시스템이 이미 어떤 대화에든 하는 바로 그 연산.

왜 '태어날 때부터 canonical'이 승격을 공짜로 만드나

앞선 약속이 여기서 어떻게 보상하는지 봐. 폰 대화가 로컬 초안이면, 승격은 맞춤 마이그레이션 경로가 필요해: 직렬화, 업로드, ID 매핑, 역사 재구축, 부분 실패 처리. 태어날 때부터 canonical 이니까, 그런 게 아무것도 없어. 대화가 이미 완전한 역사로 백엔드에 있고; '승격'은 '거기서 브랜치해서 계속하기' 를 뜻해, 다른 모든 대화가 쓰는 같은 브랜치 기계를 재사용하며. 제일 어려울 거라 예상할 기능 — 폰 조각을 완전한 스레드로 바꾸기 — 이 거의 코드가 없어. 앞선 결정이 그걸 필요하게 했을 틈을 만들기를 거부했으니까.

재발명보다 재사용

이건 구체적 의상을 입은 일반 교훈이야. 새 능력(폰 Q/A 승격)이 기존 능력(대화 브랜치)을 새 시작점에 겨눈 걸로 드러나면, 맞는 수는 평행 경로를 짓는 게 아니라 기존 기계를 재사용하는 거야. 맞춤 '폰 승격' 파이프라인은 시스템이 이미 하는 걸 하는 두 번째 방식이야 — 더 많은 코드, 더 많은 버그, 더 많은 drift. 브랜치로 승격은 하나의 브랜치 구현이 모든 케이스를 섬기게 지켜. 우아함은 영리함이 아냐; 애초에 대화를 fork 하기를 거부한 데 대한 보상이야.

Code

승격 = 이미-canonical 대화를 브랜치·typescript

// 폰에서 태어난 대화는 이미 canonical, 그래서 '승격'은 브랜치를 재사용.
async function promoteToFullConversation(phoneConvId: string) {
  // 내보내기 없음, 업로드 없음, ID 재매핑 없음 — 이미 백엔드에 있음.
  return branchConversation(phoneConvId); // 어떤 대화든 쓰는 그 호출
}

// 네가 안 써도 되는 초안-후-업로드 버전이랑 비교해:
//   serialize(phoneState) -> upload() -> remapIds() -> rebuildHistory()
//   -> handlePartialFailure() -> reconcile()
// 그 전부가 기존 branch() 호출 하나로 접혀.

Exercise

초안-후-업로드 클라이언트가 폰 대화를 완전한 걸로 승격하는 데 필요한 단계를 열거해(직렬화, 업로드, 재매핑, 재구축, 화해). 그다음 브랜치로 승격 버전을 써. 각각의 줄 수랑 실패 모드를 세. 마지막으로, 짧은 버전을 가능하게 한 앞선 설계 결정을 이름 붙여 — 그리고 여기의 우아함이 여기가 아니라 그때 구매됐다는 걸 적어.

Hint

긴 버전의 모든 단계는 두 진실의 출처 사이 틈을 잇기 위해 존재해. 태어날 때부터 canonical 이 틈을 없앴으니, 브랜치로 승격은 빈 다리를 물려받아 — 마이그레이션 파이프라인 대신 재사용된 호출 하나. 절약은 앞선 결정에 선불됐어.