개발 외주가 실패하는 이유는 대부분 기술력 부족이 아니에요. 계약과 커뮤니케이션의 문제예요. 갑도 을도 서로 "당연히 포함된 줄 알았는데"를 반복하면서 프로젝트가 무너져요.
이 글에서는 개발 외주에서 반복되는 3가지 실패 패턴과, 계약서에서 어떻게 예방할 수 있는지 정리했어요.
갑: "회원가입 기능 만들어주세요" 을: (이메일+비밀번호 로그인 구현) 갑: "카카오 로그인은요? 당연히 포함된 거 아닌가요?" 을: "기획서에 소셜 로그인 언급이 없었는데요..."
기획서(또는 요구사항 정의서)가 모호하면 갑은 "당연히 포함"이라고 생각하고, 을은 "문서에 없으니 별도"라고 생각해요.
핵심은 "무엇을 만들지"가 아니라 **"무엇을 안 만들지"**를 명확하게 정하는 거예요.
프로젝트 완료 후 갑이 "소스코드 전체를 넘겨주세요"라고 요청. 을은 "결과물(서비스)은 납품했지만, 소스코드는 내 자산인데요?"라고 반응.
방법 1 — 소스코드 포함
"납품 범위: 소스코드 전체(Git 저장소 이전 포함). 을이 재사용하는 공통 라이브러리는 사용 라이선스를 부여하되 소유권은 을에게 남는다."
방법 2 — 소스코드 미포함
"납품 범위: 빌드된 실행 파일/배포 패키지. 소스코드는 별도 양도 계약 대상."
방법 3 — 절충안 (가장 흔함)
"소스코드는 대금 완납 시 갑에게 양도한다. 단, 을이 본 프로젝트 이전에 보유한 라이브러리·프레임워크의 소유권은 을에게 남으며, 갑에게 비독점 사용권을 부여한다."
갑: "여기 에러가 나요, 고쳐주세요" 을: "납품 후 3개월이 지났는데요..." 갑: "버그 수정은 당연한 거 아닌가요?"
하자보수(버그 수정)와 유지보수(기능 추가/변경)의 경계가 불명확하면 을이 무한 무료 수정에 빠져요.
| 항목 | 권장 조건 |
|---|---|
| 하자보수 기간 | 납품 후 1~3개월 |
| 하자보수 범위 | 기능명세서 기준 미달 사항에 한정 |
| 유지보수 | 별도 계약. 월 O만원 또는 건당 정산 |
| 대응 시간 | 하자 접수 후 O영업일 내 확인, O영업일 내 수정 |
"하자보수"는 원래 약속한 기능이 안 되는 것, "유지보수"는 새로운 요청이나 환경 변화 대응이에요. 이 구분이 계약서에 없으면 갑은 전부 "하자"라고 주장할 수 있어요.
기능 범위부터 소스코드, 하자보수까지 — 사인봐에 계약서를 넣으면 개발 외주 특화 패턴으로 자동 체크해드려요.