Next.js 13 (App Router) 예상 면접 질문 (1)

📁 라우팅 및 디렉토리 구조

1. Q: Next.js 13에서 pages/와 app/ 디렉토리의 주요 차이점은 무엇인가요?

A: pages/는 Pages Router로 파일 기반 라우팅과 getStaticProps, getServerSideProps를 사용합니다. 반면 app/은 App Router로 React Server Components(RSC)를 지원하고, layout.tsx 등의 파일로 더 유연한 아키텍처를 제공합니다.

💡 설명:

• App Router는 중첩 레이아웃, 서버 컴포넌트, 스트리밍 등을 지원합니다.
• Pages Router는 기존 방식이며 점차 App Router로 전환되고 있습니다.
• 두 라우팅 시스템은 서로 호환되지 않으므로 프로젝트 구조 선택이 중요합니다.

 

2. Q: app/디렉토리 내의 page.tsx, layout.tsx, loading.tsx의 역할은 무엇인가요?
A: page.tsx는 특정 경로의 실제 콘텐츠 페이지이고, layout.tsx는 해당 경로의 공통 UI를 정의합니다. loading.tsx는 데이터 패칭 중 보여줄 로딩 화면을 정의합니다.

💡 설명:

• layout.tsx는 중첩 가능하며 하위 모든 페이지에 적용됩니다.
• loading.tsx는 해당 디렉토리와 그 하위 디렉토리에만 적용됩니다.
• 이 구조는 사용자 경험 향상과 코드 재사용성에 기여합니다.

 

3. Q: layout.tsx와 _app.tsx의 차이는 무엇인가요?
A: layout.tsx는 App Router에서 경로 단위로 중첩 가능한 레이아웃을 정의합니다. 반면 _app.tsx는 Pages Router에서 모든 페이지에 공통으로 적용되는 글로벌 컴포넌트입니다.
💡 설명:

• layout.tsx는 중첩이 가능하고 route 분기별로 다르게 설정할 수 있습니다.
• _app.tsx는 하나만 존재하며 모든 페이지에 동일하게 적용됩니다.
• App Router에서는 _app.tsx를 사용하지 않습니다.

 

4. Q: error.tsx는 언제, 어떻게 동작하나요?
A: 특정 route나 해당 하위에서 오류가 발생할 경우 error.tsx가 자동으로 렌더링됩니다. 이 파일은 해당 디렉토리 단위에서만 적용됩니다.
💡 설명:

• 서버 컴포넌트/클라이언트 컴포넌트 모두에서 에러 처리 가능
• try/catch와 함께 사용할 수도 있음
• 사용자 경험을 향상시키기 위한 커스텀 에러 페이지 제작 가능

 

5. Q: 동적 라우팅은 App Router에서 어떻게 구현하나요?
A: 폴더명을 [slug]와 같이 대괄호로 감싸서 생성하면 해당 부분이 동적 파라미터로 처리됩니다. params 객체를 통해 해당 값을 사용할 수 있습니다.
💡 설명:

• [id]/page.tsx 형태로 구현
• params.id를 통해 URL 파라미터 접근 가능
• generateStaticParams()와 함께 사용 시 정적 빌드 가능

 

---

 

📁 서버 컴포넌트와 데이터 패칭

 

6. Q: React Server Components(RSC)란 무엇인가요?
A: RSC는 서버에서 렌더링되고 클라이언트에 HTML로 전달되는 컴포넌트입니다. 클라이언트에서 JavaScript를 최소화하여 초기 로딩 성능을 높일 수 있습니다.
💡 설명:

• 서버에서 데이터를 바로 읽고 렌더링 가능
• 클라이언트에 전송되는 JS 크기 감소
• 서버 전용 API 키나 보안 정보를 안전하게 처리 가능

 

7. Q: 클라이언트 컴포넌트에서 fetch를 쓰면 안 되는 이유는 무엇인가요?
A: 클라이언트 컴포넌트는 브라우저에서 실행되므로, 서버 전용 API 키나 비공개 정보를 사용할 수 없습니다. 서버 컴포넌트에서 데이터를 패칭하고 클라이언트로 전달하는 것이 안전합니다.
💡 설명:

• 클라이언트 fetch는 API 키 노출 위험이 있음
• 서버 fetch는 보안과 성능 측면에서 유리함
• 데이터 캐싱, revalidation 등의 기능도 서버 컴포넌트에서 활용 가능

 

8. Q: getStaticProps, getServerSideProps는 App Router에서 어떻게 대체되나요?
A: App Router에서는 이 함수들을 사용하지 않고, 서버 컴포넌트 내에서 직접 fetch()를 통해 데이터를 가져옵니다. 캐싱과 revalidation은 fetch 옵션으로 제어합니다.
💡 설명:

• fetch()에 cache, next.revalidate 옵션 사용
• 더 선언적이고 간결한 방식
• 서버 컴포넌트가 페이지 데이터 패칭의 중심 역할 수행

 

9. Q: fetch()에 cache: 'no-store'를 사용하면 어떤 효과가 있나요?
A: 이 설정은 요청마다 데이터를 새로 가져오는 SSR(Server Side Rendering) 방식으로 동작하게 합니다. 항상 최신 데이터를 보여줘야 하는 경우에 유용합니다.
💡 설명:

• 데이터가 자주 바뀌는 대시보드 등에 적합
• cache: 'force-cache'는 빌드 시 캐시, revalidate는 ISR
• 클라이언트가 아닌 서버 측에서만 작동하는 설정

 

10. Q: generateStaticParams()는 언제 사용되며, 어떤 역할을 하나요?
A: 동적 라우팅 페이지에서 빌드 타임에 필요한 경로 목록을 반환하여 SSG(static generation)를 가능하게 합니다. params 값을 기준으로 정적인 HTML 파일을 생성합니다.
💡 설명:

• App Router에서 getStaticPaths의 대체 기능
• 동적 경로를 정적으로 프리렌더링할 수 있음
• 동적 URL과 SSG를 함께 사용할 수 있는 유용한 메커니즘