내구성 있는 기다림, 가짜 답 아님

"오프라인은 크래시가 아냐. 네 질문이 문 열리기를 안전하게 기다리는 방이야."

오프라인은 상태지 에러가 아냐

앱들은 대개 오프라인을 실패로 모델링해. 빨간 배너, 그냥 버려지는 동작, 입력은 이미 던져버린 뒤에 뜨는 '나중에 다시 시도해 주세요'. Pippa Go 는 오프라인을 세상의 정상 상태로 봐. 어떨 땐 링크가 있고 어떨 땐 없어. 둘 다 예외가 아니야. 연결 없이 질문해도 깨지는 건 하나도 없어. 질문은 캡처되고, 안 없어지게 박히고, 기다리는 중으로 표시돼. 안테나 꽉 찬 데서 물어본 질문이랑 똑같이 안전하게 outbox 에 앉아 있어. 다른 건 아직 배달이 안 됐다는 것뿐이고.

이렇게 다시 보는 게 왜 중요하냐면, 오프라인을 어떻게 모델링하느냐가 최악의 순간에 코드가 뭘 할지를 정하거든. 에러로 모델링하면 반사적으로 에러를 처리하게 돼. 버리거나, 무작정 다시 보내거나, 결과를 지어내면서. 상태로 모델링하면 반사가 상태를 표현하는 쪽으로 붙어. 캡처하고, pending 으로 표시하고, 정직하게 기다리는 거지.

'내구성 있는 기다림'이 실제로 뜻하는 것

여기서 말하는 기다림은 막연한 게 아냐. 세 조각으로 된 구체적인 보장이야.

안 없어짐. 기다리는 질문이 앱이 죽어도, 재부팅해도, 몇 시간을 오프라인으로 있어도 그대로야. 메모리가 아니라 outbox 에 살고 있으니까.
기다림. 상태가 정직하게 pending 이야. answered 도 아니고, 소리 없이 버려지지도 않고. UI 가 'Pippa 한테 닿기를 기다리는 중' 이라는 진짜 상태를 보여줘.
다시 이어짐. 링크가 돌아오는 순간 그 질문이 알아서 배달돼. 사용자가 뭘 또 누를 필요 없이.

셋을 합치면 사용자 머릿속 그림이 믿을 만해져. '나 물어봤고, 저장됐고, 될 때 나갈 거다.' 이 문장은 셋이 다 성립할 때만 참이야. 안 없어지는 걸 빼면 재부팅 한 번에 질문이 날아가. 정직함을 빼면 UI 가 다 끝났다고 거짓말하고. 다시 이어지는 걸 빼면 사용자가 전송되는 걸 지켜보고 앉아 있어야 해.

다른 길은 조용한 배신이야

오프라인일 때 솔깃한 지름길은 사용자한테 뭐라도 쥐여 주는 거야. 캐시해 둔 답, 로컬 추측, '아마 Pippa 는 이렇게 말할걸' 하는 낙관. 도움 되는 것 같지? 배신이야. 진짜 질문을 했는데 Pippa 얼굴을 뒤집어쓴 조작된 답을 받은 거잖아. 여기선 그 거래를 거부해. 1초 만에 나오는 자신만만한 거짓말보다 한 시간짜리 정직한 '기다리는 중' 을 골라. 다음 레슨들이 그 거부를 더 촘촘하게 만들 거야.

Code

오프라인은 상태, 처리는 표현으로·typescript

async function ask(turn: PippaGoTurn) {
  await commitLocally(turn);          // 무슨 일이 있어도 캡처됨
  if (!navigator.onLine) {
    await setStatus(turn.deviceTurnId, "pending"); // 정직한 기다림
    return;                            // 에러 아님, 가짜 답 아님
  }
  await enqueueForDelivery(turn);
}

// 'else 지어내기' 분기도 없고 'throw offlineError' 도 없어.
// 오프라인은 그냥 턴이 내구성 있게, 보이게 기다리는 경로일 뿐이야.

Exercise

자주 쓰는 앱을 하나 골라서, 오프라인일 때 뭔가 하면 어떻게 굴러가는지 적어 봐. 동작을 버려? 결과를 지어내? 아니면 캡처해 놓고 정직하게 기다려? 그다음 그 행동을 내구성 있는 기다림으로 다시 써 봐. 뭘 캡처하고, 어떤 상태를 보여주고, 언제 다시 이어갈지. '에러를 처리한다'가 실은 '작업을 날린다'인 경우가 얼마나 많은지 보일 거야.

Hint

가르는 기준은 오프라인 상태로 재부팅했을 때 그 작업이 살아남느냐야. 살아남고 정직한 pending 상태를 보여주면 내구성 있는 기다림이 맞아. 사라지거나 뭔가 지어내면, 그 앱은 오프라인을 상태가 아니라 에러로 모델링한 거고.