2022년 상반기 회고

 

 

벌써 8월이 가까워지고 있다.

원래 6월 말쯤에 상반기에 대한 회고를 작성해 보려고 했는데, 리프레시 겸 제주도 여행도 다녀오고 이것저것 밀린 일들을 하느라 벌써 상빈기 회고를 작성하기가 애매한 시기가 되었다.

그래도 6개월이란 시간 동안 정말 많은 일을 했고 내 스스로 많은 성장 과정을 한번 더 겪을 수 있었던 기간이었던 만큼, 늦게나마 회고는 작성해야겠다는 생각이 들었다.

작년 하반기에 이어 상반기까지 쭉 기술적인 부분들도 계속 성장할 수 있었지만, 무엇보다 소프트 스킬과 팀워크, 그리고 팀 문화에 대해 많은 것은 배우고 깨달을 수 있었던 기간이었던 것 같다.

나와 우리팀이 상반기 동안 지속적인 성장을 위해 활동했던 내용들을 아래에 큰 단위로 한번 정리해 보려고 한다.

 

모노레포 시스템 구축

작년 하반기부터 쭉 진행해온 모노레포를 구축하는 과정을 통해 스스로 기술적인 성장을 크게 느낄 수 있었다.
프론트엔드 팀이 모노레포를 안정적으로 사용하는 단계까지 오면서 모노레포 레이드 활동을 마칠 수 있었고, 이에 대한 콴다 팀 블로그 글과 개인회고까지 작성했다.

모노레포 시스템 구축 과정은 정말 힘들었지만 기술적으로 엄청난 성장을 할 수 있는 과정이었고, 해당 업무를 메인으로 맡게 된 것은 내게 정말 큰 행운이었다.

 

코드리뷰 문화

상반기에 우리 팀의 빠르고 안정적인 작업을 반영하기 위해 코드리뷰 문화에 대해서도 많은 신경을 썼다. 
이전에는 코드리뷰 문화라고 하면, 단순하게 코드리뷰를 하고 작업을 반영을 하는지에 대한 정도로만 생각을 하고 있었는데, "코드리뷰 문화"에 대해 알아보면서 "좋은 코드리뷰 문화를 제대로 갖추는 것"은 쉽지 않다는 것을 깨달을 수 있었다.

내가 속한 팀 내에서 코드리뷰를 가진다는 것.
다른 사람이 작성한 코드를 보며 나 역시 학습의 자세를 가지는 마인드를 가지는 것.
그리고 팀 퍼포먼스 면으로 원활한 리뷰를 할 수 있는 여러 가지 방법을 고민해 보는 것.

이러한 요소들을 기반으로 우리 팀에게 맞는 코드리뷰 방식을 많이 논의해 보면서, 우리만의 코드리뷰 시스템과 가이드를 작성할 수 있었던 것 같다.

나중에 기회가 된다면 코드리뷰 문화에 대한 글도 한번 작성해보려고 한다.

 

디자인 시스템

상반기에 우리 콴다 서비스 내에서 우리만의 색깔을 돋보이게 하기 위해 디자인 시스템에도 많은 공을 들였던 것 같다.
(아쉽게도 나는 많은 참여를 하진 못했지만...)

디자인 시스템이라고 하면 마냥 여러 프로젝트에서 공용으로 쓰는 컴포넌트들을 모아서 라이브러리 화 한 것이라고 생각할 수도 있다.

그러나 이를 넘어서서, 우리 서비스에 있는 UI/UX에 쓰이는 컴포넌트들의 Accessibility를 어떻게 하면 더 높일 수 있을지, 많은 프로젝트에서 사용되는 컴포넌트 시스템을 어떤 사이클을 통해 관리를 할 것이며, 이러한 디자인 시스템을 운영하기 위해 디자이너와 개발자 간의 원활한 협업을 어떻게 이루어 나갈 것인지 등 프론트엔드 단에서도 정말 많이 고려해야 할 요소가 있었다.

추가로, 여러 디자인 시스템을 리서치 해보면서 디자인 시스템이 가져다주는 철학적인 부분들도 많이 들여다볼 수 있었고, 서비스에서 사용되는 디자인 시스템에 대한 생각을 조금 더 키울 수 있는 계기가 되었던 것 같다.

 

TDD(Test Driven Development)

나는 테스트코드를 정말 정말 싫어하는 사람이었다. 
너무 재미없고 너무 지루해서 테스트코드를 짜는 것을 정말 좋아하지 않았다.

그래서 사실 TDD 문화를 팀에서 처음 얘기를 꺼냈을 때는 꽤 거부감을 느꼈던 것 같다.
그러나 TDD 문화에 대해 리서치를 하고 알게 되면서, TDD가 가져다주는 이점을 통해, 테스트코드 라는 요소를 다시 한번 생각해보는 계기가 되었던 것 같다.

TDD 방식에 맞게 이미 짜여져 있는 기능에 테스트코드를 붙이는 것이 아니라, 해당 기능을 구현하기 전에 해당 기능에 대한 여러 케이스의 테스트 코드를 미리 작성을 해놓는 것, 그리고 기능을 구현하면서 해당 테스트코드를 함께 돌려가며 구현에 문제가 없는지를 체크를 한다.

이와 같은 방식으로 테스트코드를 작성해보면서 이전에 실제로 내가 테스트코드에 지루함을 느끼던 포인트가, 이미 구현된 기능에 테스트코드를 짜 맞춰서 작성하면서 완료된 작업에 부가적인 작업을 하는 느낌을 받아서였다는 것을 깨달을 수 있었다.

그러나 기능 구현 전에 테스트코드를 작성하는 식으로 작성을 하니 테스트코드 작성이 지루하지 않았고, 기능 구현 중 결함을 빨리 확인할 수 있는 도구를 만든다 생각하니 조금 더 정교하게 테스트 코드를 작성하려고 노력하게 되는 것을 느낄 수 있었다.

단지 테스트코드를 언제 작성할지에 대한 순서를 바꿨을 뿐인데, 이렇게 테스트코드에 대한 인식이 크게 차이가 나는 것이 놀랐다.

테스트코드가 장기적인 프로젝트 관리면으로 우리에게 얼마나 큰 이점을 가져다주는지에 대해서도 깨닫게 되었고, 실제로 가끔 기능 수정이나 리펙토링 하면서 놓칠뻔한 버그를 테스트코드를 통해 몇 번 잡았던 케이스가 생기면서, 이제는 테스트코드를 습관화하기 위해 항상 PR마다 테스트코드를 함께 추가할 것이 없는지 생각하게 되는 것 같다.

 

TBD(Trunked Base Development) 문화

이전에 한번 TBD 전략 블로그 글을 작성한 적이 있었다.
모노레포로 이전하면서 기존의 Github Flow 전략보다는 우리 모노레포 환경에서 조금 더 어울릴 전략을 찾다가 TBD를 알게 되면서 해당 전략에 대해 많은 리서치를 해보고 팀 문화에 적용하려고 노력했다.

"Trunk Branch 하위로 브랜치를 따서 바로 작업하고 빠르게 Merge하여 반영한다."

TBD 자체는 매우 단순하지만, 이러한 TBD 전략을 위해서 필수적인 부분들이 꽤 있다. 앞 단에서 얘기한 TDD와 코드리뷰 역시 TBD 전략을 위해 필요한 요소들인 것처럼, 어쩌면 TBD 전략은 현재 우리에게 아주 맞는 방식이라고 감히 얘기해볼 수 있을 것 같다.

그만큼 나는 'TBD를 전략'이란 말보단 'TBD 문화'라는 말을 쓰고 싶다.

 

애자일 사고방식

우리 팀 모두가 애자일에 대해 알아보고 공부해보며, 애자일에 대한 사고방식을 넓힐 수 있었던 것 같다. 
이전에는 애자일이라고 하면 그냥 하나의 방법론이라고 생각했는데, 애자일에 대해 알아갈수록 방법론 보다는 철학에 굉장히 가깝다는 생각이 들었다. 

'빠른 피드백'을 기반으로, 우리가 어떻게 하면 개인이나 팀적으로나 현재의 문제점을 인식하고 개선점을 찾아내서 더욱 큰 퍼포먼스를 낼 수 있을지, 어떻게 하면 역량을 더 높일 수 있을지에 대한 생각을 가지는 것이 애자일을 위한 가장 기본적인 자세이다.

어쩐지 초반에 알면 알수록 정말 두루뭉실하고 추상적이고 구체적이지 않다고 생각을 했었는데, 애자일은 정해진 방식이 없다.
현재의 나와 우리 팀의 색깔에 맞는 개선 시스템을 직접 찾고, 그것을 찾기 위해 우리가 어떤 마인드를 가지고 습관화를 시켜야 하는지를 깨닫는 것이 애자일의 핵심 포인트라는 것을 알게 되었다. 

더 나아가, 애자일은 업무 뿐 아니라 우리 일상과 삶에서도 많이 고민해보면 좋을만한 사고방식이라는 생각도 들어, 나는 애자일을 철학이라 부르고 싶다.

 

---

 

이번 상반기를 정리하면, 빠르게 성장하는 우리 팀이 모노레포 환경 위에서, TDD, 코드리뷰, 디자인시스템이란 활동을 기반으로 TBD 문화를 구축하여 우리 팀이 '함께 자라기' 위한 애자일 문화를 갖추기 위한 활동을 했다고 할 수 있겠다.

굉장히 바빴지만 그만큼 바쁘면서 큰 성과도 거둘 수 있었던 것 같고, 무엇보다 업무적인 면을 넘어서서 '나'라는 사람에 대해서도 많은 성장을 한 것 같다. (딱 6개월의 기간이었는데, 6개월 전과 후인 나의 모습이 확실히 비교가 되는 것 같다.)

 

정말 즐거웠던 6개월이었다.
올해 남은 하반기도 화이팅 해보자!