계약서에 개발 범위를 적어 두는 법

앱 개발 계약서에 「회원 관리 기능」이라고 한 줄 적혀 있었습니다. 개발이 끝날 무렵 담당자님은 관리자가 회원 등급을 바꾸는 화면을 찾았습니다. 개발사는 회원 목록만 만들었다고 했습니다. 둘 다 「회원 관리」였습니다.

누가 틀렸다고 하기 어려웠습니다. 계약서에 적힌 말이 두 가지로 읽혔을 뿐입니다. 결국 추가 비용과 일정이 붙었고, 서로 감정도 상했습니다.

핵심은 계약서의 개발 범위를 기능 이름이 아니라 화면 목록과 화면설계로 정하는 것입니다. 「별첨 화면설계에 있는 화면을 만든다」처럼 문서를 붙이면 해석이 갈릴 여지가 크게 줄어듭니다. 만들지 않을 것도 함께 적어 두어야 합니다.

이 글은 기획 실무의 관점에서 쓴 것이며 법률 자문이 아닙니다. 실제 계약서 문구는 변호사 등 전문가에게 확인하시기 바랍니다.

기능 이름만 적으면 생기는 일

기능 이름은 짧고 편합니다. 그런데 그 안에 무엇이 들어가는지는 사람마다 다르게 생각합니다. 「결제」에 환불이 들어가는지, 「알림」에 문자가 들어가는지, 「관리자」에 통계가 들어가는지 계약서만 보고는 알 수 없습니다.

개발 중에는 이 차이가 드러나지 않다가, 납품 직전에야 「그건 범위 밖입니다」라는 말로 나타납니다. 그때는 이미 일정이 빠듯해 조정할 여유가 없습니다.

더 흔한 경우는 「등」이라는 한 글자입니다. 「알림, 공지 등」이라고 적으면 그 「등」에 무엇이 들어가는지를 두고 서로 다른 목록을 떠올리게 됩니다.

계약 범위로 붙일 문서

계약서 본문은 짧게 두고, 범위는 별첨 문서로 붙이는 방식이 많이 쓰입니다. 별첨에는 아래 문서가 들어가면 좋습니다.

문서에는 작성 날짜와 버전을 적어 둡니다. 계약 뒤에 문서가 고쳐지면 어느 버전이 계약 범위인지 헷갈리기 때문입니다.

범위와 함께 적어 둘 것

범위를 문서로 정했다면, 그 범위가 바뀔 때와 끝났을 때를 어떻게 다룰지도 함께 정해 둡니다.

• 변경 절차. 범위를 바꾸고 싶을 때 누가 요청하고, 누가 검토하고, 일정과 비용은 어떻게 다시 정하는지
• 포함된 수정의 기준. 화면설계 안에서의 문구나 배치 수정은 어디까지 포함인지
• 검수 기준. 화면설계와 대조해 확인한다는 것, 확인 기간은 얼마인지
• 넘겨받을 것. 소스 코드, 관리자 계정, 서버 정보, 최신 화면설계

기획자가 계약 전에 문서를 다듬을 때 가장 공들이는 곳이 제외 목록과 관리자 화면입니다. 이 두 곳이 비어 있으면 나중에 범위 다툼이 생길 가능성이 큽니다.

계약 전에 한 번 더 확인합니다

1. 화면 목록의 모든 화면에 화면설계가 있는가
2. 관리자 화면이 사용자 화면과 따로 적혀 있는가
3. 이번에 만들지 않을 것이 목록으로 있는가
4. 개발사가 문서를 읽고 범위에 동의했다는 기록이 있는가

범위를 계약서에 정확히 적을 수 있느냐는 결국 그 전에 메뉴 구조와 화면설계, 기획서가 얼마나 정리돼 있느냐에 달려 있습니다. 문서가 먼저 있으면 계약은 그 문서를 붙이는 일로 단순해집니다. 개발은 다른 곳에 맡기셔도, 직접 하셔도 됩니다.

자주 묻는 질문

앱 개발 계약서에 개발 범위는 어떻게 적나요?

본문에 기능 이름을 나열하기보다 화면 목록과 화면설계를 별첨으로 붙이는 방식이 해석 차이를 줄입니다. 만들지 않을 기능을 적은 제외 목록도 함께 붙이면 좋습니다. 구체적인 문구는 전문가에게 확인하십시오.

계약 뒤에 기능을 추가하고 싶으면 어떻게 되나요?

계약서에 정한 변경 절차를 따르게 됩니다. 그래서 계약할 때 변경 요청을 누가 하고 일정과 비용을 어떻게 다시 정하는지 미리 적어 두는 것이 좋습니다. 절차가 없으면 매번 협상이 처음부터 시작됩니다.

화면설계 없이 계약해도 괜찮을까요?

계약은 할 수 있지만 범위가 말로 남아 해석이 갈릴 여지가 커집니다. 적어도 화면 목록과 제외 목록은 갖추고 계약하시기를 권합니다. 화면설계가 있으면 납품 때 확인하는 기준으로도 쓸 수 있습니다.