[ SW 엔지니어에 대한 잘못된 생각들 ]

SW를 잘 알지 못하는 사람들이, SW 엔지니어에 대해 이야기 할때 일반적으로 범하기 쉬운 몇가지 오류들에 대해서 짚어보고자 한다.

* SW엔지니어는 일정을 이야기할때 굉장히 보수적인 일정만을 말한다.

음... 일부러 일정을 늘려서 이야기하는 엔지니어도 분명히 존재한다.
그렇지만, 그런 경우는 엔지니어의 태도문제도 존재하지만, 조직의 분위기에도 문제가 있다고 보는게 옳다.
estimation한 일정을 지키지 못했을 경우 - fix된 일정이 아니라 estimation한 일정임에도 불고하고 - '실패'로 몰아세우면서 질책하는 문화에서는 보수적인 일정을 제시할 수 밖에 없기 때문이다.
이런 '책임 회피성 일정'을 논외로 한다면, 엔지니어들은 일정을 굉장히 aggressive하게 제시하는 경향이 오히려 강하다.
왜냐하면, 일에 대한 구체적인 분석이 없는 상태의 초기 estimation은 항상 여러가지 사항들을 놓치게 마련이고, 따라서 실제 일의 양보다 적은 양을 예상하기 때문이다.
그래서, "실질적인 일정 = 엔지니어의 예상 * 2"라는 우스겟 소리도 있다.
따라서, 필자는, 조직에서 SW엔지니어들이 보수적인 일정을 제시하는 경향이 있다면, 그것이 소위 '책임 회피성 일정'이 아닐까를 먼저 의심하고 그렇게 할 수 밖에 없게 만드는 조직의 문제점을 찾아서 제거할 필요가 있다고 생각한다.

* SW엔지니어의 생산성은 투입된 시간에 비례한다.

SW작업에서 물리적인 시간적 투자를 필요로 하는 일은 일부에 지나지 않는다. 대부분은 고도의 집중력을 요구한다.
대부분의 사람들이 위의 이야기에는 동의함에도 불구하고, SW엔지니어가 일한 시간에 관심을 가지는 이유는, 생산성을 측정할 수 있는 방법을 알지 못하기 때문이다.
그렇기 때문에 '시간 투자 = 성실/성과' 이라는 차선(?)책을 사용하고 있고, 이것이 생산성과 시간과의 관계에 대한 잘못된 생각을 퍼트리고 있다.

* 많은 버그를 잡는 사람은 뛰어난 SW엔지니어이다.

버그는, 수정하는게 중요한게 아니고, 만들지 않는 것이 중요하다.
이는 비단 초기 개발 단계만의 이야기가 아니다. 버그를 잡기 위해서 다시 버그를 만드는 과정을 반복하는 많은 미숙한 엔지니어들이 있다.
만약, 실제로 SW를 개발을 하는 팀이라면, 버그에 관계된 성과 측정기준은, 반드시 "발견된 버그의 개수"가 되어야기 "수정한 버그의 개수"가 되어서는 안된다.
이는 유지보수팀에서도 일정부분 적용되는데, 유지보수팀에서는 "버그를 수정한 수"에 앞서 "fix-on-fix"의 수에 더 많은 가중치를 주어야 할 것이다.
넘치는 fix-on-fix를 감당하지 못해서 commit자체를 revert하는 경우도 심심치 않게 일어난다.

* 디버깅을 잘하는 사람은 programming도 잘 한다.

'만류귀종'이라는 말처럼, 궁극에 이르면 두 가지 능력 모두 최고 수준을 보일 것이다.
그렇지만, 상당부분에서 디버깅과 programming은 서로 다른 skill을 요구한다.
필자의 post 중 여기 를 참조하자.

* 작성한 코드의 line수와 생산성은 비례한다.

정말 이 말을 맏는가?
무관하다고 말할 수도 없지만 - 1년에 1라인을 작성한 사람과 하루에 1000라인을 작성한 사람 - 그렇다고 해서 비례하지도 않는다.
너무 극단적인 경우를 제외하고는, 이것은 성과측정의 기준이 될 수 없다.

* 변수/함수의 이름을 바꾸기, 하나의 함수를 두개로 분리하기, compiler warning을 제거하기, 주석 추가/수정하기 등 실질적으로 코드의 동작과 무관한 contribute는 무의미하다.

이런 일들이 생산성과 무관하다고 생각하는 사람이 있다면, 음... 더 이상 필자의 글을 읽을 필요가 없다.
왜냐하면, 기본적인 믿음 자체가 다르기 때문이다.
필자가 보기에는, 이런 일들은 버그를 잡거나, 새로운 기능을 구현하는 것만큼 중요하다.
SW의 가독성을 높여서, 유지보수를 쉽게 하고, SW의 장기적인 건전성을 확보하는 일은 그리 가벼이 볼 일이 아니다.

* 뛰어난 SW 엔지니어는, 버그 및 수정 요구사항을 빠르게 해결해서 적용한다.

'속도'가 중요한게 아니다.
지나치게 빠르다고 생각되는 대부분의 수정은 다량의 'fix-on-fix'를 유발하는 경우가 많다.
'얼마나 빨리 하느냐?' 가 아니라, '얼마나 정확히 잘 하느냐?'가 중요하다.
빨리 했지만 결국에는 버려야 할 contribute보다는, 조금 늦게 진행되고 있지만 착실한 contribute가 가치가 있는 법이다.

기타 많은 것들이 더 있겠지만.. 일단 여기까지만... 생각나면 더 추가하도록 하겠다..

+ Recent posts