개발자 비급(祕笈) – 4. 팀장이 아니지만 괜찮아

백발이 휘날리며 코딩하는 개발자로 남는 것이 많은 분들의 꿈입니다. 반대로 경력이 올라가면 팀장 혹은 리더라는 (듣기엔 그럴듯한) 새로운 역할에 대한 요구가 많아지게 되는데요. 오늘은 팀장이 되지 않아도 개발자 그 자체로서 행복할 수 있는 방법을 한번 이야기해볼까 합니다. (제목은 최근 아주 재미있게 본 드라마 ‘사이코지만 괜찮아’의 오마주입니다.)

팀장이 되라는 유혹을 이겨 내기는 정말 어려운 일입니다. 많은 회사에서 개발 잘하는 사람에게 팀장을 맡기고 싶어하니까요. 회사에서 인정도 받고 연봉도 올라가는 일을 누가 거절할 수 있을까요? 혼자서 일하기 보다 여러 사람을 데리고 일하면, 눈에 보이는 성과도 늘어나구요. 그렇게 매니저(Manager)로 성장해서 임원에까지 이르면 회사에서의 영향력도 커지고 더 많은 일을 해 낼 수 있습니다.

출처: 사이코지만 괜찮아 (tvn 홈페이지)

사실 누구에게도 매니저의 기본 자질은 필요합니다. 대개 경력이 올라가면 자신의 개발 능력 만큼이나 소통 및 협업 능력, 그리고 사람에게 동기 부여를 하는 소위 소프트 스킬이 매우 중요해집니다. 어떤 직업에서도 똑같이 해당되는 일이기 때문에 그런 부분도 연마하고 키워져야 합니다. 그렇다면, 스스로 매니저 경력으로 가는 게 맞는지 아니면 탐나는 개발자로 쭉 일하는 게 맞는지 어떻게 알 수 있을까요?

■ 핸즈온(Hands-on) 계속하기
저는 3명의 개발자인 작은 스타트업에서 처음 일을 시작해서, 7년간 30여명으로 커지는 동안 빠르게 팀장과 연어이 기술 이사(CTO)를 맡았습니다. 회사와 서비스도 성장하고 직원도 많아졌지만 늘 한편에 아쉬운 점이 있었습니다. 바로 내 손으로 뭔가 하는 게 있었으면 좋겠다는 것이죠. 사내 주요 서비스에 손수 코드를 짜는 건 좋지 않아서, 혼자서 처음부터 끝까지 하는 프로젝트를 하나 둘씩 만들기 시작했습니다.

이런 일들은 개발팀이나 개발자에게 맡기기에 짜친(?)일이였습니다. 개중에는 윈도 미디어를 기반한 DRM 솔루션, 델파이로 만든 외주 프로그램이나 ASP로 만들어진 외주 쇼핑몰 유지 보수 등등… 덕분에 안 써보던 다양한 프로그램 언어도 배울 수 있었죠. 그외에 Mozilla와 파이어폭스 한국어 번역이나 기술 블로그 같은 글쓰기도 그때 시작했습니다. 제가 예전에 쓴 개발자 경력 관리 조언의 마지막 바로 “나이가 들어도 핸즈온이 필수다!”라는 것입니다.

AWS로 이직할 때, 네이버 송창현 CTO님이 저에게 해 주신 이야기입니다. “나이가 들고 경력이 쌓였는데도 손발이 없다고, 의사 결정 안 해 준다고, 예산 없다고 일하기 힘들다는 사람들이 있다. 자기가 직접 손으로 혼자 다할 줄 알고, 해결할 수 있어야 일을 제대로 하는 사람이 아닐까?” 그렇습니다. 옆에서 손발이 되는 사람이 없으면 작은 일도 못하면 안되고, 스스로 직접 손으로 할 수 있는(Hands-on) 사람이 되어야 합니다.

만약 여러분이 이런 성향을 가지고 있다면, 충분히 매니저의 유혹을 이겨내고도 행복하실 수 있는 분입니다. 그렇다면 매니저로 성장하지 않더라도 충분히 사내에서 존경을 받는 방법은 무엇일까요?

■ 남들이 안 하는 일을 찾아보기
제가 일하는 글로벌 기업의 직급 문화는 한국 기업과 많이 다릅니다. 매니저 트랙과 함께 개인 전문가(Individual Contributor) 트랙이 나눠져 있어, 해당 업무의 전문가로서 승진을 통해 최상위 직급(임원)까지 올라갈 수 있습니다. 아마존에서 개발자의 경우, 소수의 분들이 이런 Distinguished Engineer라는 임원급 직함을 가지고 있죠. 다만, 국내 기업에서는 이렇게 개발자 트랙을 분리하는 곳이 드뭅니다. 제가 Daum에 있을 때, 꼭 해보고 싶었던 부분이었는데 아쉽게도 그러지 못했습니다. (혹시 있는 곳이 있다면 알려주세요.)

그렇다고 실망할 필요는 없습니다. 제가 드리고 싶은 조언은 ‘낮은 데로 임하라’는 것입니다. 대개 실력자들이 모이는 팀, 실적이 좋은 팀을 선호하지만 회사에는 누구도 신경쓰지 않지만, 꼭 필요한 일이 있습니다. 그런 일은 성장 가능성이 무궁무진하죠. 7년간 키워왔던 첫 직장을 떠나 Daum에 이직했을 때, 처음에 작은 개발팀을 맡았다가, 6개월만에 새로운 일을 찾기로 했습니다. 당시만 해도 개발자가 300여명이 있던 곳이고, 포털 사이트다 보니 웬만한 인터넷 서비스는 다 하고 있었습니다.

제가 찾았던 일은 누구도 관심을 기울이지 않았던 일이지만, 개발자 생산성과 직결된 일이었습니다. 지금 생각해 보면 우스울 수도 있는데, 전사 소스코드 레포지터리, 위키 시스템, 사내 라이브러리 통합 배포 사이트 같은 것들을 개발하는 일이었습니다. 처음에는 혼자서 하다가 한 두명이 붙고, 여러명이 붙는 일이 되니까 또 팀이 필요하더라고요. 자연히 제가 해야 되는 건데 다른 사람을 매니저로 일임하고 저는 다른 일을 찾았습니다. (그 조직은 향후에 테크에셋 – 기술전략, 공통 시스템, QA 등을 가진 본부급 조직으로 성장했습니다.)

제가 찾은 또 다른 일이 (많은 분들이 알고 계신) 외부에 사내 API를 공유하는 플랫폼 개발이었구요. 이 일도 처음에 한두명으로 시작해서 팀이 어느 정도 되자, 새로운 팀 매니저를 선임하고 저는 박사 과정을 위해 휴직을 했습니다. 2년 후 복직했는데도 다행히(?) 그 일이 그대로 있더라구요. 팀은 그대로였지만, 각자에게 한명이 한팀이 할만한 일로 찾아서 나눠주었습니다. (예를 들어, API 개발 운영, 사내 클라우드 플랫폼 테스트베드 개발, 개발자 마케팅/행사 등) 그 후에 전사 API 공통 플랫폼 플랫폼과 통합, 카카오와의 합병으로 인한 API 통합 등 더 큰 조직으로 변모해야 하는 상황에서 마지막 수습(?)을 한 후, 더 잘 하실 수 있는 분에게 맡기고, 저는 새로운 일을 향해 미련 없이 떠났습니다.

■ 공유로 자신만의 영향력 만들기
존경 받는 시니어 개발자로 꾸준히 성장하려면 늘 호기심을 가지고 새로운 기술을 배우는 데 게을리 하지 않고, 처음부터 끝까지 자기 손으로 일을 수습하고 마무리하는 핸즈온을 하는 것, 그리고 회사 내에 중요하지만 빠진 부분이 있는지 그런 부분을 찾아내서 새로운 일로 만들어 내는 것에 더해서 꼭 필요한 것이 바로 ‘영향력(Impact)’를 만들어야 합니다. 회사에서 영향력은 조직장의 권위에서만 오는 게 아닙니다. 시니어 개발자로서 다양한 부분에 적극적으로 자신의 의견을 내고, 합리적인 설득 과정을 거쳐 기술 조직내 의사 결정을 이끄는데 꼭 필요한 것입니다.

일반 개발자가 나의 의견을 귀담아 듣게 하는 영향력을 가지려면, 무엇보다 공유를 하려는 마음가짐이 중요합니다. 자기가 가진 정보와 경험을 남에게 공유하면 본인에게 영향력으로 돌아온다는 것은 아이러니하지만 사실입니다. 아직 개인 블로그를 운영하거나, 개발자 커뮤니티 활동을 하거나, 외부에 발표를 하거나, 책을 쓰거나 하는 것이 남들의 입방아에 오를지도 모릅니다. 하지만, 그런 공유야 말로 진정 기술 생태계에서 영향력을 얻는 가장 좋은 방법입니다.

당연히 본업에서 공유도 충실히 해야 합니다. 사내 개발자들에게 세미나를 열어 기술 지식을 공유하고, 취미 활동으로 기술 분야 동아리를 만들고, 필요하다면 사내 게시판에도 글을 자주 쓰세요. 제가 Daum 다닐때, 송년회에서 연간 1위를 한것이 바로 연중 ‘자유게시판’에 총 글 작성수였습니다. 글마다 찬반 투표를 할 수 있는데, 찬성수가 가장 많은 글도 제 글이고, 반대수가 가장 많은 글도 제글이었다는… 수천명이 보는 게시판에 글을 쓴다는 건 보통의 용기로 할 수 있는 일은 아닙니다. 하지만 그 과정에서 영향력을 얻는 방법을 연마할 수 있습니다.

감사하게도 제가 글을 쓰면 많은 분들이 읽어 주시는데, 이 글을 통해 다양한 기술 공유하시는 분들에게 작은 지지를 보내고 싶습니다. 누가 뭐라고 해도 실망하거나 멈추지 마세요.


다음을 떠나 AWS로 와서 혼자서 일하는 것을 즐기고 있는데도, 여전히 유혹이 많습니다. 여러 곳에서 임원급 제안이 오기도 하고, 내부적으로도 팀이 커지고 있다 보니 매니저가 되지 않겠느냐는 권유도 받습니다. 그래도, 저는 지금의 제 일이 좋습니다. 사실 글로벌 기업에서 쌓은 경험을 가지고 몇 년 후에 한국 회사로 돌아갈 생각으로 왔지만, IT 환경을 바꾸는 새로운 클라우드 기술과 서비스를 맛보고, 샘플 코드를 짜고, 다양한 방법으로 공유하는 보람이 너무 큽니다. (최신 클라우드 서비스를 돈 걱정 없이(?) 자유롭게 쓸수 있는 곳이 얼마나 있을까 싶네요.)

혹시 시니어 개발자로 일하고 계신 분들 중에 관심이 있다면, 클라우드 시대의 새로운 직업인 솔루션즈 아키텍트(SA), 프로페셔널 컨설턴트(ProServ), 테크니컬 어카운트 매니저(TAM) 같은 IC 직업에도 도전해 보세요. (물론 저처럼 테크 에반젤리스트도 좋구요.) 모두 개발 경험이 필요하고, 핸즈온이 가능하면서 신기술에 영향력을 끼칠 수 있는 신종 직업입니다.

탐나는 백발의 개발자로 평생 살아가시려는 분들께 포스가 함께 하시길… 여러분이 살아남아야 매니저가 아니어도 개발자로서 좋은 길을 얻는 후배들이 생깁니다. 우리 나라에도 그런 길을 열어주는 IT 기업이 많이 늘어나길 바랍니다.

May The –Force Be With You T-Shirt for Developers

개발자 비급(祕笈) 시리즈는 직장 생활을 하는 모든 분들이 어떻게 하면 개발자의 방식으로 경력 관리, 업무 처리, 프로젝트 관리 등을 할 수 있을지 생각해 보는 시리즈입니다. 개발자들에게는 자기 자신을 돌아볼 수 있고, 비개발 직군에서는 자신의 경력 방향에 시금석이 되었으면 합니다.

연재 목차

Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)

- ;

여러분의 생각 (8개)

  1. 백발코딩 댓글:

    진짜 어려운 숙제네요. 개발자로도 계속 남을 수 있는 회사가 많아졌으면 좋겠어요.

  2. 배민개발자 댓글:

    좋은 글 감사합니다! 우형 있습니다~ “우아한형제들은 2020년 들어서며 개발 역량 강화를 위해 개발직군에 대한 별도의 직급 체계를 마련했습니다. 새로운 체계에 따라 개발직군은 TM(Technical Manager) 트랙과 TE(Technical Expert) 트랙으로 이원화하고, 이에 따라 기존의 임원과는 별도 트랙으로 개발직군의 정점에 선 기술이사도 다섯 분을 선임했습니다.”
    https://woowabros.github.io/experience/2020/08/12/techleaders.html

  3. 강태 댓글:

    재미있게 잘 읽었습니다 저도 천상
    개발을 좋아합니다. 드라마 팬이에요 여기서 고문영 얼굴 보니 새롭네요

  4. 개발자2020 댓글:

    기승전-채용이네요 ㅋㅋㅋ 저도 개발 경력으로 다른 일을 해보고 싶은데 좋은 정보 감사해요

  5. @Jaewoo Ahn 댓글:

    국내에서도 몇군데 시도는 있긴 했죠. TD(Technical Director), Master 등등.. 원글 댓글에 달린 배민도 결국 예전 TD를 답습한 명칭을 쓰고 있군요. 여기서 TD와 Distinguished Engineer는 상당히 많은 의미 차이가 있습니다. 그리고 DE로 가기 전까지 개발자에게도 다양한 테크트리가 있다는 점도…

    • Channy 댓글:

      @Jaewoo Ahn 네 특히 principal 들이 훨씬 많은게 장점이죠. 아무래도 우리 나라는 좀 힘든 것 같아요. 기술 경영진들 인식이 아직 ㅠㅠ

  6. @이호동 댓글:

    팀장 노릇 하기 힘든 법이죠

강태에게 댓글 남기기

이름* 이메일* 홈페이지(선택)

알림: 스팸이 너무 많아 블로그 운영자의 승인하에 댓글 노출이 바로 보여지지 않을 수 있음을 양해 부탁드립니다.