개발 검수, 무엇을 기준으로 완성이라고 승인하는가 — 인수 전에 확인할 6가지

“완료됐습니다”라는 한 줄에서 시작되는 문제

개발 검수는 개발사가 “완료됐습니다”라고 통보한 순간에 시작하는 일이 아닙니다. 그런데 실제로는 그 순간에 처음 시작하는 회사가 대부분입니다.

화면을 열어 봅니다. 로그인이 됩니다. 목록이 보이고 버튼이 눌립니다. 겉으로는 문제가 없습니다. 담당 팀장은 이 화면을 보고 승인 여부를 판단해야 합니다. 그런데 무엇을 기준으로 판단할지가 손에 없습니다. 계약서에는 “상호 협의하여 검수한다”고만 적혀 있습니다. 기획 단계의 요구사항은 메신저와 메일과 회의록에 흩어져 있습니다. 어떤 기능은 빠진 것 같은데, 빠진 것인지 애초에 범위가 아니었는지 확인할 문서가 없습니다.

그래서 대개 이렇게 끝납니다. “일단 오픈하고 수정하죠.” 잔금을 지급합니다. 다음 주에 결제 오류가 나옵니다. 개발사에 연락하면 그건 추가 개발이라는 답이 옵니다. 이 시점에 발주사가 쓸 수 있는 카드는 없습니다. 이미 승인했고, 이미 지급했습니다. 절반 이상의 외주 프로젝트가 납기 후 분쟁으로 끝나는 이유도 대부분 여기서 갈립니다.

이 글의 근거

디비컨설팅은 한국인 PM이 검증된 글로벌 개발팀을 관리하는 방식으로 100건 이상의 프로젝트를 수행했습니다. 협업 중인 글로벌 파트너사는 50개 이상이고, 고객 만족도는 98%입니다.

이 숫자를 먼저 말씀드리는 이유는 하나입니다. 프로젝트가 100건을 넘기면 실패하는 지점이 반복적으로 보입니다. 그리고 그 지점은 대부분 기술이 아닙니다. 개발 검수를 승인할 기준이 계약 시점에 문서로 존재하지 않았다는 것, 그 한 가지입니다.

아래는 그 반복을 정리한 내용입니다.

개발 검수가 실패하는 구조적인 이유

검수 기준이 계약 시점에 없었습니다

검수는 비교 작업입니다. 비교에는 대상이 두 개 필요합니다. 완성된 결과물과, 처음에 합의한 기준입니다. 기준이 없으면 검수는 비교가 아니라 감상이 됩니다. “괜찮아 보이는데요”와 “좀 부족한 것 같은데요” 사이에서 회의가 끝나고, 결론은 목소리가 큰 쪽으로 납니다.

기준은 개발이 끝난 뒤에 만들 수 없습니다. 결과물을 본 다음에 쓰는 기준은 이미 결과물에 맞춰진 기준입니다. 그래서 요구사항 정의서를 어디까지 써야 하는지가 검수의 출발점입니다.

“동작한다”와 “요구사항을 충족한다”를 구분하지 않았습니다

개발사가 시연하는 것은 “동작한다”입니다. 발주사가 확인해야 하는 것은 “요구사항을 충족한다”입니다. 이 둘은 자주 다릅니다.

정산 기능을 예로 들겠습니다. 화면에서 숫자가 나옵니다. 동작합니다. 그런데 부분 환불이 섞인 달의 정산 금액이 맞는지는 화면을 눌러서 알 수 없습니다. 시연은 성공 경로만 보여줍니다. 요구사항 충족 여부는 실패 경로에서 갈립니다.

검수 담당자가 개발 내용을 모릅니다

검수를 맡는 사람은 보통 그 업무를 가장 잘 아는 실무 팀장입니다. 업무는 압니다. 그러나 이 기능이 어떤 데이터를 어디에 어떻게 쌓고 있는지는 모릅니다. 그래서 질문을 만들 수 없습니다. 개발사가 “그건 구조상 그렇게 됩니다”라고 답하면 검증할 방법이 없습니다.

담당자의 잘못이 아닙니다. 발주사 안에 개발 언어로 질문할 수 있는 사람이 없는 상태로 프로젝트를 시작한 결과입니다.

잔금 지급과 검수 승인이 같은 시점에 묶여 있습니다

많은 계약서가 검수 승인일에 잔금을 지급하도록 되어 있습니다. 이 구조에서는 승인하는 순간 협상력이 사라집니다. 승인 이후에 발견된 문제는 전부 추가 요청이 되고, 추가 요청은 대부분 유상입니다. 최종 비용이 견적의 1.5배가 되는 일은 드물지 않습니다. 개발 외주 계약서에서 서명 전에 확인할 조항에 이 지급 구조가 포함되어야 하는 이유입니다.

선택지는 세 개입니다. 차이는 “누가 검수 기준을 쓰는가”입니다

발주 방식을 정할 때 보통 단가를 비교합니다. 그런데 결과를 결정하는 변수는 단가가 아니라, 검수 기준을 누가 쓰는가입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
검수 기준 작성 책임	개발사	발주사 본인	한국 PM
검수 소통 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

해외 개발팀에 직접 발주하는 방식이 기대만큼 싸지 않은 이유가 여기 있습니다. 단가는 내려갑니다. 대신 국내 개발사가 해 주던 일 하나가 발주사로 넘어옵니다. 요구사항을 영어로 명세하고, 검수 항목을 정의하고, 결과물을 항목별로 대조하는 일입니다.

이 일은 발주사의 시니어급 인력만 할 수 있습니다. 그리고 몇 주가 걸립니다. 그 시간은 견적서에 나타나지 않습니다. 회사에서 가장 바쁜 사람의 일정에서 조용히 빠져나갑니다.

핵심은 이것입니다. 검수 기준을 정의하는 일은 없어지지 않습니다. 누군가는 해야 합니다. 국내 개발사에 맡기면 비용으로 지불하고, 해외에 직접 발주하면 발주사 담당자의 시간으로 지불합니다. 한국인 PM을 두는 IT 아웃소싱 방식은 그 일을 맡을 사람을 프로젝트 안에 두는 방식입니다.

디비컨설팅이 검수를 통제하는 방식

진행 방식은 5단계입니다. 각 단계가 검수 관점에서 무엇을 남기는지를 기준으로 설명하겠습니다.

① 상담 및 요구 분석 — 한국인 PM이 발주사와 한국어로 요구사항을 정리하고 문서화합니다. 이 문서가 검수 기준의 원본이 됩니다. 기능 단위로 “무엇이 되면 완료인지”를 이 단계에서 적습니다. 기획서가 없는 상태로 오시는 경우가 많고, 그 상태를 전제로 시작합니다.

② 개발팀 구성 — 정리된 요구사항에 맞춰 2~4주 내에 전담팀을 구성합니다. 팀을 먼저 만들고 요구사항을 거기에 맞추지 않습니다. 순서가 반대가 되면 범위가 팀 사정에 맞춰 휘어집니다.

③ 프로젝트 개발 — 진행 상황을 투명하게 공유합니다. 마지막에 한 번 검수하는 대신, ①에서 만든 문서의 항목이 하나씩 닫히는 것을 확인합니다. 몰아서 하는 검수는 이미 늦은 검수입니다.

④ 테스트 및 배포 — QA를 거친 후 릴리즈합니다. 이 시점의 확인 대상은 화면이 아니라 ①의 문서입니다. QA 전담팀이 없는 개발사를 피해야 하는 이유가 이 단계에서 드러납니다.

⑤ 운영 및 유지보수 — 운영을 이어가고, 인계 시에는 문서와 함께 넘깁니다. 소스코드, API 명세, DB 스키마, 배포 절차가 포함됩니다. 출시 이후의 비용 구조는 앱 유지보수 비용에서 따로 정리했습니다.

발주사가 영어로 소통하는 구간은 없습니다. 요구사항 정의, 일정, 검수는 한국인 PM의 책임입니다.

인수 전에 확인할 6가지

인수 전 개발 검수에서 확인할 항목은 여섯 개입니다. 각 항목 뒤에, 그것이 가능하려면 발주 시점에 무엇이 있어야 했는지를 함께 적었습니다. 대부분은 지금 만들 수 없는 것입니다.

1. 요구사항 정의서 대비 기능 대조표

기능 목록을 받는 것과, 요구사항 정의서의 각 항목에 결과물을 1:1로 붙인 표를 받는 것은 다릅니다. 후자를 요구하십시오. 항목마다 구현 여부, 확인 방법, 확인한 사람이 적혀 있어야 합니다.

이 표는 요구사항 정의서가 있어야 만들 수 있습니다. 문서가 없으면 대조표는 결국 개발사가 만든 기능 목록이 됩니다.

2. 소스코드와 저장소 이관, 그리고 귀속

전체 소스코드와 저장소를 넘겨받으십시오. 소유권이 발주사에 귀속되는지 계약서에서 확인하십시오. 압축 파일 하나가 아니라 커밋 이력이 남은 저장소 단위로 받는 것이 맞습니다. 외부 서비스 계정과 키도 인계 대상입니다.

이 조항은 계약서에 있거나 없습니다. 인수 시점에 새로 협상할 수 없습니다.

3. API 명세 · DB 스키마 · 배포 절차 문서

이 세 가지가 없으면 다음 개발사는 코드를 읽는 데만 몇 주를 씁니다. 배포 절차는 “누가 어떤 명령으로 어디에 올리는지”가 한 문서에 정리되어 있어야 합니다. 특정 담당자의 머릿속에 있는 상태는 인계가 아닙니다. 개발사를 교체해야 하는 상황에서 이 문서의 유무가 이관 비용을 결정합니다.

4. 더미 데이터가 아닌 실사용 데이터 기준 테스트

시연은 대부분 정리된 데이터로 진행됩니다. 실제 데이터는 지저분합니다. 공백이 들어간 이름, 누락된 값, 예상보다 긴 텍스트, 과거 시스템에서 옮겨온 이력이 섞여 있습니다. 이관 데이터나 실제 운영 데이터로 다시 확인하십시오. 여기서 나오는 문제가 오픈 직후 장애의 대부분입니다.

5. 장애와 예외 상황에서의 동작

결제가 중간에 실패했을 때, 외부 API가 응답하지 않을 때, 같은 요청이 두 번 들어왔을 때 무엇이 남는지 확인하십시오. 정상 경로는 대체로 동작합니다. 사고는 예외에서 납니다. 로그가 남는지, 실패한 거래를 나중에 찾을 수 있는지도 함께 보십시오.

6. 잔금 지급 시점과 검수 승인의 분리

검수 승인일과 잔금 지급일을 같은 날로 두지 마십시오. 승인 후 일정 기간의 하자보수 기간을 두고, 그 기간이 지난 뒤에 잔금을 지급하는 구조가 안전합니다. 하자보수의 범위도 문서로 정해 두십시오. “버그는 무상, 신규 기능은 유상”만으로는 부족합니다. 다툼은 그 경계에서 생깁니다.

이것도 계약 조항입니다. 인수 직전에 만들 수 없습니다.

이 방식으로 만든 서비스

• 삼성물산 홈닉 — 주거 플랫폼 앱
• GS건설 엘리시안 리조트 — 리조트 웹·앱 통합
• 하나투어 하나오픈챗 — 여행 상담 채팅
• 직방 호갱노노 — 부동산 데이터 서비스
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
• 가천대학교 학사관리 시스템

공통점은 규모가 아니라 검수 난이도입니다. 대기업과 대학은 내부 승인 절차가 있고, 문서 없이 인수하지 않습니다. 요구사항 정의서와 인계 문서가 처음부터 갖춰져야 통과되는 프로젝트들입니다. 전체 구축 사례는 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다 / 반대로 권하지 않습니다

적합합니다

• 웹·앱·플랫폼을 외주로 만들어야 하지만 내부에 개발 총괄이 없는 경우
• 기획서가 아직 없고, 해결할 문제와 필요한 기능 수준만 정리된 경우
• 국내 개발사 견적이 예산을 넘고, 해외 발주는 관리 부담 때문에 망설이는 경우
• 이전 프로젝트에서 인수 후에 문제가 나왔던 경험이 있는 경우

권하지 않습니다

• 내부에 시니어 개발자와 QA가 이미 있고, 요구사항 정의서와 검수 기준을 직접 쓸 수 있는 조직이라면 굳이 필요하지 않습니다. 이 경우 개발 인력만 확보하는 방식이 더 저렴합니다.
• 며칠 안에 결과물이 필요한 일이라면 맞지 않습니다. 전담팀 구성에 2~4주가 필요합니다.
• 요구사항을 정리할 시간을 전혀 낼 수 없는 상황이라면 시작하지 않는 편이 낫습니다. ① 단계에는 발주사의 시간이 반드시 들어갑니다. 몇 주가 아니라 몇 차례의 회의 수준이지만, 그것도 어렵다면 결과가 좋지 않습니다.

자주 묻는 질문

해외 개발팀이면 의사소통은 어떻게 됩니까?

발주사는 한국인 PM과 한국어로만 소통합니다. 개발팀과 직접 회의하거나 영어로 문서를 쓰는 일은 없습니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 개발팀과의 소통에서 생기는 오해는 PM이 흡수해야 하는 비용이고, 발주사로 넘기지 않습니다.

기획서가 없는데 검수 기준을 정할 수 있습니까?

가능합니다. 그리고 그 상태로 시작하는 경우가 더 많습니다. 첫 상담에 필요한 것은 네 가지입니다. 해결하려는 문제, 주요 사용자, 반드시 있어야 하는 기능 3~5개, 일정과 예산의 범위입니다. 이 네 가지가 있으면 요구사항 정의서를 만들 수 있고, 그 문서가 검수 기준이 됩니다. 기획서를 완성한 뒤에 오시라고 말씀드리지는 않습니다. 그 작업이 사실 가장 어려운 부분입니다.

소스코드 소유권은 어떻게 됩니까?

발주사에 귀속됩니다. 소스코드와 저장소 전체를 인계하고, API 명세, DB 스키마, 배포 절차 문서까지 함께 넘깁니다. 다른 회사로 유지보수를 옮기더라도 문서만으로 이어받을 수 있는 상태로 인계하는 것을 원칙으로 합니다. 이 조건은 계약서에 명시합니다.

팀 규모는 조정할 수 있습니까?

전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택할 수 있습니다. 진행 중에도 조정이 가능합니다. 초기 개발에는 인원을 늘리고 안정화 이후에 줄이는 형태가 일반적입니다.

검수에서 문제가 나오면 어떻게 됩니까?

요구사항 정의서에 있는 항목이 충족되지 않았다면 저희 책임으로 처리합니다. 정의서에 없던 요구라면 범위 변경으로 보고 일정과 비용을 다시 협의합니다. 이 구분이 가능한 이유는 ① 단계에서 만든 문서가 있기 때문입니다. 문서가 없으면 모든 논의가 “원래 그렇게 말했는지”를 다투는 일이 됩니다.

정리

개발 검수는 마지막 단계의 확인 절차처럼 보이지만, 실제로는 발주 시점에 결정되는 일입니다. 검수 기준은 개발이 끝난 뒤에 만들 수 없습니다. 결과물을 보고 쓴 기준은 결과물을 통과시키는 기준이 되기 때문입니다. 그래서 질문은 “어떻게 검수할 것인가”가 아니라 “발주 시점에 검수 기준을 쓸 사람이 우리 회사 안에 있는가”입니다. 있다면 개발 인력만 확보하면 됩니다. 없다면 그 역할을 대신 맡을 한국인 PM이 필요합니다. 단가를 비교하기 전에 이 질문을 먼저 정리하시는 것을 권합니다.