2026년 기준으로 Next.js 프로젝트를 새로 세팅한다면, 그냥 create-next-app 치고 시작하는 건 좀 아쉽습니다. 프레임워크 내부에 이미 꽤 정교한 기능들이 내장되어 있는데, 모르고 지나치면 나중에 '왜 이걸 진작 안 썼지?' 하게 되거든요. Turbopack, Draft Mode, Edge Runtime, Instrumentation—이 네 가지가 딱 그 경우입니다. 각각 번들 성능, 콘텐츠 미리보기 워크플로우, 런타임 전략, 그리고 모니터링 초기화에 직결됩니다. 하나씩 짚어볼게요.
① Turbopack: 이제 기본값입니다, 근데 함정도 있어요
Turbopack은 Rust로 작성된 점진적(incremental) 번들러로, Next.js에 아예 내장되어 있습니다. next dev만 쳐도 바로 활성화됩니다. 따로 설정할 게 없다는 게 포인트예요. Webpack 대비 로컬 개발 서버 기동 속도가 압도적으로 빠른 건 사실인데, '점진적'이라는 말의 의미를 제대로 이해하고 써야 합니다.
서버 기동은 미칠 듯이 빠른데, 특정 페이지에 처음 접속할 때 약간의 지연이 생깁니다. 그 순간에 해당 페이지에 필요한 모듈만 골라서 번들링하기 때문이에요. 사용자 입장에서는 첫 방문 시 로딩이 살짝 걸리는 것처럼 느껴질 수 있는데, 개발 환경에서만 그렇다는 걸 팀원들한테 미리 설명해두지 않으면 버그 신고가 들어옵니다. 실제로 겪어봤어요.
주의해야 할 지점이 하나 있습니다. 아직 생태계의 모든 플러그인이 Turbopack을 지원하지 않습니다. 특히 레거시 프로젝트에서 커스텀 Webpack 플러그인을 쓰고 있다면, next dev --webpack 플래그로 Webpack으로 폴백하는 옵션이 있습니다. Sass sassOptions.functions를 활용한 커스텀 함수도 현재는 Turbopack에서 지원이 안 됩니다—Rust 기반 아키텍처라 Node.js 함수를 직접 실행할 수 없기 때문이에요. 레거시 Sass 코드가 있는 팀은 마이그레이션 전에 이 부분 반드시 확인하세요.
② Draft Mode: 기획자·에디터가 진짜 좋아하는 기능
SSG(정적 생성) 기반 블로그나 마케팅 페이지를 운영하다 보면, 콘텐츠 하나 수정할 때마다 전체 사이트를 리빌드해야 하는 상황이 생깁니다. 기획자가 오타 하나 고치고 결과 확인하려고 몇 분씩 기다리는 건 솔직히 말이 안 되는 경험이에요. Draft Mode가 이 문제를 해결합니다.
작동 방식은 쿠키 기반입니다. Route Handler에서 draftMode().enable()을 호출하면 브라우저에 __prerender_bypass 쿠키가 심기고, 이후 해당 브라우저의 요청에 한해서만 페이지가 SSR로 동적 렌더링됩니다. 일반 사용자 브라우저에는 쿠키가 없으니 기존 정적 페이지를 그대로 보게 되고요. Headless CMS(Contentful, Sanity 등)와 연동할 때 시크릿 토큰 + slug 파라미터를 검증하는 패턴으로 안전하게 구성하는 게 정석입니다.
한 가지 꼭 짚고 싶은 보안 포인트: slug 파라미터를 검증 없이 redirect(slug)에 그냥 때려 넣으면 Open Redirect 취약점이 생깁니다. 악의적인 요청자가 ?slug=https://phishing-site.com을 넣으면 우리 서버가 피싱 사이트로 리다이렉트해버리는 거예요. CMS에서 실제 존재하는 slug인지 먼저 검증하고, 검증된 경로로만 리다이렉트해야 합니다. 기획서에는 당연히 안 나와 있는 내용이에요.
③ Edge Runtime: 빠르지만 '가벼워야' 합니다
Next.js는 Node.js 런타임과 Edge 런타임 두 가지를 선택적으로 쓸 수 있습니다. Edge Runtime은 전 세계 CDN 노드에서 사용자와 가장 가까운 위치에서 실행되는 경량 환경입니다. V8 엔진 기반이라 빠르지만, 파일 시스템(fs) 접근이나 Node.js 내장 모듈을 쓸 수 없다는 게 핵심 제약입니다.
ISR을 쓰고 싶은데 Edge Runtime을 선택했다면, 그 조합은 안 됩니다. ISR은 파일 시스템에 렌더링 결과를 저장하는 방식인데, Edge 환경은 파일 시스템 자체가 없거든요. 대신 스트리밍은 Edge에서 아주 강력합니다. AI 응답처럼 텍스트가 실시간으로 흘러나오는 UX—글자가 타이핑되듯 화면에 나타나는 그 경험—를 구현하려면 Edge Runtime + ReadableStream 조합이 핵심 기술이 됩니다. 포트폴리오에 AI 채팅 기능 넣으실 분들, 참고하세요.
런타임 선택은 라우트 단위로 가능합니다. 모든 라우트를 Edge로 돌릴 필요도 없고, 그래서도 안 됩니다. 무거운 DB 처리나 Node.js 전용 라이브러리가 필요한 라우트는 Node.js 런타임에 두고, 지연에 민감한 경량 API나 미들웨어만 Edge로 보내는 전략이 현실적입니다.
④ Instrumentation: 서버 켜기 전에 모니터링부터
Sentry, Datadog, New Relic 같은 모니터링 툴을 Next.js 프로젝트에 붙이다 보면 "초기화 코드를 어디에 넣어야 하지?" 하는 문제에 부딪힙니다. 컴포넌트 안에 넣자니 서버 사이드 처리가 문제고, _app.tsx에 넣자니 Pages Router 한정이고. Instrumentation이 이 고민을 해결합니다.
프로젝트 루트에 instrumentation.ts 파일을 만들고 register 함수를 export하면, Next.js 서버 인스턴스가 시작될 때 딱 한 번 이 함수를 실행합니다. 트래픽을 받기 전에 실행이 완료되어야 하기 때문에, 여기에 대용량 데이터 전처리 같은 무거운 작업을 넣으면 서버 기동이 한참 걸립니다. 모니터링 툴 초기화 정도가 적절한 용도예요.
실무에서 놓치기 쉬운 포인트 두 가지. 첫째, 파일 최상단에 정적으로 import하지 말고 register 함수 내부에서 await import()로 동적 import하세요. 환경 변수(.env)가 완전히 로드되기 전에 파일이 먼저 평가되면서 에러가 터지는 경우가 생각보다 자주 있습니다. 둘째, Edge와 Node.js 환경에서 각각 다른 초기화 코드가 필요하다면 process.env.NEXT_RUNTIME으로 분기하세요. Datadog APM처럼 Node.js 전용 모듈을 내부적으로 쓰는 툴을 Edge 환경에서 초기화하려 하면 서버가 뻗습니다.
결국 이건 DX와 성능의 교차점
네 가지를 묶어서 보면 공통된 맥락이 보입니다. Turbopack은 개발자 경험(DX)에서 체감되는 빌드 성능의 문제이고, Draft Mode는 콘텐츠 팀과의 협업 워크플로우 문제입니다. Edge Runtime은 런타임 아키텍처 전략이고, Instrumentation은 프로덕션 가시성(observability) 문제예요. 각각 독립적으로 보이지만, 결국 '서비스가 안정적으로, 빠르게, 협업 가능하게 돌아가는가'라는 하나의 질문에 대한 답변입니다.
특히 Turbopack의 Webpack 폴백 옵션과 Edge/Node.js 런타임 혼용 전략은 당장 도입하기 어려운 레거시 프로젝트에서 점진적 마이그레이션 경로를 열어줍니다. '한 번에 다 바꿔야 한다'는 부담 없이 라우트 단위, 기능 단위로 새 패러다임을 실험해볼 수 있다는 게 지금 Next.js가 가진 현실적인 강점이에요. 다음 프로젝트 세팅할 때, 이 네 가지는 체크리스트에 넣어두세요.