개발 범위가 늘면 시즌을 잃는다

시즌 론칭 두 달 전, 개발팀에서 연락이 옵니다. "요청하신 기능들을 다 반영하다 보니 일정이 조금 늘어날 것 같습니다." 조금이라는 단어가 불안하게 느껴졌다면, 이미 경험이 있으신 겁니다.

처음 계약할 때 범위는 분명했습니다. 발주 관리, 재고 현황, 매장별 배분. 그런데 회의가 거듭되면서 "이것도 되면 좋겠는데요"가 쌓이기 시작합니다. 반품 처리 자동화, 거래처별 정산 리포트, 인스타그램 연동, 시즌별 마진 분석 대시보드. 하나하나는 다 합리적인 요청입니다. 문제는 그것들이 합쳐지는 순간 일어납니다.

범위가 늘어나는 건 욕심이 아니라 구조적 문제입니다

스코프 크리프(Scope Creep), 즉 개발 범위의 점진적 확장은 패션·유통 업계 시스템 구축 프로젝트에서 가장 흔하게 발생하는 실패 원인입니다. 그런데 이걸 단순히 "요구사항을 너무 많이 넣어서"라고 보면 본질을 놓칩니다.

왜 패션 브랜드에서 특히 심각한가

패션 업계의 업무 구조 자체가 범위 확장을 부추깁니다. 영업팀은 거래처 관리가 필요하고, MD는 시즌 기획 데이터가 필요하고, 물류팀은 입출고 현황이 필요하고, 대표는 전체 매출 현황이 필요합니다. 이 네 가지 니즈는 서로 연결되어 있고, 연결되어 있기 때문에 "어차피 하는 거 같이 하자"는 논리가 계속 생깁니다.

게다가 패션은 시즌이 있습니다. SS 시즌 전에 끝내야 한다, FW 전에는 반드시 가동해야 한다는 데드라인이 명확합니다. 이 데드라인은 협상이 안 됩니다. 바이어 오더 마감일은 개발 일정을 기다려주지 않습니다.

숫자로 보는 범위 확장의 실제 비용

중간 규모 패션 브랜드(연매출 50억~100억 원, 매장 10~20개)가 ERP나 통합 관리 시스템을 구축할 때 초기 계약 범위는 보통 4~6개월, 5,000만~1억 원 수준입니다. 범위가 30% 늘어나면 어떻게 될까요?

• 개발 기간 연장: 4개월 → 6~7개월 (단순 비례가 아닌 복잡도 증가로 더 늘어남)
• 추가 개발 비용: 1,500만~3,000만 원
• 론칭 지연으로 인한 기회비용: SS 시즌 초반 6주를 엑셀로 버텨야 하는 운영 비용, 데이터 이중 입력 인건비, 오발주 리스크

그런데 진짜 비용은 마지막 항목입니다. 시스템이 없는 상태로 시즌 피크를 맞으면, 팀은 새 시스템 적응 대신 엑셀 오류 수습에 집중합니다. 론칭이 늦어질수록 도입 효과를 체감하는 시점도 밀립니다. 최악의 경우, 한 시즌을 통째로 날리고 다음 시즌 준비도 지연됩니다.

"이것도 되면 좋겠는데요"가 쌓이는 세 가지 순간

범위 확장은 갑자기 일어나지 않습니다. 특정 패턴이 반복됩니다.

1. 킥오프 직후 — 실무자가 처음으로 참여하는 순간

계약은 대표나 운영 총괄이 합니다. 그런데 킥오프 미팅에 실무 담당자가 처음 참여하면서 "저희는 이런 것도 필요한데요"가 시작됩니다. 계약 당시에는 없던 요구사항이 등장합니다. 이 시점에 명확한 범위 기준이 없으면, 개발사는 "검토해보겠습니다"로 넘어가고 나중에 추가 비용이나 일정 연장으로 돌아옵니다.

2. 중간 검토 시점 — 프로토타입을 처음 보는 순간

화면을 처음 보면 비로소 구체적인 아이디어가 생깁니다. "이 화면에서 바로 발주서 출력도 되면 좋겠어요", "여기에 전월 대비 증감률도 보여주세요." 각각은 작은 요청처럼 보이지만, 개발 입장에서는 데이터 구조 변경이나 새 기능 추가를 의미합니다.

3. 오픈 직전 — "이것만 추가하면" 의 함정

가장 위험한 순간입니다. 오픈이 임박했을 때 "이것만 하나 더 추가하면 완성인데"라는 생각이 듭니다. 그 "하나"가 오픈을 2주 미루고, 2주가 시즌 론칭과 겹칩니다.

시즌을 지키는 범위 관리의 실제 방법

스코프 크리프를 막는 건 개발사의 역할이기도 하지만, 브랜드 측이 먼저 구조를 갖춰야 합니다.

Phase 분리: 지금 당장 필요한 것 vs 나중에 해도 되는 것

가장 효과적인 방법은 기능을 시즌 오픈 전 필수(Phase 1)와 운영 안정화 후 추가(Phase 2)로 명확히 나누는 겁니다. 이 구분은 회의실에서 말로만 해서는 안 됩니다. 계약서와 개발 명세서에 문서로 박혀 있어야 합니다.

예를 들어 발주·재고·배분은 Phase 1, 거래처 정산 자동화와 마진 분석 대시보드는 Phase 2로 분리합니다. Phase 2는 시스템이 안정된 뒤 실제 운영 데이터를 보고 우선순위를 다시 정합니다. 이렇게 하면 오픈 시점에 "완벽한 시스템"은 없어도, "작동하는 시스템"은 있습니다.

변경 요청 프로세스를 만드세요

개발 중 새로운 요청이 생기면 구두로 전달하지 말고, 변경 요청서(Change Request) 형태로 문서화하는 습관이 필요합니다. 요청 내용, 예상 개발 기간, 일정 영향, 추가 비용을 한 페이지로 정리하면 "이게 정말 지금 필요한가"를 냉정하게 판단할 수 있습니다.

이 프로세스가 있으면 실무자의 요청이 나쁜 게 아니라 "이 요청은 Phase 2로 가자"는 합리적 결론이 납니다. 없으면 요청이 쌓이고, 일정이 밀리고, 책임 소재가 불분명해집니다.

개발사 선택 기준에 "범위 관리 경험"을 포함하세요

기술력만큼 중요한 게 프로젝트 관리 방식입니다. 제안 단계에서 "범위 변경이 생기면 어떻게 처리하시나요?"라고 직접 물어보세요. 명확한 프로세스를 설명하는 곳과 "유연하게 대응합니다"고만 답하는 곳은 다릅니다. 유연함은 좋지만, 프로세스 없는 유연함은 결국 브랜드가 비용을 부담합니다.

루브릭랩스가 Mardi Mercredi의 리오더·생산 통합 ERP를 구축할 때도, 폭발적 성장기라는 특수한 상황에서 Phase를 명확히 나누는 것이 핵심이었습니다. 성장 중인 브랜드일수록 요구사항이 빠르게 변하기 때문에, 처음부터 모든 것을 담으려 하면 시스템이 완성되기 전에 비즈니스가 이미 다른 방향으로 가 있습니다.

완벽한 시스템보다 제때 작동하는 시스템이 낫습니다

시스템 구축을 앞두고 가장 많이 하는 실수는 "이번 기회에 다 해결하자"는 생각입니다. 이해합니다. 엑셀 한계를 오래 버텨왔고, 이번 한 번에 제대로 하고 싶은 마음은 당연합니다.

하지만 패션 업계에서 "완벽한 시스템"은 시즌 이후에 존재합니다. 시즌 중에는 "지금 작동하는 시스템"이 필요합니다. 범위를 줄이는 게 타협이 아닙니다. 시즌을 지키는 전략입니다.

기능 하나를 Phase 2로 미루는 결정이 시즌 론칭 일정을 지키는 가장 확실한 방법입니다. → 문의하기