개요
회사에 입사하게 되고, 2주간은 회사 코드를 읽어보고
주로 서비스에 적응하는 시간를 가졌다.
특히나 앞으로 백엔드 작업도 함께 하게 될 것이라는 말씀을 듣고,
회사에서 백엔드 프레임워크로 NestJS를 채택하고 있어
공식문서를 통해 읽어보고 회사코드와 대조하며 공부해보고
1차 스프린트에 들어가게 되면, 면접 때 하고 싶은 업무로 말했던
이미지 최적화에 들어가게 될 것이라고 CTO님께서 미리 말씀해주셔서,
관련 데이터 구조 파악과 해결방안에 대해 생각하는 시간도 가졌다.
본격적으로 1차 스프린트에서는 피드 이미지 크기 최적화 업무를 맡아 작업하고,
작업하면서 발견했던 버그들을 해결하는 업무를 하게 됐다.
그리고 데일리 스크럼에서 CTO님께서 새로운 프로젝트를 세팅해야 한다고 하셔서,
직접 해보고 싶다고 하여 해당 업무 또한 맡게 되었다.
1차 스프린트 기간: 24.07.08 ~ 24.07.19 (10일)
업무
피드 이미지 크기 최적화
피드 이미지 크기를 최적화하는데 고려했던 방안들은 아래와 같았다.
- 이미지 리사이징
- 이미지 확장자 변환
- 이미지 스켈레톤 적용
이미지 리사이징과 확장자 변환은
백엔드 단에서 sharp라이브러리를 통해 진행하고자 했다.
하지만 이미 회사코드에 프론트 단에서 utils 함수로
canvas를 이용하여 리사이징을 진행하는 코드가 있었다.
데이터 가공은 백엔드 단에서 하는 것이 일반적이라고 생각이 되어 해당 이유를 여쭤보자,
AWS 청구서를 함께 보여주시면서 비용과 부하의 책임에 대해 말씀해주셨다.
그동안에는 유저의 부하만 생각하여 부하가 최대한 가지 않도록 하여
유저에게 최고의 UX를 주는 것이 Best라고 생각했다.
하지만 현실에서는 다양한 관점에서 문제를 바라봐야 하기 때문에
해결책을 1가지에 국한하지만말고 열린 생각을 가져야겠다고 느끼는 계기가 되었다.
터득한 Point.
- 좋은 라이브러리 코드 많이 읽어보기
- 최소한의 시간으로 최적의 코드 구현 (시간 >>>>> 퀄리티 높은 코드)
- 현재에 상황에 맞는 해결방법을 채택하기 위한, 다양한 해결책 구상과 넓은 시야
- 공통 컴포넌트로 뺄 수 있는 컴포넌트 === (다양한 곳에서 쓰이는지 >> 분리할 수 있는 컴포넌트)
신규 프론트엔드 프로젝트 세팅
이전에 맡았던 팀 프로젝트에서 프로젝트를 세팅한 경험이 여럿 있었는데,
회사에서의 프로젝트 세팅은 또 하나의 좋은 경험이 될 것 같아,
자원하여 해당 업무를 맡게 되었다.
프로젝트를 세팅하며 기술 선택에 있어 CTO님과 계속해서 얘기하며
지속적인 업데이트 여부, 러닝 커브, 생태계, 기술의 효용성에 대해,
종합적으로 생각해보는 좋은 시간이었다.
이후 프로젝트를 세팅하고, S3와 CloudFront, Route53을 이용하여 개발 서버를 배포하고,
GitHub Action으로 CI/CD를 구축하는 작업을 진행했다.
이전에 외주 작업을 하며 CI/CD를 구축해본 경험이 있어 어렵지 않았는데,
나름대로 캐싱도 적용하여 구축해 한 번에 통과했다🙌
예상외로 발목을 잡은 것은 eslint 설정이었다.
eslint가 9.x 버전으로 올라가면서 eslint config 설정을
eslintrc.js에서 eslint.config.js로 무조건 작성하도록 바뀜에 따라,
새롭게 eslint config 방법에 대해 공부했다.
아직 이에 대한 자료들이 많지 않아,
공식문서를 읽어가며 하나하나 적용해보고 테스트해보며 시간을 많이 사용했다.
이에 대해 포스팅도 작성하여 미래의 스스로에게도, 설정에 애를 먹는 다른 사람도 읽어볼 수 있도록 해야겠다.
시간이 가면 갈수록 포스팅하고 싶은 글들이 점점 불어나는 느낌...
터득한 Point.
- 기술 채택에 있어 정답은 없고, 현재 상황을 근거로 종합적으로 판단하여 선택
- yarn-berry zero-install의 도입 배경
- 웹사이트 배포 과정 재정립 및 CI/CD 구축 재정립
- eslint config 설정
기타 오류 수정
회사 서비스에 적응하고자 서비스의 이곳 저곳을 탐방하다가 몇가지 오류들을 찾아냈다.
아직은 바로 오류를 수정하고자하면 안될 것 같아,
해당 오류가 있었던 코드상 이유와 해결방법 정도만 찾아 지라에 티켓으로 만들어놨다.
이미지 최적화를 마친 뒤에, 찾은 오류를 직접 수정해보고 싶다고 말씀을 드린 후
수정을 진행했는데 마침내 서비스에 첫 기여를 한 순간이 된 것 같아 매우 뿌듯했다.
그러다 이미지를 불러올 때, cdnImageUrl 함수를 통해 이미지 주소에 cdn 주소를 붙이고 있었다.
애초에 이미지 주소를 내려줄 때, cdn 주소를 붙인 주소를 저장하지 않는 여부가 궁금해 여쭤봤다.
그 이유는 이미지를 저장하고 있는 클라우드 서비스를 이전했을 경우에,
cdn 주소를 붙인 상태로 저장하고 있다면 DB 전체를 마이그레이션 해야하는데,
그것이 아니라, cdn주소를 함수를 통해 붙여주게 되면
cdn 주소를 붙여주는 함수만 바꿔주면 해결된다는 것이었다.
그리고 실제로 이번에 클라우디너리에서 AWS S3로 이미지 파일들을 이동하는 일이 있었는데,
이미지를 옮긴 뒤에, 해당 함수만 변경해주니 이미지 이전 작업이 끝이 났었다.
이런 경험의 지혜를 최대한 많이 배워가고 싶다.
터득한 Point.
- 이미지를 담고 있는 주소의 경우 확장성을 고려하여, DB에 저장되는 주소를 선택한다.
- 아직 스스로 많이 부족하다. 경험을 많이 쌓아나가자!!
