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를 한 번 시도했을 때 프로덕션에서 많은 하이드레이션 오류를 만났음
- 프레임워크가 서버에서 렌더링하는 잠재적 이득을 위해 모든 것을 복잡하게 만듦
- 전체 프레임워크가 그들의 비싼 클라우드 서비스를 판매하기 위한 좋은 외관으로 만들어졌음
본문의 내용은 최근 tanstack이나 remix 등 경쟁 프레임워크 간 비교를 해봤다면, 크게든 작게든 다들 알고있는 내용입니다. 아직은 워낙 nextjs의 점유율이 크고 버셀도 노골적인 행보를 보이진 않아서 표면화되지 않은 겁니다.