지앤선 이야기

[한글화 프로젝트] 7. 생산성은 측정할 수 없다.

지앤선 2014. 5. 9. 12:04


 



번역가 : 박성철

월간 라디오와 모형의 마이컴 강좌를 시작으로 컴퓨터 프로그래밍에 빠져서 지금까지 시간 가는 줄 모르고 살았다. 현 SK 플래닛 개발팀 팀장으로 멋진 팀원의 덕을 보며 잘 지내는 중이며 한국 SW 개발 문화를 개선하는 데 관심이 많다.

원문링크

 

 

생산성은 측정할 수 없다.

마틴 파울러 2003 8 29



소프트웨어 프로세스나 실천적인 설계 기법 같은 것을 두고 감정적으로 대립하는 토론이 많이 보인다. 이런 논쟁 대부분은 해결할 수 없는데, 소프트웨어 산업계는 소프트웨어 개발 효율성의 몇 가지 기본 요소를 측정할 능력이 없기 때문이다. 특히 생산성에 대해서는 타당한 측정 방법이 없다.


물론 생산성이라는 건 어떤 활동의 투입대비 결과를 지켜보면 측정이 가능한 게 맞다그렇다면 소프트웨어의 생산성을 측정하려면 소프트웨어 개발의 결과를 측정해야 하는데이 결과를 측정할 수 없으니 생산성도 측정할 수 없다.

 

사람들이 생산성을 측정하려고 시도해보지 않은 건 아니다코드가 몇 줄인지를 가지고 생산성을 측정하려는 연구는 짜증스럽기까지 하다우선 코드 줄 수는 언어마다 다르고세는 방식에 따라서 다르고코드를 정렬하는 규칙에 따라서 다 다르다그리고 프로그램의 코드를 세는 표준화된 방식이 있고하나의 언어를 사용하고코드가 한 가지 모양으로 자동으로 정렬된다고 해도 코드의 줄 수를 토대로 결과를 제대로 측정할 수는 없다.

 

괜찮은 개발자라면같은 기능을 정말 다양한 분량으로 작성할 수 있다는 사실을 안다게다가 잘 설계되고 정리된 코드라면중복이 없을 테니 더 짧은 것이다복사해서 붙여 넣는 프로그래밍 방식은 코드 줄 수를 엄청나게 키우면서 중복을 일으켜 설계를 망친다메서드 코드 삽입(Inline Method) 리팩터링을 지원하는 리팩터링 도구를 이용하면 쉽게 증명할 수 있다공통 메서드 호출을 메서드 코드 삽입 리팩터링으로 없애버리면 쉽게 코드 줄 수를 두 배로 늘릴 수 있다.

 

코드 줄 수로 평가하는 방법이 이미 죽었다고 생각하겠지만코드의 줄 수에 기반을 둔 생산성 연구를 거의 매달 본다심지어는 IEEE 소프트웨어 같이 인정받는 저널에서도 아직 본다.

 

코드 줄 수가 아주 쓸모가 없는 측정방법이라는 얘기는 아니다시스템의 크기를 가늠하기에는 꽤 좋다. 10만 줄의 코드로 구성된 시스템이 1만 줄의 코드로 구성된 시스템보단 클 것이라고 확신하는 건 타당하다하지만 내가 10만 줄의 시스템을 1년 동안 개발했고나잘난씨(원문에는 Joe라고 되어 있음.)가 똑같은 시스템을 같은 기간 동안 1만 줄의 코드로 개발했다고 하면 내가 더 생산적이었단 얘기는 아니다오히려 둘의 생산성은 비슷했지만 내 시스템의 설계가 훨씬 형편없다고 결론을 낼 수 있다.

 

결과를 측정할 때 자주 거론되는 다른 방법으로 기능 점수(Function Point, FP)가 있다기능 점수에 대해서는 약간은 동의하는 편이지만 그래도 이해가 되지는 않는다하나의 시스템에 대해 같은 시스템을 사용하는 여러 사람의 평가가 세 배까지 차이가 난다는 얘기를 들었다이런 측정 방법으로는 별로 도움이 되지 않는 것 같다.

 

기능 점수를 이용해 기능성을 측정하는 정확한 방법을 찾았다고 쳐도 생산성에 대해서는 놓치고 있다고 생각한다기능성 측정은 소프트웨어 개발의 직접적인 산출물을 살펴보는 방법이라고 말할 수 있는데사실 실제 산출물은 다른 것이다정확한 방법으로 FP를 측정해서 시스템을 개발한다고 가정해보자내가 1년 동안 100FP의 시스템을 나잘난씨는 1년 동안 50FP에 해당하는 시스템을 만들었다고 해서 내가 더 생산적이라고 얘기할 수 있을까나는 그렇지 않다고 본다내가 만든 100FP 중에서 고객에게 도움이 되는 기능은 30FP 정도뿐일 수도 있고나잘난씨의 50FP는 모두 고객에게 도움이 될 수도 있다그렇다면 나의 직접적인 생산성은 나잘난씨 보다 높았지만나잘난씨의 실제 생산성이 더 높은 게 아니냐고 따져볼 수 있다.

 

제프 그리그(Jeff Grigg)는 기능 점수를 구현하는 데는 내부적인 요인이 있다고 말한다. “제가 맡은 기능점수 100점짜리는 무척 유사한 기능들로 구성되어 있었지만적절하게 재사용 기법을 활용하지 못해서 개발하는 데 1년 정도의 시간이 걸렸어요나잘난씨의 기능점수 50점짜리는 (그에게 안타까운 소식이지만전부 전혀 달랐어요재사용이 거의 불가능 했죠그래도 나잘난씨는 전혀 다른 50FP를 구현하는 데재사용이 거의 불가능한데도단지 1년 만에 그걸 다 해냈어요대단하다니까요.

 

그러나 이 모든 논의에유용한 기능성조차도 진정한 측정은 아니라는 점이 간과되었다내가 30FP의 유용한 기능성을 구현해서 15FP를 달성한 나잘난씨보다 앞섰다고 해보자알고 보니 나잘난씨의 15FP는 고객에게 천만 불의 추가 수익을 가져다 줬지만 나는 오백만 불 가치만 제공했을 수도 있다이 관점대로라면 나잘난씨가 사업적인 가치를 더 냈으니 실제 생산성이 더 높지 않느냐고도 따져볼 수 있다그리고 나는 소프트웨어 개발의 생산성을 제대로 측정하려면 사업적인 가치를 고려해야 한다고 생각한다.

 

이런 생각은 성공률에 미친다소프트웨어가 성공했다고 하는 일반적인 발표는 엉터리이다사람들은 뭐가 실패인지 이해하지 못하기 때문이다. 프로젝트의 비용보다 큰 사업적인 가치를 제공해야지 성공한 프로젝트이다이런 관점에서 나잘난씨하고 내가 각각 다섯 개의 프로젝트를 진행해서 내가 네 개의 프로젝트에 성공하고 나잘난씨가 한 개의 프로젝트만 성공했다면 내가 나잘난씨보다 더 나은 결과를 낸 건가꼭 그렇지는 않다내가 진행한 성공한 프로젝트는 각각 백만 불의 수익을 냈고나잘난씨가 성공한 프로젝트 하나가 천만 불의 수익을 내서 진행한 모든 프로젝트의 수익 이상을 냈다면 나잘난씨가 승진하는 게 맞다.

 

“측정할 수 없다면 관리도 할 수 없다”고 얘기하지만 그건 변명일 뿐이다사업이란 항상 가치를 측정할 수 없는 것들을 관리하는 일이다회사의 변호사들마케팅 부서교육 조직의 생산성을 어떻게 측정하나측정할 수는 없지만여전히 관리해야 한다. (더 자세한 내용은 로버트 스틴[Robert Austin] 을 보도록 하자)

 

전체 팀의 생산성을 측정하기 어렵다면 팀원 개개인의 기여도를 측정하기란 훨씬 어렵다팀의 결과는 반복주기마다 얼마나 많은 요건(feature)을 처리했느냐로 대략 감을 잡을 수 있다정확하지 않은 방법이지만 어떤 팀의 속도가 빨라지고 있는지 아니면 다른 팀과 비교해서 생산적인지에 대해 어느 정도 감을 잡을 수 있게 해준다하지만 개개인의 기여도를 평가하기란 훨씬 더 어렵다팀원 일부는 요건을 직접 구현하고 일부는 요건을 구현하기 쉽게 지원하는 역할을 맡았다고 해보자전체 팀의 생산성을 높이도록 이바지했음에도 그 팀에 속한 개발자가 아닌 이상 지원 업무를 맡은 개발자의 결과를 알아내기란 쉽지 않다.

 

지금까지의 설명이 만족스럽지 않다면 이코노미스트지(2003 9 1319)에 생산성에 대한 동향을 정리한 기사가 있으니 참고하자경제학자들은 90년대에 컴퓨터에 투자한 덕에 사업에서의 생산성이 향상되었다고 평가하는 것으로 보인다요점은 투자에서 실제 향상까지는 시간이 걸린다는 점이다. “컴퓨터에 투자했다고 해서 바로 생산성이 높아지지는 않는다기업이 사업적인 경험을 통해서 적용법을 찾아야 한다. 전기가 발명됐을 때도 마찬가지로 이런 시간이 필요했다.

 

그러니 사업적인 가치는 측정하기 어려울 뿐 아니라 시차도 있다제작한 소프트웨어를 발표하고 나서 수년이 지나기 전에는 팀의 생산성을 측정할 수 없을지도 모른다.

 

생산성 측정이 이토록 매력적인 이유를 이해한다생산성을 측정할 수 있다면 소프트웨어를 지금 우리가 하는 것보다 훨씬 쉽고 객관적으로 평가할 수 있게 된다하지만 잘못된 측정은 상황을 더 나쁘게 만들 뿐이다이쯤에서 우리의 무지를 인정해야 할 것 같다.