실패와 피드백 설계

개요

하네스와 enforcement는 잘못된 경로를 막는다. 하지만 실패가 잘 설계되지 않으면, 시스템은 우회를 막으면서도 같은 우회를 반복해서 다시 생산한다.

이 섹션은 그 문제를 feedback design 관점에서 다룬다. 핵심 질문은 다음과 같다.

실패를 단순한 거절이 아니라, 정상 경로로 되돌리는 피드백으로 만들려면 무엇이 필요한가

architecture 섹션이 하네스를 붙일 수 있는 구조 조건을 다뤘고, api-design 섹션이 정상 경로를 가장 짧게 만드는 surface를 다뤘다면, 이 섹션은 그 위에서 실패를 어떻게 보여줄 것인가를 다룬다.

즉 여기서 보는 것은 에러 문구 작성법이 아니다.

를 함께 본다.

구조가 좋아도 피드백이 약하면 다음 문제가 생긴다.

특히 AI 코딩에서는 이 문제가 더 도드라진다. 실패 메시지가 vague하면 모델은 원인을 좁히지 못한 채 주변 코드에서 더 짧아 보이는 우회를 다시 조합한다.

그래서 feedback design은 부차적인 UX가 아니라, control strength의 일부다.

좋은 feedback design은 보통 다음 질문에 답한다.

늦고 모호한 실패가 왜 우회를 늘리는지, 그리고 좋은 실패가 어떤 속성을 가져야 하는지 본다.

validator 출력이 단순 로그가 아니라 고쳐야 할 행동을 가리키는 인터페이스가 되려면 어떤 정보가 필요한지 본다.

runtime enforcement가 단순 exception spam이 아니라 정상 경로 복귀를 돕는 최종 방어선이 되려면 무엇이 필요한지 본다.

반복되는 실패를 어떻게 분류하고, 어떻게 rule, doc, API, harness, enforcement 개선으로 돌려야 하는지 본다.

현재 시스템의 failure feedback 품질을 빠르게 점검하기 위한 체크리스트다.

이 순서는 실패를 드러내는 시점에서 시작해, 메시지 구조를 정리하고, 최종 방어선의 출력 방식을 보고, 마지막에 조직적 환류까지 닫는 흐름이다.

좋은 feedback design은 다음을 만족한다.

즉 이 섹션이 다루는 것은 문구 작성이 아니라, 실패를 구조 학습으로 바꾸는 설계다.