우여곡절 끝에 회사에서 운영중인 숏폼 영상 광고 제작 플랫폼을 리뉴얼하여 출시하게 되었습니다.
리뉴얼 전, 한 파일에 천 줄이 넘는 코드와 독창적이고 파괴적인 코딩 스타일을 보고 경악을 금치 못했습니다.
처음 업무를 배정받고 이슈 하나를 해결할 때 마다 사막에서 바늘을 찾는 느낌이었습니다.
이 때 처음으로 방 청소 방 정리는 안 해도 코드 정리는 꼭 해야한다는 생각이 들었습니다. 또한 코드의 "규칙"에 필요성에 대해서 다시금 생각하게 되었습니다.
리뉴얼 전 프로젝트의 문제점
우선 이 프로젝트의 문제점에 대해서 정리해보기 시작했습니다.
-
일관성 없는 코드스타일 및 미사용 코드 잔재와 중복 코드
-
길다... 컴포넌트 하나가 길어도 너무 길다 레거시한 코드들이 있어 문제를 파악하는데 시간이 너무 오래걸렸다.
-
독창적인 구현으로 인한 성능 이슈, 랜더가 너무 오래걸렸다.
위 3가지 이슈들은 인지는했지만 출시 일정을 고려해본 결과 우선 순위가 밀려 출시가 완료된 현재 최적화 및 정리를하고 있다.
돌이켜보는 나의 업무
어딘가에 적지 않으면 내가 이 프로젝트에서 어떤 부분을 담당했는지 나중에 알기가 힘들 것 같아 기억을 더듬어보며 인상적이었던 것들 위주로 나열해보자면
비디오 편집 화면 crossbrowsing
언뜻보면 크로스 브라우징이 왜 인상적이었을까? 라고 생각할 수 있지만 실로 인상적이지 않을 수가 없었다.
이력서에 자신있게 "반응형 됩니다!" 라고 썼던 내 자신이 민망할 정도였다.
기존에 앱으로 해당 기능이 제공되고 있었는데 앱에서 모든 것으로 웹으로 변경하여 리뉴얼하기로 결정이 되어 반응형 작업을 시작하기 시작했는데....
기존 반응형은 나에게
엥? 그냥 width로 분기 나눠서 적당히 끼워 넣으면 되는거 아니야?
라고 생각했었으나
문제는 이 녀석이었으니..
이 악랄한 나침반 녀석은 사춘기인지 하루가 다르게 몸의 변화가 생기는데..
IOS 14, IOS 15, IOS 16 별로 이슈가 달랐고 Chrome과 다르게 돌아가는 부분들도 너무 많아서 엄청난 고생을하게 되었다.
또한 요구사항중에
한 화면에 다 들어왔으면 좋겠다.
가 있었으나 이는 기존 디자인으로는 실로 어려웠던 것이 iphone 7,8 이하의 사이즈가 height가 너무나 작아 낑겨넣으면 아예 사진이 너무 작게 보이는 등의 이슈가 있어 이를 조절하는 것이 힘들었다.
결국 width뿐만 아니라 height도 신경써야하고 safari 버전별로 주소창이 차지하는 영역의 이슈가 있어 신경써야하며 chrome safari 둘 다 문제가 없나 체크하는 기간이 너무나 길었다.
린트 세팅
린트론자가 된 나로서 가장 뿌듯하고 자랑하고 싶은 업무중에 하나였다.
기존에 lintrc 파일이 있었으나 버전도 너무 낡고 제대로 동작도 하지 않고 있어서 새롭게 Plugin들과 rule들을 다시 짜주었고 import/order도 일관될 수 있게 새롭게 짜주었다.
airbnb rule들을 다 키면 난리가 나기 때문에 크리티컬한 rule들부터 하나씩 켜 나가는 중이다. 특히 deps, no circle과 같은 룰들은 수정하는데 꽤나 긴 시간이 걸리기때문에 일단은 기본적인 것들 수정에 힘쓰고 있다.
Git actions 문제 해결
배포직전에 해결하려 했다면 아찔했던 문제로 git actions가 반년 넘게 돌고 있지 않았다. dependency install 과정에서 이상하게 계속 오류가 났었고 히스토리를 들어보니 기존 코드 병합 과정에서 충돌이 났던 것 같다. yarn 캐시도 밀고 이것저것 세팅해서 우여곡절 끝에 다시 actions를 돌리는데 이 점은 정말 미리 해결하길 잘했다고 생각했다.
초록불이 켜졌을 때의 쾌감은 말로 표현할 수 없다....
그 외에도 무한스크롤, 필터, lottie 등등 다양한 것들을 맡아서 했지만 역시 위에 3가지가 가장 기억에 남았다.
새롭게 배운점들
마찬가지로 개발뿐만 아니라 협업, 소통을 포함해서 너무나 많은 것들을 느끼고 배웠지만 기술과 그 외로 몇 가지만 추려서 나열해보자면
기술
데이터독을 통한 트러블 슈팅
서버 터지면 멍멍이 체했다고 노티오는게 너무 귀여웠던...
사내에서는 데이터독 사용을 적극적으로 도입하고 권장했으며 RUM 수집, 지표 관리를 위해서 도입했고
신기해서 적극적으로 공부해본 결과 병목 현상이나 로깅 react나 redux등 다양한 integrations를 통해 프론트에도 도움이 되는 부분들이 많았고
사용해본 소감은 다양한 서비스들에서 제공하는 것들을 한 군데에서 통합적으로 볼 수 있다는 장점이 있었고 replay 기능이 정말 편하고 강력했다. 모바일로 테스팅을 진행하다 오류가 생겼고 해당 오류에 대한 내용을 구구절절 텍스트로 받아보는 것보다 리플레이 돌려보고 무슨 상황인지 인지하는 것이 훨씬 도움이 되었다.
100퍼센트 활용하고 있지는 못한다고 생각되는게 replay 세션에서 에러 로깅이 생각보다 디테일하게 나오지 않고 핵심적이거나 오류 발생이 잦은 곳에서 로그를 직접 다는 등의 개선이 필요하다고 느끼고 있다. 또한 상품 상세정보 페이지의 주소가 ? 로 나오니 route 커스텀도 진행해야 하는 부분이다.
전역관리에 대한 생각
해당 프로젝트는 생각보다 전역 상태 관리의 필요성이 적었다. 대부분의 버튼들에 api call이 담겨져있고 react query의 이용으로 더욱 효율적으로 관리할 수 있게 되었고 state는 해당 페이지에서만 사용되는 것들이 대부분이었다. 이 정도 규모라면 recoil과 같은 상태관리 툴들이 간편하게 빠르게 개발할 수 있겠다라는 생각을 했다.
react query의 기능들은 역시나 강력했고 많은 개발자들을 편하게 만들어 주는 훌륭한 도구로서의 역할을 수행했다.
동영상에 대한 공부
만들어져있던 기존 동영상 crop 모듈의 코드에 오류가 있어 손 볼 일이 생겼는데 처음엔 굉장히 난감했다. 지금까지 static한 영상이나 주소로 동영상을 Play시키기만 했지
동영상 file을 blob으로 받아 모바일 영상 코덱을 변환해야 했기 때문에 ffmpeg을 이용했는데
지금까지 해당 작업을 할 일이 없었기 때문이다.
우선 정보를 얻는데 많은 시간을 쏟아야했다. 오래된 라이브러리이기에 오래된 정보들도 많았다. 또한 video에 대한 지식이 없었던 터라 좀 더 깊게 공부할 필요가 있었다. 사용 방식도 특이했다. command를 스트링과 띄어쓰기로 넣어주어야했고 옵션들도 너무 다양하고 많아서 우리 프로젝트에 적합한 command를 설정하는 부분도 많은 공부가 되었다.
협업, 소통 그리고..
개인적인 생각이고 물론 어디든 안 중요하겠냐 싶지만 소통 능력, 협업 능력은 회사 규모가 작을수록 "프론트엔드" 개발자에게는 특히나 더욱 요구되는 사항이라고 생각한다.
그 이유는 규모가 큰 회사라면 다양한 직군들이 있는 만큼 각 직군들에게 소량의 정보만 전달하면 되는데 작은 회사는 한 사람에게 전달해야하는 정보의 양이 정말 많고
특히 이를 텍스트나 사진만으로 전달하다보면 의도 파악이 힘들 때가 많았다. 구두로 전달하는 것이 가장 좋지만 일을 하다 중간중간 구두로 전달하게 되면 서로 일의 흐름에 지장이 갈 수 있기 때문에 협업툴을 적극 사용하게 되었다.
내가 편하려고 적극적으로 flow를 만들어 나갔고
아사나를 활용해 비동기적으로 편하게 소통하는 것을 목표로 했다.
결과, 백로그에 팀별로 번호를 부여했고 팀 내부에서는 모르겠으나 개인적으로 비동기가 되니 소통의 양이 증가하고 기록으로 남아 까먹을 일이 적었으며 해결해야 할 일들의 우선순위를 정하기 편했다.
개선하고 나아가야 할 방향
너무너무너무 개선할 부분들이 많고 아쉬움이 남은채로 출시했기 때문에 앞으로는 최적화에 치중하려 한다. 가독성이 떨어지는 코드들은 컴포넌트 분리, 기존에 잘못쓰여지거나 비효율적으로 쓰여진 useEffect들을 하나씩 보면서 개선하고 비디오가 많아 무거운 메인화면도 링크 방식등으로의 변환을 고려하고 있으며 이미지 최적화도 진행해야하는 부분이다. 스타일의 공통화와 시맨틱하게 쓰여져있지 않은 코드들도 수정해서 결과적으로 추구하는 목표는 로딩타임 개선 및 빠른 동작 수행이다.
