'프로그래밍'에 해당되는 글 4건
- 2009.11.02 아키텍트 이야기
- 2009.10.29 사랑하지 않으면 떠나라! 4
- 2009.07.08 티맥스라는 회사에 대한 실망 20
- 2009.06.08 아이들의 아파트 자랑
이 정도 경력이 되면 이전에는 눈에 보이지 않던 것들이 서서히 보이기 시작하고 개발 프로젝트의 전체적인 흐름 파악도 어느 정도 될 시점인데, 이제는 프로그래밍을 그만 둬야 하나? 지금까지 익혀온 기술과 눈치(?)가 아깝게 느껴진다. 프로젝트 관리자 등을 맡아서 프로젝트의 성공을 위해 일을 할 수는 있지만, 지금까지 쌓아놓은 개발 노하우는 어디에 써야 한단 말인가. 그냥 그대로 묵혀놔야 할까. 아깝다.
나이가 먹어서도 계속 프로그래밍을 할 수 있는 방법은 없을까? 어느 정도 실력과 연륜을 쌓은 개발자로 현장에서 일할 수 있는 방법은 없을까? 이 책에서는 하나의 길을 제시하고 있다.
바로 아키텍트라는 것인데, 아키텍트는 아래와 같이 정의할 수 있다.
아키텍트는 아키텍처를 설계하고 그것을 시스템 개발 전체에 미치게 하는 것이 임무다. 개발팀의 중심인물로, 팀원을 이끈다는 의미에서 '프로젝트 리더(PL)'와 겹치는 부분도 있지만, 시스템 기획 같은 초기 단계에 기술 전문가로 참여하거나, 시스템이나 프로젝트의 특성에 맞춰서 문서세트를 구성하는 등, 활동무대는 더욱 폭넓다.
아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 11쪽.
그럼 아키텍처는 무엇인가? 아는 사람은 다 아는 이 단어는 건축에서 기초와 골격에 비유할 수 있다. "시스템 전체의 대략적인 구성과 거기에 구체적인 구현지침을 합친 개념" 정도라고 이 책에서는 이야기하고 있다.
이 책에서 이야기하는 아키텍트의 주요 업무로는 다음과 같은 것들이 있다.
- 요구사항 정의에 참여
- 아키텍처 설계
- 프레임워크 준비
- 문제 해결
- 테스트 지원
- 개발 이외의 업무 지원
이 내용들을 보면 프로젝트 관리자(Project Manger, PM)의 역할과 비슷해 보이는데, 프로젝트 관리자는 프로젝트가 원활하게 수행되도록 하는 데 중점을 두는 반면, 아키텍트는 설계와 프레임워크 개발 등 프로젝트의 기술적인 핵심 부분을 담당하게 되는 역할이라고 할 수 있다.
아키텍트가 하는 일은 결정된 명세를 프로그래밍하는 프로그래머나, 프로젝트의 원활한 진척을 계획하는 프로젝트 관리자의 업무와 다르다. 기술적 관점에서 시스템 전체를 넓게 바라볼 수 있는 존재가 바로 아키텍트다. 아키텍트라는 말은 '책임 설계자'로 번역하는 것이 정확할 것이다. 아키텍트의 역할이 애플리케이션의 설계와 구현 전체를 책임지고 개발팀을 이끄는 것이기 때문이다.
아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 19쪽.
이 책은 실제 개발 프로젝트에서 일어날 만한 일을 예로 들어 아키텍트 C가 이를 어떻게 풀어나가며 어떤 일을 하는지를 설명하고 있다. 이 흐름을 따라가면 아키텍트가 주로 어떤 일을 해야 하고 어떤 것들을 알아야 하는지 파악할 수 있을 것이다. 이 책에서도 강조하고 있는 부분은 개발자라고 해서 개발만 잘 하면 되는 것은 아니라는 것이다. 개발자가 아키텍트의 역할을 제대로 수행하기 위해서는 무엇보다도 비즈니스를 이해하고 의사소통 능력이 필요하게 된다.
아키텍트는 기술력을 토대로 시스템 개발과 IT를 활용하는 비즈니스에 이르는 넓은 범위에 대해 깊은 이해가 있어야 한다. 이러한 아키텍트의 역할을 이미 다양한 비즈니스 현장에서 요청하고 있다. 비즈니스에 대한 IT의 영향력이 커지면 아키텍트의 필요성 역시 높아질 것이다.
아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 214쪽.
물론 아키텍트는 개발팀 내에서 최고 개발자이기 때문에 기술적인 능력도 뛰어나야 한다. 단순히 자신이 알고 문제를 해결하는데 끝나는 것이 아니라, 이러한 기술력을 바탕으로 다른 팀원들이 해결하기 힘든 경우 도와줄 수 있어야 하며, 기술적인 문제에 대해 개발자가 아닌 다른 부서의 사람들을 이해시킬 수 있어야 한다. 즉, 기술력 뿐만 아니라 이를 풀어서 설명할 수 있는 능력과 의사소통 능력이 중요하다는 말이다.
아키텍트는 책임 설계자이며 최고 개발자로서, 개발팀을 이끌 수 있을 정도의 전문적인 기술과 역량이 요구되는 역할이다. 기술에 대해 잘 알고 있는 팀원들을 결속시키기 위해서는 그들이 인정할만한 기술력이 필요하다. 이와 동시에 개발팀과 비즈니스의 가교 역할을 해야 한다. … 아키텍트는 시스템 개발이라는 활동에서 기술자와 비즈니스 관계자들이 서로 협조할 수 있도록 조정자 역할을 한다.
아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 215쪽.
기술자가 흔히 하는 실수는 전문용어를 남발하는 것이다. 그 기술을 아는 사람들끼리는 전문용어를 쓰는 것이 의사소통에 도움이 될 지 모르겠지만, 이런 기술을 모르거나 익숙하지 않은 사람에게 자세한 설명 없이 전문용어를 무분별하게 쓴다면 이야기를 하기 싫다는 뜻으로 받아들여지기 딱 좋을 것이다. 전문용어는 상대를 봐가면서 쓰도록 하자. 전문용어를 쓰지 않고도 상대에게 내가 하고자 하는 말을 제대로 전달할 수 있어야 제대로 된 기술자가 아닐까?
비기술자인 결정권자에게 기술자의 의견을 적절하게 전달하는 데는 어려움이 많다. 기술적으로 정확한 판단과 근거, 부적절한 판단이 가져올 위험요소를 이해시키려면, 프로그램을 한 행씩 지적하며 설명하거나, 프로그램 언어나 제품 등에 대해 자세하게 가르쳐야 하기 때문이다. … 비기술자에게 의견을 전달할 때는 전문용어를 되도록 쓰지 않고, 도표나 비유를 이용하여 설명한다. 문제가 복잡한 경우에는 개요만을 정확히 전달하는 방법으로 앞서 말한 실수를 피할 수 있다. 물론 때에 따라서 정확하고 자세하게 설명하지 않아도 되는 상황도 있을 수 있다.
아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 181쪽.
아래는 이 책을 감수하신 한의근님이 책의 첫머리에 하신 말씀이다. 그리고, 내가 하고 싶은 말이기도 하다.
기술자의 정년은 마흔이라는 말을 들을 때마다 안타깝다. 나이가 많아지면 그만큼 경륜이 생기는데도 관리직 일을 맡아 경험을 충분히 활용할 수 없게 되는 경우를 적지 않게 보아 왔다. 현재 가지고 있는 소망 중 하나는 나이가 들어서도 장인 기술자로 남고 싶다는 것이다.
아키텍트 이야기, 야마모토 케이지 지음, 이지연 옮김, 인사이트, 2007년 4월, 6쪽.
'Books' 카테고리의 다른 글
| 이기적 유전자 (2) | 2009.11.12 |
|---|---|
| 카인의 징표 (4) | 2009.11.08 |
| 사랑하지 않으면 떠나라! (4) | 2009.10.29 |
| 내 통장 사용설명서 (8) | 2009.10.23 |
| 보랏빛 소가 온다 (0) | 2009.10.22 |
- 사랑하지 않으면 떠나라!
- Books
- 2009. 10. 29. 09:03
IT 직종, 거기에서도 개발자들은 상대적으로 낮은 임금과 열악한 근무 환경에서 일을 하고 있다. 남들이 보기에는 멋있어 보이는 직업이지만, 실상 안을 들여다보면 처참하기 그지 없다. 밥 먹듯이 야근하는 것은 기본이며, 자기를 위해 시간을 투자하는 것은 사치일 정도로 어렵게 살고 있는 것이 개발자들의 삶이다.
엎친 데 덮친 격으로 개발자가 멋있어 보이는 것인지 먹고 살기 좋다는 헛소문이 떠돈 탓인지 개발자들이 넘쳐나고 있다. 그렇지 않아도 열악한 근무 환경으로 인해 어려운데 넘쳐나는 개발자들로 인해 자신이 원하는 좋은 자리를 찾는 것도 힘들어지고 있다. 물론 이런 건 어디나 다 마찬가지일 거다. 개발자에게만 한정된 어려움은 아니라는 것은 안다.
그렇다면, 이런 어려움 속에서 우리는 어떻게 해야 할까? 개발자들이 앞으로도 자기 자리 지키면서 먹고 살기 위해서는 어떻게 해야 할까? 그냥 지금 하는 있는 일이나 잘 하고 있으면 회사에서 정년 혹은 퇴직할 때까지 먹여 살려줄까?
이 책의 지은이 차드 파울러는 흔치 않은 경력을 가지고 있다. 음악을 했고 색소폰을 하다 우연한 기회에 개발자로 일을 시작하여 지금은 꽤 알려진 개발자이다. 한 회사의 인도 개발센터를 맡으며 인도에서 생활하기도 했고, 다른 여러 나라의 개발센터 개설하는 것을 돕기도 했다. 이 책은 이런 일을 겪은 차드 파울러가 개발자가 앞으로 어떤 생각과 어떤 준비를 해야할 것인가를 말해준다.
이 책의 서론에는 개발자들이 비즈니스 관점에서 자신의 경력을 위해 집중해야 할 네 가지 측면이 나와있다.
- 자신의 시장을 선택하라. 집중할 기술과 비지니스 분야를 신중하게 고른다. 리스크와 보상의 균형을 어떻게 맞출 것인가? 수요와 공급을 어떻게 결정할 것인가?
- 자신에게 투자하라. 지식과 기술은 자신이라는 상품의 주출돌이다. 지식과 기술에 적절하게 투자하는 것은 자신의 시장성을 높일 수 있는 중요한 부분이다. 단순히 비주얼 베이직(Visual Basic)으로 프로그래밍하는 것만으로는 더 이상 충분하지 않다. 새로운 경제 환경에서는 어떤 기술이 필요할까? 해외 또는 국내 경쟁자들과 어떻게 경쟁할까?
- 실행하라. 단순히 뛰어난 기술을 갖춘 직원을 고용하는 것으로는 회사에 성과가 나지 않는다. 직원은 회사를 만족시킬만한 가치를 만들어내야 한다. 여러분은 무리하지 않고 그러한 페이스를 어떻게 유지하는가? 자신이 회사를 위해 좋은 가치를 만들고 있는지 아닌지 어떻게 인지하고 있는가?
- 마케팅 하라. 역사상 최고의 제품이라도 아무도 모르면 팔리지 않는다. 여러분은 회사와 업계에서 자신을 전혀 알리지 않고 어떻게 인정받는가?
사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 30쪽.
안타깝게도 현장에서 이런 생각을 갖고 있는 개발자를 만나기는 어려운 일이다. 이런 비슷한 생각들을 가진 사람이라도 현실의 벽이라는 것에 부딪혀서 제대로 해보지 못하고 포기한 경우도 있다. 그 벽을 넘는 것이 당연히 쉬운 일은 아닐테고 그걸 넘어서야 발전이 있을텐데 현재에 정체되어 버린, 어떻게 보면 현실과 타협해버린 삶을 살고 있는지도 모르겠다.
넘쳐나고 있는 개발자들, 날로 늘어가는 새로운 기술들. 이 틈바구니 속에서 나를 돋보이게 하고 앞으로도 개발자로 살기 위해서는 무엇을 해야할까? 남들 다 알고 있는 기술을 알고 있다는 것만으로는 부족하다. 요즘은 Java나 C, Python, PHP 등을 알고 있다고 그게 내세울만한 것이 되지 못한다. 개발자라면 누구나 다 알고 있는 거 아냐? :-)
어떤 기술에 투자할지 생각하는 것만으로는 충분하지 않다. 이제 기술은 필수품이 되어버렸다. 결국 프로그래머들은 비즈니스 담당자들이 비즈니스를 책임지는 동안 편하게 앉아서 단순히 프로그래밍 언어를 익히거나 운영체제를 공부하는 일만 할 수 없게 되었다. … 회사에서 계속 쓸모있는 사람으로 남고 싶다면 자신이 속한 비즈니스 분야에 뛰어들어야 한다. 실제로 소프트웨어 개발자는 비즈니스 분야를 이해하고 그에 해당하는 소프트웨어를 잘 개발할 수 있어야 할 뿐만 아니라 그 분야 권위자가 되어야 한다.
사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 43쪽.
맞는 말이다. 어떤 것이든 어떤 분야든 비즈니스가 적용되지 않은 곳은 없고 그걸 이해하지 못한다면 개발자는 단순히 코딩을 하는 기계에 불과할 것이다. 제대로 알고 일을 하자.
비즈니스 분야를 잘 선택해야 하는 중요성에 비춰보면 포트폴리오를 완성할 때 여러분이 선택한 회사나 업계는 자신에게 중요한 투자처다. 자신이 투자해야 할 비즈니스 분야에 대해 아직 정말 진지하게 생각해 보지 않았다면 지금이 바로 생각해야 할 때다. 하루가 지나갈 때마다 기회를 잃어버리는 것이다. 정체된 비즈니스 분야에서 개발 일을 계속 하는 것은 고이자율 예금 상품이 나왔는데 이자율이 낮은 계좌에 예금을 계속 내버려두는 것과 같은 좋지 않은 투자 선택이다.
사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 45쪽.
이건 참 쉽지 않은 것이다. 지금 몸 담고 있는 곳을 벗어나 새로운 것에 투자하는 것, 쉽게 결정할 수 있는 일이 아니다. 여기에는 상당한 위험이 존재하고 그 위험을 제대로 극복하지 못할 때에는 경력 자체가 흔들릴 수도 있다. 하지만, 미래를 위해서는 적극적인 투자가 필요할테고 현실에 안주하는 것은 결국 도태를 의미하기 때문에 뭔가 방법을 찾기는 찾아야 한다. 역시 그건 위험을 감수하고 도전하며 투자하는 것이 아닐까.
직업을 선택하는 기준은 무엇인가? 사람에 따라 다르겠지만, 난 좋아하지 않는 일을 직업으로 선택하는 것은 불행이라고 생각한다. 어떻게 좋아하지도 않는 일을 하루 종일 할 수 있단 말인가. 아무리 먹고 살려고 하는 일이라도 말이다. 더군다나 일의 성과나 능률도 좋아하는 일과 그렇지 않은 일의 경우에는 차이가 많이 생긴다. 열정을 가지고 일을 할 때의 성과가 더욱 좋다는 것은 누구나 인정할 것이다.
다양한 분야의 대가에 대한 전기나 다큐멘터리를 보면 이같이 열정적으로 몰두하는 행동 패턴이 나타난다. 재즈 색소폰의 대가 존 콜트레인(John Coltrane)은 소문에 따르면 입술에 피가 나도록 연습했다고 한다. 물론 타고난 재능도 능력에서 중요한 구실을 한다. … 그러나 우리 모두는 열정을 쏟을 수 있는 일을 찾아냄으로써 평범함을 벗어나 한 단계 더 도약할 수 있다.
사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 82쪽.
열정을 가지고 일을 한다는 것은 여러 면에서 좋은 일이다. 당장 지금 하고 있는 일의 성과가 올라가게 될 것이며, 이에 따라 여러 일에 좋은 영향을 미칠 것이다. 그래, 나비의 날개짓 하나가 허리케인을 불러오는 거야!
그리고, 자신에게 투자하는 것은 정말 중요하다. 끊임없이 투자하고 발전하지 않는다면 도태될 수 밖에 없다. 하루가 다르게 변하고 있는 이 세상에 나만 변하지 않는다면 결과는 뻔하다. 그리고 이런 투자는 위에서 이야기한 "열정"을 가지고 해야할 일이다. 열정이 없는 투자, 즉 마지못해 새로운 기술을 배우거나 지금 당장 프로젝트에 적용하기 위해 다른 언어를 대충 살펴보는 것은 시간 낭비다.
이런 경험을 한 적도 있다. 새로운 기술에 대해 스스로 찾아보거나 공부할 생각은 하지 않고, 처음 접하는 것이기 때문에 개략적인 것들을 추려서 세미나를 부탁하는 사람을 본 적이 있다. 누구는 태어날 때부터 그 내용에 대해 알고 태어난 것인가? 알고 있는 것을 공유하고 또 그 과정에서 내가 아는 것을 정리할 수 있기에 응하기는 했지만, 그런 생각은 참 마음에 들지 않는다.
소프트웨어 개발자에게 적용할 수 있는 노자의 교훈은 다음과 같은 것이다. "물고기 한 마리를 달라고 하면 하루 동안 먹는다. 물고기 잡는 법을 가르쳐 달라고 하면 평생 동안 먹는다." 그러나 가르쳐 달라고 부탁하기보다는 차라리 스스로 찾아서 배우라.
사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 93쪽.
무엇인가를 정말 배우고 싶다면 그것을 다른 누군가에게 가르쳐 보라. 어떤 것에 대한 이해를 구체화하는 데 가장 좋은 방법은 다른 사람들이 이해할 수 있도록 그것을 표현하는 것이다. 말을 한다는 것은 단순한 행동이지만 불분명한 사고를 다루는 데는 특효약이다. 인형과 같은 물체와 얘기하는 것은 소프트웨어 개발에서 전승되어온 잘 알려진 문제 해결 수단 중 하나다.
사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 104쪽.
개발을 하다 보면 지겨운 일을 해야할 때도 있다. 이럴 때는 능률도 오르지 않고 짜증이 나기도 한다. 어떻게 하면 이런 일들을 즐겁게 할 수 있을까? 이것을 반대로 생각해보면, 지겨운 일은 왜 지겨울까? 왜 아직도 재미가 없을까?
대부분의 기술자에게 일이 지겨워지는 것은 다음과 같은 두 가지 근본적인 이유 때문이다. 좋아하는 일을 하면 창조력이 발휘된다. … 그냥 넘어가고 싶은 일들은 창조력을 발휘할 여지를 주지 않는 일일 것이다. … 지겨운 일이 지겨워지는 두 번째 이유는 첫 번째 이유와 명백히 밀접하게 연결되어 있다. 지겨운 일은 도전적이지 않다는 것이다.
사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 156쪽.
그렇다면, 어떻게 해야 지겨움에서 벗어날 수 있을까? 이 책에서는 이를 위해 "지겨운 일을 완벽하게 하려고 노력해 보는 건 어떨까?"라고 제안하고 있다. 일을 완벽하게 하는 것은 사실 불가능하다. 하지만, 완벽하게 하려고 함으로써 일은 어렵게 느껴질 것이고 그럼 결과적으로 지겨움에서 벗어날 수 있다는 것이다. 어찌 보면 맞는 말인 것 같기도 하다. 앞으로는 지겨운 일을 만날 때 이 방법을 시도해 봐야겠다.
일을 하면서 실수는 언제나 생길 수 있다. 사람에 따라 실수에 대처하는 방법이 다른데, 어떤 방법을 선택하느냐에 따라 다른 사람의 나에 대한 평가는 달라진다. 실수를 무작정 덮으려고 하지 말고, 아래와 같은 방법을 써보라고 파울러는 말하고 있다.
- 알게 되자마자 문제를 제기하라.
- 책임을 지라.
- 해결책을 제시하라.
- 도움을 구하라.
자존심이 쌘 사람이거나 높은 직책에 있는 사람이라면 이렇게 솔직하게 행동하는 것이 어려울 지도 모르겠다. 하지만, 잘못하다가는 배보다 배꼽이 더 커지는 사태가 발생할 수도 있음을 잊지 말자.
그리고, 우리는 일에 대한 약속을 너무 쉽게 한다. 그러다 이 약속을 지키기 위해 무리하게 작업을 하기도 하고 대충 작업을 마치기도 한다. 결국 이건 또 다른 문제를 일으키게 되고 잘못하다가는 무능력한 사람으로 낙인 찍힐 수도 있다.
"예"라고 말하는 것은 습관적이고 유해한 버릇이다. 그것은 좋은 사람인 척 하려는 나쁜 버릇이다. '할 수 있다'는 태도와 자신의 능력을 '거짓으로 말하는 것'은 차이가 크다. 후자는 자신뿐만 아니라 자신이 약속한 사람들에 대해서도 문제를 일으킨다. …
"아니오"라고 말할 용기가 있는 팀원이 있고 그 말이 사실이라면, "예"라고 말할 때에는 그것이 거짓말이 아님을 알 수 있다. 이런 사람이 하는 약속은 더 믿을 만하다. … 어떤 사람이 항상 "예"라고만 말한다면 엄청나게 재능이 있거나 거짓말을 하는 것, 둘 중에 하나다. 대개의 경우 후자다.
사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 181쪽, 183쪽.
그리고, 자주 느끼는 것인데, 개발자라면 의사 소통이 중요하다. 어떤 요구 사항이 있을 때 이를 제대로 이해해야 하며, 보고서 등을 작성할 때도 전달하고자 하는 것을 제대로 전달할 수 있어야 한다. 그런 면에서 파울러는 "개발자는 글쓰기 능력을 배양한다"라고 말하고 있다. 특히 문법과 철자에 맞춰 제대로 적을 줄 알아야 한다라고 말한다. 아울러 논리적이고 체계적으로 자신의 생각을 글로 표현할 수 있어야 한다. 아무리 좋은 아이디어가 있다고 하더라도 그것을 다른 사람에게 제대로 설명할 수 없다면 무슨 소용이 있겠는가.
글쓰기 능력이 있으면 자신을 잘 인식할 수 있을 뿐만 아니라 내적으로는 자신이 어떤 길로 가고 있는지에 대한 진정한 통찰도 생긴다. 다른 사람이 분명하게 이해할 수 있도록 자신의 모국어로 자기 생각을 구성할 수 없는데, 프로그래밍 언어로 그렇게 할 수 있다고 어떻게 기대하겠는가?
사랑하지 않으면 떠나라!, 차드 파울러 지음, 송우일 옮김, 인사이트, 2008년 1월, 207쪽.
이왕 하는 일이라면 즐기면서 일을 하고 최선을 다해 자신이 하는 분야에서 최고가 되기 위해 노력해 보자. 하루 하루 닥친 일들 대충 처리해가며 살아갈 수도 있겠지만, 그보다는 조금만 더 앞을 내다 보며 인생을 사는 것이 멋지지 않을까? 용의 꼬리보다는 뱀의 머리가 되고 싶다. 그러기 위해 오늘 하루도 힘차게!
'Books' 카테고리의 다른 글
| 카인의 징표 (4) | 2009.11.08 |
|---|---|
| 아키텍트 이야기 (0) | 2009.11.02 |
| 내 통장 사용설명서 (8) | 2009.10.23 |
| 보랏빛 소가 온다 (0) | 2009.10.22 |
| 파인만 씨, 농담도 잘하시네 (5) | 2009.10.21 |
- 티맥스라는 회사에 대한 실망
- Thoughts
- 2009. 7. 8. 13:06
지난 글에서 말했지만, 난 그래도 국내에서 처음으로 운영체제를 개발한다는 티맥스에 조금이나마 기대를 갖고 있었다. 그런데, 어제 있었던 티맥스 발표회를 본 후에는 실망만이 남는다. 어제 그들이 한 것은 제품 발표회가 아니다. 어제 그들이 한 것은 한낫 쇼에 불과하다. 그 많은 사람들을 데리고 그런 의미없는 쇼를 할 생각을 하다니, 그들은 참 대단하다.
이건 얼마나 잘 개발했느냐의 문제가 아니다. 기업의 신뢰에 대한 문제이다. 운영체제 개발이라는 것이 얼마나 어려운 일인가 하는 것은 프로그래밍에 대해 조금이라도 아는 사람이라면 충분히 이해할 것이다. 처음부터 제대로 동작하는 운영체제를 개발한다는 것은 불가능에 가까운 일이다. Microsoft나 Apple에서도 새로운 운영체제가 나올 때마다 문제가 발생하고 수시로 버그 수정을 한다. 따라서 이건 창피한 일은 절대 아니다. 문제는 그걸 숨긴다는 것이다.
처음부터 잘 돌아가는 운영체제와 소프트웨어를 개발한다면 얼마나 좋겠는가. 하지만, 이건 거의 불가능한 일이기 때문에 개발자나 개발 회사에서는 항상 이런 문제점이 발생할 수 있다는 것을 인식하고 이에 대해 대처를 해야 한다. 그런데, 어제 발표회에서 그들은 자신들이 개발한 운영체제를 숨기기 위해 상당히 많은 노력을 기울였다.
차라리 그런 발표회를 하지 않거나 연기하는 것이 옳은 일이었겠지만, 이미 확정된 일정이라 그리 하지 못한다면 있는 그대로를 보여주고 정직하게 자신들의 문제점을 밝히는 게 그리도 어려웠을까? 투자자들이 떨어져나갈 것이 두려웠나? 어차피 대다수 국민들은 대충 그렇게 발표해도 속을 것이라 확신하고 그런 허무맹랑한 발표회를 준비한 건가?
이런 제품 발표회가 있었던 적이 있는지 궁금하다. 해외 토픽감이 아닐런지 모르겠다.
지금까지 티맥스라는 회사에 대한 많은 비난을 있어왔지만, 이번 운영체제 개발에 대해서만은 그들이 지금까지 들어왔던 비난을 벗어나 제대로 된 개발 정책이 있기를 바랬다. 어제 발표회는 이런 바람이 쓸데없는 정력 낭비였다는 것을 여실히 보여주었고, 티맥스라는 회사는 그저 입만 살아남은 무책임한 회사라는 것을 다시 한번 깨닫게 해주었다. 티맥스라는 회사는 양치기 소년과 다를 바 없다.
우리가 바라는 것은 입으로 개발하는 회사가 아니다. 어제 그들이 보여준 쇼는 지금까지 고생한 티맥스 개발자들을 기만하는 행위이며 그들의 노력을 거짓으로 만들어버린 몹쓸 짓이다. 그런 회사에 몸 담고 고생하는 개발자들이 불쌍하다. 이래저래 불쌍한 것은 개발자이다.
...
이러니 저러니 해도, 이런 문제가 있다는 것을 아는 사람은 얼마 되지 않고, 결국 티맥스 윈도는 어떤 식으로든 관공서 등에 설치될 것이다. 쳇! 어제 발표회를 보니 티맥스에서는 다분히 그럴 의도라는 것이 분명해 보인다. 우리나라 정책결정자들이 이런 기업의 제품은 쓰지 말아야 기업들이 정신 차리게 될텐데, 이건 총체적인 난국이다.
이건 얼마나 잘 개발했느냐의 문제가 아니다. 기업의 신뢰에 대한 문제이다. 운영체제 개발이라는 것이 얼마나 어려운 일인가 하는 것은 프로그래밍에 대해 조금이라도 아는 사람이라면 충분히 이해할 것이다. 처음부터 제대로 동작하는 운영체제를 개발한다는 것은 불가능에 가까운 일이다. Microsoft나 Apple에서도 새로운 운영체제가 나올 때마다 문제가 발생하고 수시로 버그 수정을 한다. 따라서 이건 창피한 일은 절대 아니다. 문제는 그걸 숨긴다는 것이다.
처음부터 잘 돌아가는 운영체제와 소프트웨어를 개발한다면 얼마나 좋겠는가. 하지만, 이건 거의 불가능한 일이기 때문에 개발자나 개발 회사에서는 항상 이런 문제점이 발생할 수 있다는 것을 인식하고 이에 대해 대처를 해야 한다. 그런데, 어제 발표회에서 그들은 자신들이 개발한 운영체제를 숨기기 위해 상당히 많은 노력을 기울였다.
차라리 그런 발표회를 하지 않거나 연기하는 것이 옳은 일이었겠지만, 이미 확정된 일정이라 그리 하지 못한다면 있는 그대로를 보여주고 정직하게 자신들의 문제점을 밝히는 게 그리도 어려웠을까? 투자자들이 떨어져나갈 것이 두려웠나? 어차피 대다수 국민들은 대충 그렇게 발표해도 속을 것이라 확신하고 그런 허무맹랑한 발표회를 준비한 건가?
이런 제품 발표회가 있었던 적이 있는지 궁금하다. 해외 토픽감이 아닐런지 모르겠다.
지금까지 티맥스라는 회사에 대한 많은 비난을 있어왔지만, 이번 운영체제 개발에 대해서만은 그들이 지금까지 들어왔던 비난을 벗어나 제대로 된 개발 정책이 있기를 바랬다. 어제 발표회는 이런 바람이 쓸데없는 정력 낭비였다는 것을 여실히 보여주었고, 티맥스라는 회사는 그저 입만 살아남은 무책임한 회사라는 것을 다시 한번 깨닫게 해주었다. 티맥스라는 회사는 양치기 소년과 다를 바 없다.
우리가 바라는 것은 입으로 개발하는 회사가 아니다. 어제 그들이 보여준 쇼는 지금까지 고생한 티맥스 개발자들을 기만하는 행위이며 그들의 노력을 거짓으로 만들어버린 몹쓸 짓이다. 그런 회사에 몸 담고 고생하는 개발자들이 불쌍하다. 이래저래 불쌍한 것은 개발자이다.
...
이러니 저러니 해도, 이런 문제가 있다는 것을 아는 사람은 얼마 되지 않고, 결국 티맥스 윈도는 어떤 식으로든 관공서 등에 설치될 것이다. 쳇! 어제 발표회를 보니 티맥스에서는 다분히 그럴 의도라는 것이 분명해 보인다. 우리나라 정책결정자들이 이런 기업의 제품은 쓰지 말아야 기업들이 정신 차리게 될텐데, 이건 총체적인 난국이다.
'Thoughts' 카테고리의 다른 글
| 지식의 너비와 깊이 (22) | 2009.07.09 |
|---|---|
| 구글 이벤트 상품이 도착했습니다! (50) | 2009.07.08 |
| 그들에게 박수를! (22) | 2009.07.08 |
| 양치기 소년 (0) | 2009.07.07 |
| 아날로그에 대한 그리움 (26) | 2009.07.07 |
- 아이들의 아파트 자랑
- Thoughts
- 2009. 6. 8. 10:32
길을 걷다가 놀이터에서 자신의 아파트를 자랑하는 두 꼬마의 이야기. 내용인 즉 ..
- 꼬마A : 우리 아파트는 디게 디게 높아서 저번에 비행기 땜시 무너진 빌딩(WTC를 말하는 듯) 100배야!!
- 꼬마B : 우리 아파트는 에레베스트랑 삐까전쩍(?)해!!
- 꼬마A : 우리 아파트는 미사일 맞아도 끄떡없써!!!
- 꼬마B : 흥!! 우리 아파트는 핵폭탄 맞아도 끄떡없다!!!
- 꼬마A : 우리 아파트는 록히드가 만들어써!(이꼬마 뭐지?)
- 꼬마B : 우리 아파트는 내가 만들었어!!
- 꼬마A : 우리아파트 주차장에는 자동차가 천만대나 들어가!!
- 꼬마B : 우리아파트 주차장에는 자동차가 무한대로 들어가!!
- 꼬마A : 우리 아파트는 로보트로도 변신해!!
- 꼬마B : 우리 아파트도 변신한다!!
- 꼬마B : 우리 아파트에 사는 여자들은 다 이쁘다!
- 꼬마A : 우리 아파트에 사는 남자들은 전부 힘 세!!!
옥신 각신. 그렇게 10분여 정도가 지나고 두 아이의 말을 종합해 봤을 때.
꼬마A가 사는 아파트
- 높이 : (417m x 100) 즉 41700m
- 층수 : (110x100) 약 1만여층
- 건설자제 : 강화 티타늄, 특수 콘크리트
- 주차장넓이 : (자동차 한대를 주차시키는대 약 3평이라 했을때) 10000000x3 약 3천만평 (여의도 공원의 142배)
- 건설업체 : 록히드마틴 사
- 부가기능 : 비상시 전투지원 메카닉 변환
- 주류 입주 주민 : 조폭,씨름선수 등으로 추측
꼬마B가 사는 아파트
- 높이 : 8,848m
- 층수 : 약 2천여층
- 건설자제 : 외계 광물질
- 주차장넓이 : 버뮤다 삼각지, 블랙홀이라 추정
- 건설업체 : 민간인 (꼬마B)
- 부가기능 : 비상시 전투지원 메카닉 변환
- 주류입주주민 : 8천미터의 대형아파트에 모두 미녀 입주자가 주거하고 있음.
via 아이들의 아파트 자랑
아이들의 대화보다 저걸 계산한 사람 때문에 한참 웃었다.
죠리퐁 세기를 읽어보면 또 한참을 웃을 수 있을 것이다. 아, 이 글은 어느 정도 프로그래밍에 대한 안다거나 리눅스에 대해 아는 사람이 봐야 동감하며 웃을 수 있다. 댓글이 4 페이지 정도 되니 시간 있을 때 천천히 읽어보길 권한다. 특히 주위에 누가 있다면 조심하는 것이 좋을 것이다. :-)
'Thoughts' 카테고리의 다른 글
| 200번째 트위터 Follower (4) | 2009.06.08 |
|---|---|
| 정치 성향 자가 진단 (2) | 2009.06.08 |
| 뿌리를 찾아서 (0) | 2009.06.08 |
| 72의 법칙 (4) | 2009.06.08 |
| 아님 말고! (6) | 2009.06.07 |
Recent comment