React 프로젝트를 리팩토링 하면서 Next.js로 마이그레이션을 하게 되었고, 처음으로 서버 사이드 컴포넌트(Server-side Component, SSC) 를 사용할 기회를 갖게 되었다. 기존 React에서는 React Query를 활용하여 서버의 부담을 줄이며 데이터를 관리해왔는데, Next.js에서도 기존처럼 React Query를 사용할 수 있을지 고민하게 되었다.

SSC와 CSC의 차이

Next.js의 서버 컴포넌트(SSC) 와 클라이언트 컴포넌트(CSC) 는 동작 방식이 다르다.

• SSC(Server-side Component): 서버에서 데이터를 가져와 미리 렌더링하여 클라이언트에 전달함 → SEO 최적화
• CSC(Client-side Component): 클라이언트에서 데이터를 가져오고, 동적으로 업데이트함 → 실시간 변화 가능

이전처럼 React Query를 사용하여 데이터를 가져오려 했지만, 만약 모든 데이터를 클라이언트에서 가져온다면 Next.js의 서버 렌더링 기능을 제대로 활용하지 못하게 된다. Next.js를 사용하면서 서버의 역할을 최대한 활용해야 한다는 점에서 React Query만을 사용할 수는 없었다.

서버 부담 문제와 캐싱

처음에는 페이지를 이동할 때마다 서버가 데이터를 불러오면 부담이 커질 것이라고 생각했다. 하지만 Next.js에서는 서버에서 데이터를 가져올 때 캐싱을 통해 성능을 최적화할 수 있는 방법이 있었다.

async function getPosts() {
  const res = await fetch("https://api.example.com/posts", {
    next: { revalidate: 60 }, // 60초 동안 캐싱 유지
  });
  return res.json();
}

위와 같이 revalidate: 60을 설정하면 60초 동안 같은 요청을 반복하지 않고 캐싱된 데이터를 반환한다. 덕분에 SEO를 챙기면서도 서버의 부담을 줄일 수 있다.

어떤 데이터는 SSC, 어떤 데이터는 CSC로?

처음에는 서버와 직접적인 연관이 있는 것은 SSC로, 정적인 것은 CSC로 사용해야 한다고 생각했는데, 사실은 그 반대였다.

✔️ 서버 컴포넌트(SSC)를 사용해야 하는 경우

• SEO가 중요한 데이터 (검색 엔진 노출 필요)
• 초기 렌더링이 빠른 것이 중요한 데이터
• 변경이 자주 일어나지 않는 데이터
• 페이지 구조를 구성하는 주요 데이터

✅ 예시

• 블로그 글 목록 (게시글 리스트)
• 블로그 글 내용 (제목, 본문)
• 사용자 프로필 정보 (변경이 잦지 않은 경우)
• 카테고리 목록

✔️ 클라이언트 컴포넌트(CSC)를 사용해야 하는 경우

• 실시간으로 변화하는 데이터
• 사용자와의 인터랙션이 필요한 데이터
• 페이지 내에서 상태 변화가 필요한 데이터

✅ 예시

• 좋아요 개수, 댓글
• 검색 기능 (검색어 입력 시마다 데이터 변경)
• 무한 스크롤 (React Query의 useInfiniteQuery 활용)
• 사용자 설정 변경

결론: SSC와 CSC의 최적 조합

1. 초기 데이터를 서버에서 받아와 렌더링해야 하는 경우 → SSC 사용
2. 자주 변경되거나 사용자 인터랙션이 필요한 경우 → CSC + React Query 사용
3. 서버 부담을 줄이기 위해 revalidate 로 캐싱 활용

Next.js 마이그레이션을 하면서 서버 컴포넌트와 클라이언트 컴포넌트를 적절히 나누는 것이 성능 최적화에 매우 중요하다는 것을 깨달았다. SEO가 필요한 데이터는 서버에서 미리 받아오고, 실시간 업데이트가 필요한 데이터는 클라이언트에서 관리하는 것이 핵심이다. 이를 잘 활용하면 서버 부담을 줄이면서도 빠른 렌더링을 유지할 수 있다.