하나의 팀에 팀장이 되기까지 회고 해보기

개발자 인생의 처음으로 웹팀의 팀장이라는 포지션을 갖게 되었습니다.

아직까지는 순항중 것 같습니다만, 언제나 그렇듯 아직 제가 모르는 우리팀에 맞는 더 좋은 방법이 존재할 것이기 때문에, 더 많은 시행착오가 필요할 것 같습니다.

지금까지 웹팀이 구성되고, 팀장되기까지 겪었던 경험을 써보려고 합니다.

팀원의 존재

2017년 한 회사에 입사했습니다. 입사 당시에는 Web Front End 개발자가 2명이였으나, 6개월 만에 혼자가 되었습니다.

큰 서비스는 아니였기때문에, 일이 엄청 힘들거나 복잡하지는 않았으나, 그래도 혼자서하기에는 조금 벅찼습니다.

그래서 동료를 뽑아야 했었는대, 항상 면접을 보기만 했지, 면접관이 되본적이 없었기 때문에, 어떤 동료가 나와 맞는지 기준을 잡아야 했습니다. 개발자는 당연히 개발 실력이 뛰어나야한다고 생각했고, Javascript 를 잘 이해하고 있는지를 기준으로 잡았습니다. 하지만, 동료를 찾기 너무나도 어려웠는데, 특별한 기회가 생겨 CTO 님을 통해 인턴을 모집하게 되었고, 운 좋게도 인턴 2분께서 함께 해주시게 되었습니다.

하지만, 그렇다고 제 실력이 뛰어나진 않아서, 두분께 뭘 가르쳐 드리거나, 가이드 해 드릴수 있는 방법은 없었습니다. 대신 함께 일하는 방법을 시도해보기 시작 하였습니다.

처음은 이전 회사에서 스크럼 회의의 경험 했던것을 따라하기 시작했습니다. 아침에 5분씩 모여서 어제 뭘했고, 오늘 뭘할지, 이야기 해보는 자리를 만들었습니다. 주로 작업 이슈 사항에 대해 서로 의견을 주고 받았습니다. 눈에 보이는 효과는 없었으나, 이때부터 같이 일하는 동료로써의 팀이라는 개념이 잡하기 시작했던것 같습니다.

같이 일하는 동료이지만, 아침모임 이외에는 각자가 개발하고, 작업물은 함께 확인 하였기, 제품에는 문제가 없었습니다. 하지만 얼마 지나지 않아, 다른분들이 작업하신 부분을 수정하려고 보니, 정말 읽기가 힘들었습니다. 코드를 잘못 작성 되어있는 것이 아니라, 저와는 너무나도 형태가 달라서, 익숙지 않았습니다.

그때부터 코드 리뷰를 시작했습니다. 작업이 끝나면, 작업물에 대해서 전체적인 설계나 코드를 리뷰를 해주고, 의견을 주고 받았습니다. 그러다보니, 서로의 습관들이 나오기 시작했고 논의는 조금씩 길어졌습니다.

이때부터 함께 개발하는 형태에 대해서 고민하기 시작했습니다. 함께 개발하기위 한 첫번째 단계로 코드 스타일을 맞추기로 했는데, 한분께서, Prettier 를 소개해 주시고, 적용까지 해주셔서 지금까지도 요긴하게 코드 스타일을 맞추고 있습니다.

인턴분들과 함께 일하면서, 느낀점은 팀으로 일하는 동료에게 중요한 능력은 기술력이 아니라 함께 일하는 방법을 이해하고 실천하는 분이라는 점이였습니다. 이때부터 함께 일하는 방법을 더 고민하기 시작 하였습니다.

작업물 공유

회사가 조금씩 커지면서, 동료가 더 채용 되었습니다. 그리고 App 과 Web 을 합친 클라이언트 팀이 형성 되었습니다.

팀이 형성되면서 작업은 클라이언트 팀장님이 작업을 분배해 주시거나, 리소스가 남는 사람에게 업무가 요청이 들어왔고, 각자가 프로젝트 그룹에 할당되어 점점 각자가 각자의 업무에 몰입하기 시작 하였습니다. 각자의 프로젝트에만 집중하다보니, 코드리뷰나 작업물 공유를 점점 않하게 되었습니다.

작업물을 공유하기 위해서, 작업 요청이 오면, 웹 개발자 스스로가 일정을 산출하던것에서, 웹 개발자들이 모여서, 작업물에 대한 플래닝 포커를 진행하고, 작업 일정과 요구 사항을 산출하였습니다.

또한 웹 개발자들끼리 2주에 한번씩 모여서 회고와 표준화 회의를 시작하였습니다. 처음에는 무엇을 해야할지 몰라서, 각자가 겪은 작업에 대한 난상토론으로 시작하였으나, 점차적으로 규칙을 만들고, 잘한점과, 더 잘했어야하는 점, 앞으로 우리가 해야할 일 등 다양한 시도를 시작하였습니다.

점차 팀 문화가 형성되기 시작했는데, 이때 느낀 것은 팀 문화는 동료들이 자발적으로 만들어 낸다는 점입니다. 여러가지 시도를 하였지만, 각자가 내준 소중한 의견들 예를 들면, 컨퍼런스를 다녀온 경험 공유하기, 스터디 함께 진행하기, 주말에 공부한 내용 공유하기, 좋은 글 공유하기 등등 당연할 수 있지만, 당연하지 않는 자발적인 행동들은 지금의 팀문화를 만드는 기반이 되어 있습니다.

웹팀

클라이언트팀에 TO 가 증가되면서, 규모가 커지다 보니, Web 팀과 App 팀으로 분할이되면서, 공식적으로 웹팀이 형성 되었습니다.

웹 개발자 중 말을 제일 많이 하던 개발자에서, 이제는 웹팀의 팀장이 되었습니다.

팀장은 처음이라, 팀을 위해서 어떤 일을 해야할지, 어떻게 팀원 들을 대해야할지, 아무것도 몰랐습니다. 하지만 지금까지 했던 경험을 발판 삼아서, 해보고 싶었던 것들을 진행 해보기 시작했습니다.

팀이 형성 되자마자 처음 시도했던 것은 모든 요청을 하나로 모으고 공유 하는것이 였습니다.

보통 이슈가 발견되거나, 특정 이슈에 대해서 문의할 일이 생기면, 슬랙이나 자리에서 각 담당자에게 요청하거나 담당자를 찾습니다.

이를 줄이기 위해서 이슈를 슬랙의 개인 멘션을 팀 멘션으로 요청하여, 이슈를 공유하고 가장 잘 아는 담당자가 확인해주거나, 팀장이 가장 먼저 확인하고, 대응하여 팀원들이 일에 집중하게하는 방식을 시도해보았습니다. 아직까지는 성공적이나, 나중에 팀이 더 커지면 어떻게 해야할지 고민입니다.

다음으로 한것은 일주일 단위로 업무를 프리징 시키는 것이였습니다.

웹의 경우 자유롭고, 빠르게 배포할 수 있기 때문에, 작은 요청이 오면, 바로바로 해주는 경향이 강합니다. 하지만 지속적으로 요청을 바로바로 처리 하다보니, 하루만에 작업 해달라고 오는 경우도 있고, 급하게 발생하는 경우가 많이 생겨, 하던 작업을 미루고, 작업하는 상황이 종종 생겼습니다.

하여, 일주일 단위로 작업을 프리징 시키고, 정말 급한 hotfix 건을 제외한 요청하는 모든 업무를 backlog 로 만들고, 다음주에 작업하도록 스케줄을 조정했습니다. 일주일 동안 해야하는 작업물이 크게 변하지 않고, 미리 정리하고 공유하여, 작업에 대한 이해도도 사전에 올리며, 일주일 이상 걸리는 작업은 최대 일주일 단위로 잘라서, 일주일 단위로 작업 상황을 빠르게 피드백 받을 수 있는 많은 장점이 생기게 되었습니다.

업무소통 방법과 진행방법을 어느정도 정리되니, 이제는 팀에 프로젝트별로 작업 요구사항과 유지보수 작업물, 그리고 팀내 작업물을 분배할 필요가 생겼습니다.

처음에는 큰 덩어리의 Story 를 만들고, 이를 팀원에서 나누어 주었습니다. 그러다보니 요청자와 작업자 간의 혼란이 생겨서, 더 많은 커뮤니케이션 비용이 발생 하게되었습니다.

• 개선안으로 먼저 팀밖에서 발생하는 업무는 팀장이 담당자와 협의를 거쳐 어느정도 요구사항을 정리합니다.
• 정리된 내용은 Jira 에 Epic 을 생성하고, 요구사항을 Story 로 분할하고 Backlog 에 쌓아놓습니다.
• 그리고 매주 일정 회의를 통해 Epic 과 Story 를 공유하고, 원하는 팀원이 업무로 가져갑니다.
• 작업후, 회고를 통해 작업 내용을 공유하고, 경험을 공유합니다.

장점은 개발자 본인에게, 주어진 작업물에 집중하게되고, 여러 Story 로 쪼개놓아, 하나의 프로젝트를 여러 개발자가 동시에 작업하게 되어, 작업 속도가 증대되었습니다.

단점은 개발자 주도로 작업을 진행할 수 없다는 점이 였는데, 원하는 개발자가 있다면, 특정 프로젝트에 속하게되어 직접 요구사항을 정리하고, 해당 내용을 매주 일정 회의때 공유하는 방식도 추가되었습니다.

두가지 방향으로 팀이 운영되다보니 개인적으로는 혼란이 있긴하지만, 더 알맞을 방법을 찾으리라 기대하고 있습니다.

작업물들이 점점 쌓여가면서, 서로 중복된 작업물들이 늘어만 갔습니다. 팀내업무로 각자가 필요한 module 을 만들거나 만들어보고 싶었던 작업을 진행후, 이를 코드리뷰를 통해 재사용이 용의하게 처리합니다.

하지만 인원이 늘어나면서, 각자 작업하고 코드리뷰를 요청하는 건도 많아지기 시작했습니다. 처음에는 회의실에 모여서 모두 함께 코드를 리뷰를 진행 했습니다.

하지만 횟수가 늘어나면서 오프라인에서 온라인으로 옮기게 되었고, 특정 branch 에 pull req 를 날리고, 모든 팀원이 comment 로 코드 리뷰를 진행했습니다.

또 그러다보니, 리뷰가 길어지고, 리뷰해야할 내용이 많아지면서, 리뷰의 품질이 떨어지기 시작하여, 리뷰어가 코드 리뷰를 받고 싶은 2명을 선정하여, 코드리뷰를 진행하게 변경하였습니다. 아직까지는 괜찮은것 같지만, 코드 리뷰문화를 개선할 수 있는 방법이 더 있을 것 같아 고민중입니다.

앞으로 가야할길

팀장으로써는 아직 부족한 점이 너무나도 많습니다. 특히나 가장 많이 부족한 부분이 커뮤니케이션 이였습니다. 여러 방법을 시도해보면서 본인이 이해하고 있는 바를 다른사람에게 쉽게 설명할수 있는 능력을 키워야 요청자가 원하는 요구사항을 정확하게 구현할수 있으며, 이를 개발자에게 잘 전달할 수 있을것 같습니다.

하지만 역시나 아직은 팀장보다는 개발자를 잘하고 싶습니다. 지금 하고있는 팀장의 업무 경력이 쌓이면 쌓일수록 더 큰힘이 될것 같아 지금은 팀장의 업무를 잘 소화하면서 개발을 잘하기 위해서는, 어느정도 개인적인 삶을 내려두고, 그 시간을 개발 공부에 투자할 수 밖에 없는것 같습니다.

올해까지는 아직은 잘해온것 같지만, 내년도 잘할수 있을지 더 기대해 봅니다.