앱 개발 견적서 총액 말고 먼저 봐야할 항목들

견적서 한 장을 받아 들고 맨 아래 총액만 한참 들여다보신 경험, 아마 있으실 겁니다. 숫자는 분명한데 그 위에 줄줄이 적힌 항목이 무엇을 뜻하는지, 이 값이 비싼 건지 싼 건지 가늠할 잣대가 없으니 답답해집니다.

그래서 보통 두세 군데에 같은 내용을 보내고 총액을 줄 세워 보시는데, 여기서 또 한 번 당황하십니다. 분명 같은 요청을 했는데 어느 곳은 다른 곳의 두 배, 세 배를 부르기 때문입니다.

이 간극은 대부분 업체들이 서로 다른 것을 견적했기 때문에 생깁니다. 오늘은 앱 개발 견적서가 어떤 뼈대로 짜이는지, 항목 하나하나에서 무엇을 짚어야 하는지, 그리고 여러 장을 놓고 비교할 때 어디부터 맞춰봐야 하는지 순서대로 풀어 드리겠습니다.

 

견적의 본질은 인력의 시간입니다

항목을 보기 전에 이 한 가지만 머릿속에 두시면 견적서가 다르게 보입니다.

앱을 만드는 데는 자재가 들지 않습니다. 대신 사람이 들어갑니다. 기획하는 사람이 며칠, 화면을 그리는 사람이 며칠, 코드를 짜는 사람이 몇 주를 쓰느냐가 그대로 금액이 됩니다.

따라서 견적서의 밑바탕은 어떤 인력이 얼마 동안 어떤 단가로 투입되는가입니다. 겉으로는 화면 몇 장, 기능 몇 개로 표기되어 있어도 그 뒤에서는 이 셈법이 돌아가고 있습니다.

이 원리를 아시면 업체에 던지는 질문 자체가 바뀝니다. 왜 이렇게 나왔느냐 대신, 어떤 역할의 인력이 몇 명, 몇 주 동안 붙는지를 물으시게 됩니다. 이 질문에 또렷하게 답하는 견적일수록 믿어도 되는 견적입니다.

 

견적서를 구성하는 기본 항목

명칭은 회사마다 제각각이지만, 뜯어보면 대개 다음 갈래로 정리됩니다.

기획과 설계 — 요구사항을 문서로 굳히고, 화면 흐름과 기능을 정의하는 단계

디자인 — 화면 시안과 아이콘, 색·글꼴 같은 디자인 가이드

앱 화면 구현(프론트엔드) — 사용자가 실제로 만지는 안드로이드·iOS 화면

서버 구현(백엔드) — 데이터를 저장하고 처리하는 API와 데이터베이스

관리자 화면 — 운영자가 회원·주문·콘텐츠를 다루는 웹 페이지

테스트와 안정화 — 기기별 확인, 버그 잡기

출시 지원 — 스토어 등록과 심사 대응

프로젝트 관리 — 일정 조율과 커뮤니케이션

여기서 보셔야 할 것은 무엇이 들어 있느냐보다 무엇이 빠져 있느냐입니다. 눈에 띄게 저렴한 견적이라면 위 갈래 중 몇 개가 아예 없을 확률이 높습니다.

빠지기 쉬운 단골은 관리자 화면, 테스트, 출시 지원 세 가지입니다. 셋 다 결국에는 반드시 필요해지는 항목이라, 처음 견적에서 누락되면 진행 중에 추가 비용이라는 이름으로 다시 등장합니다.

 

같은 앱인데 금액이 갈리는 지점

똑같은 서비스를 만들더라도 조건 몇 가지에 따라 견적은 크게 출렁입니다. 어떤 변수가 금액을 움직이는지 알아두시면 예산에 맞춰 조정하실 때 요긴합니다.

운영체제 범위 — 안드로이드 하나인지, iOS까지 두 플랫폼인지

화면 개수 — 화면이 하나 늘면 디자인과 개발이 동시에 늘어납니다

회원 체계 — 가입, 로그인, 카카오·구글 같은 소셜 로그인은 의외로 품이 많이 듭니다

결제 — PG 연동에 환불 흐름까지 붙으면 금액이 뛰어오릅니다

실시간 요소 — 채팅과 푸시 알림은 서버 설계가 한 단계 복잡해집니다

외부 시스템 연동 — 지도, 본인인증, 기존 사내 시스템과의 연결

디자인 완성도 — 기성 템플릿 수준인지, 브랜드에 맞춘 전용 디자인인지

견적을 요청하기 전에 이 항목들을 미리 정해서 넘겨주시면 모든 업체가 같은 잣대로 계산합니다. 반대로 요구사항이 흐릿한 상태로 보내시면 업체마다 제멋대로 해석하게 되고, 결국 서로 비교가 안 되는 견적서만 세 장 손에 남습니다.

 

총액 밑에서 꼭 짚어야 할 5가지

숫자 아래쪽을 읽으실 때 놓치면 안 되는 대목입니다.

기능 목록 첨부 여부 — 무엇을 만들기로 했는지 문서로 남아야 나중에 말이 안 엇갈립니다

수정 횟수 명시 여부 — 디자인 시안은 몇 번, 기능 변경은 몇 번까지 견적에 포함되는지

단계별 일정 유무 — 총 기간 하나만 적혀 있으면 중간에 점검할 기준이 없습니다

대금 지급 기준 — 날짜에 맞춰 내는지, 단계 완료를 기준으로 내는지

하자보수 기간 — 출시 뒤 몇 개월까지 무상으로 고쳐 주는지

이 다섯 가지 가운데 빈칸이 있다면 바로 질문해 보시길 권합니다. 즉시 명확한 답이 돌아오는지, 아니면 말끝을 흐리는지에서 그 업체의 실력과 태도가 상당 부분 읽힙니다.

 

개발비 말고 매달 나가는 돈도 확인하세요

견적서에 적힌 금액은 보통 스토어에 올라가는 시점까지입니다. 하지만 앱은 출시한 날부터 진짜 운영이 시작됩니다.

출시 뒤에도 꾸준히 지출되는 항목이 있습니다.

서버 사용료 — 이용자가 늘어날수록 같이 커집니다

도메인과 SSL 인증서 갱신비

애플 개발자 계정 연회비와 구글 플레이 등록 비용

외부 서비스 요금 — 문자 발송, 지도 API, 본인인증 등

유지보수비 — 장애 대응, 운영체제 업데이트 대응

이 부분을 짚고 넘어가지 않으시면 출시 다음 달 청구서에서 낯선 금액을 마주하게 됩니다. 견적을 받으시는 자리에서 매달 운영비가 대략 어느 정도인지 함께 물어보시는 것이 좋습니다.

 

유독 싼 견적, 이유부터 물어보세요

여러 곳 중 한 곳만 눈에 띄게 낮은 금액을 제시할 때가 있습니다. 무턱대고 걸러내실 필요는 없지만, 왜 싼지는 반드시 확인하셔야 합니다.

금액이 내려가는 경로는 크게 셋입니다. 예전에 만들어 둔 코드를 다시 쓰는 경우, 기능 범위를 좁게 잡은 경우, 그리고 다른 곳에 재하청을 줘서 단가를 낮춘 경우입니다.

앞의 두 경로는 상황에 따라 충분히 합리적일 수 있습니다. 걱정되는 쪽은 마지막입니다. 재하청 구조에서는 요구사항이 한 단계를 거치면서 원래 의도가 희미해지고, 사소한 수정 하나에도 며칠씩 걸리는 일이 생깁니다.

그러니 미팅 자리에서 개발을 직접 하시는지, 외부에 맡기시는지를 한 번은 물어보시길 권합니다. 대답하는 태도와 구체성만으로도 꽤 많은 것이 드러납니다.

 

예산이 모자랄 때 줄일 수 있는 곳

받아 든 견적이 잡아둔 예산을 넘는 일은 흔합니다. 이럴 때 막연히 깎아 달라고 하시기보다, 어느 부분을 덜어낼 수 있는지 아시면 훨씬 건설적인 대화가 됩니다.

핵심 기능만 1차로 출시 — 비용과 기간이 동시에 줄어듭니다 / 단, 나중에 붙일 기능을 미리 설계에 반영해야 합니다

플랫폼 하나로 시작 — 개발량이 크게 줄어듭니다 / 단, 고객이 어느 운영체제를 많이 쓰는지 먼저 확인하세요

앱 대신 웹으로 먼저 — 설치 없이 빠르게 반응을 볼 수 있습니다 / 단, 푸시 알림에는 제약이 있습니다

기본 디자인 적용 — 디자인 비용이 절감됩니다 / 단, 브랜드 인상은 약해집니다

관리자 화면 축소 — 개발량이 줄어듭니다 / 단, 운영이 번거로워질 수 있습니다

이 중 가장 추천드리는 방법은 첫 번째입니다. 처음부터 기능을 전부 담으려 하시면 비용도 일정도 불어나는데, 막상 출시해 보면 거의 안 쓰이는 기능이 꼭 나옵니다.

핵심만 담아 먼저 내보내고 실제 사용자 반응을 본 뒤 넓혀 가시는 쪽이, 같은 돈으로 더 좋은 서비스를 만드는 길입니다.

단, 이 방식을 택하실 때는 나중에 추가할 기능을 처음부터 업체에 알려주셔야 합니다. 알고 설계하면 확장이 수월하지만, 뒤늦게 얹으려면 구조를 다시 뜯어야 하는 상황이 생기기 때문입니다.

 

견적서 여러 장을 나란히 놓고 볼 때

몇 곳의 견적서를 펼쳐 놓고 비교하실 때 따라가시면 좋은 순서입니다.

1. 기능 목록부터 맞춰봅니다 — 애초에 같은 것을 견적했는지 확인하는 단계입니다

2. 누락 항목에 표시합니다 — 관리자 화면, 테스트, 출시 지원이 들어 있는지

3. 일정을 견줘봅니다 — 유난히 짧다면 무엇을 건너뛰었는지 물어봅니다

4. 수정 횟수와 하자보수 조건을 봅니다 — 총액이 같아도 여기서 승부가 갈립니다

5. 출시 후 운영비를 더합니다 — 개발비만으로는 실제 총비용이 보이지 않습니다

이 순서로 정리해 보시면 처음 총액 순위가 뒤집히는 경우가 적지 않습니다. 가장 싸 보였던 견적이 빠진 항목을 채워 넣는 순간 가장 비싼 견적으로 바뀌기도 합니다.

 

궁금해하시는 것들

Q. 견적 요청 전에 무엇을 갖춰야 하나요?

A. 앱의 목적, 핵심 기능 목록, 지원할 운영체제, 희망 일정과 예산 범위를 정리해 주시면 충분합니다. 벤치마킹할 만한 앱이 있으면 같이 알려주시면 업체 간 해석 차이가 확 줄어듭니다.

Q. 왜 업체마다 금액이 이렇게 다른가요?

A. 요구사항을 저마다 다르게 읽었거나, 견적에 담긴 항목의 범위가 달라서인 경우가 대부분입니다. 총액이 아니라 기능 목록과 포함 항목을 나란히 놓고 보셔야 진짜 비교가 됩니다.

Q. 화면 수 기준 견적은 믿을 만한가요?

A. 대략의 규모를 가늠하기엔 유용하지만, 화면마다 담긴 기능의 난이도가 다릅니다. 화면 수와 더불어 기능 목록을 기준으로 확인하시는 편이 정확합니다.

Q. 견적에 없던 것을 중간에 요청하면요?

A. 계약 범위 밖 요청은 별도 견적으로 처리되는 것이 일반적입니다. 범위 밖 요청을 어떻게 다룰지 계약서에 미리 적어두시면 진행이 훨씬 부드럽습니다.

Q. 개발 기간은 어느 정도로 잡아야 하나요?

A. 기능 범위에 따라 편차가 큽니다. 다만 검수와 수정, 스토어 심사 기간까지 일정에 넣어야 하므로, 개발 기간만 보고 출시일을 정하시면 대부분 늦어집니다.

 

핵심만 다시 정리하면

하나, 앱 개발비의 실체는 사람의 시간이니 어떤 인력이 몇 명, 얼마 동안 붙는지가 출발점입니다. 둘, 견적서에서는 총액보다 항목 구성과 누락된 항목을 보셔야 합니다. 셋, 기능 목록·수정 횟수·지급 조건·하자보수 기간은 반드시 문서로 있어야 합니다.

넷, 출시 뒤 매달 나가는 운영비를 같이 확인하시고, 다섯, 유난히 싼 견적은 그 까닭을 물어보시면 됩니다.

토리토시스템은 20년 경력의 개발진이 재하청 없이 직접 만듭니다. 견적 단계에서 기능 목록과 일정은 물론 출시 뒤 운영비까지 함께 짚어 드리기 때문에, 진행 중에 뜻밖의 비용이 튀어나오는 일이 드뭅니다. 구상 중이신 서비스를 들려주시면 꼭 필요한 구성부터 차근차근 안내해 드리겠습니다. 부담 없이 토리토시스템에 문의해 주세요.

토리토시스템 공식 홈페이지 바로가기