브랜치로 승격

"승격은 업로드가 아냐. 브랜치야. 백엔드가 이미 할 줄 아는 수를 폰에서 태어난 대화에 겨눈 것뿐이고."

툭 던진 질문에서 제대로 된 스레드로

가끔 폰에서 툭 던진 질문이 알고 보니 더 큰 뭔가의 시작일 때가 있어. 브랜치도 붙고 백엔드 기능도 다 붙은 온전한 대화로 이어가고 싶어지는 거지. 초안 먼저 세계에선 이게 겁나는 작업이야. 폰 상태를 싸서 보내고, 저쪽에서 제대로 복원되길 비는 거니까. 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 이 그 틈을 없앴으니 브랜치로 승격은 건널 게 없는 다리를 물려받아. 마이그레이션 파이프라인 대신 호출 하나 재사용하면 끝이고. 아낀 값은 앞선 결정에서 이미 치른 거야.