한빛출판네트워크

 

『개발 7년차, 매니저 1일차』 214쪽 중

 

매니저에 대한 글을 부탁 받고 주저할 것도 없이 승락을 했습니다. IT 업계에서 매니저의 중요성을 어느 때보다 실감하고 있고, 한국과 일본 그리고 미국의 기업에서 경험한 매니저라는 역할에 대해 하고 싶은 이야기가 많았기 때문입니다.

· · ·

고령화 사회와 매니저
2000년대 초반, 외환위기가 할퀴고 간 한국 사회엔 ‘정리해고’라는 단어가 생겼습니다. 열심히 공부해서 좋은 대학 들어가고 졸업해서 이름 있는 기업에 들어가면 평생 먹고살 걱정은 없을 줄 알았는데, 경영자의 실패로 한순간 직장을 잃을 수 있다는 현실에 사람들은 경악하게 됩니다. 이런 당시 분위기를 잘 반영한 단어가 ‘사오정 오륙도’입니다. 45세가 정년이고 56세까지 일하면 도둑놈이란 말입니다. 2019년도의 대한민국 기대수명은 대략 82세가 넘는데 45세가 정년이라니 너무나도 끔찍한 일이 아닐 수 없습니다. 그리고 어느덧 20년이라는 세월이 흐른 오늘날 우리는 심각한 인구절벽을 마주하고 있습니다.

2018년 한 통계에 의하면 우리나라는 건국 이래 처음으로, 아니 지구상의 모든 국가를 통틀어 처음으로 합계출산율이 0.98명이 되었습니다. 인류 역사상 유래가 없는 상황입니다. 이렇게 젊은 사람이 급속도로 줄어들면 앞으로 45세 정년을 걱정하는 게 아니라 은퇴가 없는 삶을 걱정해야 할지 모릅니다. 정년 이후 은퇴하지 못하고 열악한 노동 시장에 내몰리는 삶 말입니다.

뜬금없이 고령화 이야기를 꺼낸 것은 이러한 역피라미드형 인구 구조 덕분에 매니저가 자신보다 더 나이 많은 팀원들과 함께 일해야 하는 경우가 점점 많아지기 때문입니다. 실제로 우리나라보다 고령화가 먼저 진행된 일본에서는 오래전부터 팀원이 매니저보다 나이가 많은 경우를 흔히 볼 수 있습니다. 나이 많은 팀원을 두면 뭐가 어떻게 다를까요?

· · ·

매니저는 직급일까, 아니면 직책일까
일반적으로 조직 내에서는 직위에 의해 상하관계가 만들어집니다. 우리에게 친숙한 직위로는 선임, 주임, 대리, 과장, 차장, 부장 등이 있습니다. 반면 직책은 업무에서의 책임과 권한에 대한 이름입니다. 예를 들면 파트장, 팀장, 실장, 본부장, 사업부장 같은 것들이 대표적인 직책의 명칭입니다.

그러면 매니저는 직위일까요, 직책일까요? 많은 회사들이 매니저를 직책명인 팀장과 같은 의미로 사용하고 있습니다. 하지만 본래 외국계 기업에 있어서 매니저는 직급이나 직책이라기보다는 역할명에 해당됩니다.

수평적인 기업 문화 속에서 매니저는 상급자라기보다는 팀원들이 자신의 일을 원활하게 할 수 있도록 도와주는 집사에 가깝습니다. 매니저라는 역할의 주요 업무는 다음과 같습니다.

한마디로 테크 기업에서 매니저는 팀에 주어진 미션을 달성하기 위해 팀을 만들고 그 팀이 원활하게 기능하고 성장하도록 도움을 주는 책임을 지닌 자리입니다.

· · ·

· · ·

유교 문화와 고령화 시대의 매니저
어릴 때부터 나이에 따른 서열을 중시하는 이른바 유교 사상에 길들여진 대한민국 사회에서는 자신보다 나이가 어리거나 나중에 입사한 사람에게 명령을 받는 것은 자연스럽지 못하다는 인식이 뿌리깊게 박혀 있었습니다. 그러다 보니 직무에 대한 명령을 전달하거나 대리하는 상급 직위로서의 팀장 혹은 매니저에게 자신보다 나이가 많은 팀원이 존재하는 것은 무척 곤혹스러운 일로 여겨졌습니다. 그런 일이 벌어지지 않도록 신입 사원의 나이를 제한하거나 동기나 부하가 승진하는 경우 나이가 더 많은 팀장이 있는 부서로 이동시키거나 심지어 퇴직시키도 합니다.

하지만 지금은 사정이 달라졌습니다. 수평적인 문화가 IT 기업 사이에서 점차 확산되면서 연장자에 대한 공경과 매니저 역할이 상충되지 않을 수 있는 토대가 마련되고 있습니다. 어려서부터 길들여져온 유교 사상에서 벗어나는 것이 말처럼 쉬울까요? 저는 기업 최고경영자의 의지와 몇 가지 원칙만 잘 지켜진다면 한국 사회에서도 수평적인 기업 문화가 충분히 정착 가능하다고 생각합니다. 실제 그런 사례를 주변에서 목격했습니다.

· · ·

수평적 조직 문화와 매니저
그럼 수평적 조직 문화란 무엇일까요?

수평적 조직 문화는 조직 내 구성원 모두가 같은 권한을 가진다는 것을 의미하지는 않습니다. 기업이나 조직은 특정한 목적을 달성하기 위해 존재하므로 이런 목적을 달성하기 위해 적합한 의사결정 구조를 지니며 당연히 책임이나 전문성에 따라 다른 권한을 가질 수밖에 없습니다. 하지만 이런 권한은 합리적인 원칙에 의해 부여되며 단순히 직위가 높다고 해서 권한이 따라오는 구조는 아닙니다.

창의성을 극대화해야 하는 IT 기업에게 수평적 조직 문화는 제품이나 프로젝트만이 아닌 조직 자체에 대한 주인 의식을 고취시켜주는 중요한 장치이며, 이 주인의식이야말로 개개인의 창의성과 능력을 최대한 발휘하게 하는 토대가 됩니다.

개발자의 경력 경로는 사다리가 아니라 정글짐개발자의 커리어 패스에서 매니저는 필수일까요? 예전에는 경력이 많은 개발자는 관리직이 되거나 아니면 퇴직하는 것이 일종의 관례처럼 되어 있습니다. 하지만 지금은 그런 모습이 점차 사라지고 있습니다. 나이가 든다고 해서 꼭 매니저를 한다기보다는 관리직이 적성에 맞는 사람이 한다는 인식이 점차 퍼지고 있습니다.

개발자로 통칭되는 기술 기반 직군은 코드를 직접 만드는 프로그래머 이외에도 세분화된 다양한 역할이 있습니다. 예를 들자면 프로그래머도 프론트엔드나 백엔드 개발자로 분류되고 품질을 책임지는 QA, DB를 유지 관리하는 DBA, 인프라를 포함해 시스템의 안정적인 운영을 책임지는 운영자, DevOps 파이프라인의 구성과 운영을 책임지는 DevOps 엔지니어 등 다양한 역할이 존재합니다. 매니저도 그런 역할의 하나일 뿐입니다.

저는 개발자로서 일하면서 꼭 한 가지 길만 고집할 필요는 없다고 봅니다. 개발자의 경력 관리 측면에서 여러 역할과 직책을 두루 경험해보는 것은 앞으로 맡게 될 직책이나 역할을 수행해 나가는 데 분명 유리한 측면이 있기 때문입니다.

만약 매니저를 하다가 적성과 맞지 않거나, 아직 이르다고 판단되면 일반 개발자로 돌아갈 수도 있어야 합니다. 이를 좌천으로 보아서는 안 됩니다. 매니저는 더 많은 권한을 가지는 만큼 스트레스도 큰 자리입니다. 기술만 다루면 되는 개발자에 비해 사람과 조직 그리고 비즈니스까지 시야에 넣어야 합니다. 기술과 관련해서 올바른 결정을 내리려면 최신 기술에 대한 꾸준한 학습도 필요합니다. 나이 많은 개발자가 매니저가 되는 것은 더 높은 직책이어서가 아니라 이런 요구사항을 충족시키기 위해서는 오랜 기간이 필요하기 때문입니다.

· · ·

매니저 직은 개발자의 무덤인가
매니저에 대한 이야기를 마치기 전에 언급하고 싶은 것이 한 가지 있습니다. 앞서 매니저 역할은 스트레스도, 요구되는 역량이나 책임도 크다고 이야기했습니다. 하지만 매니저가 기피되는 현실적인 이유가 하나 있습니다. 바로 이직의 불리함입니다. 우선 인력 시장에서 수요가 개발자보다는 적습니다. 아무래도 조직의 인력 구조상 매니저는 그 수가 적을 뿐 아니라 여러 가지 정치적, 외교적인 역량도 요구되는 자리인 만큼 외부에서 매니저를 채용하기보다는 가능한 한 내부에서 매니저를 키우려 하기 때문입니다.

다시 개발자로 돌아가려 해도 일단 매니저가 되고 나면 실무에서는 손을 떼게 되기 때문에 매니저를 오래 하다 보면 요즘 채용 프로세스의 트렌드인 기술 면접이나 코딩 테스트에는 아무래도 불리할 수밖에 없습니다. 솔직히 이 부분에서는 뾰족한 해답이 없습니다. 기술직 매니저로서의 전문성과 역량을 더욱 키울 것인가 아니면 개발 일선으로 언제든지 돌아갈 수 있게끔 기술을 손에서 놓지 않을 것인가는 개개인이 선택해야 할 문제입니다.

다만 앞으로도 개발이나 IT와 관련된 일자리는 계속해서 늘어날 것이 자명합니다. 따라서 기술 조직을 전문으로 하는 IT 매니저의 수요도 꾸준히 증가할 것입니다. 우리가 매니저가 되는 그때를 대비해야 하는 이유가 여기에 있습니다.

 

 

정도현(정개발)

일본과 한국에서 개발자, 아키텍트, IT 컨설턴트로서 20년 넘게 일해 오다 현재는 AWS 코리아에서 테크니컬 트레이너로 일하고 있다. 이전에는 프로그래머를 위한 팟캐스트 ‘나는 프로그래머다’에서 ‘정개발’이라는 별명으로 활동하기도 했다. 저서로는 『팟캐스트 나는 프로그래머다』, 공저, 역서로는 『실전 AWS 워크북』과 『배워서 바로 쓰는 14가지 AWS 구축 패턴』이 있다.