박피디의 게임 아키텍트 블로그

소프트웨어 크리에이티비티 2.0 을 읽다가
작년부터 계속 고민해왔던 생각을 떠올라 써 봅니다.

작년 KGC 에서 내가 발표한 내용 중, UnitTest 도입 효과에 대해 설명한 것이 있다.
대략 다음과 같은 그림이었는데...


이 자료는 다음과 같은 방식으로 수집했다.
1. 버그 추적 도구에서 데이터를 XML 로 export 한 후
2. C# 의 XML 파서를 사용해서 디버깅 생산성 측정 프로그램을 만든 후 데이터를 분석

통계는 다음 규칙을 만들었다.
1. 버그가 처음 보고된 시간으로부터 버그를 수정한 시간까지의 평균
1-1. 우선순위가 높은 것부터 확인. 너무 우선순위가 낮은 버그는 통계에서 무시
1-2. 사례보고 같이 몇 년동안 해결되지 못한 버그도 무시
2. 버그가 발생한 횟수를 개발 분기별로 분류

'500% 생산성 증가'란 말에는 약간 과장이 있지만, (특히 레거시 코드에서는) 200% ~ 300% 이상 생산성이 증가한다고 생각한다. 이런 자료 덕분에 막연히 UnitTest 를 도입하면 생산성이 향상되고, 버그가 줄어든다더라가 아니라, 실제로 해 보니 이렇게 생산성이 향상되고 버그가 줄었다고 얘기할 수 있는 근거를 얻게 되었다.

문제는 이제부터인데,
막상 이런 식으로 디버깅 생산성 측정 규칙을 정했더니, 그 규칙에 내가 끌려다니게 되었다.
예를 들자면, 버그 추적에 아직 올라와 있지 않은 긴급한 서버 Crash 가 날 경우, 당연히 Crash 를 다른 무엇보다도 먼저 수정해야 한다. 하지만 Crash 는 버그 추적 도구 대신 개발팀에 직접 이메일로 전달되는 '시급한' 문제다보니, 이걸 고친다고 하루, 이틀 고생해 봐야, 위에서 정한 디버깅 생산성 통계만 놓고 보면 내가 아무 것도 안 한 것이 된다.
마찬가지로, 다른 사람이 버그로 고생하고 있을 때에도, '내꺼부터 빨리 수정해야지, 다른 사람 도와줘봐야 측정도 안 되고...'라는 어이없는 생각에서 벗어날 수가 없게 되었다.
(디버깅 생산성 측정 프로그램은 순전히 UnitTest 를 적용했을 때의 효과를 확인하기 위해서만 썼지, 팀원들의 생산성을 측정하는 용도 등으로는 쓰지 않았는데도 불구하고 말이다)
Crash 수정 횟수라던가 다른 사람을 도와준 횟수도 같이 기록하면 되지 않겠냐고 할 수 있겠지만, 이것 역시 누가 얼마나 공헌했는지를 알기도 어렵고, 이렇게 모든 걸 다 기록하기 시작하면, 어느새 작업량보다 측정을 위한 일이 더 많아지게 된다.

그래서...? 당장 디버깅 생산성 측정 프로그램을 폐기해 버렸다. ㅎㅎ
이렇게 하고 나니, 마음이 편안해지고, 다시 팀에서 가장 중요한 일을 먼저 할 수 있는 마음가짐을 가질 수 있게 되었다.

시간당 LOC(line of code) 를 기록하는 회사도 있다고 하는데, 누가 하루 종일 고민해서 대박 버그를 찾아내 고쳤는데, LOC 만 놓고 보면 시간당 1 라인을 작업했다고 나와서, 관리자가 왜 이리 일을 안 하냐고 다그쳤다는 얘기도 있다.

개발자의 생산성은 어떻게 측정하더라도, 거기에 맞춰 사람들이 최적화되기 때문에, 가능하면 하지 않는게 좋다. 생산성을 측정하겠다면, 그 목적이 사람들을 평가하기 위해서가 아니라, 팀 개발 프로세스 중 어디에서 생산성을 더 높힐 수 있는지를 확인하고, 변경한 프로세스가 이전보다 생산성을 얼마나 높혀주었는지를 확인하는 목적에만 써야 한다. 그렇지 않고, 어떻게든 사람을 평가하기 위해 측정 방법을 도입한다면, 개발자들은 그에 맞춰 배신게임을 할 것이다.