앱 개발 외주 견적 비교 — 빠진 범위와 인수 조건 확인법
한 업체는 "개발 완료"라고 쓰고 다른 업체는 기획, 디자인, QA, 배포를 따로 적습니다. 총액만 나란히 두면 어느 쪽이 비싼지 판단하기 어렵습니다. 먼저 같은 결과물을 견적받고 있는지부터 맞춰야 합니다.
견적서를 한 표에 놓기 전에
업체마다 아래 항목을 포함했는지 확인하세요.
- 결과물이 웹 앱인지, iOS·Android 앱까지 포함하는지
- 화면과 기능의 목록, 관리자 기능의 범위
- 디자인 원본과 반응형·접근성 작업의 포함 여부
- 기존 데이터 이전과 외부 서비스 연동
- 테스트, 보안 점검, 오류 수정의 범위
- 서버 배포와 앱 스토어 심사 대응
- 납품 뒤 보증 수정과 유상 유지보수의 조건
항목 하나가 빠지면 낮은 견적처럼 보여도 나중에 별도 비용이 될 수 있습니다. 반대로 필요 없는 플랫폼이나 운영 지원까지 포함되어 금액이 올라간 경우도 있습니다. 업체명과 총액 대신 포함·제외·가정 세 칸을 만들어 비교하는 편이 낫습니다.
프로토타입은 명세서가 아니라 대화 자료입니다
Claude Code, Codex, Cursor나 Lovable로 화면을 만들어 두었다면 원하는 동작을 말보다 정확하게 보여 줄 수 있습니다. 그렇다고 실행되는 화면이 곧 완성된 명세이거나, 기존 코드가 그대로 납품에 쓰일 수 있다는 뜻은 아닙니다.
특히 Lovable은 웹 애플리케이션을 만드는 도구입니다. PWA나 별도 래핑 경로는 있지만, 웹 프로토타입을 네이티브 iOS·Android 앱의 진척률로 바로 계산하면 안 됩니다.
프로토타입이 보여 주는 것과 아직 모르는 것을 나눠 적으세요.
이미 확인된 것
- 화면 흐름과 주요 문구
- 사용자가 해야 할 핵심 동작
- 선호하는 디자인 방향
아직 확인할 것
- 코드를 재사용할 수 있는지
- 모바일·브라우저별 동작과 접근성
- 인증, 권한, 결제의 안전성
- 테스트, 배포, 모니터링 구조
- 사용한 라이브러리와 자산의 라이선스
이 구분이 있으면 프로토타입을 과대평가하지 않으면서도, 이미 정한 요구를 다시 설명하는 일은 줄일 수 있습니다.
전체 견적을 받기 전에 짧은 유상 진단을 요청합니다
코드를 보지 않고 "기존 것의 80%를 살릴 수 있다"거나 "전부 다시 만들어야 한다"고 확정하기는 어렵습니다. 먼저 진단 범위와 산출물을 합의하세요.
진단에서는 최소한 다음을 확인하면 좋습니다.
- 새로 준비한 환경에서 README만 보고 설치하고 실행할 수 있는지
- 주요 화면과 기능이 현재도 작동하는지
- API 키 같은 민감정보가 코드나 로그에 노출되지 않았는지, 인증과 사용자별 권한에 눈에 띄는 문제가 없는지
- 테스트가 어디까지 있고 무엇이 수동 확인인지
- 의존성, 호스팅, 외부 계정과 라이선스가 무엇인지
결과는 유지해서 마무리, 일부 리팩터링, 재구축 세 가지 선택지로 나누고, 각 선택지의 범위·위험·일정을 견적받으세요. 프로토타입이 있다고 무조건 저렴해지는 것도, 코드가 거칠다고 가치가 없어지는 것도 아닙니다. 진단 뒤에 재사용 범위를 알 수 있습니다.
넘길 자료는 코드보다 조금 더 많습니다
개발자가 저장소를 받은 날 바로 실행해 볼 수 있게 다음 묶음을 준비합니다.
- 설치, 실행, 빌드 명령을 적은 README
- 필요한 환경변수 이름과 발급 위치, 실제 값은 별도 안전한 경로로 전달
- 화면·기능 목록과 현재 알려진 오류
- 테스트 계정과 테스트 절차
- 서버, 도메인, 결제, 분석, 스토어 계정 목록
- Git 저장소와 중요한 결정이 남은 커밋 기록
AI가 만든 중복 파일이나 쓰지 않는 코드가 보여도 인수 직전에 무작정 지우지는 마세요. 먼저 현재 동작 버전을 태그나 브랜치로 남기고, 삭제 대상은 진단 과정에서 확인하는 편이 안전합니다.
실제 값이 든 .env 파일과 API 키 같은 민감정보는 저장소에 커밋하지 않습니다. 필요한 변수 이름만 적은 .env.example은 값 없이 별도로 둡니다. 이미 키가 커밋됐다면 먼저 폐기하거나 교체한 뒤, 필요하면 Git 이력 정리를 검토하세요.
계약서에서 통제권을 확인합니다
납품 뒤 문구 하나를 바꿀 때도 업체를 거쳐야 하는 상황은 계정과 산출물의 소유가 불명확할 때 생깁니다. 계약 전에 다음 질문에 답을 받아 두세요.
- 소스 코드와 Git 이력은 어떤 저장소로 인도되나요?
- 도메인, 서버, 스토어, 결제 계정은 누구 명의로 만드나요?
- 디자인 원본, 폰트, 이미지, 유료 라이선스도 인도 대상인가요?
- 중간 검수는 어떤 기능 단위로 하고, 승인 기준은 무엇인가요?
- 범위 변경은 누가 어떤 방식으로 승인하며 비용은 어떻게 계산하나요?
- 납품 뒤 보증 수정과 유지보수는 어디까지인가요?
계정은 가능하면 발주자 명의로 만들고 업체에는 필요한 권한만 부여합니다. 기존 GitHub 저장소를 넘겨야 한다면 GitHub의 저장소 이전 절차와 이전 뒤 권한도 함께 확인하세요.
견적 요청은 이렇게 짧게 써도 됩니다
현재 웹 프로토타입과 Git 저장소가 있습니다.
목표 결과물: 반응형 웹 앱, 관리자 화면 포함
이번 견적 범위: 코드 진단, 인증·결제 검토, 배포, 인수 문서
제외 범위: 네이티브 iOS·Android 앱
납품물: 소스와 Git 이력, 배포 설정, README, 테스트 결과
먼저 유상 진단 후 유지·리팩터링·재구축 범위를 나눠 제안해 주세요.
업체마다 같은 문서를 보내고 질문과 답을 기록하세요. 가장 싼 견적보다, 빠진 범위와 인수 조건을 설명할 수 있는 견적이 비교하기 쉽습니다. 최종 선택 전에는 일정, 대금 지급 조건, 지식재산권과 라이선스 조항을 계약 전문가와 함께 확인하는 것도 고려하세요.