첫 미팅에서 기능 목록을 꺼내는 순간 벌어지는 일
지난해 말, 서울 강남에서 커머스 플랫폼을 준비하던 대표님을 만났습니다. 첫 미팅 자리에 A4 용지 세 장에 빼곡히 적힌 기능 목록을 들고 오셨습니다. 회원가입, 상품 등록, 결제 연동, 리뷰, 쿠폰, 정산, 알림톡까지 87개 항목이었습니다. 저는 그 목록을 잠깐 훑어보고 첫 질문을 던졌습니다. “이 기능 중에 첫 달에 꼭 필요한 게 몇 개입니까?” 대표님은 한참을 고민하다가 “다 필요한데요”라고 답하셨습니다. 그 순간 저는 이 프로젝트가 최소 6개월은 걸리겠구나 싶었습니다. 실제로 그 플랫폼은 8개월째 개발 중이고, 추가 비용만 4천만 원이 넘게 나갔습니다.
기능 목록은 실행의 도구이지 기획의 출발점이 아닙니다. 플랫폼 제작 현장에서 10년 넘게 겪어보면, 첫 미팅에서 기능 개수부터 세는 팀은 예외 없이 일정과 예산에서 무너집니다. 반대로 첫 미팅에서 “누가, 왜, 얼마를 쓰고 이 플랫폼을 떠나는가”를 먼저 묻는 팀은 기능이 절반으로 줄어듭니다. 기능을 줄이는 게 목적이 아니라, 진짜 필요한 것만 남기는 겁니다.
제가 상담했던 한 교육 플랫폼 스타트업은 첫 미팅에서 기능 목록 대신 사용자 시나리오 세 장을 가져왔습니다. “수강생이 결제 후 첫 강의를 듣기까지 3분 안에 끝나야 한다”는 문장 하나가 기능 12개를 대체했습니다. 결과적으로 초기 개발 범위는 28개 기능으로 정리됐고, 11주 만에 베타 오픈을 했습니다. 같은 예산으로 두 배 빠르게 나간 셈입니다.
견적서에 드러나지 않는 숨은 비용 구조
플랫폼 제작 견적을 받아보면 보통 3천만 원에서 1억 원 사이에서 형성됩니다. 같은 기능 목록을 줬는데 왜 이렇게 차이가 날까요? 이유는 크게 세 가지입니다. 첫째, 인력 구성입니다. 3천만 원 견적은 보통 프론트엔드 1명, 백엔드 1명, 디자이너 1명이 3개월간 투입되는 구조입니다. 1억 원 견적은 여기에 기획자, QA, DevOps, PM이 추가되어 5~6개월간 투입됩니다.
둘째, 기술 부채를 누가 감당하느냐입니다. 저렴한 견적은 대개 검증되지 않은 오픈소스 조합이나 외주 개발자를 단기 계약으로 씁니다. 초기에는 문제없어 보이지만, 트래픽이 몰리거나 기능을 추가할 때 구조 자체를 뜯어고쳐야 하는 상황이 옵니다. 제가 봐온 사례 중에는 3천만 원에 만든 쇼핑몰이 1년 만에 서버 비용과 유지보수 비용으로 7천만 원을 추가로 쓴 경우도 있습니다.
셋째, 요구사항 변경 비용입니다. 계약서에 “추가 기능은 별도 협의”라고 적혀 있으면, 그 순간부터 모든 변경이 유료입니다. 기능 하나 추가에 200만 원, 화면 하나 수정에 50만 원씩 청구되는 구조를 모르고 계약했다가 예산이 두 배로 늘어난 대표님들을 수도 없이 봤습니다.
정리하면, 견적서의 숫자는 시작점일 뿐입니다. 진짜 비용은 계약 이후에 발생합니다. 그래서 저는 견적을 비교할 때 총액보다 “이 금액에 무엇이 포함되고 무엇이 제외되는지”를 먼저 확인하라고 조언합니다.
기술 스택 선택이 3년 뒤 유지보수 비용을 결정한다
플랫폼 제작에서 기술 스택은 생각보다 훨씬 중요한 결정입니다. 그런데 대부분의 대표님들은 이 부분을 개발팀에 전적으로 맡깁니다. “개발자가 알아서 하겠지”라고 생각하지만, 그 선택이 3년 뒤 유지보수 비용과 인력 채용 난이도를 좌우합니다.
예를 들어, 국내에서 흔히 쓰이는 Java Spring 기반 플랫폼은 개발자를 구하기 쉽고 레퍼런스도 많습니다. 반면에 최신 JavaScript 프레임워크 조합은 초기 개발 속도는 빠르지만, 2~3년 뒤 유지보수할 개발자를 찾기 어려워지는 경우가 많습니다. 실제로 제가 컨설팅한 한 핀테크 스타트업은 2021년에 당시 유행하던 프레임워크로 플랫폼을 만들었다가, 2023년에 개발자가 퇴사한 후 6개월 동안 후임자를 구하지 못해 서비스 업데이트를 전혀 못 했습니다.
데이터베이스 선택도 마찬가지입니다. MySQL과 PostgreSQL은 안정적이고 인력 풀이 넓습니다. 반면에 MongoDB나 Firebase 같은 NoSQL 계열은 초기에는 편하지만, 트랜잭션이 복잡해지는 순간 설계를 다시 해야 하는 경우가 많습니다. 특히 결제나 정산 기능이 들어가는 플랫폼이라면 관계형 데이터베이스가 거의 필수입니다.
제 판단은 이렇습니다. 기술 스택은 “가장 멋진 것”이 아니라 “3년 뒤에도 나를 도와줄 사람이 있는 것”으로 골라야 합니다. 개발팀이 특정 기술을 강하게 권한다면, 그 이유를 문서로 설명하게 하세요. 설명하지 못하면 그건 취향입니다.
MVP 범위를 잘못 잡으면 6개월이 1년이 된다
MVP(최소 기능 제품)라는 말은 많이들 하지만 https://webpreme.com , 실제로 제대로 잡는 팀은 드뭅니다. 대표님들이 흔히 하는 착각은 “MVP는 기능을 조금 줄인 것”이라고 생각하는 겁니다. 아닙니다. MVP는 “핵심 가설을 검증할 수 있는 최소 단위”입니다.
예를 들어, 중고 거래 플랫폼을 만든다고 가정해봅시다. 회원가입, 상품 등록, 검색, 채팅, 결제, 리뷰, 신고 기능이 필요하다고들 말합니다. 하지만 https://www.nytimes.com/search?dropmab=true&query=https://webpreme.com 첫 번째 가설이 “사람들이 우리 플랫폼에 물건을 올릴 것인가”라면, 필요한 건 상품 등록과 검색뿐입니다. 채팅도 결제도 리뷰도 없어도 됩니다. 거래는 당분간 외부 메신저와 계좌 이체로 처리하면 됩니다.
제가 함께 일했던 한 팀은 이 원칙을 철저히 지켰습니다. 첫 버전에는 기능이 9개밖에 없었습니다. 대신 출시까지 8주가 걸렸고, 3개월 동안 사용자 1,200명을 모았습니다. 그리고 그 데이터를 보고 두 번째 버전에 결제와 리뷰를 넣었습니다. 반면에 같은 시장에서 47개 기능을 넣고 7개월을 개발한 팀은 출시 직후 사용자 200명을 모으는 데 그쳤습니다. 기능이 많을수록 사용자는 오히려 길을 잃습니다.
MVP 범위를 잡는 실전 팁을 하나 드리면, “이 기능이 없으면 사용자가 우리 플랫폼을 떠나는가?”라고 자문해보세요. 대부분의 기능은 없어도 사용자는 남습니다. 그런 기능은 두 번째 버전으로 미루면 됩니다.
외주, 자체 개발, 노코드 사이에서 흔들릴 때 보는 기준
플랫폼 제작 방식을 고를 때 가장 많이 받는 질문이 “외주가 나은가요, 자체 개발이 나은가요?”입니다. 정답은 없지만, 판단 기준은 있습니다. 첫째, 플랫폼이 회사의 핵심 경쟁력인가입니다. 만약 플랫폼 자체가 제품이라면 자체 개발이 맞습니다. 반대로 플랫폼이 비즈니스를 돌리기 위한 도구에 불과하다면 외주가 효율적입니다.
둘째, 내부에 기술을 이해하는 사람이 있는가입니다. 외주를 주더라도 요구사항을 정리하고 결과물을 검수할 사람이 필요합니다. 이 역할을 할 사람이 없으면 외주는 거의 실패합니다. 제가 본 성공적인 외주 프로젝트는 대표님이나 기획자가 매주 개발팀과 2시간씩 스프린트 리뷰를 했습니다. 반대로 실패한 프로젝트는 3개월 동안 연락이 없다가 결과물을 받고 충격을 받았습니다.
셋째, 시간과 예산입니다. 노코드 도구는 빠르고 저렴합니다. 2주면 프로토타입이 나옵니다. 하지만 트랜잭션이 복잡해지거나 사용자가 늘어나면 한계에 부딪힙니다. 노코드로 시작해서 검증한 뒤, 유료 사용자가 1,000명을 넘어가면 그때 커스텀 개발로 전환하는 전략이 현실적입니다. 실제로 한 고객은 노코드로 3개월 만에 월 매출 800만 원을 만들고, 그다음에 1억 원을 투자해 자체 플랫폼으로 전환했습니다.
제 의견은 이렇습니다. 초기에는 노코드나 외주로 빠르게 시장 반응을 확인하고, 제품-시장 적합성이 확인된 후에 자체 개발로 가는 게 가장 안전합니다. 처음부터 1억 원을 들여 완벽한 플랫폼을 만드는 건 도박에 가깝습니다.
내일 아침 미팅 전에 준비해야 할 세 가지 질문
플랫폼 제작을 시작하기 전에, 개발팀이나 외주 업체와 미팅을 잡았다면 다음 세 가지 질문을 반드시 준비하세요. 첫째, “이 기능이 없으면 사용자가 떠나는가?”입니다. 이 질문에 명확히 답하지 못하는 기능은 첫 버전에서 빼세요. 둘째, “3개월 뒤에 이 플랫폼을 유지보수할 사람은 누구인가?”입니다. 외주 업체가 유지보수까지 맡는지, 아니면 인수인계를 받을 내부 인력이 있는지 확인해야 합니다. 셋째, “추가 비용이 발생하는 조건은 무엇인가?”입니다. 계약서에 명시된 변경 비용 기준을 미리 확인하세요.
이 세 가지 질문에 대한 답을 문서로 받아두면, 나중에 분쟁이 생겼을 때도 기준이 됩니다. 그리고 가능하다면 개발팀에 “우리 플랫폼의 첫 사용자 100명을 어떻게 모을 계획인지”도 물어보세요. 이 질문에 답하지 못하는 팀은 기술만 알고 비즈니스를 모르는 팀입니다.
마지막으로, 오늘 바로 할 수 있는 일이 하나 있습니다. 지금 가지고 있는 기능 목록을 펼쳐놓고 각 기능 옆에 “이 기능이 없으면 사용자가 떠나는가?”라고 적어보세요. ‘예’라고 답한 기능이 10개가 넘는다면, 그중에서도 가장 핵심적인 5개만 남기고 나머지는 다음 버전으로 미루는 겁니다. 그 5개로 8주 안에 첫 버전을 내놓는 겁니다. 완벽한 플랫폼은 없습니다. 시장에 나와서 배우는 수밖에 없습니다.
자주 묻는 질문
플랫폼 제작 비용은 보통 얼마인가요?
국내 기준으로 간단한 MVP는 2천만4천만 원, 중간 규모는 5천만8천만 원, 복잡한 커머스나 핀테크는 1억 원 이상이 일반적입니다. 비용은 기능 개수보다 사용자 수, 트랜잭션 복잡도, 연동해야 할 외부 시스템 수에 따라 크게 달라집니다.
외주 개발과 자체 개발 중 어떤 게 나은가요?
플랫폼이 회사의 핵심 제품이면 자체 개발, 단순 운영 도구라면 외주가 효율적입니다. 다만 외주를 선택하더라도 요구사항을 정리하고 결과물을 검수할 내부 인력이 반드시 필요합니다. 이 역할이 없으면 외주 프로젝트는 실패할 확률이 높습니다.
노코드 툴로 플랫폼을 만들어도 괜찮을까요?
초기 검증 단계에서는 노코드가 매우 효과적입니다. 2주 내에 프로토타입을 만들 수 있고 비용도 수백만 원 수준입니다. 하지만 사용자가 1,000명을 넘거나 결제·정산 기능이 복잡해지면 한계에 부딪히므로, 그때 커스텀 개발로 전환하는 것을 권합니다.
플랫폼 제작 기간은 얼마나 걸리나요?
기능 10개 내외의 MVP는 812주, 중간 규모는 46개월, 복잡한 플랫폼은 6~12개월이 걸립니다. 기간을 단축하려면 기능을 줄이는 것이 가장 확실한 방법입니다. 기능을 20% 줄이면 기간은 30% 이상 단축되는 경우가 많습니다.
개발 중에 기능을 추가하면 비용이 얼마나 더 드나요?
계약서에 따라 다르지만, 일반적으로 화면 하나 추가에 50만150만 원, 기능 하나 추가에 200만500만 원이 청구됩니다. 초기 계약 시 변경 비용 기준을 명확히 문서로 남겨두지 않으면 예산이 두 배로 늘어날 수 있습니다.
플랫폼 제작 후 유지보수는 어떻게 해야 하나요?
외주 업체와 월 유지보수 계약을 맺는 경우 보통 월 100만300만 원이 듭니다. 내부 인력을 두는 경우 개발자 1명당 연봉 6천만8천만 원이 필요합니다. 초기에는 외주 유지보수를 받으면서 내부 인력을 천천히 채우는 것이 현실적입니다.