lambda에 대하여...

  C++을 좋아하긴 하지만 또 그다지 열혈 사용자는 아니었던 나는, 얼마전 트위터를 통해 새로운 C++ 표준 제정(아직 완료되지 않은)에 대한 소식을 들었다. 여러가지 큰 변화가 있는 듯 했지만 가장 큰 관심을 끌었던 거은 바로 lambda의 지원이다.  C++이 워낙에 다양하고 방대한 기능을 지원하는 편이긴 하나, lambda에 대한 지원은 나에게 생각해볼 거리를 던져주는 주제다. 사고의 시작은 C++로부터 비롯되었으나 이 글의 주제는 바로 lambda이다.

  lambda를 지원하는 언어는 많다. 새삼 이제와서 C++이 lambda를 지원한다고 할 때 그냥 '아, 그렇구나' 하고 넘어갈 법도 한 문제다. 그리고 내가 선호하고 좋아하는 많은 언어들(python, vala 등)도 lambda를 제공한다. 내가 이제와서 lambda에 대해 고민하는 것은 과연 lambda의 효용이 무엇인가 도저히 모르겠어서이다.


  일단 lambda가 무엇인지부터...

  본 주제로 넘어가기 전에 lambda가 무엇인지부터 보고 넘어가자.

  쉽게 말해 lambda는, 이름없는 함수다. 예를 들어보자.

ex1) python
>>> f = lambda x, y: x + y
>>> f(1, 2)
3
>>>

ex2) vala (anonymous method)
 (a) => { stdout.printf ("%d\n", a); }

  파이썬에서는 함수 자체가 역시 객체다. 즉 파이썬에서의 lambda는 lambda 문으로 정의한 호출 가능한 함수 객체를 리턴하는 것이다. vala 역시 마찬가지의 개념으로 => 문법에 의해 함수 객체를 리턴한다. 다만 vala에서는 anonymous method라는 용어를 사용하지만 결국은 같은 개념이다.


왜 lambda를 사용할까...

  lambda를 사용하면 함수의 파라미터로 함수 객체를 - C라면 함수 포인터가 될 것이다 - 주고 받아야 하는 상황에서 따로 함수를 정의하지 않고, 바로 파라미터 내에서 lambda를 이용해 객체를 생성, 전달할 수 있다. 그렇지만 단지 이런 용도라면 구지 언어에서 lambda라는 기능을 제공해야 할 이유가 있을까.

  미리 말하지만, 이 포스트는 lambda를 사용하는 이유에 대해 설명하는 글이 아니다. 나는 아직까지 그 해답을 얻지 못했으며, 또한 일반적인 경우에 lambda의 사용을 최대한 피하는 편이다. 그럼에도 소위 최신 트렌드를 따라가는 수많은 언어들이 - 심지어는 C++ 마저! - lambda를 앞다투어 지원하는 것에는 무언가 이유가 있을테지만, 난 아직 그것을 모르겠다.


내가 lambda 사용을 자제하는 이유는...

  매우 단순하다. 앞서 말한 lambda의 정의 자체가 내가 생각하는 바람직한 코드의 형태와 맞지 않기 때문이다. 컴퓨터가 할 수 있는 일은 매우 한정적이기에, 나는 이름을 짓는다는 것에 상당한 의미를 부여하고 있다. 변수의 이름을 정하는 것, 함수의 이름을 정하는 것이 개발자가 코드에 할 수 있는 최초의 권리라고 생각한다.

  lambda라는 것은, 개발자 스스로 이름 짓기에 대한 권리를 포기함으로써 코드의 가독성을 떨어뜨린다. 재미삼아 하는 short coding이라면 lambda만큼 유용한게 없겠지만은 코드는 짧다고 좋은게 아니기 때문이다. 코딩의 대부분은 코드를 쓰는 것이 아니라 읽는 것이기에, 나는 lambda의 사용을 지양한다.


그럼에도 불구하고...

  그렇지만 너무나 많은 언어들이 lambda를 지원하고 있다. 파이썬의 하위도, C++ 위원회와 비야네, 그리고 수많은 똑똑한 사람들이 어떠한 합리적인 판단하에 lambda라는 기능을 넣었으리라 생각한다. 아무리 생각해도 최소한 나보다는 똑똑하고 경험많은 그들이 내가 생각한 문제를 생각하지 않았을리는 없을 것 같고, 그렇다면 이름짓기의 권리를 포기하면서라도 얻고 싶은 무언가가 있을테다. 하지만 난 그것을 모르겠다.

  사실 내 생각에는, lambda를 사용하는 사람들중 많은 비율이 그저 습관적으로 사용하는 것일 거라고 생각한다. lambda를 사용함으로 인해 그저 함수 정의를 한번 덜 할 수 있는 편리함에 빠진 것이다. 그렇지만 다시 생각해보면 과연 그로인해 불필요한 코드가 줄지도 않았을테고, 결국 이름만 짓지 않았을 뿐 새로운 함수를 정의한 것은 마찬가지라는 것이다.


그래서 나는 궁금하다...

  나는 lambda의 불필요함에 대해 말하기 위해 이 포스트를 작성하는 것이 아니다. lambda를 가치있게 만드는 무언가를 찾기 위한 노력이다. 이 누추한 블로그에 오는 사람이 많지 않다는 것도 알고, 이 포스트를 읽을 사람도 얼마 되지 않는다는 것도 알지만, 여기저기서 앞다투어 내놓는 lambda 지원이라는 이 기능이, 진정으로 프로그래밍 언어에서 갖는 의미가 무엇인지에 대해 누군가 답을 주었으면 하는 바람이다.

by fm100 | 2010/09/26 22:01 | I think... | 트랙백 | 덧글(12)

Agile practices seminar 후기

  오늘 agile practices seminar를 다녀왔다. 전반적으로 여러가지 생각해 볼 만한 거리가 많았던 세미나였던 것 같다. 개인의 노력이 요구되는 것들 보다는 팀의, 더 나아가 고객과 팀의 협력과 노력이 필요한 부분이 많았기에 더욱 도전적인 과제이다. 

  TDD는 어렵다. 리팩토링도 어렵다. 많은 부분에 있어서 TDD를 시도하지만 스스로 도대체 어떤 테스트를 만들어야 할 지 몰라 그냥 진행할 때도 많다. 테스트 작성이 쉽지 않으면 당연히 리팩토링도 어렵다. 그러나 TDD와 리팩토링은, 나에게 있어서는 그나마 쉬운 agile method에 속했다. 개인적인 실천이 가능하기 때문이다.

  오늘의 세미나를 계기로 가장 많이 생각해보게 된 주제는 '고객참여'와 'code ownership'이다. 각각의 주제에 대해 생각도 정리해볼 겸 간략하게 요약해보자(세미나 내용의 요약이 아니라 내 생각의 요약이다).



  1. 고객참여

  개발 프로세스에 고객을 참여시키는 것이다. 이 고객참여에는 여러가지 난관이 존재한다. 첫 째로, 고객이 참여하기를 원하지 않는 경우다. 약간의 게으른 고객을 예로 들 수 있겠는데(아마 정부쪽 과제가 이렇지 않을까 싶다), 신경도 안쓰고 있다가 마지막에 완성된 결과물만을 받기 원하는 경우다. 이 부분에 대해 고객참여가 개발에 필수적이라고 생각하는 내 이유는, '고객은 스스로 무엇을 원하는지 모르기 때문에 항상 확인시켜줘야 할 필요가 있다'는 것이다. 이럴 경우, 고객을 개발에 참여시키기 위해 어떻게 고객을 설득하느냐가 또 문제가 된다. 하지만 얘기가 길어질 것이므로 여기까지.

  두 번째, 고객이 적극적으로 참여하지만 의도한 대로 움직이지 않는 경우다. 이 경우는 개인적으로 심각한 악례가 좀 있는 편인데, 고객(갑)이 개발사(을)를 '노예'로 취급하는 경우가 많다. 개발자의 출퇴근까지 관리하기를 원하고, 하물며 문제가 없는 상황에서도 개발자의 퇴근을 기분나빠한다. 구체적인 실례를 들자면, 얼마전까지 내가 투입되었던 과제에서는 고객이(고객사의 직원들이) 번갈아가며 개발자들을 감시하고 혹시나 퇴근하지 않았는지 확인한다. 매일매일 다음날 아침 해 뜰때까지 과중한 업무가 반복되는걸 고객이 당연하게 여기고 그것을 요구한다.
  아무리 agile에서 제시하는 실천사항중에 잦은 릴리즈와 지속적인 test, 빠른 피드백이 있다지만, 주말포함 일주일에 5번씩 하는 릴리즈와 QA팀의 쉴 새 없는 검증, 개발자들의 실시간 응답을 기대하는 고객과는 일하는게 너무너무 힘들다. 실제로 나는, QA에서 언제든지 문제를 올리기만 하면 바로바로 응답하기 위해 상시대기하며, 문제가 하나라도 올라올 경우 실시간으로 응답하고 디버깅하면서, 또한 각각의 문제 수정이 이루어질때마다 곧바로 다시 QA가 검증에 들어가고, '검증 - 수정 - 릴리즈'의 반복이 밤샘으로 하루밤만에 5~6번씩 반복되는 과제에서 일했다. 또한 앞서 말했든 그러한 매일이 일주일에 최소 이틀, 많으면 5일까지도 발생했다. 고객이 그러한 것을 원했고, 고객이 원하는 일정은 언제나 '당장' 이었다. 고객은 필요 이상으로 적극적으로 개발에 참여하면서, 특정 모듈의 일정이 지연되면 그 모듈의 담당 엔지니어의 이름까지 거론해가며(내가 많이 당했다) 마녀사냥을 했다. 이런 고객과는 agile에서 말하는 '진짜' 고객참여는 이루어지기 힘들다.

  이러한 상황이 나에게는, 특히나 나의 두 번째 경험과 같은 고객과 함께 일해야 할 때, 어떻게 agile을 실천할 수 있을지가 매우 도전적인 과제다.



2. Code ownership의 확산

  오늘의 세미나에서 인상깊었던 문구중에 하나가 'That's not my job'이다. 회사가 한 사람 한 사람에게 professionalism을 요구할 때 발생할 수 있는 문제다. 한명의 엔지니어가 특정 모듈에 대해 너무 강한 ownership을 갖게되면, 그 모듈을 벗어나는 순간 그 일은 내 일이 아닌것이 된다. 오늘의 세미나에서 나왔던 말은 아니지만 개인적으로 인상깊게 느꼈던 문구중에 하나가 'who's wrong이 아니라 what's wrong을 고민하라' 였는데, 엔지니어가 모듈별로 ownership이 분산되면 문제가 발생했을 때 마녀사냥 - who's wrong? - 이 이루어지기 쉽다. 이는 엔지니어 개개인을 매우 방어적으로 만들고, 의견제시를 주저하게 만든다.

  Non-agile한 상황, 그러니까 팀이 code ownership을 함께 공유하지 않는 경우 발생할 수 있는 또 하나의 문제는, 누구도 ownership을 갖지 않은 문제가 발생했을 때이다. 이런 문제는 기술적으로 해결이 쉽든 어렵든 불필요한 회의를 하게 만든다. 그리고 모두가 외친다. That's not my job. 앞서 언급한 문제와 동일하다고 생각할 지 모르지만 여기에는 한가지 추가적인 쟁점이 있다. 결국 문제는 문제이고 누군가는 해결해야 한다는 것이다. 그 이야기는 즉, 누군가는 추가적인 일이 부과된다는 것이다. 이런 상황에서는 일반적으로 해결책에 대한 아이디어를 먼저 제시한 사람이 문제를 떠안게 된다. 사람은 대부분 - 테레사 수녀같은 예외도 있겠다 - '나만' 고생하는 것을 싫어한다. 누군가 한명이 해결책을 제시하면 함께 숙고하고 발전시키기 보다는, '아, 그럼 되겠네. 말 꺼낸 사람이 해야지'가 되어버리는 것이다.

  팀이 code ownership을 공유하는 경우는 이런 문제가 없다. 전체 코드에서 '내 코드'는 존재하지 않는다. 마찬가지로 '남의 코드' 또한 존재하지 않는다. 모든 것은 '우리의 코드'이며 '우리의 문제'이다. 이런 분위기는 의견 제시를 자유롭게 만든다. 내가 제시한 의견이 나를 불편하게 하지 않는다. 다른사람이 제시한 의견에 오류가 있다면 문제를 해결하기 위해 들어야 할 '내 노력'이 추가된다. 따라서 나는 항상 다른 팀원의 의견을 숙고하고 더 나른 방법이 없는지 고민해야 한다.

  Code ownership이 팀 전체로 확산될 경우, 또 하나의 이득이 있다. 일반적으로 소프트웨어 엔지니어는 학습의 욕구가 강하다. 많은 경험을 해보아 고민없이 해결할 수 있는 문제는 별로 선호하지 않는다. 하나의 큰 시스템은 다양하고 복잡한 문제가 혼합되어 있기 때문에, 팀이 함께 모든것을 공유할 경우 이런 엔지니어 각각의 학습욕구를 충족시킬 수 있다.

  Code ownership의 확산을 위한 방법으로, review되지 않은 코드는 repository에 merge되지 않도록 하는 시스템(e.g. gerrit)을 사용하는 것도 가능할 것 같다(Thanks to 재원). 팀이 함께 코드리뷰할 시간을 정기적으로 가지고, 팀이 동의한 코드가 repository에 merge되게 한다면 팀원 '개인의 죄'는 사라진다. 시스템에 문제가 발생했을 때 팀의 누구도 '너 때문이야' 라고 말하지 못한다. 그 코드에 대한 리뷰의 책임이 모두에게 있었기 때문이다.

  코드리뷰는 귀찮다. 코드리뷰가 귀찮아서, '컴파일 되네? 돌려봐. 잘 돌아? 뭐 대충 멀쩡한거 같네. OK'와 같은 상황이 발생 할 수 있다. 이를 위해 떠오르는 해결방안은 역할 돌리기다. 아주 작은 스텝으로, 팀원은 코드를 교환한다. 어제는 내가 계산기의 덧셈연산을 만들었다면(물론 이정도로 작은 단위로 움직이진 않겠지만), 오늘은 다른사람이 곱셈을 만든다. 내일은 나눗셈을 만들기로 했다면, 누가 내일 나눗셈을 만들어야 할 지 모르므로, 오늘의 곱셈 리뷰에 모두가 적극적으로 참여해야 한다.
  그러나 이 방법은 위험을 동반한다. 엔지니어라면 누구나 동의하지만 코딩이 매일매일 잘 되는 것이 아니다. 따라서 어제 리뷰를 열심히 했더라도 오늘 내가 맡은 부분에 진척이 없을 수도 있다. 그리고 그것이 내일 누군가에게 돌아갈 것이라고 기대한다면, 팀원은 다시 게을러 질 수 있다. 코드리뷰는, 여전히 어려운 문제다.


3. Pair Programming

  서론부분에서 언급하진 않았지만 agile에서 협업의 대명사는 pair programming이다. 오늘의 세미나에서는 다른 팀원에 비해 performance가 뛰어난 일부의 팀원이 pair programming을 거부할 경우 어떻게 할 것인가에 대한 질문이 있었다. 패널들의 다양한 의견이 있었지만 패널의 의견은 배포되는 세미나 자료를 통해서 다시 볼 수 있을거 같아 여기서는 내 생각을 정리하도록 한다.

  일단 performance가 뛰어난 팀원이 pair programming을 거부하는 이유를 생각해보자. 가장 큰 이유는 pair programming으로 인해 자신의 개발속도가 더뎌진다고 느끼는 것이다. 혼자하면 더 빠를텐데, 파트너가 고민하는 사이 자신은 모든 답을 내어놓을 수 있고, 코딩도 내가 더 빠르다. 파트너의 '왜 그렇죠?'라는 질문이 반복될 경우 짜증을 느낄 수도 있다.

  그러나 한가지 다행인점은, 진짜 못된 사람은 별로 없다는 것이다. 정말 성격이상이고 독불장군이라 pair programming은 죽어도 못해먹겠다고 주장하는 사람은 거의 없다. 일반적으로는 혼자 작업하는 것에 비해 갑갑함을 느끼고 짜증날 뿐이다. 이 경우에는, 적어도 내 생각에는 해결책이 있다.

  먼저 임의로 경험많고 performance가 뛰어난 팀원을 senior, 그렇지 못한 팀원을 junior라고 표현하자. 소프트웨어는 기술적으로 변화가 심한 분야라서, senior라 할 지라도 모든 것을 알고있는 엔지니어는 없다. junior는, 아무리 경험이 부족하더라도 정말 아무것도 모르지는 않는다. 일반적인 경우 정말 아무것도 모른다면 엔지니어도 아닐 뿐더러 한 회사에 들어가는 것 자체가 불가능 했을 것이라고 보는게 옳다. 따라서 내가 제시하는 한 가지 방법은, senior를 그가 경험하지 못한 부분을 작업하고 있는 junior에게 붙이는 것이다. 이 경우 구지 pair programming을 언급할 필요는 없다. '안해본 거지만 당신은 실력이 좋으니깐 잘 할거야. 좀 도와줘'라고 말한다면, '나는 다른사람 도와주는 것 따위엔 흥미 없어요'라고 말할 사람 몇 되지 않는다. 진짜로 그런 사람이 있다면, 아무리 performance가 좋더라도 차라리 팀에 없는것이 이롭다.

  말했듯이, 일반적으로 소프트웨어 엔지니어는 학습욕구가 매우 강하다. performance가 뛰어난 엔지니어라면 더욱 그러할 것이라고 예상할 수 있다. 학습욕구가 강하지 않았다면 실력이 좋을 수는 없는것이니까 말이다. '안해본 거지만 당신은 실력이 좋으니깐 잘 할거야. 좀 도와줘'라는 말은 senior 엔지니어에게 후배를 도와주겠다는 선의와 함께, 호기심을 자극할 수 있다. 소프트웨어는 언제나 경험해 보지 못한, 신기술에 목말라하는 사람들이기 때문이다.

  그리고 이런 조합이 이끌어내는 또 하나의 장점이 있다. 나같이 성격 참 부담없고 맘 편한 사람은 문제가 없을지 모르지만, 전문분야의 senior를 붙여준다면 junior 엔지니어는 시험치는 기분을 느낄 수도 있다. 그리고 필요 이상으로 의존하게 된다. 어차피 내가 생각한 것보다 더 나은 훌륭한 아이디어를 이사람이 언제나 가지고 있을 것이라 무조건 적으로 믿어버린다면, pair programming의 의미가 사라진다. 아무리 실력 좋은 엔지니어라 하더라도, 처음 해보는 것이라면 이것저것 모를 수도 있다는 생각이 오히려 junior를 편하게 만들어 줄 수도 있다. 이는, 자유로운 의견 제시와 토론으로 이어질 것이다.


  여기까지가 오늘의 세미나에서 나에게 던져진 생각할 과제였다. 하나하나 어렵지 않은 주제가 없으니, 역시 많은 사람들의 아이디어와 토론이 필요해 보인다.

by fm100 | 2010/04/21 21:37 | I think... | 트랙백(3) | 핑백(1) | 덧글(3)

한국 소프트웨어는 어째서 성장하지 못하는가.

  본 포스트는 '어째서 한국 소프트웨어 산업은 발전하지 못하고 항상 정체되어 있는가'에 대한 개인적 고찰이다.


들어가는 글...


  소프트웨어는 지식노동산업이다. 지식노동이라는 것, 그것은 다분히 사람에 의존적이라는 것을 의미하기도 한다. 일반인들(이 글에서 일반인들이란 엔지니어가 아닌사람을 말한다)이 흔히 생각하는 철저한 비밀에 부쳐지는 그런 연구따위는 무의미하다는 것을 의미하기도 한다. 기업 깊숙한 곳에 철통같은 보안과 함께 소중이 모셔놓는 핵심 기술따위는 무의미 하다는 말이다.

  소프트웨어를 개발한다는 것은 원초적으로 코드를 작성하는 것을 말한다. 많은 기업들이 이 코드를 기업의 소중한 자산으로 생각하며, 기업의 기술로 여기고, 코드를 공개하지 않는다. 코드를 공개한다는 것을 곧 기술의 유출로 생각하기 때문이다.

  내 생각에 이것은 정말 크나큰 착각이다. 아주 단적인 예를 들어보자. IT업계에 종사하는 사람이라면 누구나 구글이라는 기업을 알고있다. 더군다나 내가 몸담고 있는 모바일 업계에서는 구글의 안드로이드가 업계의 폭풍으로 몰아닥치고 있다. 앞서 말한 논리대로라면 안드로이드의 소스코드는 구글의 기술이다. 그리고 안드로이드는 전체 소스코드가 모두 오픈소스이다. 이 말은 구글의 기술이 전 세계로 유출되었다는 것을 의미한다. 이대로라면, 다른 수많은 기업들이 이 유출된 구글의 기술을 입수하고 구글같은 기술력을 갖출 수 있어야 할 것이다. 그러나, 현실은 구글만이 구글이다. 다른 수많은 기업들이 노력했지만 역시 구글이 되지는 못했다.

  그럼 어째서, 같은 소스코드를 갖고있는 다른 여러 기업들은 어째서 구글과 같이 될 수 없을까. 이에대한 해답은 아주 간단하게 '소스코드 == 기술' 이라는 등식을 부정함으로써 얻을 수 있다. 그럼 다시 질문을 하자. 무엇이 기술력인가? 바로 사람이 기술력이다. 글의 시작에서 말한 '사람에 의존적'이라는 것은 곧 사람 자체가 기술력이라는 것을 말한다. 구글과 같은 소스코드를 가지고 있는 수많은 기업들이 구글과 같은 기술력을 갖지 못하는 이유는 단 하나다. 그 기업들의 엔지니어가 구글의 엔지니어가 아니기 때문이다.

  그럼 이제 본론으로 들어갈 준비를 해보자. 글의 주제는 한국 소프트웨어가 어째서 정체되었는가에 대한 물음이다. 한국 소프트웨어의 정체를 한국 소프트웨어 기술력의 정체라는 말로 바꿔보자. 이것은 다시 한국 소프트웨어 개발자들의 정체로 이어진다. 그렇다. 한국의 엔지니어들은 멈춰있다. 기술영역에서의 정체란, 곧 후퇴와 다르지 않다는 것에서 이 말이 가지는 의미는 참으로 크다.


도대체 왜...

  엔지니어가 정체되었다는 것을 현실로 인정했으 때 우리가 해야 할 일은 그 원인을 파악하는 것이다. 물론 그 원인이 한가지도 아닐 뿐더러 아주 다양한 측면을 가지고 있지만, 여기서는 사회 문화적 측면의 요소와 업계 현실로 인한 한계, 그리고 개발자 스스로의 문제점 등을 파악해 볼 것이다.


애송이 문화...

  무협지를 좋아하는 사람이 늘 접하는 레파토리가 있다. 바로 갓 출도한 명문가의 자제와 무림에서 산전수전 다 겪은 평범한 무사와의 대결이다. 좋은 가문에서 어려서부터 착실히 무공을 닦은 이 명문가의 자제는 이름도 모를 삼류무사에게 패한다. 여기서 늘 등장하는 표현이 실전을 겪어보지 못한 '애송이'이다.

  무협지 후반부의 전개는 그 '애송이'가 주인공이냐 아니냐에 따라 천차만별로 달라질것이다. 그러나 그 '애송이'의 패배에서 우리가 놓치고 있는 것은, 비록 패했지만 그 대결을 주도했던 것은 그 '애송이'라는 것이다. 항상 그렇다. 명문가의 자제는 좋은 환경에서 수련에만 전념하여 다양하고도 깊이있는 무공을 익힐 수 있었다. 그리고 그 무공을 바탕으로 대결 가운데 전반적인 흐름을 좌지우지 했다. 그러나 실전 경험이 없다는 그 '애송이'라는 딱지를 바탕삼아 삼류무사가 숨기고 있던 비장의 한 수와 약간의 비겁하다 싶은 수에 당하고 만다. 우리가 주목해야 할 것은 당장에 있었던 그 결투가 아니라 그 후의 상황이다. 좀 전 까지 있었던 그 '애송이'는 더이상 존재하지 않는다. 한번의 실전을 통해 그는 무섭게 성장하고 만다.

  이를 소프트웨어 개발의 현실로 끌고와 보자. '애송이'를 대졸 신입의 엔지니어와 비교해 볼 수 있을 것이다. 그리고 우리는 아주 일반적이면서도 치명적인 착각을 하고 만다. '대졸 신입이 뭘 알겠어' 라는 것. 평균적으로 대졸 신입보다 경력 1~2년차가 실력이 좋을 확률은 높다. 그 1~2년 차이가 바로 실전 경험의 차이가 되기 떄문이다. 그러나 모두가 그렇지는 않다. 삼류무사가 실전 경험을 통해 하게되는 성장과 명문가의 자제가 하게되는 성장은 질적으로 다르기 떄문이다. 여기서 삼류무사와 명문가의 자제는 각각 대충 4년이라는 시간만 버티다 시간에 떠밀려 졸업한 대졸자와, 4년의 시간을 각고의 수련기간으로 삼은 대졸자에 매치 시킬 수 있을 것이다.

  결론적으로 그 어중이 떠중이 대졸신입은 경력이 10년이 되어도 별 발전이 없다. 왜냐하면 대학 4년의 시간을 수련하지 않았던 만큼, 실전에서의 10년도 별다른 수련과정이 없었기 때문이다. 그리고는 혼자서 10년치만큼 발전했으리라 착각하고, 자신보다 경력이 뒤지는 이들을 바라보며 자신이 더 실력있을 것이라 착각한다.

  소제목을 '애송이 문화'라고 달아놓긴 했지만 본질적으로 말하고 싶었던 것은 엔지니어 한명 한명이 가져야 할 각고의 수련에 대해 무시하는 전반적인 문화다. 1년이라도 실전에서 더 굴러먹었으면 조금이라도 더 실력있을 것이라는 그 착각이 열심을 다한 수련을 통해 이미 나보다 앞서있는 후발주자가 있다는 사실을 보지 못하게 만드는 것이다. 경험의 중요성을 부정하는 것은 아니지만, 본질적으로 엔지니어의 실력이란 실전 과제보다는 자기 수련을 통해 발전하게 된다.


지친다 지쳐...


  엔지니어가 성장하지 못한다는 것은 본질적으로 엔지니어가 수련하지 않는다는 것이다. 그렇다면 그냥 시간에 밀려 대학을 졸업하고 그냥 하루하루 버티다보니 경력자가 되어버린 쭉정이들을 제하고서, 스스로의 의지를 다잡고 학습하고 수련하던 그 많은 사람들은 대체 어디로 가버린 걸까.

  현실의 벽은 높기만 하다. 대한민국 소프트웨어 업계는 본질적으로 개발자의 칼퇴근을 용납하지 않는다. 개발자가 칼퇴근을 할 수 있다는 것은 일정이 여유있다는 것을 의미하므로, 개발자들이 야근하면 일정을 더 당길 수 있다고 생각한다. 아주 관성적인 야근 문화는 개발자에게서 수련에 대한 마음의 여유를 잃게 만들었다.

  물론 그 와중에도 잠을 줄여가며 스스로의 발전을 위해 수련에 박차를 가하는 이들이 있다. 그러나 모든 이에게 이것을 강요하기엔 현실이 너무 개차반이지 않은가. 우리나라에서 소프트웨어 개발을 하는 엔지니어는 정상적인 건강상태를 갖기 힘들다. 끝없이 이어지는 야근과 철야, 불규칙한 생활은 사람을 지치게 만들고 아프게 만든다. 이런 현실에서 자기 수련을 해나가는 엔지니어가 훌륭한 것이지, 나머지 엔지니어가 게으른 것은 절대로 아니다.



결론적으로...

  글이 길었지만 이 글에서 언급한 한국 엔지니어의 성장을 가로막는 요소는 크게 두가지이다. 경력에 대한 환상과 그로인한 자기 수련 부족이 첫째요, 하루하루 목 앞에서 칼날이 날아다니는 와중에 수련은 언감생심 꿈도 못꾸게 하는 업계의 현실이 그 둘째다.

  그러므로 우리는 스스로 엔지니어로서 내 경력이 몇년이니 이만한 대우를 받아야겠다는 환상을 버리고 스스로 수련에 박차를 가할 것이며, 또한 개발자의 칼퇴근이 곧 개발자의 성장이고 업계의 발전이며 대한민국의 발전이라는 것을 업계 전반적으로 인식할 수 있는 계기가 필요하다.

by fm100 | 2010/03/03 23:03 | I think... | 트랙백(1) | 핑백(1) | 덧글(17)

사춘기 극복과 꿈.

Q. 중학교 2학년인 딸이 사춘기를 겪고 있습니다. 아무 이유도 없이 우울해 하는 것은 물론 때때로 눈물을 보이기도 하고 공부도 귀찮아합니다. 어떻게 해야 딸아이가 사춘기를 극복하고 다시 학업에 전념할 수 있을까요?

  사춘기 극복이라는 주제로 Q&A형식으로 쓰여진 어떤 기사를 보았다. 위와 같은 질문으로 내용이 시작되었다. 그에 대한 답변은 상상했던 그대로이며, 진심으로 가슴아프고 화가 나며 견딜 수가 없었다.

  첫 째로, 어찌하여 사춘기의 극복이 공부를 열심히 하는 것으로 이어지는가.

  질문은 그럭저럭 아이의 정서 변화에 대한것도 포함되어 있지만, 답변이란 것은 고작 사춘기 때 아이들이 이러이러하니 저러저러하게 공부를 시켜 성적을 향상시키자 하는 것이었다. 사춘기는 누구에게나 다가오는 매우 보편적인 현상이다. 그러나 그만큼 중요하고 앞으로의 삶이 결정되는 시기이다.

  사춘기의 아이가 공부를 열심히 하지 않는가. 왜 그럴까. 답은 간단하다.
하기 싫기 때문이다. 공부가 재밌지 않고 공부보다 재밌는 것은 세상에 넘쳐나고 궁금한 건 많기 때문이다. 그래서 큰일 나는가. 공부가 좀 재미없으면 어떻고 좀 안하면 어떠한가. 소위 다 자란 성인들은 스스로를 한 번 돌아보자. 사춘기였을 때, 공부보단 다른것에 관심이 많던 그 시절로 돌아가 60점이던 수학을 90점으로 만들고, 모르던 영어단어를 더 외우고 나면, 그래 무엇이 달라지곘는가.

  사람은 항상 깨어있지 못한다. 낮에 활동했으면 반드시(일반적으로) 밤에 잠을 자야한다. 자는 동안에는 꿈을 꾼다. 그러나 깨고나면 기억나지 않는다. 우리의 매일 매일은 이러하다.
  그러나 사춘기는, 깨어있는 동안 꿈을 꾸는, 인생에서의 유일한 기간이다(내가 나이가 어려 확신은 못하곘지만). 나의 꿈을 몇십년이고 기억할 수 있는 유일한 꿈이다. 사춘기에는 꾸고 싶은 꿈이 너무도 많다. 알고싶은 것도 너무나 많다. 그렇다면 좀, 그것들을 알아가도록 내버려 두면 안될까.


  둘 째로, 어째서 꿈을 가르치지 않는가.

  앞에서부터 쭉 꿈 얘기를 해왔지만, 한 번만 더 해야겠다.
  우리는 현실 속에서 살아가고 있다. 냉혹한, 이기적인 사람들, 니가 밟지 않으면 밟히고 말거야. 이런 것들, 우리가 살아가는 이 공간. 우리는 통칭하여 우리가 살아가는 현실이라고 말한다.
  그래, 우리는 이런 곳에서 살고있다. 우리가 우리 아이들에게(난 아직 결혼도 안했지만) 가르치지 않아도, 언젠가는 스스로가 맞이하게 될, 바로 그 현실이다. 누구나 마주치며 살아야 하기에 현실이라고 부른다.

  꿈은 우리의 상상이다. 또한 상상 너머의 어떤 이상이며, 우리가 감동하게 하는 그 무엇이다. 꿈은 상상이기에 우리의 현실이 아니다. 현실이 아니기에 시간이 흐른다고 저절로 알게 되는것도 아니다. 오히려 시간이 지날수록 잊어가겠지.

  현실은 현실이기에 가르치지 않아도 알게된다. 그리고 사실 직접 겪어보기 전에는 가르쳐봐야 모른다. 그렇기에 더욱이, 우리는 꿈을 가르쳐야 한다. 현실 속에서 꿈 꾸지 않고 자란 아이들. 냉혹하다고 표현되던 현실은 지옥이 될 지도 모를 일이고, 그 아이들이 어른이 되어 살아갈 땐, 한 사람 한 사람이 오로지 살기위해 살아갈 지도 모를일이다.

  우리는 우리의 아이들이 포식자가 되기를 원하는가.

  사람은, 꿈을 꾸어야 사람이다.

by fm100 | 2009/12/19 01:41 | I think... | 트랙백 | 덧글(0)

◀ 이전 페이지          다음 페이지 ▶