Next.js 미드레벨 종합 기술면접
새 면접Q. Next.js에서 SSG, SSR, ISR, CSR의 하이브리드 렌더링 전략을 사용해야 하는 대규모 전자상거회 사이트를 설계한다고 가정합니다. 상품 목록 페이지, 상품 상세 페이지, 장바구니 페이지, 사용자 대시보드에 각각 어떤 렌더링 전략을 적용할지 결정하고, 각 선택의 근거를 SEO, 성능, 데이터 신선도 관점에서 설명해주세요.
상품 목록 페이지는 ISR(revalidate: 300)을 적용하여 SEO를 확보하면서도 주기적으로 재생성합니다. 상품 상세 페이지는 generateStaticParams로 인기 상품만 SSG하고 나머지는 ISR로 온디맨드 생성하여 빌드 시간을 단축합니다. 장바구니는 사용자별 데이터이므로 CSR을 적용하고 Server Components로 레이아웃만 SSR 처리합니다. 사용자 대시보드는 인증이 필요하고 개인화된 데이터이므로 SSR을 적용하되 Streaming을 활용해 TTFB를 최적화합니다. 각 페이지의 특성에 맞는 렌더링 전략을 선택하여 성능과 사용자 경험을 최적화할 수 있습니다.
- • 상품 목록: ISR로 SEO와 데이터 신선도 균형
- • 상품 상세: 하이브리드 SSG+ISR로 빌드 시간 최적화
- • 장바구니: CSR로 사용자별 데이터 처리
- • 대시보드: SSR+Streaming으로 인증 데이터 처리 및 성능 확보
ISR을 사용할 때 CDN 캐시 무효화 전략과 on-demand revalidation을 어떻게 조합하여 사용하시겠습니까?
Q. Next.js App Router에서 동적 메타데이터를 생성하는 generateMetadata 함수를 사용할 때, 이 함수에서 수행하는 데이터 페칭이 페이지 컴포넌트의 데이터 페칭과 중복되는 경우가 있습니다. Next.js가 이러한 중복 요청을 어떻게 최적화하는지 설명하고, 이 메커니즘의 한계와 주의사항을 설명해주세요.
Next.js는 Request Memoization을 통해 동일한 렌더링 사이클 내에서 같은 URL과 옵션을 가진 fetch 요청을 자동으로 중복 제거합니다. generateMetadata와 페이지 컴포넌트에서 동일한 API를 호출하면 실제로는 한 번만 요청이 발생하고 결과가 공유됩니다. 하지만 이 메모이제이션은 서버 렌더링 중에만 유효하며, fetch 함수를 사용하지 않는 직접적인 데이터베이스 쿼리나 외부 SDK 호출은 메모이제이션되지 않습니다. 따라서 중복 요청 방지를 위해 React의 cache 함수로 직접 래핑하거나, 데이터 페칭 로직을 별도 함수로 분리하여 재사용하는 것이 좋습니다.
- • Request Memoization으로 동일 fetch 요청 자동 중복 제거
- • 서버 렌더링 사이클 내에서만 유효
- • fetch 외 데이터 소스는 React cache로 수동 래핑 필요
- • 데이터 페칭 로직 분리로 재사용성 확보
generateMetadata가 비동기 함수인데, 이것이 Streaming SSR과 함께 사용될 때 메타태그 렌더링 시점에 어떤 영향을 미치나요?
Q. Next.js 애플리케이션에서 Context API를 과도하게 사용하면 불필요한 리렌더링이 발생할 수 있습니다. Context value가 객체일 때 발생하는 참조 동일성 문제를 설명하고, 이를 해결하기 위한 Context 분리 전략과 useMemo의 활용 방법을 설명해주세요. 또한 Zustand나 Jotai 같은 상태 관리 라이브러리가 이 문제를 어떻게 해결하는지 비교해주세요.
Context의 value가 객체나 배열인 경우 Provider가 리렌더링될 때마다 새로운 참조가 생성되어 모든 Consumer가 리렌더링됩니다. 이를 해결하기 위해 value를 useMemo로 메모이제이션하거나, 상태와 업데이트 함수를 별도 Context로 분리하는 패턴을 사용합니다. 또한 자주 변경되는 값과 거의 변경되지 않는 값을 다른 Context로 분리하여 리렌더링 범위를 최소화합니다. Zustand는 선택자 기반으로 상태의 일부만 구독하여 해당 부분이 변경될 때만 리렌더링하며, Jotai는 원자 단위로 상태를 관리하여 필요한 atom만 구독하므로 불필요한 리렌더링을 근본적으로 방지합니다.
- • Context value 객체의 참조 동일성 문제
- • useMemo로 value 메모이제이션
- • 상태와 업데이트 함수 Context 분리
- • Zustand/Jotai는 선택적 구독으로 문제 해결
App Router의 Server Components 환경에서 전역 상태 관리를 할 때 클라이언트 전용 상태와 서버에서 초기화되는 상태를 어떻게 구분하여 설계하시겠습니까?
Q. Next.js 애플리케이션의 실제 사용자 성능을 모니터링하기 위해 Web Vitals(LCP, FID, CLS)를 측정하고 수집하려고 합니다. Next.js의 reportWebVitals 함수를 사용한 측정 방법을 설명하고, 수집된 데이터를 분석하여 성능 병목을 식별하는 전략을 제시해주세요. 또한 Lab Data와 Field Data의 차이점과 각각의 활용 방법을 설명해주세요.
reportWebVitals는 _app.js나 layout.tsx에서 구현하여 CLS, FID, FCP, LCP, TTFB 등의 메트릭을 수집할 수 있습니다. 수집된 데이터는 Google Analytics나 Sentry 같은 모니터링 도구로 전송하여 집계하고, 페이지별, 디바이스별, 네트워크 환경별로 분석합니다. Lab Data는 Lighthouse 같은 도구로 통제된 환경에서 측정한 데이터로 개발 중 최적화 방향을 잡는데 유용하며, Field Data는 실제 사용자의 다양한 환경에서 측정된 데이터로 실제 성능 문제를 파악하는데 필수적입니다. 두 데이터를 함께 활용하여 Lab에서 문제를 재현하고 최적화한 후 Field에서 개선을 검증하는 사이클을 구축합니다.
- • reportWebVitals로 실시간 메트릭 수집
- • 모니터링 도구 연동 및 세그먼트별 분석
- • Lab Data: 통제된 환경, 개발 중 최적화
- • Field Data: 실사용자 데이터, 실제 성능 검증
LCP가 느린 페이지를 발견했을 때 원인을 특정하기 위해 어떤 순서로 디버깅을 진행하시겠습니까?
Q. Next.js 애플리케이션에서 CSRF(Cross-Site Request Forgery) 공격을 방지하기 위한 전략을 설명해주세요. SameSite 쿠키 속성의 역할과 한계, CSRF 토큰 패턴의 구현 방법, 그리고 Next.js API Routes나 Server Actions에서 각각 어떻게 CSRF 보호를 적용해야 하는지 설명해주세요.
CSRF 공격은 사용자가 인증된 상태에서 악의적인 사이트가 의도하지 않은 요청을 보내는 공격입니다. SameSite=Lax 또는 Strict 쿠키 속성을 설정하면 크로스 사이트 요청에서 쿠키가 전송되지 않아 기본적인 보호가 가능하지만, 같은 사이트 내 XSS 공격에는 무력합니다. API Routes에서는 CSRF 토큰을 세션에 저장하고 요청 헤더나 바디에 포함시켜 검증하는 방식을 사용합니다. Server Actions는 Next.js가 자동으로 생성하는 액션 ID와 오리진 검증을 통해 기본적인 CSRF 보호를 제공하지만, 민감한 작업에는 추가적인 토큰 검증이나 재인증을 요구하는 것이 안전합니다. 또한 중요한 작업에는 POST 메서드를 사용하고 GET 요청에서는 상태 변경을 하지 않는 원칙을 지켜야 합니다.
- • SameSite 쿠키로 기본 보호, XSS 취약점 주의
- • API Routes: CSRF 토큰 생성 및 검증
- • Server Actions: 내장 보호 + 추가 검증
- • 중요 작업은 POST 사용 및 재인증 요구
Next.js 애플리케이션에서 XSS 공격을 방지하기 위해 적용해야 할 Content Security Policy 설정과 dangerouslySetInnerHTML 사용 시 주의사항을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!