개발 공수 산정의 정석: 순수 개발 시간과 리스크를 분리하는 엑셀·스프레드시트 템플릿 실무 가이드

📌 들어가는 글: 왜 개발자의 "10일 걸립니다"는 항상 틀릴까?

"이 기능 개발하는 데 얼마나 걸릴 것 같나요?"

개발 팀장이나 엔지니어가 프로젝트 시작 시 가장 자주 받는 질문입니다. 그리고 십중팔구 개발자는 머릿속으로 '코딩하는 시간'을 계산해 "한 10일 정도 걸릴 것 같습니다"라고 답변합니다.

하지만 결과는 어떤가요? 10일이 지나도 작업은 끝나지 않고, 경영진이나 기획자는 "왜 약속한 날짜를 지키지 않냐"며 독촉합니다. 개발자는 회의, 기획 변경, 외부 연동 문제, 버그 수정 때문에 순수하게 코딩에 집중할 시간이 없었다고 억울해합니다.

이 비극의 원인은 개발자의 실력 부족이 아닙니다. 바로 '순수하게 코딩하는 시간(Ideal Time)'과 '불확실성 및 외부 위험 요소(Risk & Uncertainty)'를 구별하지 않고 하나의 숫자로 뭉뚱그려 추정했기 때문입니다.

경영진과 개발팀 간의 불신을 끝내고 예측 가능성을 높이기 위해서는, 순수 공수와 리스크를 명확히 분리하여 수식화하는 체계가 필요합니다. 본 글에서는 실무에서 즉시 구글 스프레드시트나 엑셀로 구축해 활용할 수 있는 [요구사항 분해 및 공수·리스크 산정 템플릿]과 운용 노하우를 상세히 다룹니다.

📊 1. 개발 공수 & 리스크 산정 템플릿 실무 예시

이 템플릿의 핵심은 "개발자가 생각하는 순수 구현 시간"과 "실제 불확실성(리스크)"을 계량화하여 분리 산정하는 것입니다.

📋 공수 산정 스프레드시트 예시

ID	대분류	세부 작업 (Task)	담당	순수 공수 (Man-Day)	리스크 등급	리스크 가중치	보정 공수 (Man-Day)	산정 사유 및 리스크 요인
AUTH-01	회원관리	소셜 로그인 (카카오/네이버)	BE	2.0	Low	1.1	2.2	기존 모듈 재사용 가능, 기획 확정
AUTH-02	회원관리	본인 인증 (NICE 연동)	BE	3.0	High	1.5	4.5	외부 대행사 승인절차 지연 및 문서 미비 리스크
ORD-01	주문결제	PG사 결제 모듈 연동	BE	4.0	Medium	1.3	5.2	아임포트/토스 연동 경험 있으나 망취소 로직 검증 필요
ORD-02	주문결제	결제 페이지 UI 및 상태값 반영	FE	3.0	Low	1.1	3.3	디자인 시안 확정됨
DSH-01	대시보드	일별 매출 집계 및 차트 시각화	BE/FE	5.0	High	1.5	7.5	대용량 쿼리 튜닝 필요, 차트 라이브러리 미정
SUM	소계	5개 작업	-**	**17.0 M/D	-**	**-	22.7 M/D	(MM 환산: 약 1.13 MM)

📐 2. 템플릿 구성 요소 및 핵심 수식 정의

구글 스프레드시트나 엑셀에 템플릿을 구축할 때 적용해야 하는 핵심 칼럼 정의와 자동 계산 수식 규칙입니다.

① 순수 공수 (Ideal Man-Day)

정의: 회의, 버그 수정, 운영 지원 등 방해 요소 없이 오직 개발에만 전념했을 때 걸리는 일수 (1 M/D = 8시간 기준).
작성 수칙 (Breakdown Rule):
- 하나의 세부 Task는 최대 3~5일(Man-Day)을 넘지 않도록 최대한 세분화해야 합니다.
- 만약 단일 작업이 5일을 초과한다면, 이는 요구사항이나 구현 방식이 명확하지 않다는 방증이므로 더 작고 구체적인 Task로 재분해(Breakdown)해야 합니다.

② 리스크 등급 및 가중치 매트릭스 (Buffer Matrix)

불확실성의 원인을 감추지 않고 Low, Medium, High 3단계의 보정 가중치로 명확히 시각화합니다.

┌──────────────┬─────────────┬────────────────────────────────────────────────────────┐
│ 리스크 등급   │ 가중치 비율  │ 해당 조건 및 기준                                       │
├──────────────┼─────────────┼────────────────────────────────────────────────────────┤
│ Low          │ 1.1 (+10%)  │ • 기획 및 UI/UX 디자인 시안이 완벽히 확정됨            │
│              │             │ • 기존에 이미 구현해 본 익숙한 기술 및 코드 베이스      │
│              │             │ • 외부 연동 없이 내부 시스템 내 변경만 존재            │
├──────────────┼─────────────┼────────────────────────────────────────────────────────┤
│ Medium       │ 1.3 (+30%)  │ • 기획의 세부 스펙이 일부 유동적이거나 추가 논의 필요  │
│              │             │ • 연동 경험은 있으나 외부 API/PG 연동이 포함됨         │
│              │             │ • 타 부서/타 팀과의 협의 및 인터페이스 정의 필요       │
├──────────────┼─────────────┼────────────────────────────────────────────────────────┤
│ High         │ 1.5 ~ 2.0   │ • 신규 기술 검증(PoC)이 필수로 선행되어야 함           │
│              │ (+50~100%)  │ • 외부 기관(PG사, 공공기관 등)의 승인/인증 지연 예상   │
│              │             │ • DB 스키마나 핵심 시스템 아키텍처가 전환되는 작업     │
└──────────────┴─────────────┴────────────────────────────────────────────────────────┘

③ 자동 계산 수식 (Spreadsheet Formulas)

스프레드시트에 바로 적용할 수 있는 수식 설계 구조입니다.

보정 공수 (Buffered Man-Day): $ ext{보정 공수} = ext{순수 공수} imes ext{리스크 가중치}$
- 엑셀 수식 예시: =E2 * G2
총 Man-Month (MM) 환산: $ ext{총 MM} = rac{\sum ext{보정 공수}}{20 ext{ (월평균 영업일수)}}$
- 엑셀 수식 예시: =SUM(H2:H6) / 20
경영 예비비 (Management Buffer):
- 프로젝트 전체 보정 공수 합계 상단에 추가로 10~15%의 경영적 예비비(전체 QA 대응, 최종 배포 리스크, 긴급 운영 이슈 대응용)를 별도 행으로 추가합니다.

💡 3. 체계 도입 시 테크 리더를 위한 실무 운용 팁

산정 템플릿을 만들어 놓는 것보다 중요한 것은 이를 조직의 의사소통 도구로 만드는 것입니다.

1️⃣ "버퍼(Buffer)"를 감추지 말고 정당하게 시각화하세요

기존 방식에서 개발자는 불안감 때문에 순수 공수 자체를 부풀려 말합니다. (예: 3일이면 될 일을 10일이라고 말함) 경영진은 이를 눈치채고 "왜 이렇게 오래 걸리냐"며 깎으려고 합니다.

대신 이 템플릿을 사용해 다음과 같이 논리적으로 설득해 보세요:

💬 설득 예시:
"경영진님, 이 본인인증 모듈의 순수 개발 코딩 시간은 3일입니다. 하지만 외부 NICE 연동 승인 절차 문서 미비와 대행사 피드백 지연 리스크가 커서 High(1.5 가중치)를 부여했습니다. 따라서 보정 공수는 4.5일로 산정되었습니다."

근거가 산식으로 명확히 드러나면 경영진도 일정에 대해 불필요한 의구심을 갖지 않고 '리스크를 제거해주기 위해 지원할 점'에 집중하게 됩니다.

2️⃣ 기획 변경 시 템플릿의 행(Row)을 실시간으로 추가하세요

프로젝트 진행 중 흔히 발생하는 비극은 "이 기능도 살짝 추가해 주세요"라는 무분별한 스콥 크립(Scope Creep)입니다.

이때 구두로 받아들이지 말고, 산정 템플릿 하단에 즉시 새로운 행(Row)을 추가하고 순수 공수와 리스크 가중치를 입력하세요.

새 행이 추가됨에 따라 전체 보정 공수와 MM, 완료 예정 일자가 실시간으로 연동되어 증가합니다.
기획자와 경영진에게 "요구사항 추가 시 일정과 비용이 얼마나 늘어나는지"를 시각적 데이터로 눈앞에서 확인시켜 줌으로써 무리한 스콥 추가를 효과적으로 방지할 수 있습니다.

3️⃣ 실제 소요 시간 측정과 회고 (Retrospective)

완료된 작업은 실제 소요된 시간을 반드시 템플릿 옆 칼럼에 기록해 두어야 합니다.

만약 Low 등급으로 잡았던 작업이 지속적으로 지연된다면, 팀의 기본 생산성 산정 방식이나 개발 환경에 병목이 있음을 알 수 있습니다.
반대로 High 리스크 작업이 빠르게 끝났다면, 축적된 데이터를 바탕으로 다음 프로젝트에서는 가중치를 내릴 수 있습니다.
이 데이터 피드백 루프가 축적될수록 우리 팀만의 정밀한 산정 방정식이 완성됩니다.

🎯 맺음말: 예측 가능성이 만들어내는 조직의 신뢰

개발 산정은 단순히 '날짜를 맞추기 위한 행위'가 아닙니다. 프로젝트의 불확실성을 통제 가능한 리스크로 변환하고, 개발팀과 비즈니스 팀 간의 신뢰를 구축하는 리더십의 언어입니다.

오늘 소개한 [순수 공수 + 리스크 가중치 매트릭스] 스프레드시트 템플릿을 팀에 도입해 보세요. 감에 의존하는 개발 문화에서 벗어나, 데이터와 논리로 일정을 예측하는 건강한 테크 조직으로 거듭날 수 있을 것입니다.

본 가이드가 도움이 되셨다면 조직 내 PM, Tech Lead, 경영진 분들과 공유해 보세요!