아래는 모두 필자 개인의 생각임을 미리 밝힌다.
우리나라에서 SW산업은 그 역사가 짧다. 그래서 아직 제대로 된 체계가 잡혀있지 않다.
또한 SW 프로젝트에 대한 성과를 측정하는 방법 또한 체계적으로 정리되어 있지 않은 관계로, SW쪽 경력을 가지고 승진을 하는 것도 쉽지 않은 것이 현실이다.
(SW쪽에서 대단한 일을 했다고 내세울 수 있고 받아 들여질 수 있는 판단 기준이 정립되어 있지 않기 때문이다.)
이련 현상은 SW개발이 주가 되지 않는 embedded쪽에서 더욱 극명하게 나타나는데, 어떤 제품이 크게 성공했을 때에도 SW쪽에서 특진을 하거나 노고를 치하 받는 경우는 드물다는 것이 이를 잘 반영해 주고 있다.
앞서 이야기한 바와 같이 이런 모든 부작용의 근본 원인은, 합리적인 측정기준이 없다는데 있다. 측정할 방법이 없기 때문에, 성과에 대한 보상을 할 수도 없고, 잘한 것 못한 것을 구별할 수도 없다. 한 마디로, 주먹구구식으로 진행될 수 밖에 없다는 것이다.
싫으나 좋으나 그래도 측정이란 것을 해야하니 이런 저런 방법들이 동원되는데, 일단 논의의 대상을 ‘각 개인의 성과에 대한 측정’으로 한정해서 생각해 보기로 하자.
SW R&D 쪽에서 보면, 회사 차원에서 SW 엔지니어의 성과를 측정하는 구체적인 기준이 마련된 곳은 거의 없다.
그냥 개발 팀의 팀장의 주관에 맡기는 것이 현실이다.
쉽게 말하자면, 회사차원에서 측정 방법에 대한 가이드 라인을 줄 수가 없으니까 그냥 손놓고 있다는 말이다.
그리고, 요즘 SW 연구소에서 팀장의 직급을 맡고 있는 분들의 상당수는 예전에 IT 붐이 일어났을때 IT업계에서 실무를 담당해서, 대단히 이른 시기에 관리자의 역할을 했던 그런 분들이다.
즉, 실제 실무 SW개발 경력보다는 관리 쪽 경력이 풍부한 분들이다.
그런 관계로, 모든 분들이 그러하진 않겠지만 필자가 보아온 대다수는, 기술적인 측면에서 상당한 아쉬움이 있었다.
문제는, 기술적인 면이 부족한 사람이 기술력이 가장 중요한 엔지니어의 성과를 측정한다는 것이다. 제대로 될 리가 없다.
일 예로, 야근을 얼마나 많이 했느냐? 주말에 얼마나 많이 출근했느냐? 버그 수정 개수 – 얼마나 많은 수의 버그를 수정했는가? – 등으로 로 엔지니어의 성과를 측정하기도 한다.
이게 말이 되는가?
그런데 놀라운 사실은, 내부적으로 이런 식의 측정기준을 가진 팀/연구소가 내가 평소에 생각했던 것보다 많다는데 있다.
실무에 대한 경험이 부족하니, 엔지니어의 성과를 측정하는 제대로된 기준을 만들 수도 없는 것이다.
이런 저런 이야기를 쓰다보니 횡설수설하게 되었는데, 요점을 미리 말하자면, 마땅한 측정 기준이 없다면, 이런 측정 기준은 어떤가?
“테스트&디버깅 단계에서 나온 버그 수(1), 마지막 배포 버젼에 남아 있는 버그 수(2)” 이 두 가지가 적은 것! 단 (1)이 (2)에 우선한다.
SW개발에서 가장 잘못된 믿음이 “열심히 하는 것”이다. 열심히 버그 만들고, 고치고, 고치면서 또 만들고…
SW개발에서 상책은 버그를 가능하면 만들지 않는 것이다.
“열심히 하는 것이 미덕” 이라는 생각이 “버그 수정 개수 = 성과” 라는, 얼핏 생각하면 그럴 듯 하지만, SW실무에서 봤을때 말도 안되는 공식을 만들어 내는 것이다.
능력이 부족한 엔지니어의 대부분이 버그 수정 개수가 많다. 자기가 버그를 만들고 자기가 수정하는 과정을 반복하니까.
특히 하루에 버그를 2~3개 잡아 냈다는 것은 자기가 만든 버그를 자기가 잡았다는 말이다. 자랑할게 아니고 부끄러워 해야할 것이다.
남이 만든 버그는 하루에 1개 잡아내기도 힘들다.
그렇다면, 왜 (1) – 발견된 버그 수 – 이 (2) – 남아 있는 버그 수 – 에 우선해야 하는가?
버그의 수정은 반드시 검증의 과정을 필요로 한다. 그런데 이 비용이 작지가 않다. 오히려 버그 수정 그 자체에 드는 비용보다 검증에 드는 비용이 더 큰 경우가 많다. 하나의 사소한 버그 수정이 만들어 낼 수 있는 side effect가 모두 검증되어야 하기 때문이다.
또한, 만약 버그 수정이 모듈의 interface, 심하게는 software 전체 구조의 변경을 요구한다면, 엄청난 추가 비용을 요구하게 될 수도 있다.
즉, 버그의 수정에 드는 비용은 해당 팀/개인 의 비용 뿐만이 아니라, 부수적으로 상당히 많은 양의 추가 비용을 포함하기 때문에, 될 수 있으면 피해야 하는게 옳다.
따라서, 버그를 많이 수정해서 남아 있는 버그 수를 작게 유지하는 것도 중요하지만, 그 보다 더 중요한 것이, 버그 자체를 적게 만드는 것이다.
글을 쓰다보니 약간 흥분한 듯 하다. 차후 내용을 정리하도록 해야겠다…
추가적인 생각들…
* 개발이 아니라 maintenance feature의 경우, 넘겨 받은 부분이 거의 완벽해서 아무일도 하지 않아도 버그가 없는 경우.
-> 일을 적절히 나누어 주는 것은 관리자의 몫이다. 이런 feature들은 그 이전의 history로 부터 파악이 가능하다.
Yhcting's Blog 