규모·비용 추정의 가정

신청 함수가 20줄이니 프로젝트 전체도 하루면 끝나리라는 판단은 정책을 합의하는 시간, 저장 오류를 다루는 시간, 확인하는 시간을 모두 놓친 것입니다. 만들 대상의 양을 규모(size), 거기에 들어가는 작업량을 노력(effort), 시작부터 끝까지 흐른 시간을 기간(duration)이라고 하며, 셋은 서로 관련되지만 같은 값이 아닙니다. 이 글에서는 규모와 노력을 추정하는 여러 방법이 각각 무엇을 근거로 삼는지 정리하고, 추정값과 함께 어떤 가정을 남겨야 하는지 다룹니다.

무엇을 기준으로 셀까

코드 줄 수(lines of code, LOC)는 규모를 코드의 줄 수로 나타냅니다. 하지만 빈 줄과 주석, 자동으로 생성한 코드를 셀지, 어떤 언어로 어떻게 썼는지에 따라 값이 크게 달라집니다. 같은 동작을 한 줄로 압축했다고 해서 노력이 줄었다고 결론 내릴 수는 없습니다.

기능점수(function point, FP)는 사용자가 보는 입력, 출력, 조회, 데이터 같은 기능을 정해진 규칙에 따라 분류하고 점수를 매겨 규모를 평가합니다. 단순히 버튼이나 API의 개수를 세는 것과는 다르며, 시스템의 범위를 어디까지로 보았는지, 기능을 어떻게 분류했는지, 어떤 가중치 규칙을 적용했는지를 함께 남겨야 다른 추정과 비교할 수 있습니다. 이 글은 실제 프로젝트의 공식 기능점수를 산정하지 않으며, 계산 방법은 범위에서 기능점수까지에서 다룹니다.

유사 프로젝트 추정(analogy-based estimation)은 비슷한 과거 프로젝트의 실제 기록을 가져와 지금의 범위와 무엇이 다른지 비교합니다. 델파이 기법(Delphi technique)은 여러 전문가의 판단을 서로 영향을 주지 않게 따로 모은 뒤, 값이 차이 나는 이유를 나누며 여러 차례 조정하는 방법입니다. 여러 사람이 근거 없는 같은 숫자를 되풀이한다고 그 숫자가 정확해지지는 않습니다.

사용자 기능을 종류별로 나누어 본다

기능의 규모를 세려면 먼저 이번 소프트웨어가 무엇을 관리하는지 범위를 정해야 합니다. 독서 모임 앱이 모임과 참가 관계를 관리하고, 회원의 자격 정보는 바깥의 회원 시스템에서 조회만 한다고 가정해 봅시다. IFPUG 방식의 기능점수는 사용자 기능을 다음 다섯 종류로 나누며, 이 측정 방법은 ISO/IEC 20926 표준 소개에서 확인할 수 있습니다.

여기서 "파일"은 실제 JSON 파일의 개수가 아니라 사용자에게 의미 있는 논리적인 데이터 묶음을 가리킵니다. 같은 데이터를 백업 파일 두 개에 나누어 저장했다고 사용자 기능이 두 배가 되지는 않으며, 웹 화면과 명령줄이 같은 취소 처리를 부른다면 화면의 수만큼 따로 세지도 않습니다. 실제로 산정할 때는 범위를 정하는 기준, 기본 처리를 구별하는 규칙, 데이터의 분류, 복잡도 규칙까지 더 확인해야 합니다. 원자료에 나오는 기능점수의 가중치와 보정 계수, COCOMO의 계수표도 지금의 프로젝트에 그대로 적용하지 않으며, 이 글은 논리적인 기능과 물리적인 코드의 차이, 그리고 단위와 가정과 민감도를 먼저 다룹니다.

경험 모형의 쓰임과 한계

COCOMO(constructive cost model) 같은 비용 모형은 코드의 규모와 프로젝트의 특성을 넣어 노력을 추정하는 식입니다. 처음 나온 모형과 그 뒤의 개정판은 식과 계수가 서로 다르며, 퍼트넘(Putnam) 모형처럼 규모와 생산성, 인력과 기간의 관계를 다루는 다른 모형도 있습니다. 이런 모형은 과거 프로젝트의 자료로 만든 것이므로, 지금 조직의 실제 기록으로 보정하지 않은 식을 이 프로젝트의 확정 일정으로 쓰지 않습니다.

다음 코드의 앞부분은 노력이 규모의 거듭제곱에 비례하는 지수형 모형에서 규모가 두 배가 되면 노력이 몇 배가 되는지 보는 가상의 계산입니다. 계수 3과 지수 1.2는 설명을 위해 정한 값으로, COCOMO의 공식 계수나 이 교재를 만드는 데 든 노력과는 관계가 없습니다. 뒷부분은 낙관적인 값, 가장 가능성 높은 값, 비관적인 값으로 기대값을 구하는 세 점 추정(three-point estimation)입니다.

function toyEffort(size, coefficient, exponent) {
  return coefficient * size ** exponent;
}

const first = toyEffort(2, 3, 1.2);
const doubled = toyEffort(4, 3, 1.2);
console.log("규모 2배일 때 노력의 배수:", (doubled / first).toFixed(2));

function threePoint(optimistic, mostLikely, pessimistic) {
  const expected = (optimistic + 4 * mostLikely + pessimistic) / 6;
  const spread = (pessimistic - optimistic) / 6;
  return { expected, spread };
}

const { expected, spread } = threePoint(2, 4, 12);
console.log("기대값:", expected.toFixed(2), "표준편차 근사:", spread.toFixed(2));

규모 2배일 때 노력의 배수: 2.30
기대값: 5.00 표준편차 근사: 1.67

**는 거듭제곱 연산자로, size ** exponent는 size의 exponent제곱을 계산합니다. 지수가 양의 정수이면 size를 그 횟수만큼 곱한 값과 같고, 이 예제의 1.2처럼 정수가 아닌 지수도 쓸 수 있습니다. 지수가 1보다 크면 규모가 두 배일 때 노력은 2의 1.2제곱, 약 2.30배가 되어 정확히 두 배보다 커집니다. 규모가 커질수록 사람 사이의 소통과 통합에 드는 노력이 늘어난다는 가정을 식으로 나타낸 것이며, 이 식이 그런 값을 냈다고 현실이 반드시 그렇게 되는 것은 아닙니다.

세 점 추정은 PERT에서 쓰는 방식으로, 가장 가능성 높은 값에 4배의 무게를 두어 평균을 냅니다. 낙관 2일, 보통 4일, 비관 12일이면 기대값은 5일로 가장 가능성 높은 값인 4일보다 큰데, 비관적인 쪽으로 길게 늘어진 위험이 기대값을 끌어올렸기 때문입니다. 표준편차의 근사인 (비관 - 낙관) / 6은 추정이 얼마나 불확실한지를 함께 보여 주므로, 기대값 하나만 적지 않고 이 폭과 각 값의 이유를 함께 남깁니다.

더 깊이: COCOMO II.2000의 실제 식

앞의 계수 3과 지수 1.2는 설명용이었지만, 실제 모형도 같은 모양의 식을 씁니다. USC 소프트웨어공학 센터의 COCOMO II 모델 정의 매뉴얼에 따르면, COCOMO II.2000의 아키텍처 이후(Post-Architecture) 모형은 노력을 사람-월(person-month, PM) 단위로 A × Size^E × (노력 승수의 곱)으로 계산하고, 규모는 천 줄 단위의 코드(KSLOC)로 넣습니다. 계수 A는 이 모형의 데이터베이스에 든 161개 프로젝트의 실제 값으로 보정한 2.94이고, 곱하는 노력 승수(effort multiplier)는 16개입니다.

지수 E는 고정값이 아니라 B + 0.01 × (다섯 규모 인자의 합)으로 정하며 B는 0.91입니다. 다섯 규모 인자(scale factor)는 비슷한 일을 해 본 정도(PREC), 개발 방식의 유연성(FLEX), 아키텍처와 위험의 해소(RESL), 팀의 결속(TEAM), 프로세스 성숙도(PMAT)입니다. 매뉴얼의 값으로 노력 승수를 모두 보통(1.0)에 두고 계산하면, 모든 인자가 가장 좋은 100 KSLOC 프로젝트는 E가 0.91이 되어 약 194 PM이지만, 모든 인자가 가장 나쁘면 E가 1.226이 되어 약 832 PM이 나옵니다. 같은 규모에서도 팀과 프로세스의 사정에 따라 노력이 네 배 넘게 달라지는 것이며, 매뉴얼이 자기 조직의 실제 기록으로 모형을 다시 보정하는 방법을 따로 한 장으로 다루는 것도 이 때문입니다.

추정 기록에 남길 것

추정값은 그 값이 나온 가정과 함께 남겨야 나중에 다시 검토할 수 있습니다.

추정에는 범위와 폭을 함께 적고, 아직 확인하지 않은 작업에 정확한 완료 날짜를 붙이지 않습니다. 사람을 두 배로 늘린다고 기간이 절반이 되지 않는 이유도 여기에 있습니다. 작업 사이의 의존 관계는 사람을 늘려도 줄지 않고, 사람이 늘수록 서로 맞추어야 할 소통의 경로도 늘어나기 때문입니다.

정리

• 규모는 만들 대상의 양, 노력은 들어가는 작업량, 기간은 흐른 시간이며 서로 다른 값입니다.
• 코드 줄 수는 언어와 세는 규칙에 따라 크게 달라지고, 기능점수는 사용자가 보는 기능을 규칙에 따라 분류해 규모를 평가합니다.
• 유사 프로젝트 추정과 델파이 기법은 판단의 근거와 차이의 이유를 남길 때 쓸모가 있습니다.
• COCOMO 같은 경험 모형은 실제 기록으로 보정하지 않으면 확정 일정으로 쓸 수 없으며, 지수형 모형은 규모가 커질수록 노력이 더 빨리 늘어난다는 가정을 담습니다.
• 추정에는 범위, 가정, 근거, 불확실성의 폭, 다시 추정할 시점을 함께 남깁니다.

연습 문제

1. 화면이 늘면 기능도 늘까

웹의 취소와 앱의 취소가 같은 사용자 요구와 처리, 데이터를 함께 씁니다. 이 밖에 신청, 단순한 명단 조회, 참가율을 계산한 출력이 있고, 앱이 관리하는 논리적인 데이터 묶음 하나와 바깥에서 관리하는 참조 데이터 묶음 하나가 있습니다. 이 가정에 따라 EI, EO, EQ, ILF, EIF의 개수를 구하고, 그 합을 곧바로 기능점수라고 부를 수 없는 이유를 설명하세요.

2. 줄 수가 늘었는데 품질은 좋아졌다면

아이디 검사와 테스트를 추가했더니 코드 줄 수가 늘었습니다. 팀은 "한 일에 비해 코드가 늘었으니 생산성이 나빠졌다"고 판단했습니다. 이 비교에서 빠진 것과 더 알맞은 판단 근거를 제시하세요.

3. 세 점 추정의 해석

저장 기능의 작업 기간을 낙관 3일, 보통 5일, 비관 19일로 추정했습니다. 기대값과 표준편차의 근사를 구하고, 이 결과를 보고 무엇을 먼저 해야 할지 제안하세요.

규모와 노력을 추정하는 일과 일정을 계산하는 일은 다릅니다. 다음 글 일정·의존성·위험에서는 작업 사이의 의존 관계가 전체 기간을 어떻게 바꾸는지 계산해 봅니다.