첫 미팅에서 이미 어긋나는 이유
플랫폼 제작을 결심하고 업체를 만나러 간 자리. 대표님은 “우리 서비스에 맞는 플랫폼 하나 만들어 주세요”라고 말합니다. 개발사는 고개를 끄덕이며 “네, 가능합니다”라고 답하죠. 그런데 이 대화가 끝나고 돌아온 견적서를 보면, 양쪽이 서로 전혀 다른 그림을 그리고 있었다는 걸 알게 됩니다.
제가 상담했던 한 스타트업 대표는 첫 미팅에서 ‘간단한 중고거래 플랫폼’을 요청했습니다. 개발사는 3천만 원 견적을 냈고, 대표는 계약금을 걸었습니다. 6개월 뒤 결과물은 회원가입과 게시판 기능만 있는 수준이었습니다. 대표가 원한 건 실시간 채팅, 위치 기반 검색, 안전결제까지 포함된 서비스였지만, 그 어떤 문서에도 그런 요구사항이 적혀 있지 않았습니다.
문제는 개발사의 능력이 아니었습니다. 첫 미팅에서 ‘중고거래 플랫폼’이라는 단어 하나로 서로 다른 100가지 기능을 상상한 겁니다. 플랫폼 제작에서 가장 흔한 실패는 기술 부족이 아니라 언어의 불일치에서 시작됩니다.
그래서 저는 첫 미팅 전에 반드시 ‘기능 목록’을 종이에 적어 가라고 조언합니다. 거창한 기획서가 아니어도 됩니다. 사용자가 어떤 버튼을 누르면 무슨 일이 일어나는지, 관리자는 무엇을 할 수 있어야 하는지, 결제는 어떻게 이루어지는지. 이 세 가지만 적어도 견적의 편차는 절반으로 줄어듭니다.
견적서에 숨은 숫자 읽는 법
플랫폼 제작 견적서를 받으면 대부분 총액부터 봅니다. 3천만 원, 5천만 원, 1억. 그런데 그 숫자 뒤에 숨은 항목을 뜯어보면 완전히 다른 이야기가 나옵니다.
예를 들어 A사는 3천만 원에 ‘관리자 페이지’를 포함시켰지만, B사는 같은 항목을 1천만 원 추가 옵션으로 뺐습니다. C사는 ‘유지보수 1년 무상’이라고 썼지만, 그 안에 서버 비용과 기능 추가는 빠져 있습니다. 총액만 비교하면 A사가 가장 저렴해 보이지만, 1년 뒤 실제 지출은 C사가 두 배가 될 수도 있습니다.
제가 본 가장 전형적인 사례는 ‘동시 접속자 수’를 명시하지 않은 계약입니다. 한 고객은 3천만 원에 플랫폼을 만들었는데, 오픈 첫날 접속자가 500명을 넘자 서버가 다운됐습니다. 급하게 서버를 증설하느라 800만 원을 추가로 썼고, 트래픽 분산 설계를 다시 하느라 2개월을 더 기다려야 했습니다.
견적서에서 꼭 확인해야 할 숫자는 네 가지입니다. 동시 접속자 수, 데이터 저장 용량, API 호출 제한, 그리고 관리자 계정 수. 이 네 가지가 명시되지 않았다면 그 견적서는 절반만 쓰인 것입니다. 개발사가 이 항목을 빼먹은 게 아니라, 대부분의 고객이 묻지 않기 때문에 굳이 적지 않는 관행이 자리 잡았습니다.
저는 견적서를 받으면 ‘이 금액에 포함되지 않은 것이 무엇인가’를 먼저 물으라고 합니다. 포함된 기능보다 제외된 기능이 앞으로의 비용을 결정합니다.
노코드와 자체 개발, 어디서 갈라지나
요즘은 노코드 툴로도 플랫폼 제작이 가능합니다. 실제로 제가 컨설팅한 한 교육 스타트업은 노코드로 2주 만에 MVP를 만들었습니다. 비용은 300만 원도 안 들었죠. 하지만 사용자가 3천 명을 넘어서자 문제가 터졌습니다. 결제 모듈 연동이 안 되고, 데이터 분석이 불가능하고, 무엇보다 속도가 눈에 띄게 느려졌습니다.
노코드가 답인 경우는 명확합니다. 시장 반응을 빠르게 확인하려는 초기 검증 단계, 기능이 단순하고 사용자 수가 1만 명 이하인 서비스, 내부 관리용 도구. 이 세 가지에 해당한다면 노코드로 시작해도 충분합니다.
반대로 자체 개발로 가야 하는 기준도 있습니다. 결제·정산 로직이 복잡하거나, 실시간 데이터 처리가 필요하거나, 외부 서비스와의 연동이 5개 이상이거나, 사용자 데이터를 직접 통제해야 하는 경우입니다. 이런 조건 중 두 개 이상 해당되면 노코드는 오히려 독이 됩니다. 나중에 마이그레이션하는 비용이 처음부터 개발하는 비용보다 더 많이 들기 때문입니다.
중간 지점도 있습니다. 노코드로 프로토타입을 만들고, 검증이 끝난 뒤 핵심 기능만 자체 개발로 옮기는 방식입니다. 제가 본 가장 성공적인 플랫폼 쇼핑몰제작 제작 사례는 이 방식을 택한 팀이었습니다. 초기 6개월은 노코드로 버티면서 사용자 피드백을 모았고, 투자 유치 후 1억 2천만 원을 들여 자체 개발로 전환했습니다. 이때 이미 검증된 기능만 개발했기 때문에 https://en.search.wordpress.com/?src=organic&q=쇼핑몰제작 불필요한 기능에 돈을 쓰지 않았습니다.
개발 기간, 왜 항상 두 배로 늘어나는가
플랫폼 제작 계약서에 적힌 개발 기간은 대개 3개월에서 6개월입니다. 그런데 실제로 이 기간을 지키는 프로젝트는 10개 중 2개도 안 됩니다. 제가 관여한 프로젝트만 봐도 평균 지연 기간은 4.2개월이었습니다.
지연의 주범은 개발사가 아닙니다. 대부분 고객 쪽에서 발생합니다. 첫째, 기획 변경입니다. 개발이 30% 진행됐을 때 “이 기능 하나만 추가해 주세요”라는 요청이 들어옵니다. 그 ‘하나’가 다른 5개 기능을 건드려야 하는 경우가 태반입니다. 둘째, 의사결정 지연입니다. 디자인 시안 하나를 확정하는 데 2주가 걸리고, 그 사이 개발자는 다른 프로젝트로 이동합니다. 다시 돌아오면 컨텍스트를 복기하는 데만 3일이 필요합니다.
한 고객은 계약서에 ‘기능 추가 시 별도 협의’라는 문구를 넣었습니다. 개발사는 이 문구를 근거로 추가 기능마다 견적을 새로 냈고, 고객은 그때마다 “이건 원래 포함된 거 아니냐”며 다퉜습니다. 결국 소송 직전까지 갔고, 플랫폼은 1년째 베타 상태에 머물렀습니다.
지연을 줄이는 가장 현실적인 방법은 ‘기능 동결’입니다. 개발 착수 후에는 새로운 기능 요청을 모두 ‘2차 개발 목록’에 넣고, 1차 오픈 때는 계약서에 명시된 기능만 구현합니다. 이 규칙 하나로 평균 개발 기간이 30% 줄어드는 걸 여러 번 봤습니다. 물론 대표님 입장에서는 시장 반응이 두려워 기능을 자꾸 넣고 싶겠지만, 그 욕심이 일정을 갉아먹는다는 사실을 기억해야 합니다.
유지보수 계약, 여기서 흑자가 갈린다
플랫폼을 오픈했다고 끝이 아닙니다. 오히려 시작입니다. 그런데 많은 대표님이 유지보수 계약을 ‘형식적인 것’으로 여기다가 큰 비용을 치릅니다.
유지보수 계약에는 세 가지 유형이 있습니다. 첫째, 장애 대응만 포함하는 ‘기본형’. 월 50만100만 원 수준입니다. 둘째, 기능 개선과 콘텐츠 업데이트까지 포함하는 ‘표준형’. 월 150만300만 원입니다. 셋째, 전담 인력을 배치하는 ‘전담형’. 월 500만 원 이상입니다.
문제는 대부분의 계약서가 ‘기본형’인데, 고객은 ‘표준형’을 기대한다는 점입니다. 오픈 후 디자인을 조금 바꾸고 싶어도 추가 비용이 발생하고, 기능 하나를 수정하려면 견적서를 다시 받아야 합니다. 이걸 모르고 계약했다가 오픈 첫 달에 300만 원이 넘는 추가 청구서를 받는 경우를 숱하게 봤습니다.
제가 권하는 방식은 ‘초기 3개월은 표준형, 이후 트래픽에 따라 조정’입니다. 오픈 직후에는 예상치 못한 버그와 개선 요청이 쏟아지기 때문에 전담형에 가까운 지원이 필요합니다. 실제로 한 커머스 플랫폼은 오픈 첫 달에만 47건의 수정 요청이 들어왔습니다. 이걸 모두 별도 견적으로 처리했다면 1천만 원이 넘었을 겁니다.
유지보수는 비용이 아니라 보험입니다. 플랫폼 제작 예산의 1015%를 연간 유지보수 비용으로 미리 잡아두는 게 안전합니다. 1억 원짜리 플랫폼이라면 매년 1천만1천5백만 원을 각오해야 한다는 뜻입니다. 이 숫자를 모르고 계약하면, 나중에 유지보수비를 아끼려다 플랫폼 전체를 다시 만들어야 하는 상황이 옵니다.
업체를 고를 때 제가 마지막으로 보는 것
플랫폼 제작 업체를 고를 때 포트폴리오와 견적서만 보는 대표님이 많습니다. 물론 중요합니다. 하지만 제가 10년 넘게 현장에서 본 바로는, 성공적인 프로젝트와 그렇지 않은 프로젝트를 가르는 결정적 차이는 다른 곳에 있습니다.
첫째, 개발사가 ‘우리가 못 하는 것’을 먼저 말하는지 보십시오. 모든 걸 다 잘한다고 말하는 업체는 대개 모든 걸 적당히 합니다. “이 기능은 우리 전문 분야가 아니라서 파트너사를 통해 진행합니다”라고 솔직하게 말하는 업체가 오히려 신뢰할 만합니다.
둘째, 기획 단계에 얼마나 시간을 쓰는지 확인하십시오. 견적을 내기 전에 최소 3회 이상의 미팅을 요구하는 업체가 좋습니다. 첫 미팅에서 바로 견적서를 주는 곳은 요구사항을 제대로 파악하지 않았을 가능성이 큽니다. 실제로 제가 아는 한 개발사는 계약 전 ‘요구사항 정의서’를 무료로 작성해 줍니다. 이 과정에서만 2주가 걸리지만, 그 덕분에 개발 중 기획 변경이 거의 없습니다.
셋째, 유사 프로젝트를 ‘직접’ 해본 적이 있는지 물으십시오. 간접 경험과 직접 경험은 하늘과 땅 차이입니다. 예를 들어 결제 시스템을 연동해 본 적이 없는 업체는 예상치 못한 PG사 정책 변경에 속수무책입니다. 반대로 여러 번 해본 업체는 “이 PG사는 심사에 2주 걸리니 미리 신청하세요”라고 조언합니다.
마지막으로, 계약서에 ‘산출물 소유권’과 ‘소스코드 이관’ 조항을 반드시 넣으십시오. 이 조항이 없어서 나중에 다른 업체로 옮기지 못하는 경우를 정말 많이 봤습니다. 플랫폼 제작은 결혼이 아니라 동업입니다. 헤어질 때를 대비한 조항이 없으면, 헤어질 때 모든 걸 잃습니다.
자주 묻는 질문
플랫폼 제작 비용은 보통 얼마인가요?
간단한 MVP는 2천만4천만 원, 중간 규모는 5천만1억 원, 복잡한 기능이 포함된 플랫폼은 1억 5천만 원 이상입니다. 비용을 결정하는 핵심은 기능 개수보다 ‘동시 접속자 처리’와 ‘외부 연동 수’입니다. 같은 기능이라도 결제·정산·실시간 채팅이 들어가면 견적이 두 배로 뜁니다.
노코드로 플랫폼 제작해도 괜찮을까요?
초기 시장 검증이나 사용자 1만 명 이하의 단순 서비스라면 노코드로 충분합니다. 다만 결제 로직이 복잡하거나 데이터를 직접 통제해야 한다면 나중에 마이그레이션 비용이 더 많이 들 수 있습니다. 노코드로 시작하되, 핵심 기능은 자체 개발로 전환할 계획을 미리 세워두는 게 안전합니다.
플랫폼 제작 기간은 얼마나 걸리나요?
계약서에는 보통 3~6개월로 적지만, 실제로는 평균 4개월 이상 지연됩니다. 지연의 주된 원인은 개발사가 아니라 고객의 기획 변경과 의사결정 지연입니다. 개발 착수 후에는 새로운 기능 요청을 2차 개발로 미루는 ‘기능 동결’ 원칙을 지키면 일정을 30% 이상 단축할 수 있습니다.