개발 범위와 개발비·검수·지식재산권 조항을 채우고 양쪽이 전자서명하면 위처럼 도장이 들어간 계약서가 PDF로 완성돼요.
앱 개발 계약서는 앱 개발을 외주로 맡기거나 수주할 때 개발 범위·대금·소스코드 권리를 문서로 정해두는 계약서예요. 양식을 무료로 쓰면 조항이 채워진 상태에서 빈칸만 채우고, 전자서명까지 받아 분쟁 여지를 줄일 수 있어요.
시작 전에 하나만 정직하게 짚을게요. 문서박사에 "앱 개발 전용" 템플릿이 따로 있는 건 아니에요.
앱도 소프트웨어라서, 프로그램 개발 템플릿(문서 제목: 소프트웨어 개발 계약서)을 그대로 쓰면 돼요. 스토어 등록이나 지원 OS 같은 앱 특유의 항목은 별첨 "요구사항 정의서"와 조항 수정으로 얹으면 되는데, 그 방법을 아래에서 차례대로 정리했어요.
앱 개발 분쟁, 대부분 말로만 정해서 생겨요
앱 개발은 웹보다 관여하는 요소가 많아요. 스토어 심사, 두 개의 OS, 서버, 관리자 화면까지 있으니 "포함이냐 아니냐" 다툼이 더 자주 생겨요.
실제로 자주 부딪히는 장면은 이렇습니다.
- iOS·Android 둘 다인 줄 알았는데 한쪽만 개발 범위였다
- 관리자 화면과 서버 API가 견적에 포함인지 애매하다
- 스토어 심사에서 반려됐는데 수정 대응이 누구 몫인지 정한 적 없다
- 앱은 받았는데 소스코드와 서명 키를 못 받아 다른 업체가 업데이트를 못 한다
이런 건 계약서 한 장과 별첨 문서에 미리 적어두면 감정 싸움까지 안 가요.
앱 개발도 소프트웨어 개발 계약서 양식이면 돼요
문서박사에서 프로그램 개발 템플릿을 고르면 제1조부터 제13조까지 채워진 소프트웨어 개발 계약서가 열려요. 개발 내용·대금·검수·지식재산권·하자보수처럼 앱 외주에도 그대로 필요한 조항들이에요.
조항 문구는 에디터에서 수정하거나 추가할 수 있어서, 앱에 필요한 특약을 덧붙이기도 어렵지 않아요.
조항 하나하나의 전체 해설은 소프트웨어 개발 계약서 양식 가이드에 따로 정리돼 있어요. 만약 앱이 아니라 홈페이지 중심 프로젝트라면 웹사이트 제작 계약서 양식이 더 맞을 수 있어요.
서명 전에 꼭 짚어둘 조항
앱 외주에서 특히 다툼이 잦은 조항만 추리면 이래요.
- 개발 내용(제2조): 프로젝트명과 개발 내용을 적고, 세부 기능은 별첨 "요구사항 정의서"에 담아요. 명시 안 된 사항은 협의로 정한다고 못 박아둬요.
- 개발비(제4조): 계약금 30%·중도금 30%·잔금 40% 분할이 기본 틀이고, 세금계산서 발행일로부터 15일 이내 지급으로 정해요.
- 요구사항 변경(제5조): 변경은 서면으로 요청하고, 추가 비용·일정은 별도 합의예요. "이 기능도 넣어주세요"가 쌓이는 앱 개발에서 제일 자주 쓰이는 조항이에요.
- 납품·검수(제7조): 납품일로부터 14일 이내 검수, 이의가 없으면 검수 완료로 봐요.
- 지식재산권(제8조): 저작권은 잔금 지급이 완료돼야 발주 측으로 넘어가요. 개발자가 원래 보유한 범용 라이브러리·프레임워크는 개발자 소유로 남고, 발주 측은 결과물 안에서 쓸 권리를 가져요.
- 하자보수(제9조): 검수 완료일로부터 6개월 무상이고, 임의 수정·운영환경 변경으로 생긴 오류는 제외예요.
서명 전 체크리스트 — 표로 한 번에 확인하기
앱 개발 계약서에 서명하기 전, 아래 표를 한 줄씩 확인해보세요.
| 확인할 것 | 왜 필요한가 | 이 양식 기준 |
|---|---|---|
| 개발 범위·지원 OS | "iOS도 포함이었다" 분쟁 방지 | 요구사항 정의서 별첨(제2조) |
| 대금 분할 | 한쪽만 위험을 떠안지 않게 | 계약금 30%·중도금 30%·잔금 40%(제4조) |
| 범위 변경 절차 | 추가 기능 요청의 비용·일정 정리 | 서면 요청 후 별도 합의(제5조) |
| 검수 기한 | 검수가 무한정 늘어지는 것 방지 | 14일, 이의 없으면 완료 간주(제7조) |
| 소스코드 권리 | 결과물 권리 이전 시점 | 잔금 완납 시 귀속(제8조) |
| 소스코드·서명 키 인계 | 다른 업체도 업데이트 가능하게 | 요구사항 정의서·특약에 추가 |
| 하자보수 | 출시 후 버그 수정 책임 범위 | 6개월 무상, 임의 수정 제외(제9조) |
| 해지·정산 | 중간에 틀어졌을 때 극단 방지 | 시정요구 30일, 진행률 정산(제11조) |
표에서 "요구사항 정의서·특약에 추가"로 적힌 항목이 양식에 기본으로 없는 앱 특화 부분이에요. 아래에서 하나씩 볼게요.
요구사항 정의서에 앱 특유 항목부터 적어두세요
이 양식은 세부 기능을 별첨 요구사항 정의서로 두는 구조라(제2조), 앱 특유의 항목은 여기에 적는 게 자연스러워요.
- 지원 OS와 최소 버전: iOS·Android 각각 어디까지 지원하는지
- 대상 기기: 스마트폰만인지, 태블릿 대응도 포함인지
- 관리자 화면과 서버 API: 앱 뒤에서 돌아가는 부분이 이번 계약에 포함인지
- 기능 단위: 푸시 알림, 로그인 방식, 결제 같은 기능을 항목으로 나열
"앱 하나 만들어주세요"가 아니라 이렇게 기능 단위로 적어야, 나중에 제5조의 서면 변경 절차도 제대로 작동해요.
스토어 계정과 심사는 계약서에서 미리 정리하세요
앱은 만들어도 스토어에 올라가야 끝나요. 그래서 세 가지를 계약 단계에서 정해두는 게 안전해요.
앱스토어·플레이스토어 개발자 계정은 발주사 명의로 만드는 걸 권해요. 개발사 명의 계정으로 올리면 이후 업데이트나 계정 양도 때 절차가 꼬이기 쉬워요.
심사 반려(리젝)가 나왔을 때의 수정 대응이 계약 범위에 포함인지도 특약으로 적어두세요. 반려는 드문 일이 아니라서, 정하지 않으면 추가 비용 분쟁으로 이어져요.
오픈 예정일은 심사 기간을 감안해서 잡는 게 좋아요. 납품일과 별개로 심사에 걸리는 시간이 있으니, 오픈 행사 날짜부터 박아두면 곤란해질 수 있어요.
납품 범위에 소스코드와 서명 키를 명시하세요
앱 외주에서 가장 뼈아픈 실무 함정이 이거예요. 납품 때 소스코드와 함께 서명 키를 받아야 해요.
Android는 키스토어(앱에 서명하는 열쇠 파일), iOS는 배포 인증서가 있어야 같은 앱으로 업데이트를 올릴 수 있어요. 이걸 안 받아두면 나중에 다른 업체가 앱을 이어받아도 업데이트를 못 하고, 새 앱으로 다시 올려야 하는 상황이 생겨요.
이 양식의 지식재산권 조항(제8조)은 저작권 귀속을 정해주지만, 서명 키 인계까지 자동으로 다루진 않아요. 요구사항 정의서나 특약에 "납품물: 소스코드, 키스토어 파일, 인증서, 계정 정보" 식으로 한 줄 적어두세요.
출시 후 업데이트 대응은 하자보수와 달라요
이 양식의 하자보수(제9조)는 검수 완료일로부터 6개월간 버그를 무상으로 고쳐주는 조항이에요.
그런데 OS가 업데이트돼서 생기는 대응 작업이나 기능 개선은 버그 수정이 아니에요. 하자보수 기간이라도 당연히 무상은 아니고, 별도 계약 영역이에요.
출시 후에도 앱을 계속 손봐야 한다면 처음부터 유지보수 계약서를 따로 준비하는 걸 권해요. 월 대응 범위와 비용을 정해두면 출시 후 관계가 훨씬 매끄러워요.
템플릿 고르고 앱에 맞게 수정하는 방법
문서박사에서 새 계약서를 만들면 템플릿 선택 화면이 나와요. 여기서 프로그램 개발을 고르면 돼요.
제1조부터 제13조까지 자리 잡힌 문서가 바로 열리고, 회사 정보·프로젝트명·기간·금액 같은 빈칸만 채우면 돼요.
조항은 에디터에서 바로 수정·추가할 수 있어서, 위에서 본 스토어 계정·서명 키 특약도 이 화면에서 넣으면 돼요. 거래처를 한 번 등록해두면 다음 계약서에선 다시 입력하지 않아도 돼요.
앱 개발 말고 다른 계약이 필요하면 계약서 양식 모음에서 종류별로 찾아볼 수 있어요.
종이 없이 전자서명으로 마무리하기
작성이 끝나면 출력·도장·스캔 없이 그대로 전자계약으로 보내면 돼요. 상대방은 받은 링크에서 바로 서명해요.
전자계약은 건당 비용 없이 무제한 무료라 프로젝트가 여러 건이어도 부담이 없어요.
서명이 완료되면 서명자·일시·접속기록이 문서에 함께 남고, 위변조 방지 보안 코드도 저장돼요. "그 범위에 합의한 적 없다"는 말이 나와도 기록으로 확인할 수 있어요.
이미 쓰던 PDF 계약서가 있다면 그 파일을 올려서 서명 영역만 얹는 방법도 있어요.
자주 묻는 질문
앱 개발 전용 계약서 양식이 따로 필요한가요?
아니요, 앱도 소프트웨어라 소프트웨어 개발 계약서 양식을 그대로 쓰면 돼요. 지원 OS·스토어 등록·서명 키 인계 같은 앱 특유 항목만 별첨 요구사항 정의서나 특약으로 추가하면 충분해요.
스토어 개발자 계정은 누구 명의로 만들어야 하나요?
발주사 명의로 만드는 게 안전해요. 개발사 명의 계정에 앱이 올라가면 나중에 업데이트 권한이나 계정 양도 절차가 꼬일 수 있어요. 계정 생성·연회비 부담 주체를 계약 때 같이 정해두세요.
심사에서 반려(리젝)되면 수정은 누가 하나요?
정해두지 않으면 분쟁이 되기 쉬운 부분이에요. 스토어 정책 위반 등으로 반려됐을 때의 수정 대응이 개발 범위에 포함인지, 몇 회까지인지 특약으로 적어두는 걸 권해요. 오픈일도 심사 기간을 감안해 여유 있게 잡는 게 좋아요.
출시 후 OS 업데이트 대응도 무상 하자보수인가요?
이 양식 기준 하자보수는 검수 완료일로부터 6개월간의 버그 수정이에요(제9조). OS 업데이트 대응이나 기능 개선은 하자가 아니라서 별개예요. 출시 후 대응이 필요하면 유지보수 계약을 따로 맺는 게 깔끔해요.
다음 앱 프로젝트 전에 계약서부터 준비해보세요
앱 개발은 금액이 크고 기간이 길어서, 계약서 없이 시작하면 되돌리기 어려워요.
외주 건이 잡혔다면 문서박사에서 프로그램 개발 템플릿을 골라 개발 범위와 금액부터 채워보세요. 가입·작성·전자서명·보관까지 비용이 들지 않아요.