태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

 

 

 

 
분류 전체.. (1308)
마이크로소.. (132)
민수네 가족 (17)
호랭이 사.. (141)
열이아빠의.. (7)
PlayPhone (98)
NetworkON (1)
ratharn의.. (10)
큐브 해법 (10)
사람들 (6)
개발 이야기 (94)
아이티 이.. (539)
영어 이야기 (2)
좋은책 이.. (8)
대기중인.. (1)
발명 이야기 (2)
건강하게.. (15)
호랭이  마이크로소프트웨어  LG전자  구글  삼성전자  개발자  마이크로소프트  블로그  마소  아이폰 
 free offers
└>free offers
 online pharma..
└>online pharma..
 Go here
└>Go here
 visit my webp..
└>visit my webp..
 Go Source
└>Go Source
«   2021/10   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
+ ITViewpoint
+ 도이모이
+ with okgosu
+ 학주니닷컴
+ 열이아빠의 R⋯
+ Gsong.s Blog
+ 비주얼스튜디⋯
+ 광파리의 글⋯
+ LovedWeb
+ 블루오션의⋯
+ 울지 않는 벌새
+ PC 지존
+ 디지털통
+ 아크비스타
+ 고독한 프로⋯
+ Total : 2,100,957
+ Today : 10
+ Yesterday : 6
  

 

 

 

한용희 _해당되는 글 2건
2009.09.30   개발자도 며느리도 모르는, 개발자 심리학 (10)
2008.04.14   한국에서 개발자로 살아간다는 것 & 기자로 산다는 것 (10)

 

개발자도 며느리도 모르는, 개발자 심리학
+   [마이크로소프트웨어]   |  2009. 9. 30. 08:43  


개발자는 어떤 사람일까? 개발자는 과학자에 속한다는 사람도 있고, 엔지니어에 속한다는 사람도 있고, 예술가에 속한다는 사람도 있다. 개발자는 지적인 작업으로 새로운 것을 창조하기 때문에 예술가에 가깝다. 그럼 이러한 예술가들을 어떻게 이해해야만 잘 관리할 수 있을까? 지금부터 그에 대한 내용을 알아보자.

한용희 woom33@korea.com|현재 Microsoft Visual C# MVP이며, 여러 SW 개발 프로젝트에 참여했다. 다양한 SW 개발 프로젝트에 참여해 오면서 항상 더 나은 개발 방법에 대해 고민하고 있다.

개발이라는 작업은 고도의 집중력을 필요로 한다. 개발자가 개발하기 위해서는 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등등 많은 내용들을 머릿속에 장전하고 개발을 시작해야 한다.

 

개발자의 직업병

이러한 내용이 머릿속에 제대로 장전되지 않으면, 오류가 생기거나 개발 속도가 떨어진다. 한 가지 일에 집중해야 하는 직업 특성상 개발자를 주변에서는 내성적인 사람이라고 오해하기도 한다. 하지만 그들 성격이 내성적이기 때문에 그런 것이 아니라, 정신의 에너지를 내부에 집중해야 하기 때문에 다른 사람이 볼 때 그렇게 보이는 것이다.

개발자들은 숲을 보기보다는 나무를 보는 경향이 있으며, 작은 것에 민감하게 반응한다. 또한 자기 관심 분야에는 굉장한 열정을 보이지만 다른 분야에는 관심을 보이지 않는다. 모든 개발자가 그런 것은 아니지만, 외부에서 개발자를 보는 인식은 대체로 위와 같다.

개발자는 자기 자신과 일을 가장 많이 한다. 타인과 같이 일하는 시간보다, 자기 자신과 대화하면서 일하는 시간이 많다. 그러다 보니 다른 사람과의 커뮤니케이션 기술이 부족한 경우가 많아서 함께 일하는 데 원활하지 못한 경우가 있다. 그런데 개발자라고 처음부터 내성적이고, 커뮤니케이션이 부족한 사람은 아니었을 것이다. 직업 특성상 자기 자신과의 싸움을 오랫동안 외롭게 하다 보니 그렇게 된 것이다. 개발자와 함께 일하는 관리자와 이해 관계자들은 이러한 개발자의 특성을 잘 이해해야만 프로젝트를 성공적으로 수행하는 데 유리하다.

 

개발자의 무아지경

개발자가 고도의 집중 상태에 빠져드는 것은 마치 ‘무아지경’과도 같다(영어로는 ‘in the zone’ 또는 ‘flow’라고 한다). 한번 이런 상태에 빠지면 굉장한 속도로 개발을 해 나간다.

개발자의 생산성이 최대가 되는 순간이다. 그런데 한 가지 안타까운 것은 이 상태가 너무나도 쉽게 깨져 버린다는 것이다. 한 예를 들어보자.

개발자가 열심히 무아지경에 빠져서 개발하고 있는데, 갑자기 고객으로부터 전화가 왔다. 개발자는 전화를 받자마자 고객으로부터 짜증 섞인 목소리를 들었다.

고객은 온갖 짜증을 내면서 이따위 시스템 못 써먹겠다고 불평불만을 쏟아낸다. 이 순간 개발자의 무아지경 상태는 깨졌고, 이를 다시 회복하는 데에는 많은 시간이 소요될 것이다.

머릿속에 장전해 놓은 각종 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등등 많은 내용이 순식간에 언로드(unload)되고 고객의 짜증섞인 불만 내용이 머릿속에 로딩(loading)된다. 이를 다시 끄집어내고(unload) 다시 무아지경에 빠지기 위해 명명규칙, 공통 API, 디자인 패턴, DB 테이블 구조, 성능, 상호 인터페이스 등의 내용을 다시 장전하기 위해서는 정신 상태부터 치유해야 한다.

갑자기 고객으로부터 온갖 욕을 얻어먹은 개발자는 정신 치유를 위해 담배를 피우던지, 음악을 듣던지 하는 휴식 시간이 필요하다.

그런데 프로젝트 막바지에 다다라서 시간이 촉박하고 깐깐한 관리자를 만났다면 그나마도 못한다. 정신적인 쇼크 상태에서 개발을 지속하다 보면 많은 오류를 양산하게 되고, 향후 고객으로부터 다시 한 번, 이 시스템 못 써먹겠다는 소리를 듣는 악순환이 이어진다.

낮에는 이해 관계자들의 전화에 시달려 일을 하지 못한 개발자는 드디어 모두 퇴근한 밤이 되어서야 자기 자신만의 시간을 가질 수 있었다. 밤새 무아지경에 빠져서 수정사항을 다 고친 후에야 퇴근했다.

그런데 다음날 아침 9시에는 관리자가 프로젝트 진행 상태를 점검하기 위해 이해 관계자와 함께 하는 회의 시간을 잡아 놓았었다.

관리자와 이해 관계자는 아침 9시에 모여서 회의가 시작되기를 기다리는데, 개발자는 아직 출근도 안 했다.

관리자는 개발자가 어제 몇 시에 퇴근했는지 모르는 채, 그리고 왜 야근을 해야 하는지도 모르는 채, 매일 지각 출근한다고 이미 불만이 많았다.

고객은 아침 9시부터 불러놓고 회의도 안 한다면서 관리자를 독촉하기 시작했고, 관리자는 연신 휴대폰을 부여잡고 개발자에게 전화를 한다.

드디어 아침 10시가 되어 개발자가 나타나자, 관리자는 그동안 참았던 모든 불만을 다 쏟아냈다. 이를 묵묵히 듣고 있던 개발자는 끊었던 담배를 다시 피워야만 했다. 그렇게 프로젝트는 진행이 되었고, 그래도 끝을 보게 되었다.

드디어 프로젝트 종료보고를 하던 어느 날 그 개발자는 홀연히 사라져 버렸다. 그가 어디로 갔는지 아는 사람은 없었다. 혹자는 그가 머리를 깎고 중이 되었다는 사람도 있고, 그가 공사장에서 트럭 몰고 있는 모습을 봤다는 사람도 있고, 이민을 갔다는 사람도 있고, 다들 추측만 난무했다.

위는 실제 사례는 아니지만, 현장에서 얼마든지 있을 수 있는 사례다. 개발자는 고도의 집중상태에 한번 빠지면 엄청난 생산성을 낼 수 있지만, 아쉽게도 이 상태는 외부의 충격에 의해 쉽게 깨져버린다. 그런데 이 무아지경 상태는 context switching(문맥 변화)이 일어나는 상태에서만 깨진다.

컴퓨터에서 프로세스나 스레드가 바뀔 때 context switching이 일어난다. 하나의 CPU는 한 번에 하나의 작업만 할 수 있기 때문에, 여러 작업을 동시에 하기 위해서는 작업이 바뀔 때마다 context switching을 해서 작업을 진행하기 위한 기본적인 내용을 CPU 레지스터에 로딩해야만 한다.

사람의 두뇌도 이와 유사해 비슷한 일을 계속하는 경우에는 context switching이 일어나지 않는다.

개발자가 개발하는 중간에 지금 무슨 일을 하고 있는지 묻는 질문은 context switching을 일으키지 않는다. 하지만 위의 사례처럼 고객의 전화를 받는 작업은 context switching을 일으킬 수 있는 작업이다. 개발자는 과학자도 엔지니어도 아니다.

자기 자신과의 싸움에서 새로운 것을 창조해 내야 하는 예술가인 것이다.

그런 예술가를 마치 하나의 기계 부속품인 것처럼 고장나면 교환하면 된다고 간주하거나, 통제를 많이 하면 할수록 더 일을 잘 한다고 생각한다면, 개발자의 업무 특성을 잘 이해하지 못한 것이다.

 

무아지경에 빠지기 위한 환경

유명한 개발자 사이트인 DevX(www.devx.com)에 보면 Bryan Dollery가 2003년에 쓴 ‘개발의 심리학 이해’라는 글이 있다(www.devx.com/DevX/Article/11659). 이 글에 보면 개발자가 무아지경에 빠지는 것을 돕는 세 가지 방법이 나와 있다.

- 적절한 정신적 격리 상태를 제공할 것

- 창의적인 에너지를 재충전할 수 있는 적절한 시간을 제공할 것

- 이치에 맞는 특별한 요구를 수용해줄 것

개발자가 정신적으로 집중할 수 있도록 방해되는 주변 환경을 차단해야 한다. 한 예로 수정사항이나 요구사항은 개발자가 직접 듣는 것이 아니라 관리자가 일괄 취합해서 우선순위를 정해 개발자에게 전달하는 것이 전체 프로젝트의 생산성을 높이는 데 도움이 된다.

개발자가 개발에 집중할 수 있도록 주변 환경을 조성해 주는 것이 관리자로서 해야할 첫 번째 임무인 것이다. 두 번째는 개발자가 중복된 실수를 하지 않도록 그들에게 적절한 휴식시간을 제공해 주어야 한다는 것이다.

무아지경 상태에 다시 빠질 수 있도록 적절한 휴식이 필요하기 때문이다. 세 번째는 개발자들이 원하는 특별한 요구사항이 있다면 수용해주라는 것이다.

긍정 심리학 분야의 세계적인 대가인 시카고 대학의 칙센미하이(Csikszentmihalyi) 교수는 노벨상 수상자 또는 뛰어난 과학자들의 심리 상태를 연구해 몰입(flow)에 대한 많은 책을 썼다.

특히 우리나라에도 소개된 ‘몰입의 즐거움’, ‘몰입의 경영’ 등을 통해 ‘몰입 이론’으로 세계적인 명성을 얻었다. 그가 인용한 한 유명 컴퓨터 과학자는 자신이 샤워를 할 때 가장 많은 아이디어가 떠올랐다고 한다. 그러던 그가 한 회사에 취직을 했는데, 그 회사는 샤워 부스를 제공하지 않았다. 그 이후 그는 새로운 아이디어가 떠오르지 않아서 그만 두었고 샤워부스를 제공해 주는 다른 회사로 옮겼다. 그랬더니 거기에서는 많은 아이디어가 떠올라서 일을 계속 할 수 있었다고 한다.

여기에서 샤워부스는 개발자의 특별한 요구사항에 속하는데, 아마 우리나라의 환경에서는 개발자 1명을 위해 샤워부스까지 만들어 주기는 어려울 것이다. 그것보다는 개발자들이 무아지경(몰입)에 다시 쉽게 빠질 수 있도록 적절한 휴식 공간을 제공해 주는 것이 더 좋은 방법이다.

개발자는 멀티태스킹 기계가 아니다

조엘은 그의 블로그의 ‘개발자는 멀티태스킹 기계가 아닙니다(Human Task Switches Considered Harmful)’라는 글에서 개발자에게 두 가지 일을 동시에 시키지 말라고 했다. 위에서 언급했듯이 개발자가 개발을 하기 위해서는 한 가지 일에 집중해야 한다.

그런데 두 가지 일을 한꺼번에 시키면 개발자는 두 가지 일 사이에서 문맥교환(context swtching)을 하느라고 오히려 전체 개발 시간이 더 늦어지게 된다.

<그림 1>은 조엘이 제시한 예제이다. A라는 작업과 B라는 작업이 있는데, 각각 10초씩 걸린다. 이를 순서대로 처리하면 아래와 같다.


이를 멀티태스킹으로 처리하면 <그림 2>와 같다.


순서대로 처리하면 A를 처리하는 데 10초, B를 처리하는 데 20초가 걸렸다. 평균으로 하면 15초이다. 그런데 멀티태스킹으로 하면 A를 처리하는 데 19초, B를 처리하는 데 20초 걸렸다. 평균 19.5초이다. 오히려 멀티태스킹의 평균 시간이 더 큰 것을 알 수 있다.


문맥을 교환하는 데 비용이 드는 경우도 따져봐야 한다. 실제 개발자가 멀티태스킹을 하기 위해서는 문맥 교환 비용이 들어간다. 문맥을 교환하는 데 0.5초가 걸린다고 가정하고 계산하면 <그림 4>와 같다.


평균적으로 보면 멀티태스킹이 28초나 걸린다는 것을 확인할 수 있다. 이렇듯 개발자에게 두 가지 일을 동시에 시키는 것은 결국 생산성만 악화시키는 결과를 초래한다.

개발자들이 한 가지 일에 집중할 수 있도록 관리자는 일을 적절히 배분하는 기술과 요령을 익혀야 한다. 가장 최악의 케이스는 관리자가 개발자에게 할 일을 모두 던져주고 알아서 하라는 식으로 두는 경우이다. 그렇게 일을 주면 개발자는 한 가지 일에 집중할 수 없다.

관리자는 근본적으로 일에 대한 관리를 하는 사람이다. 자신이 작업에 대한 관리를 하지 않고 개발자에게 일임한다면 그 팀의 생산성은 좋지 않을 것이다.

 

비자아적 프로그래밍(egoless programming)

비자아적 프로그래밍은 『컴퓨터 프로그래밍의 심리학』(The Psychology of Computer Programming, Weinberg 1971)이라는 책에서 처음 언급됐다.

그 책의 요지는 개발자는 자신이 만든 프로그램에 자아를 투영해서는 안 된다는 것이다. 프로그램을 마치 자신의 작품인 것처럼 생각한다면 남들의 비판에 방어적이 되기 때문이다.

오류보고서는 인신공격으로, 검토는 위협으로, 작업에 대한 질문은 비생산적으로 생각해 오히려 제품의 품질을 떨어뜨릴 수 있다. 팀으로 작업하는 프로젝트에서는 이러한 상황을 내버려 둬서는 안 된다.

누군가가 자신의 코드에 대해 오류를 지적하면 개발자는 감정적으로 대응하게 되고, 나중에는 오류가 있더라도 지적을 하지 않는 사태가 발생해 결국에는 프로젝트의 품질이 떨어질 수 있다. 따라서 개발자는 프로그램을 자신의 작품처럼 생각해서는 안 되며, 팀 작업의 결과물로 인식해야 한다는 것이다.

이러한 ‘비자아적 프로그래밍을 위해 개발자가 갖춰야 할 10가지 지침(Ten Commandments of Egoless Programming)’이라는 것을 TechRepublic이라는 사이트에서 Lamont Adams라는 사람이 주장했다.

1. 당신은 실수할 수 있다는 것을 받아들이고 이해하라

실수는 일찍 발견할수록 좋은 것이다. 일찍 발견할수록 수정 비용도 적게 든다.


2. 당신의 코드는 당신의 작품이 아니다


코드 리뷰의 목적은 문제를 발견해서 치료하는 것이다. 그것을 개인적인 감정으로 받아들이지 마라


3. 장기도 훈수 두는 사람이 더 잘 안다


장기를 두다 보면 장기에 몰입해서 장기를 두는 사람보다도 주변에서 훈수를 두는 사람이 더 잘 알 수도 있다. 따라서 주변에서 하는 가르침에 겸손해야 한다.


4. 조언 없이 코드를 다시 쓰지 마라


혼자서 독단적으로 판단해서 코드를 다시 작성하지 말고, 코드 리뷰를 통해 코드를 다시 작성해라


5. 잘 알지 못하는 사람들을 존경하고, 복종하고, 참아라.

비기술자들은 개발자들을 좋을 때는 오페라의 프리마돈나처럼 생각하지만, 안 좋을 때는 울보로 간주한다. 여기에 휘둘리지 마라.


6. 세상에서 변하지 않는 진리는 변한다는 것이다.


변화에 대해 열린 마음으로 웃으면서 받아들여라. 요구사항의 변화, 플랫폼의 변화, 기술의 변화 이 모든 것에 대해 열린 마음으로 받아 들여라.


7. 진정한 권위는 직위가 아닌 지식으로부터 나온다.

지식은 권위를 낳고, 권위는 존경을 낳는다. 그러므로 비자아적 프로그래밍 환경에서 존경을 받고 싶다면 지식을 쌓아라.


8. 당신이 알고 있는 지식을 고수하며 싸워라. 그러나 패배는 겸허히 받아 들여라.

때로는 당신의 아이디어가 채택되지 않을 수 있다. 심지어 나중에 그것이 더 낫다고 밝혀지더라도 “내가 말한 게 맞죠?”라면서 복수할 필요는 없다.


9. 독방의 개발자는 되지 마라

어두운 사무실에 홀로 앉아서 콜라 살 때만 나타나는 은둔형 개발자는 되지 마라.


10. 사람이 아닌 코드를 비판하고, 코드가 아닌 사람에게 친절해라

코드에 대한 코멘트는 긍정적이며, 개선하는 방향으로 해야 하며, 기존 코드에 대한 비판적인 방향은 좋지 않다.


이러한 비자아적 프로그래밍이 정착되기 위해서는 프로젝트 팀 내에서도 노력이 필요하다.

가령 “이 프로그램은 누가 짜서 이렇게 오류가 많아”라는 식으로 말하게 되면 이는 결국 말하는 사람 스스로가 개발자와 코드를 하나로 인식한 셈이 된다.

이러한 언급을 용인하고 묵인해 주는 환경에서는 비자아적 프로그래밍을 할 수 없다. 또한 개발자가 한번 개발한 코드에 대해서는 영구적인 오류 수정 권한을 부여하는 환경에서도 비자아적 프로그래밍을 할 수 없다.

비자아적 프로그래밍은 특히 오픈소스 환경에서도 잘 적용되는 개념이다.

한 명의 독창적인 작품이 아닌 공동의 작품으로 간주하는 오픈소스 환경에서는 누구든지 오류를 수정하고 개선해 가면서 함께 개발해 나갈 수 있다.

이러한 비자아적 프로그래밍은 여러 명이 작업하는 팀 환경에서는 어느정도 필요한 부분이다. 그런데 위의 10가지 지침을 다 지키려면 개발자는 소인이 아닌 군자가 되어야 한다.

남의 비판도 겸허히 받아들여야 하고, 자신이 공들여 애써 만든 작품을 남들이 무너뜨리더라도 웃으면서 받아들여야 한다.

개발자는 자존심을 다 버리고 군자가 되어야 한다. 현실적으로 쉽지 않은 일이다. 필자는 현재도 개발을 하지만, 필자가 개발하는 프로그램에는 최대한의 정성을 다 쏟으려고 노력한다.

하나의 작품을 만든다는 생각으로 내 자신의 자아를 투영한다.

그래야만 정성을 가지고 애착을 가지고 만든다. 만약 개발자가 프로그램에 자아를 심지 않는다면 어떤 정성과 애착을 가지고 잘 만들 수 있을까? 자아 없이 잘 통제하고 잘 감시하면 좋은 프로그램이 나올 수 있을까?


정도의 차이는 있겠지만, 극단적인 비자아적 프로그래밍도 좋지 않으며, 그렇다고 프로그램에 자신의 자아를 너무 투영한 나머지 주변의 충고를 무시하는 것도 좋지 않다.

필자는 앞으로도 내 ‘작품’에는 자아를 투영할 것이다. 자신의 작품에는 항상 최선을 다 하고 싶은 것이 예술가들의 자존심이다.

이를 무시한 채, 자아를 버리라고 강요하는 것은 이 또한 현실을 무시한 생각이다. 열린 마음으로 자신의 작품을 향한 주변의 비판을 받아들이는 예술가야말로 진정으로 좋은 작품을 만드는 예술가다.


참고자료


1. 소프트웨어 공학의 사실과 오해, 로버트 L. 글래스, 2003

2. 조엘 온 소프트웨어, 조엘 스폴스키, 2004

3. Professional 소프트웨어 개발, 스티브 맥코넬, 2004

4. 똑똑하고 100배 일 잘하는 개발자 모시기, 조엘 스폴스키, 2007

5. 스크럼-팀의 생산성을 극대화시키는 애자일 방법론, 켄 슈와버, 마이크 비들, 2002

6. 피플웨어, 톰 디마르코, 2003

7. 개발의 심리학 이해, http://www.devx.com/DevX/Article/11659

8. 개발자는 멀티태스킹 기계가 아닙니다, http://www.joelonsoftware.com/articles/fog0000000022.html

9. 비자아적 프로그래밍을 위한 10가지 지침, http://articles.techrepublic.com.com/5100-10878_11-1045782.html

>> 출처 | 아이마소





     MSW, 개발자, 개발자심리학, 마소, 마이크로소프트웨어, 소프트웨어, 심리학, 월간마소, 한용희
     3   
BlogIcon yiabb 2009.09.30 09:33 신고
오랜만에 정독한 포스팅이네요. 마구 추천합니다^^
BlogIcon 마소호랭이 2009.10.04 14:39 신고 
ㅎ.ㅎ 감사합니다. 저도 마구 추천입니다.
lookit 2009.09.30 11:15
관리자들이 많이 읽어줘야 할듯하네요.. ^^;
BlogIcon 마소호랭이 2009.10.04 14:40 신고 
관리자뿐만 아니라 프로젝트에 참여하는 사람들이 서로 이해하기 위해 필요한 내용이란 생각이듭니다.
BlogIcon sheon 2009.09.30 12:12 신고
포스팅 잘 보았습니다. 개발자(엔지니어측면)는 업무 특성상 폐쇄적으로 빠질 수 있는 경우가 많은 것 같아요.
언급 하셨던 것처럼 마치 작품을 빚어내는 예술가 처럼 말이죠. 저역시 최근 개발자와 프로그래머라는 입장에
대해 좀 생각해본 계기가 있어 트랙백 걸고 갑니다.
좋은 하루 되세요~
BlogIcon 마소호랭이 2009.10.04 14:40 신고 
감사합니다.
BlogIcon 도이모이 2009.10.01 17:58
정독해야 할 거 같아.. 프린터 했습니다 ~
BlogIcon 마소호랭이 2009.10.04 14:41 신고 
^-^*
추석 연휴는 잘 보내고 계신지요? 늘 감사합니다.
BlogIcon 도이모이 2009.10.05 08:07 
제가 감사하죠 ^^
taxhon 2009.10.12 17:50
이 글이 절실히 느껴져 퍼갑니다. 감사해요~

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

한국에서 개발자로 살아간다는 것 & 기자로 산다는 것
+   [개발 이야기]   |  2008. 4. 14. 14:39  


사용자 삽입 이미지
(오래 전 이 그림을 보고 참으로 공감을 했었습니다. 그런데 생각해 보니 기자도 그다지 다르지 않다는 생각도... ㅎ.ㅎ)

어릴 적 자신이 원하는 거라면 뭐든지 만들어낼 수 있는 프로그래밍이 재미있어서

개발자가 되기를 꿈꾸었다는 개발자가 있습니다.

프로그래밍이 너무 재미있어 틈만나면 프로그래밍을 하다가 결국에는 개발자가 되었습니다.

그리고 얼마 뒤 그는 알아버리게 되었습니다.

개발자라고 모든 걸 다 만들 수 있는 것이 아니라는 사실을 말입니다.

개발자 한용희 씨의 이야기입니다.

그는 요즘 개발자와 관리자의 갈림길에 서 있습니다.

아마 어느정도 연차가 쌓인 개발자라면 누구라도 비슷한 경험을 하였을 거라고 생각합니다.

그리고 그가 '한국에서 개발자로 살아간다는 것'이란 제목의 글을 썼습니다.

읽어보면 많은 부분 공감이 갈 거라고 생각합니다.

호랭이는 얼마 전 한 개발자로부터 비슷한 이야기를 들은 적이 있습니다.

SI 업체에 일하는 그는 자신의 회사 직원 중 90%가 관리자라고 말했습니다.

그는 보기 드문 개발자라는 얘깁니다.

게다가 이제 자신도 그 회사에서 개발할 수 있는 날이 얼마 남지 않은 듯하다고 말했습니다.

개발자 열 명보다 영업자 한 명이 벌어주는 돈이 많은 탓에

연차가 쌓이고 연봉이 오를 수록 영업과 관리의 압뷁을 받게된다는 이야기였습니다.

어차피 개발은 하청을 주면 저렴하게 이용할 수 있으니 돈 많이 받는 고참 개발자 따위는 필요 없다는 이야기였습니다.

사실 이런 우울한 이야기를 하자면 기자도 그다지 다르지 않습니다.

하지만 꿈과 열정을 가지고 시작한 일이기에 우리의 일은 소중하다고 믿고 있습니다.

한용희씨의 글에서처럼 개발자들의 가치가 좀 더 높이 평가받는 날이 어서 빨리 오기를 바랍니다.

개발자 파이팅!!! 기자들도 파이팅!!!




     SI, 개발자, 개발자 연봉, 관리자, , 마이크로소프트웨어, 한용희
     0   
BlogIcon 지환태 2008.04.14 15:49 신고
저도 장래희망이 개발자인데.
한국에선 힘든가보네요 ㅠㅠ
BlogIcon 호랭이 2008.04.14 16:36 
환타 님이 개발자가 되실 때 쯤에는 한국 개발자들도 좋은 대우를 받고 있게 되겠지요. ㅎ.ㅎ
2008.04.14 18:59
비밀댓글입니다
BlogIcon 마소호랭이 2008.04.14 19:45 신고 
감사합니다. 얼굴 못지 않게 마음까지 아름다운 분이군요. 덜덜덜... ㅎ.ㅎ
2008.04.15 09:16
비밀댓글입니다
BlogIcon 마소호랭이 2008.04.15 10:54 신고 
ㅋㅋㅋ 제가 하는 짓이 그렇죠 뭐!
BlogIcon 이정주 2008.04.18 23:42
학생들은 늘 개발자는 야근만하고 제일 밑이다라는 꼭 않좋은 소문으로(다 오래간만에 다녀간 선배들을 통해) 좌절을 하더라구요. 얼릉 좋은 환경이 만들어졌으면 좋겠어요~^^
BlogIcon 호랭이 2008.04.19 10:20 
그러게 말예요. 자 그럼 이제부터는 아주 신나게 사는 개발자들의 소식만 전해 드리겠습니다. 충성 ^-^ㅋ
한용희 2008.05.02 09:32
편집장님 글 잘봤습니다.^^ 감사 합니다.~
BlogIcon 호랭이 2008.05.02 10:14 
ㅎ.ㅎ 감사합니다.
언제 한번 뵈야 하는데 말이죠.

아이디 
비밀번호 
홈페이지 
비밀글   

 

<<이전 | 1 | 다음>>

열이아빠's Blog is powered by Daum