opinion, Uncategorized

기능 점수(Function Point) 유감

2005년의 일입니다. 군사업에서 당시 업계 표준이었던 EJB 대신에 Spring이라는 오픈소스를 도입해서 (EJB 악몽을 피해) 프로젝트 성공을 경험한 일이 있습니다. 아직 주니어(엔지니어)였던 저를 사장님이자 총괄 아키텍트였던 제 첫 직업적 멘토님께서 니가 원하는대로 하라고 기회를 주셔서 당시 저를 위협하던 선배 개발자와 엔지니어들의 탄압(?)을 이겨내고 모두가 행복한(다시 말해 야근이 거의 없는) 프로젝트로 마칠 수 있었습니다. 성공 요인을 말하자면, 길게 써야하지만 이 글의 주제와는 동떨어져서 이 정도로 각설하죠. 아무튼 성공적인 프로젝트를 했는데, 문제가 하나 발생했죠.

 

그것은 바로 세금을 쓰고, 국가 안보가 걸린 군사업 특성상 엄격한 검수를 거치는데 사전에 EJB 기준으로 산정한 결과물의 양 다시말해 코드 라인수가 Spring 탓에 순수 자바 객체(Pojo)를 쓰느라 턱없이 줄어든 것입니다. 라인 수가 줄었다는 것은 생산성은 물론 유지보수가 용이한 이점이 있지만, 당시 검수하는 시각에서는 계획 대비 실적이 저조한 것으로 해석되었습니다. 그래서, 당시 일시적으로 검수기간에는 코드량을 늘리는 일을 했던 추억의 에피소드가 있습니다.

 

10년의 세월이 흐른 지금은 그런 일을 다시 겪을 수 없었습니다. 그런데, 몇 일전 술자리에서 잊혀진 단어인 Function Point(기능 점수) 때문에 유사한 해프닝을 겪는 이야기를 들었습니다. 무려 2016년에 말이죠. 주인이 없는 회사인 공공사업은 세금을 써야 하니 말이 되지 않아도 객관적인 기준이 필요합니다. 그래서, 기능 점수가 좋은 도구는 아니지만 (마지못해) 필요성을 인정합니다. 하지만, 제 경험에서는 5~6년 전에 통용되던 ‘말이 안되는 객관적인 기준’이 바로 Function Point입니다. 그런데, 그것을 공공사업도 아닌 민간기업에서 아직도 쓰고 있다니 안타까웠습니다. 그것은 회사의 주인 즉, 오너도 주주도 손해만 볼 뿐인 도구이고, 시스템 사용자에게도 아무런 도움을 주지 않는 무미건조한 기준일 뿐이니까요. 더군다나 그걸 기준으로 기획과 구매 등의 집행을 해야 하는 분은 정말 답이 없는 일에 답을 내는 고통스런 업무를 맡게 되거든요.

 

그래서, 하고 싶은 말은… 제발 그런 도구는 검토해주시면 좋겠습니다. 공공사업이라면 제가 그 사정을 몰라 잘 모르겠지만, 적어도 주인이 있는 회사 즉, 민간기업에서 ‘기능 점수’나 ‘Function Point’를 쓰는 일은 어떤 말로 비난해도 과하지 않다고 생각합니다. 그런 일은 일을 가장한 일 코스프레라도 말하고 싶을 정도로 말이죠.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중