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)

서버 또는 빌드 환경에서 실행되어 렌더링 결과가 RSC Payload로 전달되는 컴포넌트입니다. 컴포넌트 코드가 클라이언트 번들에 포함되지 않으므로 브라우저가 다운로드하고 하이드레이션해야 할 JavaScript를 줄일 수 있으며, 서버 환경의 데이터 소스에 직접 접근할 수 있습니다.

2. 하이드레이션 (Hydration)

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

3. ISR (Incremental Static Regeneration)

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

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

• 🐣 영철 (후반): "영호 님! '영수네 메인 페이지'에서 날짜 포맷, 마크다운 변환, 추천 글 계산을 다 클라이언트에서 처리했더니 초기 로딩이 느립니다. 그런데 기능을 빼기는 어렵습니다."
• 🦁 영호 (리드): "영철 님, 클라이언트가 그 일을 모두 맡을 필요는 없어요. 서버 컴포넌트(RSC)를 쓰면 무거운 라이브러리와 데이터 가공은 서버에 남기고, 브라우저에는 사용자가 상호작용해야 하는 얇은 경계만 보낼 수 있습니다."

면접 질문 1. 리액트 서버 컴포넌트(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'는 클라이언트 번들 경계를 여는 선언입니다. onClick, useState, window처럼 브라우저 실행이 필요한 부분에만 두고, 데이터 가공이나 무거운 라이브러리 활용은 서버에서 끝내는 편이 RSC의 장점을 살립니다."

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

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

// app/posts/PostList.jsx
// 🦁 영호: "서버는 데이터를 준비하고, 클라이언트는 상호작용만 담당하게 나눕니다."
 
// 🏢 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>
  );
}

// app/posts/LikeButton.jsx
// 📱 Client Component ('use client')
// - 인터랙션이 필요한 부분만 최소화하여 분리
'use client';
 
function LikeButton() {
  const [liked, setLiked] = useState(false);
  return <button onClick={() => setLiked(!liked)}>좋아요</button>;
}

'use client'는 파일 단위 경계입니다. 한 파일에 선언하면 그 파일이 import하는 모듈도 클라이언트 번들에 포함될 수 있으므로, 상호작용이 필요한 leaf 컴포넌트 근처에 최대한 좁게 두는 것이 좋습니다.

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

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

면접 질문 2. 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)

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

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

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

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

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

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

📝 마무리 퀴즈

Q1. 'use client'를 모든 컴포넌트에 붙이는 방식이 왜 RSC 관점에서 좋지 않은가요?

✅ 정답: 서버에서 끝낼 수 있는 데이터 조회와 무거운 라이브러리까지 클라이언트 번들로 보내 초기 JS 비용을 키우기 때문

💡 상세 해설:

• 원리 설명: 서버 컴포넌트의 기본 가치는 브라우저에 보낼 일을 줄이는 것입니다. DB 접근, 데이터 가공, 무거운 모듈 사용은 서버에서 끝내고, 상호작용이 필요한 작은 경계만 클라이언트로 넘기는 것이 핵심입니다.
• 오답 피드백: 에러가 사라진다는 이유로 'use client'를 넓히면, 문제 해결이 아니라 서버/클라이언트 책임 경계를 무너뜨린 것입니다.
• 📌 핵심 기억법: 클라이언트 컴포넌트는 기본값이 아니라 필요한 경계입니다.

Q2. App Router에서 layout, page, loading, error 파일을 이해해야 하는 이유는 무엇인가요?

✅ 정답: 라우트 세그먼트마다 데이터, UI 공통 구조, 스트리밍, 에러 복구 경계를 나눌 수 있기 때문

💡 상세 해설:

• 원리 설명: App Router는 단순 파일 라우팅이 아니라 UI와 데이터 로딩의 경계를 파일 시스템으로 표현합니다. 면접에서는 이 구조가 UX와 장애 격리를 어떻게 개선하는지 말해야 합니다.
• 오답 피드백: pages 폴더와 이름만 다른 라우팅 방식이라고 답하면 RSC와 streaming의 장점을 놓칩니다.
• 📌 핵심 기억법: App Router의 파일은 URL보다 UI 경계를 더 많이 설명합니다.

Q3. 영철이의 테스트 타임: 게시글 목록은 서버 컴포넌트, 좋아요 버튼은 클라이언트 컴포넌트로 나눈 이유는 무엇인가요?

✅ 정답: 목록 데이터 조회와 렌더링은 서버에서 처리하고, 클릭 상태와 이벤트 핸들러가 필요한 최소 부분만 클라이언트로 보내기 위해서

💡 상세 해설:

• 원리 설명: RSC의 설계 판단은 "무엇이 브라우저에서 꼭 실행되어야 하는가"를 묻는 일입니다. 상호작용이 없는 데이터 UI는 서버에 남기고, 이벤트가 필요한 leaf만 클라이언트로 보냅니다.
• 오답 피드백: 하나의 페이지라서 전부 같은 실행 환경에 있어야 한다는 생각은 서버/클라이언트 컴포넌트 모델과 맞지 않습니다.
• 📌 핵심 기억법: 브라우저에는 사용자가 만지는 부분만 최대한 얇게 보냅니다.

🐣 영철이의 퇴근 일기

오늘은 'use client'가 문제 해결 주문이 아니라 비용이 붙는 경계 선언이라는 걸 배웠다. 예전 같으면 에러가 나면 일단 붙이고 봤을 텐데, 이제는 이 컴포넌트가 정말 브라우저에서 실행되어야 하는지 먼저 물어봐야 한다.

💡 "서버 컴포넌트의 핵심은 새 기능을 더하는 게 아니라, 브라우저가 하지 않아도 되는 일을 덜어내는 것이다."

다음 설계에서는 page, layout, loading, error를 단순 파일명으로 보지 않고 사용자 경험의 경계로 봐야겠다. 영철이 이제 "어디에 코드를 둘까"보다 "어디서 실행되어야 할까"를 먼저 묻기 시작했다.