요즘은 웬만하면 펑션포인트(Function Point)가 대세다. 경력이 조금 있는 개발자라면 펑션포인트가 뭔지 안다. 펑션포인트란 기능점수다. 시스템에 필요한 기능 목록을 나열하고, 각 기능별 구축 난이도의 점수를 매기고, 그래서 결과값을 얻는다. 이 결과값은 구축 비용 산정에 직접적으로 이용한다.

해외에서 펑션포인트의 도입 배경은, 기존의 인력 소요 또는 코드라인수에 따른 비용산정 방식을 실제 구축물량 기준으로 대체하기 위해서이다.

SI 사업은 건축과 마찬가지로 연인원 또는 월인원 (소위 Man Month) 으로 계산해왔다. XX 시스템을 구축하기 위해서는 총 250 맨몬스가 필요하다는 식으로 말한다. 250 MM 이란 월 25명씩 10개월, 또는 월 50명씩 5개월이 투입된 프로젝트를 수행해야 목표 시스템을 구축할 수 있다는 뜻이다.(또는 외국에서는 코드라인수로 계산했다고 한다.)

이러한 방식의 문제점은 실제 목표시스템 구축을 위해 필요한 정확한 소요를 알 수 없다는 것이다. 투입인원 및 코드라인은 <투입량>이다. 하지만 비용은 <투입>에 근거하는 것이 아니고 <산출>에 근거해야한다. 백명이 하든 천명이 하든 정해진 시간에 정해진 품질의 제품을 인도하면 되는 프로젝트의 기본 개념에 맞지 않다.

이런 문제점을 극복하기 위해 개발된 것이 투입 인력 기준이 아닌 물량 산정 방식이다. 펑션포이느는 정보시스템이 요구하는 기능, 연계 기능, 데이터베이스 등에 대해 검토해서 물량을 산정한다. 비용은 물량 기준으로 책정된다. 백명이 만들든 이백명이 만들든 그것은 중요하지 않다. 지정된 물량만 산출이 되면 된다. 이러한 사상이 SI 쪽으로 적용되면 펑션포인트이고, SM 쪽으로 적용되면 SLA (서비스 레벨 어그리먼트)가 된다.

이와 같은 사상을 받아들여, 현재 공공기관 및 대형 금융 고객을 위시한 수많은 고객들이 펑션포인트 방식 및 SLA 방식을 도입하고 있다. 그런데 과연 진짜로 고객들은 펑션포인트를 도입했느냐? 도입되긴 개뿔. 프로젝트에 들어갔을 때, 기능점수를 말하는 사람이 있는가? 고객이 가장 먼저 물어보는 말은 : 몇 MM이 투입되었습니까? 이다.

자, 이렇게 되게 된 배경은 무엇인가?  

펑션포인트의 실체를 본 사람이라면 누구나 안다. 이것은 단순하게 기능을 대충 나열한 것이 아니다. 펑션포인트는 아키텍쳐의 관점에서 말하자면 어플리케이션 아키텍쳐(Application Architecture, 이하 AA)이다. 구축하고자 하는 업무 아키텍쳐를 구조화하고 공통화하며 업무 절차를 소화할 수 있는 정보시스템의 기능을 체계화한 것이 AA의 기능 트리이다. AA에서 가장 중요한 골격이다. AA의 기능트리를 구현 난이도에 따라 다시금 분류한 것이 펑션포인트이다.

기능트리 구축을 위해서 선행되어야 하는 것은 업무 분석이다. 고객의 업무 절차를 알아야 하고, 고객의 요구사항을 알아야 한다. 이 과정은 정보시스템 개발에 있어서 가장 중요하다. 이것은 방향을 잡는 일이다. 시작에서 1cm가 어그러지면 종착역에서는 10m 가 어그러지기 때문이다. 업무 분석은 시스템 담당자 뿐만 아니라 현업의 지속적인 참여가 필요하다.

프로젝트의 단계가 <요구수집 --> 요구 분석 --> 설계 --> 개발 --> 테스트 --> 전환> 정도의 단계로 구분된다고 할 때, 제대로 된 펑션포인트가 나올 수 있는 단계는 최소한 요구수집과 요구분석이 끝난 단게이다. 업무 분석이 안 되면 요구분석이 될 수 없고, 요구분석이 되지 않으면 제대로 된 기능트리가 나오지 않는다. 제대로 된 기능트리 없이 펑션포인트를 구축한다는 것은 말이 안된다.

실제 외국의 사례를 예로 들겠다. 외국에서는 제안서 작성에도 돈을 낸다는 이야기는 많이 알려져있다. 그런데 제안서 작성에 돈을 내는 이유는 막연히 제안 업체의 노력을 가상히 여겨서 그들이 허공에 삽질한 제안 비용을 보상하기 위해서가 아니다. 당연하다. 노력에 대해 보상해주는 것은 자본주의 사회에서 통하지 않는다. 결과에 대한 보상이다.

그렇다. 제안서는 바로 요구수집과 요구분석의 결과이다. 고객과 인터뷰하고 요구사항을 수집하며 분석하고 사업 발주 담당자에게 확인을 받아서, 그들이 필요로 하는 정보시스템을 정확하게 형상화하고, 그러한 정보시스템을 구축하기 위해 필요한 상세한 자원과 일정에 대한 계획을 세우는 것이 제안서이다.

미주권에서 소프트웨어 제안서는 PM과 치프 아키텍트(Chief Architect), 두 사람이 투입된다. PM은 인력 및 일정에 대한 책임을 진다. 그리고 치프 아키텍트(우리나라에서는 그 직책 자체가 생소한 이름이다만)는 업무 요구사항 분석 결과를 통해 Function Point를 만든다. 두 사람의 밀접한 협업의 결과로 산출되는 것이 제안서이다. 제안서에는 만들어질 물량 및 기한, 그리고 이를 바탕으로 산출된 비용이 명기된다. 이러한 제안이 받아들여져서 사업이 착수된 이후에는 변경관리에 들어간다. 아키텍트나 PM의 실수로 인해 프로젝트 투입 자원이 증가하는 경우, 투입업체에서 손해를 책임진다. 고객이 예전의 요구사항을 번복하는 경우에는 고객이 책임을 진다. 이것이 바로 서양인이 계약에 목숨을 거는 방식이다. 실제 사업수행은 여기에서 시작된다.

우리나라의 현실을 보자면..... 한숨만 나온다. 우리나라 펑션포인트는 백프로 통박으로 만든다. 법적 구속력도 없고 계약으로서의 효력도 없다. 다만 정해진 예산에 대한 근거를 만들기 위해서만 사용되는 것이 펑션포인트이다. 펑션포인트에 항목 몇 개 넣고 빼서 주어진 액수에 맞춘다. 결국 펑션포인트를 만들기 위해 수행업체 및 발주업체 (또는 기관)의 업무만 늘어난 셈이다. 당연하게도 펑션포인트를 만드는 과정에서 고객의 개입은 없다. 그냥 손 닿는대로, 발 닿는대로 만든다. 고객에게 몇 마디 물어보면 해결될 문제인데, 규정상 (예를 들면 RFP 발송 이후 고객업체를 만날 수 없다) 고객과의 커뮤니케이션은 불가능하다. 그래서 수행업체는 추리소설을 쓴다. 물론 아무도 읽지 않는 추리소설이다.

그것은 펑션포인트에 아무런 법적 구속력이 없기 때문이다. 물론 더 본질적인 원인은, 법적 구속력이 있다고 해도 <을>에게만 있기 때문이다.

펑션포인트는 할려면 제대로 해야 한다. 그렇지 않으면 상호간의 업무만 배가시킬 뿐이다. 언젠가 모 공공기관에서 프로젝트에 투입되었는데, 공무원이 이렇게 말했다.

"제안서는 제안서고, 일은 일 대로 해야될 것이 아니냐. 지금 우리한테 계약가지고 협박하는거냐."

그저 한숨만 나온다. 관련 체계가 법으로 명문화되면 좋겠다.

Posted by 삼천포

티스토리 툴바