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

이전 글("뛰어난 개발자는 타고나는 것")에서 논리적인 두뇌가 개발자의 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) 똑똑하다는 것이 개발자에게 필요한 오직 한가지 조건은 아닙니다. 즉, 똑똑하기만 하다고 최고는 아니죠. 특히 인성과 긍정적인 자세가 중하죠. 이런 부분은 나중에 기회가 되면 풀어 보겠습니다. 또한 다양한 채용 방법에 대해서도 글을 올려 볼 계획입니다.

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

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

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

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

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

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

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

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

거짓말쟁이 개발자

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

시한부 프로그래머

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

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

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

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

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

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

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

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

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

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

Copy & Paste의 종말

직업상 다른 개발자들이 작성해 놓은 코드를 볼 기회가 정말 많습니다.

그러다보면 자주 접하는 것이 복사된 코드들입니다. 

소소코드 Copy & Paste는 개발자의 대단히 큰 잘못입니다. 즉, 소스코드를 복사해 놓는 것은 쉽지만 그로 인해서 지속적으로 회사와 후배들이 부담을 져야 하기 때문입니다. 즉, 회사의 생산성을 갉아 먹는 행동입니다. 그런 개발자는 해고가 되어야 마땅하지요.

한쪽 제품이나 컴포넌트에서 사용한 함수나 소스코드들을 복사해 와서 다른 제품이나 컴포넌트에서 사용하는 것입니다. 동일하게 그대로 사용하는 경우도 있고, 약간 수정해서 사용하는 경우도 있습니다.

이런 일이 반복되다보면 비슷한 코드들이 회사의 전체 소스코드 중에서 여기 저기 산재하게 됩니다. 그러다가 버그가 발생하는 그중 일부는 고쳐지고, 일부는 여전히 버그를 가지고 있습니다. 또 해당 기능이 변경이 될 때도 이를 모두 찾아서 변경하기란 쉬운 일이 아닙니다. 이쯤 되면 개발은 창의적인 작업이 아닌 점점 노동이 되어 갑니다.

이런 공통적인 소스코드들은 공통모듈을 잘 계획해서 공통적으로 사용할 수 있어야 합니다. 공통모듈은 전사적으로 관리가 되어서 효율적으로 사용할 수 있도록 해야 하며, Copy & Paste의 욕구가 생겨도 시간을 약간 더 들여서 공통모듈화 하는 노력을 들이는 것이 필요합니다.

공통모듈을 관리하려면 당연히 소스코드관리시스템을 잘 사용해야 하고, 각 제품이나 컴포넌트들이 공통모듈들과 더불어 효과적으로 빌드가 가능하도록 빌드 스크립트도 준비가 되어야 합니다.

Peer review, code review가 정착되어서 다른 팀에서 서로 모르고 중복된 작업을 하는 것을 줄여야 합니다.

또, 특정 고객을 위한 커스트마이즈된 제품을 만들 때 대규모 소스코드 복사가 일어나는데, 이를 통제없이 만들고 방치하면 함수 몇개 복사한 것과는 비교도 안되는 큰 비용을 치뤄야 합니다. 물론 상황에 따라서 다르기는 하지만, 이런 경우에는 가능하면 소스코드 브랜치를 줄이고 브랜치를 만들더라도 소스코드관리시스템을 이용하여 잘 관리를 해야 합니다. 그리고 추후 Merge를 통해서 브랜치의 수명 주기를 짧게 가져갈 필요가 있습니다.

여기저기 복사된 쌍둥이 소스코드들... 참 문제가 아닐 수 없습니다.

고객이 요구사항을 너무 자주 바꿔요.

우리나라 소프트웨어 시장을 너무 비관적으로 과대평가하는 경우를 종종 봅니다.

예를 들면 전세계 유래가 없는 까다로운 고객 요구 수준, 시도 때도 없이 바뀌는 요구사항, 엄청나게 낮은 금액, 제품의 Output과는 상관없이 작업 시간을 통제하는 관행

일부는 공감을 하기도 하지만, 어느 나라를 가던지 각 나라만의 특징이 있다는 측면으로 바라보고 싶습니다. 우리나라 고객은 요구사항을 정말로 외국에 비해서 더 자주 바꾸는 것인지는 생각해 볼 필요가 있습니다. 어딜 가던지 고객은 요구사항을 항상 바꾸기 마련이고, 그것이 고객의 습성이라고 볼 수 있습니다. 그런데, 외국에서는 관행적으로 문화적으로 스펙을 근거로 계약을 하고, 분석 능력이 뛰어난 엔지니어들도 많이 있습니다. 하지만 그런 저변이 상대적으로 부족한 우리는 개발을 하는 쪽이나 고객이나, 일단 대충으로 요구사항으로 개발을 하고 나중에 서로 맞춰나가는 것이 상당 부분 관행화된 측면이 있습니다.

개발회사와 개발자가 요구사항을 분석하고 통제하는데 능력을 갖추고 있다면 100%는 아니지만, 고객의 요구사항 변경을 상당부분 통제 가능한 범위 안으로 가져올 수도 있습니다. 

스스로가 주먹구구 식으로 개발을 하면서 고객에게만 덤터기를 씌우는 것은 스스로에게 이득이 될 것이 없습니다.

오늘의 잡담 - 개발자와 영어

이 소프트웨어라는 것이 미국에서 처음 만들어지다 보니 엄청나게 많은 자료들이 영어로 되어 있고, 대부분의 커뮤니케이션의 영어로 진행되고 영어가 마치 소프트웨어 업계에서는 표준어가 된 듯합니다.

나 자신도 영어를 지독히 싫어했고, 최근 2,3년간 영어 공부에 열을 올리고 있지만, 제가 처음 소프트웨어를 시작할 때부터 영어를 잘했다면은 지금 내 모습이 달라졌을 것을 생각합니다.

대부분의 프로그래밍 언어가 영어 기반이고, 메뉴얼 원본은 다 영어인데, 영어로 된 원서를 읽으려면 번역서보다 10배이상 속도도 느리고 이해가 잘 안되니 항상 번역서만 찾아 다녔었던 기억이 납니다.

이제와서 뛰어난 개발자가 되려면 영어도 잘해야 한다고 말하기도 쑥스럽지만, 영어를 유창하게 하지 못하는 개발자는 이미 기회를 반쯤 버리고 경쟁하는 것과 같다고 생각합니다.

일단 소프트웨어 업계로 들어서면 너무 바빠지는 것이 일반적이라서 개발자가 왠만해서는 영어 공부를 하기 쉽지 않습니다. 학교 다닐 때 미리미리 영어 공부 유창하게 될 때까지 하고 오세요.

이미 개발자로 일하고 있고, 영어가 부족하다면 음... 알아서 꾸준히 공부하세요.

참고로 제 개인 블로그(http://raymond.pe.kr)에서는 영어 공부에 대한 주제로도 글을 꾸준히 올리고 있습니다. 혹시 영어 공부에 관심이 있으시다면 미미하나마 도움이 되면 좋겠네요.

"영어는 가까이하기엔 너무 먼 당신이다" - 매우 다가갔다고 생각하면 어느덧 또 멀어져 있는.......

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

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

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

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

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

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

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

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

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

개발자들이 바글바글한 외딴섬에 떨어진다면

개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까?

Language 기초를 다시 가르칠까요?

UML을 가르칠까요?
문서 작성법을 훈련 시킬까요?
개발방법론을 가르칠까요?
팀워크를 키워줄까요?
OOP를 가르칠까요?

어떻게 하시겠습니까?

나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다. 

즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement engineering을 제대로 알고 잘 작성한 스펙문서는 별로 접해보지 못했습니다. 또한 그로 인해서 프로젝트나 제품에서는 수많은 문제들이 야기되고 있었습니다.

물론 스펙을 제대로 쓰기만 한다고 소프트웨어를 잘 개발할 수 있는 모든 준비가 된 것은 아닙니다. 스펙을 쓰는 것은 이제 소프트웨어 제대로 된 소프트웨어 개발에 한 걸음 내디딘 것 뿐입니다. 거꾸로 스펙도 쓰지 않고 소프트웨어를 어떻게 개발하냐고 반문할 수 있습니다. 즉, 무엇을 개발할지도 모르고 여럿이서 소프트웨어를 어떻게 개발하냐는 것입니다. 또 영업이나 고객은 정확하게 무슨 제품이 나올지도 모르고 기다리냐는 것입니다.

하지만, 이에 대한 반론을 얘기하는 사람도 꽤 됩니다. 기존에 제대로 된 스펙 없이도 훌륭한 제품을 많이 탄생했고, 성공한 제품도 꽤 된다고 얘기합니다.  물론 예외는 항상 있습니다. 저도 몇몇 그런 사례를 알고 있습니다.

정확하게 따지면, 그렇게 성공한 제품은 별로 많지는 않습니다. 그리고 초창기에 제품의 크기가 작거나 고객 수가 작을 때는 멋진 제품이었으나 매출이 늘고, 소프트웨어 규모가 커지면서 망가진 제품도 꽤 많습니다. 즉, 스펙의 부실로 혼동에 빠져서 실패한 제품이 꽤 됩니다.

제대로 된 스펙도 없는 제품이 성공할 확률은 잘 작성된 스펙을 토대로 개발하고 유지보수 되는 제품의 성공확률의 1/10도 안될 겁니다. 

소프트웨어 개발자라면 스펙이 왜 중요하고, 스펙을 잘 적기 위해서 배우고 많은 노력을 기울여야 한다는 것을 알아야겠습니다.

PS) 가끔 우리나라가 소프트웨어 업계에서는 섬처럼 느껴지곤 합니다.

개발자는 억울하다.

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

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

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

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

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

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

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

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

거만한 속빈 강정

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

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

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

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

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

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

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

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

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

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

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

Peer Review의 방해꾼들

Peer Review가 정말 중요하다고들 다들 생각할 것 같지만, 실상은 그렇지 않습니다.

Peer Review의 중요성을 알고 있는 사람은 정말 많은 경험과 깨달음을 얻은 사람이고 대부분은 Peer Review의 중요성을 모르거나 심지어는 노골적으로 또는 은연 중에 방해를 합니다.

Peer Review는 (이미 언급했지만), 소프트웨어의 결함을 줄이고 개발 비용과 시간을 절약하며, 개발자들 간의 정보와 지식을 공유하고, 개발자들을 성장시키며, 개발자들의 사기를 높여줍니다.

그런데, 결함을 줄이고, 비용과 시간을 절약하며, 지식을 공유하는 것을 싫어하는 개발자들이 의외로 꽤 많습니다. 공유를 통해서 자신만 알고 있는 지식이 빠져나가면 자신의 가치가 줄어들 것으로 생각하며 심각한 버그를 만들어서 자신만이 멋지게 해결하는 모습을 보고 싶어하고, 프로젝트의 일정을 항상 궁지로 몰아 넣고 자신이 이를 해결할 수 있는 유일한 사람인척 행동하는 많은 개발자들이 있습니다. 이러한 행동이 자신의 가치를 높여주고 자리를 보존해 준다고 생각합니다. 하지만 그 말로는 뻔하죠. 본인도 성장하지 못할 뿐더러 동료와 후배의 성장도 방해하고, 결국 실력은 부족한데 영향력만 유지하려고 하는 "정치꾼 개발자"로 전락하고 맙니다. 

회사들은 알고도 또는 모르고 이러한 개발자들에게 인질로 잡혀서 끌려다니곤 합니다.

Peer Review를 시행하면 이러한 개발자들의 방해에 부딪혀서 좌절하기 일쑤이며 이런 개발자들에게 동조한 관리자들도 방해자 노릇을 톡톡히 해냅니다. 프로젝트의 지연을 Peer Review의 탓으로 돌리기 일쑤이며 Peer Review의 성과를 평가절하 합니다. 또 영업부서가 고객이 Peer Review를 반대하기도 합니다.

이러한 방해꾼들을 극복할 의지가 회사에 없다면 Peer Review는 그림의 떡입니다. 즉 회사가 정말로 Peer Review의 필요성을 모르는 상태이거나 아직 이를 시행할 외적인 준비나 성숙도가 떨어진다고 볼 수 있습니다. 준비를 조금 더 해야겠죠? 

그럼 다음에는 Peer Review를 시행하기에 앞서서 준비가 되어야 할 것들에 대해서 알아보겠습니다. 

밥그릇을 지키려는 처절한 몸부림(기생충 개발자)

자신이 작성한 소스코드를 숨김으로써 자신의 밥그릇을 지키려고 애쓰는 개발자들이 상당히 많습니다.

이런 개발자들의 특징은 자신이 작성할 소스코드는 정말 어렵고 복잡하다고 광고를 하고, 소스코드관리시스템에 등록하는 것을 거부하거나 코드리뷰를 기피합니다. 그리고 철저히 문서와 주석 없이 코딩을 하며 심지어는 소스코드를 비비 꼬아서 분석하기 어렵게 만들어 놓기도 합니다.

개발자들의 이러한 행동은 단기적으로는 자리보존에 도움이 될지 모르지만, 스스로의 발전을 저해하고 결코 오래가지 못할 것입니다.

또한, 이러한 개발자들이 한두 명만 있어도 회사는 큰 시한폭탄을 안고 있는 것과 마찬가지입니다.

저는 직업상 수많은 개발자들을 만나기 때문에 이런 개발자가 정말로 많고 웬만한 소프트웨어 회사에는 꼭 몇 명씩 있다는 것을 잘 알고 있습니다. 실제로 수년 전 알고 있던 한 회사에서는 개발자가 암호 같은 소스코드를 잔뜩 남겨놓고 인수인계도 하지 않고 퇴사를 했는데, 소스코드관리시스템을 사용하지 않았기 때문에 개발 History도 하나도 없고, 스펙서도 설계서도 없고, 소스코드는 주석도 하나 없이 깨끗했으면, 혼자 다루던 소스코드라서 이를 알고 있던 개발자는 하나도 없었습니다. 물론 코드리뷰도 안 했었지요. 그래도 회사에서 가장 뛰어난 개발자라고 추켜줬었는데, 달랑 소스코드만 남은 상태에서 회사는 위기를 맞게 되었습니다. 이런 스토리는 너무흔합니다. 대부분 비슷한 얘기는 한 두개씩 알고 계실 걸요?

대부분의 별것도 아닌 소스코드라 하더라도 이렇게 망쳐 놓은 상황이라면 유지보수하기가 정말 어려운 상황이 됩니다. 이렇게 회사의 피를 빨아먹고 다른 곳으로 옮겨 다니는 "빈대형 개발자"가 있는 반면에 회사가 망할 때까지 회사를 숙주 삼아 오랫동안 고혈을 빨아먹는 "기생충형 개발자"도 있습니다.

이러한 개발자는 회사도 어렵게 하고, 본인 스스로도 미래를 지워버리는 것과 같습니다. 개발자는 이렇게 자신만 아는 소스코드를 생산함으로써 자신의 밥그릇을 지키기보다는 소프트웨어 전문가로서의 실력을 키우는데 집중해야 할 것입니다. 그래야 회사도 살고 본인의 미래도 키워집니다.

그럼 이런 개발자가 있는 회사는 어떻게 해야 할까요?

당장 짤라 버리십시오.

그럼, 회사가 망한다구요? 그런 상황이라면 이미 시기를 놓치셨네요. 안타깝습니다. 암조직을 떼어내는 순간 본인도 죽을 수 있는 상황이 된 겁니다. 당분간은 암조직과 같이 살아야 합니다. 그리고 암조직을 떼어내어도 살 수 있도록 체력을 키우셔야죠.

회사의 개발 체계를 정립하고, 소스코드를 관리하고, 개발 문서를 제대로 만들고, Peer Review도 시행을 해야 합니다. 3년이 걸릴지 5년이 걸릴지 모르는 일이지만, 이 수밖에 없습니다. 전문가의 도움을 받으면 시간이 조금 앞당겨지겠지요. 이 동안 이런 "기생충, 빈대형 개발자"들의 엄청난 반대와 비평에 시달릴 겁니다. 당장 프로젝트가 급하다고 하기도 하고, 개발자의 창의성을 방해한다고 하기도 하고, 온갖 그럴싸한 이유를 댈 겁니다. 그럼 같이 망하는 거죠. 듣기에는 정말 그럴싸하지만 이는 자신의 밥그릇을 지키기 위한 본능적인 몸부림이라는 것을 잊으면 안됩니다. 그렇다고 대놓고 이런 개발자를 비난하면 안됩니다. 살살 잘 유도해서 새로운 체계로 끌어들여야죠. 그렇지 않아서 중간에 나가버리면 곤란합니다. 그리고 이런 개발자들에게 기회를 줘야죠.

사실 대부분의 소프트웨어 회사의 경영자들은 이러한 고비를 넘지 못합니다. 심지어는 자신의 회사가 이러한 개발자에게 피를 빨리고 있다는 것을 인식조차 못하는 경우도 많습니다. 이러한 개발자가 회사를 먹여 살리고 있다고 생각하고 성실히 일하는 보통의 개발자들은 이런 개발자보다 못하다고 생각하기도 합니다.  이런 회사야 어차피 싹수가 없지만, 이를 알고 있는데도 이미 암덩어리가 커져서 어떻게 못하는 상황이라면 각고의 노력을 해야 합니다. 혼자 어려우면 전문가의 도움도 받으세요.

개발자들을 비난하기 위해서 이 글을 쓰는 것은 아닙니다. 대부분의 개발자들은 성실히 일하니까요. 대부분의 성실한 개발자들이 이러한 개발자들에게 피해를 당하지 안았으면 하는 바램이고, 소프트웨어 업계 저변에 소프트웨어 공학이 잘 접목된 개발 방법이 퍼져서 개발자도 살고 성공하는 회사도 마구 쏟아져 나오는 미래를 기대하는 마음에 글을 씁니다. 그동안 제 글들을 읽으신 분이라면 제가 소프트웨어 개발을 사랑하고 있다는 것을 아실 겁니다.

소프트웨어 개발자의 권리

지난번 글에서 소프트웨어 개발자윤리(의무)에 대해서 얘기를 한 적이 있습니다.

그때 많은 분들이 개발자의 권리도 좀 생각해보자고 하였습니다.

이에 개발자의 권리와 개발자에 대한 경영자와 고객의 의무를 정리해 봤습니다.

의견이 있는 분들은 댓글 남겨주세요.

개발자의 권리

○ 우리도 남들 잘 때 잘 수 있다.  ○ 우리도 희망적인 미래를 꿈꿀 수 있다.  ○ 우리도 가족과 저녁식사를 할 수 있다.  ○ 나이가 먹어도 계속 개발을 할 수 있다.  ○ 전문가로 성장할 수 있는 기회를 제공 받아야 한다. ○ 우리에게는 자기계발을 할 수 있는 시간과 기회가 제공되어야 한다.

개발자에 대한 경영자의 의무

○ 개발자를 부품이 아닌 전문가로 생각해야 한다. ○ 개발자에게 최상의 개발 환경을 제공해야 한다.  ○ 개발자에게 적절한 교육을 받을 수 있도록 해야 한다.  ○ 개발자가 원하는 캐리어로 성장할 수 있도록 보장해야 한다.  ○ 개발자는 근무시간이 아닌 실력과 성과로 평가해야 한다.   ○ 개발자의 실력과 성과에 합당한 보상을 제공해야 한다.

개발자에 대한 고객의 의무

○ 개발자를 하나의 인간으로서 존중해야 한다.  ○ 개발팀의 개발프로세스를 존중해야 한다.  ○ 요구사항을 개발자에게 정확하게 전달해야 한다. ○ 개발자의 요청에 시기적절하게 대응해야 한다.  ○ 개발 기간이나 시간을 산정한 개발자의 분석을 존중해야 한다.  ○ 요구사항 변경요청은 최대한 빨리 개발자에게 알려야 한다.  ○ 요구사항 변경은 개발팀의 프로세스를 따라야 한다.

자기 중심적인 사고에 갇힌 개발자

개발자들은 모든 생각의 중심을 본인으로 생각하는 경우가 흔합니다.

소프트웨어를 개발하면 모든 판단의 기준을 본인으로 하는 것이지요.

우주가 자신을 중심으로 돌고 있다고 생각하는 개발자들입니다.

적용하는 기술도 본인이 잘 알고 익숙한 것으로, 또 사업적인 관점으로 고려를 하기보다는 본인의 취향에 따라서 섯부른 판단을 하는 경우가 많습니다.

특히나 이렇게 자기 중심적인 사고방식에 꽉 막혀 있는 개발자들과는 대화조차 어려운 경우가 많습니다. 보통 고집도 센 것이 아니어서 같이 일하기 피곤합니다. 이런 개발자들이 실력이 뛰어난 것처럼 보여서 어쩔 수 없이 붙들어 두고 있는 경우가 많은데 일찌감치 팀에서 제외를 하던가 해고를 하는 것이 더 나을 겁니다.

소프트웨어를 개발하면서 벌어지는 수많은 판단과 결정은 이렇게 개발자 중심으로 이루어져서는 경쟁력 있는 제품이 나오기 어렵습니다. 무슨 DB를 쓸지, 어떤 개발언어를 사용할지, 아키텍처를 어떻게 구성할지? 또는 무슨 기능을 포함할지도 개발자가 마음대로 결정하고 해당 담당자에게 리뷰도 하지 않고 덜렁 소프트웨어를 개발해 놓으면 뒤늦게 문제들이 뻥뻥 터집니다.

개발자는 자신이 잘하는 일을 해야죠. 자신의 전문분야가 아닌 것은 다른 사람의 의견을 들을 수 있어야 합니다. 무슨 DB를 쓸지에 대한 이슈도 기술적인 이슈라기 보다는 비즈니스적인 측면이 더 큽니다. 개발자들은 이러한 결정의 순간에 자기 중심적인 사고를 버려야 합니다. 경험이 많은 개발자들은 이렇게 균형을 갖춘 사고를 하지만, 경험이 많은 모든 개발자가 그런 것은 아닙니다.

세상은 자신을 중심으로 돌고 있지 않다는 것을 알아야 합니다.

우리나라에는 전지전능한 슈퍼 개발자가 있다.

여러 소프트웨어 회사를 컨설팅하다보면 아주 많은 개발자들을 만나게 됩니다. 

그 중에는 전지전능한 슈퍼 개발자를 만나게 됩니다.

코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반 관리, 아키텍처 등등 엄청나게 많은 일을 하는 개발자들을 보게 됩니다.

이들은 대부분 팀장 쯤 됩니다.

어떻게 생각하시나요? 

바람직해 보입니까?

"나도 그런 전지전능한 개발자야 돼야지"라는 생각이 드십니까?

혹시 지금 이렇게 모든 분야의 일을 다 하고 계시나요?

이것은 One man company 얘기가 아닙니다. 

개발자가 100명이 넘는 회사도 이러한 경우를 여럿 봤습니다.

대부분은 회사가 성장과정에서 적당한 때에 조직을 변화시키지 못하고 그냥 달려온 경우입니다.

이런 경우 전지전능한 개발자가 대부분의 기술과 이슈를 꽤 뚫고 있어서 조직이 그럭저럭 굴러갑니다. (개발자들은 몰라도 사장님은 고민 많으실 겁니다.)

모든 길은 로마로 통하듯 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결됩니다.

이런 개발자가 나가면 회사는 망할 것만 같습니다.

이러한 상황이 정상일까요?

어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능합니다. 아주 작은 회사라면 그렇게 해야지요. 다른 대안이 없으니까요.

이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 합니다. 그건 애초에 불가능합니다.

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

심지어는 테스트, 고객 전화응대, 고객 지원까지 한다는 것은 100원의 돈을 받으면서 20원짜리 일을 하는 것과 같습니다. 그런 일은 싸게 고용할 수 있는 사람을 시켜야지요. 그리고 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못합니다. 

결국 이 개발자는 다른 소프트웨어 회사에 가면 별로 가치 없는 개발자가 되고 맙니다. 분야가 달라지면 Domain Knowledge에 의한 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 됩니다. 관리자로 가야 할까요? 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되고 맙니다.

회사는 이들에 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 됩니다.

이들이 등돌리면 회사는 휘청합니다. 

이것이 개발자 탓일까요? 아니면 회사 탓일까요? 

네, 회사 탓입니다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야죠.

그런데 맨땅에 개발자가 북치고 장구치고 다 하다 보니까, 어쩌다보니 그렇게 된 것이지요.

그럼 어떻게 해야 할까요?

조직이 작을 때부터 나중에 커질 때를 대비해야 합니다.

조직이 커지면 언제든지 분리하기 쉬운 업무부터 띄어낼 수 있도록 말입니다.

이렇게 하려면 갖춰야 할 것이 3가지 있습니다.

이는 "프로세스"와 "기반시스템" 그리고 "문서"입니다.

이 3가지가 있어야 개발 조직이 전문적으로 움직일 수 있습니다.

단 제대로 갖춰야지요. (제대로의 의미는 너무 많이 설명해야 하니 앞으로 계속 올리는 글에서 설명하도록 하죠, 그리고 사실 문서는 프로세스에 포함된 것입니다.)

혼자 일을 하더라도 "스펙"을 작성하고 "설계문서"도 작성하고 "Test Case"도 만들어 놓습니다. 물론 남에게 일을 시키는 것보다는 간소화 할 수 있습니다.

인도에 외주를 줄만큼 자세히 작성하는 것은 낭비죠.

그리고 적절한 개발 프로세스를 만들어서 조직이 커질 때마다 그에 알맞게 계속 발전시켜나가야 합니다.

그리고 "소스코드관리시스템"과 "버그(이슈)관리시스템"은 무조건 제대로 갖추고 있어야 합니다.

이전 포스트 참조하세요(기반시스템(Infrastructure System)을 사용하고 계신가요?)

이 모든 것은 혼자 소프트웨어 회사를 한다고 해도 갖추고 있어야 합니다.

프로세스, 문서 얘기가 나오니까 오히려 개발이 늦어질 것 같은가요?

혼자 개발을 해도 이것들은 꼭 필요합니다. 개발이 더 빨라지고, 제품의 품질도 올라가죠.

왜?

지금 이해가 가지 않는 분이라면, 여기서 납득을 시켜드릴 수는 없습니다. 

제 책(소프트웨어개발의 모든 것)을 읽어보시거나 저를 찾아오시면 친절하게 설명드리겠습니다.

각설하고..

그렇게 준비가 되고 나면 회사 커지면 직무를 하나씩 전문화시켜야 합니다.

우선 "테스트팀"을 만드십시오. 회사가 작다면 이들이 Technical Support(고객지원)도 병행할 수 있을 겁니다. 

물론 테스트 직무도 전문화를 시키십시오. Random Test가 아닌 제대로 된 절차에 의한 테스트를 할 수 있도록 훈련시켜야 합니다. 그 방법은 제 책을 포함해서 시중에 좋은 책들이 얼마든지 있습니다.

그리고 개발자가 많아지면 관리자를 나누고, 기획, 프로젝트 관리자, 빌드/릴리즈 역할을 나눠 나갈 수 있을 겁니다. 

아직 "프로세스", "기반시스템", "문서", 이런 것들을 갖추고 있지 않은 회사라면은 조직을 어떻게 바꿔도 결국 그 전지전능개발자에게 커뮤니케이션이 다 몰리고 리스크는 여전할 것입니다.

이렇게 회사를 바꾸려면 개발자나 회사나 모두 "성장통"을 감내해야 합니다.

개발자는 현재 자신이 하는 일에만 가치가 있다고 생각하면 안됩니다. 좀더 큰일을 하기 위해서 과감하게 현재의 일을 버리고 자신이 가장 잘하는 일에 집중해서 더욱 가치를 높여야 합니다.

회사는 이 과정에서 임시적을 생산성이 떨어집니다. 이 기간이 짧게는 5,6개월에서 길게는 1년이 갈 수도 있습니다. 부작용을 최소화 하기 위해서 점진적인 변화를 할 수도 있고, 전문가를 영입하여 한번에 바꾸는 방법도 있습니다.

회사 안에 있으면 경영자나 개발자나 이러한 상황을 잘 느끼지 못하는 경우가 많습니다.

개구리를 냄비 안의 찬물에 넣고 서서히 데우면 뜨거워서 견지디 못하는 순간이 될 때까지 잘 느끼지 못하는 것과 같은 거죠.

그냥 익숙해지는 겁니다.

이런 경우 외부의 전문가가 회사를 분석하는 것이 효과적일 때가 많습니다.

궁금하신 내용이 있으면 언제든지 E-mail([email protected])으로 연락주세요. 궁금증을 시원하게 풀어드리지요. 

장문의 글을 읽어주셔서 감사합니다.