brunch

라이킷 27 댓글 6

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 에단박씨 Jun 10. 2018

개발 잘하는 김과장은 왜 팀장이 되어야 하죠?

개발자 vs 관리자

이 전에 다녔던 회사에서 일 잘하는 선배들과 이야기를 하면 이런 이야기를 듣고 했다.

이젠 위에서 관리하래. 코드 한줄도 볼 일이 없어

그렇다. 조직의 장이 된 선배들의 일과는 하루 종일 인력 assign하고 타 조직과 업무협의하고 임원들에게 줄 보고서 작성해서 제출하고, 관련 이슈해결하고 나면 퇴근시간이 빨라야 23시에서 00시였다. 이런 스케줄의 반복 속에서 30대후반 40대초반 선배 파트장/팀장들은 코딩은 커녕 IDE조차 켤 시간이 없었다. 아니 켤 생각조차 하지 않았다. 왜 이젠 개발자가 아니기 때문에...

그럼 왜 그럴까?

수천 명이나 되는 다양한 직원들이 존재하는 대기업의 구조상 개발자가 중심이 되기 보다는 경영기획과 인력운영에 더 관점을 두는 회사였기 때문에 개발자들의 커리어 패스까지 고려하기 어려웠을 것이다. 물론 요즘은 탈SI를 외치며, 기존 이미지를 탈피하려고 하지만, 회사의 구조와 문화가 하루 아침에 바뀌기는 어렵기 때문에 쉽게 바뀌지는 않을 것이다. (개발자 노트북 제공옵션에 맥북도 있게 해달라고 했더니 구매기획장께서 삼성노트북에 맥OS설치하면 되지 않냐는 이야기를 하면서 굳이 멋부릴 필요없지 않냐고 하셨으니... 말 다함...)

하지만 지금부터 하려고 하는 이야기는 결코 '대기업이 나빠요'를 이야기 하고 싶은 것이 아니다. 솔직히 말하면 이전 회사가 이름만 대면 알만한 대기업이었고 브랜드 value도 있었기 때문에 어른들께서는 그냥 다니길 바라셨고, 그곳의 복지 및 급여수준도 꽤 좋은 편이었기 때문에 이직시 고민이 없었다고 할수는 없을 것 같다.

하지만, 그럼에도 불구하고 내가 이직을 했던 가장 큰 이유는 관리가 아닌 개발을 계속 하고 싶었기 때문이다.

저 친구 일 잘해 차기 팀장 감이야

팀장이 된다는 것은 경영층 및 주변 동료들에게 실력을 인정받았다는 뜻이기에 분명 행복해 하는 것이 맞을 것 같다. 하지만, 그건 다른 뜻으로 '개발자로서의 커리어는 끝'을 의미하기도 한다. 당신의 나이가 30대 후반이면서 이력서에 관리자란 내용이 있는 순간, 그 어떤 IT회사에서도 당신에게 선뜻 손을 내밀지 못할 것이다.

그럼 관리자가 되는 게 나쁜거예요?

절대 그렇지는 않다. 관리자는 매우 어려운 직책이면서 많은 경험을 가진 사람에게 부여하는 직책이기 때문에 굉장한 책임감과 고독함을 요한다. 그렇기 때문에 그에 맞는 대우를 해주는 것이고...본인의 커리어를 임원으로 잡고 있는 사람이라면 당연히 그런 회사에서 최선을 다해야 한다. 그런 커리어 목표로 타 회사에 가봤자, 스카우트 되서 가는 케이스가 아닌 이상 굴러들어온 돌로서 기존 사람들과의 정치싸움에서 이기기 쉽지 않기 때문이다.

하지만, 당신이 '난 개발을 놓지 않으면서 언젠가 실리콘벨리 같은 IT회사에서 일할꺼야'라는 생각을 하고 있다면, 하루빨리 개발자를 소중히 생각하는 곳으로 가야 한다. 어디를 가든 개발자는 어차피 실력으로 말할 수 있고 인정받을 수 있으니깐!

1년 정도 공부한 다음에 이력서 써보려고요

얼마 전, 30대후반되어가는 후배에게 TO가 있어 한번 써보라고 했더니 이런 대답을 들었다. 물론 본인이 준비를 완벽하게 한 다음에 도전해보고 싶은게 당연한 마음이겠지만, 중요한 건, 그런 IT회사들이 당신을 기다려주지 않는다는데 있다. 회사에서 경력을 뽑는 가장 큰 이유는 특정 업무를 당장 해결할 수 있는 개발자들을 내부에서 찾기 어렵거나 신사업을 추친하기 때문이다. 그렇다면, 시간이 지난다면 내부에 있는 주니어들로 충분히 커버할 수 있기 때문에 굳이 나이 많고 비싼 시니어 개발자를 쓸 필요가 없어진다.

그럼 전 이제 어떻게 할까요?

당신이 6~7년차의 개발자로서, 현재 하는 일이 매너리즘을 느끼고 있으면서 관리자가 아닌 개발자의 커리어를 목표로 하고 있다면 아래와 같이 준비를 해보기 바란다.

다수의 면접을 통해 현재 당신의 위치를 가늠해보길

회사에서 6~7년정도 일하게되면 대다수는 인정받으면서 일을 하게 될텐데, 거의 대부분 그것이 자신의 개발실력이 뛰어남을 의미하는 줄 착각하게 된다. 이런 우물안 개구리에서 탈출하기 위한 가장 좋은 방법은 당신을 전혀 모르는 사람이 기술만으로 당신을 냉정하게 평가해주어야만 하는데 그게 바로 기술면접이다. 기술면접을 하게 되면, 당신의 연차에 요하는 수준을 알 수 있게 되면서 내가 얼마나 부족했는지 또한 느낄 수 있게 된다. 물론 면접을 통해 받은 내상으로 인해 잠깐 동안의 자괴감 극복은 본인이 해결해야 할 몫이다. ^^;

냉정하게 자신의 장점을 판단해보자

가끔씩 면접을 보면 full stack개발자라고 하는 사람을 만나게 된다. 어떤 기준으로 말하는 건지는 모르겠으나, 대부분은 depth가 매우 얕은 면서 조금씩 다양하게 아는 사람이 대부분이었다. 어설프게 조금 할 수 있다는 것을 잘 한다고 생각하지 말고 진짜 자기가 잘하는 것을 찾아야 한다. 그리고 그것을 기반으로 어필해야만 한다. 괜히 이것 저것 잘한다고 했다가는 면접에 들어온 에이스들한테 탈탈 털리고 위의 내상과 함께 주화입마에 빠질 지도 모른다.

주 개발언어외에 sub 언어들도 공부해놓자

카뱅에서도 기본 언어는 java지만, python / go lang / groovy / scala등 스크립트 언어들도 많이 사용하고 있다. 틈틈히 다른 언어들도 공부해놓는 다면 분명 좋은 기회가 찾아올 수 있을 것이다.

도메인별 아키텍처 이해도를 높히자

업무 도메인별로 다양한 아키텍처가 존재할텐데, 현재 개발하고 있는 프로젝트에서 전체 아키텍처가 어떻게 되는 꼭 이해하는 습관을 갖도록 하자. 단순히 본인 개발에만 집중하고 전체 그림을 이해하지 못한다면, 면접 때 난처한 상황을 경험할 수도 있다. 필수는 아니겠지만, 가고자 하는 회사의 도메인에 맞는 아키텍처를 이해하고 있다면 다른 언어를 사용한다고 하더라도 새로운 기회를 잡는 것이 어렵지만은 않을 것이다.

위에 이야기 한 모든 것들을 30대 중반 전에 경험하도록 하자.