없는 목소리는 loud-fail 해

"없는 binding은 명시적 unavailable 에러야. Bellows는 편한 엉뚱한 목소리로 절대 안 때워."

도구가 잘못되는 갈림길

profile을 요청했는데 활성 계정에 그 binding이 없어. 두 길이 열려. 편한 길은 가장 가까운 목소리를 찾거나 다른 계정으로 조용히 손 뻗어서, 요청이 성공하게 뭔가를 돌려주는 거야. 정직한 길은 멈춰서 뭐가 unavailable인지 정확히 말하는 거고. Bellows는 늘 정직한 길을 택해. 없는 계정 binding은 명시적 unavailable 에러야. 조용한 대체도, 조용한 계정 간 fallback도 절대 없어.

왜 틀렸는데 성공이 최악이냐면

요란한 실패는 짜증나. 조용한 오답은 위험하고. 엔진이 '친절하게' 대체를 골라서 사적인 메시지가 엉뚱한 목소리로 나가면, 아무것도 아무한테도 경고 안 했는데 실수는 이미 방 안에 있어. 요청을 배신하는 성공은 깔끔한 에러보다 나빠. 숨어버리거든. 고른 계정이 정확한 logical binding을 쥐고 있어야 해. 아니면 요청은 이름을 대면서 멈춰.

사고가 아니라 설계로서의 fallback

이건 fallback을 미워하는 게 아니야. fallback이 의도적이어야 한다는 고집이지. 패밀리 다른 데엔 진짜 설계된 fallback 경로가 있어. 네이티브 비전에 텍스트 경로, OAuth에 API-키 보험. 그것들은 골라졌고, 테스트됐고, 전환 지점에서 눈에 보여. Bellows가 거부하는 건 사고성 fallback이야. 특정 약속('pippa로 말해')을 조용히 더 흐릿한 것('아무 목소리로든 말해')으로 낮추는 것. hard-fail이 기본이고, 어떤 완화도 편의가 아니라 의도적 예외야.

Code

이름을 대고 멈춰, 절대 딴 걸로 때우지 말고·python

def resolve_binding(profile: str, account: Account) -> VoiceBinding:
    binding = account.bindings.get(profile)
    if binding is None or not binding.verified:
        # LOUD: an explicit, NAMED unavailable. Not a fallback, not a guess.
        raise VoiceUnavailable(profile=profile, account=account.name)
    return binding

# What Bellows NEVER does here:
#   return account.bindings.nearest(profile)     # convenient wrong voice
#   return other_account.bindings.get(profile)   # silent cross-account swap
#
# Both 'succeed'. Both betray the request. A named error is the safe outcome.

Exercise

네가 쓰는 소프트웨어에서 진짜 입력이 없을 때 틀렸는데 성공한 결과를 돌려주는 '친절한 fallback'을 찾아. 기본 통화, 최근접 주소, fallback 언어. 요란한 실패가 더 안전했을 구체적 경우를 그려봐. 그다음 판단해. 그 fallback은 의도적이고 눈에 보이나, 아니면 사고성이고 조용하나?

Hint

fallback이 발동하는 순간에 알려주는지 물어봐. 눈에 보이고 미리 경고받은 fallback은 설계야. 피해가 난 뒤에야 발견하는 fallback은 버그고.