Next.js를 Vite로 옮기기 전에: Vinext 1.0 호환성 점검표

빌드 도구를 바꾸면 개발 속도가 빨라질 것이라는 이야기는 매력적입니다. 하지만 이미 사용자가 있는 앱에서는 첫 화면이 뜨는 것만으로 전환을 결정하기 어렵습니다. 로그인한 사람의 화면, 저장 직후 목록, 오래 열어 둔 탭에서도 기존 동작이 유지되어야 합니다.

Cloudflare는 2026년 9월 28일 Vinext 1.0을 발표했습니다. Next.js 애플리케이션을 Vite 기반으로 실행하고 배포 환경의 선택지를 넓히려는 프로젝트입니다. 웹 개발을 오래 해 온 제게 흥미로운 지점은 새 도구 자체보다, 익숙한 API의 행동을 다른 기반에서 어디까지 유지하느냐입니다.

이 글은 운영 서비스를 Vinext로 이전한 후기가 아닙니다. 10월 11일 확인한 공식 발표에서 현재 범위를 짚고, 실제 앱의 전환 검토에 사용할 점검 순서를 정리합니다. 아래 항목을 통과했다는 결과나 성능 개선 수치는 아직 주장하지 않습니다.

호환된다는 말을 내 앱의 동작으로 바꿉니다

공식 발표는 App Router와 Pages Router, 서버 액션, 라우트 핸들러 등 여러 동작의 지원을 설명합니다. 동시에 Cache Components를 이끄는 use cache 지시어의 지원은 제한적이라고 밝힙니다. 따라서 1.0이라는 이름만 보고 모든 Next.js 앱에 그대로 적용할 수 있다고 해석하면 안 됩니다.

여기서 중요한 구분은 함수가 존재하는 것과 사용자에게 같은 결과를 주는 것입니다. 캐시 무효화 함수를 호출할 수 있어도 이후 요청과 다른 탭에서 보이는 데이터가 다르면 운영에서는 차이가 생깁니다. 먼저 내 앱이 사용하는 기능을 적고, 그 기능을 호출한 뒤 사용자가 무엇을 보아야 하는지 문장으로 바꿔야 합니다.

기능 목록은 실제 경로를 중심으로 만듭니다. 로그인, 글 저장, 이미지 업로드, 검색, 결제 완료 화면처럼 사용자가 작업을 끝내는 흐름입니다. 사용하지 않는 고급 기능의 지원 여부보다 매일 이용하는 한 경로의 정확성이 먼저입니다.

• 환경: 현재 Next.js와 Node.js, 패키지 잠금 파일, 배포 대상과 환경변수를 기록합니다. 비밀 값 대신 변수 이름과 용도만 남깁니다.
• 입력: 사용자 상태, 요청 방식, 경로와 필요한 데이터를 정합니다.
• 기대 결과: 화면뿐 아니라 상태 코드, 쿠키, 저장 결과와 다음 요청의 동작을 적습니다.
• 실패 결과: 인증 만료, 중복 제출, 누락 데이터에서 기존 앱이 어떻게 대응하는지도 남깁니다.

라우팅과 인증, 저장 이후의 캐시를 먼저 봅니다

첫 번째로 확인할 것은 주소입니다. 목록에서 상세로 이동할 때와 상세 주소를 새 창에서 직접 열 때가 같아야 합니다. 새로고침, 뒤로 가기, 존재하지 않는 주소, 한글 검색어와 여러 쿼리 조건도 포함합니다. 개발 서버에서는 정상인데 배포 환경에서 직접 접근이 실패하는 문제를 분리해서 볼 수 있어야 합니다.

두 번째는 인증과 권한입니다. 로그인 성공 화면 하나로 끝내지 말고 로그아웃 후 같은 주소를 다시 열어 봅니다. 만료된 세션, 권한이 다른 두 계정, 비로그인 요청을 각각 구분합니다. 쿠키가 저장되는지뿐 아니라 보호된 데이터가 다른 사용자에게 보이지 않는지를 확인해야 합니다. 이것은 속도 비교보다 앞에 둘 조건입니다.

세 번째는 쓰기 이후의 읽기입니다. 예를 들어 원고 제목을 저장하면 편집 화면, 목록, 상세 화면에 어떤 순서로 새 제목이 보여야 하는지 정합니다. 같은 브라우저의 다른 탭과 새 세션에서도 확인할 범위를 기록합니다. 캐시를 쓰지 않는다고 생각한 화면도 데이터 요청 계층에 캐시가 있다면 별도 검토가 필요합니다.

사용 흐름	성공 조건의 예시	보류 신호
상세 주소 직접 열기	예상 화면과 상태 코드 반환	내부 이동만 성공
로그아웃 후 재접속	보호된 내용 접근 차단	이전 사용자 데이터 노출
제목 수정 후 목록 이동	설계한 시점에 새 값 표시	탭마다 값이 계속 다름
저장 버튼 중복 입력	중복 처리 정책 유지	동일 작업이 여러 번 생성

표의 성공 조건은 모든 서비스의 정답이 아닙니다. 일부 화면은 일정 시간 오래된 값을 보여 주도록 설계할 수 있습니다. 그런 경우에는 즉시 갱신을 무조건 요구하기보다 원래 약속한 지연 범위를 유지하는지 봅니다. 전환 검증 과정에서 원래 설계도 설명할 수 없다는 사실을 발견했다면, 먼저 그 약속을 정리하는 것이 순서입니다.

실제 배포 환경의 의존성과 복귀 경로를 확인합니다

Vite로 빌드할 수 있는지와 목표 런타임에서 필요한 기능이 동작하는지는 별개의 확인입니다. 파일 시스템, 네이티브 모듈, 외부 서비스 연결, 요청 시간 제한처럼 서버 코드가 기대하는 조건을 목록으로 만듭니다. 특정 호스팅에서 제공하던 기능을 다른 곳에서도 같은 이름으로 제공한다고 가정하지 않습니다.

이때 개발 환경과 배포 환경을 구분해 결과를 남깁니다. 로컬에서는 이미지가 보이는데 배포 후 최적화 주소가 실패하거나, 환경변수는 있는데 공개되는 위치가 달라지는 문제를 찾으려면 어느 환경에서 확인했는지 알아야 합니다. 로그에 오류가 없다는 말도 실제 요청이 해당 경로를 거쳤을 때만 의미가 있습니다.

비교용 복사본에는 운영 비밀 값과 실제 고객 데이터를 무심코 가져오지 않습니다. 목적에 맞는 시험 계정과 허가된 데이터를 준비합니다. 외부 알림이나 결제처럼 다른 시스템을 바꾸는 경로는 시험 환경을 연결해야 합니다. 화면을 점검하다 실제 사용자에게 메일이 발송되면 도구 검토의 범위를 벗어나게 됩니다.

복귀는 이전 버전으로 다시 배포하는 명령만의 문제가 아닙니다. 전환 도중 데이터 형식이나 업로드 위치가 바뀌었다면 기존 앱이 새 데이터를 읽을 수 있어야 합니다. 캐시, 정적 파일, 도메인 연결도 원래 경로로 돌아갈 수 있는지 적습니다. 복귀 절차를 설명할 수 없으면 작은 앱이라도 운영 전환은 보류하는 편이 낫습니다.

성능은 동작을 맞춘 다음 같은 조건에서 비교합니다

새 도구를 평가하다 보면 빌드 시간이나 첫 응답 속도가 먼저 눈에 들어옵니다. 그러나 서로 다른 데이터와 캐시 상태로 측정한 숫자는 선택 근거가 되기 어렵습니다. 같은 코드 변경, 같은 데이터 크기, 같은 요청 흐름으로 비교할 범위를 고정해야 합니다. 첫 요청과 캐시가 준비된 뒤 요청도 나누어 기록합니다.

개인 프로젝트에서는 숫자를 많이 모으기보다 실제 불편을 하나 정하는 편이 좋습니다. 배포 대기가 문제라면 빌드부터 배포 완료까지, 느린 편집 화면이 문제라면 사용자가 작업을 끝내기까지를 봅니다. 도구가 보여 주는 한 구간의 개선이 전체 작업의 개선과 같은지 확인해야 합니다.

운영 비용도 같은 관점으로 봅니다. 호스팅 청구액뿐 아니라 전환 코드, 배포 설정, 장애 조사에 필요한 시간이 추가될 수 있습니다. 한 번의 실험에서 비용이 줄어 보이더라도 사용량이 달라지는 구간에서 다시 확인할 조건을 적어 둡니다. 이 글에서는 직접 측정하지 않은 절감률이나 공급사의 수치를 제 앱의 성과로 바꾸지 않습니다.

검토 결과는 도입과 거절 두 칸보다 유지, 시험, 전환의 세 칸으로 정리할 수 있습니다. 현재 불편이 작으면 유지합니다. 기대 이득은 있지만 중요한 경로가 미확인이면 시험을 이어갑니다. 필요한 동작과 복귀 방법을 확인했고 운영 부담을 감당할 수 있을 때 전환을 검토합니다. 새 버전이 나오는 것만으로 이 판단을 매번 처음부터 반복할 필요는 없습니다.

마치며: 명령어보다 성공 조건 한 줄이 먼저입니다

Vinext 1.0은 Next.js 앱의 실행과 배포를 검토할 새로운 선택지입니다. 선택지가 늘어난다는 점은 반갑지만, 내 앱의 책임까지 도구가 대신 정해 주지는 않습니다. 사용자에게 유지해야 할 행동을 문장으로 적어야 호환성이라는 큰 단어를 검증 가능한 일로 바꿀 수 있습니다.

오늘 할 일로는 가장 중요한 사용자 흐름 하나를 고르고 성공과 실패 조건을 각각 한 줄 쓰는 것을 권합니다. 도구를 당장 바꾸지 않아도 이 기록은 다음 배포와 회귀 확인에 사용할 수 있습니다. 이전 여부를 판단하는 과정에서 기존 서비스가 지켜야 할 약속을 더 분명히 하는 셈입니다.

출처: Cloudflare, Vinext 1.0 발표(2026-09-28, 확인 2026-10-11). 지원 범위는 이후 변경될 수 있으며, 본문 점검표는 운영 이전을 수행한 결과가 아닌 검토안입니다.