소프트웨어 개발 비용, 어떻게 산정할까? - 4가지 방법론과 실제 적용 사례

들어가며

"이 프로젝트 개발하면 얼마나 들까요?"

외주를 맡기든, 직접 개발하든, 누구나 한 번쯤 이 질문을 던져봤을 겁니다. 그런데 막상 대답하려고 하면 막막합니다. 감으로 때려맞히자니 근거가 없고, 정확하게 계산하자니 방법을 모르겠고.

최근 제가 3개월간 개발한 개인 블로그 프로젝트의 비용을 산정해볼 일이 있었습니다. 42,000줄의 TypeScript 코드, 286개의 파일, NestJS 백엔드부터 Next.js 프론트엔드까지. 이 프로젝트의 "가치"를 숫자로 표현하려면 어떻게 해야 할까요?

여러 방법론을 적용해보면서 각각의 원리와 장단점을 정리해봤습니다.

1. 시장 시세 기반 산정

원리

가장 직관적인 방법입니다. "비슷한 일을 하는 사람들이 얼마를 받는가?"를 기준으로 삼습니다.

총 비용 = 예상 공수(일) × 일당 단가

핵심은 두 가지입니다. 첫째, 작업을 세분화해서 공수를 추정하는 것. 둘째, 적절한 단가를 적용하는 것.

실제 적용

제 프로젝트를 18개 기능으로 분해하고 각각의 공수를 추정했습니다.

JWT 인증 시스템: 5일 (상)
TiptapEditor 구현: 7일 (상)
블로그 CRUD API: 4일 (중)
AI SEO 분석 연동: 5일 (상)
다국어 지원: 3일 (중)
...
총 예상 공수: 69일

여기에 한국 프리랜서 시장 시세를 적용하면:

주니어 (1-3년): 30-40만원/일 → 2,070 - 2,760만원
미드레벨 (3-5년): 50-70만원/일 → 3,450 - 4,830만원
시니어 (5년+): 80-120만원/일 → 5,520 - 8,280만원

장단점

장점: 직관적이고 시장 현실을 반영합니다. 클라이언트에게 설명하기도 쉽습니다.

단점: 공수 추정이 주관적입니다. 경험이 부족하면 과소/과대 추정하기 쉽고, "이 기능이 왜 5일이냐"는 질문에 객관적 근거를 대기 어렵습니다.

2. COCOMO II 모델

원리

COCOMO(COnstructive COst MOdel)는 1981년 Barry Boehm이 개발한 모델로, 코드량(LOC, Lines of Code)을 기반으로 개발 노력을 추정합니다.

핵심 공식은 이렇습니다:

Effort (Person-Months) = A × (KLOC)^B × EAF

- A: 상수 (보통 2.94)
- KLOC: 천 줄 단위 코드량
- B: 스케일 팩터 (보통 1.0997)
- EAF: 노력 조정 계수 (팀 역량, 도구 등)

쉽게 말하면, "코드가 많을수록 개발 시간이 기하급수적으로 늘어난다"는 경험적 사실을 수식화한 것입니다.

실제 적용

KLOC = 42.48 (42,480줄)
Effort = 2.94 × 42.48^1.0997
       ≈ 156 Person-Days
       ≈ 13 Person-Months (Man-Month)

여기서 중요한 건 "월급"이 아닌 "인건비 총비용"을 적용해야 한다는 점입니다. 회사가 개발자 한 명을 고용하면 월급 외에도 4대보험 회사 부담분(약 9%), 퇴직금 충당(8.3%), 복리후생, 장비, 사무실 비용 등이 들어갑니다. 일반적으로 순수 월급의 1.3~1.5배가 실제 인건비입니다.

한국 개발자 연봉 현실을 반영해서 계산해보면:

경력        연봉 범위        월급      인건비 총비용(×1.4)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
주니어      3,500-5,000만    290-420만    400-590만
미드레벨    5,000-7,000만    420-580만    590-810만
시니어      7,000-9,500만    580-790만    810-1,100만

13 Man-Month 적용 시:
━━━━━━━━━━━━━━━━━━━━━━━━━━
주니어: 13 × 500만 = 약 6,500만원
미드레벨: 13 × 700만 = 약 9,100만원
시니어: 13 × 950만 = 약 1.2억원

장단점

장점: 객관적인 수치(코드량)를 기반으로 합니다. 대규모 프로젝트에서 통계적으로 검증된 모델입니다.

단점: 코드량을 미리 알기 어렵습니다. 같은 기능도 언어/프레임워크에 따라 코드량이 다릅니다. 10줄짜리 Python과 100줄짜리 Java가 같은 일을 할 수도 있으니까요. 또한 리팩토링으로 코드가 줄어들면 "가치"도 줄어드는 것처럼 보이는 역설이 있습니다. 그리고 위 계산에서 보듯 다른 방법들보다 상당히 높게 나오는 경향이 있는데, COCOMO는 1980년대 모델이라 현대 개발 환경(프레임워크, 라이브러리, AI 도구)의 생산성 향상을 반영하지 못하기 때문입니다.

3. 기능점수(Function Point) 분석

원리

1979년 IBM의 Allan Albrecht가 개발한 방법론으로, 사용자 관점에서 소프트웨어의 기능을 측정합니다. 코드량이 아닌 "사용자에게 제공되는 기능"을 기준으로 삼기 때문에 기술에 독립적입니다.

5가지 기능 유형을 정의합니다:

데이터 기능 (시스템이 관리하는 것)
├─ ILF (Internal Logical File): 내부 데이터 (DB 테이블 등)
└─ EIF (External Interface File): 외부 참조 데이터 (외부 API 등)

트랜잭션 기능 (사용자가 하는 것)
├─ EI (External Input): 데이터 입력 (글 작성, 로그인)
├─ EO (External Output): 가공된 출력 (리포트, 분석 결과)
└─ EQ (External Inquiry): 단순 조회 (목록, 상세 보기)

각 기능은 복잡도(Low/Average/High)에 따라 가중치가 달라집니다:

기능 유형    Low   Average   High
ILF          7      10        15
EIF          5       7        10
EI           3       4         6
EO           4       5         7
EQ           3       4         6

실제 적용

제 프로젝트를 분석해보면:

ILF (내부 데이터)
├─ 블로그 글 (blog_posts): High → 15 FP
├─ 사용자 (users): Average → 10 FP
├─ AI 분석 로그: Average → 10 FP
└─ ... 총 8개 → 76 FP

EIF (외부 인터페이스)
├─ Cloudinary API: Average → 7 FP
├─ Google Gemini AI: High → 10 FP
└─ ... 총 5개 → 34 FP

EI (외부 입력)
├─ 블로그 글 작성: High → 6 FP
├─ 이미지 업로드: Average → 4 FP
└─ ... 총 15개 → 58 FP

EO (외부 출력)
├─ AI SEO 분석 결과: High → 7 FP
├─ 동적 Sitemap: Average → 5 FP
└─ ... 총 12개 → 62 FP

EQ (외부 조회)
├─ 블로그 목록: Average → 4 FP
└─ ... 총 12개 → 40 FP

━━━━━━━━━━━━━━━━━━━━━━━
총 UFP (Unadjusted FP): 270 FP

한국 SW산업협회 기준 FP당 단가 20만원을 적용하면:

270 FP × 20만원 = 5,400만원

장단점

장점: 기술에 독립적입니다. Python으로 만들든 Java로 만들든 같은 기능이면 같은 FP입니다. 사용자 관점이라 비즈니스 가치를 반영합니다. 국제 표준(IFPUG)이 있어 비교가 가능합니다.

단점: 복잡도 판단이 주관적입니다. "이 기능이 Average인가 High인가?" 학습 곡선이 있고, 비기능 요구사항(성능, 보안)을 직접 반영하기 어렵습니다.

4. 유사 프로젝트 비교

원리

"비슷한 프로젝트가 얼마에 개발되었는가?"를 참고합니다. 가장 현실적이지만, 비교 가능한 데이터를 구하기 어렵습니다.

실제 적용

개인 블로그 플랫폼의 시장 가격을 조사해보면:

WordPress 커스텀 테마 + 플러그인: 500 - 2,000만원
맞춤형 블로그 (기본 CRUD): 1,500 - 3,000만원
CMS + Admin + API (풀스택): 3,000 - 6,000만원
AI 기능 + 다국어 + 고급 에디터: 5,000 - 8,000만원

제 프로젝트는 마지막 범주에 해당하므로, 5,000 - 8,000만원 정도로 추정됩니다.

장단점

장점: 시장 현실을 직접 반영합니다. 클라이언트 설득에 효과적입니다.

단점: 정확히 같은 프로젝트는 없습니다. 비교 대상을 구하기 어렵고, 범위와 품질 차이를 정량화하기 힘듭니다.

교차 검증: 4가지 방법 비교

같은 프로젝트에 4가지 방법을 적용한 결과입니다:

방법                    결과
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
시장 시세 (미드레벨)     3,450 - 4,830만원
COCOMO II (미드레벨)    약 9,100만원
기능점수 (FP)           5,400 - 6,000만원
유사 프로젝트           5,000 - 8,000만원
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
합리적 추정 범위        4,500 - 6,000만원

흥미로운 점은 COCOMO가 압도적으로 높게 나왔다는 것입니다. 코드량 기반 모델의 특성상, 모노레포 구조나 타입 정의 파일처럼 "기능 대비 코드가 많은" 경우에 과대 추정되는 경향이 있습니다.

반면 시장 시세가 가장 낮게 나왔는데, 이는 공수 추정에서 제가 보수적으로 잡았기 때문일 수 있습니다. 실제 개발 중 삽질한 시간, 리팩토링 시간 등을 빼먹기 쉽습니다.

결국 기능점수와 유사 프로젝트 비교가 가장 현실에 가까운 결과를 보여줬습니다.

어떤 방법을 써야 할까?

상황에 따라 다릅니다.

상황                        추천 방법
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
프리랜서 견적             시장 시세 + 기능점수 교차 검증
대기업 SI 프로젝트        기능점수 (IFPUG 표준)
내부 예산 책정            COCOMO + 유사 프로젝트
스타트업 MVP              시장 시세 (빠른 추정)
분쟁/소송 상황            기능점수 (객관적 근거)

개인적으로는 2가지 이상의 방법을 교차 검증하는 것을 권합니다. 한 가지 방법만 쓰면 그 방법의 편향에 빠지기 쉽습니다.

마치며

비용 산정은 결국 "이 소프트웨어의 가치는 얼마인가?"라는 질문에 답하는 과정입니다. 완벽한 방법은 없지만, 여러 관점에서 바라보면 합리적인 범위를 찾을 수 있습니다.

제 프로젝트의 경우, 4가지 방법을 종합했을 때 4,500 - 5,500만원 정도가 합리적인 가치라는 결론에 도달했습니다. 프리랜서로 직접 계약하면 3,000만원대, 에이전시에 맡기면 5,000만원 이상.

물론 이건 "만들었을 때의 비용"이고, 실제 시장에서 팔 수 있는 가격과는 다릅니다. 하지만 최소한 "내가 만든 것의 객관적 가치"를 아는 것은, 협상에서든 자기 평가에서든 꽤 쓸모 있는 지식이 아닐까 하는 생각이 듭니다.