앱 외주 계약서에서 가장 중요한 건 "무엇을 만드는지"를 계약서에 붙은 문서로 못 박는 일입니다. 그 위에 범위가 바뀔 때의 절차, 단계별 검수 기준과 대금 지급, 소스코드와 계정이 누구에게 남는지, 출시 후 하자보수를 어디까지 하는지를 적어 두면 분쟁이 날 여지가 크게 줄어듭니다. 개발사 입장에서 계약서를 여러 번 써 보며 서로에게 필요하다고 느낀 항목들을 순서대로 정리했습니다.

계약서 양식은 어디서 시작하면 좋을까

처음부터 백지에 쓰기보다 공개된 표준계약서를 놓고 고쳐 쓰는 편이 빠릅니다. 과학기술정보통신부는 2020년 말 소프트웨어 진흥법에 맞춰 SW 표준계약서 6종을 만들어 배포했고, 이 가운데 "정보시스템 개발구축 사업 표준계약서"가 민간 발주 개발 계약에 참고하기 좋습니다. 앱 외주에 그대로 쓰기에는 맞지 않는 부분도 있으니, 뼈대로 삼고 앱 특성에 맞는 항목을 더하는 식으로 쓰시면 됩니다.

아래 항목들은 그 뼈대에 저희가 앱 프로젝트에서 따로 챙기는 내용입니다. 법률 해석이 필요한 부분이나 금액이 큰 계약이라면 서명 전에 법률 전문가의 검토를 한 번 받으시길 권합니다.

개발 범위는 본문이 아니라 첨부 문서로

계약서 본문에 "쇼핑몰 앱 개발 일체" 같은 한 줄만 있으면, 나중에 어떤 기능이 포함인지를 두고 서로 다른 말을 하게 됩니다. 개발 범위는 별도 문서로 만들어 계약서에 첨부하고, 본문에는 "개발 범위는 첨부 문서에 따른다"고 적는 방식이 좋습니다.

첨부 문서에는 최소한 이런 내용이 들어가야 합니다.

• 지원 플랫폼(iOS, Android, 웹)과 최소 지원 OS 버전
• 화면 목록과 화면별 주요 기능
• 서버, 관리자 페이지 포함 여부와 범위
• 외부 연동(결제, 본인인증, 지도, 푸시, 소셜 로그인 등) 목록
• 스토어 등록을 누가, 어디까지 하는지
• 범위에서 제외되는 것

마지막 항목이 의외로 중요합니다. "포함되지 않는 것"을 적어 두면 해석의 여지가 확 줄어듭니다. 범위 문서를 어떻게 정리하면 좋은지는 기획서에 꼭 들어가야 할 것에서 따로 다뤘습니다.

범위가 바뀔 때의 절차

개발 중에 요구사항이 바뀌지 않는 프로젝트는 거의 없습니다. 바뀌는 것 자체보다, 바뀔 때 어떻게 처리하는지가 정해져 있지 않은 게 문제입니다.

변경 요청 처리 절차

1. 서면 요청이메일이나 협업 도구에 기록
2. 영향 안내개발사가 일정과 비용 영향 알림
3. 양쪽 확인발주사와 개발사가 함께 확인
4. 반영확인된 변경만 개발에 반영

계약서에는 변경 요청을 서면(이메일이나 협업 도구 기록 포함)으로 하고, 개발사가 일정과 비용에 미치는 영향을 알린 뒤, 양쪽이 확인해야 반영한다는 절차를 적어 둡니다. 작은 문구 수정처럼 일정에 영향이 없는 변경은 어디까지 추가 비용 없이 반영할지도 기준을 정해 두면 좋습니다. 이 절차가 없으면 "이 정도는 원래 해 주는 것 아니냐"는 대화가 반복되고, 그게 쌓이면 일정이 무너집니다.

단계와 검수 기준, 그리고 대금 지급

프로젝트를 기획, 디자인, 개발, 테스트, 출시 같은 단계로 나누고 단계마다 무엇을 넘기는지 적습니다. 그리고 각 단계의 결과물을 어떤 기준으로 검수(결과물이 약속한 대로 나왔는지 확인하는 절차)할지도 함께 정합니다.

검수와 대금 지급 흐름

단계 결과물기획, 디자인, 개발 등

검수범위 문서 기능이 기기에서 동작

검수 기간기간 안에 의견, 지나면 완료

대금 지급검수 완료와 연결해 지급

검수 기준이 "발주사가 만족할 때까지"로 되어 있으면 개발사는 끝을 알 수 없고, 기준이 아예 없으면 발주사가 확인할 근거가 없습니다. 첨부한 범위 문서의 기능이 실제 기기에서 동작하는지를 기준으로 삼는 게 가장 깔끔합니다. 검수 기간도 적어 두세요. 결과물을 받은 뒤 정해진 기간 안에 의견을 주고, 기간이 지나면 검수가 끝난 것으로 본다는 식입니다. 이 조항이 없으면 검수가 몇 주씩 늘어지기도 합니다.

대금은 이 단계와 묶는 게 일반적입니다. 착수할 때 일부, 중간 단계 검수 후 일부, 최종 검수 후 잔금을 내는 식입니다. 비율은 프로젝트마다 협의하면 되지만, 대금 지급 시점이 검수 완료와 연결되어 있어야 서로 안심할 수 있습니다. 착수 시점에 대부분을 먼저 내는 구조라면 한 번 더 생각해 보시는 게 좋습니다.

소스코드와 지식재산권

계약서에 적지 않으면 가장 크게 후회하는 부분입니다. 개발한 결과물의 지식재산권이 누구에게 있는지, 소스코드를 언제 어떤 형태로 넘기는지를 분명히 적어야 합니다.

"최종 대금 지급 시 소스코드 일체와 지식재산권이 발주사에 이전된다" 같은 문장이 있으면 기본은 됩니다. 여기에 넘겨받을 것의 목록을 구체적으로 붙여 두세요. 앱과 서버 소스코드 저장소, 데이터베이스 구조, 빌드와 배포 방법을 적은 문서, 서명 키(앱을 스토어에 올릴 때 쓰는 인증서와 키 파일), 관리자 계정 정보 등입니다. 서명 키와 키 비밀번호는 누가 보관하는지까지 정해 두세요. 담당자가 바뀌는 순간 찾을 수 없게 되는 일이 생각보다 자주 있습니다.

개발사가 여러 프로젝트에 공통으로 쓰는 모듈이나 자체 솔루션이 들어간다면, 그 부분은 소유권을 넘기는 대신 사용권을 주는 식으로 따로 정하는 경우가 많습니다. 어느 부분이 여기에 해당하는지 계약 때 확인해 두면 나중에 오해가 없습니다.

계정은 처음부터 발주사 명의로

Apple 개발자 계정, Google Play 개발자 계정, 서버 호스팅, 도메인, 푸시 알림 서비스, 결제 대행사 계약은 발주사 명의로 만들고 개발사에는 작업에 필요한 권한만 주는 게 원칙입니다. 계약서에도 "서비스 운영에 필요한 계정은 발주사 명의로 개설한다"고 적어 두세요.

개발사 명의 계정으로 출시하면 나중에 앱을 발주사 계정으로 옮기는 이전 절차를 거쳐야 하고, 그동안 업데이트가 막히기도 합니다. 유지보수 업체를 바꾸거나 사내 개발로 넘어갈 때 계정 문제가 발목을 잡는 경우가 많습니다. 외주에서 사내 개발로 넘어갈 때 챙길 점은 외주와 직접 개발 비교 글에도 정리해 두었습니다.

하자보수와 유지보수는 나눠서

하자보수는 계약한 범위의 기능이 제대로 동작하지 않을 때 개발사가 무상으로 고치는 것입니다. 기간을 정해 두고, 무엇이 하자인지 범위를 적습니다. 보통 첨부한 범위 문서대로 동작하지 않는 것을 하자로 보고, 새 기능 추가나 디자인 변경, 발주사가 나중에 바꾼 요구사항은 제외합니다.

하자보수와 유지보수

하자보수

• 범위 기능 오류를 무상 수정
• 기간과 하자 범위 명시
• 새 기능, 디자인 변경 제외
• 새 OS 대응은 보통 제외

유지보수

• 하자보수 기간 이후 관리
• 별도 계약 권장
• 월 단위 또는 요청 시
• 새 OS 대응은 주로 여기

OS 새 버전이 나와서 생기는 문제는 애매한 영역이라 미리 정해 두면 좋습니다. 개발 당시에 없던 OS 변경에 대응하는 일은 하자보수가 아니라 유지보수로 보는 경우가 많습니다.

유지보수는 하자보수 기간이 끝난 뒤 이어지는 관리입니다. 이건 별도 계약으로 두는 걸 권합니다. 월 단위로 할지, 요청할 때마다 할지, 장애 대응은 얼마 안에 시작할지 같은 조건이 개발 계약과는 성격이 달라서, 한 계약서에 섞으면 오히려 해석이 어려워집니다.

비밀유지, 오픈소스, 해지

비밀유지 조항에는 서로 알게 된 사업 정보와 개인정보를 계약 목적 외에 쓰지 않는다는 내용과, 계약이 끝난 뒤에도 일정 기간 유지된다는 내용을 넣습니다. 개발사가 포트폴리오에 이 프로젝트를 올려도 되는지도 여기서 같이 정해 두면 좋습니다.

앱에는 오픈소스 라이브러리가 거의 반드시 들어갑니다. 라이선스마다 조건이 달라서, 일부는 배포할 때 저작권 고지나 소스 공개 같은 의무가 따릅니다. 계약서에는 개발사가 사용한 오픈소스와 외부 유료 라이브러리 목록, 각각의 라이선스를 결과물과 함께 넘긴다고 적어 두세요. 개발에 AI 코딩 도구를 쓴다면 그 사실과 결과물 권리에 대한 내용도 함께 적어 두는 게 요즘은 안전합니다.

해지 조항도 빠뜨리면 안 됩니다. 어느 한쪽이 계약을 지키지 않을 때 어떤 절차로 해지하는지, 해지하면 그때까지 만든 결과물과 소스코드는 어떻게 넘기고 대금은 어떻게 정산하는지를 적습니다. 잘 될 때는 안 보는 조항이지만, 일이 틀어졌을 때는 이 조항만 보게 됩니다.

자주 묻는 질문

계약서는 개발사가 주는 양식을 그대로 써도 되나요?

개발사 양식을 출발점으로 삼는 건 괜찮습니다. 다만 범위 첨부, 검수 기준, 소스코드 이전, 계정 명의 항목이 들어 있는지는 직접 확인하시고, 없으면 추가를 요청하세요. 이런 요청을 불편해하는 개발사라면 그것도 판단 근거가 됩니다.

하자보수 기간은 얼마가 적당한가요?

정해진 기준은 없고 프로젝트 규모와 성격에 따라 협의합니다. 기간보다 중요한 건 무엇이 하자인지가 분명히 적혀 있는지입니다. 기간이 길어도 하자 범위가 좁으면 실제로 받을 수 있는 대응은 많지 않습니다.

기획이 아직 확정되지 않았는데 계약해도 되나요?

기획 단계를 먼저 따로 계약하고, 기획이 끝난 뒤 개발 범위를 확정해 개발 계약을 맺는 방법이 있습니다. 범위가 흐린 상태로 전체 계약을 하는 것보다 서로 덜 위험합니다.

계약서에 AI 도구 사용을 적어야 하나요?

의무는 아니지만 적어 두는 쪽을 권합니다. 어떤 도구를 쓰는지, 발주사 자료를 외부 AI 서비스에 넣어도 되는지, 결과물 권리는 어떻게 되는지를 미리 정하면 나중에 생길 수 있는 오해를 줄일 수 있습니다.

계약 전에 범위 문서나 계약 항목을 같이 정리해 보고 싶으시면 상담으로 연락 주세요.