기능 확장 통과 기준

추가 기능 확장 기준

검색, 인증, 댓글, 알림, 성능 개선 같은 기능을 붙일 때는 “있으면 좋다”에서 멈추면 안 된다. 각 기능이 어떤 데이터 모델과 라우트, 실패 상태, 권한 규칙, 배포 전 확인 기준을 요구하는지 내려와야 프로젝트가 흐트러지지 않는다.

01

사용자 흐름 정의

기능 이름이 아니라 사용자가 시작해서 완료하는 경로를 한 문장으로 적는다.

검색 추가보다 원하는 항목을 찾고 열 수 있어야 한다
02

데이터 모델 확인

새 필드, relation, index, cache key, revalidation 범위가 필요한지 확인한다.

UI만 붙이면 운영 데이터가 따라오지 않는다
03

라우트와 권한

Route Handler, Server Action, page route 중 어느 경계가 요청을 받아야 하는지 정한다.

비로그인, 권한 부족, 소유자 mismatch를 나눈다
04

실패 상태 작성

loading, empty, error, unauthorized, retry를 기능 화면에 포함한다.

성공 흐름만 있으면 기능이 아직 열리지 않았다
05

릴리스 기준

테스트, 성능 수치, 로그, 롤백 방법이 준비되었을 때 배포 후보로 둔다.

기능 추가는 운영 책임도 추가한다
인증
사용자 식별과 권한 세션, refresh, middleware 보호, 서버 측 권한 확인을 함께 설계한다.
클라이언트 가드는 보조 장치다
검색
색인과 빈 결과 쿼리 파라미터, debounce, cache, pagination, no result UI를 정한다.
URL 공유 가능성을 본다
댓글
쓰기와 낙관 업데이트 작성, 수정, 삭제, 신고, 권한, 중복 제출을 상태로 나눈다.
서버 실패 시 되돌림이 필요하다
성능
측정 가능한 개선 LCP, INP, bundle size, server timing 중 어떤 지표를 개선할지 고른다.
느낌보다 수치가 기준이다

릴리스 확인

제외 목록 이번 릴리스에 하지 않을 기능이 명시되어 범위가 커지지 않는지 확인한다.
실패 화면 기능별 오류와 빈 상태가 실제 화면으로 구현되어 있는지 본다.
측정값 기능 추가 전후 성능과 오류율을 비교할 지표가 있는지 확인한다.