실패와 피드백 설계
개요
하네스와 enforcement는 잘못된 경로를 막는다. 하지만 실패가 잘 설계되지 않으면, 시스템은 우회를 막으면서도 같은 우회를 반복해서 다시 생산한다.
이 섹션은 그 문제를 feedback design 관점에서 다룬다.
핵심 질문은 다음과 같다.
실패를 단순한 거절이 아니라, 정상 경로로 되돌리는 피드백으로 만들려면 무엇이 필요한가 핵심 질문
이 섹션의 위치
architecture 섹션이 하네스를 붙일 수 있는 구조 조건을 다뤘고,
api-design 섹션이 정상 경로를 가장 짧게 만드는 surface를 다뤘다면,
이 섹션은 그 위에서 실패를 어떻게 보여줄 것인가를 다룬다.
즉 여기서 보는 것은 에러 문구 작성법이 아니다.
- 실패를 언제 드러낼 것인가
- 어떤 정보까지 같이 보여줄 것인가
- 그 실패가 어떻게 다음 수정 행동으로 이어질 것인가
- 반복되는 실패를 어떻게 rule과 harness 개선으로 환류시킬 것인가
를 함께 본다.
왜 feedback design이 중요한가
구조가 좋아도 피드백이 약하면 다음 문제가 생긴다.
- 사람은 규칙을 이해하지 못하고 임시 우회를 만든다
- 리뷰어는 같은 설명을 계속 반복한다
- 테스트 실패가 잡음처럼 보인다
- validator 출력이 행동으로 이어지지 않는다
- AI는 모호한 에러를 보고 같은 시도를 더 빠르게 반복한다
특히 AI 코딩에서는 이 문제가 더 도드라진다. 실패 메시지가 vague하면 모델은 원인을 좁히지 못한 채 주변 코드에서 더 짧아 보이는 우회를 다시 조합한다.
그래서 feedback design은 부차적인 UX가 아니라, control strength의 일부다.
이 섹션의 핵심 질문
좋은 feedback design은 보통 다음 질문에 답한다.
- 실패는 가능한 한 빨리 드러나는가
- 무엇이 잘못됐는지 충분히 구체적인가
- 정상 경로로 돌아가려면 무엇을 해야 하는지 보이는가
- validator와 runtime guard의 메시지가 서로 충돌하지 않는가
- 반복되는 실패가 rule, API, harness 개선으로 돌아오는가
이 섹션의 구성
fail-fast-and-specific 빠르고 구체적인 실패
늦고 모호한 실패가 왜 우회를 늘리는지, 그리고 좋은 실패가 어떤 속성을 가져야 하는지 본다.
validator-message-shape 메시지 형태
validator 출력이 단순 로그가 아니라 고쳐야 할 행동을 가리키는 인터페이스가 되려면 어떤 정보가 필요한지 본다.
runtime-guard-feedback 런타임 가드 피드백
runtime enforcement가 단순 exception spam이 아니라 정상 경로 복귀를 돕는 최종 방어선이 되려면 무엇이 필요한지 본다.
feedback-loop-closure 루프 폐쇄
반복되는 실패를 어떻게 분류하고, 어떻게 rule, doc, API, harness, enforcement 개선으로 돌려야 하는지 본다.
checklist 점검표
현재 시스템의 failure feedback 품질을 빠르게 점검하기 위한 체크리스트다.
읽는 순서
- fail-fast-and-specific
- validator-message-shape
- runtime-guard-feedback
- feedback-loop-closure
- checklist
이 순서는 실패를 드러내는 시점에서 시작해, 메시지 구조를 정리하고, 최종 방어선의 출력 방식을 보고, 마지막에 조직적 환류까지 닫는 흐름이다.
요약
좋은 feedback design은 다음을 만족한다.
- 실패를 늦추지 않고
- 실패 이유를 구체적으로 드러내며
- 정상 경로를 다시 가리키고
- 반복되는 실패를 구조 개선으로 환류시킨다
즉 이 섹션이 다루는 것은 문구 작성이 아니라, 실패를 구조 학습으로 바꾸는 설계다.