계약·개발 진행 가이드

앱개발업체 선정 후 첫 회의에서 꼭 확정할 8가지

앱개발업체를 정한 뒤 첫 착수회의에서 목표, 출시 범위, 담당자, 검수일, 계정 소유와 변경 절차를 합의하는 방법을 정리합니다.

약 7분처음 앱을 만드는 분을 위한 안내
앱 개발 첫 회의에서 목표부터 계정 소유까지 여덟 가지를 확정하는 체크리스트
01

계약이 끝나면 개발이 바로 시작되는 것은 아닙니다

앱개발업체를 선정하고 계약서에 서명해도 서로 생각하는 첫 결과물이 다르면 일정은 곧 흔들립니다. 고객은 완성된 앱을 떠올리지만 개발업체는 화면 설계, 데이터 구조와 계정 준비부터 시작할 수 있습니다. 첫 회의의 목적은 아이디어를 다시 설명하는 것이 아니라 누가, 무엇을, 언제까지 결정하고 확인할지 같은 기준으로 맞추는 것입니다.

어플제작업체와 첫 회의를 준비한다면 기능 목록만 보내기보다 아래 여덟 가지를 회의 결과로 남기세요. 모든 답을 회의 전에 정할 필요는 없지만, 미정인 항목의 담당자와 결정일은 정해야 합니다.

02

1. 이번 개발의 목표와 성공 기준을 한 문장으로 정합니다

‘좋은 앱을 만든다’는 목표는 우선순위를 정하는 기준이 되기 어렵습니다. 첫 출시에서 사용자가 완료해야 할 핵심 행동과 사업자가 확인할 결과를 함께 적어야 합니다.

사용자 목표

예를 들어 예약 서비스라면 고객이 가능한 시간을 찾고 예약을 완료하는 것까지가 사용자 목표가 될 수 있습니다.

운영 목표

운영자는 예약을 확인하고 담당자를 배정하며 변경과 취소를 처리할 수 있어야 합니다. 두 목표가 함께 있어야 고객 화면만 완성되고 운영이 막히는 상황을 줄일 수 있습니다.

회의록 첫 줄에 ‘누가 어떤 행동을 완료하면 첫 출시가 성공인가’를 한 문장으로 남기세요.

03

2. 첫 출시 범위와 다음 버전을 나눕니다

기능 목록에는 꼭 필요한 기능, 있으면 좋은 기능과 나중에 검증해도 되는 기능이 섞여 있습니다. 첫 회의에서는 각 기능을 첫 출시, 다음 버전, 검토 보류로 구분합니다.

범위를 줄이는 것은 기능을 포기하는 일이 아닙니다. 첫 출시일을 지키고 다음 개발의 근거를 확보하는 결정입니다.

첫 출시와 다음 버전, 검토 보류를 담당자와 결정일로 나눈 범위표
기능을 첫 출시·다음 버전·검토 보류로 나누고 담당자와 결정일을 적습니다.

확인해보세요

  • 첫 출시 없이는 핵심 행동을 완료할 수 없는가?
  • 운영자가 수작업으로 보완할 수 있는가?
  • 실제 사용 데이터를 본 뒤 결정해도 되는가?
  • 외부 승인이나 별도 계약이 필요한가?
04

3. 사용자 역할과 관리자 권한을 함께 정합니다

고객, 판매자, 전문가, 담당자처럼 역할이 여러 개인 서비스는 같은 화면을 누가 볼 수 있는지부터 정해야 합니다. ‘회원관리’라는 기능도 일반 직원이 볼 수 있는 정보와 최고 관리자가 수정할 수 있는 정보가 다릅니다.

사용자 역할

가입 방식, 볼 수 있는 정보, 신청하거나 취소할 수 있는 범위를 역할별로 정합니다.

관리자 역할

조회, 승인, 수정, 환불, 내보내기와 계정 관리 권한을 구분합니다. 중요한 변경은 누가 언제 처리했는지 기록할지도 결정합니다.

05

4. 고객과 개발업체의 담당자를 한 명씩 정합니다

여러 사람이 서로 다른 의견을 전달하면 개발업체는 어느 요청이 최종 결정인지 알기 어렵습니다. 고객사에서는 최종 승인 담당자와 자료 전달 담당자를 정하고, 개발업체에서는 일정과 범위를 조율할 창구를 명확히 해야 합니다.

회의 참석자가 많아도 최종 의견은 지정된 창구를 통해 한 번에 전달하는 것이 좋습니다.

확인해보세요

  • 고객사 최종 승인자
  • 기능·화면 의견 취합자
  • 문구·이미지·약관 자료 담당자
  • 개발업체 프로젝트 담당자
  • 긴급 이슈 연락 방법
06

5. 자료 전달일과 미정 항목의 결정일을 적습니다

로고, 화면 문구, 실제 상품 데이터, 약관과 외부 서비스 계정은 모두 필요한 시점이 다릅니다. 자료가 늦어지면 개발이 멈추는지, 임시 자료로 진행할 수 있는지도 구분합니다.

시작 전에 필요한 자료

브랜드 원본, 사용자 역할, 핵심 정책처럼 구조를 바꾸는 자료입니다.

화면 확정 전에 필요한 자료

버튼 문구, 상품·서비스 예시, 이미지와 빈 화면 안내처럼 실제 화면을 검수할 자료입니다.

출시 전에 필요한 자료

스토어 설명, 개인정보 처리방침, 심사 계정과 고객 문의 정보처럼 공개에 필요한 자료입니다.

07

6. 중간 검수일과 확인 대상을 일정에 넣습니다

‘완성되면 확인’하는 방식은 수정이 한꺼번에 몰릴 수 있습니다. 화면 흐름, 핵심 기능, 외부 연동, 출시 준비를 나눠 확인하고 각 단계에서 무엇을 승인해야 다음으로 넘어가는지 정합니다.

검수일에는 정상 화면만 보는 것이 아니라 권한 없음, 데이터 없음, 실패와 취소 상황도 함께 확인해야 합니다.

착수부터 출시 준비까지 고객 승인과 자료 전달 시점을 연결한 검수 일정
개발 일정에 자료 전달과 고객 검수·승인 시점을 함께 배치합니다.

확인해보세요

  • 화면 흐름 확인일
  • 핵심 기능 확인일
  • 관리자와 데이터 확인일
  • 통합 검수 시작일
  • 스토어 제출 준비일
08

7. 소스코드·서버·스토어 계정의 소유와 접근을 정합니다

서비스를 오래 운영하려면 결과물뿐 아니라 계정에 접근할 수 있어야 합니다. 가능한 항목은 운영 주체 명의로 만들고 개발업체에는 필요한 권한을 부여하는 방식이 안전합니다.

계정 소유와 비밀번호 공유는 같은 문제가 아닙니다. 공동 비밀번호보다 사용자별 권한과 회수 방법을 정하세요.

확인해보세요

  • 소스코드 저장소와 전달 시점
  • 서버·데이터베이스 계정과 결제 수단
  • 도메인과 이메일 발송 계정
  • Apple·Google 개발자 계정
  • 결제·문자·지도 등 외부 서비스 계정
  • 디자인 원본과 사용한 유료 자산의 조건
09

8. 변경 요청과 추가 비용의 확인 절차를 정합니다

개발 중 새로운 아이디어가 생기는 것은 자연스럽습니다. 문제는 요청을 바로 개발로 받아들여 기존 일정과 비용이 바뀌는지 확인하지 않는 경우입니다.

요청이 들어오면 기존 계약 범위, 약속한 기능의 오류, 기존 기능의 변경, 신규 기능 중 어디에 해당하는지 먼저 표시합니다. 그 다음 앱 화면, 관리자, 서버, 외부 연동과 일정에 미치는 영향을 확인하고 고객의 승인을 받은 뒤 반영합니다.

요청서를 보냈다는 사실만으로 개발 일정과 비용이 확정되는 것은 아닙니다. 영향 확인과 승인 기록까지가 변경 절차입니다.

10

첫 회의가 끝나기 전에 남겨야 할 결과

회의 시간보다 결과물이 중요합니다. 아래 항목이 한 문서나 협업 공간에 남아 있으면 다음 회의부터 같은 기준으로 판단할 수 있습니다.

첫 회의에서 모든 세부 화면을 확정하려고 하기보다, 결정을 만드는 순서와 책임을 확정하세요. 그 기준이 있어야 앱개발업체와 고객이 같은 범위와 일정으로 프로젝트를 시작할 수 있습니다.

확인해보세요

  • 프로젝트 목표 한 문장
  • 첫 출시와 다음 버전 기능 목록
  • 사용자·관리자 역할표
  • 고객사·개발업체 담당자
  • 자료별 전달일과 미정 항목 결정일
  • 단계별 검수일과 승인자
  • 계정·결과물 소유 및 접근 방식
  • 변경 요청의 검토·승인 절차

무료 요구사항 문서

업체에 보낼 개발 요청서를 완성해보세요

서비스 목표와 사용자, 핵심 기능, 관리자 업무, 납품 조건을 질문에 답하며 정리하고 문서로 저장할 수 있습니다.

결과 확인에는 연락처가 필요하지 않고, 상담을 신청할 때만 결과 포함 여부를 직접 선택합니다.

RFP·요구사항 작성하기

30분 무료 전화 상담

내 상황에 맞는 개발 방향을 함께 확인하세요

앱개발업체를 정한 뒤 첫 착수회의에서 목표, 출시 범위, 담당자, 검수일, 계정 소유와 변경 절차를 합의하는 방법을 정리합니다.

앱 개발 착수 범위 30분 무료 상담
전체 개발 가이드로 돌아가기