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

  1. 2012.11.09 error value global vs. module specific
  2. 2012.07.31 두 가지 SW Branch정책에 대한 단상.
  3. 2012.07.18 회사내에서 추친하는 직원들 기술 교육의 효과가 미미한 이유에 대한 생각.
  4. 2012.06.07 R&R(Role And Responsibility)의 범위의 유연성에 단상
  5. 2011.06.01 [Essay] SW 엔지니어 역량 측정 - 02
  6. 2011.05.31 [Essay] SW 엔지니어 역량 측정 – 01
  7. 2011.05.17 [Prog] Separating mechanism from policy (microscopical view) - function implementation.
  8. 2011.04.22 [Essay] SW 엔지니어 역량 측정 - 00
  9. 2011.03.25 [Essay] 기술면접에서의 질문방법에 대한 단상
  10. 2011.03.02 [Essay] SW영역에서 Role and Responsibility를 정의하는 두 가지 방법에 대한 비교/단상...

error value global vs. module specific

Essay/Software 2012.11.09 14:41

 소프트웨어가 커지다 보면, 자연스럽게 OOP개념들을 집어 넣을 수 밖에 없고 - 그렇지 않으면, SW 유지보수가 거의 불가능 하다. - 각 컴포넌트/모듈들을 독립적으로 구현하기 위해서 고민하게 된다.

 각 모듈이나 컴포넌트가 독립적일수록 재사용성이 높아지고 모듈간 의존도가 줄어들게 된다.

 그런데, 문제는 이렇게 서로 독립적으로 만들다 보면, error value들 역시 독립적으로 선언해야 하게 되는데, 이게... 좀... 거시기 하다.

예를 들어, 모듈 A, B, C가 있을 때, A -> B -> C 이런식으로 C가 B를 reference하고, B가 A를 reference하는 경우, C와 B는 각각 내부 구현을 숨기기 위해서, B와 A의 error value를 노출 시킬 수 없게 된다. 따라서, B는 A의 error value를 B자신의 value로 mapping해야 하고, C또한, 이렇게 mapping된 B의 value를 다시 C자신의 value로 mapping해야 하게 된다.

 쩝... overhead의 chain effect라 불릴만 하다.

그래서 많이 하는 방법이, 상당히 자주 사용되는 error value는 global하게 공통적으로 정의하고 - ex. invalid parameter, out of memory 등등 - 세부적인 것들에 대해서는 모듈 specific하게 정의하는 것이다.

예를 들면...


common_error.h

enum {

COMMON_ERR_01 = 0,

COMMON_ERR_02,

...

LIMIT_COMMON_ERR,

CUSTOM_ERR_BASE_OFFSET,

};


module1.h

enum {

MODULE1_ERR_01 = CUSTOM_ERR_BASE_OFFSET,

MODULE1_ERR_02,

...

};


module2.h

enum {

MODULE2_ERR_01 = CUSTOM_ERR_BASE_OFFSET,

MODULE2_ERR_02,

...

};


 음... 꽤나 괜찮은 해결책으로 보인다. 아니, 현재까지 생각으로는 현실적으로 가장 좋은 해결책으로 보인다.

 그렇지만, 여전히 몇 가지 문제점이 존재한다. 먼저, error value의 return type을 그냥 int 를 사용해야 하는데 - 공통된 error value의 type을 정의할 수 없다 - constant value는 inline으로 코드에 삽입되기 때문에, debugging시에 썩 좋지 못하다는 문제가 있다. 또한, return type이 그냥 int 라 code readability도 썩 좋지 못하다.  또한, global common error code가 module내에서 사용되므로, 이 모듈을 전혀 다른 SW에 porting할때, common error 부분을 해당 SW에 맞게 수정을 가해야 하는 문제도 있다.

 그렇지만, overhead와 재사용성 양쪽을 균형있게 고려한, 충분히 훌륭한 방법임에는 틀림없다.


음...

 혹시 다른 좋은 아이디어가 떠 오르면... 다시 posting하기로 하고...

신고
Trackback 0 : Comment 0

두 가지 SW Branch정책에 대한 단상.

Essay/Software 2012.07.31 12:28

뭐.. 여러가지 SW Branch 정책들이 있을텐데... (하나의 branch에 전부 때려 잡아 넣고 개발하는 회사라면... 쩝 뭐 특별히 할 말 없다)

보통의 경우 SW branch는 아래와 같은 형태를 가진다.


+------------------------------ sub branch

/ ---------+-------------------+-------------------------------------- main branch

\

+------------------------------------ sub branch


기본적인 형태는 같지만, 정책적인 측면으로 보면 크게 두 가지로 분류할 수 있다.


1. 큰 main branch 정책

main branch가 기능 구현의 주요 작업 공간이 되는 방법.

main branch 가장 자주 update된다.

- feature이 대부분 main branch에서 개발되므로, 다른 외부 project branch의 개수가 적은 편이다.


2. 작은 main branch 정책

sub-branch가 기능 구현의 주요 작업 공간이 되는 방법.

- main branch가 가장 뜸하게 update되고 엄격하게 관리된다.

- feature들을 main branch와는 별도로, 서로 다른 project branch로 관리한다.


위의 두 가지 모두 기본적인 업무 방식은 같다.

1. 특정 시점에서 main branch에서 branch out

2. 필요한 새로운 feature들을 구현하거나, 다른 feature branch로 부터 가져오고, stability를 향상시킴

3. software release

4. 필요한 patch들을 main branch에 다시 merge함.


그렇지만, 위와 같이 서로 다른 방식의 정책을 적용하다보면, branch의 특성이 서로 달라진다.

1. 큰 main branch 정책

- main branch는 feature위주로 관리된다.

- main branch는 거의 모든 feature들을 가진다.(feature들의 super-set)

- main branch가 가장 많은 버그를 가진다.

- main branch의 코드 size가 sub branch에 비해 크다.

- 보통 branch out의 기준은 feature가 된다. 즉, 특정 feature가 available한 시점을 기준으로 main branch로 부터 branch out한다.

장점 : Integration에서 발생가능한 문제들이 main branch에서 충분히 다루어진 상태이므로, sub branch에서 이 문제에 대한 risk가 적다.

단점 : main branch의 stability관리가 어렵다. 그래서, sub branch에서 stability를 위한 비용이 크다.


2. 작은 main branch 정책

- main branch는 stability위주로 관리된다.

- main branch는 최소한의 feature만을 가진다.

- main branch의 stability가 가장 뛰어나다.

- branch out의 기준은 feature보다는 stability가 된다.

장점 : main branch의 stability가 충분히 좋으므로, sub branch에서 stability문제가 발생하더라도, main branch를 기준으로한 debugging이 가능하므로, 적은 비용으로 sub branch의 stability를 유지할 수 있다.

단점 : integration에 따른 문제들이 충분히 드러난 상황이 아니므로, sub branch에서 이것과 관련된 많은 문제들이 나올 수 있다.


branch 정책을 결정할 때는 위의 두 가지 요소를 충분히 고려할 필요가 있다.

stability에 대한 비용 vs. integration에 대한 비용

그리고 거기에 따라, branch 정책을 정할 필요가 있다.


개인적으로 봤을 때, 대부분의 경우, stability를 위한 비용이 integration비용에 비해 상당히 비싸다.

따라서, 작은 main branch정책이 더 좋은 것 같은데.... 


신고
Trackback 0 : Comment 0

회사내에서 추친하는 직원들 기술 교육의 효과가 미미한 이유에 대한 생각.

Essay/Software 2012.07.18 09:38

어지간한 규모가 있는 회사라면, 이유나 목적이야 어떻든 공식적으로는 직원들의 역량 강화라는 명목으로 교육을 실시하는 경우가 많다. 하루짜리 단일성 교육부터 8시간 4~5일짜리 장기교육까지... 가격도 어마어마하다.

그런데 그런 교육의 효과는 어떠한가? 그만한 값어치를 하는가? 교육을 받는 당사자의 생각도 중요하지만, 돈을 들여 교육을 실시한 회사의 입장은 어떤가? 직원들을 일주일간 업무에서 빼고, 비싼 강의료를 지불하면서까지 실시한 교육의 그만한 가치가 있다고 생각하는가?

대부분의 경우 만족스럽지 못할 것이다. 왜 그럴까?

아래는 전부 내 개인적인 생각으로 어떠한 근거도 뒷받침할 자료도 없다. -_-;


과거 학생 때를 돌이켜 보면, 공부에서 가장 중요한 것은 예습/복습이다. 회사에서 실시하는 교육도 그 연장선상에 있다고 본다.

보통 회사에서 실시하는 교육자체가 직무관련 교육인 경우가 많기때문에 어느정도 예습의 효과는 있다고 본다. - 물론, 교육의 커리큘럼을 따라서 제대로 예습한다면 더 좋겠지만...

그런데 문제는 '복습'이 전혀 이루어 지지 않는 다는 것이다.

1주일 교육이라면, 그 교육이 끝난 뒤에는 바로 업무에 복귀하게 되고, 일반적으로 회사에서 수행하는 없무는 교육받은 내용과 어느 정도 거리가 있기 마련이기 때문에 교육기간 동안 습득한 내용을 자기 것으로 만들 시간이 거의 없다.

복습의 효과에 대해서는 이미 수많은 검증된 연구결과들이 있다. 복습을 전혀 하지 않는 것과 어느 정도 복습을 하는 것은 교육의 효과와 더불어 내용을 기억하는 기간에 엄청난 차이를 가져온다.


그래서 난, 회사가 어차피 직원들을 교육시키는데 비용을 투자하기로 결정했다면, 약간의 비용 - 직원들이 업무 외의 일을 할 수 있는 추가적인 시간 - 을 더 투자해서 '강의'를 통한 교육에 이어서 교육의 내용을 소위 '복습'할 수 있는 공식적인 기간을 주는 것이 필요하다고 본다.

물론, 회사에서 하는 일이니 측정가능한 '성과'는 있어야 할 것이다.

그것이 세미나의 형태가 되었건 아니면, 잘 정리된 문서가 되었건, 아니면 교육의 내용을 기반으로한 간단한 소프트웨어 툴이 되었건, 자신이 습득한 내용을 정리하고 적용해 볼 수 있는 시간을 공식적으로 주고 또 장려할때, 교육의 성과가 극대화 될 것이라고 본다.


구체적으로 예를 들어보면, 하루 8시간 5일 교육을 가정하면, 이후 일주일 - 5 업무일 - 은 '복습'의 시간으로 할애해서, 피 교육생들이 교육시간에 배웠던 것들을 이것저것 실습해보고 적용해 보도록 하는 것이다...


쩝... 전부 내 개인적인 생각들이였다... 교육 들을때만 고개를 끄덕이고, 끝나고 일주일만 지나면, 뭘 들었는지조차 기억에서 희미해지는 그런 비효율적인 교육들을 보면서 답답한 마음에 끄적여 본다...

신고
Trackback 0 : Comment 0

R&R(Role And Responsibility)의 범위의 유연성에 단상

Essay/Software 2012.06.07 10:12
소프트웨어 엔지니어로 10년 가량 직장생활을 하면서 R&R(Role And Responsibility)에 대한 고민은 항상 있어 왔던 것 같다.
블로그에 R&R에대한 다른 포스트들도 여럿 더 있고...
뭐, 사실 이런 류의 논의는 정답이 없기 때문에 더욱 곤란한 경우가 많은데, 각설하고, 한가지 경우에 대한 장단점을 이야기 하고자 한다.

R&R에 대해 이야기 할때, 가장 주로 사용되는 방식이...

너의(혹은 너의 팀의) 주 임무(Main Role)은 'xxx'이다. 그렇지만, 거기에 국한되지는 않는다(not limited). 그러므로 경우에 따라서는 다른 사람(팀)의 일을 도와 주어야 하는 경우도 있을 것이다.


이런 식인데... 과연 이게 적절한 방식인가에 대한 이야기이다

물론, 일 자체가 너무 달라서, 서로의 영역을 서로 도와 줄 수 없는 경우는 고민할 거리도 없지만... 개발 조직 내에서는, 특히 소프트웨어 에서는, 다른 영역에 contribution하는게 충분히 가능하기 때문에 위와 같은 정의가 자주 사용되는 것 같다.


사실 "너는 이 일만 해!"는 현실적으로 불가능하다. 그래서 "거기에 국한되지는 않는다.(not limited)"라는 말이 항상 들어가게 된다.

왜 현실적으로 불가능한가?

일이라는게, 항상 고정되어 있는 것도 아닐 뿐더러, 어떤 때는 이 일이 많았다가, 어떤 때는 저 일이 많았다가... 이런 식이기 때문이다.


장점이라면, 당연히, 남는 자원을 적절히 분배할 수 있다. 특정 일이 많을때는 그 일을 서로 나누어서 할 수 있으니, 인적자원의 효율적인 활용이 가능해 진다.

단점이라면? 사실 이 부분이 이 글에서 이야기하고 싶은 부분인데... 예를 들어 A, B 두 팀이 있다고 생각해 보자.

A팀은 굉장히 적극적이고 또 능력도 뛰어나서 맡은 일을 빠른 속도로 처리해 나가는 팀이고. B팀은 A팀과 반대되는 성향을 가진다고 생각하자.

이 경우, 위와 같은 R&R의 정의를 적용하면, B팀은 항상 제 시간에 일 처리를 끝내지 못하기 때문에 A팀은 항상 B팀을 도와주는 형태로 업무가 진행되게 된다.

A팀은, 비록, 열심히 부지런히, 그리고 소위 '스마트'한 방법으로 자신들의 역할을 다 했음에도 불구하고, B팀의 상황이 안 좋기 때문에 B팀을 도와 주게 되는 것이다.

만약 B팀 역시 A팀과 비등한 정도의 열정/성실/능력 을 가진 팀이라면, 이런 상황은 어쩔 수 없고, A팀 역시 커다른 불만 없이 B틈을 도와 줄 것이다.

왜냐하면, 이 경우는 명백하게, 순간적으로 B팀에게 일이 몰리는 상황이고 이것은 어떻게 처리할 수 없는 형국이기 때문이다.


그렇지만 많은 경우, B팀의 불성실/게으름 등등의 이유로 절대적인 일의 양은 A팀에 비해 많지 않았음에도(혹은 오히려 적었음에도) 불구하고 이런 일이 일어나게 된다. 그리고 이런 경우, A팀에서 이런 사실을 모를리 없다. 이는 당연히 불만으로 이어지고, A팀의 사기를 떨어뜨리게 된다. A팀 역시 일을 부지런히, 빨리 끝낼 이유가 없으니까... 빨리 끝내봤자 B팀의 일을 해야 하니...

B팀 역시, 어차피 A팀이 도와줄테니, 최선을 다해서 현 상황을 이겨나갈려고 하지도 않는다.

즉, B팀 입장에서는 Role은 있으되, Responsibility는 없는 형국이랄까... (A, B팀 공동 책임이다.)


자... 이 두 가지 장/단점 중에서 어느쪽에 손을 들어주어야 하는가?

물론, 항상 어느 한 팀의 일이 많다면, 이것은 일의 양을 잘못 판단한 관리자의 책임이고, 팀 구성을 새롭게 가져 가야 한다.


개인적으로는 지금까지, 위와 같은 R&R의 정의만 보아 왔다. 따라서, 위와 반대되는 R&R을 정의하고 조직이 흘러가는 경향을 관찰해 보고 싶은 호기심을 느낀다.

긍정적인 방향이라면, 각 팀의 자신의 일을 최대한 효율적을 빨리 끝내려고 '스마트'한 일 처리 방식을 끊임없이 연구할 것이고, 일의 전반적인 효율이 증대될 것이다.(일을 빨리 끝내면, 놀 수 있으므로...)

부정적인 방향은, "왜 우리만 항상 고생하는데!"와 같은 불만으로 팀웤이 손상되는 방향이 있을 수 있겠다.


일의 영역이 장기간 고정적이고 변화가 적다면, 유연성이 없는 엄격한 R&R정의도 고민해 볼 필요가 있지 않을까?


신고
Trackback 0 : Comment 0

[Essay] SW 엔지니어 역량 측정 - 02

Essay/Software 2011.06.01 08:44

[ SW 엔지니어에 대한 잘못된 생각들 ]

SW를 잘 알지 못하는 사람들이, SW 엔지니어에 대해 이야기 할때 일반적으로 범하기 쉬운 몇가지 오류들에 대해서 짚어보고자 한다.

* SW엔지니어는 일정을 이야기할때 굉장히 보수적인 일정만을 말한다.

음... 일부러 일정을 늘려서 이야기하는 엔지니어도 분명히 존재한다.
그렇지만, 그런 경우는 엔지니어의 태도문제도 존재하지만, 조직의 분위기에도 문제가 있다고 보는게 옳다.
estimation한 일정을 지키지 못했을 경우 - fix된 일정이 아니라 estimation한 일정임에도 불고하고 - '실패'로 몰아세우면서 질책하는 문화에서는 보수적인 일정을 제시할 수 밖에 없기 때문이다.
이런 '책임 회피성 일정'을 논외로 한다면, 엔지니어들은 일정을 굉장히 aggressive하게 제시하는 경향이 오히려 강하다.
왜냐하면, 일에 대한 구체적인 분석이 없는 상태의 초기 estimation은 항상 여러가지 사항들을 놓치게 마련이고, 따라서 실제 일의 양보다 적은 양을 예상하기 때문이다.
그래서, "실질적인 일정 = 엔지니어의 예상 * 2"라는 우스겟 소리도 있다.
따라서, 필자는, 조직에서 SW엔지니어들이 보수적인 일정을 제시하는 경향이 있다면, 그것이 소위 '책임 회피성 일정'이 아닐까를 먼저 의심하고 그렇게 할 수 밖에 없게 만드는 조직의 문제점을 찾아서 제거할 필요가 있다고 생각한다.

* SW엔지니어의 생산성은 투입된 시간에 비례한다.

SW작업에서 물리적인 시간적 투자를 필요로 하는 일은 일부에 지나지 않는다. 대부분은 고도의 집중력을 요구한다.
대부분의 사람들이 위의 이야기에는 동의함에도 불구하고, SW엔지니어가 일한 시간에 관심을 가지는 이유는, 생산성을 측정할 수 있는 방법을 알지 못하기 때문이다.
그렇기 때문에 '시간 투자 = 성실/성과' 이라는 차선(?)책을 사용하고 있고, 이것이 생산성과 시간과의 관계에 대한 잘못된 생각을 퍼트리고 있다.

* 많은 버그를 잡는 사람은 뛰어난 SW엔지니어이다.

버그는, 수정하는게 중요한게 아니고, 만들지 않는 것이 중요하다.
이는 비단 초기 개발 단계만의 이야기가 아니다. 버그를 잡기 위해서 다시 버그를 만드는 과정을 반복하는 많은 미숙한 엔지니어들이 있다.
만약, 실제로 SW를 개발을 하는 팀이라면, 버그에 관계된 성과 측정기준은, 반드시 "발견된 버그의 개수"가 되어야기 "수정한 버그의 개수"가 되어서는 안된다.
이는 유지보수팀에서도 일정부분 적용되는데, 유지보수팀에서는 "버그를 수정한 수"에 앞서 "fix-on-fix"의 수에 더 많은 가중치를 주어야 할 것이다.
넘치는 fix-on-fix를 감당하지 못해서 commit자체를 revert하는 경우도 심심치 않게 일어난다.

* 디버깅을 잘하는 사람은 programming도 잘 한다.

'만류귀종'이라는 말처럼, 궁극에 이르면 두 가지 능력 모두 최고 수준을 보일 것이다.
그렇지만, 상당부분에서 디버깅과 programming은 서로 다른 skill을 요구한다.
필자의 post 중 여기 를 참조하자.

* 작성한 코드의 line수와 생산성은 비례한다.

정말 이 말을 맏는가?
무관하다고 말할 수도 없지만 - 1년에 1라인을 작성한 사람과 하루에 1000라인을 작성한 사람 - 그렇다고 해서 비례하지도 않는다.
너무 극단적인 경우를 제외하고는, 이것은 성과측정의 기준이 될 수 없다.

* 변수/함수의 이름을 바꾸기, 하나의 함수를 두개로 분리하기, compiler warning을 제거하기, 주석 추가/수정하기 등 실질적으로 코드의 동작과 무관한 contribute는 무의미하다.

이런 일들이 생산성과 무관하다고 생각하는 사람이 있다면, 음... 더 이상 필자의 글을 읽을 필요가 없다.
왜냐하면, 기본적인 믿음 자체가 다르기 때문이다.
필자가 보기에는, 이런 일들은 버그를 잡거나, 새로운 기능을 구현하는 것만큼 중요하다.
SW의 가독성을 높여서, 유지보수를 쉽게 하고, SW의 장기적인 건전성을 확보하는 일은 그리 가벼이 볼 일이 아니다.

* 뛰어난 SW 엔지니어는, 버그 및 수정 요구사항을 빠르게 해결해서 적용한다.

'속도'가 중요한게 아니다.
지나치게 빠르다고 생각되는 대부분의 수정은 다량의 'fix-on-fix'를 유발하는 경우가 많다.
'얼마나 빨리 하느냐?' 가 아니라, '얼마나 정확히 잘 하느냐?'가 중요하다.
빨리 했지만 결국에는 버려야 할 contribute보다는, 조금 늦게 진행되고 있지만 착실한 contribute가 가치가 있는 법이다.

기타 많은 것들이 더 있겠지만.. 일단 여기까지만... 생각나면 더 추가하도록 하겠다..

신고
Trackback 0 : Comment 0

[Essay] SW 엔지니어 역량 측정 – 01

Essay/Software 2011.05.31 19:28

* SW 엔지니어에 대한 역량 측정의 어려움 *

SW 엔지니어에 대한 역량 측정이 그렇게 중요하다면, 왜 지금까지 이런 것들이 잘 이루어지고 있지 않는 것인가?
아니, 그전에 "제대로 이루어지지 않고 있다."라는 필자의 주장에 대한 근거를 먼저 제시하고자 한다.

SW 개발비용산출시 많이 사용되는 단위가 MM(man-month)이다.
이는, "얼마나 많은 '사람'이 얼마간의 '시간'에 걸쳐 해야 하는 일인가?"를 나타낸다.
이런 방식의 측정은 개인간의 생산성 편차가 작으면 작을 수록 신뢰도가 올라간다.
단순 반복 노동같은 경우,어느 정도 신뢰도 있는 결과를 보여줄 수도 있을 것 같다.
그렇지만, SW programming의 경우, 개인간의 편차가 상당히 크다.
여러 연구 결과가 이를 잘 말해주고 있으니, 특별히 첨언하지는 않겠다.
그런데, 실제 비용산출시에는 MM을 쓴다.
또 다른 근거로는, SW 분야에서, 채용시 지원자의 처우는 대부분의 경우, 전 직장에서의 처우/연봉 + 그 사람의 경력에 의해 결정된다는 점을 들 수 있다.
만약 어떤 방법을 통해서 그 실력을 검증할 수 있다면, 위의 조건들이 지원자의 처우를 결정하지는 못할 것이다.

그렇다면 왜 아직도 이런 문제점이 해결되지 않고 있는가?
SW 엔지니어의 역량을 사회적인 합의가 이루어진 척도를 통해서 수치화 시키는 것이 상당히 어렵기 때문이다 - 사실 불가능에 가깝다.
이제부터 왜 그런지 하나씩 살펴보자.

* SW분야는 일정 수준이 넘어서면, 철학적인 문제를 상당 수 동반하게 된다. 따라서, '정답'이 없는 경우가 많다.

C 언어의 syntax에 대한 문제는 '답'이 있다.
즉, '틀렸다' 혹은 '맞았다'를 말할 수 있다.
그렇지만, C언으로 어떤 방대한 크기의 SW를 만든는 경우, SW layering, architecture design 등에는 정답이 없다.
요구사항에 대한 이해의 정도, 개인의 SW design철학/경험 그리고 속해있는 조직/분야의 culture 등에 따라 다양한 형태의 결과물이 나올 수 있고, "어떤 것이 더 낫다 ."라고 명백하게 판단할 수 없는 경우가 대부분이다.
구체적인 예를 들어보자.
Unix culture는 "정상적인 동작에 대해서는 어떠한 feedback도 주지 않는다." 라는 부분이 있다.
그렇지만, MS Windows의 경우는 "현재 어떤 일이 일어나고 있는지 feedback을 주어야 한다."는 culture가 있는 듯 하다 [*1].
어떤 것이 더 좋은가?
정답이 없다. 각각 장,단점이 존재하고 이러한 장,단점 역시 논쟁의 소지가 충분하다.
물론, 위와 같은 고 수준의 문제가 아니라면 대부분의 전문가들이 동의하는 방법론이 존재하는 것이 사실이다.
그렇지만, 이런 방법론 역시 절대적인 것이 아니기 때문에, 제시된 해결책을 받아들이지 않는다고해서 논리적으로 "당신이 틀렸다."라고 설득할 수 있는 방법은 존재하지 않는다.
이렇게 '정답'이 없는 기술에 대한 역량 측정이 쉬울 리가 없다.

* 좋은 SW의 가치가 실질적인 형태로 나타나기까지는 시간이 걸린다 .

SW life cycle에서 maintenance는 압도적인 비중을 차지한다.
그래서, 좋은 SW design/coding의 방법론을 이야기할 때 maintenance비용에 대한 부분이 항상 언급된다.
그런데,  "maintenance의 비용을 줄이기 위해 많은 노력과 고민을 통해서 SW를 design하고 구현한 결과물"과, 소위 말하는 "당장 돌아가만 가는 결과물" 두 가지에 대한 차이를, 기술적인 지식이 부족한 의사결정권자들이  구별해 내는 것은 불가능에 가깝다.
위에서 언급한 두 가지 SW 결과물의 차이가 실질적인 '비용'의 형태로 나타나는 것은, 개발과 maintenance가 같은 사람/팀에 의해 최소한 2~3년이상 이루어졌을때 부터이다.
그리고, 그 이후에는 차이가 기하급수적으로 벌어진다. 그렇지만 이 말은, 기술적인 분석을 제외한 상태에서, 좋은 SW와 나쁜 SW를 구별하기 위해서는 2~3년의 시간이 필요하다는 뜻이기도 하다.
물론, 기술적인 분석 자체도 상당한 시간을 요구한다.
이런 SW의 특성은, 단기간내에 금전적인 가치로 환산된, 수치화 된 결과물을 바라는 국내 산업환경과 대치된다.

* 기술적으로 뛰어난 사람이라 하더라도, 엔지니어의 실력을 평가하는데 오랜 시간을 필요로 한다.

각종 오디션을 생각해 보자. 노래, 춤, 연기 등등.
그런데, 'SW programming 오디션' 이라는 말을 들어본 적이 있는가?
(Programming 대회를 말하고 있는 것이 아니다.)
없을 것이다. 노래/춤 같은 오디션은 처음 몇 초만을 보고도 미숙한 지원자의 상당 수를 걸러 낼 수가 있다.
그렇기 때문에, 하루에 수백명의 오디션을 볼 수가 있는 것이다.
그렇지만, SW의 경우는 다르다.
노래/춤의 오디션에서 자격 미달의 미숙한 지원자를 찾아내기 위한 '몇 초'는, SW 엔지니어의 면접에서는 '몇 십분'에 해당한다. 이런 상황에서 어떻게 많은 수의 엔지니어를 충분히 평가할 수 있겠는가?
그리고, 어차피 충분히 평가할 수 없다는 것을 알고 있기 때문에, 평가자 역시 일정 수준이상의 노력은 사용하지 않는 것 같다.

* SW에는 다양한 분야가 존재한다.

비록 SW라는 이름으로 통합되어 있지만, SW는 다양한 분야로 이루어져 있다. 그리고 각 분야가 필요로 하는 기술적인 지식 또한 다양하다. 이런 점을 반영하기 위해서, SW 엔지니어의 기술적인 역량을 이야기 할때, domain knowledge를 같이 이야기 하게 된다. 예를 들면, Java Application SW, System SW 등등이 있겠다.
업무 영역 또한 다양하다. Integration, Programming, Debugging, Porting 등의 분야가 있고, 각 분야에서는 요구하는 skill set에는 어느 정도 차이가 있다. 그렇기 때문에,  programming은 정말 잘 하지만, 다른 사람의 code를 debugging하는 능력은 평범한 사람이 있고, 반대로 programming skill자체는 평범하지만, debugging에는 뛰어난 성과를 보이는 사람도 존재한다.
이런 다양한 가치들을 고려한 측정기준을 만드는 것은 결코 쉬운일이 아니다.

이외에도 많은 이유들을 들 수 있겠지만, 일단 이 정도만 이야기 하도록 하겠다.

[*1]
이 부분에 대해서는, 특별히 어디에 명시적으로 언급되어 있질 않아서 100%확신할 수는 없지만, 대부분의 Windows program이 일어나고 있는 일들에 대해서 feedback을 준다.
예를 들면, Unix에서 "rm -rf ."는 정상적으로 동작한다면, 끝날때 까지 아무런 feedback도 주지 않는다.
그렇지만 Windows의 경우, 어느 정도 진행되고 있는지 progress bar의 형태로 보여주는 것이 일반적이다.

신고
Trackback 0 : Comment 0

[Prog] Separating mechanism from policy (microscopical view) - function implementation.

Essay/Software 2011.05.17 14:13

Separating mechanism from policy is very important issue of SW design.
This is also true for microscopic area - implementing function.
Here is one of simplest example - function that calculates area of rectangle.

int rect_area(int left, int top, int right, int bottom) {
        return (right - left) * (bottom - top);
}

Simple, isn't it?
But, this function doesn't have any exception/error handling.
Let's add some of them.

int rect_area(int left, int top, int right, int bottom) {
        if (left >= right)
                left = right;
        if (top >= bottom)
                top = bottom;
        return (right - left) * (bottom - top);
}

It's seems good.
Soon after, another function that calculates area of rectangle is needed.
But, this function should return error value if input rectangle is invalid.
I think quick solution is

int rect_area2(int left, int top, int right, int bottom) {
        if (left > right || top > bottom)
                return -1;
        return (right - left) * (bottom - top);
}

But, in this solution, code for calculating area of rectangle is duplicated.
At above example, this is just one-line code. So, duplicating is not a big deal.
But, it's not good in terms of code structure.
Why did this happen?
Calculating rectangle area is 'Mechanism'.
But, exception/error handling is 'Policy' at this example.
So, above example should be implemented like below.

static inline int _rect_area(int left, int top, int right, int bottom) {
        return (right - left) * (bottom - top);
}

int rect_area(int left, int top, int right, int bottom) {
        if (left >= right)
                left = right;
        if (top >= bottom)
                top = bottom;
        return _rect_area(left, top, right, bottom);
}
int rect_area2(int left, int top, int right, int bottom) {
        if (left > right || top > bottom)
                return -1;
        return _rect_area(left, top, right, bottom);
}

Can you know the difference?
'_rect_area' is implementation of pure 'Mechanism'.
And policy is implemented at each interface function.
Even for simple function, developer should consider CONCEPT of separating Mechanism from Policy.

신고
tags : function
Trackback 0 : Comment 0

[Essay] SW 엔지니어 역량 측정 - 00

Essay/Software 2011.04.22 13:43

* 들어가는 글. *

SW 엔지니어로 다년간을 보내면서, 많은 불합리/부조리 를 보아왔다.
그리고, 이런 문제들이 어디서부터 비롯되었는지를 고민해 왔었다.
나 뿐만이 아니라 이 바닥 (SW Engineering)에서 밥을 빌어 먹고 있는 사람들이라면, 누구나 한번쯤은 이런 고민을 해 보았으리라 생각된다.
그리고 나름대로 고민한 내용들을 기록해 두는 것도 의미가 있는 일이라고 생각되어서 "SW 엔지니어 역량 측정"이라는 카테고리로 글을 시작하고자 한다.
이 글은 어떠한 과학적 근거나, 의미있는 실험적인 통계에 바탕을 두거나 하지 않은다.
말 그대로 나의 상상의 나래에서 뻗어나온 생각의 줄기일 뿐이다.
그리니 괜시리 딴지 걸지 말자... -_-; 그냥 한 blogger의 humble opinion일 뿐이니까...

* 왜 MMORPG 게임은 재미있는가? *

뜬금없이 MMORPG로 이야기를 시작하고자 한다.
리니지, WOW, 던파 등등 한국은 MMORPG게임의 천국이다.
몇몇 콘솔 게임을 제외한 패키지 게임 시장은 고난의 나날을 보내 있음에도, MMORPG 시장은 끝없이 성장하고 있다.
왜냐고? 재미있으니까...
불법 복제 문제를 뒤로 하고서라도, MMORPG가 재미있고 중독성이 강하다는 것은 부정하기 힘들다.
그럼 왜 MMORPG는 재미있는가?
여러가지 이유가 있을 수 있겠지만, 난 아래와 같은 내용에 주목하고자 한다.

* 소위 '레벨'로 대변되는 "모든 사람이 동의하는 역량의 기준"이 존재한다.
* '레벨'은 알기 쉽고 비교하기 쉽게 수치화 되어 있다.
* '레벨'은, 모두 평등한 조건에서 시작하고, 노력한 만큼 얻는다.
* '레벨'이 높은 캐릭터는 거기에 따른 대우/보상 - 게임상에서의 지위, 게임 머니 등등 - 을 받는다.

독자가 여기에 동의하지 않는다면... 음 할수 없다. (-_-;) 그냥 동의하는 '척' 해 주길 바란다.
각설하고, 한 마디로 요약하면, "열심히 하면 누구에게나 인정받고 최고가 될 수 있다." 라는 뜻이다.
현실 세계가 위와 같은 조건을 가진다고 가정해 보자.
그리고, '대우/보상'은 현실세계를 반영해서 '돈'이라고 가정해도 좋다.
그러면 당신은 어떤 선택을 하겠는가?
그래도 MMORPG를 하고 있겠는가? 아니면, 현실세계에서 열심히 '레벨 업'을 할 것인가?
나라면 후자를 택할 것이다.
돈을 많이 버는 사람은 그 만큼 레벨도 높은 사람이고, 그 사람은 레벨을 높이기 위해서 다른 사람보다 더 많이 노력한 사람이다.
따라서, "더 많은 돈을 받을 가치가 있다."는 사회적인 동의를 쉽게 얻을 수 있다.
어떤가? 얼마나 재미있는 사회인가?
기타 여러가지 외적인 요소는 일단 무시하자 - 딴지 걸지 말라는 뜻이다. (-_-)

왜 갑자기 이런 이야기를 꺼내는 걸까?
SW Engineering분야에서 생기는 많은 문제점들이 이와 관련되어 있기 때문이다.
인사(人事)분야에 올인 해서 생각을 해보자.
사실, 인사분야만 해결되면 나머지는 거져 먹는 거다. (인사(人事)는 만사(萬事) 니까...)

현재 국내 SW 업계를 보면, 회사는 뽑을 사람이 없다고 난리고, 엔지니어들은 갈 곳이 없다고 외친다.
뽑을 사람이 없다는 것은, 필요한 사람을 원하는 가격에 채용할 수 없다는 뜻이다.
갈 곳이 없다는 것은,  원하는 수준으로 대우를 해 주는 회사를 찾을 수 없다는 말이다.
자, 이제 모든 SW 엔지니어의 머리위에 그들의 실력을 나타내는 '레벨' 막대가 있다고 생각해보자.
그럼 회사는 소위 '뽑을 사람'을 쉽게 결정할 수 있다.
자금에 여유가 있다면, 실력좋은 사람을 그 만한 대우를 해 주고 데려 오면 되고, 그렇지 않다면, 회사가 제공해 줄 수 있는 수준의 사람을 채용하면 된다.
"어떻게든, 싼 가격에 좋은 사람을 채용하겠다!"
라는 논리가 더 이상 통용될 수 없으니, "뽑을 사람이 없다!"는 말은 "뽑을 (자금적인)여력이 안된다!" 라는 말로 바뀔 수 밖에 없게 된다.
이것은 엔지니어 관점에서도 마찬가지이다.
본인이 어느 정도 수준인지를 쉽게 알 수 있으므로, 본인이 어느 정도의 가치가 있는지도 쉽게 알 수 있다. 따라서,
"어떻게든, 대우가 좋은 곳으로 가겠다!"
는 생각은 통용될 수 없다.
"갈곳이 없다!"라는 말은 "내가 능력이 부족하다!"라는 말로 대체될 수 밖에 없다.
비단 채용뿐만이 아니다.
회사내에서의 승진, 연봉 협상, 대우에 따른 불만 등등이 모두 이와 일맥 상통한다.

그럼, 이런 것들이 현실적으로 가능한가? 물론 불가능 하다. 윗 글은
"사회(혹은 소속 집단)적 동의를 얻은, 측정 기준과 수치화된 결과가 가지는 힘"
에 대한 이야기이며,  엔지니어의 능력을 측정하는 합리적인 metric이 필요한 이유이기도 하다.

신고
Trackback 0 : Comment 0

[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

티스토리 툴바