블로그 이미지
Every unexpected event is a path to learning for you.

카테고리

분류 전체보기 (2731)
Unity3D (814)
Programming (474)
Server (33)
Unreal (4)
Gamebryo (56)
Tip & Tech (228)
협업 (57)
3DS Max (3)
Game (12)
Utility (136)
Etc (96)
Link (32)
Portfolio (19)
Subject (90)
iOS,OSX (51)
Android (14)
Linux (5)
잉여 프로젝트 (2)
게임이야기 (3)
Memories (20)
Interest (38)
Thinking (38)
한글 (30)
PaperCraft (5)
Animation (408)
Wallpaper (2)
재테크 (18)
Exercise (3)
나만의 맛집 (3)
냥이 (10)
육아 (16)
Total
Today
Yesterday
03-29 00:00

'프로그래머'에 해당되는 글 4건

  1. 2014.05.11 [펌] 프로그래머로 산다는 것
  2. 2013.09.26 프로그래머 죽이기
  3. 2010.10.25 [펌] 프로그래머에 관한글
  4. 2010.08.23 How To Be A Programmer
출처 : http://deview.kr/2013/detail.nhn?topicSeq=15


반응형
Posted by blueasa
, |

프로그래머 죽이기

Thinking / 2013. 9. 26. 00:03

출처 : http://www.mrlatte.net/2013/09/blog-post.html



어떤 글이 사람들에게 주목을 받기 위해서는 제목이 중요하다. 하지만 너무 자극적인 제목을 사용하면 처음에는 사람들의 관심을 받을 수 있겠지만, 내용이 기대에 못 미친다면 아마 끝까지 읽게 하기는 힘들 것이다. 그렇다고 너무 뻔하고 무난한 제목을 선택한다면 관심조차 받지 못할 것이다. 이처럼 제목의 선정이란 참으로 고민되는 일이다. 짧은 블로그 게시물은 물론이고 많은 노력이 들어간 책의 긴 글의 경우는 더욱 그러하리라 생각한다. 

최근 피플웨어(Peopleware)[1]라는 책을 읽었다. 나는 이 책을 읽는 내내 소프트웨어 분야에 종사하는 관리자라면 꼭 읽었으면 좋겠다는 생각이 들 정도로 이 책은 소프트웨어 분야의 명서로 꼽을만하다. 나는 이 책을 읽고 어떻게 하면 소프트웨어 개발자로서 일을 잘할 수 있는지에 대해 글을 써보기로 결심했다. 하지만 제목은 여전히 고민스러운 문제였다. 그런데 이 책의 한 단락에서 아이디어를 얻을 수 있었다. 피플웨어는 내용도 좋지만, 단락의 제목을 짓는 기술이 특히 인상적이다. 수학적 증명 방법에 비교하면 아마 귀납법[2]보다는 간접 증명법[3]에 가까울 것이다. 여기서 아이디어를 얻어서 본 글의 제목을 간접증명법의 "프로그래머 죽이기"로 하기로 결심했다.



내가 생각하는 프로그래머를 죽이는 방법은 3가지인데 다음과 같다. “짜장과 짬뽕 모두 좋아하는 관리자", “제임스 본드(James Bond)[4] 관리자", “스티븐 잡스(Steven Jobs)[5] 프로그래머"이다. 세 가지 항목 모두 비유를 통해서 의도하는 바를 더 효과적으로 설명하려고 한다.

프로그래머를 죽이는 방법의 첫 번째는 "짜장과 짬뽕 모두를 좋아하는 관리자"가 필요하다는 것이다. 이 관리자는 마치 중국집에서 짜장을 먹을까? 짬뽕을 먹을까? 고민하다가 결정하지 못하고 안절부절못하여 결정이 늦거나 짜장면을 시킨 후에 짬뽕을 먹을 걸 하면서 계속 후회하곤 한다. 실제 업무에서 의사 결정을 할 때도 마찬가지이다. 구글의 래리 페이지(Larry Page)[6]는 빠르고 좋은 결정은 있지만, 느리고 좋은 결정은 없다고 했다. 이런 유형의 관리자는 빠른 결정을 못 함은 물론이고 프로젝트 결정을 진행하고 있는 도중 프로젝트에 대한 성공 여부를 확신하지 못하여 그 프로젝트를 적극적으로 지원해 주지도, 프로젝트 팀원에게 비전도 제시하지도 못함으로써 결국 프로젝트와 참여한 프로그래머들을 망치게 된다.

다음으로 프로그래머를 죽이기 위해서 “제임스 본드 관리자"가 있어야 한다. 007[7] 영화에서 보듯이 제임스 본드는 비밀 작전을 수행하는 요원이다. 그에게 내려진 지령은 엄격한 비밀에 부쳐지고 몇 초 내에 파괴되기도 한다. 실제 프로젝트에서도 마치 자신이 007 요원이나 된 듯이 프로젝트에 대한 정보를 공유하지 않고 비밀로 하는 관리자가 있다. 때로는 어떤 정보는 프로젝트 팀원에게 좋지 않은 영향을 미치는 정보일 수 있다. 하지만 그렇다 하더라도 프로젝트에 관한 모든 정보는 공유돼야 한다. 프로젝트 팀원들은 공유된 정보를 바탕으로 때로는 의욕적으로 또 때로는 위기 상황을 같이 해결하는 단결력과 협동심의 팀워크를 발휘함으로써 프로젝트를 성공적으로 이끌 수 있기 때문이다.

마지막으로 “스티븐 잡스 프로그래머"가 프로젝트 팀에 존재해야 한다. 위 제시한 두 가지 사항은  관리자가 프로그래머를 죽이는 원인이었다면 이 항목은 프로그래머 자신의 문제이다. 스티븐 잡스 같은 프로그래머라니? 스티븐 잡스가 얼마나 성공적으로 애플(Apple)을 이끌었는지, 얼마나 혁신적인 사람이었는지 몰라서 하는 말이 아닐까? 라고 생각할지 모르겠다. 하지만 이것은 스티븐 잡스의 업적을 두고 하는 말은 아니다. 바로 그처럼 일 중독에 걸린 것처럼 일하는 프로그래머를 두고 하는 말이다. 스티븐 잡스는 업무 적으로는 큰 성공을 거뒀지만, 가정과 개인의 삶에는 상대적으로 소홀할 수밖에 없었을 것이다. 비슷한 내용을 다룬 영화 "클릭"[8][9]이 있으니 아직 못 보신 분들이 있다면 보기를 추천한다.

프로젝트 팀에 일 중독의 프로그래머가 많다면 프로젝트는 성공할 수 있을지는 몰라도 결국 프로젝트가 끝나면 프로그래머가 모두 떠나거나 떠나지 않더라도 정신적으로 큰 상처를 받은 상태가 지속될 것이다. 이에 따르는 비용을 계산하면 결국 프로젝트는 실패한 것으로 판단할 수 밖에 없다.

프로그래머는 창의적인 직업이다. 그들은 공학적으로 시스템을 만들고 있지만, 창의적인 아이디어도 역시 필요한 직업이다. 같은 맥락으로 심지어 최근 프로그래머들의 소양 중에 인문학도 포함되고 있지 않은가? 창의적인 아이디어는 매일 몰아치는 업무 속에서는 나올 수 없다. 창의력은 충분한 휴식에서 나온다는 벤자민 베어드(Benjamin Baird)의 연구 결과도 이미 알려진 바 있다. 우리는 구글(Google)의 지메일(Gmail), 파이썬(Python), 최근 깃헙(Github)의 수많은 프로젝트들이 프로그래머들의 잉여 시간으로 탄생하였고 운영되고 있다는 사실에 주목해야 한다. 프로그래머들은 과도하게 업무를 수행하기 보다는 조금 느슨하게 그리고 여유 시간에는 현재 프로젝트의 심도 있는 고민과 새로운 프로젝트를 위한 재창조의 시간으로 보내야 한다.

우리나라 뿐만 아니라 소프트웨어의 선진국이라고 생각되는 미국에서 조차 회사의 조직을 정비하고 프로그래머들이 속해있는 각 조직과 프로젝트를 성공적으로 이끄는 것은 쉽지 않은 문제라는 것을 책 "피플웨어"를 통해 알 수 있었다. 그리고 이 책이 미국의 현실을 바탕으로 쓰여 있긴 하지만 우리나라의 현재 소프트웨어 기업들의 현실과 전혀 다르지 않다는 것도 놀랄만한 일이다.

나는 미국의 프로그래머는 연봉이 10만 달러가 넘는다는 기사를 보고 부러워했던 적도 있다. 하지만 실상 막대한 세금과 기본 생활비를 제외하고 나면 실제 쓸 수 있는 것은 우리나라보다 적을 수도 있다는 사실은 상대적으로 열악한 환경에 있는 우리에게 매우 고무적인 사실로 들린다. 

내가 1999년 대학에 처음 입학했을 때 10년 후인 2009쯤 되면 소프트웨어 개발자들이 더 이상 할 일이 없을 만큼 소프트웨어 개발이 자동화 될 것으로 생각했었다. 하지만 지금 현실은 어떠한가? 아직도 대부분의 소프트웨어 개발을 프로그래머가 직접하고 있다. 오히려 1999년 보다 지금이 플랫폼이 다양화되고 스마트 기기가 확산됨으로써 프로그래머가 해야 하는  일들이 오히려 더 많아졌다.

소프트웨어 개발은 사람이 직접 수행하고 그 과정에서 사람과의 관계가 중요할 것은 앞으로 영화 터미네이터(The Terminator)[10]에서 등장했던 스카이넷(skynet)[11]이나 메트릭스(The Matrix)[12]처럼 스스로 코드를 생성해 낼 수 있는 뛰어난 인공지능 컴퓨터가 나오기 전까지는 계속될 것이라고 생각한다. 그리고 지금의 인공지능 발전 속도를 감안하면 아마 내 일생 동안 앞으로 70년 이상은 계속되리라 예상해본다. 결국 앞으로 꽤 오랜 시간 동안 소프트웨어 개발에 있어서는 사람과의 관계는 매우 중요한 요소로 자리 잡고 있을 것이며 이를 어떻게 잘 해결하는 지가 소프트웨어 프로젝트의 성공을 결정할 것이다.

프로그래머를 죽일 수 있는 방법은 본 글에서 제시한 것 외에 훨씬 더 많이 있을 것이다. 우리는 이러한 프로그래머를 죽이는 상황에 처했을 때 이것을 인지할 수 있는 능력을 길러야 한다. 인지할 수 있는 것과 전혀 인지하지 못하는 것은 매우 다르기 때문이다. 인지할 경우 바꿀 수 있는 기회는 아직 남아있다는 뜻이다. 프로그래머들은 지금 또는 앞으로의 상황들을 인지하고 바꾸고자 노력해야 한다. 마지막으로 "피플웨어"에 있는 내용을 하나 인용하면서 글을 마치고자 한다. 이러한 상황에 처했을 때 "우리는 회사를 바꾸거나 우리가 회사를 바꾸거나 둘 중에 하나는 꼭 해야 한다."



Reference


[1] (2012). Peopleware: Productive Projects and Teams (Second Edition): Tom ... Retrieved September 7, 2013, from http://www.amazon.com/Peopleware-Productive-Projects-Second-Edition/dp/0932633439.
[2] (2007). 수학적 귀납법 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EC%88%98%ED%95%99%EC%A0%81_%EA%B7%80%EB%82%A9%EB%B2%95.
[3] (2009). 2장 증명. Retrieved September 7, 2013, from http://sungkyul.edu/~choiym/class/Fundamental_Mathematics_for_Multimedia/pdf/media_lecture2.pdf.
[4] (2006). 제임스 본드 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EC%A0%9C%EC%9E%84%EC%8A%A4_%EB%B3%B8%EB%93%9C.
[5] (2005). 스티브 잡스 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EC%8A%A4%ED%8B%B0%EB%B8%8C_%EC%9E%A1%EC%8A%A4.
[6] (2007). 래리 페이지 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%EB%9E%98%EB%A6%AC_%ED%8E%98%EC%9D%B4%EC%A7%80.
[7] The Official James Bond 007 Website | Home. Retrieved September 7, 2013, from http://www.007.com/.
[8] (2005). Click | Sony Pictures. Retrieved September 9, 2013, from http://www.sonypictures.com/movies/click/.
[9] (2011). 라떼군 이야기 (Mr.Latte Story): 영화 클릭(Click). Retrieved September 9, 2013, from http://www.mrlatte.net/2009/09/click.html.
[10] (2010). 터미네이터 (영화) - 위키백과, 우리 모두의 백과사전. Retrieved September 9, 2013, from http://ko.wikipedia.org/wiki/%ED%84%B0%EB%AF%B8%EB%84%A4%EC%9D%B4%ED%84%B0_(%EC%98%81%ED%99%94).
[11] (2006). 터미네이터 - 위키백과, 우리 모두의 백과사전. Retrieved September 7, 2013, from http://ko.wikipedia.org/wiki/%ED%84%B0%EB%AF%B8%EB%84%A4%EC%9D%B4%ED%84%B0.
[12] (2003). The Matrix - Wikipedia, the free encyclopedia. Retrieved September 7, 2013, from http://en.wikipedia.org/wiki/The_Matrix.


반응형
Posted by blueasa
, |

[펌] 프로그래머에 관한글

Etc / 2010. 10. 25. 21:22
프로그래밍이란 절대 코딩이 아니다. 먼저 생각하고 만든 것을
  정리하고 문제점을 해결해 나가는 모든 과정이 프로그래밍이다.
  이 점을 자기 자신에게 충분히 납득시켜야 한다. 코딩은 프로그래밍
  의 일부이다.

- 각 언어는 모두 나름의 탄생 이유가 있으면 그 언어를 만든 사람의
  아이디어가 담겨 있다. 언어를 먼저 선택하려 하지 말라.
  유능한 프로그래머는 절대 한 가지 언어에 집착하지 않는다.

언어를 처음 배울 때에는 그에 걸맞게 쉬운 언어부터 시작하라.
  실전에서 사용하는 언어를 먼저 배워두면 더 이득이 될 것이라고
  생각하지 말라. 전문 프로그래머가 되려면 최소한 세 개 이상의
  언어를 익혀야 한다. 물론 세 가지 언어를 똑같이 잘 할 필요는
  없다. 자기 주 종목 언어를 갖지 말라는 말이 아니다.

- 책을 다 읽고 나서야 프로그래밍할 수 있다고 생각하지 말고
  배운 만큼만 갖고도 연습 코드를 작성할 수 있어야 한다.

- 언어 그 자체는 여러분의 상상력을 키워주지 않는다. 상상력은
  여러분 스스로 인생의 모든 영역에서 듣고 배우면서 채워야 한다.
  언어는 상상력을 실현할 도구만 제공할 뿐이다. 과학과 수학에
  관심을 가져 보라(그렇대고 해서 A 등급을 맞을 만큼 잘 할 필요는
  없다).

주석과 문서화 버릇을 들이자. 프로그래밍의 귀찮은 일부가 아니라
  매우 중요한 핵심 부분이다.

- 언어책이 줄 수 있는 지식의 양은 딱 그만큼이다. 여러분의 상상력과
  프로그래밍 능력을 살찌워주는 것은 다른 사람, 다른 프로그래머다.
  적극적으로 프로그래밍 사용자 모임 또는 뉴스그룹에 참여해 남을
  돕고 남으로부터 도움을 받는것이 자기 계발의 원천이다.

자기가 습득한 지식은 자기만이 볼 수 있는 형태든 아니면 홈페이지를
  통해 누구나 볼 수 있는 형태든 상관없이 정리하는 습관을 갖자.
  무엇이든 막상 글로 적으면 자신이 얼마나 피상적으로 알고 있는지
  각성하게 되고 지식을 좀 더 견고하게 만들게 된다.

- 현실은 현실이다. 영어를 잘 못하고 두려워하는 사람이 최고의
  프로그래머가 되기는 거의 불가능하다. 여러분이 한국어만 하면
  한국 프로그래머의 지식만 습득할 수 있을 뿐이다. 영어를 두려워
  하지 않는다면, 그 대가는 전세계 프로그래머의 지식 습득이 된다
  (영어를 잘 하는 방법은 영어를 잘하는 사람에게 물어보라).


반응형
Posted by blueasa
, |

How To Be A Programmer

Etc / 2010. 8. 23. 19:31
반응형
Posted by blueasa
, |