Pippa Go 가 뭔지 (그리고 뭐가 아닌지)

"더 작은 챗 앱이 아냐. 머릿속 질문에서 진짜 답까지, 가장 빠르고 정직한 경로야."

딱 하나의 일, 꽉 붙잡고

Pippa Go 가 지어진 그 순간을 그려봐. 기차 안, 신호 한 칸, 지금 당장 Pippa 한테 묻고 싶은 질문이 머리에 떠올라 — 지금 보고 있는 그것 사진까지 붙여서. 폰 앱 열고, 쓰고, 붙이고, 전송. 그 흐름 하나 — 질문 잡고, 이미지 나르고, 진짜 답 받고, 링크 끊겨도 질문 안 잃기 — 가 일 전부야. 이 퀘스트의 모든 게 그걸 지키려고 존재해.

대부분의 '모바일 클라이언트'는 이 순간에 무너져. 전송 버튼을 저장 버튼처럼 다루거든. 그래서 연결 끊기면 입력이 먹혀버려. Pippa Go 는 그걸 뒤집어. 전송은 운송이고, 저장은 이미 조금 전에 로컬에서 끝나 있어.

날카로운 부정 셋

어떤 것의 모양을 제일 빨리 보는 법은, 일부러 되지 않기로 한 걸 짚는 거야:

풀 챗의 축소판 아님. 브랜치, council, artifact, 관리, 전체 트랜스크립트 리플레이 — 그건 canonical 백엔드에 살아. 그걸 폰에 욱여넣으면, 이미 있는 걸 더 나쁘게 만든 버전이 될 뿐이야.
두 번째 Pippa 아님. Pippa 는 딱 하나야. 정체성, 기억, 판단, 모델 라우팅 전부 백엔드에 있어. Pippa Go 는 평행 soul 도, 두 번째 모델 라우터도, 경쟁하는 진실의 출처도 안 키워.
오프라인 챗봇 아님. 캡처는 오프라인에서 아름답게 되지만, 진짜 답은 여전히 진짜 Pippa 한테 닿아야 나와. 오프라인이 '로컬에서 대충 지어내기'인 적은 없어.

남은 게 곧 제품

그 셋을 빼면 진짜 제품이 또렷해져: 견고한, 질문 우선의 투영. 내구성 있는 기기 로컬 캡처, 재시도 상태, 오프라인 outbox, macro 캐시, 연결 설정을 소유해. 집중된 Q/A 표면을 보여줘. 그 뒤에선 모든 대화가 태어날 때부터 백엔드에서 canonical 이고, 평범한 컨텍스트 리플레이랑 브랜치 의미를 그대로 가져 — 폰은 그저 거기로 가는 가장 닿기 쉬운 창일 뿐이야.

이 단어를 붙잡아: 투영(projection). 투영은 그것이 되지 않으면서 그것을 보여줘. 벽에 진 그림자는 물체가 움직이면 따라 움직이지, 혼자 움직이겠다고 결정하진 않아. Pippa Go 가 그 그림자야 — 충실하고, 닿기 쉽고, 자기를 드리운 몸으로 절대 착각되지 않는.

Code

Pippa Go 한 턴, 폰이 쥐고 있는 모양 (스케치)·json

{
  "device_turn_id": "d7f3c1a2-9b4e-4c8a-bf10-2e5a6d0c1234",
  "question": "이 두 렌즈 중에 35mm 가 어느 쪽이야?",
  "attachments": [
    { "local_id": "img-01", "media_type": "image/jpeg", "bytes_ref": "idb:blob:img-01" }
  ],
  "sync_status": "pending",   // pending -> sending -> answered | failed
  "created_at_device": "2026-07-16T09:14:02Z"
}

// 질문이랑 이미지는 하나의 aggregate, 기기에 먼저 저장돼.
// sync_status 는 네트워크가 뒤집는 플래그일 뿐. 네트워크가 데이터를 소유하진 않아.

Exercise

입력을 잃어버렸던 모바일 앱을 하나 떠올려봐 — 연결 나빠서 초기화된 폼, 전송 도중 사라진 메시지, 실패하면서 캡션까지 데려간 사진 업로드. 정확히 뭐가 사라졌는지 적고, 물어봐: 그 '저장'이 네트워크에 묶여 있었나, 기기에 묶여 있었나? 입력을 잃은 이야기는 거의 다, 실은 전송이었던 저장 이야기야.

Hint

앱을 닫거나 신호를 잃었을 때 작업이 지워졌다면, 그 앱은 로컬에 먼저 커밋한 적이 없는 거야. 해법은 거의 항상 '기기에 저장하고, 그다음 운송' — Pippa Go 가 세워진 바로 그 뒤집기야.