관리자의 프로그래밍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Advertisements

117 – make 규칙 1: 암시적 규칙

make 파일을 작성할 때는 컴파일에 필요한 각 처리 단계와 의존성을 분명히 지정해주었다. 이와 같이 make가 해야 할 일을 분명히 지정하는 것을 명시적 규칙(explicit rules)이라고 한다. 이와 반대로, make 내에 미리 정의된 규칙을 이용해 make 파일을 단순화시키는 규칙을 암시적 규칙(inference rules)이라고 한다.

이를 보여주기 위해서 전에 작성하던 make 파일을 상당히 줄여서 예시로 보여주겠다.

20180116_234757.png

소스 파일에서 오브젝트 파일로 컴파일하도록 하는 단계를 빼고 그냥 바로 test를 오브젝트로 만들어서 빌드하도록 하였다. 전에 글들의 코드를 보고 비교하면 상당히 단축시킨 것을 볼 수 있다. 이 코드는 실행하면 그대로 컴파일 된다. 그 결과가 아래의 화면이다.

20180116_234811.png

대상이 되는 test를 생성하기 위해 make는 의존하는 파일들을 살필 것이다. 그러나 대상이 의존하는 test1.o test2.o test3.o 이 세 파일이 존재하지 않기 때문에 make는 다시 저 파일들의 대상으로 있는 곳을 찾으려 한다. 이때, 찾지 못할 경우에는 오류를 내고 중단할 것 같지만, 실제로는 암시적 규칙에 따라 오브젝트 파일을 gcc가 생성할 수 있는 것을 알기 때문에, test1.o test2.o test3.o 파일을 생상하기 위해 의존하는 파일을 스스로 찾고 컴파일러 호출까지 알아서 수행한다. 이때, 실행 결과에 찍힌 규칙을 보면 알겠지만 gcc를 호출하는 것이 아니라 cc 컴파일러를 호출하였다.

이 과정을 보고 싶다면 make -p 라고 해서 -p 옵션을 통해서 볼 수 있다. 실행하면 아래와 같이 쭉 나온다. 아래 화면에 스크롤 바를 주목해라. 내용 장난 아니게 많다. 암시적 규칙으로 어떤 것들이 불러지는지 알고 싶다면 계속 스크롤을 내려서 살펴보는 것도 좋을 것이다. 근데 당장은 이해 못한다.

20180116_234940

20180116_234956.png

20180116_235008

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

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

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

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

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

왜 이런 소리 떠드냐면…

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

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

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

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

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