티스토리 뷰

연륜과 경험이 무시되는 한국 IT, 노년의 백발을 가진 소프트웨어 개발자를 키워야 하는 이유?


최근 어떤 기사에서 이런글을 본적이 있습니다. 50대 부터 은퇴 준비를 시작한다고요.. 그런데 재미있는 것은 IT 업종은 이미 30대 중반이 되면 미래를 준비한다는 이야기가 있습니다. 개발자는 40살이 마지막이고 관리자나 다른 업무로 영역을 넓히지 않으면 결국 은퇴가 예정되었다고요. 


제가 존경하고 롤모델로 삼고 있는 선배가 있습니다. 물론, 개발자입니다. 제가 기획자라는 걸 아는 사람이면 기획자가 무슨 개발자를 롤 모델로 삼냐고 의아해 하실지 모르겠습니다. 


그런데.. 조금이지만 개발 공부도 했었습니다. 물론 이 길이 아닌갑다하고 다 때려치고 이 업종에 들어섰지만 말입니다. 


제가 그 선배를 좋아하고 롤모델로 삼은건, 흐트러짐이 없고 자신의 목표와 목적을 명확히 알고 있다는 점입니다. 어려운 여건과 상황에서도 전 잘 흥분하기도하고 때론 멘붕 상태가되.. 허우적대는데 반해 그 선배는 그런 저의 부족함을 거울 삼을 만큼 훌륭한 자질을 가지고 계시죠. 


전 일이 바빠지면 지인들과 연락을 잘 안하게 됩니다. 아니.. 안한다기 보다는 생각을 안합니다. 일에 빠져버리죠. 약간 이런 부분은 개발자 스타일 같은데.. 개발은 하기 싫으니 의외이긴 합니다. 


암튼.. 그런 상황에서 먼저 연락을 주시고 챙겨주시죠. 응원도 해주시고요. 그런데 이 선배가 몇년전 (당시엔 충격이었는데 이제는 익숙해 졌네요.. ㅡㅡ;) 40살 넘어가면 은퇴준비로 편의점이나 해야 할까보다 하시더군요. 


급자기 오늘은 그 씁쓸함이 생각나서..이야기를 해보려고 합니다. 





왜? 40대 은퇴를 준비한다고 했을까?

이 선배가 이런 이야기를 하자. 제가 물었지요. "형.. 왜요? 형.. 개발일 좋아하시고 학부때 늙을때까지 하고 싶다고 하셨잖아요?", 그러자 그 형님이 "하고야 싶지 임마, 근데 그게 내맘대로 되냐? 젊은 애들 치고 올라오는데, 위에서 연봉 높고 말은 많아지는 고급 개발자 쓰겠냐구?"


참씁쓸했습니다. 작은 단위로 경영자 입장에서 보면 2~3년차 개발자 (이제 막 개발을 알고 일을 좀 시켜먹을만한 연차인데 반해 단가는 매우 싸다고 알려져 있죠) 몇명 더 부리는게 이익이라고 생각하는 것 같습니다. 


단순한 수치적 경영관으로 본다면 틀린말은 아닙니다. 연봉작고 초 고급 기술이 필요한 일이 아니면 인력 여러명 부려서 프로젝트 2~3개 수주하는게 남는 장사라고 볼 수 있으니깐요?


하지만, 이런식으로 프로젝트를 진행하는 경우 신입 개발자들은 좋은 경험을 쌓기 어렵고, 기술적으론 하급 기술과 당장 구현에만 초점을 맞추기에 결국에는 좋은 소프트웨어가 나오기 어렵습니다.


개발자의 40대 은퇴설이 나도는 것은 상당 부분은 경영자 마인드가 문제이지만, 고급 개발자를 지속적으로 고용하기 힘들게 만드는 산업적 구조도 어떻게 보면 근본적 원흉이라고 할 수 있습니다. 


단가 후려치기, 개념 상실한 단가 책정... 등으로 제대로 된 소프트웨어 노임 단가를 받기 어려운게 지금의 한국 현실입니다. 


기본적으론 경영자가 고급 개발자를 바라보는 관점을 바꿔야 하고, 더 나아가선 국가적으로 소프트웨어 개발 단가의 현실화와 개념있는 산정 모델 도입이 필요하다는 생각입니다. 



은퇴가 아니면 뭘할까?

얼마전 페북으로 네이버에 계신 모 블로거분과 이야기를 하는데.. 이와 비슷한 이야기를 했습니다. 그러다 그분에게 앞으로 개발쪽에 계시기 힘들텐데, 어떻게 준비하냐고 했더니.. 아직 40대를 넘긴 분이 아니셨음에도.. 


개발쪽일은 거의 손때고, 기획/운영쪽에 포커스 맞춰 일종의 업종 변경을 하셨다고 하더군요. 


그게 더 그분에게 맞는 일이라면 좋겠지만, 개발을 더 하고 싶은데 못하는 것이라면.. 참 서글픈일이 아니겠습니까?


이 사례에서 보면 알 수 있듯.. 관리자와 운영자.. 개발영업등.. 비 개발 직군으로 업종을 변경하지 않으면 사실 당장 이 업계에 있기 힘든게 사실입니다. 


오늘 IT 업종에선 꽤 유명하신 전규현 컨설턴트님이 쓰신글을 보았는데, 한국에서는 Technical track과 Management track을 구분해야 하는데 인식이 부족하다는 말씀을 해주셨습니다. 그에 대한 근본적 원인을 이 분은 Technical career path 가 없기 때문에 관리자가 되지 않고서는 개발자로소 회사내에서 파워(존재감)을 유지하기 힘들기 때문이라고 진단하고 있습니다. 


즉, 관리와 개발분야는 단순히 직급 차이를 넘어서 접근법이 틀림에도 한국에서는 일정 수준이 되면 경험과 경력을 바탕으로 관리를 통해 조직을 장악하고 이를 바탕으로 회사 경영의 일임을 담당해야 한다는 인식이 암묵적으로 형성되어 있다는 걸 이야기하고 있는 것이죠. 



해외 사례는 어떤가?

아무래도 공대 출신이다 보니 대부분 선후배가 개발직종에 있는데, 현재 대학원에 있는 후배가 몇년전 세미나 때문에 미국에 갔다와서 이런 사례를 이야기해 주었습니다. 


해외에 가니깐 나이가 지긋한 백발 개발자가 검색 컨퍼런스에 와있더라는 것입니다. 물론 이 친구도 말걸어서 정보를 교환 할 정도로 나서는 친구는 못되서 이야기는 못해봤는데, 자기 딴에는 충격이 컸다고 하더군요. 


제가 업계에서 듣기로도 해외는 개발직군과 관리 직군이 나뉘어 있어서 개발직군은 나이가 들어도 개발만하고 관리직군은 관리만 한다더군요. 물론 서로 직군을 옮기는 일도 있지만, 개발자는 보통 개발만 한다는 것입니다. 


그렇게 안정과 개발에 대한 주권을 인정하는 만큼 도퇴되지 않기 위해 끊임 없이 노력을 해야하긴 한다고 합니다. 백발의 나이에도 기술적으로 이제 개발에 들어 온 후배들에게 뒤지지 않을 만큼의 식견과 실력을 갖추기 위해 노력해야 그 나이가 되도 개발일을 할 수 있다는 것입니다. 


회사가 어려워져도 개발쪽에서 큰 비중이 있는 인력은 잘리지 않고 매니징 하는 직군이 잘린다는 이야기도 있습니다. 또, 실제로 연봉도 직급면에서는 더 높은 매니저지만 전문 개발만 한 개발자가 실제 연봉을 더 받기도 한다고 합니다. 


해외의 경우 전규현님이 이야기하시는 것 처럼, 올바른 개발 체계를 갖추기 위해 파워가 필요할때 직급으로 승진해 파워를 갖는게 아니라, 개발 실력과 능력으로 인정받고 이를 바탕으로 후배와 매니저들의 지지를 이끌어내는 문화가 있다고 합니다. 


사실 이게 올바른 방향이란 생각을 갖게되는게 사실입니다. 



개발자의 권력과 매니저의 권력.. 

한국 같은 경우 직급이 높은 매니저가 개발에 관여해 업무 프로세스를 망가뜨리는 경우가 종종 있습니다. 개발자 관점에서 시스템을 설계하고 방향을 잡아가야 하지만 경영적 마인드에 따라 장기적인 관점을 보지 못하고 개발자 의견을 무시하고 자신의 생각과 의견을 따르길 강요하는 경우가 있습니다. 


해외는 이럴떄 개발자의 의견이 존중된다는 군요. 매니저는 정확한 프로젝트 진행과 관리를 위해 비개발적인 업무를 전담하고 개발자는 개발일에 특화하는 거죠. 예를들면 새로운 서비스를 개발 할때 전체적인 아이디어등은 같이 논의하더라도 개발일정, 개발에 따른 시스템 설계와 방향은 모두 개발자(보통 팀장이겠죠) 협의해 전체적인 업무 스케줄을 자는다는 거죠. 


그리고 일정관리와 그 이외의 인력 수급 및 다양한 경영지원과 프로젝트 운영 관리의 업무는 매니저가 전담하면서 확실한 업무 분담이 이루어 진다는 거죠. 


그런데 한국은 이게 기형적이라.. 외주를 하는 경우 보통 비 개발자 출신의 영업 및 기획자가 찾아와 전체적인 스펙을 정하고 개발에 대한 대략적인 스케줄과 내용을 정해 개발팀에 전달하는 프로세스가 일반적입니다. 


물론, 한국이 미국과 구조적으로 다른 문제도 있기는 하지만, 업무 분담과 전담에 따른 능동적이고 합리적인 프로세스가 한국에는 없다는 생각입니다. 


그리고 이는 단순히 문화적인 문제가 아니라 기본적으로 갑이나 을 모두 이런 부분에 대한 투자와 지원에 인색하다는 문제가 있습니다. 전체적으로 보면 갑과 을의 관계 개발자와 매니저의 관계가 좀 더 명확하고 체계화 할 필요가 있습니다. 



한국의 IT 개발 능력이 업그레이드 되기 위해서는

제목에서 적고 있듯이 백발이 되도록 개발만 할 수 있는 체계가 만들어져야 합니다. SI 쪽이나 공공 기관 쪽에선 아마 레퍼런스를 만들기 힘들 겁니다. 워낙 몰지각한 구조가 일반화 되서요. 


가능하다면 네이버 같이 플랫폼 사업자나 좀 더 외부 여건에 휘둘리지 않고 개발주체를 확실하게 지우너 할 수 있는 IT 기업에서 먼저 시도를 좀 했으면 좋겠습니다. 


개발팀의 직급 체제를 없애고, 프로젝트마다 담당자 제도를 만들고 기술적인 프레임에서 설계와 전반적인 개발팀 구성을 맞기고 이것이 끝나면 매니저 팀에 프로젝트 관리를 일임해 각가 분담 된 개발 업무만 전담해 프로젝트를 끌고 갈 수 있게 하자는 것이지요. 


물론, 이렇게 하려면 개발 범위와 개발 내용을 아주 명확하게 선별하고 틀을 잡아 낼 수 있는 기업 스스로의 개발 롤 모델이 필요합니다. 이것에 대한 교육도 필요하고요. 


저희 같은 경우 소규모라서 그런 것도 있지만, 적은 인원이 담당해야 할 업무가 많아서 실제 계획한 일정대로 움직이지 않는 경우가 너무 많습니다. 이런게 때론 능동적이고 즉각적이라 도움이 되지만, 계획한 일정이 늘어진다는 부분에서 문제가 있기도 합니다. 


암튼.. 이런 조직 체계를 좀 갖추고 제대로 된 개발자를 육성해야 한다고 생각합니다. 기술이 쌓이다 보면 정말 큰 가치를 발현합니다. 개발 기술은 지식이기 때문입니다. 이런 숙성된 노하우와 경험이 쌓이고 여기에 신기술이 덧입혀져야 제대로 된 개발 인력들이 지속적으로 배출될 수 있는 거죠. 


이렇게 되려면 좋은 개발자가 앞에서 이끌어주고 노하우를 전수하며 후배 개발자를 끌어내는 선순환의 구조가 되어야 합니다. 이렇게 되려면 40대에 짤릴지 모른다는 불안감이 없는 직업이 되어야 하고 말이지요. 


조금씩 좋은 사례가 나오는 만큼 머지 않아 좋은 결과가 있으리라 믿습니다만.. 비 개발자 출신의 매니저님들도 이 블로그를 보시고 계시리라 생각되기에 관련글 한번 소개해 봤습니다. 도움 되셨기를 바라고 생각이 다 다를 수 있는 만큼 딴지는 사양합니다. 

댓글