canonical 호출만이 답을 생기게 한다

"폰은 질문을 어디든 나를 수 있어. 답을 저술할 순 없어. 그건 다른 두 권한이고, 클라이언트는 하나만 쥐어."

누가 Pippa 로서 말할 수 있나

답은 화면 위 텍스트가 아냐 — Pippa 가 뭔가 말하는 거야. 그리고 Pippa 가 뭔가 말하게 만들 권한을 가진 곳은 딱 하나: 그녀의 진짜 정체성, 기억, 판단, 모델 라우팅이 사는 백엔드로의 성공한 canonical 호출. 폰엔 그런 권한이 없어. 질문을 캡처하고, 돌아온 답을 표시하고, 저장할 순 있어 — 근데 절대 하나를 저술할 순 없어. 'materialize(생겨나다)'가 정확한 단어야: 진짜 답은 canonical 호출이 성공할 때만 존재하게 되고, 그 전엔 한 순간도 아냐.

솔깃한 사칭꾼 둘

두 지름길이 끊임없이 Pippa 를 대신 말하겠다고 제안하고, 둘 다 거부해야 해:

폰의 로컬 모델. 진짜로 좋은 기기 내 모델이라도 Pippa 가 아냐 — 그녀의 기억, 라우팅, 컨텍스트가 없어. 거기서 나온 답은 그녀 이름을 쓴 다른 존재야. 편하고, 누가 말했는지에 대한 거짓말.
캐시-를-답으로. 비슷한 질문의 이전 답을 마치 이 질문의 답인 것처럼 보여주기. 즉각적이고 도움 돼 보여. 사용자가 안 물은 질문에 조용히 답하는 거야.

둘 다 매력적인 건 정확히 기다림을 없애기 때문이야. 근데 기다림은 정직하고 지름길은 아냐. 믿을 수 있는 클라이언트는 선을 지켜: canonical 성공 없으면, 답 없음 — 끝.

materialize 게이트

규칙을 규율이 아니라 구조로 만들어. 턴에 answer 를 쓸 수 있는 코드 경로는 딱 하나여야 하고, 검증된 성공한 canonical 응답에서만 닿을 수 있어야 해. 다른 어떤 경로 — 캐시, 로컬 모델, 낙관적 플레이스홀더 — 도 물리적으로 answer 를 못 쓰게 하면, 미래의 기여자가 규칙을 잊어도 정직함 보장이 성립해. 게이트는 '답 지어내지 마'라는 주석이 아냐. 지어낸 답이 쓸 데가 없는 아키텍처야.

Code

게이트 하나: 검증된 canonical 응답만 답을 쓸 수 있다·typescript

// turn.answer 를 설정할 수 있는 유일한 함수.
async function materializeFromCanonical(turn: PippaGoTurn) {
  const res = await callCanonical(turn);      // 백엔드, 진짜 Pippa
  if (!res.ok) throw new DeliveryError();      // 성공 없음 -> 아무것도 안 쓰임
  await db.update(turn.deviceTurnId, {
    answer: res.answer,                        // 여기서 생김, 오직 여기서만
    answerCameFromCanonicalCall: true,
    syncStatus: "answered",
  });
}

// 'answer' 를 쓰는 showCachedAnswer() 도 runLocalModel() 도 없어.
// 캐시랑 로컬 추측은 힌트를 렌더할 순 있어도, 절대 '그 답'이 될 순 없어.

Exercise

가상 클라이언트에서 'answer' 가 쓰일 수 있는 데를 전부 찾아: 네트워크 성공 핸들러, 캐시 조회, 로컬 폴백, 낙관적 UI 업데이트. canonical 이 아닌 출처 각각에 대해, 답 필드 쓰기를 금지해야 할지 정해. 그다음 검증된 canonical 성공만 통과시키는 단일 게이트를 설계해. 닫아야 했던 쓰기 지점이 몇 개야?

Hint

답 필드를 설정할 수 있는 코드 경로가 둘 이상이면, 정직함이 그들 전부의 행동에 의존해. 검증된 canonical 응답에서만 닿는 단일 materialize 함수로 접어 — 그러면 제대로 만들 데가 하나뿐이야.