[연픽] SSG 되지 않아도 되는 컴포넌트 격리하기

🐶 기존 시스템의 문제

 

기존 시스템의 경우 next.js의 pages router 내부에 컴포넌트 폴더가 존재하는 형태였습니다.

next.js는 폴더/파일 기반 라우팅을 수행하기 때문에 pages, app과 같은

약속된 폴더명 내부에는 라우팅을 위한 파일들만 두는 것이 좋다고 생각합니다.

 

다만 이러한 라우팅을 회피하는 기법도 존재하는데요

예컨대 underbar를 폴더명에 붙여주는 것을 통하여

해당 파일, 폴더들이 라우팅되지 않아도 된다는 것을 알려줄 수 있습니다.

 

하지만 연픽의 기존 시스템은 컴포넌트들 역시 모두 페이지로 취급되어

빌드타임에 SSG 되고 있는 상태였으며 이는 건강한 구조가 아니라고 생각했습니다.

 

1. 파라미터 조작을 통해 외부인도 너무 쉽게 컴포넌트의 구현에 접근할 수 있습니다.

2. 개발자가 의도하지 않은 경로로 접근하더라도 404 error를 반환하지 않을 수 있습니다.

3. 실제로 라우팅되어야할 페이지와 컴포넌트가 뒤섞여 구분이 어려워집니다.

4. SSG 되지 않아도 될 컴포넌트까지 SSG를 하며 빌드시간에 손해가 생깁니다.

 

이를 개선하기 위해서는 컴포넌트 폴더가 SSG 되지 않도록 분리시킬 필요가 있었는데요

설상가상으로 컴포넌트 폴더 안에 모든 컴포넌트가 있는게 아니라

각 페이지들에도 컴포넌트 폴더가 잔뜩 만들어져있는 상태였습니다.

 

다행히 현대 IDE 들은 폴더,파일명 변경 / 폴더,파일 이동등에 대하여

알아서 경로를 바꿔주는 똑똑함을 보여주긴 하지만 완벽한것은 아닙니다.

그리고 IDE가 해결해주지 못하는 작업은 사람이 직접 해줄 수 밖에 없죠..

결국 꽤 시간을 들여서 해결되지 못한 경로들을 해결하는데 성공했습니다.

---

🐽 개선 전과 개선 후 비교

개선 이전

 

개선 후

개선 이전에 비하여 약 1초 가량 빌드 시간이 아껴진 모습입니다.

고작 1초줄이려고 이런 귀찮은 일을 수행했느냐? 라고 하면 안타까운 일이지만..

개선 전

 

개선 이전 SSG 되고 있던 페이지의 갯수입니다.

657개로 어마어마한 양의 정적페이지가 생성되고 있었던 것을 알 수 있습니다.

사실 몇백개의 페이지가 필요할정도의 초 거대규모의 프로젝트가 아님에도 불구하고요

 

개선 후

이번엔 개선 이후의 정적 페이지 생성 결과입니다.

657 개 -> 33개로 확연히 정적생성되고있는 페이지가 줄어들었음을 알 수 있습니다.

이제 사용자가 접근할 수 있는 페이지의 경우의수가 압도적으로 줄어들었으며

pages 폴더에 산재해있던 컴포넌트파일들이 바깥으로 추출되어

pages 폴더에 있는 파일들은 라우팅을 위한 파일들이라는 것이 더욱 확실해질 수 있었습니다.

---

🦆 마치며

기술적으로 어려운 작업은 아니지만 쉽지 않은 작업이었어요..