첫 미팅에서 “이 정도면 되죠?”라고 말하는 순간 벌어지는 일
지난 10년 동안 플랫폼 제작 프로젝트를 수백 건 진행하면서, 첫 미팅에서 대표님들이 가장 많이 하는 말은 “이 정도면 되죠?”입니다. 이 한마디가 프로젝트의 운명을 결정짓는 경우를 수도 없이 봤습니다.
작년에 컨설팅한 A사는 첫 미팅에서 기능 목록을 대충 훑고 “3천만 원이면 충분하다”고 판단했습니다. 하지만 실제로는 결제 연동, 정산 시스템 https://search.daum.net/search?w=tot&q=홈페이지제작 , 관리자 권한 분리, 알림톡 발송, 통계 대시보드까지 필요했고, 최종 견적은 1억 2천만 원이 나왔습니다. 이미 3개월을 허비한 뒤였습니다.
왜 이런 일이 반복될까요? 대표님들은 플랫폼 제작을 ‘웹사이트 만들기’의 연장선으로 생각합니다. 하지만 플랫폼은 사용자, 데이터, 트랜잭션이 얽힌 하나의 생태계입니다. 단순한 화면 몇 개가 아니라, 비즈니스 로직이 코드로 구현된 결과물입니다.
첫 미팅에서 “이 정도면 되죠?”라고 말하기 전에, 먼저 스스로에게 물어야 합니다. 우리가 해결하려는 문제가 정확히 무엇인지, 그 문제를 해결하기 위해 어떤 데이터가 오가야 하는지. 이 질문에 답하지 못하면, 어떤 견적도 의미가 없습니다.
숫자 하나: 하루에 발생하는 트랜잭션 수
플랫폼 제작 견적을 가르는 첫 번째 숫자는 ‘하루 트랜잭션 수’입니다. 여기서 트랜잭션은 결제, 예약, 매칭, 메시지 전송 등 플랫폼 안에서 일어나는 모든 상호작용을 말합니다.
예를 들어 하루 100건의 예약이 발생하는 플랫폼과 10,000건이 발생하는 플랫폼은 완전히 다른 아키텍처가 필요합니다. 100건이면 단일 서버로 충분하지만, 10,000건이면 로드 밸런싱, 캐싱, 데이터베이스 샤딩까지 고려해야 합니다. 이 차이만으로 개발 비용이 3배에서 5배까지 벌어집니다.
제가 작년에 상담한 B사는 하루 500건 정도의 주문을 예상하고 플랫폼을 제작했습니다. 그런데 오픈 첫 달에 하루 5,000건이 몰리면서 서버가 다운됐습니다. 급하게 서버를 증설하고 코드를 수정하는 데만 2개월과 추가 비용 4천만 원이 들었습니다. 초기 설계 단계에서 트랜잭션 수를 과소평가한 대가였습니다.
대표님들이 자주 하는 착각은 “처음에는 작게 시작하고 나중에 키우면 된다”입니다. 물론 맞는 말입니다. 하지만 처음부터 확장 가능한 구조로 설계하지 않으면, 나중에 키우는 비용이 처음부터 제대로 만드는 비용보다 훨씬 큽니다. 플랫폼 제작에서 확장성은 선택이 아니라 필수입니다.
그렇다면 어떻게 예측해야 할까요? 보수적으로 잡으라고 말씀드립니다. 현재 예상하는 트랜잭션 수의 3배에서 5배를 기준으로 설계하세요. 그래야 최소 1~2년은 추가 비용 없이 버틸 수 있습니다.
숫자 둘: 관리자와 사용자의 권한 구조
두 번째 숫자는 ‘권한 구조의 복잡도’입니다. 플랫폼 제작에서 가장 과소평가되는 부분이 바로 권한 관리입니다. 단순히 관리자와 일반 사용자로 나뉘는 줄 알지만, 실제로는 그렇지 않습니다.
예를 들어 쇼핑몰 플랫폼을 만든다고 가정해봅시다. 최고 관리자, 운영 관리자, CS 담당자, 상품 등록 담당자, 정산 담당자 등 최소 5개 이상의 역할이 필요합니다. 각 역할마다 접근할 수 있는 메뉴와 데이터가 다릅니다. 이걸 제대로 구현하려면 역할 기반 접근 제어(RBAC) 시스템을 구축해야 하고, 이는 전체 개발 공수의 15~20%를 차지합니다.
작년에 C사는 권한 구조를 단순하게 설계했다가 오픈 후 큰 문제를 겪었습니다. CS 담당자에게 모든 회원 정보를 볼 수 있는 권한을 줬는데, 퇴사한 직원이 고객 데이터를 유출한 사건이 발생했습니다. 법적 분쟁까지 갔고, 플랫폼 신뢰도는 바닥으로 떨어졌습니다. 권한 설계를 소홀히 한 대가는 금전적 손실보다 훨씬 큽니다.
권한 구조를 설계할 때는 ‘최소 권한 원칙’을 지켜야 합니다. 각 역할이 업무를 수행하는 데 꼭 필요한 최소한의 권한만 부여하는 것입니다. 이 원칙을 처음부터 적용하면 개발 기간이 2~3주 늘어날 수 있지만, 나중에 발생할 수 있는 보안 사고와 법적 리스크를 생각하면 충분히 투자할 가치가 있습니다.
또 하나 중요한 것은 권한 변경 이력 관리입니다. 누가 언제 어떤 권한을 변경했는지 기록으로 남겨야 합니다. 이 기능 하나가 나중에 감사나 분쟁 상황에서 결정적인 증거가 됩니다. 플랫폼 홈페이지제작 제작 견적을 받을 때 이 부분이 포함되어 있는지 반드시 확인하세요.
숫자 셋: 데이터 보관과 백업 주기
세 번째 숫자는 ‘데이터 보관 기간과 백업 주기’입니다. 이 숫자를 간과하면 서비스 장애는 물론 법적 문제까지 생깁니다.
국내 전자상거래법에 따르면 계약 기록은 5년, 대금 결제 기록은 5년, 소비자 불만 처리 기록은 3년간 보관해야 합니다. 단순히 데이터를 저장하는 게 아니라, 필요할 때 즉시 꺼내볼 수 있어야 합니다. 이 요구사항을 충족하려면 데이터베이스 설계 단계부터 아카이빙 전략을 세워야 합니다.
D사는 이 부분을 놓쳐서 오픈 6개월 만에 데이터베이스가 한계에 도달했습니다. 로그와 거래 기록이 하루 10GB씩 쌓이는데, 아카이빙 없이 모두 메인 DB에 저장했기 때문입니다. 결국 DB를 분리하고 아카이빙 시스템을 구축하는 데 3개월과 8천만 원이 추가로 들었습니다.
백업 주기도 중요합니다. 하루에 한 번 백업하는 플랫폼과 실시간으로 백업하는 플랫폼은 장애 발생 시 복구 시간에서 엄청난 차이를 보입니다. 금융이나 예약 플랫폼이라면 실시간 백업이 필수입니다. 반면 콘텐츠 플랫폼이라면 하루 한 번 백업으로도 충분할 수 있습니다.
비용 효율을 따지려면 데이터의 성격을 먼저 분류하세요. 결제 데이터, 개인정보, 로그 데이터, 콘텐츠 데이터를 각각 나누고, 각각에 맞는 보관 기간과 백업 주기를 설정해야 합니다. 이 작업을 초기 설계에 포함하면 전체 개발 비용의 5~10% 정도가 추가되지만, 장애 복구 비용과 법적 리스크를 고려하면 반드시 필요한 투자입니다.
플랫폼 제작 견적서를 받을 때 ‘백업’이라는 단어가 한 줄로 처리되어 있다면, 그 견적서는 절반만 맞는 것입니다. 백업 정책, 복구 목표 시간(RTO), 복구 목표 시점(RPO)이 구체적으로 명시되어 있는지 확인하세요.
오늘 바로 할 수 있는 세 가지 행동
첫째, 오늘 당장 우리 플랫폼의 예상 트랜잭션 수를 숫자로 적어보세요. 하루, 한 달, 1년 단위로 말입니다. 그리고 그 숫자의 3배를 기준으로 개발사에 질문하세요. “이 트랜잭션을 처리할 수 있는 구조인가요?” 이 질문 하나가 수천만 원의 추가 비용을 막을 수 있습니다.
둘째, 관리자 권한 목록을 지금 당장 만들어보세요. 누가, 어떤 메뉴에, 어떤 데이터에 접근해야 하는지 표로 정리하세요. 이 표를 개발사에 건네주면 견적의 정확도가 훨씬 높아집니다. 권한 구조를 명확히 하지 않으면 나중에 반드시 문제가 생깁니다.
셋째, 데이터 보관 정책을 문서 한 장으로 요약하세요. 어떤 데이터를, 얼마 동안, 어디에 보관할 것인지 적어보세요. 그리고 개발사에 백업 주기와 복구 목표 시간을 반드시 질문하세요. 이 세 가지 질문에 명확히 답하는 개발사라면 신뢰할 수 있습니다.
이 세 가지를 준비하지 않고 첫 미팅에 가면, 대표님은 개발사의 말에 휘둘릴 수밖에 없습니다. 반대로 이 세 가지를 준비해 가면, 개발사는 대표님을 진지한 파트너로 대합니다. 플랫폼 제작의 성패는 첫 미팅 전에 이미 절반이 결정됩니다. 오늘 이 세 가지를 적어보는 것만으로도 수개월의 시행착오와 수천만 원의 비용을 절약할 수 있습니다.
자주 묻는 질문
플랫폼 제작 비용은 보통 얼마인가요?
국내 기준으로 간단한 플랫폼은 2천만 원에서 5천만 원, 중간 규모는 5천만 원에서 1억 5천만 원, 복잡한 기능이 포함된 대규모 플랫폼은 2억 원 이상입니다. 비용은 트랜잭션 수, 권한 구조, 데이터 보관 요구사항에 따라 크게 달라집니다. 견적을 받을 때는 기능 목록뿐 아니라 확장성과 유지보수 조건까지 확인해야 합니다.
플랫폼 제작 기간은 얼마나 걸리나요?
일반적으로 기획부터 오픈까지 3개월에서 6개월이 소요됩니다. 하지만 기능이 복잡하거나 외부 시스템 연동이 많으면 1년 이상 걸릴 수도 있습니다. 개발 기간을 단축하려면 초기 요구사항 정의를 명확히 하고, 권한 구조와 데이터 정책을 미리 확정하는 것이 중요합니다. 개발사와의 커뮤니케이션 주기가 짧을수록 일정 지연 가능성이 줄어듭니다.
외주 개발과 자체 개발 중 어떤 게 나은가요?
초기 스타트업이나 IT 인력이 없는 회사는 외주 개발이 현실적입니다. 반면 장기적으로 플랫폼을 지속적으로 개선하고 내부 역량을 쌓으려는 회사는 자체 개발팀을 꾸리는 것이 유리합니다. 외주는 초기 비용이 낮지만 유지보수와 기능 추가 시 추가 비용이 발생할 수 있고, 자체 개발은 초기 투자가 크지만 장기적인 통제력이 높습니다. 프로젝트의 규모와 회사의 성장 계획을 고려해 결정하세요.