한국의 경영자들은 가짜 영웅을 원한다.

개발자들의 고충 중에는 다음과 같은 것이 이다.

"제대로 하고 싶은데 그러면 경영자의 눈에 들지 않는다"는 것이다.

스펙도 제대로 작성하고 리뷰도 하고 싶은데 경영자는 문서를 작성하고 있으면 노는 줄 알고 제대로 하는 것보다는 빨리하기를 원한다고 한다.

실제로 많은 경영자들이 Software 개발에 대한 이해 부족으로 회사에 진정으로 필요한 개발자가 어떠한 사람인지 잘 모른다. 그래서 진짜 영웅들이 가짜 영웅에 밀려서 대우를 못받는 경우가 많다.

그럼 회사에서 꼭 지켜야 하는 가짜 영웅과 회사를 좀먹는 가짜 영웅은 어떻게 다른지 알아보자.

가짜 영웅	진짜 영웅
말이 많고 잘 떠버린다.  자신만 믿으라고 한다.	묵묵히 일한다. 잘하는 것이 눈에 잘 안띈다.
첫번째 버전을 엄청나게 빨리 만들어 낸다.	합리적인 일정을 제시하고 차근차근 개발한다.
프로젝트 마무리를 잘 못한다. 다른 사람들이 마무리를 해준다.  잽싸게 다른 프로젝트로 넘어간다.	자신이 맡은 프로젝트는 책임감을 가지고 끝까지 마무리를 잘 한다.
회사의 규정을 잘 안지킨다. 자신은 특별대우를 받아야 한다고 주장한다. 회사의 규정외로 높은 대우를 받기를 원한다.	회사의 정책과 규칙을 잘 따른다.
자신이 그만두면 회사가 망하는 줄 안다.  또 그렇게 주장한다.  실제로 회사를 그만두면 회사가 휘청한다.	당장 퇴사를 해도 아무 문제가 없을 만큼 문서화도 잘하고 후배들도 잘 양성해 놓았다. 실제로 퇴사를 해도 회사가 문제 없이 돌아간다.
자신의 지식이나 자신이 개발한 제품의 정보에 대해서 타인과 공유를 잘 안한다.	공유를 잘 한다.  스펙 등 문서를 잘 작성하고 다른 개발자와 업무를 잘 나눠서 일한다. 타인, 특히 후배들이 작성한 문서나 코드 리뷰를 잘 한다.
유지보수 비용이 점점 더 많이 들어가는데 이는 유지보수 인력이 개발을 잘 못해서 그런 것이라고 주장한다.	유지보수에 비용과 시간이 별로 많이 안들어가도록 제품의 Architecture를 잘 만들어 놓았다.
회사의 미래를 위해서 이런 사람은 최대한 빨리 짤라 버려야 한다.  하지만 기존에 벌려 놓은 것이 많아서 당장 짜르기도 어렵다.	회사의 미래를 위해서 이런 사람은 높은 연봉을 주고라도 꼭 잡아야 한다.

회사에서 어떤 사람을 지킬 것인지 잘 생각해야 한다.

SW개발자의 미래

개발이 좋아서 SW개발자가 된 사람들이 한 5~7년 개발을 하다보면 흔히 미래에 대해서 생각하게 되고 불확실한 미래를 불안해하곤 한다.

특히 대부분의 회사에서 개발자의 Career를 보장해주지 않기 때문에 막연히 팀장이 되기도 하고 다른 직종으로 옮기기도 한다.

그러다보니 전문성있고 가치가 높은 개발자의 경험과 지식이 묻혀버리기 일쑤이고 회사는 기술력이 축적되지 못하게 된다.

개발자의 Career Path 상에는 어떠한 직종들이 있는지 알아보자. 자신의 역량과 성향에 따라서 Path를 정하면 좋을 것이다. 물론 회사에서 그리고 사회 전체적으로 개발자의 Career Path를 보장해 주는 방향으로 변하면 좋겠다.

Senior Engineer, Chief Scientist

한마디로 고참개발자이다. 신참때는 주로 코딩을 많이 하고 버그를 잡았으면 이제는 분석, 설계에 더 많은 시간을 소비하고 Peer Review에 많이 참석한다. 

자신의 팀의 프로젝트만 관심을 가지는 것이 아니고 다른 팀의 프로젝트 리뷰에도 참석하여 기여를 한다.

흔히 Architect라고 불리기도 하고 여전히 코딩도 한다. 

외국에서는 60세가 넘는 Software엔지니어를 볼 수 있기도 하다. 

제대로 된 엔지니어라면 Domain과 상관없이 어느 분야로든지 이직이 가능하다.

CTO

회사의 최고 기술 책임자이며 많은 개발자들의 Role model이다.

회사의 경영에 관여를 하지만 관리는 하지 않는다.

장기기술전략, 실행전략, 아키텍처, 구현, 인프라구조 정립, 프로세스 등 개발에 관하여 기술적인 것이라면 모두 책임진다.

왕년에 코딩을 했다는 것으로는 CTO가 될 수 없다. CTO라면 현재도 코딩을 할 수 있어야 한다. 바쁘고 코딩의 Value가 낮기 때문에 안하는 것 뿐이지 분석/설계/코딩을 현재도 모두 할 수 있어야 한다.

소프트웨어 회사의 최고봉이라고 할 수 있다.

SCM, Build and Release Engineer

소프트웨어 회사에는 몇가지 전문적인 분야가 있다. 형상관리, 빌드, 릴리즈, 팩키징 등이 그것이다. 처음에는 개발자들이 개발과 더불어 이런 업무도 같이 수행하지만 회사가 커지면 전문적인 업무로 떨어져 나온다. 몇명이 전담을 해도 될만큼 충분히 일이 많고 취미로 해도 될만큼 일이 쉬운 것이 안다. 또한 개발 능력도 필요하다.

대단히 전문적인 업무이고 이러한 개발외의 환경이 잘 되어 있어야 개발자들이 개발에 집중할 수 있고 업무 효율이 오르게 된다.

개발자 중에는 프로젝트보다 이러한 전문적이고 SW공학적인 업무에 관심을 가지는 사람들이 있다. 이 영역에서 실력을 닦으면 이직시에도 이 전문성을 활용할 수가 있다.

Technical Marketer

제품을 기획할때는 비즈니스적인 요소, 기술적인 요소가 모두 고려된다. 그중에서 기술적인 부분은 일반 기획자들이 속속들이 알기가 어렵다. 따라서 기술을 아주 잘아는 테크니컬 마케터가 기술적인 부분을 담당하게 된다. 경쟁사의 제품을 분석할 때도 단순히 기능이 되는지 O, X만 체크 하는 것이 아니고 기술적인 부분까지 검토를 해서 적용된 기술도 파악할 수 있다. 

새로 기획하는 제품의 기술적인 비전을 수립하고 마케팅과 개발자의 연결고리 역할도 수행한다.

Technical Supporter

개발자 중에는 진득히 않아서 개발하는 것을 좀 쑤셔하고 싫어하는 사람들이 있다. 여러 경쟁 제품을 써보기를 좋아하고 새로운 제품이 나오면 먼저 써보려고 하고 동료들의 시스템에 문제가 생기면 누구보다 빠르게 해결해 주는 능력을 가지고 있다.

이런 경우 개발 경력과 지식을 활용하여 기술지원업무를 수행할 수 있다. 회사의 제품에 대해서 기술적으로는 누구보다 속속들이 잘 알기 때문에 수준 높은 지원도 가능하다.

외향적인 사람들에게 어울리는 직종이다.

QA Engineer/Manager

개발자 출신으로 QA 엔지니어나 관리자가 될 수 있고 개발 능력을 활용하여 테스트 관련 툴을 개발할 수 있다. 

개발 경험이 있는 것은 장점으로 작용하면 계획적인 삶을 살 수 있는 장점도 있다. 물론 우리나라에서는 똑같이 무지막지한 야근을 해야 하는 경우가 많다.

Project Manager

기술자 트랙과 관리자 트랙의 중간쯤 되는 포지션이다. 프로젝트를 책임지고 맡아서 관리하는 역할로서 General Manager가 되는 중간 과정이 될 수도 있다. 

General Manager

기술과는 관련이 없는 일반 관리자다. 기술에서는 손을 떼는 것이다. 우리나라의 개발팀장과는 또 다르다. 개발팀장이 오래되서 더이상 개발을 하지 않고 관리를 하면 General Manager라고 볼 수 있다.

기술적인 결정은 하지 않는다. 하지만 과거에 개발 좀 해 봤다고 기술적인 결정을 자기가 해버리면 월권이라고 할 수 있다.

일단 일반 관리자로 넘어오면 다시 엔지니어로 돌아가는 것은 불가능 하다. VP Engineering으로 성장하는 Track이다.

VP Engineering

우리말로는 "기술부사장", "연구소장" 정도가 되겠다. CTO와는 완전히 다르다. CTO는 관리를 하지 않지만 VP Engineering은 관리자다. 개발관리 총책임자 쯤 된다. 개발자나 CTO가 하는 기술적인 얘기의 용어들을 거의 알고 있고 개발프로세스가 어떻게 돌아가는지도 잘 안다.

하지만 기술적인 결정을 하지는 않고 관리만 한다.

우리나라에서는 흔히 VP Engineering을 CTO라고 불러서 오해를 하는 경우가 많다.

Domain Expert

소프트웨어 개발 역량보다는 업무 지식에 치중하는 사람들이다. 증권사, 은행, 회계, 토목, 건설, 기계, 예술 분야의 소프트웨어를 개발하려면 해당 영역의 지식과 경험이 많이 필요하고 소프트웨어 기술도 어느 정도 알아야 한다. 개발 경험을 가지고 해당 산업 지식을 쌓으면 도메인 전문가가 될 수 있고, 이 경우 해당 분야로만 이직이 가능하다.

Restaurant Owner

소프트웨어 개발에 염증을 느끼거나 비전을 찾지 못하면 소프트웨어 업계를 완전히 떠나는 것도 한 방법이다. 

좋은 프로그래머가 되는 24가지 방법

1. 프로그래밍에 열정이 있어야 한다. 열정이 없고 즐기지 못하면 평생하기 어려운 일이다.
2. 프로그래밍 기초 원리를 완전히 이해해야 한다. 원리를 모르면 근본적인 해결을 할 수 없다.
3. 문제 해결 능력을 키워야 한다. 개발자의 가장 중요한 핵심 역량이다.
4. 창의적인 사람이 되라. 대부분의 좋은 해결책은 창의력에서 나온다.
5. 다른 사람의 코드를 이해할 수 있는 능력을 키워야 한다. 다른 사람의 코드에서 배운다.
6. 수학을 잘 해야 한다. 수학을 못하면 값싼 쉬운 개발 밖에 못한다.
7. 좋은 커뮤니케이션 스킬을 갖도록 노력해야 한다. 프로그래밍은 컴퓨터와 얘기하는 것이 아니고 사람들과 얘기하는 것이다. 
8. 협업 능력을 키워라. 다른 사람과 일을 나눠서 할 수 있어야 내 몸값이 비싸진다.
9. 논쟁(debate) 능력을 키워야 한다. 고급 개발자가 될 수록 토론하는 일이 늘어날 것이며, 좋은 토론이 좋은 소프트웨어를 만든다.
10. OOP를 완전히 이해해야 한다. 협업이 더욱 원활해질 것이다.
11. 남이 이해할 수 있는 문서를 작성할 수 있어야 한다. 문서 작성은 평생 따라다니는 중요한 업무이다.
12. 적어도 한가지의 개발언어는 완전히 마스터를 해야 한다. 마스터한 언어로는 어떠한 문제도 풀 수 있어야 한다.
13. 적어도 한가지의 스크립트 언어를 구사할 수 있어야 한다. 간단한 툴은 쉽게 만들어 쓸 수 있다.
14. 비즈니스를 이해해야 한다. 훌륭한 아키텍트가 될 것이다.
15. 주변에 나보다 훨씬 뛰어난 프로그래머를 둬라. 끊임 없이 배울 수 있다.
16. 끊임 없이 새로운 기술을 익혀라. 전쟁에서 쓸 무기가 많아질 것이다.
17. 습관적으로 주석을 달아야 한다. 주석은 남을 위해서 다는 것이 아니고 프로그래밍의 일부이다.
18. 남이 이해하기 쉬운 코드를 작성해야 한다. 나중에 내 발목을 잡지 않을 것이다.
19. 리뷰와 친해져야 한다. 평생 리뷰를 하며 사는 것이 프로그래머의 인생이다. 리뷰를 하지 않으면 발전하기 어렵다.
20. 건강을 유지해라. 건강을 잃으면 실력이고 뭐고 다 필요 없다.
21. 좋은 의자를 사라. 건강을 지켜주고 효율을 높여준다.
22. 인생을 즐길 줄 알아야 한다. 프로그래머로 오래 지속하고 싶으면 인생 자체를 즐기는 다양한 방법을 익혀야 한다.
23. 소프트웨어 공학을 익혀라. 주먹구구식 개발에서 벗어나게 해주고 개발을 즐겁게 해줄 것이다.
24. 높은 연봉을 받일 수 있도록 꾸준히 노력하라. 위 23가지 방법이 도움이 될 것이다.

망할 회사로 옮겨타는 방법

많은 개발자들이 현재 회사에서 희망을 느끼지 못하고 회사를 옮깁니다. 그런데, 옮긴 회사도 별반 다를 바가 없는 경우가 많습니다. 그럼 어떤 회사로 주로 옮기게 될까요? (사실 좋은 회사 찾기 정말 힘듭니다.)

• 망하지 않을 회사? (내가 다니는 동안에는 ...)
• 정말 재미있는 일을 할 수 있는 회사 또는 좋은 사람과 같이 일할 수 있는 회사?
• 이전 회사보다 연봉을 많이 주는 회사? (훨씬 많이)

이 모두 이직하는 회사의 조건들입니다. 하지만 아무리 재미있는 일을 할 수 있고 연봉이 많아도 회사가 망해버리면 소용이 없습니다.

망하지 않을 회사는 왠만해서는 망하지 않을 큰 회사이거나 작지만 알찬 회사일 것입니다. 큰 회사들이야 S사나 N사 등 다들 알고 계실 것입니다. 연봉도 작은 회사보다는 많죠. 이런 회사에서 일까지 재미 있다면 금상첨화지만 욕심 같네요. 주로 안정성 때문에 선택을 하게 되겠죠.

큰 회사도 좋지만 저라면 작지만 재미있게 일할 수 있고 성장 가능성이 높은 회사를 선택하겠습니다. 그럼, 작은 회사 중에서 망하지 않을 회사를 어떻게 고를 수 있을까요? 벤처투자가들이 이것을 알았다면 다들 떼돈을 벌었겠죠?

실제로 꽤 유명하고 규모도 큰 회사가 속은 썩어 있고 망하는 길로 가고 있는 회사는 의외로 많습니다.

제 블로그에 예전에 등록한 소프트웨어 회사의 개발 역량 평가표를 통해서 평가를 해보면 약간의 도움이 될 것입니다. 옮기려는 회사 내부에 이를 평가해줄 친구가 있다면 가능하겠지만 그렇지 않다면 알아낼 방법이 없겠죠. 물론 개발 역량이 회사의 성공을 위한 필요충분 조건은 아니지만 필요조건이기는 합니다.

회사의 내부 정보를 알아 낼 수 없다면 경영자를 살펴보는 것이 좋겠습니다. 대부분의 소프트웨어 회사가 특정 단계를 넘지 못하고 꺾이는 결정적인 이유는 경영자의 마인드에서 찾을 수 있습니다. 소프트웨어 회사에서 경영자가 소프트웨어를 이해하지 못한다면 특정 규모 이상으로 성장할 수 없습니다. CEO가 소프트웨어에 대한 이해가 부족하면 CTO가 이를 대신해주는데 우리나라 대부분의 소프트웨어 회사는 CTO가 없거나 CTO가 있어도 CTO역할을 하지 못하고 있습니다.

따라서 회사를 옮길 때 CEO 또는 CTO가 소프트웨어에 대해서 어떤 생각을 가지고 있는지 파악을 해보면 조금더 즐겁게 일할 회사, 그리고 앞으로 더 성장할 수 있는 회사로 옮길 가능성이 조금더 높아질 것입니다. 

세계 최초!

소프트웨어 업계만큼이나 "세계 최초"라는 수식어를 자주 듣는 곳도 드물 것입니다.

이러한 수식어가 붙는 이유는 세간의 이목을 끌기 위함이 명백합니다.

하지만 세계 최초라고 하는 것들의 99%는 아래 범주에 속합니다.

• 나는 세계 최초로 알고 있다. 하지만 진짜 세계 최초인지 알아보려는 노력은 별로 하지 않았다.
• 별거 아니라서 아무도 관심을 가지지 않는 기술이다. 따라서 시장성도 없다.
• 이미 더 좋은 기술이 있는데 나는 공부를 많이 안해서 잘 모른다.

그럼에도 불구하고 지금도 툭하면 "세계 최초"라고 주장하는 기술들이 계속 튀어나오고 있고 이제는 별로 믿음도 안 갑니다. 오히려 세계 최초라고 하면 더 색안경을 끼고 보게 되었습니다.

또, 가끔 듣는 얘기가 "획기적인 기술"이라는 겁니다. 자세한 기술 요소는 보안 때문에 밝힐 수 없다고 합니다. 이런 경우는 99% 아래 범주에 속합니다.

• 나는 획기적인 것으로 알고 있는데 그건 내가 수준이 낮아서 그런 것이고 사실 별거 아니다.
• 별거 아닌 줄 알고는 있는데 밝히면 창피하니까 자세한 기술요소는 밝힐 수 없다.

사실 소프트웨어를 개발하는데 있어서 "세계 최초", "획기적인 기술"이 필요한 경우는 그리 많지 않습니다. 

대부분의 소프트웨어 프로젝트의 성패여부는 얼마나 획기적인 기술을 적용했나로 판가름 나지 않습니다.

오히려 대부분의 프로젝트는 이미 알려진 검증된 기술들로 수행을 해야 합니다. 

현재 쏟아져 나오고 있는 기술들을 꾸준히 따라가는 것만 해도 벅찬 일입니다.

사실 세계 최초로 뭔가를 해냈다고 해서 결과가 더 좋은 것은 아닙니다. 야후가 최초의 인터넷 검색을 제공했지만 지금 1등은 구글입니다.

MS도 최초의 OS 회사는 아니죠. 물론 최초가 1등인 분야도 있지만, 최초라는 수식어가 1등을 보장해주지는 않습니다.

"세계 최초" 남발하지 말고 실속 있게 개발해야 할 것입니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

이전 글("뛰어난 개발자는 타고나는 것")에서 논리적인 두뇌가 개발자의 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 중의 하나가 그런 환경을 가진 소프트웨어 회사를 많이 만드는 겁니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

가장 말 안듣는 개발자는?

소프트웨어 업계에서 가장 독특한 개발자들을 꼽으라면 단연 "게임개발자"들입니다.

대부분 태생적으로 형식과 규칙을 싫어하고 개성이 강하며 자신만의 스타일을 즐깁니다.

물론 이런 방식으로 곧잘 쓸만한 게임을 개발해내기도 합니다.

게임 개발자들이 독특한 것은 비단 우리나라 얘기만이 아닙니다. 미국 실리콘 밸리에서도 게임 개발자들을 평가하라고 하면 프로세스를 따르기 싫어하고 해커와 같이 밤새 시스템에 매달리기를 좋아한다고들 합니다.

이러한 인식들이 게임 개발자는 자기 스타일로 마음대로 개발을 해도 좋은 게임을 만들 수 있을 것으로 착각하게 합니다. 물론 다른 소프트웨어와 마찬가지로 게임도 규모가 작을 때는 주먹구구든 어떤 방식으로 개발을 해낼 수 있습니다. 하지만 규모가 커지기 시작하면 비즈니스 S/W든 게임이든 주먹구구식으로 개발할 수가 없게 됩니다.

따라서 게임 개발자들의 강한 개성은 회사의 규모가 커지면서 성장하는데 더 큰 방해요인이 됩니다. 현재 성공한 게임회사들이 이런 개성 강한 개발자들을 멋대로 방치해서 그렇게 성장했다고 생각하면 착각입니다. 다들 프로세스와 게임 개발자 특유의 특징을 잘 조합해서 합리적인 개발 프로세스를 정착했기 때문에 그렇게 성장한 것입니다.

게임 개발자들이 프로세스와 규칙을 더욱 더 싫어 이유는 다음과 같은 것들이 있습니다.

• 원래 얽매이는 것을 싫어합니다.
• 자신의 스타일을 좋아하고 변화를 싫어합니다. (일반적인 개발자 또는 사람들도 그렇습니다.)
• 프로세스와 규칙이 잘 정비되면 자신에 대한 의존도가 떨어진다고 착각합니다.

이러한 이유들 때문에 회사에서 성장을 하기 위한 개혁 시도에 갖가지 핑계를 대면서 개혁을 방해합니다. 창의력을 저해시킨다는 등의 핑계를 꽤 효과적이어서 상당기간 개혁을 지연시키기도 합니다. 하지만 이는 회사에도 큰 Risk이고 개인에게도 성장을 방해시키는 요인이 되므로 결국 다 손해입니다.

소프트웨어 개발 프로세스는 바이블이 하나 있어서 모든 회사에 똑같이 적용할 수 없습니다. 각 회사에 알맞게 만들어가야 합니다.

또한 게임 개발자들도 장점인 창의성이나 개성은 유지하되 프로세스를 따르고 게임 뿐만 아니라 소프트웨어 공학에도 관심을 둬야 회사가 성장해 감에 따라서 회사의 게임 개발을 이끌 수 있는 리더로서의 능력을 갖출 수 있습니다.

개발자 부품화 vs. 만능 개발자

개발 프로세스를 너무 따지만 개발자가 부품화 되고 창의성이 줄어든다고 합니다.

또 분석, 설계, 구현, 테스트를 나눠서 하게 되면 부품화되고 비인간적이라고 하기도 합니다.

그래서 개발자가 이것 저것 다하는 만능의 역할을 수행하게 합니다.

투수는 공만 던지고, 골키퍼는 골만 막는 것은 부품화일까요?

이렇게 전문화되지 않고 모두 만능으로 잘하는 동네 축구를 해서 어떻게 세계적인 소프트웨어와 경쟁할 수 있을까? 잘 하고 싶어도 동네축구를 계속 하는 이유는 제대로 된 방법을 경험해 본적이 없어서 그렇습니다. 개발자가 한명인 회사나 개발자가 50명인 회사가 개발하는 방법은 크게 다르지 않습니다. 개발자가 개발 전반의 모든 일을 다 알아서 하고 프로젝트는 개발자의 역량과 의지에 달려있습니다. 

동네 축구를 벗어나기 위해서는 소프트웨어를 개발하는 전체 프로세스를 이해해야 합니다. 이에 따라서 프로세스를 체계화 하고 각 역할별 전문화된 조직을 갖춰나가고 설령 인원이 매우 적어서 한명의 개발자가 여러가지 일을 수행하더라도 업무의 구분이 필요합니다. 나중에 조직이 커지면 일을 떼어 줄 수 있어야 합니다.

만능 개발자는 자칫하면 정작 개발자로서의 가치 있는 성장에 지장을 초래할 수 있습니다. 

거짓말쟁이 개발자

의도적이던, 의도적이지 않던 간에 개발자의 거짓말은 개발자 스스로의 신뢰를 떨어뜨릴 뿐만 아니라 회사의 중요한 결정을 잘못된 방향으로 이끌기도 합니다.

거짓말쟁이 개발자들은 거짓말을 하면서도 본인이 거짓말을 하고 있다는 것을 자각하지 못하거나 온갖 합리화를 할 수 있는 핑계로 무장을 하여 진실을 말하고 있는 자기 최면에 빠지기 도합니다.

사람들은 계속 속아주지는 않습니다. 결국 신뢰도 떨어지는 개발자가 될 수 있습니다.

모르는데 아는 것처럼 말하는 것

이름 한번 들어본 기술 또는 샘플 코드 한번 돌려본 것 가지고 아는 척하는 경우를 흔히 볼 수 있습니다. 이때는 자신이 어느 정도 아는지 정확하게 밝혀야 합니다. "들어는 봤다", "프로젝트에 적용해 봤다", "남을 가르칠 수 있다"

중요한 의사 결정에 있어서 자신이 잘 아는 기술을 유리하게 주장하는 경우

자신이 잘 아는 기술을 계속 고집하여 자신의 지식이 계속 유용하게 하려는 주장은 흔히 들을 수 있습니다. 이로 인해서 회사가 잘못된 결정을 내리면 자칫 회사의 존폐가 위태로울 수도 있습니다. 또한 이런 개발자들은 다양한 기술을 접할 기회가 줄어들어서 결국 자신의 몸값을 낮추게 됩니다.

자신의 파워를 유지하기 위하여 그릇된 정보를 사실인 것처럼 말하는 경우

회사를 다니는 직원이라면 자신의 힘을 유지하고 키우는 것이 중요하지 않을 수는 없습니다. 하지만 이를 위하여 거짓된 정보로 잘못된 결정을 유도한다면 결국 자신의 도끼로 자신의 발등을 찍는 일이 될 수도 있습니다.

사실, 의견, 정보를 혼동하는 경우

가장 흔한 거짓말입니다. 말을 하면서도 이것이 자신의 의견인지? 공식화된 사실인지? 누구의 의견인지? 정확하게 밝히지 않는 것입니다. 이 이야기를 듣고 결정을 하는 사람들은 의견을 사실로 오해해서 중요한 의사 결정을 할 수도 있습니다. 그런 다음에 "누가 그렇게 얘기했다"라고 변명하는 것은 통하지 않습니다.

자신의 성과를 과대 포장하는 경우

자신이 개발한 SW를 마치 대단한 성과물인양 광고를 하고 심지어는 Open source를 가져다가 뚝딱뚝딱 만든 것을 자신의 창작물인 것처럼 속이는 경우도 많습니다. 자신을 전혀 홍보하지 못하는 것도 문제지만, 이렇게 너무 과대 포장하는 것은 자칫 회사도 과대 포장이 되고 결국 다른 개발자들의 시기의 대상이 되기도 합니다.

자신의 실력을 과대평가하여 불가능한 일을 할 수 있는 일처럼 말하는 경우

개발자는 자신의 실력의 한계를 잘 알아야 합니다. 자신의 실력을 뛰어넘는 일이라면 사실대로 밝혀서 회사의 지원을 받아야지, 거짓말로 일에 뛰어 들어서 프로젝트를 크게 망친다면 누구를 탓할 수는 없습니다. 이 거짓말은 마치 거짓말이 아닌 것처럼 생각되기도 하지만, 아주 흔한 거짓말 중 하나이며, 자신이 자신을 몰랐다는 핑계는 진짜 핑계일 뿐입니다.

결국 이런 거짓말들을 일삼는 개발자들은 거짓말이 또 거짓말을 낳게 되고, 적당한 핑계에 익숙해 지게 됩니다. 결국 제살을 깎아먹는 일이 됩니다. 또, 이런 개발자들이 더 대우받고 활개 치는 회사라면 같이 일하는 개발자들은 참 피곤한 노릇이 아닐 수 없습니다.

자칫하면 이런 개발자들의 많은 거짓말들이 거짓말이 아닌 것처럼 묻혀버리는데, 항상 커뮤니케이션을 할 때는 모든 것을 확실히 하여 특히 위 예와 같은 것들은 단단히 확인을 받아서 거짓말에 대한 책임을 지게 해야 항상 더 올바른 정보로 정확한 커뮤니케이션이 일상화 됩니다.

시한부 프로그래머

우리나라 개발자들은 10년 후가 매우 불확실합니다.

오랫동안 프로그래머로서 일할 수 있도록 보장이 되지도 못하고, 그런 Role model을 본 적도 별로 없기 때문이죠. 그래서 5년~7년쯤 일하고 나면 미래를 걱정해야 할 시기가 도래합니다.

윗사람들은 자꾸 관리를 하라고 하고, 선배들을 봐도 15년차 개발자보다 15년차 관리자가 회사 내에서 영향력도 더 크고, 연봉도 더 높습니다.

개발이 좋기는 한데 계속 개발자로만 머물려면 미래를 많이 희생해야 합니다.

그래서 개발과 관리 양다리를 걸치기도 하는데, 결국 관리도 잘 못하고 개발도 잘 못하는 어정쩡한 상태가 계속 되기도 합니다.

SW선진국에서는 기본적으로 개발자의 Career path는 확실히 개발자냐 관리자냐 구분이 됩니다. 내가 개발자로 머물고 싶다면 관리를 하지 않고 개발자로 계속 머물 수 있습니다. 물론 그에 걸맞은 실력도 있고 기여도 해야겠지요. 보통 개발자가 연봉도 더 높고, 회사의 위기 때 짤릴 위험도 적고, 회사를 옮기기도 더 쉽습니다. 또 골치 아픈 관리를 하지 않아도 되니 흰머리도 덜 생기지요.

하지만 개발에 대한 전문성에 대한 이해가 부족한 우리나라에서는 개발과 관리의 구분을 명확하게 하지 못하고 개발을 잘하고 고참이 되면 팀장이 되고, 관리자가 되는 것을 당연하게 생각하고 있습니다. 이는 한창 잘 뛸 10년차 축구 선수에게 이제 고참이니 구단 관리도 좀 맡아 달라고 하는 것과 비슷합니다. 

고참개발자에게 관리를 맡기는 것보다 관리 전문가를 따로 뽑거나 키우는 것이 더 효율적이고 비용도 적게 듭니다. 관리를 만만하게 보고 개발자들에게 관리 일도 시킨다면 개발, 관리 둘다 망치는 일입니다.  

또한 개발자 역시 신참 때나 고참이 되어서나 코딩이 좀 빨라진 정도 가지고는 개발자로서의 신분 보장을 주장하기에는 설득력이 약합니다. 경력을 쌓아 갈 수록 단순 코딩이 아니고 설계, 분석 능력을 점점 키워야 하고 소프트웨어 전문가로서 손색이 없는 지식과 경험을 갖춰야 합니다.

하지만 결국 아무리 노력해도 회사차원에서 Career path가 보장되지 않는다면 어려운 일입니다. 회사가 그리고 경영자의 마인드가 먼저 바뀌어야죠. 멀게만 느껴집니다.

부지런한 개발자가 되라

지난번에 "게으른 개발자가 되라"는 글을 올린 적이 있습니다.

이번에는 그 반대 제목인 "부지런한 개발자가 되라"는 글입니다.

소프트웨어 개발은 대단히 섬세하고 꼼꼼한 작업입니다.

이를 어설프게 대충 접근하다가는 프로젝트도 망칠 수 있을 뿐만 아니라 본인 스스로의 성장에도 지장을 줄 수 있습니다. 다음에 몇 가지 질문에 답변을 해보시죠.

• IDE에서 제공하는 편리한 Wizard를 이용하지 않으면 개발이 어렵다.
• 새로운 시도를 할 때 책은 안보고 일단 해본다.
• 새로운 알고리즘에 원리는 관심이 없고 사용만 한다.
• 내가 작성한 코드를 꼼꼼하게 Trace 해보지 않는다.
• 버그는 미뤘다가 나중에 고친다.
• 유닛 테스트는 잘 하지 않고 QA테스트에서 걸러줄 것으로 기대한다.
• 내가 참여하는 프로젝트만 관심이 있고 다른 부서의 프로젝트에 대해서는 전혀 모른다.
• 내가 주로 쓰는 프로그래밍 언어 외에는 배척한다.
• 항상 업무에 치여서 신기술에는 관심을 가질 시간이 없다.
• 동료들과의 지식공유에 많은 노력을 기울이지 않는다.

이 질문들에 Yes가 얼마나 많으신가요? 설마 10개는 아니겠죠.

질문들이 직접적인 관계는 없는 것 같지만 개발자가 단순히 Output만을 내기 위해서만 일을 해서는 안되다는 메시지를 담고 있습니다. 

너무 편리하게 일하려고 하고 원리에 소홀하면 개발자로서의 기술적인 깊이를 다질 수가 업습니다. 또 자신의 코드를 꼼꼼하게 검사하는 습관을 들이지 않으면 항상 버그만 많이 만들어 내는 개발자로 낙인 찍힐 수 있습니다. 또한 다른 부서의 프로젝트에 대해서도 관심을 많이 가져야만 지식과 경험의 범위가 넓어지고, 회사 내에서도 기술적인 영향력을 지속적으로 확대해 나갈 수 있습니다. 또한 다른 부서의 개발자들에게 도움도 줄 수 있습니다. 

따라서 10년 이상의 경력을 가진 개발자인데 아직도 자신의 팀의 프로젝트에서 게다가 코딩만 열심히 하고 있다면 정말 똑똑하게 부지런한 개발자는 아닙니다. 이런 개발자들이 주는 Value는 신입사원에 2,3배에 불과합니다. 당연히 연봉도 많이 받을 수가 없죠. 10년 경력 이상이라면 적어도 타 부서의 프로젝트의 다양한 Review session에 참여하여 기술적인 결정에도 참여를 하고 전사적인 기술 Roadmap이나 의사결정에 참여할 수 있어야 합니다. 물론 회사 규모에 따라서 그 정도는 약간씩 달라지지만 아직까지 자신의 팀에만 머물러 있어서는 안됩니다.

요지는 부지런해도 좀 Smart하게 부지런해야 한다는 것입니다. 코딩에만 몰두하지 말고 본인의 지식과 경험을 좀더 깊게 좀더 넓게 하기 위해서 꾸준히 부지런을 떨어야 합니다. 그래야 10여년 후에 연봉 1억을 받아도 아깝지 않은 개발자가 될 수 있습니다.

게으른 개발자가 되라!

"게으른 개발자가 되라!"라고 하면 무슨 봉창 두드리는 소리냐고 할 겁니다. 진짜 게을러지라는 의미가 아니고 쓸데없는 일에 부지런하지 말자는 의미입니다.

항상 괜히 바쁜 개발자들이 있습니다. 본연의 연구 개발작업 이외의 과외 업무로 바쁜 것을 말합니다.

이런 개발자들은 개발도 열심히 하지만 과외 업무로 인해서 상당히 많은 시간을 빼앗깁니다.

가만히 보고 있으면 항상 열심히 하는 것 같지만, 헛고생하고 있는 것이 많습니다. 이런 과외 업무들은 최대한 자동화를 해 놓고 개발 본연의 업무에 충실해야 합니다.

개발자가 하루 종일 하는 일을 분석해보면 자동화를 해야 할 부분이 상당히 많다는 것을 알게 될 것입니다. 그럼 상당 부분 자동화할 수 있는 것들의 간단한 예를 들어보죠.

• Engineering Unit Test

• System Test

• Daily Build

• 소스코드관리시스템 Audit

• Build 전반의 프로세스

• Release 전반의 프로세스

• Packaging 프로세스

• Patch 업데이트를 위한 프로세스

• 소스코드 Merge

• 소스코드 정적/동적 테스트

이중에서 빌드를 예를 들어 보면 Build를 하면서 자동으로 소스코드 관리시스템에 Baseline을 설정하고 Build number를 갱신하고, 자동으로 Compile을 진행합니다. 또 빌드를 하면서 발생하는 Warning과 Error를 체크하고 자동으로 소스코드관리시스템에서 해당 Warning과 Error를 유발한 개발자를 찾아내고 이를 보고서로 만들어서 관리자와 담당자들에게 Email을 보내며 빌드 기록을 보관하게 됩니다.

이 과정에서 사람이 개입하는 것은 Build Script를 실행하는 것 뿐입니다. 공식 빌드를 하기 위해서 개발자들이 평상 시에 하는 Engineering Build처럼 Visual Studio나 Eclipse를 열어서 빌드를 하고 FTP로 서버로 파일을 옮기고 필요한 파일을 모아서 Install Shield를 실행하여 설치 프로그램도 만들고 Diff 프로그램을 이용해서 바뀐 파일도 찾아내서 Path update 파일을 서버에 등록하고 하는 일련의 작업을 직접 수동으로 하고 있다면 자동화 할 부분이 굉장히 많으니 기뻐하십쇼. 앞으로 개선된 일이 무궁무진하니까요.

개발 프로세스는 회사마다 다르기 때문에 자동화할 부분을 획일적으로 정할 수는 없습니다. 따라서 아직 자동화가 많이 부족하다면 자동화를 했을 때 효과가 크고 자동화가 쉬운 부분부터 차근차근 자동화를 해 나가야 합니다. 그 중에서 대표적인 것이 빌드입니다.

자동화가 잘 된 조직과 그렇지 못한 조직은 개발 생산성에서 몇십% 차이가 나고 자동화가 잘된 조직은 그렇지 못한 조직이 밤새고 혼돈 속에서 고생하고 있을 때 제품에 아키텍처에 대해서 더 고민하고 신기술도 더 익힐 수 있고 그러면서도 퇴근은 더 빨리 할 수 있습니다.

게으른 개발자가 되십시오. ^^

과거의 개발자 vs. 미래의 개발자

개발자는 2가지의 상반된 가치를 가지고 있습니다.

하나는 과거의 가치
또 하나는 미래의 가치입니다.

"이 사람들 나가면 과거에 개발해 놓은 것 어떡하지?"라는 생각이 들면 과거의 가치를 가진 개발자이고

"이 사람들 나가면 미래에 개발은 누가 하지?"라는 생각이 들면 미래의 가치를 가진 개발자입니다.

과거의 가치를 가진 개발자들은 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식은 머리 속에 있기 때문에 자신이 과거에 만들어 놓은 소프트웨어를 인질 삼아서 회사와 인질극을 벌이고 있는 것과 같습니다. 이렇게 된 원인이 상당부분 회사에 있다고 하더라도, 개발자의 가치는 인질범과 별반 다를 바가 없습니다. 기존 소프트웨어를 망칠까봐 대우해줄 수 밖에 없습니다.

미래의 가치를 가진 개발자들은 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수 할 수 있도록 충분히 문서화를 해 놓았고, Peer review를 통해서 이미 많은 지식이 전달된 상태입니다. 이러한 개발과정을 거쳐서 본인은 분석, 설계 능력을 더욱 향상시켰고, 신기술들에 대한 연구에 집중하여 미래에는 과거의 제품들 보다 한 단계 높은 수준의 제품들을 만들어 낼 것입니다. 이러한 개발자들이 진정한 영웅이라고 할 수 있습니다.

인질범이 되겠습니까? 영웅이 되겠습니까? 이는 본인의 의지에 달려있습니다.

안타까운 것은 고참 소프트웨어 개발자 중에는 영웅보다 인질범이 더 많다는 겁니다. 물론 이 개발자가 인질범과 다를바가 없다는 것을 본인도 모르고 회사도 모르는 경우가 태반이지만 말입니다.

개발자는 억울하다.

회사에서 제대로 배우고 성장할 기회를 갖지 못한 채 혼자서 북치고 장구치고 밤새가면서 개발하여 회사를 성장시켜놨는데 이제는 골치덩어리 개발자가 되어 버렸습니다.

이제는 문서도 안 만들고, 프로세스도 지키지 않으며, 정보를 꽉 쥐고 내놓지 않으려는 "꼴통개발자"로 보이기 십상입니다. 실제로 한참 후배들은 그런 고참개발자를 "꼴통" 또는 "철밥그릇"이라고 부릅니다.

당장은 그런 고참 개발자가 없으면 회사가 안 돌아 갈 것 같으니까, 잡아두고 있지만, 프로세스를 정비하고 시스템을 구축하여 정보가 공유되고 후배들이 그들을 대신할 수 있으면 언제 든지 내쳐질 것 같습니다.

살기 위해서는 소스코드와 업무지식을 내 놓지 않고 꽉 쥐고 있어야 하는데, 점점 쉽지 않아집니다.

이렇게 된 가장 큰 이유는 회사의 소프트웨어 개발에 투자가 필요하다는 것에 대한인식 부족 때문입니다.

소프트웨어 회사는 개발자들이 알아서 제품 만들고 영업이 팔고 그렇게 하면 쉽게 운영이 될 것 같지만, 소프트웨어 회사들이 갖춰야 할 기본 체계와 투자를 해야 한다는 것을 모르고 있는 것 같습니다. 사실 개발자 혼자라도 얼마든지 제품을 만들어 낼 수 있습니다. 그래서 너무 쉽게 보였는지도 모릅니다. 즉 겉으로 보여지는 모습만 보고 소프트웨어를 제대로 개발하고 개발자들을 훈련시키고 성장시키기 위해서는 얼마나 많은 투자를 해야 하는지 모르는 겁니다.

그 결과 회사는 외형적으로 성장을 했는데, 개발자들은 성장하지 못하고 커진 회사의 외형을 뒷받침을 못하니 천덕꾸러기 개발자가 되고 맙니다. 원래 회사는 적절한 시기에 적절한 투자를 꾸준히 해 나가야지 경기가 안 좋다고 잠시 미루고 매출이 떨어졌다고 잠시 미루고 이렇게 투자의 시기를 놓치면 그 손해는 배가 됩니다. 개발자들에 대한 교육 및 회사의 개발 체계에 대한 투자가 늦어지면 손해가 배가 아니고 몇 갑절이 될 수도 있습니다. 반대로 적절한 시기에 개발자들을 교육하고 성장시키면서 회사의 개발 시스템을 발전시켜나가면 몇 배의 성장도 할 수 있습니다. 

물론 이러한 투자가 성공을 담보하지는 않습니다. 적어도 비즈니스적인 성공의 발목을 잡지 않게 됩니다. 지금도 수많은 소프트웨어 회사들이 내부의 개발 실패와 비효율적인 개발 시스템으로 발목을 잡히고 있습니다. 그러면서도 개발이 잘못되고 있다는 것을 쉽게 알아차리지 못하고 있습니다. 늦었더라도 내부에 대한 투자를 멈추면 안됩니다.

거만한 속빈 강정

소프트웨어 개발 경험도 개발자가 미국 실리콘밸리의 소프트웨어 회사에 입사해서 5년이면 배울 수 있는 것(소프트웨어를 개발하는 방법)을 우리나라에서는 10년, 20년 아니 30년을 소프트웨어만 개발해도 배우지 못합니다.

오히려 이런 경험 많은 고참 개발자들은 배울 수 있는 기회가 눈앞에 와도 배울 수가 없게 됩니다.

책을 하나 봐도 대부분 아는 내용이라고 저자를 평가 절하하지만 아는 수준이라는 것이 용어 한번 들어보고 샘플 좀 사용해 본 정도인 경우가 대부분입니다.

예를 들어 소스코드관리시스템에 대한 내용을 봐도 내가 대형SI회사에서 10년 넘게 개발을 했는데, 이런 것을 모를까봐?라고 생각하지만 고작 소스코드 백업 받듯이 저장하고 태깅 좀 한 정도 가지고 소스코드 관리를 제대로 하고 있다고 착각합니다. 

오히려 이러한 개발자들은 온갖 화려한 기술과 온갖 툴 및 기법에 능숙해서 UML의 도사이고 자신은 아키텍트라고 하면서도 진짜 설계는 할 줄도 모릅니다. 이런 고참 개발자들은 아무것도 모르는 신참 개발자보다 제대로 배우기는 훨씬 어렵습니다. 신참 개발자들은 책이나 강연을 통해서 배움이 기회가 왔을 때 자신은 잘 모르고 부족하다고 생각을 하기 때문에 받아드리려는 마음이 있으나 이런 고참 개발자들은 자신들이 잘 알고 개발을 잘하고 있다고 착각하기 때문에 즉 자신의 무지를 모르기 때문에 배움을 받아드리려고 하지 않습니다. 또 자신이 해왔던 방식이 나름대로 편하다고 생각해서 바꾸기를 싫어하고 괜히 바꿨다가 회사에서 자신의 위상이 흔들리면 어떡할까 하는 걱정도 하곤 합니다.

2,3년 된 신참 개발자들은 회사에서 제대로 된 개발 환경 및 교육의 기회만 주어진다면 4,5년 안에 이런 고참 개발자들보다 훨씬 뛰어난 실력을 갖는 것은 그리 어려운 일이 아닙니다. 또 배우려고 하지 않는 고참개발자들은 세계 최고의 소프트웨어 대가가 와도 이들을 가르칠 수는 없습니다. 그냥 그렇게 회사에서 정치나 하면서 연명을 하는 수밖에 없습니다. 다른 회사로 이직을 하면 자신의 위상이 확 떨어지니 회사에 꼭 붙어 있어야겠지요. 물론 은퇴 전에 회사가 망하면 큰 일지만 말입니다. 

그런 일을 당하지 않으려면 마음을 바꿔 먹어야 합니다. 물론 정말 실력이 뛰어난 개발자들도 많이 있지만, 자신이 소프트웨어 개발을 잘하고 있다고 착각하는 고참개발자들은 늦었지만, 바뀌어야 합니다. 

자신이 정말로 뛰어난 개발자인지? 뛰어나다고 착각하는 것인지? 어떻게 아냐고요?

후배 개발자들이 많이 있는데 아직도 주로 코딩에만 매달리면서 자신이 코딩을 하지 않으면 개발이 잘 안될 것 같습니까?  문서를 만들면서 개발을 하는 것보다 코딩부터 개발을 하고 문서는 불필요하다고 생각하시나요? 문서를 만들어도 다른 개발자들이 이해를 잘 못하나요?  자신은 개발을 정말 잘하는데 후배 개발자들은 정말 실력이 떨어진다고 생각이 드나요? 후배들이 실력이 딸려서 같이 일하기 정말 힘듭니까? 후배들에게 잘 설명해줘도 원하는대로 개발이 진행이 잘 안됩니까? 개발은 기가 막히게 하는데 회사의 비즈니스 상황은 잘 모르나요? 개발에만 집중하고 소프트웨어 기획, 테스트, 배포 등의 전반의 내용은 잘 모르나요? 해당 Domain 지식(업무지식)에 대해서 도사급이라 다른 업계로 이직은 싫은가요? 소스코드관리, 버그관리는 기초기능만 사용하나요? (기초의 기준이 뭔지 알기 어렵겠군요.) 개발프로세스는 불필요하거나 불편한 것이라고 생각하시나요? 경영자들에게 기술이나 아이디어를 설명해도 경영자들이 이해를 잘 못하나요?

너무 많아서 다 나열할 수가 없네요. 

이중에 몇 가지만 해당해도 착각하고 있는 것일 가능성이 대단히 높습니다. 착각에서 빨리 벗어나는 것이 자신의 미래를 위해서 이롭습니다.