[Essay] 리더로서 자연스럽게 팀의 업무 상황 파악하기…

리더가 팀을 이끌어 과는 과정에서 팀원의 업무 파악은 상당히 중요한 일이다.
업무 파악을 위해서 가장 많이 하는 일은 다음과 같은 것들이 있다.
– 주간 업무 회의 : 주 1회 정도 정기적인 업무 회의를 통해서 보고 받는다.
– E-mail 참조 : 업무관련 E-mail 을 주고 받을때, 리더를 CC에 넣도록 한다.
– 식사/커피 등 함께 하기 : 자연스러운 분위기에서 업무 관련 이야기를 듣고자 한다.

다 좋다. 필수 적이기도 하다.
그렇지만 위의 것들을 모두 잘 하고 있음에도 불구하고, 늘 팀원의 업무 파악이 제대로 되지 않는 것 같다고 느끼는 경우도 있다.
무엇이 문제인가?
내가 생각하기에, 위의 방법들도 좋지만, 가장 중요한 것은 팀원들이 리더에게 도움을 받을 수 있어야 하고, 팀원이 이를 실질적으로 느끼고 있어야 한다는 것이다.

예를 들면, 어떤 문제에 대해서 실무자가 자기 자신의 힘만으로는 해결이 힘들어서 리더에게 보고를 하는 경우를 생각해보자.
이런 문제의 경우 대부분이 내부에서 실무적으로 처리하기는 한계가 있다고 실무자가 판단하는 경우이다.
즉, 외부 혹은 타 부서와의 협력을 통해 문제를 해결할 필요가 있는 문제이다.

이때, 리더가 취하는 가장 일반적인 자세는, 일단 무엇이 문제인지 문제를 파악하고자 한다. 그래서 실무자에게 관련 문제에 대한 문답이 이루어진다. 여기까지는 자연스러워 보인다.

그런데 이후, 물론 리더에 따라 다르겠지만, 실무적인 가이드를 시작하는 경우가 있다. 그리고 이런 경우는 대부분, 상당한 시간을 소모함에도 불구하고, 리더가 제시한 가이드가 해결에 도움이 되기 보다는, 리더가 문제에 대해 더 잘 이해하는데 도움이 되는 정도로 끝난다.
이 과정이 반복되면, 일단 실무자는 피로를 느끼게 된다.
최악의 경우는, 리더가 실무에 대한 잘못된 가이드를 제시하고, 실무자의 의견에 반하여 그 가이드에 따라 일을 진행시키라고 강요하는 경우다.
이런 리더에게 실무자는 어떠한 도움도 구하고자 하지 않는다.

그리고 이후, 리더는 자신의 실무적인 해결책에 도움이 되지 못하게 됨을 깨닫고, 실무자에게 어떤 도움이 필요한지를 묻게 되고, 실무자는 ” xxx가 필요합니다.”라는 말을 하게 된다. 이런 도움의 대부분은 타 부서와의 업무 협조, 상위 부서에 보고 등에 대한 문제이다.
실무자가 요구한 사항을 리더가 해결해 주는 것이 정상적이나, 어떤 리더의 경우는 “그래? 그럼 xx씨가 직접 oo한테 연락해서 처리하도록.”의 식으로 결국 실무자가 모든 일을 해야 하는 방향으로 결정을 내리기도 한다.

자. 위에서 문제가 된다고 생각하는 과정을 거친 실무자의 입장에서 보면, 본인이 진행하는 업무에 문제가 있어서 리더에게 보고를 했을때, 업무 진행에 도움을 받기 보다는, 시간과 에너지를 소모하고, 결국 자기 자신이 처리해야 하는 방향으로 결론이 난 것이다.
즉, 문제를 보고하는게 하등 도움이 되지 않는 것이다.
실무자가 이렇게 느낀다면, 과연 이후 업무에 대해서 리더에게 보고하려고 할까?
그냥 정기적인 보고 이외 특별히 리더와 업무에 대해 상의하고자 하지 않을 것이다.
어차피 결과적으로는 자기 자신이 모두 처리해야 하니까…

주저리주저리 이야기가 길었다.
간단하게 결론을 정리하면, 리더가, 실무자에게 도움을 줄 수 있고, 또 그렇다고 실무자가 느낀다면, 리더는 자연스럽게 실무자가 가지고 있는 문제를 보고 받게 되고, 팀원들이 업무적으로 가지는 문제가 무엇인지 이해할 수 있게 된다는 말이다.
직설적으로 이야기 하면, 맨날 보고 안한다고 뭐라고 하지 말고, 실무에 도움이 좀 되란 말이다. 그럼 자연스럽게 팀원들이 보고하게 될테니까…
실무적으로 아는게 없다고 해서 팀원들에게 도움을 줄 수 없다는 말은 하지 말자. 외부와의 소통문제, 업무 협조 요청 등등 수많은 일들로 팀원들을 도울 수 있으니…

[Essay][시사]진정성이 중요한 이유…

유시민 전 장관께서 예전에, 서울대학교 강연에서 “진정성은 중요치 않다. 제시한 정책이 좋냐, 나쁘냐로 판단해야 한다.”라고 하셨던 것이 생각난다.
유 전 장관님의 이야기는 아마도, “초점을 정책 자체에 두라!”라는 의미였을 것이다. “정책은 정책 자체로 평가되어야 하지 외부적인 요소가 개입되면 안되다는 뜻” 이 아닐까? 난 그 말에 전적으로 동의한다.
그렇지만, 여기에 내 개인적인 생각을 약간 첨언하고자 한다.
정책을 판단할때 가장 중요한 요소는 정책 자체이다. 그런데 문제는, 정책이 “좋냐, 나쁘냐”를 판단할 수 있는 경우 만큼이나, 판단할 수 없는 경우도 많다는 것이다.
예를 들어, FTA (굳이 이번 한미 FTA가 아니더라도)에 대해서 생각해보자.
FTA로 인해 명백하게 이익이 되는 혹은 명백하게 손해가 나는 사람들이 분명히 존재한다. 그런 사람들이 FTA를 판단할 때는 정책자체 – FTA는 정책이 아니긴 하지만… 따지지 말자. – 를 놓고 찬성/반대 하면 된다.
그렇지만, 애매한 사람들도 많다. 이게 국민에게 – 라고 말하지만, 사실은 ‘나’에게 – 이익이 되는지 손해가 되는지 도무지 판단할 수 없는 사람들 말이다. 정부, 또 각종 언론 등에서 이런 저런 예측 수치를 내 놓지만, 그건 단지 예측일 뿐이다. 그것도 적중률이 상당히 떨어지는…

이럴 경우는 무엇을 근거로 정책에 대한 찬성/반대를 해야할 것인가?
이럴 때 ‘진정성’ 이 다시 중요해진다.
확률적으로, 정치인이 ‘진정’으로 “이것이 국가/국민에게 이익이 된다.”라고 믿고 추진하는 정책이, 정치인 개인의 이익에 근거해서 추진되는 것보다는, 국민/나 에게 이익이 될 확률이 높기 때문이다.
물론, ‘진정성’을 정확히 판단하는 것은, 정책 그 자체를 판단하는 것 만큼이나 어려울 것이다.
그렇지만, 특정 정치인의 삶의 발자취에 근거한 ‘진정성’에 대한 판단은 신뢰할 만하지 않을까?

그래서, 많은 사람들이 ‘진정성’에 대해 이야기 하고, 또 고민하는 것이 아닐까?
(물론, 특정 정치인의 삶의 발자취를 ‘제대로’ 분석하는 것이 쉬운일은 아닐테지만… – 그래서 언론의 역할이 중요한데, 이건 뭔…쩝…)

[Essay] 개인이 자체 개발 SW를 회사에 공개하지 않는 이유…

회사에서 근무하는 개발자들 가운데, 개발 자체를 좋아하거나, 혹은 기술을 숙련시키는 과정의 한 방법으로 자체적으로 SW를 개발하는 사람들이 있다. 대부분의 경우, 개인이 제한된 시간안에서 prototyping하는 정도일 것이다. 그렇지만, 그 중 몇몇은 조금만 개선/발전 시킨다면, 제법 괜찮은 SW의 근간이 되는 것들도 있을 것이다.
대표적으로, Google의 경우 20%의 시간은 개발자가 자기가 하고 싶은 것을 하도록 두는데, 여기서 나온 산물을 회사차원에서 지원해서 제품으로 발표한 것들도 적지 않은 숫자가 된다고 알고 있다.
그런데, 국내 개발자들 대부분이 자신이 틈틈이 개발한 SW를 회사에 공개하는 것을 극도로 꺼려한다.
왜 그럴까?

근본적으로 지적 재산권 문제가 걸린다.  물론 회사마다 정책이 다르겠지만, 국내 대부분의 회사에서는, 개발자가 자체개발 SW를 회사측에 공개하는 즉시 지적 재산권 전부를 회사에 넘겨준다고 보는 것이 좋다 – 국내 대부분의 회사의 고용계약서의 위의 사항이 명시되어 있다. 따라서, 내가 잠자는 시간을 줄여가며, 여가시간을 희생해 가면서 만든 SW를 아무런 대가 없이 회사에 넘겨 주는 것은 그리 유쾌한 일은 아니다.
그렇지만, 만약 공개한  SW가 회사의 지원을 받게 되고, 개발자 본인이 그 일에 참여할 수 있다면, 지적 재산권을 넘겨주는 손해도 충분히 감수할 만한 경우도 있다. 사실 자신의 SW를 회사에 공개하는 개발자의 대부분은 이런 결과를 기대했었을 것이다.
물론 의도한 대로 진행되면 좋겠지만, 회사의 판단이 개인의 판단과 달라서, 개발자 개인은 충분히 가치있다고 생각되는 SW를 회사에서 사장시키기로 결정했을 경우 문제가 복잡해진다.
이런 상황에서 개발자는 자신의 꿈과 열정이 담긴 SW의 가치를 믿고 계속 발전시켜 나가고자 하지만, 이미 지적재산권이 회사로 넘어간 이후이므로 그렇게 할 수가 없다. 왜냐하면, 개발자 개인이 아무리 많은 열정과 노력을 해당 SW에 쏟는다고 하더라도 모든 권리는 회사의 것이기 때문에 말 그대로 “죽 쒀서 개 주는 꼴” 밖에 되지 않기 때문이다.
즉, 원작자는 눈물을 머금고 자신의 SW가 사장되는 것을 지켜볼 수 밖에 없어진다.
이러니, 어떤 개발자가 자신의 SW를 회사에 공개하려고 하겠는가?

위와 같은 구조는 개인과 회사 모두에게 손해가 된다.
개인이 혼자서 SW개발을 하는 것은 분명히 한계가 있으므로, 개발자는 자신이 생각하는 내용의 SW를 완성시키기 위해 너무 많은 노력이 든다 (회사의 지원을 받을 수 없으므로). 반대로 회사는 충분히 좋은 idea의 SW들을 제공받을 수 있는 통로 하나를 상실한다.
이런 문제를 해결하기 위한 해결책은 없을까? 내 개인적인 생각은 아래와 같다.

기본적으로, SW의 지적 재산권은 회사가 가진다.
그렇지만, 공개된 SW에 대한 특정 심사 기간을 두고 (ex. 3개월), 회사에서 해당 SW를 사장시키기로 결정했다면, 해당 SW에 대한 지적 재산권을 개발자 개인에게 돌려 주는 것이다. 반대로, 만약 SW가 지원할 가치가 있다고 판단되면, 개발자에게 관련 중책을 맡긴다.

위와 같은 정책이 정직하게 운영되는 회사라면 아마도 많은 SW개발자들이 자신의 SW를 회사에 공개하지 않을까… 조심스럽게 생각해 본다.

[Essay] Sorry vs. Thank you.

내 생각에 대한민국은 ‘조언’의 문화보다는 ‘훈계’의 문화가 지배적인 것 같다.
‘조언’의 문화란, 대등한 관계에서 이루어지는 ‘제안’ 같은 것을 의미하고, ‘훈계’란 상하관계에서 가르침을 뜻한다.
대한민국에서 부모/자식 관계는 대등하기 보다는 상하관계에 가깝다.
따라서 부모는 자식을 ‘훈육’하게 되고, 자식입장에서는 가르침을 받게 된다.
‘조언’이든 ‘훈계’든 어떤 것이 낫고 나쁜지는 모르겠다.

그런데 재미있는 것은 ‘훈계’의 문화에서 사용되는 ‘가르침’이  ‘질책’의 의미로 사용되는 경우다.
사실 상당히 많은 경우, 상하관계에서의 ‘훈계’는 ‘가르침’보다는 ‘질책’의 의미를 가진다. ‘사랑’이 바탕이 되는 부모/자식 관계도 그러할진데, 다른 사회적인 관계에서는 말할 필요도 없겠다. 그래서 그런지, 대한민국이란 나라에서 (다른 나라의 경우는 잘 모르겠다.), 사회적인 관계를 형성하는 사람들 사이에서는 ‘감사합니다.’ 보다는 ‘죄송합니다.’가 더 익숙한 것 같다.

예를 들어, A 신입사원이 거래처와의 일을, 조금 어설프게 처리했고, 그래서 B대리는 A신입사원의 일처리에서 문제점들을 지적했다고 생각하자. 만약 A가 신입사원이 아니라 대리 혹은 과장이였다면, 위 사안은 ‘질책’이 될 가능성이 높다. 그렇지만, 신입사원이다. A가 일의 내용을 어설프게 처리할 것은 당연한 일이고, 아마 신입사원에게 맡긴 일이라면, 어느 정도의 실수는 용납될 일이 였을 것이다. 이런 경우, B대리가 A사원에게 하는 말은 ‘질책’처럼 들릴지라도 ‘훈계’에 가깝다. 그렇다면, A사원의 대답은 ‘죄송합니다.’ 보다는 ‘감사합니다.’가 옳지 않을까?
‘자신의 잘못된 부분을 지적해주고 가르쳐 주어서 감사합니다. ‘가 맡는 대답이 아닐까 말이다.
그렇지만, 우리들 대부분은 ‘죄송합니다.’가 먼저 튀어나온다. 자라온 환경에서 ‘훈계’보다는 ‘질책’을 받아왔던 탓이리라.
설사, ‘질책’이라 할지라도, ‘감사합니다.’는 여전히 유요한 반응이다.
‘질책’했다는 자체가, 관심의 표현이고, 더 잘되라는 뜻이기 때문이다. 그렇지만, 우리는 어김없이 ‘죄송합니다.’가 나온다.

어찌보면, 문화가 만들어낸 것인 것도 같다. 그리고 사실, 이것이 ‘잘못되었다!’라고 말할 근거도 용기도 없다.
그렇지만, 내 개인적인 생각으로는 ‘죄송합니다.’보다는 ‘감사합니다.’가 듣기도 좋고, 한결 부드러운 것 같다. 아닌가?
‘조언’이든 ‘훈계’든 아니면 그것이 ‘질책’이든, ‘죄송합니다.’보다는 ‘감사합니다.’가 먼저 생각나고 떠오를 수 있는 문화, 그런 문화는 과연 어떨까?

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

다음은  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에 대한 주제로 바꾸어 봅시다. ”
식으로 ‘문답’을 유도해 나가면 된다.

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

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

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

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)는 아직 경험해 보지 못했다.
과연 어느 쪽어 더 효율적일까? (산업/업무 문야에 따라 다르겠지만…)

[Essay] 비효율적인 회의가 발생하는 여러가지 상황들…

*  leader가 담당자의 기술적인 능력을 신뢰하지 않을때.

보통, leader가 기술적으로 뛰어나거나, 실무자가 기술적으로 미숙한 경우 많이 볼 수 있다. 이 경우, leader는 담당자가 report하는 사항에 대해 기술적인 detail을 모두 다 알려고 하고, 기술적인 문제에 대한 guide를 하길 원한다.
실제로 leader의 해당 분야에 대한 기술적인 역량이, 담당자보다 뛰어난  경우, 이런 방식이 효과적일 수 있다. (예. 신입사원과 경력사원의 사수-부사수, 혹은 멘토-멘티 의 관계.)
그렇지만 (실무자의 역량이 조금 부족하다고 하더라도) 실무자 보다 leader가 해당 분야의 기술적인 역량이 뛰어난 경우는 거의 없다.
그럼에도 불구하고, leader가 해당 실무자의 기술적인 능력을 신뢰하지 못하게 되면, 실무적인 보고 사항에 대한 세세한 부분까지도 알고자 하게 된다.
따라서, 실무자는 실무의 상세한 부분을 leader에게 설명해서 이해시켜야 하게 되고, leader의 ‘미숙한’ 기술적인 질문에 답해주어야 한다. 이는 실무자에게 상당한 overhead로 작용하게 된다.
이런 관계의 reporting line이 길어지면 길어질수록, 효율은 급격하게 떨어지게 된다.

의사결정을 해야할 경우는 leader는 reporting을 받으면서 – 담당자를 믿지 못하므로 – 좀 낫다고 생각되면 몇몇 다른 실무자들을 동반할 지도 모른다.
이 경우 문제는 좀더 심각해진다. 올바른 방향으로 의견이 잘 정리되어 모아 진다면 좋겠지만, 그렇지 않은 경우, 참석한 모든 사람들 사이에 공감대가 형성되기 전까지는 회의가 계속되는 비효율이 발생하게 된다.
특히, 중간 중간에 사람을 좀더 불러 들이는 것은 더욱 안 좋다. 회의에 참석하게되는 실무자들 역시 문제의 기술적인 detail까지 알고 싶어할 것으므로, 담당자는 이들 모두에게 또 다시 반복적으로 기술적인 설명을 해야 한다.
Leader의 요청에 의해 참석한 실무자가 기술적으로 뛰어날 수도 있겠으나, 해당 분야에 대해서 담당자 보다 더 잘 아는 경우는 거의 없다.
따라서, 담당자는 leader를 위해서 그러했듯이 다시 회의에 뒤늦게 합류한 실무자를 위해 같은 설명과정을 계속해서 반복해야 한다.
그러므로, 이런 경우는 회의하는 사람의 숫자를 될 수 있으면 줄이는 편이 좋다.
“좀더 많은 사람의 생각이 모이면 좀더 좋은 생각이 나온다.”라는 말은 평등한 구조의 회의에서 성립되는 말이다.
보통의 회사에서 “평등한 구조”는 존재 하지 않는다. 노파심에서 많은 사람들을 불러 들이기는 하나, 실제로 의사결정에 관여하는 사람은 소수일 뿐이다.
실제로 회사에서 다수의 사람들을 모아 놓고 회의가 진행되는 모습을 보면 소수 (이것도 20:80 법칙을 적용 받는지는 모르겠지만…)의 사람들이 발언권을 독점하고 나머지 사람들은 꿔다놓은 보릿자루처럼 머릿수만 채우고 않아 있는 경우가 대부분이다.
왜 이런 문제가 발생하는지는 여기서 논의하지 않기로 하자. 단, 현실이 그러하다는데는 큰 이견이 없을 거라고 본다.
따라서, 차라리 의사결정에 필요한 최소한의 인원으로 회의를 진행하는게 오히려 나아 보인다.
실무자가 기술적인 내용을 일일이 설명해야할 비용도 줄어 들고, 회의 참석자들간 공감대를 만들어 내기도 더 쉽기 때문이다. 잘못될 결정을 할 가능성은? 필자가 보기에는 별 차이가 없다.

* leader가 자기 자신의 기술적인 역량이나 실무적인 역량에 자신감이 없을 때.

실무를 떠난지 오래된 leader에게서 종종 볼 수 있다. management가 주 업무가 되면서 실무에 대한 ‘감’을 잃어버리게 된 경우다.
이 경우, leader는 기술적인 지식이 필요한 모든 회의/논의에 실무자들을 불러 들인다.
예를 들면, 2시간의 회의에, leader한명, 실무자 10명이 들어가서, 실무자들은 말 그대로 그냥 ‘듣고만’ 나오는 경우다.
leader는 언제 나올지 모르는 기술적인 문제를 상의하기 위해서 실무자들을 전부 이끌고 들어간다. 그렇지만, 실제 이런 문제에 답해 줄 수 있는 기회를 갖는 실무자는 한 두명 뿐이다. 나머지는 말 그대로 “시간만 때우고 머릿수만 채우는” 겪이 된다.
이런 일이 반복될 경우, 실무자는 시간을 뺏기는 것은 물론, 업무에 집중하기도 힘든 상황이 된다.

to be updated…