삼성이 바다를 출시해서는 안되는 이유

일전에 삼성이 왜 소프트웨어를 잘 개발하지 못하는지에 대한 글을 쓴적이 있습니다.

2010/01/05 - [소프트웨어이야기] - 삼성은 왜 소프트웨어를 잘 만들지 못할까?

개인적인 생각이지만 바다의 정식 출시가 임박할수록 점점 걱정스러워지고 있습니다.

일단 이글은 삼성을 비난하려고 작성한 글이 아닙니다. 삼성이 잘되어야 하는 이유를 잘 알고 있는 한 사람으로서 현재 상황에 대한 소프트웨어 공학적인 우려를 말하고자 하는 사견임을 밝혀둡니다.

일단 삼성이 왜 바다를 출시하고 싶어 했는지 그 마음은 충분히 이해를 합니다. 기존에 피처폰에서 삼성은 눈부신 성과를 거두었고, 10여년전만해도 경외의 대상이던 여러 Global 회사를 추월하고 이제 Nokia만 앞에 보이는 상황입니다. 이 과정에서 너무 큰 자신감을 가지게 된게 아닌가 생각되는 군요.

삼성의 대단한 저력과 성과는 인정합니다. 하지만 삼성이 이렇게 핸드폰 분야에서 성공한 이유를 제대로 알아야 합니다. 하드웨어 제조 능력과 탁월한 마케팅 능력이 있었던 것이지 소프트웨어를 잘 만들어서는 절대로 아니라고 봅니다. 삼성에게 자신들의 시장을 내준 Global 회사들이 소프트웨어를 제대로 만드는 능력이 삼성보다 부족해서 삼성에게 진 것이 아닐겁니다. 그런데 이런 결과가 삼성에게 소프트웨어에 대한 자신감까지 불어 넣어 준 것이 아닌가 생각이 듭니다.

기존 피처폰에서는 소프트웨어 개발 능력 부족이 사업을 성공하는데 결정적인 요소로 작용하지 않았다고 봅니다. 소프트웨어 개발력의 부족함은 인력과 자금으로 보충하고 소프트웨어 개발자들의 헌신적인 야근으로 어떤 글로벌 회사들도 불가능했던 초단기간에 새로운 모델의 핸드폰을 만들어서 출시를 해왔습니다. 이러다보니 경영층에서는 개발팀의 소프트웨어 개발 능력을 대단히 높게 과대평가 했을지도 모릅니다. 어떤 회사보다 빨리 개발을 해내기 때문에 소프트웨어를 잘 이해하지 못하는 경영자들은 착각하기 충분하다고 봅니다. 하지만 이러한 무리한 개발이 계속 되면서 소프트웨어를 잘 개발할 수 있는 역량을 닦을 기회조차 박탈당했기 때문에 현재 삼성이 가지고 있는 소프트웨어 개발 능력은 삼성의 위상에 걸맞지 않에 뒤처져 있다고 생각합니다.

삼성의 소프트웨어 개발능력은 삼성이 제쳤던 핸드폰 회사들이나 애플, 구글과는 비교도 할 수 없을만큼 떨어진다고 봅니다. 부정하고 싶겠지만 긍정적인 증거는 별로 없는 것이 현실입니다. 그동안 소프트웨어에 얼마나 투자를 해왔을까요? 소프트웨어를 잘 아는 경영자를 등용하고 믿어주고 밀어줬나요? 제가 알기로는 그렇지 않지 않습니다.

스마트폰은 기존에 삼성이 크게 성공시킨 피처폰과는 다릅니다. 피처폰 처럼 몇날 며칠 개발자들이 코피 쏟아가면서 개발하면 되는게 아닙니다. 게다가 스마트폰 OS(Platform)의 개발은 몇차원 더 높은 개발입니다. 정말 소프트웨어를 잘 만드는 회사가 아니면 제대로 만들수가 없습니다. 이런 종류의 소프트웨어를 개발할 때 가장 깊게 고려해야 하는 요소는 눈에 보이는 기능이 아닙니다. 수많은 비기능 요소가 훨씬 중요합니다. 앞으로 바다를 통해서 전세계 수많은 개발자들이 소프트웨어를 개발을 해야 합니다. 이때 발생하는 모든 요소를 고려해야 합니다. 전세계 개발자들이 삼성 개발자들처럼 밤새며 개발하게 만들 건가요? 하나의 Application을 만드는 것과는 차원이 다른 얘기입니다. 물론 고려야 했겠지만, 현재 삼성의 위상에 걸맛게 모든 사람들이 기대하는 바를 충족실킬 만큼 소프트웨어 개발 능력은 갖추고 있지 않기 때문에 출시후 겪게 수많은 문제들이 눈에 보이는 듯합니다.

능력의 한계를 알아야 합니다. 능력을 훨씬 뛰어넘는 무모한 도전은 대단한 도약 아니면 엄청난 실패를 가져옵니다. 삼성은 그동안 이러한 한계를 많이 뛰어 넘어왔습니다. 하지만 소프트웨어 분야에 있어서 만은 엄청난 실패가 기다리고 있는 듯합니다. 바다의 도전은 기존과는 다른 도전입니다. 소프트웨어에 있어서 능력이 안되는 것은 안되는 겁니다. 진정한 소프트웨어 개발역량을 갖추려면 소프트웨어 분야에 제대로 투자해서 10년은 걸릴 겁니다. 그래도 조직내의 복잡한 역학관계 때문에 어려울 겁니다.

사실 저는 바다는 출시를 포기하는 것이 삼성에 더 이익이라고 생각합니다. 일단 출시를 해 놓으면 되돌릴 수가 없습니다. 이제부터 돈은 돈대로 들어가고 욕먹을 시간일 될 것입니다. 유지보수는 끝없이 들어갈겁니다. 아기는 한번 낳으면 다시 엄마 뱃속으로 들어가라고 할 수 없습니다. 그리고 바다의 유지보수는 삼성만의 이슈가 아닙니다. 이를 기반으로 소프트웨어를 개발한 전세계 개발자들과 관련됩니다. 삐끗하면 핸드폰 하나 망치는게 아닙니다. 그 파급효과가 얼마나 큰지 지금 상상할 수 있어야 합니다.

정말 바다가 순항을 하면서 칭송을 받는 상황이 발생한다면 삼성은 나 뿐만아니라 어느 누구도 모르는 끝내주는 소프트웨어 개발팀을 수백명 양성을 해왔고 이들이 바다를 개발했다는 것인데 이런 기적같은 일이 벌어지겠습니까? 지금도 바다가 큰 성공을 거두기를 기대하고는 있지만, 그리 희망적으로 생각되지 않습니다.

차라리 안드로이드폰을 더 잘 만들기 위해 투자하는 것이 더 좋은 선택이라고 생각합니다. 사실 이것도 쉽지는 않습니다. 기존 피처폰 만드는 마인드로 또 밤세워가며 Copy & paste가 난무하는 개발을 한다면 별로 나아질 것이 없습니다. 그렇지만 바다에 투자할 막대한 노력을 현실성있는 안드로이드폰 개발에 투자를 하는 것이 좋을 겁니다. 

이미 삼성은 스마트폰 분야에서 상대적으로 뒤쳐지기 시작했다고 봅니다. 만약에 바다가 크게 실패한다면 그동안 이룩해 놓은 휴대폰 분야에서 삼성의 브랜드에 크게 타격을 줄지도 모릅니다. 

삼성은 그동안 수차례 엄청난 변화를 통해서 세계 제1의 IT회사가 되었습니다. 앞으로 한단계 더 점프를 하려면 소프트웨어 분야를 손놓고는 어렵습니다. 어렵더라도 내부에서 여러 방해에 부딛히더라도 소프트웨어에 투자를 해야 합니다. 비싼 툴 사주고 복잡한 프로세스 만드는 것이 소프트웨어에 대한 투자가 아닙니다. 애플, 구글 또는 실리콘밸리의 작은 소프트웨어 회사들이 어떻게 소프트웨어를 개발하는지 보십시오. 기존 조직에서 안된다면 소프트웨어 분야는 새로운 조직에서 새로운 경영자와 때묻지 않은 새로운 개발자들로 새로 시작해서 Global 경쟁력을 갖춘 소프트웨어 조직으로 키우는 것도 한 방법일 겁니다. 

정말 소프트웨어 분야는 잘 될 가능성이 없다면 그냥 하드웨어 분야에서 더 큰 성공을 거두는 것이 좋겠네요. 지금의 삼성처럼요. 

이미 "바다"의 출시가 기정 사실이라면 "바다"의 "순항"을 간절히 기원합니다.  

아이폰, 안드로이드폰 개발자 급구

요즘 확실히 스마트폰이 이슈이긴 한 모양입니다.

종종 "아이폰 개발 경험이 있는 개발자 급구" 또는 "안드로이드폰 개발 경험이 있는 개발자를 모십니다"와 같은 채용 광고를 보게 됩니다.

과연 아이폰이나 안드로이폰 개발 경험이 있는 개발자가 아이폰과 안드로이드 앱을 더 잘 만들까요?

전 아니라고 생각합니다. 당장은 실력은 부족하지만 해당 경험이 있는 개발자들이 개발 속도가 조금더 빠를 수는 있지만, 6개월 아니 1,2달만 지나도 아이폰, 안드로이드폰 개발 경험은 없지만 원래 소프트웨어를 잘 개발하는 개발자가 훨씬 더 낫습니다. (경험도 있고 실력도 있다면 말할 필요도 없지만...)

개발자를 채용하려는 회사에서 이런 경험있는 개발자를 요구하는 것은 소프트웨어 개발에 대한 이해가 부족하거나 진짜 급해서일 겁니다. 첫번째 경우도 별로 가고 싶은 회사가 아니지만 두번째 경우도 문제네요. 소프트웨어 회사에 있어서 가장 중요한 자산은 개발자인데 이렇게 근시안적으로 개발자를 뽑는 회사는 문제가 있어보입니다.

요지는 개발자들의 개발 능력은  Domain지식과 경험에 크게 구애받지 않아야 한다는 겁니다. 물론 Domain지식이 소프트웨어를 개발하는데 필요한 것은 사실이지만 이는 어느 환경에서 일하느냐에 따라서 자연스럽게 익히게 됩니다. Domain지식을 핵심무기로 삼는 개발자들은 더 좋은 회사로의 이직이 어렵고 계속 그 물에서만 돌아다니다가 소프트웨어 개발자로서의 실력은 형편없는 개발자가 되고맙니다.

또한 개발자들은 Coding도 잘해야 합니다. 그런데 하나의 개발 언어에 매달리는 경우도 위와 비슷한 경우입니다. 나는 Java밖에 못한다. 또는 나는 C++밖에 못한다라고 못을 박는 개발자들이 있습니다. 물론 손에 익은 언어를 사용하는 효율이 높기는 하지만 그렇다고 하나의 개발 언어로만 개발을 하면 스스로 자신의 미래 진로를 가로막는 꼴입니다. 

진정 소프트웨어 개발자라면 특정 개발 언어, 특정 Domain 지식, 특정 Technology에 올인하지 말고 골고루 다 경험을 해야 하고 새로운 것에도 쉽게 적응할 수 있어야 합니다. 특히 고참 개발자가 될수록 다양한 경험과 적응력이 있어야 View도 넓어지고 회사내에서도 기술적으로 중요한 업무를 수행할 수 있습니다. 그래야 개발자로서 10년, 20년 지속적으로 가치있게 일할 수 있습니다.

뛰어난 아이폰, 안드로이드폰 개발자를 뽑고 싶으면 그냥 뛰어난 개발자를 채용하셔야 합니다. 그 개발자와 1,2달 일하고 말것이 아니라면요.

소프트웨어 회사 vs. 정치판 (이인자 죽이기)

"Two is company, Three is a crowd"

사람이 3명 이상 모이면 다툼이 있을 수 있지만, 정치도 생기기 마련입니다.

정치를 잘하는 사람도 있는가 하면 정치 자체를 모르는 사람도 많습니다. 저는 완전 후자입니다. 하지만 소프트웨어 개발자로서 15년 이상 일해온 시간을 꺼꾸로 거슬러서 생각해보면 크고 작은 정치판이었다는 것을 깨닫게 됩니다. 그리고 왜 과거에 그런 일들이 일어났고 왜 그렇게 흘러왔는지 이해가 됩니다. 그것이 그들만의 생존 방법이었다고 생각이 듭니다.

내가 이해할 수 없는 것은 정치가 별로 필요 없을 것 같은 소프트웨어 회사에서 뭔 그리도 많은 정치가 판을 치냐는 겁니다. 모두 힘을 합쳐 실력만 발휘하기도 부족한 마당에 정치로 소모하는 에너지가 어마어마합니다.

특히 실력은 없이 오로지 정치력으로 버티는 사람들이 많아서 이런 사람들이 버티는 조직에서는 정치는 모르지만 진짜 실력이 있는 사람들 특히 개발자들은 성장하기 어렵습니다. 특히 관리자와 개발자의 경계가 모호한 우리나라에서는 정치성이 강한 개발자들이 뛰어난 선임 개발자들을 정치적으로 말살하는 일들이 종종 벌어집니다.

관리자와 개발자는 엄연히 다른 직종이지만, 정치적 관리자는 이들을 미래의 경쟁자로 생각하여 나쁜 평가를 내리며 회사에서 몰아내기도 하고, 시키는 대로 일 잘하는 약간 멍청한 개발자들을 열심히 등용하곤 합니다. 5년 후에 위협이 될 듯한 개발자들은 싹부터 자르는 거지요. 중간관리자들의 이러한 행태를 회사의 최고 경영층이 눈치채기란 어렵습니다. 그렇게 시간이 흐르고 나면 우리가 흔히 보는 정치만 판치는 회사가 되는 겁니다. 그리고 뛰어난 인재가 다 죽어버려서 마땅히 일을 시킬 사람이 없어지고, 이들을 죽인 관리자만 계속 등용하는 수밖에 없게 됩니다.

개발자를 너무 열심히 관리하면 안되는 이유가 여기에도 있습니다. (프로젝트 관리는 다른 이슈입니다.)

개발자들은 일반 다른 직종과는 다르게 스스로 자신들이 할 일을 찾아내고 일을 합니다. 개발자들에 필요한 관리란 고작 휴가나 캐리어 관리(지원) 등입니다. 자칫하면 "과유불급"이 됩니다.

개별 프로젝트에서는 프로젝트 관리자가 관리업무를 수행하니 일반 관리자가 할 일은 그렇게 많지 않습니다. 따라서 20~30명 규모의 회사가 관리의 강화를 위해서 일반 관리자를 채용하곤 하는데, 소프트웨어 개발에 대해서 잘 이해하고 있지 않은 관리자들은 개발자들의 일을 방해하고 사기를 저하시키며 개발자를 내쫓기도 합니다. 

개발조직을 전통적인 서열 조직으로 만들지 마십시오. PM, 팀장, 부서장이 있을 수 있지만, 시스템과 프로세스를 통해서 개발자와 최고 경영층이 직접 접촉을 유지할 수 있도록 해야 합니다. 그렇지 않으면 정치꾼 관리자가 귀한 인재를 다 짤라 버릴지도 모릅니다.

삼성은 왜 소프트웨어를 잘 만들지 못할까?

오늘 아침 조선일보 IT관련 기사를 보다가 다음 글을 보게 되었습니다.

[조형래 IT팀장의 심층 리포트] 삼성폰 운영체제 '바다' 순항 준비 끝!

사실 삼성에서 개발하고 있는 바다에 관심은 있지만 큰 기대를 하고 있지 않기 때문에 별 생각 없이 기사를 훑어 보고 있는데, 생각해볼 내용이 있어서 인용합니다.

삼성전자는 이를 통해 '하드웨어는 강하지만 소프트웨어는 약하다'는 인식을 단번에 뒤집겠다는 것이다. 삼성전자가 '바다(bada)'라는 한글 이름을 해외 시장에서도 그대로 사용한 것도 한국에서 개발한 휴대폰 플랫폼이라는 이미지를 세계인에게 각인시키기 위해서다. 홍 상무는 "바다 프로그램은 스마트폰뿐 아니라 일반 휴대폰에서도 사용할 수 있도록 설계된 게 차별화 요소"라면서 "(바다는) 전 세계 개발자들이 만든 수많은 응용프로그램이 거래되는 장터라는 의미도 있다"고 말했다.  조선일보기사에서 인용

'하드웨어는 강하지만 소프트웨어는 약하다'는 인식을 단번에 뒤집겠다"

이 의미는 원래 소프트웨어가 강한데 인식만 안 좋은 것이고 바다를 기똥차게 만들어서 인식을 바꾸겠다는 걸까요?

아니면 원래 소프트웨어가 약한데 이번에 바다를 개발하면서 갑자기 소프트웨어를 잘 만드는 조직으로 탈바꿈하겠다는 걸까요?

사실 둘다 말이 안되기는 마찬가지입니다.

일단 삼성도 소프트웨어는 약하다고 스스로 인정하는 것 같고, 그 동안의 경험을 토대로 판단해보면 절대로 소프트웨어를 잘 만드는 조직이라고 볼 수 없기 때문에 첫번째는 무시하죠.

비록 소프트웨어는 잘 못 만들지만, 소니, 모토롤라가 따라 올 수 없는 큰 강점들이 많아서 지금은 성공을 이루었기 때문에 삼정 자체를 평가할 생각은 없습니다. 단지 소프트웨어 얘기를 좀 해보죠.

왜 소프트웨어를 잘 못 만들까요? 사실 외형적인 것만 보면 부족할 것이 없어 보입니다. 조직, 프로세스 모두 갖추고 있고(오히려 과도하기도 합니다.), 개발툴이나 시스템은 세계 최고의 것들을 쓰고 있고, 똑똑한 개발자들이 바글바글(반대하는 사람도 많을 것 같네요.) 합니다. 

마치 "아이폰"과 "옴니아2"를 스펙만 놓고 보면 큰 차이가 없지만 막상 둘을 나란히 놓고 써보면 느낌이 확 다른 것과 비슷하다고 할까요?

겉보기에는 비슷하게 흉내를 내고 있지만, 속을 까보면 조금씩 다릅니다. 그 작은 차이들이 모여서 이렇게 되었다고 볼 수 있죠. 결국의 개발문화의 차이로 나타납니다. 실제 제 컨설팅 경험에 의하면 그런 환경에서 그런 방법으로 소프트웨어를 개발하고도 지금까지 살아 있는 것에 감탄을 하면서도 그 속의 개발자들을 안타깝게 생각한 적이 있었습니다. '좋은 환경과 제대로된 조직에서 개발을 해왔으면 훨씬 잘 되었을 개발자들인데'라는 생각이 들더군요.

결국 그 원인은 경영층의 소프트웨어에 대한 무지 때문이라고 생각합니다. 하드웨어 분야는 몇 십년간 정말 많은 투자를 해온 것에 비해서 소프트웨어는 그렇지 못합니다. 하드웨어적인 마인드로 소프트웨어 조직을 키울 수 있다고 생각하는 것 자체가 말이 안됩니다. 소프트웨어 조직은 소프트웨어를 철저히 이해하고 있는 경영자가 있어야 합니다. 이러한 경영자가 힘을 가지고 10년 이상은 노력해야 세계적인 소프트웨어 회사들과 어깨를 조금 나란히 할까 말까 합니다. 그렇게 할 수 있을 까요?

힘이 있고 소프트웨어를 정말 잘 이해하는 경영자가 있어야 소프트웨어 개발자들이 꾸준히 성장할 수 있는 길을 열어 줄 수 있습니다. 소프트웨어 개발이란 철저히 사람이 하는 일이라서 뛰어난 개발자들을 10년 이상 키워내야 합니다. 그냥 연수만 10년을 채운다는 의미는 아닙니다. 형식적으로만 갖춰진 조직이 아닌 정말 소프트웨어 개발조직다운 환경에서 제대로 된 개발문화 속에서 꾸준히 키워져야 "이제 소프트웨어 개발 좀 하겠구나~"하는 소리를 들을 수 있습니다. 

소프트웨어 개발조직 다운 환경과 개발문화가 구체적으로 무엇이냐고요? 짧은 글에서 다 설명하기는 정말 어렵습니다. 우리 전통문화를 잘 이해하지 못하는 사람에게 그게 뭔지 글로 설명하는 것이라고 해야 할까요?

궁금하다면 제 블로그 자체가 지속적으로 얘기하는 내용이므로 다른 글들을 읽어 보시기 바랍니다. 제 블로그를 구독하고 계신 분들은 나름대로 이해를 하고 계실 겁니다.

안타까운 것은 하드웨어와 소프트웨어의 갭이 상상이상으로 크고 삼성같은 큰 조직은 바뀌는 것이 훨씬 어렵다는 것입니다. 내부에 변화를 싫어하는 사람들이 너무 많기 때문입니다. 하지만 삼성은 이미 이전에 몇번의 변화를 통해서 지금에 이르렀기 때문에 약간의 희망을 가져봅니다. 

Why new year's resolution?

안녕하세요. 2010년 새해입니다.

모두 새해 복많이 받으세요. 

"New year's resolution" 제가 참 싫어하는 말입니다.

결심은 매 순간 할 수 있습니다. 새해라고 해서 우주적으로는 별다른 거 없습니다. 

사실 매 순간이 새로운 것이죠. 

결심할 것이 있다가도 12월에는 새해를 기해서 결심하기 위해서 미루는 경우도 봤습니다. 

그래도 외부적인 영향을 많이 받는 사람들에게는 새해라는 것이 뭔가 결심을 할 수 있게 해주는 좋은 순간인 것 같습니다. 

그래서 하는 말인데 새해도 되었는데, 각자 목표와 계획을 만들면 좋을 것 같습니다.

우리나라는 어느 회사에서나 소프트웨어 개발자로서 10년, 20년 마음껏 일할 수 있는 환경이 안되기 때문에 소프트 웨어 개발자의 길을 계속 걷고 싶다면 자신이 80%는 만들어 가야 합니다.

장기적으로는 개발자의 길을 계속 가게 해주는 회사도 찾아야 하고 소프트웨어 전문가로서의 면모도 갖춰 나가야 합니다. 목표와 계획 없이 매일 코딩과 문제 해결에만 매달리면 10년 후에는 주변 환경이 만들어주는 틀대로 자신이 변해 있는 모습을 발견하게 되고 "이건 내가 원하던게 아냐!"라고 후회하게 됩니다.

소프트웨어 개발자에게 필요한 3대 능력은 다음과 같습니다.

첫째, 소프트웨어공학지식입니다. 코딩, 설계, 분석, 형상관리, 테스트, 이슈관리, 공학관리, 방법론, 프로세스 등 소프트웨어 개발에 필요한 일반적인 지식들입니다. 

자신이 아직 코딩과 설계에만 포커스를 하고 있다면 다른 분야도 두루 알아야 합니다. 올해는 뭐를 좀더 공부해보고 경험해볼지 계획을 세워보시죠.

둘째, 산업지식(Domain Knowledge)입니다. 이거야 따로 공부하지 않아도 일하면서 계속 익히는 것이니까 별로 신경쓰지 않아도 자연스럽게 알게되죠. 소프트웨어공학적으로는 크게 중요시하지는 않지만, 일할 때는 매우 중요하기는 하죠.

세째, 영어입니다. 가장 큰 난관이죠. 개인적으로 소프트웨어 개발자가 영어를 모른다면 "태권도"를 배우면서 한국이 어떤 나라인지 모르는 것 같다고 할까요? 지금도 대부분의 자료는 영어이고 국경없는 교류가 필수적인 소프트웨어 개발 세상에서 영어를 못하면 운신의 폭이 "100분의 1"로 줄어 듭니다. 대부분의 개발자들은 영어 공부를 중도에 포기합니다. 대부분은 바빠서 또는 게을러서 입니다. 

제 경험상 맘잡고 영어 회화 공부를 시작하면 1년 정도는 나름 대화가 가능하고 3년은 되어야 상당히 유창하게 말을 할 수 있고 5년은 공부해야 다양하고 자연스러운 대화가 가능합니다. 단 거의 매일 빠짐없이 영어공부(회화)를 했을 경우입니다. 5년도 하루가 모여서 됩니다. 일단 시작해보세요. 같이 공부하는 동료를 만드는 것도 좋습니다. 공부는 재미있게 해야죠. 

10년 후의 자신의 모습을 그려보고 올해 해야할 목표와 계획들을 한번 만들어보죠.

머리속으로만 그리지 말고 종이에 적고 사람들에게 광고도 좀 하세요. 실천하기 한결 쉬워질 겁니다.

제 블로그나 책이 도움이 되길 바랍니다. 참 제 개인 블로그에서는 영어 공부도 다루고 있습니다. ^^

동종업계 취업금지 각서

개발자에게는 동종업계 취업금지라는 이상한 족쇄가 있습니다.

보통 2년 어쩔 때는 더 길기도 합니다.

입사 시에 이러한 동종업계 취업금지 각서에 사인을 하라고 하는 회사가 종종 있습니다.

물론 특정 업종에 따라서는 이러한 금지조항이 꼭 필요한 경우가 있습니다. 하지만 그렇지 않은 회사에서도 너무 광범위하게 "동종업계 취업금지"를 활용하고 있습니다. 

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

이 작은 땅덩어리에서 개발자들이 경쟁 업체에 취직을 못하게 하면 개발자는 갈 곳이 별로 없습니다.

이전 회사에서는 상당히 그럴싸한 이유를 댈 수 있습니다. 

개발자가 회사의 소스코드를 몽땅 들고 가서 경쟁회사에서 이를 그대로 사용할 수 있다는 겁니다. 이것은 범죄인데 직원이 퇴사 시 범죄를 저지를까봐 미리 방지하는 셈입니다. 실제로 이러한 걱정을 하는 회사가 꽤 많고 일부 이해도 됩니다. 

마치 지하철에서 신문을 보면 이 신문을 깔고 "대ㅂㄴ"을 볼 수 있으므로 신문을 못 보게 하는 것처럼 생각되기도 합니다.

영업직은 자신의 모든 영업라인을 끌고 이직을 해도 입사할 때 이런 서약을 하라고 하지 않습니다.

물론 개발자가 이직을 해서 기존의 소스코드를 얼마나 활용하고 참조하는지는 알 수 없습니다. 또한 자신이 개발한 일부 함수를 재활용한다고 해도 범죄라고 얘기하기가 어렵습니다. 회사에서는 나중에 문제가 되고 귀찮아지니까 이를 원천 봉쇄하겠다는 뜻이죠.

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

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

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

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

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

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

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

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

이런 사람들에는 다음과 같은 말을 해주고 싶습니다.

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

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

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

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

관리자로서는 HR이슈, 프로젝트, 인력, 비용 관리, 부서간 이슈 조정, 경영자에게 보고 등 많은 일들을 더 잘 처리하는 것이 중요합니다.

이런 현상이 벌어지는 근본적인 이유는 개발자와 관리자의 트랙이 명확하게 구분이 되어 있지 않아서입니다. 개발자라면 언젠가는 둘 중에 하나를 선택해야 합니다. 

관리자를 선택한 사람들은 일정 기간이 지나면 다시는 개발자 트랙으로 돌아오지 못합니다.

하지만 개발자 트랙에 있던 사람은 시기에 구애 받지 않고 관리자가 될 수 있습니다. 물론 관리를 잘하느냐 못하느냐는 다른 이슈입니다. 가능하다는 거죠.

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

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

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