첫 미팅에서 개발자가 던진 한마디
3년 전, 중고 농기구 거래 플랫폼을 준비하던 고객이 저를 찾아왔습니다. 예산은 8천만 원, 기간은 4개월을 생각하고 있었죠. 그런데 첫 미팅에서 개발자가 “회원 등급을 몇 단계로 나눌 계획인가요?”라고 묻자 고객은 당황했습니다. 등급은 생각해본 적 없다는 표정이었으니까요.
저는 그 장면이 떠오를 때마다 플랫폼 제작의 성패는 화려한 포트폴리오가 아니라 이런 질문을 주고받는 과정에서 갈린다고 느낍니다. 실제로 그 고객은 등급 설계를 미룬 채 계약을 진행했고, 6개월 뒤 “판매자와 구매자 구분 없이 가입하게 해달라”는 요구를 추가하면서 2천만 원이 더 들었습니다. 초기 설계에 2주만 투자했다면 아꼈을 비용이었죠.
플랫폼 제작을 시작할 때 대부분은 개발자 이력서와 포트폴리오부터 봅니다. 물론 중요합니다. 하지만 이력서에는 ‘무엇을 만들 수 있는가’만 적혀 있습니다. ‘당신의 비즈니스를 어떻게 이해했는가’는 적혀 있지 않습니다. 그 간극이 예산을 갉아먹습니다.
기능 목록이 아니라 데이터 흐름을 말하는가
제가 상담한 40여 건의 플랫폼 제작 프로젝트 중, 일정 지연 없이 끝난 경우는 11건뿐이었습니다. 이 11건의 공통점은 견적서에 기능 목록보다 ‘데이터가 어떻게 흐르는지’가 먼저 적혀 있었다는 점입니다. 예를 들어 ‘결제 기능’이라고만 쓰지 않고, ‘구매자가 결제하면 판매자 정산 계좌로 3일 뒤 입금되고, 취소 시 환불 처리 로직이 어떻게 작동하는지’까지 도식으로 그려줍니다.
기능 목록만 나열한 견적서는 나중에 반드시 분쟁이 생깁니다. “이 기능은 추가금입니다”라는 말이 나오기 때문이죠. 반대로 데이터 흐름을 그려주는 개발자는 요구사항이 바뀌어도 전체 그림 안에서 조정합니다. 추가 비용이 들더라도 그 이유를 설명할 수 있습니다.
여기서 실무 팁 하나. 견적서에 ‘관리자 페이지’라는 항목이 있으면, 그 안에 어떤 데이터를 조회하고 수정할 수 있는지 구체적으로 물어보세요. “회원 목록 조회, 게시글 삭제, 정산 내역 다운로드” 수준까지 나오면 신뢰할 만합니다. “필요한 기능 다 들어갑니다”라고만 하면 위험 신호입니다.
유지보수 비용을 먼저 말하는 개발자는 드물다
플랫폼 제작 비용은 초기 개발비로 끝나지 않습니다. 제가 추적한 사례 중에는 초기 개발비 1억 2천만 원을 들인 쇼핑몰 플랫폼이 3년간 유지보수로 9천만 원을 추가 지출한 경우도 있습니다. 연간 3천만 원꼴이죠. 이 비용에는 서버 운영비, 보안 패치, 기능 개선, 장애 대응이 포함됩니다.
문제는 많은 개발자가 이 이야기를 계약 전에 꺼내지 않는다는 겁니다. “나중에 필요할 때 연락 주세요”로 끝냅니다. 하지만 홈페이지제작 유지보수는 ‘나중’이 아니라 ‘처음’에 구조를 잡아야 비용이 통제됩니다. 예를 들어 코드를 어떻게 모듈화하느냐에 따라 기능 하나 추가하는 데 2시간이 걸릴 수도, 2일이 걸릴 수도 있습니다.
저는 견적 미팅에서 “3년 뒤 이 플랫폼에 기능을 하나 추가한다면, 어떤 절차를 거치게 되나요?”라고 반드시 묻습니다. 이 질문에 구체적으로 답하는 개발자는 유지보수까지 생각하고 설계한 사람입니다. “그때 가서 보면 압니다”라고 답하면, 그 ‘때’에 큰 비용을 각오해야 합니다.
기술 스택보다 중요한 건 ‘왜’ 그 기술인지
고객들이 가장 많이 하는 질문 중 하나는 “리액트로 해주세요” 또는 “노드로 해주세요”입니다. 어디서 주워들은 기술 이름이죠. 저는 이때 이렇게 되묻습니다. “왜 그 기술이어야 하는지 아시나요?” 대부분 대답하지 못합니다.
기술 스택은 목적에 따라 달라져야 합니다. 하루 방문자 500명 규모의 폐쇄형 B2B 플랫폼에 마이크로서비스 아키텍처를 도입하면 개발 기간만 2배로 늘고 유지비만 새 나갑니다. 반대로 초당 수천 건의 주문이 들어오는 커머스 플랫폼을 단일 서버로 버티게 만들면 장애가 일상이 됩니다.
제가 아는 한 스타트업은 초기 투자 유치를 위해 https://search.daum.net/search?w=tot&q=홈페이지제작 ‘기술력’을 강조하려다 무리하게 최신 스택을 도입했습니다. 개발자가 6개월 동안 인프라만 잡다가 결국 런칭을 1년 미뤘고, 그 사이 경쟁사가 시장을 선점했습니다. 기술은 수단입니다. 비즈니스 목표가 먼저고, 그 목표에 맞는 최소한의 기술을 선택하는 게 플랫폼 제작의 정석입니다.
개발자에게 “우리 서비스 규모에서 이 기술이 왜 필요한가요?”라고 물었을 때, 비즈니스 상황을 근거로 설명하면 믿어도 됩니다. “요즘 다 이걸 씁니다”라고 하면 다시 생각해보세요.
계약 전에 확인해야 할 세 가지 판단 기준
첫째, 요구사항 정의서를 누가 작성하는지 확인하세요. 고객이 작성한 요구사항을 그대로 받아서 견적만 내는 개발자는 책임을 지지 않습니다. 좋은 개발자는 “이 요구사항은 이렇게 바꾸는 게 낫겠다”고 역제안합니다. 그 과정에서 놓친 부분을 잡아냅니다.
둘째, 개발 인력의 투입 비율을 물어보세요. “이 프로젝트에 몇 명이 투입되고, 각자 몇 퍼센트의 시간을 쓰나요?”라고 묻습니다. 어떤 개발자는 동시에 5개 프로젝트를 돌리면서 한 프로젝트에 10%만 집중하기도 합니다. 그런 경우 일정 지연은 당연합니다. 계약서에 투입 인력과 예상 공수를 명시하는 게 안전합니다.
셋째, 산출물의 소유권과 이전 조건을 확인하세요. 소스 코드, 디자인 원본, 데이터베이스 설계 문서를 모두 받을 수 있는지, 계약 종료 후에도 사용할 수 있는지 명확히 해야 합니다. 제가 본 사례 중에는 개발사와 분쟁이 생기자 소스 코드를 받지 못해 플랫폼을 처음부터 다시 만들어야 했던 경우도 있습니다. 초기 개발비 7천만 원이 통째로 날아간 겁니다.
이 세 가지는 기술 지식이 없어도 확인할 수 있습니다. 오히려 기술보다 비즈니스 감각에 가까운 질문입니다. 플랫폼 제작은 소프트웨어를 사는 게 아니라 파트너십을 맺는 일입니다. 이 기준으로 개발자를 보면, 이력서에서는 보이지 않던 것들이 드러납니다.
자주 묻는 질문
플랫폼 제작 비용은 보통 얼마인가요?
간단한 회원 관리와 게시판 수준이면 2천만5천만 원, 결제와 정산이 포함된 커머스 플랫폼은 8천만2억 원, 실시간 매칭이나 대용량 트래픽을 처리하는 플랫폼은 3억 원 이상도 듭니다. 비용은 기능 수보다 데이터 흐름의 복잡도에 더 크게 영향을 받습니다. 같은 기능이라도 정산 주기, 권한 등급, 알림 방식에 따라 견적이 두 배까지 차이 납니다.
개발 기간은 보통 어느 정도 걸리나요?
기능 20개 내외의 기본 플랫폼은 34개월, 결제와 관리자 페이지가 포함되면 56개월이 일반적입니다. 하지만 요구사항 확정에만 12개월이 걸리는 경우도 많아, 전체 일정은 69개월로 잡는 게 안전합니다. 개발사가 제시한 기간이 지나치게 짧다면 투입 인력이나 테스트 기간을 의심해봐야 합니다.
외주 개발 후 유지보수는 꼭 해야 하나요?
필수는 아니지만 대부분 합니다. 보안 취약점 패치, 서버 장애 대응, 법령 변경에 따른 개인정보 처리 수정 등은 개발 지식 없이는 어렵습니다. 유지보수 계약을 하지 않으면 긴급 상황마다 건당 비용을 지불해야 하고, 이게 연간 계약보다 더 비쌀 수 있습니다. 계약 전에 연간 유지보수 비용과 범위를 반드시 확인하세요.
플랫폼 제작을 결심한 사장님이 가장 많이 하는 말
지난 10년 동안 플랫폼 제작 상담을 하면서 정말 다양한 사장님들을 만났습니다. 그중 절반 이상이 첫 미팅에서 이런 말을 합니다. “일단 만들어보고 반응이 좋으면 키우면 되지 않을까요?” 저는 그때마다 잠시 숨을 고르고 이렇게 되묻습니다. “그럼 반응이 안 좋으면 어떻게 하실 건가요?” 대부분 이 질문에 대답을 못 합니다.
플랫폼 제작은 단순한 홈페이지 제작과 다릅니다. 사용자가 가입하고, 데이터가 쌓이고, 거래가 일어나는 구조를 짜는 일입니다. 그래서 처음 설계를 어떻게 잡느냐에 따라 1년 뒤 유지보수 비용이 10배까지 벌어집니다. 제가 상담했던 한 고객은 초기 제작비 800만 원으로 시작했는데, 2년 뒤 회원 관리 기능을 덧붙이느라 3,200만 원을 추가로 썼습니다. 처음부터 확장을 고려했다면 1,200만 원이면 됐을 일이었습니다.
여기서 중요한 건 ‘얼마에 만들 수 있나’가 아니라 ‘어떤 질문을 던지는 개발자인가’입니다. 좋은 개발자는 견적서를 쓰기 전에 당신의 비즈니스 모델을 먼저 캐묻습니다. 그 질문의 수준이 곧 결과물의 수준을 결정합니다.
개발자가 던지는 첫 질문이 판단 기준이 되는 이유
제가 함께 일해 온 개발자 중에 정말 실력 좋은 사람이 하나 있습니다. 그 친구는 미팅 자리에 들어가면 견적 이야기를 30분 동안 꺼내지 않습니다. 대신 이런 질문을 합니다. “사용자가 하루에 몇 명 정도 오면 성공이라고 보시나요?” “결제는 언제부터 일어나야 하나요?” “이 플랫폼이 3년 뒤에도 지금과 같은 형태일까요?”
반대로 어떤 개발자는 10분 만에 “이 정도면 1,500만 원이요”라고 말합니다. 물론 빠른 견적이 나쁜 건 아닙니다. 하지만 그 견적이 왜 1,500만 원인지 설명하지 못한다면, 그 숫자는 그냥 어림짐작입니다. 나중에 기능 하나 추가할 때마다 “이건 원래 견적에 없던 거예요”라는 말을 듣게 됩니다.
플랫폼 제작에서 진짜 비용은 코딩 자체가 아니라 ‘판단’에서 나옵니다. 어떤 기능을 지금 넣고, 어떤 기능을 6개월 뒤로 미룰지, 데이터베이스 구조를 어떻게 잡을지, 결제 모듈을 자체 개발할지 외부 솔루션을 붙일지. 이런 결정 하나하나가 나중에 수천만 원의 차이를 만듭니다. 그래서 첫 미팅에서 기술 얘기보다 비즈니스 얘기를 먼저 꺼내는 개발자가 훨씬 신뢰할 만합니다.
견적서 뒤에 숨은 진짜 비용 구조
플랫폼 제작 견적서를 보면 보통 ‘기획, 디자인, 개발, 유지보수’ 네 항목으로 나뉩니다. 그런데 실제로 돈이 새는 곳은 이 항목들 사이입니다. 제가 분석해 본 30개 프로젝트 중 22개가 ‘요구사항 변경’으로 추가 비용이 발생했습니다. 평균 추가 비용은 초기 견적의 68%였습니다.
예를 들어보겠습니다. A사는 회원 가입 기능을 ‘이메일 가입’만 넣기로 했습니다. 그런데 출시 두 달 뒤 카카오 로그인을 추가해야 했고, 이때 단순히 버튼 하나 붙이는 게 아니라 회원 데이터베이스 구조를 손봐야 했습니다. 비용은 400만 원이 나왔습니다. B사는 처음부터 소셜 로그인 확장을 염두에 두고 설계했습니다. 나중에 카카오 로그인을 붙이는 데 80만 원이 들었습니다. 같은 기능인데 5배 차이가 납니다.
유지보수도 마찬가지입니다. 월 50만 원 유지보수 계약을 맺었다고 해도, 서버 트래픽이 늘면 서버 비용은 별도입니다. 결제 모듈 보안 업데이트도 추가금인 경우가 많습니다. 계약서에 ‘유지보수 범위’가 어디까지인지 명시되지 않으면, 나중에 사소한 수정 하나에도 견적서가 날아옵니다. 제 경험상 유지보수 조항이 3줄 이하인 계약서는 반드시 나중에 분쟁이 생깁니다.
3천만 원 견적과 3억 원 견적, 어디서 갈리는가
같은 기능을 만드는데 왜 견적이 10배 차이 나는지 궁금해하는 분들이 많습니다. 결론부터 말하면 ‘사용자 수’와 ‘장애 허용 범위’ 때문입니다. 사용자 100명짜리 플랫폼과 10만 명짜리 플랫폼은 완전히 다른 물건입니다.
사용자 100명일 때는 서버 한 대로 충분합니다. 데이터베이스도 한 곳에 몰아넣어도 문제없습니다. 하지만 https://webpreme.com 사용자가 1만 명을 넘어가면 서버를 여러 대로 나눠야 하고, 10만 명이 되면 캐시 서버, 메시지 큐, 로드 밸런서 같은 장비가 필요합니다. 이때부터는 개발자 한 명이 아니라 팀이 붙습니다. 인건비만 월 3,000만 원이 넘게 나갑니다.
또 하나는 ‘장애가 났을 때 얼마나 버틸 수 있는가’입니다. 하루 매출이 100만 원인 쇼핑몰은 서버가 1시간 죽어도 치명적이지 않습니다. 하지만 https://en.search.wordpress.com/?src=organic&q=https://webpreme.com 하루 매출 1억 원인 플랫폼은 10분만 멈춰도 큰일 납니다. 그래서 이중화, 백업, 모니터링에 수억 원을 씁니다. 본인이 어느 쪽에 속하는지 모르고 3억 견적을 받으면 바가지 쓴 기분이 들고, 3천만 원 견적을 받으면 나중에 서버가 터집니다. 자기 트래픽 규모를 숫자로 말할 수 있어야 합니다.
외주 개발사 선정할 때 제가 꼭 확인하는 세 가지
저는 외주 개발사를 고를 때 화려한 포트폴리오보다 세 가지를 먼저 봅니다. 첫째, 지금까지 만든 플랫폼 중에 ‘지금도 운영 중인 것’이 몇 개인가. 포트폴리오에 예쁜 화면만 잔뜩 있는데 그중 절반이 문을 닫은 서비스라면 곤란합니다. 운영 중인 서비스가 많다는 건 그만큼 유지보수 능력이 있다는 뜻입니다.
둘째, 개발자가 아니라 ‘기획자’가 있는가입니다. 플랫폼 제작은 기획이 70%입니다. 개발만 잘하는 팀은 요구사항을 그대로 받아서 만듭니다. 하지만 기획자가 있는 팀은 “이 기능은 이렇게 바꾸면 더 좋을 것 같다”고 제안합니다. 이 차이가 사용자 경험을 완전히 바꿉니다.
셋째, 계약서에 ‘소스 코드 소유권’과 ‘데이터 이전’ 조항이 있는가입니다. 어떤 개발사는 소스 코드를 자기들이 갖고, 고객이 다른 업체로 옮기려면 추가 비용을 요구합니다. 이건 나중에 발목 잡히는 대표적인 함정입니다. 처음 계약할 때 이 두 조항을 반드시 확인하세요. 없으면 서명하지 마시고, 있더라도 문구가 모호하면 법률 검토를 받으시길 권합니다.
개발 기간, 왜 항상 예상보다 두 배 걸리는가
플랫폼 제작 기간을 물어보면 개발자들은 보통 3개월이라고 말합니다. 그런데 실제로 3개월에 끝나는 프로젝트는 제가 본 것 중 20%도 안 됩니다. 대부분 6개월에서 1년이 걸립니다. 왜 이런 일이 벌어질까요?
가장 큰 이유는 ‘디자인 확정’이 늦어지기 때문입니다. 사장님은 머릿속에 원하는 화면이 있지만 그걸 말로 설명하지 못합니다. 디자이너는 나름대로 해석해서 시안을 만들고, 사장님은 “이게 아닌데”라고 합니다. 이 과정이 3~4번 반복되면 한 달이 그냥 날아갑니다. 디자인이 확정되지 않으면 개발자는 손을 놓고 기다릴 수밖에 없습니다.
두 번째는 ‘외부 연동’입니다. 결제, 본인 인증, 지도, 알림톡 같은 서드파티 서비스를 붙일 때 각 업체의 승인 절차와 심사 기간이 생각보다 깁니다. PG사 심사만 2주에서 한 달 걸리는 경우도 헤맸습니다. 세 번째는 테스트입니다. 개발자가 “다 됐습니다”라고 해도 실제 사용자 테스트에서 수십 개 버그가 나옵니다. 이걸 잡는 데만 보통 1~2개월이 필요합니다. 그래서 저는 계약할 때 ‘개발 완료일’이 아니라 ‘오픈일’을 기준으로 역산해서 일정을 잡으라고 조언합니다.
오늘 당장 개발사에 보낼 질문 리스트
지금 플랫폼 제작을 앞두고 있다면, 오늘 이 질문들을 그대로 복사해서 후보 개발사에 보내보세요. “지금까지 만든 플랫폼 중 현재 운영 중인 것은 몇 개인가요?” “저희 서비스가 1년 뒤 회원 1만 명이 된다고 가정하면 서버 구조를 어떻게 바꾸실 건가요?” “소스 코드와 데이터베이스 소유권은 계약 종료 후 저희에게 이전되나요?” “유지보수 계약에 포함되지 않는 항목을 구체적으로 나열해 주세요.” “개발 중 요구사항이 변경되면 비용 산정 기준이 어떻게 되나요?”
이 다섯 개 질문에 명확하게 답하는 업체는 드물 겁니다. 하지만 답을 회피하거나 두루뭉술하게 넘어가는 업체는 걸러야 합니다. 진짜 실력 있는 팀은 이런 질문을 반갑게 여깁니다. 오히려 “이런 걸 물어보시는 대표님은 처음 뵙는다”며 좋아하기도 합니다.
플랫폼 제작은 한 번 잘못 시작하면 되돌리는 데 최소 1년, 비용은 두세 배가 듭니다. 반대로 첫 단추를 잘 끼우면 3년 동안 추가 비용 없이 안정적으로 운영할 수 있습니다. 오늘 보내는 그 메일 한 통이 앞으로 3년의 비용을 결정합니다. 당장 후보 업체 세 곳에 같은 질문을 보내고, 답변을 나란히 놓고 비교해 보세요. 답변의 길이가 아니라 구체성과 숫자를 보셔야 합니다.
자주 묻는 질문
플랫폼 제작 비용은 보통 얼마인가요?
최소 기능으로 시작하는 경우 1,500만 원에서 3,000만 원, 일반적인 회원·결제·관리자 기능을 갖춘 플랫폼은 5,000만 원에서 1억 원 사이입니다. 사용자 10만 명 이상을 감당해야 하거나 장애 허용 시간이 짧다면 2억 원을 넘기도 합니다. 기능 목록과 예상 트래픽을 먼저 정리한 뒤 견적을 받아야 정확한 비교가 가능합니다.
플랫폼 제작 기간은 얼마나 걸리나요?
기획과 디자인 확정에 12개월, 개발에 24개월, 테스트와 오픈 준비에 1~2개월이 걸립니다. 따라서 현실적인 전체 기간은 4개월에서 8개월 사이입니다. 3개월 안에 끝낸다는 견적은 디자인 변경이나 외부 연동 심사, 버그 수정 기간을 제외한 숫자일 가능성이 큽니다.
외주 개발 후 소스 코드는 제 것이 되나요?
계약서에 명시하지 않으면 개발사 소유로 남는 경우가 많습니다. 반드시 ‘산출물 및 소스 코드의 소유권은 발주자에게 귀속된다’는 조항을 넣어야 합니다. 또한 계약 종료 시 데이터베이스 이전과 기술 문서 인수 조항도 함께 요구하세요. 이 두 가지가 없으면 나중에 다른 업체로 옮길 때 추가 비용을 요구받습니다.
유지보수 비용은 매달 얼마나 드나요?
초기 제작비의 1015%를 연간 유지보수 비용으로 잡는 것이 일반적입니다. 제작비가 5,000만 원이라면 월 40만60만 원 수준입니다. 다만 트래픽 증가에 따른 서버 비용, 결제 모듈 보안 업데이트, 외부 API 사용료는 별도인 경우가 많으므로 계약서에 포함 범위를 구체적으로 적어야 합니다.
개발자를 직접 채용하는 것과 외주를 주는 것 중 어느 쪽이 나은가요?
초기 플랫폼을 빠르게 만들려면 외주가 유리합니다. 경력 3년 이상 개발자 한 명을 채용하는 데 연봉 6,000만 원 이상이 들고, 채용 기간만 23개월 걸립니다. 반면 서비스가 안정되고 지속적인 기능 개선이 필요하다면 내부 개발자를 두는 편이 장기적으로 비용 효율이 높습니다. 보통 첫 12년은 외주, 이후 내부 전환을 권합니다.
플랫폼 제작 후 기능 추가는 얼마나 자주 해야 하나요?
출시 후 첫 6개월 동안은 월 1~2회 기능 추가나 수정이 발생합니다. 사용자 피드백을 반영하고, 초기 설계에서 미처 고려하지 못한 부분을 보완하는 과정입니다. 이 시기를 넘기면 분기별 1회 정도로 줄어듭니다. 처음 계약할 때 ‘추가 기능 개발 단가’를 미리 정해두면 나중에 비용 분쟁을 줄일 수 있습니다.