기능만 잘 만들면 된다는 착각

플랫폼 제작을 의뢰할 때 가장 흔한 오해가 ‘기능만 잘 구현되면 성공’이라는 생각이다. 지난 10년간 수많은 프로젝트를 지켜보면서 이 착각이 얼마나 큰 비용을 초래하는지 여러 번 목격했다. 기능 목록은 플랫폼의 뼈대일 뿐이고, 살아 숨 쉬는 서비스로 만드는 건 전혀 다른 문제다.

실제로 한 고객은 3천만 원을 들여 쇼핑몰 플랫폼을 제작했다. 기능은 모두 구현됐다. 상품 등록, 결제, 배송 조회까지. 그런데 오픈 첫 달 매출이 200만 원도 안 됐다. 이유는 간단했다. 상품 상세 페이지가 모바일에서 깨졌고, 검색 속도가 5초를 넘겼다. 기능은 있지만 쓸 수 없는 플랫폼이었다.

기능 구현에만 집중하면 사용자 경험이라는 본질을 놓치기 쉽다. 플랫폼 제작의 성패는 ‘무엇을 만들었는가’보다 ‘어떻게 작동하는가’에 달려 있다. 기능 목록을 검토하기 전에 먼저 확인해야 할 세 가지가 있다.

첫째, 사용자가 실제로 쓰는 흐름인가

기능 목록에는 ‘로그인’, ‘검색’, ‘결제’ 같은 항목이 나열된다. 하지만 사용자는 그런 단위로 행동하지 않는다. ‘친구가 추천한 상품을 찾아서 비교하고, 할인 쿠폰을 적용해 결제한다’는 하나의 흐름으로 움직인다.

플랫폼 제작 초기 단계에서 사용자 시나리오를 그려보지 않으면, 기능은 있어도 연결이 끊어진다. 예를 들어 장바구니에 담은 상품이 품절되면 어떤 메시지가 뜨는가? 검색 결과가 없을 때 다른 상품을 추천해주는가? 비밀번호를 잊어버렸을 때 재설정 링크는 몇 분 안에 도착하는가? 이런 디테일이 실제 사용률을 가른다.

내가 상담했던 한 스타트업은 기능 목록 50개를 들고 왔다. 그중 실제로 출시 후 3개월간 사용된 기능은 12개였다. 나머지 38개는 개발비만 축내고 사라졌다. 기능 개수보다 사용자 여정의 완성도가 훨씬 중요하다.

기능 목록을 받으면 ‘이 기능이 어떤 흐름에서 쓰이는가’를 물어야 한다. 답이 명확하지 않다면 그 기능은 우선순위에서 밀어도 된다.

둘째, 운영할 수 있는 구조인가

플랫폼은 만들고 끝이 아니다. 매일 상품을 등록하고, 리뷰를 관리하고, 회원 정보를 처리해야 한다. 그런데 많은 의뢰인이 이 운영 부담을 간과한다.

작년에 한 교육 플랫폼 프로젝트를 봤다. 강의 영상 업로드 기능은 훌륭했다. 하지만 강사가 직접 영상을 올리려면 FTP에 접속해 파일을 올리고, 관리자 페이지에서 경로를 수동으로 입력해야 했다. 결국 운영팀이 대신 해줘야 했고, 강사 10명당 운영 인력 1명이 추가로 필요했다. 인건비로 연간 3천만 원이 더 나갔다. 초기 개발비 5천만 원보다 큰 비용이다.

관리자 페이지의 완성도는 플랫폼 제작 견적에서 가장 저평가되는 부분이다. 개발사는 눈에 보이는 사용자 화면에 집중하고, 관리자 기능은 최소한으로 구현하는 경우가 많다. 하지만 실제로 플랫폼을 굴리는 사람은 관리자 페이지를 쓰는 운영팀이다.

견적서를 받을 때 ‘관리자 페이지에 어떤 기능이 포함되는가’를 반드시 확인해야 한다. 콘텐츠 일괄 등록, 권한별 접근 제어, 로그 조회, 통계 대시보드 같은 항목이 빠져 있으면 나중에 추가 비용이 발생한다. 보통 전체 개발비의 20~30%를 추가로 요구받는다.

셋째, 확장 가능한 기술 쇼핑몰제작 선택인가

플랫폼 제작 초기에는 사용자 100명도 버거울 수 있다. 하지만 https://search.naver.com/search.naver?query=쇼핑몰제작 1년 후 1만 명이 될 수도 있다. 문제는 초기 기술 선택이 확장성을 결정한다는 점이다.

한 고객사는 초기 비용을 아끼려고 공유 호스팅에 플랫폼을 올렸다. 월 3만 원이었다. 사용자가 5천 명을 넘어서자 페이지 로딩 속도가 10초를 넘기 시작했다. 결국 서버 구조를 바꾸는 데 2천만 원과 3개월이 들었다. 처음부터 클라우드 기반으로 설계했다면 월 20만 원 정도로 해결됐을 문제다.

기술 스택도 마찬가지다. 개발사가 익숙한 기술을 쓰겠다고 하면, 그 기술이 5년 후에도 유지보수 가능한지 확인해야 한다. 실제로 2015년에 유행했던 한 프레임워크는 지금 지원이 종료됐다. 그 프레임워크로 만든 플랫폼을 유지보수하는 데 시간당 15만 원을 쓰고 있는 고객도 있다.

확장성은 단순히 서버 성능만 뜻하지 않는다. 데이터베이스 구조, API 설계, 코드 모듈화 수준까지 포함된다. 견적이 2천만 원 차이 난다면, 그 차이가 3년 후 유지보수 비용에서 어떻게 나타날지 따져봐야 한다. 저는 초기 개발비 20% 차이보다 3년간 유지보수 비용 50% 차이가 더 크게 다가오는 것을 여러 번 봤다.

견적서에서 놓치기 쉬운 숨은 비용

플랫폼 제작 견적서에는 드러나지 않는 비용이 있다. 대표적인 것이 ‘변경 요청 비용’이다. 대부분의 개발 계약서에는 초기 기능 목록에 없는 기능을 추가할 때 별도 비용을 청구한다는 조항이 있다. 문제는 ‘기능 목록에 없는’의 기준이 모호하다는 점이다.

예를 들어 ‘회원가입’ 기능이 목록에 있다고 하자. 그런데 소셜 로그인(카카오, 네이버)은 목록에 없다. 개발사는 추가 비용 300만 원을 요구한다. 의뢰인은 ‘회원가입에 당연히 포함되는 것 아니냐’고 생각한다. 이런 분쟁이 전체 프로젝트의 30%에서 발생한다.

또 하나는 ‘테스트 및 배포 비용’이다. 개발 완료 후 실제 서버에 올리고, 오류를 잡고, 보안 점검을 하는 과정에 추가 인력이 투입된다. 견적서에 이 항목이 명시되어 있지 않으면 나중에 전체 개발비의 10~15%를 추가로 요구받을 수 있다.

가장 흔한 숨은 비용은 ‘유지보수 계약’이다. 개발사는 초기 3개월 무상 유지보수를 제공하고, 이후 월 100만~300만 원의 유지보수 계약을 제안한다. 이 비용을 초기 예산에 포함하지 않으면, 오픈 후 매달 고정비가 발생해 자금 압박을 받는다. 플랫폼 제작 예산을 세울 때 개발비의 최소 20%는 첫해 유지보수 비용으로 잡아두는 게 안전하다.

개발사 선정에서 반드시 물어야 할 질문

플랫폼 제작 파트너를 고를 때 포트폴리오만 보면 실수한다. 포트폴리오는 잘된 사례만 보여주기 때문이다. 대신 다음 질문을 던져보길 권한다.

“이 프로젝트에서 가장 어려웠던 기술적 문제는 무엇이었고, 어떻게 해결했나요?” 이 질문에 구체적으로 답하는 개발사는 실무 경험이 있다. 반면 “특별히 어려운 점은 없었습니다”라고 답하면 실제로 그 프로젝트를 수행하지 않았거나, 문제를 인식하지 못한 것이다.

“오픈 후 6개월 동안 유지보수 요청이 가장 많았던 기능은 무엇이었나요?” 이 질문은 개발사가 운영 단계까지 책임감을 가지고 있는지 보여준다. 좋은 개발사는 유지보수 데이터를 가지고 있다.

“비슷한 규모의 플랫폼을 운영 중인 고객사가 있나요?” 레퍼런스 체크는 필수다. 가능하면 그 고객사에 직접 연락해 “개발사가 일정 변경을 얼마나 자주 요청했는지”, “장애 대응은 얼마나 빨랐는지”를 물어보라. 계약 전 이 과정을 생략하면 나중에 후회한다.

내가 아는 한 의뢰인은 이 질문 세 개를 통해 3개 개발사 중 2개를 걸러냈다. 최종 선정된 개발사는 예상보다 견적이 1.5배 높았지만, 일정 지연 없이 프로젝트를 마쳤다. 초기 비용보다 총비용을 보는 관점이 필요하다.

지금 당장 무엇부터 해야 하나

플랫폼 제작을 시작하기 전에 가장 먼저 할 일은 기능 목록을 줄이는 것이다. 100개의 기능을 나열했다면, 그중 20개를 골라 ‘출시 첫 달에 반드시 필요한 것’만 남겨라. 나머지는 2차 개발로 미뤄도 된다. 실제로 성공한 플랫폼 중 초기 버전이 30개 이상의 기능을 가진 경우는 드물다.

두 번째는 사용자 흐름을 종이에 그려보는 것이다. 회원가입부터 첫 구매까지, 또는 첫 콘텐츠 업로드까지의 과정을 단계별로 적어보라. 각 단계에서 사용자가 어떤 정보를 필요로 하고, 어떤 불편을 겪을지 예상해보라. 이 과정에서 불필요한 기능이 걸러지고, 빠진 기능이 보인다.

세 번째는 예산의 20%를 ‘예비비’로 남겨두는 것이다. 플랫폼 제작은 계획대로 되지 않는다. 기능 변경, 일정 지연, 추가 테스트 비용이 발생한다. 예비비 없이 시작하면 중간에 자금이 끊겨 프로젝트가 중단된다. 내가 본 실패 사례의 절반은 기술 문제가 아니라 예산 문제였다.

마지막으로, 개발사와 계약하기 전에 ‘이 플랫폼을 3년 후 누가 운영할 것인가’를 생각하라. 내부 인력이 운영할 것인지, 외주를 줄 것인지에 따라 기술 선택과 문서화 수준이 달라져야 한다. 이 질문에 답하지 못하면 3년 후 유지보수 비용이 개발비를 넘어설 수 있다. 플랫폼 제작은 단기 프로젝트가 아니라 최소 3년을 내다보는 투자다.

자주 묻는 질문

플랫폼 제작 비용은 얼마나 드나요?

규모에 따라 3천만 원에서 1억 원 이상까지 다양합니다. 간단한 기능만 있는 초기 버전은 3천만5천만 원, 사용자 관리와 결제, 관리자 페이지까지 포함하면 7천만1억 원 선입니다. 여기에 첫해 유지보수 비용(개발비의 1520%)과 서버 운영비(월 10만50만 원)를 별도로 잡아야 합니다.

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

기능 30개 기준으로 34개월이 평균입니다. 하지만 요구사항 변경이 잦으면 6개월 이상 늘어납니다. 일정을 단축하려면 초기 기능을 20개 이하로 줄이고, 디자인과 개발을 동시에 진행하는 방식을 선택해야 합니다. 개발 기간보다 오픈 후 안정화 기간(보통 12개월)을 더 넉넉히 잡는 게 좋습니다.

외주 개발과 내부 개발 중 어떤 게 나은가요?

초기에는 외주가 일반적입니다. 내부 개발팀을 꾸리려면 개발자 23명에 연봉 6천만1억 원이 들기 때문입니다. 다만 플랫폼이 핵심 사업이 되면 내부 인력을 확보하는 편이 유지보수 속도와 비용 면에서 유리합니다. 외주로 시작하되, 2년 후 내부 전환을 염두에 두고 코드 문서화와 인수인계 조건을 계약서에 명시하세요.

플랫폼 제작 후 유지보수는 꼭 해야 하나요?

법적 의무는 아니지만 사실상 필수입니다. 보안 취약점, 서버 장애, 기능 오류는 언제든 발생하며, 이를 방치하면 서비스 중단으로 이어집니다. 개발사와 월 50만200만 원의 유지보수 계약을 맺거나, 최소한 장애 대응만이라도 포함한 계약을 권합니다. 계약 없이 문제가 생기면 긴급 출동 비용으로 시간당 10만20만 원을 청구하는 경우가 많습니다.

기능 목록은 어떻게 정리해야 하나요?

사용자 흐름 기준으로 정리하세요. ‘로그인, 검색, 결제’처럼 기능을 나열하지 말고, ‘신규 사용자가 상품을 검색해 첫 구매를 완료하는 과정’과 같이 시나리오로 묶는 겁니다. 각 시나리오에 필요한 기능만 남기면 자연스럽게 우선순위가 정해집니다. 이렇게 하면 불필요한 기능이 30~40% 줄어들고, 견적과 일정도 그만큼 현실적으로 바뀝니다.

기능만 잘 만들면 된다는 착각

플랫폼 제작을 의뢰하러 온 고객 중 절반 이상이 기능 목록부터 꺼냅니다. 회원가입, 결제, 검색, 알림, 관리자 페이지…. 항목은 30개가 넘는데, 정작 이 플랫폼이 어떤 사람을 어떻게 모으고 무엇으로 돈을 버는지에 대한 문장은 없습니다. 기능은 도구일 뿐인데, 도구 목록을 완성하면 서비스가 완성된다고 믿는 겁니다.

작년에 상담한 한 고객은 기능 정의서 42페이지를 들고 왔습니다. 예산은 4천만 원, 기간은 4개월을 생각하고 있었죠. 그런데 첫 질문인 “이 플랫폼에 첫 100명은 어디서 오나요?”에 답이 없었습니다. 기능은 많은데 유입 경로가 없으니, 만들어도 아무도 없는 광장이 될 판이었습니다. 결국 그 프로젝트는 초기 기능을 12개로 줄이고, 대신 커뮤니티 운영 도구와 초대 시스템에 예산을 몰아넣었습니다. 오픈 3개월 만에 가입자 1,800명을 모았고, 그중 유료 전환은 4.2%였습니다. 기능 개수와 성공은 별개라는 걸 보여준 사례입니다.

플랫폼 제작에서 진짜 위험한 건 개발이 안 되는 게 아닙니다. 다 만들어 놓고 아무도 안 쓰는 겁니다. 기능 목록은 개발자에게 일을 시키는 문서지, 시장에게 사랑받는 문서가 아닙니다. 의뢰 전에 기능을 하나씩 지워보세요. 지워도 서비스가 굴러가면 그건 없어도 되는 기능입니다.

견적서에 드러나는 진짜 차이

같은 기능 목록을 주고 견적을 받아도 3천만 원부터 1억 2천만 원까지 나옵니다. 고객은 “왜 이렇게 차이가 나죠?”라고 묻지만, 사실 견적 차이는 기능 차이가 아닙니다. 아키텍처 설계에 시간을 얼마나 쓰는지, 테스트 자동화를 포함하는지, 배포와 모니터링을 어디까지 책임지는지에서 갈립니다.

3천만 원 견적서에는 보통 이런 항목이 빠져 있습니다. 서버 부하 테스트, 보안 취약점 점검, 장애 대응 매뉴얼, 데이터 백업 정책. 이걸 나중에 추가하면 3천만 원짜리가 6천만 원이 됩니다. 반대로 1억 원 견적서에는 기획 문서화, QA 전담 인력, 출시 후 3개월 무상 유지보수가 포함된 경우가 많습니다. 견적서를 받을 때는 총액보다 ‘무엇이 빠졌는지’를 먼저 보세요. 빠진 항목이 곧 나중에 청구될 항목입니다.

제가 본 가장 흔한 실수는 견적서 비교표를 기능 체크리스트로만 만드는 겁니다. A사와 B사 모두 ‘결제 기능 포함’에 체크되어 있으면 같은 것으로 보지만, A사는 PG사 연동만, B사는 정기결제와 환불 자동화까지 포함합니다. 항목 이름이 같아도 깊이가 다릅니다. 견적서를 받으면 “이 항목에 들어가는 공수가 몇 맨데이인가요?”라고 물어보세요. 답이 바로 나오지 않으면 그 견적서는 신뢰하기 어렵습니다.

3개월이 9개월로 늘어나는 구조

일정 지연은 개발자의 게으름 때문이 아닙니다. 대부분 의사결정 구조에서 발생합니다. 플랫폼 제작 현장에서 가장 자주 보는 지연 원인은 ‘결정을 미루는 것’입니다. 디자인 시안 하나, 문구 하나, 정책 하나가 확정되지 않아 개발자가 대기하는 시간이 전체 일정의 20~30%를 차지합니다.

한 프로젝트는 3개월 계획으로 시작해 9개월 만에 오픈했습니다. 지연 원인을 추적해보니 개발 이슈는 3주였고, 나머지 5개월은 의사결정 지연과 요구사항 변경이었습니다. 대표가 중간에 “역시 모바일 앱도 있어야겠다”고 했고, 마케팅 팀장은 오픈 한 달 전에 “랜딩 페이지를 완전히 바꾸자”고 했습니다. 개발팀은 계속 재작업을 반복했죠.

이걸 막으려면 계약서에 ‘변경 관리 조항’을 넣어야 합니다. 요구사항 변경은 문서로만 접수하고, 변경 1건당 공수와 비용을 산정해 승인받는 절차입니다. 실제로 이 조항을 넣은 프로젝트는 지연율이 평균 18%로 떨어졌고, 없던 프로젝트는 42%였습니다. 숫자 하나 넣는 것만으로 일정 예측 가능성이 두 배 이상 좋아집니다.

또 하나, 기획 문서의 완성도가 일정을 좌우합니다. 화면 설계서에 ‘로그인 화면’이라고만 적혀 있으면 개발자는 자기 방식대로 만듭니다. 그러면 대표가 “이게 아니야”라고 하고, 다시 만듭니다. 화면 하나에 최소 3번의 피드백 사이클이 생기는 겁니다. 기획 단계에서 2주를 더 쓰면 개발 단계에서 6주를 아낄 수 있습니다.

기술 스택보다 중요한 운영 설계

고객들이 가장 많이 묻는 질문 중 하나가 “어떤 언어로 개발하나요?”입니다. 물론 중요합니다. 하지만 10년 넘게 현장을 보면서 느낀 건, 기술 홈페이지제작 스택이 플랫폼의 성패를 가른 경우는 생각보다 드물다는 겁니다. 반대로 운영 설계가 엉망이어서 실패한 사례는 수도 없이 봤습니다.

플랫폼은 오픈 후에 진짜 시작입니다. 회원이 늘고, 거래가 발생하고, 문의가 쌓입니다. 이때 관리자 페이지에서 할 수 있는 일이 제한적이면 운영팀이 개발팀에 매일 요청을 넣어야 합니다. “이 회원 정지 좀 풀어주세요”, “이 주문 상태 좀 바꿔주세요”. 개발자는 신규 기능을 만들어야 하는데 운영 요청에 발목 잡힙니다.

제가 컨설팅한 한 커머스 플랫폼은 오픈 6개월 만에 운영 요청이 하루 평균 47건까지 치솟았습니다. 원인은 관리자 페이지에 일괄 처리 기능이 없었기 때문입니다. 회원 상태 변경, 쿠폰 발급, 배송 상태 업데이트를 한 건씩만 할 수 있었습니다. 결국 관리자 도구를 다시 만드는 데 2천만 원을 추가로 썼습니다. 처음부터 운영 시나리오를 정의하고 관리자 기능을 설계했다면 들어가지 않았을 비용입니다.

기술 스택은 5년 뒤에 바뀔 수 있습니다. 하지만 운영 흐름은 서비스가 살아 있는 동안 계속됩니다. 개발사와 상담할 때 “관리자 페이지에서 운영팀이 직접 할 수 있는 일이 무엇인가요?”를 물어보세요. 이 질문에 구체적으로 답하는 개발사가 믿을 만한 곳입니다.

어떤 파트너를 선택해야 하는가

플랫폼 제작 파트너를 고를 때 가장 먼저 볼 것은 포트폴리오의 화려함이 아닙니다. ‘유지보수 중인 프로젝트가 몇 개인지’입니다. 오픈만 하고 손을 떼는 개발사는 책임감이 약합니다. 유지보수 계약이 살아 있는 고객이 많다는 건, 그들이 만든 플랫폼이 실제로 돌아가고 있다는 증거입니다.

두 번째로 볼 것은 장애 대응 체계입니다. “장애가 나면 어떻게 연락하나요?”라고 물었을 때 “카톡 주세요”라고 답하는 곳은 피하세요. SLA(서비스 수준 협약) 문서가 있는지, 장애 등급별 대응 시간이 정의되어 있는지 확인해야 합니다. 실제로 결제 장애는 1시간 안에 복구하지 못하면 매출 손실이 기하급수적으로 늘어납니다. 하루 거래액 2천만 원인 플랫폼에서 3시간 장애가 나면 250만 원이 그냥 날아갑니다.

세 번째는 ‘만들지 말라고 말해주는 용기’입니다. 고객이 원하는 기능을 다 들어주는 개발사는 편하지만 위험합니다. 예산과 일정 안에서 우선순위를 조정하고, 지금은 필요 없는 기능을 과감히 빼자고 제안하는 파트너가 오래 갑니다. 제 경험상 프로젝트 성공률이 높은 팀은 기능을 많이 만든 팀이 아니라, 뺄 것을 정확히 뺀 팀이었습니다.

마지막으로 계약서에 ‘소스 코드 소유권’과 ‘이관 조건’을 명시하세요. 개발사가 바뀌어도 플랫폼이 멈추지 않으려면 이 두 가지가 확실해야 합니다. 소유권 조항이 없어서 분쟁이 생긴 사례를 열 번 넘게 봤습니다. 플랫폼 제작은 결혼이 아니라 동업에 가깝습니다. 헤어질 때를 대비한 계약이 오히려 좋은 관계를 만듭니다.

자주 묻는 질문

플랫폼 제작 비용은 평균 얼마인가요?

국내 외주 시장 기준으로 기본 기능(회원, 결제, 관리자)을 갖춘 플랫폼은 3천만 원에서 6천만 원 선입니다. 여기에 실시간 채팅, 추천 알고리즘, 다국어 지원 같은 고도화 기능이 붙으면 1억 원을 넘어갑니다. 견적은 기능 개수보다 데이터 구조와 운영 도구의 복잡도에 더 크게 영향을 받습니다.

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

기획과 디자인을 포함해 최소 3개월, 일반적으로 4~6개월을 잡습니다. 다만 의사결정이 빠르고 요구사항 변경이 적은 프로젝트는 3개월 안에 오픈하는 경우도 있습니다. 반대로 이해관계자가 많거나 외부 연동이 복잡하면 9개월 이상 걸릴 수 있습니다.

노코드 툴로 플랫폼 제작해도 되나요?

초기 검증 단계라면 충분히 가능합니다. 월 10만~30만 원 수준으로 프로토타입을 만들 수 있어서 아이디어 테스트에 유리합니다. 하지만 거래량이 늘거나 커스텀 기능이 필요해지면 월 비용이 급증하고, 데이터 이관도 쉽지 않습니다. 유료 고객 1,000명을 넘길 시점에는 자체 개발을 검토하는 게 좋습니다.

개발사와 유지보수 계약은 꼭 해야 하나요?

의무는 아니지만 강력히 권합니다. 오픈 후 6개월 안에 발생하는 장애의 70% 이상이 초기 코드 안정화와 관련이 있어서, 개발을 맡은 곳이 대응하는 게 가장 빠릅니다. 보통 월 100만300만 원 수준의 유지보수 계약을 맺으며, 계약 없이 건별로 수리하면 비용이 23배 더 들 수 있습니다.