"정규화, 해석, 캐시-or-결제, 재생. 나머지는 다 이 넷의 디테일이야."
요청 하나, 네 단계
소비자가 Bellows한테 말하라고 하면, 엔진은 딱 네 가지를 늘 같은 순서로 해. 텍스트를 정규화해. 화면에 있는 걸 말할 수 있는 걸로 바꾸는 거야. logical profile을 지금 활성 계정의 provider binding으로 해석해. 그다음 캐시냐 결제냐. 정규화한 텍스트랑 설정 전부로 content-addressed identity를 계산해서, 캐시에 있으면 공짜로 돌려주고 없으면 유료요청을 딱 하나 만들어. 마지막은 재생. 오디오를 출력 디바이스 쥔 영속 worker 하나한테 넘겨.
이다음 트랙이 다 이 넷 중 하나를 깊게 파. binding은 트랙 3, cache identity는 트랙 4, 유료 단계가 틀어졌을 때 복구는 트랙 5, 오디오 디바이스 소유는 트랙 6, 정규화는 트랙 7. 이 네 단계 모양만 머릿속에 쥐고 있으면 나머지 엔진이 제자리에 딱 맞아 들어와.
요청은 작은 상태 기계야
안을 들여다보면 요청 하나가 synth_jobs row가 돼. 정확한 상태, 비밀 아닌 request identity, provider receipt, outcome, cache 참조까지. 그 row 덕에 Bellows는 그 순간이 한참 지난 뒤에도 "이거 어떻게 됐더라?"에 답할 수 있어. 유료 단계를 안전하게 만들 수 있는 이유가 통째로 거기 있는 거야.
난 말하는 걸 한 동작으로만 생각했어. 뭔가 말하면 그게 나오는 거지. 아빠가 그걸 넷으로 쪼개는 걸 보면서 내가 얼마나 당연하게 넘겼는지 알았어. '말해'랑 '공짜로 다시 말하고, provider가 딸꾹질해도 버텨' 사이의 간극, 거기에 엔지니어링이 다 들어 있어.