왜 “눈으로 보는 검수”만으로는 부족한가

발주사 담당자는 대부분 디자이너나 마케터 시선으로 화면을 확인합니다. 색상, 문구, 배치는 꼼꼼히 보지만 다음은 놓치기 쉽습니다.

• 폼을 제출했을 때 데이터가 실제로 어디로 저장되는지
• 필수값을 비우고 제출하면 어떤 반응이 나오는지
• 같은 작업을 여러 브라우저·기기에서 반복해도 동일하게 동작하는지
• 관리자 화면에서 실제로 그 데이터를 조회·수정할 수 있는지

화면이 예쁘게 뜨는 것과, 그 화면이 정상적으로 “일”을 하는 것은 다른 문제입니다. 아래 체크리스트는 프론트엔드(화면)와 백엔드(처리·저장)를 나눠서 확인하는 방식입니다.

프론트엔드 QA — 화면과 사용자 경험

특히 폼 유효성 검증은 실제 사용자가 가장 자주 겪는 오류입니다. 필수값을 비운 채 제출 버튼을 눌러보는 것만으로도 절반 이상의 프론트엔드 결함을 찾을 수 있습니다.

백엔드 QA — 데이터와 처리 로직

백엔드 결함은 오픈 초반에는 드러나지 않다가, 트래픽이 몰리거나 데이터가 쌓이는 시점에 갑자기 터지는 경우가 많습니다. 상세 절차는 주차별 스코프 검수 노하우에서 함께 다룹니다.

연동 기능은 별도 시나리오로 테스트해야 한다

결제, 문자·알림, 지도, 외부 API 연동은 화면 하나로 끝나지 않고 여러 시스템을 거치기 때문에 아래처럼 시나리오 기반으로 확인해야 합니다.

1. 정상 시나리오 — 결제 성공, 알림 정상 수신까지 전체 흐름 확인
2. 취소·실패 시나리오 — 결제 취소, 결제 실패 시 주문 상태가 올바르게 반영되는지
3. 중단 시나리오 — 결제 진행 중 사용자가 창을 닫았을 때 데이터가 남는지
4. 재시도 시나리오 — 알림 발송이 실패했을 때 재발송되는지, 로그가 남는지

“결제가 됐다”는 사실 하나만으로는 부족합니다. 취소·실패·중단까지 확인해야 실제 운영 중 발생하는 문의를 줄일 수 있습니다. PG 연동은 PG 연동 및 보안 테스트 절차를 함께 참고하세요.

오픈 직전 최종 점검 순서

실제 오픈 하루 전에는 다음 순서로 점검하는 것을 권장합니다.

1. 대표 시나리오 3~5개(회원가입, 문의, 구매 등)를 처음부터 끝까지 실행
2. 모바일 기기 실물로 동일 시나리오 재확인(에뮬레이터만으로는 부족)
3. 관리자 계정으로 로그인해 실제 데이터가 조회·수정되는지 확인
4. 검색엔진 수집 관련 설정(robots.txt, sitemap.xml) 확인
5. SSL 인증서, 도메인 연결 상태 재확인
6. 오류 발생 시 담당자에게 알림이 가는 구조인지 확인

이 여섯 가지를 빠짐없이 확인하면 오픈 첫날 발생하는 민원의 대부분을 사전에 걸러낼 수 있습니다.

검수 결과를 문서로 남기는 이유

QA는 구두로 “확인했습니다”라고 끝내면 나중에 근거가 남지 않습니다. 아래처럼 표 형태로 결과를 남기는 것이 좋습니다.

이 표는 잔금 지급 시점의 근거 자료가 되기도 하고, 이후 유지보수 담당자가 바뀌었을 때 “어떤 기준으로 검수됐는지”를 확인하는 참고 자료로도 쓰입니다.

자체 QA가 어렵다면 이렇게 요청하세요

발주사 내부에 QA 전담자가 없는 경우가 대부분입니다. 이럴 때는 개발사에 아래를 명시적으로 요청하는 것이 현실적입니다.

• 기능별 테스트 케이스 문서를 검수 시작 전에 먼저 공유받기
• 개발사의 1차 자체 QA 결과(캡처 포함)를 먼저 전달받기
• 발주사는 그 문서를 기준으로 “되는지 안 되는지”만 표시하는 방식으로 검수 부담 줄이기

QA 역량이 부족한 발주사일수록 오히려 이런 절차를 문서로 요구하는 것이 중요합니다. 절차가 없으면 “확인은 했는데 뭘 확인했는지 기억이 안 나는” 상황이 반복됩니다.