Thoughts2017.03.06 15:34

지난번에 예고 하였듯이, 오늘은 바람직한 링크드인(LinkedIn) 이력서의 비결을 알아보자.


'바람직한 링크드인 이력서'란 무엇인가를 알기 위해서는, 내가 가고 싶은 회사에서 어떤 기준으로 이력서를 고르는지를 소상히 알아보는 것이 순서이리라. 


아마존을 기준으로 살펴보면 (다른 기업들도 대동소이하리라고 생각되지만), 대략 다음과 같은 기준으로 이력서를 고른다.


1. 어느 회사를 다녔나?

2. 어느 학교를 다녔나?


그러나 보통 2는 1보다는 덜 중요하다. 미국 리크루팅 팀이 한국 대학 순위에 대해서 별로 신경쓰지 않기도 하거니와, 보통 리크루팅 팀이 채용 대상으로 하는 주니어-시니어 엔지니어는 2년 이상의 경력을 가진 사람을 말하기 때문이다. 경력자를 뽑는 경우에는 대체로 어디에서 일했는지만 본다고 생각하면 된다. 따라서 위의 두 기준은 대체로 아래의 한 가지 기준으로 수렴한다.


1. 어느 회사를 다녔나?


자... 그러면 바람직한 글로벌 이력서를 만들기 위해서는 좋은 회사에 들어가야 한다는 역설적인 결론에 도달한다. -_- 


미국 현지 리크루팅 팀이 주로 보는 한국 기업은 다음과 같다.


1. 샘숭

2. 엘쥐

3. 네이버

4. 넥슨

5. 카카오

6. NHN ENTERTAINMENT

7. ... (생각하기 귀찮아서 이하 생략)


그러니까 여러분이 생각하는 바로 그 기업들을 미국에서도 주목하고 있다고 보면 된다. 


... 그러니 어쨌던 2년 이하의 비경력자는 미국 진출하기가 쉽지 않다. 일단 국내에서 2년 이상의 경력을 쌓도록 하자. 가급적이면 해외에서도 알고 있을만한 굴지의 소프트웨어 회사면 유리하다. 


이 글을 쓰고 있는 필자의 링크드인 이력서는 어떻게 생겨먹었을까? 아래의 링크를 보자. 


https://www.linkedin.com/in/bjlee72/


보시다시피 별거 있다면 있고 없다면 없는, 평범한 이력서다. 아마 이 이력서에서 아마존 이전의 가장 쓸만한 경력은 NHN ENTERTAINMENT일텐데, 아마존에서도 그거 한줄 보고 연락한 것 같다. 


그러니 해외 취업을 꿈꾸고 있다면 국내에서 좋은 기업에 입사해 최소 2년간 열심히 일하도록 하자. 그러면 좋은 해외 기업에서도 높은 확률로 연락이 올 것이다. 그러니 링크드인 프로파일은 절대로 한글로 적지 말자. 구사 가능 언어 목록에는 꼭 영어를 명시하자.


다음 시간에는, 모든 개발자에게 공통적으로 심각한 문제 가운데 하나인 '영어'에 대해서 잠시 살펴보도록 하겠다.




저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2017.03.03 04:22

오늘은 미국에서 프로그래머로 일하는 방법을 알아보자. 그 첫 번째 시간이다. 


미국에서 프로그래머로 일하는 첫 걸음이 뭐라고 생각하는가?


미국에서 프로그래머로 일하려면 일단 미국에 가야한다. 


미국에 가는 방법은 여러가지가 있다.


1. 비행기

2. 배

3. ?


이 중 가장 쉬운 방법은 비행기를 타는 것이다. 물론 돈이 좀 든다. 이 돈을 내가 직접 내면 너무 아깝다. 그러니 공짜로 갈 수 있는 방법을 알아봐야 한다.


공짜로 가는 방법에는 여러가지가 있으나, 가장 보편적인 것은 출장일 것이다. 그러나 회사에서 돈들여서 출장을 보내줬더니 면접이나 보러다니고... 그러다가 ㅈ망하기 딱 좋다. 


가장 좋은 방법은 일단 면접에 합격하고 미국 취업 비자를 받은 다음 해당 회사가 지원해주는 트랜스퍼 패키지를 이용해서 미국에 가는 것이다. 그러면 죄 공짜다. 


그러니 결론은 하나 뿐이다. 일단 면접에 합격해야 한다. -_-


그러면 한국에서 면접에 합격하려면 어떻게 해야 하나?


한국에 자주 와서 대규모 채용 행사를 진행하는 회사를 눈여겨 봐뒀다가 면접을 보면 된다. 대표적인 회사로 아마존이 있다. 일년에 두어번씩 한국에서 채용 행사를 하니 그 기회를 이용하면 된다. 


한국에서 열리는 채용 행사를 통해 면접을 보는 경우, 대개의 경우 당일 바로 당락 통보를 받으므로 편하다. 


그런대 대관절 채용 행사에 초청은 어떻게 받나?


보통 아마존 같은 곳에서 채용 대상 직원을 물색하는 방법은 다음의 몇 가지다.


1. 링크드인 이력서

2. 아마존 직원을 통한 추천


따라서, 취업하고 싶은 회사에 아는 사람이 없으면 링크드인 이력서를 잘 써서 검색 대상이 되는 수 밖에 없다.


다음 시간에는 링크드인 이력서를 잘 쓰는 방법을 알아보자. 




저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 담덕

    우선 영어를 해야되죠? ㅠㅠ

    2017.03.04 13:48 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 다음 편이 기다려지네요. 다음 편에서 관리자님의 링크드인 이력서도 예시로 들어주시면 좋을 것 같습니다.

    2017.03.05 23:05 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2014.08.04 10:20

Q: 프로그래머 남편이 수상해요


안녕하세요. 프로그래머 남편을 두고 있는 여성입니다. 남편의 행동이 아무래도 수상해서 이렇게 다른 분들의 의견을 듣고자 글을 남깁니다. 


예전과는 다르게 부쩍 남편이 핸드폰 알림에 민감해요. 알림이 오면 꼭 컴퓨터 앞에 가서 앉고요. 앉았다 오면 히죽히죽 즐거운 표정이 되어 있는 경우도 있고, 표정이 안좋아지는 경우도 있어요. 


그래서 몰래 핸드폰에 무슨 알림이 오나 본 적이 있는데, 한글로 대화를 나누는 것 같지는 않고 영어로 대화를 나누는 것 같아요. 이메일은 아닌 것 같고요.


핸드폰 알림에 신경쓰는 남자들 대부분 바람 피는 거라던데, 내 남편도 그러는 걸까요? 


아. 퇴근 시간이 달라지거나, 부쩍 술을 많이 마신다거나 하진 않아요. 


A: 정상입니다


안녕하세요. 댁의 남편은 지극히 정상일 가능성이 높습니다. 


기회가 되신다면 남편의 핸드폰에 StackExchange 같은 어플이 깔려있는지 살펴보세요. 이 어플은 대개 StackOverflow.com 같은 사이트에 연결되어 있는데, 프로그래머들끼리 질문하고 대답하면서 노는 사이트입니다. 멋진 답변으로 채택되면 배지도 주고 점수도 주기 때문에, 의외로 중독성이 높습니다. (물론 이 점수가 환금성은 전혀 없기 때문에, 지나치게 중독되면 곤란하긴 합니다.) 


전 세계의 프로그래머들과 질문/답변을 주고받는 시스템이기 때문에, 시도때도 없이 알람이 울릴 수 있다는 것은 문제입니다. 취침할때는 무음으로 바꿔놓도록 신경써 주세요. 아니면 핸드폰 어플은 삭제하도록 권해 주시던지요. 웹에서만 보고 답변하도록 해 주시고, 가능하면 하루에 한 가지 정도의 질문/답변에만 집중하도록 해주세요. 너무 몰두하면 업무에 방해가 되기도 하니까요.


아무튼 히죽히죽 즐거운 표정이 되어 돌아온다는 것은 점수를 땄다는 거고, 표정이 어두워져서 왔다는 것은 답변이 성의가 없는 것으로 간주되어 점수가 깎였다는 뜻이라고 보시면 됩니다. 그럴때는 다 알고 있다는 표정으로 어깨나 두들겨 주세요. 


이 사이트에서 높은 점수를 받으면 외국계 기업에 이직 기회가 생기는 경우도 있기 때문에, 중독되는 것이 걱정되어서 굳이 막으실 필요는 없겠습니다.


물론 점수놀이에 몰두하는 게 좀 유치하게 느껴지실 수는 있겠습니다만... (웃음) 



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. ㅋㅋ 프로그래머라서 그런지 역시 ㅡ로그램에 일희일비하는군요

    2014.08.04 15:59 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2013.12.11 17:07

좋은 개발자를 뽑기 위한 환경을 갖추었다고 칩시다. 그런데 대관절 좋은 개발자는 어떻게 알아볼 수 있을까요? 좋은 개발자와 그렇지 않은 개발자를 가려내는 것은 생각보다 어렵습니다. 



일단 개발자를 만났다면: 


1. 어떤 프로그램을 만들어 보았는지 물어보라.


만일 '재미삼아' 만들어 본 프로그램이 있다면, 그리고 그 프로그램을 아직도 유지보수하고 있다면, 혹은 그 프로그램을 공개 소프트웨어로 만들어 많은 사람들에게 배포해 본 경험이 있다면, 그 사람은 좋은 개발자일 가능성이 아주 높습니다. 


2. 어떤 프로젝트를 진행했었는지 물어보라. 


자신이 진행했던 프로젝트 이야기를 하면서 많은 개발자들은 자기 어필을 하려고 시도합니다. 가급적이면 그 이야기를 끝까지 들어주면서 그 개발자의 역할이 어느 정도였는지 파악하세요. 가능하면 무엇이 어려웠고, 그 어려움을 극복하기 위해 어떤 노력을 했는지 들어보세요. 그런 이야기를 듣다 보면, (1) 독야청청 독불장군형 개발자인지 (2) 협업 중심의 개발자인지 (3) 문제 방임형 개발자인지 (4) 문제 해결형 개발자인지 (5) 자기를 잘 포장할 줄 아는 개발자인지 (5) 말에는 별 소질이 없는 개발자인지 (6) 문제를 깊이있게 들여다보고 개발을 진행하는 사람인지 (7) 일단 만들어 보고 문제를 몸으로 이해하는 유형의 개발자인지 등등의 중요한 정보를 알아낼 수 있을 겁니다. 


3. 간단한 문제를 던져주고 어떤 접근법으로 풀 지를 물어보라.


보통 '코딩 인터뷰'를 진행하기도 하는데, 문법을 다 기억 못하거나 관련 자료를 찾아보면서 프로그래밍하는 사람도 많으니 코딩을 실제로 해 보라고 요구하기 보다는 어떤 접근법을 사용할 것인지 물어보는 것도 괜찮습니다. (물론 대부분의 외국 IT 업체는 종이에라도 프로그램을 만들어 보라고 요구하죠.) 답변을 들어보면 꽤 많은 정보를 얻을 수 있는데 (1) 예전에 이 개발자는 어떤 식으로 문제를 풀었는지를 알 수 있고 (2) 필요한 분야에 맞는 최신 지식을 많이 갖추고 있는지 알 수 있고 (3) 실질적으로 문제를 해결할 능력이 있는 지를 알 수 있습니다. 


덤으로, '당신의 해결방법에는 이러저러한 문제가 있을 것 같은데, 그건 어떻게 해결할 건가요?' 같은 질문도 던져 보면 좋습니다. 


4. 개발자의 입장에서 대화해 보라.


개발자의 입장에서 술 한잔 하면서 이런 저런 이야기를 하다보면, (결국에는) 일과 관련된 무용담을 털어놓게 되기 마련입니다. 가능하면 솔직하게 가감없이 자기 이야기를 먼저 하세요. '저도 그런 문제를 겪었었는데 저는 이렇게 해결했습니다' 같은 답변을 듣게 된다면, 아마 술이나 커피 값이 아깝지는 않을 겁니다. 


5. 옷차림에는 신경쓰지 마라.


허술한 옷차림을 하고 있는 개발자라면, 일 이외의 다른 문제에는 아예 관심이 없는 사람일 가능성이 있습니다. 의외로 갖춰입고 면접에 임한 개발자라면, 세상에 대한 열정이 가득한 사람일 가능성이 높습니다. 어느 쪽이라도 손해날 것은 없으니 웬만하면 옷차림은 신경쓰지 마세요. 


6. 회사 문화에 잘 동화될 만한 사람인지 알아보라. 


자만심, 아집, 편견 등등은 협력이나 조화같은 보편적인 가치에 굉장히 적대적인 속성들입니다. 이런 속성들을 갖춘 사람인지 살펴보시고, 능력이 기대치를 훨씬 상회하지 않는 한 그런 사람은 뽑지 마세요. 결국에는 팀이 아작납니다. 남 이야기를 잘 들으려 하지 않는 사람, 열 명이 아니라고 해도 자기 고집대로 하는 사람은 전부 이 부류에 넣을 수 있습니다. 냉소적이거나 빈정대는 습관이 있는 사람도 좋지 않습니다. 다른 사람 기분을 상하게 만드니까요. 


7. 가르칠 수 있을만한 사람인지 알아보라. 


즐겁게 배울 준비가 되어 있는 사람은 설사 배경지식이 부족해도 뽑아볼 만 합니다. 의외의 분야에 사람이 필요한데 거기 지원해 볼 생각은 있느냐, 같은 질문을 던져보고 반응을 보면 좋습니다. 물론 거짓된 반응을 보일 수도 있으니, 일정 기간 동안은 함께 일하면서 살펴볼 기회를 갖는 것도 좋습니다. 새로운 업무에 대한 파악 능력이 좋은 사람은 어떤 상황에 처하더라도 도움이 됩니다. 


8. 이전 직장에서의 평판을 알아보라. 


요즘은 전직을 통해 새로운 기회를 찾는 것이 보편화되고 있는 추세이므로, 직장을 많이 옮기는 것은 그다지 흠이 되지 않습니다. 오히려 전 직장에서 사람들과 어떻게 어울렸고, 어떤 리더십을 발휘했고, 어떤 결과를 만들어 낸 다음에 퇴사했는지를 알아보면 뽑는 사람 입장에서는 리스크를 줄일 수 있으므로 도움이 됩니다. 다만 너무 뒷조사하듯 할 필요는 없고, 그냥 아는 사람이 있다면 (이 바닥에서는 한 다리 건너면 다 아는 사람이죠) 한번 넌지시 물어보는 것으로 충분하겠죠. 


저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2013.10.12 12:58

하루 30분씩 운동한다는 원칙을 지키려고 애를 많이 쓰고 있는데요. 날이 좋으면 자전거로 출퇴근을 하려고 하고, 집에서는 근력 운동을 보충하려고 하고 있습니다. 지난 2년간 이런 식으로 적어도 일주일에 3일 이상은 운동을 하고 있는데요. 덕분에 아직까지 별다른 신체적 이상 없이 프로그래머로서 건강을 유지하고 있습니다. 


제가 생각하기에 꾸준한 운동의 비결은 (1) 별다른 기구 없이 가능해야 하며 (2) 재미있어야 한다는 것인데요. 별다른 기구 없이 운동을 하려면 자기 신체의 중량을 최대한 이용해야 하고, 재미가 있으려면 다양하게 변화를 주는 것이 가능해야 합니다. 변화로는 운동의 순서를 바꾼다거나, 중량을 바꾼다거나 하는 것이 있을 수 있겠네요. 


아무튼 2년 이상 이런 식으로 운동을 하고 소박한 식사 습관을 유지하다보니 (1) 체중이 거의 항상 일정하게 유지되고 (2) 최소한 어떤 운동은 반복해주어야 근력이 유지된다는 것이 감이 좀 오더군요. 그래서 오늘은 그 이야기를 좀 할까 합니다.


1. 스트레칭


운동 전에는 반드시 (아무리 짧은 시간 운동하건 간에) 스트레칭으로 몸을 풀어주는 것이 좋습니다.


2. 턱걸이


해보니 턱걸이로 운동을 시작하는 것이 가장 효과가 좋은 것 같습니다. 턱걸이에는 두 가지 방법이 있는데, 친업과 풀업의 두 가지 방법이 있습니다. 어느 쪽으로 하시던 자기한테 잘 맞는 쪽으로 시작해서, 나머지를 보충하시면 됩니다. 저는 오른 팔의 근력이 별로 시원치가 않아서, 턱걸이는 거의 흉내만 내고 있습니다. ^^; 어쨌든 3~4세트. 세트당 개수는 좋으실 대로 (보통 10회내외)





3. 팔굽혀펴기


팔굽혀펴기는 아무데서나 아무런 제약 없이 할 수 있는 운동이라는 장점도 있고, 이런 저런 변화를 주기 쉬운 운동이라는 장점도 있습니다. 인터넷으로 찾아보시면 다양한 방법들이 있는데요. 육각 아령과 함께 하는 방법도 있구요. 그런 도구가 없을 때에는 양쪽 다리를 들어주는 변화를 줄 수도 있습니다. 팔굽혀펴기 할 때 왼쪽 다리를 들어주면 왼쪽 가슴에 더 큰 자극이 가구요. 오른쪽 다리를 들어주면 오른쪽 가슴에 더 큰 자극이 갑니다. 단, 정자세에서 한 다리만 들어준다는 기분으로 자세를 잡고 해야 합니다. (3~4세트. 세트당 회수는 더 이상 못할 때 까지 ㅋㅋㅋ) 





4. 아령


아쉽게도, 아령 정도의 기구는 있어야 합니다. 일반적인 성인 남성에게 7kg 정도의 중량이면 충분할 것 같구요. 저 같은 경우에는 이두근 운동, 덤벨 로우를 교차 반복해서 3~4세트 (세트당 회수는 15~24회)를 하고 있습니다. 


5. 딥스


딥스용 기구를 사서 하는 방법도 있겠습니다만, 조그만 의자 두개 정도만 있으면 충분히 딥스를 하실 수 있습니다. 역시 3~4세트를 하고, 한 세트당 횟수는 15회 정도로 합니다. 


6. 크런치/리버스 크런치 


두 가지 운동 방법을 번갈아 가면서 천천히, 복근에 뻐근함이 느껴질때까지 계속 반복합니다. (횟수 무제한. 최소 40회.) 


7. 마무리 스트레칭 / 샤워


이상의 모든 운동을 신속하게 하면 30분~40분 정도 걸립니다. 마무리로 스트레칭을 해 주고 정리합니다. 이렇게 운동하는 것이 재미가 없으실 때에는 턱걸이-팔굽혀펴기-아령-딥스-크런치를 1세트로 삼고 3~4회 반복하면 재미있으실 겁니다. (그런데 더 힘듭니다 ㅎㅎㅎ) 그런 모든 운동을 한번해 해결하고 싶다는 생각이 드실 때는 버피 테스트를 해 주시는 방법도 있습니다.





어쨌거나 이런 저런 운동을 하는 데 있어서 가장 중요한 것은 꾸준함인데요. 헬스클럽에서 2시간 정도 죽치고 있을 만한 시간이 없는 사람이 하루 삼십분으로 몸을 바꾸는 데는 최소 6개월에서 1년정도는 걸립니다. 


잦은 야근으로 시간이 없더라도, 하루 30분 정도는 운동하면 오랫동안 프로그래머로서 일할 수 있는 건강을 지킬 수 있게 될 겁니다. :-)



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 전 9년 넘게 수영으로 건강을 유지 하고 있습니다.
    하지만 목과 허리쪽의 무리는 어쩔 수 없네요.
    고도의 집중을 보이는 시간이 길다면 아무리 스트레칭을 해도
    목/허리는 계속 긴장 하고 있으니 아푸네요. ㅠㅠ

    2013.10.14 11:07 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 군대에서

    하는 모든 PT동작이 운동이었다는게 놀라움이네요.
    힘들다고만 생각했지 운동이 된다고 생각을 못했으니.. ㅋ;;

    2014.01.11 05:43 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2010.11.12 11:02
모든 사람들은 기억에 의존해 살아갑니다. 모든 창조는 기억에 의존하니, 기억하지 않고는 만들 수도 없고, 개선할 수도 없습니다. 프로그래머는 프로그래밍 언어에 대한 기억, 프로젝트에 대한 기억, 아키텍처에 대한 기억, 디버깅에 대한 기억 등등 여러가지 기억들에 의지해 생활합니다.

- - -

일주일 전, 프로그래머 L을 만났습니다. 늦게 시작한 공부를 마칠때가 되어 그런지, 논문 준비에 초췌해진 모습이었습니다. 회사 일 하랴 논문 쓰랴, 까칠해진 그의 얼굴이 여전히 안스러워 보였습니다. 책상에 조용히 기대앉아 있는 그의 어깨에 손을 얹고 물었습니다.

- 괜찮아? 힘들어 보이는데...

그런데 저를 돌아보는 그의 눈빛은 어쩐지 서늘하고 허전해 보였습니다. 그는 내 손을 붙잡고 입술을 달싹였습니다. 쉽게 열리지 않는 그의 입술은, 무언가를 간절히 찾고 있는 듯 했습니다.

- 도와주세요.

뜬금없이 도와달라니. 업무를 도와달라는 뜻이 아님은, 그의 절박한 표정을 보고 미루어 짐작할 수 있었습니다. 믹스 커피를 앞에 두고, 우리는 휴게실에 마주앉았습니다. 도와달라는 말을 할 때 처럼, 그는 다시 힘겹게 운을 뗐습니다.

어제 세시쯤이었어요. 핸드폰 수리 때문에 대리점을 찾았죠. 그리고 핸드폰을 받아왔어요. 다시 깨끗해진 액정을 보면서, 즐거웠던 기억이 나요. 기분이 좋아서 매점에 들러 아이스 아메리카노를 주문했죠. 뚜껑을 닫고 빨대를 꽂으려 했는데, 마침 뚜껑이 없었어요. 괜찮겠지, 싶어서 그냥 커피를 들고 나왔죠. 빨대 없다고 커피를 마실 수 없는 건 아니잖아요. 천천히 걸었죠. 그런데 비가 왔어요. 후두둑, 갑자기 거세게 쏟아졌죠. 뛰어야 했어요. 비 냄새가 뒤섞인 커피를 마셔야 할지도 모른다고 생각하니, 어쩐지 마음이 급해졌어요. 그래서 뛰었어요. 그런데 그때, 전화벨이 울렸어요.

- 그래서?

전화를 받으려다 미끄러졌고, 넘어졌어요.

- 다친데는 없고?

눈을 떠 보니, 곁에 사람들이 서 있었어요. 저를 흔들고 있었죠. 바닥에 머리를 부딛혔나봐요. 잠깐 정신을 잃었던 거죠. 그런데, 일어나 보니 이상하게 개운한 거에요. 여태껏 그런 적이 있었나, 싶을 정도로 머리가 맑았죠. 괜찮은지 묻는 사람들에게 '멀쩡합니다' 라고 씩씩하게 말한 다음 자리로 돌아왔어요. 십분쯤 지났나, 두통이 생기더군요. 조금 쉬면 괜찮겠지 싶어 눈을 감고 하던 대로 명상을 하기 시작했어요. 그러다 까무룩 잠이 들어버렸죠.

- 그리고?

눈을 떴어요. 얼마나 잔 건지. 알 수 없었죠. 시계를 보니 네시였지만, 언제 잠이 들었던 건지는 기억나질 않았어요. 그런데 뭔가 달라졌다는 느낌이 들었어요. 무슨 느낌이었냐고요?

- 그래, 뭐가 달라졌다고 느꼈는데?

기억이 나질 않았어요.

- 기억이?

네. 기억이. 기억이 나질 않았죠. 내가 그날 무슨 일을 하고 있었는지, 무슨 일을 하게 되어 있었는지 기억이 나질 않았어요. 돌아보니, 주변의 풍경도 생경했죠. 누가 저를 찾는 목소리가 들렸어요. 이상하게 낯설어보이는 자리에서 일어나 누가 부르는 지를 찾으니, 팀장님이었어요. 그런데, 제가 아는 팀장님의 얼굴과 달랐죠. 그분이 말씀하시더군요. 'L 선임. 잠시 자리로 와서 이것좀 봐 주겠어?' 자리로 갔습니다. 어쩔 수 없었어요. 이해할 수 없는 상황이 벌어지고 있었지만, 어떻게든 아무 일 없는 척 해야 한다는 생각이 들었어요. 그래서 그 분 자리로 가서, 그분이 보라는 문서를 봤습니다. 쓴 사람 이름이 저로 되어 있더군요.

- 그 문서의 내용은 기억이 났어?

아뇨. 기억이 나질 않았습니다. 팀장님이 이것 저것 물으시는데, 바로 답변을 할 수가 없었어요. 그래서 좀 더 생각해보고 말씀드리겠다고 한 다음에, 자리로 돌아왔습니다.

- 괜찮아?

네. 괜찮습니다. 저는 멀쩡해요. 아니, 온전히 멀쩡하다고 할 수는 없겠죠. 지난 2년간의 기억 일부가 사라졌으니까요.

- 2년간? 그건 어떻게 안거지?

자리로 돌아와서 제일 먼저 한 것은 메일함을 뒤지는 것이었어요. 아시잖아요. 네트워크의 도움을 조금만 빌리면 자신이 어떤 사람인지 파악하는 것도 그다지 어렵지 않아졌죠. 이제 인터넷은 인간의 기억까지 분산시켜 저장해버리고 있으니까요. 메일함을 뒤지면, 내가 어디까지를 기억하지 못하는 건지 알 수 있으리라 생각했어요. 그래서 메일함을 가장 최근 날짜부터 옛날까지 순서대로 뒤졌죠.

- 그랬더니?

2년 전 메일에 담긴 내용은 기억이 나더군요.

- 그럼 지난 2년간 무슨 일을 했는지, 완전히 잊어버렸다는 거야?

아뇨. 그렇지는 않아요. 메일을 거꾸로 천천히 읽어 나가다 보니, 머리 속에 뭔가 그림이 떠오르기 시작하더군요. 내가 사람들과 무슨 이야기를 했고, 무슨 언쟁을 했으며, 뭘 중요하게 생각했었는지가 조금씩 생각났어요. 결국, 업무에 관한 내용은 50% 정도는 되살릴 수 있었고, 팀장님의 질문에도 답을 할 수 있었죠. 팀장님이 언제 바뀌었는지도 다시 생각났구요.

- 그럼 일시적인 기억 상실인건가?

잘 모르겠습니다. 일상적인 일들은 비교적 쉽게 다시 기억해 낼 수 있었어요. 집도 제대로 찾아갈 수 있었고, 아이들이 어떻게 컸는지도 기억할 수 있었습니다. 핸드폰에 저장된 사진, 그리고 블로그에 적어놓은 글들, 이런 것들이 도움이 됐죠. 제가 지난 2년간 관심가졌던 일들, 하고자 했던 일들, 그런 것들이 메일과 블로그, 핸드폰에 저장되어 있었어요. 그런 것들은, 주변 사람을 걱정시키지 않고도 쉽게 기억해 낼 수 있었고, 설사 기억나지 않는다고 하더라도 다시 기억해 버릴 수 있었죠.

그런데 핸드폰에 저장된 주소록에 이르니 좀 난감해지더군요.

- 무슨 문제가 있었는데?

가족을 빼곤, 주소록에 저장된 이름들이 나와 무슨 관계에 있는 것인지 도무지 기억해 낼 수가 없었어요.

- 기다리면 되지 않나?

네. 기다리면 되겠죠. 기다리면 분명 연락이 올 겁니다. 연락하게 되어 있는 사람이라면 연락을 해 오겠죠. 그런데 제가 그 사람들에게 대체 어떻게 반응해야 하나요? 죄송한데요 제가 기억을 잃었습니다. 그래서 당신이 어떤 사람인지 기억나질 않으니 조금만 힌트를 주시겠어요, 이렇게 물어야 하나요?

- 그렇긴 하군. 말하기도 그렇고, 듣는 사람도 당황스럽긴 마찬가지겠네.

갑자기 병자가 된 기분이에요. 최근까지 작업하던 논문의 내용도 기억이 잘 나질 않아서, 다시 읽어야 했어요. 그리고는 제 컴퓨터와 노트북을 이잡듯 뒤져 소스 코드를 찾았죠. 다행히 데스크탑에 SVN이 설치되어 있었고, 거기에 모든 소스코드의 최신 버전이 있어서 내가 무슨 프로그램을 만들고 있는지 알아내는 건 쉬웠어요. 그 프로그램 가운데 내가 쓰고 있던 논문에 관계된 것을 추리고 걸러내는 일이 힘들었고, 실험 데이터를 어디다 저장해 뒀는지 찾아내는 것이 어렵긴 했지만 말이에요.

- 그런데... 뭘 도와달라는 거지?

제가 지난 2년간, 어떻게 살았는지 말씀해 주세요.

그래서 저는 L에게, 그가 어떻게 살았는지 이야기해 주었습니다. 그의 생활은 단순했습니다. 일찍 출근하고, 일찍 퇴근했으며, 주말에는 아이들과 시간을 보냈다는 것. 작년에는 머리에 껌이 붙어 머리를 박박 밀어버렸었고 그 일로 모두들 재미있어 했다는 것, 프로그래밍이 아닌 일은 도통 하지 않으려 했다는 것, 정신과 치료를 받으러 다녔다는 것, 그리고 최근에는 교회에 나가기 시작했고 새벽기도를 하러 나가는 날에는 기도가 끝나자 마자 부리나케 회사 체육관으로 달려와 몸을 만들었다는 것. 덕분에 식스팩이 생겼다고 팀원들에게 자랑하기도 했다는 것. 회사 사람들에게는 약간 까칠한 인물로 알려져 있었는데 요즘은 사람이 좀 유해졌다는 소리를 듣기도 했으며, 담배를 끊겠다는 결심은 도통 지키질 못했다는 것 등등의 자질구레한 이야기들을 해 주었습니다. 최근에는 책을 쓰고 있었고, 출판사로부터 출판 제의를 받은 덕분에 내년쯤에는 책을 출간할 예정이었다는 말도 해 주었습니다. 이야기를 들으며 그는 웃기도 했고, 한숨을 쉬기도 했으며, 도통 모르겠다는 듯 고개를 저어 보이기도 했습니다.

그래서 거울로 보는 제가 낯설어 보였던 거군요.

- 그렇지, 살이 많이 빠졌으니까.

정신과에는 왜 다녔던 걸까요?

- 모르지. 업무 때문에 스트레스를 많이 받아서 잠을 못 이룬다고 한번 나에게 말을 했던 적이 었었어. 집안 문제 때문에 골치아프다는 이야기도 했었고. 이런 말 하긴 좀 뭣하지만, L씨는 고민이 많은 사람이었어.

책을 쓰고 있다는 것은 알았습니다. 윈도우즈 최근 문서 목록에 제가 쓰고 있던 한글 파일이 링크되어 있더군요. 프로그래머들에 관한 책이었어요. 재미는 없었지만, 어쨌든 출판 제의는 받았던 거로군요.

그는 한참을 말 없이 앉아 있었습니다. 나는 함께 그의 자리로 돌아가, 회사 서버에 쌓여 있는 주간 업무보고 목록을 보여주었습니다. 거기엔 지난 2년간 그가 팀에서 어떤 고민을 했는지, 매주 어떤 업무를 했는지 고스란히 기록되어 있었습니다.

- 이걸 보면 기억을 되살리는 데 도움이 좀 될거야.

우리는 함께 많은 것을 살폈습니다. 가장 큰 도움이 되었던 것은 그가 써 놓은 논문이었습니다. 거기에는 그가 지난 2년간 했던 일의 정수가 담겨져 있었습니다. 저널에 투고를 앞두고 있던 그 논문이, 박사 졸업 이외의 다른 곳에도 쓰임새가 생길 줄은, 그도 미처 예상치 못했을 것입니다. 아니, 예상했더라도 기억에서는 사라져버렸을 터이지요.

가장 문제가 되었던 것은 그가 만든 소스코드였습니다. 걱정하기 보다는 만들고 본다는 그의 모토에 걸맞게, 그의 소스 코드는 간결하고 짜임새가 있었지만 주석문이 부실하다는 문제가 있었습니다. 우리는 함께 자리에 앉아 그 모든 함수들을 하나 하나 밑바닥부터 테스트하고, 테스트 결과를 바탕으로 주석문을 만들었습니다. 그가 시스템을 설계할 당시 만들어 두었던 시퀀스 다이어그램과 인수테스트 문서는 시스템의 전체 얼개를 파악하는 데 많은 도움을 주었습니다. 최종 시스템 테스트가 끝나고 그가 쌓아올린 모든 코드에 대한 기억을 복원하는 데 까지 꼬박 일주일이 걸렸습니다. 그것도 그나마 그가 단위 테스트에는 열심히 주석을 달아 둔 덕분에 일주일이었지, 그렇지 않았다면 한달이 걸렸을 지도 모르는 일이었습니다.

그는 교회에 대한 기억도 다시 되살리고 싶어 했습니다. 그래서 우리는 그의 gmail 계정을 뒤져, 그가 facebook에 계정이 있었다는 것을 알아냈습니다. 그의 facebook 계정에는 그가 읽었던 성경귀절, 그리고 그가 했던 고민들이 몇 줄 안되는 문장이지만 고스란히 남아 있었습니다. 그가 facebook을 했던 시점이 2년이 채 안되어, 그 이전의 일들은 짐작할 수 없긴 했지만 말입니다.

- 꽤 큰 일을 치룬 것 같군.

그러자 그가 말했습니다.

그러네요. 꽤 큰 일을 해냈습니다. 선배님 아니었으면 불가능 했을 거에요. 고맙습니다.

- 고맙긴 무슨...

이 일을 하면서, 또 한가지 기억난 게 있습니다.

- 뭔데?

제가 뭔가 잊고 싶어 했다는 걸 기억해 냈어요. 뭘 잊고 싶어 했는지는 기억나지 않아요. 떠올리고 싶은 생각도 없고요. 떠올리고 싶은 일이었다면, 잊고 싶어 했을 리도 없겠죠. 제 기억 상실이 제 정신적 문제에 대한 방어기제 때문에 생긴 것인지, 아니면 신체적 충격 때문인지 알 수는 없지만, 그건 중요하지 않아요. 중요한 건 제가 기억을 잃었다는 사실이고, 이제 그 기억 중 일부는 영원히 되살릴 수 없는 어딘가로 떠나버렸다는 사실이겠죠.

우리가 그의 기억에 대해 이야기한 것은 그것이 마지막입니다. MRI며 CT며 열심히 받아본 결과 그의 머리에는 아무런 이상이 없었고, 손상된 것은 그의 기억 뿐이었습니다. 그가 마지막으로 했던 말이 떠오릅니다.

행복하다는 생각이 들어요. 이제 저에게 남은 것은 행복했던 기억들 뿐이니까요. 이것도 하나님의 은총이라면 은총이겠지요. 고맙습니다 선배. 신세 두고두고 갚겠습니다.

사람이 죽으면 망각의 강을 건넌다고 합니다. 죽어 망각의 강을 건넌다는 것에는 여러가지 의미가 있겠지만, 아마 이승에서 받은 고통의 기억으로부터 벗어난다는 의미도 있을 거에요. 돌아서는 그의 뒷모습을 보고 있자니, 저승 문턱에도 가보지 못한 그가 망각의 강에 발을 담글 수 있었던 것도 나름 행운이 아니었을까, 하는 생각이 들었습니다.

하지만 저보고 같은 경험을 하라면? 글쎄요. 제가 짠 소스코드를 남의 것처럼 느껴야 한다는 것 만큼 끔찍한 일도 아마 없으리라는 생각이 들어요.

FIN.

Amnesia (from Greek Ἀμνησία) is a condition in which memory is disturbed or lost. Memory in this context refers either to stored memories or to the process of committing something to memory. The causes of amnesia have traditionally been divided into the "organic" or the "functional". Organic causes include damage to the brain, through physical injury, neurological disease or the use of certain (generally sedative) drugs. Functional causes are psychological factors, such as mental disorder, post-traumatic stress or, in psychoanalytic terms, defense mechanisms. Amnesia may also appear as spontaneous episodes, in the case of transient global amnesia - Wikipedia
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. dhyi123

    가끔 코드를 보면서 "왜 이렇게 짠거야?!" 하며 작성자 욕하다가 로그를 보고 "아~ 이거 내가 옛날에 짠거구나" 이럴 때도 있죠.

    2010.11.16 07:28 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 나상실

    이거 실화인가요? 재밌어서 소설같은 느낌으로 읽었네요

    2010.12.01 00:50 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 재미있게 읽었습니다. 정말 많이 공감도 되네요~

    저는 거의 10년 동안 HDD 를 날린 적이 딱 한번 있었는데, 그래서 약 한달의 제 기억을 빼고는 다 저장하고 있습니다 ㅋㅋ 한번씩 어디선가 발견되는 10년 전의 문서를 보면 재미있습니다. 동기들의 사진 스캔이라던지, 고전 게임이라던지, mp3 라던지 ㅎㅎ

    2010.12.18 23:41 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2010.08.02 17:49
인사이트에서 "프로그래머의 길, 멘토에게 묻다"라는 제목의 신간이 나왔습니다.

프로그래밍을 처음 할 때에는 잘 몰랐습니다만, 어느 분야에서 전문가가 되려고 맘을 먹은 사람이라면 가장 중요하게 따져봐야 할 덕목중에 하나로 '소통'이라는 것이 있더군요. 간단하게 이야기하면, 우물안 개구리처럼 자기 코드만 들여다 봐서는 절대로 전문가가 될수 없다, 뭐 그정도로 요약할 수 있겠습니다.

그래서 많은 프로그래머들이 직간접적으로 어떤 커뮤니티에 소속되어, 많은 다른 프로그래머들의 이야기를 듣습니다. 시스템 설치시 발생하는 오류에 대한 대처법에서부터 버그 교정법, 그리고 더 나은 프로그램을 만드는 데 필요한 많은 지식들이 이런 커뮤니티를 통해 오고가죠.

저희 회사에서도 그랬습니다만, '사수'라는 제도가 있었습니다. 이 제도를 요즘 유행하는 다른 말로 이름지어 부른다면 '코치'나 '멘토'쯤 되겠죠. 옆에 좋은 멘토가 있으면 (그 멘토의 말을 귀담아 들을 자세가 되어 있다는 가정 하에서) 실력이 느는 속도가 적어도 배는 빨라집니다.

언어를 혼자서 배울 수는 있겠지만, 전문가들과 교류하지 않으면 그 언어의 진수를 깨우치는 데 오랜 시간이 걸리게 됩니다. - 68페이지


이런 이야기를 해 줄 사람이 주변에 많으면 좋은데, 안타깝게도 프로그래머들은 독립적인 성향이 강해서 그런 이야기를 외면하거나, 외면하지 않더라도 주의깊게 귀를 기울이는 일은 드물죠. 듣더라도 실천에 옮기는 경우는 더더욱 드물고요.

이 책에는 프로그래밍 언어에 관한 교훈 뿐 아니라, 다른 교훈도 풍성합니다. 여태껏 단 한번도 멘토를 가져본 적이 없거나, 멘토의 말에 귀를 기울여 본 적이 없는 사람이라면 읽어볼 만한 이야기들이 많다는 뜻이죠. 제가 말로 주구장창 이야기해봐야 감은 잘 안오실 터이고, 몇 가지 인상적인 대목을 추려보겠습니다.

겸손은 성공적인 견습과정의 토대 중 하나다. 야망과 결합될 때, 겸손은 당신을 집중하게 해주며 올바른 방향으로 전진할 수 있게 해 준다. 겸손함이 없다면 견습과정이 끝났다는 판단을 성급하게 내릴 여지가 있으며, 소중한 교훈을 일부 놓칠 수 있다. - 178페이지


소프트웨어를 만들면서 우리는 업무 중에 연습을 하는데, 그것이 업무 중에 실수를 하게 되는 원인이다. 우리는 직업적인 일과 연습을 구분할 방법을 모색해야 한다. 우리에게는 연습 시간이 필요하다. - 190페이지


실패는 불가피한 것이다. 그것은 늦든 이르든 간에 모든 이에게 일어난다. 사실 무언가를 한 번도 실패해 본 적이 없는 사람이라면, 그는 자기 능력의 한계치까지 밀어붙이기를 피해 왔거나 자기 실수를 대수롭지 않게 여기도록 배운 사람이다. - 225페이지


동시성의 다양한 형태(및 그 한계)에 대해서 아는 것이, 'subclass Thread나 implement Runnable'보다 더 유용한 지식이다. - 244페이지


정말 어려운 일은 도구상자의 많은 부분을 버려야 할 때 생긴다. 가끔 당신의 도구들은 구식이 되어 버리기도 하고, 더 좋은 대체품이 나타나기도 할 것이다. 드물게는 당신이 '최첨단'에 대해 정통한 결과, 전에 알던 도구를 소용없게 만들어버리는 무언가를 발명하게 될 수도 있을 것이다. - 253페이지


같은 식으로, 이 책에 실린 패턴과 아이디어 중 많은 부분은 갈등과 저항을 불러올 것이다. 이것은 어느 정도는 현재 상황으로 이득을 보는 사람들, 상황이 개선됐을 때 뭔가 잃을 것을 두려워하는 사람들이 늘 있기 때문이다. - 262페이지


신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. dmoons.kim

    좋은 책 소개 감사합니다... 꼭 한번 읽어봐야겠네요

    2010.08.03 14:44 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. duru

    서평 감사허유,,,,
    에고,, 지는 왜 만년 부사수일까유,,,흐윽,,,

    2010.08.04 14:10 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2010.08.01 18:33
내가 컴퓨터를 처음 접한건 국민(초등)학생일 때 였다. 만화책처럼 묶인 베이직 프로그래밍 입문서를 우연히 구해 읽었는데, 그 뒤로 8비트 컴퓨터를 사 달라고 아버지께 조르고 졸랐다. 결국 내가 처음으로 쓰게 된 컴퓨터는 IQ-1000이라고 불리던 MSX 호환 컴퓨터. 메인보드와 키보드가 일체형이었고, 오래 쓰면 뜨끈뜨끈해져 사람을 불안하게 만들던 컴퓨터였다. 

내가 그 컴퓨터로 할 수 있는 것은 고작해야 IF-ELSE를 사용한 간단한 프로그램을 만드는 것이었다. 뭔가 심각한 일을 할 수 있으려면 디스크 드라이브를 사용해야 할 것 같다는 감은 왔지만 MSX에서 당시 1.4인치 디스크드라이브는 70만원 가까이 하던 고가의 물건이었던 터라, 감히 사달라는 말은 할 수 없었다. 대용품으로 구할 수 있던 것은 그나마 저렴했던 quick-drive. 3.5인치의 디스켓을 사용했던 이 드라이브는 random access가 불가능한 미디어라 고속의 테이프와 다를 것이 없었다. 그래서 목록의 가운데에 있는 파일을 지우려면 마지막 파일부터 순서대로 거꾸로 지워 나가는 삽질을 해야 했다.

아버지는 컴퓨터 교육을 받은 1세대의 직장인이었다. EDPS같은 용어를 교육받은 첫 번째 직장인이었다는 뜻. 그래서 아버지는 내가 짠 프로그램이 무슨 일을 하는 프로그램인지 어깨 너머로 보고도 대충 짐작하실 수 있었다. 밤새워 게임 소스코드를 입력하고는 디버깅을 하지 못해 쩔쩔매는 나를 보고 아버지가 무슨 생각을 하셨을지 알 수는 없지만, 그저 뭔가에 몰두하는 모습을 보고 대견해 하셨던 기억은 난다.

지금도 조금은 그런 편이지만, 나는 그 때 친구들이 전혀 이해하지 못할 책을 들고 다니면서 뻐기는 것을 즐기는, 유치한 자부심에 사로잡혀 있는 소년이었다. 어셈블리 소스 코드가 가득한 책을 들고 다니면서 쉬는 시간마다 책장을 넘기며, 마치 그 모두를 아주 잘 알고 있다는 표정을 짓는 것이 낙이었다. 물론, 90% 정도는 모르는 내용이었다. 

디스크 드라이브가 아쉬워서 애플 IIe 컴퓨터를 사달라고 어머니를 조르기 시작했는데, 아버지께서 하셨던 말씀이 지금도 기억이 난다.

"아빠가 필요해서 그러는데... 명함 관리 프로그램 하나만 짜 줄 수 있겠니?"

아버지는 내가 컴퓨터로 하는 일이 고작해야 게임 프로그램을 입력하고, 게임을 하고, 간단한 베이직 프로그램을 짜고, 친구들을 불러 자랑하는 것이 전부라는 사실을 잘 알고 계셨으리라 믿는다. 아버지는 그 한 마디 말로 나를 꼼짝못하게 하셨다. (한 마디 말로 사람을 꼼짝 못하게 하는 것은 아버지의 장기 중 하나였다.)

그 뒤로 내가 한 일은, 베이직으로 명함 관리 프로그램을 짜는 것이었다. 물론 완벽한 프로그램을 만들어 내지는 못했다. 하지만 적어도 데이터를 저장하고 불러온다는 것이 어떤 의미인지는 이해하게 되었다. 

내가 그 프로그램을 이리저리 매만지며 고민에 고민을 거듭하는 날이 한달 가까이 되었을 때, 나는 애플 IIe 컴퓨터를 손에 넣을 수 있었다. 물론 아버지의 선심 덕분이었다. 



애플의 주변기기가 상대적으로 저렴했던 탓에 싼 값에 플로피 드라이브를 가질 수 있게 되었지만, 그 뒤로 내가 컴퓨터를 사용하는 패턴이 극적으로 달라진 것은 아니었다. 나는 여전히 프로그래밍 보다 게임을 더 즐기는 소년이었고, 생산적이기 보다는 소비적으로 컴퓨터를 사용했다. 내게 컴퓨터는 그저 남의 집에는 없는 신기한 물건일 따름이었다.

그리고 중3이 되었을 때 쯤에는 컴퓨터에는 완전히 흥미를 잃었다. 그것 말고도 해야 할 일이 산더미처럼 늘어가기 시작했으니까. 가파르게 기울던 가세도 한 몫을 했다. 지금 생각해 보면, 어쩌다 프로그래머가 되었는지 신기할 뿐이다.

그 시절의 나는 분명히 프로그래머는 아니었다. 그저 재미삼아 컴퓨터를 만지는, 또래의 아이들 보다 조금 더 운이 좋았던 소년일 뿐이었다. 남들보다 조금 불편한 몸을 가졌다는 사실 때문에 자식이 하고 싶은 거라면 무엇이든 들어주려고 애쓰셨던 부모님이 아니었다면, 나는 그런 운을 결코 누릴 수 없었을 것이다. 

가끔 키보드를 두들기며 뭔가를 만들어 내려고 애쓰는 나 자신을 보고 있노라면, 그 위로 아버지의 모습이 오버랩되는 것을 느낀다. 내가 썼던 컴퓨터들은 내가 아버지로부터 받았던 최고의 선물들 중 하나였고, 그 선물들은 결국 내 인생의 방향을 결정했다. 가끔은 궁금하다. 아버지도 내가 컴퓨터를 처음 보았을 때 느꼈던 감정을 똑같이 느끼셨었을까? 

폴 오스터의 책 제목도 그렇듯, 인생은 우연이 만들어 내는 음악과도 같다. 프로그래밍도 마찬가지다. 불확실성으로 가득한 초기 단계에서 내린 많은 결정들이 이리 부딛히고 저리 부딛히며 어떤 결과를 만들어 낸다. 우리는 그 과정을 최대한 합리적으로 컨트롤하려고 애쓰지만, 인간이 하는 일에 우연이 끼어드는 것을 완벽히 통제하는 것이 애초에 가능하기나 하던가. 

그렇게 따진다면, 아버지는 내 인생의 프로그래머나 다름 없다. 내 인생이라는 랜덤 함수에 최초의 seed를 뿌린 프로그래머. 아버지는 자신이 빚어낸 결과물을 보고 기꺼워하고 계실까?

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 요즘은 프로그래밍하기가 너무 어려워진게 아닌가 싶습니다.

    개발 도구는 발전하였으나 실제로 쓰기 위해서 준비할 것이 너무 많고 복잡합니다.

    저시절 MSX는 전원만 올리고 바로 베이직 코딩 들어갈 수 있어서 배우는 입장에서 참 좋았습니다.

    2010.08.02 09:16 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2010.03.19 11:00
[이전 글에서 계속...]

아무려나, 회식은 그렇게 마무리되었습니다. 노래방을 나선 모두는 조용히 집으로 향했습니다. 새벽 한시쯤인가, 술에 혀가 꼬부라진 허동수가 전화를 해서 '아직도 술 마시고 있는거냐'고 물은 것을 빼고는, 괜찮은 마무리였습니다. 물론 다음날 회의실에 모여앉은 사람들 가운데 한 두 명 정도는 그때까지도 불콰한 표정이긴 했지만요.

그리고 그때부터 쭈욱, 우리는 프로젝트의 방향을 잡고 개발 일정을 정하고 구체적인 개발 방법을 만들어 가는 일에 몰두했습니다. 한 번도 해 본 적이 없는 프로젝트라는 점이 걸리긴 했습니다만, 그렇다고 해서 손 놓고 누군가 완벽한 요구사항 목록을 던져주기를 기다릴 수는 없었습니다. 우리가 만들 시스템의 사용자가 누구며 그들이 무엇을 원할 것인지를 추정해야 했습니다. 그리고 그 결과를 놓고 갑과 토론을 해야만 했습니다.

"OLYMPUS의 사용자는 과연 어떤 사람들일까요?"

팀장이 질문을 던지자 제 머리 속에는 오만가지 생각들이 스쳐갔습니다.

"신전의 사용자는 신들이 아닐까요?"

뜬금없는 제 대답에 박팀장은 웃음을 터뜨렸습니다.

"그렇긴 해요. 가끔 사용자는 우리가 만들 시스템에 신적인 권능을 요구하기도 하죠. 그런 의미에서 보면 사용자는 모두 신들과 같다고 비유해도 무리는 아닐 것 같네요."

그 말에 남기수는 사뭇 진지한 표정으로 이렇게 대꾸했습니다.

"물론 그렇습니다만... 우선은 그들이 '어떤 신'들인지 범위는 좁혀 두어야 겠죠."

램은 '솔라리스'라는 소설에서 세상에 대한 호기심으로 가득찬, 마치 어린아이와 같은 신에 대해 언급한 적이 있습니다. 자신이 가지고 노는 존재들이 무엇인지 알기 위해 이런 저런 시도들을 하지만, 정작 그 결과로 장난감들이 어떻게 망가질 지에 대해서는 알지 못하고 관심도 없는 그런 신 말이에요. 우리가 모셔야 하는 신들이 그러하다면 과연 우리는 어떻게 대처해야 하는 걸까요?

"우선 우리 시스템이 플랫폼적인 성격을 가지고 있으니까, 개발자를 주요 타겟으로 보아야 할 것 같은데요. 플랫폼을 이용해서 네트워크 관리 시스템을 개발할 사람들 말입니다."

유식이 말했습니다. 그러자 팀장이 화이트보드에 그림을 그리기 시작했습니다.

"그러니까 여기 플랫폼이 있고... 그 위에 이렇게 개발자가 있다 이 말이군요."

팀장은 UML의 액터(actor) 기호를 그려넣고는, 그 아래에 '개발자'라고 큼지막하게 적었습니다. 그 아래에는 우리가 만들 플랫폼의 경계가 사각형으로 그려져 있었습니다. 그 안을 채우는 것은, 우리가 할 일이었습니다. 그러자 남기수가 나섰습니다.

"그럼 롤 플레이(role-play)를 한번 해 보는 것은 어떨까요?"

"롤 플레이요?"

"가상의 개발자를 한 명 두고, 그 사람이 우리 시스템을 실제로 어떤 식으로 사용할 것이며 어떤 기능을 요구할 지 역할극을 한 번 해 보자는 것이죠."

그러자 허동수가 말했습니다.

"재미있겠네예."

그러자 남기수가 웃으며 대답했습니다.

"재미있을지는 저도 장담할 수 없습니다만... 적어도 그런 페르소나(Persona)를 만들어 놓고 이야기를 하다 보면, 우리가 상대할 사용자를 좀 더 잘 이해할 수 있을 것 같긴 합니다. 그런 의미에서, 그 사용자에게 이름을 붙여 보는 것은 어떨까요?"

"이름이요?"

박팀장이 물었습니다. 그러자 유식이 말했습니다.

"좋은 생각이네요. 계속 사용자 사용자 사용자 이렇게 부르는 것 보다는, 이름이 있으면 이야기하기 좀 더 편하겠죠. 어떤 이름이 좋을까요?"

모두들 이런 저런 이름들을 내 놓았습니다. 저도 하나를 제안했습니다.

"제우스가 어떨까요?"

"제우스요?"

"네. 그리스 로마 신화에 등장하는 신들의 수장이기도 하고, 가장 제멋대로인 신이기도 하죠. '사용자는 제멋대로다'라는 개발자 사이의 통념에 비추어 본다면 가장 잘 어울릴 이름일 것 같기도 합니다만...'

그 말에 모두들 너털웃음을 터뜨렸습니다.

"제우스라. 거창하긴 하지만 발음하기도 편하고, 괜찮은 이름이군요. 다른 분들 생각은 어떠세요?"

"좋습니다."

결국, 우리의 사용자는 제우스라는 이름을 갖게 되었습니다. 팀장은 화이트보드에 적인 '개발자'라는 단어를 지우고, 그 자리에 '제우스'를 큼지막하게 써 넣었습니다.

"자. 그럼 지금부터 제우스씨가 우리에게 무슨 이야기를 하는 지 들어보도록 하죠."

[다음 글에 계속...]
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Extremely Agile/General2009.01.21 23:51
보통 프로그래머들에게는 한가지씩의 무용담이 있습니다. 그 중 가장 흔한 것이 바로 "내가 만났던 가장 개같은 버그" 류의 무용담입니다.

이런 이야기는 왜 하는 것일까요? 뭐 다들 잘 아시겠습니다만, (1) 이런 무용담이 많으면 어디가서 분위기를 띄우기 좋고 (2) 자기가 경력이 꽤 된다는 걸 간단하게 입증해 보여줄 수 있으며 (3) 다른 프로그래머에게 유용한 정보를 전해줄 수 있다는 장점이 있습니다. 물론 이런 이야기는 '군대에서 축구한 이야기'랑 비슷하기 때문에, 프로그래머들이 둘 이상만 모이면 저절로 튀어나오게 되는 경향도 있긴 합니다. ^^;

프로그래밍 심리학이라는 책에도 나옵니다만, 천공 카드를 통해 프로그래밍을 했던 중세시대에도(ㅋㅋ) 소위 '개발자 커뮤니티'라는 것이 있었습니다. 천공 카드를 컴퓨터에 입력하려면 순번을 기다려야 하니까, 기다리면서 노가리들을 깠던 것이죠. 인터넷이 없었으니 당연했겠죠? 그 시대의 개발자들은 아마 지금 개발자들에 비해 백배는 수다스러웠을 겁니다.

각설하고... 그런데 버그에 관한 그런 무용담들을 들어보면, 보통 '버그를 잡았다'에서 스토리가 끝나버려요. 그 뒤의 이야기들은 좀체로 하질 않습니다. 오늘도 커피를 마시러 휴게실로 가다가 같이 일하는 분들하고 잠시 이야기를 할 기회가 있었는데요. 개발자를 한달간 애먹인 버그에 대해서 들려주시더군요. 관련된 모든 사람들의 영혼을 한달동안이나 잠식했던, 정말 가공할만한 버그였습니다. (가장 큰 문제는 그 버그가 그분들이 개발한 시스템에서 나온게 아니라는 점이었죠.) 듣는 제가 다 소름돋을 정도였으니....

보통은 거기까지 듣고 마는데, 오늘은 제가 이런 질문을 한번 해봤습니다.

"그런 버그를 한 번 겪고 나면 본인이 어떻게 달라졌다고 느끼나요?"

질문을 좀 뜨악하게 들으시는 것 같아서 좀 다르게 물어봤습니다.

"그런 버그가 (프로그래머로서의) 자신의 인생을 바꿔 놓았다고 느낄 때가 있나요?"

생뚱맞게 들리실수도 있겠습니다만, 저는 이런 질문을 한번쯤은 던져 보아야 하지 않나 합니다. 제가 이 직장에 처음 들어왔을때 처음 맞닥뜨린 가장 심각했던 'UNDETERMINISTIC' 버그[각주:1]는 시그널 핸들링 관한 것이었습니다. 시스템이 죽긴 죽는데, 진짜 어쩌다 한번 죽는 겁니다. 그리고 그 상황 사이의 일관성을 찾기가 정말 힘들었어요.

이 문제의 해결책을 찾기 위해 정말 많은 삽질을 했습니다. (지금 생각하면 삽질이 아니라 당연하게 해야 하는 일들이지만요.) 첫 번째로 했던 일은 메모리 누수가 시스템의 crash로 이어지는 시점을 정확하게 동기화시키기 위해 MALLOC_CHECK_ 환경 변수의 값을 설정하는 것이었습니다. (Linux라면 man malloc하시면 관련 자료가 나올 겁니다.) 처음에는 시스템이 죽는 이유가 메모리 누수 때문이 아니었을까 하고 추측했거든요. (그당시에는 valgrind에 대해서 몰랐습니다.)

물론 그래도 문제가 해결이 안되었습니다. 한달 뒤에야 겨우 문제의 실마리를 찾을 수 있었죠. (쪽팔립니다ㅎㅎ) 문제인즉슨 이런거였습니다. write를 할 때 리턴 값으로 '파이프가 깨졌다'는 오류 메시지를 받을 수 있을 것으로 기대했었는데 (write를 하는 중에 서버가 죽을 경우를 대비하려던 거였죠) 문제는 그게 SIGPIPE 시그널을 block 하지 않으면 제대로 동작하지 않고 프로세스가 죽는다는 거였습니다. (그것도 꼭 항상 죽는건 아니었죠. ㅋㅋ)

이 문제의 교훈은 이런 거였습니다. 매뉴얼에 의존해서 그대로 몇 줄 코드를 구현했습니다. ('상대 프로세스가 죽을 경우 내 프로세스는 파이프가 깨졌다는 오류 메시지를 받는다'는 것이 매뉴얼 내용이었습니다.) 그런데 그 코드가 정말로 제대로 동작하는지는 확인을 하지 않았던 겁니다. '몇 줄'에 불과하고, '매뉴얼 대로' 구현했기 때문에, 거기 버그가 숨어들어갈 거라고는 생각을 못했던 것이죠.

이 문제를 '기계적'으로 해결하려면, 작은 수정을 가할 때 마다 그 수정이 정말로 올바른지 확인을 하고 넘어가야 했습니다. TDD 수준으로 보폭을 좁게 가져가는 것이 필요하다는 결론을 그 때 얻은 거죠. 이 결론을 실천해 볼 기회는 2년 뒤에 찾아왔습니다. 일단 모든 코드의 구현을 마친 뒤 (테스트 과정에서 설계가 변경될 수 있다는 가정은 일단 배재했기 때문에 그럴 수 있었습니다. 코드에 확신이 있기도 했고, 사실 무식할 때 가장 용감해지는 법이니까요), 시스템의 아주 작은 부분부터 차례로 테스트를 해 나기가 시작했습니다. 테스트를 마친 코드만을 조금씩 시스템에 포함시켜서 빌드를 해 나가기 시작했고, 그 부분이 제대로 시험되었다는 확신이 들 때메만 다음 코드로 넘어갔습니다. 이런 식으로 해서 결국 연동시험 때 발견된 버그 수를 0으로 낮출 수 있었습니다. 테스트에 CppUnit을 도입한 것, TDD를 공부한 것, '한 걸음을 뗄 때 마다 뒤돌아보기'에 대한 확신이 생긴 것 등이 그 시기에 했고 느꼈던 것들입니다. (지금 생각하면 '책 한 권만 잘 읽었어도 더 잘 할 수 있었을텐데' 하긴 합니다만.)

결국, '그 자그마한 버그 하나'가 저를 바꿔놓은 것이죠. 이 블로그도 그 덕에 생겼습니다. ^^;

많은 개발자들이 Continuous Integration이나 Issue Tracking의 필요성에 대해 공감은 하면서도 실제 도입을 망설이는 이면에는 '버그는 부끄러운 것'이라는 개발자적 자존심이 어느 정도 깔려 있다고 저는 생각합니다. 그런 부분을 해소할 수 있으려면, 버그 자체도 지식으로 대우하는 자세가 필요합니다. Bug Tracking이라는 말 대신 Issue Tracking이라는 다소 점잖은 용어가 널리 쓰이는 것도, 어쩌면 그래서일지도 모르겠어요.

버그가 나를 더 좋은 곳으로 데려갈 수 있다는 확신을 가지는 것은, 그런 의미에서 중요하다고 생각합니다. 여러분도 저처럼, '나를 바꾼 버그'를 하나씩 가지고 계신가요?

  1. reproduce하기 굉장히 난감한, 발현 시점을 도무지 정확히 알 수 없는 버그. [본문으로]
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 공감하고 갑니다. ^^

    2009.01.29 02:40 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 아. 안녕하세요? 제가 블로그 첨 열었을 때 A2님 블로그에서 X-note에 리눅스 설치하는 방법을 참고했던 기억이 나네요. 새해 복은 많이 받으셨는지? 올해도 건승하시길~

      2009.01.29 09:11 신고 [ ADDR : EDIT/ DEL ]
  2. 정말 공감가는 글입니다. 저는 아직 인생까지 걸어보진 못했지만 잡아내는 버그 한두개로 소프트웨어 자체를 fail 시켜야 한다는 점에서는 거의 매일 누구에겐가는 운명적인(?) 버그를 잡아낸다고 해야하나요. 하지만 더 열심히 한다면 언젠가는 저도 제 인생을 바꿀만한 버그를 잡아내는 날이 오겠죠? ^^; 어쨌든 이젠 돌다리를 두들겨만보고 건너는 버릇은 아예 없앴습니다. 뛰어보고 엎어보고 발로 차보고 긁어보고 맛도 본 후에나 건너게 되더군요.

    2009.03.26 13:00 신고 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/TDD2008.10.21 13:53
TDD를 배우고 실무에 적용해보고 나면, 프로그래머는 대략 다음 두 가지 중 하나의 유형으로 바뀝니다.

1. TDD를 굉장히 열정적으로 사용하는 프로그래머
2. 테스트의 필요성을 절감하고 테스트 케이스를 작성하긴 하는데, 그렇게 TDD를 열심히 하지는 않는 프로그래머

저는 이 중 어느쪽이냐 하면, 후자 쪽입니다. 아직 TDD에 확실히 익숙해지지 않아서 그럴 겁니다. 물론, 자기가 작성하는 코드에 대한 자신감이 높은 프로그래머도 두번째 유형에 속할 가능성이 높습니다. 이런 프로그래머는 TDD는 너무 오버헤드가 높은 방법이라고 느끼는 경향이 있습니다.

사용자 삽입 이미지

http://www.nilkanth.com/archives/2007/06/08/three-monkeys-of-test-driven-development/


그런데 두 번째 유형의 프로그래머들이 흔히 빠지는 함정이 하나 있습니다. 블랙박스 테스트(blackbox test)를 하게 될 가능성이죠.

보통 프로그램을 클래스 단위로 구분해서 작성하게 되면, 최소한 클래스가 하나 만들어 질 때 마다 테스트 케이스들을 만들도록 하는 것이 좋습니다. 그런데 프로그래머에 따라서는 클래스가 아니라, 모듈이 하나씩 만들어 질 때마다 테스트 케이스들을 작성하기도 합니다.

그렇게 하면 보통 모듈에 속한 모든 클래스들에 대해 테스트 케이스를 작성하기는 어려워집니다. 정말로 어려워서 어렵다는 것이 아니라 귀찮아서 생략할 가능성이 높아지기 때문에 어렵다고 하는 것이죠. 그렇게 되면 모듈의 관리자 클래스(Manager class)에 대한 테스트 케이스들만 만들어지게 됩니다. 모듈의 인터페이스에 대한 테스트 케이스만 만들어지게 된다는 것이죠.

결국 모듈이 블랙 박스가 됩니다.

블랙 박스 테스트가 의미가 없다는 뜻은 아닙니다. 하지만 추상화 단계의 위쪽으로 올라가 테스트를 하게 되면, 거기서 처리해야 할 테스트의 가짓수가 늘어나게 됩니다. 그 모든 경우를 다 따져 테스트 케이스를 작성하면 좋겠지만, 그렇게 못할 가능성이 높습니다.

결정적으로, 블랙 박스 테스트로는 "모듈의 어느 부분에서" 오류가 발생했는지를 감지하기가 어렵다는 문제도 있습니다. 그렇기 때문에 가급적 코드의 가장 작은 단위에 대해서부터 단위 테스트를 진행하는 것이 좋다는 것이죠.

TDD를 하지 않더라도 그렇게 하면 적어도 버그의 수를 줄이는 데는 도움이 되는 것을 경험했습니다. 거기다 부수적인 이득도 얻을 수 있는데, "테스트가 쉬운 코드를 만든다"는 목적은 그대로 유지할 수 있다는 겁니다. 물론 "테스트 코드를 통해 실제 코드의 디자인이 결정되는" 신기한 경험은 할 수 없겠지만 말이죠.
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Extremely Agile/General2008.02.29 12:11
뻔한 이야기가 되겠습니다만, 프로그래머도 다른 직장인과 다를 것이 없는 사람입니다. 휴식이 필요한 존재죠. 하지만 프로그래머들은 잘 쉬질 못합니다. 특히, 잘 가다듬어진 프로젝트 환경이나 업무환경을 가지지 못한 상태에서 일하는 프로그래머들은 더더욱 그렇습니다. 거기다가, 어떤 프로그래머들은 스스로 휴식을 거부하는 경향을 보이기도 합니다. 이런 증상을 보통은 업무 중독증이라고 부르기도 하죠.

지난 한주 괌 PIC에 다녀왔습니다. 가끔 가까운 데 아이들을 데리고 놀러갔다 올 때는 있었습니다만, 제 돈을 주고 이렇게 오랫동안 쉬어본 것은 처음입니다. 그래서 그런지, 사박오일동안 많은 생각이 들더군요.

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지

제가 프로그래머로서 코드를 잡고 일을 한 지가 벌써 십수년 가량이 흘렀습니다. 그 동안, 저는 의식적으로 휴식을 회피하면서 살았습니다. 거기에는 제가 하는 일의 성격이 한 몫을 했습니다. 사실 프로그래머라는 사람들은 컴퓨터가 놓인 자리에 앉아 하루의 대부분을 보내죠. 단기적으로 보면, 대단한 육체적 강인성을 요구하는 직업도 아닌데다, 손가락 놀릴 힘만 있으면 그다지 큰 피로감없이 하루 종일을 컴퓨터 앞에서 보낼 수도 있습니다. 생각해 보니까, 저도 최근 한 십년 가량은 거의 그런 상태로 살았던 것 같습니다.

예전에 마이크로소프트웨어라는 잡지를 구독했던 적이 있는데요. 초창기 기사중에 프로그래머의 책상 위 풍경을 묘사한 대목이 있었습니다. 아무렇게나 구겨져 뎐져 있는 서류 뭉치, 필요할 때면 아무때나 손을 뻗어 마실 수 있는 음료수, 키보드, 마우스, 매뉴얼, 그리고 플로피 디스크들... 사실 지금도 대부분의 프로그래머들은 이런 책상 앞에서 일을 하고 있을 겁니다. 프로그래머들의 생활 패턴이라는 것이 그다지 많이 바뀌지 않았으니까요. 프로그래밍이라는 것이 갖는 창의적인 속성이 큰 만큼, 그 앞에서 시간을 보내는 것이 가장 재미있는 일이라는 생각을 가지고 있는 프로그래머들이 많습니다. 그리고 그렇게 시간을 보내다 보면 책상은 여지없이 어지러워지고 말지요.

그런데 이런 생활을 오랫동안 하다 보면, 프로그래밍 이외의 다른 모든 활동들에 대한 자신의 태도가 좀 이상하게 바뀌게 된다는 문제가 있습니다. 가령 일을 하다가 하루 쉬어도 되는 날이 생겼다고 칩시다. 그런데 그 쉬는 날이 어쩐지 영 탐탁치 않게 느껴진다는 겁니다. 안그래도 업무가 바쁜데, 하루를 쉬면 그 업무를 좀 더 빨리 처리할 수 있을 시간을 날려버리게 되는 것 같이 느껴지는 것이죠. 그러다 보면, 다른 사람들이 전부 휴가를 내고 자리를 비웠다 할지라도, 회사에 나와 업무를 보게 되는 일이 많아집니다. 팀원 중에 누군가가 하루 같이 시간을 내서 어디 바람이라도 쐬러 가자고 하면, "이렇게 바쁜데 놀자니, 제정신인가?"하는 마음이 들어 기분이 좋지가 않죠. 어쩐지 그 사람은 팀 전체 생산성에 악영향을 주는 사람 같이 느껴지기도 합니다.

이 이야기는 제 이야기이기도 합니다. 저는 이런 생활을 십여년 동안 하면서, 단 한 번도 제 자신이 '소비되고 있다'는 생각을 한 적이 없습니다. 아마 거기에는 '하루라도 빨리 돈을 벌어야 한다'는 식의 경제적 강박관념과, '이렇게 놀고 있어서는 분명 뒤쳐질 것이다'라는 불안감도 한 몫을 했을 것입니다. 하지만 이제 37세가 된 제 자신을 돌아보면, 저는 분명 제 자신을 조금씩 갉아먹었던 것 같습니다. 체중은 조금씩 늘었고, 머리는 희끗희끗해지기 시작했으며, 젊은 나이에 녹내장을 앓고 있고, 속이 좋지 않아서 탄산음료나 차가운 물은 거의 엄두도 내질 못합니다. 그리고 건강 문제는 제쳐두고라도, 저는 그렇게 살아온 시간 동안 스스로 기꺼워할만한 멋진 업적 하나도 만들어 내질 못했습니다.

진부한 이야기일지 모르지만, 휴식은 재충전의 기회입니다. 인간에게도 충전지와 비슷한 구석이 있어서, 재충전이 없이는 이전 수준으로 생산성을 되돌리는 일이 불가능 할 때가 생깁니다. 잠을 자지 않고서도 위대한 업적을 만들어 낼 수 있겠지만, 그런 상태는 오래 지속될 수 없습니다. 거기다, 쉬지 않는 사람은 나중에 감당하기 어려울 정도로 큰 문제를 만들어 내기도 합니다. 술을 마신 상태에서 만든 코드가 나중에 너덜너덜해지는 것과 비슷한 이치죠.

휴식은 어떻게 보면 "나는 내 자신에게 얼마나 관대한가"의 지표이기도 합니다. 자신에게 관대하지 않은 사람은, 타인에게도 관대할 수 없습니다. 타인에게 관대하지 않은 사람은 종종 팀웍을 해치고, 그런 사람들은 자신도 모르는 사이에 팀 전반의 퍼포먼스를 떨어뜨리기도 합니다. 저는 지난 사박오일간, 지난 십년간 제가 제 자신에게 얼마나 무자비했던가를 깨달았습니다. 앞으로 프로그래머로 일할 날이 몇 년이나 더 남아있을지는 알 수 없습니다만, 앞으로는 제 자신에게 좀 더 관대해 져야 할 것 같습니다.

다만, 코드에게까지 필요 이상으로 관대해질 필요는 없겠죠.
자신에게는 관대하게, 그리고 코드에게는 냉철하게.


신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 맞습니다. 충분한 휴식은 더 좋은 코드를 생산해 낼 수 있는 원동력이지요. ^^

    2008.02.29 12:44 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 전 몇 시간 코딩을 하다가 만나는 문제는
    몇 시간 더 투자하여 머리를 싸는 것보다는
    잠시 휴식을 취하거나 잠을 자고 다음 날 풀어보면 깔끔하게 풀리더군요.
    거기에 그 때 실수한 것들을 찾아내고 최적화까지...;;;;
    하지만 저도 '조금만 더 하면 되겠는데....', '쉬는 것보다는 나아가는 것이 더 좋잖아.'라는 강박감이 있습니다.OTL..

    2008.02.29 14:38 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. morison

    휴식.. 정말 중요하죠...
    그런의미에서 이런글도 좋지만
    괌의 멋진 풍경 사진이라도 한번 올려주셔 보시죠^^

    2008.02.29 17:35 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. 저도 휴식이 참 중요하다는걸 새삼 느끼고 있답니다...
    (아직 학생이긴 하지만..)
    이제는 코딩이 잘 안된다는 생각이 들면 딱 접어야겠습니다.
    다음날 아침에 맑은 정신으로 다시 오는 것이 좋습니다.
    또한 밤늦게까지(또는 밤새는거) 예전부터 너무 싫어했고요.
    (하지만 함께 해야 될때는 올빼미 스타일의 사람들이 너무 많아서 저 너무 괴로워요 ㅠㅠ)

    2008.02.29 22:19 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그러게요~ 같이 일하는 사람들 스타일이 다르면
      어쩔수 없이 따라가야 하는 일도 생기죠.

      2008.03.01 08:23 신고 [ ADDR : EDIT/ DEL ]
  5. 아이의 웃는 모습을 보니 괜시리 기분이 좋아지는군요.. :)
    아이가 크고 나면 같이 놀아주고 싶어도 애가 놀 시간이 없어진다고 일부러 시간은 못낼 망정 주말만이라도 같이 놀아줘라라고 호통치던 아내의 말이 문득 떠오릅니다.. 휴식은 자기만의 충전이 아닌 가족과의 커뮤니케이션의 다른 모습일 수도 있겠다는 생각을 해봅니다..

    2008.03.03 14:54 신고 [ ADDR : EDIT/ DEL : REPLY ]
  6. 우어... 정말 좋은글을 보고 갑니다.

    저도 요새 이런 생각을 하고 있었거든요.
    연구실에서 하루종일 매달려서 알고리즘 개발하고
    실험하고 뭔가 테스트 해보고 정신없이 무엇인가 하다가
    막상 휴일이 되었을때, 내가 지금 쉬면 남들보다 뒤쳐질텐데 라는 생각을...
    그래서 휴일에도 어김없이 나와서 뭔가 새로운걸 보고 연구하고 있었습니다.

    하지만 이 글을 보니 다시 한번 생각해봐야겠군요.
    저에게 있어서 제대로된 휴식이 주어지지 않은지가
    매우 오래 되었다는걸 잊고 있었습니다.
    다시금 저를 되돌아보도록하게 해주는 글이군요. 감사합니다 ^^;

    2008.03.11 00:15 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 재미있게 읽어주셔서 감사합니다.
      휴식은 모든 사람에게 필요한 부분인데,
      정작 잊고 살게 되는 경우가 많지요.
      우리 모두 좀 쉬면서 삽시다. ㅋㅋ

      2008.03.11 00:46 신고 [ ADDR : EDIT/ DEL ]

Extremely Agile/General2007.11.25 21:12
오늘 이런 글을 하나 봤습니다. 개발자 부족이 낳은 기이한 현상들이라는 제목의 글이더군요. 다른건 둘째치고 그 글에 달린 덧글들이 굉장히 인상적이었습니다. 현재 개발자로 일하고 계시는 분들이 원 글을 쓰신 분을 비난하는 듯한 덧글들이 굉장히 많았는데요. 저는 이분의 문제 제기 자체는 정당했다고 생각합니다. 다만 현재 개발자가 아닌 다른 위치에 계시는 분이니까, 같은 문제를 보는 시각이 개발자들 분과는 좀 다를 뿐입니다.

어쨌건 이 분이 지적한 문제는 대략 다음과 같습니다.

(1) 초급 개발자의 능력 문제
(2) 초급 개발자의 능력에 비해 과도한 보수
(3) 프로페셔널리즘의 부재


이중 (3)은 괜히 논란만 불러 일으킬 뿐이지 현재 상황을 생산적으로 극복하는데 별 도움은 안되는 것 같군요. 그러니 (3)은 이야기하지 않는 편이 더 나았을 겁니다. 개발자의 자존심 문제하고 관련이 있거든요.

그러면 (1)과 (2)의 문제를 생각해 보죠. 사실 (1)이나 (2) 모두 사람이 부족하니까 생기는 문제입니다. 개발자 층이 풍부하다면, 초급 개발자의 능력 문제를 따질 필요가 없습니다. 초급 개발자는 초급 개발자답게, 스스로의 역량을 키우는 데 집중하면 될 것이고, 프로젝트를 이끌어 가는 것은 중고급 개발자들이 하면 됩니다. 그럼 왜 이렇게 개발자들이 부족한 것일까요? 거기에는 여러가지 요인이 있습니다. 그 중 가장 뻔한 것 부터 살펴보죠.

A. 개발자들이 부족하기 때문이다.

네. 말장난같지만 개발자들이 부족하기 때문에 개발자들은 더 부족해지고 있습니다. 개발자들이 부족하다는 것은 프로젝트 인력 수급이 비정상적으로 될 수 밖에 없다는 것을 암시합니다. 이미 존재하는 팀이 프로젝트를 맡는 것이 아니라, 프로젝트 계약이 성사되면 그 시점에 프로그래머들을 구하기 시작합니다. (이렇게 해서 구해진 프로그래머들 대부분은 초급입니다. 중/고급 프로그래머들은 대부분 이미 다른 일이 있습니다.) 계약이 성사된 시점에 이미 데드라인은 받은 상태이고, 어떤 기능을 언제까지 내놓을지는 모호한 상태입니다. 구해온 프로그래머는 관리자 입장에서 보면 그야말로 '어디서 데려온 프로그래머들'이기 때문에, 프로젝트 관리자는 이들을 고객과 대면시킬 생각도 없고, 그럴 계획도 없습니다. (그런 경우가 대부분입니다.) 따라서 프로그래머들은 모든 지시를 프로젝트 관리자로부터 받는데, 문제는 관리자가 각각의 프로그래머의 능력을 정확하게 알지 못하므로, 이 관리자가 '누가 어떤 작업을 언제까지 마무리 지을 것이다'라는 추정을 할 경우, 그 추정은 백발백중 실패하게 되리라는 사실입니다[각주:1].

이렇게 될 경우, 결국 프로젝트 일정은 날이 갈수록 타이트해지고, 후반부로 갈 수록 빡빡해지며(원래는 일이 진척되어 갈 수록 일의 양이 줄어들어야 하잖아요?), 프로그래머에게 아무 예고 없이 요구사항 변경이 통보되는 빈도수도 증가합니다(고객과 대면할 기회가 없으니 당연하죠). 결국, 개발자들이 체감하는 삶의 질은 프로젝트가 진행될 수록 나아지고 예측 가능해 지는 것이 아니라, 프로젝트가 끝날 때 쯤 되면 완벽하게 피폐해지게 됩니다. 그러니, 개발자들이 이 바닥에서 오래 버틸 리가 있겠어요?

B. 질적인 성장을 담보하지 못한 양적인 팽창

한떄 대학교가 IT 관련 학과들의 정원을 무차별적으로 늘리면서, 업계에 몸담는 프로그래머의 수도 늘어났습니다. 한때 닷컴 열풍이 불면서, 이 때 쏟아져 나온 프로그래머들 대부분이 자연스럽게 업계로 이동했고, 프로그래머와 일자리 간의 수급 균형이 얼핏 맞는 것 같아 보이게 되었습니다.

하지만 닷컴 열풍은 오래가지 못했고, IMF가 찾아왔고, 대부분의 프로그래머들의 고용이 불안정한 지경에 놓이게 되었습니다. 어쩌면 프로그래머들이 프로그래밍으로부터 등을 돌리기 시작한 시점은 이때부터 일겁니다. 고용이 불안정한 일거리에 누가 붙어 있으려고 하나요?

하지만 그렇다고 IT 전반이 한꺼번에 죽어버린건 아닙니다. 아직도 많은 SW 프로젝트들이 만들어지고 있고, 한국 IT 인프라를 보는 많은 사람들은 아직도 긍정적인 전망을 내 놓고 있습니다. 그러다 보니 이제 프로그래머를 둘러싼 수요와 공급 간의 불균형이 두드러집니다. 아직도 프로그래머들을 원하는 새로운 일거리는 꾸준히 있는데, 소위 '쓸만한' 프로그래머는 많지 않습니다. 그러다보니 자연스럽게 중고급 프로그래머가 느끼는 일의 강도는 상승합니다. 일이 몰리는거죠. (반면에 보수는 그다지 높지 않죠.) 그러다보면 작업 결과의 질이 떨어져 '좀 쓸만해 보였던 프로그래머'가 일순간에 '생각보다는 쓸만하지 않은 프로그래머'로 전락하기도 합니다.

이런 상황에서 중고급 프로그래머가 초급 프로그래머에게 바람직한 역할 모델을 보여줄 기회는 많지 않습니다. 다들 자기 앞가림 하기에 바쁘죠. 실제로, 대부분의 중고급 프로그래머들은 자신이 몸담고 있는 IT 업계에서의 '프로그래머의 미래'를 그다지 낙관적으로 보고 있지 않습니다. 많은 사람들이 이야기하듯이, 35이 넘어가면 프로그래밍을 떠나 다른 일을 하게 될 가능성이 높지만 (정말로 이상한 현상 중의 하나입니다만) 그렇더라도 프로그래머에게 주어지는 그 '또다른 기회'의 질이 그다지 높은 것도 아니거든요.

그러다보니 이제 'IT 돌려막기'의 최전선으로 나서는 중고급 프로그래머들, 소위 이 바닥의 잘나간다는 IT 프로젝트를 왔다갔다 하면서 책임지는 새로운 프리렌서 집단이 나타나게 되었습니다. 이런 부류의 프로그래머 분들은 붙박이 직장이 주는 스트레스에서 한발 떨어져 있으면서, 자신이 가진 프로그래밍 노하우를 활용하여 더 많은 금전적 혜택을 얻고자 하는 분들입니다.

결국 업계 전반적으로 만연된 '쓸만한 프로그래머가 없다'는 푸념은 애초에 이 바닥이 양적으로 팽창했다가 차갑게 식어갈 무렵, 예정되어 있던 것이라고 보는 것이 맞겠어요. 그리고, 이런 인력 부족 현상은 초급 프로그래머에게 있어서 보다(초급 프로그래머는 어쨌던 계속해서 시장에 나오게 되어 있습니다. 많던 적던), 중고급 프로그래머들을 대상으로 훨씬 심하게 나타나고 있습니다. 이런 결과는 (1) 과도한 업무량 (2) 낮은 보수 (3) 불투명한 미래 (4) 불확실한 보장 등등이 맞불려 일어나는 현상이죠. 앞서 말씀드린 35세라는 나이 문제도 있구요. 35세 이전에 아키텍트가 되지 못하면 영원히 되지 못하는거죠 ㅎㅎ

그러니 초급 프로그래머에 대해서는 '보수' 문제가 불거지고(왜케 비싼거냐?), 회사에서는 '쓸만한 인재가 없다'는 투덜거림(쓸만한 놈들 다 어디갔어? 우리 회사에 있는 놈들은 다 왜이래?)이 나올 밖에요.

그러면 이런 문제는 어떻게 해결해야 하나요?

이런 문제를 해결하려면 IT 업체들이나 새로 이 바닥에 뛰어들려는 사람들이 개발자라는 사람이 원하는 것을 조금 더 이해하도록 노력해야 하고, IT SW 프로젝트의 라이프사이클에 대해서 좀 더 치밀한 연구를 해야 합니다. 프로그래머의 수를 늘리는 방법이 나오질 않아서 의아하시죠? 저는 지금 프로그래머의 수 자체는 적정 수준이라고 생각합니다. 중고급 프로그래머들이 적어서 문제죠. 피라미드는 피라미드인데, 밑이 너무 넓어요.

중고급 개발자의 수를 늘리려면 사실 '프로그래밍 언어를 가르치는 수준'에서 한발짝도 더 나아가지 못하는 IT 교육 과정의 문제점부터 사실 개선해야 합니다. 김창준님 같은 분에게 부탁해서 "프로그래머라면 반드시 읽어야 하는 추천 도서" 목록이라도 한번 배포하고 나면 문제가 어느 정도는 개선이 될지도 모르죠. 저는 중고급 프로그래머가 되려면 적어도 설계+구현+테스트에 필요한 잘 알려진 솔루션을 한가지씩은 섭렵하고 있어야 한다고 생각합니다. UML도 불편하지 않을 정도로 하고, 언어들 중 한두가지 정도는 불편하지 않을 정도는 쓸수 있고, 프로그램을 넘기기 전에 단위 테스트를 충실히 해야한다는 것 정도는 알고 있고, 알고리즘을 어떻게 만들고 개선해 나가면 되는지에 대한 기본적인 지식 정도는 있어야 하겠죠. (부분적인 예에 불과합니다. 이것보다 더 많은 것들이 '기본적인 지식'으로 꼽힐 수 있을겁니다.)

그런데 중고급 개발자의 층을 두텁게 하기 위해서는 사실 교육보다도 환경의 문제가 먼저 개선이 되어야 합니다. 그렇게 고된 삽질에 시달리다보면 스스로에게 지적 영감을 줄만한 깨달음을 얻기가 참 힘들죠. 만사 귀찮아지는 생활을 몇년 하다 보면 매너리즘에 젖어서 나중에는 (1) 개발에 넌덜머리가 나거나 (2) 스스로의 지식만이 최고라고 믿는 양극단 중 한쪽으로 가기가 쉽거든요. 그럼 환경의 문제는 어떻게 개선을 해야 하나요?

잘 알려진 이야기 몇 가지를 해 보죠.

  1. 여러가지 업무를 동시에 하는 프로그래머의 업무 효율은 한 가지 업무를 할 때보다 떨어진다
  2. 기능이 아닌 '활동' 기반의 프로젝트 Planning은 실패할 가능성이 높다
  3. 그러므로 Gantt Chart는 실제로는 아무 쓸모가 없다
  4. 야근을 한다고 업무 효율이 증가하는 것은 아니다
  5. 끊임없이 재검토되지 않은 요구사항은, 프로젝트 말미에 가면 아무도 원하지 않는 요구사항이 될 가능성이 높다
  6. 따라서 요구사항은 끊임없이 재검토 해야 한다
  7. 일정을 맞추기 위해 제품의 질을 희생하는 것은 좋은 생각이 아니다
  8. 일정을 맞추기 위해 새로운 프로그래머를 채용하는 것은 그다지 큰 효과가 없다
아마 이런 이야기들을 한귀로 흘려듣지 않고 좀 깊게 생각해 볼 화두로 받아들이기만 해도, IT 프로젝트가 실패하거나 프로그래머들에게 고통을 줄 가능성은 굉장히 줄어들 겁니다.

프로그래머와 프로젝트가 win-win할 수 있는 가장 좋은 방법은, 프로젝트를 planning할 때 프로그래머를 참여시키는 것입니다. (물론 그러려면 프로젝트가 요구사항을 검토하기 시작할 때 부터 이미 팀은 꾸려져 있어야 합니다.) 프로그래머가 추정한 일정이나 규모 추정치를 가장 현실적인 것으로 받아들이고, 야근과 같은 잔업을 프로젝트 일정 추정 과정에서 철저히 배재시켜야 프로그래머도 인간적인 환경에서 일을 할 수 있고, 프로젝트도 그 일정에 관한 한 보다 현실적인 추정을 할 수 있습니다. 현실적인 추정이 될 때, 그에 기반한 계획(Planning)이 가능하고, 그런 계획이 만들어질 때 프로그래머는 계획한 일을 하고 남는 시간을 자신을 위해 투자할 수 있습니다. 프로그래머는 프로젝트를 진행하는 사람이지 간트 차트에 그려진 일정을 맞추기 위한 기계나, 프로젝트의 소모품이 아닙니다. 프로그래머도 쉴때는 쉬어야 합니다. 일자리가 주는 삶의 질이나 기회가 높아질 때, 초급이 중급으로, 그리고 중급이 고급 프로그래머로 나아갈 수 있습니다. 그때가 되면 아마 "쓸만한 개발자가 없어"라는 말도 좀 덜 나올 수 있겠죠. "쓸만한 개발자"는 사실 "여러분 주변"에 있는 개발자입니다. 조직이 그 사람들에게 "쓸만한 개발자로 스스로를 갈고 닦을 시간"을 주지 않거나, "머리를 좀 굴려서 눈 앞의 석탄을 다이아몬드로 바꿀 방법을 고안해 낼 시간"을 주지 않기 때문에 쓸만한 개발자로 보이지 않을 뿐입니다.

그리고 중고급 프로그래머를 나이가 좀 들었다고 다른 업무로 돌리는 식의 인사 행태도 좀 달리 생각해봐야 합니다. 그런 분들이 프로젝트 초기 부터 SW 아키텍처 작업에 주도적으로 참여하고 Chief Programmer로서 일하게 되면, 최종적으로 나오게 될 프로그래밍 결과물은 굉장히 달라질 수 있습니다.

물론 이렇게 이야기하면 또 이런 질문이 나올겁니다.

A. 사람이 없는데 어떻게 인간적인 일자리를 만드나?
B. 일정이 빡빡한데 어떻게 그렇게 낭만적으로 일할 수 있나?

A에 대해서라면, 인간적인 근무환경을 보장하는 것으로 프로그래머들을 모을 수 있다는 사례 1 2가 있습니다. B에 대해서라면, 위에 언급한 '잘 알려진 이야기'들에 대한 연구 사례들을 조금 더 주의깊게 읽어 보셔야 할 것 같습니다. 이 '잘 알려진 이야기'들은 전부 지금의 IT 바닥에서 매일같이 일어나고 있는 일들에 대한 아주 '현실적인' 이야기들입니다. 프로그래머를 족친다고 문제가 해결되는게 아니라구요! ㅋㅋ

  1. 추정을 정확하게 하려면, 고객이 '자신이 원하는 기능'에 대한 명세를 개발자들에게 보여주고, 개발자들이 그 기능을 구현하는 데 소요될 시간을 추정하게 한 다음에, 그에 기반해서 최종 소프트웨어에 탑재할 기능을 취사선택하도록 해야 합니다. 개발자들이 정확한 추정을 할 지 못믿으시겠다구요? 그러면 본인의 추정치는 무슨 근거로 확신하세요? [본문으로]
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 늙은개발자

    정확히 합시다. 부족한게 아닙니다.
    전혀...

    다만 마구 양성했던 싼값에 진행했던 또는 그런데로 진행되고 있다고 느끼게 했던 그
    현상이 사라져서 느끼는게 부족하게 느끼는거죠...

    부족이란 말과 적정 및 과도하다는 말은 공급쪽 팩터에 뭔가 균형을 헤치는
    힘이 존재하기 때문인데.. 그런게 과도한 적은 있었지만.. ( 정부 지원 학원 난립시절 )
    현재를 보면 수요나 공급쪽에 전혀 인위적 개입이 없습니다. 수요가 크면
    공급은 일어납니다만.. 현재 전혀 공급이 늘어나지 않는것은 수요가 사실 없기 때문입니다.

    그냥 막연히 업계 시공사에서 하는 말은 무시하세요. 안되면 말마따나 인도쪽이나 배트남쪽을
    알아보겠죠.

    중요한건..... 부족이라고 판단하는것 자체가 어떤 근거가 있는게 아니라는 겁니다.
    게다가 초보가 월 300이라니? 란 말도 전혀 근거가 없는 그냥 감정상의 느낌일 뿐이라는 거죠...
    과거와 비교되기 때문에 느껴지는 그런 느낌.

    엔지니어이거나 과학자라면... 그냥 느낌으로 판단해서는 안되겠죠? 애초에 엔지니어 공급을
    양쩍으로 팽창시킨다고해서 산업이 건강해지는건 아닙니다. 생태계가 건강해야죠.... ^^

    또 한번 느낌으로 일을 저지르면 ( 학원에 돈 퍼주기 같은거 다시 하면..)
    이젠 영영 복구하기 힘든 지경이 될겁니다.

    2007.11.30 11:37 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 늙은개발자

    참고로 ...

    보통의 기업에서 경영기획이나 관리파트사람들은 판단을 느낌 + 읽었던 책에 나온말..
    로 하는 경향이 있습니다. 원글자 ( 기이하다고 했던.)
    도 MIS 관련일을 했을수는 있지만.

    실제 엔지니어는 아니었을거라고 짐작합니다. ( 학교에서 배웠다 하더라도
    실무를 직접했던 경험이 많지 않은 경우나 바로 PM 생활했거나..)

    2007.11.30 11:40 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 늙은개발자

    님의 잘알려진 사항들 잘 읽어보시면..

    고객이 무지 좋아하는 걸로 이루어져 있지요?

    기이하다고 했던 분도 저같은 코더들에게는 다른

    고객과 별로 차이없는 어쩌면 더 난해한 고객입니다.

    2007.11.30 11:42 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그 '잘 알려진 사항'들은 고객이 좋아하는 사항은 아닙니다. 사실은 개발자가 몸담고 있는 조직에서 조차도 그닥 선호하는 이야기는 아니죠. '그분들'은 그렇게 기민하게 반응하면 애초에 계획했던 대로 프로젝트가 굴러갈 리 없다고 믿거든요.

      위의 '잘 알려진 사항'은 '비현실적 추정'으로 프로그래머들을 압사시키는 대신 '현실적인 추정'이 이루어져야 한다는 연구결과입니다. 고객에게 만족스러운 부분은 아마 고객이 프로젝트 진행 중에 요구사항을 바꾸는 것이 '당연한 현상'이라고 보는 부분 정도일거에요.

      하지만 그것을 '당연한 현상'이라고 보지 않으면, 프로젝트 말미에 '이미 완결된 아키텍처까지도 뒤엎어야 하는' 일이 발생할 가능성이 점점 더 높아집니다.

      요는, 그런 요구사항 변화에 기민하게 대응할 수 있으면서, 프로그래머에게 인간적인 근무 환경을 보장할 수 있으려면, 현실적인 추정과 그에 입각한 프로젝트 플래닝이 이루어져야 한다, 뭐 그런 겁니다. :-)

      와주셔셔 감사합니다. 좋은 의견 주신 점도 감사드립니다.

      2007.12.01 06:49 신고 [ ADDR : EDIT/ DEL ]
  4. 늙은개발자

    일이 몰리면 초급하나 더 밖아주고..
    일정이 반으로 줄거라고 생각하죠.. 머리들은..

    2007.12.18 13:06 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그런 분들에게는 "프로그래머의 수가 늘어난다고 프로젝트가 빨리 끝나지는 않는다"는 연구 결과를 보여드리는게 좋을 것 같습니다. agile.egloos.com 어딘가에서 읽었었는데 링크를 다시 찾아보려니 못찾겠네요.

      2007.12.18 13:29 신고 [ ADDR : EDIT/ DEL ]

제 주변엔 게으른 사람들이 좀 있습니다. 유유상종이라고, 저부터도 굉장히 게으른 편입니다. 스스로 프로그래머를 자처하고 있으니, 저는 '게으른 프로그래머'입니다.

흔히 프로그래밍에 있어서 게으름은 '창조의 어머니'에 비유되고는 합니다. 프로그래밍은 복잡한 문제를 단순하게, 그것도 컴퓨터의 힘을 빌어 풀어보자는 것이므로, 사실은 귀차니즘 신봉자의 게임이라고도 할 수 있습니다. 그러니 '게으르면 게으를수록 프로그래밍에 능하다'는 Myth가 유포되는 것도 어쩌면 당연한 일일지 모르죠.

하지만 정말로 그럴까요? (오늘의 질문입니다.) 주변의 사례를 한번 살펴보겠습니다.

제 주변에는 '어찌나 모든것을 귀찮아 하는지 회의시간에도 꾸벅꾸벅 졸기만 하는' 프로그래머가 한명 있습니다. (편의상 그를 A라고 하겠습니다.) 요구사항 검토회의이건, 개발 회의이건 굉장히 일관되게 좁니다. 하지만 그 사람의 업무 생산성은 그다지 나쁘지 않습니다. 왜 그럴까요?

일단 A에게는 주어진 작업량을 시간 안에 해 낼 정도의 최소한도의 책임감과 능력이 있습니다. 그것마저 없었다면 아마 그는 벌써 회사를 나갔을 겁니다. 그리고 무엇보다, A는 '회의시간에 조는' 바로 그 불성실한 행위를 통해 (1) 요구사항 변동 (2) 문서 갱신 (3) 일정 변동 등등의 정보를 스스로 차단합니다.

통상 Waterfall 형태의 개발 방법론을 따르는 조직에서 실제 코딩에 돌입하기 전 70% 정도의 시간을 소요하게 마련인 (1), (2), (3) 등등의 절차를 기꺼이 외면한 그는, 모든 사람이 코딩에 돌입하는 '개발 phase' 초기가 되어서야 비로소 자신에게 할당된 작업의 이름을 확인하고는 주변 사람들을 귀찮게 해 가면서 '그 작업이 대체 무엇인지'를 파악하기 시작합니다. 그리고는 코딩을 시작하는 것이죠.

A가 정말로 '좋은 프로그래머'인지는 잘 모르겠습니다만 한 가지는 분명합니다. 그의 행동에는 '애자일 적' 혹은 '사용자 스토리'적인 구석이 있다는 것이죠.

사용자 스토리는 보통 '구현될 기능이 어떤 것인지'를 한두줄 정도로 명세하고 그칩니다. 실제로 구현되어야 할 시스템의 디테일은 테스트 케이스들을 통해, 혹은 고객과의 대화를 통해 알아내거나 해야 하죠. 하지만 Waterfall 형태의 개발 모델에서는 사용자 스토리 대신 '유스케이스'라는 도구를 사용하는 경향이 있습니다. 유스케이스는 잘 알려진 대로 특정한 액터의 시스템 사용 시나리오를 굉장히 상세하게 기술합니다. (심지어는 Exceptional Case까지 전부 하나의 유스케이스 안에 때려넣는 경우도 있습니다.)

A는 본인도 모르는 사이에 '사용자 스토리에 기반한 개발'과 유사한 형태로 개발을 하고 있습니다. 그가 커피타임에 이런 이야기를 하는 것을 들은 적이 있습니다.

'확정될 수 없는 것을 확정짓고 개발을 하려 하면 개발에 소요되는 시간은 더 늘어나게 되어 있습니다. 그렇게 열심히 만들어 놓은 유스케이스를 실제로 펼쳐놓고 코딩해야 될 때가 되면, 고객의 요구사항이 상당부분 바뀌어 있는 경우가 많잖아요?'

그러니, 어쩌면 A가 회의 시간에 조는 것은 요구사항이 널뛰는 과정을 연대기적으로 파악하고 있어야 하는 오버헤드가 귀찮아서 일 겁니다.

하지만 그의 행동에는 상당히 비-애자일 적인 면도 많습니다. '회의 시간에 조는' 바로 그 행위는 애자일 적이면서도 한편으로는 비-애자일적이기도 합니다. 다른 사람이 열심히 떠들때 '굉장히 일관되게' 존다는 것은 다른 사람들에 대한 배려가 부족하다는 증거입니다. 그런 경우에는 그가 몸담고 있는 조직이 그를 피곤하게 하는 것은 아닌지도 확인을 해 봐야겠지만, 그 자신의 태도에도 문제가 있음을 한편으로는 지적해 줄 필요가 있습니다. 애자일적인 조직이건, 비-애자일 적인 조직이건 가장 중요한 것은 상호 존중이기 때문입니다.

TIP: 회의를 외면하는 프로그래머가 늘어난다면 '사용자 스토리'를 도입하는 것을 고려해 보세요.

각설하고, 원래의 질문으로 돌아가보죠. 게으른 A는 훌륭한 프로그래머입니까? '게으른 사람 중에 훌륭한 프로그래머가 많다'는 것은, 게으름이 '상황을 개선하고자 하는 의지'로 환골탈태하게 되는 케이스가 많다는 것을 의미합니다. 하지만 A는 자기 주변의 상황을 전혀 개선하려고 하질 않아요. 상황을 개선하고 나면, 남는 시간에 보다 더 게을러질 수도 있는데 말이죠. 그러니, 제 기준에서 보면 A는 그다지 훌륭하지 않습니다. 충분히 게으르지 않은 프로그래머라고도 말할 수 있겠습니다. 프로젝트 기간의 70%를 유스케이스 작성에 투자하는게 그렇게 귀찮았다면, 스스로 애자일 프로세스 도입을 주장해서 상황을 더 낫게 만들 수도 있었을텐데 말이에요. :=P





신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Extremely Agile/General2007.10.13 00:42
블로그 "애자일 이야기"에서 달인이 되는 데 도움을 줄만한 책과 영화에 대한 글을 본 적이 있습니다. 그 글을 읽다 보니, 과연 나에게 그런 책이 있었나 하는 생각이 들더군요. 한참을 생각한 끝에, 저에게도 그런 책과 영화들이  있다는 것을 발견했습니다. 물론 저에게는 '달인'이라는 용어는 어울리지 않으니 '좋은 프로그래머가 되려면 읽어두는 게 좋을 책과 영화를 발견했다'고 말을 바꾸도록 하죠. :-P


1.

첫 번째 책은 "생각하는 프로그래밍"입니다. 추천하신 분 말대로, 뭔가 깨달음을 주고 무릎을 치게 만드는 명저더군요. 아직 다 본 것은 아니고 단기간 내에 읽을 수 있는 책도 아닙니다만, 프로그래밍 관련 서적 중 베스트로 손꼽히는 이유를 책장을 넘기는 순간 순간마다 느낄 수 있습니다. 이런 저런 C++ Idiom들이나 Effective XX 시리즈들에 질리신 분은 한 번 읽어볼 만 합니다. 프로그래머에게도 추천할 책이긴 합니다만, 연구하다가 좌절을 많이 겪은 연구자들, 논문을 읽기는 읽는데 도대체 breakthrough를 못찾겠다, 는 생각을 자주 하는 분들도 읽으면 좋을 것 같다는 생각입니다. 그럼 대체 이 책이 뭐가 좋다는 건가요?

이 책은 문제의 해법을 스스로 창조하기 위한 생각의 패턴을 가르쳐 줍니다. 그 이상은 스스로 알아내야 합니다만, 그래도 그게 어딥니까? :-P

사용자 삽입 이미지


2.

두 번째 책은 "Network Algorithmics"입니다. 네트워크 하드웨어 연구자에게 적합한 책입니다만, 네트워크 장비가 해결해야 할 이슈들에 조금이라도 지식이 있는 사람이라면, 이 책에서 분명 그 이상의 일반적인 교훈을 얻을 수 있을 것입니다.

이 책의 백미는 뭐니뭐니 해도 제한된 메모리와 시간 요구사항을 뛰어넘는 "longest prefix match"알고리즘을 장비에 탑재하기위해 수많은 개발자와 연구자들이 어떤 식으로 알고리즘을 조금씩 개선시켜왔는지를 보여주는 부분입니다. 모든 문제나 언제나 조금씩 해결되기 마련이라고 생각하는 분들은 그 이면에 어떤 사고과정이 개입되는지를 이 책을 통해 짐작하실 수 있을 거라고 믿습니다.

네트워크 공부를 하는 학생들이 생각하는 것 이상으로 좋은 책입니다.

사용자 삽입 이미지

3.

마지막으로 소개할 무엇은 책이 아니라 영화입니다. 제목은 "The Pursuit of Happyness"입니다.

사용자 삽입 이미지

사람은 누구나 행복해지고자 합니다. 프로그래머도 마찬가지입니다. 프로그래머는 프로그래밍을 통해 행복을 얻고자 하는 사람들입니다. 많은 것들이 프로그래머에게 기쁨을 줍니다. 코드, 프로그램, 자신의 성장, 그리고 가족들의 성장. 코드가 자라듯 프로그래머를 둘러싼 모든 것들은 조금씩 자라나고 프로그래머와 함께 성장합니다.

하지만 프로그래머도 사람인지라, 좌절을 겪습니다. 지금 생각해도 우스운 일이지만, 저는 B+ 트리를 보름간 디버깅해 본 경험이 있습니다. 그 보름간, 저는 밥먹는 시간을 제외한 모든 시간을 컴퓨터 앞에서 보냈습니다. 잠도 거의 자지 않았습니다. 아무도 어떻게 디버깅을 해야 하는지 알려주지 않았고, 몸은 물 먹은 솜 마냥 무거웠습니다. 모든 것은 그저 제 경험에 달려 있었습니다. 아마 그 때 좌절해 버리고 프로그래밍으로부터 등을 돌렸다면, 저는 끊임없이 저를 자극하는 이 재미있는 작업을 지금도 저주하고 있었을 겁니다. 하지만 저는 그렇게 하지 않았고, 지금은 스스로를 프로그래머라고 생각하는 사람이 되어 있습니다. (물론 썩 좋은 프로그래머는 아닙니다 -_-;;)

"The Pursuit of Happyness"는 프로그래머가 겪는 좌절을 어떻게 극복하면 되는지에 대해서는 알려주지 않습니다. 다만 그것을 극복한 사람에게 어떤 선물이 주어지는지를 조용히 이야기할 뿐입니다. 그런 의미에서는, 모든 사람들에게 도움이 될 만한 영화라고 할 수 있겠습니다.



신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 비밀댓글입니다

    2008.08.04 17:42 [ ADDR : EDIT/ DEL : REPLY ]