나는 일류 개발자

 

 

 

당신이 만약 개발자라면, 스스로 자신에게 물어보자.

 

"나는 일류 개발자인가?"

 

어떤 답을 할 수 있을지 한번 생각해보자, 

그리고 지금 소속되어 있는 개발팀의 동료들을 보고 

똑같은 질문을 한다면 어떠한 답을 내릴 수 있겠는가?

 

쉽게 대답을 할 수 없다면 지금 당신과 일하는 동료들은 일류 개발자라고 볼 수는 없다.

사실 업계에서 일류 개발자라 불리는 사람들은 손으로 꼽을 만큼 몇 되지 않는다.

그리고 인정하기 싫지만, 메이저 회사에 대부분 포진해 있다.

 

그리고 조용히 성실하게 자기 일을 해나가며, 

일류 개발자가 되기 위해서 노력하는 이류 개발자와, 

일류를 흉내 내기에만 급급한 삼류 개발자들이 있을 뿐이다.

만약 프로젝트에 일류 개발자가 많이 있다면 

당연히 출시된 게임의 성공 확률은 높을 수밖에 없을 것이다.

개발 관리자나 개발자의 관점에서 개발자 수준이 

일류가 아니라는 말은 굉장히 자존심 상하는 일일 수 있다.

자존심이 상할 뿐만 아니라, 제삼자가 자신을 분류한다는 것 자체에 기분이 나쁠 수 있다.

누구나 자신만의 기준을 갖고 개발을 하고 있고, 

그런 부분에 있어 자기 일에 자부심이 있기 때문이다.

 

여기서 일류란 실력을 뜻한다. 그러나 이 실력이라는 부분에 개발 능력만을 말하는 것은 아니다.

개발 능력만 뛰어나다고 하여 일류 개발자가 된다고 하기에는, 

게임 산업은 이미 그 규모를 넘어선 지 오래다.

다시 말해서 예전처럼 개발만 치중하면 게임이 성공하는 시대가 아니므로, 

개발자에게도 더 많은 것을 요구하는 시대가 된 것이다.

개발자는 개발 능력은 물론이고 리더십, 노하우 등 

그 외에 이미지 메이킹이나 이슈거리를 제공할 수 있는 

그 무언가 특별한 재능을 함께 보여줄 수 있는 사람을 일류라고 부르는 경우가 많다.

그래서 일류 개발자는 어디 어느 곳에서나 볼 수 있을 정도로 흔하지 않다.

흔히 우리가 일류라고 부르는 사람들은 자신의 몸값을 자기가 정하지 않는다.

또한, 자신이 일하는데 보탬이 될 수 있는 환경을 가진 회사를 원한다.

그리고 회사가 그만한 인프라를 갖추고 있는지 확인할 수 있는 능력도 갖추고 있다.

따라서 이런 개발자는 메이저 개발사가 아닌 곳에서는 고용하기 어렵다.

이런 사람들을 고용한 회사는 인재의 중요성을 누구보다 잘 알고 있어서,

높은 비용을 지급하고 일류 개발자를 고용하는데 아낌없이 비용을 투자한다.

 

이류 개발자들의 경우, 일류 개발자가 되기 위해서 열심히 노력하는 개발자들이다.

대부분 회사의 리더나 핵심 인재들이 이런 개발자 위주로 조직이 구성된 경우가 많고, 

이런 사람들이야말로 중소 개발사를 키워나가고 

게임을 성공하게 하는 인재가 될 수 있는 역량을 가진 개발자들이다.

조금만 회사에서 뒷받침을 해주면 쑥쑥 커 나갈 수 있는 사람들이기 때문이다.

그래서 자기 자신만의 기준이나 생각을 명확히 가지고 있고, 

이를 통해 게임을 성공하기 위해서 어떻게든 노력을 하는 것을 힘들어하지 않는다.

자신의 능력과 한계를 잘 알고 있고, 이를 개선하기 위해서 항상 노력한다.

이런 개발자들이 차후 일류 개발자로 성장할 수 있는 그런 사람들이다.

 

자 이제, 문제가 되는 개발자는 바로 삼류 개발자이다. 80대 20 법칙이라는 것이 있다.

흔히들 "파레토 법칙"이라고도 하는데 불균형에 관한 내용이다.

여기서 개발자를 예로 든다면 20%의 개발자가 80%의 개발자를 먹여 살린다는 말이다.

20%가 일류 혹은 이류의 개발자라고 한다면 나머지 80%는 결국 삼류 개발자들이다.

주변의 대다수가 삼류 개발자인데 스스로 일류로 착각하는 개발자가 있는가 하면, 

삼류라고 인정하지 않으면서 자신은 무조건 일류가 될 수 있는 

개발자라고 막연히 희망하는 개발자도 있다.

 

물론 노력만 한다면 충분히 될 수 있다.

그러나 이런 사람들의 문제점은 아무런 준비 없이 성공만을 바란다는 것이다.

다시 말해 이류 개발자들이 쏟는 노력만큼 노력하지 않고, 

자신만의 기준이나 생각이 명확하지도 않은 상태에서 

일류 개발자들이 하는 행동만 따라 하면서 일류가 될 수 있을 거란 생각을 하는 개발자다.

예를 들면. 한동안 애자일 개발 방법론이 개발자들 사이에서 큰 인기를 끌게 되었다.

애자일 개발 방법은 어느 정도 개발 경험이 많다거나 

혹은 주체가 명확하여 이를 리딩 할 수 있는 개발자가 있다면 

개발 시 매우 효과적인 방법론으로 작용할 수 있다.

그러나 필자가 알고 있는 A라는 프로젝트의 경우 

애자일 개발 방법론을 적용하기에는 매우 무리가 있는 팀이었다.

 

일단 해당 팀은 개발에 대한 경험이 풍부하다고 볼 수 없었고 

개발 관리자조차도 처음으로 프로젝트를 이끄는 처지였다.

그 외 팀장급 역시 약 3~5년 정도의 경력을 가진 사람들이었다.

따라서 애자일 개발 방법론을 도입하고는 싶으나, 

어떤 방식으로 팀 내 적용을 해야 할지 명확한 그림을 그릴 수 있는 개발자는 없었다.

일단 부분적으로나마 도입하자는 것이 목적이라, 

시중 나와 있는 책대로 하면 무조건 잘 될 것이라는 생각으로 해당 방법론을 도입했다.

처음에는 프로젝트에 잘 맞게 돌아가는 듯싶었으나, 

문제는 시간이 지날수록 하나둘씩 나타나기 시작했다.

 

애자일 개발 프로세스를 이끄는 하는 주체가 없었다.

애자일 프로세스에 문제가 있는지 살펴보고 개선하는 작업을 

지속해서 해야 하는데 이를 할 수 있는 사람이 없었다.

또한, 만약 해당 방법론이 자신의 프로젝트 개발 방법과 

맞지 않는다면 기존 개발 방법론과 병행을 한다든지 

혹은 일부분만 도입한다든지 하는 융통성을 가진 의사 결정권자도 없었다.

결과적으로는 개발 산출물이 지연되고 이로 인해 개발 기간이 연장되는 결과에 초래했다.

결국, 해당 프로젝트는 개발 관리자가 변경되었고, 개발 프로세스를 다시 재정비하게 되었다.

 

일류 개발자가 하는 개발 방법을 따라 하는 것이 나쁜 것은 아니다.

이로 인해서 자신도 좀 더 발전할 수 있고 팀 자체적으로도 발전할 기회를 얻고 온다.

그러나 자신의 능력을 정확하게 알고 있어야지만 그러한 방법이 통하게 된다.

일류 개발자의 방법이 현재 자신의 개발사에, 혹은 팀원의 능력 밖의 일이라면 

과감히 배제하거나 혹은 변경할 수 있는 노력을 기울여야 한다.

그렇지 못한 경우 위와 같이 "뱁새가 황새를 따라가다 가랑이 찢어지는 일"이 발생하는 것이다.

 

예는 삼류 개발자 모두에게 공통으로 나타나는 문제는 아닐 수 있으나, 

대부분 이런 개발자들의 문제점은 아래와 같이 정리할 수 있다.

 

첫째, 나는 프로다. 그래서 내가 만드는 게임은 무조건 재미있고 성공할 것이다.

 

둘째, 우리 개발사도 내 게임을 위해서 

총 개발 비용의 약 50% 이상을 마케팅 홍보에 투자할 것이다.

 

셋째, 내가 함께 일하는 동료들은 무조건 100% 믿을 만하다.

 

 

 

첫 번째의 경우, 자기 실력을 과신하는 경우이다.

 

실제 자기 실력은 간장 종지인데, 큰 대야 같은 실력을 갖추고 있다고 생각하는 것이다.

실력은 자기가 평가하는 것이 아니다.

개발자의 결과와 능력을 보고 보고 타인이 평가해주는 것이다.

자기는 아무리 100% 만족하는 결과를 얻었다고 할지라도 실제 이를 보고 평가하는 

유관부서 인원이나 경영자, 개발 관리자, 혹은 플레이어까지도 

만족하지 않는다면 이는 제대로 된 결과물이라 볼 수 없다.

너무 자신의 실력에 대해 의심을 하는 사람도 문제이긴 하지만 

자기 실력을 맹신한 나머지 자신만 옳다고 생각하는 것도 문제다.

결과물에 대해 모든 사람이 "아니오!"를 외칠 때, 

자신만 "예!"를 외친다고 해결될 문제는 아니다.

이런 성향의 개발자면 외골수 경향을 지닌 사람들이 많고, 

다른 사람의 의견이나 생각은 무시하는 경우가 많다.

 

 

 

둘째, 회사를 너무 믿고 있는 경우라 할 수 있다.

 

게임 회사도 회사의 이익을 내는 것이 목표이다.

한마디로 자선사업 단체가 아니라는 뜻이다.

그래서 게임에 현재까지 투자된 비용이 얼마이든 간에, 

수익에 대한 확신이 생기지 않는다면 비용을 절감하거나, 

혹은 프로젝트 개발을 종료할 수 있다. 개발 도중이라고 할지라도 말이다.

현실을 직시하지 못하고 회사를 맹신하거나, 

게임은 산으로 가고 있는데도 방향을 수정하지 않으려는 개발자들은 많다.

대충 만들어도 회사는 어차피 개발에 들인 비용이 있으니 

함부로 프로젝트를 종료하지는 못할 것이라는 생각을 하는 것이다.

또는 그저 그런 게임을 만들어 서비스해도 일단 마케팅이 시작되면 

어느 정도의 플레이어들은 접속하여 게임을 할 것이라는 안일한 생각을 하기도 한다.

 

 

 

세 번째는 덮어주기 식 개발 문화를 말한다.

 

일단 내가 아는 사람이기 때문에, 나와 함께 일하는 동료이기 때문에 감싸주는 행동이다.

개발팀을 구성할 때 공채나 혹은 인력 구인 사이트 등을 통해서 개발자를 뽑는 일도 있지만, 

아는 지인이나 혹은 지인의 지인을 통해서 팀을 구성하는 때도 잦다.

그래서 이런 경우 서로 아는 사람이라는 끈끈함으로 인해 개발 시 협업이 원활할 수 있다.

그러나 이러한 끈끈한 정으로 인해서 개발 시 대내외적으로 

문제가 발생하여도 쉬쉬하며 덮고 지나가는 경우도 많다.

이럴 때 개발자 간의 유대감은 커질지 모르겠으나, 

프로젝트의 성공을 위해서는 불필요한 부분이다.

인맥으로 맺어진 관계라고 할지라도 업무적으로 공과 사를 정확하게 

구분할 수 있는 사람이라면 아무런 문제가 없겠지만, 그런 사람은 많지 않기 때문이다.

따라서 잘못된 것은 잘못되었다고 짚고 넘어갈 수 있는 개발팀의 개발 문화가 정착되어야 한다.

 

 

 

위와 3가지 경우 외에도 삼류 개발자가 가진 한계와 문제는 더 많다.

팀의 분위기를 흐리는 것 또한 삼류 개발자가 자주 능력을 발휘하는 특성이다.

간혹 다른 사람들과 협업이 되지 않거나 혹은 개발 이외의 

문제로 인해서 트러블을 일으키는 일도 있다.

이런 경우 개발 능력이 좋다고 할지라도 팀을 이끄는 데 

방해가 되는 잘못된 마인드를 가진 삼류 개발자임이 분명하다.

 

그렇다면 우리 스스로 또는 당신의 동료 개발자가 

일류가 되기 위해서 어떤 노력을 하는지 알아볼 필요가 있다.

일류가 되기 위해서는 개발자 자신만 잘해서 되는 것이 아니다.

개발하는 동료와의 팀워크도 중요하고, 자신이 얼마나 노력하는지, 

실력은 점차 높아지고 있는지 그리고 프로젝트에 노력한 부분이 전부 반영되는지가 중요하다.

이런 것을 바탕으로 프로젝트의 성공적인 결과가 나왔는지에 따라 일류 개발자로 도약할 기회가 온다.

여기서 말하는 것 외에 운도 따라야 하는 것이 사실이다.

하지만 노력의 밑바탕이 마련되어 있지 않다면 운은 비켜나갈 수밖에 없다.

이렇듯 실력과 노력, 다른 사람들과의 협업, 그리고 이를 통한 좋은 결과, 

이렇게 삼박자가 골고루 잘 갖춰져야지만 일류 개발자로 도약할 기회가 찾아온다.

 

개발 관리자나 개발자는 항상 자신에게 이런 질문을 할 필요가 있다.

 

"내가 일류면 지금 개발하는 개발사는 내가 다닐만한 곳인가?"라는 것이다.

 

현재 상황을 정확하게 직시하는 데 도움을 줄 수 있는 질문이다.

이런 질문을 던졌을 때, 당신이 얻어낸 대답이 

"내가 이런 XX같은 개발사에 계속 있으면 난 발전이 없을 거야.

그냥 대충 일하다가 더 좋은 곳으로 옮겨야지."라고 생각한다면 절대 일류가 될 수 없다.

 

물론 자기가 발전하는 데 있어, 개발사가 걸림돌이 된다면 과감히 이직할 필요는 있다.

그러나 자신으로 인해서 개발사를 발전시킬 수 있다는 생각을 배제한 체, 

개발사 탓만 하는 것은 자기 발전을 위해서도 반드시 버려야 할 생각이다.

이직을 선택하더라도, 자신이 일할 수 있는 회사에 대해 분석하고, 

그 회사가 원하는 인물상은 어떤지를 파악하는 것은 꼭 필요한 자세 중 하나이다.

그 회사의 경영, 개발 프로세스 등과 개발 환경, 문화 등을 

잘 판단해보고 자신이 목표한 방향과 잘 맞는지 확인해야 한다.

 

그 후, 자신의 실력을 그 회사에 맞게 만들고 경험과 실력을 쌓은 후 

인정받기 위해 노력해야지만 자신이 원하는 회사로 이직하는 것이 수월해질 수 있다.

간혹 인맥만으로 회사를 선택할 수가 있는데, 자신이 선택한 올바른 결정이 없다면 

위와 똑같이 회사에 대한 불만만 쌓여갈 뿐이다. 개발 관리자는 이런 부분을 더욱 조심해야 한다.

개발 관리자가 이러한 불만을 쌓고 있다면, 그 조직의 분위기 자체가 엉클어지게 된다.

업무를 진행하면서 안일해지기 시작하고, 성공을 위해서 서로 노력하고 

격려하는 모습은 사라질 수 있다는 것을 명심해야 한다.

 

필자가 잘 활용하는 방법으로 내가 되고 싶은 역할을 뽑는 

구직 사이트의 구인 광고 스펙과 나의 이력서 스펙을 비교해 

부족한 점이 무엇인지를 체크하고 부족한 부분을 체크하면, 

좀 더 구체적인 어떤 노력을 해야 하는지 결과를 얻을 수 있었다.

내가 일류가 아닐지라도 혹은 동료가 일류가 아닐지라도, 

개발하는 게임이 성공할 가능성은 얼마든지 있다.

일류가 없다고 하여 게임이 다 실패할 것이라는 말은 하지 않는다.

오히려 은근과 끈기를 앞세워 성공하는 기회를 잡을 수 있다.

무조건 일류가 하는 개발 방법을 따라 하려 하지 말고, 

현재 자신이 할 수 있는 범위 내에서 상황을 극대화하여 개발하려 노력해야 한다.

 

대형 개발사만이 게임을 성공할 수 있는 것은 아니다.

만약 대형 개발사만 성공한다면 그들이 가진 자본력이나 인프라가 없다면 

게임은 성공할 수 없다는 뜻이 되어버린다.

무조건 일류가 하는 방법을 따라 하는 데 급급하지 말고 자신의 회사의 상황에 맞춰, 

혹은 능력에 맞춰서 어떠한 방식으로 게임을 개발하는 것이 

성공으로 갈 수 있는지 항상 생각하고 이를 바탕으로 게임을 개발하고 

프로젝트를 운영할 수 있도록 해야 한다.

 

 

 

[출처]

www.itester.co.kr/2012/11/blog-post_11.html