‘한국의 저커버그’가 양성되기 위한 조건

교육기관이나 양성기관에서 배출할 수 있는 한계는 코더 또는 프로그래머이다. 굳이 정부 주도로 한국의 빌게이츠나 저커버그를 양성하지 않아도 한국의 소프트웨어 환경이 충분히 매력적이라면 머리 좋고 도전정신이 뛰어난 인재들이 뛰어들 것이고 그 중에서 빌게이츠나 저커버그 같은 사람도 탄생할 것이다.

이글은 제가 씨넷코리아에 게재한 칼럼입니다. 새로 시작하는 씨넷코리아에 많은 관심 바랍니다.

예전에는 한국의 빌 게이츠를 키워야 한다고 하더니 요즘은 스티브 잡스를 거쳐서 마크 저커버그를 키워야 한다는 목소리가 높다.  정부 주도의 한국판 저커버그 양성 프로젝트가 생기는가 하면 기업이 주도하는 시도들도 있다.  이런 시도들이 나쁜 것은 아니다.

프로그래머 인력을 키울 수는 있을 것이다. 하지만 빌게이츠나 저커버그 같은 사람이 탄생하는 데는 별 도움이 안될 것 같다. 과연 특수한 교육기관이나 양성 기관에서 그런 인물을 양성할 수 있을까?

그럼 한국의 빌게이츠, 저커버그를 양성하기 위해서 그들이 어떤 역량을 가지고 있는지 살펴보자. 물론 “인생 운칠기삼”이라는 말이 있듯 역량이 뛰어나기 때문에 빌 게이츠나 저커버그가 성공한 것은 아닐 것이다.

또한 그런 역량이 있는 사람이 무조건 성공하는 것은 아니다. 하지만 그런 역량을 가진 사람이 많이 배출될 수 있는 환경이 있다면 우리나라도 빌게이츠 같은 사람을 배출할 가능성이 높아질 것이다.

필자는 소프트웨어 개발자가 가져야 하는 역량 또는 소양을 8가지로 구분하여 비교를 해보았다. 비교 대상은 주변에서 흔히 볼 수 있는 일반적인 코더 또는 프로그래머, 경험이 많고 뛰어난 아키텍트 그리고 마지막으로 청년 시절의 빌 게이츠다.

비교 수치는 지극히 필자의 개인적인 의견이기 때문에 실제와는 차이가 있을 수 있으며 전체 맥락을 설명하기 위한 것이니 수치의 정확성을 가지고 논하지는 말자.

각 항목은 뛰어난 개발자 또는 아키텍트가 되기 위해서 필요한 역량과도 상당히 비슷하니 개발자라면 관심을 가져보자. 그럼 각 항목을 살펴보자.

1. 창의력

남들이 생각하지 못하는 새로운 생각을 해내고, 문제에 봉착했을 때 참신하고 뛰어난 해결책을 찾아가는 능력이다. 단시간의 교육으로 배울 수 없으며 소프트웨어에 대한 지식뿐만 아니라 다양한 인문학도 창의력과 연관이 있다.

2. 논리력

소프트웨어 개발자에게 필수적으로 필요한 역량이다. 수학 교육과 다양한 논리 교육으로 향상 될 수 있으며 선천적인 지능에 크게 좌우된다. 이를 향상하기 위해서는 어렸을 때부터 오랫동안 꾸준한 교육이 필요하다.

3. 커뮤니케이션 능력

일반 코더에게는 그렇게 높은 수준이 커뮤니케이션 능력이 요구되지 않지만 뛰어난 아키텍트가 되려면 상당히 중요한 능력이다. 대화능력, 듣기능력, 토론기술, 대인기술, 설득능력, 인내력 등이 필요하다. 이런 능력은 암기식 교육환경에서는 키워지기 어렵다.  어렸을 때부터 토론식 교육 환경이 필요하며 능력을 키우기 위해서 시간이 매우 오래 걸린다.

4. 문서 작성 능력

가독성이 뛰어난 문서를 작성하는 기술이다. 일반적인 쓰기 능력, 정보 조직화 기술 등이 필요하며 일반 코더들이 가장 부족한 능력 중 하나이다. 십 수년의 학교 교육을 통해서 기초를 다져야 하며 실전 개발을 통해서도 오랫동안 단련해야 향상되는 능력이다.

5. 컴퓨터, 소프트웨어 지식

소프트웨어 동작원리, 자료구조, 알고리즘, 개발언어 등 개발의 기초 지식이다. 대학의 소프트웨어 관련학과에서 주로 가르치는 것이고 단시간에 기초를 닦을 수 있고 독학도 가능하며 실전 개발을 통해서 꾸준히 습득하는 지식이다. 단기적이고 집중적인 학습이 가능하다.

6. 코딩 능력

누구나 아는 코딩 파워다. 일반 코더의 능력을 구분하는 기준이며 그 능력차이는 코더마다 천지차이다. 다른 부분에 비해서 상대적으로 단기적인 교육의 효과가 있다.  우리나라 프로그래머들이 별로 떨어지지 않는 능력이다.

7. 소프트웨어 공학 경험

소프트웨어를 빠르게 개발하기 위한 공학적인 지식과 경험이다. 소프트웨어 분석, 설계, 소스코드관리, 이슈관리, 테스트, 프로세스, 툴, 개발문화 등 광범위한 영역의 경험이 필요하다. 학교에서는 배우기가 거의 불가능하며 제대로 된 개발환경에서 실전 개발을 통해 배워야 하며 매우 오랜 시간이 걸린다.

8. 도전정신

소프트웨어 개발자에게 꼭 필요한 역량은 아니지만 빌게이츠나 저커버그를 양성한다고 하면 필요한 정신이다. 타고난 유전자가 큰 영향을 미치며 주변 환경에 영향을 받을 수 있다. 단기적인 교육으로 향상하기는 어렵다.

이 중에서 교육기관이나 양성기관에서 단기적으로 키워서 효과를 볼 수 있는 분야는 소프트웨어 지식이나 코딩 정도이다. 나머지는 어렸을 때부터 꾸준히 키워야 하거나 실전 개발을 통해서 배워야 하는 것이다. 인위적이고 단기적인 교육으로 빌게이츠나 저커버그를 만들어낼 수 없다는 것은 자명하다. 인문학을 조금 더 가르치는 것도 새발의 피일 뿐이다.

교육기관이나 양성기관에서 배출할 수 있는 한계는 코더 또는 프로그래머이다. 굳이 정부 주도로 한국의 빌게이츠나 저커버그를 양성하지 않아도 한국의 소프트웨어 환경이 충분히 매력적이라면 머리 좋고 도전정신이 뛰어난 인재들이 뛰어들 것이고 그 중에서 빌게이츠나 저커버그 같은 사람도 탄생할 것이다.

직업훈련소 같은 학원을 세울 것이 아니고 불합리한 소프트웨어 업계를 바로잡는 제도와 법률을 손보고 도전하는 청년 창업자를 지원하는 것이 좋겠다. 그렇게 소프트웨어 생태계를 건강하고 매력적으로 만들어야 우수한 인재들이 모여들고 소프트웨어 환경은 더욱 좋아질 것이다.

출처: http://cnet.co.kr/view/18291 

개발자, 회사의 과거인가 미래인가

개발자는 소프트웨어 회사의 가장 중요한 자산이면서 서로 상반된 2가지 가치를 가지고 있다.

첫 번째는 ‘과거의 가치’이고

두 번째는 ‘미래의 가치’이다.

나는 과거의 개발자일까? 미래의 개발자일까? 스스로 판단하기는 어려울 것이다. 동료나 경영진에게 내가 퇴사를 하면 어떻게 될까?라는 질문을 해보면 짐작할 수 있다.

내가 퇴사를 하면 과거에 개발해 놓은 제품들을 어떻게 하지?라는 생각이 가장 먼저 들면 ‘과거의 개발자’에 가깝다.

반대로 내가 퇴사를 하면 과거에 개발해 놓은 제품들은 문제가 없는데 미래에 개발할 제품은 누가 개발하지?라는 생각이 들면 ‘미래의 개발자’라고 볼 수 있다.

회사나 개발자 입장에서 권장되는 개발자 타입은 미래 가치를 많이 지닌 “미래의 개발자”이다. 미래의 개발자가 지금은 가치가 적은데 미래에 가치가 높다는 의미가 아니다. 미래에 가치가 더 있고 시간이 흐를수록 점점 가치가 높아진다는 의미다.

과거의 가치를 더 많이 가지고 있는 ‘과거의 개발자’는 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식이 머리 속에 있기 때문에 동료나 신입개발자와 지식을 공유하기 어렵다. 본인이 의도해서 그렇게 한 것은 아니지만 결과적으로 자신이 과거에 만들어 놓은 소프트웨어를 인질삼아 회사와 인질극을 벌이고 있는 것과 같다.

물론 이런 개발자가 퇴사를 한다고 회사가 망하는 것은 아니지만 적게든 많게든 타격을 입게 되고 심한 경우 회사는 퇴락의 길을 걷기도 한다. 따라서 회사는 이런 개발자에게 질질 끌려 다니곤 한다. 이런 상태의 개발자는 스스로도 상황의 피해자일 뿐이다.

미래의 가치를 가진 ‘미래의 개발자’는 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수를 수월하게 할 수 있도록 개발 과정에서 적절히 문서화를 해 놓았고, 아키텍처를 깨끗하게 만들었으며 모든 이슈는 이슈관리시스템에 기록으로 남겨 놓았다. 그리고 Peer review를 통해서 이미 많은 지식을 동료들과 공유를 한 상태다.

이런 합리적인 개발 과정을 통해서 본인은 분석, 설계 능력이 꾸준히 향상되어 왔으며, 회사도 성장에 걸맞게 프로세스와 개발문화가 발전되어 왔다. 유지보수에 허덕이지 않으므로 신기술에 대한 연구에 소홀하지 않아서 미래에는 과거 제품들보다 한 단계 수준 높은 제품을 만들어 낼 것이다.

언뜻 보기에는 과거의 엄청난 폭풍 코딩을 통해서 짧은 시간에 많은 제품을 만들어내는 성과를 낸 ‘과거의 개발자’가 영웅처럼 보이지만 미래의 가치를 지닌 ‘미래의 개발자’가 진정한 영웅이다.

필자는 대기업부터 작은 소기업까지 여러 소프트웨어 회사를 다니면서 개발자와 경영진을 대상으로 소프트웨어 개발에 대해서 강연이나 세미나를 많이 한다. 그럴 때 이런 질문을 하곤 한다.

“오늘 회사를 그만둬도 당장 큰 문제가 발생하지 않는 사람 손들어 보세요”.

“오늘 회사를 그만두면 회사가 당장 큰 일 나는 사람 손들어 보세요”.

이 두 가지 질문 중에서 두 번째 질문에 손을 드는 사람이 상당히 많다. 특히 주변에 특정인을 가리키며 손을 들라고 하는 경우가 많다. 이런 사람은 십중팔구 ‘과거의 개발자’이다.

과거에 엄청나게 많은 일을 해냈지만 대부분은 유지보수에 치여 본인도 발전 못하고 격무에 시달리고 있는 경우이다. 수많은 문제와 이슈는 본인만 알고 있어서 수시로 불려 다니고 정작 본인은 개발할 시간이 없고 발전도 어렵다.

물론 ‘과거의 개발자’양산이 개발자에게 책임이 있는 것은 아니다. 소프트웨어 개발 환경이 회사에서 제공하는 프로세스, 시스템이 열악한 상태에서 전적으로 개발자의 내공에 의존을 하기 때문에 개발자도 어쩔 수 없이 ‘과거의 개발자’가 되어 버리는 것이다.

‘과거의 개발자’가 주도하는 회사는 엄청난 개발자 Risk를 안고 있는 것이다. 뛰어난 개발자가 많지만 이들이 한두 명만 나가도 회사가 휘청대며, 유지보수에 발목을 잡혀서 앞으로 나가기 어려운 상태인 경우가 많다.

회사는 개발자가 개발에 전념할 수 있고 개발 과정에서 꾸준히 성장할 수 있도록 환경을 제공해야 한다. 개발자 경력을 보장하는 것은 물론이고 프로세스와 기반시스템을 제대로 갖추고 개발문화 구축에 제도적인 노력해야 한다. 그렇게 해서 개발자 내공에 의존하는 개발이 아닌 시스템에 의존한 개발이 되어야 한다. 그런 환경에서야 개발자가 최고의 활약을 할 수 있다.

그래야 개발자도 행복하게 개발을 할 수 있고 회사도 개발자 Risk가 줄어든다. 이런 환경에서 성장하는 개발자는 신참때는 주로 코딩을 하지만 고참이 되어 갈수록 설계, 분석에 집중하고 문서를 통한 협업에 능숙해진다. 이런 방법이 개발자와 회사 모두에게 좋은 방법이다.

여전히 개발자의 내공에 의존한 개발 환경을 가진 회사에서 유지보수에 허덕인다고 개발자를 탓하지는 말자. 지금이라도 ‘미래의 개발자’를 위한 환경에 대해서 고민해보자.

책에도 다 있고 이론은 많지만 현실에서 실천이 어려운 것이다. 이론으로는 배울 수 없고 경험에 의해서 밖에 배울 수 없기 때문이다. 책과 이론은 약간의 도움을 줄 뿐이다.

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

전지전능한 슈퍼 개발자의 역설

필자는 여러 소프트웨어 회사에서 많은 개발자를 만난다. 그러면 보통 회사에 한두명씩 전지전능한 슈퍼 개발자가 있는 것을 보게 된다.

이들은 코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반관리, 전략 수립 등 엄청나게 많은 일을 한다. 직책은 대부분 팀장이다.

여러분의 회사에도 이런 개발자가 한두명씩은 있을 것이다. 이들이 여러분의 롤모델인가? “나도 그런 전지전능한 개발자가 되어야지”라는 다짐을 하는가? 아니면 혹시 여러분이 이런 전지전능한 개발자인가?

이렇게 많은 일을 하는 개발자가 One man company에만 있는 것이 아니다. 개발자가 수백명이 넘는 회사에서도 드물지 않게 만날 수 있다.

이런 회사에서는 모든 길이 로마로 통하듯이 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결이 된다. 이 전지전능한 개발자가 모든 기술과 정보를 꽤 뚫고 있어서 문제가 발생하면 즉시 해결해주고 회사는 그럭저럭 굴러간다. 이 개발자가 나가면 회사는 망할 것만 같다.

이런 현상이 좋아보이는 사람도 있을지 몰라도 회사는 인력적으로 큰 리스크를 안고 있는 것이고 뛰어난 개발자를 가장 가치 있는 일에 제대로 사용하지 못하는 손해를 입고 있는 것이다. 전지전능한 개발자는 본인이 선택을 해서 그런 위치가 된 것은 아니다.

회사가 성장과정에서 적당한 때 조직을 전문화하고 변화를 꾀했어야 하는데 그냥 달려만 오다보니 능력이 좋은 개발자가 이거 저거 다 떠 안게 되면서 이런 현상이 벌어지게 되었다. 좀더 잘할 수 있는 분야에 집중했다면 본인 역량 면으로도, 미래 가치면으로도 훨씬 좋은 결과를 가져왔겠지만, 지금은 회사의 맥가이버가 된 상황에 만족할 수 밖에 없다.

다른 회사로 가면 지금의 가치는 대부분 사라지고 만다. 개발자 본인에게도 안타까운 상황이다.

어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능하다. 아주 작은 회사에서나 그렇게 하는 것이다. 이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 한다. 모든 일을 잘한다는 것은 애초에 불가능하다. 특히 중요한 일은 주 업무인 개발을 할 시간이 확 줄어 든다는 것이다.

대부분의 이들은 예전에는 뛰어난 개발자였다. 하지만, 개발 이외 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됐다. 그리고 각 일의 Switching cost가 만만치가 않다. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거다.

심지어는 그런 개발자에게 테스트, 고객 응대, 기술 지원까지 하라는 것은 100원주고 20원짜리 일을 시키는 것과 같다. 비효율적일 뿐만 아니라 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못한다.

이런 슈퍼 개발자는 다른 소프트웨어 회사에 가면 가치가 확 떨어진다. 분야가 달라지면 Domain Knowledge 관련 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 된다. 관리자가 되어야 하나 고민이 많다. 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되는 경우도 있다.

회사는 이들에 대한 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 된다. 이들이 등돌리면 회사는 휘청거린다.

이것이 개발자 탓일까? 아니면 회사 탓일까? 회사 탓이다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야한다. 그런데 개발자가 맨땅에서 북치고 장구치고 다 하고, 회사에서는 이를 방치하다보니 이렇게 되는 것이다. 하지만 많은 경영자들은 개발자가 잘 하니 그냥 그렇게 개발자가 다 해야 하는 것으로 아는 경우가 매우 많다.

그럼 어떻게 해야 할까?

개발자가 개발에 전념할 수 있도록 항상 여건을 조성해줘야 한다. 회사가 아주 작아서 어쩔 수 없이 개발자가 여러가지 일을 겸해서 하고 있다고 하더라도 회사가 조금만 커져도 개발자의 일에서 개발업무가 아닌 일을 떼어낼 수 있도록 준비를 해야 한다.

조직이 조금 커지면 테스터를 뽑고, 기술지원인력을 보강하는 것이 좋다.

개발자 10명이 이거 저거 모든 일을 다하는 것보다. 개발자 7명에 테스터2명, 기술지원 인력 1명인 조직이 더 낫다. 개발자가 개발에 더 집중할 수 있고 개발자 10명이서 하는 일보다 더 많은 일을 할 수 있다. 물론 조직과 더불어 프로세스, 기반시스템, 개발문화도 뒷받침이 되어야 하지만 이는 기본으로 생각하자.

이렇게 조직이 분리되고 개발자가 개발에 전념을 할 수 있어야 개발이 좀더 체계적으로 진행된다. 다른 조직의 인력과 협업을 하기 위해 필요한 최소한의 문서도 만들어야 하고 프로세스도 자연스럽게 필요하게 된다. 커뮤니케이션을 위한 기반시스템도 잘 활용하게 된다.

조직이 더 커지면 분리해야 하는 역할이 점점 많아진다. 즉 조직이 세분화 된다. 이는 회사 규모에 따라서 다르니 이 일이 개발자가 해야 하는 일인지 잘 생각해보고 결정하면 된다.

여기서 개발자의 업무를 모두 나열할 수는 없지만 회사에서 개발자가 개발에 집중할 수 있도록 노력하는 일은 대단히 중요하다. 개발자가 잘 해낸다고 그냥 방치하면 안된다. 개발자는 개발을 잘할 때 회사의 보물이 되는 것이다. 다른 일들은 여건이 되는 대로 다른 전문가에게 맡기도록 하자.

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

한국에서 외국인 개발자가 일하기 어려운 이유

소프트웨어 회사의 경영자는 항상 개발자 수급을 고민한다. 우수한 인재를 싸게 쓰고 싶지만 좋은 개발자를 찾기도 어렵고 인건비가 여간 비싼 것이 아니라고 생각한다. 물론 개발자 입장에서는 많지 않지만 경영자는 반대 입장이다.

그러다 보면 저렴하고 우수한 외국인 개발자를 쓰고 싶은 욕구가 생겨난다. 중국이나 인도 개발자들은 평균적으로 인건비가 국내 개발자보다 저렴하고 실력도 뛰어나다. 그래서 실제로 많은 회사들은 외국인 개발자 채용이나 현지 개발센터를 설립하는 일들을 그동안 많이 해왔다.

경우에 따라서는 인건비 이슈가 아닐 수도 있다. 외국인 개발자를 활용하는 것이 국내 개발자에게 들어가는 비용보다 더 많이 들어가기도 한다. 그럼에도 불구하고 개발 인력 수급 문제 해결과 조직의 Global 문화 흡수 등 여러가지 이유로 외국인 개발자 활용 전략을 추진해 왔다. 

나름 성과를 내고 있는 회사도 있으나 대부분은 실망이 큰 것이 사실이다. S사 같은 경우는 그룹차원에서 현지 개발자를 채용하여 각 계열사로 정책적으로 외국인 개발자를 배치하고 있으나 경영진의 바람과 외국인 개발자와 같이 일하는 국내 개발자와 평가는 차이가 꽤 크다. 뛰어난 개발자를 데려다가 단순 코더로 전락 시키기도 하고 문화적인 충돌로 인해서 거의 활용을 못하는 경우가 허다하다.

그럼 미국 실리콘밸리에서 일하는 인도, 중국 개발자들도 똑같은 상황일까? 전혀 그렇지 않다. 유독 우리나라에서 외국인 개발자들과 같이 제대로 일을 못하는 이유는 언어 장벽외에도 여러가지가 있다. 이것을 잘 생각해 보면 바로 우리들이 가지고 있는 문제를 고스란히 보여주기도 한다. 

우리는 왜 외국인 개발자와 제대로 같이 일을 하지 못할까?

1. 언어의 장벽

요즘은 영어를 잘하는 직원들이 많지만 소프트웨어 개발자들 중에는 영어를 잘하는 비율이 좀 낮은 것 같다. 생활영어 정도를 할 줄 안다고 해도 외국인 개발자와 회의나 리뷰를 제대로 하기 어렵다. 대화가 가능해도 훨씬 많은 노력을 들여야 하기 때문에 부담이 커진다. 특히 인도 영어는 더욱 알아 듣기 힘들다. 

2. 문서

외국인 개발자와 같이 일하려면 문서를 기반으로 일해야 한다. 대부분은 프로세스, 스펙 등에 익숙하기 때문에 우리나라와 같이 대충 말로 때우거나 지시하는 환경에 익숙하지 않다. 의사 소통도 쉽지 않은데 매번 말로 지시하고 확인하는 일이 쉽지 않다. 

3. 번역

외국인 개발자와 같이 일하려면 문서를 영어로 작성해야 한다. 모든 문서를 영어로 작성하면 우리나라 개발자가들이 힘들기 때문에 영어로만 작성하기도 어렵다. 한국어로 작성하고 영어로 번역을 해도 보통 어려운 일이 아니다. 최신 문서를 유지하기도 어렵고 싱크가 맞지 않는다. 보통 일이 아니다. 스펙을 제대로 작성했으면 한번만 번역을 하면 되는데 스펙을 제대로 작성하는 경우도 많지 않고 쉽게 바뀌는 일이 흔하기 때문에 매번 번역에 어려움이 있다.

4. 문화

외국인 개발자들이 한국에서 개발을 하면 문화적인 충격이 만만치 않다. 회사와 가정이 똑같이 소중한 외국인 개발자에게 무조건적인 헌신을 요구하는 경우가 많은데 상당히 어려움을 겪는다. 특히 야근 강요와 무리한 일정 요구는 많은 트러블을 일으킨다. 가끔은 후진국 사람이라고 무시하는 경향도 있다.

5. 전문가

우리나라 개발환경은 전문가가 제대로 일하기 어려운 환경이다. 보안 전문가를 데려다가 제대로 활용하지 못하기도 한다. 전문가들이 우리나라에 오면 그냥 똑같은 개발자가 되는 경우가 흔하다. 전문가가 제대로 역할을 하려면 스펙도 제대로 작성되어야 하고 합리적인 개발문화가 있어야 한다.

결론 

이러한 현상은 외국에 외주를 줄 때도 비슷하다. 외국에 외주를 주거나 개발센터 설립등이 쉽지 않은 이유이다.  스펙을 제대로 작성하고 수평적인 조직구조 등 제대로된 개발문화를 가지고만 있다면 이 또한 해결될 수 있다.

스타트업과 궁합이 맞는 개발자

소프트웨어 스타트업의 두 가지 필수 요소를 꼽으라면 좋은 아이디어와 뛰어난 개발자이다.

개발자가 스스로 창업을 하기도 하지만 좋은 아이디어를 가지고 개발자 파트너를 물색하기도 하고 본인이 개발자라고 하더라도 추가로 개발자 파트너를 찾기도 한다. 좋은 개발자는 스타트업의 성공의 중요한 열쇠이지만 구하기 쉽지 않다. 또한, 어떠한 개발자가 스타트업에 꼭 필요한 개발자인지 판단하기 어렵다. 실력이 뛰어나 보이지만 막상 일을 그르치는 개발자도 있다.

만약 스타트업을 위해서 개발자 파트너를 찾고 있다면 어떤 조건이 필요한지 알아보자. 물론 일반적인 소프트웨어 회사에서 개발자를 선택하는 방법과 같은 조건도 있지만 사뭇 다른 요소도 있다.

1.특정 분야 유경험자?

개발자 채용이나 파트너 선택에서 흔히 하는 실수 중 하나가 특정 분야 유경험자의 가치를 너무 높게 보는 것이다.

물론 해당 분야의 경험이 풍부하다면 바로 실무에 투입되어서 일할 수 있는 장점이 있다. 스타트업이 아니고 이미 성숙된 회사라면 대부분 기존 제품 개발과정에서 변변한 기록도 없고 뒤죽박죽이라서 해당 분야에 경험이 풍부한 사람이 아니면 제대로 일할 수 없는 경우가 대부분이다. 그렇지 않은 경우도 있지만 드물다. 또한 개발자들이 많이 들어왔다 나갔다 하므로 무조건 당장 써먹을 수 있는 개발자를 선호한다.

하지만 스타트업이라면 얘기가 좀 다르다. 우선, 개발자 파트너를 특정 분야 유경험자로 한정 지으면 범위가 너무 좁아진다. 소프트웨어에는 수천 가지의 Domain이 있는데 그렇게 범위를 좁히면 좋은 개발자를 구하기 힘들어진다.

오랜 기간 한 분야에만 종사하고 있는 개발자들 중에는 의외로 소프트웨어 개발 능력은 형편 없는 경우가 매우 많다. 대신 Domain 지식만 풍부해서 해당 분야에서 조금만 벗어나도 별 쓸모가 없어지곤 한다. 특히 스타트업은 아직 개발해야 할 분야가 고정 되지 않았기 때문에 특정 분야 유경험자만 찾다가는 골치덩어리 개발자를 떠안게 될지도 모른다.

특정 분야 유경험자보다는 무조건 뛰어난 개발자를 골라야 한다. 분석, 설계, 구현 능력이 뛰어난 개발자가 분야가 바뀌어도 빠른 시간 내에 실력을 발휘할 수 있다. 처음에는 유경험자보다 약간 느릴 수 있지만 역전되는 것은 순식간이다.

실리콘밸리를 보더라도 개발자들이 특정 분야에 국한하지 않고 어떠한 소프트웨어 회사라도 마음대로 옮겨 다닐 수 있는 이유이다.

실리콘밸리에서 개발자를 채용할 때 특정 분야 유경험자보다는 문제 해결 능력이 뛰어난 개발자를 뽑는 것이 그 이유이다. 심지어는 사용하고 있는 개발 언어의 경험을 보지 않는 경우도 있다.

물론, 특정 분야 유경험자가 꼭 필요한 분야도 있기는 하지만 이는 일반적인 케이스가 아니므로 여기서는 언급하지 않는다.

2. 경험이 많은 개발자?

흔히 경험이 많은 개발자가 실력이 뛰어날 것으로 생각하는데 우리나라에서는 통하지 않는다. 물론 경험 많은 개발자 중에서 뛰어난 개발자가 꽤 있는 것은 사실이지만 기대하고 있는 것만큼 많지가 않다.

그 이유는 우리나라 개발 환경이라는 것이 막노동판과 비슷해서 초급 때 벽돌 100장 쌓던 사람이 고참이 되면 200장 쌓을 수 있는 식이다. 공사판 10년 경험이면 멋진 빌딩을 설계할 수 있을 것으로 기대하는 것과는 거리가 멀다. 제대로 된 분석, 설계 경험이 부족하고 개발문화라는 것이 너무 척박해서 오랫동안 개발을 한다고 해서 실력이 많이 향상되지 않는다. 단지, 숙달되고 능숙해지며 해당 분야의 지식이 주로 쌓인다. 여전히 분석, 설계 역량은 미천하고 개발문화는 잘 모르는 경우가 허다하다.

스타트업에는 차리라 경험이 적더라도 두뇌가 뛰어난 개발자가 필요하다. 경험이 너무 많은 것보다 경험은 적당하지만 머리가 좋은 개발자가 다양한 도전에서 뛰어난 결과물을 만들어낸다.

또한 경험이 너무 많으면 수많은 잘못된 문화와 관행에 너무 젖어서 스타트업에서 필요한 혁신을 해내지 못한다. 정말 뛰어난 두뇌를 가지고 있다면 경력이 1,2년이라도 전혀 문제가 되지 않는다. 기존 조직의 개발 문화에서는 별로 배울 것이 없기 때문이다. 기존 환경에서 배운 것이 적은 개발자들이 새로운 스타트업에서 더 좋은 개발문화를 정착할 가능성이 더 높다. 기존에 잘못된 관행에 젖어 있는 수많은 개발자들은 이를 부정하고 화를 낼 수도 있지만 그것이 곧 반증이다.

3. 빨리 개발하는 개발자?

스타트업은 다양한 시도와 빠른 전략이 매우 필요하다. 그래서 빨리 개발을 하는 개발자를 선호하지만 빨리 개발하는 개발자보다는 확실하게 마무리를 잘 해내는 개발자가 더 필요하다. 이는 개발자의 성향과 관련이 있다.

어떤 개발자는 첫 번째 프로토타입은 매우 빨리 만들어내지만 마무리를 제대로 못하는 개발자가 있고 약간은 느려 보이지만 착실하게 개발을 해서 꼼꼼하게 마무리를 하여 제품을 제대로 만들어 내는 개발자가 있다. 이러한 성향은 쉽게 바뀌는 것이 아니므로 일당백을 해야 하는 스타트업에서는 확실하게 마무리를 잘하는 개발자가 더 필요하다. 그렇게 개발하는 것이 최종적으로는 더 빠르다.

같이 일을 해본 경험이 있다면 이러한 개발자를 가려낼 수 있을 것이다.

4. 개성이 강한 개발자?

스타트업에서는 개발자의 실력보다 더 필요한 것이 과연 얼마나 뜻을 하나로 모아서 나아갈 수 있는가 이다. 이 또한 개발자의 성향과 관련이 있다. 회사의 정책이나 비전에 적극적으로 따르는 개발자가 있는가 하면 부정적이고 따로 행동하는 개발자가 있다. 회사의 정책과 비전을 따르지 않는 개발자는 실력이 아무리 뛰어나도 스타트업의 파트너로는 적당하지 않다. 실력만 보고 동참을 시켰다가 두고두고 고생을 하게 될 것이다.

개발자 하나하나가 영향력이 매우 큰 스타트업에서는 특히 중요한 조건이다.

5. 개인 시간이 소중해?

스타트업에서 꼭 필요한 것 중 하나가 멤버들의 헌신이다. 일반 회사에서 항상 야근을 강요하는 그런 헌신이 아니다. 회사에 시간과 노력과 위험부담을 같이 투자한 파트너들로서 미래의 결실을 공유하고자 하는 것이므로 헌신은 매우 필요하다. 따라서 헌신할 수 없는 개발자는 고려하지 않는 것이 좋다.

나이, 가정, 주변 환경이 헌신을 가로막는 경우도 고려를 해야 한다. 가장 중요한 것은 정신적으로 얼마나 헌신을 할 자세가 되어 있는가 이다. 이는 하루 아침에 판단할 수는 없고 스타트업의 중요한 개발자 파트너 구하기 위한 것이라면 꾸준히 관찰을 해야 알 수 있는 요소이다.

아이디어가 스타트업의 중요 요소이듯이 좋은 개발자도 꼭 필요한데 겉모습만 보고 대충 채용을 했다가는 차라리 시작을 안 하느니만 못한 경우가 많다. 몇 년 후에 창업을 생각하고 있다면 주변의 개발자 중에서 위 다섯 가지 조건이 맞는 개발자를 꾸준히 물색해둬야 한다. 그리고 친하게 지내라. 그 중에 한 두명이 당신의 스타트업 파트너가 될 것이다.

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

Technical Career Path를 보장하는 방법

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

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

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

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

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

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

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

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

셋째, 공정한 평가이다.

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

넷째, 적절한 대우이다.

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

다섯째, Career Path 제공이다.

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

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

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

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

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

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

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

무늬만 개발자

우리나라에서 소프트웨어를 개발한지 10년이 넘은 개발자 중에서 진짜 개발자는 생각보다 적다. 15년쯤 지나면 자신은 스스로를 개발자라고 생각할지 몰라도 진짜 개발자인 경우는 급격히 줄어든다. 대부분은 개발과 관리의 경계에서 애매한 포지셔닝을 하다가 다시는 개발로 돌아오지 못하곤 한다.

그럼에도 자신은 개발자라고 착각을 하는 경우가 많다. 또는 자신을 Architect라고 우기기도 한다.

선임급 개발자를 채용하기 위해서 인터뷰를 하면 이런 "개발자가 아닌 무늬만 개발자"를 자주 볼 수 있다.

매일 수많은 회의에 쫓겨 다니고, 온갖 보고서를 만들고, 수시로 경영진에게 보고하고, 팀원들 관리하고 평가하느라고 시간을 다 보내면서, 스스로는 개발에 관해서 아는 것은 많다고 생각해서 개발할 때마다 간섭하고 스스로 뛰어난 Architect라고 생각한다.

이런 사람들은 개발을 좀 안다고 해도 절대로 개발자가 아니다. 개발과 관리의 차이에 대한 개념도 희미한 상태이다. 대부분은 개발자로 다시 돌아갈 수 없는 상태이다.

절대로 "개발"과 "관리" 둘 다 잘할 수는 없다.

우리나라 대부분의 기업에서 본부장, 부문장, 부서장쯤 되면 이러한 상태에 이르게 된다.  그래도 팀장급에서는 개발자의 모습을 아직도 간직하고 있는 경우가 종종 있다.

하지만 팀장급 이상으로 올라가게 되면 개발자이고 싶은 관리자가 되게 된다. 물론 외형적으로도 완전히 관리자를 선언한 사람도 있겠지만, 여전히 개발자이고 싶은 사람들도 매우 많다.

이렇게 되는 결정적인 이유는 경영자의 개발조직 관리에 대한 오해에서 비롯된다. 경영자는 개발조직을 관리하는 관리자는 개발을 매우 잘 알아야 하기 때문에 가장 뛰어난 개발자들이 관리를 하는 것이 옳다고 생각한다. 그래서 경험 많은 선임 개발자들에게 본부장, 부문장, 부서장을 맡기곤 한다.

개발조직을 관리하는 관리자는 개발에 대해서 개발자만큼 잘 알 필요가 없다. 개발자가 개발에 대해서 아는 정도와 관리자가 알아야 하는 정도는 엄청나게 다르다. 그런데 경영자는 이 둘을 같은 것으로 착각하곤 한다.

개발을 잘하는 개발자는 관리는 전혀 하지 않고 개발에 몰두할 때 가장 높은 가치를 창출한다. 경영자의 착각 속에 개발자는 점점 잘 하지도 못하는 관리 일에 치중하게 된다. 자연스럽게 회사는 개발 파워를 잃게 된다. 그럼 남는 것은 정치적인 경쟁밖에 없게 된다. 불쌍한 개발자들이다.

이렇게 관리자화 된 개발자들은 이직도 곤란하게 된다. 동일한 분야가 아니라면 이직을 해도 회사에 도움이 별로 안된다. 다른 분야로 이직을 한다면 관리 능력이 중요한데 사실 관리는 전문 관리자보다 훨씬 못하기 때문이다. 이미 전문 개발자는 아니기 때문에 다른 분야에서 개발자로서 활약하기도 어렵다. 정말 어중간한 위치기 된다.

결국 그 회사에서 관리자의 길을 걷거나 선택할 옵션이 별로 없게 된다.

물론 개발자 본인이 스스로 이런 선택을 하지 않았지만 결국 이런 결과에 이르는 것이 우리나라 개발자들의 안타까운 현실이다.

개발자가 원하고 실력이 된다면 은퇴할 때까지 개발자의 경력이 보장되는 외국의 상황은 부러울 따름이다.

2008/12/03 - [개발조직] - 우리나라 소프트웨어 회사에는 Technical career path가 없다.

주변의 환경을 무시하고 스스로 개발자로 계속 살아남는 다면 대단한 결심이 필요할 것이다.

하지만 결국 이런 개발자들이 언젠가는 대우를 받을 수 있을 것이다. (당장은 글쎄 …)

그런 환경을 만들고 싶다.

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