"Programming skill"의 정의와 거기에서 파생되는 문제점...

Software업계에서 Programming skill 이라는 단어가 많이 사용되고 있는데 비해, 그 정의가 명확하지 않은 것 같다.

아니, 정의가 명확하지 않은게 아니라, 정의를 실체화 하는 방법이 명확치 않다고 해야 하나?

일단 "좋은 코드/소프트웨어"라는 말에 대한 정의는 어느 정도 합의된 실체가 있는 것 같다.

그럼에도 불구하고, 정량적인 측정 기준이 없기 때문에 여전히 관념적인 형태에 머물러 있긴 하지만...

그런데, "좋은 소프트웨어"를 만드는 것 => Programming skill 이 뛰어난 것"이 되지 못하는 이유는 현실적으로, 보통 '시간'으로 대표되는 '비용'이라는 요소가 들어가기 때문이다.

그래서 결국, Programming skill은 "적은 비용으로 좋은 소프트웨어를 만드는 기술"이라고 정의되어 질 수 밖에 없다.

문제는 앞서 이야기한 것처럼, "좋은 소프트웨어"라는 요소는 정량적인 기준이 없고, 측정방법 또한 모호하다. 그렇지만, '비용'은 객관적이고 명확한 측정 방법을 가진다. 그러다보니, 두 요소 중 '비용'이라는 요소에 더 집중하게 되고, 그것을 기준으로 Programming skill 을 말하는 경우가 많다.

그러다 보니, 극단적으로, "적인 비용으로 소프트웨어를 만드는 기술"이 Programming skill 로 왜곡되어 정의되어 버리게 된다.

(이 경우, 소프트웨어의 품질은 전혀 고려 대상이 아니다.)

실제, 계약에서도, 측정할 수 없는 "좋은 소프트웨어"라는 항목을 계약서에 기술할 수 없으므로, "비용"에 초점이 맞추어 질 수 밖에 없게되고, "적은 비용"이라는 기준을 만족시키는 쪽이 "기술력이 있는 곳"이라는 평가를 받게 되는 기이한 현상이 벌어지게 된다.

이는 계약에서 뿐만아니라, 국내 기업의 업무 형태에서도 쉽게 찾아볼 수 있다 - 물론 모든 기업이 그렇다는 이야기는 아니지만, 대부분(특히 소프트웨어가 주 제품이 아닌 곳들)의 경우 해당될 것이다.

소프트웨어를 만드는데, 연봉이 높은 우수 인력을 사용하는 것은 '과다 비용'으로 받아들이고, 경력이 짧은 미숙한 엔지니어에게 일을 맞겨 소위 "돌아가는 소프트웨어"를 만들어 내는 것을 "잘 했다"고 평가한다. 즉, 소프트웨어의 "품질"은 무시되고, "비용"부분만 고려된 "평가"인 것이다.

이와 같은 현상은 계속 반복된다.

위와 같은 방식으로 만든 소프트웨어는 필연적으로 수많은 문제점(버그)를 내포하게 된다. 이제 이 문제점들을 수정해야 하는데, 이 역시 '비용'만을 고려해서, 미숙한 엔지니어가 처리하게 되고, 수많은 fix-on-fix를 양산하는 악순환을 반복한다.

그러면서, "소프트웨어는 당연히 많은 버그를 내포할 수 밖에 없고, 약간의 수정도 많은 문제점을 동반할 수 밖에 없다."라는 이상한 결론을 내려 버린다.

위의 이야기는 좀 극단적인 측면이 있지만, 국내 현실을 상당히 잘 반영한다고 생각한다.

"소프트웨어의 비용 감소"라는 측면에서 시작된 것이 아니라, 순수하게 "소프트웨어 품질의 정량화"라는 측면에서 시작된, 소프트웨어 관련 연구가 활발하게 이루어 졌다는 이야기는 들어 본적이 없다. 물론, 내가 잘못 알고 있는 것일 수도 있지만...

각설하고... 슬프지만... Programming skill에 대한 가장 현실적인 정의는 "적은 비용으로 소프트웨어를 만들어 내는 기술"이라고 할 수 밖에....

주저리 주저리... 문맥도 안맞고... 내용도 정리가 안되어 있고.. 쩝..