[Essay] 쓸만한 SW Engineer 선별하기.

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

앞서 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...