[1편] 개발 7년차에서 매니저 3년차로(개발팀 7명에서 33명이 되기까지)

들어가면서

  실무자가 매니저로 넘어가는 길에 도움이 되는 이정표를 작게나마 더하고 싶었다.

개발자로 7년을 일하다 7명을 팀원을 맡게 되고(자기소개의 글), 2년간 팀과 함께 성장하며 33명이 되기까지 경험을 바탕으로 피해서 돌아가야 할 것과 마주하고 정면 돌파해야 하는 것들을 정리해 보았다.

피하고 돌아가야 할 길

비교형 문장

  우리 팀은 반기마다 서라운드 리뷰(협업했던 동료를 서로 리뷰하고 평가함)를 진행한다. 팀을 리드하는 입장에서 좀처럼 받기 어려운 동료들의 피드백을 들을 수 있는 소중한 시간이다. 서라운드 리뷰를 통해 나는 "프런트엔드와 백엔드를 비교하며 표현하지 말아 달라."라는 피드백을 받았다. 할 일을 계획하는 부서회의 때 "A라는 기능은 트랜잭션 관리 때문에 프런트엔드 개발보다 백엔드 개발이 중요하다. 일정을 더 많이 잡아 달라"라는 표현을 하였고 이에 대한 피드백으로 주신 말씀이었다. 너무나 맞는 피드백이었고 늘 새기며 일하게 되었다. 업무량과 영향범위는 다를 수 있지만  무엇이 더 중요한 일은 없다. 더 중요하다고 생각되더라도 그것은 개인의 의견일 뿐 모두가 동의할 수 있는 사실은 아니다.
  비교하는 표현을 사용하면 부정적으로 표현되는 면이 생기기 마련이다. 매니저가 전체회의에서 하는 말은 영향력이 크기 때문에 비교형 문장은 피하자.

 

개발 리소스에 등 떠밀리기

  스타트업은 언제나 리소스가 부족하다. FE개발자에게 퍼블리싱 작업은 기본이고 데이터 지표 추적 같은 스크립트 추가는 일상이다. 이런 상황에서 새로운 프로젝트를 목표한 기간 안에 완성하기 위해 가장 쉽게 선택할 수 있는 선택지는 개발자 채용이다. (채용 난이도도 높지만 개발자 출신 뉴비 매니저였던 나는 '그 일정으로는 안됩니다'라고 말하고 실망감을 감내하는 것보다 채용을 통해 일정을 맞추는 방향이 좀 더 쉬웠다.)
  어려운 채용시장에 맞춰 주니어 역량의 구성원을 채용하고 성장을 유도하며 프로젝트를 완료한 뒤 우리 팀은 디자인/기획 리소스에 비해 개발 리소스가 큰 조직이 되었다.(팀 유지비용이 올라가는 것은 덤이었다.) 

이때부터 매니저로서의 나는 '개발자를 놀릴 순 없어!', '개발하지 않으면 재미가 없어져버린다구!'라는 생각을 하며 충분한 고민이 담기지 않은 기획서와 디자인을 요구했고, 유기적으로 돌아가는 팀을 보며 흐뭇해하기까지 했다. 높아진 팀 유지비용을 성과로서 상쇄해야 한다는 조바심이 더해져 상황은 좀처럼 나아질 기미가 없었다.

  조바심이 난 매니저는 어떤 행동이든 할 수 있는 무서운 동물이었다. 의욕이 넘치는 초보 매니저로서 회사를 위해 열심히 달리고 목표를 완수하기 위해 최선을 다했을 뿐인데 나는 예측 불가한 추진체가 되어 있었다. 자연스럽게도 개발 리소스에 등이 떠밀리게 되었고 매니저로서 부족한 결정을 하면서 팀과 프로덕트의 성장에 걸림돌을 만들었다. 

  사용자를 충분히 고려하지 않거나 모두를 만족시키기 위해 복잡한 기능을 설계하고, 유지보수에 사용되는 리소스 예측에 소홀해 매일같이 야근이 이어졌다. 무엇보다 철야하며 구현한 기능들이 유저에게 외면받을 때에는 그 원인을 나에게서 찾지 않고 시장을 탓하곤 했다. 자연스럽고 쉽게 빠져들 수 있는 실수로 인한 등떠밀림의 효과는 강력했고, 그로 인한 결과는 랜덤박스처럼 다방면에서 터져 나왔다. 매니저는 여유롭게 고민하는 시간이 많아야 한다는 조언을 들었을 때 이것은 무슨 소리인가! 했었는데 실수를 거듭하고 난 뒤에야 비싼 값을 치르고 그 의미를 체득하게 되었다. 다시 처음으로 돌아갈 수 있다면 개발 리소스를 늘리기 전에 충분히 고민하고 설계할 수 있는 기획/디자인 리소스 그리고 개발 리소스를 효율적으로 사용할 수 있는 매니저로서의 역량을 먼저 준비할 것이다.

 

매니징과 실무를 동시에 하기

  개발자에서 초보 매니저로 넘어온 나는 의욕이 넘쳤다. 동료들에게 기술역량이 있는 매니저로서 인정받고 싶었고 코드를 작성하는 실무를 통해 증명할 수 있다고 생각했다. 하지만 실무를 통해 구성원의 신뢰를 얻을 수 있었던 기간은 고작 6개월이었던 것 같다. 성장곡선이 너무나 가팔랐던 동료들은 내가 공유했던 기술 레벨 수준을 각자의 분야에서 빠르게 뛰어넘었고 나는 그들이 챙기지 못하거나 리소스 부족으로 담당자가 없는 업무들을 찾아 빈틈을 채우는 정도로 실무를 이어갔다.

  물론 실무를 이어가며 매니징을 하는데 문제가 없다면 실무에도 도움이 되는 매니저가 될 수 있었다. 하지만 나는 초보 매니저였고, 새로운 업무에 적응하기 위해 모든 리소스를 사용하여도 부족한 상황인 것이 문제였다. 그로 인해 매니저로서 해야 하는 것들을 놓치는 경우가 많았고, 실무에도 온전히 집중할 수 없어 리팩터링이 필요한 코드들이 쌓여갔다.

  매니징과 실무를 동시에 하느라 매일같이 야근하는 매니저, 거기에다 완성도 낮은 코드와 인사이트가 부족한 결정을 내리는 리더와 함께 일하는 동료들은 얼마나 힘이 들지 그때는 미처 생각하지 못했다. 초보 매니저라면 겸업은 피하고 매니저로서의 역할을 먼저 소화해 내는 것이 동료들에게 깊은 신뢰를 얻을 수 있는 길이 아니었을까. 역시나 다시 돌아간다면 매니저로서 역할을 할 수 있도록 온전히 노력을 쏟고 싶다.

K-애자일

스타트업이나 소프트웨어를 개발하는 IT조직에서는 애자일 방법론을 채택하는 경우가 많다.
K-애자일을 논하기 전에 찐 애자일 선언문 먼저 살펴보자.

공정과 도구보다 개인과 상호작용을, 포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을, 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.

Source: YouTube, Making Sense of MVP (Minimum Viable Product), https://youtu.be/0P7nCmln7PM

 

  나는 애자일 선언문을 바탕으로 최소 기능 제품(MVP)을 만드는데 주력하고 유저에 집중하여 완성도를 높여가는(때로는 목적지도 바꾸어가며) 형태로 일하려고 했다(근데 못했다). 지난 2년간 우리 팀은 정말 유저에 집중하고 있었을까? 프로덕트의 완성도를 높여가는데 집중하고 있었을까? 반문해보면 명확히 '아니다'라는 답이 돌아온다. 그러면 내가 추구하고 요구했던 개발 방법론은 무엇이었을까? 그것은 바로 K-애자일이었다 흑ㅠ흑ㅠ

우리가 했던 K-애자일은 이렇게 진행된다.

 

① 스프린트 결과에 대한 정량적, 정성적 성과를 측정할 수 있는 환경이 없다.

  이전 스프린트의 성과를 측정하지 않고서 다음 스프린트를 계획할 수 있을까? 스케이트보드가 제대로 완성되었는지 알기 어려운 상황에서 핸들을 추가한다면 그것은 킥보드로서 동작할 수 있을 것인가? 거듭되는 스프린트마다 행운이 따라야만 우리는 목적지에 다다를 수 있을 것이다. 

② 결과물(목적지)은 변경할 수 없으며, 개발 완료 시점이 확정되어있다.

  나는 스프린트로 작업해나가는 것을 관철했고 스프린트를 계획하고 종료하는 기준은 배포일이었다. 2주 또는 3주마다 배포일을 지정해두고 배포일에 맞춰 스프린트를 진행했다. 정해진 개발 완료 시점으로 인해 우리 팀은 유저와 기능에 대하여 충분히 고민할 시간은 줄어들고 기획 파트와 개발 파트의 갈등을 야기했다. 기획서 리뷰 시간에 개발자 의견이 더해지면 기획자는 다시 기획서를 업데이트해야 했고, 그만큼 개발할 시간은 줄어들기에 일정을 더 확보해야 했다. (그러나 일정을 추가하지 못하는 것이 K-애자일의 핵심!)

③ 기능 배포 시점을 팀 외부(타 부서, 고객사 등)에서 결정한다.

  앞선 ②번의 상황에서 기능의 퀄리티 높이기 위해서는 일정을 조율하고 다시 첫 스탭부터 수정해나가는 과정을 반복해야 한다. 하지만 기능 배포 시점을 우리가 조정할 수 있는 상황이 아니라면? 스프린트를 진행하는 중간에 꼭 개발해야만 하는 기능이 추가된다면? 무엇보다 그것이 전사 관점의 이슈(이것은 몹시 민감하고 예민하다.)가 반영되어있다면, 개발팀은 일정보다 늦게 완성된 기획서에 발맞춰 개발을 해내야만 한다. 이를 통해 우리는 파트 간 볼맨 소리, 퀄리티의 결핍, 우리가 원했던 건 이게 아닌 데와 같은 다양한 부작용을 얻게 된다.

④ ①번부터 ③번까지 과정을 반복한다.

 

  어쩌면 워터폴 방식이 어울렸을 우리 조직에 K-애자일이 자리 잡게 된 것은 애자일에 대한 이해도가 부족한 상태에서 애자일을 해야 한다고 큰소리로 주장했던 매니저(나)가 가장 큰 원인이었다. "한국 기업들에서 행해지는 애자일 방법론은 일을 빠르게 많이 시키기 위한 것이 아니냐"는 글이 커뮤니티에 올라올 때마다  "우리는 아니야(응 맞아)"라며 현실을 부정하는 내 모습이 늘 함께했다.

  다행히도 우리 조직은 얼마 전 애자일을 코치와 스크럼 마스터를 전담해주시는 @김영민 님을 만나게 되어 건강한 애자일 문화를 처음부터 다시 키워나가고 나가고 있다. 곧 건강한 애자일 문화에 대한 블로그를 올릴 수 있을 것 같아, 자조 섞인 K-애자일에 대한 설명은 서둘러 마친다.

Source: YouTube Product Owner in a Nutshell, https://youtu.be/502ILHjX9EE

마치면서 

  초보 매니저로서 피하고 돌아가야 할 길을 작성하다 보니, 내용이 너무 길어져 버렸다. 아마도 많은 길을 돌아왔기 때문이 아닐까? 매니저로서 역할을 더 잘했다면 피해 갈 수 있었던 길들을 돌아보면서, 어떤 문제든 팀에서 발생하는 문제는 모두 매니저의 책임임을 또 한 번 느낀다.😢 (그렇다면 잘한 것도 모두!? 🤣)

  피해 가야 할 길에 대해서 글을 쓰다 보니 반성문이 되어버렸다. 잘해온 것도 무척?이나 많기에, 반대로 마주하고 지나가야 할 길에 대해서 페이지를 분리해서 공유할 예정이다. 내가 작성한 글이 나와 비슷한 길에 올라서 있는 분들께 조금이나마 도움이 되고 실수를 덜할 수 있는, 혹은 잘못된 길은 피해 갈 수 있는 단서가 될 수 있으면 좋겠다. 

  

다음 글) 마주하고 지나가야 할 길 

• 작은 목소리에 귀 기울이기
• 동종 업계 연봉 시세
• 강약약약
• 개밥 먹기
• 투명한 정보 공유 

---

김병규

새로움과 자유로움을 좋아하는 개발자입니다.
프로덕트의 성장은 구성원의 성장으로부터 온다고 믿습니다.