2024년 11월 1일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/2a3741f8-626e-4237-b985-d52de10bb444_thumbnail_1.png)

## Frontend — Next.js 15 정식 출시

Next.js가 **10월 21일 Next.js 15**를 정식 출시했습니다.

이번 버전의 가장 큰 변화 중 하나는 **기본 Caching 정책이 바뀌었다는 점**입니다.

Next.js 14까지는 App Router를 사용하면서 개발자가 명시적으로 Cache를 설정하지 않아도 Framework가 자동으로 Cache하는 경우가 많았습니다.

Next.js 15에서는 이러한 기본 동작을 줄이고, **데이터를 Cache할지 개발자가 명시적으로 선택하는 방향**으로 정책이 변경됐습니다.

이외에도 Turbopack 기반 `next dev`의 Stable 승격, React 19 지원, Server Actions 보안 개선 등이 포함됐습니다.

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

---

### App Router와 Cache

Next.js App Router가 등장하면서 Server Component와 함께 강력한 Caching 기능이 도입됐습니다.

대표적인 구조는 다음과 같습니다.

```text
Server Component
      ↓
    fetch()
      ↓
Data Cache
      ↓
Rendered Result
```

Server에서 데이터를 가져와 Cache하고 이를 다시 활용하면 Backend 요청이나 Database Query를 줄일 수 있습니다.

하지만 문제는 **Caching 동작이 개발자가 예상한 것보다 복잡할 수 있었다는 점**입니다.

---

### Next.js 14의 기본 Cache

Next.js 14에서는 `fetch()` 요청이 기본적으로 Cache되는 경우가 있었습니다.

```javascript
const response = await fetch(
  'https://api.example.com/posts'
);
```

개발자가 Cache 설정을 명시하지 않아도 Framework가 결과를 재사용할 수 있었습니다.

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

```text
fetch()
  ↓
Cache
  ↓
Response 재사용
```

성능 측면에서는 효율적일 수 있지만 데이터가 자주 변경되는 서비스에서는 예상하지 못한 문제가 발생할 수 있습니다.

---

### 데이터가 갱신되지 않는 문제

예를 들어 게시글 목록을 조회한다고 가정할 수 있습니다.

```text
Database

Post A
Post B
Post C
```

사용자가 새로운 게시글을 추가합니다.

```text
Database

Post A
Post B
Post C
Post D
```

하지만 Application이 기존 Cache를 계속 사용한다면 다음과 같은 상황이 발생할 수 있습니다.

```text
Database
   ↓
Post D 추가

하지만

Next.js Cache
   ↓
Post A
Post B
Post C
```

Database에는 새로운 데이터가 존재하지만 화면에서는 이전 데이터가 계속 보이는 것입니다.

개발자는 이런 상황을 해결하기 위해 Cache 설정과 Revalidation 동작을 정확하게 이해해야 했습니다.

---

### Next.js 15의 변화

Next.js 15에서는 기본 정책이 반대 방향으로 변경됐습니다.

```text
Next.js 14

Implicit Cache
      ↓
필요하면 Cache 해제


Next.js 15

Uncached by Default
      ↓
필요하면 Cache 활성화
```

즉 데이터가 자동으로 Cache된다고 가정하기보다 **Cache가 필요한 곳에서 개발자가 명시적으로 선택하는 방향**으로 바뀌었습니다.

---

### `fetch()` 기본 정책 변경

Next.js 15에서는 `fetch()` 요청이 기본적으로 Cache되지 않는 방향으로 변경됐습니다.

```javascript
const response = await fetch(
  'https://api.example.com/posts'
);
```

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

```text
Request
  ↓
fetch()
  ↓
Latest Data
```

Cache가 필요한 경우에는 개발자가 명시적으로 Cache 정책을 설정할 수 있습니다.

```javascript
const response = await fetch(
  'https://api.example.com/posts',
  {
    cache: 'force-cache'
  }
);
```

이 경우에는 Cache 사용 의도가 코드에 드러납니다.

```text
fetch()
  ↓
force-cache
  ↓
Cached Response
```

---

### Cache 정책이 코드에 드러난다

이 변화의 중요한 점은 단순히 Cache를 끈 것이 아닙니다.

**Application의 Cache 전략이 코드에 더 명시적으로 나타난다는 점**입니다.

```text
기존

fetch()
 ↓
Framework가 Cache 결정


변경

fetch()
 ↓
개발자가 Cache 정책 결정
```

개발자는 데이터를 가져올 때 다음을 직접 판단해야 합니다.

```text
이 데이터는

항상 최신이어야 하는가?

몇 분 정도 오래돼도 되는가?

거의 변경되지 않는가?

요청마다 달라지는가?
```

즉 Cache를 Framework의 기본 동작에 맡기는 것이 아니라 **Application Data 특성에 맞게 설계하는 방향**으로 바뀌었습니다.

---

### GET Route Handler도 변화

Next.js 15에서는 `GET` Route Handler도 기본적으로 Cache되지 않는 방향으로 변경됐습니다.

예를 들어 다음과 같은 API가 있다고 가정할 수 있습니다.

```typescript
export async function GET() {
  return Response.json({
    message: 'hello'
  });
}
```

기존에는 Cache 동작을 추가로 이해해야 하는 경우가 있었다면 Next.js 15에서는 기본적으로 **Dynamic한 Request 처리에 가까운 동작**을 기대할 수 있게 됐습니다.

---

### 왜 중요한가

Caching은 성능을 크게 향상시킬 수 있지만 잘못 사용하면 데이터 정합성 문제를 만들 수 있습니다.

```text
Cache 사용

장점
├─ 빠른 응답
├─ Backend 부하 감소
└─ Database Query 감소


단점
├─ Stale Data
├─ Cache Invalidation
└─ 복잡한 상태 관리
```

특히 Web Application에서는 **Cache Invalidation**이 가장 어려운 문제 중 하나입니다.

```text
Data 변경
   ↓
Cache는 언제 갱신?
   ↓
누가 갱신?
   ↓
어떤 Cache를 삭제?
```

Next.js 15는 기본적으로 Cache를 덜 사용하는 방향으로 이동하면서 이러한 문제를 개발자가 더 명시적으로 관리하도록 변경했습니다.

---

### Framework Semantics의 변화

이번 변화가 중요한 이유는 단순히 Option 하나가 바뀐 것이 아니라 **Framework가 데이터를 바라보는 기본 철학이 바뀌었다는 점**입니다.

```text
Next.js 14

Cache First
    ↓
필요하면 Dynamic


Next.js 15

Dynamic First
    ↓
필요하면 Cache
```

App Router가 처음 등장했을 때는 적극적인 Caching을 통해 성능을 자동으로 확보하려는 방향이 강했습니다.

하지만 실제 개발자들의 Feedback을 반영하면서 **예측 가능한 데이터 동작을 우선하는 방향**으로 조정된 것입니다.

---

### Turbopack `next dev` Stable

Next.js 15에서는 Turbopack 기반의 Development Server도 Stable 단계로 올라왔습니다.

기존 Next.js 개발 환경에서는 Webpack이 중심이었습니다.

```text
Source Code
    ↓
Webpack
    ↓
Development Server
```

Turbopack은 Rust 기반으로 만들어진 Bundler로 빠른 개발 환경을 목표로 합니다.

```text
Source Code
    ↓
Turbopack
    ↓
Fast Development Build
```

Next.js 15에서는 다음과 같이 사용할 수 있습니다.

```bash
next dev --turbo
```

개발 중 Build와 Hot Reload 성능을 개선하기 위한 Next.js Toolchain 변화가 본격적으로 안정화되기 시작한 것입니다.

---

### React 19 지원

Next.js 15는 **React 19 지원**도 포함했습니다.

Next.js App Router는 React Server Component와 깊게 연결돼 있기 때문에 React 자체의 변화가 Framework Architecture에도 직접적인 영향을 줍니다.

```text
React
  ↓
React Server Components
  ↓
Next.js App Router
```

Next.js는 단순한 React Router나 Build Tool이 아니라 React의 새로운 기능을 적극적으로 통합하는 Full Stack Framework로 계속 발전하고 있었습니다.

---

### Server Actions

Server Actions 역시 Next.js의 중요한 기능입니다.

Client에서 별도의 REST API를 직접 작성하지 않고 Server Function을 호출할 수 있습니다.

```typescript
'use server';

export async function createPost(
  formData: FormData
) {
  // DB 처리
}
```

구조적으로 보면 다음과 같습니다.

```text
Client
  ↓
Server Action
  ↓
Server
  ↓
Database
```

Next.js 15에서는 Server Actions 관련 보안 처리도 개선됐습니다.

Server Action이 실제 Backend Logic을 실행할 수 있기 때문에 Framework 수준에서의 보안과 Validation이 점점 중요해지고 있습니다.

---

### Frontend와 Backend 경계의 변화

Next.js는 더 이상 단순한 Frontend Framework라고 보기 어려워지고 있습니다.

```text
Next.js

├─ Client Component
├─ Server Component
├─ Route Handler
├─ Server Action
├─ Authentication
├─ Cache
└─ Data Fetching
```

Frontend 개발자가 Application Server의 동작까지 다루게 되면서 다음 개념도 함께 이해해야 합니다.

```text
Frontend Developer

UI
+
Rendering
+
Server
+
Cache
+
Data Fetching
+
Security
```

Frontend와 Backend의 경계가 점점 흐려지는 흐름입니다.

---

### Next.js 14 → 15 Migration

Next.js 15로 Upgrade할 때 중요한 것은 단순히 Version을 올리는 것이 아닙니다.

```text
Next.js 14
    ↓
npm install next@15
    ↓
끝
```

이렇게 접근하면 문제가 생길 수 있습니다.

가장 먼저 확인해야 할 것이 **데이터 Freshness와 Cache 정책**입니다.

```text
Migration

├─ fetch Cache 확인
├─ Route Handler Cache 확인
├─ revalidate 확인
├─ Static / Dynamic Rendering 확인
├─ Server Actions 확인
└─ React 19 Compatibility 확인
```

---

### 데이터 성격에 따른 Cache 전략

모든 데이터를 동일하게 처리할 필요는 없습니다.

예를 들어 상품 상세 정보처럼 변경이 적은 데이터라면 Cache가 유리할 수 있습니다.

```text
Product Detail
     ↓
Cache
     ↓
Fast Response
```

반면 재고나 주문 상태처럼 자주 변경되는 데이터는 Freshness가 중요합니다.

```text
Order Status
     ↓
No Cache
     ↓
Latest Data
```

결국 Application마다 데이터 특성에 맞는 전략이 필요합니다.

```text
Static Data
    ↓
Cache


Semi-dynamic Data
    ↓
Revalidation


Real-time Data
    ↓
No Cache
```

---

### Backend 관점에서도 중요한 변화

Next.js를 BFF(Backend for Frontend)처럼 사용하는 서비스에서는 Cache 정책이 Backend Architecture에도 직접적인 영향을 줍니다.

```text
Browser
   ↓
Next.js
   ↓
Backend API
   ↓
Database
```

Next.js에서 Cache가 적용되면 실제 Backend API까지 Request가 전달되지 않을 수 있습니다.

```text
Browser
   ↓
Next.js Cache
   ↓
Response
```

따라서 Cache 정책은 단순한 Frontend Optimization이 아니라 **Backend Traffic과 Database Load까지 영향을 주는 Architecture 요소**입니다.

---

### 실무 영향

Next.js 15의 가장 중요한 변화 중 하나는 개발자가 Framework의 암묵적인 Cache 동작을 덜 의식해도 되는 방향으로 이동했다는 것입니다.

기존에는

```text
데이터가 왜 안 바뀌지?
        ↓
Next.js Cache 확인
        ↓
revalidate 확인
        ↓
Rendering Mode 확인
```

같은 Debugging 과정이 발생할 수 있었습니다.

Next.js 15에서는 기본적으로 최신 데이터를 가져오고, 성능이 필요한 곳에서 Cache를 명시적으로 적용하는 방향으로 바뀌었습니다.

```text
Default
 ↓
Fresh Data


Optimization 필요
 ↓
Explicit Cache
```

결국 Next.js 15의 Cache 정책 변경은,

> **Framework가 자동으로 성능을 최적화하는 것보다 개발자가 데이터의 특성에 맞게 Cache를 명시적으로 선택하도록 방향을 수정한 변화**

라고 볼 수 있습니다.

2024년 10월 25일(금) 주간 개발트렌드

독자의 메모