Next.js Turbopack 마이그레이션 가이드: SaaS·관리자 화면 빌드 속도와 배포 리스크 기준
결론: Turbopack은 켜는 기능이 아니라 빌드 경로를 바꾸는 결정입니다
Next.js Turbopack 마이그레이션의 실무 결론은 단순합니다. 신규 프로젝트라면 Turbopack 기본값을 자연스럽게 받아들이는 편이 맞지만, 이미 운영 중인 SaaS·관리자 화면이라면 기존 webpack 설정, 플러그인, CSS 처리, 번들 분석, CI/CD 캐시, 모니터링 연동을 먼저 점검해야 합니다. Next.js 16 기준으로 Turbopack은 next dev와 next build의 기본 경로가 되었고, custom webpack 설정이 있으면 빌드가 실패할 수 있습니다. 즉 이제 문제는 ‘Turbopack을 쓸까 말까’가 아니라 ‘어떤 설정을 버리고, 어떤 설정을 옮기고, 어디까지는 --webpack으로 보류할 것인가’입니다.
운영 서비스에서 좋은 마이그레이션은 한 번에 성공하는 업그레이드가 아닙니다. 실패했을 때 되돌릴 수 있고, 성공했을 때 어떤 지표가 개선됐는지 설명할 수 있는 업그레이드입니다.
랜딩 페이지는 SEO, 이미지 최적화, Core Web Vitals가 중요합니다. 반면 SaaS와 관리자 화면은 권한별 메뉴, 데이터 그리드, 차트, 파일 업로드, 리치 에디터, 대량 폼, 사내 API 호출이 얽혀 있습니다. 이 글은 Turbopack을 홍보하기 위한 글이 아니라, 대표·PM·마케터·지원사업 책임자가 개발팀 또는 외주사와 같은 기준으로 논의할 수 있도록 의사결정표와 체크리스트를 정리한 가이드입니다.
1. 왜 지금 Next.js Turbopack 마이그레이션을 봐야 하나
Next.js 16 전후의 중요한 변화는 Turbopack이 실험 옵션이 아니라 기본 빌드 경로로 이동했다는 점입니다. 과거에는 next dev --turbopack 또는 next build --turbopack처럼 명시적으로 켜는 흐름이었지만, 이제는 기본 명령어 자체가 Turbopack을 사용합니다. 프로젝트에 next.config.js의 webpack 함수가 남아 있으면 ‘설정이 의도와 다르게 무시되는 상황’을 막기 위해 빌드가 실패할 수 있습니다.
이 변화는 개발자만의 문제가 아닙니다. 정부지원사업 MVP는 중간점검과 최종시연 일정이 있고, B2B SaaS는 고객사별 운영 화면이 깨지면 바로 신뢰 문제가 됩니다. 관리자 화면은 내부 도구처럼 보여도 결제, 정산, 고객 데이터 수정, 알림 발송처럼 서비스 운영의 핵심 권한을 갖는 경우가 많습니다. 빌드 도구 전환은 화면 하나를 바꾸는 일이 아니라 배포 체인 전체의 전제 조건을 바꾸는 일입니다.
| 프로젝트 유형 | Turbopack 전환 기대효과 | 먼저 확인할 리스크 |
|---|---|---|
| 마케팅 랜딩·콘텐츠 사이트 | 로컬 개발 서버 반응, 반복 배포 시간, 이미지·CSS 수정 속도 개선 가능성 | 정적 생성 결과, SEO 메타, sitemap, OG 이미지, CSS 순서 |
| B2B SaaS | 대형 App Router 프로젝트의 개발 경험 개선 가능성, 반복 빌드 시간 관리 | 권한별 라우트, RSC 경계, 인증 세션, 번들 크기, 서드파티 SDK |
| 관리자 화면 | 대량 컴포넌트 수정 시 HMR 체감 개선 가능성 | 차트·그리드·리치 에디터·파일 업로드·모니터링 플러그인 |
| 지원사업 MVP | 짧은 개발 기간에서 반복 수정 비용 감소 가능성 | 데모 전 빌드 실패, 외주 인수인계 문서 부족, CI 환경 Node 버전 불일치 |
2. 마이그레이션 전 점검표: next.config.js부터 CI까지
Turbopack 전환을 시작하기 전에 가장 먼저 할 일은 코드 수정이 아니라 목록화입니다. 특히 외주개발로 시작한 프로젝트는 왜 특정 webpack 설정이 들어갔는지 모르는 경우가 많습니다. 설정의 목적을 모르는 상태에서 삭제하면 당장은 빌드가 통과해도 특정 고객사 브라우저, 특정 관리자 메뉴, 특정 파일 형식에서 문제가 발생합니다.
| 점검 항목 | 확인 질문 | 실무 판단 |
|---|---|---|
| custom webpack 함수 | next.config.js에 webpack: config => config 형태가 있는가? | 목적이 없으면 삭제 후보, 플러그인 때문에 필요하면 대체 경로 검토 |
| webpack plugin | 번들 분석, Sentry, source map 업로드, 환경변수 주입, 파일 복사 플러그인이 있는가? | Turbopack은 webpack plugin을 그대로 지원한다고 보면 안 됨 |
| webpack loader | SVG, MDX, YAML, raw text, GraphQL loader가 있는가? | turbopack.rules로 이전 가능한지 작은 샘플에서 먼저 확인 |
| CSS·SCSS | Tailwind, PostCSS, Sass, CSS Modules, ~bootstrap import를 쓰는가? | PostCSS와 Sass 기본 지원 여부보다 custom Sass function, import 경로, CSS 순서 확인이 중요 |
| Babel | .babelrc 또는 babel.config.js가 있는가? | Next.js 16의 Babel 자동 감지 흐름과 기존 SWC 사용 차이를 확인 |
| Monorepo | workspace 밖의 패키지를 link하거나 사내 UI 패키지를 참조하는가? | turbopack.root와 패키지 경계 설정 필요 가능성 |
| CI/CD | Node.js 버전, package manager, .next 캐시, 빌드 산출물 경로가 고정되어 있는가? | Next.js 16 최소 런타임 조건과 캐시 정책을 배포 환경에 반영 |
| 테스트 | App Router, Server Actions, 인증, 관리자 권한 테스트가 자동화되어 있는가? | 빌드 통과와 화면 정상은 다르므로 회귀 테스트 기준 필요 |
Webpack 설정은 세 그룹으로 나눠야 합니다
- 삭제 가능한 설정: Next.js가 이미 기본 지원하는 CSS, CSS Modules, Sass, 일반 Babel 목적 설정 등입니다. 오래된 boilerplate에서 남은 설정일 수 있습니다.
- Turbopack 옵션으로 이전할 설정: alias, 확장자 해석, SVG loader처럼
turbopack.rules,resolveAlias,resolveExtensions로 옮길 수 있는 설정입니다. - 당분간 webpack을 유지할 설정: webpack plugin 기반의 빌드 산출물 조작, 특수 source map 업로드, 검증되지 않은 모니터링 연동입니다. 이 경우 production build만
--webpack으로 유지하는 전략도 가능합니다.
테스트 전략이 없다면 마이그레이션 논의가 추상적으로 흐릅니다. App Router 프로젝트라면 라우트 단위 렌더링, Server Actions, 인증 흐름을 먼저 정리해 두는 것이 좋습니다. 관련 기준은 Next.js App Router 테스트 전략 가이드에서 별도로 다뤘습니다.
3. 실험 브랜치 운영: 하루짜리 버전업이 아니라 비교 가능한 실험
운영팀이 가장 경계해야 할 방식은 main 브랜치에서 버전을 올리고 빌드 에러를 보면서 즉흥적으로 설정을 삭제하는 것입니다. Turbopack 전환은 최소한 별도 브랜치, 기준 측정, CI 병렬 실행, canary 배포, 롤백 스크립트를 갖춘 작은 프로젝트로 다뤄야 합니다.
- 기준선 저장: 현재 Next.js와 webpack 빌드에서 cold build, warm build,
next dev첫 라우트 진입 시간, HMR 반영 시간, 번들 크기, CI 총 시간을 기록합니다. - 업그레이드 브랜치 생성: Next.js, React, React DOM, TypeScript 타입 패키지, ESLint 관련 설정을 함께 올립니다. Node.js 20.9 이상 조건도 CI 이미지에 반영합니다.
- 설정 분리: webpack 설정을 바로 삭제하지 말고 주석과 커밋 단위로 목적을 남깁니다. 나중에 어떤 설정 때문에 문제가 생겼는지 추적하기 위함입니다.
- Turbopack 빌드 확인:
next build기본 경로에서 실패하는지 보고, 필요한 경우next build --turbopack과next build --webpack을 각각 비교합니다. - CI 병렬 실행: 같은 커밋에서 Turbopack build와 Webpack build를 나눠 돌려 산출물, 로그, 시간, 오류를 비교합니다.
- 제한 배포: 내부 사용자, staging 고객사, 특정 관리자 권한만 대상으로 canary 배포를 진행합니다.
git checkout -b chore/next16-turbopack
rm -rf .next
pnpm next build
pnpm next build --webpack
NEXT_TURBOPACK_TRACING=1 pnpm next dev이 명령어들은 정답이라기보다 실험 틀입니다. 핵심은 --webpack이 남아 있어야 롤백이 가능하고, .next 삭제 여부를 통제해야 cold build 비교가 가능하다는 점입니다. Turbopack의 filesystem cache를 켜거나 끈 상태도 명시해야 합니다. 캐시가 섞이면 성능 개선처럼 보이는 숫자가 실제 번들러 차이인지 캐시 차이인지 구분하기 어렵습니다.
4. 성능 비교: ‘빨라졌다’ 대신 숫자로 남길 것
Turbopack의 장점은 대형 프로젝트에서 특히 기대되지만, 모든 서비스에서 같은 폭의 개선을 보장한다고 말할 수는 없습니다. 프로젝트 구조, RSC 사용 방식, 패키지 수, CSS 전략, CI 캐시, 모노레포 구성에 따라 결과가 달라집니다. 따라서 의사결정자는 ‘얼마나 빨라진다더라’가 아니라 ‘우리 코드베이스에서 어떤 지표가 개선됐는가’를 물어야 합니다.
| 지표 | 측정 방법 | 판단 기준 |
|---|---|---|
| 개발 서버 첫 진입 | next dev 후 주요 라우트 첫 접속까지 시간 기록 | 개발자가 매일 반복하는 대기 시간이 줄었는지 확인 |
| HMR 반영 시간 | 관리자 테이블, 폼, 차트 컴포넌트 수정 후 화면 반영 시간 기록 | 프론트엔드 생산성 개선 여부 판단 |
| Cold build | rm -rf .next 후 CI와 로컬에서 build 시간 측정 | 캐시 없는 순수 빌드 경로 비교 |
| Warm build | 동일 환경에서 캐시를 유지한 반복 빌드 측정 | CI 캐시 정책을 적용했을 때 실제 배포 시간 확인 |
| 번들 크기 | next experimental-analyze --output 또는 분석 도구로 라우트별 client/server bundle 확인 | 관리자 화면에 불필요한 대형 패키지가 섞였는지 확인 |
| 런타임 오류 | staging 로그, 브라우저 콘솔, 모니터링 도구에서 오류 수집 | 빌드 성공 이후 실제 사용자 흐름 안전성 확인 |
| Core Web Vitals | 랜딩, 가입, 첫 대시보드 화면의 LCP, INP, CLS 관찰 | 빌드 도구 변경이 사용자 경험을 악화시키지 않았는지 확인 |
특히 번들 분석은 관리자 화면에서 중요합니다. 아이콘 라이브러리, 차트, 날짜 처리, 엑셀 내보내기, 리치 에디터는 기능 하나를 위해 큰 client bundle을 만들 수 있습니다. Turbopack 전환 자체가 번들 크기를 자동으로 줄여 주는 것은 아닙니다. 전환 과정에서 라우트별 분석을 같이 수행해야 ‘빌드 도구 교체’가 ‘프론트엔드 구조 정비’로 연결됩니다.
RSC 경계를 잘못 잡으면 서버에서 처리해도 되는 데이터 준비 로직이 client component로 내려가거나, 반대로 상호작용이 많은 화면이 불필요하게 복잡해질 수 있습니다. 이 부분은 번들러보다 아키텍처 문제에 가깝습니다. SaaS 화면의 RSC 기준은 React Server Components 성능 최적화 가이드와 함께 보면 판단이 쉬워집니다.
5. 호환성별 의사결정: CSS, MDX, SVG, Babel, 모니터링
마이그레이션 실패의 대부분은 Turbopack 자체보다 ‘우리 프로젝트가 webpack을 어떻게 확장해 왔는지 모르는 상태’에서 발생합니다. 다음 표는 SaaS·관리자 화면에서 자주 만나는 항목별 판단 기준입니다.
| 항목 | Turbopack 전환 시 확인할 점 | 권장 대응 |
|---|---|---|
| Tailwind·PostCSS | postcss.config.js 인식, Tailwind content 경로, CSS 생성 순서 | 빌드 후 핵심 화면 스냅샷과 class 누락 여부 확인 |
| SCSS·Sass | 일반 Sass는 지원되지만 custom Sass functions는 제약이 있을 수 있음 | custom function이 핵심이면 webpack 유지 또는 Sass 구조 리팩터링 |
| CSS Modules | Turbopack은 JS import 순서에 따라 CSS module ordering을 처리 | 공통 버튼, 모달, 테이블 스타일 충돌 화면을 우선 확인 |
~ import | webpack에서 쓰던 ~bootstrap 스타일 import는 그대로 안 맞을 수 있음 | ~를 제거하거나 resolveAlias로 명시 |
| SVG React Component | @svgr/webpack은 loader 형태로 이전 가능성이 있음 | turbopack.rules에 작은 샘플부터 적용 후 전체 아이콘 검증 |
| MDX | 문서형 SaaS, 도움말, 블로그에서 loader 또는 plugin 설정이 얽혀 있을 수 있음 | MDX 라우트만 따로 빌드·렌더링·검색 색인까지 확인 |
| Babel | Next.js 16은 Babel 설정 파일을 감지해 Turbopack에서 자동 사용 흐름을 제공 | 기존 Babel plugin이 왜 필요한지 확인하고 SWC 기본 처리와 충돌 여부 점검 |
| Webpack plugin | Turbopack은 webpack plugin을 지원하지 않는다고 보는 것이 안전 | 대체 CLI, 호스팅 플랫폼 기능, 별도 CI step으로 분리 |
| Bundle analyzer | @next/bundle-analyzer나 새 분석 명령어 사용 여부 확인 | CI에서 분석 산출물을 저장해 전후 비교 가능하게 구성 |
| 모니터링·source map | 빌드 후 source map 업로드, release 식별자, debug ID 연동 확인 | staging에서 실제 오류를 발생시켜 매핑되는지 테스트 |
관리자 화면에서 자주 보이는 함정
관리자 화면은 사용자가 적다는 이유로 성능과 빌드 안정성을 후순위로 두기 쉽습니다. 그러나 운영자가 하루 종일 사용하는 화면이라면 개발 서버 속도보다 런타임 오류, 데이터 저장 실패, 권한별 메뉴 노출 오류가 더 큰 비용을 만듭니다. 특히 차트와 데이터 그리드 패키지는 브라우저 전용 코드가 많아 server/client 경계에서 오류가 날 수 있습니다. Turbopack 전환 브랜치에서는 ‘로그인 후 대시보드가 뜬다’가 아니라 ‘권한별 메뉴, 필터, 정렬, 엑셀 다운로드, 파일 업로드, 대량 수정, 알림 발송’까지 검증해야 합니다.
6. 배포 리스크 관리: 랜딩, SaaS, 관리자 화면을 같은 기준으로 보지 말 것
빌드 도구를 바꾼 뒤 모든 라우트를 한 번에 배포하는 것은 작은 팀에게 부담이 큽니다. 라우트의 성격에 따라 gate를 나누면 리스크를 줄일 수 있습니다.
| 영역 | 배포 전 gate | 실패 시 조치 |
|---|---|---|
| 랜딩·가격 페이지 | 메타태그, canonical, OG 이미지, sitemap, LCP, 폼 제출 | 해당 라우트 rollback 또는 이전 build artifact 유지 |
| 로그인·인증 | 세션 유지, refresh token, 권한 리다이렉트, protected route | 즉시 --webpack build로 되돌리고 인증 로그 비교 |
| SaaS 대시보드 | 고객사별 데이터 분리, chart hydration, API 오류 처리 | canary 사용자 범위 축소 후 문제 패키지 분리 |
| 관리자 CRUD | 생성·수정·삭제·대량처리·감사 로그 기록 | 배포 차단. 관리자 데이터 손상은 속도 개선보다 우선순위가 높음 |
| 파일·리포트 | 업로드, 다운로드, PDF·Excel 생성, MIME 처리 | 서버 API와 client bundle 의존성 분리 여부 확인 |
| AI·자동화 기능 | 도구 호출, 큐 처리, 진행 상태 표시, 실패 재시도 | 프론트 변경과 백엔드 작업 큐를 분리해 원인 범위 축소 |
Next.js 16 전후에는 Turbopack 외에도 Proxy, 캐싱, 런타임 경계처럼 함께 점검할 변화가 있습니다. Edge와 Node 런타임을 어디에 둘지 고민하는 팀이라면 Next.js Edge Functions 운영 가이드를 함께 참고해 라우팅, 인증, A/B 테스트, API 경계를 나누는 편이 좋습니다.
7. 롤백 기준과 ‘마이그레이션 완료’의 정의
좋은 롤백 기준은 감정적 판단을 줄입니다. 대표나 PM은 ‘문제가 생기면 알아서 되돌리자’가 아니라 어떤 상황에서 즉시 --webpack으로 되돌릴지 숫자와 조건을 정해야 합니다.
즉시 롤백을 고려할 조건
- production build가 통과해도 staging에서 인증, 결제, 관리자 저장 기능 중 하나가 실패한다.
- CSS 순서 변화로 주요 랜딩, 가격표, 대시보드, 모달의 레이아웃이 깨진다.
- source map 또는 모니터링 연동이 끊겨 배포 후 오류 원인 추적이 불가능하다.
- CI 총 시간이 줄지 않거나 오히려 늘었는데 원인을 설명할 수 없다.
- 특정 webpack plugin 대체 방안이 없고, 해당 plugin이 운영 필수 기능을 담당한다.
- 고객사별 권한 화면 또는 관리자 대량 작업에서 재현 가능한 런타임 오류가 발생한다.
완료로 볼 수 있는 조건
next.config.js에서 불필요한 webpack 설정이 제거되었고, 남은 설정의 목적이 문서화되어 있다.- Turbopack build와 rollback용 Webpack build 명령이 CI에 명확히 분리되어 있다.
- cold build, warm build, HMR, bundle size, 주요 라우트 오류율의 전후 비교표가 남아 있다.
- 랜딩, 인증, SaaS 대시보드, 관리자 CRUD, 파일 처리, 모니터링 연동이 staging에서 검증되었다.
- 신규 개발자가 들어와도 Turbopack 관련 alias, loader, cache 정책을 이해할 수 있는 README가 있다.
여기까지 되어야 마이그레이션 완료라고 말할 수 있습니다. 단순히 next build가 통과했다는 사실만으로는 운영 리스크가 충분히 줄었다고 보기 어렵습니다.
8. 2주 안에 끝내는 최소 실행 로드맵
팀 규모가 작다면 Turbopack 마이그레이션을 장기 프로젝트로 만들기보다 2주 안에 ‘전환 가능 여부’를 판단하는 방식이 현실적입니다. 핵심은 모든 문제를 한 번에 해결하는 것이 아니라, 의사결정 가능한 산출물을 만드는 것입니다.
| 기간 | 작업 | 산출물 |
|---|---|---|
| 1~2일차 | Next.js 버전, Node 버전, webpack 설정, 플러그인, loader, CI 캐시 조사 | 마이그레이션 영향도 표 |
| 3~4일차 | 기준선 측정: Webpack build, dev server, HMR, 번들 분석 | before 지표 |
| 5~7일차 | Next.js 16 브랜치 생성, Turbopack 기본 빌드, 설정 이전 | 빌드 에러 목록과 해결 후보 |
| 8~9일차 | CSS, SVG, MDX, 관리자 핵심 화면 검증 | 호환성 체크리스트 |
| 10일차 | CI 병렬 실행과 분석 산출물 저장 | Turbopack vs Webpack 비교표 |
| 11~12일차 | staging 또는 내부 canary 배포 | 런타임 오류와 사용자 흐름 검증 결과 |
| 13~14일차 | 전환·보류·롤백 의사결정 | 최종 실행안과 README |
이 로드맵에서 중요한 점은 ‘완전 전환’만 성공으로 보지 않는 것입니다. 어떤 서비스는 당장 Turbopack으로 production build를 바꾸는 것이 맞고, 어떤 서비스는 개발 서버만 Turbopack을 쓰고 production build는 --webpack으로 유지하는 편이 맞습니다. 의사결정자는 속도 개선보다 운영 안정성, 원인 추적 가능성, 팀의 유지보수 능력을 함께 봐야 합니다.
AgentMit 관점: Turbopack 전환은 프론트엔드 아키텍처 정비의 기회입니다
AgentMit은 Next.js Turbopack 마이그레이션을 단순 버전 업그레이드로 보지 않습니다. SaaS와 관리자 화면에서는 번들러보다 더 오래 남는 문제가 있습니다. 너무 큰 client component, 목적을 모르는 webpack 설정, CI에만 숨어 있는 환경변수, source map이 연결되지 않는 모니터링, 외주 인수인계 때 빠진 배포 문서가 그렇습니다.
BizMit처럼 업무 운영을 담는 SaaS·자동화 서비스, AI 기능이 붙은 관리자 화면, 정부지원사업 MVP를 운영 서비스로 확장하려는 팀이라면 Turbopack 전환 시점에 다음 작업을 함께 정리하는 것이 좋습니다. 첫째, App Router 구조와 RSC 경계를 재점검합니다. 둘째, 관리자 화면의 번들 분석과 권한 테스트를 자동화합니다. 셋째, CI/CD에서 Webpack 롤백 경로를 남깁니다. 넷째, 외주 이후에도 유지보수 가능한 README와 운영 체크리스트를 만듭니다.
내부에 프론트엔드·DevOps 경험이 충분하지 않다면 AgentMit은 Next.js 업그레이드, Turbopack 호환성 점검, SaaS 관리자 대시보드 개선, CI/CD 템플릿, 번들 분석 자동화, AI 서비스 화면 구현까지 필요한 범위만 나눠 지원할 수 있습니다. 다만 첫 단계는 상담이 아니라 현재 프로젝트의 next.config.js, CI 로그, 핵심 라우트, 운영 장애 이력을 모아보는 것입니다. 그 자료가 있어야 현실적인 견적과 일정이 나옵니다.
참고한 공식 문서
이 글은 2026년 8월 작성 시점에 공개된 Next.js 공식 문서를 기준으로 정리했습니다. 실제 적용 전에는 사용 중인 Next.js 마이너 버전, 호스팅 플랫폼, 배포 런타임, 패키지 버전을 다시 확인해야 합니다.
- Next.js Version 16 Upgrade Guide: Turbopack 기본값, custom webpack 설정 실패 조건,
--webpack우회, Node.js·TypeScript 요구사항 - Next.js Turbopack API Reference: 지원 기능, Webpack과의 차이, CSS·Sass, Babel, 캐시, trace 파일
- next.config.js turbopack:
rules,resolveAlias,resolveExtensions, loader 호환 범위 - Next.js CLI Reference:
--webpack,next experimental-analyze, 분석 산출물 저장 - Next.js Package Bundling Guide: bundle analyzer와 패키지 최적화 기준
FAQ
- Q1. Next.js 16으로 올리면 Turbopack을 반드시 써야 하나요?
- 기본값은 Turbopack이지만 반드시 즉시 전환해야 하는 것은 아닙니다. 기존 webpack 설정이나 플러그인이 핵심이면
next build --webpack으로 우회할 수 있습니다. 다만 장기적으로는 webpack 설정을 삭제 가능한 것, Turbopack 옵션으로 이전할 것, 당분간 유지할 것으로 나눠 관리하는 편이 안전합니다. - Q2. 기존 webpack 플러그인은 Turbopack에서 그대로 동작하나요?
- 일반적으로 그대로 동작한다고 가정하면 안 됩니다. Turbopack은 일부 webpack loader 호환을 제공하지만 webpack plugin은 지원하지 않는다고 공식 문서가 설명합니다. 번들 분석, 모니터링, 에러 추적, 빌드 산출물 조작 플러그인은 대체 방법이나
--webpack유지 여부를 먼저 검토해야 합니다. - Q3. Tailwind, SCSS, SVG, MDX는 Turbopack 마이그레이션 때 무엇을 확인해야 하나요?
- Tailwind와 PostCSS는
postcss.config.js인식 여부를 확인하고, SCSS는 custom Sass functions 사용 여부와 node_modules import 경로를 확인해야 합니다. SVG는@svgr/webpack을turbopack.rules로 이전할 수 있는지 테스트하고, MDX는 현재 사용 중인 설정이 Turbopack 빌드에서 통과하는지 별도 브랜치에서 검증하는 것이 좋습니다. - Q4. Turbopack 전환 후 빌드 속도가 빨라졌는지 어떻게 비교하나요?
- 감각이 아니라 기준 빌드 시간을 남겨야 합니다. Webpack과 Turbopack 각각에서
.next를 삭제한 cold build, 캐시가 있는 warm build, 첫 페이지 컴파일, HMR 반영 시간, CI 전체 소요 시간, 번들 크기, 주요 라우트의 런타임 오류를 같은 조건으로 비교해야 합니다. - Q5. SaaS 관리자 화면은 언제 --webpack으로 유지하는 게 낫나요?
- 권한별 메뉴, 데이터 그리드, 차트, 리치 에디터, 파일 업로드, 모니터링 플러그인처럼 운영 리스크가 큰 의존성이 많고 Turbopack 대체 경로가 아직 검증되지 않았다면
--webpack으로 production build를 유지하는 선택이 합리적일 수 있습니다. 대신 전환을 포기하지 말고 호환성 이슈를 목록화해 단계적으로 제거해야 합니다.
