'Essay/Software'에 해당되는 글 53건

  1. 2011.03.25 [Essay] 기술면접에서의 질문방법에 대한 단상
  2. 2011.03.02 [Essay] SW영역에서 Role and Responsibility를 정의하는 두 가지 방법에 대한 비교/단상...
  3. 2011.02.09 [Essay] SW 팀/엔지니어 의 성과 측정방법에 대한 단상.
  4. 2011.01.14 [Essay] 쓸만한 SW Engineer 선별하기.
  5. 2010.12.16 [Essay] 야근... 초과 근무.. 휴가.. 등에 대한 단상.
  6. 2010.11.04 [Essay][Prog] Multi-Threading SW Programming 방법론에 대한 단상.
  7. 2010.10.21 [Essay] Domain Knowledge vs. Programming Skill
  8. 2010.08.14 [Essay] SW Debugging Skill vs. SW Programming Skill
  9. 2010.07.20 [Essay] SW Engineer의 Value…
  10. 2010.04.05 [Prog] Object Oriented Programming

[Essay] 기술면접에서의 질문방법에 대한 단상

Essay/Software 2011.03.25 17:37

다음은  SW Engineer 경력 사원 기술 면접 내용 중 일부이다.
면접 진행은, 대화가 꼬리를 무는 문답 thread가 아니라 "질문->답" 형태였다.
즉, 지원자의 답에 따른 면접관의 이어지는 관련 질문이 없었다는 뜻이다.

(*1) C/C++에 자신이 있다고 하셨는데, 그렇다면 C++에서 'virtual'은 왜 존재하는가?
-> 몇번의 communication끝에, 위 질문의 정확한 의도는 "C++에서 virtual member function은 어떨때 쓰이고 왜 쓰이는가?" 였음이 밝혀졌고, 면접관이 요구한 답은 "base class로 type casting해서 사용할 때의 문제점을 해결하기 위한 방법" 이였다.

(*2) semaphore와 mutex의 차이는 무엇인가?

(*3) thread와 process의 차이는 무엇인가?

(*4) singleton 은 무엇인가?

* 기타 등등...

난 개인적으로 위의 질문들의 수준이 높다고 보지는 않는다. 물론 이건 전적으로 내 개인적인 생각이므로 보는 사람에 따라 다를 수 있다는 것은 인정한다.
따라서 쓸데없는 딴지는 사양한다. 전부 내 개인적인 생각이니까..

그럼 왜 위의 질문들이 소위 "수준 높은 질문"이 될 수 없는가? 인터넷에서 10분만 검색해 보면 전부 답을 알 수 있는 내용들이기 때문이다.
물론 위의 질문들을 통해서 턱없이 부족한 실력의 지원자를 골라낼 수도 있겠다.
그렇지만, SW engineer의 경력분야에 따라서 실질적인 내용은 전부 알고 있음에도 불구하고, 위의 질문들에 제대로 대답하지 못하는 경우도 발생할 수 있다.

예를 들어, low tier embedded분야에서만 장시간 일해온 사람이라면, singleton 이라는 design pattern의 용어는 생소하게 들릴 것이다.

또한, context간 - 굳이 thread라는 용어를 사용하지 않았다. 왜냐하면, 'task'라는 용어 역시 가끔 'thread'와 동일 개념으로 사용되기도 하기 때문이다. - 동기화에 대해서는 잘 알고 있지만, semaphore와 mutex의 차이 역시  별 관심이 없을 수도 있다.
그냥 interrupt disable/enable로 동기화를 해야하는 SW system에서 일해 왔을 수도 있기 때문이다.
즉, '동기화' 라는 실질적인 내용은 잘 알고 있지만 - 사실 이 부분이 핵심이다 - 'semaphore'라든가 'mutex'라는 용어에 익숙치 않을 수도 있다는 뜻이다.
이는 그 사람의 지식 체계가 'semaphore'와 'mutex'를 사용하는 곳에서 쌓여진 것이 아니라, interrupt disable/enable을 사용하는 '체계'이기 때문이다.

마지막으로, 위의 면접형태의 가장 큰 문제점은, 계속되는 문답을 통한 지원자의 실질적인 지식을 측정하지 않고, 질문에 대한 정답을 요구하는 '주관식 시험 문제'와 같은 형태라는 것이다.
따라서, 그 사람의 실질적인 기술 지식(용어를 많이 안다는 것을 뜻하는게 아니다,) + 지식체계를 판단하기에는 다소 미흡하다고 생각한다.

위의 질문들은, 뛰어난 실력에도 불구하고 위에서 사용된 용어들과 맞지 않는 지식체계를 가진 사람들을 배제시킬 가능성이 있다.
또한, 실질적인 내용은 잘 모르고 용어의 뜻만 알고 있는 사람을, 실질적인 내용을 알고 있는 사람으로 오해할 여지도 있다.
그렇다면 어떤식으로 질문이 이루어져야 하는가? 위의 질문들을 가지고 다시 한번 재구성해 보자.

먼저 위의 질문은 크게 *1, *4  (A 그룹) 그리고 *2, *3  (B 그룹) 두 가지로 분류할 수 있고, 각 그룹은 하나의 문답 thread로 연결 시킬 수 있다.
필자가 생각하는, 각 그룹에 대한 문답 thread는 아래와 같다.

[ A그룹 ]

* SW architecture design에서 중요한 것들은 어떤 것들이 있을까?
-> 대화중, 모듈화나 information hiding에 대한 이야기를 유도한다.

* information hiding에 대해서 이야기 해 보면?
-> 여기서, "interface와 implementation의 분리"에 대한 이야기를 이끌어 낸다.

* interface와 implementation의 분리를 실제로 어떤 식으로 구현할 수 있을까? C++를 잘 안다고 했는데, C++를 예로 설명해 보면?
-> 이때, 상속, 다형성 등의 이야기가 나올 것이고, 자연스럽게 'virtual' 에 대한 이야기를 끄집어 낼 수 있다. 또한 instantiation에 대한 이야기도 이끌어 내도록 하자.

* 특정 class/모듈에 대해서는 instance를 여러개 만드는 것을 막고 싶은데 어떻게 하면 될까?
-> singleton에 대한 이야기를 끄집어 낼 수 있다. 이때, singleton이라는 용어를 알고 모르고는 중요하지 않다. 실질적인 내용과 개념을 정확히 알고 있는지 파악하는게 중요하다.

* 계속진행...
(각종 design pattern에 대한 이야기들, C++이 아니라 C에서 구현하는 design pattern의 개념들 - C로 상속, singleton, 다형성의 구현 등 -  등으로 이야기를 진행시킬 수 있다.
사실 C로 information hiding, OOP의 개념들을 구현하는 것에 대한 대화는, 해당 분야에 대한 지원자의 이해도를 측정하기에 굉장히 좋은 방법 중에 하나이다.)

[B 그룹]

* OS란 무엇인가? OS의 가장 핵심이 되는 기능은 무엇인가?
-> context관리에 대한 이야기를 끄집어 낼 수 있다. 혹은 대부분의 경우, 이미 thread와 process라는 용어가 등장했을 것이다.

* 무엇이 thread고 무엇이 process인가?
-> 사실, 위의 질문 자체는 괜찮은 시작점이 될 수 있었다. 문제는 이어지는 후속 질문들이 없었다는 것이다.

* 어떤 경우 thread/process를 사용해야 할까? 각각의 장단점은?
-> context switching, scheduling등의 개념과 더불어,  race condition에 대한 이야기를 끄집어 낼 수 있다.

* race condition문제는 어떤식으로 해결해야 할까?
-> 이때, context간 동기화에 대한 이야기를 이끌어 내면서, semaphore, mutex 등의 개념의 이해를 판단할 수 있다.

* 계속 진행... (deadlock, mutex의 구현 방법 (atomic instruction, interrupt disable/enable), Out-of-order optimization, Memory Barrier 등등으로 이야기를 계속 진행시켜 나갈 수 있다.)

이런 식으로 대화를 진행하면, 단지 용어만을 알고 있는 어설픈 실력자를 구별해 내면서, 지원자의 실질적인 지식과 지식 체계까지 파악할 수 있다.
면접관이 지원자에게 하는 질문의 이상적인 형태는 소크라테스의 '문답법'과 같아야 한다고 생각한다.
지원자의 대답과 거기에 이어지는 꼬리를 무는 질문들... 이런 식의 질문이 정말 "제대로 된 면접 질문" 이라고 생각한다.
물론, 동의하는 사람도 있고... 그렇지 않은 사람도 있겠지만... -_-;

이제 이 문제를 조금 더 확장해 보도록 하겠다.

보통 면접관은 지원자의 '대답'을 통해서, '질문'이 의미하는 특정 분야에 대한 지식/역량/기술을 알아보고자 한다.
그래서 일반적인 면접은 "질문(면접관)->대답(지원자)"이 연속하는 과정이다.
그런데 무언가 빠진 것 같지 않은가?
이런 과정에서는 '지원자' 가 어떤 것에 관심이 있고, 어떤 것을 중요하게 생각하는지는 알 수 없다.
어떤 사람과 함께 일하기 위해서는 그 사람의 관심분야,  중요하게 생각하는 분야, 가장 잘 하는 분야 등도 굉장히 중요한 고려사항이다.
비록 지금 당장 필요한 부분의 역량은 조금 부족하다고 생각되는 지원자라도, 의외로 다른 중요한 부분에서 굉장한 두각을 나타낼 수도 있기 때문이다.
물론, 단도직입적으로 "당신은 어떤 분야에 관심이 있나요?" 혹은 "어떤 분야를 잘 할 수 있나요?"라는 추상적인 질문을 통해 이를 파악할 수도 있을 것이다.
그렇지만, SW는 엄청나게 많은 분야에 걸쳐 세분화 되어 있으므로, 추상적인 "질문 -> 대답" 으로 명확한 답을 얻기란 쉽지 않다.
예를 들면, "전 OS에 관심이 있습니다."라는 대답하는 지원자가 있다고 가정하자.
이 대답으로 '관심분야'와 '중요하게 생각하는 분야'에 대한 파악이 다 되는가?
아마도 추가적으로 "OS중에 구체적으로 어떤 분야에 관심이 있나?" 식의 추가적이고 연속적인 질문이 뒤따라야 할 것이다.
그리고 대부분의 경우 이런 추가적인 질문들을 통해서도 원하는 만큼의 관련 정보를 얻기는 쉽지 않을 것이다.

다시 한번 정리해 보자.
일반적으로 사용되어지는 "질문(면접관) -> 대답(지원자)"의 면접 방법은 "면접관이 관심있고, 중요하게 생각하는 분야에 대한 지원자의 역량을 파악하기 위함"이라고 봐도 좋다.
그런데, 이 과정은 "지원자의 관심/중요 분야, 그리고 지원자가 가장 잘 할 수 있는 분야에 대한 파악"에는 적합하지 않다.

여기서 난 다음과 같은 방법을 제안해 본다. (아직 개인적으로 시험해 볼 기회가 없었기 때문에 실제적인 '실험(?)' 결과는 제시할 수 없지만, 기회가 되어서 실질적으로 적용해 볼 기회가 생기면 결과를 추가적으로 기재하도록 하겠다.)

"지원자 스스로가 질문하고 대답하는 것이 주(main)가 되고, 면접관의 질문은 이를 조정(control)하는 역할을 하는 면접"

(예) <지원자(홍길동) 에 대한 기술 면접>
홍길동씨 자신이 면접관이라고 생각하고, 자기 자신과 같이 일할 사람을 뽑는 다고 생각합시다.
그리고, 홍길동씨가 면접볼 사람은 홍길동씨 자신힙니다.
다시 말하면, 홍길동씨 스스로가 질문하고 대답하는 것입니다.
시작해 볼까요.

어떤가?
면접관이 다양한 분야 충분한 기술적인 지식이 있다면 위와 같은 면접은 기술적인 분야에서 지원자의 성향/가치관/비젼 등에 대한 세세한 파악을 가능하게 해 준다.
그리고, 문답의 진행 분야/방향 역시 지원자의 역량을 파악하기 위한 중요한 정보가 될 수 있다.
만약 문답의 진행이 엇나가거나, 면접관이 생각하기에 무언가 부족한 부분이 있다면(면접관이 꼭 알아보고 싶은 분야가 빠졌다던가...), 진행 중간에 이를 조정해 주면 된다.
단, 이때에도 구체적인 질문의 형태를 통해서 이를 조정하고자 하면 안된다.
예를 들면, thread 동기화에 관한 '문답'이 진행되고 있는데, 이 과정에서 'deadlock'에 대한 내용이 빠져 있고, 이를 알아볼 필요가 있다고 면접관이 생각한다면,
"deadlock 에 대한 부분은 어떻게 생각합니까?"
라는 지원자의 직접적인 '답'을 유도하는 질문 보다는
"무언가 빠진거 같은데, 동기화 관련해서 몇몇 문제들이 있지 않나요? 거기에 관련해서 지원자의 역량을 좀더 파악해 보도록 합시다."
라는 식으로, 관련 분야에 대해서 지원자가 다시 '질문 -> 답'의 과정을 시작할 수 있게 해 주어야 한다.
즉, 면접관에 대한 지원자의 반응이 '답'으로 끝나는 형태의 조정이 아니라, 지원자 자신에 대한 '질문 -> 답'이 되는 형태의 조정을 해 주어야 한다.
주제를 바꿀 때도 마찬가지다.
"이제 OOP에 대한 주제로 바꾸어 봅시다. "
식으로 '문답'을 유도해 나가면 된다.

단, 이런 식의 면접은 다양한 분야에 충분한 양의 기술적인 지식을 가진 면접관을 필요로 한다.
특정 분야에 편중된 지식을 가진 면접관의 경우, 이런 식의 면접은 오히려 시간 낭비가 될 수 있다.
운이 좋아서 지원자의 '문답' 진행 방향과 면접관의 지식 분야가 일치하면 더 없이 좋겠으나, 그렇지 않은 경우는 그냥 일반적인 '질문(면접관) -> 대답(지원자)'와 별반 다를 게 없어진다.

괜시리 이야기가 길어졌는데...
어쨌든... 일단 내 개인적은 경험/생각 에서 정리된 내 나름대로의 방법을 정리해 보았다.
음... 실제로는 어떤 결과를 보여줄지 궁금하기도 하고...
기회가 되면 꼭 이 방법을 적용해 보리라...

Trackback 0 : Comment 0

[Essay] SW영역에서 Role and Responsibility를 정의하는 두 가지 방법에 대한 비교/단상...

Essay/Software 2011.03.02 05:00

RnR(Role and Responsibility)데 대한 정의는 공동업무를 진행하는 과정에서 꼭 필요한 부분이다.
SW 실무적으로 RnR를 정의하는 방법은 크게 두가지로 나뉠 수 있을 것 같다.

첫번째, 기능별 분류이다. (a)
Multimedia Engine, Multimedia Application, GPS, Call 등등으로 구분하는 것이 대표적인 방법이다.
내가 생각하기에 현재 대부분의 SW연구소가 택하는 방법이 아닌가 한다.

두번째, 물리적인 file/directory 단위의 구분이다. (b)
Linux Kernel을 예로 들면, /mm, /kernel, /sound 등의 단위로 나누는 것이다.
이 방법은 몇몇 특수한 경우에만 사용하는 것으로 일반적이지는 않는 것으로 알고있다.

위 두가지 방법을 간단하게 비교해 보자.
먼저 (a)의 경우다.
장점: 특정 기능별로 구분되어 있으므로 해당 분야의 domain knowledge를 쌓아 전문가를 양성하기 좋다. 따라서 해당 분야에 대한 장기적인 성장에 유리하다.
단점: SW code의 물리적인 위치가 기능별로 명확히 구분되어 있지 않고, common한 부분이 많은 경우 (보통의 효율적이고 well-structured 된 code 일 수록  code 공유/재사용 이 많다.) RnR에 대한 논란의 여지가 많다. 따라서, 이로 이한 팀/개인 간의 갈등, communication overhead, 비협조적인 업무진행 등의 문제를 만날 수 있다.

(b)의 경우 (a)와 정확히 반대 된다.
같은 기능이라도 여러 팀이 관여하게 되므로, 업무 진행시 실무자간 제법 많은 양의 communication을 필요로 한다.
Camera 기능을 예로 들어보자.
Camera의 경우, Sensor Driver, HAL(Hardware Abstraction Layer), Application Framework, Application등에 그 기능이 걸쳐 있을 것이다.
따라서 Sensor에서 지원해 주는 특정 기능을 구현하기 위해서는 각 directory (아마도, driver, HAL, FW, App은 각각 다른 directory에 위치해 있을 것이다.) 별 owner들간 많은 대화가 필요할 것이다.

경우에 따라 다르겠지만, 비교/분석해 봐야할 대상은 명확해 진듯 하다.
"RnR의 불확실성에 따른 문제로 인한 업무 비용" vs. "기능별 SW업무시 발생할 수 있는 file/directory owner들 간 communication에 따른 비용"
(a)의 경우는 이미 많이 겪어 봤다. (b)는 아직 경험해 보지 못했다.
과연 어느 쪽어 더 효율적일까? (산업/업무 문야에 따라 다르겠지만...)

Trackback 0 : Comment 0

[Essay] SW 팀/엔지니어 의 성과 측정방법에 대한 단상.

Essay/Software 2011.02.09 23:18

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

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

Trackback 0 : Comment 0

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

Essay/Software 2011.01.14 08:19

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

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

Trackback 0 : Comment 0

[Essay] 야근... 초과 근무.. 휴가.. 등에 대한 단상.

Essay/Software 2010.12.16 14:27

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

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

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

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

Trackback 0 : Comment 0

[Essay][Prog] Multi-Threading SW Programming 방법론에 대한 단상.

Essay/Software 2010.11.04 17:41

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는 많이 줄일 수 있으니...

Trackback 0 : Comment 0

[Essay] Domain Knowledge vs. Programming Skill

Essay/Software 2010.10.21 19:33

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

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를 일설했을 뿐이다.

Trackback 0 : Comment 0

[Essay] SW Debugging Skill vs. SW Programming Skill

Essay/Software 2010.08.14 22:03

예전에는 위의 두가지 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간에 차이는 분명히 존재하고, 이를 인정/감안 할 필요가 있다!
(물론, 만류귀종이라고... 어느 하나가 부족하다면, 다른 하나도 극한에 이를 수는 없다고 생각하지만....)

Trackback 0 : Comment 0

[Essay] SW Engineer의 Value…

Essay/Software 2010.07.20 17:51

최근 나는, 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의 일반적인 가치에 대한 측정은 대단히 신중해야 한다.

tags : essay
Trackback 0 : Comment 0

[Prog] Object Oriented Programming

Essay/Software 2010.04.05 17:40

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.

tags : OOP
Trackback 0 : Comment 0