싼 견적으로 만들고 1년 뒤 전면 재개발 한 패턴

“일단 시장에 나가야 해서” 가장 낮은 견적으로 앱이나 쇼핑몰을 오픈합니다. 처음 몇 달은 기능 추가가 조금 불편해도 버팁니다. 그런데 반년, 길어야 일 년이 지나면 회의실에서 비슷한 말이 반복됩니다. “이 구조로는 다음 단계가 안 됩니다. 새로 짜야 합니다.”

전면 재개발은 기술팀의 취향 문제가 아닌 경우가 많습니다. 처음부터 어떤 전제로 맡겼는지가 나중에 큰 청구서로 돌아오는 일입니다. 아래는 실명이나 가짜 회사 이야기 없이, 현장에서 자주 보는 패턴만 정리한 것입니다. 겁을 주려는 글이 아니라, 같은 돈을 두 번 쓰지 않기 위한 이야기입니다.

자주 보는 세 가지 패턴

첫 번째는 화면 견적만 맞춘 쇼핑몰입니다. 처음 범위는 “상품 목록, 상세, 장바구니, 결제, 간단 관리자” 정도였고, 견적도 페이지 수 기준이었습니다. 오픈 뒤 실제로 필요한 것은 쿠폰 예외, 부분 취소, 재고 맞추기, 송장, 고객 문의, 정산 리포트였습니다. 임시로 붙인 수정이 쌓이다 결제와 재고가 어긋나기 시작하면, 그때부터 재개발 이야기가 나옵니다. 쇼핑몰은 예쁜 화면보다 주문 상태가 끝까지 맞는지가 제품입니다.

두 번째는 MVP라는 이름만 빌린 정식 서비스입니다. 보고용 일정에 맞춰 권한, 로그, 관리 운영을 빼고 올립니다. 실제 손님이 들어오면 고객센터 문의가 곧 개발 요청이 되고, 한 사람이 병목이 됩니다. 데이터가 쌓인 뒤 다시 만들 때는 이관 비용까지 붙습니다. 실제 데이터가 들어가는 순간, “나중에 버릴 데모”의 폐기 비용은 급격히 올라갑니다.

세 번째는 계정과 소스가 수행자 개인에게만 있는 경우입니다. 싸게 유지보수하며 버티다 연락이 어려워지면, 서버와 저장소 접근이 불완전해집니다. 이때의 “재개발”은 개선이 아니라, 현황을 복구하기 어려운 상태에서 하는 신규 구축에 가깝습니다. 초기 구축비가 싸 보여도, 소유권이 비어 있으면 나중에 더 비쌀 수 있습니다.

비용이 두 번 붙는 이유

견적 두 장을 단순 합산해도 이미 부담이 큽니다. 여기에 늦어진 기능, 떠난 손님, 놓친 시즌 같은 기회 비용까지 더하면 격차는 더 벌어집니다.

재개발이 맞는 경우, 막을 수 있었던 경우

사업 방향이 크게 바뀌었거나, 검증에 성공한 뒤 계획대로 키우는 단계라면 재개발이 합리적일 수 있습니다. 규제나 플랫폼 정책이 바뀌어 전제가 무너진 경우도 마찬가지입니다.

반대로, 처음부터 매일 쓰는 운영 제품이었는데 데모 품질로 올렸거나, 계정·소스를 넘기지 않았거나, 결제·권한 같은 민감한 부분을 임시로 막았거나, 요구가 흐린 채 최저가만 고른 뒤 관계가 끊긴 경우는 막을 수 있었던 재개발에 가깝습니다. “그 업체가 문제”라고만 말하기 전에, 우리 프로젝트가 어느 유형인지 먼저 나누는 편이 다음 실수를 줄입니다.

다시 만들기 전에 답해볼 다섯 가지

무엇을 버리고 무엇을 옮길지 한 페이지로 쓸 수 있는지, 지금 시스템에 어떤 데이터가 어떤 의미로 있는지, 서비스가 잠깐 멈춰도 되는지·얼마나 병행할지, 1차 범위가 “예전 기능 전부 복제”가 아니라 우선순위인지, 소유권·보안·인수인계가 계약 첫 장에 있는지 확인합니다.

이 질문에 답하지 못한 채 “더 싼 재개발 업체”만 찾으면, 같은 패턴이 한 번 더 반복되기 쉽습니다.

처음부터 재개발 확률을 낮추는 최소 투자

모든 것을 대기업 수준으로 만들 필요는 없습니다. 효과 대비 부담이 작은 것만 골라도 충분합니다. 시나리오 중심으로 범위를 적고, 저장소와 클라우드는 발주 조직 명의로 두고, 운영에 올리기 전 시험 환경을 하나 두고, 결제·권한 경로는 대충 넘기지 않으며, 주간으로 이슈를 남기고, 오픈 때 “아직 안 되는 것” 목록을 공개하고, 유지보수 경계를 미리 합의하는 일입니다.

이 항목들을 합쳐도 대개는 “조금 더 여유 있는 1차 견적” 수준입니다. 전면 재개발 한 번에 비하면 훨씬 작은 보험인 경우가 많습니다.

재개발에 들어갈 때 피하고 싶은 실수

감정이 앞서면 “이번엔 다 넣고 제대로”로 흐르기 쉽습니다. 그러면 1차의 반대 극단인 과잉 범위가 됩니다. 지금 쓸 수 있는 자산부터 목록으로 만들고, 매출·운영에 꼭 필요한 시나리오만 1차로 두고, 데이터는 단계적으로 옮길 수 있는지 보고, 옛 시스템을 언제 끄고 문제가 생기면 어떻게 되돌릴지 정한 뒤, 첫 주에 소유권과 보안을 닫고, 로그·백업·시험 환경을 “나중에”로 미루지 않는 순서가 안전합니다.

성공 지표는 “예전 기능 전부 복원”보다 핵심 경로가 안정적으로 돌아가는지인 경우가 많습니다. 나머지는 데이터가 안정된 뒤 백로그로 올려도 됩니다. 재개발 중에도 옛 시스템의 긴급 장애 창구를 남겨 두지 않으면, 구축 팀이 매일 화재 진압에 불려가 일정이 다시 무너집니다.

회고에는 기술 목록뿐 아니라 선정 기준도 남기면 좋습니다. “가격 비중을 얼마나 뒀고, 어떤 질문이 빠졌는가?”를 적어 두면, 같은 패턴의 1차 구축을 반복할 확률이 줄어듭니다. 싼 견적의 함정은 숫자 자체가 아니라 그 숫자에 포함되지 않은 전제입니다. 전제가 깨지면 비용은 재개발이라는 큰 묶음으로 돌아옵니다.

LB Contents는 앱·홈페이지·쇼핑몰을 만들 때 화면뿐 아니라 운영 구조까지 같이 설계합니다. 저가 구축 이후 재개발을 검토 중이거나, 처음부터 재개발 확률을 낮추고 싶을 때 정리 전 단계의 상담도 가능합니다.