같은 기능인데 왜 견적서 금액은 10배까지 벌어질까

중소 쇼핑몰을 운영하는 사장님이 저를 찾아온 적이 있습니다. 플랫폼 https://webpreme.com 제작을 알아보는데 A 업체는 3천만 원, B 업체는 1억 2천만 원, C 업체는 3억 원을 불렀다고 하더군요. 기능 목록은 거의 비슷해 보였습니다. 상품 등록, 결제, 배송 추적, 정산. 그런데 이 숫자 차이를 ‘바가지’나 ‘덤핑’으로만 해석하면 큰코다칩니다.

저는 그 사장님께 견적서를 한 줄씩 비교해보자고 했습니다. A 업체는 서버 비용과 유지보수를 별도라고 명시했고, B 업체는 관리자 페이지 개발이 빠져 있었습니다. C 업체는 5년간 트래픽 10배 증가를 가정한 아키텍처 설계비를 포함했더군요. 같은 ‘플랫폼 제작’이라는 단어 아래 숨은 범위가 이렇게 다릅니다.

당신이 지금 받은 견적서도 마찬가지일 겁니다. 금액만 보지 말고, 그 금액에 무엇이 포함되고 무엇이 빠졌는지를 먼저 확인해야 합니다. 이 글은 그 확인 작업을 어떻게 하는지에 대한 현장 기록입니다.

첫 번째 차이: 사용자 수 1만 명과 100만 명은 완전히 다른 시스템이다

많은 분들이 플랫폼 제작을 ‘앱 만들기’ 정도로 생각합니다. 하지만 사용자 규모에 따라 설계가 근본적으로 달라집니다. 동시 접속자 100명이면 서버 한 대로 충분하지만, 1만 명이 넘어가면 로드밸런서, 캐시 서버, 데이터베이스 분산이 필수입니다.

제가 작년에 컨설팅한 한 교육 플랫폼은 오픈 첫날 동시 접속자 3천 명을 감당하지 못해 4시간 동안 서비스가 마비됐습니다. 개발사는 ‘예상보다 트래픽이 많았다’고 했지만, 사실 견적서에 오토스케일링 옵션이 빠져 있었습니다. 그 옵션 하나 때문에 추가로 2천만 원을 더 썼고, 신뢰도는 회복하기 어려울 정도로 떨어졌습니다.

사용자 수가 10배 늘면 서버 비용은 10배가 아니라 30배까지 늘어날 수 있습니다. 데이터 동기화, 백업, 모니터링, 장애 대응 체계가 기하급수적으로 복잡해지기 때문입니다. 견적서에 ‘예상 사용자 수’가 명시되어 있지 않다면, 그 견적은 반쪽짜리입니다.

저는 고객에게 항상 이렇게 묻습니다. “3년 뒤 회원 수가 지금의 몇 배가 될 것 같으세요?” 이 질문에 대한 답이 플랫폼 제작 비용의 첫 번째 분기점입니다.

두 번째 차이: 관리자 페이지 하나가 5천만 원짜리인 이유

의뢰인들은 사용자 화면에는 관심이 많지만 관리자 페이지는 ‘그냥 대충’ 생각하는 경우가 많습니다. 하지만 현장에서 플랫폼 제작 비용의 30~40%는 관리자 페이지에서 나옵니다.

예를 들어 상품 하나를 등록한다고 해도, 단순히 제목과 가격만 넣는 게 아닙니다. 옵션 조합, 재고 연동, 할인 정책, 노출 순서, 승인 워크플로우, 로그 기록까지 들어가면 화면 수가 20개를 넘어갑니다. 여기에 권한 관리(슈퍼관리자, 운영자, CS 담당자)를 넣으면 개발 공수가 두 배로 뜁니다.

작년에 한 유통 플랫폼을 봤는데, 관리자 페이지에 ‘대량 등록’ 기능이 없어서 상품 1만 개를 직원이 하나씩 수동으로 입력하고 있었습니다. 이 기능 하나 개발하는 데 800만 원이 들었지만, 그 전까지 직원 3명이 3개월 동안 매달린 인건비를 생각하면 훨씬 비쌌습니다. 견적서에 ‘관리자 기능 상세’가 없으면 나중에 이런 숨은 비용이 터집니다.

결국 관리자 페이지는 ‘운영 효율’에 대한 투자입니다. 처음에 5천만 원을 아끼려다가 매년 1억 원의 운영비를 쓰는 사례를 수도 없이 봤습니다.

세 번째 차이: 결제와 정산, 이 두 글자가 만드는 1억 원의 격차

플랫폼 제작에서 가장 까다로운 부분은 결제와 정산입니다. 사용자에게 돈을 받는 것까지는 그럴듯하게 만들 수 있습니다. 하지만 판매자에게 돈을 나눠주는 정산 시스템은 완전히 다른 이야기입니다.

예를 들어 마켓플레이스 플랫폼을 만든다고 가정해봅시다. PG사 연동은 기본이고, 수수료 정책, 배송비 분담, 환불 처리, 부분 취소, 세금계산서 발행, 정산 주기(주간/월간), 정산 내역서 자동 생성까지 들어갑니다. 여기에 전자금융거래법상 의무사항까지 지키려면 보안 컨설팅 비용만 2천만 원이 추가됩니다.

제가 만난 한 스타트업 대표는 결제 모듈을 300만 원에 외주로 해결했다가, 6개월 후 금융감독원 검사에서 적발되어 서비스 전체를 중단해야 했습니다. 정산 로직이 법적 요건을 충족하지 못했던 겁니다. 다시 만드는 데 1억 5천만 원이 들었고, 그 사이 투자 유치도 무산됐습니다.

결제와 정산은 ‘기능’이 아니라 ‘규제 준수’ 영역입니다. 이 부분을 견적서에서 얼마나 구체적으로 다루는지가 플랫폼 제작 업체의 실력을 판가름하는 기준이 됩니다.

네 번째 차이: 개발 언어와 프레임워크가 유지보수 비용을 결정한다

비전문가에게 개발 언어를 설명하는 건 쉽지 않습니다. 하지만 이 선택이 3년 뒤 유지보수 비용에 큰 영향을 미친다는 사실은 알아두셔야 합니다.

예를 들어 PHP로 빠르게 만든 플랫폼은 초기 개발비가 2천만 원 정도로 저렴할 수 있습니다. 하지만 기능이 복잡해지고 트래픽이 늘면 구조적 한계에 부딪힙니다. 반면 자바 스프링이나 Node.js 기반으로 제대로 설계하면 초기 비용은 3~4배 높지만, 5년간 유지보수 비용은 오히려 절반 이하로 줄어드는 경우가 많습니다.

실제로 제가 관여한 한 물류 플랫폼은 처음에 저렴한 외주로 PHP 기반으로 만들었습니다. 2년 후 기능 추가를 요청하자 개발사는 “이 구조에서는 더 이상 확장이 어렵다”며 전면 재개발을 권했습니다. 결국 1억 8천만 원을 다시 들여 자바로 다시 짰습니다. 처음부터 제대로 된 스택을 선택했다면 총비용은 1억 원 정도였을 겁니다.

물론 무조건 비싼 기술이 답은 아닙니다. 서비스 규모와 향후 3년 로드맵에 맞는 기술 선택이 중요합니다. 견적서에 사용 기술 스택이 명시되어 있지 않다면, 그 업체는 유지보수까지 고려하지 않았다고 봐야 합니다.

다섯 번째 차이: 개발 기간 3개월과 9개월, 그 사이에 숨은 함정

플랫폼 제작 기간은 단순히 ‘일하는 시간’이 아닙니다. 기간이 길어지면 인건비가 늘고, 시장 기회를 놓치고, 팀 사기가 떨어집니다. 그런데 많은 견적서가 비현실적으로 짧은 기간을 제시합니다.

한 고객은 A 업체에서 ‘3개월 완성’이라는 견적을 받았습니다. 계약금을 지불하고 3개월 후에 가보니 로그인 화면만 겨우 나와 있었습니다. 개발자는 “기능이 워낙 많아서 시간이 더 필요하다”며 6개월을 더 요구했습니다. 결국 9개월 만에 겨우 오픈했지만, 그 사이 경쟁사는 시장을 선점했습니다.

반대로 B 업체는 9개월을 제안하며 상세한 마일스톤을 함께 줬습니다. 1개월 차에는 요구사항 정의서, 2개월 차에는 프로토타입, 3개월 차에는 핵심 기능 데모. 이런 식으로 매달 결과물을 확인할 수 있었습니다. 결과적으로 9개월 만에 안정적인 플랫폼을 오픈했고, 추가 비용은 거의 발생하지 않았습니다.

개발 기간을 단축하려면 기능을 줄이거나 인력을 늘려야 합니다. 인력을 늘리면 커뮤니케이션 비용이 기하급수적으로 늘어나기 때문에, 오히려 전체 기간이 길어지는 경우도 허다합니다. ‘3개월’이라는 말에 현혹되지 마세요. 그 기간이 어떻게 산출됐는지, 중간 산출물은 무엇인지 확인해야 합니다.

플랫폼 제작 업체, 이 다섯 가지 질문으로 걸러내세요

지금까지 다섯 가지 차이를 짚었습니다. 그렇다면 실제로 업체를 선정할 때는 어떤 기준을 적용해야 할까요? 제가 현장에서 수백 건의 견적서를 비교하며 정리한 질문 목록입니다.

첫째, “이 견적서에 명시되지 않은 추가 비용 항목은 무엇인가요?” 서버, 유지보수, 보안 업데이트, 기능 추가 단가를 반드시 문서로 받아두세요. 구두 약속은 나중에 없던 일이 됩니다.

둘째, “개발 완료 후 소스 코드와 데이터베이스 소유권은 누구에게 있나요?” 이 질문에 명확히 답하지 못하는 업체는 거르세요. 소스 코드를 주지 않으면 나중에 다른 업체로 옮기는 것조차 불가능합니다.

셋째, “장애 발생 시 대응 절차와 SLA(서비스 수준 협약)는 어떻게 되나요?” 24시간 대응인지, 평일만 가능한지, 복구 목표 시간은 몇 시간인지 구체적으로 확인하세요.

넷째, “비슷한 규모의 플랫폼을 만든 레퍼런스 3개만 보여주실 수 있나요?” 단순히 포트폴리오 개수가 아니라, 실제 운영 중인지, 트래픽은 어느 정도인지, 의뢰인 연락처를 줄 수 있는지 물어보세요.

다섯째, “개발 인력의 고용 형태는 어떻게 되나요?” 프리랜서를 모아서 프로젝트를 진행하는 업체는 중간에 인력이 바뀌면서 코드 일관성이 깨질 위험이 큽니다. 정규직 비중이 높은 업체가 안정적입니다.

이 질문들에 대해 명확하고 구체적인 답변을 주는 업체라면, 최소한 견적서의 숫자를 믿을 수 있는 기반은 갖춘 셈입니다. 플랫폼 제작은 일회성 구매가 아니라 3~5년을 함께 가는 파트너십입니다. 처음에 1천만 원 아끼려다 1억 원을 날리는 일이 없도록, 이 다섯 가지 질문을 반드시 던져보시기 바랍니다.

자주 묻는 질문

플랫폼 제작 비용은 보통 얼마인가요?

간단한 커뮤니티형 플랫폼은 2천만 원에서 5천만 원, 결제와 정산이 포함된 마켓플레이스는 1억 원에서 3억 원 사이가 일반적입니다. 다만 이 금액은 사용자 수, 관리자 기능, 결제 연동 여부에 따라 크게 달라지므로, 기능 명세서 없이 받은 견적은 신뢰하기 어렵습니다.

플랫폼 제작 기간은 얼마나 걸리나요?

핵심 기능만 구현하는 MVP는 34개월, 정식 서비스는 69개월이 평균입니다. 기간을 단축하려면 기능을 줄이거나 인력을 늘려야 하는데, 인력을 늘리면 커뮤니케이션 비용이 증가해 오히려 지연될 수 있습니다. 3개월 완성 같은 제안은 중간 산출물을 확인할 수 있는지부터 따져보세요.

외주 개발 후 유지보수는 꼭 해야 하나요?

법적 의무는 아니지만, 보안 취약점 패치와 서버 장애 대응을 위해 사실상 필수입니다. 유지보수 계약 없이 운영하다가 해킹이나 데이터 유출이 발생하면 복구 비용이 초기 개발비를 넘는 경우도 있습니다. 보통 개발비의 15~20%를 연간 유지보수 비용으로 책정합니다.

첫 삽 뜨기 전에 새는 돈

플랫폼 제작 프로젝트 10건 중 7건은 첫 3개월 안에 원래 예산의 30% 이상이 추가로 청구됩니다. 제가 작년에 컨설팅했던 한 중견 유통업체는 초기 견적 1억 2천만 원으로 시작했는데, 4개월 만에 3억 8천만 원까지 늘어났습니다. 이유는 단 하나였습니다. “로그인만 되면 나머지는 나중에 정하죠”라고 말한 기능 정의서 한 줄이, 실제로는 47개의 하위 기능으로 쪼개졌기 때문입니다.

많은 대표님들이 견적서에 적힌 금액을 ‘총액’으로 읽습니다. 하지만 실무에서 견적서는 ‘시작가’에 가깝습니다. 특히 플랫폼 제작은 일반 홈페이지와 다릅니다. 사용자 권한, 결제, 정산, 알림, 관리자 도구가 서로 맞물려 돌아가야 하니까요. 하나를 바꾸면 세 개가 흔들립니다. 이 연쇄를 견적 단계에서 계산에 넣는 업체는 생각보다 많지 않습니다.

제가 만난 한 스타트업 대표는 “기능은 30개인데 왜 개발자는 5명이 필요하냐”고 물었습니다. 그 질문에 답하려면 기능 목록이 아니라 ‘기능 간 의존 관계’를 봐야 합니다. 예를 들어 ‘간편 로그인’ 하나에도 본인 인증, 약관 동의 이력, 탈퇴 시 데이터 처리, 기기 변경 감지가 붙습니다. 이 네 가지가 빠지면 나중에 법적 이슈까지 생깁니다. 견적서에 이 의존 관계가 명시돼 있지 않다면, 그 견적서는 절반짜리라고 봐야 합니다.

기능 개수보다 무서운 것

플랫폼 제작 견적을 볼 때 대표님들이 가장 먼저 세는 것은 기능 개수입니다. 하지만 현장에서 예산을 갉아먹는 주범은 기능 개수가 아닙니다. ‘데이터 흐름’입니다.

예를 들어 쇼핑몰 플랫폼을 만든다고 가정해 보겠습니다. 상품 등록, 주문, 결제, 배송 추적, 리뷰, 정산. 기능은 여섯 개입니다. 그런데 이 여섯 개가 주고받는 데이터 필드는 최소 120개가 넘습니다. 주문 하나에 들어가는 정보만 해도 주문자, 수령인, 결제 수단, 할인 코드, 배송 메모, 세금 계산 방식이 얽혀 있습니다. 이 중 하나라도 정의가 바뀌면 관련된 화면 12개를 다시 손봐야 합니다. 견적서에 ‘화면 30개’라고 적혀 있어도, 실제로 수정이 발생하는 지점은 그 세 배가 넘습니다.

제가 작년에 봤던 한 교육 플랫폼은 ‘강의 수강 신청’ 기능 하나 때문에 6주를 지연시켰습니다. 이유는 간단했습니다. 수강 신청 버튼을 누르는 순간, 재고 확인, 결제 모듈 호출, 수강 권한 부여, 알림 발송, 통계 테이블 업데이트가 동시에 일어나야 하는데, 이 다섯 가지를 순차적으로 처리하도록 설계한 겁니다. 사용자가 몰리는 시간대에 서버가 버티지 못했습니다. 이 문제를 해결하려면 아키텍처를 처음부터 다시 짜야 했고, 추가 비용은 4천만 원이었습니다.

기능 목록은 나무고, 데이터 흐름은 숲입니다. 나무만 세는 견적서는 숲에서 길을 잃습니다.

개발자 이력서에 속지 않는 법

플랫폼 제작 업체를 고를 때, 많은 대표님이 개발자 이력서부터 요구합니다. 물론 중요합니다. 하지만 https://webpreme.com 이력서에 적힌 ‘프로젝트 20건’이 그 개발자의 실력을 보장하지는 않습니다. 저는 이력서 대신 세 가지를 보라고 권합니다.

첫째, ‘장애 대응 기록’입니다. 플랫폼은 살아 있는 동안 반드시 장애가 납니다. 결제가 안 되거나, 알림이 안 가거나, 특정 사용자만 로그인이 안 되는 일이 생깁니다. 이때 얼마나 빨리 원인을 찾고 복구했는지가 진짜 실력입니다. 이력서에는 ‘성공적으로 런칭’만 적혀 있지만, 실무에서는 ‘런칭 후 3개월간 무중단 운영’이 더 값집니다. 업체에 “가장 최근에 발생한 장애와 복구 시간”을 물어보세요. 구체적으로 답하는 업체는 드물지만, 그 답이 실력을 말해줍니다.

둘째, ‘코드 리뷰 문화’입니다. 개발자가 5명 이상인 업체라면 코드 리뷰를 하는지 확인해야 합니다. 코드 리뷰 없이 진행된 플랫폼은 개발자가 퇴사하는 순간 유지보수가 불가능해집니다. 제가 상담했던 한 고객은 개발자 한 명에게 모든 걸 의존했다가, 그 개발자가 이직한 후 6개월 동안 아무것도 못 했습니다. 코드를 읽을 수 있는 사람이 없었기 때문입니다.

셋째, ‘문서화 수준’입니다. 기능 정의서, API 명세서, DB 스키마 문서가 프로젝트 중간에 업데이트되는지 보세요. 문서가 없는 플랫폼은 인수인계가 안 됩니다. 견적서에 ‘문서화 비용’이 별도 항목으로 있는지 확인하는 것도 방법입니다. 이 항목이 없는 업체는 대개 개발만 하고 끝냅니다.

내일 아침에 할 수 있는 세 가지

플랫폼 제작을 앞두고 있다면, 내일 아침에 이 세 가지를 하세요.

첫째, 견적서에 ‘변경 요청 비용’ 항목이 있는지 확인하세요. 없으면 계약 전에 반드시 추가하라고 요구하세요. 기능 하나를 바꿀 때 드는 비용과 시간을 미리 정해두지 않으면, 나중에 협상력이 사라집니다. 실제로 한 고객은 ‘버튼 색상 변경’에 200만 원을 청구받았습니다. 사전에 합의된 단가가 없었기 때문입니다.

둘째, ‘최소 기능 제품(MVP)’ 범위를 종이에 적으세요. 플랫폼 제작에서 가장 흔한 실수는 처음부터 완벽한 플랫폼을 만들려는 것입니다. 1단계에서는 로그인, 핵심 기능 하나, 결제만 넣으세요. 나머지는 사용자 반응을 본 뒤에 추가하세요. 이렇게 하면 초기 비용을 40% 이상 줄일 수 있습니다. 제가 아는 한 스타트업은 MVP로 3천만 원에 시작해 6개월 만에 2억 원을 추가 투자했지만, 그때는 이미 시장 반응을 확인한 상태였습니다.

셋째, ‘유지보수 계약’을 개발 계약과 동시에 논의하세요. 플랫폼은 런칭이 끝이 아닙니다. 서버 비용, 보안 업데이트, 기능 개선이 매달 발생합니다. 월 유지보수 비용을 초기 개발비의 10~15%로 잡는 것이 일반적입니다. 이 비용을 처음부터 예산에 넣지 않으면, 런칭 후 6개월 안에 다시 자금을 끌어와야 합니다. 유지보수 계약서에 ‘월 몇 시간까지 무상 지원’인지 명시하세요. 시간당 단가가 10만 원을 넘는다면 다른 업체를 알아보는 게 좋습니다.

자주 묻는 질문

플랫폼 제작 비용은 보통 얼마인가요?

간단한 MVP는 3천만 원에서 5천만 원, 중간 규모는 1억 원에서 3억 원, 대규모는 5억 원 이상입니다. 비용은 기능 개수보다 데이터 흐름의 복잡도에 따라 결정됩니다. 예를 들어 결제와 정산이 들어가면 기본 1억 원은 잡아야 합니다.

플랫폼 제작 기간은 얼마나 걸리나요?

MVP 기준 3개월에서 6개월, 일반적인 플랫폼은 6개월에서 12개월입니다. 하지만 견적서에 적힌 기간은 개발만 기준입니다. 기획, 디자인, 테스트, 배포를 포함하면 실제로는 1.5배에서 2배가 걸립니다. 계약서에 각 단계별 마감일을 명시하세요.

외주 개발자와 직접 고용 중 어떤 게 나은가요?

초기에는 외주가 유리합니다. 직접 고용은 4대 보험, 장비, 교육 비용까지 포함하면 개발자 1명당 연 8천만 원 이상 듭니다. 하지만 플랫폼이 안정화된 후에는 핵심 개발자 1~2명을 직접 고용하는 것이 유지보수 비용을 줄입니다.

견적서에 어떤 항목이 빠져 있으면 위험한가요?

변경 요청 비용, 유지보수 범위, 문서화 비용, 서버 아키텍처 설계비가 빠져 있으면 위험합니다. 이 네 가지가 없으면 나중에 추가 비용이 발생할 가능성이 90% 이상입니다. 특히 변경 요청 단가가 없으면 기능 하나 수정에 수백만 원을 청구받을 수 있습니다.

플랫폼 제작 후 유지보수 비용은 얼마나 드나요?

초기 개발비의 10~15%를 월 유지보수 비용으로 잡습니다. 예를 들어 개발비가 1억 원이면 월 1천만 원에서 1천5백만 원입니다. 여기에는 서버 비용, 보안 패치, 버그 수정, 소규모 기능 개선이 포함됩니다. 별도로 대규모 기능 추가는 추가 견적이 발생합니다.

개발 업체 선정할 때 가장 중요한 기준은 무엇인가요?

장애 대응 기록과 문서화 수준입니다. 이력서에 적힌 프로젝트 수보다, 실제 장애 발생 시 평균 복구 시간이 4시간 이내인지, API 명세서와 DB 스키마 문서를 제공하는지가 중요합니다. 이 두 가지가 없으면 개발자가 퇴사할 때 플랫폼을 버려야 할 수도 있습니다.