개인 플레이에 능한 개발자들, 관리직에 오르면 의외로 헤매
기술에 특화되어 있다면 그에 맞는 기회를 제공해주어야
[보안뉴스 문가용 기자] 수석 개발자의 위치에 올랐다고 해서 모두 관리자의 능력을 갖추고 있는 건 아니다. 사실대로 말하자면 개발도 잘하고 관리도 잘하는 사람은 드물다. 개발자라는 직업을 가진 사람들의 성향 상 대부분 ‘개인 플레이’에 능하기 때문이다. 혼자 컴퓨터 화면 앞에 앉아 생각하고 고민하고 풀어내는 것이 알파와 오메가인 사람들인 것이다.
그렇지만 인생 어디 마음대로 되는가. 개발자의 코스를 착착 밟아나가다 보면 회사에서 어느 순간 ‘관리자’의 임무를 준다. 원하든 원치 않던 말이다. 분위기가 그러니 개발자들도 그 관리자 임무를 받아들이지 않으면 더 높은 곳으로 치고 올라가지 못할 거 같은 두려움을 느낀다. 회사마다 나름의 상황이 있겠지만 관리에 관심이 없는 사람이 경력이 찼다는 이유만으로 관리를 시작하게 되면 회사 다니기 재미없어지고, 관리 하에 있는 팀원들도 에너지가 떨어지고, 회사가 기대하는 효율적인 시스템을 갖출 수 없게 된다.
관리 실수
필자 역시 주니어 개발자들의 멘토 역할을 맡을 때가 있는데, 개발만 하던 사람에게 사람과 팀, 프로젝트를 관리하는 건 너무나 어려운 일이다. 나와 비슷한 처지에 놓인 동료 개발자들 역시 ‘관리자 역’을 맡게 되었을 때 퉁퉁 부은 얼굴로 근무시간을 채우곤 했다. 개발자일 때는 회사 에이스였는데, 관리자 자리에 앉혀놓으니 고문관이 되던 경우도 많이 봤다. 다만 개발 자체가 아니라 승진이 목표인 사람들은 관리직도 나름 기쁘게 받긴 하더라.
아무튼 결국엔 개발직에서 관리직으로 옮겨가는 것이 너무나 당연한 것처럼 자리 잡았다. 그리고 관리직의 자리에까지 오르면 개발자들은 더 이상 코딩 스킬을 연마할 수 없게 된다. 그 동안 쌓인 지식만 자꾸만 재활용할 뿐이다. 그러니 시간이 갈수록 팀원에 대한 의존도가 높아지고, 어느 순간부터는 젊은 개발자들이 무슨 소리를 하는지 잘 못 알아듣게 되기도 한다. 아래에선 치고 올라와, 자기는 윗사람 기분만 맞춰야 하는 순간이 찾아온다.
여기서부터는 악순환이 시작된다. 개발자들은 개인의 실력을 키우는 것이 삶의 보람인 사람들인데, 그 기회가 끊겨버린다. 더 잘 할 수 있고 뭔가 더 잘 만들 수 있는 기회가 사라지니 자존감이 떨어지고 자기 자신에 대한 가치를 의심한다. 그러니 더 열심히 뭔가를 하는데, 회사에서 요구하는 바가 있으니 팀원들을 닦달하는 식으로 표출된다. 개발자로서의 자존감은 더 낮아진다. 그러면 그냥 그런 현실을 받아들여 개발자가 아니라 관리자로 돌아서거나, 회사를 그만두거나, 회사의 성공이 곧 나의 성공이라고 타협한다.
굳이 이럴 필요가 있을까? 관리자가 되고 싶다면야 당연히 그런 기회를 회사에서 주어야겠지만, 그렇지 않다면 이는 양자 모두에게 손해다. 인재를 제대로 활용도 못할 뿐만 아니라, 그 나쁜 영향을 멀쩡한 주니어들에게도 뻗칠 수 있게 한다. 그렇다면 연수가 차오를 대로 차오른 수석 개발자들은 어느 방향으로 경력을 쌓아가야 할까? 경험 상 다음 몇 가지가 가장 바람직하다.
소프트웨어 아키텍트. 기술력에 특화되어 있는 개발자들이 보통 꿈꾸는 종착지다. 물론 회사마다 이름이 조금씩 다를 수는 있다. 이들은 회사 전체가 사용할 소프트웨어들을 선택하고 소프트웨어들이 사용되는 작업 프로세스 전체를 기획하고 만들어내는 역할을 한다.
주니어 개발자들이 가장 많이 멘토로 삼는 것이 바로 이 소프트웨어 아키텍트들이다. 문제 해결에 특화된 전문성을 보유하고 있으며, 10년 이상 특정 소프트웨어에 대한 경험을 축적해왔거나 여러 소프트웨어를 사용해온 경험이 풍부해 다양하거나 보편적인 소프트웨어 및 플랫폼에 능통한 모습을 보인다.
개발자들이 훗날 아키텍트가 되려면 신기술에 대한 학습을 끊이지 않는 게 가장 중요하다. 소프트웨어 개발이나 특정 기술에 아무리 특화되어 있더라도 소프트웨어 개발 과정 전체에 대한 지식 정도는 풍부히 가지고 있어야 하고, 반대로 ‘제너럴리스트’에 가까운 개발자라면 특수 분야 혹은 주무기가 될 만한 전문지식을 보유하고 있어야 한다.
수석 개발자. 개발자 관리자라고 불리기도 한다. 시간 관리에 능하고 사람 대하는 기술이 뛰어난 개발자들에게 잘 어울린다. 개발에 특화된 사람들과 개발을 이해하지 못하는 사람들 사이에서 다리 역할을 맡는다. 그렇기에 프로젝트 관리를 하면서 일을 여기저기 잘 조율하고 배분한다.
이런 데에 소질이 보이는 개발자가 있으면 소그룹 프로젝트를 만들어 관리자 역할을 주어보는 것이 좋은 방법이다. 마감을 잘 지키는지, 마감 내 어느 정도 퀄리티가 나오는지, 팀원들의 만족도는 어느 정도나 되는지 살펴봐가면서 후보를 정하는 것이 위에서 설명한 악순환을 막는 방법이다.
수석 기술 프로젝트 관리자. 예산 및 자원 관리에 능한 개발자에게 어울리는 직책이다. 수석 기술 프로젝트 관리자는 인적 측면에서가 아니라 예산의 측면에서 프로젝트를 진행하는 데 능하며, 그러므로 사전에 뭔가를 계획해서 실행하는 성향을 가졌으며 효율성을 굉장히 따진다는 특성도 있다. 압박에 강한 타입이다.
조직 입장에서 수석 기술 프로젝트 관리자 후보들을 어떻게 추리고 양성해야 할까? 먼저 프로젝트의 기획부터 맡기고, 자원과 시간을 어떻게 배분하고 관리하는지를 지켜봐야 한다. 위와 다른 건 기획 단계부터 맡긴다는 것이다. 이들은 보통 ‘자기가 기획한 프로젝트’에서 빛을 발한다는 특징을 가지고 있다. 그러니 기획한 내용이 회사의 사업 방향과도 잘 맞는 것도 중요히 봐야 할 부분이다.
개발자들은 의외로 여리여리한 사람들이다. 이들은 묵묵하고, 자기 스스로의 실력을 다듬어가는 걸 즐긴다. 이런 사람들에게 어떤 위치를 강제로 부여한다는 건 – 물론 회사도 ‘진급’시켜주는 것이겠지만 – 깊은 상처를 주는 행위일 수도 있다. 그리고 실제 회사의 갑작스런 진급 결정 때문에 그만두고 회사를 나가고 식당을 차리는 개발자들이 수도 없이 많다.
글 : 루디 머터(Rudy Mutter)
[국제부 문가용 기자(globoan@boannews.com)]
기술에 특화되어 있다면 그에 맞는 기회를 제공해주어야
[보안뉴스 문가용 기자] 수석 개발자의 위치에 올랐다고 해서 모두 관리자의 능력을 갖추고 있는 건 아니다. 사실대로 말하자면 개발도 잘하고 관리도 잘하는 사람은 드물다. 개발자라는 직업을 가진 사람들의 성향 상 대부분 ‘개인 플레이’에 능하기 때문이다. 혼자 컴퓨터 화면 앞에 앉아 생각하고 고민하고 풀어내는 것이 알파와 오메가인 사람들인 것이다.
[이미지 = iclickart]
그렇지만 인생 어디 마음대로 되는가. 개발자의 코스를 착착 밟아나가다 보면 회사에서 어느 순간 ‘관리자’의 임무를 준다. 원하든 원치 않던 말이다. 분위기가 그러니 개발자들도 그 관리자 임무를 받아들이지 않으면 더 높은 곳으로 치고 올라가지 못할 거 같은 두려움을 느낀다. 회사마다 나름의 상황이 있겠지만 관리에 관심이 없는 사람이 경력이 찼다는 이유만으로 관리를 시작하게 되면 회사 다니기 재미없어지고, 관리 하에 있는 팀원들도 에너지가 떨어지고, 회사가 기대하는 효율적인 시스템을 갖출 수 없게 된다.
관리 실수
필자 역시 주니어 개발자들의 멘토 역할을 맡을 때가 있는데, 개발만 하던 사람에게 사람과 팀, 프로젝트를 관리하는 건 너무나 어려운 일이다. 나와 비슷한 처지에 놓인 동료 개발자들 역시 ‘관리자 역’을 맡게 되었을 때 퉁퉁 부은 얼굴로 근무시간을 채우곤 했다. 개발자일 때는 회사 에이스였는데, 관리자 자리에 앉혀놓으니 고문관이 되던 경우도 많이 봤다. 다만 개발 자체가 아니라 승진이 목표인 사람들은 관리직도 나름 기쁘게 받긴 하더라.
아무튼 결국엔 개발직에서 관리직으로 옮겨가는 것이 너무나 당연한 것처럼 자리 잡았다. 그리고 관리직의 자리에까지 오르면 개발자들은 더 이상 코딩 스킬을 연마할 수 없게 된다. 그 동안 쌓인 지식만 자꾸만 재활용할 뿐이다. 그러니 시간이 갈수록 팀원에 대한 의존도가 높아지고, 어느 순간부터는 젊은 개발자들이 무슨 소리를 하는지 잘 못 알아듣게 되기도 한다. 아래에선 치고 올라와, 자기는 윗사람 기분만 맞춰야 하는 순간이 찾아온다.
여기서부터는 악순환이 시작된다. 개발자들은 개인의 실력을 키우는 것이 삶의 보람인 사람들인데, 그 기회가 끊겨버린다. 더 잘 할 수 있고 뭔가 더 잘 만들 수 있는 기회가 사라지니 자존감이 떨어지고 자기 자신에 대한 가치를 의심한다. 그러니 더 열심히 뭔가를 하는데, 회사에서 요구하는 바가 있으니 팀원들을 닦달하는 식으로 표출된다. 개발자로서의 자존감은 더 낮아진다. 그러면 그냥 그런 현실을 받아들여 개발자가 아니라 관리자로 돌아서거나, 회사를 그만두거나, 회사의 성공이 곧 나의 성공이라고 타협한다.
굳이 이럴 필요가 있을까? 관리자가 되고 싶다면야 당연히 그런 기회를 회사에서 주어야겠지만, 그렇지 않다면 이는 양자 모두에게 손해다. 인재를 제대로 활용도 못할 뿐만 아니라, 그 나쁜 영향을 멀쩡한 주니어들에게도 뻗칠 수 있게 한다. 그렇다면 연수가 차오를 대로 차오른 수석 개발자들은 어느 방향으로 경력을 쌓아가야 할까? 경험 상 다음 몇 가지가 가장 바람직하다.
소프트웨어 아키텍트. 기술력에 특화되어 있는 개발자들이 보통 꿈꾸는 종착지다. 물론 회사마다 이름이 조금씩 다를 수는 있다. 이들은 회사 전체가 사용할 소프트웨어들을 선택하고 소프트웨어들이 사용되는 작업 프로세스 전체를 기획하고 만들어내는 역할을 한다.
주니어 개발자들이 가장 많이 멘토로 삼는 것이 바로 이 소프트웨어 아키텍트들이다. 문제 해결에 특화된 전문성을 보유하고 있으며, 10년 이상 특정 소프트웨어에 대한 경험을 축적해왔거나 여러 소프트웨어를 사용해온 경험이 풍부해 다양하거나 보편적인 소프트웨어 및 플랫폼에 능통한 모습을 보인다.
개발자들이 훗날 아키텍트가 되려면 신기술에 대한 학습을 끊이지 않는 게 가장 중요하다. 소프트웨어 개발이나 특정 기술에 아무리 특화되어 있더라도 소프트웨어 개발 과정 전체에 대한 지식 정도는 풍부히 가지고 있어야 하고, 반대로 ‘제너럴리스트’에 가까운 개발자라면 특수 분야 혹은 주무기가 될 만한 전문지식을 보유하고 있어야 한다.
수석 개발자. 개발자 관리자라고 불리기도 한다. 시간 관리에 능하고 사람 대하는 기술이 뛰어난 개발자들에게 잘 어울린다. 개발에 특화된 사람들과 개발을 이해하지 못하는 사람들 사이에서 다리 역할을 맡는다. 그렇기에 프로젝트 관리를 하면서 일을 여기저기 잘 조율하고 배분한다.
이런 데에 소질이 보이는 개발자가 있으면 소그룹 프로젝트를 만들어 관리자 역할을 주어보는 것이 좋은 방법이다. 마감을 잘 지키는지, 마감 내 어느 정도 퀄리티가 나오는지, 팀원들의 만족도는 어느 정도나 되는지 살펴봐가면서 후보를 정하는 것이 위에서 설명한 악순환을 막는 방법이다.
수석 기술 프로젝트 관리자. 예산 및 자원 관리에 능한 개발자에게 어울리는 직책이다. 수석 기술 프로젝트 관리자는 인적 측면에서가 아니라 예산의 측면에서 프로젝트를 진행하는 데 능하며, 그러므로 사전에 뭔가를 계획해서 실행하는 성향을 가졌으며 효율성을 굉장히 따진다는 특성도 있다. 압박에 강한 타입이다.
조직 입장에서 수석 기술 프로젝트 관리자 후보들을 어떻게 추리고 양성해야 할까? 먼저 프로젝트의 기획부터 맡기고, 자원과 시간을 어떻게 배분하고 관리하는지를 지켜봐야 한다. 위와 다른 건 기획 단계부터 맡긴다는 것이다. 이들은 보통 ‘자기가 기획한 프로젝트’에서 빛을 발한다는 특징을 가지고 있다. 그러니 기획한 내용이 회사의 사업 방향과도 잘 맞는 것도 중요히 봐야 할 부분이다.
개발자들은 의외로 여리여리한 사람들이다. 이들은 묵묵하고, 자기 스스로의 실력을 다듬어가는 걸 즐긴다. 이런 사람들에게 어떤 위치를 강제로 부여한다는 건 – 물론 회사도 ‘진급’시켜주는 것이겠지만 – 깊은 상처를 주는 행위일 수도 있다. 그리고 실제 회사의 갑작스런 진급 결정 때문에 그만두고 회사를 나가고 식당을 차리는 개발자들이 수도 없이 많다.
글 : 루디 머터(Rudy Mutter)
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-23] 
.jpg)
.jpg)
