Next.js 미드레벨 코딩 및 설계 면접
새 면접Q. Next.js App Router에서 동적 세그먼트를 사용하는 페이지([id])에서 generateStaticParams를 구현할 때, 전체 데이터가 10만 개 이상인 경우 모든 경로를 사전 생성하는 것은 비효율적입니다. 이런 상황에서 일부 경로만 사전 생성하고 나머지는 온디맨드로 처리하는 전략을 설명하고, dynamicParams 옵션의 역할과 404 처리 전략을 함께 설명해주세요.
generateStaticParams에서 인기 있는 상위 N개의 경로만 반환하여 빌드 타임에 사전 생성하고, dynamicParams를 true(기본값)로 설정하면 사전 생성되지 않은 경로도 런타임에 동적으로 생성됩니다. 존재하지 않는 ID에 대해서는 데이터 페칭 단계에서 null 체크 후 notFound() 함수를 호출하여 404 페이지로 리다이렉트합니다. ISR과 결합하면 처음 요청된 경로도 캐시되어 이후 요청에서 빠르게 응답할 수 있습니다. 이 방식은 빌드 시간을 단축하면서도 SEO와 성능을 모두 확보할 수 있습니다.
- • generateStaticParams에서 인기 경로만 선별적으로 반환
- • dynamicParams: true 설정으로 온디맨드 생성 활성화
- • 데이터 없을 시 notFound() 호출로 404 처리
- • ISR과 결합하여 동적 생성된 경로도 캐싱
generateStaticParams가 반환하는 배열의 크기가 매우 클 때 메모리 문제를 방지하기 위한 방법은 무엇인가요?
Q. Next.js App Router에서 error.tsx와 global-error.tsx의 차이점을 설명하고, 에러 바운더리가 Server Components의 에러를 어떻게 포착하는지 설명해주세요. 또한 에러 복구를 위한 reset 함수의 동작 원리와 한계점을 설명해주세요.
error.tsx는 해당 세그먼트와 하위 세그먼트의 에러를 포착하지만 같은 레벨의 layout.tsx 에러는 포착하지 못하며, global-error.tsx는 루트 레이아웃의 에러까지 포착합니다. Server Components에서 발생한 에러는 서버에서 직렬화되어 클라이언트의 에러 바운더리로 전달됩니다. reset 함수는 에러 바운더리 내부 상태를 초기화하고 세그먼트를 리렌더링하지만, 서버 측 데이터나 상태는 복구하지 못하므로 데이터 재페칭이 필요한 경우 router.refresh()를 함께 사용해야 합니다.
- • error.tsx는 하위 에러만, global-error.tsx는 루트 레이아웃 에러까지 포착
- • Server Components 에러는 직렬화되어 클라이언트로 전달
- • reset 함수는 클라이언트 상태만 초기화
- • 서버 데이터 재페칭을 위해 router.refresh() 필요
에러 바운더리에서 포착할 수 없는 에러 유형에는 어떤 것들이 있나요?
Q. Next.js 애플리케이션에서 여러 사용자 액션이 동시에 발생하여 동일한 상태를 업데이트할 때 발생할 수 있는 Race Condition 문제를 설명하고, useTransition과 AbortController를 활용하여 이를 해결하는 방법을 설명해주세요. 또한 낙관적 업데이트와 함께 사용할 때의 롤백 전략도 함께 설명해주세요.
Race Condition은 이전 요청이 완료되기 전에 새 요청이 발생하여 응답 순서가 보장되지 않을 때 발생합니다. useTransition의 isPending 상태로 진행 중인 트랜지션을 추적하고, AbortController를 사용해 이전 요청을 취소함으로써 최신 요청만 처리되도록 합니다. 낙관적 업데이트 시에는 이전 상태를 스냅샷으로 저장하고, 요청 실패나 취소 시 저장된 스냅샷으로 롤백합니다. useOptimistic 훅을 사용하면 낙관적 상태와 실제 상태를 분리하여 관리할 수 있어 더 안전한 롤백이 가능합니다.
- • Race Condition은 비동기 요청의 응답 순서 불일치로 발생
- • useTransition으로 트랜지션 추적, AbortController로 이전 요청 취소
- • 이전 상태 스냅샷 저장 후 실패 시 롤백
- • useOptimistic으로 낙관적 상태와 실제 상태 분리 관리
여러 컴포넌트에서 동일한 리소스를 동시에 업데이트할 때 서버 측에서 동시성을 제어하는 방법은 무엇인가요?
Q. Next.js에서 dynamic import를 사용할 때 ssr 옵션을 false로 설정하는 경우와 true로 유지하는 경우의 차이점을 설명하고, 각각 어떤 상황에서 사용해야 하는지 설명해주세요. 또한 loading 컴포넌트와 Suspense의 관계, 그리고 번들 크기에 미치는 영향을 분석해주세요.
ssr: false로 설정하면 해당 컴포넌트는 클라이언트에서만 렌더링되어 SSR 시 번들에 포함되지 않으며, window 객체에 의존하는 라이브러리나 브라우저 전용 기능을 사용할 때 적합합니다. ssr: true(기본값)는 서버에서도 렌더링되지만 코드 스플리팅으로 초기 번들 크기를 줄입니다. loading 옵션은 내부적으로 Suspense를 사용하며, 동적 컴포넌트 로딩 중 fallback UI를 표시합니다. 번들 분석 시 ssr: false는 클라이언트 번들만 영향을 받지만, ssr: true는 서버와 클라이언트 번들 모두에 영향을 미칩니다.
- • ssr: false는 클라이언트 전용 렌더링, 브라우저 API 사용 시 필요
- • ssr: true는 서버/클라이언트 모두 렌더링하되 코드 스플리팅 적용
- • loading 옵션은 내부적으로 Suspense 사용
- • ssr 설정에 따라 서버/클라이언트 번들 크기 영향 상이
여러 개의 dynamic import를 사용할 때 Webpack의 매직 코멘트를 활용한 청크 그룹핑 전략을 설명해주세요.
Q. Next.js App Router에서 Server Actions를 사용한 폼 제출 시 클라이언트 측 유효성 검증과 서버 측 유효성 검증을 모두 구현해야 하는 이유를 설명하고, useFormState와 useFormStatus를 활용한 점진적 향상(Progressive Enhancement) 패턴을 설명해주세요. 또한 파일 업로드와 함께 처리할 때의 주의사항도 설명해주세요.
클라이언트 검증은 사용자 경험 향상을 위한 즉각적인 피드백을 제공하지만 우회 가능하므로, 서버 검증은 보안과 데이터 무결성을 위해 필수입니다. useFormState는 Server Action의 반환값을 상태로 관리하여 에러 메시지를 표시하고, useFormStatus는 폼 제출 중 로딩 상태를 제공합니다. JavaScript 비활성화 시에도 기본 폼 제출로 동작하는 점진적 향상이 가능합니다. 파일 업로드 시 FormData에서 파일을 추출하고 크기 제한을 서버에서 검증해야 하며, 대용량 파일은 스트리밍이나 청크 업로드를 고려해야 합니다.
- • 클라이언트 검증은 UX, 서버 검증은 보안과 무결성 보장
- • useFormState로 에러 상태 관리, useFormStatus로 로딩 상태 추적
- • JavaScript 없이도 동작하는 점진적 향상 지원
- • 파일 업로드 시 서버에서 크기 및 타입 검증 필수
Server Actions에서 CSRF 공격을 방지하기 위해 Next.js가 내부적으로 사용하는 메커니즘은 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!