외주 개발을 맡기고 나면 납품일에 "이게 우리가 원한 게 맞나요?" 하는 말이 오가기 쉬워요. 이런 다툼은 대부분 합격 기준이 말로만 오갔기 때문에 생겨요. 아래 기준과 숫자는 모두 회사가 정하는 가상의 내부 기준이에요.

합격 기준은 어느 수준까지 적어 두면 될까요?

"누가 봐도 같은 결론이 나오는 문장"까지 적으면 충분해요. "빠르게 동작해야 한다"가 아니라 "주문 목록 조회 화면이 3초 안에 열린다"처럼 확인 방법이 보이게 쓰는 거예요.

기준 문서에는 이 네 가지만 있어도 큰 도움이 돼요.

  • 검수 대상: 화면, 기능, 설계 문서, 소스코드, 운영 매뉴얼 중 무엇을 받는지
  • 합격 조건: 항목별로 '된다/안 된다'가 갈리는 문장
  • 인수 테스트 방법: 누가, 어떤 환경에서, 어떤 순서로 확인하는지
  • 첫 출시에 꼭 필요한 흐름과 나중으로 미룰 기능의 구분

보완 요청은 어떤 절차로 정해 두나요?

검수 기간, 보완 요청 방식, 재검수 횟수를 미리 합의해 두면 돼요. 이 절차도 계약서에 같이 넣어 두는 게 좋아요.

실무 체크 포인트 보완 요청은 말이나 메신저가 아니라, 항목 번호가 붙은 목록 한 장으로 주고받으세요. 어느 항목이 왜 불합격인지 남아야 다음 확인이 쉬워져요.

가상 상황으로 보면 어떻게 달라지나요?

가상의 A사가 주문 관리 웹 화면을 외주로 맡겼다고 해볼게요. 전제는 이래요. 검수 대상은 화면 10개, 검수 기간은 납품 후 영업일 5일, 보완은 최대 2회까지로 양사가 합의했어요.

납품 후 A사가 화면 10개를 점검해 8개는 합격, 2개는 "검색 결과가 비어 있을 때 안내 문구가 없음"이라는 사유로 불합격 표시를 했어요. 개발사는 이 2개만 고쳐서 다시 제출하고, A사는 그 2개만 재확인해요. 합격 기준이 문장으로 있었기 때문에 8개는 다시 다투지 않아도 돼요.

기준이 없었다면 "전체적으로 마음에 안 든다"는 이야기가 오가며 10개 모두 다시 논의했을 거예요.

오늘 바로 할 일

  1. 진행 중인 외주 건의 검수 대상 목록을 만들고, 항목마다 합격 조건을 한 문장씩 적어 보세요.
  2. 검수 기간·보완 요청 방식·재검수 횟수를 개발사와 문서로 합의하세요.
  3. 보완 요청서 양식(항목 번호, 불합격 사유, 확인 방법)을 한 장 만들어 두세요.