현재 진행중인 프로젝트는 next.js 를 이용하여 구현하였다.
프로젝트 시작할 때 서버 컴포넌트에 대한 인지를 못한 상태로 그저
우와 라우팅 편하다~~ 라고 냅다 개발해버린 결과...
돌이켜보니 서버 컴포넌트가 단 한개도 없다는 문제가 있었다!!!!
처음 발단은...
-
모든 페이지가 'use client'로 작성되어있음
-
api 요청 인터셉터가 클라이언트 컴포넌트에서만 동작 가능
-> 서버 컴포넌트에서는 사용 불가ㅜ
'이러면 next.js 를 사용하는 의미가 없는데...?'
위기감을 느끼고 서버컴포넌트를 쓰는 이유와 나누는 기준
최종적으로는 현재의 문제 (서버 컴포넌트에서의 요청 인터셉터)를 해결해 보겠다.
1. 서버 컴포넌트를 쓰는 이유
서버 컴포넌트를 쓰면 좋은점!! 지피띠예에게 앙딱정 해달라고 하였다
✅ 1. 초기 로딩 속도 개선 (서버 사이드 렌더링)
서버에서 데이터를 가져와 렌더링한 HTML을 클라이언트에 보내기 때문에,
클라이언트는 자바스크립트 번들 없이도 빠르게 콘텐츠를 볼 수 있습니다.
✅ 2. 클라이언트 번들 크기 감소
use client를 선언하지 않은 컴포넌트는 클라이언트에 JS로 번들되지 않음.
즉, 브라우저는 해당 컴포넌트를 JS로 다운로드하지 않음.
📌 효과:
사용자 디바이스에서 적은 JS만 실행되므로 렌더링 속도 향상
번들 용량 감소 → 모바일 환경에서도 빠름
✅ 3. 보안 강화 (비공개 API/로직 보호)
클라이언트에서 노출되면 안 되는 로직(예: 관리자 전용, 내부 토큰 등)은 서버에서 실행되기 때문에 코드 유출 위험이 없음.
✅ 4. 클라이언트 요청 횟수 감소 (네트워크 최적화)
서버에서 API 호출 후 HTML을 그려서 보내므로, 클라이언트에서 다시 API를 호출할 필요가 없음.
✅ 5. 병렬 데이터 페칭이 가능
await 없이 여러 서버 컴포넌트가 병렬적으로 데이터를 받아오고 렌더링됩니다.
✅ 6. 자동 캐싱 및 ISR 지원
Next.js는 서버 컴포넌트 결과를 자동으로 캐시하거나 Incremental Static Regeneration (ISR)을 적용 가능.
- Incremental Static Regeneration: SSG(Static Site Generation) 방식에서 일정한 주기마다 페이지를 자동으로 재생성하여 최신 데이터를 반영하는 기능
즉, 서버 컴포넌트는 정적/동적 페이지로 모두 활용 가능.
✅ 7. 코드 분리 및 관심사 분리 용이
서버 컴포넌트는 "데이터 로딩"에 집중
클라이언트 컴포넌트는 "UI 상호작용"에 집중
→ 코드 구조가 깔끔해지고 유지보수가 쉬워짐
여러모로 서버 컴포넌트로 분리하는것이 유리한 것 같다.
다음으로 든 의문점! 서버컴포넌트로 나누는 기준은 무엇일까?
2. 서버 컴포넌트로 나누는 기준
이것도 지피띠예가 앙딱정 해주었다
브라우저와 직접적인 연관이 있는 부분은 클라이언트로, 그렇지 않은 부분들은 서버 컴포넌트로 구현을 하는것이 좋다고 한다.
이렇게만은 명확하게 이해가 되지 않아서 현재 구현중인 페이지를 통해 예시를 들어달라고 해보았다.
예시로 든 페이지는 리스트를 불러오는 페이지이고, 각 리스트 영역을 누르면 해당 항목의 아이디 값을 통해 세부 정보 페이지로 이동한다.
일단 이런 식으로 구성이 된 것을 볼 수 있다.
다음 글에서는 위 구성에 따라 실제로 구현해보도록 하겠다.
