질문 우선, 축소판 챗 아님

"스코프가 곧 기능이야. 안 만들기로 한 그것이, 만든 그것을 좋게 만들어."

줄이고 싶은 유혹

누가 '모바일 버전 필요해' 하면, 기본 반사는 데스크톱 앱을 줄이는 거야. 똑같은 사이드바, 똑같은 대화 목록, 똑같은 전부를 40% 크기로. 안전해 보여 — '기능을 빼는' 게 아니니까. 근데 줄인 데스크톱 앱은 더 나쁜 데스크톱 앱이야. 폰에서, 기차에서, 한 손으로, 사이드바 원하지 않아. 질문을 하고 싶은 거야.

Pippa Go 는 반대로 걸어. 폰에서 제일 중요한 상호작용 하나를 골라서 그걸 탁월하게 만들지, 모든 상호작용을 다 넣고 다 그저 그렇게 만들지 않아. 기본 단위는 질문이랑 그 답. 그 제약은 작은 기능 세트가 아니라 — 더 날카로운 제품이야.

질문 우선이 실제로 사주는 것

기본 단위 하나를 고르면 그 아래 모든 데서 이득이 돌아와:

캡처 흐름을 방탄으로 만들 수 있어. 입력 타입 하나(질문 + 선택적 이미지)는 원자적으로 저장하고 깔끔하게 재시도할 만큼 작아. 편집 가능한 대화 트리 전체는 안 그래.
오프라인 이야기가 단순해져. '이 질문 하나를 링크 돌아올 때까지 붙잡기'는 실제로 지킬 수 있는 약속이야. '임의의 브랜치 대화를 오프라인 동기화'는 연구 프로젝트고.
화면이 정직하게 남아. 집중된 표면은 sync 상태, 재시도 버튼, 대기 상태를 또렷하게 보여줄 공간이 있어 — 네트워크가 불안할 때 신뢰를 쌓는 것들.

전체 대화는 여전히 존재해 — 백엔드에서 canonical 이고, 거기서 브라우징하고 브랜치할 수 있어. Pippa Go 는 그냥 '그걸 하는 곳'이 되기를 사양할 뿐이야. 여긴 묻는 곳이야.

집중은 기능 빈곤이 아냐

사진만 찍는 카메라 앱은 영상 편집이 '빠진' 게 아니야. 카메라인 거지. Pippa Go 가 질문 우선인 건, 뭐가 없다고 사과하는 벗겨진 챗 클라이언트가 아냐. 자기 일을 아는 도구야. '그냥 작은 대화 목록만' 이나 '그냥 인라인 브랜치만' 을 넣고 싶을 때마다, 물어봐: 그게 딱 하나의 일 — 질문, 답해짐, 절대 안 잃음 — 에 봉사하나, 아니면 데스크톱 줄이기 반사가 슬그머니 돌아온 건가.

Code

표면 전체를, 타입으로·typescript

// 질문 우선은 핵심 상태가 작고 읽기 쉽다는 뜻.
type PippaGoTurn = {
  deviceTurnId: string;
  question: string;
  attachments: StagedImage[];
  syncStatus: "pending" | "sending" | "answered" | "failed";
  answer?: string; // canonical 호출이 성공해야만 채워짐
};

// 여기 '없는' 걸 봐: 대화 트리 없음, 브랜치 포인터 없음,
// council 상태 없음, artifact 저장소 없음. 그건 백엔드 거야.
// 폰은 이것들의 큐를 쥐고, 그게 모델 전부야.

Exercise

데스크톱이랑 폰에서 둘 다 쓰는 앱을 하나 골라. 폰 버전에서 실제로 하는 상위 3가지를 적어. 이제 그 3가지'만' 아름답게 하고 나머지는 사양하는 클라이언트를 상상해봐. 뭐가 나아져 — 속도, 신뢰성, 한 손 사용? 진짜로 아쉬울 건 뭐야? '빠진' 기능 대부분은 모바일에선 안 쓰는 데스크톱 반사로 드러나.

Hint

진짜 아쉬울 기능이 진짜 기본 단위를 드러내. '데스크톱에 있으니까'로만 적은 것들이 바로 집중된 클라이언트가 사양해야 할 것들이야.