"신뢰는 UI 가 주는 느낌이 아냐. 아키텍처가 지키는 약속들이야."
왜 '신뢰'가 구체적이어야 하나
나쁜 연결에서 믿을 수 있는 클라이언트는, 안심시키는 문구나 예쁜 로딩 애니메이션으로 지어지지 않아. 코드가 매번 지키는 몇 개 안 되는 약속으로 지어져. 특히 일이 틀어질 때. Pippa Go 는 네 개를 해. 이 퀘스트의 나머지는 약속당 트랙 하나씩이지만, 들어가기 전에 외울 수 있어야 해 — 나머지 전부가 걸려 있는 척추니까.
그 넷
- 캡처 먼저. 질문이랑 이미지가 네트워크 시도 전에 하나의 원자적 aggregate 로 내구성 있는 기기 저장소에 커밋돼. 링크를 잃으면 상태 플래그가 바뀌지, 입력이 지워지진 않아. (트랙 2)
- 정직한 오프라인. 끊긴 연결은 보이는, 내구성 있는 기다림을 만들지 — 지어낸 답이 아니라. 진짜 답은 canonical 호출이 성공해야만 생겨. (트랙 3)
- 멱등 재시도. device turn ID 가 canonical 로그에 살아. 재시도는 모델을 부르기 전에 완료/대기/모름을 확인해. 크래시나 더블 탭이 두 번 청구하는 일은 없어. (트랙 4)
- 투영, 뇌 아님. 모든 대화는 태어날 때부터 백엔드에서 canonical 이야. 폰은 내구성 있는 캡처랑 표현을 소유하지, Pippa 의 정체성이나 기억, 판단은 절대 안 가져. (트랙 5)
약속은 복리로 쌓여
같이 읽으면, 넷은 체크리스트가 아냐 — 서로 맞물려. 캡처 먼저가 있어야 멱등 재시도가 가능해져. 내구성 있게 기록된 것만 안전하게 재시도할 수 있으니까. 정직한 오프라인은 투영, 뇌 아님에 기대. 클라이언트가 지어내길 거부하는 건, 바로 자기가 진실의 출처가 아니고 그걸 알기 때문이야. 하나 깨면 나머지가 흔들려. 넷 다 지키면 드문 걸 얻어 — 네트워크가 완벽하든 사라졌든 똑같이 행동하는 클라이언트. 제일 필요할 때 실제로 기댈 수 있는 유일한 종류야.
남은 트랙(6, 7, 8)은 이 약속들 주변 모서리를 날카롭게 해: 진짜 이미지 바이트 보내기, prompt macro 를 깨끗한 투영으로 유지하기, 그리고 내 클라이언트를 소유하는 마무리 규율. 근데 네 약속이 심장이야. 외울 줄 알면, 넌 이미 Pippa Go 가 뭔지 이해한 거야.