개발 외주 계약서에 적어 둘 여섯 가지

계약서에 결과물의 소유권을 적지 않으면, 나중에 다른 업체에 수정을 맡기려 할 때 소스를 받을 수 있는지부터 다투기 쉽습니다. "결과물 일체의 저작권 등 지식재산권과 소유권은 대금을 다 치른 때 발주자에게 넘어간다"처럼 넘어가는 대상과 시점을 함께 적어 두세요.

넘어가는 대상은 소스코드만이 아닙니다. 데이터베이스 구조와 데이터, 디자인 원본 파일, 서버 설정, 관리자 계정까지 목록으로 적어 두는 편이 분명합니다.

소유권을 적어 두어도 소스가 개발사 컴퓨터에만 있으면 받기까지 시간이 걸립니다. 코드 저장소는 개발 첫날부터 발주자가 볼 수 있게 공유받고, 개발 중에도 진행 상황을 직접 확인하세요.

도메인, 서버, 앱 스토어, 알림톡 발신 계정처럼 서비스를 돌리는 계정은 발주자 명의로 만드는 편이 안전합니다. 개발사 명의로 만든 계정은 나중에 옮기기 번거롭고, 옮기는 동안 서비스가 멈출 수 있습니다.

"관리자 페이지 개발"처럼 한 줄로 적힌 범위는 끝나는 기준이 없습니다. 화면 목록이나 기능 목록을 계약서에 붙이고, 그 목록이 다 되면 끝이라고 적어 두세요. 화면 시안이 있으면 시안을 붙이는 것이 가장 분명합니다.

검수도 기간을 정해 두세요. 납품 뒤 며칠 안에 확인하고, 그 안에 말하지 않으면 검수가 끝난 것으로 본다는 식입니다. 개발 중에 기능이 늘어나면 그 부분은 따로 견적을 내고 일정을 다시 잡는다는 것도 함께 적어 둡니다. 범위가 늘었는데 일정과 금액이 그대로면 어딘가에서 품질이 빠지기 쉽습니다.

둘을 섞어 쓰면 "이건 무상으로 고쳐 줘야 하는 것 아니냐"를 두고 다투게 됩니다.

• 하자보수: 계약한 대로 동작하지 않는 것을 고치는 일입니다. 런칭 뒤 정한 기간 동안 무상으로 합니다.
• 유지보수: 새 기능 추가, 화면 변경, 서버 운영 대응처럼 계약 범위 밖의 일입니다. 보통 월 단위나 건 단위로 따로 계약합니다.

하자보수 기간은 몇 개월인지(또는 무엇의 몇 배인지) 적고, 그 기간이 언제부터인지(런칭일인지 검수 완료일인지)도 함께 적으세요.

개발사가 바뀌거나 사내에서 직접 관리하게 될 때 필요한 것은 문서입니다. 서버 구성, 배포 방법, 외부 서비스 계정 목록, 비밀번호와 키를 넘기는 방법, 관리자 화면 사용법을 납품 범위에 넣어 두세요. 문서를 납품물로 적어 두지 않으면 일정에 쫓겨 가장 먼저 빠집니다.

대금을 착수, 중간, 완료처럼 단계로 나누고 단계마다 무엇을 확인하면 지급하는지 적어 두면 서로 불안이 줄어듭니다. 외주 플랫폼을 거쳐 계약하면 그 플랫폼의 결제 방식을 따르게 되니, 단계와 검수 기준을 그 결제 단계에 맞춰 적어 두세요.

1. 착수코드 저장소를 발주자가 볼 수 있게 공유받고, 서비스를 돌리는 계정은 발주자 명의로 만듭니다.
2. 중간공유받은 저장소에서 진행 상황을 직접 확인합니다. 늘어난 기능은 견적과 일정을 따로 정합니다.
3. 완료계약서에 붙인 화면·기능 목록이 다 됐는지 정한 검수 기간 안에 확인하고, 인수인계 문서를 받습니다.