개발 기간은 어떻게 계산하고 왜 자꾸 밀릴까요 | 일정 산정 기준 정리
IT 프로젝트의 절반 가까이가 예산과 일정을 넘겨 완료되고, 지연의 상당수는 요구사항 변경에서 시작된다는 조사 결과가 있어요. 기능점수·공수 기반 기간 산정 방식과 착수 전 확인해야 할 지연 신호를 운영해본 개발사 기준으로 정리했어요.
개발 기간은 대개 “기능 개수”가 아니라 “복잡도·투입 인력·검수 절차”로 계산돼요. 착수 전 견적서에 적힌 일정이 실제로 밀리는 이유는 대부분 요구사항 변경, 외부 연동사 일정, 검수 기준 미확정처럼 계약 밖 변수예요. 한국소프트웨어산업협회(KOSA)의 기간 산정 가이드도 기능점수(FP)·투입 인력·복잡도 계수를 함께 봐요. 직접 만들고 운영해본 개발사 기준으로, 기간을 계산하는 방법과 지연을 줄이는 법을 정리했어요.
“분명 8주라고 들었는데 왜 벌써 4개월째 진행 중이죠?” 개발 외주를 맡겨본 발주자라면 한 번쯤 들어본 질문이에요. 견적서에 적힌 기간과 실제 완료 시점 사이의 간극은 예산 초과보다 체감상 더 크게 느껴지곤 해요. 마케팅 일정, 투자 라운드, 다른 팀의 후속 작업까지 줄줄이 밀리기 때문이에요.
1. 개발 기간, 왜 항상 처음 말한 것보다 늦어질까요
해외 IT 프로젝트 리서치기관 스탠디시 그룹(Standish Group)이 수만 건의 프로젝트를 분석한 카오스 리포트에 따르면, 정해진 일정·예산·범위를 모두 지킨 ‘완전 성공’ 프로젝트는 31%에 그치고, 절반 가까이(약 50%)는 예산이나 일정을 초과해 완료돼요. 국내 상황을 그대로 대입하긴 어렵지만, 저희가 11년 넘게 프로젝트를 진행하며 체감한 흐름과도 크게 다르지 않아요. 일정이 밀리는 이유는 대부분 “개발자가 느려서”가 아니라 착수 시점에 확정되지 않은 변수 때문이에요.
2. 개발 기간은 어떤 기준으로 계산할까요
기간 산정 방식은 크게 두 갈래예요.
- 기능점수(FP, Function Point) 기반: 화면·기능의 개수와 복잡도를 정량화한 뒤, 표준 생산성 지표로 나눠 기간을 추정해요. KOSA의 소프트웨어 사업기간 산정 가이드가 이 방식을 기준으로 삼아요.
- 공수(맨먼스) 기반: 필요한 인력 등급과 투입 기간(M/M)을 먼저 정하고, 병렬로 투입 가능한 인원 수로 전체 기간을 나눠요.
실무에서는 두 방식을 섞어서 써요. 기능점수로 전체 규모를 가늠하고, 실제 투입 가능한 인력 구조에 맞춰 공수 기준으로 일정을 다시 짜는 식이에요. 애자일 방식으로 진행하는 프로젝트라면 스토리포인트(작업 난이도를 상대적으로 점수화한 단위)로 스프린트별 완료량을 추적하면서 기간을 조정하기도 해요.
3. 프로젝트 유형별로 기간은 얼마나 차이 날까요
공식 기준 — 유형별 개발 기간 범위(기획~검수, 공개 시장 자료 종합·추정)
| 유형 | 기간 |
|---|---|
| 단순 웹사이트 | 2～6주 |
| 중소기업 홈페이지 | 3～8주 |
| 쇼핑몰 구축 | 1～6개월 |
| 단순 모바일 앱 | 6～10주 |
| 커머스·예약 앱 | 3～5개월 |
| 플랫폼·실시간 시스템 | 4～6개월 이상 |
프로젝트 조건(연동 수, 디자인 커스터마이징 정도, 조직 형태)에 따라 범위 안에서도 크게 갈려요. 같은 ‘쇼핑몰’이라도 결제·배송 연동이 몇 개인지에 따라 1개월 이상 차이가 나기도 해요.
4. 일정이 밀리는 진짜 원인은 무엇일까요
업계에서 공통으로 꼽는 지연 원인은 크게 세 가지예요.
- 스코프 크리프(scope creep, 범위의 점진적 확장) — 처음 정의한 범위에 “이것도 조금만 추가해주세요”가 쌓이는 현상이에요. 하나하나는 작아 보여도 누적되면 전체 일정을 크게 밀어요.
- 요구사항 변경 절차 부재 — 변경 자체가 문제가 아니라, 변경이 일정·비용에 미치는 영향을 확인하지 않고 그냥 반영하는 게 문제예요.
- 외부 변수 — 결제·인증 등 외부 연동사의 심사·승인 기간, 클라이언트 측 의사결정 지연도 발주자 통제 밖에서 일정을 늦춰요. 실제로 해외 대형 시스템 전환 프로젝트 사례에서도 지연 원인 상당수가 범위 확대와 거버넌스(의사결정 구조) 부실로 꼽혀요.
같은 원인이 실무에서는 이런 모습으로 반복돼요.
- QA·버퍼를 견적 기간에 아예 넣지 않는 경우: “개발 8주”에 테스트·수정 기간이 빠져 있으면 실제로는 더 걸려요.
- 변경 요청을 ‘간단한 수정’으로 여기는 경우: 절차 없이 반영되는 요청이 쌓이면 스코프 크리프로 이어져요.
- 외부 연동사 승인 기간을 자체 일정에 포함하지 않는 경우: 결제대행사 심사 등은 발주자·개발사 모두 통제하기 어려운 변수예요.
5. 자주 헷갈리는 용어부터 정리해볼까요
스코프 크리프는 계약 범위 밖 요청이 승인 절차 없이 조금씩 반영되며 일정이 늘어나는 현상이에요. 마일스톤은 프로젝트 중간에 산출물을 확인하는 시점이고요. 기능점수(FP)는 화면·데이터·연동의 복잡도를 표준 단위로 환산한 규모 지표예요. 실무에선 “마일스톤마다 스코프 크리프가 없는지 확인하고, 있다면 기능점수 기준으로 재견적한다”는 흐름으로 이 세 개념을 함께 써요.
6. 착수 전에 무엇을 확인해두면 지연을 줄일 수 있을까요
자사 실무 기준 — 착수 전 점검 체크리스트
| 확인 항목 | 왜 확인하나요 |
|---|---|
| 요구사항 정의서 확정 여부 | 확정 전 착수하면 설계 단계에서 재작업이 반복돼요 |
| 마일스톤별 산출물 정의 | 무엇을 언제까지 볼 수 있는지 합의해야 지연을 빨리 알아챌 수 있어요 |
| 외부 연동사 일정 확인 | 결제·인증 등 외부사 대응 속도는 우리 통제 밖 지연 요인이 돼요 |
| 검수 기준·기간 명시 | ”○일 내 미통보 시 검수완료” 조항이 없으면 검수 단계가 늘어져요 |
| 변경 요청 처리 절차 | 절차가 없으면 스코프 크리프가 조용히 쌓여요 |
운영사 Tip — 저희는 착수 전에 “일정에 이미 반영된 버퍼(예비 기간)가 며칠인지”를 먼저 물어봐요. 버퍼 없이 딱 맞춘 일정은 작은 변수 하나에도 전체가 밀리거든요. 자체 SaaS 4종을 운영하며 배운 건, 빠듯한 일정보다 변수를 흡수할 여유가 있는 일정이 결과적으로 더 빨리 끝난다는 점이었어요.
7. 운영까지 보면 일정 계산이 왜 달라질까요
실시간 시스템은 오픈이 끝이 아니라 시작이라, 배포 후 조정 단계까지 처음부터 일정에 넣어야 해요. 저희는 출시일 자체보다 출시 후 2～4주 안정화 기간(초기 트래픽 대응, 버그 픽스, 운영 데이터 기반 튜닝)을 일정에 포함했는지를 더 중요하게 봐요(자사 실무 기준, 시스템 성격에 따라 차이가 있어요). 이 기간을 빼고 “개발 완료일 = 실제 이용 가능일”로 계산하면 십중팔구 다시 밀려요.
8. 자주 묻는 질문
기간 산정에서 가장 먼저 확정해야 하는 건 무엇인가요?
요구사항 정의서예요. 범위가 확정되지 않은 상태에서 잡힌 기간은 실제 착수 후 재조정될 가능성이 커요.
요구사항이 프로젝트 도중 바뀌면 일정은 어떻게 조정하나요?
변경 요청이 일정·비용에 미치는 영향을 먼저 확인하고, 계약서에 정의된 변경 처리 절차에 따라 재견적·재일정을 합의하는 방식이 안전해요.
스토리포인트 방식과 기능점수(FP) 방식, 어떤 걸 써야 하나요?
애자일 방식으로 짧은 주기(스프린트)로 진행한다면 스토리포인트가 진행 상황을 추적하기 편해요. 공공·SI개발처럼 계약 단계에서 규모를 정량화해야 한다면 기능점수(FP) 방식이 더 흔히 쓰여요.
9. 정리하며
저희는 같은 기능 수보다, 출시 후 얼마나 자주 수정될지부터 봐요. 개발 기간을 볼 때도 마찬가지예요. 견적서에 적힌 숫자보다, 그 숫자 안에 버퍼와 검수 기준이 들어 있는지를 먼저 확인해요. 11년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 경험에서 나온 기준이에요.
관련해서 함께 보면 좋은 글이에요.
일정이 늘어지는 게 가장 걱정이시라면, 착수 전에 일정 리스크를 함께 점검해볼 수 있어요 → 저희는 10년 이상 50개가 넘는 프로젝트를 진행하며 자체 SaaS 4종을 직접 운영해온 개발사예요. 지연이 어디서 생기는지 겪어본 쪽에서 답해드려요.