소프트웨어 개발 계약서 양식 — 조항 16개, 왜 있고 빠지면 무엇이 터지나

공정거래위원회 표준하도급계약서, 각 부처가 배포하는 소프트웨어 개발 표준계약서가 있습니다. 무료로 받을 수 있고 출발점으로 나쁘지 않습니다. 다만 그 양식들은 대체로 발주처 사업장에 인력을 투입하는 대규모 SI 도급을 전제로 씁니다. 소규모 원격 개발에 그대로 가져오면 두 가지 문제가 생깁니다.

쓸모없는 조항이 남습니다. 상주 인력의 근태, 하도급 승인 절차, 산업안전 조항 같은 것들이 그렇습니다. 반대로 정작 필요한 조항이 없습니다. 수집 대상 사이트가 개편됐을 때, 연동하던 외부 API가 스펙을 바꿨을 때, 결제 대행사가 장애를 냈을 때 — 요즘 프로젝트가 실제로 깨지는 지점을 다루는 조항이 표준 양식에는 거의 없습니다.

아래는 저희가 실제로 쓰는 계약서의 조항 구성입니다. 견적이 확정되면 이 16개 조항으로 계약서가 만들어집니다. 특별할 것 없는 구성이지만, 하나하나가 실제로 터졌던 지점을 막으려고 들어가 있습니다.

이 목록 자체는 발주 전 관점의 [외주 계약서 필수 조항 체크리스트](/guide/outsourcing-contract-checklist)와 겹칩니다. 그쪽은 "계약 전에 무엇을 확인할까"이고, 이 글은 "그 조항이 실제 문장으로 어떻게 쓰여 있어야 하는가"입니다.

1. 저작권이 넘어오는 시점 — 납품일인가, 잔금 완납일인가

발주자는 납품과 동시에 이전되기를 원합니다. 수급자는 완납 시점을 원합니다. 소스코드를 넘긴 뒤에는 대금을 회수할 지렛대가 사라지기 때문입니다. 저희 조항은 완납 시 이전입니다. 발주자 입장에서 이게 불편하다면, 방향은 "이전 시점을 앞당겨 달라"가 아니라 "잔금 비율을 낮추고 검수 기준을 구체화해 완납을 빨리 오게 하는 것"입니다. 검수 기준이 명확하면 완납은 검수 후 며칠 안에 옵니다. 관련해서 [소스코드 소유권 가이드](/guide/source-code-ownership)에 이전 범위(신규 제작분과 기존 보유 모듈의 구분)를 따로 정리해뒀습니다.

2. 하자와 추가 기능의 경계

"하자보수 기간이니까 무상 아닌가요"에서 시작되는 다툼입니다. 하자는 합의된 요구사항대로 동작하지 않는 것입니다. 그 정의를 계약서에 써도, 정작 "합의된 요구사항"이 문서로 존재하지 않으면 문장 전체가 무력해집니다. 요구사항 정의서를 계약의 별첨으로 붙이는 이유가 이것입니다. 요구사항에 없던 화면을 추가해 달라는 것, 발주자 쪽에서 코드를 고쳐서 생긴 문제, 브라우저나 OS를 바꿔서 생긴 문제는 하자가 아니라 유상 작업입니다. 이 경계선을 계약서에 열거해 두면 나중에 감정 소모가 줄어듭니다.

3. 지연의 귀책 — 자료를 안 주고 기다린 2주는 누구 책임인가

개발이 멈추는 흔한 이유는 개발사의 게으름이 아니라 발주자 쪽 자료·계정·의사결정 대기입니다. 그런데 계약서에 협조 의무가 없으면, 달력상의 지연은 전부 개발사 몫으로 기록됩니다. 저희 계약서는 확인 요청에 3영업일 내 회신을 요청하고, 회신이 없으면 제시한 안대로 진행하는 데 동의한 것으로 봅니다. 발주자에게 불리한 조항처럼 보이지만, 실은 발주자에게도 "무엇을 언제까지 줘야 하는가"의 기준이 생깁니다. 기준이 없는 쪽이 더 자주 지연됩니다.

4. 상주 요구

계약서에는 없었는데 진행 중에 "다음 주부터 사무실로 나와주실 수 있나요"가 나옵니다. 원격 수행이 전제라면 그 문장을 범위 조항에 명시해야 합니다. 발주자 입장에서 상주가 정말 필요한 프로젝트라면, 그건 도급이 아니라 인력 상주 계약이고 단가 체계 자체가 다릅니다. 도급 단가로 상주를 요구하는 것은 무상 인력 요청과 같습니다.

5. 요구사항이 바뀔 때의 추가 대금

"이 정도는 서비스로 해주시죠"가 반복되면 프로젝트는 조용히 적자로 갑니다. 저희 조항은 서면 합의와 추가 대금이 없는 변경은 수행 의무에 포함되지 않는다고 씁니다. 다만 발주자 쪽에서도 매번 협상하는 건 피곤합니다. 계약 시점에 변경 단가 산정 방식(시간당인지 기능당인지)을 미리 정해두면 변경이 생길 때마다 견적서를 새로 뜨지 않아도 됩니다. 산정 방식은 [요구사항 변경 시 추가 비용 산정](/guide/change-request-pricing)에서 다룹니다.

계약서를 처음 받아본 발주자가 걸리는 조항은 대체로 정해져 있습니다. 숨길 것 없이 이유를 씁니다.

손해배상 한도를 수령한 대금 범위로 제한 — 300만 원을 받고 수억 원의 사업 손실을 배상하는 구조라면, 그 일을 받을 수 있는 개발사는 없습니다. 한도가 없는 계약은 결국 견적을 올리거나 계약 자체를 성사시키지 못합니다. 다만 고의나 중대한 과실로 인한 손해는 이 제한을 받지 않습니다. 그 예외가 빠져 있는 계약서라면 그건 문제가 맞습니다.

외부 요인 면책 — 수집하던 사이트가 구조를 바꾸는 것, 연동하던 API가 정책을 바꾸는 것, 결제사가 장애를 내는 것은 개발사가 통제할 수 없습니다. 대신 그로 인한 수정은 유상 작업입니다. 발주자가 확인할 지점은 면책 자체가 아니라 "그때 얼마에 고쳐주는가"입니다. 그걸 계약 시점에 물어보세요.

검수 무응답 시 완료 간주 — 검수 기간에 답이 없으면 검수가 완료된 것으로 봅니다. 잔금이 무기한 미뤄지는 것을 막는 조항입니다. 발주자 입장에서 7영업일이 짧다면, 협상할 지점은 "간주 조항을 빼달라"가 아니라 "기간을 10영업일로 늘려달라"입니다. 검수 항목은 [검수 체크리스트](/guide/acceptance-test-checklist)를 계약 별첨으로 붙이면 대부분 해결됩니다.

이 조항들이 과하다고 느껴지면 협상하면 됩니다. 다만 리스크는 공짜가 아닙니다. 무제한 책임을 요구하면 견적이 올라가거나 거절당합니다. 그 교환 관계를 알고 협상하는 발주자가 결과적으로 좋은 조건을 얻습니다.

조항을 아무리 잘 써도, 아래 네 가지가 별첨으로 붙어 있지 않으면 조항 절반이 작동하지 않습니다.

요구사항 정의서 / 기능 목록 — 범위 조항, 검수 조항, 하자보수 조항 셋 다 이 문서를 근거로 판단합니다. 이게 없으면 세 조항이 동시에 무력해집니다. 완벽한 명세서일 필요는 없고, 화면별로 한 줄씩 적은 목록이면 충분합니다.

검수 기준 — 무엇이 되면 "완성"인지. 기능 목록에 통과 기준을 한 줄씩 붙이는 것으로 시작하면 됩니다.

결제 일정 — 착수·중도·잔금의 비율과 각 지급의 조건(무엇이 확인되면 지급되는지). 마일스톤 구조는 [단계별 지급 구조](/guide/payment-milestone-structure)를 참고하세요.

산출물 목록 — 소스코드, DB 스키마, 배포 가이드, 서버·도메인 계정. 특히 클라우드·도메인 계정이 발주사 소유인지가 나중에 업체를 바꿀 때 결정적입니다.

금액대별로 어느 수준까지 문서를 갖출지는 [소프트웨어 외주 개발 단가표](/guide/software-outsourcing-price-table)의 예산 구간과 함께 보면 감이 잡힙니다.

전자문서 및 전자거래 기본법과 전자서명법에 따라 전자적 방법의 서명은 서면 서명과 동일한 효력을 가집니다. 계약서 본문에 그 취지의 문장을 한 줄 넣어두면 다툼의 여지가 줄어듭니다. 프린트해서 도장 찍고 스캔해서 이메일로 보내는 절차는 실무적으로 필요하지 않습니다.

프리시에서는 견적이 확정되면 위 16개 조항으로 계약서가 자동 생성되고, 양측이 전자서명으로 체결합니다. 서명 시점의 계약서 전문이 그대로 저장되므로 나중에 "그때 그 조항이 뭐였더라"가 생기지 않습니다.

마지막으로 정직하게 덧붙입니다. 이 글은 실무에서 반복해서 부딪힌 지점을 정리한 것이고, 변호사의 계약서 검토를 대체하지 않습니다. 계약 규모가 크거나 지식재산권·개인정보 처리가 얽혀 있다면 검토를 받으세요. 실제 분쟁이 벌어진 뒤에는 이 글이 아니라 계약서 문장만 남습니다.