본문 바로가기

카테고리 없음

도매 사업자 서비스 개발 과정

입사 전 회사에선 대규모 업데이트(v1 -> v2)가 진행되고 있었다.

회사의 프로젝트는 총 3가지로 구성된다.

1. 터틀체인

2. 백오피스

3. 도매 사업자

이 중에서 도매 사업자의 변경 과정에 대해서 겪었던 경험을 작성하려 한다. 몇 가지 이유에 의해 기존의 v1버전을 유지하지 않고 새롭게 만들기로 결정했는데 다음과 같다.

처음부터 새롭게 설계를 고려하게 된 이유.

1. api 재설계

 팀에 합류 전 전체적인 api 재설계가 이루어져 있었다. 그에 따라 도매 사업자 내에서 사용하던 api도 수정사항이 발생했는데, 확인한 결과 수정사항이 발생한 api가 90% 이상이었다. 사실상 도매 사업자에 대한 전체적인 내부코드를 수정해야 함을 의미했다.

2. 클래스형 컴포넌트

 또한 컴포넌트를 구성하는 방식이 클래스형으로 구성되어 있었다. 나 자신이 함수형 컴포넌트에 익숙했던 점, 다른 프로젝트(터틀체인, 백오피스) 또한 함수형 컴포넌트로 구성되어 있던 점을 고려해 보면 함수형 컴포넌트로 통일하고자 하는 생각이 들었다. 

3. 리덕스를 통한 상태관리

이것도 2번과 마찬가지로 개인적으로 익숙했던 기술스택 + 다른 프로젝트에서 사용 중을 고려해봤을 때 recoil + react-query로 통일하고자하는 생각이 들었다.

4. 사용자 측면고려

도매 사업자를 사용하는 주 사용자는 동대문상인의 매장 업주였다. 상대적으로 저사양의 휴대폰을 사용한다는 점을 고려해봤을때 렌더링의 부담을 사용자의 브라우저의 성능에 달린 CSR방식보단 우리 서버 쪽에서 부담을 하는 SSR방식을 적용하게 되면 좀 더 빠르게 첫 화면을 볼 수 있지 않을까라는 생각이 들었다.

 

여기서 4번 항목에 따라 next.js의 사용여부가 결정되었었는데 좀 더 유의미한 지표를 확인하기 위해 크롬개발자 도구의 Performance탭을 통해 렌더링 시간을 측정해 보았다. 환경과 측정방식은 다음과 같다.

1. 환경: pc가 m1임을 감안하고, 실제 상황과 비슷한 환경을 고려하기 위해 Network상태를 Fast3G로 설정하고 진행

2. 측정방식: 초기 구글 크롬에서 강력 새로고침을 통해 캐시 초기화를 진행하고 도매 사업자 접속.

 

performance탭을 통한 렌더링 시간 측정

유의미한 화면을 보기까지 약 4초가량이 걸린다. 구글에서 제공해 주는 PageSpeed Insights를 통해 web vitals도 측정해 보자.

PageSpeed insights중 LCP측정 결과

LCP도 3.7s로 비슷하게 나왔다. 구글에서 제공하길 LCP가 2.5초에서 4초 사이에는 개선을 필요로 한다고 한다.(web vitals에 대해 선 참고자료로 남겨놓겠다.) 따라서 next.js를 통한 SSR을 적용하여 페이지의 로딩속도를 개선하기로 하였다.

 

next.js도입 결과

변경후 performance탭을 통한 렌더링 시간 측정

마찬가지로 이전과 동일한 환경으로 구성하였다.

performance탭 확인결과 흰 화면이 아닌 순간이 대략 7~900ms정도로, 이전보다 빠른 렌더링 속도를 확인할 수 있다.

마찬가지로 PageSpeed Insights도 확인해 보면

PageSpeed insights중 LCP측정 결과

900ms로 비슷하게 측정되었다.

전환하면서 느낀 점.

1. 클라이언트환경과 서버환경에 대한 이해

기존에 CSR로 개발을 진행할 땐 client와 api서버만 고려하면 문제가 없었다.

하지만 next.js를 사용하면 client와 api서버 외에 SSR를 구현할 node서버가 하나 더 추가가 된 셈이다. 서버 구성자체는 next.js에서 제공해 주기 때문에 문제가 없지만 SSR을 통해 페이지를 구성하는 과정에서 web API를 사용할 수 없다는 게 큰 걸림돌이었다.

예를 들어 도매 사업자의 모든 페이지 내의 데이터는 사용자의 권한을 필수로 요구하기 때문에 페이지를 SSR로 구현을 하려면 getServerSideProps 내에서 JWT토큰정보를 api헤더에 담아서 보내야 한다. 여기서 문제가 발생한다. JWT토큰은 웹스토리지에서 관리 중이었기 때문에 web API를 통해 접근해야 하지만, 서버환경이기 때문에 web API를 사용할 수 없는 것. 따라서 JWT토큰을 쿠키에 저장하는 방식으로 변경하여 이를 해결할 수 있었다.

 

2. 클라우드 컴퓨팅 구성

기존에 CSR로 개발을 진행할 땐 S3버킷에 배포를 진행했었는데(사내 인프라는 aws를 사용 중이었다.) next.js는 서버를 별도로 구성하는 방식이기 때문에 ec2에 배포를 진행했다. pm2를 활용한 무중단 서버구동등 기존과는 다른 방식의 배포과정을 이해하는데 추가적인 시간이 소요됐다.

 

 

참고자료

https://yozm.wishket.com/magazine/detail/2036/?utm_source=stibee&utm_medium=email&utm_campaign=newsletter_yozm&utm_content=contents