개발 외주 검수, 어떻게 해야 분쟁이 줄어들까요 | 절차·기준 체크리스트
검수 없이 넘어가면 착수 후 잔금·하자 분쟁으로 번지기 쉬워요. 검수 요청부터 검수완료 간주 조항, 결함 등급 분류, 하자담보책임기간(소프트웨어산업 진흥법 기준 통상 1년)까지 검수·인수 절차를 운영해본 개발사 기준으로 정리했어요.
검수는 “다 됐죠?”라고 한마디로 끝내는 절차가 아니에요. 검수 요청부터 검수완료까지 기한을 정하고, 무엇을 확인할지 항목으로 나누고, 결함이 나오면 등급을 매겨 재검수하는 흐름이 있어야 착수 후 다툼이 줄어들어요. 검수 기준이 애매하면 잔금 지급도, 하자보수 책임도 같이 흐려져요. 직접 만들고 운영해본 개발사 기준으로 검수·인수 절차를 정리했어요.
“오픈은 했는데 이게 검수가 끝난 건지 아닌지 모르겠어요.” 개발 외주를 진행해본 발주자분들이 실제로 자주 하는 말이에요. 눈으로 보기엔 화면이 다 떠 있으니 완료된 것 같은데, 계약서 어디에도 “이 시점부터 검수 완료”라는 기준이 없으면 잔금·하자보수·유지보수 전환 시점까지 줄줄이 애매해져요. 검수를 어떻게 설계해야 이런 상황을 피할 수 있는지 순서대로 짚어볼게요.
1. 검수 없이 넘어가면 왜 나중에 분쟁으로 번질까요
개발 외주 분쟁의 상당수는 계약 초반이 아니라 마무리 단계에서 터져요. “완성됐다”는 개발사 말과 “이 정도면 아직 부족하다”는 발주자 체감이 서로 다른 채로 오픈일이 다가오면, 그 간극이 잔금 지급 거부나 하자보수 범위 다툼으로 이어져요. 대한상사중재원에 접수되는 IT 관련 분쟁에서도 결과물 불일치와 저작권·하자 분쟁이 꾸준히 등장하는데, 두 유형 모두 “무엇을 기준으로 완료로 볼 것인가”가 처음부터 정해지지 않아서 생기는 경우가 많아요. 검수는 이 기준을 문서로 확정하는 절차라서, 계약서에서 가장 가볍게 다뤄지면 안 되는 항목이에요.
2. 검수와 인수 테스트는 정확히 무엇을 확인하는 절차일까요
용어 하나만 짚고 갈게요. 단위 테스트는 개발사 내부에서 기능 하나하나가 제대로 작동하는지 확인하는 단계고, 통합 테스트는 여러 기능이 맞물렸을 때 오류가 없는지 보는 단계예요. 인수 테스트(User Acceptance Test)는 이 둘을 통과한 뒤 발주자가 직접 참여해서 처음 요구했던 조건대로 작동하는지 검증하는 단계고, 검수는 이 인수 테스트 결과를 근거로 “완료로 인정한다”고 공식화하는 절차예요. 실무에선 “인수 테스트를 통과해야 검수 요청이 가능하다”는 순서로 이 셋을 함께 써요.
발주자 입장에서 헷갈리기 쉬운 지점은, 화면이 눈으로 정상 작동해 보인다고 해서 인수 테스트를 통과한 게 아니라는 거예요. 처음 합의한 요구사항 정의서를 기준으로 항목별로 하나씩 대조해야 “정상 작동”이라는 말이 실제로 의미를 가져요.
3. 검수는 어떤 순서로 진행돼야 안전할까요
검수는 대체로 이런 흐름으로 진행돼요.
- 검수 요청 — 개발사가 완료 보고서와 최종 산출물을 정리해 검수를 요청해요.
- 인수 테스트 — 발주자(또는 지정 담당자)가 요구사항 정의서 항목별로 직접 확인해요.
- 결과 정리 — 통과 항목과 결함 항목을 구분해 문서로 남겨요.
- 재검수(필요 시) — 결함을 수정한 뒤 다시 확인해요.
- 검수조서 서명 — 양측 담당자가 검수 완료를 문서로 확정해요.
이 순서가 계약서에 명시돼 있지 않으면, 5단계인 검수조서 서명 없이 “구두로 괜찮다고 했으니 끝난 거 아니냐”는 식으로 흘러가기 쉬워요. 앱 개발 외주를 맡기기 전에 확인해야 할 체크리스트에서도 다뤘듯, 검수 기준을 계약 전에 구체적으로 정해두는 것 자체가 검수 단계의 절반이에요.
4. 결함이 나오면 등급을 어떻게 나누고 처리해야 할까요
인수 테스트에서 나온 결함을 전부 같은 무게로 다루면 재검수 일정만 계속 늘어져요. 저희는 실무에서 결함을 아래처럼 나눠서 처리해요.
| 항목 | 자사 실무 기준 예시 | 참고할 공식 기준 |
|---|---|---|
| 결함 등급 | 치명(핵심 기능 불가) · 중요(대체 방법 있음) · 경미(디자인·오타 수준) 3단계 | 별도 법정 기준 없음 — 사업 특성에 따라 자율 설정(SW기술성평가 지침 등 참고) |
| 검수 요청 후 완료 기한 | 규모별로 5～15영업일을 계약서에 명시 | 법정 기간은 없고 실무 관행상 통상 2주 내외로 운용되는 사례가 많아요 |
| 미통보 시 처리 | 기간 내 서면 이의가 없으면 검수 완료로 간주 | 계약 관행상 통용되나, 계약서에 문구가 없으면 효력을 주장하기 어려워요 |
치명 결함은 재검수가 필수예요. 반면 경미한 결함까지 재검수 대상으로 묶으면 오픈 일정 자체가 밀리기 때문에, 경미 항목은 “오픈 후 N일 내 수정”으로 분리하는 편이 실무적으로 더 매끄러워요.
5. 검수 완료 이후 하자보수는 언제부터, 얼마나 이어질까요
검수완료일은 하자보수 기간이 시작되는 기준점이기도 해요. 소프트웨어산업 진흥법 제60조는 소프트웨어 사업의 하자담보책임기간을 최종 산출물을 인도한 날, 즉 검수 완료일로부터 통상 1년으로 보고 있어요. 이 기간 안에 개발사 과실로 확인된 결함은 무상으로 고쳐주는 게 원칙이고, 이 기간이 끝나면 유지보수는 별도 계약으로 넘어가요. 검수완료일이 문서로 확정돼 있지 않으면 “하자보수 기간이 아직 안 끝났다”는 주장 자체가 성립하기 어려워지니, 검수조서에 날짜를 명확히 남기는 게 생각보다 중요해요.
6. 검수 과정에서 흔히 하는 실수는 무엇일까요
가장 흔한 실수는 검수 기준을 “정상 작동”처럼 뭉뚱그려 적는 거예요. 어떤 기기, 어떤 환경에서, 어떤 조건을 충족해야 하는지 구체적으로 적지 않으면 통과 여부를 두고 서로 다른 말을 하게 돼요. 그다음으로 자주 보이는 실수는 인수 테스트를 구두로만 확인하고 검수조서를 남기지 않는 경우예요. 실제로 공개된 판례 중에는, 검수와 인도가 끝난 뒤 발주자 측이 개발사가 만든 소스코드를 무단으로 복제·재사용해 저작권 침해로 4천만 원을 배상한 사례도 있어요. 검수 시점에 산출물 범위와 저작권 귀속을 문서로 명확히 남겨두지 않으면, 검수가 끝난 뒤에도 이런 분쟁의 씨앗이 남는다는 걸 보여주는 사례예요.
7. 운영까지 보면 검수를 왜 ‘끝’이 아니라 ‘시작’으로 봐야 할까요
저희는 검수조서에 서명하는 순간을 프로젝트의 끝이 아니라 운영의 시작으로 봐요. 자체 SaaS 4종을 운영하며 배운 건, 검수를 통과한 순간이 아니라 그 이후 실제 이용 데이터가 쌓이는 시점부터 진짜 품질 문제가 드러난다는 점이었어요. 그래서 검수 항목을 정할 때도 화면이 정상 작동하는지뿐 아니라, 오픈 후 트래픽이 몰렸을 때도 같은 기준을 유지하는지까지 함께 확인해요. 납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각하기 때문이에요.
8. 자주 묻는 질문
개발 외주 맡기는 절차 5단계는 무엇인가요?
일반적으로 요구사항 정의 → 계약·착수 → 개발·중간 산출물 확인 → 검수(인수 테스트 포함) → 유지보수 전환 순서로 진행돼요. 검수는 이 중 네 번째 단계이지만, 앞선 세 단계가 얼마나 구체적이었는지에 따라 검수가 매끄럽게 끝날지가 갈려요.
검수 기간을 계약서에 안 적으면 어떻게 되나요?
법으로 정해진 검수 기간은 없어서, 계약서에 명시하지 않으면 “아직 검토 중”이라는 말로 검수가 무한정 늘어질 수 있어요. 반대로 개발사 입장에서도 “미통보 시 검수완료 간주” 조항이 없으면 잔금 지급이 계속 미뤄질 위험이 있어요. 양쪽 모두를 위해 기간과 처리 방식을 문서로 남기는 게 안전해요.
검수에서 발견된 결함은 모두 무상으로 고쳐주나요?
검수 단계에서 발견된 결함은 원래 요구사항 범위 안이라면 무상으로 수정하는 게 일반적이에요. 다만 검수 이후 새로운 기능을 추가해달라는 요청은 유지보수나 추가 개발 계약으로 별도 협의하는 항목이에요. 이 둘을 같은 것으로 여기면 “이 정도는 당연히 되는 거 아니냐”는 오해가 생기기 쉬워요.
9. 정리하며
검수는 프로젝트에서 가장 조용히 지나가기 쉬운 단계지만, 동시에 분쟁 여부를 가르는 지점이기도 해요. 저희는 같은 기능 수보다, 검수 이후 얼마나 자주 재작업이 발생하는지부터 봐요. 11년 넘게 50개 이상의 프로젝트를 진행하면서 자체 SaaS 4종을 직접 운영해온 경험에서 나온 기준이고요. 롯데·캐논 같은 곳과 진행한 프로젝트에서도 검수 항목을 하나씩 문서로 맞춰가며 마무리했어요.
관련해서 함께 보면 좋은 글이에요.