주식 투자, 부동산 투자, 시간 관리.... 세상엔 재테크를 다루거나 자기 계발에 관련된 서적이 널려 있지만, 개발자가 어떻게 자신에 투자하고, 경력 개발을 해나갈지 조언하는 책은 드물답니다. 아직도 책을 구입할까 말까 망설이는 분들을 위해 아래에 내용 일부(52개 실천 사항 중 하나)를 공개하니 참고하세요.
------------------------------------------------------------------------------------
또는 작은 신생 기업에 투자할 수 있다. 예를 들어 수천 달러를 투자해 회사 소유권 일부를 얻을 수 있다. 회사의 구상이 좋고 그것을 효과적으로 실행할 수 있다면 돈을 많이 벌 수 있을 것이다. 하지만 다른 한편으로는 원금을 되찾을 수 있다는 보장은 없다.
이 개념은 새로운 것이 아닐 것이다. 사람들은 어렸을 때 놀이를 하면서부터 이것을 배운다.“내가 가운데로 달려 내려가면 모두 놀랄 거고 아무도 날 잡지 못할 거야.” 이러한 생각은 일상의 생활에서도 자주 떠오른다. 회의에 늦어 어느 길로 회사에 가야할지 결정할 때 위험과 보상을 적절히 조절(trade-off)해야 한다.“길이 막히지 않을 경우 32번가로 가면 15분 일찍 도착할 수 있어. 길이 막히면 난 망하는 거지.”
위험-보상 트레이드오프는 어떠한 기술과 영역에 투자할지 신중하게 고르는 데 중요한 부분이다. 10년 전만 해도 위험이 작은 안전한 선택은 코볼 프로그래밍을 배우는 것이었다. 물론 평균 임금을 놓고 경쟁했던 코볼 프로그래머가 많았지만 그다지 대단하지 않았다. 일자리를 쉽게 찾을 수 있었지만 돈을 특별히 많이 벌지는 못했다. 위험이 작은 만큼 보상도 작았던 것이다.
반면에 같은 시기에 썬 마이크로시스템즈(Sun Microsystems)에서 새로 출시한 자바 언어를 연구하기로 했다면 자바로 실제 개발을 하는 회사의 일자리를 찾기가 한동안 어려웠을 것이다. 그러나 결국 자바로 개발을 하게 될 줄 누가 알았겠는가? 그러나 당시에 업계 상황을 보고 있었다면 썬이 그랬던 것처럼 자바에 특별한 뭔가가 있다는 것을 알았을 것이다.
자바가 클 거라는 강한 느낌이 들었을 것이다. 초기에 자바에 투자하면 다가오는 거대한 기술 추세에서 리더가 됐을 것이다. 물론 그렇게 됐다면 여러분이 옳았을 것이다. 그리고 패를 제대로 냈다면 자바에 대한 개인적인 투자는 매우 수지 맞는 것이 됐을 것이다. 위험이 큰 만큼 보상도 큰 것이다.
1995년 Be에서 BeOS를 시연했을 때를 떠올려 보자. BeOS는 당시로서는 엄청난 운영체제였다. 이 운영체제는 멀티프로세서를 활용하기 위해 처음부터 새로 만들어졌다. 멀티미디어 성능은 정말 놀라웠다. BeOS 플랫폼은 확실한 입소문을 만들어냈고 전문가들은 운영체제 동네에 강력한 새 경쟁자의 등장을 예감하고 들떴다.
물론 새 플랫폼에는 새 프로그래밍 방법, 새 API(Application Programming Interface) 새 사용자 인터페이스가 따라왔다. 배워야할 게 많았지만 정말 그만한 가치가 있어 보였다. BeOS용 FTP(File Transfer Protocol) 클라이언트나 개인 정보 관리 프로그램을 만든 최초의 개발자가 되기 위해 엄청나게 노력한 사람들도 있었다. Be에서 BeOS의 인텔Intel 호환 버전을 출시하자, 애플Apple이 Be를 사들여 차세대 매킨토시Macintosh 운영체제의 기반으로 BeOS 기술을 사용한다는 소문이 돌았다.
애플은 Be를 사지 않았다. 그리고 Be가 틈새시장조차 잡지 못할 것이라는 것이 결국 확실해졌다. 그 제품은 받아들여지지 않았다. BeOS 환경 프로그래밍을 익힌 많은 개발자들은 자신들의 투자가 장기적으로 잘 되지 않을 것이라는 것을 천천히 그리고 고통스럽게 깨닫게 됐다. Be는 결국 팜Palm에 매각됐고 운영체제는 단종 됐다. BeOS는 위험하지만 매력적인 기술 투자였다. 그러나 BeOS에 경력을 투자하기로 한 개발자들에게는 구체적이고 장기적인 보상을 주지 못했다. 위험은 컸지만 보상은 없었다.
지금까지 최첨단인 기술과 확고하게 기반이 닦인 기술을 선택하는 것에는 차이가 있다는 것을 얘기하고 있다. 세계적으로 기업 생산 시스템에 자리 잡은 안정된 기술을 선택하는 것이 아직 더 안전하다. 그러나 아무도 활용하지 않은 화려한 신기술을 고르는 것보다는 보상이 적을지도 모르는 선택이다. 하물며 수명이 다한 기술은 어떨까? 종지부를 찍고 관에 들어갈 기술 말이다.
누가 종지부를 찍는가? 예를 들어 백발의, 은퇴 날짜를 기다리는 마지막 RPG(Role Playing Game) 프로그래머들이 있다고 하자. 젊은 세대들은 RPG에 대해 들어본 적도 없다. 모두 자바와 닷넷만 배우고 있다. 죽어가는 옛 기술을 아는 최후 기술자의 경력이 기술과 함께 죽어가고 있음을 상상하기란 어렵지 않다.
그러나 옛 시스템은 죽지 않는다. 교체된다. 게다가 대부분의 경우에 자체 개발 시스템은 단계별로 교체된다. 그 단계에서 옛 시스템은 새 시스템과 통신할 수 있어야 한다. 누군가는 새 시스템에서 옛 시스템으로, 그리고 옛 시스템에서 새 시스템으로 통신하게 하는 방법을 알아야 한다. 일반적으로 신출내기들은 옛 시스템이 새 시스템을 알아듣게 하는 법을 모른다(알고 싶어는 한다). 은퇴를 앞둔 늙고 괴팍한 사람들 역시 최신식 시스템이 자신들이 아끼는 시스템과 통신하게 하는 방법을 모른다.
기술 호스피스
따라서 신중한 공학자(technologist)의 역할이 필요하다. 바로 기술 호스피스(technology hospice)다. 옛 시스템이 편안하고 존엄하게 죽도록 돕는 일은 과소평가될 수 없다. 물론 대부분의 사람들은 기술이 수명을 다하기 전에 은퇴하거나 또 다른 기술 영역으로 옮길 것이다. 중요한 시스템을 지원하는 최후의 1인이 된다면 여전히 칼자루를 쥘 수 있다. 물론 그렇게 한다는 것은 위험 부담이 있다. 일단 기술이 정말 사라지면 '존재하지 않는 기술의 전문가’가 되어 버리기 때문이다. 하지만 빨리 움직이면 수명이 다해가고 있는 레거시 시스템을 찾아 다시 시작할 수 있다.
채용 곡선에는 어느 쪽이든 막다른 곳이 있다. 막다른 곳에서 얼마만큼 떨어져 있고 싶은가?
