1단계 — 요구사항을 상태와 증거로 바꾸기

“업로드가 된다”, “시드가 끝난다”는 문장은 너무 넓습니다. 무엇이 성공이고, 어느 순간 사용자가 기다려야 하며, 일부만 처리됐을 때 무엇을 다시 해야 하는지부터 써야 합니다.

상태 표부터 만든다

0건과 조회 실패는 같은 상태가 아닙니다. 목록 갱신이 실패했을 때 기존 데이터를 빈 배열로 덮으면 사용자는 삭제된 것으로 오해합니다. 이전 성공 데이터를 보존하고 오류·재시도 상태를 별도로 표시합니다. 반대로 mutation은 성공했지만 후속 목록 갱신만 실패했다면 “저장 실패”가 아니라 “저장됨·최신 목록 확인 실패”로 표현해야 중복 실행을 막을 수 있습니다.

다섯 관점의 증거

기획은 정상·예외 요구를, 디자인은 좁은 화면·키보드·포커스를, 개발은 API·DB 계약을, 사용자는 현재 상태와 재시도를, 운영은 health·로그·복구를 확인합니다. 아래 흐름에서 한 칸이 비면 완료가 아니라 검증 대기입니다.

요구사항 → 상태/오류 → API·DB → UI 피드백 → 자동 검사 → 배포 smoke

관리 콘솔의 콘텐츠 시드는 파일 오류를 조용히 성공으로 만들지 않고 409와 오류 목록을 반환해야 합니다. 화면은 role=status, 처리·실패 건수, 펼칠 수 있는 상세, 재실행 안내를 제공해야 합니다. 사용자는 “버튼을 눌렀다”가 아니라 “어디까지 반영됐는지”를 알아야 합니다.

직접 해 보기

새 기능 하나를 골라 위 표를 작성하고, 각 행마다 실제 테스트 명령 또는 로그 위치를 하나씩 적습니다. 성공만 검사하는 테스트는 부분 실패를 추가한 뒤 다시 설계합니다.

연결 읽기

• 검증 가능한 완료 조건
• 다음 단계