팀장으로서 1년을 보낸 후기

먼저 해당 글이 사적인 내용이기도 하지만 회사 업무이기도 해서, 카테고리를 개발에 넣어야 하나 신변잡기에 넣어야 하나 고민하다 객관성 하나도 없는 글이 될 것 같아, 신변잡기에 넣기로 결정했다 ㅎㅎ.
그리고 이제 팀장일을 내려놓게 된 이상, 더 늦어서 내 기억속에서 지워지기 전에 빨리 글로 정리해야겠다는 생각이 들어 일단 글부터 쓰고 본다.

어쩌다 팀장이 됐나?

일단 회사 특성상 퇴사율이 다소 높다는 이야기를 하고 넘어가야겠다.

그렇기 때문에 누군가 퇴사하거나, 팀장이 바뀐다는 이야기는 그닥 놀라운 이야기는 아니다. 하지만 이번에는 우리 팀이었다. 전에 팀장 하시던 시니어 분이 팀장을 그만 두고 다른 일을 해보고 싶다고 이야기를 하셨다고 한다.

회사 다닌지 이제 막 2년차였던 나는 스스로가 주니어의 티를 벗지 못했다고 생각하고 있었지만, 회사 내에서는 나름 트러블슈팅을 잘하는 위치에 있는 엄연한 "시니어" 포지션으로 인정받고 있었다. 그렇게 여느때처럼 별 생각없이 할 일 하고 있었는데, 갑자기 제안이 들어왔다.

"너, 팀장 해볼 생각이 있니?"

'제가요? 이렇게나 평범한데...'

인정받고 있다는 기쁨도 있지만, 아무래도 이 회사에서 팀장은 대체로 기피직인 편이었다. 보수에 비해 잡무가 많이 늘어나는 편이었는데, 인사평가도 해야하고, 특히 팀 대표로서 참석해야 하는 회의가 기하급수적으로 늘어난다는 이야기가 많이 알려져 있었다. 개발 능력을 키우고 싶었던 나 또한 그러한 일들을 그닥 좋아하지는 않았지만, 그래도 뭐, 한번쯤은 괜찮지 않을까? 하는 안일한 패시브가 다시 발동해 버렸다.

"뭐, 시켜주시면 할게요?"

(놀랍게도) 그렇게 팀장이 되었다 ㅡ,ㅡ; 뭐... 연차도 짧고 적극적인 표현도 취하지는 않았지만, 그래도 회사에서 신뢰해 주니까 시켜준 것 아닐까? 나는 그렇게 생각한다.

문제는 나도 회사 연차가 그렇게 높지 않지만, 팀원들은 나보다 더 그러했다. (2년 넘게 다닌 사람이 없었음...)
드림팀을 이끄는 주니어 팀장이라, 당시에는 전혀 실감나지 않았다.

초보 팀장으로서 살아남기

일단 팀장이 되었으니 해야 할 일들을 인수인계 받아야 했다. 그런데 이놈의 중소기업은 항상 문제가 있다. 그 모든 프로세스들이 문서화가 되어 있지 않았다 ㅡ,ㅡ;

일부는 인수인계를 잘 받았으나, 그렇지 못한 것들은 직접 몸으로 겪어가며 부딪혀보는 수밖에 없었다.

• 참석해야 하는 회의들
• 팀 내 규율에 대한 내용
• 주간회의 참석 시의 일종의 자질구레한 규율들
  • 이건 심지어 매번 규칙이 바뀌어서 문서화 하기도 곤란하다...
• 매달 팀 비용 카드값 정산
• 매 분기 인사평가를 위한 가이드라인

나는 뒷 사람이 같은 고초를 겪지 않도록, 그러한 내용들을 모조리 잘 정리해 두었다.

그리고 다음으로 굉장히 날 당황하게 만들었다는 점은, 내가 업무를 일방적으로 받아 처리하고, 평가를 받던 위치였다면 이제는 업무를 분배하고 팀원을 평가하는 위치에 서게 되었다는 것이다. 처음에는 팀에 들어온 일을 내가 모조리 처리하려고 노력했었다. 하지만 당연히 불가능한 일이고, 나에게 번아웃을 유발할 뿐만 아니라 더 나아가서는 팀원의 성장을 저해하는 일이다. 그리고 처리되지 못하는 여분의 이슈는 팀원들에게 아무 가이드 없이 뿌려지게 되다 보니 문제 해결의 시작점 자체를 잘 잡지 못하는 팀원의 생산성이 극도로 저하되는 문제가 있었다.

그래서, 내가 이슈를 처음부터 끝까지 끝내는 것이 아니라 문제의 시작점만 짚고서 이를 팀원에게 넘겨주는 식으로 형태를 바꿨다. 이렇게 하니 팀원도 일을 훨씬 수월하게 할 수 있는 게 눈에 보였고, 나 스스로도 훨씬 부담이 줄어들었다.

그리고 소통의 문제가 있다. 팀원들에게 일을 시키거나 혹은 진행상황을 보고받을 때 의도한 대로 되지 않는 경우가 생각보다 많았다. 이를테면 팀원이 업무 사항을 전달하는 법을 잘 몰라서 문제 원인에 대해서는 쓰지도 않고 QA랑 질펀하게 싸운 내용만 보고한다던가, 아니면 내가 팀원에게 할 일을 전달하는데 세부적인 목표와 기간을 제대로 전달하지 않아서 A-B-C 3개의 일을 해야 하는데 A만 하고서 멀뚱멀뚱 있다던가.

이런 경우를 마주칠때면 당황하거나 답답해서 화도 나긴 했지만, 근본적인 문제는 내가 전달을 잘못했었다는 것을 금방 알 수 있었다. 그래서 나 스스로에게 일종의 규율을 정했다.

• 모든 보고에는 반드시 문제상황 - 문제내용 - 진행상황 - 목표일정 전달받을 수 있도록 함
  • 내 스스로가 이 정도는 보고를 받아야지 전체 맥락을 파악할 수 있더라.
• 업무 내용은 가능하면 두괄식으로 전달하도록 함
  • 핵심 내용이 먼저 나오지 않고 말이 길어지면 서로 집중력이 떨어지고 힘들다

팀장으로서의 자질과 소통 관해서 자세히 쓴 책들이 훨씬 많기 때문에, 여기 있는 걸 참조하기보다는 그러한 책들을 읽는게 나을 듯 싶다 ㅎㅎ.

마지막으로, 아키텍쳐 이해의 부족함을 절실하게 느낄 수 있었다. 팀 내 문제만 해결할때는 사실 전체 아키텍처에 대해서 무관심해도 상관이 없었다. 우리 모듈의 아키텍처만 알고 있으면 우수한 개발자 취급을 받기에 충분했으니까. 하지만 팀장으로서 회사 단위의 회의에 참석하다 보면 자연스럽게 우리 팀이 언급되는 경우가 있었다. *"이걸 왜 이렇게 만들었나요?" / "이 로직이 왜 여기서 불리나요?"* 같은 질문이 들어오면 전체 그림을 모르는 나는 모른다고밖에 말할 수 없었다. 문서화가 썩 잘 되어 있지 않은 회사 탓만 마냥 할 수는 없었다. 나 스스로 소프트웨어 전체 아키텍처에 대해서 공부하려고 부던히 노력하기 시작한게 이 때부터였다. 경쟁사 제품이나 최신 트랜드의 아키텍처에 관심을 가지며 공부하기 시작했고, 다행히 금방 따라올 수 있었다. 하지만 문서화는 하지 못했다...

팀 내 문화에 대해서도 신경썼다. 생산성을 떨어뜨리는 팀 내 불필요한 회의는 없애거나 축소시키고, 코드리뷰는 최대한 다 같이 참여하도록 했다. 능숙하다면 피어코드리뷰로 충분하지만, 다들 잘 모르는 부분이기 때문에 코드리뷰로 오류도 잡음과 동시에 공부할 수 있는 기회를 만드는 것이다.

팀의 생산성에 대한 고민

위에서 팀의 모든 일을 내가 하던 방향에서 팀원들을 적극적으로 활용(?)하는 쪽으로 바꿨다고 이야기했었다. 하지만 그것만으로는 여전히 팀원의 생산성이 충분하지 못했던 것 같다.

문제 하나를 몇달간 물고 늘어지는 사람도 있었다. 문제의 큰 틀에서의 해결 방안은 짚어주었지만, 이후 어떤 식으로 진행해야 하는지도 잘 몰랐는지 진행도 잘 안되고 있었다. 매주 보고를 받는데 보면 진행을 한다고 쓰긴 썼는데 막상 봤을 때 그 내용은 전혀 없는 보고만 받고 있었다. 잘 안 되는거 같으면 와서 물어보고 도움을 청해달라고 이야기를 했지만... 결국은 데드라인이 도래해서 어쩔수 없이 내가 붙어서 바로 치워버렸던 기억이 있다.

이건 우선 보고에 문제가 있음을 자각하고서도 별 조치를 취하지 않았던 나의 잘못이 크다. 하지만 잘 진행되지 않는다 싶으면 문제 상황을 바로 보고해주거나, 아니면 팀장한테 진행이 막힌 부분을 이야기 해 주었어야 했는데 그렇지 않는 것도 크다고 생각한다. _잘 진행되지 않음_에 대한 기준도 다를 것이라고 생각하는데, 개인적으로는 시도할 수 있는 방안이 없거나, 해당 방안에 대해서 진행이 안 되는 상황이 이에 해당된다고 본다.

특정 사람이 일이 없어 놀거나, 일이 몰려있는 경우도 있었다. 그런 경우는 내가 보고를 기반으로 일을 재분배하여 특정 사람이 과다하게 부담을 지우지 않도록 했다.

그래도 이 정도가 되니 신참 팀은 그럭저럭 굴러는 가는 수준이 되었고, 기능이 안정화되고 나서는 이따금씩은 팀으로서 할 일이 없는 경우도 있었다.

팀이 나아갈 방향으로의 고민

팀이 할 일이 없으니 막상 불안하더라. 이러면 팀의 존재 가치가 없는 것 아닐까? 그러면 아무도 평가를 잘 못 받을 텐데? 본인의 커리어에도 흠집이 날 텐데? 그런 생각이 들었다.

그런데 잘 생각해보면 팀이 할 일이 없다는 것 자체가 틀린 말이었다. 툭하면 팀 모듈의 불안정한 이슈 리포트가 들어오고, 내 스스로도 모듈의 불완전함을 느끼고 있는데, 정말 그럼에도 불구하고 할 일이 없는 것일까?

그래서 나는 다시 한번 고민을 시작하게 되었다. 우리 팀이 해야 하는 일이 무엇일까? 다르게 말하면, 우리팀의 기술 부채가 무엇인지 찾고자 고민하게 되었다. 경쟁사 제품들과 근래 유행하는 제품들의 아키텍처 및 설계, 구성등을 참조하며 우리 제품/모듈에 없는 것은 무엇인지 열심히 찾았다.

해답은 어렵지 않게 찾을 수 있었다. 로그성 정보가 많이 부족한 점도 있었고, 성능상 하자가 있는 부분도 많이 있었다. 해답 또한 타사의 아키텍처나 테크블로그 같은 곳에서 힌트를 얻을 수 있는 점이 많아 금방 찾을 수 있었다. 그리고 그렇게 얻은 할 일들은 팀원 각각에게 장기 프로젝트로 하나씩 쥐어주었다. 성취해 낸다면 회사 뿐만 아니라 개인의 성장에도 아주 큰 도움이 될 것이다. 그리고, 이러한 경험 자체가 나에게 훨씬 넓은 아키텍처들을 경험하게 해 줄 수 있었고, 큰 도움이 되었다.

팀장을 그만두게 되었다

연말이 되니 팀원들도 한결 업무에 익숙해졌고, 나도 일이 훨씬 편해져서 팀장의 자리를 만끽(?)하고 있었다.

하지만 나를 필요로 하는 다른 자리가 생겼고... 자연스럽게 요청이 나한테로 흘러왔다. 팀장에서 팀원으로 내려가는 위치라 그렇게 이득을 보는 조건은 아니었지만, 같은 모듈만 한 지가 벌써 3년째다. 다른거 해 볼때도 되었고, 나 말고도 다른 팀원에게 "성장의 기회"를 주는 게 좋지 않을까? 하는 생각이 들었다.

이번에도 안일하게 "시키면 하구요"라는 답변을 취했고, 그렇게 나는 1년의 짧은 팀장 경험의 마무리를 지었다.

생각해보면...

약간 과장해서 말하면 짧은 기간동안 스타트업 해보는 거랑 비슷한 경험이 아니었나 싶다. 조직을 이끌고, 고객사의 문제를 1차로 받아 처리하고, 팀이 가야할 방향에 대해서도 고민해 보고.

그래도 여러가지 아쉬운 점도 있긴 하다. 특히 관리와 소통의 문제가 있지 않았나 싶다. 다들 성격이 둥글둥글해서 별 마찰은 없었지만, 아무리 생각해도 업무 효율이 불만족스럽다. Jira와 같은 프로젝트 관리 솔루션이 있다고는 하지만, 팀장을 하면서 느낀 문제는 그런 것으로 해결되는 게 아닌 것 같다. 나중에 관련 서적을 읽으며 공부할 필요가 있지 않나 싶다.

그래도 커리어 상으로 크게 도움이 되었던 점이 제일 좋은 것 같다. 이직할 때 이력도 한 줄 더 써넣을 수 있고 (ㅎㅎ), 큰 틀에서 각종 아키텍처들을 공부해 놓은게 이제 와서 크게 도움이 된 것 같다.

아무튼, 팀장을 할 기회가 온다면, 한번쯤은 해보는 게 역시 좋은 것 같다. 큰 틀에서 아키텍처를 볼 수 있다면 경력은 크게 문제가 되지 않는 것 같고, 오히려 개발할 일은 적기 때문에 실력은 필요가 덜할지도 모른다. 물론 개발을 관리하는 능력도 필요하기 때문에 가능하면 개발도 잘하는 쪽이 좋다... 게다가, 평상시에 개진하고 싶은 의견이 많다면 팀원으로서보다 팀장으로서가 목소리를 더 크게 낼 수 있다.

그리고 팀장을 할 기회가 주어진다는 것 자체가 신임할 수 있는 자리에 있기 때문인 것 아닐까? 기회가 있다면 두려워 말고 해보자 ㅎㅎ.