소스코드관리시스템 사용도 2차 조사 결과

2009년 2월에 이와 동일한 조사를 한 적이 있었습니다.

2009/02/22 - [기반시스템/소스코드관리] - 소스코드 관리 방법 조사 결과

그때도 약 20일간 조사를 했었고, 이번에도 마찬가지로 20일간 조사를 했습니다. 

2009년에는 109명이 참여를 했는데 이번에는 370명이 넘는 인원이 참여를 해서 더 정확한 결과가 나왔을 것으로 기대합니다.

이번 설문의 핵심은 소스코드관리시스템을 사용하는지? 사용하지 않는지? 또, 사용한다면 어떤 시스템을 사용하고 있는지를 알아내는 것이었습니다.

2009년초와 비교를 해보면 꽤 많은 변화가 있었음을 알 수 있습니다.

가장 큰 변화를 요약하면 다음과 같습니다.

• 소스코드관리시스템 사용률의 향상
• CVS, VSS의 몰락
• Git의 약진
• Subversion(SVN)의 꾸준한 증가

그럼 조사 결과를 살펴 보도록 하겠습니다.

소스코드관리시스템을 사용하고 있는 그룹에서만 통계를 내보면 여전히 Subversion이 압도적인 1위를 차지하고 있고, CVS와 VSS의 사용률이 많이 떨어지면서 Git가 크게 치고 나온 것을 알 수 있습니다. Mercurial의 가세까지 보면 분산소스코드관리시스템에 대한 관심이 많이 높아졌음을 알 수 있습니다.

또한 더 다양한 소스코드관리시스템의 사용을 시도해보고 있는 것이 눈에 띕니다.

소스코드관리시스템을 사용하는 비율도 많이 높아졌습니다. 그동안 책이나 블로그를 통해서 소스코드관리시스템을 사용하지 않고 소프트웨어를 개발하는 것은 기적에 가깝다고 하였는데, 이는 긍정적인 신호로 생각됩니다.

물론 소스코드관리시스템을 사용하고 있는 83%에서도 제대로 사용하고 있는 비율은 극히 낮습니다. 그래도 사용하기 시작한 것만 해도 큰 의미라고 생각됩니다.

많은 발전이 있었음에도 여전히 소스코드관리시스템을 사용하지 않는 개발자나 회사가 많이 있고 그 속에서의 비율은 큰 차이가 없어 보입니다.

소스코드관리시스템을 100%의 개발자들이 사용하고, 또한 제대로 사용할 수 있는 날까지 계속 노력을 합시다. 

저는 수많은 회사에서 소프트웨어 공학/경영 컨설팅을 진행하면서 소스코드관리시스템이 개발 문화를 긍정적으로 상당히 많이 바꾸는 것을 보아 왔습니다. 소스코드관리시스템 없이 소프트웨어를 개발한다는 것은 남들은 총들고 전쟁할 때 돌멩이 들고 싸우겠다는 것과 같습니다. 일단 무기가 있어야 싸움을 시작할 수 있을 것 아닙니까?

그리고 나서야 기술이나 전략이 의미가 있어집니다. 돌멩이 들고 싸우면서 전략을 논할 수는 없습니다.

물론 이와 같이 꼭 필요한 무기들은 몇가지 있습니다. 이런한 것들이 기본은 되어야 글로벌 소프트웨어 회사들과 경쟁이란 것을 생각해 볼 수 있습니다. 그렇다고 물론 경쟁이 된다는 것이 아닙니다. 이제 시작할 수 있다는 것 뿐입니다. 

그리고 나면 진짜 개발 실력, 전략, 마케팅이 필요한 때입니다. 하지만 국내 대부분의 소프트웨어 회사들은 아직 글로벌 경쟁은 생각하지도 못할 수준인데 단순히 요소기술만 가지고 경쟁을 할 수 있다고 착각하는 경우가 많습니다.

이번 조사 결과를 보면서 점점 긍정적인 신호들을 느낍니다. 앞으로 좀 더 깊은 내용들도 풀어 나가도 될 것 같습니다.

조사에 협조해주신 모든 분들께 감사드립니다.

2차 소스코드관리시스템 사용도 조사 Poll

약 2년전쯤 제 블로그에서 어떤 소스코드관리시스템을 사용하고 있는지 조사를 한 적이 있습니다. 

시간도 꽤 흘러서 그동안 어떤한 변화가 있었는지 알고 싶어집니다. 특히 그동안 소스코드관리시스템을 사용하는 비율이 어느정도 높아졌는지가 가장 궁금하더군요. 또한 최근에 분산소스코드관리시스템에 대한 관심의 증가가 실제로 사용도에 영향을 주는지도 궁금합니다.

설문은 간단하게 사용하시는 소스코드관리시스템을 체크하면 됩니다. 만약에 보기에 없다면 Other 항목에 직접 적어 넣으시면 됩니다.

많은 참여 부탁합니다.

소스코드는 어디에 보관하세요? (최신 소스코드의 기준이 되는 저장 장소를 선택해주세요. 다중 선택 가능)

SubversionCVSVisual SourceSafeTeam Foundation ServerIBM Rational ClearCaseRCSGitMercurialSVKBazaarBitKeeperFileServer에 보관개인 PC에 보관공용개발서버에 보관실운영서버에 보관Other:

VoteView ResultsPolldaddy.com

 

문서화 딜레마

우리나라 소프트웨어 회사 중에서 문서를 제대로 작성하고 있는 곳을 찾기란 그리 쉬운 일이 아닙니다.

제대로 작성한다는 의미는 꼭 필요한 만큼 적절히 효과적으로 작성하는 것입니다.

대부분의 소프트웨어 회사는 변변한 문서 하나 없이 개발을 하고 있고 반대로 소수의 회사는 불필요한 문서를 잔뜩 만들어서 오히려 효율성을 떨어뜨리고 있습니다.

물론 제대로 하고 있는 회사도 있지만 그 수는 극히 적습니다.

대부분의 여러분들도 겪은 현상이거나 앞으로 겪을 것입니다. 변변한 문서하나 제대로 만들지 않고 소프트웨어를 개발하고 있는 회사는 구멍가게 이상의 규모로 성장하기 어렵습니다. 회사의 규모가 커지면서 문서가 부족하면 커뮤니케이션 비용이 기하급수로 증가하기 시작합니다. 회사가 작았을 때 숨어있던 문제들이 마구 터져 나오기 시작합니다.

이미 문제가 되기 시작한 이후에 문서를 만들어보자는 결심을 하기도 합니다. 하지만 이미 제품을 다 개발한 이후에 유지보수하는 제품의 문서를 제대로 만드는 것은 거의 불가능합니다.

문서의 주목적은 소프트웨어를 제대로 개발하기 위한 것이지 유지보수를 위한 것이 아닙니다. 유지보수 단계에서 문서를 만들면 문서에 많은 내용이 빠지게 되고 의욕도 떨어지게 됩니다.

하지만 문제는 또 다른 곳에 있습니다. 그동안 제대로 문서를 만들지 않고 개발을 해온 개발자들이 문서를 만들자고 결심만 했다고 해서 문서를 작성하는 실력이 갑자기 생기지는 않습니다.

즉, 문서를 만드는 실력이 부족하다는 겁니다.

본인들은 문서를 잘 작성할 줄 아는데 바빠서 만들지 못한다고 합니다. 그래서 시간만 있다면 문서를 언제든지 만들 수 있다고 합니다. 이렇게 말하는 것자체가 문서를 제대로 만들어 본적도 없고 문서를 만들지도 모른다는 반증입니다. 왜냐하면 바쁠 수록 문서를 적절히 잘 만들어야 프로젝트 시간이 단축되기 때문입니다.

그러다보니 제대로 된 문서도 없이 유지보수가 뒤죽박죽이 되어서 항상 고참 개발자들이 유지보수에 매달려야 해서 계속 바쁘게 되고 그러다보니 문서를 제대로 만드는 실력을 향상할 기회는 또 없게 됩니다. 새로운 프로젝트를 시작해도 또 과거의 방식으로 문서도 제대로 없이 개발을 하게 됩니다.

개발자들이 코딩을 잘하는 이유는 수년에 결쳐서 코딩을 계속 해 왔기 때문입니다. 철저히 훈련이 잘 되어 있습니다. 다들 실력차이는 나지만 코딩을 못하는 개발자는 개발자도 아니죠. 

그렇듯 문서도 계속 작성을 해봐야 잘하게 됩니다. 처음부터 기가막히게 멋진 문서를 만들 필요는 없습니다. 항상 기록을 남기는 습관을 들이는 것도 문서를 잘 작성하는 실력을 키우는데 좋은 도움이 됩니다.

물론 프로젝트에서 필요한 문서는 단순히 글을 잘 작성한다고 되는 것도 아닙니다. 하지만 글을 쓰는 습관이 출발점입니다.  그리고 프로젝트에서 필요한 문서는 원래 선배들이 제대로 작성을 해 왔다면 문서를 리뷰할 때 참석해서 문서 작성 방법을 배울 수 있습니다. 하지만 안타깝게도 선배에서 문서 작성법을 배울 수 있는 회사는 우리나라에 그렇게 많지 않습니다. 대부분은 스스로 해 나가야 합니다. 이에 관련된 책들의 도움을 받는 것도 방법 중 하나 입니다.

명심할 것은 욕심을 부리지 않는 것입니다. 너무 많은 내용을 완벽하게 적으려고 하면 오히려 금방 질려서 포기하게 됩니다. 또한 바쁘니까 나중에 몰아서 만든다는 생각도 버려야 합니다. 문서는 지금 이순간이 아니면 만들 수 없습니다.  지금 필요한 만큼만 적당히 적게 만들어야 합니다.

내가 지금 하고 있는 일의 가격

개발자 여러분... 

아침에 출근하셔서 여러분들이 하루종일 일하는 업무의 가격을 생각해보신 적이 있으신가요?

이것을 여러분의 "하루의 부가가치"로 생각을 하죠. 

여러분의 연봉은 "하루의 부가가치" x "일년동안 일한 날"에서 회사에서 여러분에게 사용한 비용을 제하면 됩니다.

대기업은 보통 60~70%를 비용으로 제하면 되고, 중소기업들은 30~50%정도의 비용이 듭니다.

여러분은 자신이 만들어 내는 부가가치에 비해서 높은 연봉을 받고 있나요? 낮은 연봉을 받고 있나요?

회사입장에서는 연봉보다 높은 부가가치가 있는 개발자를 더 많이 보유하기를 원하고 있습니다.

물론 이보다 좀더 복잡하기는 합니다만 일단 간단히 생각해보죠.

여기서 문제는 "하루의 부가가치"가 얼마나 되는지 측정하기 어렵다는 겁니다. 특히 여러분 스스로는 자신이 매우 가치있는 일을 하고 있다고 생각하지만, 다른 사람들의 시각으로는 그렇지 않을 수 있습니다.

모두들 알고 계시듯이 모든 재화의 가격은 시장의 원리에 의해서 결정됩니다.

수요가 많고 공급이 적으면 가격이 올라가고, 공급이 넘치면 가격은 떨어지게 됩니다.

여기에 개발자들이 높은 연봉을 받는 두가지 방법이 있습니다.

첫째, 부가가치를 높여서 높은 연봉을 받는 개발자

즉, 회사에 돈을 많이 벌어다 주고 미래에도 더 많은 돈을 벌어다 줄 개발자입니다.

이런 개발자들의 특징은 다음과 같습니다.

• 자신의 경력에 알맞는 일을 수행한다. 즉, 고참이 되어서도 맨날 코딩에만 매달리는 것이 아니고 설계, 요구사항 분석에 집중하며 프로젝트를 이끈다.
• 문서화와 리뷰를 잘하여 지식의 공유를 원활하게 하여 모든 개발자들이 서로 향상되는데 기여한다.
• 커뮤니케이션이 능통하여 복잡한 이슈들을 잘 해결한다.
• 회사의 중요한 기술적인 의사결정에 중요한 역할을 하여 회사의 기술 방향을 결정하여 회사가 기술적으로 올바른 길을 가도록 기여한다.

둘째, 자신이 없으면 회사에 손해를 끼치게 해서 높은 연봉을 받는 개발자

현재는 돈을 많이 벌어다 주는 개발자들이라도 곧 손해를 끼치게 하는 개발자들이 수두룩합니다. 

이런 개발자들의 특징은 다음과 같습니다.

• 항상 바쁘다는 핑계로 문서도 만들지 않고 프로세스를 지키지 않으며 자신만 알 수 있는 코드를 마구 쏟아 낸다.
• 후배들을 적극적으로 양성하기 않고 여전히 본인이 가장 많은 코딩을 한다. 막상 후배들을 시킬려고 해도 가르키기가 어렵고 본인이 제일 바쁘다.
• 회사의 개혁 시도를 방해하고 항상 본인은 열외라고 생각한다.

결론은 자신의 연봉에 걸맞는 부가가치가 높은 일을 해야 합니다.

소프트웨어 프로젝트에서 어려운 업무일수록 비싼 일입니다. 물론 모든 업무는 가치가 있고 꼭 해야 하는 일입니다. 하지만 이제 대학을 갓 졸업한 신입사원도 할 수 있는 일을 연봉을 3~4배나 많이 받는 개발자가 하고 있다면 연봉이 아까울 것입니다. 물론 그러한 일도 신입사원보다 2~3배 잘하기는 할 겁니다. 하지만 프로젝트에는 신입사원은 절대로 할 수 없는 어려운 일이 수두룩 합니다.

개발자들이 하는 업무를 크게 나누어서 간단히 비교를 하면 다음과 같습니다.

Coding < Low level design < High level design < Spec

코딩에서 있어서는 신입사원보다 크게 잘할 것도 없지만, 설계나 스펙은 수십배, 수백배 잘할 수 있는 분야입니다. 코딩도 그렇다고 생각하는 사람들은 코딩에 설계와 스펙을 짬뽕해서 생각하고 있는 것일 가능성이 매우 높습니다.

이외에 개발자는 잘하기 어려운 전문적이거나 매우 귀찮은 일을 개발자가 하는 경우도 있습니다. 

QA(Test), Project Management, B/R 등이 여기에 포함됩니다.

자신이 첫번째 개발자에 해당하는지 두번째 개발자에 해당하는지 잘 생각해봅시다.

두번째 개발자들이 주도하는 회사의 미래는 뻔합니다. 언제 망하는지는 시간 문제일 뿐입니다. 이런 회사들은 보통 한번의 성장을 이룬 다음에 첫번째 또는 두번째 변곡점에서 보통 망하게 됩니다. 즉, 회사가 성장하는 것이 망해하고 있는 것과 거의 같은 의미입니다. 이런 경우 성장하지 않거나 느리게 성장하는 것이 차라리 오래 살아 남는 길입니다.

주변에서 크게 성장한 다음에 망해간 수많은 소프트웨어 회사들을 생각해보세요. 이러한 특징들이 고스란히 드러납니다. 눈에 띄지 않게 조용히 망한 회사들은 셀 수 없을 만큰 수두룩합니다.

첫번째 개발자가 될지 두번째 개발자가 될지는 여러분의 선택입니다. 주변의 환경때문에 어쩔 수 없다는 것은 핑계에 불과합니다. 방법을 몰라서 그런 것이라면 마음만 열면 많은 도움을 받을 수 있습니다.

QA팀은 없다고 생각하라

저는 여러 소프트웨어 회사를 접할 기회가 많기 때문에 우리나라의 소프트웨어 현실을 다양하게 보게 됩니다.

많은 회사들이 전문 QA팀없이 개발자가 테스트를 하곤합니다. 제가 접한 소프트웨어 회사들의 대략 70% 이상이 전문화된 QA가 없었습니다. 심지어는 대기업에 속한 회사들도 QA팀 없이 개발자나 팀장이 테스트를 하는 경우도 있습니다.

그 이유야 제가 이전에 여러번 언급했듯이 주먹구구식 개발이나 형식에 치우친 프로세스를 채용한 회사들은 개발자가 아니면 그 기능을 속속들이 잘 모르기 때문에 개발자나 팀장이 테스트를 할 수 밖에 없고 누가 좀 도와준다고 하더라도 Random 테스트 밖에 수행을 하지 못합니다.

이 이슈는 차치하고 소수의 QA팀을 가지고 있는 회사들에서는 QA테스트가 제대로 이루어지고 있는지 확인을 해볼 필요가 있습니다. 제 경험에 의하면 많은 회사들이 QA팀이 있다고 하더라도 QA팀을 충분히 활요하지 못하고 있었습니다. 이런 경우들이 존재합니다.

- QA팀에게 개발자의 일을 떠넘기는 경우

QA팀이 무슨일을 하는 것인지 정확하게 모르는 경우입니다.

- QA팀에게 테스트를 할 수 있는 충분한 정보를 제공하지 않는 경우

QA팀이 있다고 해도 또 주먹구구식으로 테스트를 하거나 QA팀이 제품의 기능을 알아내기 위해서 제품을 일일이 써보는 수밖에 없는 경우입니다. 수박 겉핧기씩 테스트를 할 수 밖에 없고 많은 버그는 고객들이 찾아줍니다. 

- QA팀의 테스트 결과를 비난하는 경우

QA팀의 책임이 무엇인지 모르는 경우입니다.

이 중에서 첫번째에 대해서 얘기를 해보려고 합니다. 

소프트웨어 회사들이 QA팀 없이 개발을 하다가 QA팀이 생기고 또는 테스트 전담 인원이 생기면 개발팀의 자신들이 그동안 해 왔던 테스트를 QA팀에서 대신 해줄 것으로 착각을 하곤합니다.

엄밀히 말하면 이는 잘못된 생각입니다. 대부분의 개발자들이 하는 테스트는 QA테스가 아닙니다. 개발자들이 개발과정에서 당연히 해야할 유닛테스트와 통합테스트일 뿐입니다. 

개발자들은 자신들이 하던 테스트를 도와줄 사람이 생겼다고 생각하고 대충 구현을 해서 QA팀에 넘겨버립니다. 그러면 QA팀에서는 버그투성이인 제품을 테스트하느라고 시간을 낭비하곤 합니다. 그래서 정작 제대로 된 테스트는 해보기도 어려운 경우가 허다합니다. 이런 회사들의 특징은 개발자와 QA팀이 타이트하게 붙어서 개발자가 개발을 하는대로 바로바로 테스트를 해줍니다. 혹시 이런 형태로 개발을 하고 있다면 QA팀을 전문가로 생각하지 않고 개발팀의 심부름꾼 정도로 생각하고 제대로 활용하지 못하고 있고 생각할 수 있습니다.

개발자들은 QA팀이 없다고 생각하고 완벽하다고 생각하는 코드를 작성해서 QA팀으로 넘겨야 합니다. QA팀은 이렇게 만들어진 제품을 제대로 검증할 책임이 있습니다.

먼저 QA팀의 역할이 무엇인지 정확하게 이해해야만 QA팀이 제 역할을 할 수 있습니다.

개발팀장과 프로젝트관리자(PM)

오랫만에 찾아뵙니다.

요즘 워낙 바쁜 날을 보내고 있다는 핑계로 블로그 포스트를 자주 못하고 있습니다. 다시 힘을 내서 시작하려고 합니다.

최근에 컨설팅에 많은 시간을 보내고 있는데, 컨설팅을 하면서 주로 겪게 되는 현실적인 얘기 위주로 적어볼까 합니다. 그 중에서 가장 흔히 보게 되는 것이 개발팀장의 애매한 포지션입니다.

당신이 개발자라면 또는 개발팀장이라면 어떠한 일을 하고 있는지 잘 살펴 보시기 바랍니다. 제가 여러 회사를 컨설팅하면서 만나본 개발팀장의 역할은 천차만별이었습니다. 

공통점은 있습니다. 개발자로서 오랫동안 일을 하다가 개발팀장이 되었다는 것입니다. 

하지만 현재 하고 있는 일들은 천차 만별입니다.

어떤 개발팀장은 여전히 코딩에 90% 매진하고 있고, 어떤 사람은 프로젝트 관리만 하고, 어떤 사람은 회사 경영회의 쫒아다니면서 바쁜 나날을 보내고 있고, 어떤 사람은 코딩도 하고 관리도 하고 정신 없이 시간을 보내는 사람도 보았습니다.

개발팀장은 "개발팀"의 "장"이란 의미를 가지고 있어서 관리자로서의 역할을 요구하고 있는 듯하지만 대부분의 소프트웨어 회사에서는 가장 경험이 많고 뛰어난 개발자들이 맡고 있습니다.  

하지만 회사에서는 "장"이라는 의미에 따라서 개발자로서의 뛰어난 역할도 계속 해주기를 원하면서 관리도 하기를 원하는 경우가 많습니다. 개발팀에서 필요한 관리란 일반관리와 프로젝트관리인데, 보통 개발팀에서 일반관리는 할일이 별로 많지 않습니다. 일반관리 이슈가 매우 크다면 프로세스나 시스템을 개선해야 할 것입니다. 

따라서 이슈가 되는 것은 프로젝트 관리인데, 이것이 그렇게 만만한 일이 아닙니다. 즉, 개발팀장이 최고의 개발자로서 스펙도 잡고, 설계, 코딩도 하면서 할 수 있을 만큼 프로젝트관리가 간단하지 않습니다. 보통 어디하나 펑크가 나게 되어 있습니다. 

제 경험상 보통 프로젝트 관리에서 문제가 생기는 경우가 많습니다. 개발팀장은 개발자체는 원래 하던일이고 익숙하지만 프로젝트 관리는 경험도 적고 대부분 방법도 모르기 때문에 상식선에서 개발하느라고 바쁜 시간에 짬을 내서 하기 때문에 문제가 생기기 십상입니다.

그래서 필자는 개발팀장은 계속 최고의 개발자로서 개발 조직을 기술적으로 이끌고, 프로젝트 관리는 전문 PM(Project Manager)에게 맡기는 것을 권장합니다. 물론 개발자 출신으로 꼼꼼하고 관리를 좋아하는 사람이 PM으로 성장하는 것도 좋습니다.

개발조직이 10명 미만이고 대부분 소규모 프로젝트만을 진행한다고 하면 PM을 따로 두지 않아도 어떻게든 프로젝트가 진행이 될 수 있을 겁니다. 하지만 조직이 커지고 프로젝트가 복잡해지고 많은 프로젝트를 수행한다면 프로젝트의 성패는 요소기술에 달려 있지 않다는 것을 알게 될 것입니다. 이쯤되면 전문 PM이 없다면 가장 뛰어난 개발팀장들은 기술에 매진하지 못하고 잘하지도 못하는 프로젝트 관리에 허덕일 것입니다.

개발팀장은 쉽게 대체가 되지 않지만 PM은 외부에서 영입을 하는 것도 가능합니다. 즉 외부에서 영입한 사람이 할 수 있는 일을 회사에서 가장 바쁘고 가치 있는 일을 하는 개발팀장에게 맡기는 것은 비효율적입니다.

그렇다고 PM이 아무나 할 수 있다는 뜻은 아닙니다. 이또한 전문적인 일로서 전문가가 해야 하는 일입니다.

지금 일반관리자, 개발팀장, PM 등이 마구 섞여서 일을 하고 있다면 일단 임무를 나누어서 생각하는 습관을 들여야 할 것입니다. 그리고 현재 어느부분에서 문제가 생기고 있고 어느 역할을 보충해야 할지 계획을 세워서 조직을 튼튼하게 해야 합니다. 그렇지 않고 개발자 인원수만 늘여서는 현재의 많은 문제들이 해결되지 않습니다.

개발자의 파워는 어디에서 오는가?

뛰어난 개발자를 관리자로 써먹는 것 같이 개발조직에 비효율적인 일은 별로 없습니다.

하지만 현실에서는 이런 일이 흔히 벌어지고 있습니다. 실제로 저도 여러 회사에서 자주 접하고 있습니다.

여러가지 이유가 있을 수 있겠지만 주요 이유는 회사에서 개발자로서 꾸준히 성장할 수 있는 Career Path를 보장하기 않기 때문입니다.

회사에서 파워를 가지려면 팀장이 되어야 하고, 그래야 개발자들을 거느리며 힘을 행사할 수 있게 됩니다.

하지만 일단 팀장이 되고나면 개발에 전념할 시간은 점점 줄어들게 됩니다. 그렇다고 개발을 포기하고 관리만 하기에는 관리할 일의 양도 얼마 되지 않고, 파워가 줄어들게 될 까봐 걱정을 하게 됩니다.

흔히들 개발자는 행정적인 파워가 없어도 기술력에 따른 카르스마에서 파워가 생긴다고 하지만 이는 실제 현장에서는 공허한 얘기가 됩니다.

제대로 세팅된 소프트웨어 회사라면 개발팀은 관리할 것이 그렇게 많지 않습니다. 하지만 그렇지 못한 회사는 이래저래 관리할 일이 점점 늘어나게 되서 불필요하게 팀장의 관리에 많이 의존하게 됩니다.

이렇게 뛰어난 선임개발자들이 개발과 관리를 넘나드는 사이에 기술은 점점 멀어지게 되고 돌아올 수 없는 강을 건너는 경우가 예사입니다.

결국 100원짜리 개발자를 10원짜리 관리자로 만들고 맙니다.

물론 개발자 중에는 관리능력도 뛰어나서 관리자 역할을 훌륭하게 수행해 내는 사람도 있습니다. 

이 경우 개발자가 개발보다 관리에 관심이 많고 관리 능력이 더 뛰어나다면 관리자로 전환하는 것도 좋을 겁니다. 하지만 개발과 관리 둘다 능력이 좋다면 개발을 선택하는 것이 좋을 겁니다. 개발이 훨씬 부가가치가 높으며 다른 사람으로 쉽게 대체할 수가 없습니다. 둘다 훌륭하게 수행해내기를 바란다면 욕심입니다. 

뛰어난 개발자를 개발자로 있게하려면 회사에서 경력을 보장해줘야 합니다. 

개발자로 꾸준히 성장할 수 있는 Position을 만들어야 하고 연봉에서 대우을 해줘하고 관리자 이상의 파워를 가질 수 있는 제도를 마련해줘야 합니다. 그렇지 않는다면 뛰어난 개발자들이 개발과 관리사이에서 끊임없이 고민하다가 많은 개발자들이 관리자로 전환되면서 회사에 손해를 끼치게 될 겁니다.

수평적인 조직구조를 가진 외국의 회사들과 다르게 수직적인 조직구조를 가지고 있는 우리나라 회사에서 개발자에게 힘을 실어주기란 쉽지 않습니다. 그래서 제도적으로 뒷받침이 되지 않으면 어렵다는 것입니다.

현실적으로 쉽지 않은 일임을 공감합니다. 개발에 대한 전문성을 인정해주는 분위기가 같이 성장을 해야 개발자 경력 보장도 점점 이루어질 것입니다.