Next.js를 선택하기 전에 꼭 알아야 할 것들
(eduardoboucas.com)- Next.js 의 개방성과 거버넌스 문제에 대해 다루는 글: 어댑터의 부재, 공식 서버리스 지원 부족, Vercel 전용 코드 경로, 그리고 보안 사고에 대한 Vercel의 대응 자세등
- 기술 스택 선택은 프로젝트의 개발 속도, 품질, 팀 구성 등에 장기적인 영향을 주는 중요한 결정임
- 오픈소스 소프트웨어는 사용자에게 코드 확장 및 수정의 자유를 주며, 벤더 종속을 피할 수 있는 이점이 있음
- Next.js는 오픈소스로 제공되지만, 그것을 만든 Vercel의 인프라와 밀접하게 얽혀 있음
- 기업이 자사에서 만든 오픈소스로 수익을 얻는 것은 문제되지 않지만, 오픈소스와 기업의 경계가 명확해야 지속 가능한 모델이 될 수 있음
작성자의 배경과 이해관계
- 작성자는 Netlify 소속으로 4년 넘게 근무 중이며, Netlify는 Vercel과 경쟁 관계에 있음
- Netlify에서 Next.js의 전 기능을 지원하기 위한 인프라와 툴링을 직접 구축하면서 Next.js 내부 구조에 대한 깊은 이해를 얻게 되었음
- 오랫동안 공개적으로 문제 제기를 꺼려왔지만, 최근 Vercel의 보안 이슈 대응 방식이 커뮤니티에 해를 끼쳤다고 판단하여 글을 작성하게 되었음
# Next.js의 개방성과 거버넌스 문제
Fact #1: 어댑터 부재
- 대부분의 현대 프레임워크는 배포 대상에 따라 어댑터를 통해 유연하게 설정 가능함
- Next.js는 어댑터를 공식적으로 지원하지 않으며, 출력물 형식은 Vercel에서만 사용되는 독점적이고 비공개적인 구조임
- Vercel은 Build Output API를 만들었으나, Next.js는 여전히 이를 지원하지 않음
- 결과적으로 Vercel 이외의 제공자는 문서화되지 않은 API를 기반으로 구축해야 하며, 이는 예기치 못한 변경에 취약함
- Cloudflare와 Netlify는 OpenNext를 통해 Next.js용 어댑터 개발에 협력하고 있으며, Vercel도 이에 참여하기 시작했지만 아직 구체적인 일정은 없음
Fact #2: 공식 서버리스 지원 부족
- Next.js의 공식 셀프 호스팅 방식은 장기 실행 서버 기반으로, 실제 운영 환경에서 유연한 확장성과 비용 절감을 구현하기 어려움
- 과거엔 serverless 모드가 있었지만 2022년 10월에 별다른 설명 없이 제거되었음
- React 공식 문서에서는 서버리스 배포가 가능하다고 언급하지만, 실제로 이를 구현하기 위한 공식 문서는 없음
- 서버리스 환경을 원하는 호스팅 제공자는 Next.js를 리버스 엔지니어링하여 자체 구현해야 함
Fact #3: Vercel 전용 코드 경로 존재
- Next.js는 Vercel 배포 시에만 작동하는 비공개 코드 경로를 포함하고 있음 (예: minimal mode)
- 이 모드를 통해 Vercel은 미들웨어를 엣지에서 실행하는 등 성능 최적화를 가능하게 함
- 미들웨어는 캐시 이전 경로에서 빠르게 로직을 실행할 수 있는 기능이지만, 이 기능은 Vercel만 사용할 수 있음
- Netlify는 이 기능을 지원하기 위해 전담 엔지니어 팀을 두고 자체 구현했으나, 이는 소규모 제공자에겐 불가능한 수준의 리소스를 요구함
- Vercel만이 Next.js의 전체 기능을 공식적으로 제공하는 유일한 플랫폼이라는 현실은 프레임워크의 오픈소스 철학과 어긋남
보안 사고와 Vercel의 대응
- 2025년 3월 21일, Next.js에서 인증 우회를 허용하는 심각한 보안 취약점(CVE 9.1점)이 공개됨
- 해당 취약점은 요청에 특정 헤더를 포함하면 미들웨어를 무력화시켜 보호된 리소스에 접근할 수 있는 문제였음
- 취약점은 2월 27일에 보고되었지만, Vercel이 이를 조사하기 시작한 건 3월 14일이었음
- 문제 인지 후 빠르게 패치를 배포했지만, Netlify 등 다른 제공자에 알리는 데 8일이나 걸렸음
- 초기 블로그 글에서는 Vercel의 방화벽이 고객을 보호했다는 식으로 서술했으나, 실제로는 그렇지 않았음
- 이로 인해 여러 제공자와 개발자가 잘못된 정보를 바탕으로 대응하거나 혼란을 겪었으며, 여전히 많은 사이트가 취약한 상태일 가능성도 있음
Vercel의 Next.js 소유권과 오픈소스 책임
- Vercel이 Next.js를 소유하고 있다는 사실은 부정할 수 없으며, 수익화 또한 정당함
- 그러나 오픈소스로 제공되는 만큼 타 제공자도 평등하게 사용할 수 있어야 하며, 이 점에서 Vercel은 기대에 못 미치고 있음
- Redis, Grafana, WordPress 등도 상업적 서비스와 오픈소스 프로젝트를 함께 운영하면서도 개방성과 상호운용성을 유지하고 있음
결론
- 어떤 프레임워크를 선택하든 그것은 사용자의 결정이며, Next.js가 문제 해결에 최적이라면 그대로 사용하는 것도 좋음
- 다만 Next.js가 현재 갖고 있는 구조적 문제와 제한 사항을 알고 선택하는 것이 중요함
Hacker News 의견
- 나는 next.js를 사용하다가 페이지 라우터에서 앱 라우터로 전환했을 때 프로젝트를 포기했음. 앱 라우터 경험이 너무 나빴고 그 이후로 next.js를 다시 사용하고 싶지 않았음
- Vercel은 오픈 소스인 척하지만 사용자들을 그들의 호스팅 플랫폼에 가두려는 벽을 쌓고 있음
- Vercel에 대해 항상 약간 불안했음. VPS에 Next.js를 자체 호스팅하려고 할 때 그들이 설정한 작은 함정들에 걸렸음
- 그들이 이 취약점을 처리하는 방식이 나를 더욱 불안하게 만들었음
- Vercel의 방화벽이 고객을 "적극적으로 보호했다"고 주장하는 초기 설명은 나쁜 인상을 남겼음
- 다른 플랫폼에 알리는 데 지연이 있었고, 이는 Vercel이 Next.js에 취약점이 도입되는 것을 방지할 동기가 적다는 것을 보여줌
- 나는 모두에게 next.js를 피하라고 경고함. V0가 채택을 크게 증가시킬 가능성이 있음
- 많은 새로운 개발자들이 배포 및 시스템 관리에 대해 생각하고 싶어하지 않음
- React만 알고 있다면 SSR을 배우지 않고도 얻을 수 있는 것이 장점임
- 내가 next.js를 포기한 이유는 작은 프로젝트에서 변경 사항이 브라우저에 나타나는 데 6-7초가 걸렸기 때문임
- 이제 React SPA와 Vite를 사용함
- 우리는 작년에 Next.js에서 Vike로 이전했음. 개발자 경험이 크게 개선되었음
- 대부분의 필요는 페이지를 사전 렌더링하는 것으로 충족됨
- Next.js에 대해 혼합된 감정을 가지고 있음. 한편으로는 투자자와 함께 프레임워크를 구축하는 회사임
- MIT 라이선스이므로 Netlify나 다른 회사가 포크하여 더 나은 대안을 제공할 수 있음
- Vercel의 투자자라면 경쟁을 돕는 것이 투자 위험을 증가시킬 이유가 없음
- Vercel은 오픈 소스를 지지하면서도 그들의 호스팅 플랫폼을 최선의 선택으로 만들기 위한 마찰을 유지하려고 함
- 내가 일하는 회사의 React 스택을 선택하는 과정에 있음. Next.js를 대안보다 선택할 이유를 상상할 수 없음
- Remix나 React Router v7, TanStack이 SSR을 원한다면 더 합리적인 선택임
- 서버리스 접근 방식이 좋은 기본값이라고 확신하지 않음. 불필요한 복잡성을 추가함
- 백엔드에서 자바스크립트를 사용하는 것을 좋아하지 않음
- 서버 컴포넌트와 Next.js에 대한 집중이 나에게는 터널 비전처럼 느껴졌음
- 서버리스 접근 방식이 HTTP 헤더를 사용한 특권 통신의 이유였을 가능성이 높음
- 최악의 개발 빌드 시간이 있으며, 수년간 많은 불만이 있었지만 해결되지 않음
- Vercel과 NextJS는 존재하지 말아야 함
- Next를 한 번 시도했을 때 프로덕션에서 많은 하이드레이션 오류를 만났음
- 프레임워크가 서버에서 렌더링하는 잠재적 이득을 위해 모든 것을 복잡하게 만듦
- 전체 프레임워크가 그들의 비싼 클라우드 서비스를 판매하기 위한 좋은 외관으로 만들어졌음
경쟁사에서 근무한다는 이유로 글에서 전하고자 하는 정보에 대한 객관성이 부족하다는 주장은 인신공격 입니다. 작성자의 배경과 이해관계를 생략하고 읽어도 이상한 글인가요? 저는 유용한 정보라 생각합니다.