유명 블로거 조엘 스폴스키 (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 지그프리드 지그프리드

원문보기

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 지그프리드 지그프리드

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

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

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

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

원문보기

Joel on Software


The new Fog Creek office

 
Monday, December 29, 2008

 - 이전글 보기 : Fog Creek의 새 사무실 - The new Fog Creek Office 1


  소프트웨어 개발자를 위한 위대한 사무실은 두가지 목적을 만족시켜야 합니다. 생산성을 높일 것, 그리고 입사 지원자를 늘릴 것(increased recruiting pull).  프로그래머들에게 제공된  닫히는 문이 달린 개인 사무실은 그들이 코드에 집중할 수 있도록 해줍니다. 코딩을 멈추고 방안의 다른 사람들의 재미있는 대화를 듣는 것을  방지해 주기 때문입니다. 그리고 멋진 사무실은 우리 회사에 지원한 사람들을 열광시키고, 우리회사가 더 매력적으로 보이게 해주고, 우리가 수익성 좋게 프로그램을 만드는데 필요한 뛰어난 개발자들을 고용하고 붙잡아 둘 수 있게 합니다. 이것은 대부분의 다른 소프트웨어 회사들이 기본적은 칸막이 공간 정도를 제공하는 현실에서는 특별한 가치가 있습니다.

 


 새 사무실의 몇가지 특징은 다음과 같습니다.


다수의 밝은 사무실들 : 모든 개발자, 테스터, 프로그램 매니저들은 개인 사무실을 갖습니다. 두 개의 사무실만 제외하고는 모두 밖이 보이는 창문이 있습니다. (다른 두 개의 사무실은 두 개의 유리벽으로 인해 자연광이 많이 들지는 않습니다)

프로그래머를 위해 디자인된 책상 :  작업면 높이를 조절 가능하도록 모터가 달린긴 직선형 책상은 신체에 무리를 주지않으면서 매우 편안합니다. 이 책상 덕분에 여러분은 하루 중 일부는 일어서서 일할 수도 있습니다. 30인치 모니터가 기본으로 제공됩니다. 직선형 책상은 L 자형 책상보다 패어 프로그래밍(Pair programming)과 코드 리뷰에 편리합니다. 모든 책상의 뒷편에는 20개의 전기 콘센트가 있고 대부분의 개발자들은 별도이 컴퓨터를 위한 작은 허브를 갖고 있습니다. 우리의 기본형으로 제공하는 의자는 Herman Miller Aeron 제품입니다. 손님용 의자는 Arne Jacobsen의 유명한 시리즈 7 입니다. 스토리지 받침대(The pedestal storage)는 바퀴가 달려 있고, 쿠션을 올려놓으면 이것도 손님용 의자로도 사용할 수 있습니다.


유리로 된 화이트 보드 : 지우기 쉽고, 아주 잘보이며 얼룩이 남지 않습니다.

커피 바 (Coffee bar)와 식당 : 에스프레소 기계와 음료수로 가득 찬 냉장고, 끝없이 제공되는 주전부리(Snacks), 그리고 맛있는 점심이 매일 제공됩니다. 모두 함께 점심을 먹는 것은 우리회사의 하이라이트 중 하나 입니다.

거대한 해수 수족관  : 이것은 사무실 중심부에 빛과 색을 입혀줍니다.

다수의 회의공간  : 식당에는 프로젝터와 자동 스크린이 있습니다. (주로 Rock Band 영상을 트는데 사용됩니다. Thanks Jeff Atwood) 여기에는 몇개의 작은 회의용 테이블이 마련되어 있고, 두개의 컨퍼런스 룸과 큰 S 형 쇼파가 있습니다.

도서관 : 구식 종이책으로 가득 채워져 있고, 점심 낮잠 자기에 완벽한 두 개의 가죽 안락의자가 있습니다.
 
샤워실  : (바닦과 천정이 대리석으로 되어있음) 덕분에, 사무실까지 자전거로 출근하거나, 일과중에 운동을 할 수 있습니다.

나무바닥으로 된 주변지역  : 덕분에, 스쿠터를 타고 한바퀴 주변 지역을 돌아볼 수 있습니다. 정숙성을 위하여 사무실 바닦에 카펫을 깔았습니다. 식당은 콘크리트 바닥으로 되어있는데, 그편이 환하고 멋지게 보입니다.

저는 이 글 안에 여러분이 새 사무실 공간을 느낄 수 있을만큼 충분히 어울리게 사진을 배치해 넣지는 못하겠습니다. 하지만 Picsa에 Fog Creek 사무실 사진들을 올려두었습니다. 만약 여러분이 최고의 작업공간을 만들기 위해 50만 달러나 투입한 이론적 배경에 관해 배우고 싶으시다면 "A Field Guide to Developers" 를 읽어보세요.

(끝)


저자에 관하여

ps. "A Field Guide to Developers"도 조만간 번역할 예정입니다.
ps2. 번역 글이 올라가는 중입니다. 개발자 생태보고서 1부 입니다.
Posted by 지그프리드 지그프리드
  오늘 읽은 글. S/W 전공자를 대상으로 한 입사 면접 시험에서 나온 질문. "S/W 개발자에게 가장 필요한 덕목은 무엇인가?" 라는 질문에 대하여 많은 입사 지원자들은 "성실성", "끈질긴 탐구능력", "창의성" 등의 대답을 했다. 글의 저자는 "지두력"이란 도서를 예로 들면서, 프로그래머에게 가장 필요한 덕목은 "문제해결력"이라고 꼽았다. 문제를 분석하고 가장 효율적인 해결방법을 찾는 능력이 프로그래머의 최고의 덕목이라고 생각한다는 취지의 글이었다.

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

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

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

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

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

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

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


원문보기

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 지그프리드 지그프리드

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/06   »
            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            
Total : 313,389
Today : 12 Yesterday : 11