Next.js 미드레벨 프레임워크 심화면접
새 면접Q. Next.js 13+ App Router에서 Parallel Routes와 Intercepting Routes의 개념을 설명하고, 각각의 실무 활용 사례를 제시해주세요. 또한 이 두 기능을 함께 사용할 때의 장점을 설명해주세요.
Parallel Routes는 @folder 규칙을 사용해 같은 레이아웃 내에서 여러 페이지를 동시에 렌더링하는 기능으로, 대시보드에서 여러 섹션을 독립적으로 로딩하거나 조건부 렌더링에 활용됩니다. Intercepting Routes는 (.)folder 규칙으로 현재 컨텍스트에서 다른 라우트를 가로채 모달처럼 표시하며, 이미지 갤러리에서 이미지 클릭 시 모달로 표시하되 URL은 변경하는 패턴에 적합합니다. 두 기능을 결합하면 모달을 Parallel Route로 구성하고 Intercepting으로 제어하여 UX를 해치지 않으면서도 독립적인 URL을 유지할 수 있습니다. 이를 통해 뒤로가기 버튼이 자연스럽게 동작하고, 직접 URL 접근 시에는 전체 페이지로 표시되는 우아한 라우팅 전략을 구현할 수 있습니다.
- • Parallel Routes는 @folder로 동시 렌더링, 독립적 로딩 상태 관리
- • Intercepting Routes는 (.)folder로 라우트 가로채기, 모달 패턴 구현
- • 두 기능 결합 시 URL 유지하면서 모달 UX 제공, 직접 접근 시 전체 페이지 표시
Parallel Routes에서 각 슬롯의 에러 처리와 로딩 상태를 독립적으로 관리하는 방법과, unmatched routes를 처리하는 default.js의 역할을 설명해주세요.
Q. Next.js App Router에서 Server Components와 Client Components의 경계를 설정할 때 고려해야 할 사항들을 설명하고, Suspense를 활용한 Streaming SSR의 동작 원리와 TTFB, FCP, TTI 메트릭에 미치는 영향을 분석해주세요.
Server Components는 기본값으로 서버에서만 실행되어 번들 크기를 줄이고 직접 DB 접근이 가능하지만, 상태나 이벤트 핸들러를 사용할 수 없으므로 'use client' 지시어로 클라이언트 경계를 최소화하여 설정해야 합니다. Streaming SSR은 Suspense 경계를 기준으로 페이지를 청크로 나눠 준비된 부분부터 HTML을 스트리밍하며, React는 서버에서 renderToPipeableStream을 사용해 비동기적으로 컴포넌트를 렌더링합니다. TTFB는 초기 HTML 청크가 빠르게 전송되어 개선되고, FCP는 Suspense fallback이 먼저 표시되어 빨라지며, TTI는 중요한 컴포넌트를 우선 hydration하여 전체적으로 향상됩니다. 느린 데이터 fetching을 Suspense로 감싸면 나머지 페이지는 차단되지 않고, Selective Hydration을 통해 사용자 인터랙션이 있는 부분부터 우선 interactive하게 만듭니다.
- • Server Components는 서버 전용 실행으로 번들 감소, Client Components는 'use client'로 최소 경계 설정
- • Streaming SSR은 Suspense 기준 청크 분할, renderToPipeableStream으로 비동기 HTML 전송
- • TTFB/FCP 개선(초기 청크 빠른 전송), TTI 향상(Selective Hydration으로 우선순위 처리)
Server Components에서 Client Components로 props를 전달할 때 직렬화 제약사항과, Server Actions를 사용해 서버 함수를 클라이언트로 전달하는 패턴의 내부 동작 원리를 설명해주세요.
Q. Next.js App Router의 다층 캐싱 전략(Request Memoization, Data Cache, Full Route Cache, Router Cache)을 각각 설명하고, fetch 함수의 cache와 next.revalidate 옵션이 이 캐시 레이어들에 미치는 영향을 분석해주세요.
Request Memoization은 단일 렌더링 주기 내에서 동일한 URL과 옵션의 fetch 요청을 자동으로 중복 제거하며 React의 기능으로 서버 컴포넌트 트리 전체에서 동작합니다. Data Cache는 서버 측에서 fetch 결과를 영구 저장하며 빌드 타임과 런타임 모두에서 유지되고, fetch의 cache 옵션(force-cache, no-store)으로 제어됩니다. Full Route Cache는 빌드 타임에 정적으로 렌더링된 라우트의 RSC Payload와 HTML을 서버에 캐싱하며, 동적 함수 사용이나 dynamic='force-dynamic' 설정 시 비활성화됩니다. Router Cache는 클라이언트 측 메모리에 RSC Payload를 저장하여 네비게이션 시 재사용하며, 정적 라우트는 5분, 동적 라우트는 30초 동안 유지됩니다. fetch의 next.revalidate는 Data Cache와 Full Route Cache의 재검증 주기를 설정하며, revalidatePath나 revalidateTag를 사용하면 온디맨드로 캐시를 무효화할 수 있습니다.
- • 4계층 캐싱: Request Memoization(렌더링 중 중복 제거), Data Cache(fetch 영구 저장), Full Route Cache(빌드 결과), Router Cache(클라이언트 메모리)
- • fetch cache 옵션은 Data Cache 제어, next.revalidate는 Data/Full Route Cache 재검증 주기 설정
- • 동적 함수 사용 시 Full Route Cache 비활성화, revalidatePath/Tag로 온디맨드 무효화
unstable_cache API의 동작 방식과 fetch를 사용하지 않는 데이터베이스 쿼리나 CMS 호출을 캐싱하는 전략을 설명하고, 캐시 태그를 활용한 세밀한 무효화 패턴을 제시해주세요.
Q. Next.js Middleware의 실행 시점과 제약사항을 설명하고, Edge Runtime과 Node.js Runtime의 차이점을 비교해주세요. 또한 Middleware에서 인증 처리를 구현할 때 성능을 고려한 설계 전략을 제시해주세요.
Middleware는 모든 요청이 라우트에 도달하기 전에 Edge Runtime에서 실행되며, 매칭되는 경로마다 한 번씩 실행되어 리다이렉트, 리라이트, 헤더 수정 등을 처리합니다. Edge Runtime은 V8 Isolate 기반으로 전 세계 엣지 로케이션에서 실행되어 지연시간이 짧지만, Node.js API와 네이티브 모듈을 사용할 수 없고 실행 시간 제한과 메모리 제약이 있습니다. 반면 Node.js Runtime은 전체 Node.js API를 사용할 수 있지만 중앙 서버에서 실행되어 지리적 지연이 발생할 수 있습니다. Middleware에서 인증 처리 시 JWT 검증은 엣지에서 빠르게 수행하되, 세션 토큰만 검증하고 상세한 권한 체크는 라우트 핸들러나 Server Component에서 처리하며, NextResponse.next()로 인증 정보를 헤더에 추가해 전달하는 패턴을 사용합니다. 또한 공개 라우트는 matcher 설정으로 제외하여 불필요한 실행을 방지해야 합니다.
- • Middleware는 라우트 전 Edge Runtime에서 실행, 리다이렉트/리라이트/헤더 수정 처리
- • Edge Runtime은 V8 Isolate 기반 저지연, Node.js API 제약, Node.js Runtime은 전체 API 사용 가능
- • 인증은 엣지에서 토큰 검증만, 상세 권한은 라우트에서, matcher로 공개 경로 제외
Middleware에서 geo 정보를 활용한 지역별 라우팅 전략과, A/B 테스트를 구현할 때 쿠키와 헤더를 조합하는 방법을 설명해주세요.
Q. Next.js App Router에서 Server Actions의 동작 원리를 설명하고, 기존 API Routes와 비교했을 때의 장단점을 분석해주세요. 또한 Server Actions에서 낙관적 업데이트(Optimistic Updates)를 구현하는 패턴을 설명해주세요.
Server Actions는 'use server' 지시어로 표시된 비동기 함수로, 클라이언트 컴포넌트에서 직접 호출 가능하며 Next.js가 자동으로 POST 엔드포인트를 생성하고 직렬화를 처리합니다. 폼 액션이나 이벤트 핸들러에서 직접 서버 함수를 호출할 수 있어 API 라우트를 별도로 만들 필요가 없고, Progressive Enhancement로 JavaScript 없이도 작동하며, 자동 재검증과 캐시 무효화를 지원합니다. 반면 API Routes는 RESTful 설계에 적합하고 외부 서비스에서 호출 가능하며, 미들웨어 체인 구성이 명시적이지만 클라이언트-서버 간 타입 안정성이 상대적으로 약합니다. 낙관적 업데이트는 useOptimistic 훅을 사용해 구현하며, 서버 액션 호출 전 UI를 즉시 업데이트하고 액션이 완료되면 실제 데이터로 대체하되, 실패 시 이전 상태로 롤백하고 에러 토스트를 표시하는 패턴을 사용합니다. startTransition으로 감싸 논블로킹 업데이트를 보장하고, revalidatePath로 서버 데이터를 동기화합니다.
- • Server Actions는 'use server'로 서버 함수 직접 호출, 자동 엔드포인트 생성, 타입 안정성 제공
- • API Routes 대비 장점은 간결한 코드와 Progressive Enhancement, 단점은 외부 호출 불가
- • useOptimistic 훅으로 즉시 UI 업데이트, startTransition 사용, 실패 시 롤백 처리
Server Actions에서 파일 업로드를 처리할 때 FormData를 다루는 방법과, 대용량 파일 업로드 시 스트리밍과 청크 처리 전략을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!