fallback을 지우자 버그가 말하기 시작했다

빈 값이 조용히 0으로 바뀌고 있었습니다.

처음엔 친절한 코드라고 생각했습니다.
데이터가 없으면 화면이 깨지지 않게 기본값을 넣어주는 코드.
사용자는 빨간 에러 대신 숫자를 봅니다.
제품은 덜 불안해 보입니다.

근데 그 0이 너무 잘생겨서 문제였습니다.

누가 봐도 정상 값처럼 보였습니다.

에러가 안 보이면 버그도 안 보였습니다

처음엔 fallback이 안전장치라고 믿었습니다.

value ??
0
items ??
[]
label ??
"기본"

작은 UI에서는 유용합니다.
로딩 중에 빈 배열을 보여주거나, 선택 값이 없을 때 placeholder를 두는 건 괜찮습니다.
문제는 그 값이 “데이터 계약”을 대신할 때입니다.

어떤 화면에서 숫자가 0으로 나왔습니다.
사용자는 변화가 없다고 읽었습니다.
개발자는 에러가 없으니 정상이라고 봤습니다.
하지만 실제 의미는 달랐습니다.

데이터가 아직 없었습니다.

0이 아니라 “모름”이었습니다.

그 차이를 fallback이 숨겼습니다.

fallback을 지우면 처음엔 시끄러워집니다

fallback을 제거하자 화면이 조용해지지 않았습니다.
반대로 더 시끄러워졌습니다.

null이 올라오고, API 계약이 깨지고, 오래된 호출자가 드러났습니다.
처음엔 이게 퇴보처럼 느껴졌습니다.
예전엔 멀쩡히 보이던 화면이 이제는 자꾸 멈췄으니까요.

근데 그 멈춤이 진짜 신호였습니다.

이전에는 문제가 없었던 게 아니라, 문제가 값으로 위장하고 있었습니다.
fallback을 지우자 버그가 말을 하기 시작했습니다.

제가 지금 구분하는 기준은 이렇습니다.

상황	fallback 가능	fail loud
로딩 중 UI placeholder	예	아니오
선택 안 한 필터의 기본 표시	예	아니오
서버가 반드시 줘야 하는 계약 필드	아니오	예
통계/정산/권한/라우팅 값	아니오	예

핵심은 “없어도 괜찮은 값”과 “없으면 시스템이 거짓말하는 값”을 나누는 겁니다.

fallback-ok를 적어야 마음이 편했습니다

한동안은 fallback을 전부 의심했습니다.
그것도 지나쳤습니다.

모든 기본값이 나쁜 건 아닙니다.
빈 검색 결과는 []가 자연스럽고, 아직 이미지가 없으면 회색 박스가 더 낫습니다.
그래서 지금은 fallback을 허용할 때 이유를 붙입니다.

fallback-ok: loading placeholder only
fallback-ok: optional display label
fallback-ok: local-only preview

이렇게 적으면 나중에 코드를 읽는 사람이 압니다.
이 기본값은 도메인 진실을 대신하는 값이 아니라, UI 상태를 표현하는 값이라는 걸요.

반대로 이유를 못 적으면 fallback을 넣지 않습니다.

에러는 사용자에게 다 보여주지 않아도 됩니다

여기서 오해하면 안 되는 부분이 있습니다.

fail loud는 사용자에게 스택트레이스를 보여주자는 뜻이 아닙니다.
내부적으로는 크게 실패하고, 사용자에게는 안전하게 설명하자는 뜻입니다.

예를 들어 결제 금액, 권한, 통계 값, 라우팅 대상이 없는데 기본값으로 넘기면 안 됩니다.
시스템은 로그를 남기고, 요청을 거부하고, 개발자가 알 수 있게 해야 합니다.
사용자는 “잠시 후 다시 시도해 주세요”를 볼 수 있습니다.

중요한 건 시스템 내부에서 거짓 정상으로 취급하지 않는 겁니다.

그날 이후 저는 ?? 0을 보면 바로 지우지 않습니다.
대신 물어봅니다.

이 0은 진짜 0인가요.

아니면 조용히 입을 막은 버그인가요.