ETC

팀장이 되면 어떻게 해야 할까

partner_jun 2024. 9. 17. 21:27

들어가며

실장에 이어 팀장도 퇴사한다는 소식을 전해왔다. 전 CTO가 이직한 회사로 간다고 한다. 팀장뿐 아니라 팀원도 한 명 같이 가기에 더 많은 퇴사자가 있을 가능성이 크다. 흔히 그렇듯 대규모 이동이다.

그들이 '굴러간' 돌이 될지도 모른다

 
이 와중에 상위 조직인 유닛의 유닛장이 나에게 팀장 의사가 있는지 물어왔다. 팀장 아래 레벨 중 지원자가 있는지 확인하는 것이었다. 최근 회사가 비즈니스적인 이슈로 여러가지 이야기들이 있는 불안정한 시기이기에 우선 "손 들고 하겠다고 하지는 않겠다" 정도로 의사를 전했다. 곰곰히 생각해보면 조만간, 혹은 적합한 사람이 없다면 당장 팀장이 되어야 하는 상황인 것을 깨달았다. 지금이 아니더라도 팀장이 되어야 할 것이며, 미리 준비하지 않는다면 내가 욕하던 무책임한 팀장이 되리라는 생각이 들었다. 내가 팀장이 된다면 어떻게, 무엇을 해야 할지 몇가지 생각해보았고 이를 적어둔다.
 

새로운 상황에 대한 적응

이직했을 때와 마찬가지다. 이미 있던 것을 부수고 바꾸는 것은 쉽다. 이전의 상황을 분석하고 이해할 필요가 없기 때문이다. 이해는 어렵다. 사람은 가지각색이고 왜 그런 선택을 했는지 본인이 아니면 이해하기 어렵다. 하지만 어렵다고 해도 포기해서는 안 된다. 아무리 가치없어 보이고 멍청한 결과물로 보여 다시 시작해도 나 역시 같은 전철을 밟아 누군가가 부술 무엇인가를 만들어낼 확률이 높기 때문이다. 나는 이게 소위 말하는 신사업, 차세대 프로젝트가 실패하는 이유라고 생각한다. 2~3주 정도 한발치 떨어져 바라보는 겉핥기가 아니라, 직접 업무를 직면하여 면밀하게 파악하고 재구성해야 한다. 그것이 아무리 쓸모없는 회의나 문서라 할지라도.

"갈아엎자"는 직책자가 해서는 안되는 말이 아닐까.

 

작은 것부터

항상 목표는 높다. 심지어 목표를 높게 하라고 모두가 말한다. 하지만 목표 그 자체를 이루어내거나 목표를 이루어 내기 위한 과정을 유지해나가는 경우는 극히 드물다.

나도 명확한 목표를 선정해서 이룬 적은... 없는 것 같다

 
목표 선정과 달성에 대해 가장 깊게 분석한 분야는 게임이라고 생각한다. 최근의 게임들은 계단식 성장과 "분재화"를 추구한다. 하루 하루 숙제만 하다보면 어느새 성장하는 것이다. 회사 생활도 마찬가지다. 계단식 성장과 분재화를 통해 점점 성장하도록 유도하는 것이다.
 
팀장이 이러한 "분재화"된 사이클을 유도하면 팀과 개인 모두 성장할 수 있을 것이라 기대한다. 그러기 위해 한번에 많은 일들을 시작하기보다 아주 간단한 것부터 시작해야 한다. 특히 조심해야 하는 것은 회의나 평가에 이어지는 것들이다. "팀을 위해" 많은 회의를 잡고 "공정한 평가를 위해" 다양한 잣대를 세우기보다 아주 간단한 것부터 시작해야 할 것이다. 이를테면 무엇에 관심있는지, 무엇을 하고 있는지 물어보는 티타임이다.
 
 

팀의 가치 증명

결국 팀도 회사의 부품이다. 부품은 필요없어지면 버려지거나 교체된다. 팀은 해체된다. 팀장은 팀원으로 강등되고 팀원은 뿔뿔히 흩어진다. 그래서 늘 팀의 가치를 증명해야 한다. "이 팀은 잘 하고 있으니 건드릴 필요가 없어"라는 인식을 심어주어야 한다. 이런 정도로 팀의 가치를 증명하기 위해서 어떤 방법이 있을지 고민해보았다.
 

주어진 업무 수행

팀에 기대하는 기본적이고 단순한 것으로, 정확하게 수행한다 해도 팀의 가치가 높아지지 않는다. 심지어 팀이 팀으로 존속할 수 있을 가능성도 매우 낮다. 제대로 해내지 못했을 때 감점이 되는 요소일 뿐이다. 하지만 업무 수행도 가치가 생길 수 있다. 수행한 업무를 모아 가치를 만들어내면 된다. '업무 수행함' 으로 끝나는 것이 아니라, 흔히 말하는 액션 아이템을 발굴해내야 한다. 어떠한 업무를 통해 우리는 서비스를 더 뛰어나게 하기 위해 이러한 것을 발견했다는 식이다.
 
일례로, 제작년 수행했던 액션 아이템이 있다. 클라이언트 로그(통계) 전송 라이브러리 개발이다. 사내의 페이지를 수정/개발할 때마다 클라이언트 로그를 변경해야 했는데, 이 전송 로직이 프로젝트별로 흩어져 있었다. 심지어 오래된 버전의 라이브러리를 사용하고 있어 번들링 되었을 때 용량도 너무 컸다. 로직을 한데 모아 개선하고 라이브러리를 최신화한 것을 라이브러리로 만들었고 이는 꽤나 좋은 평가를 받았다. 다른 팀에서도 사용하는 일종의 공통 라이브러리가 되었을 뿐 아니라, 이를 기반으로 다양한 업무로도 이어졌다. 단순한 로그 작업에서 다른 팀에까지 영향을 미치는 프로젝트로 이어진 것이다.
 

능동적인 이미지

FE는 그 특성상 수동적인 팀으로 보일 가능성이 높다. 디자인이 나와야 한다, API가 나와야 한다 등 어쩔 수 없는 현실적인 제약 때문이다.

뭘 알려줘야 하지

 
너무 불리하다. 한걸음 떨어져서 본다면 팀 자체가 수동적인, 곧 알아서 일하지 않는 집단으로 보일 확률이 높다. 한번 생긴 인식은 떨쳐내기 어렵다. 문제가 있을 때 정리를 위한 첫번째 타깃이 될 확률이 높다. 이 현실적인 제약을 비틀어 능동적인 이미지를 만들어 두어야 한다. 개인적으로 프로토타이핑을 통한 진행 상황 공유가 그 해답이라고 생각한다. 웹 개발, 특히 웹 FE는 다른 개발에 비해 프로토타이핑에 강하다. 컴포넌트화 되면서 변화에도 그리 민감하지 않다. 이런 이점을 살려 디자인이 나오지 않더라도, 혹은 API가 나오지 않더라도 미리 작업하고 기획이나 디자이너에게 공유하는 것이다. "이런 분위기로 노출될텐데 한번 확인 부탁드립니다"라는 말 한마디로 충분하다. 덤으로 담당자들에게 다시 한번 생각할 시간을 주기에 프로젝트의 완성도도 높아진다.
 

기술적 증명

목적 조직이건 기능 조직이건 기술적 가치를 가질 수 있는 집단이라면 팀 외부에 영감을 줄 수 있어야 한다. 단순히 팀 내에서 잘 만들었고 훌륭한 기술을 사용하고 있다고 하더라도 어필하지 않으면 아무런 가치가 없다. 심지어 실제로 그 기술을 사용하지 않더라도 다른 팀, 다른 조직에게 이러한 것이 있고 우리에게 어떠한 가치가 있을 수 있다는 것을 보여준다면 그것만으로도 팀의 기술적 역량이 증명된다. 더 나아가서 팀, 조직뿐 아니라 더 넓은 필드를 목표로 해야 한다. 작게는 개인 블로그나 팀 블로그, 크게는 사내/외부 발표(컨퍼런스)나 도서 출판 등이 있다. 이런 외부 활동을 활발하게 하고 있는 배민이나 토스는 모두가 '테크 기업'이라는 인식을 가지게 되었다. 회사에 대해 좋은 인식을 심어주는 팀은 회사에서 손놓고 싶지 않을 것이다.

천룡인에 한걸음 다가서게 될지도

 
물론 발표는 쉬운 일이 아니다. 심지어 공유할 내용이 없을 지도 모른다. 그래서 내가 제안할 목표는 도서 출판이다. 업무를 수행하다 보면 많은 문제에 직면한다. 이렇게 직면했던 문제와 해결 방안들을 모아 문서화하면 그것만으로도 중-고급자에게 도움되는 엄청난 자산이 된다. 심지어 시장에 초급-중급자만을 위한 도서만이 있다는 것을 생각해보면 경쟁력도 있다. 실제 도서로 출판하지 못해도 개인/팀 블로그에 올릴 수 있다는 점도 장점이다.
 

비즈니스적 증명

기술자는 기술을 주력으로 생각한다. 하지만 회사는 돈을 벌기 위해 존재한다. 돈을 벌어주지 못하는 팀은 필요 없다. 그렇기 때문에 "기술"이 매출 증대 혹은 감소 방지에 영향을 주고 있음을 명확한 지표로 나타내야 한다. 여기에서 흔히 말하는 "정량적 지표"가 필요하다. 웹 개발자가 만들어낼 수 있는, 매출에 영향을 주는 지표는 크게 두가지로 생각된다. 첫째로 서버 비용 증감이다. 클라우드 서비스를 이용하기 시작하면서 서버 비용은 큰 부담이 되었다. 특히 프로모션에 직면하는 FE는 서버의 수가 가장 많을지도 모른다(SSR 여부에 따라 차이가 크다). 개발자가 목메는 성능을 잡아 이러한 서버의 수를 줄인다면 그것만으로도 상당한 액수를 줄여낼 수 있다. 단순히 "퍼포먼스가 늘었다"에서 끝나는 것이 아니라 "비용이 몇 퍼센트 감소했다"까지 이어져야 한다는 것이다. 두번째는 SEO를 통한 외부 진입 성과다. 한국의 검색 엔진은 거의 죽었다고 볼 수 있다. 대부분이 구글에 의존하고 있는 상황이기에 구글의 검색 순위에 따라 매출은 크게 증가한다. 몇 달간 어떤 작업을 통해 어떻게 변화했는지를 우리가 전송하는 클라이언트 로그를 기반으로 문서화해서 공유해야 한다. 장기적으로 어떤 작업을 진행해서 어떤 증감이 있었는지 가시적으로 보여준다면 관심을 가지게 될 것이다.
 
 

개인의 능력 연마

팀은 개인의 모임일 뿐이다. 언제든 취업 시장에 돌아갈 수 있음을 명심해야 하고 늘 준비해야 한다. "항상 가슴속에 사표를 지녀라"는 말은 이전 회사에서 들었던 가장 인상깊은 말이었다. 회사가 전부가 아니라는 말이기도 하지만, 언제든 회사에서 나갈 수 있도록 준비해야 한다는 말이기도 하다. 특히나 요즘처럼 높은 인건비로 신경이 곤두서있는 시기라면 평소의 준비가 빛을 발할 것이다.
 

나만의 '무기' 준비

기술자는 가진 기술로 빛난다. 하지만 모두가 같은 빛을 발한다면 비교될 수 밖에 없다. 우리는 비교당하는 사회에서 살아남기 어려움을 안다. 이른바 '제네럴리스트'로서는 살아남기 쉽지 않다는 뜻이다. 그래서 나는 본인만의 특별한 빛을 보여줄 수 있는 '무기'를 준비하는 것이 좋다고 생각한다. 하지만 정말 엄청나게 깊게 팔 필요는 없다. 그런 지식은 검증할 수 있는 사람도 없고, 한정적인 상황에서 빛을 발해 오히려 인정받기 어렵다. 동료가 찾아와 답을 얻어갈 정도의 '스페셜리스트'를 목표로 해야 한다. 당연히 막연하게 준비하는 것은 어렵다. 지금까지 해 온 업무들, 그리고 내 생각에도 '꽤나 스마트하게' 해결했던 문제를 모아보자. 그 문제를 어떻게 해결할 수 있었는지, 다른 대안은 어떤 것이 있었는지 생각하고 찾아보는 것으로 첫 발걸음을 뗄 수 있지 않을까.
 

신기술에 대한 비판적 사고

신기술에 대해 무조건 긍정하여 도입하고자 하는 사람이 있는 반면, 무조건 반대하는 사람이 있다. 나는 두가지 형태 모두 일리있다고 생각한다. 새로운 기술에 대해 반대한다면 항상 같은 것만을 사용하게 되어 학습하지 못하게 된다. 우리는 학습하지 못하면 도태된다. 하지만 무조건 긍정하여 도입한다면 돈을 벌기 위한 프로젝트가 기술의 시험장이 되어버린다. 제대로 알지 못하는 상황에서 생각치 못한 결점을 맞이하게 되면 문제가 심각해진다.

그래서 그거 왜 씀

 
그렇기 때문에 나는 두가지의 중도, 하지만 부정적인 측면에 약간 더 기울어, 기술에 대해 비판하는 상태를 지향해야 한다고 생각한다. 비판하기 위해서는 자연스레 기술에 대해 파악해야 하기 때문이다. 장단점을 파악하고 이 서비스에 있어 기술을 사용했을 때 어떠한 가치를 가지는지에 대해 분석하고 사고할 수 있어야 한다.
 

가치 증명

내가 가진 특징과 기술을 증명할 수 있어야 한다. 해온 것들을 앞에서 말로 설명할 수 있으면 좋겠지만 그럴 기회조차도 주지 않는 것이 현실이다. 최소한 문서에서만큼은 완벽하게 포트폴리오나 블로그 등을 주기적으로 기록하고 갱신해야 한다.

나도 제대로 지키지 못하고 있다

 
그러한 '페이퍼' 스타일을 싫어하는 사람도 많다. 나도 링크드인이나 이력서 등 문서로 떠드는 사람을 좋아하지 않는다. 흔히 친구들에게 "이 사람은 핵미사일을 만들어 본 것 같다"고 비아냥거리기도 한다. 하지만 지금 그것이 유행이고 현실이다. 내가 결정권자라면 그것 말고는 볼 수 있는 것이 없기 때문이다. 살아남기 위해서는 준비하는 수밖에 없다.
 
가장 주요한 것은 팀과 개인의 가치 증명, 이 두가지를 동시에 해내는 것이다. 위에서 언급한 팀 블로그나 도서 발매 등이 대표적이다. 물론 굉장히 어려운 일이다. 하지만 내가 이직하기 위해 준비한다고 생각하면 조금이나마 의욕이 생기지 않을까.
 
 

마치며

이런저런 이야기를 써두었지만 내 생각에 팀장으로써 중요한 것은 두가지다. 팀의 가치를 증명할 수 있는 일들을 주도하고, 팀원 개개인의 능력을 연마하고 증명할 수 있는 판을 짜는 것이다. 어떤 팀장에게 각자도생이라는 말을 들었던 적이 있다. 맞는 말이다. 그 누가 책임지고 도움을 줄 수 있을까. 맞지만 옳지는 못한 말이다. 팀장이라면 각자도생하라는 말로 끝나는 것이 아니라, 각자도생 하는 방법을 알려주어야 한다고 생각한다. 그것이 직위의 무게니까. 난 적어도 지금은 그렇게 생각한다.