Next.js 주니어 코딩 면접
새 면접Q. Next.js에서 fetch 함수를 사용할 때 캐싱 옵션(cache, revalidate)을 설정하는 방법을 설명하고, no-store, force-cache, 그리고 revalidate의 차이점을 실제 사용 시나리오와 함께 설명해주세요.
Next.js 13+ App Router에서 fetch는 기본적으로 force-cache로 동작하며 결과를 캐싱합니다. cache: 'no-store'는 매 요청마다 새로운 데이터를 가져오며 실시간 데이터가 필요한 경우 사용합니다. cache: 'force-cache'는 한 번 캐싱된 데이터를 계속 사용하며 변경이 거의 없는 정적 데이터에 적합합니다. next: { revalidate: 60 }은 60초마다 캐시를 재검증하는 ISR 방식으로, 뉴스나 상품 목록처럼 주기적으로 업데이트가 필요한 데이터에 사용합니다. 이를 통해 성능과 데이터 신선도의 균형을 맞출 수 있습니다.
- • cache: 'no-store'는 캐싱 없이 매번 새로운 데이터 페칭 (실시간 데이터)
- • cache: 'force-cache'는 영구 캐싱으로 정적 데이터에 적합
- • revalidate 옵션은 특정 시간 간격으로 캐시 재검증 (ISR)
- • 사용 시나리오에 따라 적절한 캐싱 전략 선택 필요
동일한 페이지에서 여러 fetch 요청이 있을 때, 각각 다른 캐싱 전략을 적용할 수 있나요? 그리고 이것이 페이지 전체의 렌더링 방식에 어떤 영향을 미치나요?
Q. Next.js App Router에서 error.js와 global-error.js 파일의 역할과 차이점을 설명하고, 이들 파일에서 반드시 'use client' 지시어를 사용해야 하는 이유를 설명해주세요.
error.js는 특정 라우트 세그먼트의 에러를 처리하는 에러 바운더리로, 해당 경로와 하위 경로에서 발생하는 에러를 포착합니다. global-error.js는 루트 레이아웃을 포함한 전체 애플리케이션의 에러를 처리하며, 프로덕션에서만 동작합니다. 두 파일 모두 'use client' 지시어가 필요한 이유는 에러 바운더리가 React의 componentDidCatch 생명주기를 사용하는 클라이언트 측 기능이기 때문입니다. error.js는 error와 reset props를 받아 사용자에게 에러 메시지를 보여주고 재시도 기능을 제공할 수 있습니다.
- • error.js는 특정 라우트 세그먼트의 에러 처리
- • global-error.js는 루트 레이아웃 포함 전체 앱 에러 처리
- • 에러 바운더리는 클라이언트 컴포넌트여야 하므로 'use client' 필수
- • error와 reset props를 통해 에러 정보 표시 및 복구 기능 제공
loading.js와 error.js를 함께 사용할 때, 데이터 페칭 중 에러가 발생하면 어떤 파일이 먼저 렌더링되나요?
Q. Next.js App Router에서 parallel routes와 intercepting routes의 개념을 설명하고, 각각 어떤 파일명 규칙(@folder, (.)folder)을 사용하며 실무에서 어떤 상황에 활용할 수 있는지 설명해주세요.
Parallel routes는 @folder 규칙을 사용하여 동일한 레이아웃 내에서 여러 페이지를 동시에 렌더링하는 기능으로, 대시보드처럼 여러 독립적인 섹션을 동시에 보여줄 때 사용합니다. Intercepting routes는 (.)folder, (..)folder 등의 규칙으로 특정 라우트를 가로채서 모달처럼 표시하는 기능입니다. 예를 들어 이미지 갤러리에서 사진을 클릭하면 모달로 표시하되, URL은 해당 사진의 전체 페이지 경로로 변경되어 공유와 새로고침 시 전체 페이지로 이동할 수 있습니다. 이는 UX 향상과 SEO를 동시에 만족시킵니다.
- • @folder로 parallel routes 생성, 동일 레이아웃에 여러 페이지 동시 렌더링
- • (.)folder로 intercepting routes 생성, 모달 같은 오버레이 UI 구현
- • 대시보드, 갤러리 모달 등 실무 활용 사례 다양
- • URL 공유 가능성과 사용자 경험 모두 개선
Parallel routes에서 각 슬롯(@folder)이 독립적으로 loading 상태와 error 상태를 가질 수 있나요? 그렇다면 어떻게 구현하나요?
Q. Next.js의 middleware.js(또는 middleware.ts) 파일의 역할과 실행 시점을 설명하고, NextResponse.redirect와 NextResponse.rewrite의 차이점을 실제 사용 예시와 함께 설명해주세요.
middleware.js는 요청이 완료되기 전에 서버에서 실행되는 코드로, 인증 확인, 리다이렉트, 헤더 수정, 로깅 등을 수행합니다. 모든 라우트 또는 config.matcher로 지정한 경로에서 실행됩니다. NextResponse.redirect는 사용자를 다른 URL로 이동시키며 브라우저 주소창이 변경됩니다(예: 비로그인 사용자를 로그인 페이지로). NextResponse.rewrite는 URL은 유지한 채 내부적으로 다른 경로의 콘텐츠를 보여줍니다(예: A/B 테스트에서 사용자 그룹에 따라 다른 페이지 제공). redirect는 클라이언트가 인지하는 URL 변경이고, rewrite는 서버 내부의 라우팅 변경입니다.
- • middleware는 요청 완료 전 서버에서 실행되는 코드
- • NextResponse.redirect는 URL 변경을 동반한 페이지 이동
- • NextResponse.rewrite는 URL 유지하며 내부적으로 다른 콘텐츠 제공
- • 인증, A/B 테스트, 국제화 등 다양한 실무 활용
middleware에서 데이터베이스 쿼리를 직접 실행하는 것이 권장되지 않는 이유는 무엇이며, 대신 어떤 방식으로 인증을 확인해야 하나요?
Q. Next.js에서 React.lazy와 dynamic import의 차이점을 설명하고, dynamic 함수의 ssr 옵션과 loading 옵션을 사용하는 이유와 실제 활용 시나리오를 설명해주세요.
React.lazy는 React의 기본 동적 import 기능이지만 SSR을 지원하지 않습니다. Next.js의 dynamic은 React.lazy를 확장하여 SSR 환경에서도 동작하며 추가 옵션을 제공합니다. ssr: false 옵션은 해당 컴포넌트를 클라이언트에서만 렌더링하도록 하여, window 객체나 브라우저 API를 사용하는 라이브러리(차트, 맵 등)를 안전하게 로드할 수 있습니다. loading 옵션은 컴포넌트 로딩 중 표시할 폴백 UI를 지정하여 사용자 경험을 개선합니다. 이를 통해 초기 번들 크기를 줄이고, 필요한 시점에만 코드를 로드하여 성능을 최적화할 수 있습니다.
- • React.lazy는 SSR 미지원, Next.js dynamic은 SSR 환경에서 동작
- • ssr: false로 클라이언트 전용 컴포넌트 처리 (브라우저 API 사용 라이브러리)
- • loading 옵션으로 로딩 중 폴백 UI 제공
- • 번들 크기 감소 및 필요 시점 로딩으로 성능 최적화
dynamic import된 컴포넌트가 여러 페이지에서 사용될 때, Next.js는 자동으로 청크를 재사용하나요? 아니면 각 페이지마다 별도로 로드되나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!