홈페이지 제작 검수표: 수정 요청·추가 개발·납품 완료를 나누는 기준

"제작사는 다 됐다고 하는데 문의 버튼을 누르면 아무 데도 안 와요. 이걸 하자로 봐야 하나요, 추가 요청으로 봐야 하나요?" 최종 검수에서 확인할 상황을 가정해 보겠습니다. 제작사와 발주사가 "완성"이라는 단어를 서로 다르게 쓰고 있거든요. 화면이 다 그려진 상태를 완성이라 부르는 쪽과, 합의한 기능이 실제로 동작하는 상태를 완성이라 부르는 쪽이 같은 표를 보고 있지 않으면 검수는 몇 번을 해도 끝나지 않습니다. 견적 단계에서 무엇이 범위에 들어가는지 확인하는 방법은 견적서 항목 체크리스트에 있으니, 이 글은 그 다음 단계인 "합의한 것이 됐는지 어떻게 증명하나"만 다룹니다.

1. "홈페이지 완성" 대신 요구사항별 합격 기준을 합의합니다

견적서에는 보통 "메인 1, 서브 5, 문의폼 1"처럼 페이지 수와 기능 이름만 적혀 있어요. 검수는 이 한 줄을 여러 줄의 시험으로 풀어 쓰는 데서 시작합니다. 아래 표는 저희가 실무용으로 제안하는 양식이고, 표준계약서나 법적 효력이 있는 서식이 아닙니다. 계약 뒤에 발주사가 일방적으로 검수 범위를 늘리는 도구도 아니에요. 합의 문서에 이미 적힌 것을 시험 가능한 문장으로 바꾸는 용도입니다.

요구 ID는 "R-01"처럼 짧게 붙이면 되고, 합의 문서·버전 열에는 견적서 v2, 회의록 8월 12일처럼 그 요구가 어디서 왔는지를 적습니다. 이 열이 비어 있으면 원래 합의와 확인 근거부터 찾아야 합니다. 기록이 없다는 이유만으로 새 요청이라고 단정하지 마세요. 기대 결과는 "잘 되는지"가 아니라 "성공 화면이 뜨고 지정한 주소로 메일이 도착한다"처럼 누가 봐도 같은 판정을 내릴 수 있게 씁니다. 담당자와 일정 조율은 제작 기간 가이드에서 다뤘으니 여기서는 검수 담당자를 한 명으로 두라는 조언만 다시 빌려 오겠습니다.

2. 문의폼 하나로 작성하는 검수표 예시

문의폼이 좋은 예시인 이유는 "클릭이 된다"와 "문의가 접수된다"의 차이가 가장 선명하게 드러나기 때문입니다. 아래 세 행은 전부 가상 예시이고 실제 고객사나 실제 결과가 아닙니다.

예 A에서 중요한 건 성공 화면이 떴는데도 보류라는 점이에요. 합의가 "이메일 전달"이면 완료 증거는 화면이 아니라 수신함입니다. 예 B는 반대로, DB 저장이 합의에 들어 있을 때만 검사하는 항목입니다. 계약에 관리자 저장이 없었다면 저장이 안 되는 것을 하자라고 부를 수 없어요. 예 C의 근거는 W3C의 WCAG 2.2 성공 기준 3.3.1인데, 입력 오류가 자동으로 검출되면 어떤 항목이 잘못됐는지 식별하고 오류를 텍스트로 설명해야 하며, 폼을 그냥 다시 보여 주기만 하는 것으로는 부족하다고 적혀 있습니다(W3C SC 3.3.1 해설). 색만 바뀌는 건 이 기준에 못 미칩니다.

시험은 반드시 합의된 환경에서 시험 데이터로 하세요. 실제 고객 연락처를 넣거나 실제 고객에게 메시지가 발송되게 하면 안 됩니다. 판정 근거도 "며칠 기다려 보자"가 아니라 그 시점의 화면 상태와 수신 기록이어야 해요. 기다림은 증거가 아닙니다.

3. 하자 수정, 합의된 수정, 추가 개발을 나누는 기록법

문의폼이 안 되는 것과 문의 내용을 새 CRM으로 보내 달라는 것은 전혀 다른 요청인데, 검수 회의에서는 같은 "수정 요청" 칸에 들어가곤 합니다. 나누는 기준은 감정이 아니라 기록이에요.

세 줄 중 어디에 넣을지 애매하면 결론을 미루고 증거와 문서 버전부터 맞추세요. "무조건 무상"도 "무조건 추가 과금"도 이 표에서 나오지 않습니다. 이 글은 비용이나 무료 횟수를 제시하지 않고, 그건 각자의 계약이 정하는 문제예요. 실제 공개 질문 중에는 계약 기간을 한참 넘긴 상태에서 사이트 내부 검색 기능 오류로 15회 넘게 검수를 반복했고, 제작사는 화면의 완성 비율을 근거로 환불이 어렵다고 주장했다는 사례가 있습니다(네이버 지식iN 493364205). 법적 결론은 저희가 낼 수 없지만, 그 갈등의 구조는 분명해요. 화면 완성 비율과 핵심 기능의 합격 여부가 한 표에 같이 기록돼 있었다면 "몇 퍼센트 완성"이라는 말이 설 자리가 훨씬 좁았을 겁니다.

4. "화면 확인", "공개 승인", "운영 인수"를 따로 기록합니다

승인은 한 번이 아니라 네 종류입니다. 화면 승인은 합의된 원고와 레이아웃이 대상 기기에서 맞게 나오는지를 보고, 기능 승인은 검수표의 기대 결과와 실제 결과, 그리고 미해결 결함 목록을 봅니다. 공개 승인은 어떤 버전을 어느 주소로 열지 발주 담당자가 결정하는 행위이고, 운영 인수는 수정 방법과 합의된 파일·계정·백업을 실제로 넘겨받았는지 확인하는 단계예요. 넷 중 하나가 됐다고 나머지가 된 건 아닙니다. 화면 승인이 끝났는데 기능 승인이 남아 있을 수 있고, 공개는 했는데 운영 인수는 안 된 상태도 흔합니다.

기술 항목을 폭넓게 점검하는 목록은 홈페이지 품질 검토 가이드에 이미 있으니 여기서 다시 나열하지 않겠습니다. 운영 인수에서 도메인·저장소·DB·관리자 권한을 항목별로 어떻게 확인하는지는 도메인 소유권 이전과 소스 인수인계 가이드에 표로 정리해 뒀어요. 도메인 변경이 계약에 포함된 경우라면 네이버 서치어드바이저의 사이트 이전 가이드가 요구하는 구 URL에서 신 URL로의 1:1 HTTP 이동과 모든 페이지의 canonical 지정을 검수 항목에 넣을 수 있습니다(네이버 웹 사이트 이전 가이드). 다만 검색 순위 자체를 합격 기준으로 삼지는 마세요. 순위는 제작사가 통제하는 값이 아닙니다.

5. 재검수 결과가 남는 승인 기록 예시

검수를 여러 번 하는 것 자체는 문제가 아니에요. 문제는 몇 번째 검수에서 무엇이 고쳐졌고 무엇이 남았는지 아무도 모르는 상태입니다. 한 줄 흐름은 이렇습니다. 버전 → 결함 ID → 수정 결과 → 동일 절차 재시험 → 승인/보류 → 잔여 항목과 담당자.

이 가상 예에서 v1.0은 화면 기준으로는 거의 다 돼 있었을 수 있어요. 그래도 문의가 안 오면 핵심 기능은 미합격입니다. 완성 비율과 기능 합격은 다른 축이고, 표는 그 둘을 섞지 않게 해 줍니다. 미해결 필수 기능이 기록된 상태에서 계약상 완료냐 미완료냐를 판정하는 건 이 글의 범위가 아니고, 그 판단에 쓸 날짜·문서·시험 결과를 남기는 것까지가 이 표의 역할이에요.

상담을 요청하실 때는 사이트 주소, 합의한 기능 목록, 그리고 위 방식으로 재현되는 문제 하나를 적어 주시면 됩니다(상담 신청). 비밀번호나 실제 고객 데이터는 일반 문의폼에 적지 마세요.

검수표를 처음 만들 때 제일 어려운 건 표 자체가 아니라, 견적서에 있던 한 줄이 실제로는 몇 개의 약속이었는지 세어 보는 일입니다. 그 개수를 세기 전까지는 제작사도 발주사도 자기가 무엇을 완성했는지 정확히 말할 수 없어요.