“무엇을 만들까”보다 “무엇이 달라져야 하나”
Outcome, evidence, invariant, non-goal과 acceptance
AI는 빈칸을 빠르게 채우기 때문에 모호한 요청도 그럴듯한 구현으로 바꿉니다. 문제는 코드가 아니라 잘못 채운 가정입니다. 사용자의 관찰 가능한 변화, 현재 증거, 깨지면 안 되는 불변식, 이번에 하지 않을 범위, 완료를 판정할 증거를 먼저 작성해야 합니다.
| 계약 요소 | 질문 | 나쁜 대체물 |
|---|---|---|
| Outcome | 누구의 어떤 행동·결과가 달라지는가? | 기능 목록 |
| Evidence | 현재 문제가 실제라는 증거는? | 추측·관례 |
| Invariant | 어떤 상태·권한·데이터는 보존해야 하나? | 암묵적 기대 |
| Acceptance | 어떤 관측으로 완료를 판정하나? | “잘 작동함” |
- 사용자 장면행위자·상황·현재 마찰·원하는 결과를 한 문단으로 씁니다.
- 증거 연결로그·사용 데이터·재현·정책 중 문제를 뒷받침하는 근거를 붙입니다.
- 경계 고정불변식·비대상·권한·시간·호환성 제약을 분리합니다.
- 판정 설계테스트·화면·지표·운영 증거로 acceptance를 만듭니다.