웹·앱 개발 비용과 기간은 어떻게 정해지나

견적은 어떻게 계산되나

웹·앱 개발 견적의 기본 구조는 단순합니다. 투입 인력 × 투입 기간입니다. 개발은 재료비가 거의 없는 일이고, 원가의 대부분이 사람의 시간입니다. 그래서 견적서에 적힌 금액은 결국 ‘어떤 역할의 사람이 몇 개월 붙느냐’를 돈으로 환산한 결과입니다.

업계에서는 이 단위를 인월(맨먼스)이라고 부릅니다. 개발자 한 명이 한 달 일하면 1인월입니다. 예를 들어 기획자가 0.5개월, 디자이너가 1개월, 개발자 한 명이 3개월 투입되는 프로젝트라면 합계 4.5인월이 되고, 여기에 역할별 단가를 곱한 뒤 프로젝트 관리 비용과 회사 운영비를 더해 최종 금액이 나옵니다.

하나의 프로젝트에는 보통 여러 역할이 관여합니다. 요구사항을 정리하고 화면 흐름을 설계하는 기획, 화면을 그리는 디자인, 사용자가 보는 화면을 실제로 동작하게 만드는 프론트엔드, 데이터와 로그인·결제 등 서버 로직을 담당하는 백엔드, 그리고 테스트와 일정 관리입니다. 규모가 작으면 한 사람이 여러 역할을 겸하고, 규모가 커지면 역할이 쪼개집니다. 역할이 쪼개질수록 소통 비용이 붙기 때문에, 인원이 두 배가 된다고 기간이 절반이 되지는 않습니다.

고정가 계약과 공수 정산 계약

같은 프로젝트라도 계약 방식에 따라 금액의 성격이 달라집니다. 고정가는 범위를 미리 확정하고 총액을 정하는 방식으로, 예산을 관리하기 쉽지만 요구사항이 바뀌면 별도 협의가 필요합니다. 업체 입장에서는 위험을 떠안는 구조라 예상치 못한 상황을 대비한 여유분이 금액에 포함되는 경우가 많습니다. 공수 정산은 실제 투입된 시간만큼 정산하는 방식으로, 범위가 유동적인 프로젝트에 맞지만 총액이 사전에 확정되지 않습니다. 어느 쪽이 옳다기보다, 요구사항이 얼마나 확정되어 있느냐에 따라 선택이 갈립니다.

견적서에 총액만 적혀 있고 인력 구성과 기간이 없다면 반드시 물어보시길 권합니다. 금액의 근거를 확인할 수 없으면 다른 업체 견적과 비교할 기준도 생기지 않습니다.

비용을 좌우하는 5가지 요소

견적 차이의 대부분은 아래 다섯 가지에서 발생합니다. 같은 ‘쇼핑몰’이라는 단어를 써도 이 다섯 가지가 다르면 금액은 몇 배씩 벌어집니다.

1. 화면 수

가장 직관적인 기준입니다. 화면 하나마다 디자인, 퍼블리싱, 데이터 연동, 테스트가 따라붙습니다. 다만 단순히 개수만 세면 안 됩니다. 목록 화면과 상세 화면처럼 구조가 비슷한 화면은 두 번째부터 비용이 크게 줄어드는 반면, 구조가 전혀 다른 화면은 개수 그대로 비용이 붙습니다. 모바일과 PC를 모두 지원해야 하면 반응형 대응 공수가 추가로 들어갑니다.

2. 기능 복잡도

화면 수가 같아도 그 안에서 무슨 일이 일어나는지에 따라 비용이 달라집니다. 내용을 보여 주기만 하는 화면과, 조건에 따라 계산하고 상태를 바꾸고 알림을 보내는 화면은 완전히 다른 작업입니다. 경험상 회원 관련 기능(가입·로그인·권한 구분), 결제, 예약·재고처럼 동시에 여러 사람이 같은 자원을 다투는 로직, 그리고 정산·통계는 겉보기보다 훨씬 많은 시간을 요구합니다. 예외 상황 처리 때문입니다. 결제가 도중에 끊겼을 때, 같은 시간대에 두 명이 동시에 예약했을 때 어떻게 할지를 모두 정의해야 하고, 그 정의가 곧 개발 시간입니다.

3. 디자인 수준

기성 템플릿을 사용하는지, 브랜드에 맞춰 처음부터 디자인하는지에 따라 차이가 큽니다. 템플릿 기반은 빠르고 저렴하지만 표현의 폭이 제한되고, 맞춤 디자인은 시안 작업과 수정 회차가 일정에 포함됩니다. 여기에 애니메이션, 인터랙션, 일러스트, 촬영 같은 요소가 들어가면 각각이 별도의 작업 단위가 됩니다. 디자인 시안 수정 횟수를 계약서에 명시해 두면 나중에 서로 얼굴 붉힐 일이 줄어듭니다.

4. 외부 연동 여부

결제(PG), 본인인증, 소셜 로그인, 지도, 문자·알림톡, 배송 추적, 회계 프로그램, 사내 기존 시스템 등 외부와 주고받는 지점이 늘어날수록 비용과 위험이 함께 늘어납니다. 연동 자체의 개발 시간도 있지만, 상대 서비스의 문서가 부실하거나 심사·승인 절차가 있는 경우 일정이 우리 손을 떠나는 것이 더 큰 변수입니다. 연동 대상이 몇 개인지는 견적 요청 단계에서 반드시 알려 주셔야 하는 정보입니다.

5. 관리자 기능

의외로 많이 누락되는 항목입니다. 사용자에게 보이는 화면만 생각하고 견적을 받았다가, 정작 운영을 시작하면 ‘상품을 어떻게 등록하나’, ‘주문을 어디서 확인하나’라는 문제에 부딪힙니다. 관리자 화면은 사용자 화면과 별개의 시스템이고, 프로젝트에 따라 전체 비용의 20~40%를 차지하기도 합니다. 초기에는 관리 화면을 최소한으로 만들고 일부는 수동으로 처리하는 선택도 가능하지만, 그 결정은 견적 단계에서 의식적으로 내려야 합니다.

규모별 대략적인 범위

아래 표는 유형별로 흔히 나타나는 화면 수와 기간의 범위입니다. 각 유형 안에서도 앞서 설명한 다섯 가지 요소에 따라 편차가 크므로, 절대적인 기준이 아니라 ‘내 프로젝트가 대략 어느 구간에 있는지’를 가늠하는 용도로 봐 주시기 바랍니다.

금액을 굳이 이야기하자면, 국내 시장에서 랜딩페이지는 수백만 원대, 소개형 웹사이트는 수백만 원에서 천만 원대, 회원과 게시판을 갖춘 웹서비스는 천만 원대에서 수천만 원대, 모바일 앱은 수천만 원 이상에서 논의되는 경우가 많습니다. 다만 이 숫자는 참고용 이상의 의미를 두기 어렵습니다. 같은 ‘모바일 앱’이라도 사진 공유 기능 하나만 있는 앱과 결제·정산·매장 관리가 붙은 앱은 완전히 다른 일이고, 실제 견적도 그만큼 달라집니다.

기간에 영향을 주는 것

일정이 밀리는 원인은 개발 속도보다 그 바깥에 있는 경우가 많습니다. 아래 세 가지는 발주하시는 쪽에서 관리할 수 있는 영역이고, 실제로 일정에 미치는 영향이 가장 큽니다.

• 고객 피드백 속도 — 디자인 시안 확인, 기능 검수, 최종 승인처럼 발주처의 결정이 필요한 지점이 프로젝트마다 여러 번 있습니다. 한 번의 확인이 사흘씩 지연되면 열 번이면 한 달입니다. 담당자를 한 명으로 정하고, 회신 기한을 서로 합의해 두는 것만으로 일정이 눈에 띄게 안정됩니다. 내부 의견이 여러 갈래로 나뉜 채 전달되면 수정이 반복되면서 기간과 비용이 함께 늘어납니다.
• 콘텐츠 준비 — 문구, 사진, 로고, 상품 정보, 약관, 사업자 정보 같은 실제 내용물은 개발사가 만들어 줄 수 없는 부분입니다. 개발은 다 끝났는데 넣을 내용이 없어서 출시가 몇 주씩 미뤄지는 경우가 생각보다 흔합니다. 개발 착수와 동시에 콘텐츠 준비도 같이 시작하시는 편이 좋습니다.
• 외부 연동 승인 — 결제 대행사 가입 심사, 본인인증 서비스 계약, 알림톡 발송 자격 심사, 앱스토어 개발자 계정 등록 등은 신청부터 승인까지 짧게는 며칠, 길게는 몇 주가 걸립니다. 이 절차들은 대부분 사업자 명의로 진행해야 하므로 개발사가 대신 처리할 수 없습니다. 프로젝트 초반에 목록을 만들어 미리 신청해 두는 것이 가장 확실한 일정 단축 방법입니다.

예산을 아끼는 현실적인 방법

단가를 깎는 협상보다 훨씬 효과가 큰 것은 만들 것 자체를 줄이는 일입니다. 아래 세 가지는 품질을 크게 훼손하지 않으면서 비용을 낮추는 방법입니다.

• 범위 축소 — 기능 목록을 적어 놓고 ‘이게 없으면 서비스가 성립하지 않는가’를 기준으로 나눠 보면, 대개 절반 정도는 나중에 추가해도 되는 항목입니다. 첫 버전은 핵심 흐름 하나가 끝까지 동작하는 데 집중하고 나머지는 목록으로 남겨 두는 편이, 모든 기능을 얕게 만들어 놓는 것보다 결과가 좋습니다.
• 기성 솔루션 활용 — 로그인, 결제, 게시판, 알림, 통계처럼 이미 잘 만들어진 서비스가 있는 영역은 직접 개발하지 않고 가져다 쓰는 편이 훨씬 저렴하고 안정적입니다. 쇼핑몰이라면 상용 플랫폼으로 시작해 검증한 뒤 직접 개발로 넘어가는 순서도 충분히 합리적입니다. 다만 월 사용료가 계속 나가고 커스터마이징에 한계가 있으므로, 초기 비용과 운영 비용을 함께 비교해야 합니다.
• 단계별 출시 — 전체를 한 번에 만들어 공개하는 대신 1차·2차로 나누면 초기 지출을 분산하고, 1차 반응을 보고 2차 범위를 조정할 수 있습니다. 쓰이지 않을 기능에 돈을 쓰는 일을 막아 주는 것이 실질적인 절감 효과입니다. 다만 나눌 때는 기능 단위가 아니라 사용자가 실제로 겪는 흐름 단위로 잘라야 1차만으로도 쓸모가 있습니다.

어떤 방법을 쓰든 전제는 요구사항이 정리되어 있어야 한다는 점입니다. 무엇을 만들지 흐릿한 상태에서는 무엇을 뺄지도 판단할 수 없습니다. 견적을 받기 전에 정리해 두면 좋은 것들은 아이디어를 요구사항으로 정리하는 방법에 따로 정리해 두었습니다.

싼 견적을 조심해야 하는 이유

같은 설명을 듣고 나온 견적이 다른 곳의 절반이라면, 대개 셋 중 하나입니다. 범위를 다르게 이해했거나, 어딘가를 빼고 계산했거나, 일단 계약부터 하고 나중에 추가 비용을 청구할 생각입니다. 저렴한 견적 자체가 문제라는 뜻은 아닙니다. 문제는 왜 저렴한지 설명되지 않는 견적입니다.

낮은 금액이 나오는 흔한 이유는 다음과 같습니다.

• 범위 인식 차이 — 관리자 기능, 반응형 대응, 테스트, 배포 환경 구축이 빠진 채 계산된 경우입니다.
• 추가 비용 전제 — 계약 후 ‘그건 견적에 없던 기능’이라며 별도 청구가 이어지는 구조입니다.
• 템플릿 재활용 — 기존 결과물을 조금 고쳐 납품하는 방식으로, 저렴한 대신 확장이 어렵습니다.
• 사후 대응 제외 — 납품 이후 오류 수정이나 문의 대응이 계약에 포함되지 않은 경우입니다.

가격을 비교할 때는 총액이 아니라 ‘그 금액에 무엇이 포함되는지’를 나란히 놓고 봐야 합니다. 소스 코드의 소유권, 하자 보수 기간, 산출물 목록, 서버와 도메인 비용의 부담 주체는 총액만큼이나 중요한 조건입니다. 계약 전에 확인해야 할 항목은 개발 외주 계약 전 확인할 것들에 정리해 두었습니다.

견적 요청할 때 전달하면 좋은 정보

정확한 견적은 정확한 정보에서 나옵니다. 아래 항목을 문서 한 장으로 정리해 여러 업체에 동일하게 전달하면, 받은 견적들을 같은 기준으로 비교할 수 있습니다. 완벽하게 채울 필요는 없고, 모르는 항목은 모른다고 적으셔도 됩니다.

• 서비스 한 줄 설명 — 누구를 위한, 무엇을 하는 서비스인지 한두 문장으로 적습니다.
• 주요 사용자 유형 — 일반 사용자만 있는지, 판매자·관리자처럼 권한이 다른 사용자가 있는지 구분합니다.
• 핵심 기능 목록 — 반드시 필요한 기능과 있으면 좋은 기능을 나눠서 적습니다. 이 구분 하나가 견적 정확도를 크게 높입니다.
• 화면 목록 또는 참고 서비스 — 화면을 다 그리지 못했다면 비슷한 서비스의 이름과 ‘이 부분이 우리와 비슷하다’는 설명만으로도 충분합니다.
• 필요한 외부 연동 — 결제, 본인인증, 지도, 알림, 기존 사내 시스템 등을 적습니다.
• 대상 플랫폼 — 웹만인지, 앱도 필요한지, 앱이라면 iOS와 Android 모두인지 밝힙니다.
• 예산 범위와 희망 일정 — 정확한 숫자가 아니어도 범위를 알려 주시면 그 안에서 가능한 구성을 제안받을 수 있습니다.
• 운영 계획 — 출시 후 콘텐츠를 직접 관리할지, 운영을 위탁할지에 따라 관리자 기능의 범위가 달라집니다.

예산을 밝히면 그 금액에 맞춰 청구당한다고 걱정하시는 분들이 있는데, 실제로는 반대인 경우가 많습니다. 예산을 모르면 업체는 안전하게 넉넉한 구성으로 견적을 내고, 그 결과 검토할 가치가 없는 숫자가 돌아옵니다. 범위를 알려 주시면 ‘이 예산에서는 여기까지 가능하고, 이 부분은 2차로 미루는 편이 낫다’는 구체적인 대화를 시작할 수 있습니다.

※ 이 글에 적힌 화면 수, 기간, 금액 수준은 일반적인 사례를 바탕으로 한 참고 범위이며 확정 견적이 아닙니다. 실제 비용과 기간은 요구사항, 연동 대상, 디자인 범위, 계약 조건에 따라 프로젝트마다 크게 달라집니다.