CPI 모터 유럽

첫 미팅에서 기능 목록부터 꺼내는 대표님들이 자주 겪는 일

플랫폼 제작을 결심한 대표님들과 첫 미팅을 하다 보면, 책상 위에 A4용지 서너 장짜리 기능 목록을 올려놓는 경우가 많습니다. 경쟁사 앱을 캡처해 오거나, 직원들이 취합한 요구사항을 빼곡히 적어오신 겁니다. 그 자체로 준비가 철저하다는 인상을 줍니다. 문제는 그다음입니다. “이 기능들 다 넣으려면 얼마나 걸릴까요?”라는 질문에 제가 “일단 이 중에 3개월 안에 꼭 필요한 건 뭔가요?”라고 되묻으면, 대개 대답이 막힙니다. 모든 기능이 다 중요하다고 생각하니까요.

실제로 제가 상담했던 한 교육 스타트업 대표는 기능 목록에 무려 87개 항목을 적어왔습니다. 회원가입, 강의 결제, 수강 관리, 커뮤니티, 쪽지, 알림, 리뷰, 쿠폰, 추천인, 통계 대시보드… 여기까지는 일반적입니다. 그런데 ‘강사 전용 정산 시스템’과 ‘학습자 간 실시간 화상 스터디’까지 1차 오픈에 넣겠다고 했습니다. 당시 예산은 4천만 원, 희망 오픈 시점은 4개월 뒤였습니다.

그 조합이 얼마나 위험한지 설명하는 데만 두 시간이 걸렸습니다. 화상 스터디 하나만 제대로 만들려면 WebRTC 기반 미디어 서버, TURN 서버, 녹화·저장, 동시 접속 부하 테스트까지 필요합니다. 그 기능 하나에만 3개월과 1억 원 이상이 들어갈 수 있습니다. 결국 그 대표는 1차 오픈에서 화상 기능과 정산 시스템을 빼고, 대신 결제-수강-알림 흐름을 탄탄하게 다듬는 쪽으로 방향을 틀었습니다. 3개월 만에 오픈했고, 지금은 2차 고도화로 정산 시스템을 붙이고 있습니다.

플랫폼 제작 견적이 3천만 원과 3억 원으로 갈리는 진짜 이유

같은 기능 목록을 들고 가도 업체마다 견적이 10배 차이 나는 이유는 크게 세 가지입니다. 첫째, ‘만들 수 있는 수준’의 차이입니다. 같은 회원가입이라도 단순 이메일 가입인지, 소셜 로그인 3종에 본인인증과 2단계 인증까지 붙이는지에 따라 공수가 3배 이상 벌어집니다. 둘째, ‘누가 만드는가’입니다. 프리랜서 2명이 만드는 것과 15명 팀이 투입되는 것은 결과물의 안정성 자체가 다릅니다. 셋째, ‘어디까지 책임지는가’입니다. 오픈 후 1년간 유지보수와 장애 대응을 포함하는지, 아니면 오픈과 동시에 손을 떼는지에 따라 총비용이 완전히 달라집니다.

제가 본 가장 극단적인 사례는 반려동물 커머스 플랫폼이었습니다. A업체는 3천2백만 원에 3개월, B업체는 2억8천만 원에 6개월을 제안했습니다. 대표는 당연히 A를 선택했습니다. 그런데 6개월 뒤 추가 개발비로 1억1천만 원을 더 썼습니다. A업체가 만든 초기 버전은 동시 접속 100명에서 결제가 멈췄고, 상품 등록 API가 수동 입력 방식이라 SKU 1만 개를 관리할 수 없었습니다. 급한 불을 끄느라 B업체를 다시 불러 아키텍처를 갈아엎었습니다. 처음부터 B를 선택했으면 6개월과 2억8천만 원으로 끝났을 일입니다.

그래서 저는 견적서를 받을 때 총액보다 ‘무엇이 포함되지 않았는지’를 먼저 보라고 말합니다. 서버 비용, 결제 수수료, 앱스토어 등록, 유지보수 기간, 추가 기능 단가, 소스코드 소유권. 이 여섯 가지가 명시되지 않은 견적서는 아무리 싸도 신뢰하지 않습니다.

노코드로 시작할까, 외주로 만들까, 자체 개발팀을 꾸릴까

이 질문을 받을 때마다 저는 ‘무엇을 파느냐’보다 ‘얼마나 자주 바꾸느냐’를 먼저 봅니다. 비즈니스 모델이 아직 흔들리고 기능을 매주 바꿔야 한다면 노코드가 답입니다. 반대로 요구사항이 비교적 고정되어 있고, 트래픽이 예측 가능하며, 3년 이상 운영할 계획이라면 외주나 자체 개발이 낫습니다.

노코드의 현실적인 한계도 분명합니다. 월 구독료가 30만~80만 원 수준이라 초기 비용은 거의 없지만, 사용자가 5천 명을 넘어가면 월 200만 원 이상으로 뛰는 경우가 흔합니다. 3년이면 7천만 원 이상입니다. 게다가 결제 로직이나 정산 같은 핵심 기능은 노코드로 구현하기 어렵고, 데이터 이관도 까다롭습니다. 저는 노코드를 ‘검증용’으로만 권합니다. 시장 반응을 6개월 안에 확인하고, 유효성이 증명되면 그때 본격 플랫폼 제작으로 넘어가는 겁니다.

외주는 속도와 품질의 균형점입니다. 다만 외주사가 내 비즈니스를 얼마나 이해하는지가 관건입니다. 같은 기능이라도 도메인 이해도가 높으면 불필요한 기능을 줄여주고, 낮으면 요구사항을 기계적으로 받아 적기만 합니다. 첫 미팅에서 “이 기능은 왜 필요한가요?”라고 되묻는 업체가 좋은 업체입니다.

자체 개발팀은 가장 비쌉니다. 개발자 3명, 기획 1명, 디자이너 1명만 채용해도 연간 인건비만 4억 원을 넘습니다. 대신 제품에 대한 이해도와 속도는 비교할 수 없습니다. 저는 시리즈 A 투자를 받았거나, 월 매출 1억 원이 홈페이지제작 안정적으로 나오는 시점에 자체팀을 고려하라고 조언합니다. 그 전에는 외주나 노코드로 버티는 게 현실적입니다.

기능을 빼는 결단이 오픈 일정을 지킨다

플랫폼 제작에서 일정이 밀리는 이유는 대개 기술 문제가 아닙니다. 기능을 빼지 못해서입니다. 제가 참여했던 프로젝트 중에 6개월 일정이 11개월로 늘어난 케이스가 있었는데, 원인을 추적해보니 1차 오픈 직전에 ‘관리자용 대시보드에 실시간 그래프를 넣자’는 요구가 추가된 것이었습니다. 그 기능 하나 때문에 https://ko.wikipedia.org/wiki/홈페이지제작 데이터 파이프라인을 다시 설계해야 했고, 결국 2개월이 더 걸렸습니다.

기능 우선순위를 정하는 실용적인 기준이 있습니다. 첫째, 이 기능이 없으면 사용자가 서비스를 이용할 수 없는가. 둘째, 이 기능이 매출과 직접 연결되는가. 셋째, 이 기능을 나중에 붙여도 데이터 손실이 없는가. 이 세 질문에 모두 ‘예’라고 답할 수 있는 기능만 1차에 넣습니다. 나머지는 2차, 3차로 미룹니다.

실제로 이 기준을 적용한 한 핀테크 스타트업은 1차 오픈 기능을 22개에서 9개로 줄였습니다. 대신 결제 실패율을 0.3% 이하로 관리하고, 앱 로딩 속도를 1.2초 안으로 잡는 데 집중했습니다. 결과적으로 오픈 후 3개월 만에 월 활성 사용자 4만 명을 확보했습니다. 기능 수가 승부를 가르지 않는다는 걸 보여준 사례입니다.

기능을 빼는 건 포기가 아니라 선택입니다. 무엇을 먼저 줄지 결정하는 회의에 두 시간을 쓰는 것이, 일정이 밀린 뒤 수습하느라 두 달을 쓰는 것보다 훨씬 저렴합니다.

개발사와의 계약서에서 반드시 확인해야 할 조항

계약서에 ‘소스코드 귀속’ 조항이 없어서 분쟁이 난 사례를 여러 번 봤습니다. 외주 개발 후 다른 업체로 옮기려는데 이전 업체가 소스코드를 넘겨주지 않아 처음부터 다시 만든 경우도 있습니다. 계약서에는 소스코드와 설계 문서, 데이터베이스 스키마, API 명세서의 소유권이 발주자에게 있음을 명시해야 합니다.

유지보수 조항도 중요합니다. ‘무상 하자 보수 6개월’이라는 문구만 있고, 그 이후 유지보수 단가가 명시되지 않은 계약서가 많습니다. 6개월 뒤에 월 500만 원을 요구하는 경우도 있습니다. 계약 시점에 유지보수 월 단가와 범위를 미리 정해두는 게 안전합니다. 보통 전체 개발비의 1015%를 연간 유지보수 비용으로 잡습니다. 1억 원짜리 프로젝트라면 연 1천만1천5백만 원 수준입니다.

지체상금 조항도 확인하세요. 일정이 밀렸을 때 발주자가 받을 수 있는 보상이 명시되어 있어야 합니다. 보통 총 계약금의 0.1~0.3%를 지연 일수만큼 받는 구조입니다. 다만 이 조항이 지나치게 강하면 업체가 무리하게 일정을 맞추다 품질을 떨어뜨릴 수 있으니 균형이 필요합니다.

마지막으로 검수 기준입니다. ‘정상 작동’이라는 모호한 표현 대신, 동시 접속 1천 명에서 응답 시간 2초 이내, 결제 성공률 99% 이상 같은 측정 가능한 지표를 넣으세요. 이 기준이 없으면 오픈 후에도 “이 정도면 된 거 아닌가요”라는 실랑이가 반복됩니다.

플랫폼 제작 파트너를 고를 때 제가 마지막으로 보는 것

업체를 고를 때 포트폴리오와 견적서만 보면 절반만 보는 겁니다. 저는 세 가지를 더 확인합니다. 첫째, 그 업체가 최근 1년간 만든 서비스 중 실제로 운영 중인 게 몇 개인지. 개발만 하고 유지보수를 안 하는 업체는 장애 대응 능력이 검증되지 않은 겁니다. 둘째, 장애가 났을 때 연락 체계가 어떻게 되는지. 새벽에 결제가 멈췄을 때 30분 안에 대응할 수 있는지 물어보세요. “최선을 다하겠습니다”라는 답변은 답변이 아닙니다. 셋째, 이 업체가 우리 도메인을 이해하려고 노력하는지. 첫 미팅에서 경쟁사 분석 자료를 가져오거나, 우리 비즈니스 모델의 약점을 지적하는 업체는 좋은 신호입니다.

비용도 중요하지만, 저는 ‘총소유비용(TCO)’으로 보라고 권합니다. 초기 개발비 5천만 원에 연 유지보수 1천만 원인 업체와, 초기 8천만 원에 연 500만 원인 업체가 있다면 3년 총비용은 각각 8천만 원과 9천5백만 원입니다. 여기에 장애로 인한 매출 손실, 기능 추가 비용까지 더하면 역전되는 경우도 많습니다.

결국 플랫폼 제작은 ‘얼마에 만드느냐’가 아니라 ‘얼마에 운영하고 개선하느냐’의 문제입니다. 첫 삽을 뜨기 전에 3년 뒤를 상상해보세요. 그때도 함께 일하고 싶은 파트너인지가 가장 중요한 기준입니다. 저는 그 질문에 ‘예’라고 답할 수 있는 업체와 일하라고 조언합니다. 가격이 20% 비싸더라도 말입니다.

자주 묻는 질문

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

간단한 MVP는 3천만5천만 원, 일반적인 커머스나 예약 플랫폼은 8천만1억5천만 원, 고도화된 기능이 포함되면 2억 원 이상으로 봅니다. 다만 이 금액은 기능 수보다 동시 접속 처리, 결제 연동, 관리자 도구의 완성도에 따라 크게 달라집니다. 견적을 받을 때는 총액보다 포함 범위와 유지보수 조건을 함께 확인하세요.

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

1차 오픈 기준으로 최소 3개월에서 6개월이 일반적입니다. 기능을 10개 이내로 줄이고 결제와 회원 흐름에 집중하면 3개월도 가능하지만, 정산이나 실시간 기능이 들어가면 6개월 이상 필요합니다. 기간을 단축하려면 기능을 빼는 결단이 필수이며, 이 결정을 미루면 오히려 두 배로 늘어납니다.

외주 개발 후 소스코드는 제 것이 되나요?

계약서에 명시하지 않으면 소유권 분쟁이 생길 수 있습니다. 반드시 소스코드, 설계 문서, 데이터베이스 스키마, API 명세서의 귀속을 발주자로 명시하고, 계약 종료 시 이관 의무를 조항에 넣으세요. 구두 약속만 믿으면 나중에 다른 업체로 옮길 때 처음부터 다시 개발해야 할 수도 있습니다.

견적서에 숨은 진짜 비용, 첫 삽 뜨기 전에 확인해야 할 3가지

지난해 상담한 한 스타트업 대표는 플랫폼 제작 견적서를 세 곳에서 받아왔다. 가장 낮은 곳은 3,200만 원, 가장 높은 곳은 1억 8,000만 원이었다. 그는 당연히 3,200만 원짜리를 선택했다. 1년 뒤 그 플랫폼을 유지하는 데 들어간 총비용은 1억 5,200만 원이었다. 추가 개발비, 서버 증설, 보안 패치, 결제 모듈 연동 실패로 인한 재작업까지 포함한 숫자다.

견적서에 적힌 금액은 전체 비용의 30%도 안 되는 경우가 많다. 특히 플랫폼은 웹사이트와 다르다. 회원이 늘고, 거래가 발생하고, 데이터가 쌓이는 순간부터 비용 구조가 완전히 달라진다. 처음 견적서에는 ‘관리자 페이지’ 한 줄로 적혀 있던 항목이 실제로는 권한 관리, 통계 대시보드, 정산 시스템, 알림 발송 등 20개가 넘는 기능으로 쪼개진다.

내가 현장에서 가장 먼저 보는 것은 기능 목록이 아니다. ‘이 플랫폼이 1년 뒤 하루 방문자 1만 명을 감당할 수 있는가’다. 이 질문에 개발사가 구체적인 수치로 답하지 못하면, 그 견적서는 절반만 맞는 것이다. 서버 비용, CDN, 데이터베이스 확장, 로그 관리 도구까지 포함한 3년 총소유비용(TCO)을 계산해 달라고 요구해야 한다.

외주 개발사가 ‘나중에 추가하죠’라고 말할 때 속으로 계산해야 할 것

플랫폼 제작 미팅에서 가장 자주 듣는 말이 “이건 1차 오픈 후에 추가하는 게 좋겠습니다”다. 물론 맞는 말이다. 하지만 그 ‘나중’이 얼마나 걸리고, 얼마가 드는지는 아무도 말해주지 않는다. 내가 경험한 바로는 1차 오픈 후 추가 개발은 초기 견적의 1.5배에서 3배까지 치솟는다.

이유는 간단하다. 초기 설계에 없던 기능을 나중에 넣으면 데이터베이스 구조를 바꿔야 하고, 기존 코드와 충돌을 잡아야 한다. 한 고객사는 예약 플랫폼을 만들면서 ‘리뷰 기능’을 2차로 미뤘다. 1차 오픈 후 리뷰 기능을 넣는 데 초기 예상 비용 800만 원이 아니라 2,700만 원이 들었다. 회원 테이블과 예약 테이블, 결제 테이블을 모두 건드려야 했기 때문이다.

그래서 나는 대표들에게 이렇게 말한다. “지금 당장 안 만들어도 되지만, 데이터 구조는 처음부터 잡아두세요.” 테이블 설계와 API 인터페이스만 미리 정의해도 나중에 드는 비용을 40% 이상 줄일 수 있다. 개발사가 이 부분을 귀찮아하면, 그 회사는 단기 프로젝트만 해온 곳일 가능성이 높다.

노코드로 시작할까, 직접 개발할까? 3개월과 1년 사이에서 흔들리는 대표를 위한 현실 점검

노코드 도구로 플랫폼 제작을 시작하는 대표들이 부쩍 늘었다. 월 5만 원에서 30만 원이면 기본적인 회원 관리와 결제까지 붙일 수 있으니 솔깃하다. 하지만 https://ko.wikipedia.org/wiki/홈페이지제작 노코드는 ‘검증’ 단계에서만 유효하다. 하루 거래 100건을 넘기면 수수료가 급격히 올라가고, 커스터마이징에 한계가 온다.

한 고객은 노코드로 중고거래 플랫폼을 만들어 6개월 만에 월 거래액 3,000만 원을 찍었다. 그런데 노코드 업체가 거래액의 3%를 수수료로 가져가면서 수익의 40%가 사라졌다. 결국 자체 개발로 전환하는 데 8개월과 1억 2,000만 원이 들었다. 노코드에서 쌓은 데이터를 옮기는 데만 2개월이 걸렸다.

반대로 직접 개발은 처음부터 모든 것을 통제할 수 있지만, 개발자 채용과 관리에 최소 6개월에서 1년이 필요하다. 초기 스타트업이라면 이 시간을 버티기 어렵다. 내가 권하는 기준은 이렇다. ‘3개월 안에 시장 반응을 확인해야 한다’면 노코드로 시작하되, 데이터 이전 계획을 처음부터 세워라. ‘처음부터 차별화된 기능이 핵심’이라면 외주 개발에 투자하라. 단, 유지보수 인력을 반드시 확보하라.

개발사 선정, 기술력보다 먼저 봐야 할 3가지 신호

플랫폼 제작 외주를 맡길 때 대표들은 포트폴리오와 기술 스택부터 본다. 물론 중요하다. 하지만 내가 10년 넘게 지켜본 결과, 프로젝트를 망치는 결정적 원인은 기술력이 아니었다. 커뮤니케이션 구조와 책임 범위, 그리고 ‘유지보수 태도’다.

첫째, 요구사항을 문서로 정리해주는가. 말로만 “네, 됩니다” 하는 개발사는 반드시 문제를 일으킨다. 기능 정의서, 화면 설계서, API 명세서를 만들어주는 곳은 전체의 20%도 안 된다. 둘째, 장애 발생 시 대응 시간을 계약서에 명시하는가. ’24시간 내 대응’이라는 문구만 있고 구체적인 SLA(서비스 수준 협약)가 없으면 새벽에 서버가 죽어도 다음 날 오후에나 연락이 온다.

셋째, 개발 완료 후 소스 코드와 데이터베이스 접근 권한을 온전히 넘겨주는가. 이걸 거부하거나 추가 비용을 요구하는 개발사는 절대 계약하지 마라. 한 고객은 이 조항 때문에 홈페이지제작 2년간 개발사에 발목이 잡혀 기능 하나 추가하는 데 3개월을 기다렸다. 계약서에 ‘소스 코드 및 데이터 소유권은 발주처에 있다’는 문장을 반드시 넣어야 한다.

오늘 당장 개발사에 보낼 이메일 한 통

플랫폼 제작을 시작하기로 마음먹었다면, 개발사와 두 번째 미팅을 잡기 전에 이 세 가지를 요구하라. 첫째, 3년 총소유비용(TCO) 견적서. 서버, 유지보수, 추가 개발 예상 비용을 연도별로 나눠서 받아라. 둘째, 데이터베이스 설계 초안. 테이블 목록과 관계도만 봐도 이 개발사가 플랫폼을 구조적으로 이해하는지 알 수 있다. 셋째, 유지보수 계약서 샘플. 장애 대응 시간, 월 유지보수 비용, 추가 개발 단가가 명시되어 있는지 확인하라.

이 세 가지를 요구하는 순간 절반의 개발사는 답변을 못 하거나 회피한다. 그런 곳은 처음부터 걸러지는 게 맞다. 나머지 절반 중에서도 TCO를 구체적인 숫자로 제시하는 곳은 10곳 중 2곳도 안 된다. 그 2곳이 진짜 플랫폼 제작을 해본 팀이다.

오늘 오후, 지금 미팅 중인 개발사에 이렇게 이메일을 보내라. “3년 TCO 견적서와 데이터베이스 설계 초안, 유지보수 계약서 샘플을 다음 미팅 전까지 받을 수 있을까요?” 이 한 통의 이메일이 1년 뒤 1억 원을 아껴줄 수 있다. 플랫폼 제작은 코딩이 아니라 의사결정의 연속이다. 그 첫 번째 결정을 오늘 내려라.

자주 묻는 질문

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

기본 기능만 갖춘 플랫폼은 3,000만 원에서 8,000만 원 사이에서 시작합니다. 하지만 결제, 정산, 알림, 관리자 대시보드까지 포함하면 1억 원을 넘기는 일이 흔합니다. 중요한 건 초기 견적이 아니라 3년 TCO입니다. 서버와 유지보수, 추가 개발을 합치면 초기 비용의 2~3배가 될 수 있습니다.

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

간단한 MVP는 23개월, 결제와 정산이 포함된 중급 플랫폼은 58개월, 대규모 트래픽을 감당하는 플랫폼은 1년 이상 걸립니다. 개발 기간보다 중요한 것은 요구사항 정의와 화면 설계에 쓰는 시간입니다. 이 단계를 건너뛰면 개발 중간에 방향을 바꾸느라 2배 이상 지연됩니다.

노코드로 플랫폼 제작해도 괜찮을까요?

시장 검증이 목적이라면 노코드로 시작해도 됩니다. 하지만 하루 거래 100건을 넘거나 수수료가 매출의 5%를 넘으면 자체 개발로 전환을 고려해야 합니다. 노코드에서 쌓은 데이터를 옮기는 데만 1~2개월이 걸릴 수 있으니 처음부터 이전 계획을 세우세요.

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

초기 자금은 있지만 개발 인력이 없다면 외주가 낫습니다. 반대로 장기적으로 플랫폼을 키울 계획이고 최소 2명 이상의 개발자를 채용할 수 있다면 직접 개발이 유리합니다. 외주는 속도가 빠르지만 유지보수 비용이 계속 발생하고, 직접 개발은 초기 속도가 느리지만 통제력이 높습니다.

개발사와 계약할 때 꼭 확인해야 할 조항은 무엇인가요?

소스 코드와 데이터베이스 소유권이 발주처에 있다는 조항, 장애 대응 시간을 명시한 SLA, 추가 개발 단가를 미리 정한 유지보수 계약서입니다. 이 세 가지가 없으면 나중에 기능 하나 추가하는 데도 수개월과 예상치 못한 비용이 듭니다. 계약서에 명시되지 않은 구두 약속은 효력이 없다고 보면 됩니다.