2026년 7월 16일 업데이트
앱 개발 견적을 세 곳에서 받았는데, 한 곳은 2천만 원대이고 다른 곳은 그 두 배를 부릅니다. 더 난감한 건 설명입니다. 모두 자기들이 기획도 잘하고, 개발도 잘하고, 유지보수도 잘한다고 말합니다.
첫 앱을 준비하는 비개발자 대표라면 여기서 막히는 게 당연합니다. 아직 없는 제품을, 서로 다른 설명과 가격만 보고 골라야 하니까요.
앱 개발사 선택 기준은 ‘좋아 보이는 회사’가 아닙니다. 미팅에서 한 약속을 결과물·문서·계정으로 확인할 수 있는 회사인가입니다.
먼저 결론부터 말하겠습니다. 현재 운영 중인 유사 앱, 실제 투입 인력, 견적의 제외 범위, 중간 데모, QA 조건, 소스와 계정 인계, 출시 후 대응. 이 일곱 가지를 같은 질문으로 비교하면 가격표 뒤에 가려진 차이가 보입니다.
개발사를 만나기 전, 같은 한 장부터 보내세요
“배달앱 같은 걸 만들고 싶습니다”라는 말로 세 회사에 견적을 요청하면 세 회사는 서로 다른 앱을 상상합니다. 그 상태에서 받은 금액은 비교표가 아니라, 서로 다른 제품 세 개의 가격입니다.
긴 기획서까지는 필요 없습니다. 누가 쓰는 앱인지, 그 사람이 앱을 켜서 반드시 끝내야 하는 한 가지 행동이 무엇인지, 첫 버전에서 미룰 기능은 무엇인지 한 장으로 적어 보내세요.
예를 들어 예약 서비스라면 “고객이 날짜를 고르고 결제한 뒤 예약 확인을 받는다”가 핵심 흐름이 될 수 있습니다. 리뷰, 포인트, 추천 기능은 그다음 문제입니다. 아직 이 한 줄도 정하기 어렵다면 MVP 핵심 기능을 좁히는 순서부터 보는 편이 낫습니다.
같은 한 장을 보낸 뒤에야 견적 차이를 물을 수 있습니다. 이제부터는 회사 소개를 듣기보다 아래 질문을 하나씩 던지면 됩니다.
앱 개발사 선택 기준 7가지: 질문과 증거로 비교하세요
1. “지금 설치해 볼 수 있는 비슷한 앱이 있나요?”
포트폴리오의 로고나 화면 캡처만 보지 마세요. 앱스토어에서 현재 내려받을 수 있는지, 개발사가 그 프로젝트에서 기획·디자인·서버·앱 중 어디까지 맡았는지 확인해야 합니다.
비슷한 업종이면 더 좋지만, 이름만 비슷하다고 충분한 것은 아닙니다. 결제, 예약, 정산, 위치, 다중 권한처럼 이번 앱의 어려운 흐름을 실제로 운영해 본 경험인지가 중요합니다.
확인할 증거: 스토어 주소, 실제 수행 범위, 출시 뒤 업데이트 이력.
위험 신호: 앱은 보여주지 못하면서 유명 고객사 로고와 화면 이미지만 반복합니다.
2. “계약 다음 날부터 누가 제 앱을 만드나요?”
영업 미팅을 잘한 사람과 실제 PM·개발자는 다를 수 있습니다. 계약 전에 PM과 기술 책임자의 이름, 역할, 투입 기간을 물어보세요. 담당자가 바뀌면 누가 어떤 문서로 인수인계하는지도 함께 확인합니다.
외부 인력과 협업한다는 사실만으로 탈락시킬 필요는 없습니다. 문제는 구조를 숨기는 경우입니다. 누가 어떤 부분을 만들고, 품질과 일정의 최종 책임을 어느 회사가 지는지가 선명해야 합니다.
확인할 증거: 역할이 적힌 팀 구성표, 실제 담당자와의 미팅, 인수인계 방식.
위험 신호: “계약하면 배정됩니다”라는 답만 있고 책임자를 특정하지 못합니다.
3. “이 견적에 들어가지 않은 것은 무엇인가요?”
포함 항목보다 제외 항목을 먼저 물으면 견적 차이가 빨리 드러납니다. 관리자 화면, 디자인 원본, 앱스토어 등록, 서버 설정, 분석 도구, 테스트 기기, 운영 문서, 외부 API 사용료가 빠져 있지는 않은지 확인하세요.
“앱 개발 일체”라는 한 줄은 편해 보이지만 완료 장면을 설명하지 못합니다. 기능마다 어떤 결과물을 받고, 어느 시점에 비용을 지급하는지가 연결되어야 합니다.
확인할 증거: 제외 범위, 단계별 산출물, 외부 서비스 비용을 구분한 견적서.
위험 신호: 금액은 빠르게 말하지만 빠진 항목과 추가 비용 조건은 설명하지 않습니다.
4. “다음 주 금요일에는 제가 무엇을 직접 볼 수 있나요?”
완성일에 앱을 한 번에 받는 방식은 방향이 틀렸을 때 가장 비싸게 고치는 방식입니다. 화면 흐름, 클릭 가능한 시안, 핵심 기능 데모, 테스트 버전처럼 중간에 직접 확인할 결과물과 날짜가 있어야 합니다.
주간 보고를 한다는 말만으로는 부족합니다. 지난주 완료 항목, 다음 주 계획, 늦어진 이유, 대표가 결정해야 할 일이 한 화면에 보여야 합니다. 이슈를 말로 흘리지 않고 기록하는 도구도 필요합니다.
확인할 증거: 데모 일정, 보고서 예시, 이슈 기록 방식.
위험 신호: 진행률은 숫자로 보고하지만 작동하는 결과물은 끝까지 보여주지 않습니다.
견적은 받았지만 범위와 비교 기준이 아직 흐리다면, 개발 전에 사업 구조부터 점검해보세요 →
5. “무엇이 되면 검수 합격인가요?”
“정상 작동하면 완료”는 검수 조건이 아닙니다. 회원가입이라면 인증 실패와 중복 가입까지, 결제라면 성공뿐 아니라 취소·오류·재시도까지 확인해야 합니다. 지원할 휴대전화와 운영체제, 네트워크가 불안정할 때의 동작도 범위에 들어갑니다.
모든 예외를 계약 전에 찾는 건 불가능합니다. 대신 핵심 사용자 흐름, 오류의 심각도, 수정 뒤 재검수 순서를 합의하면 됩니다. 보안이 중요한 앱이라면 어떤 기준으로 점검하는지 묻고, 모바일 앱 보안의 공개 기준인 OWASP MASVS처럼 확인 가능한 기준을 제시하는지도 보세요.
확인할 증거: 핵심 흐름별 테스트 항목, 지원 환경, 오류 등급과 재검수 절차.
위험 신호: “QA팀이 알아서 합니다”라고만 하고 테스트 범위와 결과를 공유하지 않습니다.
6. “잔금을 치른 뒤 다른 팀도 이 앱을 운영할 수 있나요?”
소스코드 파일 하나만 받는다고 인계가 끝나지 않습니다. 디자인 원본, 데이터베이스 구조, 배포 방법, 관리자 계정, 클라우드, 도메인, 앱스토어, 분석 도구, 소스 저장소까지 다음 담당자가 이어받을 수 있어야 합니다.
그리고 권리는 따로 봐야 합니다. 외주비를 지급했다는 사실만으로 대표가 생각한 모든 이용·수정 권리가 자동으로 정리된다고 가정하지 마세요. 권리 귀속 또는 이용 범위와 인계 시점을 계약서에 적어야 합니다. 컴퓨터프로그램을 저작물로 다루는 현행 기준은 국가법령정보센터 저작권법에서 확인할 수 있습니다.
확인할 증거: 인계 목록, 계정 소유자, 권한 회수일, 운영 문서, 계약서의 권리 조항.
위험 신호: 핵심 계정이 모두 개발사 명의이고 종료 때 넘길 항목을 지금 정할 필요가 없다고 말합니다.
7. “출시 다음 날 오류가 나면 어디까지 대응하나요?”
앱은 출시일에 끝나는 납품물이 아닙니다. 이미 합의한 기능의 오류를 고치는 하자 대응과 새 기능을 만드는 유지보수부터 구분해야 합니다. 긴급 장애 연락 경로, 응답 시간, 비용 산정 방식도 따로 물어보세요.
앱스토어 정책과 운영체제는 바뀝니다. Apple의 App Review Guidelines와 Google Play의 Developer Program Policies처럼 공식 정책을 누가 확인하고 업데이트에 반영할지도 운영 범위에 포함되어야 합니다.
개발사가 실제 고객정보에 접근한다면 목적과 범위, 안전조치, 종료 뒤 반환·파기까지 문서로 정해야 합니다. 관련 원칙은 개인정보 보호법 제26조에서 확인할 수 있습니다.
확인할 증거: 하자·유지보수 구분표, 장애 연락망, 응답 기준, 정책 업데이트 담당, 데이터 처리 문서.
위험 신호: “출시 후에도 잘 봐드립니다”라는 말만 있고 기간·범위·비용이 없습니다.
미팅이 끝나면 회사마다 세 줄만 남기세요
긴 점수표보다 세 줄이 더 잘 남습니다.
확인된 증거 하나. 지금 설치한 유사 앱, 이름이 적힌 담당자, 날짜가 있는 데모 일정처럼 실제로 본 것을 씁니다.
아직 풀리지 않은 위험 하나. 관리자 화면이 견적에 없는지, 인계 계정이 개발사 명의인지, QA 범위가 비어 있는지 적습니다.
계약 전 조건 하나. 제외 범위 보완, 담당자 미팅, 검수 문서 첨부처럼 계약 전에 해결할 일을 씁니다.
그리고 다시 가격을 봅니다. 이 순서를 거치면 가장 싼 회사가 남을 수도 있습니다. 그건 문제가 아닙니다. 무엇이 빠져서 싼 것인지, 같은 범위에서 정말 효율적인 것인지 설명할 수 있다면 합리적인 선택입니다.
개발사에 그대로 읽어도 되는 10문장
1. 지금 설치해 볼 수 있는 유사 앱과, 그 프로젝트에서 직접 맡은 범위를 보여주세요.
2. 계약 뒤 실제 PM과 기술 책임자는 누구이며 얼마나 투입되나요?
3. 외부 인력이 참여한다면 어느 부분이고 최종 책임은 누가 지나요?
4. 이번 견적에서 빠진 기능과 별도 비용 항목은 무엇인가요?
5. 제가 처음 직접 확인할 수 있는 결과물과 날짜는 언제인가요?
6. 요구사항이 바뀌면 비용과 일정을 누가, 어떤 기록으로 승인하나요?
7. 검수 합격은 어떤 사용자 흐름과 기기에서 판단하나요?
8. 잔금 지급일에 넘겨받는 파일·문서·계정 목록을 보여주세요.
9. 하자 수정과 유상 유지보수는 어떤 기준으로 나뉘나요?
10. 출시 뒤 긴급 장애가 생기면 연락 경로와 응답 기준은 무엇인가요?
자주 묻는 질문
가장 저렴한 앱 개발사를 고르면 안 되나요?
낮은 가격 자체가 문제는 아닙니다. 같은 기능, 산출물, 담당 인력, 검수, 인계 범위로 맞춘 뒤 비교해야 실제 가격 차이를 알 수 있습니다. 먼저 제외 항목을 확인하세요.
재하청을 쓰는 개발사는 무조건 피해야 하나요?
외부 전문 인력과 협업한다는 사실만으로 품질을 단정할 수는 없습니다. 다만 누가 어떤 부분을 맡고, 보안과 품질을 어떻게 관리하며, 일정과 결과의 최종 책임을 누가 지는지는 계약 전에 공개되어야 합니다.
외주비를 지급하면 소스코드 권리는 자동으로 우리 회사에 오나요?
자동으로 원하는 범위까지 정리된다고 가정하면 안 됩니다. 소스코드와 디자인 원본의 권리 귀속 또는 이용 범위, 수정·재개발 가능 범위, 인계 시점을 계약서에 구체적으로 적으세요. 복잡한 권리는 법률 검토가 필요합니다.
유지보수는 개발 계약에 기본으로 포함되나요?
계약마다 다릅니다. 이미 합의한 기능의 오류를 고치는 하자 대응과 새 기능을 추가하는 유지보수를 구분하고, 기간·응답 시간·비용 산정 방식을 각각 확인해야 합니다.
좋은 회사는 약속을 구체적으로 만드는 회사입니다
“다 됩니다”라는 대답은 계약 전에는 편안합니다. 프로젝트가 시작되면 가장 해석하기 어려운 말이 되기도 합니다.
좋은 개발사는 모르는 것을 모른다고 말하고, 가능한 범위를 문서로 좁히고, 중간 결과물을 보여주고, 끝난 뒤 넘길 것까지 먼저 설명합니다. 결국 선택 기준은 화려한 소개가 아니라 확인 가능한 약속입니다.
개발사 후보는 정했지만 사업 범위와 자금 집행 순서가 여전히 엉켜 있다면 계약부터 서두르지 않아도 됩니다.