김대중 전 대통령 서거 추모글 남기기

2010년부터는 공공발주 모든 IT사업이 펑션포인트(Function Point, 이하 FP)로 발주가 된다고 한다.
IT분야에서 나름 경험을 했다고 하면 대략 FP가 뭔지 안다. FP란 기능점수다.
시스템에 필요한 기능 목록을 나열하고, 각 기능별 구축 난이도의 점수를 매기고, 그래서 결과값을 얻는다.
이 결과값은 구축 비용 산정에 직접적으로 이용한다.

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

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

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

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

** SLA의 사전적 의미
기업이 정보 제공자(IP)와 주고받는 서비스의 품질에 관한 계약에 사용되는 보증서. 원래는 프레임 중계 서비스 등을 제공하는 통신 사업자가 이용자에 대해서 광역 통신망(WAN) 트래픽의 전송 품질을 보증하는 계약을 가리켰다. 서비스 레벨 보증서의 목적은 객관적인 평가 기준을 도입함으로써 통신망과 관련된 비용을 경감하는 데 있다. 그러므로 목표치를 설정해서 필요한 데이터를 수집, 관리한다. 통신망 관리인 경우에는 가용성(availability)이나 트랜잭션 처리 시간, 접속 실패율 등의 기준치를 미리 설정한다.
-- DAUM 백과사전 참조 --

이와 같은 사상을 받아들여, 현재 공공기관 및 대형 금융 고객을 위시한 수많은 고객들이 FP 방식 및 SLA 방식을 도입하고 있다.
그런데 과연 진짜로 고객들은 FP를 도입했느냐?
실제 업체 선정후 계약과 함께 프로젝트에 들어가게 되면, 기능점수를 말하는 사람이 있는가?
고객이 가장 먼저 물어보는 말은 : 몇 MM이 투입되었습니까? 이다.

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

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

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

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

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

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

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

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

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

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

"제안서는 제안서고, 일은 일 대로 해야될 것이 아니냐. 지금 우리한테 계약가지고 협박하는거냐."
"또다른 일례를 들자면, 제안서는 계약서의 일부이니 제안서상의 범위대로 해달라고 한다..."

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

2010년 올해부터 공공기관 발주 SI 사업이 FP 기반으로 예산 산정과 관리를 한다고 하니...
정말 다시금 FP의 원래 취지를 잘 알고 예산 수립에서부터, 발주, 계약, 구축, 준공, 유지보수까지 모든 측면에서
하나로된 지침으로 관리되었으면 하는 바램이다.

** 개인적으로 작게나마 희망이 보이는 사례 하나 **
00공기업의 감사실의 감사원 담당자(본인의 업무와는 전혀 상관없는)를 알게되어 이런 저런 이야기를 하게 되었다..
IT분야에는 잘 알지 못하는 분이지만, 00공기업의 IT예산의 부실한 집행과 관행적 이행에 따른 예산 낭비가 심각하다.
이를 위해서는 FP방식(이 방식의 적정성이 검증되었던 되지 않았건 간에)으로 진행해야 한다는 생각을 하시는 분도 있었다.
IT분야에 대해 전혀 알지 못하는 분이면서도 소프트웨어 기준에 대해 많은 고민을 하고 계신분이였다.


** 출처 :: 인터넷 여기저기와 개인적 의견 첨언...
Posted by comshin
,