왜 거짓말 거부가 기능인가

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

아무도 기능 목록에 안 적는 기능

기능 목록엔 제품이 하는 것만 잔뜩 적혀 있잖아. 근데 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

일상에서 허세 부리는 시스템을 하나 찾아 봐. 추측이나 추정이나 한참 된 값을 지금 사실인 양 내놓는 것들. 엉뚱한 지도 도착 예정 시각, 알고 보면 캐시된 '실시간' 숫자, 자신만만하게 지어내는 어시스턴트. 그 허세 때문에 대가를 치른 순간을 적어. 그다음 그 상호작용 하나를 모르는 걸 드러내는 쪽으로 다시 설계해 봐. 정직한 쪽이 거의 항상 더 믿을 만한 제품이라는 게 보일 거야.

Hint

허세를 고르는 이유는 대개 정직한 쪽이 덜 다듬어져 보여서야. 딱 떨어지는 숫자 대신 범위, 답 대신 '아직 확실치 않음'. 근데 두 번째로도 기대게 되는 건 정직한 쪽이야. 신뢰는 복리로 쌓이고, 허세는 눈에 안 보이는 인출로 그걸 하나씩 갉아먹어.