Crumb 계보

"견고한 캡처 흐름을 두 번 발명하진 않아. 한 번 검증하고, 전용 집을 주는 거야."

검증된 패턴에서 태어남

Pippa Go 는 빈 스케치에서 시작하지 않았어. 다른 데서 이미 밥값을 한 패턴에서 시작했어. Waystone 이라는 여행 클라이언트가 있어. 신호 불안한 데를 돌아다니면서 폰으로 브레인스토밍해 만든 물건이야. 거기 Crumb 이라는 작은 composer 가 있어. 그 순간의 부스러기(메모, 사진, 장소)를 툭 떨구면 기기에 먼저 커밋되고, 나중에 가능할 때 백엔드로 동기화돼. 여행하면서 제일 하면 안 되는 게 방금 붙잡으려던 순간을 놓치는 거라, 그렇게 만든 거야.

Crumb 흐름이 뭐냐면 이래. 작은 단위를 로컬에 캡처하고, sync 상태를 보여주고, 네트워크가 알아서 따라오게 하기. 알고 보니 모바일 Q/A 클라이언트한테 필요한 게 딱 그 모양이었어. 그래서 Pippa Go 는 Crumb 개념을 여행에서 통째로 들어내서, 질문이라는 단위 하나를 중심으로 다시 지었어.

계보는 설계 방법이지 향수가 아냐

검증된 패턴을 재사용하는 건 게으름이 아냐. 추측의 반대편이야. Crumb 은 이미 제일 어려운 상황을 견뎌 봤거든. 쓰는 사람이 진짜로 그게 필요한 순간에 하필 불안해지는 연결. 그 계보를 이어받는다는 건, 새로 설계했으면 프로덕션에 가서야 알았을 질문들에 대해 이미 답을 물려받는다는 뜻이야.

뭐부터 커밋돼, 기기야 네트워크야? 기기. (Crumb 이 어렵게 배웠어.)
동기화되는 동안 사용자는 뭘 봐? 있는 그대로의 정직한 상태. 거짓말하는 스피너 말고.
동기화 도중에 앱이 죽으면? 캡처해 둔 단위가 살아남아서 이어져. 네트워크에 손대기 전에 이미 안 없어지게 박아뒀으니까.

같은 뼈대, 다른 몸

Waystone 의 Crumb 은 여행 부스러기를 캡처하고, Pippa Go 의 composer 는 이미지 붙은 질문을 캡처해. 담기는 내용은 달라도 골격은 똑같아. 로컬에 먼저 커밋, 보이는 sync 상태, 몇 번을 해도 안전한 따라잡기. 시스템 한 구석에 어렵게 얻은 패턴이 있다면, 제일 남는 장사는 옆에 새로 만드는 게 아냐. 같은 골격이라는 걸 알아보고 걸맞은 집을 따로 내주는 거지. 그렇게 알아본 덕분에 여행 기능 하나가 자기 제품이 됐어.

Code

골격 하나, 몸 둘·typescript

// Waystone 의 Crumb 이랑 Pippa Go 의 질문은 모양을 공유해.
interface LocalFirstCapture<TPayload> {
  localId: string;
  payload: TPayload;              // 부스러기, 또는 질문+이미지
  syncStatus: "pending" | "sending" | "synced" | "failed";
  commitLocally(): Promise<void>; // 네트워크 호출 전에 항상 실행
  trySync(): Promise<void>;       // 멱등; 다시 불러도 안전
}

// Waystone: LocalFirstCapture<Breadcrumb>
// Pippa Go: LocalFirstCapture<QuestionWithImages>
// 골격이 계보야. payload 만 새 부분이고.

Exercise

네가 만들었거나 써 본 시스템을 봐. 이미 튼튼한 패턴이 자리 잡은 데를 하나 찾아. 초안 자동 저장, 재시도 큐, 오프라인 캐시 같은 거. 이제 똑같은 튼튼함이 필요한데 따로 다시 만들었거나 아예 없는 두 번째 자리를 찾아. 첫 번째 골격을 들어내서 재사용하면 어떤 모양이 될지 스케치해 봐. 뼈대는 그대로, payload 만 새것. Pippa Go 가 딱 그렇게 태어났어.

Hint

재사용할 수 있는 건 대개 내용이 아니라 생명주기야. 로컬에 커밋하고, 상태 보여주고, 몇 번을 돌려도 안전하게 동기화하는 그 흐름. 두 기능이 그 흐름을 공유하면 골격도 공유할 수 있어.