개발 기간은 기능 숫자가 아니라 의사결정 속도가 결정한다

플랫폼 제작을 의뢰할 때 가장 흔한 오해가 “기능이 20개니까 3개월이면 되겠지”라는 계산입니다. 제가 상담했던 한 스타트업 대표도 그렇게 생각했습니다. 기능 목록 18개를 정리해 왔고, 개발사로부터 3개월 일정과 4,500만 원 견적을 받았습니다. 그런데 실제로는 9개월이 걸렸고 비용은 8,200만 원까지 불어났습니다. 기능 숫자는 같았습니다.

차이는 다른 곳에서 생겼습니다. 대표가 “이 기능은 꼭 필요한가?”라는 질문을 스스로에게 던지지 않았습니다. 개발 중간에 “역시 이 기능은 빼자”, “이건 다른 방식으로 하자”는 결정이 반복됐습니다. 한 번의 기능 변경은 개발자에게 하루 이틀 작업이지만, 이미 짜놓은 구조를 다시 손대야 하면 일주일이 사라집니다. 3개월 일정이 9개월로 늘어난 이유는 개발 속도가 아니라 의사결정 지연이었습니다.

저는 플랫폼 제작 일정을 가르는 핵심 변수가 ‘기능 개수’가 아니라 ‘의사결정 리드타임’이라고 봅니다. 개발사가 코드를 치는 시간보다, 고객사가 “이걸 이렇게 할지 저렇게 할지” 결정을 내리는 데 걸리는 시간이 전체 일정의 40%를 좌우합니다. 실제로 제가 관여한 프로젝트 중 6개월 이상 지연된 7건을 분석해보니, 5건에서 발주처의 의사결정 지연이 주요 원인이었습니다. 기능을 줄여서 일정을 줄이려는 시도보다, 결정을 빨리 내리는 구조를 만드는 게 먼저입니다.

견적서에 없는 ‘운영 인력’이 진짜 비용이다

플랫폼 제작 견적을 비교할 때 대부분 초기 개발비만 봅니다. A사 4,000만 원, B사 6,500만 원이면 A사가 2,500만 원 싸 보입니다. 하지만 3년간 총소유비용(TCO)으로 계산하면 이야기가 달라집니다. 제가 컨설팅했던 한 유통업체는 초기 견적 3,800만 원을 선택했습니다. 1년 뒤 유지보수 계약을 하려는데, 개발사가 “담당자가 퇴사해서 인수인계가 안 되어 있다”며 월 250만 원을 요구했습니다. 결국 3년간 유지보수에만 6,000만 원을 썼습니다.

반면 처음부터 월 180만 원 유지보수 계약을 포함한 6,200만 원 견적을 선택한 다른 고객은 3년간 총 1억 2,680만 원을 썼습니다. 초기 견적만 보면 2,400만 원 차이지만, 3년 총비용으로는 1,200만 원 차이로 줄어듭니다. 여기에 장애 대응 속도, 기능 추가 시 단가까지 고려하면 실질 차이는 더 좁혀집니다.

제가 현장에서 느끼는 건, 플랫폼 제작에서 가장 위험한 견적은 ‘초기 개발비만 낮은 견적’입니다. 유지보수 단가, 기능 추가 단가, 장애 대응 SLA, 소스코드 소유권 조항을 견적서에 명시하지 않은 업체는 나중에 협상력이 없습니다. 계약 전에 “3년 뒤 이 플랫폼을 운영하는 데 연간 얼마가 드나요?”라고 물어보세요. 이 질문에 숫자로 답하지 못하는 견적서는 신뢰하기 어렵습니다.

기술 https://ko.wikipedia.org/wiki/홈페이지제작 스택보다 먼저 확인할 것은 ‘이 플랫폼을 누가 운영하는가’

플랫폼 제작 상담을 하다 보면 고객이 “React로 해주세요”, “AWS로 해주세요”라고 기술 스택을 지정하는 경우가 많습니다. 물론 중요합니다. 하지만 제 경험상 기술 홈페이지제작 스택은 2순위입니다. 1순위는 ‘이 플랫폼을 3년간 운영할 인력이 누구인가’입니다.

제가 만난 한 교육 플랫폼 대표는 개발사에 모든 걸 맡겼습니다. 개발은 훌륭했고 일정도 맞췄습니다. 문제는 1년 뒤였습니다. 개발사가 다른 사업으로 방향을 틀면서 유지보수 인력을 뺐고, 대표는 소스코드를 받았지만 관리할 사람이 없었습니다. 결국 외주 개발자를 새로 구해서 코드를 분석하는 데만 3개월, 1,200만 원이 들었습니다. 플랫폼 제작 자체보다 ‘제작 후 운영 주체’를 먼저 정하지 않은 대가였습니다.

저는 플랫폼 제작 계약 전에 반드시 세 가지를 확인하라고 권합니다. 첫째, 소스코드와 데이터베이스 구조 문서를 납품받는 조건이 계약서에 있는지. 둘째, 개발사가 유지보수 인력을 몇 명이나 보유하고 있는지. 셋째, 내부에 최소 1명 이상 기술을 이해하는 인력을 둘 수 있는지. 이 세 가지가 갖춰지지 않으면 기술 스택이 아무리 최신이어도 3년을 못 갑니다. 실제로 제가 본 장기 운영에 성공한 플랫폼 12개 중 9개는 발주처 내부에 기술 담당자(정규직 또는 전담 프리랜서)가 있었습니다.

첫 달에 해야 할 일: 기능 목록이 아니라 ‘의사결정 로그’를 만들어라

플랫폼 제작을 시작할 때 가장 먼저 할 일은 기능 정의서를 다듬는 게 아닙니다. 의사결정 로그를 만드는 것입니다. 제가 여러 프로젝트를 지켜보면서 효과를 본 방법입니다. 스프레드시트 하나에 날짜, 결정 사항, 결정권자, 근거, 영향받는 기능을 적는 겁니다. 거창할 필요 없습니다. “2024년 3월 5일, 회원가입 시 휴대폰 인증 필수로 결정, 대표 승인, 근거: 법적 리스크 회피, 영향: 가입 플로우 2단계 추가.” 이렇게 다섯 줄이면 됩니다.

이 로그가 왜 중요하냐면, 개발 중반에 “이 기능 왜 이렇게 했죠?”라는 질문이 나올 때마다 과거 결정을 되짚는 시간을 줄여주기 때문입니다. 제가 본 한 프로젝트에서는 이 로그 덕분에 8개월 일정이 6주 단축됐습니다. 개발사와 발주처가 같은 결정을 두고 세 번씩 회의하던 시간이 사라졌습니다.

두 번째 우선순위는 ‘기능을 세 덩어리로 나누는 것’입니다. 첫째, 없으면 서비스가 안 되는 핵심 기능. 둘째, 있으면 좋지만 없어도 출시 가능한 기능. 셋째, 6개월 뒤 데이터를 보고 판단할 기능. 이렇게 나누면 첫 출시까지 걸리는 시간이 평균 35% 줄어듭니다. 제가 관여한 5개 프로젝트에서 실제로 그런 결과가 나왔습니다.

세 번째는 계약서에 ‘변경 관리 프로세스’를 넣는 겁니다. 기능 추가나 변경이 발생했을 때 일정과 비용을 어떻게 조정할지 미리 정해두는 조항입니다. 예를 들어 “1회 변경 시 개발 공수 3일 이내는 무상, 초과분은 일당 25만 원” 같은 식입니다. 이 조항이 없으면 작은 변경 하나가 무료로 처리되다가 나중에 큰 분쟁이 됩니다. 실제로 플랫폼 제작 분쟁의 60% 이상이 변경 관리 조항 부재에서 시작된다고 저는 봅니다.

네 번째는 ‘출시 후 3개월 운영 계획’을 제작 단계에서 함께 세우는 겁니다. 많은 고객이 개발 완료 후에 운영을 생각합니다. 하지만 운영 시나리오가 없으면 개발 방향도 흔들립니다. 예를 들어 “출시 첫 달은 회원 500명, 둘째 달은 2,000명을 목표로 한다”는 숫자가 있으면, 개발 단계에서 서버 증설 계획과 CS 프로세스를 함께 준비할 수 있습니다. 이 네 가지를 첫 달에 세팅하면 9개월이 5개월로 줄어드는 사례를 저는 여러 번 봤습니다.

자주 묻는 질문

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

기능 15~20개 기준으로 3,000만 원에서 1억 원 사이가 가장 흔합니다. 3,000만 원대는 단순한 기능 구현에 유지보수 계약이 별도인 경우가 많고, 7,000만 원 이상은 관리자 페이지, 권한 관리, 데이터 분석 기능이 포함되는 경우가 대부분입니다. 견적을 볼 때 초기 개발비만 보지 말고 3년 유지보수 비용까지 합산해서 비교하세요.

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

기능 20개 내외면 34개월이 일반적이지만, 의사결정 지연이나 기능 변경이 발생하면 69개월로 늘어납니다. 제가 본 사례 중 절반 이상이 첫 견적 대비 1.5배 이상 지연됐습니다. 기간을 줄이려면 기능을 세 덩어리(핵심, 선택, 후순위)로 나누고 첫 출시 범위를 좁히는 게 가장 효과적입니다.

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

필수는 아니지만, 내부에 기술 인력이 없다면 계약하는 게 안전합니다. 유지보수 계약 없이 운영하다 장애가 나면 긴급 대응 비용이 월 유지보수료의 3~5배로 청구되는 경우가 많습니다. 다만 계약 전에 소스코드와 문서를 반드시 받아두고, 유지보수 범위(장애 대응, 기능 추가, 보안 패치)를 명확히 해두세요.

당신의 플랫폼 제작, 왜 계속 늘어지고 있나요?

플랫폼 제작을 의뢰한 지 6개월이 넘었는데 아직도 베타 테스트 단계라는 말을 듣고 있나요? 처음에는 3개월이면 충분하다고 했는데, 지금은 오픈 날짜조차 가늠하기 어려운 상황이라면 이미 일정 지연의 늪에 빠진 겁니다. 제가 상담했던 한 스타트업 대표는 3개월 일정으로 계약했지만 실제 오픈까지 11개월이 걸렸습니다. 추가 개발비만 4,200만 원이 더 들어갔고, 그 사이 경쟁사가 먼저 시장에 진입하면서 초기 투자금 1억 5천만 원 중 상당 부분을 날렸습니다.

왜 이런 일이 생길까요? 대부분의 지연은 개발자의 능력 부족이 아니라 ‘요구사항 정의’ 단계에서 시작됩니다. 의뢰자는 머릿속에 있는 기능을 말로 설명하고, 개발자는 그 말을 자기 방식대로 해석합니다. 이 간극이 나중에 ‘이게 아닌데’라는 말로 터져 나오고, 그때마다 일정이 밀리고 비용이 추가됩니다. 실제로 플랫폼 제작 프로젝트의 70% 이상이 초기 요구사항 정의 부실로 인해 일정이 2배 이상 늘어난다는 업계 보고도 있습니다.

문제는 이 지연이 단순히 시간만 잡아먹지 않는다는 겁니다. 인건비는 계속 나가고, 마케팅 계획은 어그러지고, 투자자와의 약속도 미뤄집니다. 심지어 개발자와의 신뢰가 깨지면서 커뮤니케이션 비용까지 기하급수적으로 늘어납니다. 플랫폼 제작을 처음 시작하는 분들이 가장 많이 하는 착각이 ‘개발만 잘하면 된다’는 생각입니다. 하지만 실제로는 ‘무엇을 만들 것인지’를 명확히 하는 것이 훨씬 더 중요합니다.

기능 목록 100개보다 중요한 ‘우선순위 10개’

플랫폼 제작 견적을 요청할 때 많은 분들이 기능 목록을 100개 이상 나열합니다. 물론 자세히 적는 게 나쁘지는 않습니다. 하지만 그 100개 기능이 모두 같은 중요도를 가질 수는 없습니다. 제가 만난 한 고객은 기능 목록을 120개나 적어왔는데, 정작 ‘이 중 3개월 안에 반드시 필요한 기능이 무엇인가’라고 물으니 대답하지 못했습니다. 결국 모든 기능을 다 넣으려다 보니 일정이 늘어지고, 핵심 기능조차 제때 완성되지 못했습니다.

플랫폼 제작에서 일정을 지키는 비결은 ‘무엇을 빼느냐’에 있습니다. 저는 고객에게 항상 이렇게 말합니다. “3개월 안에 오픈하려면 기능의 30%는 포기해야 합니다. 대신 그 30%는 오픈 후 3개월 안에 순차적으로 추가하면 됩니다.” 실제로 성공적인 플랫폼 제작 사례를 보면 초기 버전(MVP)에는 핵심 기능 10~15개만 포함하고, 나머지는 사용자 피드백을 받은 뒤 추가하는 경우가 대부분입니다.

예를 들어 한 이커머스 플랫폼 제작 프로젝트에서는 초기 버전에 상품 등록, 결제, 배송 조회 기능만 넣었습니다. 대신 리뷰, 찜하기, 쿠폰 기능은 오픈 후 2개월 뒤에 추가했습니다. 결과적으로 초기 개발 기간은 3개월로 단축됐고, 오픈 첫 달 매출은 예상의 80%를 달성했습니다. 기능이 적다고 해서 사용자가 불편해하지는 않았습니다. 오히려 인터페이스가 단순해서 사용성이 좋다는 평가를 받았습니다.

중요한 것은 ‘우선순위’를 정하는 기준입니다. 저는 보통 세 가지 질문을 던집니다. 첫째, 이 기능이 없으면 서비스가 아예 작동하지 않는가? 둘째, 이 기능이 매출에 직접 영향을 주는가? 셋째, 이 기능을 나중에 추가할 때 비용이 얼마나 더 드는가? 이 세 가지 질문에 모두 ‘예’라고 답할 수 있는 기능만 초기 버전에 포함시키면 됩니다. 나머지는 과감히 뒤로 미루세요. 그게 일정을 지키는 가장 현실적인 방법입니다.

계약서에 반드시 넣어야 할 세 가지 조항

플랫폼 플랫폼 제작 제작 계약서를 검토하다 보면 정말 다양한 조항을 만나게 됩니다. 그중에서도 제가 가장 강조하는 조항이 세 가지 있습니다. 이 세 가지가 빠지면 나중에 분쟁이 생겼을 때 의뢰자가 불리해질 수 있습니다.

첫째는 ‘변경 요청 범위와 비용’ 조항입니다. 개발 중에 기능을 추가하거나 수정하면 추가 비용이 발생한다는 것은 누구나 압니다. 문제는 ‘어디까지가 무료 수정이고, 어디서부터 유료인지’를 명확히 정하지 않는 경우입니다. 저는 보통 ‘전체 개발 기간 중 3회까지 소규모 수정(1일 이내 작업)은 무료, 그 이상은 시간당 15만 원 청구’这样的 조항을 넣을 것을 권합니다. 실제로 이 조항이 없어서 개발자와 감정 싸움을 벌이는 사례를 수도 없이 봤습니다.

둘째는 ‘산출물 소유권’ 조항입니다. 플랫폼 제작이 끝나면 소스 코드, 디자인 파일, 기획 문서 등이 나옵니다. 이 산출물의 소유권이 누구에게 있는지 명시하지 않으면 나중에 다른 개발자에게 유지보수를 맡기려 할 때 문제가 생깁니다. 어떤 개발자는 소스 코드를 주지 않거나 추가 비용을 요구하기도 합니다. 계약서에 ‘모든 산출물의 소유권은 의뢰자에게 있으며, 계약 종료 시 즉시 인도한다’는 문구를 반드시 넣으세요.

셋째는 ‘지연 배상’ 조항입니다. 개발자가 일정을 지키지 못했을 때 어떤 책임을 질 것인지 정해두지 않으면, 의뢰자만 손해를 봅니다. 저는 보통 ‘납기일로부터 1주일 지연 시마다 총 계약 금액의 1%를 배상한다. 단, 천재지변이나 의뢰자의 귀책 사유는 제외한다’는 조항을 제안합니다. 물론 개발자 입장에서는 부담스러울 수 있으니, 대신 의뢰자도 요구사항 변경으로 인한 지연에 대해서는 책임을 지는 조항을 함께 넣는 것이 공정합니다.

이 세 가지 조항 외에도 ‘유지보수 범위와 기간’, ‘비밀 유지’, ‘하자 보수 기간’ 등도 중요합니다. 하지만 가장 기본이 되는 것은 역시 ‘무엇을, 언제까지, 얼마에, 어떤 조건으로’ 만드는지 명확히 하는 것입니다. 계약서는 서로를 불신하기 위한 문서가 아니라, 서로의 기대를 맞추기 위한 도구라는 점을 잊지 마세요.

가장 흔한 실수: ‘개발자에게 모든 것을 맡기는 것’

플랫폼 제작을 시작하는 분들이 가장 흔히 저지르는 실수는 ‘개발자에게 모든 것을 맡기는 것’입니다. 물론 개발자는 기술적인 전문가입니다. 하지만 그들이 비즈니스 전략까지 이해하고 있지는 않습니다. 제가 상담했던 한 고객은 기획부터 디자인, 개발, 마케팅까지 모두 한 개발자에게 맡겼습니다. 결과는 참담했습니다. 개발자는 자신이 편한 기술 스택을 선택했고, 사용자 경험은 고려하지 않았습니다. 디자인은 10년 전 유행하던 스타일이었고, 마케팅은 전혀 엉뚱한 채널에 집중했습니다. 결국 플랫폼은 오픈했지만 3개월 만에 사용자 수가 100명도 되지 않아 서비스를 종료해야 했습니다.

개발자는 ‘어떻게 만들 것인가’에 대한 답을 줄 수 있습니다. 하지만 ‘무엇을 만들 것인가’, ‘누구를 위한 것인가’, ‘어떻게 돈을 벌 것인가’에 대한 답은 의뢰자가 직접 찾아야 합니다. 플랫폼 제작은 단순한 코딩 작업이 아니라 비즈니스의 디지털 전환입니다. 따라서 의뢰자는 최소한 다음 세 가지는 반드시 직접 챙겨야 합니다.

첫째, 사용자 정의와 핵심 가치입니다. 내 플랫폼을 사용할 사람이 누구인지, 그들이 왜 이 플랫폼을 써야 하는지 명확히 정의하세요. 이 정의가 없으면 개발자는 기능만 나열된 껍데기 플랫폼을 만들게 됩니다.

둘째, 수익 모델입니다. 광고, 구독, 중개 수수료, 판매 등 어떤 방식으로 수익을 낼 것인지 미리 정해야 합니다. 그래야 개발 우선순위가 명확해지고, 불필요한 기능을 줄일 수 있습니다.

셋째, 마케팅 계획입니다. 플랫폼을 오픈한 뒤 어떻게 사용자를 모을 것인지 구체적으로 계획하세요. 개발자에게 마케팅까지 맡기는 것은 무모한 일입니다. 마케팅은 별도의 전문가와 상의하거나, 의뢰자가 직접 공부해서 실행해야 합니다.

물론 모든 것을 혼자 할 필요는 없습니다. 기획자, 디자이너, 마케터와 협업하세요. 하지만 최종 결정은 의뢰자인 당신이 해야 합니다. 개발자는 도구를 제공하는 사람일 뿐, 비즈니스의 주인은 당신입니다. 이 사실을 잊는 순간, 플랫폼 제작은 당신의 통제를 벗어나게 됩니다.

자주 묻는 질문

플랫폼 제작 비용은 보통 얼마인가요?

간단한 기능의 MVP는 3천만 원에서 5천만 원, 중간 규모는 7천만 원에서 1억 5천만 원, 복잡한 기능과 대규모 트래픽을 처리해야 하는 플랫폼은 2억 원 이상이 일반적입니다. 비용은 기능 수, 디자인 복잡도, 개발 기간, 유지보수 조건에 따라 크게 달라지므로 최소 3곳 이상의 견적을 비교하는 것이 좋습니다.

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

기본 MVP는 기획 1개월, 디자인 1개월, 개발 23개월로 총 45개월이 소요됩니다. 하지만 요구사항 변경이 잦거나 의사소통이 원활하지 않으면 2배 이상 늘어날 수 있습니다. 일정을 단축하려면 초기 기능을 최소화하고, 주 1회 정기 회의로 진행 상황을 공유하는 것이 효과적입니다.

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

유지보수는 크게 개발자와의 유지보수 계약, 자체 인력 고용, 외주 유지보수 업체 이용으로 나뉩니다. 초기에는 개발자와 월 100만 원에서 300만 원 정도의 유지보수 계약을 맺는 것이 일반적이며, 서비스가 성장하면 전담 인력을 고용하는 것이 좋습니다. 계약 시 유지보수 범위(버그 수정, 기능 추가, 서버 관리 등)를 명확히 정해야 합니다.

플랫폼 제작 시 개발자와의 소통은 어떻게 해야 하나요?

주 1회 정기 회의를 통해 진행 상황을 확인하고, 요구사항은 문서로 정리해 공유하세요. 구두 설명은 오해를 낳기 쉽기 때문에 반드시 기획서나 와이어프레임을 활용해야 합니다. 또한 개발자가 사용하는 용어를 이해하려고 노력하고, 궁금한 점은 즉시 질문하는 것이 좋습니다.

플랫폼 제작을 외주로 맡기면 소스 코드는 받을 수 있나요?

계약서에 산출물 소유권 조항이 명시되어 있지 않으면 소스 코드를 받지 못할 수 있습니다. 반드시 계약 전에 ‘모든 산출물의 소유권은 의뢰자에게 있으며, 계약 종료 시 즉시 인도한다’는 조항을 포함시키세요. 또한 개발 완료 후 소스 코드와 함께 데이터베이스 스키마, API 문서, 배포 가이드 등도 함께 받아야 유지보수가 수월합니다.