첫 미팅에서 대표가 던진 한마디
작년 봄, 서울 성수동의 한 회의실. 예비 창업자 김 대표가 노트북 화면을 돌리며 말했다. “이거 플랫폼 제작하면 3천만 원이면 되죠?” 화면에는 프리랜서 매칭 서비스의 와이어프레임이 떠 있었다. 나는 10년 넘게 이 바닥에서 일했지만, 그 순간에도 숨이 턱 막혔다. 3천만 원. 그 돈으로는 결제 연동과 본인 인증, 알림 시스템까지 포함된 양면 시장 플랫폼을 만드는 게 사실상 불가능하다. 하지만 https://search.daum.net/search?w=tot&q=https://webpreme.com 그의 눈에는 “개발자만 구하면 다 되는 것”으로 비쳤다.
그날 나는 그에게 세 가지 질문을 던졌다. 첫째, 공급자와 수요자 중 누구를 먼저 모을 건가. 둘째, 첫 거래가 성사되는 순간에 돈은 누가 어떻게 정산하나. 셋째, 만든 뒤 유지보수에 매달 얼마를 쓸 수 있나. 이 세 질문에 바로 답하지 못하면 플랫폼 제작은 시작하지 않는 게 낫다고 나는 믿는다. 실제로 이 질문에 막히는 대표가 열 명 중 여덟 명이다.
결국 김 대표는 3천만 원 대신 1억 2천만 원 예산을 승인했고, 5개월 뒤 베타 버전을 출시했다. 3개월 만에 가입자 1만 명을 넘겼다. 이 글은 그 과정에서 내가 현장에서 보고, 고치고, 때로는 실패한 기록이다. 화려한 성공담이 아니라, 돈과 시간이 어디로 새는지를 보여주는 영수증에 가깝다.
기획서 50장보다 중요한 건 ‘거래 흐름도’ 한 장
플랫폼 제작을 의뢰하는 팀들이 가장 흔히 하는 착각은 기능 목록을 길게 쓰면 좋은 기획이 된다는 것이다. 채팅, 리뷰, 지도, 푸시 알림, 관리자 페이지까지 나열한 50장짜리 기획서를 들고 오는 팀이 많다. 그런데 개발팀이 실제로 먼저 보는 건 그게 아니다. “A가 B에게 돈을 주고 C를 받는 흐름”을 그린 한 장짜리 도식이다.
김 대표 팀은 첫 미팅 후 일주일 동안 이 흐름도를 다시 그렸다. 프리랜서가 견적을 보내고, 고객이 결제하고, 작업이 끝나면 정산되는 과정을 화살표로 이었다. 이 과정에서 놓친 구멍이 무려 7개나 나왔다. 예를 들어 고객이 결제만 하고 프리랜서가 작업을 시작하지 않았을 때 환불은 누가 승인하는가. 프리랜서가 중간에 잠적하면 남은 대금은 어떻게 처리하는가. 분쟁이 생기면 플랫폼이 중재에 나서는가, 아니면 당사자끼리 해결하게 하는가.
이 7개 구멍을 메우는 데만 2주가 걸렸다. 대신 이 작업을 건너뛴 팀들은 개발 막바지에 이 기능을 추가하느라 일정이 두 달씩 밀린다. 내가 본 바로는, 플랫폼 제작에서 기획 단계에 쓴 시간은 출시 후 유지보수 비용을 그대로 깎아준다. 흐름도 한 장에 2주를 쓰는 건 결코 낭비가 아니다.
기술 스택 선택, 유행보다 ‘사람 구하기’가 먼저다
기술 스택을 정할 때 가장 많이 받는 질문은 “요즘 뭐가 제일 좋아요?”다. 하지만 내 대답은 늘 같다. “3년 뒤에도 그 기술을 다룰 개발자를 구할 수 있는 게 최우선입니다.”
김 대표 팀은 처음에 최신 프레임워크 두 개를 섞어 쓰려 했다. 벤치마크 수치가 좋다는 이유였다. 나는 반대했다. 국내에서 그 조합을 실무에 쓸 수 있는 개발자는 당시 200명 남짓이었고, 몸값이 연봉 1억을 넘었다. 결국 우리는 조금 덜 세련됐지만 개발자 풀이 10배 이상 넓은 조합으로 갔다. 대신 서버 비용이 월 40만 원 더 나왔다. 인건비 한 명을 6개월만 붙잡아도 3천만 원이 넘는다. 월 40만 원은 아무것도 아니다.
스택을 정할 때 내가 보는 기준은 세 가지다. 첫째, 채용 공고를 냈을 때 일주일 안에 서류 20장이 들어오는가. 둘째, 그 기술로 만든 국내 서비스가 최소 5개 이상 돌아가고 있는가. 셋째, 문제가 생겼을 때 한국어로 된 해결 사례를 검색할 수 있는가. 이 세 가지를 만족하지 못하면 아무리 성능이 좋아도 나는 말린다. 플랫폼 제작은 기술 자랑 대회가 아니라 운영 싸움이다.
외주 개발, 견적서에서 반드시 봐야 할 세 줄
플랫폼 제작 견적서를 받으면 사람들은 총액부터 본다. 1억이면 비싸다, 6천이면 싸다. 그런데 정작 중요한 건 총액이 아니라 그 아래 숨어 있는 세 줄이다.
첫째, 유지보수 조건. “출시 후 3개월 무상 하자 보수”라고만 적혀 있으면 그 뒤는 유료다. 월 유지보수 계약이 없으면 장애가 터질 때마다 시간당 15만 원씩 나간다. 김 대표 팀은 월 250만 원짜리 유지보수 계약을 처음부터 넣었다. 1년이면 3천만 원이다. 이걸 빼먹고 총액만 낮춘 팀은 6개월 뒤에 더 큰 청구서를 받는다.
둘째, 소스 코드 소유권. “완성 후 소스 제공”이라는 문구가 있어도, 실제로는 빌드된 파일만 주는 경우가 많다. 나중에 다른 개발팀으로 갈아타려면 원본 소스와 데이터베이스 구조가 반드시 필요하다. 계약서에 “소스 코드 및 데이터베이스 스키마 일체”라고 명시해야 한다.
셋째, 인수인계 범위. 개발자가 퇴사하면 그 지식도 같이 사라진다. 최소 2주간의 문서화와 화상 인수인계를 조건에 넣어야 한다. 이 세 줄이 빠진 견적서는 총액이 2천만 원 싸도 결국 더 비싸다.
출시 후 3개월, 돈이 새는 진짜 이유
플랫폼을 출시하면 개발비보다 운영비가 더 무섭다는 걸 몸으로 알게 된다. 김 대표 팀의 첫 달 서버 비용은 80만 원이었다. 둘째 달에는 210만 원, 셋째 달에는 470만 원으로 뛰었다. 가입자가 늘면 비용도 늘어나는 건 당연한데, 문제는 예상보다 3배 빠르게 늘어난다는 점이다.
원인은 대부분 이미지와 알림이다. 프로필 사진 한 장을 원본 그대로 올리면 트래픽이 폭증한다. 이미지 리사이징을 안 해서 첫 달에만 60만 원을 더 쓴 팀도 봤다. 푸시 알림도 마찬가지다. 모든 사용자에게 매일 알림을 보내면 발송 비용과 서버 부하가 함께 오른다. 우리는 알림을 주 2회로 제한하고, 이미지는 업로드 시점에 세 가지 크기로 자동 변환하도록 고쳤다. 그 뒤 서버 비용 증가율이 절반으로 줄었다.
또 하나, 고객센터 인력이다. 플랫폼이 커지면 문의가 하루 50건을 넘는다. 한 명이 하루 30건을 처리한다면 두 명이 필요하고, 월 500만 원이 나간다. 이 비용을 빼고 수익을 계산한 팀은 대부분 6개월 안에 적자에 허덕인다. 플랫폼 제작 예산을 짤 때 개발비 대비 운영비를 최소 1대 1로 잡아야 하는 이유다.
성공한 플랫폼과 그렇지 않은 플랫폼의 결정적 차이
내가 10년 동안 지켜본 플랫폼 중 살아남은 것과 그렇지 않은 것에는 공통된 차이가 있다. 기능 수가 아니다. 마케팅 예산도 아니다. 바로 ‘첫 거래가 일어나는 속도’다.
살아남은 플랫폼은 출시 후 첫 30일 안에 실제 거래를 만들어낸다. 김 대표 팀도 그랬다. 출시 첫날부터 운영팀이 직접 공급자 10명과 수요자 10명을 연결해줬다. 수작업이었다. 전화를 걸고, 문자를 보내고, 때로는 직접 만나서 거래를 성사시켰다. 이 과정에서 결제 실패 3건, 환불 요청 1건, 분쟁 1건을 겪었다. 이 경험이 없으면 플랫폼은 그냥 껍데기다.
반대로 실패한 플랫폼은 기능만 완벽하게 만들고 사용자를 기다린다. “좋은 서비스를 만들면 사람들이 알아서 올 것”이라고 믿는다. 하지만 https://webpreme.com 양면 시장에서 공급자와 수요자는 서로를 기다리다가 둘 다 떠난다. 첫 거래를 인위적으로라도 만들어내는 팀만이 다음 단계로 간다.
또 하나, 데이터를 보는 습관이다. 살아남은 팀은 매일 아침 재방문율과 거래 전환율을 확인한다. 이 두 숫자가 떨어지면 그날 바로 원인을 찾는다. 반면 그렇지 않은 팀은 대시보드만 만들어두고 일주일에 한 번 본다. 플랫폼 제작의 성패는 출시 후 90일 동안 얼마나 집요하게 숫자를 쫓아가느냐에 달려 있다.
가장 흔한 실수, ‘완성’이라는 단어를 믿는 것
내가 본 가장 흔하고 치명적인 실수는 플랫폼 제작을 ‘완성’이라는 개념으로 바라보는 것이다. “다 만들면 끝”이라고 생각하는 순간, 그 플랫폼은 죽기 시작한다.
실제로 한 팀은 8개월 동안 기능 70개를 넣어 출시했다. 그런데 출시 후 3개월 동안 사용자가 실제로 쓴 기능은 12개뿐이었다. 나머지 58개는 유지보수 대상이 됐다. 버그가 생기면 고쳐야 하고, 서버 자원을 잡아먹고, 새로운 기능을 넣을 때마다 충돌한다. 결국 그 팀은 1년 만에 서비스를 접었다. 개발비 2억 3천만 원이 사라졌다.
플랫폼은 건물이 아니라 텃밭이다. 씨앗을 심고, 물을 주고, 잡초를 뽑는 일이 매일 이어진다. 출시는 끝이 아니라 시작이다. 따라서 예산을 짤 때 전체의 60%만 초기 개발에 쓰고, 40%는 출시 후 1년간의 개선과 운영에 남겨둬야 한다. 이 비율을 지키지 않는 팀은 대부분 첫 겨울을 넘기지 못한다. 지금 플랫폼 제작을 고민하고 있다면, “언제 끝나지?”가 아니라 “출시 후 1년 동안 매달 얼마를 쓸 수 있지?”를 먼저 계산하길 바란다.
자주 묻는 질문
플랫폼 제작 비용은 보통 얼마인가요?
간단한 매칭 기능만 있는 플랫폼은 3천만 원부터 시작하지만, 결제·정산·본인 인증·알림·관리자 페이지까지 포함하면 1억 원 안팎이 현실적입니다. 여기에 출시 후 1년간 유지보수 비용으로 월 200~300만 원이 추가로 듭니다. 총 예산을 개발비와 운영비로 나눠서 6대4 정도로 잡는 게 안전합니다.
개발자 없이 플랫폼 제작이 가능한가요?
노코드 툴로 프로토타입 수준은 만들 수 있지만, 실제 결제와 정산이 들어가는 상용 플랫폼은 한계가 명확합니다. 초기 검증용으로 노코드로 2~3주 테스트하고, 반응이 확인되면 외주나 내부 개발로 전환하는 방식을 권합니다. 처음부터 노코드로 완성하려다가 6개월을 날린 팀을 여러 번 봤습니다.
외주 개발과 내부 개발 중 어떤 게 나은가요?
초기 자금이 5천만 원 이하라면 외주가 현실적입니다. 다만 외주는 요구사항을 문서로 정확히 전달해야 하고, 유지보수 계약을 반드시 포함해야 합니다. 반대로 자금이 2억 이상이고 서비스를 3년 이상 운영할 계획이라면 내부 개발팀을 꾸리는 게 장기적으로 30% 이상 비용을 아낍니다.
플랫폼 제작 기간은 얼마나 걸리나요?
기획 12개월, 디자인 1개월, 개발 34개월, 테스트 1개월을 합쳐 최소 6개월입니다. 기능을 30% 줄이면 4개월까지 단축할 수 있지만, 결제와 본인 인증 같은 핵심 모듈은 줄이면 안 됩니다. 일정을 절반으로 줄이겠다는 제안은 대부분 품질 저하로 이어집니다.
플랫폼 제작 후 유지보수는 누가 하나요?
외주 개발사와 월 단위 유지보수 계약을 맺는 게 일반적이며, 월 150300만 원 수준입니다. 계약이 없으면 장애 발생 시 시간당 1020만 원을 지불해야 하고, 긴급 대응은 거부될 수 있습니다. 소스 코드와 데이터베이스 구조를 반드시 인수받아야 나중에 다른 업체로 교체할 수 있습니다.
플랫폼 제작 시 가장 중요한 법적 검토 사항은 무엇인가요?
개인정보 처리방침, 전자상거래법상 통신판매업 신고, 결제 대행사와의 정산 조건, 플랫폼 이용약관이 핵심입니다. 특히 공급자와 수요자 간 분쟁 발생 시 플랫폼의 책임 범위를 약관에 명확히 해야 합니다. 이 네 가지를 빼먹으면 출시 후 과태료나 소송으로 초기 투자금보다 큰 손실을 볼 수 있습니다.