Next.js 주니어 기술면접
새 면접Q. Next.js App Router에서 route groups의 개념과 사용 방법을 설명하고, (폴더명) 형태로 만든 폴더가 URL 경로에 영향을 주지 않는 이유와 실무에서 활용할 수 있는 사례를 설명해주세요.
Route groups는 괄호로 감싼 폴더명 (예: (marketing))을 사용하여 URL 경로에 영향을 주지 않고 라우트를 논리적으로 그룹화하는 기능입니다. 괄호로 감싼 폴더는 Next.js가 URL 매핑 시 무시하므로 경로에 포함되지 않습니다. 실무에서는 인증이 필요한 페이지와 공개 페이지를 분리하거나, 마케팅 페이지와 대시보드 페이지를 구분하여 각각 다른 레이아웃을 적용할 때 유용합니다. 또한 팀별로 코드를 조직화하거나 다른 언어별 라우팅을 구성할 때도 활용할 수 있습니다.
- • 괄호로 감싼 폴더명은 URL 경로에 포함되지 않음
- • 라우트를 논리적으로 그룹화하여 코드 조직화 가능
- • 각 그룹마다 다른 레이아웃을 적용할 수 있음
- • 인증 여부, 기능별, 팀별로 페이지를 구분하는 데 활용
여러 개의 route groups에서 같은 URL 경로를 가진 페이지를 만들면 어떤 문제가 발생하나요?
Q. Next.js App Router의 Server Component에서 async/await를 사용하여 데이터를 페칭하는 방법을 설명하고, 기존 Pages Router의 getServerSideProps와 비교했을 때의 차이점을 설명해주세요.
App Router의 Server Component에서는 컴포넌트 함수 자체를 async로 선언하고 내부에서 직접 await fetch()를 사용하여 데이터를 가져올 수 있습니다. 반면 Pages Router의 getServerSideProps는 별도의 함수로 분리되어 있고 props를 통해 컴포넌트에 전달해야 합니다. App Router 방식은 코드가 더 간결하고 직관적이며, 여러 컴포넌트에서 독립적으로 데이터를 페칭할 수 있어 컴포넌트 단위의 데이터 관리가 용이합니다. 또한 자동으로 중복 요청이 제거되는 최적화 기능도 제공됩니다.
- • Server Component 함수를 async로 선언하고 직접 데이터 페칭 가능
- • getServerSideProps보다 코드가 간결하고 직관적
- • 컴포넌트 단위로 독립적인 데이터 페칭 가능
- • 자동 중복 요청 제거(deduplication) 기능 제공
Server Component에서 두 개의 API를 호출할 때 순차적으로 호출하는 것과 병렬로 호출하는 것의 성능 차이를 어떻게 개선할 수 있나요?
Q. 웹 애플리케이션에서 Critical Rendering Path의 개념을 설명하고, Next.js에서 이를 최적화하기 위해 사용할 수 있는 기법들을 설명해주세요.
Critical Rendering Path는 브라우저가 HTML, CSS, JavaScript를 처리하여 화면에 픽셀을 렌더링하기까지의 과정을 의미합니다. DOM 생성, CSSOM 생성, 렌더 트리 구축, 레이아웃, 페인트 단계를 거칩니다. Next.js에서는 SSR/SSG를 통해 초기 HTML을 빠르게 제공하고, 자동 코드 스플리팅으로 필요한 JavaScript만 로드하며, next/font로 폰트 최적화, next/image로 이미지 지연 로딩을 수행합니다. 또한 Script 컴포넌트의 strategy 옵션으로 스크립트 로딩 우선순위를 조절하여 Critical Rendering Path를 최적화할 수 있습니다.
- • 브라우저가 HTML을 화면에 렌더링하기까지의 전체 과정
- • SSR/SSG로 초기 HTML을 빠르게 제공
- • 자동 코드 스플리팅으로 필요한 리소스만 로드
- • next/font, next/image, Script 컴포넌트로 리소스 최적화
render-blocking 리소스란 무엇이며, CSS와 JavaScript가 렌더링을 블로킹하는 방식의 차이점은 무엇인가요?
Q. 데이터베이스 인덱스(Index)의 개념과 동작 원리를 설명하고, Next.js API Routes에서 사용자 검색 기능을 구현할 때 인덱스를 어떻게 활용할 수 있는지 설명해주세요.
데이터베이스 인덱스는 테이블의 특정 컬럼에 대한 검색 속도를 향상시키기 위한 자료구조로, 주로 B-Tree나 Hash 구조로 구현됩니다. 책의 색인처럼 데이터의 위치를 빠르게 찾을 수 있게 해줍니다. Next.js API Routes에서 사용자 이메일이나 이름으로 검색하는 기능을 구현할 때, 해당 컬럼에 인덱스를 생성하면 전체 테이블을 스캔하지 않고 빠르게 결과를 찾을 수 있습니다. 다만 인덱스는 저장 공간을 추가로 사용하고 데이터 삽입/수정/삭제 시 오버헤드가 발생하므로, 자주 조회되는 컬럼에만 선택적으로 적용해야 합니다.
- • 검색 속도를 향상시키는 자료구조 (B-Tree, Hash 등)
- • 전체 테이블 스캔 없이 빠른 데이터 검색 가능
- • 자주 검색되는 컬럼(이메일, 사용자명 등)에 적용
- • 저장 공간과 쓰기 성능 트레이드오프 고려 필요
복합 인덱스(Composite Index)는 무엇이며, 어떤 경우에 단일 인덱스보다 유리한가요?
Q. Next.js App Router에서 Server Component와 Client Component가 혼재된 구조에서 전역 상태 관리 라이브러리(Zustand, Recoil 등)를 사용할 때 주의해야 할 점과 Provider 설정 방법을 설명해주세요.
Server Component는 서버에서 렌더링되므로 클라이언트 전역 상태에 직접 접근할 수 없습니다. 따라서 상태 관리 라이브러리의 Provider는 반드시 Client Component로 만들어야 하며, 'use client' 지시어를 추가해야 합니다. 일반적으로 루트 레이아웃에서 Provider를 감싸되, 레이아웃 자체는 Server Component로 유지하고 별도의 Client Component로 Provider를 분리하는 패턴을 사용합니다. Server Component에서 가져온 초기 데이터를 Client Component의 전역 상태로 hydration하려면 props로 전달한 후 useEffect에서 상태를 초기화하는 방법을 사용합니다.
- • 상태 관리 Provider는 반드시 Client Component로 작성
- • 루트 레이아웃은 Server Component로 유지하고 Provider만 분리
- • Server Component에서 가져온 데이터는 props로 전달 후 hydration
- • 직렬화 가능한 데이터만 Server에서 Client로 전달 가능
Server Actions를 사용하여 클라이언트 상태를 업데이트한 후 서버 데이터를 다시 가져오는 방법은 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!