'It'에 해당되는 글 35건

  1. 2014.03.17 거품청년, 스마트에이전트로 살아남다 - 김경훈, 한국트렌드연구소
  2. 2011.05.30 점심시간 Lunch
  3. 2011.03.05 IT 관련 세미나를 준비하는 방법 - 기술면접에도 적용 가능한 조언들 (2)
  4. 2010.09.18 또 개발자들 밤샌다고 자랑하는 얘기인가. 이젠 역겹다 (14)
  5. 2009.06.24 Clear 정신 - The eternal optimism of the Clear mind
  6. 2009.06.21 플랫폼 벤더들 - Platform vendors
  7. 2009.05.16 Stack Overflow 사이트 소개 (About Stack Overflow) (1)
  8. 2009.05.14 Stack Overflow DevDays : 스택 오버플로우 개발자의 날
  9. 2009.05.12 고과 평가가 잘못되었을 때는 누가 책임을 지는가? (2)
  10. 2009.05.09 왜 서킷 시티는 망했고, B&H는 성공했는가 (Why Circuit City Failed, and Why B&H Thrives)
  11. 2009.05.08 악역을 맡은 나의 슬픔 (2)
  12. 2009.05.04 개발자 생태보고서 6 (A Field Guide to Developers)
  13. 2009.05.02 개발자 생태보고서 5 (A Field Guide to Developers)
  14. 2009.05.01 극한직업 - IT는 어떨까? (8)
  15. 2009.05.01 프로그래밍은 상상이다 - 임백준 (4)
  16. 2009.04.30 개발자 생태보고서 4 (A Field Guide to Developers)
  17. 2009.04.29 개발자 생태보고서 3 (A Field Guide to Developers) (1)
  18. 2009.04.28 우울한 하루 1 - IT는 정녕 앞이 안보이는가 (1)
  19. 2009.04.25 Fog Creek의 새 사무실 - The new Fog Creek Office 2
  20. 2009.04.25 개발자 생태보고서 2 (A Field Guide to Developers)
  21. 2009.04.25 개발자 생태보고서 1 (A Field Guide to Developers)
  22. 2009.04.22 좋은 프로그래머의 조건 (2)
  23. 2009.04.21 당신은 뼛속까지 공대생 + 내 오리지널 버전 (8)
  24. 2009.04.20 프레젠테이션 젠 - 가를 레이놀즈 (Presentation Zen) (2)
  25. 2009.04.20 왜 나는 직원들이 임금협상을 하지 못하게 하는가? - Fog Creek의 보상 체계 2 (2)
  26. 2009.04.19 왜 나는 직원들이 임금협상을 하지 못하게 하는가? - Fog Creek의 보상 체계 1
  27. 2009.04.18 프런코 데이 - 이제 곧 마지막회 (Project Runway Korea)
  28. 2009.04.16 Animoto를 소개합니다. - 사진을 동영상으로 만들어주는 유용한 툴 (Useful tool to make Animated Presentation)
  29. 2009.03.31 생존하기는 얼마나 어려운가 : 벤처 회사의 전략 2 (How Hard Could It Be?: Start-up Static)
  30. 2009.03.25 나는 프로그래머다 - 임백준 등 공저


거품청년, 스마트 에이전트로 살아남다
국내도서
저자 : 김경훈,한국트렌드연구소
출판 : 퍼플카우 2012.11.19
상세보기



 

 아주 잘 정리된 2014 웹, IT 트렌드 

 


● 처음엔 저자에 "한국" 트렌드연구소 가 적혀있어서, 국내 소식이나 좀 다루고 마려나 하고 큰 기대를 하지 않고 읽었다. 그런데, 이 책을 읽으면서 내가 미처 알지 못했던 많은 서비스들을 발견하게 되었다. 사실, 이와 관련된 뉴스 기사를 거의 다 모니터링 하고 있어서 이 분야는 꽤 많이 안다고 자신하고 있었는데, 이 책은 큰 도움이 되었다. 


● 실시간으로 모니터링을 하고 있는 사람이 책에서 모르던 것을 알기가 쉽지 않은 일이다. 그만큼 이 책은 잘 씌여졌고, 나름의 트렌드를 정리해냈다. 웹 서비스와 IT 기획에 관심이 있는 사람이라면 꼭 한번 읽어볼만한 책이다. 내년이 되어서도 가치가 있을지는 모르겠지만, 2014년 3월 현재는 매우 시의성있고, 새로운 내용이었다. 

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

원문보기

Joel on Software

점심시간  

Lunch

by Joel Spolsky

 
Thursday, April 28, 2011


 
매일 점심시간을 어떻게 보내십니까? 어디에서 식사를 하나요? 누구와 식사를 하세요? 

  전 매일 팀원들과 점심을 같이 하는데, 정말 멋진 일입니다. 팀의 일원으로 인하는데 매일 함께 점심을 하지 않는다면, 최선의 경우에도 외로움 뿐이죠. 

  많은 대형 IT기업들이 식당을 가지고 있습니다. 가격이 공짜이거나(Google) 저렴합니다(Microsoft). 이런 회사들 안에서 몇몇 팀들은 매일 함께 식사를 하려고 노력합니다. 하지만, 많은 팀들은 그렇지 않습니다. 여러분이 점심시간에 이런 회사들을 돌아다녀 본다면, 몇몇 큰 그룹과, 많은 사람들이 둘씩 함께 먹으며 약속된 "점심 미팅"을 하는 것을 볼 수 있을 것입니다. 하지만, 또한 나홀로 식사를 하는 적지 않은 수의 사람들을 보게 될 것입니다. 아마도 그들은 책을 보거나 그들의 E-mail을 보면서 식사를 할테고, 그렇게 슬퍼 보이지는 않겠지요. 아마도 그들은 점심을 가지고 자기 자리에서 먹기때문에 회사식당에 혼자 앉아 있지는 않을지도 모릅니다. 어쩌면 태생적으로 사람들을 싫어해서 혼자서 먹는 것을 좋아할지도 모릅니다. 또는, 그냥 그렇게 얘기하는 걸지도 모르죠. 

  구글과 마이크로소프트에서는, 회사식당이 너무 붐벼서 혼자 먹는 사람들이 다른 그룹에 끼어 앉아 먹을 수 밖에 없습니다. 종종, 그들이 끼어앉은 그룹의 사람들이 혼자 먹으러 온 사람들을 그들의 대화에 끼어주기 위하여 노력을 하기도 합니다. 보다 많이 보이는 광경은, 혼자 먹는 사람들이 문자 그대로 스마트폰을 가지고 Facebook에 몰두 하고 있는 모습을 보여주어 사회적 접촉을 피하고 싶다는 메세지를 보내는 것입니다. 죄송하게도, 전 여러분에 제 소개 하는 것을 좋아합니다만, 제 페이지를 업데이트하는 것이 너무 중요하네요. 

  어디에서 누구와 점심 식사를 같이 하는가는 제게는 보통사람들이 생각하는 것보다 아주 중요한 문제입니다. 분명하게, 심리학자들이 증언하고, 또 분명하게, 우리의 어린시절, 특히 학창시절, 그중에서도 중학생 시절을 되돌아보면, 어디에서 누구와 함께 식사를 하는 것은 아주아주 중요한 일입니다. 어느 파벌에 속하여 먹는가, 심지어 당신이 그냥 샌님 그룹(Nerd)의 일원이라도, 혼자 먹는 것보다는 훨씬 사람들이 좋아합니다. 혼자먹는 사람들과 괴짜(Geek)들에게는 사람들과 식당에서 함께 식사하는 것도 큰 스트레스 입니다. 

  여러분의 동료들과 함께 식사하는 일은, 제게는, 포기할 수 없는 중요한 일입니다. 이것이 우리가 작은 원탁에 나누어 앉기 보다, 긴 테이블에 함께 앉아 먹는 이유입니다. 이것이 신입이 우리회사에서 일을 시작할 때 식당 한 구석에 떨어져 않는 것이 허락되지 않는 이유입니다. 우리회사에 방문객이 올때면, 그들도 다른 모두와 함께 앉아 먹습니다. 

  심지어 Stack Exchange와 Fog Creek이 완전히 분리된 별개의 회사임에도 불구하고, 우리는 우리의 사무실이 한 건물에 있다는 장점을 이용하여 매일 함께 식사를 합니다. 저는 이런 기회가 있어서 매우 기쁩니다. 많은 사람들이 파벌을 만들어 함께 앉는 경우가 매일 늘어가더라도요. 

  Fog Creek과 Stack Exchange에 많은 사건사고들이 있었지만, 점심식사가 그중의 하나는 아닙니다. 10년전 마이클과 제가 다소 야심찬 "좋은 일터 만들기 (Great work place)" 계획을 만들었습니다. 회사의 첫 날 부터, 함께 식사를 하는 것은 인간미있고 인정이 넘치는 일터를 지향하는 우리의 핵심 가치가 되었습니다. 
 

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


Posted by 지그프리드 지그프리드
● 바야흐로 새학기고, 기업들의 취업 설명회 시즌이다. 조금 더 있으면 신입사원 채용이 있을 것이고, 필기시험을 통과한 사람들에게는 기술 면접을 위한 프레젠테이션 준비가 필요할 것이다. 이 모든 채용과정을 통과해 신입사원이 된다면, 회사에서 직무 적응을 위한 이른바 "신입사원 세미나" 준비를 시작하게 될 것이다. 이게 일반적인 IT 관련 회사의 모습이다. 

● IT 관련 세미나를 준비하는 것은 쉽지 않다. 여라가지 이유가 있겠지만, 우선 IT관련 신기술들은 대부분 미국에서 만들어지고, 관련된 최신 자료는 당연히 영어로 되어있다. 독해를 하는 것도 쉽지 않은데, 독해한 내용을 이해하고 요약정리하는 것은 훨씬 더 어려운 일이다.  둘째로, 간혹 번역된 자료를 찾는다 하더라도, 오역되거나, 문장의 앞뒤가 안맞는 경우가 종종있다. 심지어, 번역하는 기간 (짧게는 1달, 길게는 1년 이상)  사이에 스펙이나 컨셉이 바뀌어 버리는 경우도 있다. 셋째로, 공대생들은 일반적으로 다른 사람 앞에서 자신이 아는 바를 명쾌하게 발표하는 것이 어렵다. 아는 것을 쭈욱 나열하는 것은 잘하지만, 열심히 준비한만큼, 나열할 것도 많아 스토리가 없는 이야기가 되기 쉽다. 특히, 자신은 열심히 공부해서 잘 아는 내용을 IT배경지식이 없는 사람에게 풀어 설명하는 능력이 없는 경우가 많다. 실제로, 4학년 때 모의면접 시험장에서 졸업작품에 대해 설명해 보라는 질문에 우리과 탑이던 학생의 대답이, "802.16 WAVE 관련 프로토콜 에뮬레이터를 제작했습니다." 라고 대답을 했다. "그게 뭔가요?" 라는 면접관에 질문에 WAVE 란 단어를 반복하며 자신이 한 일을 설명했는데, 졸업작품을 같이 했던 네 명 외에는 강의실 안에서 그 설명을 알아들었을 사람이 아무도 없었다. 

● 이번에 신기술 관련 세미나를 준비하면서 알게된 몇가지 팁을 공유하려 한다. 전통적인 방법도 있고, 새로운 방법도 있다. 모쪼록 기술 면접을 준비하는 학생들과 선배들 앞에서 세미나 준비하느라 밤을 지새고 있을 신입사원들에게 도움이 되었으면 좋겠다. 

   1. 기본은 책. 세권 이상 읽어라  
 

  세미나를 준비하게 되는 내용은, 보통은 책이 한 두권은 나온 상태일 것이다. 그 책이 번역본일 수도 있고, 아직 원서 밖에 안나온 경우도 있겠지만, 책이 기본이다. 스펙문서를 책의 저자가 한번 정리를 해서 책으로 엮은 것이기 때문에, 나름의 스토리를 잡기가 편리하다. 

  어떤 주제에 대해 공부를 할 때, 서로 다른 저자가 쓴 같은 분야의 책을 여러권 읽는 것은 "다치바나 다카시" 의 방법이다. "나는 이런 책을 읽어왔다" 에 보면, 그는 새로운 탐구대상이 정해지면 책을 3m, 혹은 30만엔 어치 읽는 다고 한다. 그렇게 어떤 분야의 책을 여러권 읽다 보면 각각의 책 마다 중복되는 내용이 있기 마련인데, 바로 그 부분이 그 분야에서 가장 중요한 내용이란 뜻이다. 그럼, 다시 그 중요한 부분에 대해 심화 설명한 책을 찾아 읽어가는 방식이 다치바다 다카시가 연구할 때 사용하는 방식이다. 세미나를 준비하면서 그와 관련된 책을 여러권 읽어보면 그 분야에서 가장 중요한 부분이 보이기 시작한다. 

   2. 책의 내용을 스펙 문서에서 확인하라
 

  앞서 말했듯이, 책은 출간되는데 시간이 걸린다. 원서라 하더라도 현재 최신 스펙과는 다소간의 차이가 있을 수 있다. 안드로이드 같이 계속해서 발전해 나가는 분야의 경우 몇달 사이에 새 버전이 나오면서 기존 API가 완전히 달라지거나 쓸모없는 내용이 되버리는 경우도 있다. 연구하는 분야가 신기술, 살아 움직이는 프로젝트에 관련된 것이라면 반드시 최신 스펙문서와 책에서 참고한 스펙문서와의 차이점을 확인해야 한다. 

  이 부분을 간과했다가는 세미나나 기술면접 자리에서 바보될 수도 있다. 

   3. 영문판 위키피디아 (Wikipedia) 를 활용하라 
 

  반드시, 영문판 위키피디아를 활용하라. 한글판은 안된다. 가장 큰 이유는 한글판은 영문판에 비하여 내용이 부실한 경우가 많다. 가장 한국적인 주제라고 할 수 있는 "화차 - 신기전" 에 관한 내용도 영문판 위키피디아의 내용이 한글판을 압도한다. (직접 확인해 보기 바란다. 깜짝 놀랄 것이다.) 미국에서 개발된 IT 신기술에 관해서는 더 말할 필요도 없다. 
 
  다만, 어떤 내용에 있어서는 책에서 중요하다고 생각하는 내용과 위키피디아에서 중요하다고 생각하는 부분이 다를 수 있다. 이런 경우 2번을 믿는 편이 좋다. 위키피디아는 시간이 없을 때, 특정 용어에 대한 정의를 내리고 요점을 파악하고, 연관된 다른 기술분야를 빠르게 탐색하는데는 도움이 되지만, 경험상 "발표자료용 스토리"를 짜는 데는 도움이 되지 않는다. 중요한 내용을 골라내는 것은 1번의 방법이 기본이다. 


★★ 여기부터는 중요체크 ★★


   4. 다른 사람의 세미나를 들어라  
 

  구글을 검색해 보면, 특히 IT 분야의 경우, 다른 사람이 관련 주제를 가지고 세미나나 프레젠테이션을 한 동영상을 쉽게 찾을 수 있다. 유튜브 (https://www.youtube.com), 비메오 (http://www.vimeo.com), TED (http://www.ted.com/) 등이 유명한데, 기술적인 자료는 TED에는 별로 없을 것이다. 소스가 어디이던 간에, 구글 검색하면 다 나온다. 

  이곳에서 공부하고자 하는 분야의 세미나를 들어라. 간혹 MC 스나이퍼 저리가라 할 정도의 속사포 랩을 구사하는 사람도 있고, 알아듣기 어려운 인도식 영어를 하는 경우도 있지만, 왠만하면 알아들을 만은 하다. 영어를 완전히 알아듣지 못할지라도 발표자료와 어느 부분이 중요한지 강조하는 부분, 발표 스킬과 눈을 끄는 자료와 사진, Demo 등은 충분히 구할 수 있다. 부장님 이하 모든 사람을 자게 만들 뻔한 세미나를 모든 사람이 유쾌하게 웃으며 듣는 세미나로 바꿀 수도 있다. 자료, 비유, 데모 만 건져도 성공이다. 

  기술면접에 있어서도 마찬가지다. 슬라이드나 참고자료, 데모는 따오지 못하겠지만, 발표 주제에 대한 핵심 내용을 파악하는 것은 충분히 가능하다. 그리고 이미 들어본 주제에 대한 "아는 척" 하는 데는 이보다 더 좋은 방법이 없다. 

   5. 다른 사람의 슬라이드를 참고하라  
 

  참 고맙게도, 세미나 동영상 외에 슬라이드와 핵심 내용을 공유하는 사이트가 있다. 슬라이드쉐어 (http://www.slideshare.net/) 이 그곳이다. 간단한 회원 가입만으로 기술 세미나 관련 슬라이드를 다운 받을 수 있다. 그말은 곧, 뛰어난 이미지, 그래프, 소스코드 (PPT용으로 캡춰된 것이지만) 등을 내 세미나에 사용할 수 있다는 뜻이다. 4번 못지 않게 귀중한 자료들을 얻을 수 있다. 다만, 슬라이드와 함께 했던 발표내용은 좀 단편적인 요약밖에 없다는 것이 단점이다. 


   6. 결국, 영어다.  
 

  불행히도, 최신 자료는 영어로 되어있다. 참고할 만한 세미나도, 발표자료도 영어로 되어있다. 영어가 안되면 모든게 그림의 떡이다. 

  공대생이라면, TOEIC 점수에 매달리기 전에, 원서와 씨름하고 매달려라. 스펙문서, 기술자료, 최신 트렌드 관련된 블로그 포스팅 하나라도 더 보고, 직접 번역도 해봐라. 공대 1, 2 학년 때 해야 하는 일 중 가장 중요한 일은 프로그래밍 언어를 읶히는 것 보다영어능력 향상이라고 생각한다. 프로그래밍 언어는 신기술 나오면 자신이 공부하지 않은 분야로 갈야타는 일도 빈번하지만, 영어는 죽을 때까지 쓰는 거고, 신기술 나오면 더 절실해 지는 것이 영어다. 스펙 보다다, 책 보다가 막히는 부분이 있으면 저자에게 직접 문의 메일을 쓸 수 있는 수준의 영어는 갖춰놓으면 좋겠다. 

   7. 세미나, 기술면접도 스토리가 필요하다
 

  사실, 이 포스팅을 시작한 것은 4번, 5번 관련된 조언을 하고 싶어 포스팅을 하게 되었다. 하지만, 역시 기본은 책이다. 책을 읽고 듣는 세미나와 그냥 듣는 세미나는 천지차이다. 참고는 하되, 결국 자기 세미나를 자기 스토리를 가지고 해야 하는 것이다. 

  세미나던 기술면접이던간에, 사람들 앞에서 발표하는 것은 "이야기"하는 것이고 "이야기"는 기승전결을 갖춘 스토리가 필요하다. 세미나와 면접은 주로 두괄식으로 주제를 먼저 이야기 하고 설명해 나가는 방식이 되겠지만, "왜" 이런 기술이 나오게 되었는지 설명하는 배경(기)부터 어떻게 진행되어 왔고 (승) 현재 어떤 문제점, 난관이 있으며 (전), 앞으로는 어떻게 진행되어 나갈 것이다 (결) 는 한편의 스토리가 있어야 한다. 

  IT 기술은 갑자기 툭 튀어나온 것이 아니다. iPhone 이전에 iOS가 있었고, 피쳐폰 시장이 있었다. 모든 것은 기승전결의 스토리를 만들 수 있다. 서사구조를 갖춘 이야기를 할 때에 세미나던 기술면접이던 사람들이 집중해서 듣는 발표를 할 수 있다. 

  발표 자료 양이 많다고 느껴진다면, 과감하게 뺄건 빼고 자신의 이야기만 남겨라. 나머지는 "다음에 새로운 주제로 발표하겠다" 거나 "더 알고 싶으신 분은 이 자료를 참고하라" 고 레퍼런스를 제공하면 되는 것이다. 모든 것을 다 하겠다는 공대생의 욕심이 화를 불러온다. 기술면접도 마찬가지다. 거짓말만 안하면 된다. 아는 것을 설명하는 기술을 보는 것이지, 모든걸 다 아는 사람을 뽑는 자리가 아니다. 

  

● 몇년 만에 세미나 준비를 하다보니 나름 노하우가 많이 생겨있다는 것을 느껴서 포스팅을 합니다. 후배님들에게 많은 도움이 되었으면 좋겠습니다. 
Posted by 지그프리드 지그프리드
 
● LG전자 스마트폰 따라잡기 총력전

  동아일보에 위 링크와 같은 기사가 실렸다.  아파트 다섯개 동을 리모델링해서 개발자들을 잡아두고 신모델 개발에 박차를 가하고 있다는 얘기다. 이런 기사는 우리나라에서는 심심찮게 올라오는데, IT종사자들 사이에서 공분을 일으켰던 티맥스 사장의 발언 - 이거 개발하다 이혼한 직원들도 많다 - 이나, 베가 개발하면서 개발자들 야식비로만 수천만원을 썻따는 얘기 같은 것들이다.

  IT 개발자들의 푸대접과 비인간적인 노동조건이 다음 에서도 크게 문제가 되었었다. 그럼에도 전혀 개선의 여지가 없는 것은 이런 기사들을 보고도 노동부가 전혀 느끼는 바가 없기 때문이다. 이 기사를 읽으면서 "아 그렇군 이렇게 열심히 해야지" 라던가 "이렇게 열심히 하고 있으니 곧 성과가 나오겠군 대단하다" 라는 생각이 든다면, 뭔가 크게 잘못된 것이다. 이건 그냥 인권침해사례일 뿐이고, 노동법 위반 사례일 뿐이다. IT 개발자들이 혹사당하는 원인에 대해서 하청 - 재하청 관계가 문제다 라는 글이 많았지만, 내가 보기에는 모든 원인은 정부가 노동법을 지키지 않아도 눈감아 버리는데 있다. 법대로 잔업하고, 법대로 잔특근 수당을 줘야 한다면, 하청업체가 원청업체에게 이 일은 못한다고 선을 그었을 것이다. 왜? 인건비가 단숨에 두 배가 되어 남는 것이 없었을 테니까. 모든 원인은 노동법이 유명무실한데 있다.

  기본적으로 우리나라에서는 주당 40시간 노동을 기본으로 하고 있고, 잔업과 특근을 회사가 명할 수는 있지만, 그 또한 제한이 있다. 잔업 수당은 일일 임금의 1.5배, 특근비는 2배를 지급해야 하지만, 그 또한 제대로 지키고 있는 회사가 없다. 알만한 사람들은 다 아는 얘기다. 정부 관계자만 모르는 얘기지.

  지난 달 우리 과장님은 잔업만 104시간이었고, 나도 잔특근 합쳐서 100시간 넘었다. 근데, 이런거 아무도 이슈로 생각하지 않는다. 회사야 이런줄 알고 들어왔으니 회사에 대해서는 불만이 없다. (내 발로 걸어나갈 생각도 없다. 몇번 언급했지만, 난 과분하게 받고 있다. 물론 돈이 전부는 아니다. 절대로.) 하지만, 정부에서, 회사 고위 임원들이나 홍보자료로 스스로 무리한 잔업을 강요하고 있다고 자랑스럽게 밝히고 있는데도 아무런 대응을 하지 않는 것에는 정말 화가 난다. 과연 노동부는 뭐하는데고, 근로감독관들은 손빨고 있는건가.

  회사 통근버스 터미널에 서서, 사람들이 몇시에 출근해서 몇시에 퇴근하는지 일주일만 지켜봐도 결론이 나는 얘기를, 몇십년째 계속해서 - 좀 더 희화해서 말하면, 사원으로 입사해서 사장 달 때 까지 - 초과근무를 하는 곳이 우리나라 대기업이라는 곳이다. 지금보다 5년전에는 더했고, 그 5년전 보다 10년전에는 더했다. 진대제 전장관의 책에도, 자기는 무슨 생각으로 적었는지 모르겠지만, 반도체 개발이라는 명분으로 자기 밑에 직원들이 얼마나 혹사 당했는지 얘기가 나온다. 자신이 진두지휘하고 다 같이 뺑이를 쳤다고 위법이 정당화 되는 것은 아니다.

  다시 말하지만, 이건 회사의 문제가 아니다. 이렇게 하지 않는 회사를 가려면, 대한민국에는 취업할 곳이 몇몇 공기업과 외국계 회사 밖에는 남지 않는다. 이건 회사의 문제가 아니라, 이걸 그냥 수수 방관하고 있는 정부의 문제이고 사회의 문제이다. 2010년을 살아가면서, 여전히 1970년대의 "일 자리가 있으니 배부른 소리를 한다" 는 마인드로 사회가 돌아가는 것이 가장 심각한 문제이다. 언제까지 이러고 살건가.

  이런 와중에 속시원한 이야기 하나. 모 과장님이 부장님이 되었다. 역시 승진의 제 1원인은 혹독하리만큼 밑에사람들을 닥달하는 재주. 새로운 팀이 조직되어 0부터 시작해서 새로운 제품을 만들게 되었다. 다시 시작된 엄청단 쪼임 속에, 밤새서 결과를 만들어 내라는 지시가 "메일" 로 내려왔다. 몇주를 진행하다 더이상 견디다 못한 팀원들이, 상소를 했다. 부서 인사팀이나, 회사 인사과가 아닌, 그룹 저 위로 직소를 했다. 그룹차원의 조사가 이루어졌고, "메일"로 지시를 내렸던 명백한 물증 앞에 이 부장님은 한직으로 날아가 버렸다. 팀은 해체가 되었는지, 부장님이 바뀌었는지 모르겠지만, 이후 살살 쪼라는 공문이 윗분들 사이에 돌았다고 한다.

 여운을 남기는 질문들 - 1) 살살 쪼라는 공문이엇을까, 증거를 남기지 말라는 지시였을까? 2) 한직으로 날아간 부장님은 "아 내가 너무했구나" 라고 반성을 했을까 아니면 "이런 XXX 들, 내가 너무 살살 다뤘구나" 라고 생각했을까? 3) 이 부장님도 한 집안의 가장이었을 텐데, 밑에 사람들 와이프나, 아이들을 만나봤을까? 만났다면 무슨 얘기를 들었을까?


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

Clear 정신 : 영원한 낙관주의

The eternal optimism of the Clear mind

by Joel Spolsky
Tuesday, June 23, 2009

원문보기


  방금,  클리어(Clear)가 문을 닫았습니다.

  문을 닫기 전, 클리어의 사업 방식은 이러했습니다. 200달러로 1년간 회원 자격을 얻습니다. 여러분은 자신이 아주 아주 많이 신뢰할 만한 사람(extra-super trustworthy)이라는 것을 증명하기 위하여 세세하고 많은 배경조사를 받게 됩니다.

  그 댓가로 몇몇 대형 공항에서 교통안전국(TSA : Transportation Security Administration)의 검색대 앞의 줄을 건너뛸 수 있게 됩니다.

  이렇게 해도, 검색 자체를 건너뛸 수는 없었습니다. 여전히 엑스레이를 통과해야 했고, 신발, 벨트, 주머니 속 휴대품, 노프북 그리고 화장실 용품이 들어있는 플라스틱 지퍼백까지 꺼내놓아야 했습니다.

  여러분은 단지 대기열의 맨 앞으로 질러 갈 수 있었을 뿐입니다.

  소수의 사람들만이 가입을 했습니다. 사실, 어떤 공항에서는 대기열의 맨 앞으로 질러가는데 진짜 돈이 더 도움이 되기도 했습니다.

  이것은 클리어의 진짜 사업 계획이 아니었습니다. 진짜 사업계획은 클리어가 여행자들의 세세한 배경조사를 함으로써 아주 아주 많이 믿을 만한 사람들은 보안 검색을 완전히 건너뛰게 하는 것이었습니다.

  실제로는, 교통안전국은 비행기 파일럿들 조차 신뢰하지 않았습니다. 파일럿들도 우리와 마찬가지로 3.5온스 들이 샴푸통 같이특별히 위험한 무언가를 들고 비행기에 탑승하지 않는지 보안 검색을 받아야만 했습니다. 그 이유는, 당연히도, 작은 샴푸 한 병을 가지고도 그들이 폭탄을 만들 수도 있기 때문입니다. 그 폭탄을 이용해서 그들이 조종하는 비행기를 건물로 충동시킬 수도 있겠지요. 제트기 조종석에 앉은 순진한 파일럿들에게는 불가능한 일이지만 말입니다.

  여기서 드러난 것과 같이, 교통안전국은 한번도 검색대를 지나치는 것을 실질적으로 동의한 적이 없었습니다. 결과적으로 클리어가 할 수 있었던 일은 단지 대기열을 건너 뛰는 것 뿐이었습니다.

여기서, 이 점이 재미있는 것인데요, 바로 여기서, 이성적인 사업가라면 이렇게 물을 것입니다. "음, 우리가 진짜로 보안검색을 건너뛸 수 없다면 클리어의 사업 아이디어는 말이 안되는 것 아닌가요?"

  좋습니다. 어쩌면, 대기열의 맨 앞으로 질러가는 것에 요금을 부과했을 수도 있겠습니다. 어쩌면 그들의 사업 모델이 그런 것이었겠죠.

  그렇다면, 왜 여전히 그들이 우리의 배경조사를 하는거죠? 이것은 말이 되지 않습니다.

  사업 환경이 바뀌었습니다. 보안검색을 미리 진행한다는 클리어의 사업 모델은 불가능한 것으로 드러났습니다. 하지만 그들은 어쨌든 그 일을 계속 하고 있었습니다. 어떤 종류의 조직적 기능장애가 환경의 변화를 깡그리 무시하고 손해보는 장사를 계속하게 하였습니까?

  더욱 웃기는 점은, 그들의 사업 모델에서 불필요하고 멍청하기까지한 한 부분만 생략했어도 여전히 수익을 낼 수 있을지도 모른다는 것입니다. 고객의 세세한 배경조사 말입니다.

  클리어에 있는 어느 누구도 생각을 하지 않았습니다. 그들은 사업 모델은 갖고 있었지만, 그 사업모델은 실제로 가능하지 않았고, 모든 사람이 그 점을 알고 있었지만, 여전히 그 일을 부지런히 했습니다. 생각없는 낙관주의지요. 저는 그들에게 경례를 해야 할지 웃어야할지 모르겠습니다.



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


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


  Stack Overflow무료 프로그래밍 Q & A 사이트 입니다. 질문을 올리는 것도 무료이고, 답변을 다는 것도 무료 이고, 글을 읽는 것도 무료, 인덱스를 다는 것도 무료 입니다. 평범하고 전통적인 HTML로 만들어져 있고, 낚시글은 없습니다.(no fake rot13 text on the home page), 쓸데없는 구글 검색에 걸리지 않게하는 기술을 사용하지 않고, 장사꾼도 없고, 질문 당 12.95달러를 요구하는 자바 스크립트 윈도우도 나오지 않습니다. 여러분이 카르마(karma : 지식인의 내공과 비슷한 점수 : 역자 주)를 모으거나 가치있는 명성을 얻어 여러분의 이름 옆에 나타나게 하고 싶다면 사이트에 가입하실 수도 있습니다. 하지만, 그렇지 않다면, 이 사이트는 그냥 무료 입니다. 그리고 빠릅니다. 아주, 아주 빠르지요.

  여러분은 Stack Overflow를 운영하지 않습니다. 정말로요. Stack Overflow는 여러분의 동료 프로그래머들에 의하여 공동으로 만들어지고 유지됩니다. 일단 시스템이 여러분을 신뢰하게 되면, 여러분은 모든 것을 편집(수정)하실 수 있게 됩니다. 마치 위키피디아 처럼요. 여러분의 도움으로, 우리는 좋은 답변들과 상상할 수 있는 모든 프로그래밍 관련 질문들로 이루어진 사이트를 만들 수 있습니다. 어떤 프로그래밍 언어를 사용하지, 혹은 어떤 OS를 여러분이 메인으로 사용하는 지는 중요하지 않습니다. 더 나은 프로그래밍이 우리의 목적입니다.

  우리는 Stack Overflow를 마찰이나 고통없이 사용할 수 있다도록 만들었습니다. 여러분의 프로그래밍 관련 질문들에 대한 정답을 성공의 구덩이에 빠지는 것 만큼 쉽게 (as easy as falling into the pit of success) 찾을  있을 것으로 확신합니다. 아마도 그 길을 따라가는 동안에 약간의 재미도 있을 것입니다.

그래서요? 누가 신경이나 씁니까? 이건 그냥 수없이 많은 다른 웹사이트랑 같은거 아닌가요?

  이 사이트가 뭐가 그렇게 특별하냐고요? 예, 아무것도 없습니다. 정말로요. 이것은 프로그래밍 Q&A 사이트 입니다. 유일한 다른 점은 우리는 위키, 블로그, 포럼, 그리고 디그/레딧 (Digg/Reddit)의 고유한 모든 특성을 통합했다는 것입니다. 혹은, 최소한 우리는 이 사이트를 그렇게 만들었다고 생각합니다.


Venn diagram: Wiki, Digg/Reddit, Blog, Forum

  Stack Overflow는 위 그림에서 가운데 있는 작은 별표(*) 입니다.

  하지만, 희망적이게도, 여러분은 우리가 이야기 하는 것을 스스로 경험하는 동안에 알게 될 것입니다.

당신들은 누구입니까?

  우리는 여러분과 같은, 대단한 소프트웨어를 만드는 일을 사랑하는 소프트웨어 엔지니어입니다. Stack Overflow team은 다음과 같습니다.

picture of Joel Spolsky
Joel Spolsky
New York, NY
picture of Jeff Atwood
Jeff Atwood
El Cerrito, CA
picture of Jarrod Dixon
Jarrod Dixon
Morganton, NC

picture of Geoff Dalgas
Geoff Dalgas
Corvallis, OR
picture of Jeremy Kratz
Jeremy Kratz
Little Rock, AR
picture of Brent Ozar
Brent Ozar
Whitehall, MI


당신의 이야기와 사진은 정말 매력적이네요. 더 알 수 있을까요?

  Stack Overflow FAQ를 확인하십시요. 우리에게 연락하실 필요가 있다면, team@stackoverflow.com 으로 하시면 됩니다.

(끝)

PS. 프로그래밍 하시다가 막히는 부분이 있다면 질문을 올려보세요. 현재 세계에서 가장 유용한 프로그래밍 관련 사이트 입니다. 물론, 영어로 올리셔야 겠지요.

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

원문보기

  Stack Overflow 는 조엘 스폴스키(Joel Spolsky)와  제프 앳우드(Jeff Atwood)가 함께 만든 S/W Q&A 사이트 입니다. 네이버 지식인과 비슷한 시스템이지만, 질적 수준은 전혀 다릅니다. 대부분의 프로그래밍 관련 질문 중 90%가 답변을 얻고 있고, 누구나 로그인 절차 없이 질문을 올리고 답변을 얻을 수 있습니다. (역자 주)


스택 오버플로우 개발자의 날 행사 (Stack Overflow DevDays)

By Joel Spolsky
Tuesday, May 12, 2009

  사람들이 점점 더 스택 오버플로우(Stack Overflow)에 열광하고 있습니다. 사이트를 시작한 지 단 6개월 만에 우리는 매달 3백 50만명의 중복되지 않은 방문자들이 찾아 오고 있습니다. 우리는 현실세계에서 이 위대한 개발자 부족(great tribe of developers)을 어떻게 모이게 할지 고민하기 시작하였습니다.


  우리는 일련의 Stack Overflow 이벤트들을 개최하기로 결정하였습니다. 첫번째 위대한 개발자 부족의 회합은 90% 이상의 질문이 답변을 얻을 만큼 대단히 성공적이었습니다. [Video]

  우리는 다가오는 10월에, 5개의 도시 각각에서 하루짜리 이벤트를 기획하고 있습니다.

  우리는 이 하루짜리 이벤트에 가능한 많은 다양한 주제들을 체워넣기로 결정했습니다. 마치 뛰어난 레스토랑이 선보이는 음식들의 맛을 보는 것 처럼, 우리는 각각의 도시에 여섯 명씩 위대한 강사들을 준비했습니다.

  이 행사는 단순히 자바 컨퍼런스나 닷 넷 컨퍼런스나 루비 컨퍼런스가 되지는 않을 것입니다. 어떤 분은 마이크로 소프트의 새로운 웹 프레임워크인 ASP.NET MVC를 소개할 것이지만, 다른 분은 구글의 새로운 모바일 운영체제인 안드로이드 코드를 작성하는 법에 관하여 이야기를 할 것입니다. 그리고 각각의 도시에서 한분 씩 그 지역의 컴퓨터 과학과 교수님이나 대학원생을 초청해서 학계에서 관심있어 하는 새로운 주제에 관하여 저희에게 이야기 할 수 있도록 할 것입니다.

  자신이 몸담고 있는 분야에서 조금 바깥에 있는 것들을 배우고 싶어하는 똑똑한 프로그래머들이 계시다면, 이 컨퍼런스는 바로 당신을 위한 것입니다. 우리는 Byte Magazine(1970~80년대에 유명했던 컴퓨터 잡지로, 컴퓨터와 관련된 모든 분야를 다루었습니다. 역자주)  정신으로 이 일을 준비하고 있습니다. Byte를 기억하십니까? 방대한 영역의 이슈들과 기술들을 다뤘던 잡지 입니다. 슬프게도, Byte는 사라졌고 그 자리를 Mac 만 다루는 잡지(Mac only magazine), IBM만 다루는 잡지, 심지어 마이크로 소프트 SQL 서버만 다루는 잡지 들이 대신하고 있습니다.


이러한 컨퍼런스를 여는 것은 정말로 돈이 많이 듭니다. 컨퍼런스 센터는 커피 한동이에 1,000달러를 부르기도 합니다. 이것이 일반적인 개발자 컨퍼런스 참가비가 1,500달러나 하는 하는 이유입니다. 여기에 여행경비, 숙박비, 그리고 여러분의 호텔 방에서 인터넷을 접속하기 위한 73달러가 추가됩니다. 현재의 전세계적인 경제위기 속에서, 단지 가격이 오르지 않았을 뿐입니다. SD West같은 많은 위대한 컨퍼런스들이 취소되었습니다. 살아남은 컨퍼런스들도 참석자 수가 줄어드는 추세입니다.

  그래서, 라이언 카슨(Ryan Carson, 그의 회사는 FOWA와 같이 뛰어난 컨퍼런스를 개최하는 Carsonified 입니다.)과 함께 이 비용들을 어떻게하면 최소화 할 수 있는지 계산해 보았습니다. 결과는, 첨석자 당 99달러 입니다.

  그렇습니다. 이 하루짜리 컨퍼런스는 단지 99달러 입니다. 여러분은 보통의 컨퍼런스보다 적은 비용으로 여러분 팀원 모두를 데려오실 수 있습니다.

  우리는 다섯 도시에서 이 컨퍼런스를 개최합니다. 어쩌면 여러분은 여행을 하지 않으셔도 될 것입니다. 각 도시당 단지 300명의 개발자 분들 만을 모실 수 있는 공간을 마련했습니다.

        10월 19일 샌프란시스코
        10월 21일 시애틀
        10월 23일 토론토
        10월 26일 워싱턴 DC
        10월 28일 런던

  스택 오버플로우 개발자의 날 행사에 지금 등록하십시요. 참석을 원하시는 분들은 많습니다만, 입장권은 제한되어 있습니다. 다섯 도시의 입장권이 모두 순식간에 팔려버릴 것 같습니다.

  다음은 FAQ 입니다.

  누가 강연을 하나요?

  저는 모든 도시에서 강연을 할 것입니다. 제프 앳우드는 샌프란시스코 에서만 모습을 보일 것입니다. 우리는 각각의 도시에 여섯 분의 강사를 모셨습니다.

  어떤 주제들을 다루게 되나요?

  아직 세부 주제까지 정해지지는 않았습니다. 주제는 강연자의 능력에 달려 있습니다. 저는 다음 주제들 중 가능한 많은 것을 다루어 줄 수 있는 강연자를 구하기 위해 최선을 다하고 있습니다.

  ●  안드로이드
  ●  Object C와 iPhone 개발
  ●  구글 App 엔진
  ●  파이선
  ●  jQuery
  ●  ASP.NET MVC
  ●  FogBugz 7.0
  ●  역동적이면서 분산된 버전 관리

  각각의 강연들은 어느정도는 각각의 주제를 소개하는 내용이겠지만, 경험 많은 개발자들(Advanced developers)을 대상으로 한 내용이 될 것입니다. 만약 여러분이 이미 주제에 대해서 알고 계시다면, 말씀하십시요. iPhone 개발과 관련된 것이라면, 복도에서 다른 iPhone 개발자들과 사귀실 수 있을 것입니다.

  모든 도시의 컨퍼런스가 동일한가요?

  정확히는 아닙니다. 몇몇 주재들은 반복되겠지만 - 제 강연은 다섯 도시에서 동일할 것입니다 - 각각의 도시의 강연자와 주제들이 완전히 동일하게 하지는 않을 것입니다. 우리는 최소한 한 도시에 한 명의 그 지역의 강연자를 모시려 합니다.

  저 배고파요!

  저도 그렇습니다. 저는 항상 배가 고픕니다. 아침, 점심 그리고 오후 티타임 간식까지 티켓 가격에 포함되어 있습니다. 이 컨퍼런스의 재미의 절반은 다른 스택 오버플로우 회원들과의 만남이 될 것입니다.

  행사가 어디에서 진행되나요?

  우리는 아직 강당을 예약하지는 않았습니다. 정확한 장소는 추후에 발표할 것입니다. 장소를 예약하는데 어려움이 있다면, 날짜가 조정이 될 가능성도 약간 있습니다.

  Note : 만약 여러분의 회사가 이 도시들에 있고, 300 명이 들어갈 수 있는 강당이 있다면, 여러분을 스폰서로 모시고 싶습니다. 이메일을 주세요. (devdays@stackoverflow.com)

  어떤 복장을 하고 가야 하나요?

  여러분의 스택 오버플로우 아이디와 명성(지식인의 내공과 비슷한 것 : 역자 주)으로 티셔츠를 만드세요. (오른쪽의 예제를 보세요) 이곳에서 주문을 하시거나 직접 만드셔도 됩니다.

  제가 도와드릴 일이 있나요?
 
  아, 물어봐 주셔서 감사합니다. 이 모든 일을 하기 위해서 우리는 많은 도움이 필요합니다.

  ●  우리는 각각의 도시에 자원봉사자가 필요합니다. 이 다섯 도시 중 한 곳에 살고 계시고, 티켓을 체크하거나 그 외에 일반적으로 컨퍼런스에서 유용한 일들을 도와주실 수 있다면, 이메일을 주십시요. (devdays@stackoverflow.com)

  ●  식사와 간식을 지원해주실 스폰서가 필요합니다. 여러분의 회사가 스폰서가 되기를 원하신다면, 이메일을 주십시요. 이것은 슈퍼스타 개발자를 채용할 수 있는 아주 좋은 방법입니다. 스폰서는 컨퍼런스에서 채용 부스를 만드실 기회를 갖게 될 것입니다.

  질문이 더 있습니다.

  알고 있습니다. 이메일을 주시면 Carsonified의 나타샤(Natasha)가 답장을 드릴 것입니다.

(끝)

PS1. 전반적인 내용이나 FAQ의 내용이 많은 한국의 프로그래머들에게는 도움이 되지 않을 내용입니다. 하지만, 많은 분들께 - 특히 학생 여러분들에게 - 외국에서 하는 개발자 컨퍼런스의 분위기를 알려드리고 싶어서 FAQ 까지 번역을 해보았습니다.

PS2. Stack Overflow는 어느새 대단한 사이트로 자리를 잡았습니다. 네이버 지식인이 대학교 1, 2학년 수준의 질문과 답변을 벗어나지 못하는 것에 반하여, Stack Overflow는 개발자들을 위한 커뮤니티로 완전히 자리매김한 모습니다. Stack Overflow에 관한 소개의 글을 번역할 예정입니다. 영어를 잘 하시는 분께는 문제의 해답을 구할 수 있는 또 다른 기회가 될 수 있을 것 같습니다.

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











Posted by 지그프리드 지그프리드
  직원들 개개인에 대한 평가는 인사권자의 권한이자 상사의 고유한 권한이다. 그리고 대부분의 회사들은 인사평가에 의하여 다음해 연봉을 결정 짓는다.

  고과를 매기는 기준으로 수없이 많은 기준들이 제시되어 왔다. 그중 가장 대표적인 것이 근속연수와 업적평가 일 것이다. 근속연수는 말 그대로 회사에서 업무에 종사한 기간에 따라 고과를 매기는 것이고, 업적평가는 그 직원이 회사의 이익에 기여한 정도를 평가한다. 둘 다 객곽적인 지표로 인정받으며 널리 사용된다.

  문제는 이 두가지 지표가 충돌하는 상황이다. 과거 제조업의 시대에는 같은 일에 한 달이라도 먼저 투입된 사람이 더 나은 결과를 가져왔다. 나사를 조여도 하나라도 더 조였고, 어려운 문제가 생겼을 때는 경험에서 나오는 노하우를 이용해 문제를 해결하는 능력도 더 좋았다. 이 시대에는 문제 될 것이 별로 없었다.

  하지만, 오늘날, 특히 IT분야에서는 시간에 대한 능력차이는 미미하다. 오히려 대학에서 막 학위를 받아 온 사람이 회사에서 같은 일을 반복한 사람보다 더 신기술에 익숙한 경우도 많다. 신입사원으로 입사했지만, 병역특례나 아르바이트, 혹은 독학으로 3 ~ 10년에 이르는 경험을 갖고 있는 경우도 흔해졌다. IT분야에서 점점 더 중요시되는 어학능력의 경우, 근속연수와 아무런 상관 관계가 없다.

  하지만, 한국 사회에서는, 특히 대기업에서는 여전히 연차가 중시되는 분위기다. 특히 승진을 앞둔 사람들을 배려해서 좋은 고과를 몰아주는 경우가 많은데, 이로 인해서 능력이 좋은 신입사원들이 불리한 평가를 받는 경우가 종종있다. 객관적으로 평가를 하겠다고 공언하지만, 입사년도 라는 객관적 자료를 "승진을 위한 배려"라는 이름으로 주관적으로 해석하는 경우가 생긴다. 이에 대해서는 찬반 의견이 많다. 승진을 앞둔 사람들은 당연히 찬성할 것이고, 조직의 화합이라는 측면에서 바라보는 사람도 찬성하는 사람들이 많다.

  문제가 생겼다. 연차를 중시한 인사에 불만을 품고 우수한 신입사원이 퇴사를 결정했다. "우수한" 신입사원임은 퇴사 후에 객관적으로 증명됬다. 예를 들면, 경쟁회사로 옮기거나, 선도회사에 입사하거나, 아주 수준 높은 대학에 진학하는 경우 등이 있겠다. 고과평가의 결과 우수 사원을 잃어버린 것이다. 고과평가가 잘못되었다 라고 결론을 내릴 수 있을 것이다.

  이 잘못된 고과평가는 누구의 잘못인가? 누가 책임을 져야 하는가? 우수 인재를 놓침에 따라 줄어든 회사의 이익은 누가 보전하는가? 또, 잘못된 인사고과에 관한 이야기를 듣고 입사를 포기하는 우수 인재들이 발생한다면, 이는 누구의 잘못인가? 회사의 분위기, 조직문화를 잘 못만들어낸 CEO의 책임인가? 아니면 신입사원에게 희생을 강요한 인사권자의 잘못인가? 우수한 신입사원을 설득하지 못한 직속 상사의 잘못인가/

  대개의 경우, 이런 경우 책임지는 사람은 아무도 없다. 우선, 퇴사한 직원이 우수한 신입사원이었다는 객관적 증거를 수집하려는 사람이 없다. 결국 자기 목을 죌 올가미가 되기 때문이다. 둘째로, 이 사원의 퇴사에 의하여 줄어들 미래의 수익은 어디까지나 가정된 손해에 불과하므로 정확한 측정이 불가능하다.

  그럼에도 불구하고, 남아있는 사람들은 이런 저런 이야기 - 누구는 나가서 무엇을 한다더라, 누구는 어디로 유학을 간다더라, 누구는 어디로 가서 몇배를 번다더라, 나도 어렸을 때 화학은 참 잘했는데, 약대나 갈걸 등등 - 를 하며 침체를 겪게 되고, 무엇보다 인사권자에 대한 불신은 그대로 남는다. 내가 아무리 우수해도 연차대로 간다는 회사의 방침은 그냥 연차나 쌓자 - 다시 말해, 시간이나 때우자 - 라는 무기력을 낳게 된다. 어떠한 켐페인과 표어도 잘못된 평가에 의한 무기력을 이기지는 못한다. 결국, 아무도 책임지지 않지만, 회사에는 고스란히 피해로 남는다. 평가는 그래서 중요하다. 정확한 평가 - 회사에 이익을 주는 사람에게 좋은 평가를 주는 것 - 를 하는 관리자도 그래서 중요하다.
Posted by 지그프리드 지그프리드

원문보기

왜 서킷 시티는 망했고, B&H는 성공했는가

Why Circuit City Failed, and Why B&H Thrives

망해버린 회사들 중 많은 수가 불경기 때문에 끝난 것은 아닙니다.  그 회사들은 한가지 이유로 망했습니다. 바로 고객들을 푸대접 한 것입니다.

Many companies that have gone bust didn't die because of the recession. They failed for one reason: They treated customers poorly

By: Joel Spolsky

Published May 2009

  지난 1월 서킷 시티(Circuit City : 미국 2위의 가전제품 판매 체인. 우리나라의 전자랜드나 하이마트와 비슷한 회사로 파산할 때 우리나라 삼성전자와 LG전자도 미수금이 상당히 있어서 유명해 졌습니다. 관련 기사를 참고하세요) 가 끝장났을 때, 저는 굿바이 세일에 가는 일로 시간낭비를 하진 않았습니다. 무엇보다, 물론 파산 전에도, 서킷 시티에는 쓸만한 물건이 없습니다. 일년 전에 서킷 시티의 모든 노트북을 살펴봤습니다. 제가 본 것은 모두 거대하고, 보기 흉하고, 반짝 거리는 거라고는 "Intel Inside"나 "Vista Adequate(적용)", "Y2K Ready" 같은 스티커 밖에 없는 모델들이었습니다. 게다가, 서킷 시티의 법정관리인이 굿바이 세일에서 많은 상품들의 가격을 올리도록 했다는 글을 소비자 보고서(the Consumer Reports)에서 읽었습니다.

  솔직히 말해서, 저는 서킷 시티에서는 아무것도 사지 않겠다고 생각하진 않았습니다. 주말이면 별 생각없이 가까운 서킷 시티 매장에 들러 밝은 플자즈마 TV로 된 벽면에 마치 나방처럼 이끌렸습니다. 하지만, 정말로 새 TV가 필요하게 되었을 때 저는 서킷 시티의 판매사원이 정말 용감할 정도로 아는 것이 없고 도움이 되지 않는 다는 것을 알고는 베스트 바이(Best buy)로 도망쳤습니다. 베스트 바이에서는 모든 것을 알고 있는 활기찬 20대 젊은이에게 도움을 받았습니다. 나중에 안 사실이지만, 서킷 시티는 2007년 3,400 명의 가장 경험 많은 판매사원들을 해고 하고 그 자리를 거의 최저 임금을 받는 미숙한 일반인들로 대체했다고 합니다.

  그래서, 저에게는 서킷 시티가 망한 것이 놀라운 소식이 아닙니다. 서킷 시티의 CEO는 E-mail에서 해고의 원인으로 "거시경제의 불경기" 를 지목했습니다. 이 견해는 연합 신문사(The Associated Press)에 의해서 "경제 공황의 확산" 때문에 파산하게 되었다고 반복하여 주장되었습니다.
 
  그런데 말입니다, 저는 경제 상황이 서킷 시티의 파산의 원인이라는 주장을 믿지 않습니다. 그들의 경쟁자를 한번 보기만 해도 현재의 경제상황 하에서도 전자 제품과 컴퓨터 관련 시장은 여전히 호황이라는 것을 알 수 있습니다. 애플 스토어에 가보시면 많은 사람들이 컴퓨터와 아이팟을 사기 위하여 줄을 서 있는 것을 보실 수 있습니다. 하지만 애플이 얼마나 뛰어난 회사인지 말하는 것은 이미 충분히 해 온 일이기 때문에, 여러분에게 또 다른 1류 전자제품 유통회사를 소개해 드리려 합니다. 여러분이 뉴욕에 살고 계시지 않거나, 프로 사진작가가 아니거나 열성적인 카메라 애호가가 아니라면 방문할 일이 없을 만큼 작은 회사입니다. 이 회사의 이름은 B&H 입니다.

  B&H는 1974년에 문을 열었습니다. 이곳은 놀라운 곳입니다. 여러분이 맨해튼에 계시다면, 이 매장을 방문해 보셔야 합니다. 34번가 9번 애브뉴에 (Ninth Avenue at 34th Street) 있습니다. 여러분이 아셔야 할 첫번째 특징은 이곳이 활기차다는 것입니다. B&H는 카메라 매장으로 시작해서 모든 종류의 전문가용 오디오, 비디오, 컴퓨터 장비 등 250,000 이상의 상품을 취급하는 회사로 성장했습니다.  이 회사는 상장되어 있지 않고, 언론 홍보도 잘 하지 않아서 얼마나 성공적인 회사인지 알기가 쉽지는 않습니다. 이 회사의 대변인은 "전반적인 경제 상황을 고려해도, 우리의 사업은 아주 잘되고 있습니다." 라고 말합니다. 매장에는 항상 손님들로 가득 차서 수백가지의 카메라 가방과 조합 가능한 모든 렌즈 부품들을 살펴보고 있습니다. 방에는 망원경과 사하라 사막의 모든 개미들을 바삭하게 구워버릴 수 있을 만큼 많은 렌즈들로 가득 차 있습니다. 제가 본 것 중에서 이곳 외에 지붕 아래에 이렇게 많은 장비들이 있는 장소는 도쿄의 아키하바라 전자상가가 유일합니다.

  얼마나 멋진 가게 입니까. 모든 동작(Operation)이 환상적인 윌리 웡카의 초콜릿 공장 같습니다. (crazy Willy Wonka factory : 동화이자 영화인 "찰리의 초콜릿 공장"에 나오는 난장이들이 일하는 초콜릿 공장) 만약 여러분이 전시되어 있지 않은 상품을 원하면, 판매사원은 컴퓨터 터미널을 통해서 지하에 있는 광대한 창고에 주문을 넣습니다. 잠시뒤면 마치 마법처럼, 엘레베이터와 컴베이어벨트 시스템에 의해서 그 상품이 카운터에 도착합니다. 어떤 상품이 마음에 들어서 구입하려 하면, 판매사원은 녹색 플라스틱 상자에 그 상품을 넣어서 다른 컨베이어 벨트에 실어 보냅니다. 그 상자는 여러분의 머리위를 지나서 픽업 카운터로 갑니다. 그곳에서는 다른 점원이 여러분이 산 상품을 가방에 담아줍니다. 그러는 동안에, 판매사원은 지불 카운터에 보여줄 티켓을 줍니다. 값을 치르고 나면 또 다른 티켓을 받는데, 이 것을 픽업 카운터에 주면 여러분이 구입한 상품을 받게 됩니다.

  처음에는 이 모든 것이 너무 지나치다고 생각했습니다. 하지만 이 것에 대하여 좀 더 생각해본 뒤에는, B&H가 일하는 방식에 관해 이해할 수 있게 되었습니다. 비싼 전자제품과 카메라와 렌즈와 노프북들을 가게 안에 떠다니는 동안, 이 시스템은 기본적으로 다섯명의 직원이 각각의 구매에 연관되게 되는 일련의 주문서와 영수증을 만들어내게 됩니다. 이것은 손님들과 직원들이 물건을 훔치는 것을 줄일 수 있습니다. (역자 주 : 이 시스템의 목적이 꼭 도둑 방지 때문인지는 모르겠습니다. 하지만 B&H의 가장 놀라운 점은 제가 다른 상점과 비교할 필요가 없을 만큼 가격이 싸다는 점입니다.

  아니요. 잠시만요. 가장 놀라운 점은 B&H의 판매사원들이 그들의 상품을 정말로 잘 알고 있다는 점입니다. 제가 최근에 휴대용 디지털 녹음기를 구입했을 때, 판매사원은 몇몇 제품이 2GB보다 큰 메모리 카드와 호환이 잘 되지 않는 다는 것을 알고 있었고, 몇 분 동안 인터넷 서핑을 해서는 제가 사려는 제품이 제가 함께 쓰려는 8GB 메모리 카드와 잘 동작한다는 것을 확인해 줬습니다.

  아니요. 잠시만요. 가장 놀라운 점은 제가 어떤 특정 상품을 사려고 B&H에 갈 때 마다 더 싼 제품에 대해서 말해 준다는 점입니다. 예들들어, 한번은 제가 만들고 있는 인터뷰 영상물 촬영에 쓸 휴대용 비디오 모니터를 사려고 B&H에 들렸습니다. 저는 600 달러를 예상하고 있었는데 판매사원이 "값이 싼 휴대용 DVD 플레이어는 어떠세요? 이 것들도 비디오 입력 단자가 있고, 잘 동작합니다. 이건 100달러도 안해요" 라고 알려줬습니다. 이건 우연이 아니었습니다. "우리 매장의 대원칙은 고객 여러분이 사야 한다는 거부감 없이 오셔서 만져보시고, 느껴보시고, 물어보시고, 여러분의 필요에 관해서 토론해 보실 수 있도록 하는 것입니다."  B&H의 웹사이트에 있는 말입니다.

  하지만, 잠시만요. 컨베이어 벨트, 가격, 똑똑한 판매사원, 더 싼 제품을 추천해 주는 것이 거의 법에 가깝다는 점  - 이런 특징들이 진짜로 B&H의 가장 놀라운 점은 아닙니다. 정말로, B&H의 가장 놀라운 점은 B&H의 오너(Owner)가 보수적인 유대인 - 정확히는 하시딤(Hasidim) - 이라는 점입니다. 매장은 유대교 안식일( Jewish Sabbath)을 지키기 위하여 매주 금요일 오후와 유대교 절기(holiday) 에 닫습니다. 게다가, 매출의 70%를 담당하는 B&H의 웹사이트도 같이 닫습니다. http://www.bhphotovideo.com은 제가 아는 한, 매주말마다 25시간을 닫는 유일한 메이져 온라인 쇼핑몰입니다.

  경쟁자인 서킷 시티 같은 회사가 망하는 동안에도, B&H에는 충성도 높은 고객들로 붐비고 있습니다. 그리고 이 점은 저를 매우 행복하게 합니다. 사업가로써, 사기꾼들의 굳바이 세일에서 가격을 올리면서, 시궁창에 처박히는 동안 정직한 장사꾼이 그들의 사업을 확장하는 것보다 기쁜 일은 없습니다. 고객들을 잘 대하는 것은 정말로 좋은 결과로 돌아온다는 것을 알게 하는 좋은 사례 입니다.

(끝)

2009/04/04 - [조엘 온 소프트웨어(번역)] - 조엘 온 스프트웨어 - 저자에 관하여 (Joel on Soft ware - About the Author : Joel Spolsky)
Posted by 지그프리드 지그프리드
  새로운 프로젝트가 시작되면서 협력업체의 도움을 받기로 했다. 인력이 부족하다는 판단에서 상부에서 결정한 것이지만, 맨먼스 미신의 신봉자로써, 이번에도 결과는 별로 좋지 않을 것으로 생각된다. 내가 직접 하는 것보다 더 일이 빨리 될 것 같지도 않고, 오히려 커뮤니케이션에 문제만 있을 것 같은데... 위에서 시키는 일이라 어쩔 수는 없다. 

  사실, 협력업체분이 제대로 준비되지 않은 상태에서 일을 시작하는 것과, 평소에 하던 일을 하던 사람이 투입되서 일을 하는 것은 속도와 효율에 차이가 클 수 밖에 없다. 작업결과에 대한 머지는 결국 내일이 될 것이고... 나중에 정말 급한 문제가 생기면 또 내가 수정하게 될 것이고... 인력을 이런식으로 투입한다고 더 효율이 올라가지 않는 다는건 이미 수없이 많은 프로젝트에서 증명된 명제 아닌가. 이러니 IT가 아니고 제조업이라고 자꾸 투덜대는 일이 생긱는거다.

  위에서 야근 시키면 열라 짜증내던 난데, 이젠 야근을 강요하고 강제하는 입장이 되버리는 거다. 참 불합리한건데, 장비 하나 제대로 갖추지 못해서 일 시키는데만 일주일 가까이 딜레이가 된거다. 시뮬레이터도 없어서, 다운 받아가면서 확인하면 작업이 얼마나 비효율 적인지 알면서도 "몇일 까지 하라고 팍팍 쫘요" 라고 위에서 날 쪼는데, 참. 이건 아닌데...  그러잖아도 "하청은 IT의 막장"이라는 말이 나오는데, 미안하게도 거기에 내가 일조하게 된 것 같아 기분이 좋지 않다.

  언젠가는, 나도 과장이되고 (잘하면) 부장이 되서 개발에서 손 떼고 인력관리에 집중하라는 압박을 받을 텐데, 벌써부터 걱정이된다. "우리팀은 애자일 방식으로 8시간 근무 철저히 준수하고, 매일 스크럼 하고 코딩은 반드시 패어로 합니다" 라고 말하고 팀을 운영한다면, 위에서는 "왜 니네팀은 다른 팀 다 남아있는데 집에 가냐?" 는 질문을 받을테고 밑에 사람들한테는 "일하기도 바빠 죽겠는데 무슨 놈의 스크럼이냐"  혹은 "둘이 나눠 짜도 다 못하는데 언제 둘이 같이 짜고 있냐" 같은 말을 들을 것 같아서 그렇다. 그럼 난 뭐라고 둘러대야 하지?

  아니면, 그냥 내 선배들이 그랬던 것 처럼 나도 짜증나는 또 한명의 과장이 되는 것이 필연인가... (바둑에서 말하는 필연 말이다. 이 행마를 진행할 수 밖에 없는 필연적 국면같은...)

  아 이런일 하기 정말 싫은데... 정말 싫은데... 그냥 내가 야근하고 말지. 이건 정말 아니다.
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


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

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

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

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

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

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


원문보기

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 지그프리드 지그프리드
  원문은 아주 오래된 게시판에서 읽었던 것으로 기억합니다. 하이텔 만큼 오래전인지, 학교 게시판에서였는지는 모르겠지만, 어딘가 유명한 유머 게시판에 원문이 올라왔었고요. 그래서 다시 적습니다만, 원저자는 미상이라고 밝히는 것이 맞을 듯 합니다.


‘공대생 테스트’라는 게시물도 있습니다.

‘당신은 뼛속까지 공대생인가?’에 대한 이 테스트는 몇 개의 영어단어만으로 공대생과 인문대생을 쉽게 구별해줍니다.

당신은 뼛속까지 공대생이 아닌가요??? 아니라구요???

그럼 다음 단어의 뜻은 무엇일까요?

probability
equation
evaluate
frequency
function

아래로 바로 넘기지 말고 잠시 생각을…




















probability - 확률
equation - 방정식 등식
evaluate - 계산하다
frequency - 주파수
function - 함수
라고 생각하신 분 그대는 뼛속까지 공대생!

실제로 사전을 찾아보면 주요 의미가..
probability : 실제로 있음직함, 개연성, 일어남직함.
equation : 평균화, 동일화, 동등화, 균일화, 평형.
evaluate : 평가하다, 견적하다.
frequency : 자주 일어나기, 빈발, 빈번.
function : 기능, 작용, 효용, 직무, 구실.

억울하다구요? 그럼 "정의" 가 영어로 뭘까요


definition 이라고 생각한 당신은 역시나 공대생! =_=
justice 라고 생각하신 당신은 인문대생.
(정말 우리방에서 모두 Definition을 생각했다...=_=;;;;;)

그럼 다음 단어의 뜻은 무엇일까요?
critical function..

임계 함수?

라고 생각하신분 그대는 뼛속까지 공돌이 =ㅅ=...
사회과학쪽 전공 서적에서는.........

비판적인 기능...



================================================================================

여기까지는 퍼온거고, 이하는 내 오리지널 스토리. 물론 모두 다 실화다.

1. 교회 전도사님에게 길을 알려주고 있었다. 미금역 지나셔서요 고기리 방향으로 계속 직진하시다가 사거리에서 좌회전을 하세요. 사거리 두 개를 더 지나시고 나면 세번째 사거리에서...  

  4 사분면에 있습니다.


2. 역시 교회에서.

오빠 요즘 뭐하세요?

응, 나 요즘 C++ 바이블 공부해.

어머, 오빠 성경공부 시작하셨어요?

성경공부... 우리가 보는 저 무식하게 두꺼운 책은 과연 성경이었던가...



3. 학원 강사로 아르바이트를 하던 시절에 이야기다.

김선생님, 혹시 호치키스 알 있으세요?

아뇨. 아, 알이 다 떨어졌나요?  음. 저한테 백업이 있습니다.

아 근데 이전 좀 작겠는데요. 찍을게 많은데...

음 그럼 알만 이쪽으로 옮겨서 쓸수는 없을까요? 아.. 호환이 안되는구나.

김선생님.... 컴공과라고 하셨던가요 ㅋㅋ



4. 당구장에서

흰공, 점공, 빨간공 두개가 모두 일자로 섰다. 대부분의 친구들은 이걸 "일랭" 이라고 부른다. 하지만...

공이 선형이구나... 

그러게. 리니어 시스템(Linear system)이네. 방정식 풀어봐라

이러고 논다.


5. 역시 당구장에서. 나 고등학교 때.

처음 당구를 배울 때, 날 가르쳤던 친구는 "우라"를 이렇게 설명했다.

봐, 공은 여기있고 수구는 여기서 치잖아. 그럼 이 벡터랑 이 벡터랑 만나면 공은 이 벡터로 간다는거지.

서울시 물리경시대회 장려상에 빛나던 친구였다.


6. 개강 첫 수업 때.

교수님께서 리포트 제출에 관해서 말씀하고 계셨다.

각 과제 끝날 때 마다 레포트는 주어진 형식대로 빠진 내용 없도록 작성해서 시간내로 제출하세요. FTP서버 공지할테니 워드로 작성해서 제출하세요.

저 교수님, 워드가 없는데, 한글로 작성해도 됩니까?

예, 한글도 괜찮습니다.

저 교수님, 전 둘 다 없는데, 워드패드로 작성해도 됩니까?

아 없으면 학교에서 써도 되잖아요. 그래요. 워드패드로라도 내세요.

저 교수님, 훈민정음도 됩니까?

-_-;; 알았어요. 그걸로 내세요.

저 교수님, 아리랑도 됩니까?

순간 정적... 복학생들의 킥킥거림과 현역들의 "아리랑이 뭐야?" 소리

자네, 행정병으로 갔다왔나? (공대생들, 특히 컴공과 출신은 유난히 행정, 정산병이 많다. 절반은 행정이었던 것 같다.)

예  그렇습니다.

아리랑은 안되니 그냥 학교 컴퓨터로 워드로 작성해서 내세요.


아리랑 : 군대에서(만) 쓴다는 워드프로세서 프로그램


뭐 암튼 공대생들은 저러고 놀았다. 

그때가 좋았는데 :-)







Posted by 지그프리드 지그프리드
프리젠테이션 젠
카테고리 자기계발
지은이 가르 레이놀즈 (에이콘출판, 2008년)
상세보기


  다음 동영상은 내가 이 책과 저자에 관해서 처음 알게 되었던 유튜브의 동영상이다. 구글에서 있었던 이 책의 저자 가르 레이놀즈의 강연이다. 크게 어렵지 않은 영어와, 언어를 뛰어넘는 프레젠테이션 스킬로 이해하기가 과히 어렵지 않다. 그리고, 난 이책의 번역판을 구입했다.




  지난 촛불정국 이후, 대한민국의 화두는 "소통" 이었다. 미국산 소고기와 삽을 든 대통령의 생각과 촛불을 든 국민들의 생각이 극명하게 어긋나는 것이 대한민국의 상황이었다. 서로 생각하는 것이 너무나 틀렸고, 상대를 이해하려하기 보다는 "법대로" 처벌하거나 극회에 드러눕거나 폭력적인 방법으로 때로는 유모차를 미는 모습으로 서로 자신의 주장을 하는 것이 대한민국의 모습이었다. 옳고 그름을 떠나서 서로가 공감하지 못했다. 대통령은 라디오 담화나 TV 토론 같은 방식으로 자신이 하고자하는 이야기만 했고, 국민들은 그냥 웃어넘겼다. 그런 사건들이 잊혀져 할 때쯤 내 손에는 이 책이 들려 있었다.

  저자가 직접 한 말은 아니지만, 이 책에 소개된 다니엘 핑크의 하이터치, 하이컨셉 라는 주제가 생각났다. 대통령이 하이터치를 이루는 여섯가지 감성 - 디자인, 스토리, 조화, 공감, 놀이, 의미 - 를 이해하고 국민들에게 설명했다면 사람들이 이렇게 화를 내지는 않았을 것이다. "미국산 소고기가 싸잖아.  좋아하는 소고기 많이 먹어라" 가 아니라 "타이거 우즈, 아놀즈 슈워츠네거, 빌 클린턴, 이들이 먹는 소고기와 동일한 소고기를 여러분에게 공급할 것입니다." 라는 방식으로 홍보를 했다면 극렬한 저항은 피할 수 있었을지도 모른다.

  이 책은 프레젠테이션을 이갸기 하기 전에 소통에 관해서 먼저 이야기 한다. 지금까지의 프레젠테이션은 주객이 전도되어 있었다. 무언가 발표하는 "주제"가 중심이 되어야 하는데, 많은 사람들은 파워포인트 슬라이드를 보여주는데 더 치중이 되어있다. 발표자는 파워포인트 슬라이드를 읽어주거나 부연설명을 하는 존재가 되어버렸다. 기술에 사람이 얽매이는 현상이 여기 저기에서 벌어지고 있다. 하지만 여전히 중요한 것은 주제이고, 발표자와 청중 사이의 소통이다.

  이 책 이후 "프레젠테이션 젠 스타일"이 관용어가 될 정도로, 이 책이 끼친 영향력은 지대하다. 파워포인트의 효과보다는 이미지에 집종하고, 정보를 담은 텍스트 보다는 인상을 남기는 텍스트를 사용하며 프레젠터의 쑈가 중심이 되는 프레젠테이션이 이 책이 이야기하는 프레젠테이션이다. 스티브 잡스 스타일이라고 하면 딱 맞다. 이 책에서도 몇차례 그를 잘된 예로 들고 있다. 대학 수업에서, 회사에서, 입사시험에서 어떠한 형태로든 남들 앞에서 발표를 할 일이 있다면 이 책을 꼭 읽어보기를 권한다. 그리고 흉내내 보라. 사람들이 내 발표를 들으면서 즐거워하는 그런 발표자가 될 수 있을 것이다.

  대학 졸업 직전에 학회에서 했던 발표가 생각났다. 연구 내용이 워낙 부실했기 때문에 프레젠테이션에도 자신은 없었다. 다만 워낙 작은 학회의 작은 세션에서 한 발표라, 내가 모르는 사람은 두 명 정도 였다. 하하. 지금 생각해도 좀 우습긴 했다. 이런 학회에서 하는 프레젠테이션은 대부분 형식이 딱 정해져있다. 프레젠테이션이면서 동시에 논문 요약이 되는 내용을 발표를 해야해서 엄청나게 많은 텍스트가 들어가며, 내용은 거의 대부분, 재미가 없다. 약간의 이미지가 사용되지만, 이러한 이미지 역시 "인상'을 전달하기 보다는 "정보"를 전달하기에 급급한 티가 난다.  과연, 이런 학회 발표에서도 프레젠테이션 젠 스타일을 써먹을 수 있을까? 이것이 이 책을 읽고난 내 마지막 질문이다.




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



원문보기

Joel on Software


Fog Creek Compensation System


이전글 보기 : 왜 나는 직원들이 임금협상을 하지 못하게 하는가? - Fog Creek의 보상 체계 1

  - 1부에서 계속
 
  같은 레벨에 있는 모두가 같은 임금을 받기 때문에  - 속임수는 없습니다 -  우리는 종종 어려움을 겪습니다. 우리가 더 높은 보수를 위해 임금협상을 요구하는 직원을 추적할 때, 우리의 임금체계가 자체적으로 갖고 있는 문제점이 드러납니다. 종종 이런 일은 능력있는 직원이 우리의 관점에서는 시장임금보다 높은 급여를 받고 있는데도 불구하고 발생합니다. 또 때때로는  고용될 가능성이 있는 사람이 합당한 정도는 연봉을 높이거나 낮출 수 있다고 생각하기 때문입니다. 왜냐하면 대부분의 다른 기업들은 불명확한 임금체계를 갖고 있어서 협상만 잘 한다면 더 나은 연봉을 받을 여지가 있기 때문입니다. 우리는 보통 이런 상황에서 그가 통상적으로 받게될 많은 액수의 1년차 보너스를 보장한다고 말합니다. 여기서 중요한점은, Fog Creek은 대단히 수익성이 좋고, 또한 우리는 너그러운 이익분배제도(Profit-sharing plan)를 시행하고 있다는 점입니다. 따라서 "보장된 1년차 보너스"란 거의 항상 그 직원이 받게 될 이익분배 보너스보다는 적습니다.

  우리의 임금 체계는 노동시장이 경직됬던(tight : 역자주 : 일자리보다 일 할 사람이 적은 상태) 지난 8년간 동안의 시험을 거쳤습니다. 이유를 알면 쉽습니다. 여러분이 100명의 야크 몰이꾼(yak driver) 을 시간당 10달러에 고용한다고 가정해 봅시다. 하지만, 그렇게 되면 티벳 경제는 과열되게 되고 여러분은 야크 몰이꾼을 찾는데 어려움을 겪게 됩니다. 시장가격은 시간당 15달러까지 올라갑니다. 우유부단한 행동은, 15달러에 신입 직원(Rookies)들을 고용하고, 기존 일꾼들(Seniors)이 신입들이 그들보다 더 받고 고용되었다는 사실을 모를거라는 기대를 하는 것입니다.

  만약 여러분이 잘난척 하면서 HR 은어를 사용하기를 좋아하는 분류의 사람이라면, 이것을 전문용어로 임금역전(Salary inversion)이라고 부릅니다. 임금역전은 조직안에서 분쟁을 야기할 수 있습니다. 또한 이것은 관리자와 인사 그리고 직원들사이의 관계를 완전하게 감싸버립니다(Wrap up) . 이것은 좀 우습게 보이기도 하고, 사이비 같기도 합니다만, 저는 정말로 어떤 대기업의 경영자가 그들의 핵심 직원에게 퇴사후 같은 일에 다시 지원하라고 말했다는 이야기를 들었습니다. 왜냐하면 관료주의가 시장에서 경쟁력 있는 수준까지 그들의 임금을 올려주는 것을 거의 불가능하도록 만들었기 때문입니다. Fog Creek에서는 옳은 일을 하기로 결정했습니다. 우리는 노동시장이 경직되면 같은 레벨의 모든 직원들의 임금을 올려줍니다. 이러한 임금인상은 어렵고 비용이 많이 들지만, 대안은 더 않좋습니다. 여러분은 어떤지 모르겠지만, 전 몽둥이가 무섭습니다.

  저는 우리의  임금 체계가 회사의 이익이 줄어ㄷ느느 것을 막을 수 있다고 보장은 할 수 없습니다. 하지만 저는 직원들이, 임금체계가 투명하고 공정하다면, 그리고 승진을 위해 무엇이 필요한지가 명확하다면, 약간 월급이 적어지는 것은 받아들일 의사가 있다고 매우 확신합니다.

  동시에, 여러분이 임금에 대한 많은 불평을 듣는다면 여러분은 임금체계만 들여다 봐서는 안됩니다. 제가 지난 경험에서 얻은 한가지 교훈은, 행복하고 의욕적인 프로그래머들은 그들이 좋아하는 일을 하고 그들이 어른으로써 대접받고 있다고 느낀다면, 심각하게 불공평하게 임금을 받고 있지 않는 한은 돈에대하여 불평하지 않습니다. 만약 여러분이 임금에 대하여 많은 불평을 듣고 있다면, 제 생각에는 그것은 더 큰 질병 - 직원들이 그들의 일에서 개인적인 만족을 느끼고 있지 못하거나 다른 이유로인해 비참한 상태에 있는  - 의 징후일 것입니다.

  끔찍한 상사나 감옥같은 사무실(Workplace)를 대신하기 위해서는 많은 임금이 필요합니다. 그리고 임금을 조정하기 보다는, 직원들을 행복하게 만들기 위해 비금전적인 방법을 선택하십시요. 행복한 직원들은 더 나은 제품을 만들고, 고객들에게 더 나은 서비스를 제공하며 당신의 회사를 성공하게 만들고 많은 수익을 내도록 할 것입니다. 또한 회사의 성공은 여러분이 직원들에게 더 나은 보수를 지불할 수 있도록 할 것입니다. 이것이 선순환의 고리입니다. 이것은 Fog Creek에 적용되었습니다. 여러분의 회사에서도 잘 동작하는지 알려주십시요.

[사진 출처는 http://www.inc.com/magazine/20090401/how-hard-could-it-be-employees-negotiate-pay-raises_pagen_2.html]
 


(끝)

저자에 관하여

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



원문보기

Joel on Software


Fog Creek Compensation System



Why I Never Let Employees Negotiate a Raise


At Fog Creek Software, every worker at the same level is paid the same salary. And when one gets a raise, they all do



By: Joel Spolsky



  April. 01, 2009


  Fog Creek의 보상 체계


 
왜 나는 직원들이 임금협상을 하지 못하게 하는가?


  Fog Creek Software에서는 같은 수준의 모든 직원들은 동일한 임금을 받습니다. 누군가 월급이 오르면 모든 직원이 같이 인상됩니다.
 


  어느날 당신이 출근했을 때, 휴게실(kitchen)에서 여러분의 직원들의 월급 리스트가 냉장고에 붙어있는 것을 보게된다면 어떤 일이 벌어질까요? 흥분하게 될까요? 여러분의 직원중 절반은 눈물을 흘리고, 나머지 절반은 몽둥이를 들고 (pitchforks : 역자 주 : 원래는 삼지창 처럼 생긴 농기구이나, 문맥상 우리말로는 "몽둥이"가 낫습니다)를 들고 당신 사무실 문 밖에서 기다리고 있는 것을 예상하시나요?

  임금 정보는 특별히 민감하게 받아들여지기 때문에, 고용주들은 이것을 아주 꽁꽁 숨겨둡니다. 어떤 회사는 직원들이 서로 임금을 비교하는 것을 해고 가능한 위반사항으로 정하기까지 합니다. 혹은 표준 고용계약서에 그들의 임금을 공개하는 것을 금지하는 조항을 넣기도 합니다. (미국에서는, 이런 종류의 조항들은 효력이 없습니다. 그런데도 많은 상사들은 그들의 직원들이 이 사실을 모르기를 바라지요). 임금을 비밀로 할때 생기는 문제는, 이것이 보통은 사람들에게 공정하게 임금을 지급하는 것을 피하기 위한 방법으로 사용되기 때문입니다. 그리고 이것은 직원들과 -- 혹은 회사에 좋지 않습니다.

  저와 제 파트너가 Fog Creek Software를 시작했을 때, 우리는 객관적이고 투명한 임금 체계(Pay scale)을 만들고 싶었습니다. 저는 다른 회사의 임금체계들을 조사한 결과, 많은 고용주들이 공식으로 임금을 계산하는 방식(formulaic salary scale)과 회사의 직급체계에 맞춰 일정한 범위를 설정하는 느슨한 방식 사이에서 타협점을 찾으려고 한다는 것을 알게되었습니다. 하지만 저는 이것이 불공평하게 느껴졌습니다. 저는 Fog Creek이 가능한 객관적인 임금체계를 갖기를 원했습니다. 관리자가 임금을 결정할 때 절대로 다른 여지가 있어서는 안됩니다. 그리고 각 레벨애는 동일한 임금만이 있어야 합니다.

  얼마간의 조사 끝에, 저는 Construx라는 시애틀 지역의 소프트웨어 컨설팅 회사가 그들의 웹사이트에 괜찮은 직무체계(professional ladder system)를 공개한 것을 찾았습니다. (여기에서 확인할 수 있습니다) 이것은 저에게 Microsoft의 이전 직무체계를 떠올리게 하였습니다. 제가 거기 있었을 때 꽤 잘 동작했던 시스템 입니다. 우리는 이것을 우리 임금체계의 기본 뼈대로 삼았습니다. 물론, 세부사항은 보강하였습니다. 저는 첫번째 드래프트를 제 블로그에 올리고는 두번째 드래프트를 쓰는데 도움이 된 엄청난 양의 피드백을 받았습니다. 기본 체계는 처음 그대로였습니다.

  Fog Creek의 체계에서는 모든 직원은 레벨을 부여받습니다. 현재, 이 레벨은 8(여름 인턴사원)부터 16(저 : CEO)까지 입니다.여러분의 레벨은 세가지 요소 : 경력, 책임영역, 스킬 셋 - 에 의하여 공식을 이용하여 계산됩니다. 우리가 여러분의 숫자를 결정하고 나면, 여러분은 같은 레벨의 다른 모든 직원들과 같게 됩니다.

  경력 부분은 매우 쉽습니다. 이것은 여러분이 일하고 있는 분야에서 풀 타임으로 일한 연수에의해 결정됩니다. 학교에서 한 일이나, 단순 업무에 의한 경력은 1년 이상은 인정하지 않습니다. 예를 들어, 만약 당신이 리셉션에서 6년동안 일했다면,  당신은 6년 경력을 인정받을 수 없습니다. 저는 단지 1년만 인정할 것입니다.

  영역도 매우 쉽습니다. 당신은 주된 일로써 다른 사람의 일을 돕습니까? 책임지고 있는 당신만의 분야가 있습니까? 아니면 제품 전체를 운영합니까? 우리는 대부분의 직무에 대한 영역점수를 꽤 객관적으로 매길 수 있습니다.
 
  기술을 계량과 하는 것은 약간 더 어렵습니다. 하지만 우리는 초급 프로그래머 (newbie programmer : 소프트웨어 공학의 기본을 배우고있고, 직접 감독(Close supervision)하에 일하며,  제품 코드를 작성하기를 기대하지는 않는다) 부터 숙련된 프로그래머(expert programmer : 작고 큰 프로젝트에서 참여하여 지속적인 성공을 거두었고, 그 프로젝트가 성공하는데 핵심적인 역할을 한다) 까지 공정하고 객관적으로 정의할 수 있게 되었습니다.

  우리의 용어를 정의하고 나서, 우리는 직원들의 경력과 기술과 영역에 따라 레벨을 부여할 수 있는 작은 차트를 만들었습니다.
(표는 여기에 올려져 있습니다.)  그리고 우리는 각각의 레벨에 따른 임금을 정의한  차트를 만들었습니다. 이것이 우리가 직원 한명의 임금을 계산하는 방법입니다.

  일년에 한번, 제 경영팀은 모여 앉아서 모든 직원들의 일을 검토하고 개개인의 레벨을 다시 계산합니다. 그리고 우리는 는 Salary.com 이나 Glassdoor.com같은 온라인 툴을 이용하여 노동시장에서 경쟁력 있는 임금수준을 찾습니다. 그리고는 지난 해 채용을 통해 알게된 구인시장(Job maket)에 대한 우리의 정보를 고려할 때, 각각의 레벨에 대한 임금이 직원들이 계속해서 일하고 싶어할 정도가 되도록 맞춥니다.

 - 2부에 계속 -


저자에 관하여

Posted by 지그프리드 지그프리드
  오늘은 프로젝트 런웨이 코리아의 마지막 방송이 있는 날이다. 온스타일에서는 하루 종일 프런코를 해주고 있다. 요즘들어 아주 재미있게 보고 있는 티비쇼 이다. TV에서 하루 종일 하는 데로 옆에 틀어 놓고 주구 장창 보고 있다. 그러던 중 드는 생각들


1. 한겨례 신문 기사처럼, 정말로 "와이트 보드에 선을 긋는다" 는 표현이 나온다. 처음에는 아무렇지도 않게 들었었는데, 오늘 기사를 읽고 다시 들어보니, 확실히 "한국적"이진 않은 모습인데  저런 미국식 발음이 프로그램 속에서 어색하지 않았다. 해외파 디자이너들이 많은데 시청자들이 어색하게 받아들이지 않는다는 평이 맞는 것 같다.

2. 디자이너 최혜정. 분명 손을 댄 얼굴인데, 굉장히 매력적이다. 살짝 올라간 코 끝이 정말 이쁘다. 튜더스 (Tudors)의 "앤 블린"역의 배우와 같은 코인데, 정말 이쁘다.

3. 근데.. 내 취향이 이쪽이 아닌 것 같다. 분명 최혜정이 제일 이쁜데, 내가 끌리는건 이우경 이더라는 말씀. 외모 뿐만 아니라 말투와 행동, 동작과 액세서리 하나 하나가 귀여워 죽겠다 ㅋㅋ 아 놔.. 이런게 내 진짜 취향이었나.. 마지막 회에 나오는 하얀색 드레스도 너무 잘어울린다.

암튼, 잠시 뒤에 시작될 Final이 기대된다. 

PS. 쇼 자체도 충분히 재미있다. 정말 이쁜 사람들이 나와서 계속 보는건 아니다.

PS2. Programmer Challenge 도 이런 쑈로 만들 수 있지 않을까? ㅋ 아마 시청자들이 대부분의 시청자들이 용어부터 알아듣기가 힘들어서 무리일까  :-) "이분은 코딩 스킬은 뛰어난데, 객체지향을 무시하셨군요. 이건 구시대적이에요"  뭐 이런 식으로 평가한다면 99%의 시청자는 공감하지 못할테니까. 만약, 임베디드 제품에 적용될 프로그램을 만드는 걸로 한정하면, "어 이분 프로그램은 UI는 정말 화려한데, 동영상 플레이는 안되네요" 뭐 이런식으로 좀 눈에 보이는 쇼를 만들어낼 수 있지 않을까? 음.. 역시나 재미 없을라나..
Posted by 지그프리드 지그프리드



원문보기

Joel on Software



Animoto





By: Joel Spolsky






  Jan. 02, 2009






  Tom이 Fog Creek의 사진들을 가지고 슬라이드 쇼를 만드는 일에 (Jazz up the slidehsow) Animoto를 쓰라고 추천해 줬습니다. 여기 예제가 있습니다.


  Animoto는 아주 간단합니다. 여러분은 여러장의 사진을 선택하고, 배경음악을 선택하면 이 툴은 동영상 프레젠테이션을 만들어 줍니다. 제가 가장 마음에 든 부분은 사진을 넣는 것이 얼마나 쉬운지, 여러분은 웹에서 가장 인기있는 다섯개의 사진 공유 사이트 중 하나를 선택하기만 하면 됩니다. 그러면 그 사이트에 등록한 여러분의 앨범의 리스트를 보여줍니다. 원클릭으로 사진을 가져올 수가 있습니다.



  이 툴은 30초까지는 (약 15장의 사진 까지는 충분합니다) 무료입니다. 더 긴 영상을 원한다면, 저화질 버전에는 3달러, 고화질 버전에는 5달러 입니다. 좀더 많은 수의 동영상을 만들고 싶어한다면 여러종류의 패키지 상품도 있습니다. 저는 이 모든 것이 너무나 간단하다는 점이 가장 인상적이었습니다. 이 툴은 동영상으로 렌더링하는데 정말 오랜시간이 걸려서 - 거의 여러분의 하루를 다 써야할 정도로 - 아주 많은 수정을 해 보기에는 가만히 기다리는데 지쳐 버릴 것입니다.


(끝)


저자에 관하여

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

원문보기
By: Joel Spolsky

  Published March 2009


이전글 보기 : 생존하기는 얼마나 어려운가 : 벤처 회사의 전략 1 (How Hard Could It Be?: Start-up Static)

  그렇다면, 누가 "섬세한 사기 관리" (Careful morale management) 가능할까요? 그리고 이것은 어떤 효과를 발생시킬까요? 제 생각에는, 경영자는 처음으로 단파 라디오를 가지고 노는 아이와 같다고 생각합니다. 아이는 집에서 라디오를 켭니다. 그러면 무슨 소리가 날까요?

아무 소리도 안납니다. 변화가 없습니다.

이건 좀 실망스럽습니다. 그래서, 아이는 다른 주파수를 맞춰봅니다.

아무 소리도 안납니다. 변화가 없습니다.

아이는 또다시 실망합니다. 아이의 어머니가 다가와서 라디오에 안테나를 연결해 줍니다. 그러면 갑자기, 아이는 방송국의 유령을 잡아냅니다! 그 소리는 아주 멀리서 들려오는 것 같고, 또 무언가 말하는 것 같기도 합니다. 어느나라 말일까요? 상관없습니다. 방송국입니다! 안테나 라구요! 누가 알겠습니까? 아이는 컴퓨터로 뛰어가서 블로그에 안테나가 얼마나 멋진 것인지 적을 것입니다.

  이것은 여러분이 새로운 사업을 시작할 때와 비슷합니다. 아이디어가 떠오를 때나 처음으로 매출을 올린뒤 매상이 늘고 있을 때, 여러분은 처음으로 흥분으로 충만하게 됩니다. (이 시기에는 여러분은 열라 재수없습니다. 추수감사절 가족만찬에서 와인을 잔뜩 마시고는 장모님 앞에서 그녀가 당신의 사업 아이디어를 얼마나 무례하게 무시했는지, 그리고 당신이 수백만 달러를 벌었을 때 장모님에게는 일원 한장 안줄 것인지 하나하나 꼽아가며 말하겠지요.

  사업이 진행되어 갈수록, 수신률을 높이거나 여러분이 좋아하는 다른 방송국을 찾기 위하여 라디오의 여러개의 다이얼들을 조작하기 시작하게 될 것입니다. 그리고 운이 좋게도, 사업의 영역에서, 우리 벤처 설립자들은 가지고 놀 수많은 다이얼들을 가지고 있습니다. 가격, 입지, 직원들, 마켓팅, 광고, 보상정책, 무역 전시회, 상품들, 검색엔진 최적화 그리고 여러분의 예산안에 있는 모든 항목들 말입니다.
 
  여러분이 새로운 레스토랑을 열기로 결심했다고 합시다. 여러분은 가게를 임대하고, 그 곳을 테이블로 채우고, 주방을 식재료로 채웁니다. 그리고 여러명의 웨이터들을 고용하고 손님을 자리로 안내하고 예약 전화를 받을 매니저(Host)를 고용하겠지요. 그리고 나서, 개업식 밤입니다. (여기서 카메라 플래쉬 터지는 소리들을 상상해 보세요)

  바로 이순간, 섬세한 사기 관리에 관해서 창립자는 속으로 생각합니다. "아마도, 인력관리 쪽에서 경력을 쌓는 것도 나쁘지 않을거야"  그러는 동안에, 마음을 굳힌 창립자는 다이얼들을 가지고 놀기 시작합니다. 메뉴를 재고하고, 새로운 프로모션을 시도하고, 가격을 조정합니다. 그리고 그가 알게 될 것은 라디오를 켜는 것과 같습니다. 사업의 어떤 영역은 단 하나의 아주 작은 것에 의해서 망할 수 있습니다. 그리고 아주 작은 조정만으로도 "뿅" 하고는 다시 살아나기도 합니다.

  예를들어서, 우리회사 제품 중 하나인 포그 크릭 코파일럿(Fog Creek Copilot)의 판매추이 그래프(Sales Chart)를 보시죠. 처음에는 우리는 하루에 $10로 요금을 부과했습니다.  그러나 고객들은 처음에 카드를 긁거나, 카드 번호 16자리를 입력하거나. 전신환을 이용하여 결제하는 방법으로 계속해서 이 서비스를 받고 싶어했습니다. 그래프의 초록색 선이 나타내듯이, 우리의 매출은 꾸준했지만 눈에 띄는 정도는 아니었습니다. 그때, 2005년 겨울에, 개발자중 한명이 매달 자동으로 과금되는 서비스에 고객들이 등록할 수 있도록 시스템을 만들었습니다. 우리는 이 월단위 종량제가 고객들에게 작은 편이성을 제공하는 것에 불과하다고 생각했습니다. 뚜껑을 열고 보자,우리 대부분이 이 종량제가 가진 임팩트를 과소평가 했다는 것이 들러났습니다. 붉은 선에서 보듯이, 매출이 급신장 했습니다.

  우리가 종량제 방식의 제품으로 코파일럿을 유지했다면 어쩌면 제품을 포기했을 수도 있습니다. 우리는 다른 종류의 소프트웨어를 만들었지만, 우리가 하나의 제품만 파는 상태였다면, 우리도 모든 사람들이 사기를 잃고 망해버린 다른 벤처회사들과 같이 되버렸을 것입니다. 우리가 깨끗한 소리를 듣기까지 얼마나 남았는지도 모른체 말입니다.

  다행이도 그런 일은 발생하지 않았습니다. 우리가 종량제를 시작한 이래로, 그래프에서 보듯이, 그것은 마치 호주 라디오 방송국의 신호를 잡았는데 날마다 그 신호가 선명해지고 강해지는 것과 같았습니다. 우리는 여전히 다이얼을 돌리고 안테나를 움직이고 있습니다. 우리는 최근에 전체 매출 성장률이 올라 갈 것을 기대하고 매월 정액제 가격을 낮췄습니다. 배심원들은 아직도 결론을 내리지 못하고 있습니다. 하지만, 포그 크릭(Fog Creek)이 큰 성공 거둘수 있게 하는 공식을 우연히 찾아내서 여러분이 그 성공담에 관한 책을 공항 서점에서 읽을 수 있는 날이 올때까지, 저는 계속해서 조정을 해 나갈 것입니다.

Joel Spolsky is the co-founder and CEO of Fog Creek Software andthe host of the popular blog Joel on Software. To read his pastcolumns, go to www.inc.com/keyword/spolsky.
(조엘 스폴스키는 Fog Creek Software의 공동 창립자이자 CEO이며 인기 블로그 Joel on Software의 주인장입니다. 그의 지난 칼럼을 읽고 싶다면, www.inc.com/keyword/spolsky 를 방문하세요.)



Posted by 지그프리드 지그프리드
  대학교 3학년쯤 되면 앞으로 어떤 직장에서 어떤 일을 하게 될 것인가 - 진로 문제와는 조금 다은 - 가 가장 큰 관심사 중 하나일 것이다. 취직을 하게 되다면 어떤 회사에서 어떤일을 하게 될 것인지, 단순한 코더, 웹사이트 관리자 부터 거대한 프로젝트를 수행하고 공공시스템을 설계하는 등의 일까지 어떤 일을 하느냐에 따라 모든 졸업 후의 삶은 거대한 미지수이기 때문이다.

컴퓨터를 전공하는 학생에게 이 책은 정말 큰 정보와 조언들이 되었다. 현업의 다양한 분야에서 일하고 있는 선배들의 이야기면서, 어떻게 공부를 해야 하고, 어떤 자세를 갖고 있어야 하는지 아주 실제적이고 현실적인 충고들이 있었다. 특히 앞으로 읽어할 책들의 목록과 순서를 정해준 부분과 코딩의 재미를 넘어서야 한다는 일곱 분의 공통된 조언들이 기억에 남는다. 1학년 때 처음올 프로그래밍을 배울 때 교수님이 하셨던 말씀들 - 프로그래밍은 예술이다, 설계가 가장 중요하다 - 의 의미를 다시 한번 새겨볼 수 있는 기회가 되었다.

이제, 나도 그 길을 걸어보려고 한다. 쉽지는 않겠지만 이 책을 쓴 선배들이 밤새워가며 부딫히고 지금까지도 도전하는 그 길은 몸은 좀 편하겠지만 동일한 일을 반복하는 관리직, A/S직보다는 훨씬 역동적일 것 같기 때문이다.

  - 2004. 8.

 이제 와서 다시 리류를 읽어 보면, 저 책 조차도 IT란 분야를 충분히 많이 설명하지는 못하고 있었다는 생각이 든다. 지금 내가 하고 있는 일이 IT인지 제조업인지 늘 헛갈리는 상태에서 내 일이 계속 이렇게 흘러갈지 어떨지도 모르겠고... 어쩌면 뭔가 알듯 말듯한 지금 상황이 더 혼란이 가중된 상태일지도 모르겠다. 과연 나는 어떻게 나아갈 것인가? 라는 질문은 여전히 답이 없고 미지수다. 그게 고과나 평가와 얽히는 순간 일하기 싫어저 버린다. 그냥 그냥 하루하루 주어진 - 아니, 별로 명확하게 선이 그어지고 주어진 일도 없어보인다 - 일을 해 나갈 뿐이다.

  하루 하루. 그러나 분명하게. 실력을 쌓고, 어제 보다 오늘 더 나아지고 있다고 믿는 수밖에 없다. 믿을 수 없다면? 믿을 수 있는 길로 나아가야겠지. 경력은 쌓여가지만, 아직도 얼치기 같다는 생각도 많이 한다. 직장이 날 발전시키는 곳은 아닐지도 모른다. 입사 면접 때 들었던 말이 생각난다.

"자넨 회사가 자네를 훈련 시키는 곳이라고 생각하나?" 


  그때는 웃으면서 둘러 댔지만, 지금은 말할 수 있을 것 같다. 

"아닙니다. 직장은 일하는 곳입니다.

 하지만, 직장 생활을 통해서 나아지는 것이 없다면,

그 직장은 좋은 직장은 아닐지도 모르겠습니다. "


그럼, 결론이 난건가? 글쎄.
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/08   »
        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 : 313,862
Today : 1 Yesterday : 9