점검표

개요

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

답이 아니오인 항목이 많을수록, 문제는 enforcement 기술 부족보다 feedback design 부족일 가능성이 크다.

1. failure timing

• 위반은 가능한 가장 이른 지점에서 드러나는가
• 잘못된 상태가 멀리 전파되기 전에 막히는가
• silent fallback이나 silent ignore가 숨어 있지 않은가
• warning만 남기고 계속 진행하는 경계 위반이 없는가

2. failure specificity

• 무엇이 거부되었는지 분명한가
• 어떤 규칙이나 경계를 위반했는지 보이는가
• 현재 관측된 값이나 경로가 포함되는가
• 허용되는 대안이나 다음 수정 지점이 드러나는가

3. validator message shape

• stable rule identifier가 있는가
• 위치 정보가 충분히 정확한가
• 여러 위반이 한 문장에 뭉개지지 않는가
• 문서, lint, review가 같은 규칙 명칭을 쓰는가

4. runtime guard feedback

• misuse, invalid state, environment drift를 구분하는가
• generic exception으로 끝나지 않는가
• fallback 대신 명시적 실패를 택하는가
• 운영 로그와 집계에서 같은 failure code로 추적 가능한가

5. loop closure

• 반복 실패를 rule code 단위로 묶어 보는가
• 같은 실패가 나올 때 API나 harness 개선 후보로 올리는가
• docs, examples, tests가 함께 갱신되는가
• 리뷰에서 같은 설명을 계속 반복하고 있지 않은가

6. AI coding stress test

• AI가 이 메시지를 보고 수정 범위를 좁힐 수 있는가
• 허용되는 public API나 entry point가 명시되는가
• vague한 실패 때문에 더 넓은 우회가 유도되지 않는가
• 반복되는 AI 실패를 noise가 아니라 control gap 신호로 보고 있는가

요약

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

• 실패가 빠르고
• 실패 이유가 구체적이며
• 정상 경로 복귀가 보이고
• 반복 실패가 구조 개선으로 환류된다

이 항목들이 약하다면, 시스템은 규칙을 갖고 있어도 제대로 학습하지 못하고 있는 상태다.