IT 프로젝트 공수 산정 2025 완벽 가이드: 체계적 접근법과 최신 동향(AI영향 반영)

오늘은 IT 프로젝트의 공수 산정하는 방법에 대해서 알아보고자 합니다.

 

 

 

 

핵심 요약: 2025년 현재, AI 도구의 본격 도입과 DevOps 성숙도 지표의 중요성이 증대되면서 기존 공수 산정 방식에 변화가 필요합니다. 본 가이드에서는 불확실성을 체계적으로 관리하고 정확도를 높이는 현대적 접근법을 제시합니다.

---

서론: 공수 산정의 본질적 어려움

IT 프로젝트에서 정확한 공수 산정은 여전히 가장 도전적인 과제 중 하나입니다. 이는 개발자의 역량 부족이 아닌, 불확실성의 원뿔(Cone of Uncertainty) 현상에 기인합니다.

프로젝트 초기에는 요구사항의 모호성으로 인해 추정 오차가 클 수밖에 없으며, 진행 과정에서 점진적으로 정확도가 향상됩니다. 따라서 초기에는 범위 추정을, 진행 중에는 정밀화하는 접근이 필요합니다.

---

2025년 공수 산정 환경의 변화

AI 도구의 영향력 증대

생성형 AI와 코딩 어시스턴트의 도입이 개발 생산성에 실질적 변화를 가져오고 있습니다. 연구 결과에 따르면 특정 작업 영역에서 최대 55%의 완료 시간 단축이 관찰되었으나, 모든 개발 활동에 동일하게 적용되지는 않습니다.

반복적 코드 작성과 보일러플레이트 생성에서는 상당한 효율성 향상이 있는 반면, 복잡한 설계나 도메인 전문 지식이 요구되는 작업에서는 제한적입니다.

DORA 지표와 DevOps 성숙도

**DORA(DevOps Research and Assessment)**는 Google Cloud의 DevOps 연구팀에서 개발한 소프트웨어 개발 및 배포 성과 측정 프레임워크입니다. 2023년 업데이트된 DORA 지표는 다음 5가지 핵심 메트릭으로 구성됩니다:

1. 배포 빈도 (Deployment Frequency)

• 정의: 조직이 프로덕션에 성공적으로 릴리스하는 빈도
• 측정: 일일, 주간, 월간 배포 횟수
• 공수 산정 영향: 높은 배포 빈도는 작은 단위의 개발과 빠른 피드백을 의미하여 리스크 감소

2. 리드 타임 (Lead Time for Changes)

• 정의: 코드 커밋부터 프로덕션 배포까지의 소요 시간
• 측정: 시간, 일, 주 단위
• 공수 산정 영향: 짧은 리드 타임은 효율적인 개발 프로세스를 의미하여 전체 개발 기간 단축

3. 변경 실패율 (Change Failure Rate)

• 정의: 프로덕션에서 장애나 롤백이 필요한 배포의 비율
• 측정: 실패한 배포 수 / 전체 배포 수 × 100
• 공수 산정 영향: 낮은 실패율은 품질이 높은 개발 프로세스를 의미하여 버그 수정 공수 감소

4. 복구 시간 (Mean Time to Recovery, MTTR)

• 정의: 장애 발생부터 서비스 복구까지의 평균 시간
• 측정: 분, 시간, 일 단위
• 공수 산정 영향: 빠른 복구는 안정적인 운영을 의미하여 유지보수 공수 절약

5. 신뢰성 (Reliability)

• 정의: 서비스가 사용자 요구를 충족하는 정도
• 측정: 가용성, 성능, 정확성 등의 복합 지표
• 공수 산정 영향: 높은 신뢰성은 시스템 안정성을 의미하여 장애 대응 공수 최소화

DORA 지표의 공수 산정 활용 방법

팀 성숙도별 공수 보정 계수

Elite 팀 (상위 20%):
- 배포 빈도: 주문형(On-demand), 하루 여러 번
- 리드 타임: 1시간 미만
- 변경 실패율: 0-15%
- 복구 시간: 1시간 미만
→ 개발 공수 10-15% 절약 가능

High 팀 (상위 20-50%):
- 배포 빈도: 주 1회 - 월 1회
- 리드 타임: 1일 - 1주
- 변경 실패율: 0-15%
- 복구 시간: 1일 미만
→ 개발 공수 5-10% 절약 가능

Medium 팀 (중위 50-80%):
- 배포 빈도: 월 1회 - 6개월 1회
- 리드 타임: 1주 - 1개월
- 변경 실패율: 16-30%
- 복구 시간: 1일 - 1주
→ 기준 공수 적용

Low 팀 (하위 20%):
- 배포 빈도: 6개월 1회 미만
- 리드 타임: 1개월 - 6개월
- 변경 실패율: 16-30%
- 복구 시간: 1주 - 1개월
→ 개발 공수 15-25% 추가 필요

이러한 DORA 지표 기반 평가를 통해 팀의 DevOps 성숙도를 객관적으로 측정하고, 이를 공수 산정에 반영함으로써 보다 정확한 예측이 가능합니다.

하이브리드 근무 환경의 정착

원격 및 하이브리드 근무 환경의 일반화로 포커스 팩터(실제 업무 집중 가능 시간 비율)에 대한 재평가가 필요해졌습니다.

---

공수 산정 방법론의 통합적 활용

효과적인 공수 산정을 위해서는 단일 방법론이 아닌 상황에 맞는 복합적 접근이 필요합니다. 각 방법론의 특성과 적용 시나리오를 상세히 살펴보겠습니다.

1. 유사치 기반 추정 (Analogical Estimation)

과거 수행한 유사 프로젝트의 데이터를 기반으로 하는 방법입니다.

적용 원리

• 과거 프로젝트와의 유사성 분석
• 차이점에 대한 보정 계수 적용
• 조직 내 축적된 프로젝트 데이터베이스 활용

구체적 적용 방법

1단계: 유사 프로젝트 식별
- 기능적 유사성: 비슷한 비즈니스 도메인, 사용자 유형
- 기술적 유사성: 동일/유사한 기술 스택, 아키텍처 패턴
- 규모적 유사성: 팀 크기, 프로젝트 기간, 예산 규모

2단계: 차이점 분석 및 보정
- 기능 복잡도 차이: +/-10-30%
- 기술 스택 변경: +/-15-40%
- 팀 경험도 차이: +/-20-50%
- 외부 제약사항: +/-10-25%

3단계: 보정 계수 적용
기준 프로젝트: 500MD
+ 기능 복잡도 증가: +20% = +100MD
+ 새로운 기술 스택: +25% = +125MD
- 팀 경험도 향상: -15% = -75MD
= 최종 추정: 650MD

적용 시점:

• 초기 견적 단계 (RFP 응답, 예산 수립)
• 요구사항이 구체화되기 전
• 빠른 의사결정이 필요한 상황

장점:

• 신속한 추정 가능
• 조직의 실제 경험 반영
• 직관적 이해와 설명 용이

단점 및 주의사항:

• 표면적 유사성에 의존한 오판 위험
• 숨겨진 복잡도 간과 가능성
• 과거 데이터의 정확성에 의존

실제 적용 예시

기준 프로젝트: 전자상거래 B2C 웹사이트 (800MD)
신규 프로젝트: 전자상거래 B2B 플랫폼

차이점 분석:
- B2B 특화 기능 (견적, 승인 워크플로): +30%
- 복잡한 권한 관리: +20%
- 기존 ERP 연동: +25%
- 팀의 B2B 도메인 경험: -10%

계산: 800MD × (1 + 0.3 + 0.2 + 0.25 - 0.1) = 800MD × 1.65 = 1,320MD

2. 상향식 추정 (Bottom-up Estimation)

작업분해구조(WBS)를 통해 세부 작업을 식별하고 합산하는 방법입니다.

적용 원리

• 프로젝트를 최소 작업 단위로 분해
• 각 작업별 개별 추정
• 상위 레벨로 집계하여 전체 추정치 도출

상세 적용 프로세스

1단계: 작업분해구조(WBS) 작성
레벨 1: 주요 기능/모듈
├─ 레벨 2: 세부 기능
│   ├─ 레벨 3: 개발 작업
│   ├─ 레벨 3: 테스트 작업
│   └─ 레벨 3: 문서화 작업

2단계: 최하위 작업 단위 추정
- 8-80시간 규칙: 하나의 작업은 8-80시간 범위
- 3점 추정법 활용: (낙관적 + 4×현실적 + 비관적) ÷ 6
- 담당자별 개별 추정 후 검토

3단계: 상위 레벨 집계
- 직접 합산
- 통합 및 조정 작업 추가
- 관리 오버헤드 반영

3점 추정법 상세 예시

작업: 사용자 인증 API 개발

개발자 A의 추정:
- 낙관적 시나리오 (모든 것이 순조로울 때): 16시간
- 현실적 시나리오 (일반적인 경우): 24시간  
- 비관적 시나리오 (예상치 못한 문제 발생): 40시간

계산: (16 + 4×24 + 40) ÷ 6 = (16 + 96 + 40) ÷ 6 = 25.3시간

표준편차: (40 - 16) ÷ 6 = 4시간
→ 68% 확률로 21.3-29.3시간 범위 내 완료

적용 시점:

• 요구사항이 상당 부분 명확해진 단계
• 정확한 산정이 요구되는 계약/승인 단계
• 팀원들과 함께 상세 계획 수립 시

장점:

• 높은 정확도
• 누락 작업 식별 용이
• 팀 전체의 합의 기반
• 진척 관리 기준 제공

단점:

• 상당한 시간과 노력 필요
• 초기 단계 적용 어려움
• 과도한 세분화로 인한 복잡성

실제 WBS 예시

1. 사용자 관리 모듈 (120시간)
   1.1 사용자 등록 (40시간)
       1.1.1 회원가입 UI 개발 (16시간)
       1.1.2 이메일 인증 API (12시간)
       1.1.3 입력 검증 로직 (8시간)
       1.1.4 단위 테스트 (4시간)
   1.2 사용자 인증 (50시간)
       1.2.1 로그인 API (20시간)
       1.2.2 JWT 토큰 관리 (15시간)
       1.2.3 권한 검증 미들웨어 (10시간)
       1.2.4 보안 테스트 (5시간)
   1.3 프로필 관리 (30시간)
       1.3.1 프로필 조회/수정 API (20시간)
       1.3.2 프로필 이미지 업로드 (10시간)

3. 상대적 추정 (Relative Estimation)

스토리 포인트와 같은 상대적 복잡도를 기반으로 하는 애자일 추정 방법입니다.

적용 원리

• 절대적 시간이 아닌 상대적 난이도 측정
• 팀의 과거 경험을 기반으로 한 벤치마크 설정
• 불확실성과 복잡도를 종합적으로 고려

스토리 포인트 산정 기준

고려 요소:
1. 복잡도 (Complexity): 기술적 난이도, 비즈니스 로직 복잡성
2. 불확실성 (Uncertainty): 요구사항 모호성, 기술적 위험
3. 노력 (Effort): 예상 작업량, 필요 기능 범위

포인트 척도 (피보나치 수열 활용):
- 1포인트: 매우 간단 (1-2시간, 개발자 혼자 쉽게 완료)
- 2포인트: 간단 (반나절, 약간의 조사 필요)
- 3포인트: 보통 (1일, 표준적인 구현)
- 5포인트: 복잡 (2-3일, 여러 컴포넌트 연동)
- 8포인트: 매우 복잡 (1주, 새로운 기술이나 복잡한 로직)
- 13포인트: 극도로 복잡 (2주 이상, 분할 검토 필요)

플래닝 포커 진행 방법

1단계: 기준 스토리 설정
- 팀이 과거에 완료한 스토리 중 3-5포인트 선정
- 모든 팀원이 동의하는 명확한 기준점 설정

2단계: 개별 추정
- 각 팀원이 독립적으로 카드 선택
- 토론 없이 동시에 공개

3단계: 차이점 논의
- 최고/최저 추정자가 근거 설명
- 숨겨진 복잡도나 가정 사항 발견
- 필요시 요구사항 명확화

4단계: 재추정 및 합의
- 논의 후 다시 개별 추정
- 합의에 도달할 때까지 반복
- 일반적으로 2-3라운드면 수렴

속도(Velocity) 계산 및 활용

속도 계산 예시:
Sprint 1: 완료된 스토리 포인트 = 28pt
Sprint 2: 완료된 스토리 포인트 = 32pt
Sprint 3: 완료된 스토리 포인트 = 30pt
Sprint 4: 완료된 스토리 포인트 = 26pt (휴가 영향)

평균 속도 = (28 + 32 + 30 + 26) ÷ 4 = 29pt/sprint

프로젝트 계획:
총 백로그: 290 스토리 포인트
예상 완료: 290pt ÷ 29pt/sprint = 10 스프린트

적용 시점:

• 반복적 개발 환경 (스크럼, 칸반)
• 팀의 속도 데이터가 축적된 후
• 중장기 릴리스 계획 수립 시

장점:

• 팀 합의 기반의 추정
• 추정 편향 완화
• 지속적인 학습과 개선
• 변화하는 요구사항에 유연한 대응

단점:

• 초기 속도 안정화까지 시간 필요
• 팀 구성 변경 시 재조정 필요
• 외부 이해관계자 설명 어려움

4. 모수적 추정 (Parametric Estimation)

수학적 모델을 활용한 정량적 접근법입니다.

COCOMO (COnstructive COst MOdel) 활용

기본 COCOMO 공식:
노력(MM) = a × (KLOC)^b

여기서:
- MM: Man-Months (인월)
- KLOC: Kilo Lines of Code (천 줄 코드)
- a, b: 프로젝트 유형별 계수

프로젝트 유형별 계수:
1. 단순형 (Simple): a=2.4, b=1.05
2. 중간형 (Semi-detached): a=3.0, b=1.12  
3. 복잡형 (Embedded): a=3.6, b=1.20

COCOMO III (2025년 업데이트) 적용 예시

프로젝트: 온라인 뱅킹 시스템
예상 규모: 50 KLOC
프로젝트 유형: 복잡형 (보안 중요)

1단계: 기본 추정
기본 노력 = 3.6 × (50)^1.20 = 3.6 × 82.8 = 298 MM

2단계: 비용 구동 인자 적용
- 제품 신뢰성 (RELY): 1.26 (매우 높음)
- 데이터베이스 크기 (DATA): 1.14 (큼)
- 제품 복잡성 (CPLX): 1.17 (높음)
- 실행 시간 제약 (TIME): 1.11 (높음)
- 보안 요구사항 (SECU): 1.30 (매우 높음, COCOMO III 신규)
- 애널리스트 역량 (ACAP): 0.85 (높음)
- 프로그래머 역량 (PCAP): 0.88 (높음)

조정된 노력 = 298 × 1.26 × 1.14 × 1.17 × 1.11 × 1.30 × 0.85 × 0.88
= 298 × 1.67 = 497 MM

기능점수법 (Function Point) 활용

IFPUG 기능점수 계산:

1단계: 기능 유형별 개수 산정
- 외부 입력 (EI): 25개 × 가중치 4 = 100점
- 외부 출력 (EO): 15개 × 가중치 5 = 75점  
- 외부 조회 (EQ): 20개 × 가중치 4 = 80점
- 내부 논리 파일 (ILF): 8개 × 가중치 10 = 80점
- 외부 인터페이스 파일 (EIF): 5개 × 가중치 7 = 35점
미조정 기능점수 (UFP) = 370점

2단계: 복잡도 조정 인자 적용
시스템 특성 평가 (14개 항목, 0-5점):
- 데이터 통신: 4점
- 분산 데이터 처리: 3점
- 성능: 5점
- 높은 이용도: 4점
- 트랜잭션 비율: 4점
- 온라인 데이터 입력: 5점
- 최종 사용자 효율성: 4점
- 온라인 업데이트: 5점
- 복잡한 처리: 3점
- 재사용성: 3점
- 설치 용이성: 2점
- 운영 용이성: 3점
- 다중 사이트: 2점
- 변경 용이성: 3점

총점: 50점
조정 인자 (VAF) = 0.65 + (50 × 0.01) = 1.15

조정된 기능점수 (AFP) = 370 × 1.15 = 426 FP

3단계: 공수 변환
조직 생산성: 평균 20시간/FP
예상 공수 = 426 FP × 20시간 = 8,520시간 = 1,065 MD

적용 시점:

• 대규모 프로젝트의 초기 견적
• 여러 프로젝트 간 비교 필요 시
• 조직의 생산성 벤치마킹
• 계약 기반 정확한 산정 요구 시

장점:

• 객관적이고 일관된 기준
• 업계 표준 기반 비교 가능
• 규모와 복잡도의 정량적 측정
• 조직 차원의 생산성 관리

단점:

• 모델 학습과 적용에 전문성 필요
• 조직별 보정 데이터 필요
• 신기술이나 새로운 개발 방식 반영 지연
• 초기 규모 추정의 정확성에 의존

방법론 선택 가이드

프로젝트 단계별 추천 조합

초기 단계 (요구사항 모호):
1차: 유사치 기반 (범위 추정)
2차: 상대적 추정 (T-shirt 사이징)
결과: "300-500MD 범위" 형태

계획 단계 (요구사항 구체화):
1차: 상향식 추정 (상세 WBS)
2차: 모수적 검증 (COCOMO/FP)
결과: "총 420MD, ±15%" 형태

실행 단계 (애자일 환경):
주요: 상대적 추정 (스토리 포인트)
보조: 상향식 (스프린트 계획)
결과: "29pt/sprint, 10 스프린트" 형태

---

팀 용량과 속도 산정 방법론

용량 계산 공식

용량(시간) = 팀원 수 × 스프린트 근무일 × 일일 가용시간 × 포커스 팩터

실제 계산 예시 (2주 스프린트)

기본 조건

• 팀 구성: 6명
• 스프린트 기간: 2주 (근무일 10일)
• 일일 근무시간: 8시간
• 포커스 팩터: 0.70

계산 과정

총 가용시간 = 6명 × 10일 × 8시간 = 480시간
실제 개발시간 = 480시간 × 0.70 = 336시간
용량(인일) = 336시간 ÷ 8시간 = 42 MD

속도(Velocity) 측정

과거 3-5개 스프린트의 완료 스토리 포인트 평균을 활용하여 향후 스프린트의 계획 기준으로 삼습니다.

---

역할별 공수 분배 가이드라인 (2025년 기준)

현대적 웹/모바일 서비스 개발 프로젝트의 일반적 분배 비율입니다.

주요 역할군별 비중

요구사항 및 기획 (10-15%)

• 프로덕트 오너, 비즈니스 애널리스트
• 요구사항 정의, 사용자 스토리 작성

사용자 경험 설계 (8-12%)

• UX/UI 디자이너, 사용자 리서처, 퍼블리셔
• 사용자 경험 설계, 디자인 시스템 구축

소프트웨어 개발 (45-60%)

• 백엔드, 프론트엔드, 모바일 개발자
• 핵심 비즈니스 로직 및 사용자 인터페이스 구현

데이터/AI 엔지니어링 (0-15%)

• 데이터 엔지니어, ML 엔지니어
• 프로젝트에 데이터 분석이나 AI 요소가 포함된 경우

인프라 및 운영 (5-10%)

• DevOps 엔지니어, SRE
• CI/CD 구축, 모니터링, 인프라 관리

품질 보증 (12-20%)

• QA 엔지니어, 테스트 자동화 엔지니어
• 테스트 전략 수립, 자동화, 성능 테스트

프로젝트 관리 (5-10%)

• 프로젝트 매니저, PMO, 품질 관리자
• 프로젝트 통제, 위험 관리, 품질 보증

---

AI 시대의 공수 보정 방법론

작업 유형별 생산성 영향 분석

높은 효율성 향상 영역 (-10% ~ -25%)

• 반복적 CRUD 로직 구현
• 보일러플레이트 코드 생성
• 기본적인 단위 테스트 작성
• 표준적인 API 엔드포인트 개발

중간 수준 향상 영역 (-5% ~ -10%)

• 일반적인 비즈니스 로직 구현
• 데이터베이스 스키마 설계
• 기본적인 성능 최적화

제한적 향상 영역 (0% ~ +5%)

• 복잡한 시스템 아키텍처 설계
• 도메인 전문 지식 기반 구현
• 복잡한 알고리즘 개발
• AI 생성 코드에 대한 리뷰 및 검증

보정 계수 적용 예시

기존 예상 시간: 백엔드 API 개발 100시간

세분화 및 보정:
- CRUD 구현 (40시간): 40 × 0.80 = 32시간
- 복잡한 비즈니스 로직 (40시간): 40 × 0.95 = 38시간
- 코드 리뷰 및 테스트 (20시간): 20 × 1.05 = 21시간

총 조정 시간: 91시간 (9% 단축)

---

누락되기 쉬운 숨겨진 작업들

품질 보증 관련 활동

테스트 관련

• 테스트 전략 수립 및 계획 문서화
• 테스트 케이스 설계 및 관리
• 자동화 테스트 스크립트 개발
• 성능 및 부하 테스트 수행
• 보안 테스트 (SAST/DAST) 실행
• 탐색적 테스트 및 사용성 테스트

운영 준비

• 모니터링 시스템 구축 및 설정
• 로깅 체계 설계 및 구현
• 알림 및 경고 시스템 구성
• 배포 및 롤백 전략 수립
• 운영 매뉴얼 및 런북 작성

보안 및 컴플라이언스

• 보안 정책 수립 및 적용
• 취약점 스캔 및 대응
• 개인정보 보호 대응
• 감사 및 규제 준수 활동

데이터 관리

• 데이터 마이그레이션 계획 및 실행
• 데이터 정합성 검증
• 백업 및 복구 전략 수립

권장 가산 규칙

개발 공수의 20-30%를 품질 보증 및 운영 준비 활동으로 자동 할당하는 것을 권장합니다. 이는 프로젝트 후반부의 일정 지연을 방지하는 효과적인 방법입니다.

---

리스크 관리와 컨틴전시 적용

리스크 수준별 컨틴전시 가이드

낮은 리스크 (+10-15%)

• 팀의 기술 스택 숙련도가 높음
• 명확하고 안정적인 요구사항
• 외부 의존성이 적음
• 검증된 아키텍처 패턴 사용

중간 리스크 (+15-25%)

• 팀에 신규 구성원 포함
• 일부 새로운 기술 도입
• 제한적인 외부 시스템 연동
• 중간 수준의 성능 요구사항

높은 리스크 (+25-35%)

• 새로운 기술 스택 전면 도입
• 불확실하거나 변동 가능성이 높은 요구사항
• 복잡한 외부 시스템 연동
• 엄격한 성능 및 보안 요구사항
• 미션 크리티컬한 시스템

진행 중 추정 조정 방법

정기적 검토 지표

• 스프린트별 속도 변화 추이
• 번다운 차트 분석
• DORA 지표 모니터링
• 팀 가용성 변화 (휴가, 교육, 신규 투입)
• 요구사항 변경 빈도 및 영향도

---

체계적인 산정 프로세스

1단계: 초기 범위 추정

목적: 빠른 견적 및 타당성 검토 방법: 유사치 기반 추정 + 상위 수준 기능 분해 결과: 범위 형태의 추정치 (예: 300-500MD) 소요 기간: 1-3일

주요 활동

• 유사 프로젝트 식별 및 비교 분석
• 핵심 기능 및 제약사항 파악
• 주요 기술적 리스크 식별
• 대략적인 팀 구성 및 기간 추정

2단계: 상세 계획 수립

목적: 계약 및 승인용 정확한 산정 방법: WBS 기반 상향식 추정 결과: 구체적인 공수 및 일정 (예: 총 420MD, 6개월 소요) 소요 기간: 1-2주

주요 활동

• 상세 작업분해구조 작성
• 비기능 요구사항 반영
• 품질 보증 활동 계획
• 외부 의존성 분석
• 리스크 기반 컨틴전시 적용

3단계: 진행 중 모니터링 및 조정

목적: 지속적인 정확도 향상 방법: 실제 데이터 기반 보정 주기: 스프린트 또는 월 단위 도구: 번다운 차트, 속도 추적, DORA 지표

주요 활동

• 실제 대비 계획 분석
• 속도 변화 원인 분석
• 스코프 변경 영향 평가
• 일정 및 자원 재조정

4단계: 완료 후 회고 및 학습

목적: 조직의 추정 역량 향상 방법: 실제 데이터 분석 및 벤치마크 구축 결과: 팀별 생산성 지표 및 추정 정확도 데이터

---

실제 적용 사례

신규 B2B 웹 서비스 개발 프로젝트

프로젝트 개요

• 고객 관리 시스템 및 분석 대시보드 개발
• 외부 결제, 알림, CRM 시스템 연동 (3건)
• 목표 개발 기간: 6개월

팀 구성 및 용량 산정

팀 구성:
- 프론트엔드 개발자: 2명
- 백엔드 개발자: 3명
- QA 엔지니어: 1명
- UX/UI 디자이너: 1명
- 프로덕트 오너: 0.5명 (겸임)
- DevOps 엔지니어: 0.5명 (겸임)
총 8.0 FTE (Full Time Equivalent)

월별 용량 계산:
- 월 근무일: 20일
- 일일 유효 근무시간: 6시간 (포커스 팩터 0.75 적용)
- 월 총 용량: 8.0 FTE × 20일 × 6시간 = 960시간
- 월 용량(MD): 960시간 ÷ 8시간 = 120 MD

역할별 공수 분배

소프트웨어 개발: 960시간 × 55% = 528시간
품질 보증: 960시간 × 18% = 173시간
UX/UI 설계: 960시간 × 10% = 96시간
인프라/DevOps: 960시간 × 7% = 67시간
기획 및 관리: 960시간 × 10% = 96시간

리스크 평가 및 최종 산정

리스크 요소:
- 외부 시스템 연동 복잡성: 중간 수준
- 팀의 기술 스택 숙련도: 높음
- 요구사항 안정성: 중간 수준

적용 컨틴전시: +20%

최종 산정:
- 월별 계획 공수: 120 MD × 1.2 = 144 MD
- 6개월 총 예상 공수: 144 MD × 6 = 864 MD

---

권장 도구 및 템플릿

산정 지원 도구

오픈소스/무료 도구

• Google Sheets: 용량 계산 및 추적 템플릿
• Miro: 협업적 추정 및 플래닝 포커
• GitHub Projects: 스토리 포인트 관리 및 속도 추적

전문 도구

• Jira Software: 애자일 프로젝트 관리 및 속도 추적
• Azure DevOps: 용량 계획 및 번다운 차트
• Monday.com: 프로젝트 타임라인 및 자원 관리

필수 문서 템플릿

프로젝트 가정 및 제약사항

## 기술적 가정사항
- 개발 스택: React 18, Node.js 18, PostgreSQL 14
- 팀 기술 숙련도: React (상급), Node.js (중급), PostgreSQL (상급)
- 인프라: AWS 클라우드 환경
- 외부 연동: REST API 기반, 응답시간 SLA < 3초

## 비즈니스 제약사항
- 규제 준수: GDPR, 개인정보보호법
- 보안 요구사항: ISO 27001 기준
- 성능 목표: 동시 사용자 1,000명, 응답시간 < 2초

## 프로젝트 범위 외
- 모바일 네이티브 앱 개발
- 레거시 시스템 마이그레이션
- 24/7 운영 지원

---

결론

효과적인 공수 산정은 프로젝트 성공의 핵심 요소입니다. 2025년 현재의 기술 환경에서는 AI 도구의 영향, DevOps 성숙도, 하이브리드 근무 환경 등의 새로운 변수들을 체계적으로 고려해야 합니다.

핵심 성공 요인

1. 다면적 접근법: 단일 방법론이 아닌 상황에 맞는 복합적 접근
2. 지속적 보정: 실제 데이터를 기반으로 한 정기적 추정 조정
3. 팀 역량 고려: 기술 숙련도와 협업 경험을 반영한 현실적 산정
4. 리스크 관리: 체계적인 불확실성 식별 및 대응
5. 학습 조직: 완료 프로젝트의 데이터를 활용한 지속적 개선

향후 전망

다음 포스트에서는 실제 활용 가능한 엑셀 템플릿과 자동화 도구를 제공할 예정입니다. 또한 대규모 멀티팀 환경에서의 포트폴리오 관리와 AI 도구 도입에 따른 생산성 측정 방법론에 대해서도 상세히 다룰 계획입니다.

정확한 공수 산정은 경험과 데이터의 축적을 통해 점진적으로 향상되는 역량입니다. 체계적인 접근법과 지속적인 개선을 통해 프로젝트의 예측 가능성과 성공률을 높여나가시기 바랍니다.

---

참고 문헌

• Construx Software, "The Cone of Uncertainty in Software Development"
• Atlassian, "Story Points and Estimation Best Practices"
• DORA Team, "Accelerate State of DevOps Report 2023"
• Scaled Agile, "SAFe 6.0 Framework Updates"
• Various Research Papers on AI Impact on Software Development Productivity

---

이전 글을 여기에 그대로 두었습니다.

 

최근 광주의 한 아파트공사장의 건물이 붕괴되어서 문제가 되고 있습니다.

건설처럼 IT프로젝트도 눈에 가시적으로 보이지 않는 소스코드들을 차근차근 쌓아 나가는 것이기 때문에 많은 작업과 다양한 역할을 하는 사람들이 필요로 합니다.

일반적으로 기업용 어플리케이션의 개발에는 다음과 같은 역할을 필요로 합니다.

 

아무 것도 없는 상태에서 시스템을 만들어 낸다면

고객의 요구사항을 토대로 하여 

 

1. 시스템의 아키텍처를 설계하는 사람 : TA

2. 어플리케이션의 아키텍처를 설계하는 사람 : AA

3. 고객의 요구사항을 들어서 화면을 그리는 사람 : 기획자

4. 그려진 화면을 토대로 실제적인 디자인적인 구현을 하는 사람 : 디자이너

5. 그려진 디자인을 토대로 해서 개발자가 사용할수 있도록 연계되는 코드를 넣어주는 사람 : 퍼블리셔

6. 고객과 기획자와 협력하여 시스템을 설계하는 사람 :분석설계자 

6. 개발자

- 공통개발자 : 전체적인 개발의 틀을 잡고 공통기능(로그인, 기본 함수 등)을 도출하고 개발하는 사람

- 모델러 : 고객의 요구사항과 기획자의 화면을 토대로 하여 DB모델링을 하는 사람

- FRONT 개발자 : 기획자의 설계를 토대로 하여 UI적인 개발을 하는 사람

- 백엔드 개발자 : FRONT 개발자와 협력하여 서버단의 프로그램을 하는 사람

- 인터페이스 개발자: 타 시스템과의 인터페이스 또는 내부의 인터페이스를 담당하여 설계하고 개발하는 사람

- 배치 개발자 : 내부의 베치작업들을 개발하는 사람

 

 

프로젝트를 진행하기 위해서 다음의 인력을 또 필요로 합니다.

- 프로젝트 관리자 : 전체 프로젝트를 조율하며 진행하는 관리자

- PMO : PM이나 고객을 도와서 프로젝트의 진도, 보고자료, 행정 등을 관리하는 사람

- 테스터 : 시스템이 개발되고 테스트 하는 과정에서의 테스트를 담당하는 사람이며 또다시 테스트 기획, 수행자로 나뉜다.

- 감리/품질관리 : 고객을 대신하여 주기적으로 프로젝트의 진행상태와 품질을 체크하여 보고하는 사람

 

이상과 같이 프로젝트의 참여자를 살펴보았습니다.

 

공수산정을 위해서는 우선적으로 

이런 프로젝트의 참여자가 충분하게 잘 배치되었는지를 살펴보아야 합니다.

 

프로젝트의 공수산정은 다음 글에서 계속 논의해보도록 하겠습니다.

 

2022.11.17 - [IT/프로젝트 관리] - 프로젝트의 공수산정해보기

프로젝트의 공수산정해보기

 

성공하는 프로젝트 되시기 바랍니다.