외주 계약서, 어떤 조항이 빠지면 나중에 문제될까요 | 체크리스트
개발외주계약서에 빠지기 쉬운 조항 7가지를 정리했어요. 저작권 귀속, 검수 기준, 하자보수 기간, 대금 지급 구조까지 계약 전에 확인하면 착수 후 분쟁을 크게 줄일 수 있어요.
같은 견적, 같은 업체를 골라도 계약서에 뭘 적었는지에 따라 프로젝트가 순조롭게 끝날 수도, 잔금을 두고 다투는 걸로 끝날 수도 있어요. 업무 범위·저작권·검수 기준·대금 지급 방식, 이 네 가지만 명확히 해도 대부분의 분쟁은 미리 막을 수 있어요. 저희가 직접 만들고 운영해본 개발사 기준으로 정리했어요.
“견적이랑 일정은 다 확인했는데, 계약서는 그냥 표준 양식대로 사인해도 되겠죠?” 발주자분들이 실제로 자주 하는 말이에요. 결론부터 말씀드리면, 표준 양식이라도 항목 하나하나를 실제 프로젝트에 맞게 채워 넣지 않으면 나중에 문제가 생겨요. 어떤 조항을 특히 꼼꼼히 봐야 하는지 순서대로 짚어볼게요.
1. 계약서 없이 진행하면 왜 위험할까요
구두로 합의한 내용은 프로젝트가 길어질수록 서로 다르게 기억되기 쉬워요. “이 정도는 당연히 포함된 거 아니었나요”라는 말이 나오는 순간, 이미 계약서로 정리했어야 할 부분이에요. 계약서는 일이 잘 풀릴 때보다 문제가 생겼을 때 진가를 발휘하는 문서라서, 착수 전에 시간을 들여 채워두는 게 결국 운영비를 아끼는 길이에요.
2. 업무 범위와 산출물은 어디까지 적어야 할까요
계약서에는 개발 범위·최종 산출물·납기일이 구체적으로 들어가야 해요. “쇼핑몰 개발”처럼 뭉뚱그린 표현보다는 “회원가입·결제·주문관리 포함, 관리자 페이지 별도”처럼 기능 단위로 나눠 적는 게 안전해요. 범위가 흐릿하면 착수 후 “이것도 포함 아니었나요”라는 요청이 계속 들어오고, 그때마다 추가 비용을 협의해야 하는 상황이 반복돼요.
3. 저작권과 소스코드, 누구에게 귀속될까요
용어 하나만 짚고 갈게요. 저작권법상 소프트웨어 저작권은 원칙적으로 실제로 개발한 쪽(외주사)에 귀속돼요. 발주자가 소유권을 가지려면 계약서에 “잔금 완납 시 저작권 일체가 발주자에게 귀속된다”는 조항을 명시해야 해요. 이 문구가 없으면 대금을 다 지불했더라도 소유권 분쟁의 여지가 남아요.
빌드 스크립트, 환경 설정 파일, 데이터베이스 스키마, API 문서, 주석이 포함된 전체 소스코드까지 받는 범위인지도 확인해야 해요. 오픈소스를 사용했다면 라이선스 종류와 버전을 목록으로 받아두는 것도 나중에 다른 개발사로 유지보수를 넘길 때 꼭 필요해요.
4. 검수 기준과 하자보수는 어떻게 나눠야 할까요
검수 기준을 “정상 작동”처럼 애매하게 적으면, 오픈 후 “느리다”, “스펙대로 만들었다”는 주장이 평행선을 달리기 쉬워요. 어떤 기기·환경에서 어떤 기준을 충족해야 검수 완료인지, 검수 기간은 며칠인지까지 구체적으로 적어야 해요.
| 항목 | 자사 실무 기준 예시 | 참고할 공식 기준 |
|---|---|---|
| 검수 기간 | 프로젝트 규모에 따라 5～15영업일 설정 | 별도 법정 기간 없음 — 계약서 명시 없으면 분쟁 소지 |
| 검수 완료 간주 | 기간 내 서면 미통보 시 검수 완료로 간주 | 계약 관행상 통용되나 계약서 문구 필요 |
| 하자보수 기간 | 검수 완료 후 1～3개월 무상 대응 | 별도 법정 기준 없음 — 계약 관행상 범위 |
하자보수는 개발사 과실로 발생한 버그를 무상으로 고쳐주는 기간이고, 유지보수는 별도 계약으로 진행하는 지속적인 관리예요. 이 둘을 같은 걸로 착각하면 “이 정도는 당연히 무상 아니냐”는 오해가 생겨요.
5. 대금 지급, 착수·중도·잔금은 어떻게 나눠야 할까요
운영사 Tip. 저희는 대금을 착수·중도·잔금 세 단계로 나누고, 잔금은 검수 완료 이후로 걸어두는 방식을 권해요. 선불 100%로 진행하면 발주자 입장에서 진행 상황을 확인할 지렛대가 사라지고, 반대로 후불 100%면 개발사 입장에서 리스크가 커져요. 단계별 지급이 양쪽 모두에게 합리적인 균형점이에요.
6. 지연과 분쟁, 어떤 조항으로 대비해야 할까요
계약서에는 지연 시 지체상금 조항과 연락 두절 등 이례적인 상황에 대비한 계약 해지 조건도 넣어야 해요. 흔한 실수는 이 조항을 “관례상 생략”하는 거예요. 실제로 소프트웨어 개발 관련 분쟁에서 결과물 불일치·일정 지연·연락 두절·저작권 분쟁이 반복적으로 나타나는데, 이 조항들이 있었다면 상당수는 협의로 끝날 수 있었던 사안이에요.
7. 운영까지 보면 계약서에서 무엇이 달라질까요
저희는 저작권·소스코드·산출물뿐 아니라, 배포 이후 운영 이관이 가능한 구조인지도 계약 전에 함께 확인해요. 납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각하기 때문이에요. 자체 SaaS 4종을 직접 운영하며 배운 건, 계약서에 운영 단계 조항까지 넣어두면 출시 이후 유지보수 협의가 훨씬 수월해진다는 점이었어요.
계약서 조항을 어디까지 챙겨야 할지 아직 감이 안 잡힌다면, 편하게 물어보고 함께 정리해봐요 →
자주 묻는 질문
표준 계약서 양식을 그대로 써도 괜찮을까요?
양식 자체는 괜찮지만, 업무 범위·검수 기준·대금 지급 일정처럼 프로젝트마다 달라지는 항목은 반드시 실제 내용으로 채워 넣어야 해요. 빈칸을 그대로 두거나 뭉뚱그려 적으면 표준 양식의 의미가 없어져요.
잔금을 다 냈는데도 저작권이 넘어오지 않을 수 있나요?
계약서에 “잔금 완납 시 저작권 귀속” 문구가 없다면 그럴 수 있어요. 저작권법 원칙상 만든 사람에게 귀속되기 때문에, 이전 조건을 계약서에 명시해야 발주자 소유가 확정돼요.
소규모 프로젝트도 이런 조항을 다 넣어야 하나요?
규모가 작을수록 조항이 간단해도 되지만, 저작권 귀속과 검수 기준만큼은 규모와 상관없이 꼭 넣는 걸 권해요. 두 항목이 분쟁의 대부분을 차지하기 때문이에요.
저희는 11년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과 진행한 프로젝트에서도 계약서 조항을 하나씩 함께 맞춰가며 진행했고요.
계약서 검토부터 함께 시작하고 싶다면 프로젝트 상담받기 →에서 이야기 나눠요. 업체를 아직 정하지 못했다면 개발 외주 업체 선택 체크리스트, 견적 방식이 헷갈린다면 MM·시간제·고정가 비교, 실제 계약부터 운영까지의 흐름이 궁금하다면 롯데백화점 푸드홀 실시간 혼잡도 시스템 사례도 참고해보세요.