목록으로
9분 읽기

웹개발 검수는 무엇을 기준으로 완료해야 할까?

웹사이트나 웹서비스 개발이 끝나면 의뢰사는 결과물을 확인하고 최종 승인하는 검수 과정을 진행합니다.

  • #웹개발 검수
  • #개발 완료 기준
  • #QA 테스트
  • #외주 개발 검수
  • #웹서비스 테스트

웹사이트나 웹서비스 개발이 끝나면 의뢰사는 결과물을 확인하고 최종 승인하는 검수 과정을 진행합니다.

하지만 검수 기준이 정해져 있지 않으면 다음과 같은 문제가 생길 수 있습니다.

  • 의뢰사는 아직 미완성이라고 생각함
  • 개발 업체는 계약 기능이 모두 완료됐다고 판단함
  • 디자인 취향과 기능 오류가 섞임
  • 새로운 요구사항이 검수 단계에서 추가됨
  • 작은 오류 때문에 전체 완료가 지연됨
  • 어떤 오류를 먼저 수정할지 판단하기 어려움

따라서 개발 시작 전이나 늦어도 검수 전에 다음 내용을 정해야 합니다.

어떤 환경에서 무엇을 확인하며, 어느 상태를 완료로 판단할 것인가?

검수는 단순히 화면을 둘러보는 과정이 아닙니다

웹개발 검수에서는 다음 요소를 확인할 수 있습니다.

  • 기능
  • 사용자 흐름
  • 관리자
  • 데이터
  • 권한
  • 모바일
  • 브라우저
  • 외부 API
  • 결제
  • 오류 처리
  • 배포
  • 인계

프로젝트 성격에 따라 필요한 항목은 달라집니다.

단순한 기업 홈페이지와 회원·결제·관리자가 있는 웹서비스를 같은 방식으로 검수할 수는 없습니다.

검수 전에 기준 문서가 있어야 합니다

검수의 기준은 일반적으로 다음 문서에서 확인할 수 있습니다.

  • 계약서
  • 견적서
  • 요구사항 정의서
  • 기능 목록
  • 화면 설계서
  • 승인된 디자인
  • 변경 요청서
  • 회의 결정 내용

처음에 말했던 것이나 보통 당연히 들어가는 기능은 서로 다르게 기억할 수 있습니다.

최신 합의 내용을 한 문서에 정리하는 것이 좋습니다.

1. 기능 검수

각 기능이 합의한 흐름대로 작동하는지 확인합니다.

예를 들어 회원가입 기능이라면 다음 항목을 볼 수 있습니다.

  • 필수 항목 검증
  • 이메일 형식
  • 비밀번호 조건
  • 이용약관 동의
  • 중복 이메일
  • 인증 이메일
  • 가입 완료
  • 관리자 회원 조회
  • 로그인 가능 여부

기능 이름 하나만 확인하지 말고 입력부터 결과까지 전체 흐름을 테스트해야 합니다.

2. 실패와 예외 상황 검수

정상적인 상황만 테스트하면 실제 운영 중 오류가 발생할 수 있습니다.

입력 예외

  • 필수 항목 누락
  • 잘못된 이메일
  • 너무 긴 글
  • 허용되지 않는 파일
  • 중복 데이터

네트워크 예외

  • 요청 중 인터넷 연결 끊김
  • 서버 응답 지연
  • 중복 버튼 클릭
  • 새로고침
  • 뒤로 가기

외부 서비스 예외

  • 결제 실패
  • 이메일 발송 실패
  • API 응답 오류
  • 소셜 로그인 취소
  • 알림톡 실패

사용자에게 오류 원인과 다음 행동이 적절하게 안내되는지 확인해야 합니다.

3. 사용자 권한 검수

사용자 유형이 여러 개라면 권한별로 테스트해야 합니다.

예를 들면 다음과 같습니다.

  • 비회원
  • 일반 회원
  • 기업 직원
  • 기업 관리자
  • 운영 관리자
  • 최고 관리자

확인할 항목은 다음과 같습니다.

  • 접근 가능한 페이지
  • 조회 가능한 데이터
  • 수정 가능한 데이터
  • 버튼 노출
  • 다운로드 권한
  • 관리자 메뉴
  • URL 직접 접근 차단

화면에서 버튼만 숨기는 것으로는 충분하지 않습니다.

서버에서도 권한 검사가 적용되어야 합니다.

4. 관리자 페이지 검수

관리자는 실제 운영 업무를 기준으로 테스트해야 합니다.

  • 회원 검색
  • 필터
  • 상태 변경
  • 승인·반려
  • 콘텐츠 등록
  • 이미지 업로드
  • 문의 처리
  • 결제 확인
  • 환불
  • 엑셀 다운로드
  • 권한 관리
  • 수정 이력

관리자 기능은 존재 여부뿐 아니라 실제 운영 속도와 실수 방지까지 확인하는 것이 좋습니다.

5. 데이터 검수

입력한 데이터가 정확하게 저장되고 조회되는지 확인합니다.

  • 입력값
  • 날짜
  • 시간대
  • 금액
  • 소수점
  • 상태
  • 파일
  • 특수문자
  • 다국어
  • 정렬

다음 상황도 확인할 수 있습니다.

  • 수정 후 기존 값이 올바르게 변경되는가?
  • 삭제한 데이터가 필요한 곳에서 사라지는가?
  • 통계와 실제 목록이 일치하는가?
  • 엑셀 다운로드와 화면 데이터가 일치하는가?
  • 사용자별 데이터가 섞이지 않는가?

6. 반응형 검수

PC에서 정상적으로 보인다고 모바일에서도 정상인 것은 아닙니다.

확인할 화면은 다음과 같습니다.

  • 작은 모바일
  • 일반 모바일
  • 태블릿
  • 노트북
  • 데스크톱

확인할 항목은 다음과 같습니다.

  • 글자 크기
  • 줄바꿈
  • 버튼 크기
  • 메뉴
  • 이미지
  • 팝업
  • 입력창
  • 고정 요소
  • 가로 스크롤

실제 기기와 브라우저 개발자 도구를 함께 사용할 수 있습니다.

7. 브라우저 검수

지원할 브라우저 범위를 계약 전에 정하는 것이 좋습니다.

일반적으로 다음 환경을 검토할 수 있습니다.

  • Chrome
  • Safari
  • Edge
  • Android Chrome
  • iPhone Safari

오래된 브라우저까지 모두 지원하려면 추가 작업이 필요할 수 있습니다.

8. 디자인 검수

승인된 디자인과 실제 결과를 비교합니다.

  • 폰트
  • 색상
  • 여백
  • 이미지 비율
  • 버튼
  • 카드
  • 정렬
  • 모바일 구성
  • 애니메이션

다만 브라우저와 운영체제에 따라 글꼴 렌더링이 조금 다를 수 있습니다.

디자인 검수는 주관적인 느낌보다 승인된 시안과 명확한 기준을 중심으로 진행하는 것이 좋습니다.

9. 콘텐츠 검수

  • 오탈자
  • 연락처
  • 주소
  • 이메일
  • 가격
  • 법적 문구
  • 링크
  • 이미지
  • 첨부파일
  • 다국어 번역

콘텐츠를 의뢰사가 제공했다면 내용 정확성은 의뢰사가 최종 확인하는 것이 좋습니다.

10. 결제 기능 검수

온라인 결제가 있다면 정상 결제 외에도 여러 상태를 확인해야 합니다.

  • 결제 성공
  • 결제 실패
  • 사용자 취소
  • 중복 클릭
  • 취소
  • 전체 환불
  • 부분 환불
  • 결제 내역
  • 관리자 확인
  • 서비스 권한 지급
  • 결제는 성공했지만 서버 처리 실패

PG사의 테스트 환경과 운영 환경에서 각각 확인할 수 있습니다.

11. 외부 API 검수

  • 정상 응답
  • 잘못된 입력
  • 호출 제한
  • 인증 만료
  • 응답 지연
  • 외부 서비스 장애
  • 중복 응답
  • 데이터 형식 변경

외부 서비스 자체의 장애는 개발 업체가 완전히 통제할 수 없으므로 실패 시 서비스가 어떻게 안내하고 복구하는지를 확인해야 합니다.

12. 파일 기능 검수

  • 허용 파일 형식
  • 용량 제한
  • 여러 파일 업로드
  • 진행률
  • 실패 후 재시도
  • 다운로드
  • 삭제
  • 접근 권한
  • 파일명
  • 모바일 업로드

사용자가 올린 파일을 다른 사용자가 볼 수 없는지도 확인해야 합니다.

13. 이메일·알림 검수

  • 발송 시점
  • 수신자
  • 제목과 내용
  • 링크
  • 변수 치환
  • 중복 발송
  • 실패 처리
  • 발송 이력
  • 수신 거부
  • 모바일 표시

알림이 너무 많이 발송되거나 잘못된 사용자에게 가지 않는지 확인합니다.

14. SEO와 공유 검수

기업 홈페이지나 공개 콘텐츠 서비스에서는 다음을 볼 수 있습니다.

  • 페이지 제목
  • 메타 설명
  • 검색엔진 색인 설정
  • 사이트맵
  • robots.txt
  • canonical
  • Open Graph
  • 공유 이미지
  • 잘못된 404 페이지
  • 기존 URL 리디렉션

SEO는 검색 상위 노출을 검수하는 것이 아니라 설정과 구조가 합의대로 적용됐는지 확인합니다.

15. 속도와 기본 성능 검수

프로젝트에 별도 성능 기준이 있다면 숫자로 정해야 합니다.

일반적으로는 다음 문제를 확인할 수 있습니다.

  • 첫 화면이 지나치게 늦게 나타남
  • 이미지가 너무 큼
  • 목록이 많아지면 멈춤
  • 버튼을 여러 번 누르면 중복 처리
  • 대용량 엑셀 다운로드 실패
  • 동시 요청 시 오류

대규모 트래픽이나 특정 응답 속도를 보장해야 한다면 별도의 부하 테스트 범위가 필요할 수 있습니다.

16. 보안 관련 기본 검수

보안 전문 점검과 일반 기능 검수는 다릅니다.

일반 프로젝트에서는 다음 기본 항목을 확인할 수 있습니다.

  • 관리자 권한
  • 비밀번호 저장
  • 개인정보 노출
  • API 키 노출
  • 로그인 세션
  • 파일 접근 권한
  • 입력값 검증
  • 오류 메시지에 내부 정보 노출 여부

전문적인 취약점 진단이나 침투 테스트가 필요하면 별도 보안 업체나 범위를 검토해야 합니다.

17. 운영 서버 배포 검수

개발 환경에서 정상이어도 운영 서버에서 문제가 생길 수 있습니다.

  • 실제 도메인
  • HTTPS
  • 운영 데이터베이스
  • 파일 저장소
  • 이메일
  • 결제
  • 외부 API
  • 로그
  • 백업
  • 환경변수

운영 배포 후 핵심 기능을 다시 확인해야 합니다.

오류의 심각도를 구분하는 방법

모든 오류를 같은 우선순위로 처리하기는 어렵습니다.

등급예시처리 기준
긴급서비스 전체 접속 불가, 결제 전체 실패, 데이터 노출즉시 대응 필요
높음핵심 기능 사용 불가, 특정 사용자 로그인 불가공개 전 해결
보통일부 조건에서 오류, 우회 방법 있음일정 내 수정
낮음오탈자, 작은 간격, 표현 개선우선순위 협의
개선신규 기능, 사용성 향상 아이디어별도 범위 검토

프로젝트에 맞는 등급과 처리 기준을 합의할 수 있습니다.

오류와 기능 추가를 구분해야 합니다

오류

합의한 동작과 다르게 작동함

text
합의:
관리자는 회원을 이름으로 검색할 수 있다.

결과:
이름 검색이 작동하지 않는다.

기능 추가

기존 합의에 없던 동작

text
추가 요청:
회사명·가입일·상태를 조합한 고급 검색을 추가한다.

검수 단계에서 새로운 요구가 생길 수 있지만, 기존 오류와 추가 개발은 구분해서 관리하는 것이 좋습니다.

검수 과정 예시

1. 개발 업체 자체 테스트

개발 업체가 주요 기능과 오류를 먼저 확인합니다.

2. 검수 환경 제공

  • 테스트 URL
  • 테스트 계정
  • 기능 목록
  • 알려진 제한사항

3. 의뢰사 검수

실제 사용자와 운영자 관점에서 확인합니다.

4. 오류 등록

화면, 재현 방법, 기대 결과를 기록합니다.

5. 수정

개발 업체가 우선순위에 따라 수정합니다.

6. 재검수

동일 오류와 영향받은 기존 기능을 확인합니다.

7. 최종 승인

중대한 오류가 해결되고 완료 기준을 충족하면 승인합니다.

오류를 전달할 때 포함할 정보

좋지 않은 예시:

text
결제가 안 됩니다.
화면이 이상합니다.
모바일이 깨집니다.

좋은 예시:

text
환경:
iPhone 15 / Safari

계정:
test@example.com

화면:
요금제 결제 페이지

진행:
월간 요금제 선택 → 카드 결제 → 인증 완료

현재 결과:
결제 완료 후 흰 화면이 표시됨

기대 결과:
결제 완료 페이지로 이동하고 이용 권한이 활성화되어야 함

발생 시간:
2026-07-24 14:30

첨부:
화면 녹화

오류를 재현할 수 있어야 수정이 빨라집니다.

검수 체크리스트 예시

text
[ ] 회원가입
[ ] 로그인
[ ] 비밀번호 찾기
[ ] 사용자 권한
[ ] 핵심 서비스 기능
[ ] 관리자 기능
[ ] 검색과 필터
[ ] 결제 성공·실패
[ ] 이메일·알림
[ ] 파일 업로드
[ ] 엑셀 다운로드
[ ] 모바일
[ ] 브라우저
[ ] 오탈자와 링크
[ ] SEO 기본 설정
[ ] 운영 서버 배포
[ ] 소스와 계정 인계
[ ] 관리자 사용 방법

검수 기간은 얼마나 필요할까?

프로젝트 규모에 따라 다릅니다.

  • 단순 홈페이지: 수일
  • 기능형 홈페이지: 1~2주
  • 복잡한 웹서비스: 2주 이상
  • 다수 부서가 참여하는 시스템: 별도 일정 필요

검수 기간 동안 의뢰사의 담당자가 실제로 시간을 확보해야 합니다.

검수를 늦게 시작하면 전체 공개 일정도 늦어질 수 있습니다.

검수 담당자를 정해야 합니다

다음 역할을 구분하면 좋습니다.

  • 최종 승인자
  • 사용자 기능 검수자
  • 관리자 기능 검수자
  • 콘텐츠 검수자
  • 결제·운영 검수자

여러 담당자가 개별적으로 요청하면 충돌할 수 있으므로 대표 담당자가 의견을 취합하는 것이 좋습니다.

완료를 무기한 미루지 않으려면

검수에서 모든 개선 의견을 반드시 해결할 때까지 완료를 미루면 프로젝트가 끝나지 않을 수 있습니다.

다음처럼 나눌 수 있습니다.

공개 전 필수

  • 핵심 기능 오류
  • 결제
  • 로그인
  • 개인정보
  • 화면 사용 불가

공개 후 수정 가능

  • 작은 디자인 조정
  • 표현 개선
  • 운영 편의
  • 낮은 우선순위 오류

별도 개발

  • 신규 기능
  • 구조 변경
  • 고급 통계
  • 추가 자동화

마무리

웹개발 검수는 결과물이 마음에 드는지 확인하는 단계만은 아닙니다.

계약한 기능이 실제 환경에서 정상적으로 작동하고, 의뢰사가 운영 가능한 상태로 전달됐는지를 확인하는 과정입니다.

검수 전에 다음을 명확히 정하는 것이 좋습니다.

  • 검수 기준 문서
  • 지원 환경
  • 기능별 완료 조건
  • 오류 등급
  • 수정 기간
  • 최종 승인 방식
  • 신규 기능과 오류의 구분

검수 기준이 구체적일수록 의뢰사와 개발 업체 모두 완료 상태를 명확하게 판단할 수 있습니다.

필요한 답을 찾고, 끝까지 완성합니다.

기술을 알지 못해도, 기획서가 없어도 괜찮습니다.

프로젝트 문의하기