노노니 | 실전 서비스 기획자의 인사이트 블로그

외주로 앱 서비스를 만들 때 가장 먼저 궁금한 것이 "얼마나 걸리나요?"입니다. 외주 업체는 보통 3-4개월이면 된다고 말하지만, 실제로는 그보다 훨씬 오래 걸립니다. 현실적인 일정을 이해하고 계획해야 실망하지 않습니다.

 

4개월 계획에 6개월 완성, 1년 내 오픈이면 성공입니다

일반적인 스타트업의 초기 앱 서비스 제작 기간은 4개월을 계획하고 6개월 내에 완성하며, 1년 안에 오픈하면 잘한 것입니다. 이것이 현실입니다.

많은 창업자가 "3개월이면 되겠지"라고 생각하지만, 실제로 3개월 만에 완성되는 경우는 거의 없습니다. 기획 변경, 디자인 수정, 개발 중 발견되는 문제들로 인해 일정은 늘어나는 일정 외 정상 속도로 작업을 진행하는데도 작업양을 잘못 추측하거나 지나치게 타이트한 일정 제시로 실제 일정만큼 늘어나는 경우도 있습니다.

1년 안에 서비스를 오픈했다면 잘한 것입니다. 일정을 너무 촉박하게 잡으면 품질이 낮아지거나, 중요한 기능이 빠진 채로 출시하게 됩니다. 여유 있는 일정 계획이 오히려 좋은 결과를 만듭니다.

 

파트별 작업 기간의 기본 구조

외주 프로젝트의 기본 일정은 다음과 같이 잡습니다:

서비스 기획: 2개월 요구사항 정리, 화면 구조 설계, 기능 명세, 스토리보드 작성까지 포함하면 2개월은 필요합니다. 창업자가 아이디어만 갖고 있는 상태에서 디자인, 개발을 위한 서비스 기획 완료까지 걸리는 기간입니다.

디자인: 1.5개월 시안 작업, 피드백 반영, 전체 화면 디자인 완성까지 1.5개월 정도 소요됩니다. 디자인 시안은 몇 주 내에 확정되지만 디자인이 마음에 들지 않아 시안 확정이 늦어지면 그 만큼 일정은 지연됩니다. 시안에 2주, 페이지 디자인에 4주(1개월)이 걸립니다. 디자인 해야 하는 페이지가 많은 경우 1개월 이상 걸리기도 합니다.

개발: 2.5개월 기본 기능 구현에 2.5개월이 걸립니다. 2.5개월은 혼자 작업하기에 빠듯한 일정입니다. 복잡한 기능이 많거나 외부 API 연동이 필요하면 2-3개월이 필요할 수 있습니다. 개발자를 두 배, 세 배로 늘린다고 일정이 단축되지는 않습니다. 개발 작업에는 병렬 처리가 가능한 것과 그렇지 않은 것으로 나뉩니다.

테스트: 2주 기능 테스트, 버그 수정, 최종 점검에 최소 2주는 필요합니다. 테스트는 한 번의 결과와 수정으로 끝나지 않습니다. 수정 작업 후 잘 작동하던 기능이 안 되는 경우도 발생하므로 테스트 결과인 리포트를 작성해 디자인과 개발에 반영 후 수정이 완료 되었는지 다시 검수합니다.

모든 서비스가 정상 작동할 때 까지 테스트를 반복합니다.

 

작업 간 중복 기간이 있어도 전체는 더 걸립니다

각 단계가 완전히 순차적으로 진행되는 것은 아닙니다. 디자인이 일부 완성되면 개발을 시작할 수 있습니다. 이런 중복 기간이 있어 전체 기간을 조금 단축할 수 있어 보여도 전체 기간 중 발생하는 예측 불가능한 일, 지연 사유 때문에 항상 실제 일정은 계획보다 더 걸립니다.

 

IT 프로젝트는 1.5배 이상 지연이 일반적입니다

IT 프로젝트는 일정보다 1.5배 이상 지연되는 것이 일반적입니다. 이것은 외주사가 무능해서가 아니라, IT 프로젝트의 특성 때문입니다.

개발 중에 예상하지 못한 기술적 문제가 생기거나, 기획 단계에서 고려하지 못한 상황이 발견되거나, 외부 서비스 연동에서 어려움이 생기는 일이 흔합니다. 디자인 피드백도 예상보다 오래 걸리고, 테스트 중 발견된 버그 수정도 시간이 필요합니다.

4개월 일정이라면 6개월, 6개월 일정이라면 9개월 정도로 여유 있게 계획하는 것이 현실적입니다. 외주사가 "확실히 이 일정 내에 완료됩니다"라고 말해도, 1.5배 정도는 늘어날 수 있다고 생각해야 합니다.

 

턴키 계약은 일정 압박이 더 심합니다

턴키 계약은 기획, 디자인, 개발을 한 업체가 모두 맡는 방식입니다. 편리해 보이지만, 일정 관리 측면에서는 위험합니다.

기획이 늦어지면 디자인 시작이 늦어지고, 디자인이 늦어지면 개발 기간이 줄어듭니다. 앞선 작업의 지연이 후순위 작업에 압박으로 작용합니다. 전체 마감일은 정해져 있는데, 앞에서 시간을 다 써버리면 뒤에서 쫓기게 됩니다.

일정을 맞추려다 보면 품질이 낮아지거나 기능이 빠질 수 있습니다. "이 기능은 나중에 추가하기로 하죠", "일단 이렇게 만들고 나중에 수정하죠" 같은 말이 나오기 시작하면, 결국 제대로 완성되지 않은 서비스가 나옵니다.

더 문제는 숨은 기능이 생길 수 있다는 점입니다. 기획서에는 있는데 실제로는 개발하지 않은 기능들이 있을 수 있습니다. 일정에 쫓기다 보면 "이 정도면 되겠지" 하고 넘어가는 부분이 생깁니다.

 

대기업 프로젝트도 완벽하게 끝나지 않습니다

대기업이나 대규모 IT 프로젝트도 3-6개월 일정으로 기획, 디자인, 개발을 진행합니다. 예산도 크고 인력도 많지만, 그래도 기간 내에 완벽하게 완료하지 못하는 경우가 많습니다.

보통 서비스 오픈 가능한 수준까지만 만들고 일단 출시합니다. 그리고 운영 기간 1년 내 미완성 부분을 개발 완료합니다. "1차 오픈", "2차 고도화" 같은 용어를 쓰는 것도 이 때문입니다.

스타트업은 대기업만큼 자원이 많지 않습니다. 그런데 대기업도 제대로 못 끝내는 일정을 스타트업이 칼같이 맞추기를 기대하는 것은 비현실적입니다.

 

현실적인 일정 계획을 세우세요

외주 업체가 제시한 일정에 1.5배를 곱하세요. 4개월이라고 하면 6개월, 6개월이라고 하면 9개월로 계획하세요. 이렇게 여유를 두면 실제 완성 시점에 맞춰 다른 준비(마케팅, 운영 계획 등)를 할 수 있습니다.

출시 목표일이 있다면 거꾸로 계산하세요. 1년 후 출시가 목표라면, 지금부터 시작해야 합니다. 6개월 후 출시가 목표라면, 솔직히 말해 매우 촉박합니다. 핵심 기능만 포함한 최소 버전(MVP)으로 범위를 줄여야 가능합니다.

 

단계별로 계약하면 일정 관리가 쉽습니다

기획, 디자인, 개발을 별도로 계약하면 각 단계의 일정을 더 잘 관리할 수 있습니다. 기획이 완성된 후 디자인을 시작하고, 디자인이 완성된 후 개발을 시작하면, 앞 단계의 지연이 뒤 단계의 품질에 영향을 주지 않습니다.

각 단계마다 충분한 시간을 주고, 제대로 완성된 것을 확인한 후 다음 단계로 넘어가세요. 급하게 진행하다가 품질이 낮아지는 것보다, 조금 늦더라도 제대로 만드는 것이 결과적으로 더 빠릅니다.

 

일정보다 품질이 중요합니다

일정을 맞추는 것보다 제대로 작동하는 서비스를 만드는 것이 더 중요합니다. 일정에 쫓겨 급하게 만든 서비스는 출시 후 문제가 계속 생기고, 결국 다시 만들어야 할 수도 있습니다.

"일정이 조금 늦어지더라도 제대로 만들어주세요"라고 말하는 것이 "무조건 이 날짜까지 완성하세요"보다 좋은 결과를 만듭니다. 물론 일정을 무한정 늘려서는 안 되지만, 합리적인 범위 내에서 품질을 우선하는 것이 현명합니다.

출시가 조금 늦어지는 것보다, 출시 후 서비스가 제대로 작동하지 않아 사용자들이 떠나는 것이 훨씬 큰 문제입니다.