앱 개발 외주 전에 정해야 하는 ‘변경 가능한 것’과 ‘고정해야 하는 것’
앱 개발 외주를 준비하는 대표나 신규사업 책임자는 여러 업체의 견적서를 받아 총액부터 비교하기 쉽습니다. 한 업체는 낮은 금액을 제시하고, 다른 업체는 관리자 웹과 서버 운영까지 포함한 금액을 제시합니다. 문서만 보면 어느 쪽이 합리적인지 판단하기 어렵습니다.
문제는 개발 범위가 아직 움직이는 상태에서 고정가 견적을 최종 가격처럼 받아들이는 데서 시작됩니다. 사용자가 어떤 방식으로 가입할지, 관리자가 어떤 정보를 수정할지, 결제와 알림을 어디까지 포함할지 정해지지 않았다면 견적의 숫자보다 변경 조건이 더 중요한 판단 기준이 됩니다.
앱 개발 외주 계약의 핵심은 모든 내용을 처음부터 고정하는 데 있지 않습니다. 바뀌어도 되는 영역과 계약 후 바뀌면 비용과 일정에 영향을 주는 영역을 분리하고, 그 기준을 문서로 남기는 일에 가깝습니다.
총액보다 먼저 쪼개야 할 개발 범위
초기 단계에서는 기능 목록이 있어도 실제 개발 범위가 충분히 정리되지 않은 경우가 많습니다. 예를 들어 “회원 가입”이라는 항목 하나에도 이메일 가입인지, 소셜 로그인인지, 가입 후 승인 절차가 있는지, 관리자가 계정을 정지할 수 있는지가 포함될 수 있습니다.
이때 기능명을 한 줄로 적으면 업체마다 서로 다른 범위를 상상하게 됩니다. 같은 회원 가입 기능이라도 앱 화면만 포함한 견적과 API, 데이터베이스, 관리자 웹을 포함한 견적은 작업량과 운영 준비 수준이 달라집니다.
계약 전에는 기능을 다음 네 가지 층위로 나누는 편이 실무적입니다.
- 사용자 앱에서 사용자가 직접 수행하는 흐름
- 서버와 데이터베이스가 처리해야 하는 규칙
- 운영자가 관리하는 관리자 웹 기능
- 앱 출시 이후 필요한 배포와 운영 지원 범위
이 구분은 견적을 복잡하게 만들기 위한 것이 아닙니다. 어떤 기능이 빠졌는지보다, 빠진 기능이 앱 화면에만 해당하는지 운영 구조 전체에 영향을 주는지 판단하기 위해 필요합니다.
특히 MVP 외주 범위를 정할 때는 “나중에 추가할 기능”도 별도로 적어두는 편이 좋습니다. 지금 개발하지 않는다는 결정과, 해당 기능이 계약 범위에 포함되어 있다는 주장은 서로 다릅니다. 이 둘이 섞이면 계약 후 변경 요청이 추가 개발인지, 기존 범위의 보완인지 해석이 갈릴 수 있습니다.
고정해야 하는 것은 기능보다 운영 기준이다
고정가 개발 계약에서 먼저 고정할 항목은 화면 수나 버튼 수만이 아닙니다. 서비스가 어떤 상태에서 출시되어야 하는지, 운영자가 어떤 업무를 직접 처리할 수 있어야 하는지를 정하는 것이 더 중요합니다.
예를 들어 상품이나 콘텐츠를 운영자가 등록해야 하는 서비스라면 앱 화면만 구현해서는 운영이 끝나지 않습니다. 등록, 수정, 노출 중지, 상태 변경 같은 관리자 업무가 필요한지 정해야 합니다. 고객 문의나 신고가 발생할 수 있다면 해당 내용을 어디서 확인하고 처리할지도 범위에 들어갑니다.
계약 전에 다음 항목은 가능한 한 고정하는 것이 좋습니다.
- 첫 출시에서 반드시 작동해야 하는 핵심 사용자 흐름
- 계정과 주요 데이터의 기본 구조
- 관리자에게 필요한 최소 업무 기능
- 외부 서비스 연동의 대상과 책임 범위
- 앱스토어 출시를 위한 준비와 검수 범위
- 장애나 오류가 발생했을 때의 수정 기준
여기서 고정한다는 말은 세부 디자인을 모두 확정한다는 뜻이 아닙니다. 사용자의 핵심 목적과 운영자가 처리해야 할 업무를 고정하고, 색상이나 문구처럼 비교적 영향이 작은 요소는 조정 가능 영역으로 둘 수 있습니다.
반대로 결제 방식, 권한 체계, 데이터 보관 구조처럼 뒤늦게 바꾸면 여러 영역을 다시 손봐야 하는 항목은 초기 단계에서 결정하는 편이 안전합니다. 겉으로는 작은 요청처럼 보여도 앱, API, 데이터베이스, 관리자 웹에 동시에 영향을 줄 수 있기 때문입니다.
계약서에서 중요한 문장은 “무엇을 개발한다”보다 “어떤 상태를 범위 완료로 보는가”에 가깝습니다.
변경 가능한 범위와 비용이 생기는 변경을 나누는 기준
모든 변경을 추가 비용으로 처리하면 초기 기획이 부족한 팀에게 불리할 수 있습니다. 반대로 모든 변경을 기존 금액에 포함하면 개발 일정과 품질 관리가 흔들릴 가능성이 커집니다. 따라서 변경의 성격을 구분하는 기준이 필요합니다.
첫 번째 기준은 기존 구조를 유지한 채 수정할 수 있는지입니다. 버튼 문구, 안내 문장, 일부 화면 배치처럼 데이터 구조와 주요 사용자 흐름을 바꾸지 않는 변경은 조정 가능한 항목으로 협의할 수 있습니다.
두 번째 기준은 새로운 상태나 권한이 생기는지입니다. 기존에는 승인과 거절만 있었는데 보류 상태를 추가하거나, 일반 사용자만 있던 구조에 운영자와 제휴 담당자 권한을 나누면 서버 규칙과 관리자 화면까지 달라질 수 있습니다. 이런 변경은 단순한 화면 수정으로 보기 어렵습니다.
세 번째 기준은 외부 연동이나 심사 절차에 영향을 주는지입니다. 결제, 문자, 지도, 본인 인증처럼 외부 시스템을 연결하는 경우에는 연동 방식과 계정 준비 상태에 따라 작업 범위가 달라집니다. 스토어 심사에 영향을 주는 정책 변경도 출시 일정에 영향을 줄 수 있으므로 별도 협의 대상으로 남겨야 합니다.
네 번째 기준은 이미 완료된 작업을 되돌려야 하는지입니다. 화면을 다시 그리는 수준이 아니라 데이터베이스 구조나 API 계약을 변경해야 한다면 기존 작업의 재검토가 필요합니다. 이때는 변경 내용, 영향을 받는 범위, 일정 조정 여부, 추가 비용 산정 방식을 함께 기록하는 편이 좋습니다.
견적서에는 다음처럼 문장을 구체화할 수 있습니다. “화면 문구와 기본 배치는 협의 후 조정할 수 있다”와 “회원 권한 구조 변경은 별도 범위로 산정한다”는 서로 다른 종류의 변경을 구분해 줍니다. 반대로 “합리적인 범위의 수정 가능”처럼 해석의 여지가 큰 표현만 남기면 계약 후 기준을 다시 정해야 합니다.
견적서를 비교할 때 물어볼 질문
견적 금액을 비교하기 전에 각 업체에 같은 질문을 전달하면 포함 범위의 차이가 드러납니다. 중요한 것은 가장 낮은 금액을 찾는 것이 아니라, 현재 의사결정 단계에 맞는 범위를 고르는 일입니다.
먼저 “이 견적에 포함된 운영자 업무는 어디까지인가”를 물어야 합니다. 관리자 웹이 포함되어 있더라도 단순 목록 조회만 가능한지, 등록과 수정, 상태 변경까지 가능한지는 다를 수 있습니다.
다음으로 “변경 요청이 발생하면 어떤 기준으로 추가 작업으로 판단하는가”를 확인할 필요가 있습니다. 변경 비용의 산정 단위가 기능별인지, 작업 시간별인지, 별도 합의 방식인지에 따라 계약 후 의사결정 방식이 달라집니다.
“출시 이후 오류 수정과 기능 변경의 기준은 무엇인가”도 빠지면 안 됩니다. 앱이 실행되지 않거나 핵심 흐름이 동작하지 않는 문제와, 출시 후 새로운 정책을 반영하는 요청은 같은 변경으로 보기 어렵습니다. 두 항목을 나누어야 운영 단계에서 불필요한 갈등을 줄일 수 있습니다.
마지막으로 “아직 결정하지 않은 항목을 어떻게 관리할 것인가”를 물어보십시오. 미정 항목을 계약에서 제외할지, 임시 기준으로 포함할지, 다음 단계에서 확정할지에 따라 고정가 계약의 의미가 달라집니다.
계약 전 준비할 의사결정 문서
외주 업체와 대화하기 전에 긴 기획서를 완성할 필요는 없습니다. 대신 의사결정이 필요한 항목을 짧게라도 구분해 두면 견적 비교가 수월해집니다.
첫째, 첫 출시에서 사용자가 반드시 완료해야 하는 행동을 적습니다. 가입, 검색, 신청, 결제처럼 서비스의 핵심 흐름을 우선순위로 정하고 부가 기능은 뒤로 분리합니다.
둘째, 운영자가 출시 후 매일 처리할 업무를 적습니다. 어떤 데이터를 등록하고, 어떤 상태를 변경하며, 어떤 문의나 예외 상황을 직접 다뤄야 하는지 정리합니다.
셋째, 아직 정하지 못한 항목을 숨기지 않고 미정으로 표시합니다. 미정 상태를 공유해야 업체가 임의의 가정을 넣는 일을 줄일 수 있습니다. 동시에 각 미정 항목이 일정과 비용에 미칠 수 있는 영향도 질문할 수 있습니다.
넷째, 변경 요청이 생겼을 때 필요한 승인 절차를 정합니다. 누가 범위를 승인하는지, 변경 내용을 어떤 문서로 남기는지, 일정과 비용을 언제 다시 합의하는지 정해두면 개발 중 논의가 길어지는 상황을 줄일 수 있습니다.
앱 개발 외주 계약은 처음 받은 견적서의 총액을 선택하는 과정이 아닙니다. 현재 고정할 수 있는 범위를 정하고, 아직 검증되지 않은 가설은 변경 가능한 영역으로 남기며, 그 경계를 계약 문장으로 바꾸는 과정입니다. 범위가 완전히 확정되지 않은 초기 단계일수록 이 구분이 업체 선택보다 먼저 필요합니다.
현재 견적서에서 고정 범위와 변경 비용의 기준이 분리되어 있는지 판단하기 어렵다면, 앱의 핵심 흐름과 운영 범위를 기준으로 계약 전 구조를 함께 점검할 수 있습니다. 앱 개발 외주 범위 조율이나 MVP 개발 계획에 대한 상담이 필요하면 아래 경로로 문의해 주세요. https://www.universoft.kr/contact