pending, sending, answered, failed — 다 보이게

"영영 안 끝나는 스피너는 애니메이션 붙은 거짓말이야. 진짜 상태를 보여줘, 그 진짜 상태가 '기다림'일 때조차."

UI 가 시스템보다 더 자신만만하면 안 돼

정직한 오프라인은 데이터 규칙만이 아냐. UI 규칙이기도 해. 인터페이스는 시스템이 실제로 가진 것보다 더 큰 확신을 주장하면 안 돼. 오프라인이라 턴이 pending 이면, 화면은 기다림이라고 해야 해 — 작업이 일어나는 척하는 스피너 말고, 절대 끝났다는 척하는 체크마크도 말고. 트랙 2 의 내부 상태 넷은 코드만을 위한 게 아냐. 각각 사용자가 한눈에 읽을 수 있는 뚜렷하고 참된 표면을 받을 자격이 있어.

네 상태, 네 정직한 얼굴

Pending — 캡처됨, 아직 안 보냄(종종 오프라인). 그렇게 말해: '저장됨. Pippa 한테 닿기를 기다리는 중.' 차분하고 안전한 상태고, UI 도 놀란 게 아니라 차분하게 느껴져야 해.
Sending — 능동적으로 배달 중. 스피너가 여기선 정직해. 지금 진짜로 작업이 일어나고 있으니까.
Answered — canonical 호출에서 진짜 답이 생김. 이제야 답이 나타나.
Failed — 배달 시도했고 에러남. 재시도 손잡이랑 같이 있는 그대로 보여줘. 턴은 안전하고 다시 보낼 수 있고, UI 는 딱 그걸 전해야 해, 패닉 말고.

규율은 일대일이야: 진짜 시스템 상태에 대응하지 않는 UI 상태는 없어야 하고, 보이지 않는 시스템 상태도 없어야 해. 그 둘이 맞으면, 사용자의 신뢰가 계속 벌려 — 보는 게 항상 참이니까.

왜 '보이는'이 '낙관적'을 이기나

낙관적 UI — 확인 전에 성공을 보여주기 — 는 빨라 보여서 인기야. 근데 나쁜 조건에서의 신뢰가 가치 전부인 클라이언트한텐, 낙관은 복리로 쌓이는 작은 거짓말이야. 배달 전에 메시지를 '보냄'으로 보여주면, 불안한 링크에서 사용자는 뭐가 통과했는지에 대한 틀린 모델을 쌓아. Pippa Go 는 낙관적보다 보이는을 택해: 항상 참인 조금 덜 경쾌한 pending 배지가, 가끔 거짓인 만족스러운 체크마크를 이겨. 그 배지가 렌더된 약속이야.

Code

진짜 상태당 참된 라벨 하나·typescript

function statusLabel(turn: PippaGoTurn): { text: string; spinner: boolean } {
  switch (turn.syncStatus) {
    case "pending":  return { text: "저장됨 · Pippa 한테 닿기를 기다리는 중", spinner: false };
    case "sending":  return { text: "보내는 중…",                        spinner: true  };
    case "answered": return { text: "답변됨",                            spinner: false };
    case "failed":   return { text: "Pippa 한테 못 닿음 · 눌러서 재시도",  spinner: false };
  }
}

// 스피너는 'sending' 에만 true — 작업이 진짜로 일어나는 유일한 순간.
// 'pending' 은 가짜 진행 애니메이션이 아니라 차분하고 정직해.

Exercise

Pippa Go 턴의 네 상태 배지를 설계해봐: 정확한 문구, 각각 스피너를 보이는지, 각각 어떤 탭 동작(있다면)을 주는지. 그다음 스트레스 테스트: 온라인/오프라인을 세 번 뒤집는 불안한 연결에서, 어느 배지든 시스템이 아는 것보다 더 주장한 적 있어? 그 깜빡임 중에 배지가 거짓말할 수 있으면, 못 하게 될 때까지 다시 설계해.

Hint

위험한 건 전이야. 연결 끊긴 뒤 'sending' 이 보이는 채로 멈추면, 거짓말하는 스피너가 돼 — 그러니 'sending' 중 링크 끊김은 'pending' 이나 'failed' 로 전이해야지, 아무것도 없는 위에 스피너를 돌게 두면 안 돼.