드디어 가장 바쁜 25년 정기신고 기간이 끝나게 되었다. 정말 감정적으로 체력적으로 다양한 오르내림이 있었던 한달로 글을 작성하는 6월 3일 아침 마무리되었다. 다이나믹했던 5월에 정리해보자.
😂 길고 길었던 5월의 작업들
5월의 작업량을 보면 가히 평월의 2배~3배로 진행되었던 것 같다. 작업양은 깃헙 잔디만 봐도 느껴질 수 있었는데 4월 말부터 5월의 하루 커밋양을 보면 하루 최대 60개에 달할 정도의 작업이 있었다.

매일매일 회의를 통해 액션아이템을 결정하고 그에 따라 팀의 작업방향이 수시로 바뀌기도 했고, 5월에만 가능한 정기신고이다보니 미리 준비는 했지만 놓쳤던 부분을 보완하거나 24년을 위해 특별히 추가된 공제를 지원하는 등의 작업이 필요했다.
특히 결혼공제의 경우 유저의 오입력을 막기 위해서 수정을 4차까지 진행해 사일로에서 진행했던 여타 실험보다 더 빠르게 결정하고 수정하는 작업을 진행했다. 유저의 입력을 직접 받을 수 밖에 없는 공제 내용이었고 24년 혼인신고를 한 경우에만 공제를 받을 수 있다보니 24년에 결혼을 했는지, 24년에 결혼한 상태인지로 잘못 인지하고 예로 답할 경우 공제금액이 달라지기 때문에 정말 빠르게 대응이 필요했다.
이외에도 5월에 새롭게 진행된 작업들로 선정산/후결제
, 납부 지원
작업 등 다양한 기능도 빠르게 개발이 필요했다. 매일 몰려오는 CS들과 큰 작업들로 인해 5월 초반과 중반 그리고 후반의 업무 집중도와 텐션이 점점 고갈되어감을 느꼈고 혼자 책임감으로 끙끙 앓다가 업무 중 감정적으로 대하는 모습들을 팀원들에게 보이기도 했다.
팀원분들은 "흑화했다"라고 귀엽게(?) 표현해주셨지만 해당 경험을 통해서 혼자서 감당이 안되면 팀원분들께 더 적극적으로 도움을 요청하는 것의 중요성을 크게 느끼게 되었다. 혼자서 고민하기보다 일정을 조율하거나 작업 방식을 변경하는 등의 다양한 방식이 있었을텐데, 주어진 걸 기한 내에 마무리 해야한다는 것에 너무 많은 책임감을 느꼈던 걸까, 못한다고 말하면 나의 부족함을 보이는 것이라 생각해서였을까 오히려 좋지 않은 의사소통 방식으로 진행하게 되었던 것 같다.
정말 일이 많고 힘들 때 나의 모습이 어떤지 보게 되었고 더 좋은 의사소통에 대해 고민하게 된 시간들이었다. 개인적인 우여곡절이 많았지만 정말 다행히도 팀 전체가 열심히 달려온 5월, 정말 기쁘게 전사 목표를 달성할 수 있었다.
SSR 적용과 개별 도메인 지원을 통한 개발 생산성 향상시키기
4월부터 준비해온 SSR 도입 작업을 5월 중순에 드디어 라이브에 적용하게 되었다. 해당 작업을 시작하면서 목표는 LCP 개선
과 SSR 배포 파이프라인을 세팅하면서 지원가능하게된 작업자별 개별 개발 도메인 지원
이었다.
SSR 작업은 기존 서비스는 유지하면서 렌더링 방식을 변경하기 위해서 모노레포 구조로 진행되어 CSR용 폴더를 스캐폴딩해 SSR 폴더로 옮긴다음에 SSR을 적용하는 방식으로 진행하게 되었다.
이과정에서 코어 환경에서 이미 잘 구축되어있는 SSR 관련 코드들을 전체적으로 분석하고 인컴 환경에 맞게 수정해 전체적인 SSR에 대한 지식을 높일 수 있었다. 특히 잃어버린 유저의 시간을 찾아서 : 100년을 아껴준 SSR 이야기 영상과 마이그레이션 가이드 문서를 보면서 많은 것을 배울 수 있었던 시간이었다.
현재 적용한 화면은 가장 초기화면인 index화면이지만 해당 화면에 SSR을 적용하기 위해서 어떻게 인증과정을 수정할지, react query와의 의존성은 어떻게 관리할지, 디자인 시스템인 TDS와의 연동은 어떻게 할지, 중간에 로그가 누락되는 문제는 어떻게 해결할지 등 정말 다양한 이슈와 고민들을 거쳐서 1차본을 완성해 적용하게 되었다.
아직 전체 페이지에 편하게 적용할 수 있는 상황이라 조금 더 개선이 필요해 6월부터 확장해나가려한다.
작업 과정에서 CSR과 SSR 두가지 폴더에 쪼개져있다보니 하나의 기능을 위해 각각에 작업해야하는 프론트 개발자의 비용과 두배로 테스트해야했던 QA팀의 배려가 있었고 덕분에 안전하게 배포될 수 있었다.
5월이라는 큰 이벤트가 있는 시기에 SSR이라는 큰 기술적 변화를 하는데에 많은 압박감이 있었지만 팀이 필요하다고 공감 해주셨던 문제점은 단순히 로딩시간 개선보다는 팀의 생산성
개선에 있었다.
SSR으로 마이그레이션 전까지 개발과정은 여러명의 개발자가 하나의 개발 도메인을 사용하고 테스트를 하고 있어 QA를 위해서 점유가 필요한 상황이었다. 이과정에서 라이브 액티비티와 같은 네이티브 기능이 필요한 경우에 실기기에서 봐야하기 때문에 큰 병목이 되고 있었고, QA 과정에서 자동으로 다른 분의 작업이 병합되면서 github 액션이 돌경우 갑자기 이전에 했던 QA 이슈들이 되살아나서 혼란스러운 상황이 계속해서 있어왔다.
SSR 덕분에 해결된 것은 아니지만 SSR을 도입하면서 배포 파이프라인을 새롭게 구축하게 되었고 이과정에 플랫폼 개발자분의 지원을 통해 개발자별 개별 도메인을 개발 환경에서 사용할 수 있게 변경되어 기존의 개발과정에서의 문제점을 해결해 개발 생산성을 크게 끌어올릴 수 있었다. 개발자는 편하게 실기기에서도 테스트를 할 수 있는 환경이, QA분들도 해당 개발작업만 보실 수 있는 큰 장점으로 인플로우와 퍼널 작업 크고 작은 실험이 빠르게 배포되는데 크게 기여할 수 있었다.
과정에서 아쉬웠던 점은 제품 개선 측면에 대한 분석이 어려웠던 점이다. 팀의 비용을 고려해 하루에 점진 배포로 100프로까지 올려버려 SSR 도입을 통해 유저 전환율과 같은 제품 기여도에 대해 측정하지 못했다. 이후 SSR을 확장할 때는 실험을 통해 실제 유저에게 로딩속도가 얼마나 중요한지 볼 수 있게 준비해보려 한다.
5월 이후 남은 과제들
5월에 다양한 작업들을 빠르게 진행하면서 정리되지 못하고 남아있는 코드들과 맥락들이 많아지게 되었다. 이와함께 혼자 고맥락의 제품을 개발하면서 높아진 버스지수에 대한 고민이 이어지게 되었다. 서로가 백업을 해줄 수 있고 인컴 프론트 개발자 모두가 심리적 안정감을 갖고 일할 수 있게 하기 위한 시간이 필요하다고 생각이 자연스레 들었다.
이를 위해서 6월에는 꼭 코드 정리와 함께 맥락 다운로드 등을 위한 작업들이 필요하다고 생각해 대표이신 일용님과 팀에 건의드렸고 팀에서도 공감을 받을 수 있었다. 또한 나뿐 아니라 서버 개발자분들도, QA 팀에서도 필요성을 느끼고 있어 함께 정비하는 시간을 갖기로 정해지게 되었다.
6월은 현재 프로젝트 코드 구조나 설계 방식 등 나만 알고 있는 맥락을 최대한 다운로드 드리고, 기존 서비스 내 문제점들을 발굴하고 수정해 나가려 한다.
돌아보는 5월의 액션아이템
4월회고에 작성했던 5월의 액션아이템들은 모두 수행했다.
- 5월에 빠르게 팀 업무 지원하기
- 5월을 겪으며 개선해야할 부분 정리하고 챙기기
- SSR로 라이브 성공하기
6월은 액션아이템으로 2학기를 위해 더 빠르게 성장하기 위한 준비할 예정이라 아래와 같이 액션아이템을 세워보려 한다.
- [] 프론트 코드 정리 및 히스토리 문서화하기
- [] CSR페이지 SSR로 마이그레이션하기
정말 다사다난했던 5월을 보내며 6월은 2학기와 내년 5월을 더 잘 준비하기 위한 기반을 잘 갖추고, 이번 5월의 경험을 통해 더 좋은 개발자, 더 좋은 동료가 되길 바라본다.