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

번역가 : 박성철 월간 라디오와 모형의 마이컴 강좌를 시작으로 컴퓨터 프로그래밍에 빠져서 지금까지 시간 가는 줄 모르고 살았다. 현 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월 13–19)에 생산성에 대한 동향을 정리한 기사가 있으니 참고하자. 경제학자들은 90년대에 컴퓨터에 투자한 덕에 사업에서의 생산성이 향상되었다고 평가하는 것으로 보인다. 요점은 투자에서 실제 향상까지는 시간이 걸린다는 점이다. “컴퓨터에 투자했다고 해서 바로 생산성이 높아지지는 않는다. 기업이 사업적인 경험을 통해서 적용법을 찾아야 한다.” 전기가 발명됐을 때도 마찬가지로 이런 시간이 필요했다.

 

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

 

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