"그냥 일단 해봐"가 부르는 야근과 불신: 개발 비용·일정 산정 3대 방법론과 실무 적용 가이드

📌 들어가는 글: 체계 없는 개발 현장의 비극

"기획서 정리할 시간 없으니까, 그냥 일단 해보면서 잡으시죠."
"이 정도 기능이면 한 3명이서 한 달이면 다 만들지 않나요?"

IT 프로젝트 현장에서 너무나 익숙하게 들리는 말입니다. 하지만 근거 없는 촉과 압박으로 시작된 프로젝트의 끝은 늘 정해져 있습니다. 개발자는 매일 야근하며 기획이 계속 바뀌는 현실에 지쳐가고, 경영진은 "왜 제때 결과물이 나오지 않느냐"며 개발팀의 생산성을 의심합니다. 결국 남는 것은 누적된 기술 부채(Tech Debt)와 상호 간의 깊은 불신뿐입니다.

많은 이들이 프로젝트 지연을 '개발자의 실력 부족'이나 '기획자의 우유부단함' 탓으로 돌립니다. 하지만 진짜 원인은 '우리가 무엇을 만들고 있으며, 그것이 얼마나 걸릴지 객관적으로 측정하는 체계(Estimation System)'가 부재하기 때문입니다.

개발 일정과 비용 산정은 단순한 '날짜 맞추기'가 아닙니다. 그것은 불확실성을 관리하고, 비즈니스 리스크를 통제하며, 조직의 신뢰를 구축하는 핵심 의사결정 프로세스입니다.

이번 글에서는 대표적인 개발 산정 3대 방법론(MM, FP, SP)의 특성과 한계를 비교하고, 체계가 부족한 조직이 현실적으로 도입할 수 있는 3단계 실무 개선 전략을 다룹니다.

📊 1. 개발 산정 3대 방법론 비교분석

프로젝트 규모와 일정을 측정하는 방식은 "무엇을 기준으로 측정하는가"에 따라 크게 세 가지로 나뉩니다.

[산정 기준의 차이]
• Man-Month (MM)   ---> '투입 인원 × 시간' (Input 기준)
• Function Point (FP) ---> '구현할 기능의 양' (Output 기준)
• Story Point (SP)  ---> '작업의 상대적 난이도/불확실성' (Outcome/Complexity 기준)

1️⃣ Man-Month (MM, 맨먼스): 인건비 중심의 전통적 방식

💡 개념 및 산정 방식

개념: 1명의 개발자가 1개월 동안 수행할 수 있는 작업량을 기준(1 MM)으로 전체 필요 인원과 기간을 산정합니다.
계획 예시: 총 작업량이 6 MM이고 개발자 3명을 투입한다면, $6 \div 3 = 2$개월이 소요된다고 계산합니다.

👍 장점

직관적인 금액 환산: 인건비 단가와 직결되므로 외주 계약, 견적서 작성, 경영진 보고용 예산 수립이 매우 쉽습니다.
이해하기 쉬움: 비개발 직군이나 재무 담당자도 직관적으로 이해할 수 있습니다.

👎 단점 및 위험성

맨먼스의 신화 (Brooks' Law): "임산부 9명을 모아놓는다고 1달 만에 아기를 낳을 수 없다"는 명언처럼, 개발 인원을 늘린다고 작업 기간이 비례해서 줄어들지 않습니다. (커뮤니케이션 오버헤드 무시)
개발자 숙련도 차이 미반영: 연차나 실력에 따른 10배 이상의 생산성 차이를 단순히 '1인분'으로 동일하게 취급합니다.
불확실성과 리스크 배제: 요구사항의 모호함, 시스템 복잡도, 기술적 난관이 고려되지 않습니다.

2️⃣ Function Point (FP, 기능점수): 기능 규모 중심의 객관적 방식

💡 개념 및 산정 방식

개념: 소프트웨어가 사용자에게 제공하는 '기능의 양'을 객관적 표준 수치로 정량화하는 방식입니다. (SW사업 대가산정 가이드 표준)
산정 요소:
- 데이터 기능: 내부논리파일(ILF), 외부연계파일(EIF)
- 트랜잭션 기능: 외부입력(EI), 외부출력(EO), 외부조회(EQ)
각 요소의 개수와 복잡도 가중치를 합산하여 최종 기능점수를 계산하고, 여기에 유형별 단가를 곱해 비용을 산출합니다.

👍 장점

높은 객관성: 개발자의 주관이나 프로그래밍 언어에 영향받지 않고 요구사항 명세서 자체의 규모를 측정합니다.
계약 검증 및 정산 유용: 요구사항 변경 시 증가된 기능점수만큼 비용 증액을 요구할 수 있는 명확한 근거가 됩니다.

👎 단점 및 위험성

초기 완벽한 문서 요구: 정밀한 FP 산정을 위해서는 기획서, ERD, API 명세서 등이 프로젝트 초기에 완성되어 있어야 합니다.
고비용/고노력: FP 전문가나 상세한 분석 과정이 필요하여 소규모 조직에는 과도한 행정적 부담이 됩니다.

3️⃣ Story Point (SP, 스토리 포인트): 애자일 환경의 상대적 복잡도 방식

💡 개념 및 산정 방식

개념: 작업의 절대적 시간이 아닌, 기준 작업 대비 상대적인 복잡도, 난이도, 불확실성을 피보나치 수열($1, 2, 3, 5, 8, 13\dots$) 형태로 추정합니다.
산정 방식: 개발팀이 함께 모여 Planning Poker 등을 통해 "로그인 구현이 2점이라면, PG사 결제 연동은 8점 정도의 난이도다" 형태로 평가합니다.
속도(Velocity): 한 스프린트(예: 2주) 동안 팀이 해결한 Story Point의 총합을 측정하여 팀의 실제 처리량을 파악합니다.

👍 장점

유연성과 불확실성 수용: 기획이 유동적인 상황에서도 빠르고 유연하게 산정할 수 있습니다.
팀의 실제 생산성 반영: 연차가 아닌 해당 '팀'이 실제로 처리해내는 속도(Velocity)를 바탕으로 일정을 예측합니다.

👎 단점 및 위험성

외부 보고의 어려움: 경영진이나 고객사에게 "이 프로젝트는 120 스토리 포인트입니다"라고 보고하면 이해하지 못합니다. (원화/기간으로의 재환산 필요)
조직 간 비교 불가: A팀의 5점과 B팀의 5점은 완전히 다른 의미이므로 외부 비교 척도로 사용할 수 없습니다.

🧩 3대 방법론 종합 비교표

구분	Man-Month (MM)	Function Point (FP)	Story Point (SP)
측정 대상	투입되는 인원 × 시간	구현할 기능의 객관적 양	작업의 상대적 복잡도/불확실성
산정 기준	1인이 1개월간 할 일의 양	입력/출력/파일/인터페이스 수 및 난이도	기준 작업 대비 피보나치 수열(1, 2, 3, 5, 8...)
핵심 장점	견적서 작성 및 단가 계산의 직관성	객관적 요구사항 기반, 계약 정산에 유용	요구사항 변화에 유연, 팀 생산성 정확히 반영
핵심 단점	숙련도/리스크 미반영, 브룩스의 법칙 한계	초기 완벽한 기획서 필수, 분석 비용 발생	금액/일정 즉시 환산 불가, 외부 보고 어려움
주 주요 사용 분야	SI 외주 계약, 단가 기반 외주 사업	공공기관/대기업 RFP, 대형 정밀 견적	자체 서비스 개발, 애자일/스크럼 환경

🛠️ 2. 현장 맞춤형 실무 접근법: 3단계 개선 프레임워크

체계가 전혀 없는 조직에서 갑자기 공공기관 수준의 FP(기능점수)를 도입하려 하면, 개발자와 기획자 모두 문서 작성 부담 때문에 지쳐버립니다. 반대로 기존처럼 MM만 고집하면 "개발자 3명 넣었으니 한 달 안에 무조건 끝내라"는 비현실적인 압박만 반복됩니다.

현실적인 일정·비용 통제력을 확보하기 위해 다음 3단계 실무 개선 프레임워크를 권장합니다.

[3단계 실무 개선 프레임워크]

  Step 1. Breakdown
  ┌─────────────────────────┐
  │  요구사항 기능 단위 세분화  │ (User Story / Feature 단위 분해)
  └────────────┬────────────┘
               │
  Step 2. Dual Estimation
  ┌────────────┴────────────┐
  │  추정 방식의 이원화 시스템  │
  │  • 내부: Story Point    │
  │  • 외부: MM / 일정 환산  │
  └────────────┬────────────┘
               │
  Step 3. Calibration
  ┌────────────┴────────────┐
  │  추정치 교정 & 리스크 버퍼 │ (Retrospective 데이터 축적 & 20-30% Buffer)
  └─────────────────────────┘

📍 Step 1. 요구사항을 '기능 단위'로 쪼개기 (Breakdown)

"쇼핑몰 구축해 주세요"나 "결제 모듈 만들어 주세요"라는 거대한 요구사항을 그대로 받으면 어떤 우수한 산정 방식도 작동하지 않습니다.

실무 적용법

Epic → User Story → Task 계층으로 쪼갭니다.
각 요구사항은 INVEST 원칙을 참고하여 독립적이고 검증 가능한 최소 기능 단위(Feature)로 정의합니다.
- Bad: "회원가입 기능 개발 (10일)"
- Good:
  - 이메일 중복 체크 API (0.5일)
  - 소셜 로그인(카카오, Google) 연동 (2일)
  - 비밀번호 암호화 및 유효성 검증 (1일)
  - 약관 동의 및 본인 인증 UI (1.5일)
요구사항이 명확해질수록 산정의 오차 범위(Cone of Uncertainty)는 기하급수적으로 줄어듭니다.

📍 Step 2. 추정 방식의 이원화 (개발팀용 vs 경영진용)

개발팀 내부에서 사용하는 언어와 경영진/재무팀이 사용하는 언어는 다릅니다. 이 둘을 분리하되, 데이터 기반으로 연결하는 교환 비율(Conversion Rate)을 만들어야 합니다.

[개발팀 내부]                                [경영진/고객사 보고]
Story Point 산정  ───(Velocity 측정)───>  예측 주수 산출  ───(인건비 산정)───>  MM 및 예산 환산

1) 개발팀 내부 (Story Point 활용)

개발팀이 모여 각 Task의 복잡도를 피보나치 수열로 추정합니다.
초기 2~3번의 스프린트를 거치면서 팀 속도(Velocity)를 측정합니다.
- 예: 1개 스프린트(2주) 동안 우리 팀이 평균 30 Story Point를 완료함.

2) 경영진/외부 보고 (MM 및 일정 환산)

전체 백로그의 총 스토리 포인트가 120점이고, 팀 속도가 주당 15점이라면: $ ext{예상 소요 기간} = rac{120 ext{ SP}}{15 ext{ SP/주}} = 8 ext{주 (약 2개월)}$
여기에 투입 인원 3명의 월 인건비를 적용하여 최종 비용(MM)을 역산합니다.
경영진에게는 스토리 포인트를 직접 보여주지 않고, "데이터에 기반한 2개월(6 MM) 산출 근거"를 제시합니다.

📍 Step 3. 리스크 버퍼 반영 및 추정치 교정 (Calibration)

최초에 아무리 정밀하게 산정하더라도, 개발 과정에서는 반드시 불확실성(외부 API 장애, 기획 변경, 신규 기술 도입 이슈)이 발생합니다.

1) 회고(Retrospective)를 통한 오차 측정

매 프로젝트/스프린트가 끝난 뒤 [최초 추정 시간 vs 실제 소요 시간]을 반드시 기록합니다.
예: 초기 추정 10일 → 실제 소요 15일일 경우, 우리 팀의 추정 계수(Estimation Factor)는 1.5입니다.

2) 데이터에 기반한 리스크 버퍼(Risk Buffer) 설득

단순히 "혹시 모르니 3주 더 주세요"라고 하면 경영진은 납득하지 못합니다.
하지만 "지난 3개월간 기록된 데이터상 우리 팀은 평균 1.3배의 시간 차이가 발생했습니다. 따라서 산정된 8주에 데이터 기반 리스크 버퍼 25%를 반영하여 10주로 보고드립니다"라고 설득해야 합니다.
이러한 기록이 쌓이면 추정 정밀도가 점차 비약적으로 상승합니다.

💡 맺음말: 체계적인 산정이 가져다주는 조직 문화의 변화

개발 산정 체계를 갖추는 것은 단순히 프로젝트를 제때 끝내기 위함이 아닙니다. 조직 내 '예측 가능성(Predictability)'을 확보하고 구성원 간의 신뢰를 회복하는 과정입니다.

경영진은 묻지마식 압박 대신 데이터에 기반한 합리적인 비즈니스 계획을 세울 수 있습니다.
개발자는 예측 불가능한 야근에서 벗어나 주도적으로 일정과 리스크를 관리할 수 있습니다.
기획자/PM은 요구사항 추가에 따른 일정/비용 영향을 즉각 파악하여 합리적인 우선순위 조정을 진행할 수 있습니다.

"그냥 일단 해봐"라는 말로 시작하는 프로젝트는 결국 "왜 이것밖에 못했냐"로 끝납니다. 오늘 다룬 3가지 방법론의 특성을 이해하고, [기능 쪼개기 → 추정 이원화 → 데이터 교정]의 3단계를 차근차근 도입하여 건강한 테크 리더십과 개발 문화를 만들어가시길 바랍니다.

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