55세 개발자가 막내인 개발팀

얼마전 미국 소프트웨어 회사인 P사의 호주 지사에서 일하고 있는 엔지니어를 만나서 얘기를 나눴다. P사는 본사가 캘리포니아에 있고 전체 개발자 수는100여명이다. 그리 크지 않은 회사지만 20년동안 꾸준히 성장을 해왔고, 소프트웨어 개발자라면 알만한 시스템을 개발하는 회사다. 
 
그 회사의 제품군을 알고 있는 사람들은 100여명 밖에 안되는 개발자들이 일하고 있다는 것에 놀랄것이다. 우리나라 소프트웨어 회사라면 20년간 커왔고 전 세계 많은 나라 기업들에서 사용하고 있는 시스템을 만든다면 개발자가 수백명에 육박할 것이다. 하지만 매우 적은 인원으로 효율적으로 개발하고 있다는 것은 놀라운일이다. 그런데 이렇게 효율적인 소프트웨어 회사가 우리나라 밖에는 엄청나게 많다. 
 
P사 제품의 코어엔진을 만드는 팀에는 7명의 개발자가 일하고 있다. 그중 제일 고참이 60세라고 한다. 막내는 55세다. 또 관리자의 나이가 가장 어리다. 60세 개발자는 회사 초창기부터 20년간 근무했다. 대충 짐작해도 35년은 엔지니어로 일하고 있는 것으로 보인다. 비단이 회사에만 이런 할아버지 개발자들이 있는 것은아니다. 개발자 본인이 원하고 실력이 된다면 20년, 30년 원하는 만큼 개발자로 일을할 수 있다. 
 
우리나라에서는 한 분야에서 오랫동안 한가지 제품만 개발하고 있는 개발자들의 걱정이 있다. 다양한 분야를 접하지 못하다 보니 경험이 제한되고 시야가 좁아지고 엔지니어로서의 가치가 떨어지는 것이 아닌가 하는 우려를 한다. 실제로 금융분야에서 10여년 일한 개발자를 보면 사용하고 있는 프레임워크만 알고 기계적인 코딩밖에 하지 못하는 경우를 종종 본다. 다른 분야도 마찬가지다. 그럼 한 분야에서만 일한 미국의 30년차 개발자도 그럴까? 물론 개인차가 있겠지만 개발하는 문화나 방식이 좀 다르기 때문에 상황은 다르다.
 
P사에서 개발하는 방식을 보자. 눈에 띄는 것은 개발 방법론이 어찌됐건간에 제품을 꾸준히 업그레이드하면서 코딩을 하기 전에 스펙 문서를 자세히 작성해서 전세계 많은 관련자와 세밀하게 리뷰를 한다. 스펙에는 아키텍처도 포함되어있다.  스펙은 개발자끼리만 리뷰를 하는 것이 아니다. 애플리케이션 개발자와 리뷰도하지만 QA엔지어와도 리뷰를하고 기술 지원 엔지니어 등 거의 모든 분야 관련자들과 리뷰를한다. 
 
리뷰는 그냥 훑어보는 것이 아니다. 자신이 담당하거나 전문인 분야의 지식을 총동원한 후 검토를 해서 향후 발생할 문제 등을 면밀히 분석하는 것이다. 이 과정에서 아주 기술적인 세밀한 부분까지 토론하고 논쟁한다.
 
이런 과정을 거치면 제품의 완성도는 훨씬 올라가고 아키텍트는 튼튼해진다. 이런 얘기를 들으면 우리도 시간이 충분하면 이렇게할 수 있다고 한다. 하지만 이런 생각은 착각이다. 이렇게 개발을 하기 때문에 적은 인원으로 더 빨리 개발을 하는 것이다. 논어에는 세명이 길을가면 그중에는 반드시 내 스승이 있다고 했다. 철저한 리뷰는 더 좋은 제품을 만들기도 하지만 리뷰를 통해서 많은것을 배운다. 개발자는 본인의 직접적인 경험과 책만으로 배우는 것은 한계가 있다. 여러 개발자와 또 개발자가 아니라도 여러분야의 전문가와 토론하면서 많은것을 배우게 된다.
 
우리나라 개발자들은 흔히 토론, 리뷰에 약하다. 토론의 경험도 적고 막상 토론을 하면 직급으로 누르거나상대방을 공격해서 상처를 주거나 논리적으로 진행되지 않는 경우가 많다. 한두번 이런 일을 겪고 나면 이런 자리는 자연스럽게 피하게 된다. 결국 혼자서 땅굴을 파는 것에 편하게 되고 그렇게 오랜시간 개발을 하다 보면 한 분야의 전문가는 될 수 있어도 다양한 경험과 통찰력을 가진 개발자로 발전하기는 힘들게 된다.
 
또, 주목할만한 것은  소프트웨어 선진국에서는 아주 흔한 근무형태지만 재택근무가 아주흔하다는 것이다. 위에 언급한 모든것의 진행이 온라인 시스템과 화상회의로 이루어진다. 장소에 구애 받지 않고 일하고 회의도 화상회의 시스템을 많이 이용하고 꼭 필요할 때만 회사에 나가도 된다. 이런 재택근무 문화는 개발자에게 일할 기회를 제공한다기보다는 장소에 구애받지 않고 회사가 뛰어난 엔지니어의 도움을 받을 수 있다고해석하는 것이 좋겠다. 
 
리뷰도 어차피 대양을 건너 세계 각국 많은전문가와 진행하는 것이기 때문에 한자리에서 같이 일할 필요는없다. 이렇게 뛰어난 엔지니어들이 모이면 서로의 성장에 도움이 된다. 온라인이 아니면 이런 엔지니어들이이렇게 같이 일을할 수 있겠는가?
 
이글을 읽는개발자라면 우리도 환경이 되면 이렇게할 수 있다고 생각할 수 있겠지만 막상 쉽지는 않다. 대부분의 엔지니어가 문서 작성을 코딩하는 것처럼 익숙해져 있고 잘 작성해야 한다. 이런 온라인 협업은 시스템과 문서로 진행이 되기 때문에 문서작성역량은 매우 중요하다. 많이 자세히 작성하는 것이 잘하는 것은아니다. 효율적으로 필요한 핵심 내용을 적절히 작성해야 한다. 고참 엔지니어가 될수록 문서작성능력은 더욱더 중요하다. 나뿐만 아니라 내 주변의 수많은 개발자들 이렇게 일을 할때 30년 이상 개발자로 즐겁게 일할 수 있을 것이다.

할아버지 개발자를 만나고 싶다

외국 소프트웨어 회사에서는 할아버지 개발자들을 종종 볼 수 있다. 현재도 프로그래밍을 하고 있는 진짜 개발자들이다. 우리나라가 개발자들은 이런 할아버지 개발자를 만나보거나 이야기를 전해 들으면 많이 부러워한다. 

대부분의 개발자들은 경력이 쌓이면서 자연스럽게 관리 업무를 겸하거나 아예 관리자로 전환된다. 관리와 개발업무를 동시에 하는 개발자들도 관리하랴, 회의하랴 바빠서 본인이 가장 잘하며 좋아하는 개발 업무와는 점점 멀어지게 된다. 또 관리를 하지 않으면 회사에서 파워가 줄어들거나 대우도 안 좋기 때문에 자연스럽게 그리고 본의 아니게 관리 쪽 진로를 선택하지 않을 수 없게 된다. 종종 자신은 끝까지 개발만 하겠다고 고집하는 개발자들은 관리 능력, 커뮤니케이션 능력이 떨어지는 괴짜라고 생각하는 이상한 시각도 존재한다. 

S사의 예를 보자. 이 회사는 오래 전부터 개발자 경력을 보장해주고 있다. 제도적으로는 개발자 트랙을 선택한 사람들은 관리를 하지 않고 개발만 계속 할 수가 있다. 하지만 속을 보면 개발자 트랙을 선택하나 그렇지 않으나 큰 차이는 없다. 개발자 트랙을 선택한 경우에도 개발 일에만 집중할 수 없고 그렇지 않은 경우에도 개발과 관리를 겸하게 된다. 개발과 개발이 아닌 일을 명확하게 구분하지 않고 두루뭉술하게 일을 해서 대부분은 개발 경력이 쌓일수록 개발에 집중할 시간은 점점 줄어들게 된다. 

T사의 경우 10년차 이상이 되면 팀장이 되고 파트장을 맡는다. 대부분 회사에서 가장 뛰어난 개발자들이다. 하지만 관리를 조금이라도 맡은 이상 낮에는 개발에 집중할 시간이 거의 없다. 보고서 작성에 회의 참석, 다른 부서와 의견 조율, 이런 일로 하루를 보내다가 저녁이 되어서야 개발 일을 시작한다. 이런 생활을 몇 년 하다보니 자연스럽게 개발 일에서 손을 놓게 되었다. 

이런 회사에 경영자들에게 왜 회사의 가장 뛰어난 개발자들이 개발을 거의 못하는 관리 일을 시키냐고 물어보면 다음과 같은 얘기를 한다. 

“당연한 것 아닌가? 소프트웨어 개발은 워낙 특수해서 개발을 속속들이 잘 알아야 개발 조직을 관리할 수 있다. 그가 우리 회사에서 소프트웨어 개발을 가장 잘아는 사람이다. 그래서 그에게 개발 조직 관리를 맡기고 있고 본인도 그 자리를 원하고 있는 것으로 알고 있다.” 

주변에서 소프트웨어 업계의 유명했던 롤모델들을 보면 지금도 개발을 하고 있는 사람들은 그렇게 많지 않다. 왕년에 개발을 좀 했던 실력자이지만 현재도 개발을 하고 있는 엔지니어는 만나기 힘들다. 왠만한 뚝심으로는 개발자로 남아 있기가 어렵다. 당사자들이 환경에 순응해서 개발에서 손을 놓게 된 경향도 크다 

우리는 각 기업의 최고 개발자였지만 지금은 관리자인 사람들을 종종 만나게 된다. 이들은 대부분 본부장, 센터장, 부서장, 연구소장 등과 같은 직함을 가지고 있다. 이들 대부분은 과거에는 개발자였을지 모르지만, 그리고 지금도 코드를 잘 읽을 수 있을지 모르지만, 관리자로 몇년만 지나면 더 이상 개발자가 아니다.

개발도 잘하고 관리도 잘한다는 것은 착각이다. 관리자가 된 이상 개발에 대해 특히 아키텍처나 구체적인 기술에 대해서 이러쿵저러쿵 참견하는 것은 매우 위험하다. 관리를 잘하는 것이 본인의 업무이고 그것만도 매우 어렵다. 

나는 블로그를 통해서 자신의 회사에서 개발자 경력을 보장하고 있는지 설문 조사를 한적이 있다. 과거 4년동안의 통계를 보면 개발자 경력 보장 제도가 있는 회사는 14%이다. 물론 제도는 있어도 형식적이거나 현실적으로 개발자로 남기 불가능 회사가 많기 때문에 실제 개발자가 경력을 보장받을 수 있는 비율을 훨씬 떨어지게 된다. 한마디로 20년, 30년 개발자로 남아 있기는 낙타가 바늘 구멍 통과하기만큼 어렵다. 

우리나라는 장인정신보다는 관료주의적인 전통이 자리잡고 있어서 전문가보다는 관리자가 더 높은 자리로 인식된다. 그러다 보니 개발자도 분위기에 순응해서 자연스럽게 관리 쪽으로 슬금슬금 넘어가게 된다. 팀장, 부서장이 되어서도 개발에 집중하고 싶어도 주간보고, 월간보고, 업무 분배, 진척확인, 부서간 소통, 보고서 작성, 채용, 사업계획, 평가, 경영자에게 보고 등등 이런 일이 점점 늘어가고 그러다 보면 점점 관리자로 탈바꿈한다. 

개발자가 개발 일에서 떠나는 이유가 또 하나 있다. 개발 프로젝트가 대부분 합리적이지 못하고 무리한 경우가 많아서 몇 년 구르다 보면 야근과 각개전투가 난무하는 전투현장에서 벗어나고 싶게 된다. 개발이 진짜 즐겁고, 개발자로 충분히 대우도 받고 보장을 받을 수 있다면 관리자가 되려고 할까? 개발이 합리적이고 즐겁고 비전이 있어서 개발자들이 남아 있으려고 할 것이다. 

이렇게 고급 개발자들이 떠나게 되면 소프트웨어 생산성은 극도로 낮아진다. 이것은 회사적으로도 국가적으로도 큰 손해다. 뛰어난 개발자들이 관리를 잘 해준다고 해도 소프트웨어 생산성에는 별로 도움이 안된다. 그럼 소프트웨어 개발이 그렇게 관리가 많이 필요한가? 사실 개발팀은 관리할게 별로 없다. 

관리가 많이 필요한 개발팀은 비효율적 팀이라는 것을 단적으로 나타낸다. 단, 프로젝트 관리는 필요하고 전문 프로젝트 관리자가 있을 수 있다. 큰 조직이나 큰 프로젝트는 이보다 더 많은 전문 관리자가 있을 수 있다. 프로젝트 매니저(Project Manager), 리스크 매니저(Risk Manager), 프로덕트 매니저(Product manager), 프로그램 매니저(Program Manager) 등 다양한 전문 업무로 세분화 되기도 한다. 

외국 소프트웨어 회사와 같이 일해본 개발자들은 종종 할아버지 개발들을 만나게 된다. 이들은 50세가 넘어서도 가끔은 60세가 넘어서도 개발을 한다. 코딩도 직접 한다. 

왜 할아버지 개발자가 중요할까? 소프트웨어 개발자는 물론 예외도 일부 있지만 보통 경력이 쌓일수록 실력이 늘어간다. 그래서 회사의 개발자 층은 피라미드 구조를 이룬다. 그런데 가장 뛰어난 늙은 개발자가 관리를 하고 있으면 개발자 피라미드의 중간부터 꼭대기가 아예 없는 사다리꼴 피라미드가 된다. 이런 회사에서 개발 경쟁력을 기대하기는 어렵다.

개발자 본인은 어떨까? 나도 마찬가지지만 대부분의 개발자들은 관리를 극도로 싫어하고 잘하지도 못한다. 개발자들은 개발을 할 때 가장 행복하다. 행복한 일을 하면서 세상을 바꿀 수 있는 개발자라는 직업은 얼마나 멋진 직업인가? 하지만 40, 50세를 넘은 개발자를 찾아보기 어려운 현상은 개발자의 미래를 불투명하게 하고 직업 안정성을 해치고 있다. 

올림픽 금메달을 딴 선수가 20대 중반에 은퇴한 후 직장의 조직에서 불안해하는 것과 별반 다를게 없다. 이런 현상이 개발자 직업 선호도를 낮추는 원인이 되고 있다. 성공한 소프트웨어 회사에서 사장이나 연구소장이 나와서 브리핑하는 것이 아니고 백발의 진짜 개발자가 나와서 개발 이야기를 들려주는 일들이 뉴스에 자주 나와야 한다. 

소프트웨어 개발자의 경력을 보장하는 일은 개인, 회사, 사회적으로 매우 중요하다. 우리나라 소프트웨어 미래의 사활이 걸려있다고 봐도 과언이 아니다. 여기서 가장 중요한 역할은 회사가 해야 한다. 회사에서 개발자의 경력보장이 왜 중요한지 먼저 인식해야 한다.  왜? 거기에 회사의 소프트웨어 개발 경쟁력의 핵심이기 때문이다. 

먼저 개발자와 비 개발자의 트랙을 명확하게 나눠야 한다. 좋은게 좋은 거라고 두루뭉술해서는안된다. 개발자는 철저하게 관리 업무와 잡무에서 보호를 해야 한다. 

앞에서 언급한 보고서 작성, 사업 계획, 예산, 평가 등에 시간을 허비하지 않도록 해줘야 한다. 이런데 10%라도 시간을 빼앗기면 개발 생산성은 50% 이하로 떨어진다. 관리업무와 잡무는 다른 사람을 시키면 된다. 개발자가 10명 이하인 회사도 업무는 나눌 수 있다. 

회사에 롤모델과 멘토도 만들어야 한다. 내가 지금까지 개발자로 남아 있을 수 있던 이유는 롤모델이 있기 때문이다. 개발자는 어떻게 해야 하는지 보고 따라 할 수 있어야 한다. 눈에 보이지도 않는 요정과 같은 모습은 따라 할 수가 없다. 처음에는 어렵겠지만 개발자 롤모델을 키워내야 한다. 개발자에게 모든 것을 원하는 만능 개발자 위주 정책이 없어져야 한다. 한분야의 전문가라도 개발자로 일할 수 있게 해야 한다. 

회사가 준비가 되었다고 다는 아니다. 개발자 개인들도 생각을 바꿔야 한다. 본인의 성향을 보고 진로를 결정해야 한다. 인간의 두뇌 구조는 개발자와 관리자 모두를 잘할 수 있도록 되어 있지 않다. 물론 사회적 제도적 제한이 있어서 본의아닌 선택을 해야 하는 경우도 있지만 본인의 노력도 매우 중요하다. 개발자로 남고 싶으면 끊임없이 새로운 기술을 익혀야 한다. 시야도 넓혀야 한다. 비즈니스도 잘 알아야 한다. 개발자들이 서로 기술을 공유하고 경험을 나누며 같이 성장하려면 피어리뷰가 필수다. 

최고의 개발자들이 관리자나 다른 분야로 떠나고 신참들만 넘쳐나는 개발현장에서 경쟁력을 기대하기는 어렵다. 이런 관료적인 분위기를 소프트웨어 현장에서 없애지 않으면 우리나라 소프트웨어 미래는 없다. 나는 지금도 소프트웨어 경영자를 만나면 개발자 경력 보장이 얼마나 중요한지 역설 한다. 

물론 말 한마디로 30년차 개발자의 모습이 잘 그려지지 않고 실천하기는 어려울 것이다. 개발자 경력보장의 중요성에 대한 인식이 먼저 필요하다. 생각은 바뀌었는데 방법을 모르는 회사는 얼마든지 도와줄 의향이 있다. 그 중요성을 깨달은 것만으로도 이미 50%는 달성한 것이다. 

우리 주변에서도 할아버지, 할머니 개발자를 흔하게 보는 시기가 되면 소프트웨어 개발자들이 행복하게 일하는 세상이 이미 되어 있을 것이다.

Technical Career Path를 보장하는 방법

그 동안 개발자 경력에 대한 글들을 여러 건 작성했다. 많은 독자들이 문제 인식에 공감을 했지만 여전히 해결책은 쉽지 않다. 그래서 여기 방법을 제시하고자 한다. 소프트웨어 회사들이 어떻게 하면 Technical Career Path를 보장할 수 있을까?

첫째, 경영자 의식의 변화이다.

경영자가 개발자의 경력을 보장하는 것이 회사에 얼마나 큰 이득이 되는지 깨닫지 못한다면 개발자가 꾸준히 개발만 할 수 있도록 노력할 리가 없다.

축구는 체력이 떨어지는 30대 중후반이면 더 이상 선수로 뛰기 어렵지만, 소프트웨어 개발자는 체력과 상관없이 평생 시간이 흐를수록 점점 더 뛰어난 개발자로 일할 수 있다. 이렇게 뛰어난 선수로 일할 수 있는 개발자들을 관리나 하라고 낭비하지 않고 계속 선수로 뛸 수 있도록 회사에서 지원을 해야 한다는 것을 경영자들이 절실히 깨달아야 한다.

아직은 경영자들이 이같은 인식이 부족하거나 막연히 개념만 인지하고 현실은 다르게 행동을 하는데 주위에서 설득하려는 노력이 필요하다. 이 칼럼들을 공유해도 좋고 외국의 사례를 보여주는 한 방법일 것이다. 이는 회사를 위하고 개발자도 위하는 길이다.

둘째, 개발 조직의 변화이다.

개발 조직은 워낙 회사마다 서로 달라서 하나의 형태를 지켜야 한다고 말할 수는 없다. 하지만 개발 조직이 전문 개발자들이 제대로 일할 수 있는 구조가 되어야 한다. 우선 개발팀장, 개발리더, 매니저 등 구분 없이 마구 섞여서 일하는 것은 지양해야 한다.

조직이 아주 작아서 혼자 다해야 하는 경우를 제외하고는 관리자와 개발자는 구분을 하자. 팀이 커져서 관리 일이 점점 많아지면 더 이상 개발자가 개발을 겸해서 하기는 어렵다. 전문 관리자를 두는 것이 좋고, 프로젝트에서도 프로젝트매니저를 따로 두는 것이 좋다. 개발자는 개발에 전념할 때 가장 높은 성과를 낸다. 개발 외의 일은 관리자나 프로젝트매니저가 맡아야 한다.

셋째, 공정한 평가이다.

소프트웨어 개발자로 공정한 평가를 받기 매우 어렵다. 그래서 평가 대상보다는 평가자가 되려고 하는 경향이 있다. 공정한 평가가 대단히 어려운 일이지만 나름대로 객관적인 근거에 의한 평가를 위해서 노력해야 한다. 개발자가 어찌 해볼 수 없는 이유로 평가에서 불이익을 받는다면 개발을 계속 하기가 싫어질 것이다. 소스코드관리시스템과 이슈관리시스템의 기록을 활용하고 개발 일정 준수 등의 지표를 활용하는 것도 좋은 방법이다.

넷째, 적절한 대우이다.

많은 회사에서 팀장이 되고 관리자가 되어야 더 높은 연봉을 받을 수 있다. 그 주된 이유는 관리와 개발의 분리가 안되어 있어서 구분이 안되기 때문이다. 관리를 하지 않고 평생 개발을 한다고 해서 연봉이나 대우에서 불이익을 받아서는 안된다. 오히려 동일 경력에서 개발자가 관리자보다 더 높은 연봉을 받는 것이 맞을 수 있다. 관리자나 개발자나 자신의 전문분야에서 회사에 기여하는 만큼의 적절한 대우를 받아야 한다.

다섯째, Career Path 제공이다.

회사에서 다양한 Career Path를 제공해야 한다. 개발자는 이들 중에서 적절한 시점에 선택을 할 수 있어야 한다. 계속 개발자로 경력을 발전시켜 나갈 수도 있고 관리자나 프로젝트매니저가 될 수도 있다. 또는 다른 일을 맡을 수도 있다. 한번 개발자 경력에서 벗어나면 다시 돌아오기 어려우므로 신중하게 결정해야 한다.

여섯째, 개발문화, 개발 프로세스, 기반시스템이다.

너무 광범위한 내용이라서 다 설명하기는 어렵다. 개발자가 제대로 일하기 위해서는 공유를 기반으로 한 투명한 개발문화와 적절한 개발 프로세스가 필요하다. 또한 개발에 필요한 기반시스템을 제대로 갖추고 있어야 한다. 아무것도 갖추지 못한 회사에서는 개발자가 아무리 개발을 오래해도 가치를 높이기가 어렵다.

일곱째, 롤모델이 필요하다.

롤모델이 있다면 개발자들에게 확실한 길을 보여줄 수 있다. 하지만 무늬만 개발자가 아닌 진짜 개발자를 외부에서 영입하기는 쉽지 않다. 내부에서라도 개발자들의 롤모델을 만들도록 노력해 보자. 회사에서 가장 뛰어난 개발자들에게 관리 일은 덜어내고 개발에 전념할 수 있도록 해주고 회사의 제도가 이를 뒷받침하도록 하자. 회사의 개발 조직이 더욱 탄탄해 질 것이다.

개발자 경력 보장 문화는 개발자들의 인생이 달린 일이다. 아직은 척박하지만 우리가 하나씩 바꿔나가야 한다. 가장 어려운 일은 경영자를 설득하고 깨닫게 하는 일이다. 고양이 목에 방울달기 같은 일이지만 어렵다면 주변이나 전문가의 도움도 받아보자. 지금은 3D 취급하는 사람들도 있는 소프트웨어 개발이 좀더 좋은 대접을 받기 위해서는 개발자 경력 보장이 중요한 단초가 될 것이다.

이글은 Tech it에 기고한 글입니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CEO 가장 자주 하는 거짓말은 뭘까?

CEO 가장 자주 하는 거짓말 '회사 여러분 것' 직장인들이 뽑은 최고경영자(CEO)의 가장 흔한 거짓말은 ‘이 회사는 여러분의 것’이라는 조사결과가 나왔다. 취업포털 스카우트는 최근 직장인 1천26명을 대상으로 설문 조사한 결과 CEO들이 가장 자주 하는 거짓말은 ‘이 회사 다 여러분들 것입니다’가 25.2%(216명)로 가장 많았다고 27일 밝혔다. 이어 ‘내년 한 해만 더 고생하자’(21.1%), ‘연봉 못 올려줘서 늘 미안해’(13.9%), ‘우리 회사는 미래가 있다, 다른 생각하지 말게’(12.3%), ‘사람 하나 더 뽑아줘야 하는데’(8.9%) 등이 있었다. 후략... Copyrights ⓒ 연합뉴스. (출처:조선일보)

흥미 있는 기사가 있어서 소개도 하고 의견을 좀 올려볼려고 합니다.

아직도 "회사는 여러분 것"이라는 거짓말을 믿고 있는 분들은 없으시겠죠? 회사의 주인이 되려면 CEO의 말만 믿지 말고 "주식"을 사세요. 비록 소액 주주이지만, 주인이 될 수 있습니다.

그럼 회사와 나의 관계는 무엇일까요? 

"주종의 관계"일까요?

먼저 회사의 목적과 나의 목적의 차이를 알아야 합니다.

회사의 목적은 "돈"을 버는 것이고 그 목적에 가장 충실한 사람이 CEO입니다. 충실한 정도가 아니고 그 목적을 달성하지 못하고 파리 목숨이죠. 물론 Owner라면 다르겠지만요.

회사가 "돈"을 많이 버는 방법은 "매출"을 많이 올리고, "비용"을 줄이는 겁니다. 위에서 CEO들이 즐겨하는 거짓말들은 다 이 목적을 이루기 위해서 하는 것들입니다. 직원들이 좀더 열심히 일하게 만들면서 인건비는 최대한 줄여야 합니다.

그럼 내가 회사를 다니는 목적은 무엇일까요?

"돈", "사회적기여", "자아성취", "경력개발" ???

여기서는 정답이 없는 것 같네요. "돈"이 가장 중요하다고 생각하는 사람도 많지만, 회사를 다니는 목적의 비중은 서로 다 다릅니다.

하지만, 중요한 것은 내가 회사를 다닌 기록은 사라지지 않는 다는 것입니다.

내가 다녔던 회사가 지금 훨씬 잘 나간 다면 나에 대한 평가도 후해집니다. 하지만, 내가 몸담았던 회사가 처참하게 망해 사라졌다면 나 또한 그 책임에서 자유롭지 못하고 취업 인터뷰 시 죄인을 바라보는 듯한 시선을 받을 수도 있습니다.

즉, 나와 회사는 회사를 다닐 때나 그만둔 후에나 모두 "상생의 관계"일 수 밖에 없습니다.

또한, 다른 직업도 마찬가지 일 수 있지만, 소프트웨어 개발자라면 더욱더 회사가 자신의 몸값을 높이는 중요한 역할을 합니다. 소프트웨어 개발자는 학교에서보다 회사를 다니면서 익히고 배우는 것이 훨씬 많습니다. 똑같은 학교를 졸업해서 주먹구구식으로 개발하는 우리나라 소프트웨어 회사에서 10년 일한 개발자와 Google에서 10년 일한 개발자는 간판만 다른 것이 아니라, 경험한 내용과 실력에서도 엄청난 차이를 보입니다. 그래서 월급이 적더라도 더 많은 것을 배울 수 있고, 미래의 자신의 몸값을 높일 수 있는 회사라면 주저하지 않고 선택할 수 있겠죠. 

즉, 개발자가 회사를 다니는 중요한 목적 중의 하나는 자신의 실력을 만들어나가는 겁니다. 이런 마인드를 가지고 있으면 회사 생활이 달라집니다.

맨날 코딩에 매달리면서 자신의 업무만 처리하는데 열심히 개발자의 10년 후 미래는 그리 밝지 않습니다.

몸값이 높은 개발자는

"비즈니스 마인드가 있어야 합니다."

"가치가 낮은 코딩에만 매달리기 보다는 가치가 더 높은 분석/설계 업무에 더 치중해야 합니다."

"창의적인 생각을 해야합니다."

"넓은 View를 가지고 있어야 합니다."

"커뮤니케이션 능력이 뛰어나야 합니다."

또한, "코딩도 잘해야 합니다."

이렇게 변화를 하려면 문서를 잘 작성하기 위해서 노력을 해야 하고, 넓은 View를 가지기 위해서 자신의 프로젝트 뿐만 아니라 수많은 타 팀의 프로젝트의 리뷰에도 참석하여 기여도 하고 많은 것을 배워야 합니다.

또한 "코딩" 뿐만 아니라 소프트웨어 개발 전반의 지식 영역을 고루 공부하고 경험해야 합니다.

업계 동향과 새로운 기술에 뒤쳐지지 않기 위해서 끊임 없이 공부해야 합니다. 

이러한 자세는 회사의 목적인 "돈"을 버는 것과 어긋나지 않습니다.

개발자들의 이러한 자세가 "회사"와 "개발자" 모두가 성공하는 "상생"의 길입니다.

하지만, 이를 절대 용납하지 않는 환경의 회사를 다니고 있다면, 회사를 왜 다니는지 한번 생각해 봐야 합니다. "돈"을 많이 주는지? 나의 "경력"을 장식해 주는지? 많은 것을 배우게 해주는지?

이도 저도 아니라면 이직을 차근차근 준비해야 할 때가 아닐까요?