개발 외주 계약서 체크리스트: 소스코드·유지보수에서 꼭 확인할 것

계약서에는 “웹서비스 개발”, “앱 제작”처럼 결과물 이름만 적기보다 실제 과업을 확인할 수 있는 문서를 연결하는 것이 좋습니다. 한국저작권위원회가 컴퓨터프로그램 감정에서 참고 자료로 개발계약서뿐 아니라 요구사항 정의서, 설계서, 기능명세서, 운영·설치 매뉴얼, 완료 보고서와 회의록 등을 안내하는 것도 개발 결과를 판단할 때 여러 문서가 함께 쓰일 수 있음을 보여줍니다.

계약서 본문에 모든 화면과 예외 상황을 다 적을 필요는 없습니다. 대신 계약서가 어떤 요구사항 문서와 산출물 목록을 기준으로 하는지 식별할 수 있어야 합니다.

특히 관리자 기능이나 외부 API 연동처럼 “포함”이라는 한 단어로 범위를 해석하기 어려운 기능은, 실제로 누가 어떤 행동을 할 수 있는지까지 풀어 적는 편이 좋습니다.

계약 범위는 기능 이름보다 포함 범위와 제외 범위가 함께 보여야 명확해집니다.

같은 “예약 서비스 개발”이라도 고객 화면만 만드는지, 운영자가 예약을 취소하고 환불 상태를 바꾸는 관리자 화면까지 만드는지에 따라 범위는 크게 달라집니다.

견적서의 기능 목록과 계약서의 과업 범위가 서로 다르면 분쟁이 생기기 쉽습니다. 계약 전에 같은 기능명을 같은 의미로 사용하고 있는지 확인하세요.

산출물은 “완성 후 전달”보다 구체적으로 적어두는 편이 좋습니다. 예를 들어 Figma 원본, Git 저장소, 서버 계정, API 키, 데이터베이스 스키마가 각각 누구 명의로 관리되는지를 구분할 수 있습니다.

기능명을 계약 문장으로 바꿀 때는 주체와 행동을 넣어보세요.

관리자는 신청 내역을 조회하고 상태를 변경할 수 있으며, 취소 요청은 관리자 승인 후 처리한다.

이처럼 누가, 무엇을, 어디까지 처리하는지가 보이면 개발 범위와 검수 기준을 함께 만들기 쉬워집니다.

소스코드 파일을 전달받는 것과 프로그램에 관한 저작재산권을 양도받는 것은 같은 문제가 아닙니다. 저작권법은 저작재산권을 전부 또는 일부 양도할 수 있도록 하고 있고, 한국저작권위원회도 이용허락 계약과 저작재산권 양도 계약을 별도의 표준계약서로 제공하고 있습니다.

따라서 계약서에서는 “소스 제공”이라는 표현만 두기보다 무엇을 언제 인도하고, 결과물의 권리를 어떻게 귀속할지 각각 확인하는 편이 안전합니다.

권리 조항에서는 최소한 다음 세 가지를 나눠 확인해보세요.

검수 조항은 “검수 후 완료”라는 문장보다 무엇을 어떤 환경에서 확인하고, 불합격이면 어떻게 수정하는지가 보여야 합니다.

공공 소프트웨어사업에서는 과업내용의 변경과 그에 따른 계약금액·기간 조정을 별도로 다루는 규정이 있습니다. 이 규정은 국가기관 등의 사업에 적용되는 공공 조달 제도이므로 민간 외주 계약에 그대로 적용되는 것은 아니지만, 변경 범위와 일정·금액을 함께 문서화한다는 원칙은 참고할 만합니다.

이 요청은 원래 요구사항을 충족하지 못한 오류인가요, 아니면 기존 범위를 바꾸는 새로운 요청인가요?

이 질문을 먼저 정하면 무상 수정 대상과 추가 개발을 구분하기 쉬워집니다.

서비스가 공개된 뒤에도 오류 수정, 외부 서비스 변경, 기능 개선과 운영 지원이 이어질 수 있습니다. 계약서에서 이 모든 업무를 “유지보수” 한 단어로 묶으면 포함 범위를 다르게 이해할 수 있습니다.

계약 종료 이후의 업무는 다음처럼 나눠 확인해보세요.

특히 인수인계에서는 파일 개수보다 발주사가 실제로 수정·배포·운영할 수 있는 접근 권한이 있는지를 확인해야 합니다.