소프트웨어 개발 프로젝트의 일정산정, FP, 간트차트, WBS샘플
프로젝트 일정은 견적서의 숫자가 아니라, 실행계획 그 자체입니다. 특히 소프트웨어 개발에서는 일정산정의 정확도가 프로젝트 품질과 직결되죠. 이 글에서는 Function Point(FP) 기법, 간트차트 활용법, 그리고 실전 WBS 샘플까지 실제로 써먹을 수 있는 일정관리 전략을 공유합니다. 수학처럼 정밀하되, 현장감 있는 일정산정 이야기를 시작해볼까요?
목차
Function Point란 무엇인가?
Function Point(FP)는 소프트웨어의 크기를 기능 중심으로 측정하는 방법입니다. 개발할 기능의 수와 복잡도를 기준으로 시스템의 규모를 산출하며, 이 크기를 기반으로 인력·시간·비용을 추정합니다. LOC(Line of Code) 기반 방식보다 기술 독립적이며, 초기 요구사항 단계에서도 사용 가능하다는 장점이 있습니다.
FP 기반 일정산정 실전 적용
FP 기반 일정산정은 다음과 같은 절차로 진행됩니다: 기능점수 계산 → 보정 계수 적용 → 생산성 기준 반영. 예를 들어, FP 300 규모의 시스템이라면 생산성 10FP/월 기준으로 30개월 M/M(man-month)이 산출됩니다. 여기에 난이도, 기술숙련도, 유사 프로젝트 이력 등을 반영해 현실적인 일정을 재조정합니다.
| 항목 | 예시 값 | 비고 |
|---|---|---|
| 기능점수 | 300 FP | 중대형 웹시스템 기준 |
| 생산성 | 10 FP/M/M | 조직 평균치 |
| 예상 일정 | 30 M/M | 보정 전 기준 |
간트차트로 흐름을 시각화하다
간트차트(Gantt Chart)는 일정과 자원의 배분을 한눈에 볼 수 있는 대표적 도구입니다. 작업 단위를 가로축에 시간 순으로 배열하고, 각 Task 간의 종속관계를 표현할 수 있죠. 특히 병렬 작업과 병목구간을 식별하는 데 효과적입니다. MS Project, Notion Timeline, Excel 등 다양한 도구로 구현 가능합니다.
- 주요 마일스톤 정의 (계약, 설계완료, 개발완료, 테스트종료 등)
- 작업 간 의존성(Dependency) 명시
- 병렬 가능 Task와 직렬 Task 구분
WBS 구조 이해와 핵심 포인트
WBS(Work Breakdown Structure)는 프로젝트를 체계적으로 쪼개어 계층 구조로 정리한 도표입니다. ‘할 일’ 목록이 아니라 ‘작업 단위’ 중심이라는 점이 핵심입니다. WBS가 잘 설계되어야 일정산정과 책임 배분이 가능하며, 이후 간트차트나 산정도 이 위에 얹히게 됩니다.
- 작업은 산출물 기준으로 정의한다 (ex. 설계서 작성, API 개발)
- 모든 작업은 시작일, 종료일, 책임자 포함
- Task별 리소스 추정과 의존성 명시
WBS 샘플로 보는 일정 구성
| WBS ID | 작업 항목 | 예상 기간 | 담당 |
|---|---|---|---|
| 1.1 | 요구사항 수집 및 명세 | 5일 | BA |
| 1.2 | 설계서 작성 | 7일 | SA |
| 1.3 | 화면 개발 | 10일 | FE |
| 1.4 | API 개발 및 연동 | 15일 | BE |
| 1.5 | 통합 테스트 | 5일 | QA |
일정산정을 위한 체크리스트
- 일정산정 기준이 ‘유사 이력’ 또는 ‘FP 분석’ 기반인가?
- 간트차트에 의존성과 병렬성을 명확히 반영했는가?
- WBS는 ‘산출물 중심’으로 분해되어 있는가?
- 작업 단위별 책임자와 시작/종료일이 명확한가?
- QA 및 버퍼 일정이 따로 확보되어 있는가?
기능 중심의 정형화된 시스템일수록 FP 방식이 효과적입니다. 반면 창의적 UI나 유동적 요구사항 중심 프로젝트에선 부적합할 수 있습니다.
업무 시스템, 관리계열 프로젝트에선 FP가 일정 예측에 매우 효과적입니다.
간트차트의 ‘길게 이어진 직렬 작업 구간’은 병목 가능성이 높습니다. 특히 QA, 검수 등의 자원 공유 Task는 주의가 필요합니다.
자원이 하나인데 다건 작업이 몰린다면 반드시 병목이 생깁니다.
필수는 아니지만, 표 형식이 가장 직관적이고 범용적입니다. 트리 구조, 마인드맵 형태로도 표현 가능합니다.
중요한 건 작업 간 구조와 책임, 일정을 명확히 표현하는 것이죠.
WBS에서 ‘QA’는 별도 단계로 분리하고, 테스트 리소스 기준으로 M/M 산정하여 포함시켜야 합니다.
‘남은 시간으로 QA’라는 방식은 실패한 일정의 전형입니다.
정량적 분석에 유리하지만, 주관적 판단이 개입될 수 있고, UI/UX 요소 등 정성적 요소 반영이 어렵다는 점이 단점입니다.
화면 중심 프로젝트, UI 혁신 시스템에는 주의가 필요합니다.
프로젝트 일정산정은 단순한 시간 계산이 아니라, ‘실행 가능성’에 대한 예측이자 선언입니다. FP 방식은 구조적인 접근을 제공하고, 간트차트와 WBS는 흐름과 작업의 실체를 드러내 줍니다. 결국 일정산정의 핵심은 도구가 아니라, 그 도구를 통해 어떤 현실을 예측하고 반영하는가에 달려 있습니다. 이 글이 여러분의 일정관리 실무에 작은 기준점이 되길 바랍니다.
FP, 간트차트, WBS샘플, 일정산정, 소프트웨어일정, 프로젝트관리, 작업분해구조, 일정리스크, 산정기법, 품질기반일정