이전 페이지에서는 로그, 모니터링, 운영 점검표를 정리했습니다. 이번 페이지에서는 배포 전에 반드시 확인해야 할 품질 회귀 범위와 릴리스 체크리스트를 닫습니다. 여기서 중요한 것은 "테스트를 많이 했다"가 아니라, 어떤 위험을 확인했고 어떤 상태라면 배포를 멈출지 명확히 정하는 것입니다.
실전 프로젝트에서는 작은 수정도 예상하지 못한 흐름을 깨뜨릴 수 있습니다. 상품 목록을 바꾸다가 장바구니가 깨질 수 있고, admin 권한 처리를 바꾸다가 챗봇 주문 조회가 막힐 수 있습니다. 그래서 릴리스 전에는 기능별 완료 여부가 아니라 제품 전체의 회귀 위험을 기준으로 점검해야 합니다.
즉 이번 페이지는 "이제 배포해도 되는가"를 감으로 판단하지 않고, 실행 가능한 기준으로 판단하기 위한 마지막 품질 문턱입니다.
회귀 테스트는 모든 것을 다시 확인하는 일이 아닙니다. 변경이 영향을 줄 수 있는 흐름을 의도적으로 다시 확인하는 일입니다.
예를 들어 인증 코드를 바꾸었다면 로그인 화면만 보면 부족합니다.
- 장바구니 조회가 여전히 buyer 세션을 인식하는가
- 주문 생성이 현재 사용자를 정확히 읽는가
- admin 보호 라우트가 여전히 막히는가
- 챗봇이 주문 상태 조회 권한을 정확히 확인하는가
이처럼 회귀 범위는 변경 지점이 아니라 영향 지점까지 포함해야 합니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
- 어떤 변경이 어떤 회귀 범위를 가져야 하는가
- 릴리스 전 반드시 실행할 체크리스트는 무엇인가
- 어떤 실패가 있으면 배포를 보류해야 하는가
- 어떤 실패는 알려진 위험으로 남길 수 있는가
- 릴리스 결과는 어디에 기록해야 하는가
- 배포 후 문제가 생기면 어떤 기준으로 롤백할 것인가
이번 프로젝트의 회귀 범위는 크게 다섯 묶음으로 나눕니다.
- 구매자 핵심 흐름
- 관리자 운영 흐름
- AI 상담 챗봇 흐름
- 보안과 권한 흐름
- 인프라와 배포 흐름
각 묶음은 서로 독립적이지 않습니다. 주문 생성은 구매자 흐름이면서 admin 주문 확인과 챗봇 주문 상태 안내에도 영향을 줍니다.
구매자 흐름에서는 아래를 반드시 확인합니다.
- 상품 목록이 열린다
- 상품 상세가 열린다
- 회원가입 또는 로그인이 된다
- 장바구니에 상품을 담을 수 있다
- 수량 변경과 합계가 맞다
- 주문을 생성할 수 있다
- 결제 성공 후 주문 완료 화면이 보인다
- 결제 실패 시 재시도 또는 안내가 보인다
이 흐름은 이커머스 서비스의 중심입니다. 여기서 하나라도 깨지면 릴리스를 보류하는 편이 맞습니다.
관리자 흐름에서는 아래를 확인합니다.
- admin 로그인만 admin에 접근할 수 있다
- buyer는 admin 화면과 API에 접근할 수 없다
- 주문 목록이 보인다
- 주문 상세에서 항목, 금액, 상태를 확인할 수 있다
- 상품 목록과 상세가 보인다
- 상품 수정이 의도한 필드에만 반영된다
- 상품 상태 변경이 storefront에 반영된다
관리자 기능은 구매자에게 직접 보이지 않아도 운영 장애로 이어질 수 있으므로 회귀 범위에 반드시 포함합니다.
챗봇 흐름에서는 아래를 확인합니다.
- 상품 화면에서 상품 맥락이 전달된다
- 주문 화면에서 주문 맥락이 전달된다
- 비회원의 주문 상태 질문은 로그인 필요로 안내된다
- 다른 사용자의 주문은 설명하지 않는다
- RAG 근거가 없는 질문은 handoff 또는 제한 응답으로 처리된다
- LLM 실패 시 재시도 또는 운영자 연결이 보인다
- 민감 정보가 프롬프트와 로그에 그대로 남지 않는다
챗봇은 답변 문장이 매번 조금씩 달라질 수 있으므로 문장 전체보다 상태, 권한, 구조화 응답, handoff 여부를 중심으로 검증합니다.
보안과 권한은 릴리스 전 반드시 확인해야 합니다.
우선순위가 높은 항목은 아래입니다.
- 다른 사용자의 주문 조회 차단
- buyer의 admin API 접근 차단
- 주문 금액 서버 재계산
- 판매 중지 또는 품절 상품 주문 차단
- 결제 성공 상태 위조 차단
- 토큰과 비밀번호 로그 제외
- 챗봇 프롬프트 민감 정보 제외
이 항목은 실패하면 단순 버그가 아니라 릴리스 차단 사유가 됩니다.
배포 전후에는 실행 환경도 확인합니다.
- 서버 health check가 통과한다
- storefront 빌드가 성공한다
- admin 빌드가 성공한다
- DB 연결이 정상이다
- seed 또는 migration 상태가 맞다
- 환경 변수가 누락되지 않았다
- 로그가 수집된다
- 최근 배포 커밋이 live에 반영됐다
코드는 맞는데 환경 설정이 틀리면 운영에서는 실패합니다. 따라서 인프라 확인도 릴리스 체크리스트에 포함합니다.
릴리스 전에는 아래 항목을 순서대로 확인합니다.
- 변경 범위를 확인한다
- 영향받는 회귀 범위를 선택한다
- 백엔드 테스트를 실행한다
- storefront 빌드를 실행한다
- admin 빌드를 실행한다
- 핵심 E2E 또는 smoke test를 실행한다
- 권한 실패 테스트를 확인한다
- 민감 정보 로그 노출 여부를 확인한다
- 운영 점검표를 확인한다
- 릴리스 노트 또는 검증 결과를 기록한다
체크리스트는 실제로 실행할 수 있어야 합니다. 너무 길어서 아무도 실행하지 않는 체크리스트는 품질 장치가 아닙니다.
아래 항목 중 하나라도 실패하면 배포를 보류합니다.
- 구매 성공 흐름 실패
- 주문 생성 또는 결제 확인 실패
- 다른 사용자 주문 접근 가능
- buyer가 admin API 접근 가능
- 주문 금액 조작 가능
- admin 주문 확인 불가
- 민감 정보가 로그나 프롬프트에 노출
- health check 실패
- DB migration 또는 seed 상태 불일치
보류 기준은 엄격해야 합니다. 특히 돈, 개인정보, 권한, 주문 상태와 관련된 실패는 "나중에 고치자"로 넘기면 안 됩니다.
모든 결함이 릴리스 차단 사유는 아닙니다. 아래는 상황에 따라 알려진 위험으로 남길 수 있습니다.
- 비핵심 화면의 문구 어색함
- 낮은 빈도의 UI alignment 문제
- 운영자 편의 기능의 후속 개선
- 챗봇 추천 질문 문구 개선
- 성능 기준에는 들어오지만 더 최적화할 수 있는 목록 조회
단, 알려진 위험으로 남기려면 영향, 우회 방법, 후속 작업이 기록되어야 합니다.
릴리스 기록은 나중에 장애가 발생했을 때 원인을 좁히는 데 필요합니다.
최소한 아래를 남깁니다.
- 릴리스 커밋
- 변경 요약
- 실행한 테스트
- 통과한 E2E 시나리오
- 확인한 권한 시나리오
- 알려진 위험
- 배포 시각
- 배포 후 관찰 결과
기록은 길 필요가 없습니다. 다만 나중에 같은 릴리스를 설명할 수 있어야 합니다.
배포 후에는 다시 한 번 최소 흐름을 확인합니다.
- live storefront 접속
- 상품 목록 조회
- 로그인
- 장바구니 추가
- 주문 생성 또는 smoke 주문
- admin 주문 목록 확인
- 챗봇 기본 질문 확인
- 5xx 오류율 확인
- p95 응답 시간 확인
로컬에서 통과한 테스트가 운영 환경에서도 같은 의미를 갖는지 확인하는 단계입니다.
배포 후 아래 상황이 발생하면 롤백을 고려합니다.
- 주문 생성이 다수 실패한다
- 결제 성공 처리가 실패한다
- 권한 우회가 발견된다
- admin이 운영 데이터를 볼 수 없다
- DB schema 불일치로 핵심 API가 실패한다
- 오류율이 기준 이상으로 올라간다
롤백 기준은 배포 전에 정해져 있어야 합니다. 장애가 난 뒤에 논의하면 판단이 늦어집니다.
체크리스트는 문서로만 남기지 말고 가능한 항목은 자동화합니다.
자동화 후보는 아래입니다.
- backend test
- frontend build
- lint 또는 typecheck
- smoke test
- 권한 실패 API test
- E2E seed/reset
수동으로 남길 항목은 사람이 판단해야 하는 UX, 운영 문구, 챗봇 답변 품질, live 관찰 결과입니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
- 회귀 범위가 기능별로 정리되어 있다
- 릴리스 전 체크리스트가 있다
- 배포 보류 기준이 명확하다
- 알려진 위험 기록 기준이 있다
- 배포 후 검증 항목이 있다
- 롤백 기준이 있다
- 자동화할 항목과 수동 점검 항목이 구분되어 있다
즉 이제 배포 여부를 감이 아니라 체크리스트와 검증 결과로 판단할 수 있어야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
- 회귀 테스트 매트릭스
- 릴리스 체크리스트
- 배포 보류 기준 문서
- 알려진 위험 기록 양식
- 배포 후 smoke test 절차
- 롤백 판단 기준
- CI에서 실행되는 최소 품질 gate
- 수동 운영 점검표
이 산출물이 있어야 다음 장에서 실제 배포, 운영, 확장을 다룰 준비가 됩니다.
- 변경한 화면만 보고 릴리스한다
- 권한 실패 테스트를 릴리스 전 체크에서 제외한다
- 챗봇 답변 품질을 문장 일치로만 검증한다
- 알려진 위험을 기록하지 않고 기억에 의존한다
- 배포 후 live smoke test를 생략한다
- 롤백 기준 없이 배포한다
- CI 통과를 제품 검증 완료와 같은 의미로 착각한다
이 일곱 가지 실수는 작은 릴리스를 큰 장애로 만들 수 있습니다.
이번 페이지에서는 품질 회귀 범위와 릴리스 체크리스트를 정리했습니다. 핵심은 모든 테스트를 다 돌리는 것이 아니라, 이번 변경이 영향을 줄 수 있는 구매자, 관리자, 챗봇, 권한, 인프라 흐름을 선택하고 배포 보류 기준에 따라 판단하는 것입니다.
다음 단계에서는 실제 배포와 운영과 확장까지 정리합니다.