품질관리에 드는 비용

Code Complete를 읽다가 재미있는 문구를 발견했는데, 기존에 알고 있던 상식과는 달라 잠이 확 깼다.
요약하자면 다음과 같다.

디버깅과 리팩토링, 그리고 다른 수정 작업이 전형적인 소프트웨어 개발 주기에서 약 50% 정도의 시간을 차지한다. 오류를 예방하여 디버깅을 줄이면 생산성이 향상된다. 따라서 개발일정을 줄이는 가장 확실한 방법은 제품의 품질을 향상시키고 디버깅과 소프트웨어의 수정작업으로 낭비되는 시간을 줄이는 것이다.

뭐, 이부분은 너무나 원론적인 이야기라, "그래서?"라는 반문이 튀어나오게 한다. 그런데 나는 저 문장을 전적으로 이해하고 있었던가?

400 work year 이상의 노력과 3백만줄의 코드를 포함하는 50개의 개발 프로젝트를 검토한, NASA의 소프트웨어 공학연구실의 한 연구에서 품질 보증의 향상이 오류율은 줄여주지만 전체적인 개발 비용에 있어서 추가적인 비용이 들지 않는다는 것을 발견하였다. (Card 1987)

IBM의 연구에서도 이와 유사한 결과를 발견하였다.

결함수준이 매우 낮은 소프트웨어 프로젝트는 개발 일정도 가장 짧고 생산성이 가장 높았다. 소프트웨어 결함 제거가 실제로 소프트웨어 개발에 있어서 가장 많은 비용을 유발하고 가장 많은 시간을 낭비하는 작업형태이다.(Jones 2000)

즉, 가장 좋은 디버깅보다 차라리 결함이 적은 프레임워크가 더 낫다...라는 해석.

아래와 같은 문장도 유심히 볼 내용

... 흥미로운 결과는 프로그램을 완성하기 위해서 평균 시간이 걸린 프로그래머들이 오류가 가장 많은 프로그램을 작성한 것이다. 평균보다 많거나 적게 걸린 프로그래머들은 눈에 띄게 오류가 적은 프로그램을 작성하였다.(DeMarco & Lister 1985)

조금 삐딱한 해석으로는, 어느 수준 이하의 프로그래머들이 평균적인 시간이 걸려 프로그래밍을 한다는 뜻. 다시 말해 특정 수준 이상의 프로그래머라면, 1) 매우 신속하게 문제를 해결하거나, 2) 매우 꼼꼼하게 문제를 해결한다는 뜻... 일 수도 있다.
그런데, 이 조사결과가 보여주는 재미있는 결과는, 시간을 들여 "꼼꼼하게" 해도 신속한 해결방법보다 오류율이 적다는 건 아니라는 뜻. 반대로 해석하면 문제해결 시간은 그 문제의 오류율과는 상관없다는 뜻.

내맘대로 결론은 뭐냐하면, 지금까지 의례적으로 간트 차트에 디버깅이라고 잡아놓았던 시간을 빼버리고 차라리 그 시간만큼 품질보증예방 방법들을 선행하는 것이 더 낫다는 것.
"품질을 향상시키는 것이 개발 비용을 줄이는 일." <- 요즘 몸으로 실감함.

ps. 기억을 더듬어보니 언젠가 조엘 블로그에서도 비슷한 내용을 본 것 같다. 그때는 그냥 건성으로 지나쳤는데 오늘 보니 새롭군.