NextJS 와 서버리스

해당 글은 NextJS 의 대표적인 배포 방식 중 하나인 Vercel 환경에서 발생하는 콜드스타트 현상에 대해 궁금하여 정리한 글 입니다.

서버리스(Serverless) 란?

서버리스 컴퓨팅은 개발자가 서버 인프라를 직접 관리하지 않고도 애플리케이션을 실행할 수 있게 해주는 클라우드 컴퓨팅 실행 모델입니다.

서버리스의 주요 특징

1) 인프라 관리 불필요

• 서버 프로비저닝, 스케일링, 패치 등을 클라우드 제공자가 담당
• 개발자는 순수하게 코드 개발에만 집중 가능

2) 자동 스케일링

• 트래픽에 따라 자동으로 확장/축소
• 사용량에 따른 비용 지불 (pay-as-you-go)

3) 이벤트 기반 실행

• 특정 이벤트나 트리거에 반응하여 함수 실행
• 유휴 시간 동안 비용 발생하지 않음

이러한 특징들로 생각해봤을때, 서버리스의 "필요할 때만 실행하고 과금한다". 라는 것으로 효율적인 서버관리 방법인 것 같습니다.

대표적인 서버리스 서비스

AWS Lambda

• 가장 널리 사용되는 서버리스 컴퓨팅 서비스
• 다양한 프로그래밍 언어 지원 (Node.js, Python, Java 등)
• AWS의 다른 서비스들과 쉽게 통합

Azure Functions

• Microsoft Azure의 서버리스 솔루션
• .NET 환경과의 뛰어난 통합성
• 다양한 트리거와 바인딩 지원

Google Cloud Functions

• Google Cloud Platform의 서버리스 제품
• 간단한 HTTP 엔드포인트부터 복잡한 클라우드 이벤트까지 처리
• 구글의 다른 서비스들과 원활한 연동

서버리스의 장/단점

장점: 운영 복잡성 감소, 자동 확장성, 비용 효율성, 빠른 개발 및 배포

단점: 콜드 스타트 지연, 벤더 종속성, 긴 실행 시간 제한, 디버깅의 어려움

 

위와 같은 특징으로 서버리스는 특히 변동성이 큰 워크로드, 이벤트 기반 처리, 마이크로서비스 아키텍처에 적합하며, 현대 클라우드 네이티브 애플리케이션 개발에서 중요한 역할을 하고 있습니다.

NextJS 배포 환경에 따른 특징

NextJS 를 AWS E2C 에서 배포할 경우와 Vercel 를 통해 배포할 경우 렌더링 속도에서 차이가 발생하게 되는데 그 이유는 콜드스타트 라는 특성에 의해 발생하게 됩니다.

AWS EC2로 배포 시 콜드스타트

먼저 AWS EC2로 배포 할 경우 EC2는 항상 실행 중인 서버이므로 전통적인 의미의 콜드스타트가 없으며 서버가 계속 동작하므로 초기 요청도 즉시 처리 가능합니다. 단, 인스턴스 시작/재시작 시에는 초기화 시간 발생합니다.

Vercel 배포 시 콜드스타트

서버리스 아키텍처 기반 일정 시간 동안 트래픽이 없으면 인스턴스가 슬립 상태로 전환됩니다. 그리고 새로운 요청 시 인스턴스 웨이크업 필요합니다.

 

 

 

콜드스타트 시간은  정적 페이지일 경우 거의 즉시 로드(엣지 네트워크 활용) 되지만 SSR 페이지는 첫 요청 시 300ms-1s 정도 소요되며 이후 요청은 50-100ms 내외로 소요됩니다. API 라우트의 경우 100-500ms 정도 소요가 발생합니다.

Vercel의 서버리스 실행 과정

초기 요청 발생 시

사용자 요청 → Vercel Edge Network → Google Cloud Functions 인스턴스 생성 시작 → Node.js 런타임 초기화 → Next.js 프레임워크 부팅 → 애플리케이션 코드 로드 → 요청 처리 → 응답 반환

 

이 전체 과정이 콜드스타트에서 발생하므로 300ms-1s 정도의 지연이 발생합니다.

후속 요청 처리 (웜스타트)

사용자 요청 → Vercel Edge Network → 이미 실행 중인 인스턴스로 직접 라우팅 → 요청 처리 → 응답 반환

 

웜스타트의 경우 인스턴스가 이미 실행 중이므로 50-100ms 정도로 빠른 응답이 가능합니다.

유휴 상태 전환

• 일정 시간(보통 10-15분) 동안 요청이 없으면 인스턴스는 유휴 상태로 전환
• 메모리와 컴퓨팅 리소스 해제
• 다음 요청 시 다시 콜드스타트 발생

Vercel의 서버리스 환경에서의 CSR 과 SSR 렌더링 차이

1) CSR (Client Side Rendering) 동작 과정

1. 초기 요청 → 최소한의 HTML과 전체 JS 파일 전달
- 서버리스의 콜드스타트 영향이 적음 (정적 파일 전달)
- CDN에서 캐시된 파일 바로 전달 가능

2. 브라우저에서 렌더링 - JS 다운로드 후 브라우저에서 처리 - 서버 리소스 사용하지 않음

2) SSR (Server Side Rendering) 동작 과정

1. 초기 요청 → 서버리스 함수 실행 필요
- 콜드스타트 발생 (300ms-1s)
- Node.js 런타임 시작
- React/Next.js 초기화

2. 서버에서 렌더링 - 데이터 가져오기 - HTML 생성 - 클라이언트로 전달
3. 브라우저에서 Hydration - 전달받은 HTML에 이벤트 리스너 연결

 

이런 특징으로 서버리스 환경 (Vercel 등)에서의 SSR 에서 FCP가 지연될 수 있습니다(콜드스타트 시간 + 렌더링 시간) 

서버리스 환경에서 SSR 성능을 개선하기 위한 주요 전략

1) ISR (Incremental Static Regeneration) 활용

export async function getStaticProps({ params }) {
  return {
    props: { data }, 
    revalidate: 60 // 60초마다 재생성
  }
}

 

• 정적 페이지를 주기적으로 재생성
• 콜드스타트 영향 없이 캐시된 페이지 제공
• 데이터 업데이트가 실시간일 필요 없는 페이지에 적합

2) Streaming SSR 구현

import { Suspense } from 'react'

export default function Page() {
  return (
    <>
      <Header />
      <Suspense fallback={<Loading />}>
        <SlowComponent />
      </Suspense>
    </>
  )
}

• 페이지를 점진적으로 로드
• 중요한 컨텐츠를 먼저 표시
• 사용자 체감 성능 향상

3) 서버 웜업 (Pre-warming) 구현

export default async function warmup() {
  // 주요 페이지 미리 로드
  await Promise.all([
    fetch('/api/critical-data'),
    fetch('/api/user-data')
  ])
}

 

• 정기적으로 서버 인스턴스를 활성 상태로 유지
• Cron Job으로 주기적 호출
• 중요 시간대에 콜드스타트 방지

4) Dynamic Imports 최적화

 

import dynamic from 'next/dynamic'

const DynamicComponent = dynamic(() => 
  import('../components/DynamicComponent'), {
    loading: () => <p>Loading...</p>,
    ssr: true
})​

 

• 코드 스플리팅
• 초기 번들 크기 감소
• 페이지 로드 성능 향상

이러한 전략들을 적절히 조합하여 사용하면 서버리스 환경에서도 효율적인 SSR 성능을 얻을 수 있습니다.