Next.js 면접 질문

Next.js는 React 기반의 프레임워크입니다. 주로 웹 애플리케이션의 성능 최적화와 SEO(검색 엔진 최적화) 개선을 위해 사용됩니다.

Next.js의 가장 큰 특징은 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG)을 지원한다는 점입니다. SSR을 통해 초기 로딩 속도를 개선하고, 검색 엔진 크롤러가 페이지 내용을 더 잘 파악할 수 있도록 돕습니다. SSG는 빌드 시점에 HTML 파일을 미리 생성하여 사용자에게 빠르게 제공할 수 있습니다.

또한, Next.js는 파일 기반 라우팅을 제공하여 개발자가 직관적으로 페이지를 구성하고 관리할 수 있도록 지원합니다. React의 생산성과 SSR, SSG의 성능 이점을 결합하여 사용자 경험을 향상시키는 데 효과적인 프레임워크입니다.

React와 Next.js의 가장 큰 차이점은 React가 UI를 만들기 위한 라이브러리인 반면, Next.js는 React를 기반으로 하는 프레임워크라는 점입니다.

React는 주로 클라이언트 측 렌더링(CSR)에 집중하여 브라우저에서 UI를 동적으로 생성합니다. 반면 Next.js는 서버 측 렌더링(SSR)을 기본적으로 지원하여 초기 로딩 속도를 개선하고 SEO에 유리합니다. 또한, Next.js는 파일 기반 라우팅, API 라우트, 이미지 최적화 등 웹 애플리케이션 개발에 필요한 다양한 기능을 내장하고 있어 개발 생산성을 크게 높여줍니다. 간단히 말해, React는 벽돌이고 Next.js는 그 벽돌로 집을 짓는 데 필요한 설계도와 도구를 모두 제공하는 것입니다.

Pre-rendering은 Next.js에서 페이지를 렌더링하는 방식 중 하나입니다. 기본적으로 브라우저에서 JavaScript를 실행해서 페이지를 그리는 대신, 서버에서 각 페이지에 대한 HTML을 미리 생성해두는 것을 의미합니다.

이렇게 하면 사용자가 페이지에 처음 접속했을 때, 이미 완성된 HTML을 받기 때문에 초기 로딩 속도가 빨라집니다. 또, 검색 엔진 크롤러가 JavaScript 실행 없이 내용을 파악할 수 있어서 SEO에도 유리합니다.

Pre-rendering 방식에는 크게 두 가지가 있는데, 빌드 시점에 HTML을 생성하는 Static Site Generation(SSG)과 요청이 있을 때마다 HTML을 생성하는 Server-Side Rendering(SSR)이 있습니다. 상황에 맞춰 적절한 방식을 선택하여 사용할 수 있습니다.

Next.js가 일반적인 React SPA보다 SEO에 유리한 이유는 SSR, 즉 서버 사이드 렌더링을 지원하기 때문입니다.

일반적인 React SPA는 브라우저에서 JavaScript를 실행해야 콘텐츠가 렌더링되는데, 일부 검색 엔진 크롤러는 JavaScript 실행에 어려움을 겪거나 시간이 오래 걸릴 수 있습니다.

반면 Next.js는 서버에서 미리 HTML을 렌더링하여 제공하므로, 크롤러가 JavaScript 실행 없이도 페이지의 콘텐츠를 즉시 수집할 수 있습니다. 이는 검색 엔진 최적화에 매우 중요합니다.

또한, Next.js는 초기 로딩 속도를 개선하여 사용자 경험을 향상시키고, 메타 데이터 관리를 용이하게 하여 SEO 친화적인 웹사이트를 구축하는 데 도움을 줍니다.

Next.js에서 하이드레이션은 서버에서 미리 렌더링된 HTML 마크업을 React가 클라이언트 측에서 "인수"하는 과정이라고 생각하시면 됩니다.

좀 더 자세히 설명드리면, 서버에서 초기 HTML을 만들어서 브라우저에 보내면, 브라우저는 이 HTML을 화면에 표시합니다. 이때는 그냥 정적인 화면일 뿐이죠.

하이드레이션 과정에서 React는 이 정적인 HTML 구조를 분석하고, 해당 HTML에 연결된 React 컴포넌트를 찾아서 연결합니다. 그리고 각 컴포넌트에 필요한 이벤트 핸들러들을 부착해서, 사용자와 상호작용할 수 있도록 만들어줍니다.

쉽게 말해, 서버에서 만들어진 정적인 HTML 페이지에 React가 생명력을 불어넣어서, 동적인 웹 애플리케이션으로 만들어주는 과정이라고 할 수 있습니다. 이 과정을 통해 초기 로딩 속도를 개선하고, SEO에도 유리하게 만들 수 있습니다.

Next.js의 기본 포트 번호는 3000번입니다. 이 포트 번호를 변경하는 방법은 크게 세 가지가 있습니다.

첫 번째는 CLI 명령어를 사용하는 방법입니다. next dev -p <원하는 포트 번호> 와 같이 실행하면 개발 서버가 지정된 포트에서 실행됩니다. 예를 들어 4000번 포트로 실행하고 싶다면 next dev -p 4000 이라고 입력하면 됩니다.

두 번째는 .env 파일을 사용하는 방법입니다. .env 파일에 PORT=<원하는 포트 번호> 와 같이 설정하면 Next.js가 해당 포트를 사용합니다.

마지막으로 next.config.js 파일을 수정하는 방법도 있습니다. serverRuntimeConfig 또는 publicRuntimeConfig를 사용하여 포트 번호를 설정할 수 있지만, 이 방법은 서버 설정을 변경하는 것이므로 주의해야 합니다. 주로 배포 환경에서 포트 번호를 설정할 때 사용합니다.

프로덕션 환경을 위한 Next.js 빌드 및 실행 명령어는 다음과 같습니다.

먼저, next build 명령어를 사용하여 애플리케이션을 빌드합니다. 이 명령어는 Next.js 애플리케이션을 최적화하고 프로덕션 환경에 배포할 수 있도록 준비합니다. 빌드 과정에서 환경 변수를 설정하여 프로덕션 환경에 맞는 설정을 적용할 수 있습니다. 예를 들어, API 엔드포인트 주소나 데이터베이스 연결 정보를 설정할 수 있습니다.

빌드가 완료되면, next start 명령어를 사용하여 프로덕션 서버를 실행합니다. 이 명령어는 빌드된 애플리케이션을 실행하고, 클라이언트 요청을 처리합니다. next start 명령어는 포트 번호와 같은 추가적인 옵션을 지원합니다.

배포 자동화를 위해 CI/CD 파이프라인을 구축하고, Docker를 사용하여 컨테이너화하는 것을 고려할 수 있습니다. 또한, 애플리케이션의 성능과 상태를 모니터링하기 위해 로깅 및 모니터링 시스템을 구축하는 것이 좋습니다.

App Router에서 Server Component에서 Client Component로 Props를 전달할 때 직렬화 에러가 발생하는 주된 이유는 서버에서 클라이언트로 데이터를 전송할 때 JSON 형태로 직렬화되기 때문입니다.

JSON은 JavaScript의 모든 데이터 타입을 지원하지 않습니다. 특히 함수(Function)나 Date 객체, Symbol과 같은 JavaScript 고유의 타입은 JSON으로 변환할 수 없습니다.

따라서 Server Component에서 이러한 타입의 데이터를 Props로 Client Component에 넘기려고 하면 직렬화 과정에서 에러가 발생합니다. 해결책으로는 이러한 데이터를 문자열이나 숫자와 같이 JSON으로 표현 가능한 형태로 변환하여 Props로 전달하는 방법이 있습니다. 예를 들어 Date 객체는 toISOString() 메서드를 사용하여 문자열로 변환할 수 있습니다.

음, Client Component 안에서 Server Component를 직접 import해서 자식으로 사용하면 예상치 못한 문제가 발생할 수 있습니다. Next.js는 Server Component를 서버에서 렌더링하고, Client Component는 브라우저에서 렌더링하는데, 직접 import하면 Server Component가 클라이언트 번들에 포함되어 버립니다.

이렇게 되면 Server Component의 장점인 서버 측 데이터 접근이나 보안상의 이점을 활용할 수 없게 되고, 불필요하게 클라이언트 번들 크기가 커지는 문제가 생깁니다. 또, Server Component에서만 사용할 수 있는 코드가 클라이언트에서 실행되면서 에러가 발생할 수도 있고요.

이 문제를 해결하는 일반적인 방법은 컴포넌트 합성 패턴을 사용하는 겁니다. Server Component를 Client Component의 children prop으로 전달하는 거죠. 예를 들어, Server Component에서 데이터를 가져와서 Client Component에 props로 전달하고, Client Component는 단순히 UI를 렌더링하는 방식으로 분리하는 겁니다. 이렇게 하면 Server Component는 서버에서 안전하게 실행되고, Client Component는 필요한 데이터만 받아서 렌더링할 수 있습니다.

App Router 환경에서 fetch API를 사용할 때 캐싱을 비활성화하고 매 요청마다 서버에서 데이터를 가져오려면 cache: 'no-store' 옵션을 사용합니다.

fetch 함수의 두 번째 인자로 { cache: 'no-store' }를 전달하면 Next.js는 해당 요청에 대한 응답을 캐싱하지 않습니다. 이렇게 하면 서버 컴포넌트에서 데이터를 가져올 때 항상 최신 데이터를 가져올 수 있습니다.

const data = await fetch('api/data', { cache: 'no-store' });

또 다른 방법으로는 revalidate: 0을 사용하는 방법도 있지만, cache: 'no-store'가 캐싱을 완전히 비활성화하는 더 확실한 방법입니다. dynamic 키워드를 사용하여 페이지 또는 컴포넌트를 dynamic rendering하도록 설정하는 것도 같은 효과를 낼 수 있습니다. SSR 환경에서 데이터를 동적으로 가져올 때 유용합니다.

App Router에서 특정 경로를 항상 동적으로 렌더링하도록 강제하려면 route segment config를 사용합니다. 파일 레벨에서 export const dynamic = 'force-dynamic'을 선언하면 됩니다.

dynamic이라는 변수를 export하고, 그 값을 'force-dynamic'으로 설정하는 것이 핵심입니다. 이렇게 하면 Next.js는 해당 경로를 빌드 시에 정적으로 생성하지 않고, 요청이 들어올 때마다 서버에서 동적으로 렌더링합니다. 캐싱을 무효화하고 항상 최신 데이터를 보여줘야 할 때 유용합니다.

Next.js 미들웨어에서 특정 경로에만 적용되도록 필터링하는 설정 객체의 속성은 matcher입니다. middleware.ts 파일에서 config 객체를 정의하고, 그 안에 matcher 속성을 배열 형태로 지정하여 적용할 경로를 설정할 수 있습니다.

matcher 배열 안에는 문자열 경로 또는 정규식을 사용할 수 있습니다. 예를 들어, /about 경로와 /blog/:path* 경로에만 미들웨어를 적용하고 싶다면 다음과 같이 설정할 수 있습니다.

export const config = {
  matcher: ['/about', '/blog/:path*'],
};

이렇게 설정하면 지정된 경로에 접근할 때만 미들웨어가 실행되고, 다른 경로에서는 실행되지 않습니다. 정규식을 사용하면 더욱 복잡한 패턴 매칭도 가능합니다.

미들웨어에서 조건부 리다이렉트를 하려면 NextResponse 클래스의 redirect 메서드를 사용해야 합니다. NextResponse.redirect()는 새로운 URL로 리다이렉트하는 응답 객체를 반환합니다.

예를 들어, 로그인하지 않은 사용자를 로그인 페이지로 리다이렉트하려면 다음과 같이 할 수 있습니다.

import { NextResponse } from 'next/server';

export function middleware(request) {
  const isLoggedIn = // 로그인 여부 확인 로직
  if (!isLoggedIn) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
}

여기서 new URL('/login', request.url)은 로그인 페이지의 절대 URL을 생성하는 데 사용됩니다. request.url은 현재 요청 URL을 기반으로 하기 때문에, 올바른 도메인과 프로토콜을 유지하면서 리다이렉트할 수 있습니다.

App Router에서 동적 라우팅 파라미터에 접근하려면 Route Handler 함수의 두 번째 매개변수를 활용해야 합니다.

함수를 정의할 때 request와 함께 context 객체를 받도록 선언하고, context 객체 안의 params 속성을 통해 동적 라우트 세그먼트에 접근할 수 있습니다. 예를 들어 app/api/[id]/route.ts에서 id 값에 접근하려면 export async function GET(request: NextRequest, { params }: { params: { id: string } }) 와 같이 함수를 정의하고, params.id를 사용하면 됩니다.

타입스크립트를 사용한다면 params의 타입을 명시적으로 정의하여 타입 안정성을 확보하는 것이 좋습니다.

RSC Payload는 서버 컴포넌트 렌더링 결과를 담은 일종의 데이터 스트림입니다. JSON과 비슷하지만, 줄바꿈으로 구분된 형태를 띠고 있어요.

내부적으로는 렌더링된 컴포넌트 트리 구조를 표현하고, 클라이언트 컴포넌트에 대한 참조 정보, 그리고 직렬화된 Props를 포함합니다. 예를 들어, 특정 컴포넌트의 ID와 그 위치에 삽입될 클라이언트 컴포넌트의 모듈 참조, 그리고 해당 컴포넌트에 전달될 Props가 함께 담겨있는 것이죠.

이 Payload는 클라이언트에서 파싱되어 실제 UI를 구성하는 데 사용됩니다. 서버에서 렌더링된 초기 상태를 빠르게 보여주고, 필요한 부분만 클라이언트에서 업데이트하는 방식으로 동작하게 됩니다.

RSC 페이로드를 클라이언트에서 받아 DOM과 병합하는 과정은 복합적으로 이루어집니다. 핵심적인 React API는 ReactDOM.hydrateRoot와 use 훅입니다.

ReactDOM.hydrateRoot는 서버에서 렌더링된 HTML을 초기 렌더링 시점에 클라이언트에서 "hydration"하는 역할을 합니다. 즉, 서버에서 생성된 DOM 구조를 기반으로 React 컴포넌트를 연결하고 이벤트 리스너를 부착하여 인터랙티브하게 만듭니다.

RSC 페이로드는 use 훅을 통해 비동기적으로 로드되고, React는 Suspense 바운더리를 사용하여 로딩 상태를 관리합니다. use 훅은 RSC에서 반환된 Promise를 처리하고, 데이터가 준비되면 컴포넌트를 업데이트합니다. 이 과정에서 React는 기존 DOM과 새로운 React Element Tree를 비교하여 필요한 부분만 업데이트하는 Reconciliation 과정을 거칩니다. useTransition이나 useDeferredValue를 사용하여 업데이트 우선순위를 조절하여 사용자 경험을 개선할 수도 있습니다.

Next.js 14의 Partial Prerendering 환경에서 특정 컴포넌트를 동적으로 렌더링하도록 트리거하는 가장 일반적인 React API는 Next.js에서 제공하는 useSearchParams, useCookies, 그리고 headers()와 cookies() 함수입니다.

이 함수들을 컴포넌트 내에서 호출하면 Next.js는 해당 컴포넌트가 요청 시간에 따라 달라지는 정보를 필요로 한다고 판단합니다. 따라서 해당 컴포넌트는 정적으로 사전 렌더링되지 않고, Suspense 바운더리 내에서 동적으로 렌더링되어 스트리밍됩니다. 예를 들어, useSearchParams를 사용하여 URL 쿼리 파라미터를 읽거나, headers()를 사용하여 요청 헤더에 접근하는 경우, 해당 컴포넌트는 동적 렌더링됩니다.

Next.js의 Data Cache 무효화 방식은 크게 두 가지로 나눌 수 있습니다.

기본적으로는 Stale-while-revalidate 전략을 사용합니다. 즉, 캐시가 만료되면 다음 요청이 발생했을 때 백그라운드에서 새로운 데이터를 가져옵니다. 사용자는 즉시 기존 캐시 데이터를 보게 되고, 백그라운드 업데이트가 완료되면 다음 요청부터는 새로운 데이터를 보게 됩니다.

On-demand revalidation을 사용하는 경우, revalidatePath나 revalidateTag를 통해 특정 경로 또는 태그를 가진 데이터를 명시적으로 무효화할 수 있습니다. 이 경우에도 다음 요청이 발생했을 때 데이터가 갱신됩니다. 즉시 백그라운드에서 데이터를 가져오는 것은 아닙니다.

Incremental Static Regeneration (ISR)을 사용할 때도 마찬가지로, 지정된 revalidate 시간 간격 이후에 다음 요청이 발생했을 때 백그라운드에서 데이터가 업데이트됩니다.

Edge Runtime 환경에서 미들웨어가 Vercel KV나 데이터베이스에 접근할 때 지연 시간을 줄이는 핵심은 **데이터 지역성(Data Locality)**과 **콜로케이션(Colocation)**입니다.

미들웨어는 사용자와 가장 가까운 엣지 노드에서 실행되기 때문에, 데이터베이스 역시 엣지 네트워크 내에 위치하거나, 엣지 노드와 최대한 가까운 리전에 위치시키는 것이 중요합니다. 이를 통해 네트워크 왕복 시간을 최소화할 수 있습니다.

Vercel KV와 같은 엣지 데이터 저장소를 사용하는 경우, 미들웨어와 데이터베이스가 동일한 엣지 네트워크에 위치하게 되어 초저지연 성능을 확보할 수 있습니다. 또한, Connection Pooling을 통해 데이터베이스 연결을 재사용하여 연결 설정에 소요되는 시간을 줄이는 것도 중요합니다.

결론적으로, 엣지 함수와 데이터베이스의 물리적 거리를 최소화하고, 효율적인 연결 관리 전략을 사용하는 것이 핵심입니다.

네, 좋은 질문입니다. 대규모 Next.js 프로젝트를 Turborepo 모노레포로 분리했을 때, 공통 UI 컴포넌트 패키지를 사용하려면 next.config.js 파일에 transpilePackages 속성을 추가해야 합니다.

transpilePackages는 Next.js에게 특정 패키지들을 트랜스파일하도록 지시합니다. 예를 들어 @repo/ui 패키지를 사용한다면, transpilePackages: ['@repo/ui']와 같이 설정합니다.

이렇게 하면 Next.js의 Webpack 또는 Turbopack이 해당 패키지의 코드를 번들링 과정에 포함시켜, 모노레포 구조 내에서도 UI 컴포넌트가 문제없이 동작하도록 할 수 있습니다. 이 설정을 통해 Next.js 앱이 외부 패키지 내의 최신 JavaScript 기능을 이해하고 실행할 수 있게 됩니다.

Node.js 기반 Next.js 앱에서 메모리 누수가 의심된다면, V8 엔진의 힙(Heap) 메모리 영역을 가장 먼저 모니터링해야 합니다. 힙은 가비지 컬렉터(GC)가 관리하는 동적 할당 메모리 영역으로, JavaScript 객체, 문자열 등이 저장됩니다.

메모리 누수는 더 이상 사용하지 않는 객체가 힙에 계속 남아있어 메모리 사용량이 지속적으로 증가하는 현상입니다. 따라서 힙 메모리 사용량이 GC 이후에도 계속 증가한다면 메모리 누수를 의심해 볼 수 있습니다.

힙 메모리 스냅샷을 찍어 어떤 객체들이 메모리를 많이 차지하고 있는지 분석하거나, Node.js의 내장 모니터링 도구 또는 외부 프로파일링 도구를 사용하여 힙 메모리 사용 패턴을 분석하는 것이 좋습니다.