기능 추가(변경요청) 비용 산정 룰 — 시간제 vs 기능제
소프트웨어 외주 개발 중 기능 추가나 변경 요청(Change Request) 시 비용을 산정하는 두 가지 방식(시간제/기능제)의 장단점과 적합한 상황을 비교합니다.
- •변경요청(CR)은 외주 프로젝트에서 가장 빈번한 분쟁 원인이며, 사전에 처리 룰을 정해야 합니다.
- •시간제(T&M)는 유연하지만 비용이 불확실하고, 기능제(Fixed)는 비용이 확정되지만 범위 합의가 필요합니다.
- •계약서에 CR 처리 절차를 명시하고, 건당 최소 금액 기준을 정해두면 분쟁을 예방할 수 있습니다.
변경요청(CR)이 발생하는 이유
개발 프로젝트에서 변경요청은 반드시 발생합니다. "처음부터 완벽하게 기획하면 되지 않나?"라고 생각할 수 있지만, 현실은 다릅니다.
변경요청이 발생하는 주요 원인:
1. 사용해보니 다른 게 필요했다: 화면을 보고 나서야 "이 버튼은 여기가 아니라 저기에 있어야 해요"를 깨닫습니다.
2. 비즈니스 환경 변화: 개발 중 시장 상황이 바뀌어 기능 우선순위가 달라집니다.
3. 이해관계자 추가 요구: 대표, 팀장, 마케팅팀 등 새로운 요구사항을 추가합니다.
4. 기획 누락: 처음에 생각하지 못한 예외 케이스가 개발 중 발견됩니다.
5. 사용자 피드백: 베타 테스트에서 받은 피드백을 반영해야 합니다.
중요한 것은 CR 자체를 막으려는 것이 아니라, CR 발생 시 비용·일정 처리 절차를 미리 합의하는 것입니다. 절차 없이 CR이 누적되면 예산과 일정이 통제 불능 상태에 빠집니다.
일반적으로 전체 프로젝트의 15~30% 가 CR로 인한 추가 비용입니다. 이를 사전에 예산에 반영해두는 것이 현실적입니다.
시간제(T&M) vs 기능제(Fixed) 비교
| 비교 항목 | 시간제 (Time & Material) | 기능제 (Fixed Price) |
|---|---|---|
| 비용 산정 | 투입 시간 × 시간 단가 | 기능별 고정 금액 |
| 시간 단가 | 5만~15만 원/시간 | - |
| 비용 확실성 | 낮음 (실제 투입 후 확정) | 높음 (사전 합의) |
| 유연성 | 높음 (범위 변경 자유) | 낮음 (재협의 필요) |
| 적합한 상황 | 범위가 유동적, 소규모 CR | 범위가 명확, 대규모 CR |
| 리스크 | 발주사 (비용 초과 가능) | 개발사 (공수 초과 가능) |
| 투명성 | 시간 기록 확인 필요 | 결과물 기준 확인 |
추천 방식: 소규모 CR(1~3일 공수)은 시간제, 대규모 CR(1주 이상)은 기능제로 처리하는 하이브리드 방식이 가장 효과적입니다.
시간제 시 주의점: 작업 내용과 시간을 매일 기록(타임시트)하여 투명하게 관리하세요.
기능제 시 주의점: CR의 범위를 문서로 명확히 합의한 후 진행하세요.
CR 처리 절차 템플릿
계약서에 아래 절차를 포함하세요.
1단계: CR 요청
발주사가 변경 내용을 문서(이메일/이슈 트래커)로 전달합니다.
2단계: 영향도 분석 (1~3영업일)
개발사가 해당 CR의 영향 범위, 추가 공수, 일정 영향을 분석하여 회신합니다.
3단계: 승인/거절
발주사가 추가 비용과 일정을 확인하고 진행 여부를 결정합니다.
4단계: 개발 및 검수
승인된 CR을 개발하고, 기존 기능에 영향이 없는지 함께 확인합니다.
분쟁을 예방하는 CR 관련 계약 조항
아래 내용을 계약서에 반드시 포함하세요.
무상 범위: 개발사 귀책의 버그 수정, 요구사항 명세서에 명시된 범위 내 수정은 무상
유상 범위: 초기 범위에 없는 신규 기능, 대규모 디자인 변경, 비즈니스 로직 변경
회색 지대 처리: "요구사항 명세서에 명시되지 않은 사항은 유상 CR로 처리" 조항 추가
긴급 CR 할증: 당일 배포가 필요한 긴급 CR은 통상 단가의 1.5~2배 적용
또한 "전체 CR 비용이 초기 계약금의 30%를 초과하는 경우 프로젝트 범위를 재협의한다"는 안전장치 조항을 넣어두면 비용 폭주를 방지할 수 있습니다.
실무 팁으로, 주간 미팅에서 CR 현황을 공유하면 누적 비용을 관리하기 훨씬 수월합니다.