"신뢰는 UI 가 주는 느낌이 아냐. 아키텍처가 지키는 약속들이야."
왜 '신뢰'가 구체적이어야 하나
연결이 나쁠 때 믿을 수 있는 클라이언트는 안심시키는 문구나 예쁜 로딩 애니메이션으로 만들어지는 게 아냐. 코드가 매번, 특히 일이 틀어질 때 지키는 몇 안 되는 약속으로 만들어져. Pippa Go 는 그걸 넷 해. 퀘스트 나머지가 약속 하나에 트랙 하나씩이긴 한데, 들어가기 전에 이 넷은 외워 두는 게 좋아. 나머지가 전부 여기 매달려 있는 척추거든.
그 넷
- 캡처 먼저. 질문이랑 이미지가 네트워크에 손대기 전에 통째로 한 덩어리가 돼서, 앱이 죽어도 안 사라지는 기기 저장소에 커밋돼. 링크가 끊기면 상태 플래그가 바뀌지 입력이 지워지진 않아. (트랙 2)
- 정직한 오프라인. 연결이 끊기면 눈에 보이는 기다림이 생기지 지어낸 답이 생기진 않아. 진짜 답은 canonical 호출이 성공해야만 나와. (트랙 3)
- 멱등 재시도. device turn ID 가 canonical 로그에 남아 있어. 재시도는 모델을 부르기 전에 완료인지 대기인지 모름인지부터 확인하고. 크래시나 더블 탭 때문에 두 번 청구되는 일은 없어. (트랙 4)
- 투영이지 뇌가 아님. 대화는 전부 태어날 때부터 백엔드에서 canonical 이야. 폰이 맡는 건 안 날아가는 캡처랑 화면에 보여주는 것까지지, Pippa 의 정체성이나 기억이나 판단은 절대 아냐. (트랙 5)
약속은 복리로 쌓여
넷을 같이 놓고 보면 체크리스트가 아니라 서로 맞물린 톱니라는 게 보여. 캡처 먼저가 돼야 멱등 재시도가 가능해. 안 없어지게 적어둔 것만 안전하게 재시도할 수 있으니까. 정직한 오프라인은 투영이지 뇌가 아님에 기대고 있어. 클라이언트가 지어내길 거부하는 건 자기가 진실의 출처가 아니라는 걸 알기 때문이거든. 하나 깨지면 나머지가 흔들려. 넷을 다 지키면 흔치 않은 걸 얻어. 네트워크가 완벽하든 아예 없든 똑같이 행동하는 클라이언트. 제일 아쉬운 순간에 진짜로 기댈 수 있는 건 그런 것뿐이야.
남은 트랙 6, 7, 8 은 이 약속들 언저리를 좀 더 뾰족하게 다듬어. 진짜 이미지 바이트 보내기, prompt macro 를 깨끗한 투영으로 유지하기, 그리고 내 클라이언트는 내가 갖는다는 마무리 규율. 그래도 심장은 네 약속이야. 이 넷을 외웠으면 Pippa Go 가 뭔지는 이미 이해한 거야.