Ting 이네 Software 이야기

이라는 유명한 말이 있다...
오늘 갑자기 든 생각인데... 마찬가지 내용이 회의에도 적용되지 않을까?
회의에서, 윗사람의 주장을 반대하는 사람보다 나쁜 사람이 아무 반응이 없는 사람이 아닐까?
관심 자체가 없다는 이야기니...

내가 어떤 회의를 이끌 때는 이 점을 항상 염두해 두어야 할 것 같다....
반대하는 사람은 찬성하는 사람과 마찬가지로, 관심도 있고 잘 해 볼려는 열정도 있는 사람이란걸...

아래는 모두 필자 개인의 생각임을 미리 밝힌다.

우리나라에서 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로 부터 파악이 가능하다.

들어가는 글:
수학문제같은 것이 아니고서야 '정답'은 있을 수 없다. 또, 어떤 명제든 '예외'는 항상 존재하는 법이다.
따라서, 앞으로의 논의는 모두 일반적인 상황에 대한 '나' 자신의 주관적인 견해일 뿐임을 미리 밝힌다.

앞서 SW Engineer의 능력을 측정하는 두 가지 기준 - Domain Knowledge(DK), Programming Skill(PS) - 에 대해 이야기 한 적이 있다.
여기에서 한발짝 더 나아가, 어떤 Engineer를 채용할 것인가를 고민해 보고자 한다.
아니, 아직까지 개인적으로 어떤 사람을 채용해 평가해 본 경험이 없으므로, 아마도 "어떤 Engineer와 일하고 싶은가?"에 대한 고민이라고 하는게 옳겠다.

이미 앞선 글에서 잠시 언급한 것과 같이, DK와 PS의 비중은 어떤 분야에서 일하느냐에 따라 다르다.
Debugging분야는 DK가  PS보다 중요한 대표적인 예이고, 반대로 Graphic User Interface의 구현은 PS가 DK보다 중요한 대표적인 분야이다.
업무의 특성에 따라서, DK와 PS의 가중치가 달라지겠지만, 일반적으로 PS를 향상시키는 비용이 DK에 비해 비싸다.
(이에 대한 어떠한 통계적인 근거가 있는지는 모르겠지만, 개인의 경험에 비추어 봤을때 그러하다.)
따라서, DK와 PS의 비중에 대한 확신이 없을 경우에는 PS에 무게를 두는 편이 실패 확률이 적다.
한편, DK에 대한 측정기준은 분야마다 다르므로 여기서 논의할 수 있는 사항이 아니다. 따라서 PS의 측면에 논의의 초점을 맞추고자 한다.

Programming에서 가장 중요한 두가지는, 'Algorithm'과 'Design'이다. 기타 나머지는 이 두가지에 비해 그 중요도가 크게 떨어진다.
물론, Data Structure도 무척이나 중요하지만, 이는 넓은 의미에서 Algorithm에 포함된다고 할 수 있다.
나쁜 Algorithm이나 Design이 SW에 어떤 영향을 미치는지는 굳이 설명하지 않겠다.

Alg.과 Design은 속성이 좀 다른데, "전략과 전술"간의 관계와 유사하다.
Design이 전략 - 전쟁의 전체적인 측면에서 작전 - 이라면, Alg.은 전술 - 전투 상황에서의 작전 - 이라고 할 수 있다.
전략과 전술 어느 것 하나라도 부족하면 전쟁에서 이길 수 없듯이, Alg.과 Design 어느 한 쪽이라도 부족하면, 제대로된 SW가 나올 수 없다.

그런데, 재미있는 것은 Algorithm의 경우에는 선천적인 재능이 후천적인 노력에 우선하는 경향이 있다.
무슨 말이냐 하면, '똑똑한 사람이 노력한 사람보다 잘 한다.'는 의미다.
후천적인 노력이 전혀 반영되지 않는 것은 아니지만, 선천적인 능력이 더 큰 비중을 가진다.

반면, Design의 경우는 Algorithm의 경우와 반대이다. Design은 후천적인 경험/노력이 선천적인 능력이 우선한다.
왜냐하면, 요구사항, 개발환경 등에 대한 풍부한 이해와 경험이 바탕이 되어야 좋은 Design이 나올 수 있기 때문이다.
아무리 천재적인 사람이라도, 충분한 경험이 없다면 좋은 Design을 만들 수 없다.
좋은 Design은 풍부한 지식에서 나오는 것이 아니라, 느끼고 이해했을때 비로소 만들어 낼 수 있는 것이다.

Alg. Design 양쪽 모두에 뛰어나다면, 두말할 필요도 없다. Alg.쪽에 뛰어나다면, 이 역시 굉장히 탐나는 사람이다.
Design쪽 능력은 가르치고 다듬어서 발전시킬 수 있지만, Alg.쪽 능력은 이런식의 향상이 굉장히 힘들기 때문이다.
그렇지만, Alg.쪽에 정말로 뛰어난 사람을 찾기는 힘들 것이다. 대부분 학계쪽 혹은, 다른 어떤 곳에 몸담고 있을 가능성이 높다.
우리가 접할 수 있는 대부분은 사람은, 아주 낮은 수준 부터 중상 정도 수준까지일 것이다.
그런데 이런류의 재능은, 아주 뛰어난 몇몇 사람들만 눈에 띌 뿐, 그 외에는 잘 한다고 느끼기가 어렵다.
뿐만아니라, 합리적인 측정방법을 찾는 것도 거의 불가능에 가깝다.
따라서, Alg.에 대한 측정은, "좋은 사람을 찾겠다."가 아니라, "낮은 수준의 사람을 걸러낸다."는 접근 방법을 취해야 한다.
이건, 몇몇 기본적인 함수 작성 문제들을 제시해서 알아 볼 수 있다. recursion을 사용해야하는 문제라면 더욱 좋다.

이제, Design쪽 능력을 검증해야 한다. 이번 경우는 위의 경우와 접근 방법이 달라져야 한다.
Alg.의 경우는 '걸러내는' 방법이 사용되었다면, Design쪽은 '골라내는' 방법이 사용되어야 한다.
(신입사원을 채용하는 경우는 예외다. 신입사원에게 경험을 필요로 하는 답을 기대하는 것은 무리가 있다.)
좋은 Design은 SW 개발을 충분히 이해하고 가슴으로 느꼈을 때 나타날 수 있다.
이것은 '절대' 경력에 비례해서 성장하지 않는다. 너무 짧은 경력을 가진 사람이 좋은 Design을 하는 것은 힘들지만, 충분한 경력을 가진 사람이 좋은 Design을 할 것이라는 보장은 없다. Design능력은 실무에서 경력을 쌓는 동안, SW에 대해서 고민하고, 연구하며, 자기 나름대로의 철학을 구축해 나가는 과정에서 성장해 나간다.
즉, '제대로'된 경력을 가진 사람만이 좋은 Design을 만들어 낼 수 있는 것이다.
나는 감히, "경력과 Design능력과의 관계는, 그 사람의 성실성을 측정할 수 있는 좋은 척도가 된다." 라고 말하고 싶다.
Design능력을 검증하는 test는 Alg.의 그것과는 엄연히 다르다.
Alg.의 경우는 함수 내부의 구현에 집중한다. 그렇지만  Design의 경우는, API의 정의, encapsulation / modulization 등의 주요 concept에 대한 반영, 개인이 가지는 programming 철학 등에 집중해야 한다. 함수 내부의 구현이 정확하냐 안하냐 - correctness - 는 부수적인 측정 대상일 뿐이다. 극단적으로 pseudo code로 test할 수도 있다 - 물론 좋은 선택은 아니지만.
그리고, coding test시 사용하는 language로는, 가능하다면, OOP language를 피하는 것이 좋다 - C++, Java 같은 것 보다는 순수 C 같은 언어.
도구의 이점을 최소화하면, 뛰어난 사람과 그렇지 않은 사람간의 차이를 더욱 쉽게 볼 수 있기 때문이다.
아마도, 간단한 "재사용 가능한 linked list library"를 만들어 보라고 시켜 보는 것만으로도, Engineer의 Design 능력에 대한 많은 정보를 얻을 수 있을 것이다.

to be continued...

야근, 초과근무, 휴가 등은 직장생활에서 많은 이슈가 되는 것들 중에 하나다.
앞선 몇몇 글에서도 언급한 바가 있었던 것 같은데, 한국에서는 야근, 초과근무는 당연시 되고, 휴가는 다 쓰지 못하는게 당연시 된다.
일단, "열심히 일하는 것이 미덕." 인 문화가 가장 큰 이유 중에 하나다. 이건 너무나 많이 이야기 되어 왔고, 논쟁이 되어온 내용이라 더 이상 언급하지 않겠다.
또 다른 근거로 제시되는 것은,  "다른 사람들도 (야근/초과근무/휴가 다 못쓰기를)하는데, 너만 안 하면, 다른 사람들이 어떻게 생각하겠느냐?"라는 것이다. 즉, 다른 사람들과의 형평성에 대한 이야기다. 여기에 대한 여러가지 시각이 있을 수 있겠으나, 내가 보는 시각은 좀 다르다. 난 개인적으로 위의 논리가 잘못 되었다고 생각한다.

위의 논리는 바꾸어 이야기 하면, "다 같이 힘들고 고생하자!"의 논리다. 왜 "다같이 편하고 행복하자!"의 논리를 만들어 내지 못하는가?
"많은 사람들이 초과 근무/야근을 하고 휴가도 못가니 너도 그래라."가 반복 적용되면, 결국 "모든 사람은 초과 근무/야근을 해야 한다."로 바뀐다. 이렇게 되면, "어차피 야근해야 할꺼, 근무시간에 열심히 일하면 뭐하냐? 천천히 하자." "어차피 휴가도 못쓰는거 오늘 끝낼 필요있나? 천천히 하지 뭐." 이렇게 된다. 이런 악순환의 고리가 현재 한국에 만연되어 있다고 본다. "일이 없으니, 일찍가지. 일이 없으니 휴가 가지."라고 말한다면, 일찍 퇴근하고/휴가가기 위해서 열심히 일해 일을 빨리 끝마치는 사람은 "일이 없는 사람"으로 매도 된다. 만약 정말로 업무 부담이 가벼운 경우라면, 그건 업무 분배를 제대로 하지 못한 사람에게 책임이 있는 것이다.
설사, 정말로 일의 부담이 적은 경우라면, 괜시리 야근 시키고, 휴가를 금지 시켜서 쓸데 없이 회사에 나오게 만드는 것 보다, 재충전의 시간을 보장해 주는 것이, 직원들의 사기를 높이는 방법일 것이다. (어차피 할일 없이 회사에 나와봤자, 생산적인 일을 할리가 만무하다.)

물론 위의 이야기를 이상적인 이야기, 비현실적인 이야기라고 평하는 사람들도 있을 수 있다. 그리고 나도 어느 정도 동의한다. 몇몇 사람들의 경우, 강제로 일을 시키지 않으면 - 반 강제적인 야근, 초과 근무 등등 -  제대로 맡은 일을 하지 않는 사람들도 많다. 이런 사람들에게 위와 같은 자유를 허락한다면, 제대로 된 생산성을 기대할 수 없을지도 모른다. 그렇다고 해서, 현재와 같은 방식을 유지하면, 이는 직원의 생산성을 하향 평준화 시킬 여지가 다분하다. 뛰어난 생산성을 가진 사람들은 이런 근무 환경을 견디기 힘들어 할 것이고, 결국 떠나게 될 것이다.

이게 어제 오늘의 문제는 아니다. 난 이런 현실이 어째서 바뀌지 않는 것인지에 대한 의문과, 과연 바뀌기는 할 것인지에 대한 회의를 함께 가진다.

Multi-Threading(이하 MT)  SW Programming시 동기화는 무엇보다 중요한 이슈가 된다.
생각해보면, 동기화가 문제가 되는 이유는, Programming Language의 기본 전제가 "필요한 곳에 동기화를 한다." 이기 때문이다.
이런 정책에 100% 동의한다. MT을 통해, HW 자원을 효율적으로 사용하고자 한다면 더더욱 그러하다.
그런데, 만약 상당히 많은 부분을 서로 공유하는 어떤 MT SW가 있다고 가정한다면 (그런 SW는 디자인 자체가 잘못된 것이라는 등의 이야기는 일단 접어두자.) 어떨까?
이런 경우 "필요한 곳에 동기화"란 개념으로 보면, 너무 많은 "필요한 곳"이 존재하게 되므로, 쉽지 않다.
이럴 경우, 차라리 개념을 "필요한 곳에서 rescheduling"이라는 걸로 개념을 바꾸어 보는건 어떻까?
일단 다른 측면들은 모두 차치하고서라도, Programming은 좀더 쉬워질 것 같지 않은가?
이런 식의 개념을 지원하도록 SW구조를 잡는 것은 그리 어려운 일은 아니다.
물론, HW 자원을 효과적으로 쓰도록 만들기는 앞의 개념에 비해서 상당히 더 어려울 것이다.
결국 아래와 같은 Trade-off가 발생한다.

"HW자원의 효율적인 사용 vs. Programming의 단순와"

너무 무식한 방법이라고 비판할 수도 있겠지만, Performance가 큰 문제가 되지 않고, Async한 동작자체가 중요한 경우라면, 충분히 한번 고려해 볼만하지 않은가? 일단 Bug는 많이 줄일 수 있으니...

* 들어가기 앞서, 이후의 서술은 전부 필자의 개인적인 생각에 따른 것으로, 어떠한 통계적/과학적 근거도 없다.

SW분야에서 필요로 하는 기술적인 지식은 크게 Domain Knowledge(DK)와 Programing Skill(PS) 로 나뉜다.
그리고, 대부분의 Programing은 DK를 구체화 시키고, 구현하는 작업이다.

위의 두 가지의 상대적인 비중은, 업무의 분야에 따라 결정된다.
예를 들어, Device Driver를 구현하는 경우, PS보다는 Device에 대한 DK의 비중이 훨씬 높다.
반면, UI쪽 구현은 DK보다는 PS가 더 중요하다.
따라서, 좋은 SW Engineer는 해당 분야에서 요구하는 PS와 DK의 균형을 유지할 필요가 있다.
(개인적인 생각으로는, 코드의 사이즈가 커지면 커질수록 PS의 중요도가 증가하는 것 같다.)

그럼 '측정' 이라는 측면에서 DK와 PS를 접근해 보자.
상당한 확률로, DK는 경력과 상관관계를 가진다. 해당 분야에 대한 경험이 많을 수록 DK는 깊어진다.
반면 PS는 어느 정도까지(2~3년)는 경력과 상관관계를 가지지만, 그 이후는 경력과 무관한 경우가 대부분이다.
Engineer의 태도, 노력, 열정 등에 따라 PS의 수준에 상당한 편차가 생기게 된다.
필자의 경험에 따르면, 10년차 Engineer의 PS수준이, 전산을 전공한 대졸 신입사원 수준에 머무르는 경우도 흔치않게 봐 왔다.
그런데, PS를 측정할  수 있는 공신력있는 어떠한 방법도 알려진 것이 없다.
또한 짧은 시간의 문답이나, 틀에 짜여진 시험 같은 것으로 PS를 측정하는 것도 굉장히 힘들다.
그래서, 회사는 측정하기 힘든 PS보다는 측정이 용이한 DK를 기준으로 사람을 선발하게 되고, 이것이 곧 '경력' = '실력'이라는 잘못된 측정 방식을 낳게 된다.

물론, DK가 중요한 분야라면, 위와같은 측정방식도 상당히 합리적이다.
그렇지만, 근래 SW를 보면, 코드 규모가 예전과는 비교할 수 없을 정도 크다는 것에 주목할 필요가 있다.
앞서 서술한 바와 같이 "코드 규모가 크다."는 "뛰어난 PS를 요구한다."와 관계가 깊다.
다시 말하면, 근래 SW산업 특성상, PS쪽의 요구가 DK쪽의 요구보다 빠르게 증가한다는 말이다.
그럼에도 불구하고, 필자가 보기에는 국내 SW업계는 이런 사실을 상당히 간과하고 있는 듯 하다.
여전히 '경력'='실력' - DK에 높은 비중을 둔다. - 이라는 논리가 상당히 강하다.
또한 PS 수준을 측정하기 힘든 것은 사실이지만, 이를 개선할려는 노력 또한 별로 하지 않는다.
이런 환경에서, SW Engineer는 자신의 PS를 향상시키는 노력을 등한시 하게 된다.
(물론 DK수준을 향상시키는 노력 또한 특별히 하지 않는다. 할 필요가 없기 때문이다. 경력이 곧 DK수준을 말한다고 생각하니까...)
이런 현상이 어느 정도 장기화된 지금, 의사결정권자 역시 PS가 부족한 사람들로 채워지게 되었다.
따라서, 그들 역시 PS의 중요성에 대한 이해가 부족하다.
자, 아래의 cycle을 보자.

PS를 등한시 하는 환경 => Engineer의 PS 향상에 대한 동기 부족 => Engineer의 PS 정체 => PS가 정체된 Engineer가 의사결정권자가 됨.=> PS를 등한시하는 환경 강화.

이것이 필자가 보는 한국 SW의 모습이다.

국내기업에서 경력사원 채용시, 가장 많이 듣게 되는 질문이, "어떤 분야를 얼마나 했느냐?" 이다. 즉 Domain에 대한 질문이다.
이를 통해서 면접관은 지원자의 특정 Domain에 대한 DK를 짐작하고자 하고, 이것은 면접 점수에 상당힌 비중을 차지하게 된다.
그리고 면접관은 DK에 대한 세부 질문들에 상당한 시간을 할애한다.
그런데, 국내 대부분의 회사의 경우, 면접관들이 지원자와 더불어 PS에 대한 심도깊은 면접을 진행한다는 이야기를 들어본 적이 없다.
이는 PS의 중요성에 대한 인식 부족이 가장 큰 원인 중에 하나일 것이다.
그리고, 또 하나의 중요한 이유는, 그들(면접관들) 조차 지원자와 PS에 대한 심도깊은 대화를 진행하고, 지원자의 실력을 평가할 수 있는 수준이 되지 못한다는 것이다.
이것이 현실이다.
PS 향상을 위해 노력하고, Programming 철학을 논하며, Unix Culture를 이야기하는 사람들은 현재 대한민국의 SW 인력시장에서 그만큼의 가치를 인정받지 못한다.
다시 한번 이야기 하지만, 이것이 현실이다.

별다른 뜻은 없다.
그냥 SW Engineer의 한 사람으로서, 대한민국 SW업계를 보는 주관적인 View를 일설했을 뿐이다.

예전에는 위의 두가지 Skill이 상당부분 유사하다고 생각했었다. 그런데 시간이 지나면서 위의 두가지 Skill에 작지않은 Gab이 존재함을 느낀다.
Debugging Skill(이후 D/S)과 Programming Skill(이후 P/S)간에 얼마만큼의 차이가 존재하는가?

한가지 예를 들어보자. 새로운 언어 (영어)를 배울때, reading skill과 writing skill간의 gap은 분명히 존재한다. 물론 극한에 이르려면 둘다 잘 해야 하는것은 명백하지만(만류귀종(?) 이라고 했던가..^^;), 어느정도 수준에 이르기까지는 서로 다른 방향에서 발전해 오다가 어느순간 교점을 가지는 듯 보인다. 과거 우리나라 학생들을 예로 들어보아도, reading skill은 뛰어나지만 writing skill은 부족한 경우가 많았다. 물론 그 반대도 존재한다. 대부분의 국내 대학생들의 reading skill은 미국의 저학년 초등학생의 그것보다 뛰어나다고 생각되지만, writing skill은 그렇지 못할 것이다. (어디까지는 필자의 생각이다.)

프로그래밍 언어도 마찬가지라고 생각한다. debugging을 위해서는 code reading skill(이후 R/S)이 중요하다. 그리고 Programming에는 code writing skill(이후 W/S)이 중요하다. 영어에서의 R/S, W/S간의 차이가 프로그래밍 언어에는 없으란 법이 있을까?
한 가지 예를 들어보면, P/S에서 가장 중요한 부분중에 하나인, design(class design, component design 등등) skill은 D/S에서는 별로 중요하지 않다. 반면, P/S의 경우, 내가 Programming할 분야 특화된 좁고 깊은 지식이 요구되지만,  D/S의 경우는 다양한 분야에 대한 넓고, (P/S에서의 경우대비 상대적으로)덜 깊은 지식이 필요한 경우가 많다.

각설하고, 요점은 이렇다.
두 Skill간에 차이는 분명히 존재하고, 이를 인정/감안 할 필요가 있다!
(물론, 만류귀종이라고... 어느 하나가 부족하다면, 다른 하나도 극한에 이를 수는 없다고 생각하지만....)

최근 나는, KLDP에서 data structure와 algorithm(이후 D/A)에 큰 관심이 없는 SW Engineer(이후 SWE)가 구글 코리아에 지원했다가 떨어진 내용에 대한 글 + 거기에 대한 글타래를 읽었다. (http://kldp.org/node/78668)
글타래를 보다보면, D/A에 익숙치 않은 SWE의 가치를 비하한다고 생각되어지는 몇몇 글이 눈에 띄인다. 난 이 post를 통해서 거기에 대한 반론을 전개하고자 한다.

모든 직종이 마찬가지겠지만, SW역시 다양한 분야가 존재한다. 그리고 Engineering skill의 가치는 "현재 종사하고 있는 분야에 얼마나 적합한가?"에 따라 측정되게 마련이다. 예를 들면, SW Integration Engineer의 경우, 각종 System 및 개발 환경, script와 tool의 사용 등에는 굉장히 뛰어난 skill을 보유하고 있을지 모르나, D/A에 대한 지식은 상당히 부족할 가능성이 높다. 그러나 그렇다고 해서, 뛰어난 SW Integration Engineer의 가치가 약해지거나 하는 것은 아니다. 그 사람은 본인의 직무에 적합한 skill을 가지고 있으므로, 우리는 그 사람을 충분히 '뛰어나다'고 이야기 할 수 있다. 나는 D/A가 중요하지 않다는 이야기를 하는 것이 아니다. 다만, 모든 SW분아가 D/A에 대한 skill을 요구하지는 않는다고 말하고 싶다.

SWE의 가치를 이야기할 때도 반드시 이러한 요소가 반영되어야 한다. 관련 글타래 중, "Google에서 정한 SWE의 가치(급여)가 현재의 급여보다 작다면, 현재 자신의 가치 이상의 급여를 받고 있을지도 모른다"는 의미의 글이 보인다 - 물론 내가 잘못 이해했을수도 있겠으나, 최소한 나에게는 이런 의미로 다가왔다. 그러나, 이는 분명히 잘못된 논리이다. 물론 현재 그 사람이 과한 급여를 받고 있을지도 모른다. 그렇지만, 최소한 그 기준이 Google의 급여가 되어서는 안되는 것이다. 왜냐하면, 현재 그 사람이 종사하는 분야가 요구하는 skill과 Google이 요구하는 skill이 엄연히 다르고, 각 회사는 자신들의 분야에 초점을 맞추어 SWE의 가치를 측정하기 때문이다. 다시 말하면, 그 사람이 현재 받는 급여는 현재 회사가 요구하는 skill을 기준으로 했을 때의 가치이고, Google이 제시한 급여는 Google이 필요로하는 skill을 기준으로 했을때의 가치가 되는 것이다.

"어떤 사람이 모든 측면에서 더 낫다."란  있을 수 없다. 이는 Engineering의 세계에서도 마찬가지라고 생각한다. 어느 한 분야에 국한했을때, "A가 B보다 낫다."라고 이랴기 할 수 있는 것이지, "A의 SW Engineering skill이 B의 것보다 낫다."라고 이야기 하기는 대단히 어렵다. 따라서, SWE의 일반적인 가치에 대한 측정은 대단히 신중해야 한다.

듣기로.. Nokia는.. 어떤 문제에 대해서... 해결 방법을.. 찾을 때...

* 사람들을 모아서 해결책을 찾는 방법론을 listing한다. - brain storming
* 투표를 통해서 상위 2~3개를 뽑아낸다.
* 같은 의견을 가진 사람들끼리 모여서 팀을 형성한다. (2~3개 팀이 생긴다.)
* 각 팀별로.. 해결책을 찾는다....

--> 이 방법.. 상당히 괜찮아 보인다. 사람들은 자신과 신념/비젼을 달리하는 방향에 대해서는 최선을 다하기 힘들다. (무의식적으로 나태해지게 된다.)
그런데 이 방법은 자신이 믿는 바가 옳음을 보이는 형식이므로, 사람들의 적극적인 참여를 기대할 수 있다.

일반적으로, 사람은 의사결정에 본인이 참여한 정도만큼의 열정/책임의식 을 가진다고 한다. 따라서, 사람들의 열정을 이끌어내기 위한 중요한 방법 중 하나가, 의사 결정에 충분히 참여하도록 하는 것이다!

The most important thing of OOP is "Making objects that developer don't need to look inside of it.". Reliable objects are foundation of OOP. Then let's think about this more.

* Object should respond at all cases.

That is, crashing inside object should not be happened! object should be in valid state at any case. If software is crashed inside object, developer should analyze internal code of object, and this is what we want to avoid.

* Reducing possibility of misuse interface should be considered when interface is design.

That is, usage of interfaces should be easy and intuitive. If not, developer need to investigate for object's internal parts to know correct usage. And, usually, interdependent interfaces leads to misuse. For example, "Interface B should be used after interface A is called", "Interface A should not be called after interface B is called" and so on. So, if possible, reduce dependency among interfaces of objects.

* Interface should be well-commented.

In the same context with above, developer don't need to look into the object that is well-commented. In my opinion, comments of interface should include at least following things.
  + behavior of interface.
  + prerequisite to use the interface.
  + explanation about each parameters.
  + description about return value.
And, adding usage example is recommended.

* For object to starts supporting minimal set of interface is better.

Adding interface is easy. But deleting interface is difficult because it may affect to number of other objects that already use the interface. And, stabilizing object having small number of interface, is easier. Starting from minimal set can also help developer escape from temptation of over-engineering

 
Next important point is relations among objects.
Software created by OOP consists of lots of objects and relations. To understand software's behavior, knowing relations and inter-operations among objects is significant.

* Software documentation.

Design concept, policy, block diagram, used patterns and so on is needed to be documented to help reader to understand overall shape of software.

 
There is also disadvantage of OOP.

* Performance drop.

In every object, there are lots of routines for checking and handling unexpected cases. And in general, software in OOP consists of lots of objects. So, inevitably, number of duplicated check and handling are unavoidable - all objects may check same thing. And sometimes this drops performance very much.