개발자는 매력 있는 포지션이다. 깊은 커리어가 두각을 내는 파트가 있는가 하면, 넓은 커리어가 압도적인 파트가 있다. 많은 것을 고려해야 하는 파트가 있지만, 적은 것을 고려하는 게 미덕인 파트도 있다. 타협이 답인 파트가 있는 반면, 불통이 미덕인 파트도 있다.

각 파트가 속한 업계 또한 묘한 매력이 있다. 개발자 한 명이 갖는 에너지는 조직에 큰 영향을 미치기도 하는데, 파트 여기저기에 영향을 미치는 개발자가 있는 반면, 오로지 한 분야에서만 두각을 나타내는 개발자도 있다.

나는 8년을 넘어선 내 커리어 중 대부분을 개발자로 지냈다. 첫 회사는 수백 명 직원이 있는 회사였고, SI(System Integration, 시스템 통합) 특성상 여러 조직을 떠돌며 외로움을 경험하기도 했다. 창업 후 프리랜서로 활동하며 내 평판이 없는 곳에서 일해봤고, 다시 개발자로 돌아와 잊어버린 감을 되찾기 위한 처절한 싸움을 했다. 이 과정에서 나는 개발자 수백 명을 만났고, 수십 명과 깊이 소통하며 프로젝트를 진행했다.

개발자는 여러 캐릭터가 있지만, 내가 만난 개발자 대부분은 한 가지 공통점이 있었다. 캐릭터가 강하고, 자존심이 강했던 것이다. 때문에 이들을 리드하는 테크리드와 매니저(관리자)는 깊은 자괴감에 빠지곤 한다. 그리고 개발자 출신 매니저는 하나 같이 이 말을 반복했다.

"아, 개발하고 싶다. 개발할 때가 편했어."

그들은 왜 개발이 하고 싶다고 했을까? 왜 개발자는 다루기 힘들까? 개발자는 다뤄야만 할까? 이 글에서는 강한 캐릭터를 가진 개발자, 그들을 관리하는 매니징에 관해 이야기한다.

내게 매니징이란?

8년여 개발자로 일하며, 자연스럽게 작은 팀을 리드할 기회가 있었다. 이 정도 커리어를 쌓았다면, 대부분 경험이 있을 것이다. 기술, 파트에 따라 경험하는 시기는 다르겠지만, 내 경우는 꽤 이르게 경험했다.

나는 2011년 안드로이드 개발자로 커리어를 시작했다. 당시 은행권에서는 너도나도 독립적인 모바일 애플리케이션을 개발하기 위해 돈을 쏟아부었다. 문제는 모바일 애플리케이션 개발자가 많지 않았단 것이다. 은행은 시스템에 관해 보수적일 수밖에 없고, 경험이 있는 개발자를 선호했다. 때문에 경험을 한 개발자에게 일이 몰리게 됐다. 어쩔 수 없는 상황이다.

2013년 말, 고작 3년 차 개발자인 내게 꽤 무거운 업무가 내려오기 시작했다. 커리어를 전부 합쳐도 고작 2년이 넘지만, 2년간 꽤 많은 애플리케이션을 출시했기에 익숙했다. 은행 애플리케이션은 대부분 비슷한 구조를 가졌고, 팀 내 공통 소스를 조금씩 수정해서 사용하면 됐다.

그렇게 4년 차쯤 돼서는 프로젝트 내 안드로이드 PL(Project Leader)을 맡게 됐다.

그동안 내가 경험한 PL과 PM(Project Manager)은 꽤 다양했다. 윽박지르며 욕설을 날리는 리더도 봤고, 아무런 소통도 하지 않고 홀로 회의를 오가더니 퇴사해버린 리더도 봤다. 모든 분야에서 위험인물인 예스맨도 봤고, 자신을 갈아가며 프로젝트를 완성하는 잘못된 리더십도 봤다.

그중 가장 최악은 예스맨과 무능력을 갖춘 소심한 리더였다. 요구 조건에 모두 예스를 던졌지만, 자신이 요구 조건을 충족할 능력은 없었다. 그렇다고 팀원들에게 내용을 공유하지도 않았다. 그저 가장 먼저 출근해서 가장 늦게 퇴근하는 게 리더가 했던 일이다. 결과는 예상한 그대로다.

"인기 있는 소프트웨어 추정 방법인 두 배 법칙은 '시간 추정 요청을 받을 때마다 추측한 다음 두 배로 알려준다"이다. 이 규칙은 즉석에서 추측해 달라는 요청을 받았을 때 사용할 수 있는 적절하고 좋은 규칙이다."

- 『개발 7년차, 매니저 1일차』 , 한빛미디어

개발자에게 소프트웨어 추정은 기본기 중 하나다.

내가 선호하는 매니징

물론 엉망인 리더만 경험한 것은 아니다. 나를 성장시킨 리더, 훌륭한 협업을 보여줬던 리더, 적절한 위임을 보여준 리더 등. 닮고 싶었던 리더도 많았다.

한 리더는 사내 소방수였다. 여러 프로젝트가 동시에 진행되지만, 프로젝트 오픈만 돌아가며 투입되는 사내 핵심 개발자였다. 소방수 리더가 이끄는 소방팀은 프로젝트를 돌아가며 불을 껐다. 이 팀은 고객사에도 알려져 그 팀을 투입하지 않으면 프로젝트를 발주하지 않겠다고 강하게 주장할 정도였다.

그 리더에게 저절로 고개가 숙어진 것은, 내가 속한 프로젝트 오픈 전날이었다. 당시 애플리케이션 주요 부분을 내가 맡았고, 오픈 전날 보안 점검에서 취약성이 발견됐다. 사내에서 홀로 투입된 프로젝트였고, 몇몇 프리랜서와 협업했던 나는 머리가 하얗게 됐다. 믿을맨들은 안드로이드를 몰랐고, 화살은 온전히 내게 돌려졌다. 고객사 책임자는 소리를 지르며 책임지라고 했다. 정말이지 온몸에서 땀이 났다.

SI 시절 나. 그땐 정말 힘들었다.

그때 소방수 리더가 나타났다. 리더는 안드로이드 개발을 몰랐지만, 사내에서 손꼽히는 자바(Java) 전문가였다. 내 코드를 한 줄, 한 줄 들여다보며 이렇게 구현한 이유를 물었다. 마치 모두 앞에서 발가벗겨지는 기분이었다. 자신감은 바닥을 기었고, 목소리도 내기 힘들었다. 그때 리더가 말했다.

"지금 너를 탓하는 게 아니야 인마. 일단 문제를 찾아야 할 거 아니야? 해결하자고. 일단 원인을 알아야 할 거 아냐? 뭘 졸아있어 인마. 집중해. 여태 고생해놓고 지금 다 손 놓을 거야? 다시 봐. 이거, 이거 왜 이렇게 했어."

정신이 번쩍 들었다. 그래, 쪽팔린 건 둘째였다. 일단 문제를 해결하지 못하면 십수억짜리 프로젝트가 실패할 수 있었다. 나는 내가 구현한 이유를 솔직히 답했고, 얼마 지나지 않아 리더는 원인을 파악했다. 1시간여, 얼마 되지 않는 시간에 리더는 신들린 듯 타이핑했고, 문제 해결했다.

물 한 모금도 마시지 않고 문제를 해결한 리더가 내게 고생했다며 어깨를 토닥일 땐 눈물이 날 뻔했다. 솔직히 그저 리더 품에 안겨 울고 싶었다. 시간이 꽤 흐른 지금도 그때 리더의 무심한 표정을 잊을 수가 없다. 별것 아니라는 그 표정.

"기술 팀에게 존경을 받으려면 팀원들이 기술적으로 신뢰할 수 있어야 한다. 기술적인 신뢰 없이는 힘든 싸움에 직면할 수 있으며, 한 회사에서 리더십의 위치에 오를지라도 향후 선택지가 넓어지기는 힘들다. 성공적인 기술 매니저가 되는 과정에서 기술적인 역량을 과소평가하면 안 된다."

- 『개발 7년차, 매니저 1일차』 , 한빛미디어

이후 다시 보안 점검을 받았다. 결과는 역시 이상 없음. 무사히 프로젝트를 오픈하고, 보안 점검 회사에서 놀라운 연락을 받았다.

"저, 이거 개발한 분 좀 바꿔주실 수 있을까요? 아... 문제가 있는 건 아니고, 어떻게 구현한 건지 궁금해서요. 이 정도면 완벽히 해결하셨는데, 어떻게 해결한 건지 우리도 알고 싶어서요."

무슨 말이 더 필요하랴. 개발자는 압도적인 기술력 앞에 절로 고개가 숙어지는 법이다.

내 매니징 스타일

앞서 기술적으로 뛰어난 리더를 소개했더니, 내 매니징 경험은 끝없이 하찮아 보인다. 난 기술보단 다른 부분에서 리더십을 보이는 성향이기 때문이다.

내가 PL로 프로젝트를 진행할 때 일이다. 나는 프로젝트팀 내에선 감추는 게 없어야 한다는 생각이다. 특히, PL들이 각 팀의 이야기를 감추기 시작하면 총괄 PM은 고립되고, 프로젝트는 산으로 간다. 리더가 올바른 선택을 할 수 있도록 정보를 막지 않는 것은 중간 매니저의 역할 중 하나다.

당시 프로젝트는 산으로 가고 있었다. 처음엔 내가 PL이 아니었지만, 여러 사건을 거쳐 내가 PL이 됐다. 여러 PL은 PM에게 진척도를 감췄다. 프로젝트에 문제가 없다고 말했고, PM은 고객사에 그대로 보고했다. 정말 답답한 상황이었다. 그러던 중 중간점검에서 PM이 그 사실을 알게 됐다. 당최 구현된 기능이 없던 것이다.

화가 솟구쳐 소리를 지르는 PM에게 아무도 대꾸하지 못했다. 제발 누구라도 좋으니 사실을 말하라. 우리가 언제 오픈할 수 있는거냐 물었다. 고개를 숙이는 PL 사이에서 난 도저히 참을 수 없었다. 그렇게 내가 말했다.

"일단, 이번 달엔 절대 안 됩니다. 사실, 다음 달에도 안 됩니다. 하지만 개발팀 인원 2명 충원하고, 기획팀 철수 일자 한 달 미뤄주세요. 디자인도 마찬가집니다. 그러면 다음 달엔 오픈할 수 있습니다."

불에 기름을 부었다. PM은 네가 뭔데 일정을 변경느하나며 소리를 더 질렀다. 프로젝트 분위기는 바닥을 뚫고 지하로 향했다.

하지만 며칠 뒤 PM은 나를 조용히 불렀다. 솔직히 말해달라고. 그래서 어떻게 해야 하냐고. 당시 나는 프리랜서였고, 내 평판은 없었다. 그런 내게 의견을 구할 정도니, PM이 얼마나 외로웠을까?

결국 우리는 서로 원하는 것을 솔직하게 오픈했고, 합의했다. 나는 개발자를 추가로 고용했고, PM은 현실적인 일정을 고객사에 다시 제시했다. 이 과정에서 나는 적절한 개발자를 찾아 일정을 맞추기 위해 고생했고, PM은 고객사를 설득하느라 고생했다.

새로 고용한 개발자에게도 현재 상황을 솔직하고 상세하게 설명했다. 현재 프로젝트가 이 상황이 된 히스토리와 문제점. 문제를 해결하기 위한 방법, 풀어줬으면 하는 부분 등 나는 대화가 통하는 개발자를 고용했고, 그렇게 우리는 재조정한 프로젝트 일정에 맞게 오픈했다.

위아래로 감추지 않고, 솔직히 오픈한다. 현실적인 해답에 공감하고, 최선을 다한다. 이게 내 매니징 스타일이다.

개발 8년 차, 그래서 뭐

1년여 기자 생활을 하며 개발자를 떠났었다. 그때 느낀 것 중 하나가 '개발자'라는 포지션이 정말 특수한가? 였다. 개발자로 일하며 많이 듣는 이야기가 '개발자라서 그래', '개발자 같아', '개발자처럼 말하지 마' 등 개발자를 특수 포지션으로 이야기하는 것이다.

세상엔 많은 직업이 있고, 우리가 하는 일을 꼭 '개발자'라는 포지션에 한정시킬 필요가 있을까? 개발자라서 그렇다는 방패는 단단하기만 할까?

우리나라 소프트웨어(SW) 개발자는 13만 명이다. / 과학기술정보통신부, ICT실태조사

과학기술정보통신부 통계 자료만 봐도 우리나라엔 개발자가 13만 명뿐이다. 이 자료를 보고 개발자가 13만 명 뿐이니 더 존중받아야 한다는 주장을 할 수도 있겠다. 하지만 내 생각은 다르다. 그렇기 때문에 더 '개발자'라는 프레임에 숨어선 안 된다.

더 존중받기 위한 방법 중 더 소수를 유지하는 것도 있지만, 더 많은 이가 이해할 수 있는 것도 필요하다. 어떤 부분이 힘들고, 어떤 부분이 존중돼야 하는지 더 많은 이들이 공감해야 한다.

그런 의미에서 도서 『개발 7년차, 매니저 1일차』 는 함정에 빠지기 쉽다. 개발자이기 때문에 매니저가 되는 것이 어렵다는 건 역시 함정이다. 그저 매니저를 하지 않았기 때문에 어려운 것이다. 이는 개발자뿐만 아니라 기획자, 디자이너, 사업기획 등 다른 포지션에도 마찬가지다.

『개발 7년차, 매니저 1일차』, 한빛미디어

이 책은 팀원 7년차, 매니저 1일차 정도로 바꿔서 읽으면 좋은 책이다. 기술은 전문성으로, 테크리더는 비즈니스 리더로 바꿔서 읽으면 되겠다. 다시 말하지만, 그동안 개발자여서 매니저가 어려운 게 아니다. 매니저를 하지 않았기 때문에 어려운 것이다.

커리어는 꽤 빠르게 흐른다. 앞서 소개한 프로젝트에서 어리바리했던 때가 꽤 먼일인 것 같으면서도, 때로는 여전히 마음만은 그 시절인 것 같을 때가 많다. 하지만 나는 어느새 주니어라 말하기엔 애매한 시기가 됐다.

내가 속한 스타트업 CODEF에서는 팀원으로 일하지만, 마냥 주어진 일만 해서는 안 되는 포지션이다. 때로는 리드하기도 해야 하고, 적극적으로 의견을 제시해야 한다. 사실 팀원과 리더가 완벽히 분리되는 게 맞는가 싶기도 하다. 어쨌든 우리는 모두 비즈니스를 성공으로 이끄는 비즈니스맨이 아닌가?

개발자로 한 사람 몫을 하면서, 때로는 회의를 주도하고, 때로는 팀 내 협업 도구를 제시하고, 때로는 주니어 팀원에게 경험을 전달하고, 때로는 내가 할 수 있는 콘텐츠를 만들며 리더가 놓치는 부분을 함께 메워가는 것. 결국 팀을 생각하고 함께 일하는 것이 팀원과 리더 모두가 힘써야 하는 것 아닐까?

그런 의미에서 함께 소통하고, 성장하는 스타트업 CODEF에서 나와 함께 일하지 않겠는가? 암튼 내가 할 수 있는 건 다 하는 거다. 내가 몸소 보이고 있지 않은가?

CODEF 멤버 채용. / CODEF 채용 페이지

리딩은 꼭 리더만 하는 게 아니다. 팀을 위해 할 수 있는 게 있다면 하자. 좋은 팀원이 늘 좋은 팀장이 되는 건 아니지만, 나쁜 팀원이 좋은 팀장이 될 순 없다. 좋은 팀장은 좋은 팀원에서 시작한다.

오늘도 고통받는 팀원이여, 더 고통받는 팀장을 생각하자. 그렇다. 우리는 모두 고통스러운 비즈니스 맨인 것이다. 팀원보다 한 걸음 더 고통받는 팀장을 위해, 우리는 덜 고통스럽기 위해. 늘 마음만은 1일 차 팀장이 되자.