퓨처워커들의 u-Platform 이야기

Slack 슬랙 - 톰 드마르코 지음, 류한석.이병철.황재선 옮김/인사이트

61페이지,
"여러분이 이브와 팀원들을 위해 줄인 여러분의 슬랙은 시간적 의미의 슬랙이 아니다. 그것은 통제권의 슬랙이다. 그것 또한 건강한 조직에게 있어서는 어느 모로 보나 필수라 할 수 있다."

87페이지
"일을 빨리 하라는 시간 압력을 받는다고 지식근로자가 더 빠르게 생각할 수 있는 건 아니다. - 팀 리스터"

91페이지
Push만 하는 것이 관리의 전부라고 믿는 관리자는 진정한 관리가 뭔지 모른다고 할 수 있다. 하지만 그것이 전적으로 그들의 잘못은 아니다. 그들도 원래는 조직도의 아래에 위치한 불쌍한 영혼들에게 끝없는 압력을 가하는 것보다 더 나은 그리고 더 만족스러운 무언가를 하고 싶었던 사람들이다.

107페이지
기력을 모두 소진한 직원은 대개 기업을 떠나기 위해 이직을 준비한다. 하지만 항상 그런 것은 아니다. 떄떄로 그들은 그냥 좀비로 남는다. 그런 좀비들이 많은 조직. 즉 직원 대부분이 살아 있는 시체들로 구성된 조직은 아주 갑갑하고 무기력한 느낌으로 가득 차게 된다.

127페이지
나쁜 관리의 제1법칙의 원자, Gerald M. Weinberg. 1990년대. "만약 무언가 제대로 동작하지 않는다면, 그것을 더 많이 하라"

나쁜 관리의 제2법칙, "관리자 자신이 만능 선수가 되라."

132페이지
관리가 여려운 이유는, 관리 기술이라는 게 본질적으로 숙련되기 어렵기 때문이다. 관리는 모든 것이 미묘하다. 도대체 왜 마리아는 그렇게 예민한 거지? 알만드와 엘우드 사이의 긴장감은 뭐지? 대니가 정말 새 직장을 찾고 있을까? 그가 떠난다면 우리는 어떻게 하지? 내가 데드라인을 너무 공격적으로 정해서 문제가 생기지는 않을까? 혹시 직원들이 나의 무지를 비웃고 있는 건 아닐까? 보고할 때 내 말투가 적절한가? 내 상사가 조직의 눈 밖에 나면 나는 어떻게 될까? 등등.

139페이지
분노한 관리자는 패배자다. 사람들을 어떻게 이끌어야 할지 전혀 모르는 채 스스로 감당할 수 없는 일을 하고 있는 불행한 무능력자다.

147페이지
건강한 조직에서는 어느 정도의 실패가 용인된다. 예를 들어, 마이크로소프트의 경우에는 "실패하라. 그 다음에 성공하라(sink, then swim)", 라는 거의 공식화된 정책을 갖고 있다.

161페이지
지식근로는 테일러주의가 결코 필요 없는 영역이다. 지식근로는 공장근로와 매우 다르다. 조립 라인이 없고, 고정된 규칙이 존재하지 않느며, 그 가치가 아주 주관적이어서 정략적 측정이 힘들고, 판단력이 가장 중요시된다.

169페이지
내가 생각하는 품질 운동의 문제는 그 비용의 과도함이나 조직의 에너지를 너무 많이 소모한다는 데 있지 않다. 효용성은 적은데 비해 립서비스는 넘친다는 게 문제다.
슬랙이 없는 품질 프로그램은 마치 잔인한 유머와도 같다. 시간과 인적자원이 부족하면 실제로는 기대치보다 더 느리게 일하게 되고 그러한 지연 비용의 결과로 품질에 문제가 발생하게 된다. 초기 또는 중간 단계에서 없애버린 시간은 결국 이후의 작업과 품질에 문제를 가져온다. 문제는 그러는 와중에도 "품질"에 대해 헌신하고 있다는 공허한 주장을 여전히 멈추지 않는다는 사실이다.

174페이지
제품의 품질은 그것의 "유용성"에 달려있지 그 제품이 얼마나 "결함"이 없는가가 아니다.

리더쉽은 여러분의 의제에 다른 사람을 동참시키는 능력이다. 리더쉽의 중요한 측면은 장기적인 이익을 얻기위해 단기적인 고통을 감수하는 것이다.


258페이지
근무시간에는 직원들에게 한 번만 말하면 그들은 여러분의 지시에 따라 일을 할 것이다. 하지만 어린이 야구팀의 경우에는 지시 내용을 반복해서 말해야 하고 제대로 들었는지 계속 확인해야 한다. 아이들을 잘 타이르고 반복해서 애기하고, 잘못을 바로잡고, 자신감을 갖게 하고, 칭찬을 하고, 동기부여를 하기 위해 노력해야 한다. 무엇을 하든지 처음부터 몇 번씩 반복해야 할 것이다.

295페이지
낡은 관리 방식의 핵심 요소를 나는 제조업 정신(pdocution mentality)이라고 부른다. 그것은 해당 조직의 관리자들이 사용하는 용어를 보면 분명히 알 수 있다. 여기서 내가 지칭하는 대상은 공장 생산라인의 관리자가 아니라 지식근로자들을 제조업 정신으로 관리하는 관리자이다. 그들은 "공장", "작업량"의 "측정", "공정", "품질 통제", "효율성", "ROI", "낭비 제거", "원가 절감"등과 같은 용어를 사용한다. 그런 용어들이 조직에 만연해 있다면 그것은 바로 리스크 기피를 나타내고 지식 조직의 실패를 부르는 징후라고 할 수 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

출처: 서진호의 모바일/임베디드 이야기

안녕하세요.

취업을 고민 중인 수도권 대학교 4학년 A이라고 합니다. :)

제 꿈은 퓨처워커님같은 임베디드 전문가입니다.

며칠 전에 2G폰을 만드는 중소기업 면접을 보고 왔습니다.

저는 여름방학에 국비로 휴대폰 SW개발 전문가 과정을 들었는데요.

약 두 달간 공부하면서 휴대폰 업계 강사님들의 이야기를 듣고 나니

휴대폰 SW개발자는 퀄컴에서 준 dmss 소스를 가지고 줄창 UI만 수정한다는 인상을 받았습니다.

그리고 좀 짬이 되어야 포팅을 하게 되는 펌웨어 수준도 다룰 수 있다고 하고요

요세 추세가 안드로이드나 아이폰 같은 거의 범용 수준의 OS로 바뀌어 가는 것 같은데

한물간 퀄컴의 rex나 dmss만 다루는 2G폰 만드는 곳을 가려니 걱정이 됩니다.

더군다나 퓨처워커님의 휴대폰 개발자의 치즈는 어디갔느냐 란 글을 읽고 고민이 한층 심해졌습니다 ^^;;

그냥 휴대폰 쪽으로 취업해 UI로 시작해서 펌웨어 수준까지 가느냐.

(면접을 본 회사는 디바이스팀과 SW팀이 나누어져 있다고 합니다)

아니면 다른 리눅스 임베디드 같은 접근을 해야 하는지 궁금합니다.

----------------------------------------------------------------

안녕하세요. 퓨처워커입니다.

일단 꿈이 임베디드 전문가라고 하시니 반갑네요. 제가 다니는 회사도 요새 경력사원을 뽑고 있는데 나중에 경력을 쌓으신 후에 같이 일할 기회도 오길 바랍니다.

일단 질문을 다음과 같이 정리해보죠

휴대폰쪽으로 취업해서 UI로 시작해서 Firmware 수준까지 가느냐 아니면 리눅스 임베디드/안드로이드/아이폰 같은 개방형 OS 기술을 준비하느냐?

  우선 제가 작성한 "2007/11/06 - [플랫폼 컨설팅/Mobile] - 휴대폰 S/W 개발자들이여 치즈가 사라지고 있다."를 보시면 걱정하시는 방향이 이해가 갑니다.

 하지만 제가 쓴 글을 비평하면서 한번 현실을 얘기해보죠.

 일단 국내에서 "임베디드 리눅스"를 배워서 입사할 수 있는 "휴대폰" 회사가 몇 개나 될까요? 국내 대기업인 휴대폰 제조사라면 분명 임베디드 리눅스 개발자를 필요로 할 것입니다. 하지만 아직까지 그 인원수는 극히 제한적일 것으로 알고 있습니다.

 하물며 대기업이 그렇다면 국내 중소기업에서 "임베디드 리눅스"로 휴대폰S/W를 만드는 회사는 제가 아는 한 "미지리눅스"와 "엠트레이스" 정도가 제일 유명합니다. 문제는 이런 회사들은 대부분 인원을 바로 프로젝트에 투입해야 하기때문에 아마도 신입사원을 뽑아서 사람을 키우는 것에 조금은 부담을 느낄 것입니다.

  "A"군 같은 사회 초년생들이 오해하는 것은 "최신 기술"을 익혀야만 취직이 잘 될것이라는 오해가 많습니다. 또는 "최신 기술"을 알아야 회사에 입사해서 "오래 다닐 수 있을 거라" 생각하기도 합니다. 하지만 "최신 기술에 대한 지식"은 회사에서 사람을 뽑을 때 "필요 조건"이기는 하지만 "충분 조건"은 아닙니다. 오히려 "기술" 보다는 "어떤 경험"이 있느냐가 더 중요합니다.

  따라서 "경험"이 적은 "신입 사원"의 경우는 "갖고 있는 기술의 수준"보다는 "열정"이나 "개방적인 마인드'를 더 중요시 여길 수 밖에 없습니다. "기술"은 배우면 되지면 "마인드"는 배워서 되는 것이 아니거든요.

2008/03/11 - 학교가 좋으면 취직이 어렵다-어느 면접관의 이야기

  결론적으로 "A"군이 현실적으로 회사를 입사하는 방법은 인력 수요가 아직은 많은 기존의 RTOS 기반의 휴대폰 S/W를 개발하는 회사로 가는 것이 빠른 길이라 예상합니다. 

  문제는 그 때부터입니다. 대부분의 발전하지 못하는 사람들은 자신에게 주어진 일만 하기 마련입니다. 그 회사에서 들어가서 회사에서 주는 업무인 "줄창 UI"만 수정하는 일만 한다면 아마도 본인이 원하는 Firmware 수준의 일을 하지는 못할 겁니다.

  여기서 또 다른 오해가 하나 있습니다. "줄창 UI"만 수정하는 것이 Firmware를 다루는 일보다 "수준이 낮다"라는 의미를 내포하는 느낌입니다. 물론 기술적인 수준이 낮아보일 수도 있습니다. 하지만 정말로 그럴까요?

  말 그대로 주어진 기존 코드만을 수정하는 단순한 "Coder"가 된다면 그 말은 맞습니다. 하지만 S/W란 어느 Layer라 할지라도 정말 제대로 된 개발자라면 "구조"적인 설계자로서의 능력을 향상시켜야 합니다. 그런 "설계자"로서의 능력을 가지고 Application을 개발할 수 있는 사람과 그렇지 못한 사람은 나중에 "치즈"를 선택할 수 있는 폭이 달라집니다.

  또한 회사를 다니면서 "휴대폰" 분야에만 너무 시야가 좁아질 필요도 없다고 생각합니다. 만약 A군의 임베디드 분야의 경험이 "휴대폰"에 종속된다면 자신이 다니던 회사가 망하면 선택의 폭은 좁아집니다. 리스크 관리 측면에서도 "임베디드 기술"이 활용될 수 있는 전반적인 트렌드와 기술도 짬짬이 익혀야 합니다.

  예를 들어 휴대폰 분야의 Application이라면 이제 모바일 디바이스라고 할 수 있는 PMP, 카네비, 전자사전 등 다양한 분야의 회사로 갈 생각도 해야하고 그 이상으로 TV 제조사도 갈 수 있다는 생각으로 봐야 합니다.

  물론 이 정도 생각을 하려면 어느 누구도 "짬"이 되어야 이런 "자기 발전"의 필요성을 느끼게 됩니다. 세상에는 "필요성"을 느끼는 사람과 "변화의 방향성"을 발견하는 사람 그리고 "그 방향으로 변화를 실천하는 사람"이 결과적으로 차이가 있기 마련입니다. A군은 어떤 사람이 되시겠습니까?

  일단 시작은 본인이 입사 가능한 "최선"의 직장에서 경력을 쌓으시기 바랍니다. 그리고 "지속"적으로 자신을 발전시키기 위한 "방향"을 탐색하십시요. 그런 방향은 그 회사의 "사수"에게만 얻을 수 있는 것은 아닙니다. 그리고 "방향"을 지속적으로 실험하십시요. 그런 방향을 위한 노력을 하다보면 어느덧 "A"군도 누구에겐가 "도움을 요청하는 메일"을 받고있지 않을까요?

  전 제 인생의 재미를 "발전을 향한 변화"에서 찾고 있습니다. 그런 "변화"가 저를 힘들게 하지만 그런 변화만이 저를 "생존"시킬 수 있을 거라 생각합니다. 이놈의 IT 분야가 그걸 원하기도 하니까요. 그래서 IT는 힘이 듭니다. 만약 그런 "변화"가 싫다면 일찌감치 다른 분야를 알아보실 것을 권하구요.

  너무 일반적인 얘기를 한 것 같아서 도움이 될지 모르겠습니다만, 궁금하시다면 답글 주시기 바랍니다.

북한산 공기가 싱그러운 가을에

http://futurewalker.kr

2008년 10월 13일

참조링크

미래의 행복한 소프트웨어 개발자가 되려면 (3)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.