외주 개발 막판 분쟁의 진짜 원인은 '검수 기준'입니다 — 계약·킥오프 단계에서 인수 조건을 정량화하는 법

막판 분쟁은 '품질'이 아니라 '기준의 부재'에서 옵니다

외주 개발 프로젝트가 끝나갈 무렵 가장 자주 듣는 말이 있습니다. "이건 우리가 원한 게 아니에요." 발주사는 품질 미달이라 하고, 개발사는 사양대로 납품했다고 합니다. 양쪽 다 거짓말을 하는 게 아닙니다. 문제는 '원한 것'과 '납품한 것'을 비교할 공통의 잣대가 처음부터 없었다는 점입니다.

이 잣대가 바로 검수 기준입니다. 그런데 많은 계약서가 검수 기준을 "정확도가 낮음", "사용성이 떨어짐", "기획 의도와 다름" 같은 정성적 표현으로 남겨둡니다. 이런 표현은 론칭 후 해석이 갈리기 시작하면 영원히 평행선을 달립니다. 발주사는 "당연히 이 정도는 됐어야지"라 생각하고, 개발사는 "계약서 어디에 그렇게 적혀 있느냐"고 반문합니다. 둘 다 근거가 같은 문서를 가리키는데 결론이 정반대인 상황, 이게 막판 분쟁의 전형입니다.

국내 외주 견적은 대부분 맨먼스(M/M) 기반입니다. 즉 결과물이 아니라 '개발자가 투입된 시간'을 기준으로 비용이 청구되는 구조입니다. 투입 시간으로 돈을 받는 계약에서 산출물과 검수 기준을 따로 정의해두지 않으면, 발주사는 자신이 정확히 '무엇을' 받게 되는지 모호한 채로 비용만 지출하게 됩니다. 그래서 검수 기준은 단순한 품질 관리 문서가 아니라, 발주사가 돈을 주고 사는 대상을 명문화하는 계약의 핵심입니다.

정량 검수 기준: 테스트셋을 계약서에 첨부하세요

해결의 출발점은 검수 기준을 '말'에서 '숫자와 케이스'로 바꾸는 것입니다. 업계에서는 합격/불합격을 판정할 테스트셋을 계약서에 첨부하는 정량 검수 방식이 빠르게 표준으로 자리잡고 있습니다. 핵심은 "잘 작동한다"가 아니라 "이 입력에는 이 출력이 나와야 한다"를 미리 합의하는 것입니다.

킥오프에서 합의해야 할 검수 항목

• 기능별 합격 조건: "회원가입이 된다"가 아니라 "정상 입력·중복 이메일·형식 오류 등 정의된 케이스에서 각각 어떤 화면과 메시지가 나오는가"를 케이스 단위로 적습니다.
• 판정 가능한 표현으로 변환: '빠르게', '안정적으로' 같은 형용사는 모두 '지정한 조건에서 정상 응답이 돌아오는가', '동시 접속 상황에서 오류 없이 처리되는가'처럼 누가 봐도 같은 판정이 나오는 문장으로 바꿉니다.
• 테스트 데이터와 환경 명시: 어떤 데이터로, 어떤 브라우저·기기·서버 환경에서 검수하는지 고정합니다. 환경이 다르면 결과도 달라지고, 그 자체가 새 분쟁거리가 됩니다.
• 검수 주체와 절차: 누가, 며칠 안에, 어떤 양식으로 합격/보완 요청을 회신하는지 정합니다. 검수 기간이 무한정 늘어지는 것도, 회신이 없어 자동 합격으로 간주되는 것도 미리 막아야 합니다.

테스트셋이 있으면 막판에 "이게 맞냐 틀리냐"를 두고 감정 싸움을 할 일이 줄어듭니다. 합격 조건을 통과했는지 함께 돌려보면 끝이기 때문입니다. 발주사 입장에서 이건 개발사를 의심하는 장치가 아니라, 양쪽 모두를 보호하는 객관적 심판을 미리 세워두는 일입니다.

변경관리 절차: 구두 합의가 분쟁의 불씨입니다

두 번째 단골 원인은 변경요청입니다. 프로젝트 중간에 "이 기능 좀 빼고 저걸 넣자"는 요청은 거의 반드시 생깁니다. 문제는 이걸 회의 중 구두로, 메신저 한 줄로 합의하고 넘어갈 때입니다. 정작 정산할 때가 되면 "그건 원래 범위였다"와 "추가 작업이었다"가 충돌합니다.

그래서 계약 단계에서 '변경요청(change request) 절차' 조항을 미리 넣어두는 것이 권장됩니다. 핵심은 변경의 내용·추가 비용·일정 영향을 반드시 서면으로 확정한 뒤에야 작업에 들어간다는 원칙입니다.

변경관리 조항에 담을 항목

• 변경 요청 양식: 무엇을, 왜 바꾸는지와 함께 그로 인한 비용·일정 변동을 한 장에 정리하는 표준 양식을 만들어 둡니다.
• 승인 권한자 지정: 양쪽에서 변경을 최종 승인할 사람을 한 명씩 정합니다. 권한 없는 실무자 사이의 구두 합의는 효력이 없다는 점도 명시합니다.
• 일정·비용 재산정 원칙: 비현실적 일정 수립은 도미노처럼 전체 일정 지연으로 번진다는 점이 연구로도 지적됩니다. 변경이 일정에 미치는 영향을 그때그때 반영하지 않으면, 막판에 모든 지연 책임이 한쪽에 몰리게 됩니다.
• 변경 이력 관리: 승인된 변경요청서를 모아두면 그 자체가 최신 사양서가 됩니다. 최종 검수는 '원래 계약서'가 아니라 '계약서 + 누적된 변경요청서'를 기준으로 한다는 점을 명확히 합니다.

저단가만 보고 파트너를 고르면 커뮤니케이션 비용, 일정 지연의 기회비용, 품질 미달 시 재작업 비용 등 숨은 비용이 쌓여 결국 초기 예산을 크게 웃도는 사례가 보고됩니다. 이런 숨은 비용의 상당 부분이 바로 '기준 없이 시작해 막판에 다투는' 과정에서 발생합니다. 검수 기준과 변경관리 절차는 그 비용을 앞단에서 차단하는 가장 저렴한 보험입니다.

마무리: 분쟁은 끝이 아니라 시작에서 막습니다

막판 분쟁은 마지막에 터지지만, 원인은 거의 항상 계약·킥오프 단계에 있습니다. 검수 기준을 정량화하고 변경을 서면으로 못박는 일은 개발사를 압박하는 갑질이 아니라, 발주사와 개발사가 같은 그림을 보고 출발하도록 맞추는 작업입니다. 좋은 파트너일수록 이 기준을 함께 세우는 데 적극적입니다.

FIRSTPIP은 프로젝트를 시작하기 전에 검수 기준과 변경관리 절차를 발주사와 함께 명문화하는 것을 기본 원칙으로 삼습니다. 외주 개발을 앞두고 '무엇을 받게 되는지'를 분명히 하고 싶으시다면, 킥오프 체크리스트부터 함께 점검해 보시길 권합니다.