"원격 호출을 아예 안 짓는 오프라인 요청은 못 새. 그건 약속이 아니라 모양이야."
Rekindle 유산
Firekeeper 의 글쓰기 형제 Rekindle 이 오프라인 모드에 대해 빡빡한 규칙을 배웠고, Firekeeper 가 그걸 그대로 물려받았어. 프로바이더 선택은 바이트 하나가 프로세스를 떠나기 전에 끝난다. 지금 켜져 있는 연결 모드가 먼저 구체적인 프로바이더로 결정돼. 요청은 그다음에야 만들어지고 나가고. 사소한 디테일처럼 들리지. 사실은 진짜 오프라인과 오프라인 연극을 가르는 전부야.
두 아키텍처, 하나의 치명적 차이
폴백을 짜는 방법 두 가지를 비교해 봐. 실패하면 폴백 하는 설계는 원격 호출을 먼저 시도하고, 실패했을 때만 로컬로 돌려. 그 말은 오프라인으로 처리하려던 요청이 누가 확인하기도 전에 이미 네트워크 호출을 시도했거나 최소한 준비했다는 뜻이야. 보내기 전에 선택 하는 설계는 고른 모드에서 프로바이더를 미리 정해. 그러면 오프라인 요청은 로컬 프로바이더로 가고 원격 호출은 아예 지어지지도 않아. 실패하면 폴백하는 쪽은 아무것도 안 샜기를 바라는 거고, 보내기 전에 고르는 쪽은 샐 수가 없게 구조로 막아 버리는 거야.
실패하면 폴백 (연극):
원격 호출 짓기 -> 전송 시도 -> 실패? -> 이제 로컬로 # 원격이 시도됐어!
보내기 전에 선택 (진짜):
고른 모드 읽기 -> 오프라인? -> 로컬 호출만 짓기 # 원격이 존재 안 함
왜 조심하는 것보다 구조가 나은가
실패하면 폴백하는 설계도 조심스러운 확인으로 안전하게 만들 수는 있어. '온라인일 때만 보내고, 나가기 전에 꼭 취소해' 처럼. 그런데 조심성은 약해. 리팩터 한 번, 레이스 한 번, 잊어버린 분기 하나면 원격 호출이 새어 나가. 보내기 전에 고르는 방식은 조심성에 안 기대. 오프라인 모드에선 원격 요청을 짓는 코드 경로에 아예 닿지를 않아. 그러니 샐 게 없지. 안전이 위에 볼트로 조여 붙인 가드가 아니라 제어 흐름에서 따라 나오는 성질이면, 실수로 되돌릴 수가 없어.