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

  1. 2012.06.25 인간, 조직, 권련 그리고 어느 SW 엔지니어의 변 (1)
  2. 2011.02.12 객체지향적으로 생각하라 - 맷 와이스펠드
  3. 2010.10.17 프로그래머의 고과를 어떻게 매길 것인가? - 내 경우에는 (In my case)
  4. 2010.02.17 스크럼 - 켄슈와버, 마이크 비들
  5. 2009.06.21 플랫폼 벤더들 - Platform vendors
  6. 2009.05.04 개발자 생태보고서 6 (A Field Guide to Developers)
  7. 2009.05.02 개발자 생태보고서 5 (A Field Guide to Developers)
  8. 2009.05.01 극한직업 - IT는 어떨까? (8)
  9. 2009.05.01 프로그래밍은 상상이다 - 임백준 (4)
  10. 2009.04.30 개발자 생태보고서 4 (A Field Guide to Developers)
  11. 2009.04.29 개발자 생태보고서 3 (A Field Guide to Developers) (1)
  12. 2009.04.28 우울한 하루 1 - IT는 정녕 앞이 안보이는가 (1)
  13. 2009.04.25 개발자 생태보고서 2 (A Field Guide to Developers)
  14. 2009.04.25 개발자 생태보고서 1 (A Field Guide to Developers)
  15. 2009.04.22 좋은 프로그래머의 조건 (2)
  16. 2009.04.20 Fog Creek의 새 사무실 - The new Fog Creek Office 1
  17. 2009.03.21 Joel on Software, 첫번째 번역 완료
  18. 2009.03.21 프로그램 매니저가 되는 방법 - 4 (How to be a program manager)
  19. 2009.03.19 프로그램 매니저가 되는 방법 - 3 (How to be a program manager)
  20. 2009.03.15 프로그램 매니저가 되는 방법 - 2 (How to be a program manager)
  21. 2009.03.14 프로그램 매니저가 되는 방법 - 1 (How to be a program manager) (2)
  22. 2009.03.13 프로그래머가 되는 방법
  23. 2009.03.09 어떻게 프로그래머의 고과를 매길 것인가?


인간, 조직, 권력 그리고 어느 SW 엔지니어의 변
국내도서>컴퓨터/인터넷
저자 : 이종국
출판 : 인사이트 2011.03.11
상세보기



 

 적나라한 대한민국 S/W의 현실  

 


● 그동안 S/W 관련된 에세이 혹은 소설 종류는 거의 다 읽은 것 같다. 안철수 교수의 "지금 우리에게 필요한 것은" 부터 임백준 님의 "나는 프로그래머다", "행복한 프로그래밍", "뉴욕의 프로그래머" 같은 에세이, 소설들, 조엘 스폴스키의 그 유명한 Joel on Software 와 그의 책에서 소개하던 다른 S/W 엔지니어링 관련된 책들, "해커와 화가", "데드라인", "프로젝트가 서쪽으로 간 까닭은" 같은 또 다른 저명한 외국인들의 관련 책들까지. 프로그래밍으로 밥을 벌어먹으면서 관련된 책들은 약간의 의무감까지 느끼며 모두 읽었다. 


● 앞에서 든 책들은 모두 외국의, 특히 미국의 S/W 업계의 현실을 반영한 경우가 많다. 심지어 임백준 님의 책들 조차도 뉴욕의 S/W 회사에서 벌어지는 일이다. 내가 매일 겪는 불합리한 상황들과는 - 지금은 많이 지나갔지만, 옜날에 야근이 극심할 때는, "아 이래서 회사에 창문이 안열리는구나" 란 생각 까지 했었다. - 기본적인 전제 자체가 다르다. 아무리 바쁘고 시간에 쫒기면서 돌아가는 곳이 이 S/W 업계라 하여도 대한민국 SI 업계에서 들려오는 소문들과, 내 사촌 누님이 실제로 겪은 일들과,제조업에 기반을 둔 무늬만 IT회사에서 나와 내 동기들과 동창들이 겪는 일들은 앞서 말한 책들의 저자들은 상상조차 하지 못한 일들이다. 


● 이 책, 대한민국의 SW 현실을 다룬 진짜 첫번째 책인 아닌가 싶다. 이전에 "대한민국에는 S/W가 없다" 가 그나마 대한민국의 현실을 다루려고 했었으나, 역시나 저 높은 곳에서 책상물림이 쓴 느낌이었다면, 이 책은 진짜 PM이 수십년간 프로젝트를 진행하면 겪었던 일들이 정말, 적나라하게 적혀 있다. 


● 예를 들면 이런식이다. 어떤 방법론이나 S/W 엔지니어링 이론에 따른 산출물을 만들어 달라고 요구하면 대충그럴듯하게 만들어주면 된다. 어차피 요구한 사람도 그 자세한 내용은 보지도 않을 뿐 아니라 자기 상사에게 그럴듯 하게 보고하기 위한 용도에 지나지 않기 때문이다. 이런 식으로 신랄하게 깐다. 저자와 같이 프로젝트를 진행했던 몇몇 분들은 책을 읽으면서 자기얘기가 나와서 얼굴이 붉어질지도 모른다. 



 

 대한민국 S/W 업계가 개판인 이유 - 결국 조직내 정치싸움 

 

● SI 업계의 권력 피라미드를 그리면 대충 다음과 같다. 정점에 발주사의 CEO가 있고, 그 밑에 경영진 - IT실무부서(감리부서) - 하청업체 경영진(영업부서) - 하청업체 개발팀 순서다. 일은 하청업체 개발팀이 다 하지만, 생색은 발주사의 경영진이 낸다. 중간에 껴있는 모든 사람들은 어떻게든 자기 때문에 프로젝트가 잘 돌아간 것처럼 보이기 위해서 애를 쓰고, 파워게임을 하고, 쓸데없는 문서를 요구하고, 프로젝트 일정을 압박하고, 결국 개발팀의 누군가를 희생양으로 삼으려고 한다. 이 결과, 개발자와 그 가족들의 삶은 피폐해지고, 프리랜서들은 개발 중간에 회사를 떠나고, 심지어 프로젝트가 일정에 맞춰 성공적으로 끝나는 것을 싫어하는 사람들까지 나타난다. 자신의 공적을 내세울 곳이 없기 때문이다. 


● 돈은 개발부서가 번다. 좀 더 정확히 얘기하면, 위에 권력 피라미드에서 구체적인 부가가치를 창출하는 곳은 제일 밑바닥에 있는 개발부서이다. 그런데, 실제로는 경영, 영업부서다 계약을 통해서 매출을 창출하고, 그 이후 개발부서는 이윤을 까먹는 곳으로 여겨진다. 여기서 현시로가 괴리가 생기고, 문제가 발생하다. 


● 역시, 책상물림들이 S/W 엔지니어링이라는 학문을 만들면서 불필요한 문서들이 엄청나게 늘어났다. 문제는 이 문서 산출물들이 본래의 의도는 잃어버린채, 관리부서의 실적을 입증하는 용도로 전락해 버린다. 문서는 만들어지지만, 누구 하나 내용에는 관심도 없다는 얘기다. 실제 프로젝트와 문서와의 상관관계도 큰 관심이 없다. 결국 개발자들에게 일만 많아지고, 일의 집중력만 흐트러뜨리며, 프로젝트 일정만 늦출 뿐이다. 



 

 프로젝트의 진짜 목적은 무엇인가?

 

● 소프트웨어 개발이나 운영, 유지보수의 최종 목적은 그 안에서 일하는 우리의 행복이어야 한다. 

Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. ee
    2012.06.26 02:08
    댓글 주소 수정/삭제 댓글
    사실 맞는듯요 개발이 제일천대받고무시하고 빨리하라고 야근하고 주말출근에 위에선 저렇게갈구죠


객체지향적으로 생각하라!
국내도서>컴퓨터/인터넷
저자 : 맷 와이스펠드(Matt Weisfeld) / 배선종역
출판 : 정보문화사 2009.05.07
상세보기

   Object Oriented Programing 을 공부하기 전에 필독할 만한 책  

  오늘날 프로그래밍의 주류언어로 자바(Java)가 각광을 받으면서, 대부분의 학교에서도 Java를 가르치고 있다. 자바와 C++을 공부하는데 있어서 C의 포인터 만큼이나 넘기 어려운 부분이 있다면, 객체지향(Object Oriented)의 개념을 이해하고, 설계에 적용하는 부분일 것이다. 어떠한 문제를 해결하기 위한 프로그래밍 방법은 수십가지가 있겠지만, 객체지향의 이념을 잘 살려서 우수한 설계와 구현을 하는 것은 결코 쉬운일이 아니다. 특히나 학부 레벨에서 관련된 내용을 배우기도 쉽지 않다. 대부분 과제에서도 죽지않고 돌아가는 프로그램을 짜기 급급한 수준이다. 

  이 책은 객체지향언어를 공부하기에 앞서 한번 완독할 만한 책이다. 내용이 어렵지 않으면서, 예제 코드도 적절하게, 충분히 있고, 개념 설명과 설계의 의도를 충실히 설명해 주고 있다. 최신 기술과 트렌드들을 다양하게 다루고 있고, 여러 언어의 차이와 특성에 대해서도 비교하여 설명해 주고 있다. 이만한 개념서를 찾아보기가 어렵다. 

  물론, 학부 수준 - 프로그래밍을 공부한지 1 ~ 2 학기 정도 - 된 학생의 입장에서는 모든 내용을 100% 소화하기는 어려울 것이다. 하지만, 이 책은 학기 시작 전에 읽고, 학기를 마친 뒤에 다시 한번 읽어봐도 좋을 만한 책이다. 수학 정석을 한 번 보고 버지리 않듯이, 이 책은 여러번 읽어도 좋을 만큼 내용이 다양하고, 새내기 프로그래머에게 주는 교훈들이 많이 들어있다. 

  충분히 읽어 내용을 이해한다면, 아니 이해하지 못해도 충분히 숙지해 둔다면, 후에 고급 개발자로 나아가는데 큰 도움이 될 만한 책이다. 강추한다. 

Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  유명 블로거 조엘 스폴스키 (Joel spolsky) - 저자에 관하여 (Joel on Soft ware - About the Author : Joel Spolsky) - 의 글에 따르면, S/W 개발자들의 공평한 고과를 매기는 것은 무척 어려울 뿐 더러, 일반적인 사람들에 비하여 더 똑똑한 이 사람들은 어떠한 기준을 제시해도 그 기준을 피해나갈 방법을 찾기 때문에, 차라리 고과를 매기지 않는 편이 좋다고 얘기를 합니다. 예를 들어,한주에 작성한 코드의 양을 기준으로 삼는다면 일부러 코드를 늘려서 짤 것이고, 수정한 버그 수를 기준으로 삼는다면 일부러 쉬운 버그들을 양산할 것미고, 반대로 만들어낸 버그의 수를 기준으로 삼는다면 테스트를 하느라 코드 작업이 진행되지 않는다는 거지요. 프로그래머를 평가하는 방법은 그들의 짠 코드를 직접 평가하는 수 밖에 없는데, 이는 주관적이고 절대적인 기준이지, 상대적이고 객관적인 기준을 만들 수는 없습니다. 오히려 많은 역효과가 있기 때문에, 조엘은 프로그래머들의 고과를 평가하지 말 것을 권하고 있습니다. 이와 관해서 제가 최근에 겪은 이야기를 써볼까 합니다.

  최악의 프로젝트가 막 끝났습니다. 기획과 경영 파트의 잘못된 추정과 진행으로 프로젝트가 최악으로 치달았습니다. 이로 인해서 코어팀은 6개월 가까이 잔업과 특근에 시달려야 했습니다. (시달렸다는 표현은, 월 100시간 정도 잔업과 토, 일요일 모두 출근했다는 뜻입니다.) 정말 최악이었죠. 프로젝트가 끝나기 두 달 전부터는 어플리케이션 팀도 마찬가지도 시달려야 했습니다. 어플리케이션 팀도 적지 않게 고생을 했습니다.

  어쨌든, 프로젝트는 끝이 났습니다. 그리고 수확의 계절이 되었습니다. 코어팀 리더는 목소리가 큰 분이셨는데 (Big mouth), 코어팀이 가장 고생을 한 것이 명백하니, 우리 애들이 좋은 고과를 받아야 한다고 주장을 하셨습니다. 이로 인해 다른 팀은 "보통" 고과 밖에는 받지 못했는데, 회사 정책이 각 등급의 배분에 제한을 두었기 때문입니다. 코어팀 리더의 주장은, 코어팀이 가장 많은 잔특근을 했기 때문에, 그들이 좋은 고과를 받을 자격이 있다는 것이었습니다. 이 주장은 옳은가요? 충분히 공평한 것입니까?

   이래서 반대합니다.  
 

  반대의견 1. 좋은 고과는 똑똑하고 빛나는 프로그래머들에게 가야합니다. 잔업시간은 좋은 프로그래머의 능력을 나타내는 지표가 될 수 없습니다.

  반대의견 2. 어떤 프로그래머가 코어팀에 배치가 되었습니다. 그는 잔업에 시달리게 되었습니다. 그리고 좋은 고과를 받았습니다. 그런데, 이 프로그래머가 코어팀에 배치된 것은 그가 원해서 된 것도 아니고, 그가 특별한 재능이 있어서도 아닙니다. 그냥 신입사원 배치 중 "우연히" 된 것입니다. 그렇다면, 다른 팀에 배치되어 "보통"의 고과를 받은 신입사원에게는 완전히(totally) 불공평한 일입니다.

  반대의견 3. 엄청난 좌절감(depression)이 코어 외 다른 팀들에 주어졌습니다. 그리고 이는 앞으로 팀을 관리하는데 엄청난 어려움이 됩니다. 다른 팀원들도 잔업에 시달린 것은 마찬가지 였습니다. 두 달간의 시달림도 결코 재미있는 일은 아니었습니다. 그리고, 그들은 그 보상도 받지 못했습니다. 이제, 새 프로젝트가 시작되었지만, 다른 팀원들은 잔업을 거부하게 되었습니다. 더 나아가, 그들은 관리자들로부터 모욕감을 느끼고 있습니다. 이제 관리자들은 어떻게 개발자들의 사기를 북돋을 수 있을까요?

   단순한 고과 문제가 아닌, 신뢰의 문제입니다.
 

  제가 무슨 얘기를 하는 것인지 이해가 되시나요? 이건 단순히 고과 평가에 관한 이야기가 아닙니다. 이건 개발자와 관리자(팀) 사이의 거대한 신뢰 문제에 관한 이야기 입니다. 그리고 신뢰는 멀리, 저멀리 날아가 버렸습니다.

  이것은 현재 진행형의 이야기 입니다. 끔찍한 잔업과 시달림은 관리자들 - 특히 빅 보스 (Big boss) - 에 의해서 만들어졌습니다. 그러므로, 문제를 해결하는 것도 관리자들 (역시 빅 보스)의 책임입니다. 어쩌면 모든 문제를 만든 것은 회사 조직 그 자체일지도 모릅니다.

  앞으로 어떻게 진행이 될까요? 글쎄요. 문제를 해결 할 수 있는 사람이 변하지 않으면, 계속 같은 이야기가 반복되겠지요. 아마도, 끊임없이 같은 이야기가 반복될 지 모릅니다. 그리고, 진짜 쓸만한 개발자는 아무도 안남게 되겠지요.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


스크럼 Scrum
국내도서>컴퓨터/인터넷
저자 : 켄 슈와버,마이크 비들 / 박일,김기웅 역
출판 : 인사이트 2008.10.01
상세보기

   프로그래밍에서 가장 중요한 것은?
 

  적게는 2~3명, 많게는 300명 이상의 공동작업으로 이루어지는 현재 소프트웨어 프로젝트에서 프로그래밍을 할 때, 가장 중요한 것을 꼽으라면, 단연 "커뮤니케이션 능력" 을 들 것이다. 프로그래밍이란 것이, "언어" 를 이용하여 "창작"을 하는 과정이기 때문에, 일종의 공동 문집을 만들어 나가는 과정이다. 한권의 문집이 군더더기 없는 글의 집합이 되려면 글 한 편 한 편이 올바라야 하지만, 무엇보다 무엇을 위한 문집인지, 어떻게 통일성을 갖는 한 권의 책을 만들어 낼 것인지 의사를 결정하고, 결정된 내용을 모두 함께 따르는 것이 중요하다. 교정은 누가 볼 것이고, 부족한 내용은 누가 보충할 것인지, 퇴고는 어느 방향으로 할 것인지 등을 결정하고, 지시하고, 지시에 따르는 것이 필요하다. 대규모 프로젝트 또한 이와 동일해서, 수백명의 똑똑한 개발자들이 모인 상황에서 가장 중요한 것은 한방향으로 의샇소통을 하는 것이다.

  그럼에도 불구하고, 현실에서는 여전히 군대식 의사소통이 만연해 있는 것이 사실이다. 욕설과 함께 설명이 생략된 일정 제시와, 앞뒤 안재고 무조건 "예 알겠습니다" 를 복명복창하는 중간 관리자들, 그리고 내용은 묻지 않고 무조건 수정하라고 문제를 재지정하는 팀 리더들과 조금이라도 다른 팀과 얽히면 문제를 토스하기에 바쁜 실무자들. 마지막으로 뭘 해야 할지 알지 못하고 헤메고 있는 신입 사원까지. 하나의 개발팀이 제대로 돌아가는 것은 기적에 가깝다.

   우리, 이제 계급장을 떼고 스크럼을 해보자 
 

  특히, 긱(Gig)들이 모여있다는 프로그래머 집단 사이에도 엄청난 권위주의가 팽배해 있다는 것은 정말 신기한 일이다. 군대를 안다녀온 여자들 까지도, 선배라는 타이틀과 함께 목에 힘 딱 주고, 너는 내가 시키는 일이나 해라. 니가 뭘 아냐. 난 니가 대학에서 찌질대고 있을 때, 이 코드를 혼자 다 짰다. 는 식으로 업무지시를 하는 일도 흔하고, 문제를 토스하는 와중에서도 어느쪽이 짬이 높냐가 최종 목적지를 결정짓는 일도 흔하다. 믿기지 않겠지만, 대한민국의 대부분의 조직은 이렇게 경직되어 있고, 이런 문화 자체가 개발자의 창의성을 죽이고, 더 나아가 팀의 생산성을 극도로 떨어뜨린다. 모두 같이 밤을 새고 있지만, 그 사람들이 하고 있는 일이 유럽 필드에서 날아올 메일 한통이라는 사실은 종종 내가 무엇을 위해 이짓을 하고 있나 하는 생각을 들게 한다. 좀더 나아가, 실제로 일은 컴퓨터가 하고 있는데, 사람들이 그 뒤에서 결과를 던져주기만을 두 세시간씩 기다리는 일도 흔하다.

  스크럼의 가장 큰 장점은 각자 어제 한 일, 오늘 할 일, 일을 하는데 막히는 점을 자주 만나 이야기 함으로써 서로의 진행상황을 공유하며, 관리자들에게는 할 일을, 개발자들에게는 해야 할 일을 명확히 한다는 점이다. 무엇보다 상명 하복이 아닌 자유로운 대화는 개발자 한 사람 한 사람의 존엄성을 높여줄 수 있다. 조직을 숨쉬게 만들 수 있다.

  이제 우리 스크럼을 해보자. 되도 않는 직급이니 경력이니 입사 기수 같은거 던져 버리고, 프로그래머 대 프로그래머로 대화하며 일을 해보자. 우리에게 필요한 것은 막무가내식 지시가 아니라 서로의 생각을 공유할 수 있는 통로이다.




Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


원문보기

Joel on Software


플랫폼 벤더들
Platform vendors

by Joel Spolsky

 
Wednesday, June 10, 2009


  데이브 위너(Dave Winer) (2007년) : "몇몇 개발자들은 틈새 아이템으로 선택한 것이 벤더의 개발 진행방향와 정확히 일치하거나, 더 나쁜 경우에는 벤더의 로드맵에 포함되어 있기도 합니다.  이런 개발자들은 우리의 동정을 받을 자격이 없습니다."

  iSmashPhone : 새로운 iPhone 3GS에서 15개의 앱이 쓸모없게 되었다. (15 Apps Rendered Obsolete By The New iPhone 3GS)

  독립 S/W 개발자들이 플랫폼 벤더의 구멍을 메우는 유틸리티, 애드온, 또는 어플리케이션을 만들 때,  그들은 벤더에게 큰 친절을 베푸는 것 처럼 생각하는 경향이 있습니다. 오, 보십시요. iPhone은 잘라 붙이기(Cut and paste) 기능이 없습니다. 비지니스의 기회입니다! 그들은 이 사업이 영원히 계속될 것으로 상상하고 있는 듯 합니다. 몇몇은 플랫폼 벤더가 그들의 프로그램을 인수할 것으로 상상하는 듯 합니다. 월급날이다!

  문제는 단지 아주 작은 퍼센트의 아이폰 사용자들만이 이런 단순한 잘라 붙이기 어플리케이션을 산다는 것입니다. 어떤 종류의 애드온이라도 플랫폼 사용자의 1%에게만 판매했다면 대단한 성공을 거둔 것입니다.

  애플(Apple)의 입장에서는 이것은 문제입니다. 이 말은, 99%의 고객들은 잘라 붙이기가 안되는 문제를 해결하지 못했다는 뜻입니다. 잘라 붙이기가 안되는 것이 정말로 문제라면, 애플은 문제를 해결할 것입니다. 그리고 당신의 사업은 퇴출되겠지요.

  다른 회사 제품의 라인업 사이의 작은 간극을 메우는 일(Gap-fillers)은 증기 롤러 앞에 동전을 뿌리는 일입니다.

  좋은 플랫폼은 항상 어플리케이션들이 단순한 간근 메우기로 끝나지 않도록 기회를 제공합니다. 이런 어플리케이션들은 벤더가 핵심 기능으로 절대로 생각하지 않을 만한 것입니다. 왜냐하면, 이런 것들은 수직적(vertical) - 모든 사람이 원하지는 않는 - 이기 때문입니다. 아이폰에 치과의사들을 위한 기능이 들어갈 가능성은 정확히 제로(0) 입니다. 제로.

PS. 간만에 번역입니다. 요즘 너무 바빠서 블로그에 시간을 오래 투자하기가 어렵네요.
PS2. iPhone 3GS에서 쓸모없어진 15개의 앱에 관한 글도 번역할 예정입니다.

2009/04/04 - [조엘 온 소프트웨어(번역)] - 조엘 온 스프트웨어 - 저자에 관하여 (Joel on Soft ware - About the Author : Joel Spolsky)

Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


원문보기

Joel on Software


개발자 생태보고서
A Field Guide to Developers

by Joel Spolsky

 
Thursday, September 07, 2006

2009/04/25 - [조엘 온 소프트웨어(번역)] - 개발자 생태보고서 1 (A Field Guide to Developers)
2009/04/25 - [조엘 온 소프트웨어(번역)] - 개발자 생태보고서 2 (A Field Guide to Developers)
2009/04/29 - [조엘 온 소프트웨어(번역)] - 개발자 생태보고서 3 (A Field Guide to Developers)
2009/04/30 - [조엘 온 소프트웨어(번역)] - 개발자 생태보고서 4 (A Field Guide to Developers)
2009/05/02 - [조엘 온 소프트웨어(번역)] - 개발자 생태보고서 5 (A Field Guide to Developers)

내가 어떤 일을 하게 되는가?

  덧붙여서, 개발자들을 끌어들일 수 있는 가장 좋은 방법 중 하는 그들이 재미있는 일을 하게 하는 것입니다. 아마도 이 것이 가장 바꾸기 어려운 것일 겁니다. 빌어먹을 일이지만, 만약 여러분이 자갈과 모래 같은 ( = 콘크리트 같이 딱딱한) 산업을 위한 소프트웨어를 만드는 일을 한다면, 그것이 여러분의 사업분야 입니다. 이런 일을 하면서는 개발자들을 끌어들이기 위하여 멋진 인터넷 벤처기업인 척하기는 어렵습니다.

  개발자들이 선호하는 또 다른 일은 추수감사철 만찬에서 Irma 이모에게 설명할 수 있을만큼 간단하고 유명한 일을 하는 것입니다. 물론, Irma 이모는 핵물리학자일 수도 있고, 모래와 자갈 산업을 위한 Ruby 프로그래밍에 대해서 정말로 많이 알지 못하는 분일 수도 있습니다. (역자주 : 비슷한 예가 있죠.  CNS나 SDS 다닌다고 하면 친척들에게 어떤 회사를 다닌다고 쉽게 설명 하기가 쉽지 않다고 하시더군요. "그냥 컴퓨터로 뭐 하는 회사에요"라고 설명하면 친척분들이 "우리 아들한테 컴퓨터를 한대 사주려고 하는데..." 라던지 "우리집 컴퓨터가 갑자기 느려졌어" 같은 질문들을 하신다고 하더군요.)

  마지막으로, 많은 개발자들은 그들이 일하는 회사의 사회적 가치를 바라보기 시작했습니다. 소셜 네트워킹(Social networking) 회사나 블로그(Blog) 관련 회사들은 사람들이 하나로 모일 수 있도록 도와주며, 실제로 공해를 만들지 않습니다.  그래서 정밀유도무기산업이나 도덕적으로 위협이 되는 회계 부정관련 회사에 다난 것 보다 이런 일이 더 인기가 있는 것 같습니다.

  불행하게도, 평범한 채용 책임자가 이런 종류의 일을 위해 어떤 일을 할 수 있는지 전혀 생각이 나지 않습니다. 여러분은 여러분의 제품 라인업을 쿨 한 제품을 만드는 것으로 바꾸기 위해 노력할 수는 있겠지만, 실제로 실행하기에는 너무 어려운 방법입니다. 몇몇 회사들은 다음과 같은 방법들을 시행하고 있습니다. 

  ●  상위 지원자들에게는 그들이 참여할 프로젝트를 선택하게 하십시요. 

       오랬동안, Oracle은 MAP : the Multiple Alternative Program(복수의 대안 제도)를 시행하고 있습니다.이것은 매년 대졸 구직다들 중 상위 지원자들에게 제안되었습니다. 이것은 구직자들이 Oracle에 와서 한 두 주동안 둘러보고, 모든 그룹을 공개해서 방문해보면서 그들이 일하고 싶은 그룹을 선택하는 제도입니다. 

        Oracle에 계셨던 분이 이 제도가 좋은지 나쁜지 더 잘아시겠지만, 제 생각에는 이것은 좋은 생각입니다. 

  ●  필요하지 않더라도 멋진 새 기술을 사용하십시요.

       뉴욕에 있는 큰 투자은행은 프로그래머들에게 꽤 터프한 곳으로 알려져 있습니다. 끔찍한 일, 장시간 노동, 시끄러운 환경 그리고 독제자형 상사들이 이곳의 근무 조건입니다. 증권과 채권을 직접 팔고 거래하는 테스토스테론에 미친 유인원들이 3천만 달러의 보너스와 (종종 근처에 있던 프로그래머가 배달해 주는)치즈버거를 받는 회사의 왕족인 반면에 프로그래머들은 분명히 구별되는 3등 시민입니다. 이것이 일반적인 모습입니다. 어쨌든, 최고의 개발자들을 유지하기를 위하여 투자은행들은 두가지 전략을 세웠습니다. 막대한 보수(tons of money)를 주는 것과 프로그래머들이 무엇이든 몇번이고 그들이 배우고 싶어하는 새로운 프로그래밍 언어로 다시 작성할 수 있도록 자유를 주는 것입니다. 전체 거래 프로그램을 Lisp로 다시 짜고 싶습니까? 그건 마음대로 하세요. 가서 치즈버거나 사와요. 

       몇몇 프로그래머들은 어떤 프로그래밍 언어를 쓰던지 거의 신경쓰지 않습니다. 하지만 대부분은 흥미로운 새로운 기술을 가지고 일해볼 수 있는 기회를 원합니다. 오늘날에는 Phyton이나 Ruby on Rails일 것입니다. 3년전에는 C#이었고, 그 전에는 Java였습니다.

        지금 저는 여러분에게 작업을 위한 최고의 툴을 이야기하는 것이 아닙니다.  저는 여러분이 2년마다 뜨거운 오늘의 언어(역자주 : 오늘의 요리의 패러디 language-du-jour ) 로 프로그램을 다시 작성해야 한다는 이야기를 하는 것도 아닙니다. 하지만 여러분의 개발자들에게 새로운 언어나 프레임워크나 기술에 관하여 경험할 수 있는 기회를 줄 수 있다면, 그들은 더 행복해질 것입니다. 여러분이 핵심 프로그램은 감히 다시 작성하고 싶지 않을지라도, 내부 도구 프로그램이나 (Internal tools)나 크리티컬하지 않은 새로운 어플리케이션을 연습과제(Learning project)로써 새로운 언어로 작성해보게 하지 않을 이유는 없지 않습니까?


(7부에서 계속)
PS. 드디어 막바지 입니다. 7부에서 끝날 것 같습니다. 

저자에 관하여

Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


원문보기

Joel on Software


개발자 생태보고서
A Field Guide to Developers

by Joel Spolsky

 
Thursday, September 07, 2006

  - 이전글 보기 : 개발자 생태보고서 1
  - 이전글 보기 : 개발자 생태 보고서 2
  - 이전글 보기 : 개발자 생태 보고서 3
  - 이전글 보기 : 개발자 생태 보고서 4

  ●  독립과 자치

         제가 1999년 Fog Creek Software를 시작하기 전에, Juno에서 그만 두고려할 때 인사과에서 일반적인 퇴직 면접을 가졌습니다. 그리고 어쩐지, 뭔가에 홀린듯이 인사부서 사람에게 회사의 모든 경영이 잘못되었다고 말하게 되었습니다. 어떤 부분들은 저한테 전혀 이득될 것이 없고, 분명히 손해만 될것임에도 불구하고 저는 말해버렸습니다. 제가 불만을 표햇던 가장 큰 부분은 Juno 사의 히트 앤 런 방식의 경영 스타일이었습니다. 대개의 경우,  여러분도 아시다시피, 경영자는 사람들이 혼자서 조용히 그들이 업무를 완수할 수 있도록 내버려둬야 합니다. 하지만 때때로, 그들은 어떤 일의 아주 세세한 부분에 관여하여 그 일이 자신들이 원하는 방법 그대로 수행되어야 한다고 주장합니다. 이유도 없이 말이죠. 그리고는 그들은 또 다른 업무의 세세한 부분을 관리하여 합니다. 결과가 나타날 때 까지 충분히 기다리지도 않습니다. 예를 들면, Juno에 가입하는 입력창에 날짜가 어떻게 입력되야 하는지에 관해서 CEO부터 제 직속 상관까지 모든 사람들이 떠들고 다녔던 2~3일간의 짜증났던 기간을 기억합니다. 그들은 UI 디자이너로 훈련된 적도 없으며, 제게 이 이슈에 대하여 특정한 경우에 대하여 이해할 수 있도도록 설명할 시간도 없었습니다. 그렇지만, 그건 아무래도 좋습니다. 경영진은 이 이슈에 대하여 그들의 주장을 굽히려 하지 않았고, 제 반론을 들을 생각조차 안했습니다.

        기본적으로 여러분이 똑똑한 사람을 고용하고 싶으시다면 그들이 그들의 기술을 업무에 적용할 수 있도록 하셔야 합니다. 그들이 원한다면 경영진이 조언을 할 수도 있지만, "조언"이 명령으로 통역되는 일이 없도록 대단히 신중하셔야 합니다. 여러분이 좋은 사람들을 고용하셨다면, 기술적 이슈에 관하여 경영진은 최전선의 기술자들보다 아는 것이 적을 것입니다.

        개발자들은 그들의 기술 때문에 고용되기를 원하며, 전문가로 대접받고 그들의 전문분야에서 결정권을 갖기를 원합니다. 

  ●  정치는 안됨

        실제로, 정치는 두 명 이상의 사람이 모인 곳에서는 어디에서나 일어납니다. 자연스러운 일입니다. 제가 말하는 "정치는 안됨" 의 진짜 의미는 "역기능하는 정치는 안됨" 입니다. 프로그래머들은 매우 예민한 정의감을 갖고 있습니다. 코드는 동작할 수도 있고, 그렇지 않을 수도 있습니다. 코드를 테스트해서 버그를 찾으면 되기 때문에, 버그가 있는가 없는가에 대해서는 논쟁이 필요 없습니다. 프로그래밍의 세계는 매우 정확하고 엄격하게 질서가 잡혀 있습니다. 그리고, 수없이 많은 사람들이 프로그래밍의 세계로 발을 들여놓는 첫번째 이유는 정확하고, 순위가 분명하고, 실력위주의 사회에서 다른 논쟁없이 단지 '옳기" (Being right) 만 하면 승자가 될 수 있기 때문입니다.

       이것이 프로그래머들을 끌어들이기 위해 여러분이 만드셔야하는 환경중 한가지 입니다. 한 프로그래머가 "정치"에 관하여 불만을 이야기 한다면, 그것은 아주 정확하게 말해서, 기술적인 문제보다 더 심각한 문제란 뜻입니다. 단지 사장님이 좋아하기 때문에 업무를 수행하기 위한 최선의 언어가 아닌 특정 프로그래밍 언어를 사용하라는 말 보다 개발자를더 화나게 하는 것은 없습니다. 어떤 사람을 승진 시킴으로써 얻을 수 있는 분명한 이점보다 인간관계 능력에 의해 사람들이 승진하는 것보다 개발자들을 미치게 만드는 것은 없습니다.  조직에 높은 자리에 있는 분이나, 높은 분과 친한 사람에 의해서 기술적으로 떨어지는 일을 하도록 지시를 받는 것보다 개발자들에게 더 적대적인 것은 없습니다. 

     
       정치적인 이점을 잃어버릴지라도 기술적인 이점을들어 논쟁에서 승리하는 것 보다 더 개발자들을 만족시키는 것은 없습니다. 제가 Microsoft에서 일하기 시작했을 때, MacroMan이라는 그래픽 매크로 프로그램을 위한 프로그래밍 언어 프로젝트가 있었습니다. 이 프로젝트는 메이져급 프로젝트였지만 방향을 잘못 잡은 프로젝트 였습니다. 이 프로그래밍 언어는 진짜 프로그래머들을 좌절시켰는데, 그래픽 환경이 실제로 반복문이나 조건문을 구현할 수 있는 방법을 제공하지 못했습니다. 뿐만아니라, 프로그래머가 아닌 사람들이 알고리즘을 만드는데도 도움이 되지 못했습니다. 제가 MacroMan에 관하여 이의를 제기했을 때, 제 보스는 "누구도 열차를 탈선시킬 수는 없다네. 포기하게" 라고 말했습니다. 하지만 저는 계속해서 논쟁하고 논쟁하고 논쟁해서  - 저는 당시 대학을 갓 졸업했을 대였고, Microsoft의 누구와도 인맥이 없는 상태였습니다 - 마침내 사람들이 제 이야기를 듣게 되었고 MacroMan 프로젝트는 종료되었습니다. 제가 어떤 사람이었느냐가 문제가 아니라, 제가 옳았다는 것이 중요합니다. 이것이 프로그래머들에게 기쁨이 되는 비정치적인 조직입니다. 


  대체로, 여러분의 조직의 사회적 역동성에 초점을 맞추는 것은 건강하고 즐거운 직장을 만드는데 핵심 입니다. 그리고 이러한 직장이 프로그래머들을 유지하고, 끌어들일 것입니다.  (역자주 : 미국에서는 이직이 매우 흔한 일로, 현재 일하고 있는 개발자들을 유지(Retain)하는 것이 새로운 프로그래머를 뽑는 것 만큼이나 중요한 일입니다.)


(6부에서 계속)

PS. 이번 글은 엄청나게 길군요.

저자에 관하여
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  요즘 케이블에서 자주 보게되는 프로그램 중에 하나가 EBS에서 제작한 "극한직업" 이다. 대부분이 블루워커 일들이고 - 외과의사 도 있기는 했지만 - 특히 배 타는 어부들의 일이 자주 나온다. 막장보다 배 타는 것이 더 힘들다는 말이 사실인 것 같다. 이 프로그램을 보고 있으면, 세상에 힘들일이 정말 많지만, 도둑질이나 강도짓 안하고 자기 힘으로 열심히 사는 사람들이 더 많다는 생각이 든다. 힘들게 일하는 사람들 덕분에 우리의 식탁이 풍요롭고, 우리가 꼭 필요로하는 1차 산업이 유지되고 있다는 생각을 하는 사람은 많지 않을 것이다. 이 프로그램은 특히 중, 고등학생들이 볼만한 프로그램이라고 생각한다.

  오늘도 제주도 갈치잡이 어선의 이야기가 나왔다. 거의 잠을 못자며 밥먹을 시간도 없이, 비와 바람을 뚥고 조업을 하는 어부들을 보면서, 저렇게도 일을 하는구나, 저렇게도 배를 타는구나 란 생각을 한다. 내가 저 자리에 서서 일하는 모습은 어떠한 상황에서도 대입이 되지를 않는다.

  IT쪽의 일이 힘들다는 일을 많이 한다. 잔특근은 당연한 일이고, 월급은 적고, 끊임없이 공부해야만 살아남을 수 있고, 30대 후반만 되도 관리직으로 전환을 준비해야 하고 , 미래는 불안정하다는 등이 IT가 힘든 이유로 꼽힌다. 프로젝트 막판이 되면 회사에서 일주일에서 한달 정도 철야하는 일은 당연한거고, 더 작은 회사들은 아얘 1년 12달 365일 회사에 출근한다는 이야기도 한다. 내시경과 디스크 검사를 위한 MRI가 유행이라는 웃지못할 이야기도 한다. 심지어, 영국 EA에서도 우리 못지않은 험악한 근로조건 때문에, 한 프로그래머의 여자친구가 블로그에 올린 비난 글 한편이 큰 파장을 불러일으킨 일이 있다.

  가슴에 손을 얻고 생각해 볼때, 배 타는 것보다 더 힘들지는 않다. 다행히 우리 회사는 육체적 근로 조건은 조금씩 조금씩 나아지고 있고, 잔특근비는 줄어도 휴가는 좀 더 늘어나고, 관리자들도 휴가에 관해서는 조금씩 관대해지고 있다는 것을 매년 느낀다. 매년 근로조건은 조금씩 나아지고 있다. (우리 회사만 좋아지고 있는 걸지도 모르겠다. )

  그럼에도, 여전히 IT는 힘들다고 생각한다. 그 이유는, 배를 타시는 분들은 30년, 40년도 타신다. 자신이 스스로 내리기 전에는 내리라고 강요하는 사람은 없다. 극한직업 프로그램에 나오시는 분들도, 선장님들은 30년 이상의 경력자시고, 선원 분들도 그에 못지 않은 기간 배를 타신 분들이다. 그럼, IT는 어떨까? 솔직히, 입사할 때 부터 15년을 버티는 것이 목표였다. 지금 같아서는, 10년 이상 개발을 하는 것이 목표다. 관리직으로 넘어가지 않고 좋아하는 일을 계속 할 수 있다면 정말 행복할텐데, 과연 그런 내 욕심이 받아들여질지는 의문이다.

  더 어려운 것은, 발전하지 못하고 가진 것을 빼앗기기만 한다는 느낌이 다는 것이다. 의사는 수술을 할 수록 자신의 기술이 느는 것을 느낄 것이다. 요리사도, 도공도, 하다못해 이삿짐을 나르는 분들도 경력이 쌓이면 쌓일 수록 자신이 나아지고 있다고 느낄 것이다. 그러나... 지금 내 포지션에서 이런 부분이 결여되어 있다. 입사 1년차때 내가 하던 일이나 4년차때 하는 일이 별반 차이가 없는 것. 이것이 지금 내가 받고 있는 가장 큰 스트레스 인 것 같다. 마치, 덤벨을 계속해서 다는데도 불구하고 알통이 생기지 않는 것 같은, 그래서 휴일에도 컴퓨터 앞을 벗어나면 뭔가 큰일이 날 것 같고, 손에서 책을 놓으면 큰 죄를 짓는 듯한 느낌. 이게 지금 내가 받는 가장 큰 스트레스이다.

  단언컨데. IT는 극한직업이 맞다. 어부는 배에서 내리고도 내일 고기잡는 법을 잊을까 걱정하지는 않지 않는가. 나는... 내 기술이 하루아침에 무용지물이 될 수 있다는 생각을 한다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.05.02 00:43 신고
    댓글 주소 수정/삭제 댓글
    포스팅 하신 글 처럼 국내 IT 개발자의 환경이나 대우가 나날히 낮아지는 건 사실입니다.
    근데 말씀 하시는 것 처럼 IT 의 산업이 자신에게서 자꾸 발전보다는 자신의 것에서 빼앗아 가는건
    아닐까 하는 생각을 할수도 있습니다. 저 역시 그랬엇구요.
    뭐 모든 것이 그렇진 않겠지만 다들 지식산업의 막장이라는 말을 하면서 밤새워 일하고 있죠... 이짓(?)해서 과연 뭐가 될까 라는 생각도 합니다. 하지만 IT 라는 것은 새로운 것에 끊임없이 노력하는 것에 기반을 둔 산업입니다. 시대의 트랜드에 변화가 많은 산업이긴 합니다. 언급하신 의사와 다른 것이 의사역시
    그 일을 하면서 노하우가 생긴다고 하지만 전문의나 다른 과목에 대한 선 지식을 요충하기 위해서는
    그 사람들 역시 밤새워서 별도의 자신에 대한 개발을 진행합니다. 뭐 그 의사와는 다른 성향이기겠지만
    우리 IT 산업인들은 조금 더 힘든 상황에 있긴 합니다.. 근데 아예 빛이 없는 것은 아니겟죠..?
    시대의 흐름을 잘 파악하고 자신의 일에서 더아가기 위해 준비 하는 자세를 가지고 있으면
    언제든 새로운 기회를 찾아볼 수 잇다는 것이 이 IT의 단점이자 장점이겠죠? 기술의 생명이 짧아지는 주기
    가 있지만 기존에 자신이 가진 인프라에서 새로운 것을 창출하고 만들어가고자 하는 자세라면..
    빛을 볼 수 있으니까요..
    IT programmer 직종중에 windows mobile 하위 Stack 알고리즘가능한 개발자들의 연봉이 갑자기
    너무나 올라버렸네요 그 사람들은 스마트폰에 대한 흐름을 보고 미리 대처한 결과겠죠...?
    돈을 자기고 가치를 말씀드리는게 외람된 말이지만
    그만큼 트랜드형 개발자들은 높은 우대를 받고 있습니다
    그 업무에 대한 개발자가 없어서
    요즘 중소기업이나 대기업측에서도 해당 엔지니어들을 뽑느라 고심하는 거겠죠. 제가 다니는 곳도
    마찬가지구요..
    끊임없는 새로운 것들과 지금 하고 잇는 것들의 기술적 인프라..
    그런 것들이 생각하시고 계신 IT 개발자의 미래를 다르게 변화시킬수 있다는 말을 전하고 싶네요..

    어쩌면 저도 그래서 밤에 Apple SDK 나 Windows Mobile 포팅작업을 하고 있는지도 모르겠네요

    힘내세요 ^^
    두서 없이 몇자 적고 갑니다.
    • 2009.05.02 09:28 신고
      댓글 주소 수정/삭제
      긴 답글 감사합니다.

      가장 답답한 것은 말씀하신 것 같은 기회가 안보이는 것 같습니다. 새로운 기술이 뜰 것 같은 것은 보이는데, 뭔가 새로운 것을 해볼 기회가 주어지지 않는 것이 현재 제 상황이랍니다.
  2. 2009.05.02 12:20
    댓글 주소 수정/삭제 댓글
    비밀댓글입니다
  3. 2009.05.03 22:32 신고
    댓글 주소 수정/삭제 댓글
    극한이라고 까지는 생각하지 않습니다만.. 그래도 너무 현실적으로 보여준다면 시청률이 안나올것 같은데요?ㅋㅋ
    • 2009.05.04 00:36 신고
      댓글 주소 수정/삭제
      그래도 한번 찍어는 봤으면 좋겠습니다. 프로젝트 막판 3일만 찍는다면 어부들 못지 않을지도 모르지요.
  4. 2009.05.03 23:33
    댓글 주소 수정/삭제 댓글
    비밀댓글입니다


프로그래밍은 상상이다
국내도서>컴퓨터/인터넷
저자 : 임백준
출판 : 한빛미디어 2008.09.01
상세보기

  프로그래밍에 관한 여러권의 칼럼과 에세이, 소설을 써온 임백준 님의 최신작이다. 서점에 갔다가 새 책이 나온 것을 보고 얼른 집어온 것을 이제야 다 읽었다. 역시나, 수준 높은 내용과 빼어난 문장이었다. 한국에도 이런 칼럼을 쓰시는 분들이 좀 더 늘어나야 할텐데 아직은 좀 아쉽다. 

  이 책은 기존에 여러 IT잡지들에 연재되었던 글을 모은 것이다. 저자의 개인 경험과 프로그래밍 개발 현장에서 현재 진행형으로 벌어지고 있는 이슈들을 다루고 있다. 이 책을 읽는 것은  현대 IT의 트렌드와 이슈들에 관한 좋은 정보들 얻는 가장 좋은 방법이 될 것이다. 특히 인상적인 부분은 웹 2.0과 메쉬업에 관한 내용이었다. 메쉬업에 관한 부분은 인터넷을 사용하면서도 부족했던 부분들을 채워줄 수 있는 기솔이다. 웹 이외의 모든 전자상품에서도 사용자 경험을 축적해 사용자에게 더 나은 결과를 돌려주는 알고리즘이 응용될 수 있다. 특히 동음이의어에 대한 처리와, 같은 단어가 다른 의미로 사용되는 경우 (ex. Blitzkrieg 에는 "전격전" (역사) 와 실시간 전력시뮬레이션(게임) 과 팝그룹(음악) 의 세가지 결과가 검색된다.) 에 대하여 사용자가 정말로 찾고 싶어했던 결과를 돌려주기 위해서는 사용자의 입력을 분석하여 전후문맥을 찾아주는 방법이 필요하다. 또 다른 예를 들면, 전화번호부에 동명 이인이 있는 경우 - 한국 여자 이름은 동명이인이 특히 많다 - 최근에 전화 기록과 검색결과를 참조하여 어떤 사람을 찾는 것인지 전화번호부가 먼저 알려줄 수도 있을 것이다.

  IT분야에서 일하기를 원하거나 일하고 있는 분들이라면 한번쯤은 읽어볼 필요가 있다. 이 책 뿐만 아니라 임백준 님의 다른 책들도 IT로 밥먹는 사람들이라면 꼭 읽어보길 권한다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.05.01 20:09 신고
    댓글 주소 수정/삭제 댓글
    임백준씨 저서
    뉴욕의 프로그래머를 매우 흥미롭게 봤었습니다.
    이 책도 한번 봐야겠군요^^
  2. 2009.05.01 21:29 신고
    댓글 주소 수정/삭제 댓글
    전자공학과이지만... C++을 배우고 있는 제게도 아주 좋은 교재가 될거 같습니다!
    • 2009.05.01 21:52 신고
      댓글 주소 수정/삭제
      프로그래밍을 공부하시는군요. S/W 쪽으로 진로를 생각하신다면 역시 좋은 책으로 추천해 드릴만 합니다.



원문보기

Joel on Software


개발자 생태보고서
A Field Guide to Developers

by Joel Spolsky

 
Thursday, September 07, 2006

  - 이전글 보기 : 개발자 생태보고서 1
  - 이전글 보기 : 개발자 생태 보고서 2
  - 이전글 보기 : 개발자 생태 보고서 3

장난감들

  비슷한 논리가 다른 개발자들의 장남감들에도 적용됩니다. 여러분의 개발자들에게 최신형 컴퓨터와 최소한 두 대의 21인치 LCD 모니터 (혹은 한 대의 30인치 LCD) , 그리고 아마존에서 그들의 원하는 기술 서적을 무제한 살 수 있는 권리를 주지 않을 이유는 전혀 없습니다. 이것들은 분명히 생산성을 올려주기 때문입니다. 하지만 지금 우리의 논의에서 이 장난감들이 갖는 더 중요한 이유는, 이것들이 채용을 위한 결정적인 도구이기 때문입니다. 특히, 대부분의 회사가 프로그래머들을 부속품이나 타이피스트 취급하는 현실세계에서 더 그렇습니다. "왜 당신에게 그렇게 큰 모니터가 필요한데요? 15인치 CRT 모니터에 문제가 있습니까? 내가 어렸을 때만 해도..."  말하면서 말이죠.

개발자들의 사회 생활


  소프트웨어 개발자들은 보통사람들하고 정말로 다르지 않습니다. 물론, 저도 압니다. 오늘날 개발자들을 전형적인 자폐증상이 있는 괴짜들이고, 사람들과의 관계에 적응하지 못하는 사람들로 생각하는 것은 흔한 일입니다. 하지만, 이것은 전혀 사실이 아니고, 심지어 자폐증상이 있는 괴짜들조차 직장의 사회적 측면을 생각합니다. 이런 점들을 포함해서 말이죠.

  ●  조직안에서 프로그래머들이 어떤 대접을 받는가? 

       그들은 유능한 인력입니까? 아니면 타이피스트 입니까? 회사의 경영팀은 엔지니어들이나 전직 프로그래머들로 구성되어 있습니까? 개발자들이 컨퍼런스에 참석하러 갈 때, 비행기 1등석을 타고 갑니까? (저는 이것이 돈 낭비라고 생각하지 않습니다. 스타(연예인)들은 1등석을 탑니다. 이 사실에 익숙해 지세요.) 그들이 입사 면접을 위해 비행기를 타고 올 때, 그들을 리무진 픽업으로 모셔옵니까? 아니면 그들 스스로 사무실까지 찾아오게합니까? 다른 모든 면이 동일하다면, 개발자들은 그들을 스타 대접하는 회사를 더 좋아할 것입니다.  만약 여러분의 회사의 CEO가 왜 스타 개발자들(prima donna developers)이 계속해서 손목 받침대나 대형 모니터나 편안한 의자같은 것들을 요구하는지 이해하지 못하는 지르퉁한 영업 출신 인사라면, 여러분의 회사는 (개발자를 대하는) 태도를 고칠 필요가 있습니다. 뛰어난 개발자들을 존중하지 않는다면, 여러분은 그들을 얻지 못할 것입니다.  (역자주 : 지르퉁하다 : 못마땅해하며 화내다. grouchy)
        

  ●  그들의 동료는 어떤 사람들인가?

        채용 면접날 프로그래머들이 바짝 주의를 기울이는 것 중 하나는 그들이 만나는 사람들입니다. 그들은 친절한가? 더 중요한 점 : 그들은 똑똑한가(Are they smart)? 저는 Bell Labs의 자회사인 Bellcore에서 하계 인턴쉽으로 일한 적이 있는데, 제가 만났던 모든 사람들이 계속해서 같은 이야기를 했었습니다. "Bellcore에서 일하는 가장 큰 장점은 사람들이다"  라고요. 

         이 말은, 여러분에게 잘라 버릴 수 없는 지르퉁한 개발자가 한명이라도 있다면, 최소한 그를 면접관에서 제외시키십시요. 그리고 활기차고, 사교적이고, 크루즈-디렉터 타입의 개발자가 있다면 그를 면접관에 포함시키십시요. (역자주 : 크루즈 디렉터 : 여객선에서 일하는 선원들은 승객들에게 웃으면서 먼저 인사하고 친절하지요) 이 사실을 기억하십시요. 구직자들이 면접후 집에 돌아가서 어느 회사로 갈지 고민 할 때, 그들이 만났던 사람들이 모두 침울했다면 여러분의 회사에 대하여 좋은 기억을 떠올릴 수가 없을겁니다. 

         덧붙여 말씀드리면, Fog Creek의 최초의 채용 규칙은 Microsoft에서 훔쳐온 것이었습니다. 그것은 "똑똑하고, 일을 되게 하는 사람"(Smart, and Gets Things Done) 입니다. 회사를 시작하기 전부터, 우리는 세번째 규칙을 추가해야 한다는 것을 깨달았습니다. 그 규칙은 "바보는 안됨" (Not a jerk) 입니다. Microsoft 시절을 되돌아보면, 바보가 되지 않는 것은 직장을 얻는데 중요하지 않았습니다. 그럼에도 불구하고, 다른 사람에게 친절하게 대하는 것이 중요하다는 말이 단지 립서비는 아니었다고 확신합니다. 아마도 Microsoft도 지원자들이 바보라고 불합격 시키지는 않았을 겁니다. 사실은, 바보가되는 것이 종종 상급 관리자가 되기 위한 선행조건으로 여겨지기도 합니다. 바보들을 감내하는 회사는 비지니스적 측면에서는 타격을 받지 않는 것처럼 보입니디만, 채용 측면에서는 타격을 받습니다. 누가 바보들과 일하기를 원하겠습니까?  (역자주 : Jerk : 《속어·경멸》 세상 물정을 모르는 사람, 바보; 《미·속어》 = SODA JERK. )


(5부에서 계속)


저자에 관하여




Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절



원문보기

Joel on Software


개발자 생태보고서
A Field Guide to Developers

by Joel Spolsky

 
Thursday, September 07, 2006

  - 이전글 보기 : 개발자 생태보고서 1
  - 이전글 보기 : 개발자 생태보고서 2

물리적 작업공간 (The physical workspace)

  물리적 작업공간에 관해서는 개인 사무실보다 뭔가가 더 있습니다.  한 지원자가 여러분의 회사에 인터뷰를 왔을 때, 그는 직원들이 일하는 곳을 보게될 것입니다. 그리고 그 곳에서 자신이 일하고 있는 모습을 그려볼 것입니다. 만약 사무실이 즐겁고, 밝고, 좋은 동료들이 있고, 모든 것이 새것이고 깨끗하다면 지원자들은 행복한 생각을 갖게 될 것입니다. 만약 사무실이 붐비고, 카펫은 낡았고 페인트 칠되지 않은 벽에 팀 사람들이 줄지어선 사진 위에 TEAMWORK라고 크게 씌여진 포스터가 걸려있다면, 그들은 딜버트(Dilbert : 역자주 : 미국 회사원의 회한을 그린 만화)와 같은 생각을 하게 될겁니다.

  많은 기술 인력들이 일반적인 사무환경에 대해서는 신경쓰지 않는 다는 점은 주목할 만 합니다. 사실, 좋은 사무실의 장점에 익숙해져있는 사람들은 자기 사무실의 일부 단점들을 알아보지 못합니다.

  지원자의 관점에서, 솔직하게 생각해보세요 :

  ●  그들이 우리 사무실의 입지를 어떻게 생각할까요? "버팔로" 라고 말하는 것이 "오스틴" 이라고 말하는 것과 얼마나 다르게 들릴까요? 사람들이 "디트로이트"로 이사오는 것을 정말로 원할까요? 만약 여러분이 "버팔로"나 "디트로이트"에 있다면, 최소한 채용 인터뷰의 대부분을 9월에 시도해 볼 수 있겠습니까? (역자 주 : 우리나라 회사들이 최종 면접을 포항이나 수원, 혹은 탕정에서 하는 것을 생각해 보십시요. 역삼동에 있는 회사와 제주에 있는 회사 중 어느쪽이 채용에 유리할까요?)

  ●  그들이 출근하는 길에 어떤 경험을 하게 될까요? 무엇을 보나요? 그들이 보는 것이 깨끗하고 재미있는 장소인가요? 생화(live)인 팜 나무와 분수가 있는 로비정원이 있습니까? 아니면 슬럼가에 있는 죽어가는 옥수수 화분(corn plants)과 오래전 뉴스위크가 있는  공영치과(government detal clinic) 같은가요?

  ●  그들의 작업공간은 어떻게 보입니까? 모든 것들이 새 것이고 반짝반짝 하나요? 아니면 여전히 거대한 노란색 "TEAM BANANA" 마크를 분할 프틴트로 출력하여 붙여놓고 계십니까? (역자 주 : "TEAM BANANA"는 우리식으로는 "청팀" "백팀" 정도의 흔한 팀 이름입니다. 분할 프린트는 A4 용지를 이어붙여서 큰 그림을 만들 수 있도록 해주는 기능으로 대부분의 프린터가 지원합니다. 별로 돈을 안들이고 만들 수 있지요)

  ●  책상은 어떻게 보입니까? 프로그래머들은 여러 대의 대형 LCD를 사용합니까? 아니면 한 대의 CRT 모니터를 사용합니까? 그들의 의자는 Aeron 제품입니까? 아니면 Staples Specials 입니까? (역자 주 : Aeron은 유명 가구회사 제품입니다. Staples Specials 는 우리식으로 하면 이마트 특별할인제품 정도로 이해하시면 됩니다.)

  제가 잠시동안 유명한 Aeron의자에 대해서 설명드리면, Herman Miller 에 의해서 만들어진 제품입니다. 가격은 약 900 달러 정도 합니다. OfficeDepot이나 Staples의 싸구려 제품에 비하면 약 800 달러 정도 비씨지요.

  이 의자는 싸구려 의자보다 월씬 더 편합니다. 적당한 사이즈의 의자를 잘 조정해서 앉으면 대부분의 사람들은 하루 종일 앉아있어도 불편함을 모릅니다. 등받이와 시트는 망사 형태로, 바람이 잘 통해서 땀이 차지 않습니다. 인체공학적으로 설계된, 고무를 덧된 최신 모델은 매우 뛰어납니다.

  이 의자들은 싸구려 의자보다 오래쓸 수 있습니다. 우리는 6년간의 사업기간동안 모든 Aeron 의자들을 문자 그대로 새 것같이 사용하고 있습니다. 저는 보는 사람마다 2000년에 구입한 의자와 석달전에 구입한 의자의 차이점을 찾아보라고 합니다. 이 의자들은 최소한 10년은 넉넉히 갑니다. 싸구려 의자들은 문자 그대로 몇달 뒤면 부셔지기 시작합니다. Aeron 의자만큼 오래 쓰려면 최소한 네 개의 100 달러 짜리 의자가 필요합니다.

  결국 Aeron의자는 실제로는 10년 이상 사용하는데 500 달러가 드는 것과 같습니다. 1년에 50달러 꼴이고 이는 프로그래머 한 명당 한 주에 1달러의 비용이 드는 것과 같습니다.

  좋은 화장실 휴지도 한 롤에 1달러 정도 합니다. 아마도 여러분 회사의 프로그래머도 일주일에 휴지 한 롤은 사용할겁니다.

  따라서, 프로그래머들의 의자를 Aeron 의자로 업그레이드 해주는 것은 화장실 휴지를 한 롤 더 사용하는 것과 말 그대로 동일한 비용이 듭니다. 제가 단언컨데, 만약 여러분이 화장실 휴지 비용을 올리겠다는 예산 협의회에 올린다면, 그들은 단호히 이렇게 말할겁니다. "쓸데없는 일 하지 마세요. 우리는 다뤄야 할 이슈가 많아요"

  Aeron의자는, 불행히도, 벤처 회사에서 쓰기에는 사치스럽다는 평판으로 빛이 바래 있습니다. 이 의자는 어떻해서인지 닷 컴 버블속에 벤처 투자사의 자금이 낭비되는 일의 부끄러운 상징이 되어버렸습니다. 이 의자는 얼마나 오래 쓸 수 있는지를 생각하면 별로 비싼 것이 아니지만 말이죠. 사실, 의자에 앉아서 하루 여덟 시간을 일하는 것을 생각하면, 심지어 가장 고급 모델을 살 지라도, 고무 받침대와 끝내주는 뒷모습(tailfins)을 갖춘 이 의자를 사용해서 벌 수 있는 돈에 비하여 열라 싼 것입니다.

(4부에서 계속)

[역자 주] 사실, 번역 하는 내내 제 상황이 생각나서 많이 우울해졌습니다. 조엘은 자기 회사에 더 좋은 개발자를 모셔오기 위해서 의자 하나까지도 더 좋은 것을 갖추려고 고민을 하는데, 우리회사는 비용절감한다고 화장실 휴지까지도 더 싼걸로 바꾸고 있거든요. 개발자들이 대접받을 자격이 없는건지, 경영자들이 개발자들을 무시하는 건지... 과연 누가 잘못하고 있는걸까요? 언제나 저를 모셔가려는 사람들이 나올 정도로 뛰어난 개발자가 될 수 있을까요? 어쨌든, 번역은 계속됩니다.


저자에 관하여
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.04.30 17:34 신고
    댓글 주소 수정/삭제 댓글
    저도 사실 우울해 집니다. ㅎㅎ 뭐랄까 현실이라기 보다는 판타지 읽는듯한 느낌이에요;;

    하지만 뭐..덕분에 여러가지로 생각해볼 수 있습니다. (어떤 방향으로든지요~)

    감사합니다!!

오늘 하루 종일 기분이 몹시 우울하다. 오늘 기분의 흐름은 이러했다. 

1. 우현히  회사에서  "어느 과학자의 7년 '출연연' 체험기" 를 읽었다. 음. 지금 원문 사이트를 가보니 더 우울하다. MB 정부 이후, 아니 7년 체험기니까 그 이전 정부를 포함하는 이야기일 것이다. 결론부터 말하면 이공계 찬밥이란 말이다. 그 이전에는 이런 공무원과 얽혀서 일하는 이공계가 특히 더 짜증나는 상황을 많이 겪는다는 글을 읽은 적이 있었다. 예를 들어, 출연연에서 일할 때는 개무시하던 9급 공무원이 대학 교수가 되서 돌아오자 굽신거리기가 얼마나 심한지, 자기를 알아 보지도 못하더라 같은 이야기들 말이다. 이 글도 상황이 별반 다르지 않다. 우울함이 시작되었다.

2. 내가 미쳤지. 이 시점에 다시 찾아 읽은 글이 "공생전" 이었다. 각주와 후기까지 꼼꼼히 읽었다. 농담같이 않다. 특히나 카이스트나 포공, 서울대 출신은 우리 회사에서도 거의 찾아보기 어렵다는 점에서 이 글이 현실임을 잘 알고 있다. (혹은 이들은 따로 뽑는다는 얘기가 있었다" 어느쪽이든, 나같은 평범한 개발자는 하고 싶은 일을 하기 보다는 소모될 가능성이 상당하다는 얘기가 된다. 공생전 저자와 친구들처럼 밋딧릿을 치던지 다른 분야로 옮길 여력도 없는 사람에게는 우울함만 남는다.

3. 거기에 쐐기를 박은게, 오늘 인사를 하던, 이직하는 후배였다. 공기업 전산실로 옮긴다고 한다. 뭔가, 대단하다는 생각이 먼저 들었다. 지금 부서를 떠난다는 생각도 별로 해본적이 없는데, 후배가 어느새 준비해서 이직을 한다는 것이 참 대단하다는 생각이 들었고, 내가 작아보였다. 이것 참... 지금 내 바탕화면은 곧 이사할 아파트 평면도가 올려져있다. 어제 계약을 할 때만해도 너무너무 기분이 좋았는데, 오늘 갑자기, 이걸 과연 잘한걸까 라는 생각이 들었다. 이걸 감당한다는 것은 곧 앞으로 적어도 2년은 더 이곳에서 살면서 회사를 다닐 것이라는 얘기인데, 정말 잘한걸까, 후회하지 않을까? 결혼이고 뭐고 지금이라도 다른 방향을 모색해봐야 하는 것은 아닐까란 생각이 머리속을 복잡하게 했다. 내가 들어갈 집에 살던 분은 고졸로 입사해서 10년 가까이 회사를 다니다가 결혼을 미루고 여자 친구와 유학을 결정했다고 한다. 내가 그 집을 인수하는게 잘하는 건지 모르겠다. 정작, 유학은 내가 나가야하는 것은 아닌가... 하고 생각이 많아진다.

4. 요즘 번역하고 있는 조엘의 글은 뛰어난 개발자를 "모시기" 위해서 애쓰는 이야기가 계속해서 나온다. 좋은 개발자를 얻기 위해 투자하는 것을 아까와하지 않아야 한다는 그의 주장은 천국의 이야기를 듣는 것 같다. 아마도 몇년 더 지나면 관리자로 전향할 것은 요구받게 될텐데, 난 재미있는 개발을 계속 하고 싶다. 아키텍트나 프로그램 매니져 같은 직무를 해보고 싶은데, 이 조직에는 그런 포지션 조차 없고, 내 선임자들이 나를 독립시키거나 할 것 같지도 않다. 이게 가장 큰 우울의 이유일지도 모른다. 발전이 보이지 않는다는 것. 시키는 일만 하게 될 것이라는 것. 조직이 답답하게 느껴진다는 것. 끝모를, 아니 눈에 보이는 불안감.

5. 어느 사원은 입사 3년차를 맞는 소감을 "삼년이 지났지만, 이길은 아닌가보다" 라고 적었다.  대한민국 이공계가 우울해서인지, 우리회사가 우울해서인지, 아니면 이래저래 이사를 앞두고 내가 심난해서인지, 좋은 칼럼 번역하느라 내 눈높이가 너무 높아져 버린 것인지. 무엇이 진짜 원인인지는 모르겠지만, (아마도 복합적일 것이겠다)  난 오늘 몹시 우울하다. 아 우울해.

6. 마지막으로... 다음주 쯤 지방에 친구 결혼식이 있어 내려갈 일이 생겼는데, 하루 일찍 내려가서 방을 같이 쓸 사람을 찾았더니, 또 다른 친구가 자기 여자친구와 내려가서 내 옆방을 잡겠단다. 노총각을 말려죽일 생각인가. 사실 이게 제일 큰 이유일거다 ㅋ
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.04.29 00:40 신고
    댓글 주소 수정/삭제 댓글
    지그프리드님 덕분에 공생전과 대덕넷의 기사를 읽게 되었습니다.
    잘 보고 갑니다. :(



원문보기

Joel on Software


개발자 생태보고서
A Field Guide to Developers

by Joel Spolsky

 
Thursday, September 07, 2006

  - 이전글 보기 : 개발자 생태보고서 1


  어땠든, 저는 "왜 개인 사무실이 소프트웨어 개발자들의 생산성을 향상시키는가?", "단지 주변의 소음을 줄이기 위해 헤드셋을 착용한 프로그래머가 품질이 낮은 결과를 내놓는 현상", "개발자들에게 개인 사무실을 만들어주기 위한 비용이 생각보다 비용이 많이 들지 않는 것" 등에 관한 논의를 다시 할 생각은 없습니다. 이런 것들에 관해서는 이미 말해왔습니다. (역자 주 : 그는 무려 10년 이상 칼럼을 써왔습니다. 그의 책이나 다른 글들을 찾아보세요.) 오늘은 개발자를 채용하는 일과, 채용에 있어서 개인 사무실의 의미에 관하여 이야기 할 것입니다.




  생산성에 관하여 어떠한 생각을 갖고 계시던지간에, 그리고 평등한 작업 공간에 대하여 어떤 생각을 갖고 계시던간에, 다음 두 가지 사실에는 반론의 여지가 없습니다.

  1. 개인 사무실이 더 상급(Higher status) 입니다.
  2. 칸막이나 다른 공용 공간은 (다른 사람과 같이 있어서) 불편합니다.

  이 두가지 사실에 비추어 볼 때 결론은 프로그래머들은 개인 사무실이 제공되는 직장(Job offer)을 더 좋아한다는 것입니다. 특히, 그 사무실에 닫히는 문과, 창문이 있고 전망까지 좋다면 말이죠.

  불행한 점은, 채용을 쉽게 만들어줄 수 있는 이런 일들을 여러분의 권한으로는 할 수 없다는 사실입니다. 심지어 CEO나 창업자도 벤쳐 투자사에 의지하고 있다면, 개일 사무실을 만드는 일에 제제를 받을 수 있습니다. 대부분의 회사들은 5년에서 10년마다 이사를 하거나 배치를 변경시킬 뿐입니다. 작은 벤쳐회사들은 아마도 개인 사무실을 감당하지 못할 지도 모릅니다. 몇몇 아주 혁신적인 회사들이 있는데, 이 회사들은 종종, 10년에 한 번 꼴로 협의회를 열어서 어디로 이사를 할 것인지, 어떤 곳에서 직원들이 일을 해야 하는지에 관해서 결정을 합니다. 이 협의회에는 사무실 매니저들의 비서들과 큰 건축회사의 실무 설계사들 - 이 설계사들은 "열린 공간이 열린 회사를 만든다"는 건축학교의 동화를 믿는 경향이 있습니다 - 이 참여합니다만, 개발자들이나 개발실에는 문이 닫혀있거나 어떠한 의견도 개진할 수 없습니다. 개발자들에게 개인 사무실을 제공하는 것이 사실상 불가능한 이유에 관한 여러가지 변명들만 늘어놓을 뿐이지요. (역자주 : 종종(often)과 10년에 한번 (once every tem years) 가 한 문장에 나오고 있습니다. 말이 안되지만, 원문이 그렇습니다.)

  이것은 일종의 스캔들입니다. 저는 선한 싸룸을 위하여 계속해서 싸워나갈 것입니다. 하지만, 한편으로 보면, 개인 사무실을 제공하는 것은 불가능한 일이 아닙니다. 우리회사는 정규직(Full-time) 프로그래머들에게 그렇게 하고 있습니다. 대부분의 경우, 심지어 사무실 임대료가 세계에서 가장 비싼 뉴욕에서조차도 해냈습니다. 이 개인 사무실이 Fog Creek에서 일하는 것을 좋아하게 만든다는 데는 의심의 여지가 없습니다. 그러므로, 여러분 모두가 계속해서 이 일이 불가능하다고 주장하시겠다면, 그렇게 하십시요. 저는 그냥 개인 사무실을 제공하는 것이 우리회사의 경쟁력있는 장점이 되도록 유지하겠습니다.


(3부에서 계속)


저자에 관하여

Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


원문보기

Joel on Software


개발자 생태보고서
A Field Guide to Developers

by Joel Spolsky

 
Thursday, September 07, 2006

  여러분은 적당한 모든 곳에 광고를 하고, 끝내주는 인턴쉽 프로그램을 갖고 있고, 여러분이 원하는모든 사람과 인터뷰를 할 수는 있습니다. 불행히도, 이 모든 노력에도 불구하고 뛰어난 프로그래머들이 여러분을 위해 일하기를 원하지 않는다면, 그들은 여러분의 회사에 일하러 오지 않을 겁니다. 그래서, 이번 장을 개발자 생태보고서(Field guide)로써 할애하겠습니다. 그들이 무엇을 기대하고, 그들의 직장에서 무엇을 좋아하고 싫어하는지, 그리고 최고 수준의 개발자들의 최우선으로 선택하는 것은 어떤 것들인지 이갸기 해보겠습니다.

개인 사무실

  작년에, 저는 예일 대에서 있었던 컴퓨터 과학 컨퍼런스에 참석했습니다. 그곳에서, 실리콘 벨리의 베테랑이자 벤처 캐피탈의 펀딩을 받아 설립된 벤처회사의 창립자(혹은 리더)로써 매우 존경받는 역할의 한 연사가 피플웨어(Peopleware)란 책을 들어올렸습니다.  

  "여러분은 이 책을 읽으셔야만 합니다." 그가 말했습니다. "이것은 소프트웨어 회사를 운영하는 방법에 관한 바이블입니다. 이 책은 소프트웨어 회사의 운영 방법에 대한 책들중 세상에서 가장 중요한 책입니다. " 

  저는 그의 말에 동의 해야만 했습니다. 피플웨어는 대단한 책입니다. 이 책의 주제들 중 가장 중요하고, 또한 가장 논쟁의 대상이 되는 것은 프로그래머들이 생산적으로 일하기를 원한다면 프로그래머들에게 조용한 공간 - 아마도 개인 사무실이겠지요 - 을 많이 제공해야만 한다는 것입니다. 저자들 - DeMarco와 Lister - 은 이 주제에 관해서 계속해서 이야기 합니다. 

  강연이 끝난 뒤에, 저는 그 연사에게 가서 말을 걸었습니다. "피플웨어에 관한 당신의 생각에 저도 동감합니다. 그런데, 당신의 벤처회하들에는 개발자들을 위한 개인 사무실이 있습니까?"

  "물론 아니죠" 그가 말했습니다. 벤처 투자사들(VCs : Venture Capital)을 절대로 그렇게 하도록 두지 않을겁니다."

  흠.

  "하지만 이것은 피플웨어에서 이야기하는 것들 중 가장 중요한 것일 겁니다."

  "예. 그렇지만 그것은 싸움을 시작하게 만들겁니다. 벤처 투자사들에게는, 개인사무실은 그들의 돈을 낭비하는 것처럼 보일거에요." 

  실리콘 벨리에는 넓고 열린 공간에 수많은 개발자들을 우겨넣고 일하게 만들라고 요구하는 강한 전통이 있습니다. 개인 사무실이 훨씬 더 생산성이 높다는 많은 증거가 있음에도 말입니다. 몇몇 증거들은 제가 이 사이트에서도 여러번 반복해서 밝혔습니다. 저는 동의하지 않습니다만, 프로그래머들은 설사 생산성이 떨어지게 될 지라도 다른 사람들과 함께하기를 좋아합니다. 저는 다른 사람들에게 이 점을 진정으로 이해시키지는 못했습니다. 이 것을 이해시키는 것은 힘겨운 싸움입니다. 

  저는 심지어 프로그래머들이 이렇게 말하는 것을 들은 적도 있습니다. "예, 우리는 모두 칸막이 속에서 일합니다. 하지만, 모든 사람이 - 위로는 CEO 까지 포함해서 - 칸막이 속에서 일하고 있지 않습니까!" 

  "CEO라구요? 정말로 CEO께서도 칸막이 속에서 일하십니까?"

  "물론, 그에게도 칸막이로 된 자리가 있습니다. 사실은 회의실이 하나 있는데, 그는 거기서 모든 중요한 회의를 진행 한다고 할 수 있겠습니다만...."

  오~홍, 매우 일반적인 실리콘 벨리의 모습은 CEO가 칸막이 속에서 서민적인 모습으로 일하는 쇼를 하는 것입니다. 어떤 방식으로든 이 회의실을 자신의 개인 공간으로 사용하면서 말입니다. ("개인적으로 상의할 일이 있을 때만 사용하겠다" 라고 주장하겠지만, 당신이 회의실 앞을 지나갈 때 마다 살펴보면, 반정도는 CEO가 계실겁니다. 그분 혼자서, 콜프 친구와 전화를 하면서, Cole Haans 구두 신은 발을 회의 테이블에 올려놓은 체로 말이죠.

(2부에서 계속)


저자에 관하여

Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  오늘 읽은 글. S/W 전공자를 대상으로 한 입사 면접 시험에서 나온 질문. "S/W 개발자에게 가장 필요한 덕목은 무엇인가?" 라는 질문에 대하여 많은 입사 지원자들은 "성실성", "끈질긴 탐구능력", "창의성" 등의 대답을 했다. 글의 저자는 "지두력"이란 도서를 예로 들면서, 프로그래머에게 가장 필요한 덕목은 "문제해결력"이라고 꼽았다. 문제를 분석하고 가장 효율적인 해결방법을 찾는 능력이 프로그래머의 최고의 덕목이라고 생각한다는 취지의 글이었다.

  처음 컴퓨터언어를 공부할 때, 같은 문제에 대한 내 대답은 입사지원자와 비슷했다. 알고리즘을 만들기 위한 순간의 번뜩임과 디버깅 과정에서 끈질기에 물고 늘어지는 성실함. 한줄 한줄 짜나가다보면 못짤 프로그램이 없다고 믿던 시기였다.

  4년차에 접어든 요즘, 프로그래머에게 가장 필요한 것이 무었기냐고 묻는다면 나는 "의사소통능력" 이라고 답할 것이다. 더이상 혼자서 뚝딱뚝딱 짜는 프로젝트는 없다. 대부분의 상용프로그램은 적어도 세명, 많게는 수천명의 공동작업으로 이루어진다. 따라서, 다른 사람에게 "의사"와 "정보"를 전달하는 능력이 가장 중요하다. 코딩을 해도, 효율적인 코딩보다는 읽기 쉬운 코드가 더 인정을 받는다. 컴퓨팅 파워가 인건비보다 싸기 때문이다. 복잡한 비트연산은 지양하고, 변수 하나 하나가 의미를 갖도록 선언하고 함수 하나하나의 역할을 작게 나누어 이름과 다른 동작이 없도록 짜는 것이 더 효율적이다.

  더 나아가, 의사소통 능력에는 문서를 읽고 이해하는 능력과 문서를 작성하는 능력도 포함된다. 동료 개발자나 서드 파티에서 작성한 레퍼런스를 읽고 혼자서도 작업이 가능한 것도 능력이고,  좋은 매뉴얼을 찾아 읽는 것도 능력이다. 스펙과 컨셉문서를 읽고 작성자의 의도를 이해하고 부족한 부분을 미리 찾아내는 능력. 자신의 작업 결과를 전파하기 쉽도록 레퍼런스로 작성하는 능력 등이 굉장히 중요하다. 열명 내외의 팀이라면 세미나나 구두 전달로도 정보의 공유와 수평전파가 가능하지만, 몇백명 단위의 팀이라면 문서작성 및 공유 없인는 불가능하다. 이 능력을 갖추지 못하면 문맹과 다름없다.

  마지막으로, 현업 프로그래머에게 의사소통 능력이란 영어능력과도 크게 다르지 않다. 특히, 외국인들과 얽히는 일이 많은 요즘, 영어로 화내고, 영어로 야단치고, 영어로 비꼬고 갈구는 능력도 필요하다. 물론 이런 말을 알아듣는 능력도 필요하겠다. "프로그래머는 코드로 말한다"는 낡은 명제다. 이제는 "프로그래머는 영어로 말한다" 가 맞다.

  영어의 중요성은 아무리 강조해도 부족하지 않다. 대학 입학 직후는 학교를 낮춰왔다는 생각에 적잖이 심난한 때였다. 하지만, 1학년 때 부터 교양 서적 두 권을 빼고는 모두 영어 원서를 준비하라는 말을 듣고 마음을 놓았었다. 물론 처음엔 많이 어려웠고, 실제로 한글 번역본을 따로 구하거나, 교과서 읽기는 포기하고 공부하는 친구들도 있었지만, 영어 원서를 본다는 것은 미국 대학생들과 같은 수준의 공부를 한다는 인상을 주었고, 그저 열심히 하기로 마음을 다잡는 계기가 되었다. 그 때 교수님께서 하셨던 말씀. "영어를 잘해야 한다. 영어로 인터넷에 올라온 자료를 보면 일주일 된 자료를 보는 것이요, 영어로 된 책을 읽으면 1년된 자료를 보는 것이요, 한글로 번역된 책을 보면 2~3년 이상된 자료를 보는 것이다. IT는 정신없이 변하는데, 3년된 자료를 봐서 뭘 하자는 것이냐" 는 것이 말씀의 취지셨다. 백번 옳은 이야기다.

  혹시나 이 글을 읽는 대학 초년생들이 있으시다면, 부디 명심하시기를. 혼자서 다니지 말고 친구를 사귀시라. 인터넷에 물어물어 어줍잖은 대답을 듣기 보다는 선배에게 물어서 배우시라. 원서가 어렵다고 포기하지 말고, 차라리 영어를 습득하시라. 이 모든 것이 의사소통 능력이고, 이것이 좋은 프로그래머가 되기위한 필수 조건입니다.

 
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.04.29 00:09 신고
    댓글 주소 수정/삭제 댓글
    좋은 말씀 잘 들었습니다. (__)



원문보기

Joel on Software


The new Fog Creek office

 
Monday, December 29, 2008

  바이오닉 오피스를 기억하십니까? Fog Creek은 그곳으로 2003년에 이사를 했었습니다. 몇년이 지난 뒤, 우리 회사는 첫번째 사무실이 좁을 정도로 커져서 한 층을 다 쓰게 되었습니다. 우리의 임대 계약이 만료되었을 때 우리는 18명을 위해 지어진 공간을 25명이 사용하고 있었습니다. 우리는 이사할 때가 되었다는 것을 알았습니다. 덧붙여, 중간지구(midtown)의 지저분한 지역 - 벤처회사를 시작하기에는 딱이죠 - 은 5년째 우리를 낙담하게 만들고 있었습니다. 우리에게 약간의 여유자금이 있었기에, 공간은 두배정도 넓고 비용은 네배 정도 비싼 장소를 찾고 있었습니다.

 

  지겹도록 반복했지만, Fog Creek의 목표는 소프트웨어 개발자들이 일하기에 가능한 최고의 환경을 만드는 것입니다. 뛰어난 입지를 찾는 것은 쉽지 않았습니다. 우리의 이상은 모든 개발자들에게 개인 사무실을 만들어주는 것인데, 평범한 일이 아닙니다. 이미 지어진 사무실 중에서 이런 방식으로 지어진 것을 찾는 것은 거의 불가능합니다. 이말은, 우리에게는 선택의 여지가 많지 않고, 대신에 비어있는 공간을 찾아서 우리만을 위한 인테리어 공사를 해야 한다는 것입니다.

  우리는 시간이 걸릴 것이란 것을 알고 있었습니다. 첫번째 사무실 이후로, 새 사무실을 찾는 것에서부터 실제로 이사할 때 까지는 항상 10개월의 시간이 걸린다는 것을 알고 있었습니다. 그리고 제가 공사의 세세한 부분까지 직접 개입하지 않으면, 인생을 낭비하는 음울한 칸막이를 벗어날 수 없다는 것도 알고 있었습니다.

  지루한 탐색끝에, 우리는 브로드웨이 55번가의 높은 층에 10,600 평방 피트의 (약 300평) 공간을 임대했습니다. 다운타운에 아주 가깝고, 허드슨 강과 거버너스 섬( Governor’s Island), 자유의 여신상과 저지 시티(Jersey City)가 보이는 멋진 전망을 자랑하는 곳입니다.

  우리가 찾아낸 건물주는 자체 건축인력이 있었고, 그들은 무료로 우리를 위해 인테리어 공사를 해줄 의향이 있었습니다. 단 한가지 문제는 그들이 생각하는 좋은 사무실은 Fog Creek보다는 Initech(역자 주 : 1999년에 나온 영화 "Office Space"에 등장하는 IT회사. 더 자세한 정보는 여기를 참조하세요.)에 가까웠습니다. 그래서 우리는 모든 것을 우리식으로 업그레이드 하기 위하여 50만 달러를 투입해야만 했습니다.


 - 2부에서 계속

저자에 관하여
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  네번의 연재 끝에 드디어 첫번째 번역을 마쳤습니다. 조엘이 글 자체가 부사를 굉장히 많이 써서 우리말로 읽기 쉽게, 그리고 우리말 어순과 문법에 맞게 번역하는 것이 굉장히 어려웠습니다. 가능한 우리가 사용하는 말로 의역하려고 노력을 했고, 우리말 어순을 지키려고 노력을 했습니다만, 많이 부족할 것 같습니다.

  영리를 목적으로 작성한 글은 아닙니다. 글의 원저자는 Joel Spolsky 임을 밝혀둡니다. 개인적인 영어 공부와 소프트웨어 엔지니어링 공부의 목적을 겸하고 있고, 보다 많은 공학도들이 그의 혜안을 배울 수 있었으면 좋겠다는 의도로 시작한 일입니다. 따라서 모든 종류의 태클은 정중히 사양합니다. 영문 번역에 미흡한 부분에 대한 지적은 얼마든지 환영합니다. 감사합니다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절



원문은 여기에
http://www.joelonsoftware.com/items/2009/03/09.html

How to be a program manager

by Joel Spolsky (Monday, March 09, 2009)


 - 이전글 : 프로그램 매니저가 되는 방법 - 1 (How to be a program manager)
 - 이전글 : 프로그램 매니저가 되는 방법 - 2 (How to be a program manager)
 - 이전글 : 프로그램 매니저가 되는 방법 - 3 (How to be a program manager)

  - 3부에서 계속

  어떻게 존경을 받을 수 있을까요?

  프로그램 매니저가 코딩을 잘 한다는 것은 분명히 도움이 됩니다. 예, 이것은 불공평 합니다. 프로그램 매니저는 코딩을 할 의무는 없으니까요. 하지만, 프로그래머들은 상대가 얼마나 똑똑하던 간에, 프로그래머를 프로그래머가 아닌 사람보다 더 존경하는 경향이 있습니다. 코딩을 할 줄 모르면서도 능력있는 프로그램매니저가 될 수는 있겠습니다만, 개발팀으로부터 존경을 얻기 위해 더 큰 부담을 감수해야 할 것입니다.

  개발팀으로부터 존경을 얻는 또 다른 방법은 개발팀과 무엇을 주제로 토론을 하던지 이성과(Intelligence)과 열린 자세(Open-mindedness)와 공평함(fairness)을 보여주는 것입니다. 만약 프로그램 매니저가 멍청한 말을 한다면 프로그래머들은 그를 광대 취급하며 귀를 닫아버릴 것입니다. 만약 프로그램 매니저가 자기 주장만 하거나 감정적으로 일을 한다면 논점은 점점 더 타당하지 못한 방향으로 흘러가서 결국 개발팀의 신뢰를 잃게 될 것입니다. 개발팀도 마찬가지겠지만, 특히 프로그램 매니저는 토론에서 감정을 배제하고 새로운 자료들을 검토해서, 그것에 이점이 있을 때는 자기 주장을 굽힐 줄 알아야 합니다. 마지막으로, 프로그램 매니저가 정치적인 모습을 보일 때 그들은 개발팀의 신뢰를 상실하게 될 것입니다. 예를 들면, 사장님과 개인적인 미팅을 갖는다던가, 토론에 이기기 위하여 개발팀을 분할 정복(divide-and-conquer)하려는 행동들 입니다.

  프로그램 매니저가 개발팀의 신뢰를 잃게 되면 그것으로 끝입니다. 그들은 더이상 효율적이지 못합니다. 프로그래머들은 등을 돌린체 그들이 원하는 방식대로 해버릴 것입니다. 그 결과는 나쁜 코드와 시간낭비로 나타날 것입니다. 왜냐하면, 단지 당신이 무능력한 프로그램 매니저 놀이를 하면서 월급을 축내는 것 뿐만아니라  뿐만아니라, 회의를 소집해서 모두의 시간을 탕진할 것이기 때문입니다. 물론, (좋은 프로그램 매니저 없이는) 그들이 그 시간에 코드를 더 좋게 할수도 없겠지만요.

  명세서라고? 정말? 그건 정말 애자일 방식이 아니야 (Specs? Really? That's so unagile)

  명세서는 정신나간 관료주의적인 문서작업이라고 생각에, 명세서를 작성하지 말자는  많은 개발 조직들이 생겨났습니다. 이분들은 오해를 한 것입니다. 기능명세서를 작성하는 것은 애자일 개발방식의 핵심입니다. 왜냐하면, 이것이 코딩전에 수많은 가능한 설계들을 빠르게 해 볼 수 있게 하기 때문입니다. 코드와 비교할 때, 명세서는 바꾸는 것은 하찮은 일입니다. 명세서를 작성하는 작업이 머리속으로 설계에 대하여 생각하게 만들고, 그 설계의 약점을 빨리 발견할 수 있게 하여 다른 대안을 찾을 수 있도록 합니다. 기능 명세서를 이용하는 개발팀이 더 나은 제품을 만듭니다. 왜냐하면 그들은더 많은 가능한 솔루션들들을 빠르게 찾아볼 기회가 있기 때문입니다. 또한 이러한 개발팀은 코드도 더 빠르게 작성하는데, 왜냐하면 작업을 시작하기 전에 명확한 그림을 볼 수 있기 때문입니다. 기능 명세서는 매우 중요하기 때문에, "명세서 없이는 코드 없다" (\No code Without Spec"는 포그 크릭(Fog Creek)의 몇안되는 업격한 규칙 중 하나로 제정되었습니다.

  명세서의 구체적인 형태는 바뀔 수 있습니다. 모든 기능명세서가 프로그램이 어떻게 동작해야 하는지에 관해서 담고 있어야 합니다. 코드가 내부적으로 어떻게 동작해야 하는지는 기술하지 않습니다. 여러분은 더 높은 수준에서 시작할 수도 있습니다. 비전 선언서 - 한 페이지 안에 새로운 기능에 관혜서 설명한 요점만 남는 것 - 만 작성하는 것입니다. 비전 선언문이 확정되면 , 스토리보드를 작성합니다. 스토리보드는 사용자들이 보게 될 화면의 예시와 함께 어떻게 동작해야 하는지 상세한 설명으로 되어 있습니다. 기능의 종류에 따라, 특히 UI 중심의 기능에는 스토리보드를 작성하면 다 된 것입니다. 그것이 당신의 명세서 입니다. 제이슨 프라이드 씨, (Jason Fried) 이제 가셔도 좋습니다.

    UI 스토리보드로는 숨겨진 동작이 중요한 보다 복잡한 기능을 표현할 수는 없습니다. 이런 기능을 위해서는 좀 더 상세한 명세를 작성해야 합니다. 어떤 경우던지, 명세서를 적는 행위는 여러분이 문제점, 모순점, 설계상의 이슈들을 코드의 첫번째 줄을 작성하기 훨씬 전에 발견할 수 있도록 해줍니다. 그래서 여러분이 코드를 작성할 때 예기치 못한 이슈가 튀어나와서 코드를 다시 작성하거나, 나, 상황이 더 않좋다면,  비효율적인 코드를 작성할 수 밖에 없는 경우를 훨씬 더 줄여줍니다.

  프로그램 매니저가 되는 방법을 어떻게 배우나요?

  프로그램 매니저가 된다는 것은 대부분 배움에 관한 것입니다. 기술에 관해서 배우고, 사람들에 관해서 배우고, 조직을 효율적으로 운영하는 방법을 배우는 것입니다. 좋은 프로그램 매니저는 설계 기술에 대한 엔지니어적인 태도와 사람들의 의견을 하나로 모으고 함께 하도록 만드는 정치적인 능력을 조화시킨 사람입니다. 여러분이 프로그램 매니저로 일하고 계시다면 읽어보셔야 할만한 몇가지 책들이 있습니다. 제가 이야기할 수 있는 한, 스콧 벅쿤(Scott Berkun)의 책 Making Things Happen은 프로그램 매니저가 무엇을 해야 하는지에 관해서 대부분을 다루는 유일한 책입니다. 그러니, 이 책으로 시작하십시요. 스콧은 수년동안 인터넷 익스플로러(Internet Explorer)팀의 프로그램 매니저로 일해왔습니다.

  프로그램 매니저 일의 다른 큰 부분은 유저 인터페이스 설계에 관한 것입니다. 스티브 크룩(Steve Krug)의 Don’t Make Me Think를 읽어보시고, 다음엔 제 책 User Interface Design for Programmers를 읽어보십시요.

  마지막으로, 다소 위선적으로 보인다는 것을 압니다만, 데일 카네기(Dale Carnegie)의 1937에 나온 책, How to Win Friends & Influence People은 인간관계의 기술에 대한 정말로 환상적인 입문서 입니다. 이 책은 제가 포그 크릭의 모든 매니지먼트 교육생들에게 모든 일에 앞서서 읽게 했던 책힙니다. 이제는  제가 이 책을 읽으라고 할 때면 모두들 킥킥 댑니다만, 전 그들이 이 책을 모두 읽었다는 사실에 만족합니다. (끝)

 




Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

원문은 여기에 http://www.joelonsoftware.com/items/2009/03/09.html

How to be a program manager

by Joel Spolsky (Monday, March 09, 2009)


 - 이전글 : 프로그램 매니저가 되는 방법 - 1 (How to be a program manager)
 - 이전글 : 프로그램 매니저가 되는 방법 - 2 (How to be a program manager)

대립(Conflict)

   프로그램 매니저가 없다면, 여러분의 뛰어난 프로그래머들은 엉터리 유저 인터페이스를 만들게 될 것입니다. 물론 그들은 "당신이 불칸(Vulcan : 스타트랙) 이라면 쉽게 이해할 것이다" 이란 생각으로 만들었을 것입니다. (역자주 : IF YOU'RE A VULCAN : 스타트랙에 나오는, 감정은 배제하고 논리와 이성으로 만으로 살아가는 외계 종족) 최고의 프로그래머들은 아주 똑똑하지만, 열 여섯개의 한 글자 커맨드 옵션(Command line arguments) (역자주 : copy - X -D 같은 것들)를 사용자들이 기억하기 어려월 할 것이라고는 상상도 하지 못합니다. 이러한 프로그래머들은 그들의 첫번째 아이디어를 그대로 밀고 나가는 경향을 보이는데, 특히 이미 코딩을 시작한 상태라면 더욱 그렇습니다.

 만화 원본 (http://www.ok-cancel.com/comic/4.html)


  소프트웨어 설계 프로세스에 프로그램 매니저가 추가할 수 있는 최선의 일은 프로그램이 어떻게 설계되야 하는지 대안(Second option)을 제시하는 것입니다. 이것만이 "모자른" 사용자들에게 매뉴얼을 읽거나, emacs-lisp 함수르르 스스로 만들거나, 8진수를 암산하는 일을 피할 수 있게 하는 유일한 희망적인 일입니다.

  좋은 프로그램 매니저는 UI 동작에 관한 아이디어를 제실할 것입니다. 그 아이디어는 개발자의 아이디어보다 더 뛰어날 수도 있고, 더 안좋을 수도 있습니다. 그리고, 긴 토론이 시작됩니다. 일반적으로, 프로그램 매니저는 간단하고 사용자가 이해하기 쉬운 것을 원합니다. 예를 들면 텔레파시 UI나 주머니에 넣기에는 너무 큰 30인치 스크린을 넣고 싶어합니다. 반면에 개발자들은 평범한 것들을 코드에 구현해 넣기를 원합니다. 예를 들면, 커맨드 라인 인터페이스(이에 왜 쓰기 어렵다는거지?)나 파이썬 바인딩(Python bindings) 같은 것입니다.

  엑셀 5 프로젝트 중에서 제작 기억하는 기념비적인 토론은 피봇 테이블에 관한 것이었습니다. 개발자들은 피봇 테이블을 스프레드시트의 드로잉 레이어 (Drawing layer)위에 띄워(float) 놓고 싶어 했습니다. 반면에, 프로그램 매니저는 스프에스시트의 셀의 오픈쪽에 살리고 싶었습니다. 이 토론은 정말 정말 오래 계속 되었고, 마침내 프로그램 매니저가 이겼습니다. 하지만, 최종 설계는 각각의 의견보다 훨씬 더 좋은 것이었습니다.

  이러한 토론이 서로를 존중하면서 사실에 기반하여 이성적으로 진행되기 하기 위해서는 프로그램 매니저와 개발자들이 동등한 입장에 서는 것이 매우 중요합니다. 만약 개발자들이 프로그램 매니저에게 문제제기를 할 때, 토론 중 어떤 점이 매니저의 마음에 안들면 매니저는 "됬어. 그만해. 그냥 내 방식대로 하지" 하고는 토론 전부를 무시해 버릴 것입니다. 그들이 동등한 입장에 서 있다면 이런 일은 일어날 수 없겠지요. 이건 법정과도 약간 비슷한 면이 있습니다. 법정에서는 한쪽에 치우친 판사를 허용하지 습니다. 또한, 공평한 토론 절차를 통해서 진실이 드러날 것이라고 믿습니다. 마찬가지로, 프로그램 매니저와 개발자 간의 토론도 어느 한쪽이 불공평한 이점(Advantage)이 없을 때에 비로소 공평해 집니다.

  이것이 중요한 점입니다. 당신이 11학년에 다니는 샐리(Sally)에 대해서 떠올릴 때, 그녀가 지금 어디에 있는지 궁금해 하지 않겠습니까? 기운 내십시요. 그녀는 스콧데일(Scottsdale)에 사는 바이오테라피스트고, 공화당원입니다. 자, 주목하십시요. 프로그래머들이 프로그램매니저에게  문제제기를 하지 못한다는 것은 개발팀장(혹은  CTO나 CEO)이 명세(Spec)을 만드는 사람이 될 수 없다는 뜻입니다.  (역자 주 : 1. Sally 이야기가 갑자기 왜 나왔을까요?. 이해할 수가 없습니다. 2. 이 단락의 내용을 부연하자면, 개발팀장이나 CTO, CEO 같은 사람은 개발자와 동등한 입장에 설 수 없으므로, 개발자들이 함부로 문제제기를 할 수가 없게되고, 이런 사람은 프로그램 매니저로 적절하지 못하다는 얘기 입니다.)

  많은 회사들이 저지르는 첫번째 잘못(Number one mistake)은 프로그래머들의 관리자가 명세를 작성하고 제품 설계를 하는 것입니다. 이것이 잘못인 이유는 이사람이 한 설계는 공평하게 검토될 수가 없고, 그로 인해서 문제제기와 토론이 있을 수가 없게 되어 만족할 만큼 좋은 설계가 나올 수가 없습니다.

  저는 이점을 힘들게 배웠습니다. 포그 크릭 소프트웨어(Fog Creek Software)에서, 저는 스스로 프로그램 매니저가 되어 많은 일을 했습니다. (역자 주 : 글쓴이는 포그 크릭의 창립자이자 CEO입니다.) 그리고 이 것은 사람들이 제 잘못을 지적할 때마다 계속해서 걸림돌이 되었습니다. 우리회사는 큰 회사가 아니었지만, 마침내 진짜 프로그램 매니저를 둘 만큼은 커졌습니다. 지금은 댄(Dan)과 제이슨(Jason)이 프로그램 매니저로 일하고 있고, 프로그래머들은 그들과 논쟁하기를 좋아합니다.

  물론, 프로그램매니저와 관계까 동등할 때도 프로그래머들은 우위를 갖기를 원합니다. 이런 일이 몇번 있었는데, 한번은 한 프로그래머가 프로그램매니저와의 논쟁에 제가 개입해 줄 것을 요청한 일이 있었습니다.

  "누가 프로그램을 짜지요?" 제가 물었습니다.
 
  "접니다."

  "좋아요. 그럼 누가 소스 관리 서버에 체크인(Check in)하지요?"

  "그것도... 저지요."

  "그러면, 정확히 뭐가 문제지요?" 제가 물었습니다.

  "당신이 최종 제품의 한 비트(bit) 까지 통제할 수 있는 막강한 힘이 있는데 무엇이 더 필요하십니까? 왕관이라도 씌워 드릴까요?"

  보시다시피, 이 시스템은 프로그램 매니저에게 프로그래머들을 설득해야 만 하는 부담을 안겨줍니다. 어떤 면에서는 프로그래머가 논쟁하기를 포기하고 프로그래머가 내키는 대로 막 짜버릴 위험성도 있습니다. 그러므로 능력있는 프로그램 매니저가 되기 위해서는 (a) 정당성이 있어야 하고, (b) 프로그래머 들로 부터 존경을 받아야 합니다.존경을 받을 때 비로소 당신이 정당하게 일하고 있다고 프로그래머들은 이야기 할 것입니다.

  어떻게 존경을 받을 수 있을까요?

 - 4부에거 계속됩니다. 시간이 생각보다 오래 걸리네요.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

원문은 여기에 http://www.joelonsoftware.com/items/2009/03/09.html

How to be a program manager

by Joel Spolsky (Monday, March 09, 2009)


 - 이전글 : 프로그램 매니저가 되는 방법 - 1 (How to be a program manager)

  두번째 단계는 비전 선언문을 작성하는 것입니다. 비전 선언문이란 대외 공표 문서 (Broad document)의 한가지 종류입니다. 그 내용은 엑셀에서 비주얼 베이직의 동작예시, 매크로를 어떻게 만드는지에 대한 샘플코드, 빌드를 위한 주요 부분, 그리고 사용자의 문제에 대한 해결책 등 입니다. 이 문서에 대해서 반대의견이 많지 않다면, 저는 문서에 추가작업을 합니데 그 내용으로 더 상세한 스펙을 포함하고, 세세한 부분까지 설명하고, 사용자에게 어떻게 보여야 하는지를 보충합니다.

  이것은 기능명세(Functional spec)이지, 기술명세(Technical spec)가 아닙니다. 이것은 기능명세가 사용자 입장에서 기술하는 것이지, 내부 구현에 관하여 논하지는 않는다는 뜻입니다. (기능 명세에 관해서는 이곳 을 참조하세요.) 프로그램 매니저는 개발팀이 내부적으로 어떻게 구현하는지는 신경쓰지 않습니다. 제가 개발팀 리더인 벤 왈드맨(Ben Waldman)에게 기능명세를 보내면, 그는 그의 팀들과 모여 앉아서 내부적으로 어떻게 구현할 것인지를 논의합니다. 그들은 제가 만든 객체지향 인터페이스와 내부함수간의 매우 간단하고 뛰어난 맵핑 테이블을 만듭니다. 하지만, 이것은 정말로 제가 신경쓸 일이 아닙니다. 저는 엑셀의 내부 동작과 그 구현에 관해서는 정말로 많이 알지 못합니다.

  솔직히 말해서, 저는 눈꼽만큼도 알지 못합니다. 대학을 갓 졸업했을 때부터 저는 개발, 테스트, 문서작성, 마켓팅, 사용성 테스트  등의 일들을 충분히 경험하지 못했습니다.운좋게 마이크로 소프트에는 각 분야별로 많은 경험을 가진 고수들(Gurus)이 있었고, 그들은 오늘날 제가 아는 모든 것을 저에게 가르쳐 주었습니다. 또한 그들은 뛰어난 제품을 실제로 만들었습니다. 예를 들어, 사용자들은 엑셀의 셀(Cell)에서 변수로 값을 카피하고 싶을 때, 다음과 같이 적습니다.

x = [A1]  

  문제는 이 셀에는 숫자가 들어있을 수도 있고, 문자열이 있을 수도 있다는 것입니다. 하지만, 베이직은 얼리 바운드 (Early bound) 언어 입니다. 여러분은 DIM x 를 Integer, Float  또는 String을 사용하기 전에 선언해야 합니다.

  베이직은 동적 타입(Dynamic types)을 지원해야만 하지만, 저는 이것을 구현할 만큼 똑똑하지 않았습니다. 뭐, 문제 없었습니다. 비주얼 베이직 팀의 프로그래머인 톰 코벳(Tom Corbett)이 해결방법을 찾았습니다. 그리고 Variants 와 IDispatch 가 태어났습니다. 베이직은 "덕 타이핑(Duck typing)"과 함께 동적인 언어가 되었습니다. 중요한 점은, 제 일은 문제를 해결할 필요는 없다는 것입니다. 제 일은 고객의 요구사항을 분석하고, 프로그래머들이 그 요구사항의 해결책을 확실히 찾을 수 있도록 하는 것입니다.

  일단 기능명세가 완성되고 개발팀이 일에 착수하면, 제게는 두가지 책무가 남습니다. 첫째, 설계에 대한 모든 질문에 답하고, 같은 질문이 나오지 않도록 그 내용을 다른 팀들에 전파합니다. 둘째, 테스터들에게 기능의 정상 동작에 대해서 설명하고 테스트 계획을 잡을 수 있도록 돕습니다. 문서화 팀을 만나서는 그들이 엑셀의 베이직 스크립트를 위한 좋은 튜토리얼과 참고문서를 작성할 수 있도록 합니다. 지역화 전문가(Localization experts)를 만나서는 지역향 개발을 위한 전략을 세웁니다. 매켓팅 팀과는 VBA 기능의 마켓팅 포인트에 대하여 설명합니다. 사용성 전문가와 만나서는 사용성 테스트 계획을 세웁니다.

  프로그램 매니저는 많은 회의를 합니다만, 문서화 작업은 그리 많지 않습니다. 이것이 대학을 갓 졸업한 초짜 시절부터 지금까지 제가 이일을 계속 할 수 있는 이유입니다. 여러분이 프로그램 매니저가 되기 위해서 꼭 14년 경력의 베테랑 프로그래머가 될 필요는 없습니다. (사실, 14년의 프로그래밍 경력이 있다면 여러분은 더 좋은 사용자의 대변인이 될 수 있을 것입니다.)

 
 - 3부에 계속 됩니다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

원문은 여기에 http://www.joelonsoftware.com/items/2009/03/09.html

How to be a program manager

by Joel Spolsky (Monday, March 09, 2009)

    좋은 프로그램 매니저를 얻는 것은 정말 뛰어난 프로그램을 만들기 위한 비밀 공식 중 하나입니다.  아마도 여러분에 팀에는 좋은 프로그램 매니저가 없을 것입니다. 왜냐하면, 대부분의 팀들이 없거든요.

  WYSIWYG 워드 프로세서를 공동 개발한 뛰어난 프로그래머인 찰스 시모니(Charles Simonyi)는 마르타 스튜어트(Martha Stewart)를 만났습니다. 마르타 스튜어트는 마이크로 소프트의 주식으로 억만장자가 되었고, 우주여행까지 한 사람입니다. 그들은 "맨 먼스 미신(Mythical Man Month)"의 문제를 해결하기 위한 정말 큰 소프트웨어 팀을 만들었습니다. 이 팀은 완전 뛰어난 천재 프로그래머가 상위 레벨의 함수를 만들고, 하위 레벨의 함수에 대한 구현은 초급 프로그래머들에게 넘기는 방식으로 일을 합니다. 이 천재 프로그래머의 직함을 프로그램 매니저(Program Manager) 라고 부릅니다. 시모니는 똑똑했지만, 이 아이디어는 그렇지 못했습니다. 제 생각에, 그 이유는  누구도 초급 프로그래머가 되고 싶지는 않기 때문입니다.

  80년대 후반에 Mac Excel 팀의 프로그래머였던  제이브 블루멘달 (Jabe Blumenthal)은 이 직함을 재활용했습니다. 그는 소프트웨어 개발이 점점 더 복잡해지고 있다는 점과 프로그래머들이 프로그램의 사용성과 유용성을 신장시키기 위해 고민할 시간이 없다는 점을 알고 있었습니다. 마켓팅 팀에서는 고객들의 요구사항에 대해서 시끄럽게 떠들어 댔지만, 그들과 이야기 하고 그들이 MBA-Speak를 구체적인 사양으로 번역할 사람이 없었습니다. 많은 작업량이 필요한 제품 설계 요소에는 여러가지가 있습니다. 사용자와 대화하기, 사용성 테스트하기, 경쟁제품 분석하기, 쉽게 구현하기 위한 방법을 찾기 위해 열심히 고민하기 등. 그러나 대부분의 프로그래머들은 정말로 시간이 없습니다. (시간만 있다면 그들은 이 일들을 잘 해낼 수 있습니다.) 블루멘달은 프로그램 매니저란 직함을 빌려다가 완전히 새로운 일을 하도록 재창조 했습니다.

   프로그램 매니저는 어떤 일을 하는가?

  이제부터  프로그램 매니저가 하는 일들을 살펴보겠습니다.

  1. UI 설계 (Design UIs)
  2. 기능 명세 작성 (Write functional specs)
  3. 팀 간의 업무 조정 (Coordinate teams)
  4. 고객측의 대변자 역할 (Serve as the customer advocate)
  5. 바나나 리퍼블릭(미국의 중저가 브랜드) 의 치노(chinos) 입기
 
  제 프로젝트 매니저로써의 첫번째 과제는 마이크로 소프트의 엑셀의 기능 중 커스터마이제이션 이라고 부르는 사용자 기능(User activity) 이었습니다. 예를 들자면, 스크립트와 매크로 처럼 사용자가 직접 만들어 사용할 수 있는 기능들입니다. 제가 해야 했던 첫번째 일은 사용자들의 요구사항을 알아내는 것이었습니다. 이를 위해서 저는 가능한한 많은 사용자들과 이야기를 나눴는데, 똑같은 이야기가 반복되어 지루해지기 시작할 때까지 고객의 의견을 들었습니다. 저는 어떤 것들이 18개월의 개발기간안에 구현 가능하고 타당한지검토하는데 많은 시간을 들였습니다. 또한 비주얼 베이직 팀과 컴파일러, 코드 에디터, 다이얼로그 박스 에디터 등 엑셀의 메크로 기능에 사용될 수 있는 툴들을 제공해 줄 수 있는지 확인하기 위해 오랬동안 이야기를 나눴습니다. 저는 또 애플(Apple)과 이야기를 했는데, 그들은 애플 스크립트(Apple script)라고 부르는 범용 매크로 언어를 개발하고 있었습니다. 애플 뿐만 아니라 마이크로소프트의 다른 어플리케이션 개발팀들 - 주로 워드(Word), 엑세스(Access), 프로젝트(Project) 그리고 메일(Mail) - 을 만났는데, 이들은 엑셀과 일반적인 기능들은 동일합니다. 이러한 과정들은 대부분 대화, 회의, 이메일, 전화통화로 이루어져 있습니다. 제 삶은 이 일의 흔적이 남아있고, 지금도 전화벨이 울릴 때면 제 사무실에서도 겁에 질린답니다.

 - 2부에 계속 됩니다.

Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.03.30 23:51
    댓글 주소 수정/삭제 댓글
    학생인데도 좋은 글을 읽고있군요. 멋집니다.
    10년이 넘은 고참 프로그래머들도 Joel을 모르는 사람들이 많거든요.
    번역 감사드리구요, 트랙백 걸어도 되겠지요? ^^


  네이버에 이런 질문이 올라왔다.

안녕하세요 컴퓨터프로그래머가 되고싶은 중3 학생입니다

 

저는 초등학교 6학년때부터 컴퓨터프로그래머에 푹빠졌습니다

 

그리고 그생각만 가지고 보니 중3 이였습니다

 

저는 워드프로세서 1,2,3 ITQ 한글, 파워포인트 정보처리기능사 자격증을따냈습니다

 

하지만 자격증만으론 안되고 C언어 C++ JAVA 등 여러가지를 공부해야합니다

 

하지만 저는 중학교입학할때부터 컴퓨터공부를 전혀하지 않았습니다

 

자격증만 있고 확고한 자신감만있으면 된다고 생각한저였으니까요

 

지금은 공부할 마음이 생깁니다

 

어떻게하면 컴퓨터프로그래머가 될수있을지

 

또 어떻게공부해야지 나의 진로를 갈수있을지

 

도와주세요..


 뭐 도와주고 싶은 생각이야 든다만, 과연 프로그래머가 뭐하는 사람인지 잘 모르고 있는 것 같다는 생각이 먼저 들었다. 그래서 이렇게 답변을 달았다.

열심히 공부해서 좋은 대학에 가세요

컴퓨터프로그래머가 되고 싶다면, 가장 기본적인 조건은 대학교에서 컴퓨터를 전공하는 것입니다. 대부분이 회사들이 컴퓨터공학 전공이나 컴퓨터과학 전공의 학위를 요구하기 때문입니다. 좋은 프로그래머가 되고 싶으시다면, 중학생인 지금은 컴퓨터관련 자격증이나 C언어를 공부하는 것은 아무 의미가 없습니다. 그런 공부는 대학에 가서 하셔도 충분합니다.

  컴퓨터 프로그래머는 "어떤 문제를 해결하기 위한 알고리즘을 만들어서, 그 알고리즘을 컴퓨터 언어를 이용해 컴퓨터가 이해할 수 있는 프로그램을 만드는 사람"을 뜻합니다. 지금 질문자님께서 생각하시는 부분은 컴퓨터 언어를 이용해서 프로그램을 만드는 부분만 생각하고 계신 것 입니다. 하지만 실제로 좋은 프로그래머는 문제를 해결하기 위한 좋은 알고리즘을 만드는 사람입니다. 그리고 좋은 알고리즘을 만들기 위해서는 생각이 깊고 현명한 사람이 되어야 합니다. 생각이 깊고 현명한 사람이 되기 위해서는 좋은 대학에서 체계적인 교과과정에서 따라서 열심히 공부하는 것이 가장 필요한 일입니다.

 다시 말씀드립니다만, 지금 중3이라면 학교 공부 열심히 하시는 것을 권해드립니다. 수학과 영어를 열심히 하시는 것이 특히 중요합니다. 그래서 좋은 학교를 가세요. 특히 우리나라는 좋은 학교와 그렇지 않은 학교 사이에 수준차이가 많이 납니다.

  너무 현실적인 답변이었을까? 사실 지금 내가 하는 일도 프로그래머는 이런 일을 한다고 소개하는 수많은 에세이들과 비교하면 노가다에 더 가깝다는 생각도 든다. 좀더 정신노동, 창조적인 일을 하길 원하는데 실상은 그렇지 못한 면이 많다. 내 실력도 그런 일을 할 만큼 뛰어나진 않다고 느끼고 있고. 무엇보다 대학 때 배운 것들이 국제적인 기준에서 너무 수준이 낮았다. 만약 내가 아르바이트로라도 프로그래밍을 하지 았았다면 난 지금보다도 실력이 한참 모자라는 얼치기 개발자에 불과했을 것이다.

  요즘의 대침체 이전에 미국의 최고 장래성있는 직업은 S/W Engineer 였고, 석사 출신 신입의 초봉이 평균 10만 달러에 육박했었다. 대한민국의 프로그래머는 여전히 3D와 화이트칼라의 경계를 걷고 있고, 대우는 많이 부족하다. 거기에다 동종업게 이직금지라는 노예제도까지 존재하고 있다. 공생전 같은 글이 괜히 나오는 것이 아니라는 뜻이다.

 개인적으로, 프로그래밍을 정말 좋아한다. 이 일은 The Mythical Man Month에서 나오는 것과 같이, 새로운 것을 만드는 창조적인 일이고 아름다운 코드를 만든 예술적인 일이다. 목수가 책상 다리에 못을 박고서 예술적으로 박았다고 느끼는 지는 모르겠다. 하지만 프로그래머들은 코드를 몇줄 적어놓고 "아름답다" 고 말한다. 프로그래머는 사람의 언어 대신 컴퓨터의 언어로 글을 쓰는 작가들이기도 하다. 그래서 난 이 일을 사랑하는 것 같다.

 프로그래머가 되고 싶다면, 이 일을 얼마나 사랑할 수 있을지 고민을 좀 해보는 것이 필요하다. 정말 해주고 싶은 말은 이것이다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  조엘 온 소프트웨어 (Joel on software) 에서도 여러번 다룬 이야기지만, 막상 평가를 당하는 대상이 되면 이건 전혀 다른 이야기다. 특히나 우리회사 같이 큰 회사에서 많은 수의 사원들을 대상으로 랜덤이 돌아가고 있다고 느껴진다면 이건 정말 큰 문제가 된다. 프로그래머들은 의욕을 잃고, 능력이 부족한 동료 때문에 자기에게 추가 업무가 전가되는 것에 짜증을 내기 시작한다. 불투명한 고과가 팀웍을 깬다. 그건 곳 그 고과권자가 무능함을 뜻한다.

  조엘이 자신의 글에서 실증적인 예를 들었듯이, 프로그래머를 평가하는 객관적인 방법은 없다. 어떠한 잣대를 들이대더라도 프로그래머는 빠져나갈 구멍을 만들 것이며, 어떠한 잣대도 프로그래머의 창의성을 저해할 것이다. 평가를 받는 프로그래머의 목표는 더이상 가장 뛰어난 프로그램을 만드는 것이 아니기 때문이다. 그의 목표는 당연히 고과 기준에 맞는 일을 하는 것이 될 것이다. 심지어 그것이 의도적인 버그를 숨기는 일이 될지라도 말이다.

  특히나, 우리회사 같은 곳에서는 문제가 더 심각하다. 대한민국 100대 기업 안에든다는 회사가 나 입사할 때만 해도 조엘 점수가 12점 만점에 8.5점을(매우 후하게 준 것이다) 겨우 넘기는 정도였다. 조엘은 자신의 책에서 11점 미만은 가서는 안된다고 단언을 했지만, 우리회사는 입사 경쟁률이 꽤 높았다. 지금은 많이 개선되어서 11점 정도 되었다. 하지만 아직도 가장 Critical한 문제가 남아있다. 바로 채용의 문제인데, 프로그래머를 채용하면서 프로그래밍 능력을 묻지 않는다. 하하...

  프로그래머의 고과를 객관적으로 매길 수 없다면, 처음부터 A급 프로그래머를 뽑는 수 밖에 없다. B급 프로그래머의 10배 일을 하는 A급 프로그래머들로 팀을 꾸리고 모두에게 A고과를 줘라. 그리고 그들이 마음대로 뛰어놀 수 있도록 풀어놔라. 맨먼스 미신에서 말하는 것 처럼, 300명의 프로그래머와 25명의 관리자 보다 뛰어난 25명이 그냥 일을 하는 편이 더 좋다. 내가 입사하기 전에도 제품은 출시가 되었고, 인원이 두 배가된 지금도 버그는 엄청나게 숨어있다. 결국, 인원이 늘어났지만 나아진 것은 별로 없다는 뜻이다. 아니, 문제는 더 늘어나고 있는 걸지도 모른다. 제대로된 프로그래머를 채용하지 않는다면 인원이 늘어날 수록 문제도 따라 늘어날 것이다. 제발 인사쪽에서 제조업 마인드를 버렸으면 좋겠다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


BLOG main image
일상, 프로그래밍, IT 그리고 직장생활, Dive, 여행 by 지그프리드

카테고리

Class List (402)
Studies (30)
Exercise & Quizz (10)
Term Project (0)
ECIM list (Help!) (10)
Issues & News (0)
Gossip about IT & Job (22)
Tools (2)
Think about the Justice (23)
Book Review (170)
조엘 온 소프트웨어(번역) (28)
Diary (87)
Vacations (9)
Clash of clans 클래시 오브.. (11)

글 보관함

달력

«   2019/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    
Total : 314,682
Today : 22 Yesterday : 15