굉장히 안타까운 걸 너무 많이 봐서… 좀 착각하시는 분들이나 이런 상황에 못 헤어나오는 분들을 위해서 글을 적어봅니다. 내용은 지극히 제 주관적일 수 있지만, 한번쯤은 좀 생각해 볼 만한 이야기 같아서 적어봅니다. 딴지 걸고 싶은 분들이나 의견 있으신 분들은 댓글 달면 제가 댓글 내용 승인해서 내용 공유를 해보겠습니다.
개발자들이 흔히들 말하는 것 중에 이런 이야기가 있다. 바로 “백발까지 프로그래밍 하고 싶다.”라는 것이다. 개발이 너무 좋아서, 갈때까지 가보고 싶어서 다들 이런 소리 하나씩은 하고, 한번쯤은 꼭 품에 안고 간다.
근데 지금, 이 때까지 관리자나 팀장 자리에 있으면서도 불구하고 사원, 주임급 개발자랑 동등한 수준의 코딩을 계속해서 하고 나가면서 팀 관리는 팀 관리대로 요구받는 개발자들을 많이 볼 수 있다. 근데 이분들이 하는 방식이 내가, 우리가 아는 그 끝까지 프로그래밍 하는 그런 모습이었을까란 생각이 들었다.
관리자라고 해서 바로 관리자가 되지 않는다. 초반에는 프로그래머, 혹은 코더로부터 시작해서 실력을 쌓고 경력을 쌓아가다 보면 어느 샌가 진급을 하게 되고, 프로젝트 단위로 볼 수 있는 프로그래머로 성장하게 된다. 그렇게 되다 보면 관리자 자리에 앉아 있게 된다. 문제는 여기서부터 시작된다.
관리자가 되면서 코딩을 완전히 손을 떼는 개발자들도 생기고, 그렇지 않는 개발자들도 생긴다. 관리자가 되면서 손 떼는 경우에는 여러모로 말이 많기도 해서 안좋은 경우가 엄청나게 많이 나열되어 있다. 지시를 해야 하는 젊은 개발자들과 개발에 대해서 말이 조금씩 안통하기 시작한다던가, 최신 개발 환경에 대해서 어두워지는 경우가 생기기도 하고 개발 문제 시 생기는 부분에 대해서 이해도가 떨어지는 등 여러모로 골치아픈 경우가 많이 생기게 된다. 따라서 관리자라 하더라도 프로그래밍을 어느 정도 해야 한다는 것은 여러모로 많이 퍼져있다. 필자도 이 부분에 대해서는 찬성을 하는 부분이다.
자, 이제 관리자도 개발을 한다고 치자. 그러고 보니 이젠 관리자한테는 업무량이 배로 늘게 되었다. 개발도 해야 하고, 팀 관리를 위한 관리자의 업무도 주어지게 된다. (팀 관리가 얼마 안될꺼라고 생각하는가? PM의 일이 얼마 되지 않을꺼라고 생각하는 사람들은 개발 경험이 전무하다거나 학생 수준이라고 보겠다.) 이런 상황에서 팀장에게는 선택지가 주어지게 된다. 바로 본인의 참여도를 조정하는 정도에 따라 어떤 방식으로 일을 하냐를 선택할 수 있다.
내가 바라보는 문제가 이제 여기에 발생한다. 개발을 자기 팀원들과 똑같은 수준으로 하게 되다보면 관리자 업무를 야근으로 땜빵하는 관리자들이 존재하게 된다. 의외로 손이 모자란다는 회사들에서는 관리자 분들이 똑같은 수준으로 개발 일정을 본인 것까지 잡고 관리 업무에 대해서는 야근을 하는 등의 땜빵으로 처리하는데, 이렇게 되면 관리 업무에 있어서 본인의 관리가 소홀해지는 경우가 생기는 것이다. 즉, 팀원들에 대한 관리는 하면서 정작 이분들 스스로에 대한 관리기능이 전무한 상태가 되는 것이다.
일단, 관리자들은 프로그래밍을 어느 정도까지 할 수 있어야 하는지를 묻는다면, 난 현업에 투입되어소 아무 막힘 없이 개발할 수 있는 실력이 있어야 한다고 주장한다. 그러나 이런 실력이 있다고 해서 그래도 투입되어서 개발하는 게 좋다고는 생각되지 않는다. 오히려 몇몇 파트를 제외하고는 개발에는 깊게 들어가면 안된다고 본다.
필자인 내 주장으로는 우선 팀장은 팀원들의 진행상황을 확인하고 관리해야 한다. 그리고 그에 따른 리스크 또한 계산해 둬야 하고, 해당 코드들을 결합하는 작업에 대해서 들어가는 것이 맞다고 본다. 그 중에서도 심각하게 생각하는 것이 바로 프로젝트의 문제, 즉 이슈에 대한 대응과 그에 따른 리스크 관리에 대해서 심각하게 보고 있다.
팀원들의 수준은 여럿 존재할 것이다. 주니어 개발자부터 시작해서 시니어, 어드밴스까지 다양하게 존재하는 개발자들이 개발을 진행하면서 서로의 문제를 공유하고 그에 따라 그들이 쉽게 해결할 수 없는 문제가 발생할 것이다. 이것은 그대로 이슈화 되고 리스크로 이어진다. 이럴 때, 관리자가 들어가서 개발을 하거나 하면 맞다고 본다. 특히, 문제 해결을 위한 능력은 아무래도 관리자가 좀 더 경험에 의한 해결을 더 할 수 있기 때문이다. 경력 있는 개발자들이 알고리즘 문제를 풀거나 문제 해결능력을 요구받는 것은 바로 이런 부분에서 조금이나마 경력 있는 사람들이 그렇지 않은 사람들과 해결 방법이나 능력이 다르기 때문인 것이라고 이해한다. 관리자의 조언 혹은 관리자가 생각하는 해결책을 제시해 줌으로써 해당 팀원 개발자가 그 내용을 이해해서 오류나 이슈를 수정할 수 있다면 확실히 처리할 수 있게 되는 것이다.
이때, 관리자에게도 문제 해결을 위한 어느 정도의 프로그래밍 실력(프로그래밍 언어의 스킬과는 관련이 있긴 하지만 많다고는 생각하지 않는다.), 문제 해결 능력이 없다면 여기서 생긴 이슈는 상당히 위험한 이슈가 되는 것이다. 팀원이 여럿 달려들어서 해결해야 하는 문제가 되는 것이다. 이런 이슈가 발생하면 이 이슈를 해결하기 위한 시간과 인력이 필요할 것이고, 이는 또 관리와 보고의 대상이 된다. 프로그래밍을 할 줄 알고 문제 풀이 능력이 되는 관리자라 해도 이런 일이 생기면 또 다른 관리 항목이 늘어나게 되는 것이다.
이런 상황에서 만약 관리자가 팀원들과 동일한 수준으로 개발 스케쥴을 잡고 개발을 진행한다? 매니지먼트에 대해서 바로바로 대응 못하고 뒤에 남아 야근으로 몰아서 관리한다? 관리자의 입장에서는 언제 터질 지 모르는 리스크를 안고 가는 것이라고 생각한다. 팀원 개발자들이 뭐 슈퍼천재라서 뭐 개발만 하면 아무 문제없이 전부 다 되고 그러면 모를까, 현실에서는 그럴 일은 없다.
여기에 회사에서 팀 평가 방식으로 한국식 평가지표들을 끼고 들어서면 그때는 진짜로 미친다. 특히 숫자로 제시하라 뭐하라 그러면서 KPI 지표 만들어서 매달 결과 보고 하거나 하면 어차피 진행사항이 최고 100%까지 밖에 안되는 개발 업무상(참고로 영업은 팀에서 잡은 영업 목표치보다 영업을 더 하면 저 지표가 100%를 초과할 수 있다.) 이런 저런 리스크 다 끌어안고 문제 터질 때마다 밀리고 밀리면 당연히 지표 떨어져서 한 90, 80% 이렇게 되면 일 못하는 개발팀이란 형식으로 또 찔리고 욕먹는 것이 개발팀이 되는 것이고, “개발의 특수성”이란 걸 주장하면 변명 취급당하고… 그냥 악순환이다.
이런 것 없이 그냥 개발자들의 개발 지표만 가지고 따로 관리해주면서 개발에만 집중시켜 주는 회사라면 관리자라 해도 그냥 개발자들처럼 직접 개발해도 될 지도 모르겠다. 그런데, 실제로 대부분의 회사들은 그렇지 않다. 심지어 실리콘벨리에 있는 회사들도 관리자에게는 관리자가 해야 할 일이 있는 것이기에 주니어, 시니어 프로그래머들처럼 프로그래밍 작업에 몰두하고 하는 것이 바람직하다고는 하지 않는다. 그러나 이곳도 현실적으로 막 닥치고 하면 관리자도 개발해야 한다. 그렇기에 관리자도 바로바로 투입 가능한 수준으로 프로그래밍을 할 수 있어야 한다. 근데 첨부터 관리자조차 전부 개발하는 데 인력을 투입하고 관리에 대해서 소홀하다면 그건 좀 고민해야 할 부분이라고 생각한다.