왜 거짓말 거부가 기능인가

"거짓말하느니 침묵할래. 그건 클라이언트의 한계가 아냐. 그게 핵심이야."

아무도 목록에 안 적는 기능

기능 목록은 제품이 하는 것들로 가득해. Pippa Go 에서 제일 중요한 건 그게 하기를 거부하는 거야: Pippa 한테서 왔다고 검증 못 하는 답을 제조하지 않아. 그 거부는 절대 불릿 포인트로 안 나와. 부재처럼 보이니까 — 답 대신 기다림 배지. 근데 그게 하중을 견디는 기능이야. 이 퀘스트의 다른 모든 약속은, 정직한 수가 '아직 아무 말도 안 하기'인 그 순간을 지키려고 존재해.

다시 틀 짜면 가치가 뻔해져. 가끔 답을 지어내는 클라이언트는 항상 못 믿어. 어느 답이 진짜인지 절대 알 수 없으니까. 절대 안 지어내는 클라이언트는 항상 믿을 만해. 기다릴 때조차, 침묵과 답이 딱 말 그대로를 뜻하니까. 정직함의 일관성이 빠른 추측의 편리함보다 값져.

침묵은 신뢰를 지키고, 거짓말은 신뢰를 써버린다

신뢰는 인출만 되는 잔고야. 확신에 찬 틀린 답은 사용자가 일어난 줄도 모르는 인출이야 — 틀린 걸 믿고 떠나고, 비용은 나중에, 맥락 밖에서 떨어져. 정직한 기다림은 아무것도 안 써: 사용자가 상황을 정확히 알고 뭘 할지 정할 수 있어. 참된 '아직'이랑 그럴듯한 지어냄 사이에서, 기대받을 작정인 클라이언트는 매번 '아직'을 골라. 지어냄은 1초의 만족을 사고 관계 전체를 저당 잡혀.

클라이언트보다 오래 사는 원칙

이건 폰이랑 나쁜 신호만의 얘기가 아냐. '검증 못 하는 걸 지어내지 마라; 정직한 불확실성을 보이게 하라' 는, 시스템이 불완전한 정보 아래서 말하는 모든 데로 옮겨가는 설계 가치야 — 대시보드, 에이전트, 검색, 틈을 인정하는 대신 허세 부릴 수 있는 어떤 도구든. Pippa Go 는 그냥 그 원칙이 유난히 또렷한 곳일 뿐이야. 틈(신호 없음)이 아주 구체적이니까. 여기서 배우면, 훨씬 덜 뻔한 데서 같은 선택을 알아볼 거야: 정직한 답이 덜 만족스러워서 추측을 사실처럼 내놓고 싶은 조용한 유혹.

Code

거부를, 코드로·typescript

// 클라이언트는 답에 대해 딱 두 참된 위치 중 하나에만 있을 수 있어:
type AnswerState =
  | { kind: "waiting"; reason: "offline" | "pending" | "sending" } // 정직한 '아직'
  | { kind: "answered"; text: string; fromCanonical: true };       // 검증된 진짜 답

// 일부러 세 번째 변형이 없어:
//   { kind: "guess"; text: string }   <-- 설계상 존재하지 않음
// 'guess' 를 표현할 수 없으면, 어떤 코드 경로도 그걸 답으로 못 보여줘.

Exercise

허세 부리는 시스템을 삶에서 하나 찾아 — 추측이나 추정이나 오래된 값을 현재 사실인 양 내놓는 것(엉뚱한 지도 ETA, 실은 캐시된 '실시간' 숫자, 확신에 차서 지어내는 어시스턴트). 그 허세가 대가를 치르게 한 순간을 묘사해. 그다음 그 상호작용 하나를 불확실성이 보이게 다시 설계해. 정직한 버전이 거의 항상 더 믿을 만한 제품이라는 걸 알아채.

Hint

허세는 보통 정직함이 덜 다듬어져 보여서 골라 — 숫자 대신 범위, 답 대신 '아직 확실치 않음'. 근데 정직한 버전이 두 번 기댈 버전이야. 신뢰는 복리로 쌓이고, 허세는 보이지 않는 인출로 하나씩 갉아먹어.