개발 외주 계약서, 서명 전에 반드시 확인할 7가지 조항

개발 외주 계약서를 처음 받아 보면 대부분 금액부터 확인합니다. 총 계약금이 예산 안에 들어오는지, 착수금 비율은 어느 정도인지, 잔금은 언제 나가는지. 숫자에 문제가 없으면 서명합니다.

그런데 실제 분쟁은 거의 그 숫자에서 시작되지 않습니다. 개발이 끝났다고 말하는 개발사와 아직 끝나지 않았다고 말하는 발주사가 같은 계약서를 놓고 정반대로 해석할 때 시작됩니다. 계약서에 “요구사항에 따라 개발한다”는 문장은 분명히 있는데, 그 요구사항이 무엇인지는 계약서 어디에도 정의되어 있지 않기 때문입니다.

디비컨설팅은 삼성물산, GS건설, 하나투어, 직방, LS일렉트릭, 교보생명 등과 100건 이상의 웹·앱·플랫폼 프로젝트를 수행해 왔습니다. 그 과정에서 반복해서 확인한 것이 있습니다. 프로젝트가 무너지는 지점은 대부분 계약서에 적혀 있던 조항이 아니라, 계약서에 비어 있던 칸이었습니다.

이 글은 개발 외주 계약서에 반드시 들어가야 할 7가지 조항과, 그 조항들이 왜 계약서만으로는 지켜지지 않는지를 정리한 것입니다.

금액란은 분쟁을 막지 못합니다

모든 분쟁은 “완료”의 정의에서 시작됩니다

개발사는 기능 목록에 적힌 항목이 동작하면 완료라고 봅니다. 발주사는 그 기능을 실제 업무에서 문제없이 쓸 수 있어야 완료라고 봅니다. 두 입장 모두 계약서 위반이 아닙니다. 계약서가 어느 쪽도 정의하지 않았기 때문입니다.

이 상태에서 일정이 밀리기 시작하면 협상 카드는 하나뿐입니다. 잔금입니다. 발주사는 잔금을 붙잡고, 개발사는 인력을 뺍니다. 프로젝트는 그때부터 완성이 아니라 종료를 향해 갑니다.

계약서가 대체로 침묵하는 네 가지 질문

표준 계약서 양식을 그대로 쓴 경우, 다음 네 가지는 거의 비어 있습니다.

• 무엇을 충족해야 검수가 통과되는가
• 요구사항이 바뀌었을 때 추가 비용은 어떤 기준으로 산정되는가
• 납품물에 코드 외에 무엇이 포함되는가
• 출시 후 발견된 문제는 하자인가 새 작업인가

네 가지 모두 개발이 시작되기 전에는 사소해 보이고, 끝날 무렵에는 프로젝트 전체를 좌우합니다. IT 외주 프로젝트가 납기 후 분쟁으로 끝나는 구조를 따로 정리해 둔 글도 함께 참고하시면 좋습니다.

서명 전에 확인할 7가지 조항

1. 검수 기준 — 무엇을 충족해야 완료인가

가장 중요한 조항입니다. “발주사의 검수 후 인수한다”는 문장만으로는 부족합니다. 검수 항목이 문서로 첨부되어야 하고, 그 문서가 계약서의 일부라는 문장이 있어야 합니다.

검수 기간도 명시해야 합니다. 기간이 없으면 발주사는 무한정 검수할 수 있고, 개발사는 무한정 대기해야 합니다. 반대로 “납품 후 7일 내 이의가 없으면 자동 인수” 같은 조항이 들어 있으면, 내부 검토가 늦어지는 것만으로 검수권을 잃습니다. 조항을 읽을 때 이 자동 인수 문구가 있는지 반드시 확인하십시오.

2. 요구사항 변경 절차 — 추가 비용이 생기는 기준

개발 중 요구사항은 바뀝니다. 문제는 바뀌는 것이 아니라, 무엇이 “변경”이고 무엇이 “원래 포함”인지 판단할 기준이 없다는 것입니다.

기준선이 되는 요구사항 정의서가 계약서에 첨부되어 있어야 이 판단이 가능해집니다. 정의서 없이 시작한 프로젝트에서는 모든 요청이 협상 대상이 되고, 그 협상에 발주사 담당자의 시간이 통째로 들어갑니다.

변경 절차 조항에는 최소한 이 세 가지가 있어야 합니다. 변경 요청을 누가 접수하는가, 공수 산정 결과를 며칠 안에 회신하는가, 발주사가 승인하기 전에는 착수하지 않는다는 확인입니다.

3. 산출물 목록 — 코드 외에 무엇을 받는가

코드만 받으면 다음 개발사가 그 코드를 해석하는 데 다시 비용이 듭니다. 계약서 산출물 목록에 다음 항목이 들어가 있는지 확인하십시오.

• API 명세서
• 데이터베이스 스키마 및 ERD
• 서버 구성도와 배포 절차 문서
• 외부 연동 서비스 계정과 키의 이관 목록
• 관리자 기능 사용 안내

특히 마지막 두 항목이 자주 빠집니다. 결제사, 문자 발송, 지도, 푸시 같은 외부 서비스가 개발사 계정으로 붙어 있으면, 계약이 끝나도 서비스의 일부는 개발사 손에 남습니다.

4. 소스코드와 지식재산권 귀속

“소스코드는 발주사에 귀속된다”는 한 문장이 있는지 확인하십시오. 없다면 넣어야 합니다. 대금을 완납해도 저작권이 자동으로 넘어오지는 않습니다.

개발사가 자체 보유한 공통 모듈이나 프레임워크를 쓰는 경우가 있는데, 그 부분은 소유권이 아니라 사용권으로 정리되는 것이 일반적입니다. 그렇다면 사용 범위와 기간에 제한이 있는지, 이후 다른 개발사가 유지보수할 때 문제가 되지 않는지를 문서로 확인해야 합니다.

디비컨설팅의 계약 기준은 단순합니다. 소스코드는 발주사 귀속이며, API 명세·DB 스키마·배포 절차 문서까지 함께 인계합니다. 다음 파트너가 저희가 아니어도 이어받을 수 있는 상태로 넘기는 것이 원칙입니다.

5. 하자보수 범위와 기간

하자보수 기간만 적고 범위를 적지 않는 계약서가 많습니다. 그러면 출시 후 발견된 모든 문제가 “이건 하자입니다” 대 “이건 추가 개발입니다”의 대립으로 갑니다.

범위를 가르는 기준은 검수 기준 문서입니다. 검수 항목에 있었는데 동작하지 않으면 하자, 검수 항목에 없던 것을 새로 요구하면 추가 개발입니다. 1번 조항이 5번 조항을 지탱하는 구조입니다.

또 하나, 하자보수와 운영 유지보수는 다릅니다. OS 업데이트 대응이나 외부 라이브러리 정책 변경 대응은 하자가 아니라 별도 계약 영역입니다. 이 부분은 앱 유지보수 비용이 출시 후에 발생하는 구조에서 더 자세히 다뤘습니다.

6. 투입 인력의 등급과 교체 조건

견적서에는 시니어 개발자 기준 단가가 적혀 있는데 실제로는 다른 인력이 들어오는 경우가 있습니다. 계약서에 투입 인력의 등급과 인원, 투입 기간이 명시되어 있어야 확인이 가능합니다.

교체 조건도 필요합니다. 개발사 사정으로 인력이 바뀔 때 동급 이상으로 대체한다는 조항, 그리고 인수인계 기간을 별도 일정으로 잡는다는 조항입니다. 인력 교체 자체보다 인수인계 없는 교체가 일정을 무너뜨립니다.

7. 지연 책임 — 누구의 지연인가

지연 배상 조항은 대부분 개발사의 지연만 다룹니다. 그런데 실제 프로젝트에서 일정이 밀리는 흔한 원인 중 하나는 발주사 측의 회신 지연입니다. 디자인 확정, 콘텐츠 전달, 검수 회신이 늦어지면 개발도 함께 멈춥니다.

양방향으로 쓰인 조항이 결과적으로 발주사에게 유리합니다. 발주사 귀책 사유가 정의되어 있으면, 개발사가 “고객사 때문에 늦었다”고 사후에 주장할 여지가 사라지기 때문입니다. 책임 소재가 애매한 계약서일수록 분쟁에서 불리한 쪽은 문서를 덜 남긴 쪽입니다.

그런데 이 조항들은 계약서만으로 지켜지지 않습니다

7가지를 모두 넣어도 한 가지 문제가 남습니다. 검수 기준과 요구사항 정의서를 누가 쓰느냐입니다.

이 문서는 발주사의 업무를 이해하면서 동시에 개발 공수를 판단할 수 있는 사람만 쓸 수 있습니다. 그런 사람이 조직 안에 없으면, 계약서의 1번과 2번 조항은 서명 시점에 이미 빈 껍데기입니다. 조항은 있는데 그 조항이 참조하는 문서가 없는 상태가 되기 때문입니다.

그래서 한국 기업이 개발 외주에서 실제로 마주하는 선택지는 이렇게 정리됩니다.

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

해외 개발사에 직접 발주하면 단가는 확실히 내려갑니다. 다만 계약서의 핵심 조항을 지탱하는 문서를 발주사가 직접, 영어로, 개발 공수까지 판단해 가며 써야 합니다. 사내에 개발 조직이 없는 회사에게 이 방식이 기대만큼 저렴해지지 않는 이유가 여기에 있습니다. 절감한 단가가 담당자의 시간과 재작업으로 돌아옵니다.

단가 차이가 총비용 차이로 이어지지 않는 구조는 IT 외주개발 비용이 견적을 넘어서는 지점에서 항목별로 정리해 두었습니다.

디비컨설팅이 계약 이전 단계에서 하는 일

IT 아웃소싱 프로젝트는 다음 5단계로 진행됩니다. 앞의 두 단계가 계약서의 조항을 실제로 작동하게 만드는 부분입니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요구사항을 한국어 문서로 정리합니다. 검수 기준과 변경 판단의 기준선이 여기서 만들어집니다. 이후 재작업의 대부분이 이 단계에서 제거됩니다.
2. 개발팀 구성 — 프로젝트에 맞춘 전담팀을 2~4주 안에 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 발주사 담당자가 하루를 조율에 쓰지 않는 것이 목표입니다.
4. 테스트 및 배포 — QA 프로세스를 거쳐 릴리스합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기 운영을 지원합니다.

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 계약서에 적힌 조항을 지탱하는 문서를 발주사가 직접 쓰지 않아도 되는 구조입니다.

이 구조로 만든 것들

• 삼성물산 — 홈닉, 주거 플랫폼 앱
• GS건설 — 엘리시안 리조트 웹·앱 통합 구축
• 하나투어 — 하나오픈챗, 여행 상담 채팅 서비스
• 직방 — 호갱노노, 부동산 데이터 서비스
• LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
• 교보생명 — 사내벤처 글펍, 커뮤니티 서비스
• 가천대학교 — 학사관리 시스템
• 센터필드 · 센트로폴리스 · 그랑서울 — 프라임 오피스 빌딩 관리 시스템
• 와디즈 — 글로벌 플랫폼

100건 이상의 프로젝트, 50개 이상의 글로벌 파트너사, 고객 만족도 98%. 다른 사례는 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 사내에 개발 조직이 없거나, 있어도 신규 구축을 맡길 여력이 없는 기업
• 이전 외주에서 검수 단계까지 갔다가 분쟁으로 끝난 경험이 있는 기업
• 국내 견적이 예산을 넘는데, 해외 직접 발주는 관리할 사람이 없는 기업
• 웹 개발 외주 또는 앱 개발 외주를 3개월 이상 규모로 검토 중인 기업

반대로 권하지 않습니다

• 사내에 기획자와 개발 리드가 이미 있는 기업. 요구사항 정의를 직접 하실 수 있다면 해외 인력을 직접 계약하는 편이 더 쌉니다. 저희 구조의 가치가 그 부분에 있기 때문입니다.
• 2~3주 안에 결과물이 필요한 프로젝트. 전담팀 구성에만 2~4주가 걸립니다.
• 단순 홈페이지 제작. 페이지 몇 개의 브로슈어형 사이트라면 저희 구조는 과합니다. 판단 기준은 홈페이지 제작 비용이 업체마다 갈리는 이유에 정리해 두었습니다.
• 가장 낮은 견적이 기준인 발주. 검수 기준과 문서 인계를 계약에 넣으면 견적은 올라갑니다.

자주 묻는 질문

소스코드 소유권은 어떻게 되나요?

발주사 귀속입니다. API 명세서, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 이후 유지보수를 다른 회사가 맡아도 이어받을 수 있는 상태로 넘기는 것을 기준으로 삼습니다.

해외 개발팀인데 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수가 모두 PM의 책임 범위입니다. 개발팀과의 영어 소통은 PM이 담당하며, 발주사가 부담하지 않습니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 알려주시면 개략 견적을 드립니다. 상세 요구사항 정의서는 계약 전 상담 단계에서 함께 만듭니다.

비용은 어떤 기준으로 산정되나요?

등급별 단가에 투입 기간을 곱하는 방식입니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어느 항목에서 비용이 발생하는지 확인하실 수 있습니다.

진행 중에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. 조정 절차는 계약서의 변경 조항에 반영합니다.

정리

개발 외주 계약서에서 분쟁을 가르는 것은 금액란이 아니라 검수 기준, 변경 절차, 산출물 목록, 소스코드 귀속, 하자보수 범위, 인력 교체 조건, 지연 책임 일곱 칸입니다. 그리고 이 조항들은 그것이 참조하는 문서 — 요구사항 정의서와 검수 기준서 — 를 누군가 실제로 써야만 작동합니다. 그 문서를 발주사가 직접 쓸 수 없다면, 계약서를 아무리 잘 써도 서명 시점에 이미 절반은 비어 있는 셈입니다. 외주 파트너를 고를 때 인원수보다 먼저 봐야 할 것이 그 문서를 누가 책임지는가인 이유입니다.