완료 조건을 검증 가능한 증거로 바꾸기

"기능이 끝났다"는 느낌이 아니라 다른 사람이 다시 확인할 수 있는 증거로 정의합니다. 이 기준은 기획자·디자이너·개발자·사용자·운영자가 같은 완료를 바라보게 합니다.

1. 다섯 관점의 인수 기준

관점	확인할 질문	증거 예시
기획	요구한 상태와 예외가 모두 정의됐나?	상태 전이표, 허용·거부 케이스
디자인	키보드·모바일·오류 상태가 설계됐나?	포커스 순서, 빈 상태, 실패 문구
개발	API·DB·캐시의 계약이 일치하나?	타입 검사, 단위 테스트, SQL 제약
사용자	성공·진행 중·실패를 이해할 수 있나?	`role=status`, 재시도 안내, smoke
운영	배포·복구·관측이 가능한가?	health/readiness, 로그, rollback 기록

2. Codingstairs/Admin에 적용하기

Codingstairs 콘텐츠는 한국어·영어 파일 쌍을 루트 notes/·courses/에 둡니다. Admin 시드가 파일 하나라도 실패하면 HTTP 409와 오류 목록을 남기고, 화면은 처리 건수와 재시도 이유를 보여줘야 합니다. 성공 응답만 확인해서는 완료가 아닙니다.

공개 경로에서는 다음을 확인합니다.

강좌의 단계가 1부터 연속이고 두 언어의 slug가 대응한다.
발행 목록·카테고리·키워드 조회가 language와 content_kind를 함께 적용한다.
잘못된 lesson step을 Admin API와 DB CHECK가 모두 거부한다.
모바일 화면에서 오류 상세를 펼칠 수 있고 키보드만으로 실행할 수 있다.

3. 검증 매트릭스

요구사항 → 상태/오류 정의 → API·DB 계약 → UI 피드백 → 자동 테스트 → 배포 smoke

한 칸이라도 비어 있으면 “구현 완료”가 아니라 “검증 대기”입니다. 각 칸에 명령이나 로그 위치를 남기면 다음 사람이 같은 결과를 재현할 수 있습니다.

4. 작은 게이트부터

모든 화면을 한 번에 E2E로 만들지 않습니다. 먼저 콘텐츠 인벤토리·타입 검사·Admin 시드 오류·Compose health 계약처럼 빠르고 결정적인 검사를 PR 게이트로 둡니다. 실제 브라우저와 복구 리허설은 별도 환경에서 실행하고 결과를 증거로 보관합니다.

체크리스트

성공뿐 아니라 부분 실패의 응답과 UI를 확인했다.
키보드·좁은 화면·빈 데이터·오류 상태를 확인했다.
API 입력 검증과 DB 제약이 같은 범위를 막는다.
명령, 결과, 실행 환경을 기록했다.

08-partial-failure-recovery
/notes/data/16-idempotent-migration-recovery