견적서에 적힌 숫자는 시작일 뿐이다
플랫폼 제작을 의뢰한 대표님들이 가장 많이 하는 착각이 있습니다. 견적서에 적힌 금액이 곧 최종 비용이라고 믿는 겁니다. 제가 10년 넘게 현장에서 본 바로는, 첫 견적서와 실제 지출 사이에는 평균 30~50%의 차이가 발생합니다. 5천만 원 견적이 7천만 원이 되는 건 예사고, 심한 경우 두 배가 되기도 합니다.
왜 이런 일이 벌어질까요. 대부분의 개발사는 요구사항이 명확하지 않은 상태에서 견적을 냅니다. 기획이 없거나, 있어도 구멍이 숭숭 뚫려 있죠. 그러면 개발사는 최소한의 기능만 가정하고 가격을 부릅니다. 계약 후에 “이 기능은 추가 비용입니다”라는 말이 나오는 순간, 대표님들은 선택지가 없습니다. 이미 시작한 프로젝트를 멈출 수도 없고, 다른 업체로 옮기자니 더 손해입니다.
저는 이 구조를 ‘견적서의 함정’이라고 부릅니다. 견적서는 계약서가 아니라 영업 도구입니다. 상대방이 얼마를 쓸 의향이 있는지 탐색하는 수단이죠. 그래서 견적서를 받으면 금액보다 산출 근거를 먼저 봐야 합니다. 어떤 기능에 몇 명의 개발자가 며칠을 투입하는지, 그 숫자가 합리적인지 따져야 합니다.
기획 없는 개발은 모래 위에 집을 짓는 것
작년에 컨설팅을 진행한 한 고객이 있었습니다. 요식업 예약 플랫폼을 만들겠다며 개발사 세 곳에서 견적을 받아왔습니다. A사는 3천만 원, B사는 8천만 원, C사는 1억 5천만 원을 불렀습니다. 대표님은 당연히 A사를 선택하려 했습니다. 제가 견적서를 뜯어보니, A사는 예약 기능만 포함되어 있었고 결제 연동, 알림톡, 관리자 페이지는 전부 빠져 있었습니다. B사는 결제와 알림톡까지, C사는 여기에 데이터 분석과 CRM 연동까지 포함한 견적이었습니다.
같은 ‘예약 플랫폼’인데 포함된 범위가 이렇게 다릅니다. 문제는 대표님이 이 차이를 인지하지 못했다는 겁니다. 견적서에 ‘예약 시스템’이라고만 적혀 있으면, 그 안에 무엇이 들어있는지 알 방법이 없습니다. 결국 A사와 계약하고 6개월 뒤, 결제 모듈을 추가하느라 2천만 원을 더 썼습니다. 총 5천만 원. B사 견적보다 더 비싸게 끝난 셈이죠.
기획서 없이 견적을 비교하는 건 사과와 오렌지를 저울에 올리는 겁니다. 비교 자체가 성립하지 않습니다. 그래서 저는 플랫폼 제작을 시작하기 전에 최소 2주, 길게는 한 달 동안 요구사항 정의서를 만드는 데 투자하라고 권합니다. 이 기간에 들어가는 비용은 300만~500만 원 수준입니다. 이걸 아끼려다 수천만 원을 날리는 사례를 너무 많이 봤습니다.
개발사가 말하는 ‘유지보수’의 진실
계약서에서 가장 애매하게 넘어가는 부분이 유지보수 조항입니다. “월 100만 원에 유지보수 제공”이라는 문구를 보고 안심하는 대표님들이 많습니다. 그런데 그 100만 원에 무엇이 포함되는지는 아무도 모릅니다.
실제로는 버그 수정만 포함되고, 기능 추가는 별도 견적입니다. 서버 장애 대응은 포함되지만, 트래픽 증가로 서버 증설이 필요하면 추가 비용입니다. 보안 업데이트, 정기 백업, 데이터베이스 최적화는 대부분 빠져 있습니다. 플랫폼이 커지면 커질수록 유지보수 범위를 두고 분쟁이 생깁니다.
제가 본 가장 황당한 사례는 월 150만 원 유지보수 계약을 맺었는데, 1년 동안 단 한 번도 코드를 열어보지 않은 개발사였습니다. 장애가 터지면 그때만 급하게 대응하고, 평소에는 손을 놓고 있었습니다. 결국 해킹 사고가 났고, 복구에만 3천만 원이 들었습니다.
유지보수 계약을 할 때는 반드시 세 가지를 확인해야 합니다. 첫째, 월간 작업 내역서를 제공하는지. 둘째, 장애 대응 시간(SLA)이 명시되어 있는지. 셋째, 기능 추가 시 견적 산정 기준이 문서화되어 있는지. 이 세 가지가 없으면 그 계약은 사실상 무의미합니다.
기술 스택 선택이 3년 뒤 비용을 결정한다
플랫폼 제작 견적을 비교할 때 기술 스택을 물어보는 대표님은 열 명 중 한 명도 안 됩니다. 대부분 “알아서 잘 만들어주겠지”라고 생각하죠. 하지만 기술 홈페이지제작 스택은 3년 뒤 유지보수 비용과 인력 수급 난이도를 결정하는 핵심 변수입니다.
예를 들어, PHP 기반으로 만든 플랫폼은 초기 개발비가 저렴합니다. 하지만 3년 뒤 기능을 확장하려면 레거시 코드와 싸워야 하고, PHP 개발자를 구하기도 점점 어려워집니다. 반면 Node.js나 Python 기반은 초기 비용이 20~30% 높지만, 확장성과 인력 풀에서 유리합니다.
한 고객은 초기 비용을 아끼려고 2천만 원짜리 PHP 솔루션을 선택했습니다. 2년 뒤 회원 수가 10만 명을 넘으면서 성능 문제가 터졌습니다. 결국 플랫폼을 처음부터 다시 만드는 데 1억 2천만 원을 썼습니다. 처음부터 제대로 된 스택을 선택했다면 4천만 원으로 끝났을 일입니다.
물론 무조건 최신 기술이 답은 아닙니다. 팀의 역량, 서비스의 성장 속도, 예상 트래픽을 종합적으로 고려해야 합니다. 하지만 https://search.naver.com/search.naver?query=홈페이지제작 적어도 “왜 이 기술을 선택했는지” 개발사에 물어보는 것만으로도 큰 차이가 납니다.
외주 개발, 어디까지 맡겨야 할까
플랫폼 제작을 외주로 진행할 때 가장 흔한 실패 패턴은 ‘전부 맡기기’입니다. 기획부터 디자인, 개발, 운영까지 모든 것을 외주사에 의존하면, 내부에 아무런 자산이 남지 않습니다. 개발사가 손을 떼는 순간 플랫폼은 블랙박스가 됩니다.
제가 컨설팅한 한 스타트업은 3년 동안 한 개발사에 모든 것을 맡겼습니다. 계약이 끝나고 다른 업체로 옮기려 했더니, 코드 문서도 없고, 서버 접근 권한도 없고, 데이터베이스 구조도 파악할 수 없었습니다. 결국 처음부터 다시 만들어야 했습니다. 3년 동안 쌓은 데이터는 전부 날렸습니다.
반대로 잘한 사례도 있습니다. 한 대표님은 기획과 디자인은 외주로 맡기되, 핵심 데이터베이스 설계와 API 명세서는 직접 관리했습니다. 개발사가 바뀌어도 최소한의 연속성을 유지할 수 있었죠. 또한 소스코드와 서버 권한을 계약 조건에 명시해서, 분쟁 없이 이관할 수 있었습니다.
외주를 줄이는 방법은 두 가지입니다. 첫째, 기획은 내부에서 하거나 최소한 검수라도 직접 합니다. 둘째, 코드와 데이터에 대한 소유권을 계약서에 명확히 합니다. 이 두 가지만 지켜도 외주 리스크의 절반은 줄어듭니다.
개발 기간, 왜 항상 예상보다 길어질까
플랫폼 제작에서 가장 자주 어기는 약속이 일정입니다. 3개월이면 끝난다고 했는데 6개월이 걸리고, 6개월이면 1년이 됩니다. 왜 이런 일이 반복될까요.
첫째, 요구사항이 개발 중에 바뀝니다. 대표님이 시장 반응을 보고 기능을 추가하거나 수정하는 겁니다. 이건 자연스러운 일이지만, 일정에는 반영되지 않습니다. 둘째, 개발사가 여러 프로젝트를 동시에 진행합니다. 내 프로젝트에만 매달리는 게 아닙니다. 셋째, 테스트와 배포 단계에서 예상치 못한 버그가 쏟아집니다.
한 프로젝트를 분석해보니, 전체 기간 8개월 중 실제 개발은 4개월이었습니다. 나머지 4개월은 요구사항 회의, 디자인 수정, 테스트, 배포, 재수정에 쓰였습니다. 대표님들은 ‘개발 기간’만 생각하지만, 실제로는 그 주변 작업이 절반을 차지합니다.
그래서 일정을 계획할 때는 개발 기간에 최소 1.5배를 곱해야 합니다. 3개월이면 4.5개월, 6개월이면 9개월로 잡으세요. 그리고 중간중간 마일스톤을 설정해서 진행 상황을 확인해야 합니다. “다음 주에 보여드릴게요”라는 말만 믿으면 안 됩니다. 데모 가능한 결과물을 요구하세요.
오늘 당장 할 수 있는 세 가지 행동
플랫폼 제작을 앞두고 있다면, 오늘 바로 실행할 수 있는 것들이 있습니다. 첫째, 개발사에 ‘기능 목록’을 요구하세요. 견적서에 포함된 기능을 항목별로 나열해 달라고 하세요. 그리고 그 목록을 보면서 “이 기능이 없으면 서비스가 돌아가는가?”를 자문해보세요. 없어도 되는 기능은 과감히 빼세요. 3천만 원이 2천만 원으로 줄어들 수 있습니다.
둘째, 계약서에 ‘산출물 조항’을 넣으세요. 소스코드, 데이터베이스 스키마, API 문서, 서버 접근 권한, 배포 가이드. 이 다섯 가지를 계약 종료 시점에 모두 넘겨받는다는 조항을 명시하세요. 이게 없으면 나중에 발목 잡힙니다.
셋째, 첫 미팅에서 “이 프로젝트에서 가장 리스크가 큰 부분이 무엇인가요?”라고 물어보세요. 이 질문에 구체적으로 답하는 개발사는 실력이 있습니다. 반면 “걱정 마세요, 다 잘 됩니다”라고만 하는 곳은 피하세요. 플랫폼 제작은 기술이 아니라 판단의 연속입니다. 오늘 그 판단을 시작하세요.
자주 묻는 질문
플랫폼 제작 비용은 보통 얼마인가요?
간단한 예약이나 커뮤니티 플랫폼은 3천만5천만 원, 결제와 정산이 포함된 중급 플랫폼은 8천만1억 5천만 원, 대규모 트래픽과 데이터 분석이 필요한 경우 2억 원 이상도 듭니다. 비용은 기능 범위와 기술 스택에 따라 크게 달라지므로, 견적을 받을 때 포함된 기능 목록을 반드시 확인하세요.
외주 개발 후 유지보수는 꼭 해야 하나요?
법적으로 의무는 아니지만, 실제로는 거의 필수입니다. 플랫폼은 출시 후에도 보안 업데이트, 버그 수정, 서버 관리가 계속 필요합니다. 유지보수 없이 방치하면 해킹이나 데이터 유출 위험이 커지고, 나중에 복구 비용이 초기 개발비를 넘는 경우도 많습니다. 월 100만~300만 원 수준의 유지보수 계약을 권장합니다.
노코드 툴로 플랫폼 제작이 가능한가요?
가능합니다. 간단한 MVP나 내부용 도구라면 노코드로 2~4주 만에 만들 수 있고, 비용도 수백만 원 수준입니다. 하지만 회원 수가 많아지거나 복잡한 결제, 정산, 권한 관리가 필요하면 한계에 부딪힙니다. 노코드는 초기 검증용으로 쓰고, 서비스가 성장하면 커스텀 개발로 전환하는 전략이 일반적입니다.
견적서 금액은 절반의 진실일 뿐이다
플랫폼 제작을 처음 의뢰하는 대표님들이 가장 흔하게 하는 착각이 있다. ‘견적서에 적힌 금액이 총비용이다’라는 믿음이다. 제가 상담한 한 스타트업 대표는 4,800만 원짜리 견적서를 받고 계약했다. 1년 뒤 그 플랫폼에 들어간 누적 비용은 1억 7천만 원이었다.
차액은 어디서 나왔을까. 서버비, 유지보수, 기능 추가, 결제 수수료, 보안 패치, 그리고 무엇보다 ‘처음에 말하지 않았던 요구사항’이었다. 견적서는 개발 범위를 문서로 고정한 종이일 뿐, 그 뒤에 발생하는 운영 비용은 대부분 별도다.
대표님들이 놓치는 결정적 지점은 여기다. 플랫폼은 완성품이 아니라 살아 있는 서비스다. 건물을 지어서 끝나는 게 아니라, 입주자를 받고 관리해야 하는 상가와 같다. 견적서는 건축비일 뿐, 운영비가 아니다.
저는 견적서를 받으면 항상 뒤집어 본다. ‘이 금액에 포함되지 않은 것이 무엇인가’를 먼저 확인한다. 포함되지 않은 항목이 5개 이상이면, 그 견적서는 시작가일 뿐이다.
기능 개수로 견적을 비교하면 반드시 손해 본다
많은 대표 https://webpreme.com 님들이 A 업체 견적서와 B 업체 견적서를 기능 개수로 비교한다. ‘A는 30개 기능에 5천만 원, B는 30개 기능에 7천만 원이니 A가 낫다’는 식이다. 이 비교는 거의 항상 잘못된 결론으로 이어진다.
기능 하나의 깊이가 다르기 때문이다. 예를 들어 ‘회원가입’ 기능 하나를 봐도, 이메일 가입만 있는지, 소셜 로그인이 포함되는지, 본인인증이 붙는지, 등급별 권한 관리가 되는지에 따라 개발 공수가 10배 이상 차이 난다.
제가 작년에 컨설팅한 한 교육 플랫폼 프로젝트를 보자. 두 업체 견적 차이는 2천만 원이었다. 저렴한 쪽은 ‘동영상 업로드’만 있었고, 비싼 쪽은 ‘동영상 트랜스코딩, 화질 자동 조절, DRM, 시청 진도율 추적’이 포함돼 있었다. 실제로 서비스를 열자 저렴한 쪽은 사용자 100명만 넘어도 동영상이 끊겼다.
기능 목록은 같아 보여도, 그 안에 들어간 기술적 깊이가 다르다. 견적 비교는 개수가 아니라 ‘이 기능이 어느 수준까지 구현되는가’로 해야 한다. 이걸 확인하려면 견적서가 아니라 기획서를 봐야 한다.
외주, 자체 개발, 노코드 선택의 진짜 기준
플랫폼 제작 방식은 크게 세 가지다. 외주 개발, 자체 개발팀 구성, 노코드 도구 활용. 각각의 비용과 속도, 확장성은 완전히 다르다.
외주 개발은 초기 비용이 3천만 원에서 2억 원 사이, 기간은 3개월에서 1년이다. 자체 개발팀은 개발자 3명 기준 연봉만 2억 원 이상이고, 채용에만 3~6개월이 걸린다. 노코드는 월 10만 원에서 100만 원 수준으로 시작할 수 있지만, 트래픽이 늘거나 복잡한 기능이 필요하면 한계에 부딪힌다.
문제는 대표님들이 ‘어떤 방식이 좋은가’를 묻는다는 점이다. 이 질문에는 답이 없다. 대신 ‘우리 서비스가 1년 뒤 어떤 상태여야 하는가’를 먼저 정해야 한다.
예를 들어 월 사용자 1만 명 이하, 기능 변경이 잦은 초기 검증 단계라면 노코드가 합리적이다. 반대로 결제와 정산이 복잡하고, 데이터가 민감하며, 사용자가 10만 명 이상으로 예상된다면 외주든 자체든 제대로 된 아키텍처가 필요하다.
제 경험상 가장 위험한 선택은 ‘일단 싸게 시작하고 나중에 제대로 만들자’다. 이 경우 대부분 처음 만든 것을 버리고 다시 만들어야 한다. 재개발 비용은 첫 개발 비용의 1.5배에서 2배가 든다.
기획서 없이 개발사부터 만나면 돈만 나간다
플랫폼 제작 상담을 하다 보면, 아직 기획서 한 장 없이 개발사 미팅을 먼저 잡는 대표님들이 많다. 이 순서는 거의 항상 손해로 끝난다.
개발사는 기획서가 없으면 자기들이 편한 방식으로 범위를 잡는다. 이때 ‘이건 기본 포함입니다’와 ‘이건 추가 비용입니다’의 경계가 모호해진다. 나중에 분쟁이 생기면 계약서에 적힌 모호한 문구만 남는다.
제가 본 가장 안타까운 사례는 한 유통 플랫폼이었다. 대표가 개발사 대표와 술자리에서 구두로 범위를 정하고 계약금 5천만 원을 보냈다. 6개월 뒤 결과물은 대표가 생각한 것의 30% 수준이었다. 법적으로 다툴 근거도 약했다.
기획서는 개발사를 위한 것이 아니다. 대표님 자신을 보호하는 문서다. 최소한 다음은 문서로 남겨야 한다. 사용자 시나리오, 화면 목록, 관리자 기능, 외부 연동 범위, 데이터 소유권, 유지보수 조건.
이 문서를 만드는 데 2~4주와 300만 원에서 1,000만 원이 든다. 비싸게 느껴질 수 있다. 하지만 https://search.naver.com/search.naver?query=https://webpreme.com 이 비용을 아끼려다 1억 원을 날리는 사례를 저는 수십 번 봤다.
유지보수 계약서에서 반드시 확인해야 할 조항
플랫폼 제작 계약서보다 유지보수 계약서가 더 중요하다. 개발이 끝나면 서비스는 시작되고, 그때부터 매달 비용이 발생한다.
일반적인 유지보수 계약은 월 개발비의 10~20% 수준이다. 개발비가 1억 원이면 월 1,000만 원에서 2,000만 원이다. 여기에 서버비, CDN, 문자 발송, 결제 수수료가 별도로 붙는다. 월 사용자 5만 명 기준으로 인프라 비용만 월 300만 원에서 800만 원 사이가 나온다.
계약서에서 꼭 봐야 할 조항이 몇 가지 있다. 첫째, 장애 대응 시간이다. ’24시간 이내’라고만 적혀 있으면 새벽에 결제가 막혀도 다음 날 대응한다. ‘긴급 장애 2시간 이내’ 같은 구체적 문구가 필요하다.
둘째, 기능 추가 단가다. 유지보수 범위에 포함되는 변경과 별도 견적이 필요한 변경의 기준이 명확해야 한다. ‘경미한 수정’ 같은 표현은 분쟁의 씨앗이다.
셋째, 소스코드와 데이터 소유권이다. 계약이 끝났을 때 소스코드를 받을 수 있는지, 데이터를 온전히 가져갈 수 있는지 확인해야 한다. 이 조항이 없어서 발목 잡힌 대표님을 여러 명 봤다.
넷째, 계약 해지 조건이다. 최소 계약 기간과 해지 통보 기간, 위약금 조항을 확인해야 한다. 3년 묶어놓고 중도 해지 시 잔여 기간 전체 비용을 청구하는 계약도 실제로 있다.
첫 3개월에 돈이 새는 구멍 5가지
플랫폼 제작을 시작한 뒤 첫 3개월은 예산이 가장 빠르게 새는 시기다. 제가 현장에서 반복적으로 목격한 구멍은 다섯 가지다.
첫째, 요구사항 변경이다. 대표님이 중간에 ‘이 기능 하나만 추가하죠’를 세 번 하면, 그 비용은 처음 견적의 20~30%가 된다. 변경 요청은 문서로 하고, 비용과 일정 영향을 먼저 확인해야 한다.
둘째, 디자인 수정이다. 시안을 3번 이상 갈아엎으면 디자인 비용이 두 배가 된다. 디자인 확정 전에 레퍼런스 3개를 정하고, 그 이상은 참고하지 않는 규칙을 두는 게 낫다.
셋째, 외부 연동이다. 결제, 본인인증, 지도, 알림톡 같은 외부 서비스는 각각 계약과 심사가 필요하다. 심사에만 2~4주가 걸리는 경우도 많다. 이 일정을 개발 일정에 미리 넣지 않으면 전체가 밀린다.
넷째, 테스트 인력이다. 개발사가 테스트를 하긴 하지만, 실제 사용자 관점의 테스트는 대표님 쪽에서 해야 한다. 이 인력을 따로 두지 않으면 오픈 후 첫 달에 사용자 불만이 폭발한다.
다섯째, 마케팅 준비다. 플랫폼이 완성돼도 사용자가 없으면 아무 의미가 없다. 오픈 전에 최소 2개월은 사용자 유입 채널을 준비해야 한다. 이걸 빼먹으면 오픈 첫 달에 빈 플랫폼을 보게 된다.
지금 당장 해야 할 일의 우선순위
플랫폼 제작을 앞두고 있다면, 순서를 이렇게 잡는 게 안전하다.
가장 먼저 할 일은 ‘우리 서비스가 1년 뒤 어떤 숫자를 만들어야 하는가’를 한 장으로 정리하는 것이다. 사용자 수, 거래액, 수익 구조, 핵심 기능 3개. 이게 없으면 어떤 견적서를 받아도 판단할 수 없다.
두 번째는 기획서 작성이다. 외주를 주더라도 직접 쓰거나, 기획 전문가를 써서라도 문서를 만들어야 한다. 이 문서가 견적 비교의 기준이 된다.
세 번째는 개발사 3곳 이상 미팅이다. 한 곳만 만나면 시장 가격을 모른다. 같은 기획서로 3곳에서 견적을 받으면, 어디가 비정상적으로 싼지 비싼지 감이 온다.
네 번째는 유지보수와 소유권 조항을 계약서에 명시하는 것이다. 개발 계약보다 이 조항이 장기적으로 더 중요하다.
다섯 번째는 오픈 후 3개월 운영 계획이다. 누가, 어떤 지표를, 얼마의 예산으로 관리할 것인지 정해야 한다. 플랫폼 제작은 끝이 아니라 시작이다. 이 순서를 지키는 대표님들은 같은 예산으로 두 배의 결과를 낸다.
자주 묻는 질문
플랫폼 제작 비용은 보통 얼마인가요?
간단한 커뮤니티나 정보 제공 플랫폼은 3천만 원에서 6천만 원, 결제와 정산이 포함된 커머스 플랫폼은 8천만 원에서 2억 원, 복잡한 매칭이나 데이터 분석이 들어가면 2억 원 이상도 나옵니다. 이 금액은 개발비일 뿐이고, 서버와 유지보수, 마케팅 비용은 별도로 잡아야 합니다. 첫해 총예산은 개발비의 1.5배 정도로 보는 게 안전합니다.
노코드로 플랫폼 제작해도 나중에 문제없나요?
초기 검증 단계에서는 노코드가 충분히 합리적입니다. 다만 월 사용자 1만 명을 넘거나, 결제·정산 로직이 복잡해지거나, 데이터를 외부로 내보내야 하는 순간 한계가 옵니다. 이때 노코드에서 직접 개발로 옮기는 비용은 처음부터 제대로 만든 비용의 1.5배에서 2배가 든다고 보면 됩니다.
개발 기간은 보통 얼마나 걸리나요?
기획서가 완성된 상태에서 기능 2030개 기준으로 4개월에서 8개월이 일반적입니다. 여기에 기획 24주, 디자인 46주, 외부 연동 심사 24주, 테스트와 수정 4주가 추가됩니다. ‘3개월에 끝내준다’는 말은 대부분 핵심 기능만 만들고 나머지를 다음 단계로 미친다는 뜻입니다.
개발사와 계약할 때 가장 주의할 조항은 무엇인가요?
소스코드와 데이터 소유권 조항입니다. 계약 종료 시 소스코드 전체와 사용자 데이터를 어떤 형식으로 넘겨받는지 명시돼 있어야 합니다. 또한 장애 대응 시간, 기능 추가 단가 기준, 중도 해지 시 위약금 조건도 반드시 확인하세요. 이 네 가지가 빠진 계약서는 나중에 반드시 분쟁으로 이어집니다.