빠르고 구체적인 실패
개요
구조를 지키는 시스템은 실패를 없애지 않는다.
대신 실패를 빠르게, 국소적으로, 구체적으로 드러낸다.
반대로 실패가 늦고 모호하면, 사람도 AI도 원인을 좁히지 못한 채 더 큰 수정이나 더 위험한 우회로 이동한다.
왜 늦은 실패가 문제인가
늦은 실패는 대개 다음 비용을 만든다.
- 잘못된 상태가 이미 멀리 전파된다
- 어떤 단계에서 경계를 넘었는지 추적이 어려워진다
- 실패 원인보다 증상만 보인다
- 호출자는 더 많은 컨텍스트를 뒤늦게 수집해야 한다
- 문제를 고치는 대신 fallback을 추가하고 싶어진다
이 시점의 실패는 교정 신호라기보다 정리 비용이 큰 사고 보고서에 가깝다.
좋은 실패의 세 가지 속성
빠르다
잘못된 경로에 들어간 직후 드러나야 한다. entry point, validation 단계, transition 전후가 대표적이다.
국소적이다
문제가 발생한 경계 근처에서 실패해야 한다. 가장 바깥 호출자에서 뒤늦게 generic error로 뭉개지면 실패는 구조 학습에 도움이 되지 않는다.
구체적이다
무엇이 잘못됐는지, 무엇이 허용되는지, 어디로 돌아가야 하는지가 보여야 한다.
모호한 실패가 만드는 행동
모호한 실패는 보통 다음 행동을 유도한다.
일단 null 처리하자이번 케이스만 bypass 하자helper를 하나 더 만들자테스트에서만 direct path를 열자AI가 제안한 다른 우회 코드를 한번 붙여보자
즉 나쁜 실패는 잘못된 코드만 막는 것이 아니라, 다음 잘못된 구조를 생산하는 원인이 된다.
좋은 실패가 포함해야 할 정보
최소한 다음 정보는 필요하다.
- 무엇이 거부되었는가
- 어떤 규칙이나 경계를 위반했는가
- 현재 관측된 값이나 경로는 무엇인가
- 허용되는 대안은 무엇인가
- 다음 수정 지점은 어디인가
여기서 중요한 것은 장황함이 아니라
다음 행동을 좁히는 정보다.
fail-fast가 조용한 거절이 되어서는 안 된다
빨리 실패하는 것과 조용히 버리는 것은 다르다.
예를 들어 다음은 모두 나쁜 형태다.
- 금지된 입력을 silently ignore 한다
- fallback default로 자동 전환한다
- invalid state를 warning만 남기고 진행한다
- validator가 실패를 기록하지만 build는 통과시킨다
이런 패턴은 당장의 마찰을 줄이는 대신, 구조 붕괴를 더 깊게 묻어버린다.
AI 코딩에서 왜 더 중요해지는가
AI는 실패를 사람보다 더 빠르게 반복한다. 그래서 에러가 vague하면 더 빠른 trial-and-error만 늘어난다.
- 이유가 모호하면 주변 코드의 shortcut을 참고한다
- 실패 위치가 흐리면 수정 범위를 과도하게 넓힌다
- 허용 경로가 안 보이면 비슷해 보이는 다른 entry point를 고른다
즉 AI 시대에는 fail-fast만으로 충분하지 않고, fail-fast-and-specific이 되어야 한다.
실무 질문
- 이 실패는 가능한 가장 이른 지점에서 발생하는가
- 이 메시지만 보고도 수정 범위를 좁힐 수 있는가
- 문제가 경계 위반인지 입력 오류인지 상태 오류인지 구분되는가
- 조용한 fallback이나 silent ignore가 숨어 있지 않은가
- 같은 실패가 반복될 때 우회가 아니라 개선으로 이어지는가
요약
좋은 failure feedback은 다음을 만족한다.
- 늦지 않고
- 멀리 퍼지지 않으며
- 다음 행동이 보이도록 충분히 구체적이다
통제 가능한 시스템은 실패를 줄이는 시스템이 아니라, 실패를 빨리 드러내고 올바른 수정으로 연결하는 시스템이다.