08. 🌐 Next.js App Router와 서버 컴포넌트

📌 이 면접 항목의 목표

⏱️ 예상 읽기 시간: 26분 (핵심 요약: 13분)

🗺️ 이 챕터의 흐름
[개념 사전] → [질문 1: App Router & RSC] → [질문 2: 렌더링 전략 SSR/SSG/ISR] → [실전 변형 질문]

🎯 이 챕터를 다 읽으면 할 수 있는 것

• 서버 컴포넌트(RSC)와 클라이언트 컴포넌트의 차이와 사용 시점을 완벽히 구분합니다.
• App Router 환경에서 데이터 페칭과 캐싱이 어떻게 변했는지 설명합니다.
• 비즈니스 요구사항에 따라 SSR, SSG, ISR 중 최적의 렌더링 방식을 선택합니다.

📚 핵심 개념 사전 (Concept Glossary)

1. 리액트 서버 컴포넌트 (React Server Components, RSC)

서버에서 한 번만 실행되어 결과물(HTML이 아닌 특수 JSON)만 전송되는 컴포넌트입니다. 클라이언트 번들 사이즈에 포함되지 않아 성능 향상에 혁명적이며, DB에 직접 접근이 가능합니다.

2. 하이드레이션 (Hydration)

서버에서 만들어진 정적 HTML 위에 자바스크립트를 입혀 이벤트 리스너를 달고 인터랙티브한 상태로 만드는 '부활' 과정입니다. RSC는 하이드레이션이 필요 없는 부분이 늘어난다는 점이 핵심입니다.

3. ISR (Incremental Static Regeneration)

빌드 시점에 정적 페이지를 생성(SSG)하되, 일정 시간이 지나면 백그라운드에서 해당 페이지를 새로 생성하여 업데이트하는 방식입니다. '정적 페이지의 성능'과 '데이터의 실시간성'을 모두 잡은 전략입니다.

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 🐣 영철 ( 신입 ): "영호 님! '영수네 메인 페이지'를 만드는데 무거운 라이브러리를 많이 썼더니 초로딩이 너무 느려요. 그렇다고 다 빼버릴 수도 없고... 어떡하죠? 😭"
• 🦁 영호 ( 리드 ): "영철 님, 클라이언트가 그 짐을 다 짊어질 필요는 없어요. 서버 컴포넌트(RSC)를 쓰면 브라우저는 무거운 라이브러리의 존재조차 모른 채 결과물만 받을 수 있죠. Next.js는 단순한 프레임워크가 아니라 서버 자원을 어떻게 효율적으로 쓸지 알려주는 가이드라인입니다."

Q1. 리액트 서버 컴포넌트(RSC)와 클라이언트 컴포넌트의 결정적인 차이와, 각각 언제 사용해야 하는지 설명해 보세요.

🎯 출제 의도

모던 리액트의 가장 큰 패러다임 변화인 '서버 측 실행'을 이해하고 있는지, 그리고 클라이언트 번들 크기를 최적화하려는 아키텍처적 고민이 있는지 확인합니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 아무 생각 없이 모든 파일 최상단에 'use client'를 붙이고 다닙니다.

'use client'; // 🐣 영철: "이게 없으면 다 에러 나더라고요. 그냥 다 클라이언트 컴포넌트로 하면 안 되나요?"
 
import { format } from 'date-fns'; // ⚠️ 거대한 날짜 라이브러리가 클라이언트 번들에 포함됨
 
export function PostItem({ post }) {
  // 별다른 인터랙션(onClick 등)이 없는데도 클라이언트 컴포넌트로 선언함
  return <div>{format(new Date(post.createdAt), 'yyyy-MM-dd')}</div>;
}

🦁 영호의 팩폭 조언
"영철 님, 'use client'는 리액트 18 이후부터 '비상 탈출구' 같은 거예요. 브라우저의 API(onClick, useState 등)가 필요할 때만 써야죠. 데이터 가공이나 무거운 라이브러리 활용은 서버에서 끝내고 결과만 보내는 게 RSC의 핵심입니다."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드가 서버와 클라이언트의 협업 구조를 보여줍니다.

// 🦁 영호: "서버는 데이터를 요리하고, 클라이언트는 서빙을 담당합니다."
 
// 🏢 Server Component (기본값)
// - DB 직접 접근 가능
// - 거대한 라이브러리(date-fns 등)를 써도 클라이언트에게 전송 안 됨!
async function PostList() {
  const posts = await db.post.findMany(); // ✅ 서버니까 직접 fetch!
  
  return (
    <div>
      {posts.map(post => (
        <PostItem key={post.id} post={post} />
      ))}
    </div>
  );
}
 
// 📱 Client Component ('use client')
// - 인터랙션이 필요한 부분만 최소화하여 분리
'use client';
function LikeButton() {
  const [liked, setLiked] = useState(false);
  return <button onClick={() => setLiked(!liked)}>좋아요</button>;
}

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "서버 컴포넌트는 서버에서 실행되고, 클라이언트 컴포넌트는 브라우저에서 실행됩니다. 훅(useState 등)을 쓰려면 클라이언트 컴포넌트를 써야 합니다."
• Level 2 (Senior): "클라이언트 번들 사이즈(Zero-bundle size) 관점에서의 이점을 설명합니다. 서버 컴포넌트는 보안상 민감한 정보를 숨길 수 있고 서버 자원을 활용해 데이터 페칭을 가속화할 수 있음을 강조합니다. 또한 두 컴포넌트 간의 '직렬화(Serialization)' 제약 조건을 언급합니다."
• Level 3 (Specialist): "RSC 페이로드(Payload)의 구조를 분석하고, 하이드레이션 비용을 획기적으로 줄이는 메커니즘을 설명합니다. 'Boundary'를 어떻게 설정하느냐에 따라 사용자 경험(LCP 등)이 어떻게 변하는지 실제 프로젝트 경험을 바탕으로 논리적으로 분석합니다."

Q2. SSR, SSG, ISR의 차이점을 설명하고, 서비스의 성격에 따라 어떤 전략을 선택할지 기준을 제시해 보세요.

🎯 출제 의도

다양한 렌더링 전략의 장단점을 비즈니스 상황에 매핑할 수 있는 실무 능력을 확인합니다. 성능(Speed)과 최신성(Freshness) 사이의 트레이드오프를 이해하는지가 핵심입니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 '검색 엔진 최적화(SEO)'가 중요하다고 해서 모든 페이지를 무조건 SSR로 구현했습니다.

// 🐣 영철: "서버에서 다 그려서 주니까 무조건 SSR이 좋은 거 아닌가요?"
export async function getServerSideProps() { // ⚠️ 구형 Pages Router 방식의 고질적 SSR
  const data = await fetchLargeData();
  return { props: { data } };
}
 
// ⚠️ 문제: 사용자가 접속할 때마다 서버가 매번 큰 데이터를 페칭하느라 
// 응답 속도(TTFB)가 느려지고 서버 비용이 폭발함

🦁 영호의 팩폭 조언
"영철 님, 안 변하는 페이지를 왜 매번 새로 그리나요? 정적 페이지(SSG)로 미리 구워두면 CDN을 타고 빛의 속도로 전달될 텐데 말이죠. SSR은 '나만을 위한 데이터'가 있을 때만 쓰는 도구예요."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드가 상황별 최적 렌더링 매트릭스를 제안합니다.

// 🦁 영호: "사용자 유형과 데이터의 빈도를 먼저보세요."
 
// 1. SSG (Static Site Generation): 서비스 소개, 블로그 글
// - 빌드 시점에 딱 한 번 생성. 가장 빠름.
export const dynamic = 'force-static';
 
// 2. ISR (Incremental Static Regeneration): 쇼핑몰 상품 목록, 실시간성 광고
// - 정적 페이지의 장점을 가지면서도 일정 시간마다 자동 갱신.
export const revalidate = 60; // 60초마다 갱신
 
// 3. SSR (Server Side Rendering): 마이페이지, 장바구니
// - 사용자마다 결과가 다를 때. 최신성 100% 보장.
export const dynamic = 'force-dynamic';

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "SSR은 접속할 때마다 서버가 그리고, SSG는 빌드할 때 미리 만듭니다. ISR은 주기적으로 다시 만듭니다."
• Level 2 (Senior): "각 전략이 웹 지표(Core Web Vitals) 중 특히 TTFB와 LCP에 어떤 영향을 주는지 설명합니다. 데이터의 실시간성과 서버 부하 간의 트레이드오프를 고려하여 전략을 선택하는 논리를 제시합니다."
• Level 3 (Specialist): "App Router에서의 'Full Route Cache'와 'Request Memoization' 개념을 연결합니다. 단순히 페이지 단위의 전략을 넘어, 하나의 페이지 안에서 특정 컴포넌트는 ISR로, 어떤 부분은 Streaming을 통한 SSR로 구성하는 '하이브리드 아키텍처' 설계 역량을 보여줍니다."

🔗 실전 변형 질문 (Related Variations)

Q112. Next.js의 'Streaming'과 'Suspense'가 사용자 경험을 개선하는 원리는 무엇인가요?

• 🎯 출제 의도: 데이터 페칭이 완료될 때까지 전체 페이지 렌더링을 차단하지 않고, 비어있는 화면을 최적화하는 기술을 확인합니다.
• 💡 핵심 원리 & 답변: 기존 SSR은 데이터가 모두 준비될 때까지 사용자에게 빈 화면만 보여주었으나(All-or-nothing), 스트리밍은 آماده된 부분(데이터가 필요 없는 정적 레이아웃 등)부터 먼저 브라우저에 전송합니다. 느린 컴포넌트는 Suspense 바운더리로 감싸 스켈레톤 UI를 보여주고, 데이터가 도착하는 대로 해당 부분만 조각조각 서버에서 클라이언트로 흘려보냅니다(Stream). 이는 사용자에게 페이지가 더 빨리 반응한다는 느낌(Perceived Performance)을 줍니다.

Q120. next/image 컴포넌트가 단순한 <img> 태그보다 나은 이유는 무엇인가요?

• 🎯 출제 의도: 이미지 최적화라는 구체적인 성능 개선 도구의 내부 동작을 이해하고 있는지 확인합니다.
• 💡 핵심 원리 & 답변: 첫째, 자동 이미지 최적화입니다. 사용자의 기기에 맞춰 WebP 같은 현대적인 포맷으로 변환하고 크기를 리사이징합니다. 둘째, Lazy Loading을 기본 적용하여 화면에 보이지 않는 이미지는 나중에 로딩합니다. 셋째, Layout Shift 방지입니다. 이미지 로딩 전에도 정확한 자리를 확보하여 LCP와 CLS 지표를 개선합니다. 마지막으로 CDN 캐싱을 통해 원본 서버의 부하를 획기적으로 줄여줍니다.

Q135. 미들웨어(Middleware)를 활용하여 해결할 수 있는 실무적인 사례를 들어보세요.

• 🎯 출제 의도: 요청과 응답 사이의 공통 로직을 효율적으로 처리하는 가로채기(Interceptor) 패턴을 확인합니다.
• 💡 핵심 원리 & 답변: 가장 대표적인 사례는 **인증 및 권한 체크(Auth Guard)**입니다. 로그인이 되지 않은 사용자가 보호된 페이지에 접근할 때 렌더링이 시작되기도 전에 리다이렉트 시킬 수 있습니다. 또한 사용자의 국가 정보에 따른 국제화(i18n) 라우팅, A/B 테스트를 위한 쿠키 기반 분기 처리, 혹은 봇 차단과 같은 보안 로직을 페이지 렌더링 성능에 영향을 주지 않으면서 전역적으로 처리할 수 있습니다.

🐣 영철이의 복기 일기

오늘 서버 컴포넌트를 배우면서 "자바스크립트가 브라우저의 전유물이 아니게 되었다"는 사실을 뼈저리게 느꼈다. 영호 님이 말씀하신 '서버와 클라이언트의 협업'은 단순히 코드를 나눠 짜는 게 아니라, 사용자에게 최대한 가벼운 결과물만 보내려는 개발자의 배려라는 걸 알았다.

💡 "성능 최적화는 덜어내는 데서 시작하고, 그 덜어냄의 끝에 서버 컴포넌트가 있다."

내일은 웹의 성적표라고 할 수 있는 '성능 최적화와 Web Vitals'를 배운다. 점수 1점을 올리기 위한 처절한 사투(?)가 벌어질 것 같은 예감이 들지만, 영철아 넌 할 수 있어! 📈🔥