Crumb 계보

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

검증된 패턴에서 태어남

Pippa Go 는 빈 스케치에서 시작하지 않았어. 다른 데서 이미 밥값을 한 패턴에서 시작했어. Waystone — 여행 클라이언트, 신호 불안한 데서 여행 도중 폰으로 브레인스토밍한 — 에는 Crumb 이라는 작은 composer 가 있어. 그 순간의 부스러기(메모, 사진, 장소)를 툭 떨구면 기기에 먼저 커밋되고, 가능할 때 백엔드로 동기화돼. 여행 중에 절대 할 수 없는 딱 하나가 '방금 잡으려던 순간을 잃는 것'이라서 지어졌어.

그 Crumb 흐름 — 작은 단위를 로컬에 캡처하고, sync 상태를 보여주고, 네트워크가 따라잡게 하기 — 이 알고 보니 모바일 Q/A 클라이언트가 필요로 하는 바로 그 모양이었어. Pippa Go 는 그 Crumb 개념을 여행에서 들어올려, 전용 단위 하나 — 질문 — 를 중심으로 다시 지은 거야.

계보는 디자인 방법이지 향수가 아냐

검증된 패턴을 재사용하는 건 게으름이 아냐. 추측의 반대야. Crumb 은 이미 어려운 케이스를 살아남았거든 — 작성자가 실제로 그게 필요할 때의 불안한 연결. 그 계보를 이어받는다는 건, 새 디자인이라면 프로덕션에서야 발견할 질문들에 대한 실전 검증된 답을 Pippa Go 가 물려받는다는 뜻이야:

뭐가 먼저 커밋돼, 기기야 네트워크야? 기기. (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

재사용 가능한 부분은 거의 내용이 아냐. 생명주기 — 로컬-커밋, 상태-보여주기, 멱등-동기화 — 야. 두 기능이 그 생명주기를 공유하면, 골격을 공유할 수 있어.