2025년 3월 14일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

## Frontend — Next.js/Turbopack 중심의 프론트엔드 빌드 성능 경쟁

Next.js가 **지난주 25년 2월 26일 Next.js 15.2**를 공개했습니다.

이번 버전에서는 **Turbopack의 성능과 메모리 사용량 개선**, Node.js Middleware 실험 지원, Streaming Metadata 등이 포함됐습니다.

특히 Vercel은 일부 내부 측정에서 Next.js 15.1 대비 **Route Compile 시간이 최대 57.6% 빨라졌다**고 밝혔습니다.

중요한 점은 Next.js의 경쟁력이 단순히 Routing이나 Server Component 같은 Framework API에만 있는 것이 아니라, **Compiler와 Bundler를 포함한 Build Toolchain 전체로 확장되고 있다는 점**이었습니다.

[Next.js - Next.js 15.2](https://nextjs.org/blog/next-15-2)

---

### 프론트엔드 Build Tool의 역할

React Application을 Browser에서 실행하려면 Source Code를 그대로 사용하는 것이 아니라 Build 과정이 필요합니다.

```text
TypeScript
JSX
CSS
Module

   ↓

Build Tool

   ↓

Browser에서 실행 가능한 결과
```

Build Tool은 일반적으로 다음과 같은 역할을 담당합니다.

```text
Build Tool

├─ Transpile
├─ Bundle
├─ Module Resolution
├─ Code Splitting
├─ Minification
├─ HMR
└─ Dependency Graph
```

프로젝트 규모가 커질수록 이 과정의 성능이 개발 경험에 직접적인 영향을 줍니다.

---

### 오랫동안 Webpack이 기본이었다

React와 Next.js 생태계에서는 오랫동안 **Webpack**이 사실상 기본 Bundler였습니다.

```text
React / Next.js
       ↓
     Webpack
       ↓
    Bundle
```

Webpack은 매우 강력하고 거대한 Plugin 생태계를 가지고 있었지만, 프로젝트가 커질수록 Build와 Development Server 속도가 문제가 되기도 했습니다.

```text
Project 규모 증가
      ↓
Module 증가
      ↓
Dependency Graph 증가
      ↓
Compile Time 증가
```

특히 대규모 Frontend에서는 작은 코드 수정에도 Compile을 기다려야 하는 상황이 발생할 수 있습니다.

---

### Frontend에서 Build 속도가 중요한 이유

개발자는 하루 동안 계속 코드를 수정합니다.

```text
Code 수정
   ↓
Compile
   ↓
Browser 확인
   ↓
다시 수정
```

이 과정은 수백 번 반복될 수 있습니다.

Compile에 1초가 걸리는 것과 5초가 걸리는 것은 한 번만 보면 큰 차이가 아닐 수 있습니다.

하지만 개발 과정 전체에서는 상당한 차이가 됩니다.

```text
1초 × 반복

vs

5초 × 반복
```

작은 대기 시간이 계속 누적되면 개발 흐름이 끊깁니다.

```text
Compile 지연
    ↓
Developer 대기
    ↓
Feedback Loop 증가
    ↓
개발 속도 감소
```

따라서 Build Tool 성능은 단순 Benchmark가 아니라 **Developer Experience의 핵심 요소**입니다.

---

### Turbopack

Vercel은 이러한 문제를 해결하기 위해 **Turbopack**을 개발하고 있습니다.

Turbopack은 Rust 기반의 JavaScript / TypeScript Build Tool입니다.

```text
Next.js
   ↓
Turbopack
   ↓
Development Build
```

기존 Webpack 기반 개발 환경을 더 빠르게 만드는 것을 목표로 합니다.

```text
기존

Source
  ↓
Webpack
  ↓
Development Server


새로운 방향

Source
  ↓
Turbopack
  ↓
Faster Development Server
```

---

### Rust 기반 Toolchain

최근 Frontend Toolchain에서 중요한 흐름 중 하나는 **성능이 중요한 영역을 JavaScript가 아닌 Rust 같은 System Language로 구현하는 것**입니다.

```text
Frontend Tooling

JavaScript 중심
      ↓

Rust / Native 기반 Tool 증가
```

대표적으로 다음 영역에서 이런 흐름이 나타났습니다.

```text
Bundler
Compiler
Minifier
Linter
Formatter
```

JavaScript Application을 만드는 Tool 자체는 더 낮은 Level의 Language로 구현해 성능을 확보하는 방식입니다.

---

### Next.js 15.2의 Turbopack 개선

Next.js 15.2에서는 Turbopack의 Compile Performance와 Memory Usage가 개선됐습니다.

Vercel은 일부 Project에서 Next.js 15.1과 비교해 **Route Compile 시간이 최대 57.6% 개선된 사례**를 공개했습니다.

개념적으로 보면 다음과 같습니다.

```text
Next.js 15.1

Route 변경
    ↓
Compile
    ↓
Wait


Next.js 15.2

Route 변경
    ↓
Faster Compile
    ↓
Browser
```

대규모 Project일수록 이런 Compile Time 감소의 체감 효과가 커질 수 있습니다.

---

### Memory 사용량도 중요하다

Build Tool은 CPU뿐 아니라 상당한 Memory를 사용할 수 있습니다.

```text
Large Project
    ↓
많은 Module
    ↓
Large Dependency Graph
    ↓
Memory Usage 증가
```

개발자의 Local Machine에서는 IDE, Browser, Docker, Database 등 여러 Tool을 동시에 실행하는 경우가 많습니다.

```text
Development Machine

├─ VS Code / IntelliJ
├─ Browser
├─ Docker
├─ Node.js
├─ Next.js
└─ Database
```

Bundler가 과도하게 Memory를 사용하면 전체 개발 환경에도 영향을 줄 수 있습니다.

따라서 Compile Speed뿐 아니라 **Memory Efficiency 역시 중요한 DX 요소**입니다.

---

### HMR과 개발 Feedback Loop

Frontend 개발에서 특히 중요한 기능이 HMR(Hot Module Replacement)입니다.

```text
Code 수정
   ↓
Changed Module만 Compile
   ↓
Browser Update
```

Application 전체를 다시 Build하는 대신 변경된 Module만 업데이트합니다.

이 과정이 빠를수록 개발자는 거의 즉시 결과를 확인할 수 있습니다.

```text
Edit
 ↓
Feedback
 ↓
Edit
 ↓
Feedback
```

Turbopack의 성능 개선은 결국 이 **Development Feedback Loop를 줄이는 것**과 연결됩니다.

---

### 프론트엔드 경쟁 기준의 변화

Frontend Framework 경쟁은 과거 주로 API와 기능을 중심으로 이루어졌습니다.

```text
Framework Competition

├─ Routing
├─ State
├─ SSR
├─ SSG
└─ Component Model
```

하지만 최근에는 Toolchain Performance도 중요한 경쟁 영역이 됐습니다.

```text
Modern Frontend Framework

Framework API
      +
Compiler
      +
Bundler
      +
Dev Server
      +
Build System
```

즉 Framework가 단순한 Runtime Library가 아니라 **개발 Toolchain 전체를 제공하는 Platform**으로 발전하고 있습니다.

---

### Next.js가 Build Tool까지 직접 가져가는 이유

Next.js의 기능은 점점 복잡해지고 있습니다.

```text
Next.js

├─ Server Components
├─ Client Components
├─ SSR
├─ SSG
├─ Streaming
├─ Server Actions
├─ Middleware
└─ Routing
```

일반적인 Bundler가 이 모든 Next.js 특성을 최적화하기에는 한계가 있을 수 있습니다.

Vercel이 Turbopack을 직접 개발하면 Next.js Architecture에 최적화된 Build System을 만들 수 있습니다.

```text
Next.js Architecture
        ↓
Turbopack
        ↓
Framework-aware Optimization
```

Framework와 Bundler가 하나의 생태계 안에서 함께 발전하는 구조입니다.

---

### Webpack에서 벗어나는 흐름

Frontend Ecosystem 전체에서도 Webpack 중심 구조가 점점 약해지고 있습니다.

```text
과거

Webpack
   ↓
Frontend Build


현재

Webpack
Vite
Turbopack
Rspack
esbuild
기타 Tool
```

각 Tool은 서로 다른 Architecture와 성능 전략을 사용합니다.

특히 새로운 Project에서는 Webpack이 자동으로 첫 번째 선택이 되는 상황이 줄어들고 있습니다.

---

### Vite의 영향

Frontend Build Tool 경쟁에서 Vite 역시 중요한 역할을 했습니다.

```text
Source
  ↓
Vite Dev Server
  ↓
Browser
```

Vite는 빠른 Development Experience를 제공하면서 Frontend 개발자의 기대 수준 자체를 바꿨습니다.

개발자는 점점 다음을 기대하게 됐습니다.

```text
Fast Startup

Fast HMR

Fast Compile

Low Configuration
```

Next.js 역시 이러한 Developer Experience 경쟁에서 Toolchain 성능을 강화할 필요가 생겼습니다.

---

### Local DX

Turbopack의 가장 직접적인 이점은 **Local Development Experience**입니다.

예를 들어 대규모 Next.js Application이 있다고 가정할 수 있습니다.

```text
Next.js App

500 Routes
1000 Components
Large node_modules
```

개발자가 한 Component를 수정할 때마다 3~5초씩 기다려야 한다면 생산성이 크게 떨어질 수 있습니다.

```text
Edit
 ↓
5초 대기
 ↓
확인
 ↓
Edit
 ↓
5초 대기
```

Compile Time을 줄이면 다음처럼 바뀝니다.

```text
Edit
 ↓
빠른 Compile
 ↓
확인
```

개발 Feedback Loop 자체가 짧아집니다.

---

### CI 시간에도 영향을 준다

Build Tool Performance는 Local Development에만 영향을 주는 것은 아닙니다.

CI에서도 Build 과정이 필요합니다.

```text
Git Push
   ↓
CI
   ↓
Install
   ↓
Lint
   ↓
Test
   ↓
Build
   ↓
Deploy
```

Build 시간이 길면 Pull Request마다 기다려야 하는 시간이 증가합니다.

```text
Developer
    ↓
PR
    ↓
CI Build
    ↓
10분 대기
```

팀 규모가 커지고 PR 수가 늘어나면 이 시간이 상당한 비용이 됩니다.

---

### CI 비용과 Build Performance

Cloud CI 환경에서는 Build Time 자체가 비용과 연결될 수도 있습니다.

```text
Build Time 증가
      ↓
Runner 사용 시간 증가
      ↓
CI Cost 증가
```

따라서 Compiler와 Bundler의 성능 개선은 단순한 Developer Convenience가 아니라 **Engineering Cost Optimization**과도 연결됩니다.

---

### Streaming Metadata

Next.js 15.2에서는 **Streaming Metadata**도 추가됐습니다.

Metadata를 생성하기 위해 필요한 데이터가 오래 걸리더라도 Page Rendering 전체를 막지 않고 처리할 수 있는 방향입니다.

기존 구조를 단순화하면 다음과 같을 수 있습니다.

```text
Metadata 생성
      ↓
Wait
      ↓
Page Rendering
```

Streaming 방식에서는 Rendering을 먼저 진행하면서 Metadata를 처리할 수 있습니다.

```text
Page Rendering
      ↓
Streaming

Metadata
      ↓
Later Streaming
```

Server Rendering에서 사용자가 첫 화면을 보는 시간을 줄이기 위한 최적화입니다.

---

### Server Rendering에서 Latency는 중요하다

Client SPA에서는 대부분의 Rendering이 Browser에서 이루어집니다.

하지만 Next.js Server Rendering에서는 Server Response Time이 사용자 경험에 직접적인 영향을 줍니다.

```text
Request
   ↓
Server
   ↓
Data Fetch
   ↓
Rendering
   ↓
HTML
   ↓
Browser
```

이 중 하나가 느리면 전체 Response도 늦어질 수 있습니다.

Streaming은 이러한 작업들을 순차적으로 기다리는 대신 가능한 부분부터 Browser로 전달하는 방향입니다.

```text
기존

A 완료
 ↓
B 완료
 ↓
C 완료
 ↓
Response


Streaming

A → Client

B → Client

C → Client
```

Modern React와 Next.js에서 Streaming이 중요한 이유입니다.

---

### Node.js Middleware 실험 지원

Next.js 15.2에서는 **Node.js Runtime 기반 Middleware 지원도 실험적으로 추가**됐습니다.

기존 Next.js Middleware는 Edge Runtime의 제약을 받는 경우가 있었습니다.

```text
Middleware
    ↓
Edge Runtime
    ↓
제한된 Node API
```

Node.js Runtime을 사용할 수 있다면 기존 Node.js Library와 API를 활용할 수 있는 범위가 넓어집니다.

```text
Middleware
    ↓
Node.js Runtime
    ↓
Node Ecosystem
```

다만 당시에는 Experimental 단계였기 때문에 Production 적용에는 신중한 검토가 필요했습니다.

---

### Development와 Production Build는 다르다

Turbopack을 이야기할 때 중요한 점은 **Development 성능과 Production Build 안정성을 구분해야 한다는 것**입니다.

```text
Development

Fast HMR
Fast Compile
Developer Experience


Production

Stable Build
Optimization
Tree Shaking
Code Splitting
Compatibility
```

개발 환경에서 빠르다고 해서 Production Build에서도 바로 기존 Tool을 대체할 수 있다는 의미는 아닙니다.

---

### 당시 Production Build는 신중해야 했다

Next.js 15.2 시점에서 Turbopack은 Development 환경에서 빠르게 성숙하고 있었지만 Production Build는 여전히 신중하게 접근할 필요가 있었습니다.

```text
Turbopack

Development
    ↓
실제 사용 검토 가치 높음


Production Build
    ↓
Compatibility / Stability 확인 필요
```

특히 대규모 Production Service라면 기존 Webpack Build와 결과를 비교해야 합니다.

---

### Migration에서는 Benchmark가 중요하다

Build Tool을 바꿀 때 단순히

```text
Turbopack이 더 빠르다
```

라는 이유만으로 전체 Project를 바로 Migration하는 것은 좋지 않습니다.

실제 Project에서 측정해야 합니다.

```text
Before

Startup Time
Route Compile
Memory
HMR
CI Build


After

Startup Time
Route Compile
Memory
HMR
CI Build
```

Project 구조와 Dependency에 따라 성능 차이는 달라질 수 있기 때문입니다.

---

### 대형 프로젝트에서 특히 의미가 크다

작은 Project에서는 Build Tool 차이가 크게 체감되지 않을 수 있습니다.

```text
Small Project

50 Modules
 ↓
Build 이미 빠름
```

하지만 대규모 Application에서는 상황이 다릅니다.

```text
Large Project

Thousands of Modules
Hundreds of Routes
Large Dependency Graph
        ↓
Build Performance 중요
```

Compile 시간이 몇 초만 줄어도 전체 팀 생산성에는 상당한 차이를 만들 수 있습니다.

---

### Monorepo에서는 더 중요해진다

대규모 Frontend Team에서는 Monorepo를 사용하는 경우도 많습니다.

```text
Monorepo

├─ apps/web
├─ apps/admin
├─ packages/ui
├─ packages/utils
└─ packages/config
```

Package와 Dependency가 많아질수록 Build Graph 역시 복잡해집니다.

```text
Code Change
   ↓
Dependency Graph 확인
   ↓
Affected Modules Compile
```

이런 환경에서 Incremental Build와 Caching, Compiler Performance가 매우 중요합니다.

---

### Framework가 Platform이 된다

Next.js의 발전 방향을 보면 단순 React Framework보다 더 넓은 역할을 하고 있습니다.

```text
Next.js

├─ Routing
├─ Rendering
├─ Server
├─ Cache
├─ Build
├─ Compiler
└─ Deployment
```

즉 Application Runtime뿐 아니라 **개발부터 Build, Production까지 전체 Lifecycle을 관리하는 Platform**에 가까워지고 있습니다.

Turbopack 역시 이 Platform 전략의 일부입니다.

---

### Frontend Developer에게도 Compiler 이해가 중요해진다

과거 Frontend 개발자는 Build Tool을 거의 신경 쓰지 않아도 되는 경우가 많았습니다.

```text
npm start

npm build
```

하지만 Project가 커질수록 다음 개념을 이해할 필요가 생깁니다.

```text
Bundling

Code Splitting

Tree Shaking

Module Graph

Incremental Build

HMR

Caching
```

Build Architecture 자체가 Application Performance와 Developer Productivity에 영향을 주기 때문입니다.

---

### 왜 중요한가

Next.js 15.2의 Turbopack 개선에서 중요한 것은 단순히 Compile이 빨라졌다는 사실만은 아닙니다.

Frontend Framework 경쟁의 범위 자체가 달라지고 있다는 점입니다.

```text
기존 경쟁

Framework API

Routing

Rendering


현재 경쟁

Framework
+
Compiler
+
Bundler
+
Runtime
+
Developer Experience
```

Application Framework가 Build Infrastructure까지 직접 최적화하기 시작한 것입니다.

---

### 실무 영향

Next.js 프로젝트에서는 Turbopack을 단순한 실험 기능으로만 볼 필요가 점점 줄어들기 시작했습니다.

특히 다음과 같은 환경이라면 실제 Benchmark를 해볼 가치가 생겼습니다.

```text
Large Next.js Project

Slow Local Compile

Slow HMR

High Memory Usage

Large Monorepo

Long Development Startup
```

Migration 판단은 다음과 같이 할 수 있습니다.

```text
현재 Webpack 환경
      ↓
Baseline 측정
      ↓
Turbopack 적용
      ↓
Startup / Compile / HMR / Memory 측정
      ↓
Compatibility 확인
      ↓
도입 결정
```

반면 Production Build에서는 당시 Compatibility와 안정성을 충분히 확인해야 했습니다.

결국 Next.js 15.2와 Turbopack의 발전은,

> **Frontend Framework의 경쟁력이 API 설계뿐 아니라 개발자가 매일 체감하는 Compiler와 Bundler의 성능까지 내려오고 있음을 보여주는 변화**

라고 볼 수 있습니다.

Webpack이 사실상 유일한 선택처럼 여겨지던 시대에서 벗어나 Vite, Turbopack, Rspack 등 새로운 Toolchain이 경쟁하면서 **Build Performance 자체가 Frontend Architecture와 Developer Experience의 중요한 선택 기준**으로 자리 잡기 시작했습니다.

2025년 3월 7일(금) 주간 개발트렌드

독자의 메모