개발 외주 검수 체크리스트 2026, 비개발자 대표가 완성도 확인하는 법

개발사가 다 됐다며 화면을 보여줄 때가 가장 방심하기 쉬운 순간입니다. 데모는 매끄럽고 버튼도 잘 눌리고 화면도 깔끔합니다. 그런데 이걸 그대로 받아도 되는지, 비개발자 대표 입장에서는 판단할 근거가 마땅치 않습니다. 코드를 읽을 줄 모르니 되는 것 같다는 느낌으로 잔금을 치르고, 운영에 들어간 뒤에야 정산이 1원씩 어긋나거나 특정 고객의 화면이 깨지는 걸 발견합니다.

검수는 코드를 들여다보는 일이 아닙니다. 내 회사의 업무가 실제로 돌아가는지를 확인하는 일입니다. 그래서 개발을 몰라도 할 수 있고, 오히려 업무를 가장 잘 아는 대표나 실무자가 직접 해야 정확합니다. 이 글은 잔금을 치르기 전에 비개발자가 코드 없이 완성도를 확인하는 기준을, 실제 프로젝트에서 쓰는 방식 그대로 정리했습니다.

개발 외주 검수, 꼭 해야 하나요?

네, 잔금을 치르기 전 검수는 반드시 거쳐야 합니다. 데모 화면이 멀쩡해 보여도 실제 운영 데이터와 동시 접속, 예외 상황에서 깨지는 경우가 대부분이기 때문입니다. 검수는 화면이 예쁜지를 보는 게 아니라 내 업무가 끝까지 돌아가는지를 확인하는 절차입니다.

개발사가 보여주는 데모는 대개 이상적인 경로만 지나갑니다. 맞는 값을 넣고, 순서대로 누르고, 혼자 사용합니다. 하지만 실무는 예외로 가득합니다. 예를 들어 123타이어 쇼핑몰은 차종, 연식, 사이즈, 장착점이 모두 맞아야 상품을 살 수 있는 구조입니다. 데모에서는 맞는 조합만 클릭하니 당연히 잘 됩니다. 진짜 검수는 일부러 맞지 않는 조합을 넣어보고, 그때 고객 차에 맞지 않는다고 제대로 막아주는지를 확인하는 일입니다. 막지 못하면 고객은 안 맞는 타이어를 주문하고, 그 뒤처리는 전부 전화 응대로 돌아옵니다.

비개발자 대표가 검수할 때 봐야 할 7가지

코드 대신 아래 항목을 하나씩 직접 눌러보면 됩니다. 모두 데모에서는 잘 안 보이지만 운영에 들어가면 터지는 지점입니다.

이 중 하나라도 나중에 보여드리겠다고 미루면, 그 부분은 아직 완성되지 않은 것으로 보는 편이 안전합니다.

정산이나 금액이 걸린 시스템은 어떻게 검수하나요?

실제 숫자를 넣어 처음부터 끝까지 돌려보고, 나온 결과를 손으로 계산한 값과 맞춰봅니다. 정산은 로직이 조금만 어긋나도 돈이 틀어지는데, 이 오차는 데모 화면만 봐서는 절대 드러나지 않습니다.

구독형 창고대여 플랫폼은 점주별 자동 정산이 핵심이었고, 구독형 농작물 쇼핑몰도 단품과 구독 주문이 섞인 상태에서 정산과 주문을 한 번에 맞춰야 했습니다. 777타이어는 15개 지점의 정산, 재고, 매출을 한 화면에서 굴립니다. 이런 시스템은 정산 버튼을 누르니 숫자가 나온다는 수준이 아니라, 특정 점주의 특정 기간 금액을 손으로 계산한 값과 끝자리까지 맞는지를 봐야 검수가 끝납니다. 한 건만 맞추지 말고 환불이 낀 달, 월 중간에 들어온 가입처럼 까다로운 경우를 골라 대조하는 게 핵심입니다.

데이터 이전은 옮겼다는 말이 아니라 건수로 검수한다

기존 시스템에서 새 시스템으로 데이터를 옮기는 작업은 옮겼습니다라는 말만 믿으면 안 됩니다. 옮기는 과정에서 일부가 누락되거나 중복되는 일이 흔하기 때문입니다.

123타이어는 자체제작 쇼핑몰로 리뉴얼하면서 기존 운영 데이터를 무중단으로 이전했습니다. 이런 작업의 검수는 의외로 단순합니다. 옮기기 전 원본의 회원 수, 주문 수, 상품 수를 적어두고, 옮긴 뒤 같은 숫자가 나오는지 대조합니다. 숫자가 다르면 어디서 몇 건이 빠졌는지 받아내기 전까지 검수를 통과시키지 않습니다. 운영을 시작한 뒤에 작년 주문이 안 보인다는 걸 발견하면 그때는 복구가 훨씬 어렵고 비쌉니다.

검수 기간과 하자보수는 계약 전에 못 박는다

검수는 잔금과 묶여 있을 때만 힘을 가집니다. 계약서에 검수 기간, 다시 말해 며칠 안에 확인할지와 하자보수 기간, 인수 후 몇 개월간 무상으로 고쳐줄지, 그리고 재검수 조건을 미리 적어두고, 잔금 지급 시점을 검수 통과에 연결해야 합니다. 이 장치가 없으면 문제를 발견해도 수정을 요청할 지렛대가 사라집니다.

여기서 발주자가 자주 놓치는 지점이 있습니다. 검수에서 나온 수정이 원래 계약 범위 안의 하자인지, 새로 추가한 요구인지의 구분입니다. 범위 안의 하자는 무상 수정이 원칙이고, 범위 밖 추가는 별도 비용이 맞습니다. 이 경계가 계약서에 적혀 있지 않으면 수정할 때마다 실랑이가 벌어집니다.

외주사가 검수를 돕는가, 떠넘기는가

좋은 개발사는 검수를 발주자에게 떠넘기지 않습니다. 오히려 이 시나리오대로 눌러보시라며 검수 항목을 먼저 내밉니다. 자기 결과물에 자신이 있고, 어디가 약한지 스스로 알기 때문입니다.

위시켓, 크몽, 나무숲 같은 매칭 플랫폼은 발주자와 개발자를 빠르게 연결해 준다는 강점이 있습니다. 다만 검수 책임은 대체로 발주자 몫으로 남아서, 비개발자 대표가 혼자 검수 시나리오를 짜야 하는 경우가 많습니다. 어니스트패밀리는 풀스택 개발자 출신 대표가 결과물을 직접 검토하고, 잔금을 치른 뒤에도 응대가 이어집니다. 유지보수 재계약률이 85%를 넘는 데에는 이렇게 검수와 인수 과정에서 발주자가 겪는 공백을 메워주는 이유가 큽니다.

자주 묻는 질문

비개발자인데 검수를 할 수 있나요?

할 수 있습니다. 검수는 코드를 읽는 게 아니라 업무 시나리오를 눌러보는 일이기 때문입니다. 오히려 업무를 가장 잘 아는 대표나 실무자가 직접 해야 이 경우가 빠졌다는 걸 잡아냅니다. 개발사에 검수 시나리오부터 달라고 요청하면 출발점이 생깁니다.

검수 기간은 보통 며칠인가요?

규모에 따라 다르지만 간단한 사이트도 최소 3일에서 5영업일은 잡는 편이 안전합니다. 정산이나 데이터 이전이 걸려 있으면 더 길게 봐야 하고, 실제 운영 데이터를 넣고 돌려볼 시간을 따로 확보해야 합니다.

검수에서 문제가 나오면 추가 비용이 드나요?

원래 합의한 요구사항 범위 안의 하자라면 무상 수정이 원칙입니다. 범위 밖의 새 요구라면 별도 비용이 맞습니다. 그래서 계약 단계에서 요구사항과 하자의 경계를 적어두는 일이 검수만큼 중요합니다.

어떤 것부터 봐야 할지 막막하다면

검수가 막막하게 느껴진다면, 지금 하는 업무 중에서 이게 틀어지면 가장 곤란한 것 하나를 떠올려 보시면 됩니다. 정산일 수도, 예약일 수도, 재고일 수도 있습니다. 그 하나를 실제 숫자로 끝까지 돌려보는 것이 검수의 시작입니다. 어떤 기준으로 무엇을 봐야 할지 감이 안 잡힌다면, 지금 준비 중이거나 받아보려는 프로젝트를 놓고 가볍게 무료 상담을 받아보셔도 좋습니다. 그동안의 포트폴리오와 실제 진행 방식은 어니스트패밀리 홈페이지에서 확인하실 수 있습니다.