[2025.08.29 주간 개발 트렌드] Kubernetes 1.34 정리 (DRA, GPU 할당, 드라이버)

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# Turbopack을 이제 production build에서도 써볼때인가

개발 서버는 빨라졌는데 배포할때는 여전히 빌드를 기다리는 경우가 있다. 화면을 수정하는 속도와 실제로 배포할 수 있는 속도는 다른 문제다.

이번주 8월 18일에 [Next.js 15.5](https://nextjs.org/blog/next-15-5)가 나왔다. next build --turbopack이 Beta로 들어왔고 Node.js Middleware와 Typed Routes도 Stable이 됐다.

next lint의 deprecated 안내도 같이 추가됐다. 이번주 개발트렌드로 빌드 도구와 프로젝트 설정에서 확인할 부분을 정리해보려고 한다.

# 1. 개발 서버와 production build는 구분해서 보자

개발할때 Turbopack을 사용하고있다고 배포 빌드도 같은 도구를 사용하는것은 아니다. 개발 서버와 production 결과물을 만드는 경로를 각각 확인해야한다.

15.5에서는 다음 명령으로 Turbopack 빌드를 사용할 수 있다.

```bash
npx next build --turbopack
```

다만 **production build 지원이 지금은 Beta**라는 점이 중요하다. Webpack을 사용하는 모든 프로젝트가 바로 바꿔도 된다는 의미로 보면 안된다.

이번 발표에서도 작은 프로젝트의 빌드 시간 차이, 일부 번들 최적화, CSS 결합 순서 같은 차이를 설명하고있다. 따라서 다른 프로젝트에서 몇배 빨라졌다는 결과를 그대로 내 프로젝트에 적용하기는 어렵다.

같은 저장소를 두 방식으로 빌드하고 시간뿐 아니라 실제 화면과 결과물도 비교하는게 좋겠다.

```text
같은 커밋
   ├── 기존 빌드 → 시간·크기·화면 확인
   └── Turbopack → 시간·크기·화면 확인
```

빌드는 통과했는데 특정 페이지의 스타일 순서가 달라지거나 사용하던 설정이 빠지면 빠른 빌드만으로는 충분하지 않다. 기존 webpack 설정이나 loader를 사용한다면 호환성부터 확인해야한다.

# 2. Node.js Middleware가 Stable이 됐다

Middleware에서 Node.js 런타임을 사용하는 기능도 안정화됐다. Node.js API나 관련 라이브러리가 필요한 작업을 검토할 수 있는 범위가 넓어졌다.

설정은 다음처럼 지정할 수 있다.

```typescript
// middleware.ts
import { NextResponse } from "next/server";

export const config = {
  runtime: "nodejs",
  matcher: ["/dashboard/:path*"],
};

export function middleware() {
  return NextResponse.next();
}
```

위 코드는 런타임 설정을 보여주는 최소 예제다. 로그인 확인이나 권한 검사를 구현한 코드는 아니다.

Node.js를 쓸 수 있다고 모든 요청마다 무거운 DB 조회나 외부 API 호출을 넣는게 좋은것도 아니다. Middleware에서 기다리는 시간은 요청을 처리하기 전 지연으로 이어질 수 있다.

어떤 경로에서 실행할지 matcher를 확인하고, 이 단계에서 꼭 필요한 작업인지부터 정하면 좋겠다. 페이지 접근 제어를 붙이더라도 실제 데이터를 반환하는 API의 권한 검사는 따로 유지해야한다.

# 3. Typed Routes는 어떤걸 잡아줄까

라우트 경로를 문자열로 적다보면 오타가 나도 화면에서 눌러보기 전까지 놓칠 수 있다. Typed Routes는 파일 구조를 바탕으로 경로 타입을 만들어 이런 오류를 컴파일 단계에서 확인하도록 돕는다.

```typescript
// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  typedRoutes: true,
};

export default nextConfig;
```

이제 Stable 옵션이므로 experimental.typedRoutes가 아니라 typedRoutes를 사용한다. TypeScript 프로젝트에서 사용하는 기능이다. [Typed Routes 설정](https://nextjs.org/docs/15/app/api-reference/config/next-config-js/typedRoutes)

예를 들어 실제 경로는 /settings인데 링크에 /setings라고 적었다면 타입 검사에서 확인할 수 있다.

다만 경로의 형태가 유효하다는것과 데이터가 존재한다는것은 다르다. /posts/123이라는 경로를 만들 수 있어도 123번 글이 실제로 있는지, 사용자가 볼 수 있는지는 실행 중에 확인해야한다.

Turbopack에서 route export validation도 지원하므로 page나 route handler의 잘못된 export 설정을 확인할 기반이 개선됐다. 타입 검사가 늘어나는만큼 CI에서 그 결과를 실제로 확인하는것도 중요하다.

# 4. next lint는 어떻게 바뀌나

15.5에서는 next lint를 사용하면 deprecated 안내가 나오고, Next.js 16에서는 제거될 예정이라고 안내한다. 지금 바로 lint 기능 전체가 사라진다는 뜻은 아니다.

대신 ESLint나 Biome을 직접 실행하는 방식으로 정리하는 흐름이다. 프로젝트에서 선택한 도구의 설정과 명령이 더 드러나게 된다.

ESLint를 사용한다면 package.json의 명령을 다음처럼 구성할 수 있다.

```json
{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix"
  }
}
```

명령 이름만 바꾸는것으로 끝내면 안된다. 기존 규칙과 검사 대상, 무시할 경로가 유지되는지 확인해야한다. Next.js와 React에 필요한 설정도 같이 봐야한다.

CI가 next lint를 직접 호출하고있다면 그 부분도 바꿔야한다. 로컬에서는 새 명령을 쓰는데 배포 파이프라인은 예전 명령을 쓰는 상황이 생길 수 있다.

# 5. 한꺼번에 바꾸지말고 나눠서 확인하자

이번 업데이트에는 빌드 도구, 런타임, 타입, lint 변경이 같이 들어있다. 전부 한번에 바꿨다가 문제가 생기면 원인을 찾기 어려울 수 있다.

1. 버전 업데이트 후 기존 빌드와 테스트를 먼저 확인한다.
2. Typed Routes와 lint 명령 변경을 확인한다.
3. Turbopack 빌드는 별도로 비교한다.
4. 주요 페이지의 스타일과 직접 URL 접근을 확인한다.
5. Node.js Middleware는 필요한 경로부터 검토한다.

빌드 시간은 CI 머신과 캐시 상태의 영향을 받으므로 같은 조건에서 여러번 확인하는게 좋겠다. 더 빨라졌다는 인상보다 측정값과 기능 검증을 같이 남기는것이다.

# 마무리

이번 Next.js 15.5는 Turbopack을 개발 서버에서만 보던 단계에서 배포 빌드까지 검증해볼 계기가 되는것 같다. 그렇다고 Beta 상태를 Stable처럼 생각하면 안된다.

개인적으로는 빌드가 빨라지는것만큼 경로 타입 검사와 lint 명령 정리도 실무에서 자주 만날 변화로 보인다.

기능이 많이 바뀌는 업데이트일수록 하나씩 적용하는게 나중에 덜 고생하는 방법인것 같다.. 빌드 성공 표시만 보지말고 실제 배포할 화면까지 확인해봐야겠다.


[2025.08.22 주간 개발 트렌드] Next.js 15.5 정리 (Turbopack 빌드, Middleware, Typed Routes)

독자의 메모