All of Software

2009년 12월 29일 화요일

동종업계 취업금지 각서

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2009년 12월 23일 수요일

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2009년 12월 8일 화요일

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

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

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

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

회사는 외형적으로 과거와는 비교도 안되게 성장을 했지만, 창업공신들은 과거의 주먹구구 방식의 구태를 못 벗어나면서 새로운 시스템과 프로세스를 적응하지 못하는 경우가 많습니다.

회사에서 판단해야 할 중요한 기술적이면서 비즈니스적인 이슈들이 많은데도 이들은 여전히 엔지니어 마인드를 못 벗어나서 사사건건 방해가 되곤 합니다.

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

이런 결과는 개인의 성장과 회사의 성장이 조화를 이루지 못해서 발생합니다.

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

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

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

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

또한 개발자들은 자신의 자기 계발에 꾸준히 노력해야 합니다. 회사가 아무리 기회를 제공해도 본인이 노력하지 않으면 성장할 수 없습니다. 회사가 아무리 바쁘다고 매일 코딩에만 매달리다가는 몇 년이 지나서 코딩기계가 될지도 모릅니다.

여기서 자기 계발이란 개발자로서 성장하는데 필요한 모든 것을 말합니다. 새로운 Technology를 계속 배우고, 프로세스, 툴을 익히고, 소프트웨어 공학도 배우고, 영어가 필요하면 영어 공부도 해야 합니다.

오로지 코딩에만 관심 있다고 하는 개발자들이 있는데 대부분은 코딩의 의미를 너무 광범위하게 생각해서 발생하는 오해이고 대부분, 설계/분석 등 개발에 다양한 분야에 관심이 있는 경우가 대부분입니다.

너무 바빠서 자기 계발을 할 시간이 없다고 하면 일욕심이 너무 많은 개발자일 겁니다. 일을 조금 천천히 하더라도 자기 계발할 시간을 가지는 것이 본인과 회사 모두를 위해서 좋은 겁니다.

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

2009년 11월 29일 일요일

뛰어난 개발자는 길러지는 것

이전 글("뛰어난 개발자는 타고나는 것")에서 논리적인 두뇌가 개발자의 Performance에 미치는 영향을 알아보았습니다. 이 글은 원래 상반된 의견을 가진 두 글로 계획된 것인데, 이전 글에 대해서 많이들 관심을 가지고 의견을 주셔서 두번째 글을 바로 올립니다.

이전 글을 본 독자분들은 자신의 경험에 비추어서 위화감을 느끼시는 것 같습니다. 인정하기 싫은 현실일 수도 있습니다. 사실 이전 글은 사실 경영자가 봐야할 글입니다. 자신을 똑똑한 개발자와 반대편에 두고 무조건 거부감을 둘 필요는 없습니다.

이런 형태의 글은 옛날에도 올렸었죠. ^^

2009/09/11 - [사람과 기술] - 부지런한 개발자가 되라
2009/08/28 - [사람과 기술] - 게으른 개발자가 되라!

이번 글은 개발자를 위한 글입니다.

Microsoft등의 유수의 소프트웨어 회사들은 상위 0.01% 또는 0.001% 두뇌를 확보하기 위해서 학과를 가지 않고 천문학과, 물리학과 등에서 천재들을 확보하고 있습니다. 그리고 학생 중에서도 소프트웨어 개발에 특별한 재능을 보이는 개발자 후보를 싹쓸이 하기 위해서 엄청난 노력을 기울입니다.

이러한 활동은 국내 대부분의 소프트웨어 회사들은 먼나라 얘기일 뿐입니다. 또한, 이러한 사람들이 개발자가 된다고 해도 우리나라 보통의 소프트웨어 회사에서 진짜 훌륭한 개발자로 성장하기는 어려울 것 같습니다.

똑똑하고 뛰어난 논리 회로를 지닌 사람이 뛰어난 개발자가 될 가능성이 확실히 높기는 하지만, 개발자가 몸담은 환경에 따라서 훌륭한 개발자가 될 수도 있고, 천덕꾸리기가 될 수도 있습니다.

또한 그런 특별한 논리 회로를 지닌 사람만이 할 수 있는 일은 어렵기는 하지만 그리 많지는 않습니다. 대부분의 개발업무는 보통의 두뇌를 가진 사람들이 수행합니다. 물론 이들도 일반인과 비교하면 비교도 안될 정도로 논리적인 두뇌를 가지고 있습니다.

하지만 훌륭한 개발자가 되는 것은 두뇌의 성능에 의해서 결정되지 않습니다. 상위 0.1%의 두뇌를 가지고 있다고 하더라도 훌륭한 개발자가 되는데 크게 유리하지도 않습니다. 훌륭한 개발자는 어떻게 경험과 경력을 쌓아가느냐에 달렸습니다.

제가 두 글에서 서로 다른 시각을 두는 것은 두뇌에서 나오는 개발자의 Performance와 실제 개발의 전반적인 Performance의 차이를 보여주기 위함입니다. 어차피 두뇌는 거의 정해진 것입니다. 하지만 개발자가 어떠한 환경에서 어떤 방향으로 성장하느냐에 따라서 10년 후의 Performance와 회사에서의 기여도는 엄청난 차이를 가져옵니다. 이것은 개발자 혼자만의 노력으로 가능한 것은 아니고 회사에서 환경을 제공해 줘야 합니다.

그럼, 뛰어난 개발자로 길러지는 방법에 대해서 알아보겠습니다.

첫째, 먼저 자신을 잘 알아야 합니다.

모든 사람은 장점과 단점이 있습니다. 두뇌는 뛰어나나 표현을 못하고 글을 잘 못쓰는 사람이 있는가 하면 두뇌는 보통이지만 인화력이 뛰어나고 남을 잘 이해해주는 사람도 있습니다. 누구는 발표를 잘하고 누구는 설득을 잘합니다. 누구는 끈기는 없지만 아이디어는 끝내줍니다. 또 누구는 신제품 가지고 놀기를 좋아합니다. 자신의 능력과 취향을 잘 알아야 합니다. 그래야 개발의 수많은 분야에서 어느 분야로 성장할지 결정할 수 있습니다. 소프트웨어 개발자 외에도 가능한 다른 분야는 Project Manager, Product Marketing, QA Engineer, Build and Release, Technical Support 등 다양한 분야가 있습니다.

둘째, 자신의 전문 분야에서는 최고가 되어야 합니다.

자신의 분야에서 최고가 된다는 마인드로 주변의 누구보다도 자신의 분야에서는 많은 지식과 경험이 있어야 합니다. 그렇지 않고 일반지식만 가지고 있다면 소프트웨어 개발자로는 부족하죠. 남들보다 특출난 한 분야가 꼭 있어야 합니다. 모든 분야에서 모두 최고가 된다는 것은 불가능하기 때문에 자신만의 분야를 찾는 것도 중요합니다.

셋째, 넓은 지식과 경험을 가져야 합니다.

항상 코딩에만 집중하는 개발자는 넓은 지식을 가지기 어렵습니다. 개발자는 자신만의 분야 뿐만 아니라 다양한 분야의 지식을 섬렵해야 합니다. 그러기 위해서 가장 좋은 방법은 Peer review입니다. 개발자는 자신의 프로젝트만 할 것이 아니라 다른 팀의 여러 프로젝트의 Review에 꾸준히 참석해서 도움을 주는 것 뿐만 아니라 자신의 경험과 지식도 넓혀야 합니다. Review가 아니면 그렇게 많은 지식을 넓힐 기회가 별로 없습니다. 또한 다양한 Conference에도 꾸준히 참석해서 Technology Trend도 따라가야 하며 인맥도 유지해야 합니다. 많은 경력을 가진 개발자들은 자신의 개발업무에만 치중하는 것이 아니라 회사의 중용한 기술적을 결정에 참여를 해야 하기 때문에 넓은 지식을 자지고 있지 않으면 안됩니다.

또한 소프트웨어공한의 다양한 분야에 대한 전반적인 경험과 지식도 같이 가지고 있습니다. 그렇지 않고 매일 코딩만 하는 개발자에게 어떻게 높은 연봉을 줄 수 있을까요?

넷째, 긍정적인 마인드입니다.

회사에 긍정적이고, 팀에 긍정적이고, 자신에게 긍정적이어야 합니다. 그렇지 않은 개발자는 분위기가 음산하고 같이 일하기 거북합니다.

회사의 정책에 호응하고 긍정적이지 못한 개발자는 항상 불만이고 반대합니다. 이러한 패턴은 바뀌지 않고 언젠가는 회사의 발등을 찍을지 모릅니다. 실력이 뛰어나도 이런 개발자는 빨리 내보내는 것이 좋습니다.

팀에 긍정적이지 못한 개발자는 팀웍을 무시하고 자신만을 위해서 일합니다. 이러한 개발자는 다른 개발자들에게 피해를 끼치며 마이너스 생산성을 가집니다.

자신에게 긍정적이지 못한 개발자는 자신감이 없으며 훌륭한 개발자로 성장하기 어렵습니다.

또한 이런 개인의 기본 자세는 쉽게 바뀌지 않습니다. 따라서 항상 긍정적인 마인드를 유지하기 위해서 꾸준히 노력하고 자신을 설득해야 합니다. 천성이 긍정적인 사람은 저절로 되는 일이지만 그렇지 않은 사람은 노력을 많이 해야 합니다. 부정적인 마인드는 면접시 탈락의 큰 요소도 되기도 합니다.

이 중에서 대부분은 개발자 스스로 노력해서 가능한 것들입니다. 하지만 셋째는 개발자 혼자의 노력만으로는 어렵습니다. 회사에서 그렇게 할 수 있도록 환경을 조성하고 지원을 해줘야 합니다. 그래서 좋은 환경에서 일하는 것이 중요하죠. 지금의 회사가 연봉은 괜찮지만, 개발자로서 성장할 수 있는 좋은 환경이 아니라면 오래 몸담는 것이 오히려 미래에 내 몸값을 떨어뜨리는 일일 수도 있습니다. 불행히 우리나라에는 좋은 환경의 소프트웨어 회사가 적은 편이기는 하지만, 그 중에서도 상대적으로 좋은 환경을 찾는 노력은 필요합니다. 저의 Mission 중의 하나가 그런 환경을 가진 소프트웨어 회사를 많이 만드는 겁니다.

머리는 똑똑하지만, 같이 일하기 어려운 천덕꾸리기 개발자보다는 경험과 지식 및 인성이 두루 균형 잡힌 개발자가 더 가치 있고 회사에 더 필요합니다. 미래의 나는 내가 만들어 가는 겁니다.

2009년 11월 27일 금요일

뛰어난 개발자는 타고 나는 것

1. 처음부터 똑똑한 개발자를 뽑아라.
2. 똑똑하지 않는 개발자를 채용해 놓고 똑똑한 개발자로 바꾸려고 시도하지 마라.
3. 특출나게 똑똑하지 않은 개발자도 다 적절한 역할이 있다.
4. 그 역할을 찾아서 제 역할을 하도록 하라. 각 개발자에게 알맞은 역할을 찾아 주고 제대로 일하게 하는 것만으로도 얼마나 힘든지 아는가?

소프트웨어 회사 경영자와 관리자에게 전하는 말입니다.

요즘은 뛰어난 개발자를 구별하기 정말 어렵습니다. Labor market에는 실업자가 넘쳐나지만 뛰어난 개발자는 눈을 씻고 찾아봐도 볼 수가 없습니다. 뛰어난 개발자는 이직을 잘하지 않고 노출이 잘 안되기 때문입니다.

그래서 적당한 개발자, 또는 해당 분야에 경험이 좀 있는 정도의 개발자를 그냥 채용하는 경우가 많습니다. 하지만, 이런 개발자들은 뛰어난 개발자를 대신할 수는 없습니다.
뛰어난 개발자는 타고납니다.

뛰어난 개발자의 필수 조건인 논리력은 태어날 때 이미 50%는 결정되고 교육과정을 거치면서 나머지 49%가 결정됩니다. 사회에 나와서 아무리 노력을 해도 이미 완성된 두뇌는 별로 바뀌지 않습니다. 경험이 쌓이면서 좀더 지식이 풍부해지고 노련해질 뿐입니다.

요즘의 개발환경은 뛰어난 개발자와 그저 그런 개발자를 구별하기 점점 어렵게 만들고 있습니다.

뛰어난 개발자들은 정말 복잡한 알고리즘을 몇 시간 만에 구현해 낼 수 있지만, 그저 그런 개발자들은 몇 달을 줘도 불가능합니다. 하지만, 요즘은 그런 알고리즘을 구현하지 않아도 개발이 가능한 분야가 얼마든지 있고, 일반인 수준의 논리력만 가지고도 개발자로서 일하고 있는 사람들이 넘쳐납니다.

하지만, 이런 그저 그런 개발자들만 잔뜩 모아 놓은 회사는 그저 그런 회사일 수 밖에 없습니다.

물론, 소프트웨어 회사가 돌아가려면 이런 개발자들도 필요합니다. 그런데, 뛰어난 개발자와 그저 그런 개발자를 구분하지 못하는 회사는 챔피언이 될 수 있는 선수를 후보로 썩히는 것과 같은 행동을 합니다.

일단 수학을 잘한다면 뛰어난 개발자가 될 가능성이 아주 높습니다. 물론 수학을 잘하는 모든 사람이 뛰어난 개발자가 될 수 있는 것은 아니지만, 하나의 중요한 요소인 것은 사실입니다. 하지만 수학 실력은 아주 형편없는데 뛰어난 개발자가 될 가능성은 별로 높지 않습니다. 애초부터 복잡한 논리를 처리할 수 있는 두뇌를 가지고 있지 않기 때문입니다.

경력직 개발자중에서 똑똑한 개발자를 찾기 어려우면 아직 세상 물정을 잘 모른 대학생들 중에서 찾는 것이 좋습니다. 참고로 저도 대학교 다닐 때부터 회사 생활을 했었습니다.

뛰어난 개발자들은 대학 재학 중에도 이미 뛰어난 실력을 보입니다. 대학에서 적당히 학점 따서 졸업하는 학생들보다 학점은 낮을 수 있어도 확실히 실력은 뛰어날 수 있습니다. 하지만, 요즘 같이 치열한 취업 환경에서는 학점에서 탈락해서 취업이 어려울 수 있습니다. 이런 학생들을 찾아서 회사로 끌어들이는 것이 관리자들이 해야 할 중에서 가장 중요한 일이죠.

요즘은 보통의 머리를 가진 사람도 개발을 할 수 있는 세상이 되었습니다.

그렇다고 보통이나 그 이하의 개발자들만 뭉쳐 놓고 훌륭한 제품을 만들 수 있을 것으로 착각하면 안됩니다. 뛰어난 개발자 채용에 회사의 사활을 걸어야 합니다. 관리자나 HR부서에서는 채용 시즌이나 결원이 생길 때만 잠시 채용에 관심을 둬서는 안됩니다. 1년 내내 채용에 온 힘을 쏟아야 합니다. 그렇다고 미련한 방법도 소용 없습니다. 참신한 방법들을 만이 연구해야죠.

언젠가 똑똑한 개발자들이 스스로 몰려가는 SW회사가 우리나라에고 생기면 좋겠습니다.

PS) 똑똑하다는 것이 개발자에게 필요한 오직 한가지 조건은 아닙니다. 즉, 똑똑하기만 하다고 최고는 아니죠. 특히 인성과 긍정적인 자세가 중하죠. 이런 부분은 나중에 기회가 되면 풀어 보겠습니다. 또한 다양한 채용 방법에 대해서도 글을 올려 볼 계획입니다.

2009년 11월 23일 월요일

아이디어 보상제의 함정

소프트웨어 회사에서 참신한 아이디어가 생존에 필수인 것은 당연합니다.

그래서 소프트웨어 회사는 좋은 아이디어를 뽑아 내기 위해 갖은 노력을 합니다.

하지만 이는 그렇게 쉬운 일이 아닙니다.

가끔 아이디어에 대해서 돈으로 보상하는 정책을 시행하는 회사를 보게 됩니다.

그런데, 별로 큰 효과를 보지 못하는 경우가 많습니다. 오히려 역효과를 일으킬 수가 있습니다.

개발자는 원래 아이디어가 넘치는 사람들입니다. 또한 아이디어 내는 것을 좋아하죠.

이를 보상이라는 것으로 보답을 하기 시작하면 자칫 아이디어 내는 것을 더 방해할 수도 있습니다.

보상을 위해 아이디어를 내놓는다는 도덕적인 결함이 이를 가로막습니다.

아이디어에 대한 보상은 도덕적으로 상처가 되지 않을 만큼 작다면 문제가 되지 않습니다.

즉, 새로운 아이디어를 낸 직원에게 5,000원짜리 도서상품권은 별 문제가 되지 않습니다.

하지만, 아이디어 10개를 내면 백만원을 주고 상품화되면 매출의 몇%를 준다는 식의 보상은 그럴 듯 해 보여도 도적적인 압박이 개발자들의 두뇌를 억눌러서 아이디어가 나오지 못하도록 방해하기도 합니다.

개발자에 대한 최대의 보상은 자신들이 낸 아이디어로 프로젝트를 할 수 있게 해주는 겁니다. 물론 기존의 업무는 그대로 하고 이것도 하라는 식으로는 곤란합니다. 또 나오는 아이디어마다 모두 만들어 보자는 식도 곤란합니다. 아이디어는 서로 활발히 의논하고 발전시킬 수 있는 분위기와 환경이 되어야 하면 회사의 지원도 필요합니다. 이렇게 도출된 아이디어는 아이디어 발의자의 이름이 따라다니고 개발자에게 이 프로젝트에서 활약할 기회를 주는 것으로 충분한 보상이 되기도 합니다.

또한, 실제 대단한 성과에 대한 보상은 추후 감사의 의미로 지급할 수 있습니다. 하지만 보상을 유인책으로 쓰는 것은 부작용이 더 클 수도 있습니다. 따라서 진정한 감사 의미의 보상이 아니라면 서로에게 불편하며 큰 부작용 및 송사에 휘말릴 수도 있습니다.

정말 끝내주는 아이디어가 있어서 회사에 바치기 아까우면 아이디어를 가지고 퇴사를 하십시오. 그리고 직접 회사를 설립해서 개발을 해 보세요. 물론 실패할 가능성은 99%입니다. 하지만 성공하면 대박이겠죠. 물론 기존의 회사에서 시도하더라도 성공할 가능성은 10%가 안될 겁니다.

지금의 회사에서 개발자가 가진 아이디어를 펼치는 것은 개발자에게는 좋은 기회가 될 것이고, 경력에도 긍정적인 영향을 끼칩니다. 수동적인 프로젝트 참여보다 본인의 아이디어를 기반으로 주도적으로 참여한 경력은 채용에서 훨씬 긍정적인 영향을 끼칩니다. 또한 개발자들은 이런 식으로 일을 즐기고 이렇게 일할 때 가장 퍼포먼스도 높습니다. 물론 매일 SI나 용역만 하는 회사는 이런 환경을 조성하기는 어렵겠죠. 그래서 저는 SI나 용역만 하는 회사에서 일하고 싶은 생각은 별로 없습니다.

소프트웨어 업계에서는 아이디어가 충만하고 현실화 할 수 있는 환경이 잘 되어 있는 회사가 성공할 가능성이 높습니다. 개발자에게는 돈으로 보상하는 것보다 기회와 업적으로 보상하는 것이 더 좋습니다. 또한 보상제보다는 아이디어가 샘솟을 수 있는 활기 넘치는 환경이 더 중요합니다.

2009년 11월 13일 금요일

SRS에 대한 인식의 변화

그 동안 본 블로그를 통해서 소프트웨어 개발에서 SRS(Software Requirements Specification)가 얼마나 중요한 역할을 하는지에 대해서 수 차례 역설한 적이 있습니다.

지금까지는 SRS라는 용어조차 한번도 들어본 적이 없는 소프트웨어 개발자나 관련자들이 많았었습니다. 하지만 이제는 조금씩 SRS라는 용어에 대해서 알기 시작하는 것 같습니다. 또 소프트웨어 개발에서 있어서 요구분석이 왜 중요한지에 대해서 조금씩 인식해가는 것 같습니다.

그 예로 최근에는 정부에서도 소프트웨어 기업들의 경쟁력 강화, 특히 해외 시장 진출 시 경쟁력 확보를 위해서SRS 작성을 중요한 요소로 보고 정부 지원 과제에 포함을 하고 있습니다.

이러한 과제에 평가위원으로 참석을 해보니 아직은 많은 소프트웨어 회사들이 분석능력을 제대로 갖추고 있고, SRS를 잘 쓸 수 있는 역량을 갖췄다고 보기는 어렵습니다. 하지만 제대로 된 소프트웨어를 짧은 시간에 개발하기 위해서는 분석을 제대로 하여 SRS를 작성하고 SDP를 만들어야 한다는 것을 인지한 것만으로도 큰 변화라고 볼 수 있습니다. 필요성을 인식하는 것이야 말로 변화가 가능하게 하는 원동력입니다.

다만, 문제는 분석을 잘해야 한다는 것, 즉 SRS를 잘 써야 한다는 것을 인식하고도 SRS를 잘 적는 방법을 배울 곳이 없다는 것입니다. Software 선진국에서는 수십년 간 개발자들이 SRS를 써 왔기 때문에 서로 Template는 조금씩 달라도 개발자로서 일을 하는 동안에 계속 접해 왔고, 써왔기 때문에 따로 배우고 말 것도 없이 SRS를 쓸 줄 알게 되었습니다. 물론 모든 개발자가 SRS를 다 제대로 쓸 줄 아는 것도 아니고 그럴 필요도 없지만, 소프트웨어 프로젝트를 시작할 때 누군가가 SRS를 작성하고 관련자들과 리뷰를 하는데 전혀 문제가 없습니다.

하지만 이제 시작인 우리나라는 배울 곳도 없고, 스스로 연구하고 공부해서 작성하기에는 요구분석이라는 분야 자체가 너무 어렵습니다. 그 동안 여러 회사에서 스스로 작성했다고 하는 SRS를 분석해보면 합격점을 줄 수 있는 것은 거의 전무했다고 해도 과언이 아닙니다. 그렇다고 미국 회사에 가서 몇 년 배우고 오기도 어려운 실정입니다. 또, 국내에서는 학교나 학원에서 배울 수 있는 환경도 되지 않습니다. 그렇게 배운다고 해도 몇몇 기법만 배우고 핵심은 파악하지도 못하게 됩니다. 그 이유가 대부분의 교수나 강사가 소프트웨어 프로젝트에서 실제로 SRS를 써본적이 거의 없이 이론적으로 배운 정도이기 때문입니다. 실제 프로젝트에서 SRS를 제대로 써본 경험을 많이 가지고 있는 경험자와 같이 SRS를 써보면서 꾸준히 배워 나가는 것이 가장 적절한 방법입니다.

물론 몇몇 개발 방법론에서는 SRS를 작성하지 않습니다. 하지만 이러한 방법론에서도 스펙이 필요 없다고 하는 것은 아닙니다. 다만 스펙을 바라보는 관점과 적는 방법이 다를 뿐입니다. 따라서 스펙의 개념을 정확하게 알고 SRS를 잘 작성할 줄 아는 개발자들이라면 스펙의 형태가 테스트케이스가 되든 어떤 다른 형태가 되든 문제는 없습니다. 즉, 소프트웨어 분석역량이 문제입니다.

분석역량의 부족은 부실한 스펙문서를 만들게 되고 이는 설계, 구현 기간에 많은 혼란과 재작업을 초래하고 출시 후에도 유지보수 비용을 크게 증가시킵니다. 그 동안 우물 안 개구리처럼 내수시장에서 소수의 개발자를 데리고 고객이 원하는 대로 뚝딱 만들어서 장사를 했는데, 소프트웨어 볼륨이 커지고 해외 시장에 진출을 하려니까 딱 벽에 부딪히는 겁니다. 이 과정에서 무리하게 해외 진출을 추진하다가 유명을 달리한 회사들이 상당히 많습니다. 그렇다고 세계 시장의 1%밖에 안되는 국내 SW시장에서만 놀기에는 국내 시장은 너무나 작습니다. 왠만큼 성장한 회사라면 해외 시장 진출의 유혹을 떨처버리기 어렵습니다.

물론 SRS, 스펙, 분석능력이 이 모든 것을 해결해주지는 않습니다. 하지만, 가장 중요하고 핵심적인 요소라 확신합니다. 이는 저만의 주장이 아니고 제가 존경하는 수많은 실전 소프트웨어 전문가들의 주장이기도 합니다. 그러한 맥락으로 앞으로 SRS, 스펙, 분석역량 향상에 대한 글을 종종 올려보려고 합니다. 블로그를 통한 지식전달이 얼마나 효과가 있겠는지 의문은 들지만, 필요성에 대한 인식만 생기더라도 글을 올린 보람을 있을 것으로 생각됩니다.

이와 관련된 궁금증, 의견, 경험, 고민거리, 정보, 아이디어 등 어떤 것이라도 같이 교환하고 싶습니다. 댓글이나 방명록, 메일로 얼마든지 보내주세요. 제가 해결해드릴 수 있는 것은 해결해드리죠.

그리고 교육을 받고 싶으신 개발자나 회사라면 연락 주시기 바랍니다. 제가 여건이 되는 한도내에서는 많은 소프트웨어 개발자들에게 전달하고 싶습니다.

suvery button