외주 개발 프로젝트의 마지막 한 발자국 — "다 됐어요, 잔금 입금해 주세요"라는 메시지를 받은 순간이에요. 잔금 직전 검수 단계에서 발주자는 대체로 양극단으로 갈려요. 한 쪽은 "어차피 동작하니까 그냥 사인하자"고 잔금을 보냈다가 한 달 뒤 운영 단계에서 결정적 결함이 터지는 경우, 다른 쪽은 "뭔가 이상한데 뭘 봐야 할지 모르겠다"며 검수를 무한히 미루다가 개발사와 신뢰가 깨지는 경우예요. 무비판적 승인과 무기한 지연 사이에 합의된 검수 기준이라는 중간 지대가 없으면 어느 쪽으로든 미끄러지게 돼 있어요.
분쟁은 개발이 한창일 때보다 검수와 잔금 정산 국면에서 터지는 경우가 많아요. 개발 중에는 "아직 만드는 중"이라는 말로 판단을 미룰 수 있지만 잔금은 미룰 수 없는 결정이라, 그동안 덮어 둔 인식 차이가 한꺼번에 드러나거든요. 이번 가이드에선 잔금을 안전하게 정산하면서 양쪽 모두 깔끔하게 끝낼 수 있는 6단계 승인 프로세스를 정리해 볼게요.
이 셋을 헷갈리면 분쟁이 시작돼요. 정리하면 이래요.
즉 순서는 QA → 검수 → 사인오프 → 인수인계 → 하자보수 기간이에요. 검수는 "받아도 되는가"를 결정하는 게이트고, 인수인계는 "받은 걸 우리 운영에 옮기는" 작업이에요.
가장 큰 실수가 검수 직전에야 "뭘 봐야 하지?"를 고민하는 거예요. 계약서 부속서에 "기능 요구사항 N개 통과 기준 + 비기능 요구사항(성능·보안·접근성) 통과 기준 + 검수 대상 환경 + 검수 기간"을 미리 명시해 두세요. 2026년에는 여기에 "AI 모델 응답 시간 P95"나 "토큰 사용량 한도" 같은 항목도 들어가요.
"개발사 서버에서 보여 드릴게요"는 위험해요. 환경 변수, DB 권한, 외부 서비스 키가 개발사 환경에만 박혀 있으면 검수는 통과해도 운영에 옮기는 순간 다 깨져요. 반드시 발주자 명의의 호스팅·DB·결제 키로 검수 환경을 구성하세요. 호스팅·데이터베이스·PG 계정을 발주자 명의로 미리 만들어 두는 게 출발점이에요.
"메일로 결과물 링크 보내드릴게요"는 분쟁의 시작이에요. 반드시 화면 공유로 주요 사용자 시나리오 7~10개를 끝까지 함께 실행하세요. 회원가입 → 결제 → 환불 → 관리자 통계 → 데이터 export 같은 흐름을 라이브로 보면서 합격/조건부 합격/불합격을 표 한 장에 기록해야 해요.
"버그가 있다"는 표현으로 끝내지 마세요. 결함을 세 등급으로 나누세요.
이 분류를 미리 합의해 둬야 "이건 그냥 사소한 거잖아요" vs "이건 출시를 막는 거예요" 논쟁이 안 생겨요.
한국 외주 시장 표준은 사인오프 후 30~90일 하자보수 기간(워런티)이에요. 이 기간엔 동일 범위 내 결함이 발견되면 무상 수정해야 해요. 사인오프 문서에 "워런티 시작일·종료일·대상 범위·연락 채널·SLA(예: 치명 결함은 24시간 내 응답)"를 적어 두지 않으면, 나중에 하자가 생겼을 때 그 수정이 무상인지 유상인지부터 다투게 돼요. 특히 "대상 범위"가 비어 있으면 개발사는 "그건 신규 요구사항"이라 하고 발주자는 "원래 되어야 하는 기능"이라고 해서, 같은 결함을 놓고 서로 다른 계약을 읽게 돼요. 다투는 동안 수정 작업 자체가 멈추고, 멈춰 있는 기간은 그대로 서비스 손실로 돌아와요.
사인오프가 떨어졌는데 잔금이 안 들어오면 개발사가 인수인계를 미뤄요. 반대로 검수 안 끝났는데 잔금부터 보내면 협상력이 사라져요. 표준은 사인오프 다음 영업일 ~ 5영업일 이내 잔금 지급, 인수인계 완료 시점에 보증금/유보금 반환 구조예요. 4월 28일에 다룬 7단계 마일스톤 결제 구조와 짝을 맞춰 설계하세요.
가장 흔한 형태는 검수를 "베타 사용자 몇 명이 써 봤는데 큰 문제 없네요"로 끝내는 거예요. 소수의 베타 사용자가 불편을 못 느꼈다는 사실은 계약서에 적힌 요구사항이 충족됐다는 증거가 아니에요. 체험 소감은 만족도 신호일 뿐이고, 검수는 "합의된 기준을 하나씩 대조해 통과 여부를 기록하는 절차"예요. 소감을 검수 통과 근거로 삼으면 무엇을 확인했고 무엇을 확인하지 않았는지가 문서에 남지 않아요.
이 구멍이 가장 잘 드러나는 곳이 정기결제예요. 구독 결제는 카드 유효기간 만료, 한도 초과, 발급사의 일시적 승인 거절처럼 실패가 상시 발생하는 것을 전제로 설계해야 하는 영역이에요. webhook 재시도와 실패 복구 로직이 없으면 승인 실패가 조용히 누적되고, 결제 누락은 매출 그래프가 꺾이거나 사용자가 이탈하고 나서야 발견돼요. 검수 시나리오에 정상 결제만 있고 실패·재시도·복구 흐름이 없으면 이런 결함은 검수를 그대로 통과해요. 사인오프 후에 발견되면 이번엔 워런티 범위 다툼이 시작되고요.
같은 구멍이 서비스 유형마다 다른 얼굴로 나타나요.
검수 시나리오에 "정상 흐름"만 넣고 "장애 복구 흐름"을 빼는 게 가장 흔한 함정이에요. 시나리오 목록을 만들 때 각 흐름마다 "이게 실패하면 무엇이 어떻게 복구되나"를 한 줄씩 붙여 두면, 검수 회의에서 빠뜨릴 자리가 사라져요.
좋은 개발사를 만나는 것보다 "좋게 끝내는 것"이 어려워요. 검수와 사인오프 단계에서 양쪽이 깔끔하게 합의하고 끝내야 다음 프로젝트, 다음 확장 단계에서도 같이 일할 수 있어요. 포텐랩은 97% 수행완수율을 유지하고 있는데, 그 비결은 화려한 출시가 아니라 이 마지막 6단계를 매번 똑같이 반복하는 것이에요. Notion 기반 투명한 검수 보드, 시나리오 기반 라이브 검수 회의, 명문화된 워런티 SLA — 이 세 가지가 분쟁 없이 잔금을 정산하는 표준이에요.
외주 프로젝트의 마지막 한 발자국이 불안하다면 포텐랩 상담에서 검수 체크리스트 템플릿을 받아 보세요. 무료 상담 한 시간이면 잔금 정산 전에 짚어야 할 모든 항목을 함께 정리해 드려요.
"좋은 시작은 좋은 계약이고, 좋은 끝은 좋은 검수예요. 둘 다 문서로 남길 때 다음 프로젝트가 가능해요." — 검수와 잔금 정산을 함께 다루는 실무의 기본 원칙