외주 개발 계약서에서 확인해야 할 핵심 조항

외주 개발 계약서에서 확인해야 할 핵심 조항

외주 개발을 맡길 때 계약서는 단순히 금액과 기간을 적는 문서가 아닙니다. 계약서는 프로젝트가 어떤 범위로 진행되고, 언제 비용을 지급하며, 결과물의 권리는 누구에게 있고, 문제가 생겼을 때 어떻게 처리할지를 정하는 기준입니다.

특히 앱이나 웹서비스 개발은 진행 중에 요구사항이 바뀌거나, 기능 해석이 달라지거나, 검수 단계에서 의견 차이가 생기는 경우가 많습니다. 계약서가 명확하지 않으면 이런 상황이 모두 분쟁으로 이어질 수 있습니다.

외주 개발 계약서에서 중요한 것은 어려운 법률 용어를 많이 넣는 것이 아닙니다. 실제 프로젝트에서 문제가 생기기 쉬운 지점을 미리 정리하고, 클라이언트와 개발사가 같은 기준으로 이해할 수 있게 만드는 것입니다.

이번 글에서는 외주 개발 계약서에서 반드시 확인해야 할 핵심 조항을 실무 기준으로 정리해보겠습니다.

1. 개발 범위 조항

외주 개발 계약서에서 가장 먼저 확인해야 할 것은 개발 범위입니다. 계약서에 “앱 개발”, “웹사이트 개발”, “관리자 개발”처럼 큰 표현만 적혀 있으면 나중에 해석 차이가 생길 수 있습니다.

개발 범위에는 최소한 아래 내용이 함께 정리되어야 합니다.

• 개발 대상이 앱인지, 웹인지, 관리자 페이지인지

• 사용자 화면에 포함되는 주요 기능

• 관리자 페이지에 포함되는 주요 기능

• 회원가입, 로그인, 결제, 알림, 파일 업로드 등 핵심 기능 포함 여부

• 외부 API 또는 외부 서비스 연동 여부

• PC, 모바일, 반응형 대응 범위

• 기획, 디자인, 개발, 테스트 중 어디까지 포함되는지

계약서 본문에 모든 기능을 자세히 적기 어렵다면, 별도의 요구사항 문서나 견적서를 첨부 문서로 연결하는 방식도 사용할 수 있습니다. 중요한 것은 계약서와 실제 개발 범위가 따로 놀지 않게 만드는 것입니다.

개발 범위가 명확해야 나중에 어떤 요청이 계약 범위 안의 수정인지, 어떤 요청이 추가 개발인지 판단할 수 있습니다.

2. 제외 범위 조항

포함 범위만큼 중요한 것이 제외 범위입니다. 외주 개발 분쟁은 “무엇을 하기로 했는가”보다 “무엇이 포함되지 않았는가”에서 더 자주 발생합니다.

예를 들어 클라이언트는 앱스토어 등록, 콘텐츠 입력, 서버 비용, 문자 발송 비용까지 당연히 포함된다고 생각할 수 있습니다. 하지만 개발사는 이를 별도 비용이나 클라이언트 부담으로 보고 있을 수 있습니다.

계약서나 첨부 문서에서 아래 항목의 포함 여부를 확인하는 것이 좋습니다.

• 서버, 도메인, 스토리지 등 인프라 비용

• 문자, 이메일, 알림톡, 푸시 발송 비용

• PG 가입, 심사, 계약 대응

• 앱스토어 및 구글플레이 등록 대행

• 운영 콘텐츠 입력

• 데이터 이전

• 운영 매뉴얼 작성

• 런칭 후 기능 개선

제외 범위가 명확하게 적혀 있으면 오히려 좋은 계약서입니다. 나중에 추가 비용이 발생할 수 있는 지점을 미리 알고 협의할 수 있기 때문입니다.

3. 대금 지급 조건

대금 지급 조건은 계약서에서 매우 중요한 항목입니다. 총액뿐 아니라 언제, 어떤 기준으로 지급되는지 확인해야 합니다.

외주 개발에서는 보통 아래와 같은 방식이 사용됩니다.

• 계약금, 중도금, 잔금으로 나누어 지급

• 단계별 산출물 제출 후 지급

• 월 단위 투입 인력 기준으로 지급

• 검수 완료 후 잔금 지급

여기서 중요한 것은 지급 시점과 산출물 기준이 연결되어 있어야 한다는 점입니다. 예를 들어 “중도금은 개발 50% 완료 시 지급”이라고만 적혀 있으면 50% 완료를 어떻게 판단할지 애매할 수 있습니다.

가능하면 아래처럼 구체적으로 정리하는 것이 좋습니다.

• 계약 체결 시 계약금 지급

• 기획 및 화면 설계 완료 후 중도금 지급

• 주요 기능 개발 완료 후 중도금 지급

• 검수 완료 및 배포 후 잔금 지급

또한 세금계산서 발행 시점, 부가세 포함 여부, 지급 지연 시 처리 기준도 확인해야 합니다.

4. 일정과 지연 책임 조항

개발 계약서에는 전체 개발 기간뿐 아니라 일정 지연이 발생했을 때의 처리 기준도 필요합니다. 외주 개발 일정은 개발사만의 작업으로 결정되지 않습니다. 클라이언트의 자료 제공, 피드백, 의사결정, 검수 기간도 일정에 영향을 줍니다.

계약서에서 아래 항목을 확인해보는 것이 좋습니다.

• 프로젝트 시작일과 종료 예정일

• 기획, 디자인, 개발, 테스트, 검수 단계별 일정

• 클라이언트 자료 제공 기한

• 피드백 및 검수 기한

• 지연 발생 시 일정 조정 기준

• 개발사 귀책 지연과 클라이언트 귀책 지연의 구분

예를 들어 클라이언트가 필요한 자료를 늦게 전달하거나, 검수 피드백을 정해진 기간 안에 주지 못하면 전체 일정도 밀릴 수 있습니다. 반대로 개발사가 약속한 산출물을 제때 제공하지 못하면 개발사 귀책 지연으로 볼 수 있습니다.

일정 조항은 단순히 마감일을 정하는 것이 아니라, 지연이 생겼을 때 누구의 책임인지 판단할 수 있는 기준이어야 합니다.

5. 검수 기준 조항

외주 개발에서 검수는 프로젝트 완료 여부를 판단하는 중요한 절차입니다. 하지만 검수 기준이 없으면 클라이언트와 개발사가 서로 다른 기준으로 완료 여부를 판단할 수 있습니다.

검수 조항에는 아래 내용이 포함되는 것이 좋습니다.

• 검수 대상 산출물

• 검수 기간

• 검수 방법

• 버그와 변경 요청의 구분

• 검수 중 발견된 오류 처리 방식

• 검수 완료 또는 승인 기준

• 기한 내 검수 의견이 없을 경우 처리 방식

특히 중요한 것은 버그 수정과 추가 요청을 구분하는 기준입니다. 계약 범위에 포함된 기능이 정상 작동하지 않는 것은 버그에 가깝지만, 처음 범위에 없던 기능을 새로 요청하는 것은 추가 개발에 해당할 수 있습니다.

이 기준이 없으면 검수 단계에서 “수정”과 “추가 개발”을 두고 갈등이 생기기 쉽습니다.

6. 지식재산권과 소스코드 소유권 조항

개발 결과물의 권리가 누구에게 있는지도 반드시 확인해야 합니다. 외주 개발에서는 소스코드, 디자인 파일, 문서, 데이터베이스 구조, 산출물에 대한 권리 기준이 중요합니다.

계약서에서 아래 내용을 확인하는 것이 좋습니다.

• 개발 완료 후 소스코드를 제공하는지

• 소스코드의 소유권이 누구에게 있는지

• 디자인 원본 파일을 제공하는지

• 개발사가 기존에 보유한 공통 모듈이나 라이브러리는 어떻게 처리하는지

• 클라이언트 데이터의 소유권은 누구에게 있는지

• 계약 종료 후에도 결과물을 사용할 수 있는지

모든 코드의 소유권을 무조건 클라이언트에게 이전하는 방식이 항상 현실적인 것은 아닐 수 있습니다. 개발사가 기존에 보유한 공통 모듈, 템플릿, 라이브러리, 프레임워크를 사용하는 경우도 있기 때문입니다.

중요한 것은 클라이언트가 서비스 운영에 필요한 결과물을 안정적으로 사용할 수 있는지, 그리고 계약 종료 후에도 서비스 운영에 문제가 없는지입니다.

7. 하자보수 조항

개발이 완료된 뒤에도 오류가 발견될 수 있습니다. 그래서 하자보수 조항은 반드시 확인해야 합니다.

하자보수 조항에서는 아래 항목을 확인하는 것이 좋습니다.

• 하자보수 기간

• 하자보수 대상

• 무상 처리 범위

• 오류 접수 방법

• 대응 시간

• 긴급 장애 처리 기준

• 하자보수에서 제외되는 항목

여기서도 중요한 것은 버그와 추가 개발을 구분하는 것입니다. 계약된 기능이 정상적으로 작동하지 않는 것은 하자보수 대상일 수 있지만, 새로운 기능 추가나 정책 변경은 하자보수가 아니라 추가 개발일 수 있습니다.

하자보수 기간이 있다고 해서 모든 수정이 무료로 처리되는 것은 아닙니다. 무엇이 하자이고, 무엇이 추가 요청인지 기준이 있어야 합니다.

8. 유지보수 조항

하자보수와 유지보수는 다릅니다. 하자보수는 개발 결과물의 오류를 수정하는 성격이 강하고, 유지보수는 런칭 후 서비스 운영을 지원하는 성격이 강합니다.

유지보수에는 아래 내용이 포함될 수 있습니다.

• 운영 문의 대응

• 서버 모니터링

• 보안 업데이트

• 경미한 문구 또는 화면 수정

• 외부 서비스 변경 대응

• 장애 발생 시 확인 및 조치

• 월간 리포트 또는 정기 점검

유지보수 계약이 별도라면 월 비용, 대응 시간, 포함 범위, 제외 범위를 확인해야 합니다. 유지보수 없이 런칭만 하고 끝나는 구조라면, 이후 오류나 운영 이슈가 생겼을 때 대응이 늦어질 수 있습니다.

특히 결제, 알림, 회원 정보, 예약, 주문처럼 실제 운영과 연결된 서비스라면 런칭 후 안정화 기간과 유지보수 조건을 미리 확인하는 것이 좋습니다.

9. 변경 요청과 추가 개발 조항

외주 개발 프로젝트에서는 진행 중에 변경 요청이 생길 수 있습니다. 처음 기획한 기능이 바뀌거나, 새로운 기능이 필요해지거나, 외부 심사 과정에서 수정이 필요할 수 있습니다.

중요한 것은 변경 요청을 막는 것이 아니라, 변경 요청을 어떻게 처리할지 기준을 정하는 것입니다.

계약서에는 아래와 같은 기준이 있으면 좋습니다.

• 변경 요청 접수 방식

• 변경 요청의 영향도 검토 방식

• 일정 변경 여부

• 추가 비용 산정 방식

• 승인 후 작업 착수 기준

• 구두 요청이 아닌 기록 기준

변경 요청이 말로만 오가면 나중에 무엇이 합의되었는지 확인하기 어렵습니다. 그래서 변경 요청은 가능하면 문서, 이슈, 회의록, 승인 기록처럼 남겨야 합니다.

추가 개발 비용은 감정적인 문제가 아니라 범위 변경에 대한 합의 문제입니다. 처음부터 기준을 정해두면 비용 논의도 훨씬 쉬워집니다.

10. 중도해지 조항

모든 프로젝트가 처음 계획대로 끝나는 것은 아닙니다. 예산 문제, 사업 방향 변경, 일정 지연, 품질 문제, 커뮤니케이션 문제로 중간에 계약을 종료해야 할 수도 있습니다.

이런 상황을 대비해 중도해지 조항을 확인해야 합니다.

• 어떤 경우에 계약을 해지할 수 있는지

• 해지 통보는 며칠 전에 해야 하는지

• 이미 수행한 작업의 비용은 어떻게 정산하는지

• 중간 산출물은 제공되는지

• 소스코드와 디자인 파일은 어디까지 전달되는지

• 선급금이나 잔금은 어떻게 처리되는지

중도해지 조항이 없으면 프로젝트가 중단될 때 비용 정산과 산출물 전달을 두고 큰 갈등이 생길 수 있습니다. 특히 단계별 산출물과 지급 기준이 연결되어 있으면 중도해지 상황에서도 정산이 비교적 명확해집니다.

11. 비밀유지와 개인정보보호 조항

외주 개발 과정에서는 서비스 아이디어, 사업 전략, 고객 정보, 내부 운영 정보, API 키, 서버 접근 정보 같은 민감한 정보가 오갈 수 있습니다. 그래서 비밀유지 조항도 중요합니다.

계약서에서 아래 내용을 확인하는 것이 좋습니다.

• 비밀정보의 범위

• 비밀정보 사용 목적

• 제3자 제공 금지

• 계약 종료 후 비밀유지 의무

• 개인정보 처리 기준

• 서버, 계정, API 키 관리 기준

• 자료 반환 또는 폐기 기준

특히 회원 정보, 결제 정보, 위치 정보, 의료 정보처럼 민감한 데이터를 다루는 서비스라면 개인정보보호 관련 조항을 더 꼼꼼히 확인해야 합니다. 개발사가 실제 운영 데이터에 접근하게 되는 경우 접근 권한과 로그 관리 기준도 필요합니다.

계약서는 프로젝트를 묶어두는 기준입니다

외주 개발 계약서는 법적 형식만 맞추기 위한 문서가 아닙니다. 프로젝트를 시작하기 전에 클라이언트와 개발사가 같은 기준을 갖기 위한 문서입니다.

계약서에서 확인해야 할 핵심 조항을 다시 정리하면 다음과 같습니다.

1. 개발 범위

2. 제외 범위

3. 대금 지급 조건

4. 일정과 지연 책임

5. 검수 기준

6. 지식재산권과 소스코드 소유권

7. 하자보수

8. 유지보수

9. 변경 요청과 추가 개발

10. 중도해지

11. 비밀유지와 개인정보보호

이 조항들이 명확할수록 프로젝트 중간에 생길 수 있는 오해를 줄일 수 있습니다. 계약서는 개발사를 압박하기 위한 문서도 아니고, 클라이언트를 방어하기 위한 문서만도 아닙니다. 서로 같은 기준으로 프로젝트를 진행하기 위한 안전장치입니다.

계약 후에도 변경사항과 합의 내역은 계속 남겨야 합니다

계약서를 잘 작성했더라도 프로젝트가 시작되면 상황은 계속 바뀔 수 있습니다. 새로운 요청이 생기고, 일정이 조정되고, 검수 과정에서 수정사항이 나오고, 회의에서 추가 결정이 이루어집니다.

그래서 외주 개발에서는 계약서만큼이나 계약 이후의 기록이 중요합니다. 무엇이 변경되었는지, 누가 승인했는지, 일정과 비용에 어떤 영향이 있는지 남겨야 나중에 같은 기준으로 확인할 수 있습니다.

Pronika는 외주 개발 프로젝트에서 계약 범위, 요구사항, 회의록, 변경 요청, 검수 내역을 한곳에 기록하고 관리할 수 있도록 돕습니다. 계약서에 적힌 기준과 실제 진행 중 합의된 내용을 같은 흐름 안에서 관리하면, 클라이언트와 개발사가 더 안정적으로 프로젝트를 이어갈 수 있습니다.