▲

Next.js 15.1+는 Vercel 외 환경에서 사실상 쓸 수 없다

 (omarabid.com)
10P by GN⁺ 1일전 | ★ favorite | 댓글 5개
  • Next.js 15.1.8부터 메타데이터 처리 방식이 변경되어 Vercel 이외의 배포 환경에서 심각한 문제 발생
    • 메타데이터가 HTML head에 직접 렌더링되지 않고 "메타데이터 스트리밍"이라는 방식으로 따로 전송됨
  • 검색 엔진이 자바스크립트를 실행하지 않으면 메타데이터가 아예 노출되지 않아 SEO가 치명적으로 훼손
    • 크롤러 감지(htmlLimitedBots)로 예외 처리하지만 완벽하지 않음
  • Vercel이 아닌 Netlify, Cloudflare, AWS 등은 OpenNext로 호환 시도 중이나, 실제로는 Next.js가 Vercel 인프라에 너무 강하게 묶여 포팅 자체가 어렵고 버그가 많음
  • 정적 빌드도 메타데이터가 HTML head에 포함되지 않으며, 모든 배포 환경이 복잡한 크롤러 감지/JS 실행을 강요받는 구조로 바뀜
  • 보안 이슈(2025년 3월 공개된 치명적 취약점)
    • 메타데이터 스트리밍을 피하려고 구버전을 고집하면 심각한 보안 취약점에 노출됨(패치는 15.2.3에서만 제공)
  • 메타데이터 스트리밍은 실제로 페이지 성능 문제를 감추고, SEO에도 부정적 영향
  • 결론:
    Next.js는 오픈소스처럼 보이지만, 사실상 Vercel 종속이 심각한 프레임워크가 되었으므로 새 프로젝트에는 다른 선택지를 고려하는 것이 현명함

개요

  • Next.js 15.1.8 버전부터 Vercel을 제외한 환경에서 metadata 처리에 심각한 문제가 발생함
  • 이는 Next.js의 본질적으로 Vercel 인프라에 대한 종속성 심화와 검색 엔진 최적화(SEO) 저하, 심지어 보안 위협까지 야기함

문제의 시작: metadata streaming의 도입

  • 2024년, Vercel은 metadata streaming이라는 실험적 기능을 도입함
  • 기존 방식과 달리 metadata(tags: title, description, Open Graph 등)를 HTML ``에 직접 렌더링하지 않고, 초기 페이지 로딩 이후 별도로 전송함
  • 이 기능은 JavaScript 실행이 필요해짐

Vercel의 기술적 설명과 실질적 문제점

  • 도입 배경: metadata 생성의 컴퓨팅 병목 현상 해소 목적
  • 하지만 실제 metadata는 대부분 정적이고 소량(1KB 미만)의 데이터임
  • 서버 round-trip 비용이 inline 처리보다 더 큼
  • 동적 metadata는 극히 일부 예외적 케이스임
  • metadata streaming의 구현 복잡성과 혼란 가중

성능 문제의 배경

  • 일부 개발자가 외부 API 연동 등에서 metadata 생성 지연이라는 성능 이슈를 겪었음
  • Vercel은 이 문제를 해결하고자 스트리밍 방식을 개발함

검색 엔진 크롤러와 SEO 영향

  • JavaScript를 실행하지 않는 검색 엔진은 metadata를 읽지 못함
  • 이에 따라 SEO에 큰 악영향을 줌
  • 해결책으로 Vercel은 서버가 크롤러를 감지할 경우 스트리밍을 건너뛰고 HEAD에 metadata를 넣는 htmlLimitedBots 기능을 제공함

기타 클라우드 제공업체의 한계

  • Netlify, Cloudflare, AWS 등도 Next.js와 호환을 위해 OpenNext라는 어댑터 프로젝트를 만듦
  • 하지만 Next.js가 너무 Vercel에 밀접하게 종속되어 있어, 이식 시 리버스 엔지니어링이 필요함
  • OpenNext의 품질 문제로 인해 실질적으로 제대로 동작하지 않음

정적 빌드조차 불완전

  • 정적 사이트 빌드(Static Build)도 metadata가 더는 HTML head에 포함되지 않음
  • React Server Components와 함께 번들되므로 JavaScript 실행 필요
  • 기본 HTML metadata를 위해서 크롤러 감지 로직까지 직접 구현해야 하는 불합리함 발생

심각한 보안 취약점 및 업데이트 문제

  • 2025년 3월 21일, 치명적 취약점(보안등급 9.1, GHSA-f82v-jwr5-mffw/CVE-2025-29927) 공개됨
  • 이 취약점은 특정 헤더 조작을 통해 미들웨어의 인증 보안을 우회할 수 있음
  • 취약점 패치는 Next.js 15.2.3에 적용되었으나, metadata streaming을 피하고자 15.1.8에 머물 경우 보안에 매우 취약함

스트리밍 도입이 가져온 부정적 결과

  • metadata streaming은 숨겨진 성능 문제를 더욱 감춤
  • 페이지 메타데이터 처리 지연 시 실사용자는 인지하지 못함
  • 검색 엔진 크롤러는 느린 응답에 따라 SEO 점수 페널티를 부여하게 됨

결론

  • Next.js는 오픈소스 프레임워크라는 위장된 Vercel 벤더 록인으로 변질됨
  • 차기 프로젝트의 기술 스택 선택 시, Next.js 대신 타 프레임워크를 고려하는게 더 현명
▲
bth15923 19시간전  [-]

본문에 언급된 대로 과도한 벤더 락인, 너무 블랙박스스러운 동작들, 직관적이지 않은 API들. 게다가 React측에서도 대놓고 대놓고 이러한 서버에서 렌더링하는 식의 개발이 마치 React의 표준 개발 방식인 것처럼 마케팅하고 있죠. 대부분의 앱은 Vite기반 SPA로 충분하다고 봅니다.

답변달기
▲
kansm 18시간전  [-]

remix가 대안이 되죠?

답변달기
▲
pcj9024 1일전  [-]

벤더락인이 일어나는거는 어느정도 인정하지만 Next.js 기술 자체에 대한 의견은 그냥 보고있으면 "난 글을 읽기 싫습니다" 수준에서 벗어나지 않는거같네요

답변달기
▲
ndrgrd 1일전  [-]

전부터 꾸준히 열린 척 폐쇄적인 행보를 보이더니 결국 거의 문을 걸어 잠궜네요.

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • Next 사용을 절대 추천하지 않음. 개발자 경험이 끔찍하고, 벤더 락인이 심하며, 문서화되지 않은 이상한 관례로 인해 CRUD 위주의 단순 B2B SaaS가 아니면 곳곳에 지뢰가 있는 느낌. 특히 Next <Image /> 태그가 같은 페이지의 webgl 씬 FPS를 2까지 떨어뜨린 사례 경험

    • Vercel이 어떻게 일반 React 사용자를 벤더 락인으로 천천히 끓였는지 의문. React는 Meta에서 오픈소스를 강조한 프로젝트였고, 오픈소스가 벤더 락인 방지 역할을 하길 바랐는데 실상은 그렇지 않다는 점에 실망

    • 전적으로 동의. 최근 Next를 오랜만에 사용해봤는데 개발 경험이 매우 실망스러웠음. 문서가 모호하고 찾기 힘들었으며, 앱 자체가 기본적으로 느린 느낌. Docker로 AWS에 배포하려다 Vercel에서 제공하는 샘플 Dockerfile 때문에 수많은 어려움을 겪음

    • <Image /> 이슈를 직접 분석한 것인지 아니면 NextJs의 문제라고 추측하는 것인지 궁금. 나는 NextJs, <Image>, RTF 조합으로 일하지만 그런 문제를 겪은 적 없음

  • Next.js를 지난 3년간 업무에서 사용하며 정말 고통스럽다는 느낌. Vercel에 호스팅했고, 회사는 Vercel 서비스 거의 전부를 도입해서 본격적인 벤더 락인 경험. 예전에 Dan이 RSC 관련하여 HN에 올린 글에 나쁜 경험을 공유했는데, 그의 지적이 정확하다 느꼈음. "RSC 자체는 이제 꽤 탄탄하지만, Next.js 같은 프레임워크는 아직 좀 거칠다"는 말 처럼 전체적으로 React도 이제 평균 미만이고 Next.js는 오히려 안 좋은 평판을 가속화하는 느낌. 멀리하는 것이 상책

  • Vercel이 이번 버그를 수정하겠지만, 이제는 이런 자잘한 문제들이 쌓여 Next.js에 지침. 예로, 미들웨어에서 prefetch 식별법이 몇 주(혹은 몇 달)째 깨져 있음. 이런 자잘한 문제들이 계속 누적되는 상황이라 Next.js에 피로감 큼. 하지만 JS 생태계 자체는 여전히 애정

    • Next.js에서 벗어나 Astro로 이동. 기본으로 돌아가고 싶었지만, 직접 라우트/템플릿/정적 자산/빌드 설정하기가 귀찮았음. Astro는 이 모든 걸 처리하고, 기본적으로 SSR. React/Vue를 원래 의도한 대로 상호작용 계층으로 얹어 쓰는 느낌이라 JS 프레임워크가 실제로 얼마나 불필요한지 깨닫게 됨. Next는 점점 마법 같은 요소가 많아지고 서버 액션들이 어색하고, "NextJS 식" 구현이 너무 많았음

    • 현재 업무 및 사이드 프로젝트에 Next.js를 쓰고 있지만, 예전에는 즐겁고 생산적이었던 도구였다가 pages에서 app 라우터로 전환한 뒤 방향이 아쉬움

    • 15.1.8 버전 이후부터 일부 라이브러리1이 깨져서, 작성자가 언급한 취약한 버전으로 다운그레이드해야 하는 상황 발생

    • 동감. 앞으로 Next.js는 정적 사이트나 사전 빌드 SPA에만 사용할 계획

  • Next가 농담거리가 될 지경. Remix가 이해할 수 없을 정도로 react-router로 변신하고 나니, 괜찮은 React 프레임워크가 극히 드물어진 느낌. 결국 plain vite와 tanstack router 조합으로 돌아감

    • 이런 비판적인 글이 Hacker News에 남아있는 것이 놀라움. 예전에 Remix로 더 간단하게 구현됐다는 글을 올렸더니, Vercel 직원 여러 명에게 메시지가 와서 내리라고 하거나 미팅하자는 요청을 받았던 적 있음. 여러 SNS 계정으로 동시에 접촉함

    • 브랜드 변경 이후 Remix를 더는 안 쓴다는 뜻인지, 아니면 프레임워크가 아니란 의미인지 궁금. RR7(React Router 7)도 프레임워크로 정상 작동1함. 15년차 백엔드였다가 최근 풀스택으로 전향하여 좋은 친구 추천으로 RR7 사용하는데 매일 감탄

    • 새로운 프로젝트에서 TanStack Router를 써보고 너무 좋아서 TanStack Query, TanStack Form도 추가함

    • 대안으로 무엇이 가장 좋은지, 그리고 Vite를 쓰는 이유가 궁금. 나는 소규모 프로젝트에 Next를 쓰는데, SEO가 가장 큰 장점이라고 들었음. 정적 파일만 생성해서 S3에 업로드하면 끝인데, 그게 더는 아니냐는 궁금증

    • Remix에서 react-router로 변한 게 구체적으로 뭐가 문제인지 궁금. 내가 보기엔 단지 리브랜딩인 듯함

  • Vercel 같은 데가 주도하는 React, Next, Svelte 등은 훨씬 더 신중히 접근해야 한다고 수년째 강조. 그들의 목표는 Heroku처럼 하지만, 훨씬 더 공격적으로 전체 스택(언어-런타임-머신)에서 완전 락인 유도. 다른 기업도 문제가 있음. 예를 들어 Cloudflare의 CLI 배포 툴은 macOS 13.5+만 지원(2년 조금 넘음), 왜 그런지 불분명. 2년 전에 나온 OS가 구형 취급받는 현실이 안타까움. 예전 버전 wrangler도 써볼 순 있지만, 문서와 기능이 불일치하고 어차피 더 악화될 듯함. 언젠가 호환성도 끊길 수 있음. 반면 다른 도구(vim, neovim, emacs 등)는 여전히 오래된 OS X에서 동작. 이런 오픈 도구는 락인 유인이 없기 때문이라 생각

  • Next와 RSC는 프론트엔드에서 다뤄본 것 중 가장 답답. 프론트엔드도 이미 충분히 골칫거리인데, 여기에 Next의 "마법"을 더해서 Vercel까지 벤더 락인. 팀에서는 이번 주에 tanstack router와 vite로 전환해서 평범한 CSA를 만들어 볼 예정이라 기대

    • RSC가 뭐가 그렇게 답답한지 궁금. 내 경험상 정말 잘 동작하고 아직 Next.js를 쓰는 이유도 오직 RSC 때문

  • 모두가 Next.js 개발 모드에서 라우트 컴파일에 10초 걸리는 현상을 더 크게 다뤄야 함. Rust 컴파일러는 한켠에서 담배 피우고 있는 느낌

    • 사용 불가능 수준. 내가 경험한 최악의 devx. 마지막으로 이 정도로 싫었던 스택은 Sharepoint 사이트 도와줄 때 한 번뿐

    • 이제는 단순 스크립트 언어인 JS도 빌드/컴파일 단계를 몇 번씩 거치는데, 이제 C++ 컴파일러보다 오래 걸림. 클랭(Clang)이라도 브라우저에 넣으면 더 나은 경험이 될 지경. 참고로 회사에서는 PHP도 쓰는데 여기서도 같은 문제. 스크립트 언어라 간단할 줄 알았으나, PHP 자체 퍼포먼스 한계 때문에 코드 사전 생성 및 컴포저 빌드 단계를 따로 둬야 함. 그런데 PHP 개발자가 만든 이 빌드도 느림. GCC 제작자들이 만든 게 아니라 그런 듯

    • 이상하게도 next dev —-turbo 옵션도 우리 회사 코드베이스에서는 더 빠르지 않음

    • Rust 컴파일러는 정말 컴파일 작업을 하는데 Next.js 컴파일러는 실제로 그 정도로 복잡한 작업을 하는지 의문

  • Next.js의 지금 모습이 안타까움. 여전히 사용하지만, 직접 포크해서 패치해서 써야 할 만큼. next.config.js는 기본 동작을 바꿀 수 있는 험난한 탈출구인데, 이런 옵션은 원래 확장 포인트로 제공하고 "feature flag" 뒤에 숨기지 말았어야 한다 생각. 지금은 완전 스파게티 코드에 가까운 D학점 프레임워크

  • NextJS가 아니라면 전체 스택 기준 추천 조합이 뭐냐는 질문. 나는 15년 경력의 백엔드 개발자이지만, 프론트는 AngularJS 이후 처음. 최근 사이드 프로젝트 때문에 전체 스택 앱을 만들어보려고 검색했더니 Gemini와 공식 문서에서도 모두 NextJS를 추천. 아직 초기라서 대안을 배우고 싶음. 모든 건 Docker로 VPS에 직접 운영할 계획이라 Vercel/Netlify는 피함

    • 서버 렌더링 필요 없으면, 프레임워크 없는 React와 Vite1 조합 추천. 개발 중엔 Vite로 돌리고, 프로덕션 빌드는 HTML + JS 파일만 나와서 S3 같은 정적 호스팅에 올리면 끝. 10년 넘게 써왔고 문제 없음. 백엔드는 본인에게 편한 거 쓰고, 나는 요즘 PostgREST2 위주로 씀. 클라이언트에서 API 호출은 react-query3 추천

    • 어떤 프로젝트를 개발 중인지 궁금. 나는 전형적인 SaaS 웹앱을 만들고 있는데 React/Refine.dev/Vite 조합이 아주 괜찮았음. Refine.dev 덕분에 CRUD 페이지 고민 없이 기능 개발에만 집중 가능

  • 이번 이슈가 과장됐다 생각. React에서 스트리밍이 어떻게 동작하는지 아는 사람에게는, HTML을 한 줄씩 스트림처리할 수 없다는 건 상식. 메타데이터 때문에 첫 페인트(HTML, JS 아님)까지 막히면 안 됨. 이런 행동에서 일부 유저 에이전트를 예외 처리하는 건 합리적. 대다수 트래픽에선 최대한 빠른 표시가 중요하니까. 메타데이터 불러오는 데 오래 걸리는 사용자가 있을 경우, 어떻게 해결할지 궁금

답변달기