2009년 12월 29일 화요일

동종업계 취업금지 각서

개발자에게는 동종업계 취업금지라는 이상한 족쇄가 있습니다.
보통 2년 어쩔 때는 더 길기도 합니다.
입사 시에 이러한 동종업계 취업금지 각서에 사인을 하라고 하는 회사가 종종 있습니다.
물론 특정 업종에 따라서는 이러한 금지조항이 꼭 필요한 경우가 있습니다. 하지만 그렇지 않은 회사에서도 너무 광범위하게 "동종업계 취업금지"를 활용하고 있습니다. 

실제로 이러한 조항 때문에 이직 시에 문제가 되는 경우를 종종 봐왔습니다. 이 와중에 개발자만 괜히 낙동강 오리알이 되고 오갈데 없는 신세가 되곤 하더군요. 이전 회사에 다시 돌아가지도 못하고 참 곤란한 경우를 겪더 군요. 

이 작은 땅덩어리에서 개발자들이 경쟁 업체에 취직을 못하게 하면 개발자는 갈 곳이 별로 없습니다.
이전 회사에서는 상당히 그럴싸한 이유를 댈 수 있습니다. 
개발자가 회사의 소스코드를 몽땅 들고 가서 경쟁회사에서 이를 그대로 사용할 수 있다는 겁니다. 이것은 범죄인데 직원이 퇴사 시 범죄를 저지를까봐 미리 방지하는 셈입니다. 실제로 이러한 걱정을 하는 회사가 꽤 많고 일부 이해도 됩니다. 

마치 지하철에서 신문을 보면 이 신문을 깔고 "대ㅂㄴ"을 볼 수 있으므로 신문을 못 보게 하는 것처럼 생각되기도 합니다.
영업직은 자신의 모든 영업라인을 끌고 이직을 해도 입사할 때 이런 서약을 하라고 하지 않습니다.
물론 개발자가 이직을 해서 기존의 소스코드를 얼마나 활용하고 참조하는지는 알 수 없습니다. 또한 자신이 개발한 일부 함수를 재활용한다고 해도 범죄라고 얘기하기가 어렵습니다. 회사에서는 나중에 문제가 되고 귀찮아지니까 이를 원천 봉쇄하겠다는 뜻이죠.

이는 마치 소수의 개발자와 소스코드에 회사의 경쟁력이 전적으로 의존되고 있다는 뜻이기도 한데, 이런 회사는 보기에도 좀 불안해 보입니다. 개발자들이 퇴사하는 것은 언제든지 일어날 수 있는 일인데, 이것이 그렇게 심각하다면 좀 문제가 있습니다. 분명 개발자는 소프트웨어 회사에서 가장 큰 자산이지만, 이는 소수의 한두명이 아니고 전체를 말하며 팀을 이뤄서 일했을 때 가치를 말할 수 있어야 합니다.

개발자들도 이직을 할 때 두뇌를 완전히 비우고 이직을 할 수는 없겠지만, 또 이전 회사에서 자신이 작성한 소스코드를 참조하고 볼 수는 있겠지만, 소스코드를 완전히 배껴서 동일 제품을 만든 것은 안됩니다. 자신이 만든 소스코드의 지적 재산권은 회사에 있는 것이죠. 다만 이를 만들면서 쌓인 지식과 경험은 개발자 것이지요. 새로 이직한 회사에서도 그 지식과 경험을 사는 것이지 소스코드를 들고 오라고 하면 안되겠죠. 또, 이런 지식과 경험을 이용해서 새로운 제품을 만드는데 힘쓰는 것이 좋겠죠.

개발자들의 마인드도 좀 바뀌어야 무분별한 동종업계 취업금지 관행에서 개발자들이 벗어날 수 있을 것으로 생각됩니다.

개발자들이 모든 소프트웨어 회사로 자유롭게 이동을 할 수 있어야 소프트웨어 업계 전체적으로 발전할 수 있습니다. 그래야 개발자들도 많은 지식과 경험을 접하게 되고, 개발자 및 회사 모두에게 더 많은 기회를 제공합니다.

입사시에 이런 각서에 사인을 해야 한다고 하면 사인을 해도 되는지 잘 한번 생각해보세요. 

2009년 12월 23일 수요일

당신은 개발자도 아니고 관리자도 아냐!

컨설팅을 하다 보면 많은 개발자와 관리자를 만납니다.

그런데, 특히 고참 개발자나 개발자 출신 관리자 중에는 자신의 정체성을 못 찾는 사람들이 많습니다.
이런 사람들에는 다음과 같은 말을 해주고 싶습니다.

"당신은 개발자도 아니고 관리자도 아냐!"

개발자와 관리자 두 가지 일은 병행하여 둘 다 잘할 수 있을 만큼 쉽지 않습니다.

개발자로 5년~10년 일을 하면 팀장을 하라고 합니다. 하지만 팀장으로서 정확하게 무슨 일을 하라고 하는지는 알려주지 않는 경우가 많습니다. 그래서 기존에 팀장들이 어떤 일을 하는지 보고 따라 해보곤 합니다. 하지만 팀장이라는 역할이 개발자로서 개발의 리더 역할인지 관리자의 역할인지 애매한 경우가 많아서 개발도 하면서 관리도 하면서 어쩔 때는 팀장 일을 하느라고 개발은 소홀히 하거나 팀장이라고는 하지만 여전히 개발에 매달리면서 팀장 일은 나몰라 하는 경우가 많습니다. 어떤 경우는 둘다 못하기도 합니다.

또 개발자 출신으로 관리자가 된 경우에는 관리자로서 해야 할 일들이 얼마나 많고 어려운데 개발 관련된 이슈들만 눈에 들어와서 사사건건 개발에 대한 기술적인 이슈 해결에 직접 참견을 하고 해결하려고 하고 정작 본연의 관리 업무는 소홀히 합니다. 개발자 출신으로 관리자가 된 경우는 물론 개발에 대해서 잘 알고 이런 기술적인 이슈에 대해서 조언을 해줄 수 있는 것은 확실하나 사소한 기술적인 이슈까지 너무 참견을 한다면 후배들이긴 하지만 정작 개발자들을 무시하는 처사입니다.
관리자로서는 HR이슈, 프로젝트, 인력, 비용 관리, 부서간 이슈 조정, 경영자에게 보고 등 많은 일들을 더 잘 처리하는 것이 중요합니다.

이런 현상이 벌어지는 근본적인 이유는 개발자와 관리자의 트랙이 명확하게 구분이 되어 있지 않아서입니다. 개발자라면 언젠가는 둘 중에 하나를 선택해야 합니다. 
관리자를 선택한 사람들은 일정 기간이 지나면 다시는 개발자 트랙으로 돌아오지 못합니다.
하지만 개발자 트랙에 있던 사람은 시기에 구애 받지 않고 관리자가 될 수 있습니다. 물론 관리를 잘하느냐 못하느냐는 다른 이슈입니다. 가능하다는 거죠.

이렇게 정해지면, 자신의 업무에 집중해야 합니다. 개발자 트랙을 선택한 사람이 관리에서 오는 행정적인 Power를 추구해서는 안됩니다. 개발자의 Power는 기술에 대한 지식과 경험에서 오는 카리스마입니다. 관리자 트랙을 선택했다면 관리에 힘을 써야지 개발자의 영역을 넘보면 안됩니다. 개발에 대한 해박한 지식과 이해는 관리에 분명히 도움을 많이 줍니다. 그렇다고 하더라도, 개발자가 해야 할 일을 자신이 해는 안되죠. 이미 관리로 넘어 왔다면 기술과는 점점 Gap이 벌어지게 되어 있고 어느덧 자신이 아는 지식은 옛날 지식이 되어 있을 수도 있습니다. 

물론 누구나 좋은 개발자, 좋은 관리자가 될 수는 없습니다. 하지만 둘다 하겠다고 해서는 둘다 못하는 결과를 초래합니다. 선택을 해야 할 시점에 선택을 해야 하고 회사에서도 제도적으로 이를 뒷받침 해줘야 합니다.

둘다 잘할 자신이 있다고 한다면 저는 "개발자"를 선택하겠습니다. ^^

2009년 12월 8일 화요일

SW회사에서의 창업공신 숙청

많은 성공한 소프트웨어 회사들은 초창기에 소수의 개발자들의 피와 땀으로 현재의 성공을 이루었습니다.

이 소수의 개발자들은 일반적으로 열정도 뛰어나고 소프트웨어 개발 실력도 좋습니다. 또한 회사일 내일 가리지 않고 밤낮을 구분 없이 수년 동안 헌신해 왔습니다. 회사의 성공이 곧 나의 성공이라고 생각하고 성공 뒤에 오는 결실도 꿈꿔왔습니다.

그렇게 해서 회사는 성공을 하고 규모도 커졌는데, 과거의 그 창업공신들이 앞으로의 회사 성장에 방해가 되는 경우가 흔히 발생합니다.

회사는 외형적으로 과거와는 비교도 안되게 성장을 했지만, 창업공신들은 과거의 주먹구구 방식의 구태를 못 벗어나면서 새로운 시스템과 프로세스를 적응하지 못하는 경우가 많습니다. 
회사에서 판단해야 할 중요한 기술적이면서 비즈니스적인 이슈들이 많은데도 이들은 여전히 엔지니어 마인드를 못 벗어나서 사사건건 방해가 되곤 합니다.

이들은 이미 회사 내에서 큰 영향력과 파워를 가지고 있고 또 좋은 대우를 해주고 있기 때문에 직원들도 함부로 무시를 못하고 이들도 회사를 떠나고 싶은 생각이 별로 없습니다. 이런 건설적이지 못한 관계는 지속적으로 회사를 괴롭힙니다.

이런 결과는 개인의 성장과 회사의 성장이 조화를 이루지 못해서 발생합니다.
회사의 성장과정의 열악한 환경에서 일해온 창업공신들은 개발자가 성장하면 갖추어야 할 많은 소양을 갖추지 못하게 됩니다. 매일 촉박한 일정 속에 극히 소수의 인원이 모두 슈퍼맨처럼 일을 그것도 오랫동안 해왔기 때문에 체계적인 협업, 전문화, 프로세스 등은 점점 멀어지고, 문서도 제대로 작성 못하고, 리뷰 습관은 꿈도 못 꿉니다. 이러다 보니 10년을 일해도 신참 때보다 코딩만 빨라지고 문제 해결 능력만 좋아졌지, 선임 개발자로서 역량을 갖추지 못합니다. 여전히 혼자서 열심히 일하지 많은 개발자들을 잘 리드하여 큰 프로젝트를 효과적으로 이끌지도 못합니다.

회사에서는 이런 창업공신을 대우해주고 싶어도 그렇지 못한 경우가 많고, 규모가 커진 회사에 전문 경영인이라도 들어오면 숙청을 당하는 일도 발생합니다. 그러다 보면 이런 창업공신은 살아남기 위해서 처절한 정치 싸움이 시작되기도 합니다.

이는 회사와 개발자 모두의 책임입니다.

회사는 개발자가 꾸준히 성장할 수 있는 환경을 제공해야 합니다. 개발자에게 교육의 기회를 제공하고 자기 계발을 할 수 있는 시간과 여유도 줘야 합니다. 회사가 생존 모드인데 언제 그런 여유가 있냐고요? 이는 핑계인 경우가 많습니다. 1년 365일 그럴 수는 없습니다. 개발자 성장에 관심이 있다면 언제든지 기회는 있습니다. 회사가 커 가면서도 소수의 개발자들의 공력에만 의존하지 말고 적당한 시점에 체계를 갖추면서 개발자들도 같이 성장할 수 있는 기회를 제공해야 합니다.

또한 개발자들은 자신의 자기 계발에 꾸준히 노력해야 합니다. 회사가 아무리 기회를 제공해도 본인이 노력하지 않으면 성장할 수 없습니다. 회사가 아무리 바쁘다고 매일 코딩에만 매달리다가는 몇 년이 지나서 코딩기계가 될지도 모릅니다.
여기서 자기 계발이란 개발자로서 성장하는데 필요한 모든 것을 말합니다. 새로운 Technology를 계속 배우고, 프로세스, 툴을 익히고, 소프트웨어 공학도 배우고, 영어가 필요하면 영어 공부도 해야 합니다.
오로지 코딩에만 관심 있다고 하는 개발자들이 있는데 대부분은 코딩의 의미를 너무 광범위하게 생각해서 발생하는 오해이고 대부분, 설계/분석 등 개발에 다양한 분야에 관심이 있는 경우가 대부분입니다. 
너무 바빠서 자기 계발을 할 시간이 없다고 하면 일욕심이 너무 많은 개발자일 겁니다. 일을 조금 천천히 하더라도 자기 계발할 시간을 가지는 것이 본인과 회사 모두를 위해서 좋은 겁니다.

창업공신을 숙청하는 일은 소프트웨어 업계 말고 정치판에서나 있으면 좋겠습니다.