23년은 새로운 팀으로 옮기며 내 능력들을 테스트해볼 수 있는 시간이었다.
한 해를 돌아보니 생각보다 새롭게 경험한 일들이 많다.
그럼에도 돌아보면 아쉬운 것들도 많고.
팀 문화 리딩하기
올해는 팀을 옮긴 후 팀의 문화를 만드는데 시간을 많이 쏟은 해였다.
팀 문화가 무너지고 정체된 팀에 문화를 만들자며 파트 리더가 나를 현재 팀으로 보냈다.
연간 회고를 하며 작년 회고를 봤을 때, 이전 팀은 팀 문화를 참 잘 만들어가던 팀이었구나 느낀다.
파트 리더는 ‘문화를 같이 잘 만들어 가는 것과 없는 곳에서 문화를 만드는 것은 다르다’고 ‘문화에 적응하는 사람이 있고 이끄는 사람이 있다. 이끌길 바란다’며 문화가 없는 곳에서 만들 수 있는 경험은 값진 경험이라고 하시며 나를 보냈다.
처음 팀에 와서 팀 문화를 보곤 조금은 착잡했는데 한 해를 돌아보면 나한테는 팀 문화를 리딩해보는 경험을 해보는 해가 됐던 것 같다.
리뷰 문화 만들기
처음 팀에 왔을땐 개발팀의 기본이라고 생각하는 리뷰 문화조차 제대로 되지 않아 착잡했다.
때문에 내 첫 목표는 리뷰 문화를 만드는 것이었는데 이런건 글로 정리하기 어렵지만 대강 이렇다.
- 리뷰 속도와 리뷰의 질에 대한 (수 차례의) 논의 및 회고
- 리뷰 그라운드 룰 세우기
- 운영, 개발, 문서까지 리뷰하기
의사소통 개선하기
생각보다 어떤 무언가를 한다기보단 의사소통을 개선하는데 꾸준히 노력한 것 같다.
슬랙을 통한 의사소통을 더 많이하도록 유도했고, 의사소통에 리액션을 강제?하여 슬랙 리액션을 꼭 달도록 했다.
업무 중에 small talk을 계속해서 팀 분위기도 챙기려고 했는데 사실 이건 내 스타일인 것 같기도하고.
생각보다 더 팀원들 사이의 생각이 달랐다.
더해서 ‘안전감’에 대해 회고 시간에 자주 이야기 했는데, 이런 이야기를 한 명 한 명 들어가면서 생각들을 더 잘 얘기할 수 있는 팀이 되었다. 물론 아직은 부족하지만.
스프린트
내가 올해 만든 팀 문화 중 가장 중요한거라면 스프린트를 바꾼 것 같다.
처음 우리팀은 팀 리더가 일을 나누면 각자 알아서 일을 하다가 끝나면 공유했는데, 어떤 팀원은 한 주 내내 혼자 일을 하고 리뷰를 올리기도 했다.
리더를 멤버들이 돌아가면서 하기로 정하고 스프린트 주기, 회의 방식, 문서화, 회고, 스토리 포인트 단위의 추정과 일을 쪼개고 나누는 방식들을 도입했다. 물론 하나씩 차근차근.
개발보다 문화를 바꾸는게 더 어렵다는 생각도 드는데, 내가 답답하게 일할 수 없다보니 방식을 하나씩 바꾸게 됐다.
내가 실질적으로 팀을 이끄는 리더는 아니면서 문화는 내가 바꿔가야 했기 때문에 내 생각보다 더디게 진행되긴 했는데, 우리 팀 리더는 팀 문화에 대한 제안을 드리면 ‘뭐든지 okay’로 답을 주셔서 좋았다.
주변에서 나와 비슷한 상황에서 ‘뭐든지 현재대로’를 원하시는 리더로 고생하는 분도 보았기 때문에 리더가 중요하다는 것을 다시 느꼈다.
팀 문화를 바꾸면서 느낀건 생각보다 ‘좋은 팀’을 만드는데는 시간이 제법 걸린다는 것이다.
내가 시도한 많은 것들이 우리 팀을 더 좋게 만들었지만, 아직 내가 원하는 좋은 팀이 되기까지 가야할 길은 좀 남은 것 같다.
새로운 서비스
팀을 옮긴게 처음은 아니지만 동기화 서버 개발자로 구르다가 백업 서버를 담당하게 되었다.
이직을 생각해볼 때 ‘내가 팀을 옮기게 되면 업무를 따라가는데 얼마나 걸릴까?’라는 생각을 종종 했었다.
연간 회고를 준비하면서 최근 설계를 떠올려보면 질문을 하기보단 대부분 설명을 해주고 있는 모습을 볼 때 ‘내가 생각보다 깊이있게 프로젝트를 이해하는데 시간이 오래걸리지 않는구나’를 느꼈다.
동기화 서버에서 백업 서버를 맡게되면서 했던 사내 부검과 회고 내용 중 하나는 ‘나는 동기화 서버 개발에 있어서는 프로였다’라는 말이었는데, 이제는 내 도메인이 동기화에서 백업까지 확장된 것 같다.
백업이랑 동기화는 비슷하면서도 다른 정책들이 있었는데, 이건 나중에 백업 서비스를 회고하면서 적어봐야겠다.
아쉬운 점은 백업이 아닌 gRPC를 비롯한 내가 사용해보지 않은 기술들을 사용하는 새로운 서비스를 경험해보고 싶었는데, 백업 서비스의 요구사항이 많아서 다른 서비스를 하지 못했다.
리팩토링
리팩토링이야 매일같이 하는거지만 올해는 리팩토링에 대해 다시 생각해봤다.
새로 맡은 서비스는 워낙 레거시 코드가 많아서 손댈 부분이 많았는데, 각잡고 리팩토링을 한 시간도 많았지만 기존 코드를 손대는 모든 작업에서 리팩토링을 꼭 했던 것 같다.
대규모 리팩토링은 이전 팀에서 너무 많이 해서 나한텐 재미없는 작업으로 느껴졌다.
파트 리더께서 조금 더 리팩토링에 대해 탄탄하게 정리해보자는 코멘트를 주셨고 리팩토링에 대한 생각들을 정리할 수 있는 시간들이 된 것 같다.
복합 리팩토링
피쳐 개발에 맞춰 code smell을 해결하는 리팩토링이 아니라 프로젝트의 넓은 범위에 영향을 미치는 리팩토링에 대해 마틴 파울러는 ‘복합 리팩토링(big refactoring)’이라는 표현을 사용한다.
리팩토링은 대부분이 리팩토링의 기법들에 대한 내용들이어서 기법이 아니라 복합 리팩토링에서 해야할 작업들에 대한 생각을 정리했다.
다양한 종류의 사용하지 않는 코드 제거에도 시간을 쓰고 이런 종류의 코드도 제거가 되어야 좋다는 생각을 할 수 있었다.
비용을 고려한 리팩토링
복합 리팩토링을 하면서는 키 설계나 메세지 전달 방식까지 다시 설계하게 되기도 한다.
올해는 내가 이런 설계에서 비용을 고려해보기 시작했다는 점에서 새롭다.
하루 수십억 단위의 api call 규모의 서비스를 담당하다보니, 모듈 사이에 SQS를 놓을까를 고민하다가 비용을 계산하니 SQS 추가 하나만으로 연간 억 단위가 되어 설계를 변경하기도 했고, 다른 팀원이 제안한 아이디어에 대해 반대하기 위한 근거 중 하나로 아이디어 적용시 추가되는 수십억 단위의 S3 비용을 계산해서 제시하기도 했다.
이전에도 비용을 고려하긴 했으나 자연스럽게 비용을 근거로 설계를 제시하고 반대했던 모습들을 떠올리면 내가 리팩토링과 설계에 있어서 조금 더 성장했나 하는 생각이 든다.
MSA
feature를 바쁘게 추가하면서 진행해온 작업들을 돌아봤을 때, 거대한 모놀리스인 우리 서비스를 조금이나마 분리할 수 있는 기회들을 내가 놓쳤다는 생각을 했다.
한 선배와 MSA에 대해 이야기 했는데 한 해를 돌아봤을 때 ‘아 이거 MSA’면 좋았을텐데 싶은 생각들이 드는 것들이 있다. 특히나 하반기에 읽은 마이크로 서비스 도입 이렇게 한다를 생각해봤을 때 점진적으로 MSA로 갔으면 좋았을텐데 하는 후회가 든다.
지금 팀에선 설계를 내가 많이 맡고 있는데, 내가 연초에 MSA의 장점과 모놀리스에서 MSA로 전환하는 방식들에 대해 제대로 이해하지 못했기 때문에 이런 설계를 내지 못했다는 생각이 들어 아쉽다.
연사
올해 기회가 되어 슬랙 자동화 봇을 주제로 두 차례의 연사로 설 수 있었다.
재밌고 새로운 경험들을 해볼 수 있는 시간이어서 좋았고, 이런 기회들을 더 잘 만들어갈 수 있었으면 좋겠다는 생각이 든다.
올해는 리더에 대해서 생각해볼 시간들이 많았다.
팀을 재배치하고 면담을 통해 동기부여를 하는 파트리더의 역할에 대해서 먼저 생각했고.
이전 팀 리더, 현재 팀 리더와 다른 팀 리더의 태도들로 만들어지는 팀의 분위기를 내가 더 잘 볼 수 있는 위치가 된 것 같다.
그리고 팀 문화와 회의, 설계를 주도하다보니 리더의 모습에 대해서도 더 생각하게 됐다.
새로운 경험들을 많이 하게된 해였다.
두 차례의 연사 경험, 새로운 팀으로 옮겨와서 맡게된 새로운 역할들.
기대한 새로운 기술들에 대한 개발 경험을 갖지 못한게 아쉽지만 새로운 역할들을 잘 소화해낸 것 같다.
작은 팀이지만 팀 문화와 설계를 주도하는 자리에서 일을 해본게 재밌었다. 생각보다 잘 맞는 것 같기도 하고.