관리자의 프로그래밍

굉장히 안타까운 걸 너무 많이 봐서… 좀 착각하시는 분들이나 이런 상황에 못 헤어나오는 분들을 위해서 글을 적어봅니다. 내용은 지극히 제 주관적일 수 있지만, 한번쯤은 좀 생각해 볼 만한 이야기 같아서 적어봅니다. 딴지 걸고 싶은 분들이나 의견 있으신 분들은 댓글 달면 제가 댓글 내용 승인해서 내용 공유를 해보겠습니다.

개발자들이 흔히들 말하는 것 중에 이런 이야기가 있다. 바로 “백발까지 프로그래밍 하고 싶다.”라는 것이다. 개발이 너무 좋아서, 갈때까지 가보고 싶어서 다들 이런 소리 하나씩은 하고, 한번쯤은 꼭 품에 안고 간다.

근데 지금, 이 때까지 관리자나 팀장 자리에 있으면서도 불구하고 사원, 주임급 개발자랑 동등한 수준의 코딩을 계속해서 하고 나가면서 팀 관리는 팀 관리대로 요구받는 개발자들을 많이 볼 수 있다. 근데 이분들이 하는 방식이 내가, 우리가 아는 그 끝까지 프로그래밍 하는 그런 모습이었을까란 생각이 들었다.

관리자라고 해서 바로 관리자가 되지 않는다. 초반에는 프로그래머, 혹은 코더로부터 시작해서 실력을 쌓고 경력을 쌓아가다 보면 어느 샌가 진급을 하게 되고, 프로젝트 단위로 볼 수 있는 프로그래머로 성장하게 된다. 그렇게 되다 보면 관리자 자리에 앉아 있게 된다. 문제는 여기서부터 시작된다.

관리자가 되면서 코딩을 완전히 손을 떼는 개발자들도 생기고, 그렇지 않는 개발자들도 생긴다. 관리자가 되면서 손 떼는 경우에는 여러모로 말이 많기도 해서 안좋은 경우가 엄청나게 많이 나열되어 있다. 지시를 해야 하는 젊은 개발자들과 개발에 대해서 말이 조금씩 안통하기 시작한다던가, 최신 개발 환경에 대해서 어두워지는 경우가 생기기도 하고 개발 문제 시 생기는 부분에 대해서 이해도가 떨어지는 등 여러모로 골치아픈 경우가 많이 생기게 된다. 따라서 관리자라 하더라도 프로그래밍을 어느 정도 해야 한다는 것은 여러모로 많이 퍼져있다. 필자도 이 부분에 대해서는 찬성을 하는 부분이다.

자, 이제 관리자도 개발을 한다고 치자. 그러고 보니 이젠 관리자한테는 업무량이 배로 늘게 되었다. 개발도 해야 하고, 팀 관리를 위한 관리자의 업무도 주어지게 된다. (팀 관리가 얼마 안될꺼라고 생각하는가? PM의 일이 얼마 되지 않을꺼라고 생각하는 사람들은 개발 경험이 전무하다거나 학생 수준이라고 보겠다.) 이런 상황에서 팀장에게는 선택지가 주어지게 된다. 바로 본인의 참여도를 조정하는 정도에 따라 어떤 방식으로 일을 하냐를 선택할 수 있다.

내가 바라보는 문제가 이제 여기에 발생한다. 개발을 자기 팀원들과 똑같은 수준으로 하게 되다보면 관리자 업무를 야근으로 땜빵하는 관리자들이 존재하게 된다. 의외로 손이 모자란다는 회사들에서는 관리자 분들이 똑같은 수준으로 개발 일정을 본인 것까지 잡고 관리 업무에 대해서는 야근을 하는 등의 땜빵으로 처리하는데, 이렇게 되면 관리 업무에 있어서 본인의 관리가 소홀해지는 경우가 생기는 것이다. 즉, 팀원들에 대한 관리는 하면서 정작 이분들 스스로에 대한 관리기능이 전무한 상태가 되는 것이다.

일단, 관리자들은 프로그래밍을 어느 정도까지 할 수 있어야 하는지를 묻는다면, 난 현업에 투입되어소 아무 막힘 없이 개발할 수 있는 실력이 있어야 한다고 주장한다. 그러나 이런 실력이 있다고 해서 그래도 투입되어서 개발하는 게 좋다고는 생각되지 않는다. 오히려 몇몇 파트를 제외하고는 개발에는 깊게 들어가면 안된다고 본다.

필자인 내 주장으로는 우선 팀장은 팀원들의 진행상황을 확인하고 관리해야 한다. 그리고 그에 따른 리스크 또한 계산해 둬야 하고, 해당 코드들을 결합하는 작업에 대해서 들어가는 것이 맞다고 본다. 그 중에서도 심각하게 생각하는 것이 바로 프로젝트의 문제, 즉 이슈에 대한 대응과 그에 따른 리스크 관리에 대해서 심각하게 보고 있다.

팀원들의 수준은 여럿 존재할 것이다. 주니어 개발자부터 시작해서 시니어, 어드밴스까지 다양하게 존재하는 개발자들이 개발을 진행하면서 서로의 문제를 공유하고 그에 따라 그들이 쉽게 해결할 수 없는 문제가 발생할 것이다. 이것은 그대로 이슈화 되고 리스크로 이어진다. 이럴 때, 관리자가 들어가서 개발을 하거나 하면 맞다고 본다. 특히, 문제 해결을 위한 능력은 아무래도 관리자가 좀 더 경험에 의한 해결을 더 할 수 있기 때문이다. 경력 있는 개발자들이 알고리즘 문제를 풀거나 문제 해결능력을 요구받는 것은 바로 이런 부분에서 조금이나마 경력 있는 사람들이 그렇지 않은 사람들과 해결 방법이나 능력이 다르기 때문인 것이라고 이해한다. 관리자의 조언 혹은 관리자가 생각하는 해결책을 제시해 줌으로써 해당 팀원 개발자가 그 내용을 이해해서 오류나 이슈를 수정할 수 있다면 확실히 처리할 수 있게 되는 것이다.

이때, 관리자에게도 문제 해결을 위한 어느 정도의 프로그래밍 실력(프로그래밍 언어의 스킬과는 관련이 있긴 하지만 많다고는 생각하지 않는다.), 문제 해결 능력이 없다면 여기서 생긴 이슈는 상당히 위험한 이슈가 되는 것이다. 팀원이 여럿 달려들어서 해결해야 하는 문제가 되는 것이다. 이런 이슈가 발생하면 이 이슈를 해결하기 위한 시간과 인력이 필요할 것이고, 이는 또 관리와 보고의 대상이 된다. 프로그래밍을 할 줄 알고 문제 풀이 능력이 되는 관리자라 해도 이런 일이 생기면 또 다른 관리 항목이 늘어나게 되는 것이다.

이런 상황에서 만약 관리자가 팀원들과 동일한 수준으로 개발 스케쥴을 잡고 개발을 진행한다? 매니지먼트에 대해서 바로바로 대응 못하고 뒤에 남아 야근으로 몰아서 관리한다? 관리자의 입장에서는 언제 터질 지 모르는 리스크를 안고 가는 것이라고 생각한다. 팀원 개발자들이 뭐 슈퍼천재라서 뭐 개발만 하면 아무 문제없이 전부 다 되고 그러면 모를까, 현실에서는 그럴 일은 없다.

여기에 회사에서 팀 평가 방식으로 한국식 평가지표들을 끼고 들어서면 그때는 진짜로 미친다. 특히 숫자로 제시하라 뭐하라 그러면서 KPI 지표 만들어서 매달 결과 보고 하거나 하면 어차피 진행사항이 최고 100%까지 밖에 안되는 개발 업무상(참고로 영업은 팀에서 잡은 영업 목표치보다 영업을 더 하면 저 지표가 100%를 초과할 수 있다.) 이런 저런 리스크 다 끌어안고 문제 터질 때마다 밀리고 밀리면 당연히 지표 떨어져서 한 90, 80% 이렇게 되면 일 못하는 개발팀이란 형식으로 또 찔리고 욕먹는 것이 개발팀이 되는 것이고, “개발의 특수성”이란 걸 주장하면 변명 취급당하고… 그냥 악순환이다.

이런 것 없이 그냥 개발자들의 개발 지표만 가지고 따로 관리해주면서 개발에만 집중시켜 주는 회사라면 관리자라 해도 그냥 개발자들처럼 직접 개발해도 될 지도 모르겠다. 그런데, 실제로 대부분의 회사들은 그렇지 않다. 심지어 실리콘벨리에 있는 회사들도 관리자에게는 관리자가 해야 할 일이 있는 것이기에 주니어, 시니어 프로그래머들처럼 프로그래밍 작업에 몰두하고 하는 것이 바람직하다고는 하지 않는다. 그러나 이곳도 현실적으로 막 닥치고 하면 관리자도 개발해야 한다. 그렇기에 관리자도 바로바로 투입 가능한 수준으로 프로그래밍을 할 수 있어야 한다. 근데 첨부터 관리자조차 전부 개발하는 데 인력을 투입하고 관리에 대해서 소홀하다면 그건 좀 고민해야 할 부분이라고 생각한다.

Advertisements

진짜로 평가받아야 할 것을 착각하지 말자

매년 오는 시기다. 정시 원서 넣기까지 끝났고, 수시도 지났고, 취업도 어느정도 지났다. 그러다보니 이젠 자기합리화를 하는 친구들이 점점 늘어나는지… 매년 같은 소리 또 나오고 나온다. 여기에 필자가 대학원 졸업하고 취업 준비한다고 이력서 쓰면서도 아직 취업 못한 몇몇 친구들이나 후배들의 이야기랑 비교하면 필자는 진짜 “변종”이기 때문이다.

개발자 된답시고 3학년 쯤 되다보면 다들 자격증 따기 바쁘다. 주로 남들하고 차별받기 위해서라면서 따는 것이 누구나 다 똑같은 생각하면서 따는 CCNA, CCNP라던가 OCP라던가… (솔직히 시험볼 때는 그냥 죄다 덤프 외워서 시험보고 합격하는 게 대학생들의 방식이더라.) 프로그래밍 능력을 증명하기 위해 비전공자들도 정보처리 기사를 취득하고…

근데 진짜로 웃긴 사실은, 실제로 정말 유명한, 실력 있는 기업들이 하는 코딩면접 같은 것은 문제 풀이 능력을 보고자 하는 건데 이런 건 자격증하고는 정말 상관도 없다. 직접 해보면서 익힌 문제풀이 방법이 있을 것이고, ACM 알고리즘 공부 열심히 해서 경진대회 나가보기도 했던 애들이 그런 건 더 잘 푼다. 오히려 그런 애들치고 하나쯤은 제대로 개발해보고 했던 것들도 있을 것이다.

필자가 싫어하는 소프트웨어 마에스트로나 삼성 소프트웨어 맴버쉽이던 그거 있으면서 자기가 직접 참여한 프로젝트가 있을 것이고, 그걸 위해서 뭔가 머리 싸메고 했던 경험이 있을 것인데, 오히려 지금 그런 경험 더 좋아한다. 아님 혼자서나 다른 친구들하고 직접 개발하면서 소스코드 막 짜고 고민해서 정보 남기고 뭐 했던 것 한번 딱 보여주면? 자격증만큼 좋은 거 아닌가?

왜 이런 소리 떠드냐면…

프로그래머에게 자격증은 모욕이다라는 오래된 칼럼의 링크가 뭐 학교니 자격증이니 실력이니 하는 글에서 답답한 사람들이 댓글에 달아주면서 또 다시 세상에 나온 것 땜에 좀 한심해서 적어봤다. 저거 작성된 때가 2014년인데, 아직도 이런다. 진짜 제대로 프로그래머들이 인정받기 위해서는 프로젝트 경험이랑 문제 풀이 능력으로 인정받아야 한다고 하는 게 대체 몇 년간을 계속 떠들어야 제대로 될까란 생각이 든다.

네이버나 다음, 그리고 좀 제대로 된 개발 회사들은 이런 것에 변화해 가는 거 같은데, 그 흔하디 흔한 대부분의 기업들은 아직도 숫자로 표현 잘 되는 녀석으로 줄세우기를 해야 쉽게 풀리나보다. 그러니 어정쩡한 학교 순위 메기기 이야기나 자격증 갯수나 자격증 위치 같은 것에 대해서 목숨 거나보다.

그런 분들에게 반말의 말투이지만 묻고싶다.

“그렇게 일일이 하나하나 다 따지고 자리 잡으니 행복하니? 오히려 개발 일 자체가 재밌지 않을텐데…?”

그나마 그 속에서 재미를 느꼈다면 오래 가겠지만, 그렇지 않다면 그만 두거나 아니면 기계처럼 코드몽키가 되어가겠지…

“XX, 뽑아놓으니 졸라 못하잖아!”

앞의 두 글의 이후 글입니다.

요즘 기업들이 이런 소리 합니다. “뽑을 개발자가 없다.”

기업들이 이런 소리 하는 거 공감합니다. 실제로 이력서에 적어놓 것과 전혀 다르게 진짜 기술 딸리는 개발자들도 많이 있습니다.

프로젝트는 혼자 하는 게 아닙니다. 특정 인원들이 모여서 하죠. 그 중에서도 기술자가 상, 중, 하 등 여러 실력을 가진 기술자들이 있습니다. 혼자 일당백으로 미친듯이 하는 거 아니면 왠만해선 무리입니다. 돈 오가는 곳들은 더더욱 그렇죠. 뭐, 그렇다 보니 동일한 프로젝트를 한 개발자라 해도 차이가 나게 되어 있습니다. 그걸 소스코드나 기술 보고서 등으로 어떤 개발을 했는지를 알아서 어떤 수준의 개발자인지를 알려고 하는 겁니다. 그래야 그에 맞는 일을 시킬 수 있는 거죠.

근데 한국은 좀 특이합니다. “이왕이면 다홍치마”라는 말을 당장이라도 금지어로 만들어야 하는 특별법을 제창하자고 하고 싶을 정도로 여러 경력을 가진 사람을 좋아합니다. (문제는 돈은 그렇게 안준다는 거. 그래서 없애야 한다는 거!) 이력서에 한 줄 더 들어가있는, 뭐라도 좀 더 해본 그런 개발자를 선호하죠. 그래서 뽑아보니 각각의 프로젝트가 전부 주니어급에서 멈춘 개발자를 뽑았다. 같은 현상 자주 생깁니다. 학생의 경우에는 뭐 경진대회 나간 경력이 있었는데 까고보니 별거 없는 코드만 양산했던 친구였다라던가 하는 그런 경우죠. 팀플했는데 이름만 걸쳐졌다 이런 수준도 있고요.

해당 기업의 개발 팀장 입장에서는 뽑아놓으니 그런 개발자였다 그러면 미친듯이 속이 탈 겁니다. 그 차이는 기존의 개발자들이 매워줘야 합니다. 그래도 안되면 팀장인데도 불구하고 현업 시니어들과 같은 수준으로 미친듯이 코딩하는 팀장이 나오게 되는 현상까지 벌어지죠. (왠지 이 부분은 논란 좀 많이 생길 이야기 같은데… 팀장의 역할이라는 건 코딩 외에도 좀 따로 있습니다. 나중에 좀 자세히 적겠습니다.)

회사 입장에서는 미친듯이 사기당하는 기분일 겁니다. 당연히 그 개발자한테는 말 안하죠. 정말 회사에서 개발 한번도 안해본 갓 졸업한 학생이라던가 하면 모를까 현업에서 몇 년 뛰었다고 하는 개발자가 그러면…

아마 글 읽고 상상만 해도 소름 돋는 분들 있을 겁니다. 그게 본인이 될지 본인 주변에 이런 개발자가 있었다가 될지는 모르겠지만…

괜히 기업들이 알고리즘 테스트나 깃헙 보려고 하는 게 아니라는 것 정도는 좀 제대로 알았으면 합니다.