맨먼스(M/M) 견적이 예외인 이유: SW 개발비 산정의 원칙은 기능점수

(투입인력수 × 투입기간 × 기술자직무별단가) + 제경비 + 기술료 + 직접경비.

이것이 투입공수 방식으로 소프트웨어 개발비를 구하는 공식입니다. 한국소프트웨어산업협회가 공표하는 「SW사업 대가산정 가이드」에 그대로 적혀 있습니다. 식을 천천히 다시 읽어 보면 이상한 점이 하나 있습니다. 만들어지는 것이 한 번도 나오지 않습니다.

공식에 산출물이 한 번도 등장하지 않는 계산

몇 명이 몇 달 동안 얼마짜리 단가로 앉아 있었는지가 전부입니다. 화면이 몇 개인지, 어떤 기능이 들어가는지, 사용자가 무엇을 할 수 있게 되는지는 이 식에 들어갈 자리가 없습니다.

맨먼스(M/M)를 "일의 양을 재는 단위"로 알고 쓰는 경우가 많은데, 정확히는 투입을 재는 단위입니다. 같은 3맨먼스짜리 프로젝트가 화면 열 개를 내놓을 수도 있고 세 개를 내놓을 수도 있는데, 견적서에는 둘 다 3맨먼스로 적힙니다. 그리고 발주자가 받는 것은 맨먼스가 아니라 화면입니다.

원칙은 기능점수, 예외가 투입공수라는 순서

많이들 반대로 알고 있는 부분이 여기입니다. 가이드의 문장은 이렇습니다.

소프트웨어 개발비 산정은 소프트웨어 개발규모를 기능점수(FP; Function Point)로 측정하고 기능점수당 단가를 곱하여 비용을 산출하는 기능점수 방식을 원칙으로 한다. 다만, 기능점수 방식의 적용이 어려운 특별한 경우에는 해당 사업의 과업내용, 특징 등을 고려하여 발주자의 판단에 의해 투입공수에 의한 방식(으로 산정할 수 있다) (SW사업 대가산정 가이드)

"원칙으로 한다"와 "특별한 경우"입니다. 맨먼스가 기본이고 기능점수가 정교한 대안인 것이 아니라, 기능점수가 기본이고 맨먼스는 그것이 곤란할 때 쓰는 우회로입니다. 같은 가이드의 다른 대목은 투입공수를 "기능점수 방식의 적용이 곤란한 특정 사업 유형에 한하여 적용 가능"이라고 더 못 박아 둡니다.

기능점수가 원칙인 데는 이유가 있습니다. 가이드는 기능점수를 ISO/IEC 14143(기능 규모 측정)으로 정해진 국제표준이라고 밝힙니다. 국내 가이드가 선호하는 방식이라서가 아니라, 소프트웨어의 크기를 재는 방법으로 국제적으로 합의된 규격이 있고 그것을 따르고 있는 것입니다. 반면 맨먼스에는 그런 규격이 없습니다.

가이드 스스로 「경험적 판단」이라고 적어 둔 방식

더 직설적인 문장도 있습니다. 가이드는 투입공수 방식을 이렇게 정의합니다. "과거의 유사 소프트웨어 개발 사업의 투입인력 정도를 기초로 한 경험적 판단에 의해 사업대가를 산정하는 방식."

공식 문서가 자기 방법을 "경험적 판단"이라고 부르는 경우는 드뭅니다. 이 표현이 인정하는 것은 맨먼스 견적에 측정이 없다는 사실입니다. 비슷한 프로젝트에 몇 명이 몇 달 붙었는지를 떠올려 그만큼 잡는 것이고, 그 떠올림이 맞는지 확인할 장치는 방법 안에 없습니다.

이게 맨먼스 견적이 나쁘다는 뜻은 아닙니다. 다만 그 숫자를 근거처럼 제시할 때는 근거의 성격을 알고 있어야 합니다. 3맨먼스라는 숫자는 측정값이 아니라 추정치이고, 그 추정의 출처는 과거 기억입니다.

공급자가 재는 투입과 수요자가 받는 기능

기능점수 쪽을 보면 차이가 선명해집니다. 가이드는 기능점수의 성격을 이렇게 적습니다. 소프트웨어가 "어떻게 구현되었는지"의 공급자 관점이 아니라 사용자가 "어떠한 기능을 요구했는지"의 수요자 관점에서 측정한다는 것입니다.

두 방식이 서 있는 자리가 반대입니다.

	기능점수	투입공수(M/M)
재는 대상	사용자가 받는 기능	우리가 넣는 사람과 시간
관점	수요자	공급자
측정 시점	개발 이전에 가능	유사 사업의 기억에 의존
구현 기술과의 관계	무관하게 일관 측정	기술·인력에 따라 변동

가이드가 기능점수의 장점으로 꼽는 항목 중 하나가 "조직, 구현 기술, 공수, 적용 방법론과 무관하게 일관성 있게 측정"입니다. 여기서 공수가 명시적으로 빠져 있다는 점이 중요합니다. 같은 기능을 누가 얼마나 빨리 만들든 기능점수는 같습니다. 맨먼스는 정반대로, 느린 팀일수록 커집니다.

맨먼스가 같아도 결과물이 달라지는 이유

이 구조에서 이상한 유인이 나옵니다. 맨먼스로 값을 매기면 오래 걸릴수록 비싸게 팔립니다. 재사용 자산을 쌓아 두거나 도구를 잘 써서 절반의 시간에 끝내면, 결과물은 같은데 받는 돈은 줄어듭니다.

같은 일이 반대 방향으로도 작동합니다. 발주자 입장에서 맨먼스 견적은 검증하기 어렵습니다. 5맨먼스가 왜 5맨먼스인지 물어도 "이 정도 규모면 보통 그렇습니다" 이상의 답을 받기 어렵고, 그 답의 근거가 앞서 본 "경험적 판단"이기 때문입니다.

반복되는 화면을 모듈로 만들어 두는 쪽이 유리한지 불리한지는 견적 단위가 정합니다. 기능점수로 세면 자산을 쌓을수록 이익이 남고, 맨먼스로 세면 자산을 쌓을수록 매출이 깎입니다. 같은 회사가 같은 일을 해도 그렇습니다.

1M/M을 21M/D로 환산할 때 사라지는 것들

가이드에는 환산 기준도 적혀 있습니다. 현재 기준으로 1M/M은 21M/D이고, 이 값은 매년 바뀔 수 있어 협회가 공표하는 「SW기술자 임금실태 조사」 최신 결과를 봐야 합니다.

한 달을 21일로 놓는다는 뜻인데, 이 환산이 성립하려면 스물한 날이 서로 같아야 합니다. 실제로는 그렇지 않습니다. 요구사항이 확정된 날과 회의로 반쯤 날아간 날과 다른 프로젝트 장애로 빠진 날이 모두 1M/D입니다. 투입 단위의 한계가 여기서 한 번 더 드러납니다. 시간은 정확하게 세지만 그 시간에 무슨 일이 일어났는지는 세지 않습니다.

가이드에 실린 포털 개발 예시를 보면 계산이 어떻게 굴러가는지 보입니다. 업무분석 21M/D, SW아키텍처 84M/D, 응용SW개발 105M/D, UI/UX개발 84M/D로 직무별 공수를 잡고, 이를 21로 나눠 각각 1·4·5·4M/M으로 바꿉니다. 여기서 확인할 수 있는 것은 이 숫자들이 포털의 무엇을 만드는지와는 무관하게 적혔다는 점입니다. 같은 표를 쇼핑몰 개발에 붙여도 형식은 그대로 성립합니다.

그럼에도 작은 외주에서 맨먼스가 살아남는 조건

그러면 맨먼스 견적을 버려야 하는가. 저는 그렇게 보지 않습니다. 기능점수를 제대로 측정하려면 요구사항이 기능 단위로 정리돼 있어야 하는데, 계약 전에 그 수준까지 정리된 중소기업 프로젝트는 드뭅니다. 측정할 대상이 없는 상태에서 측정 방식을 고집하면 견적 자체가 안 나옵니다.

그래서 실무에서는 맨먼스를 쓰되 성격을 정확히 알고 쓰는 쪽이 현실적입니다. 저라면 두 가지를 붙이겠습니다. 맨먼스 숫자 옆에 그 맨먼스로 만들어지는 산출물 목록을 같이 적는 것, 그리고 그 목록이 늘어나면 맨먼스도 늘어난다는 연결을 계약서에 남기는 것입니다. 산출물이 붙는 순간 맨먼스는 투입 단위가 아니라 범위의 대리 지표가 됩니다.

한 사람이 여러 역할을 겸하면 맨먼스 계산이 더 흔들린다는 문제는 프로젝트 멤버를 다룬 글에서 다른 각도로 짚었습니다. 그쪽이 사람을 몇으로 나눌 것인가의 문제라면, 이쪽은 일을 무엇으로 셀 것인가의 문제입니다. 두 질문의 답이 어긋나 있으면 견적서의 숫자와 실제로 벌어지는 일이 따로 놉니다.