개발을 하다보면 가끔 아주 사소한 문제를 가지고 깊은 고민에 빠지게 됩니다.
특정 페이지 내부에 하위 메뉴가 있는 경우,
각각의 내용들을 각 페이지로 만드는 것이 좋을지, 아니면 state를 통해 컴포넌트를 전환하는게 나을지 고민이 되었습니다.
사실 지금까지는 아무 생각없이 토글 방식의 tab 컴포넌트라면 컴포넌트 전환을,
위 이미지와 같이 사이드 메뉴 형식이라면 페이지 전환을 했었는데요.
단순히 UI의 형태로 구분하기에는 SSR 방식의 렌더링이 가능한 Next.js에서 적절하지 못한 방법이라고 생각했습니다.
추가로 들었던 생각은, '라우팅 방식을 사용했을 때 서버에서 완성된 HTML을 보내주는 SSR 방식이면 메뉴 전환을 하는 과정에서 로딩시간이 오래 걸리지 않을까?' 였습니다.
결과적으로는,
페이지나 탭 이동과 같이 '의미가 달라지는 경우'는 라우팅을 분리하는 것이,
같은 페이지에서 'view만 바뀌는 경우'는 컴포넌트 전환을 사용하는 것이 좋은 방법인 것 같다는 결론을 냈습니다.
역시 많은 사람들이 그렇게 하는 데는 다 이유가 있는 법 !! 이지요 ㅎ..
그동안은 이유를 모르고 그냥 직감적으로 이렇게 해왔었는데, 그 이유에 대해서 탐구해볼 수 있었습니다!
컴포넌트 전환 방식을 선택했다면?
만약 사이드 메뉴를 구현할 때 상태 전환 방식을 선택했을면 어떻게 문제가 있었을까요?
- 딥링크/새로고침/뒤로가기 망가짐
- 현재 클릭한 메뉴의 상태가 URL에는 존재하지 않기 때문에 특정 페이지만 공유/북마크 할 수 없습니다.
- 새로고침을 하면 기본 탭으로 튕기고, 히스토리도 남지 않아 뒤로가기를 눌러도 원하는 섹션으로 가지 않습니다.
- SEO/메타/프리렌더 약화
- 페이지 의미를 URL로 나누지 않기 때문에 크롤러·OG태그·메타 데이터 분리가 불가능 합니다. 따라서 검색이나 공유 품질이 매우 하락합니다.
생각해보면 친구가 어떤 콘텐츠를 링크를 공유했는데, 제가 접속하면 홈페이지만 보이는 사이트가 있었던 것 같습니다.. 로그인 권한이 없거나 이 페이지의 개발자도 컴포넌트 전환 방식으로 구현을 했거나 둘 중 하나가 이유였을까요 ...!
- 번들 비대화
- 코드 스플리팅을 하는 이유가 빌드를 했을 때 chunk와 번들의 크기가 너무 크기 때문이라고 알고있는데요, 컴포넌트 전환방식으로 페이지를 구현했을 때 라우팅이 아니니 코드 스플리팅도 불가능합니다.
기본적으로 발생할 수 있는 문제가 이 정도이고, 그 외에도 더 복잡한 상황들이 만들어질 수 있을 것 같습니다.
적절한 상황에서 컴포넌트 전환 방식으로 서로 다른 view를 구성한다 하더라도, ?category=dog&view=grid 이런식으로 URL에 기록을 남겨놓는 것이 좋을것 같습니다!
라우팅 방식을 사용했다면?
라우팅 방식을 사용해서 사이드메뉴를 구현한다면 어떤 장점이 있을까요?
- URL이 상태를 반영하고 있음
- URL 자체가 상태를 반영하고 있기 때문에 사용자입장에서 원하는 섹션에 바로 들어갈 수 있습니다.
- 따라서 북마크나, 공유, 히스토리 등도 원하는대로 잘 작동이 되겠지요!
- SSR·SSG·SEO 최적화 용이
- 어떤 내용이냐에 따라 섹션 별로 데이터를 로딩하는 방법(SSR/SSG/ISR)이 달라질 수도 있습니다. 이 경우 각 페이지별로 다른 전략을 사용할 수 있습니다.
- 또 SEO 최적화에도 용이합니다.
- 코드 스플리팅 & 성능 최적화 가능
- 라우팅 방식으로 구성할 경우, 코드 스플링이 가능하여 성능 최적화가 가능합니다.
- 에러·로딩 상태 격리
- /mypage/profile에서 에러가 나도 /mypage/addfamily는 영향이 가지 않습니다.
- 또 각 페이지별 error.tsx·loading.tsx 적용이 가능합니다. Next.js 의 편리성 중 하나죠 !!
왜 속도가 느려지지 않을까?
이 고민을 하면서 막연하게 들었던 생각은 'SSR 방식을 사용하는 Next.js에서 페이지 라우팅으로 하위 메뉴를 구성할 경우 로딩 속도가 느려지지 않을까?' 였습니다.
하지만 그렇지 않다는 사실 !!
SSR이 느려질 수 있는 경우는 다음과 같습니다.
- 서버에서 매번 새로 HTML을 렌더링해서 보내야 하니까, 클라이언트가 받기까지 시간이 좀 더 걸릴 수 있다.
- 특히 외부 API 호출이나 DB 쿼리가 길어지면 진짜 느려진다.
하지만 이런 문제는 Next.js 에서 다음과 같은 최적화 기법을 적용함으로써 해결할 수 있습니다.
- ISR(Incremental Static Regeneration)
- 자주 변하지 않는 페이지는 정적 파일로 캐싱하고, 일정 주기로만 재생성합니다. 따라서 매 요청마다 새로 렌더링 하지 않기 때문에 초기 로딩 속도를 단축할 수 있습니다.
- 데이터 캐싱 및 CDN 배포
- 서버와 클라이언트 모두 캐시 전략을 적용해서 동일 요청 시 즉시 응답이 가능하도록 할 수 있습니다.
- Streaming SSR & React Server Components
- 페이지 전체를 기다리지 않고, 레이아웃/공통 UI 부터 먼저 전송하기 때문에 사용자 체감 속도가 향상됩니다.
따라서 SSR 구조라도 Next.js의 캐싱, ISR, 스트리밍 렌더링, 클라이언트 fetch 분리 등을 적절히 활용하면 페이지 라우팅 방식으로 하위 메뉴를 구성해도 체감 속도 저하는 거의 없습니다.
오히려 URL 구조가 명확해지고, 코드 분리·SEO·유지보수 측면에서 더 이점을 얻을 수 있죠. 즉, 성능 저하 걱정보다는 라우팅 구조의 장점을 살리는 쪽이 유리하다는 사실 !!!! 을 또 새롭게 알게되었습니다.
결론
이로써
특정 페이지에서 각각의 의미가 다른 하위 페이지를 구성해야하는 경우, 컴포넌트 전환 방식이 아닌 라우팅 방식을 사용하는 것이 백번 만번 좋다는 사실을 알게 되었습니다.
반대로 view만 바꾸는 경우, 굳이 페이지를 나눌 필요없이 컴포넌트 전환 방법을 사용하는 것이 더 효율적이라는 것도 알게되었습니다.
(여기서 굳이 페이지를 나눠버리면 데이터 fetching을 쓸데없이 여러번 해야 할 수도 있겠군요..)
이렇게 하위 메뉴를 설계하는 것은 프론트엔드 프로젝트를 하다보면 절대 빠질 수 없는 부분인데요.
보통 컴포넌트 전환 방식으로 구현하다가 뭔가 이건 아무래도 아닌 것 같아서 라우팅으로 바꾸거나, 그냥 뭔가 그래야만 할 것 같아서 처음부터 라우팅을 사용하는 경우가 대부분이었을겁니다. 저도 그랬구요..
가끔 이렇게 사소하고 당연한 것처럼 느껴지는 부분도 '왜?' 써야하는지 깊게 고민해보면 더 사용성 높은 서비스를 만드는 데 도움이 될 것 같습니다.
뭐든지 당연하게 받아들이지 말자 !! 오늘의 명언입니다.
그럼 안뇽
