나는 100% 동의함, 나도 동일한 문제를 겪었고, 앞으로도 Next.js를 절대 사용하지 않을 거임, 회사 내 모든 팀에게도 다른 대안을 쓰라고 권장할 예정임
Next.js는 99.9999%의 프로젝트에서 필요 없는 엄청난 추상화 레이어가 있음, 정말로 이런 게 필요한 소수의 사례에서는 차라리 하위 레벨 부품으로 맞춤형 솔루션을 만드는 게 더 낫다고 생각함
내가 사용해 본 기술 중 Next.js가 단연 최악이었음
나 혼자만 이런 생각이 아니어서 정말 다행임
Next.js로 중간 복잡도의 수익 창출용 프로덕션 앱을 만들었고, 처음엔 Vercel과 Google Firebase를 썼다가 이후 직접 호스팅으로 바꾸고 Pocketbase로 교체했음
Pocketbase만 유일하게 괜찮은 경험이었고, 나머지는 전부 정말 끔찍했음
무한한 복잡성, 끊임없는 브레이킹 체인지, 접근하기 힘든 문서 등 어느 하나 쉬운 게 없었음
지난 5년간 FE 트렌드를 돌려서, 당시 존재했던 기술을 제대로 가르치는 데 집중했다면 지금보다 더 나은 상황이었을 거라고 확신함
복잡한 React 프론트엔드도 좀 만들었는데, React도 별로 좋아하진 않지만 Next.js는 더 심각했음
Go와 바닐라 JS로 CMS도 만들어 봤는데, DX는 조금 덜할지 몰라도, 무슨 일이 일어날지 내가 실제로 알고 있단 느낌을 받을 수 있었음
왜 React와 Next.js에서는 6년이 지난 지금도 항상 무슨 일이 벌어질지 추측해야 하는지 모르겠음
프레임워크의 꼬임을 수습할 수 있는 경험은 쌓았지만, 그냥 전체적으로 너무 지저분하고 나쁜 설계라는 느낌임
Go에서는 처음 6개월 빼고는 놀랄 일이 없었고, 오래된 코드베이스도 여전히 탄탄함
프론트엔드 쪽에서도 이런 경험을 만들 수 없는 게 안타까움
내 경험상 Next.js의 거친 부분들은 버그가 아니라 특징임
모든 게 사용자를 포기하게 만들어서 Vercel 호스팅에 묶이게 하려는 의도로 느껴짐
앞으로 상황이 더 악화될 것이라고 생각함
현재 PluralSight 같은 온라인 강의들도 React 관련 강좌에 Next.js만을 밀고 있음
이런 상황이 왜 만들어졌는지는 모르겠지만, 여기에 도달함
내 경우 Sharepoint가 더 더러운 기억이라서 Next.js는 두 번째로 최악임
Next.js에서 가장 답답한 점은 Rails, Wordpress, Meteor 같은 풀스택 프레임워크처럼 모든 걸 다 제공하는 척하면서, 실제로는 가장 재미없고 한정적인 부분(미들웨어, 이미지 리사이징, SSR 등)에만 의견을 내고, 정말로 가치 있는 결정(데이터베이스, ORM, 통신 프로토콜 등)은 사용자에게 떠넘긴다는 점임
실제로는 Rails/Wordpress/Meteor와 상당히 다르고, Framework가 인프라를 정의해야 하는데 오히려 인프라가 프레임워크를 좌지우지하는 상황이 되어버림
내 대시보드에서는 "Fluid Active CPU"와 "ISR Writes"가 상위 사용 항목이고, $20씩 내면서 100% 초과 안 하길 빌 뿐임
항목들의 이름이 스타트렉 같은 기술 용어로 가득하고, 다음 메이저 버전에서 또 바뀔 것 같아 공부하고 싶지도 않음
과거 Zeit에 열광했던 지인들 중 꽤 많은 사람들이 결국 프로젝트와 고객을 딴 데로 옮겼음
만약 Vercel이 내게 다음 메이저 릴리즈에서 무얼 바꿔야 하냐고 묻는다면, "App Router를 포함해 그 이후 모든 결정이 잘못됐음"이라고 밖에 얘기할 수 없음
이걸 어떻게 회복할 수 있을지 모르겠음
Next.js의 많은 문제들은 코드가 실제로 어디서 실행되는지 잘 모르는 데서 비롯된다고 생각함
브라우저, 미들웨어, edge와 node, SSR 등 모든 요소가 섞이면서 엄청난 복잡성이 생김
이렇게 까다로운 경우는 다음에 해당함
글로벌 유저 대상 B2C 서비스를 운영해 edge 세마틱스로 지연시간을 줄이고 싶을 때
Vercel의 고가 호스팅을 쓸 준비가 됐을 때
백그라운드 작업 필요 없이 복잡하지 않은 아키텍처만 요구될 때
그 외에는 react-vite SPA나 Rails같은 전통적 SSR이 훨씬 무난함
나는 위 조건에도 동의하지 않음
설사 Next.js와 맞더라도, 생산성과 유지보수성 하락이 전혀 그만큼의 값어치를 하는 것 같지 않음
나는 Gleam의 Lustre를 쓰고 있는데, 돌아볼 생각 없음
Elm 창립자의 키노트 또한 Next.js와는 반대되는 사례라 생각함 https://www.youtube.com/watch?v=sl1UQXgtepE
Vercel은 현대 웹의 암적인 존재라 평함
모든 프레임워크 생태계에 침투해 유료 플랜 영업 목적으로 남용하면서, 오픈소스와 경쟁, 웹의 발전을 위하는 척만 함
첫 번째 조건에 해당하는 경우에도, Vercel과 SSR을 쓴다고 해서 성능 병목이 해소된다고 생각하기 어려움
대부분의 성능 저하 원인은 너무 큰 번들 사이즈, 수많은 느린 API 호출 등 기본적인 곳에 있음
기본적인 프로파일링, 최적화, 단순화 등을 먼저 하는 게 아키텍처 복잡화보다 훨씬 효과적임
"코드가 어디에서 실행되는지 모르는 문제"라는 부분에 공감함
예전에는 자바스크립트 만능론이 장점이라 생각했지만, 지금은 오히려 그게 문제라 느낌
우리 회사는 Inertia.js + Vue를 쓰는데, 전체적으로 구성도 단순하고 프론트 렌더링의 힘은 그대로 있으면서 라우팅은 100% 서버 측에서 처리하고, 별도의 API도 필요 없음
React, Svelte에서도 Inertia를 쓸 수 있음
처음에는 Nuxt를 썼는데, 백엔드 서버랑 프론트엔드 서버 두 개를 동시에 운영해야 할 만큼 복잡했고, 코드가 어디서 도는지 알기 어려웠음
지금은 PHP는 서버, JS는 브라우저라는 구분 덕분에 전혀 고민이 필요 없음
이게 우리에게 엄청난 장점임
요지가 잘 정리된 것 같음
Vercel은 React Server Components, Partial Pre-rendering, Edge 서버, 스트리밍 등으로 성능 최적화를 추구하고 있음
특이한 설계나 API 결정들이 전부 여기에 기인함
필요한 경우엔 이런 게 도움이 될 수도 있지만, edge function 일부로 ssr만 적절히 활용해도 상당히 나아질 수 있음
답변 감사함
그런데 instrumentation과 observability 얘기를 꺼내니, 단순히 로그 문제를 또 다른 복잡한 계층으로 푸는 것처럼 들림
모든 앱에 OpenTelemetry가 필요하지 않음
logger().info() 같은 평범한 방법이 왜 안 되는지 모르겠음
다른 언어나 프레임워크에는 다 있는데 이건 왜 이렇게 어려운지 이해가 안됨
여기 분위기가 부정적이라서 먼저 밝히고 싶음: Next.js는 실제 목적엔 잘 맞는 훌륭한 소프트웨어임
수백만 사이트를 뒷받침하는 소프트웨어 잘 만들었다고 생각함
문제는 자세한 레퍼런스와 문서 부족에서 오는데, 문서가 무엇이 있는지 알려주긴 하지만 실제로 어떻게 쓰는지, 실행 시점, 흔한 함정 등은 잘 안 다룸
초보자에겐 친절하지만, 복잡한 런타임 컨텍스트나 Derived complexity에 대한 안내가 부족함
이건 요즘 많은 프로젝트들에 보이는 트렌드임
User friendly함과 자세한 설명의 균형 맞추기가 굉장히 어려움
계속 발전 해주길 바람
소위 한 마디 거듭
이 글의 저자는, 도메인 차이를 파악하지 못하고 모든 곳에서 동일하게 함수를 호출하려고 했던 것임
Next.js의 오류는 원래 다른 성격의 도메인을 억지로 합치려 한 데서 나옴
이런 식으로 에지, SSR, Node, 클라이언트 사이를 뒤섞으려 하면 복잡성만 늘어남
문서로도 해결이 안되고, 오히려 혼란만 더할 뿐임
난 Reddit 댓글에서 instrumentation 방법을 추천받은 적이 있음
비슷한 시간 opentelemetry를 Next에 세팅하다가 문서가 달랐다고 해도, 이런 경험 후에 블로그 포스트 썼을 것임
이건 너희 잘못은 아니지만 거의 모든 opentelemetry 패키지가 실험적 표시가 있어서, 프로덕션에 쓸 때 신뢰가 안 생김
pino instrumentation 세팅도 아주 힘들었음
pino를 serverExternalPackages에 추가해야 제대로 작동함
자동계측은 import 순서에도 극도로 민감했고, pino의 디폴트 익스포트만 계측이 됨
모듈 로컬 변수도 기대한 대로 동작 안해서 globalThis를 써야 했음
이러고도 결국 https://github.com/vercel/next.js/issues/80445에도 걸렸음
결론적으로는 잘 작동하긴 했지만, 정말 세팅이 불편했음
수동 라우터(=vercel/otel 안 씀) 덕에 이런 경험이었음
서버사이드 미들웨어를 지원하는 결정이 이뤄졌다면, 왜 아직도 미들웨어 체인(여러 함수 연결)이 안 되고, 하나만 지원하는지 모르겠음
다른 서버 프레임워크는 다 제공하는 기능임
내가 제대로 읽은 게 맞다면, Next.js가 여러 파일로 구조화하지 말고 하나로 합치라 주장하는 셈임?
스코핑 문제 때문에 여러 파일 사용이 힘든 건가? 프레임워크로선 너무 말도 안 되는 요구임
이런 어이없는 결정 대부분이 프레임워크의 이익이 아니라, Vercel 입장에 더 유리하기 때문에 내려진 거라는 의심을 지울 수 없음
Next.js를 처음 보고 Meteor.js가 바로 떠올랐음
개인 프로젝트로 꽤 투자해 배우긴 했는데, 너무 과도한 추상화와 경직성 탓에 프로토타입 이상 넘어가기 힘들었음
이런 “배터리 포함” 솔루션은 계속 나옴, 왜냐하면 세팅이 편리하기 때문임
최근 Hacker News에서도 Laravel vs Symphony 비교에서 복잡해지면 깨진다는 얘기들이 오갔음
이런 접근을 예전 NodeJS/React SPA 처럼 각자 맞춤 조립식으로 만드는 것과 비교하면, 각 부품이 저수준 추상화로 독립적이라 유연성이 높고, 부분 교체도 쉬움
단점도 있지만, 오버엔지니어링(즉, 쌓아 올린 복잡성)보다는 더 매끄러움
배터리 포함이 인기 있는 건 충분히 이해됨
각종 툴과 라이브러리를 조합해 호환성 맞추는 게 정말 번거롭기 때문임
이런 조립식 접근은 더 숙련된 사람이 세팅을 해줘야 잘 작동함
나는 asp.net에 익숙한데, 스타트업 쪽 개발 커뮤니티에선 안 좋은 평이 많지만, 실제론 굉장히 잘 설계된 프레임워크임
배터리 포함이긴 하지만 언제든 내가 프레임워크에서 빠져나와 오버라이드할 수 있었고, 한 번도 프레임워크와 싸운다는 느낌을 받은 적 없음
Blazor Server, Blazor Webasm 모두 프론트를 C#으로 쓸 수 있고, 둘 다 각각 내부 패널이나 SaaS 앱에 좋음
무엇보다 전통적 서버사이드 렌더링으로도 다 해결 가능함
누구든 웹프레임워크에 불만이 있다면 꼭 써보라고 권하고 싶음
이젠 크로스플랫폼 지원도 잘 되고, 속도도 빠르고, 배우기도 쉬움
러닝커브는 있지만 모듈 구조를 이해하면 바로 마음대로 오버라이드할 수 있었음
다른 프레임워크에 비해 한계에 부딪히는 일도 정말 드물었음
NodeJS/React SPA에서처럼 각 부품을 조립형으로 쓰는 요소가 Angular에서는 생소함
Angular는 라이브러리가 아니라 프레임워크라 대부분 필요한 기능이 잘 포함돼 있음
(RxJS 등은 러닝커브가 좀 있지만, 기본만 익히면 충분히 강력함)
보통 SPA에서 프레임워크와 씨름하는 경험이 별로 없었음
문서와 튜토리얼(Tour of Heroes 포함)도 아주 훌륭함 https://v17.angular.io/tutorial/tour-of-heroes
최신 문서는 https://angular.dev/에서 확인 가능함
Laravel은 오버엔지니어링 추상화의 성공 사례임
Laravel 덕분에 프로덕션에서 절대 후회한 적 없었음
약간 다른 얘기지만, 각종 조그맣게 호환이 안 되는 툴과 라이브러리를 계속 연결하는 게 완전히 내 업무임
우리 팀은 규모가 작아서 계속 최신화와 유지보수에 엄청난 시간을 소비하고 있음, 오래 전 지원 중단된 패키지 문제도 빈번함
경험 뿐만 아니라, 시스템 구축에 들어가는 초기 시간과 유지보수 비용이 생각보다 훨씬 큼
직접 해보면 Node로 조각조각 라이브러리 붙이는 것보다 Rails가 생산성이 10배는 높다고 느꼈음
프레임워크의 근간과 철학에 불만이 있다면(예: ActiveRecord가 싫은 경우)만 문제가 생길 뿐임
“복잡성이 오르면 다 깨진다”는 건 기술력이 부족해서임
나는 React 엄청 옹호하는 입장이고, class 컴포넌트에서 hooks로 바뀐 것도 좋아함
하지만 Next.js를 쓸 때마다 도대체 어디서부터 잘못된 건지 감이 없어짐
수많은 프레임워크와 이색적인 언어도 좋아하지만, Next.js만큼은 오류 메시지 절반도 이해 못하는 경험이 유일함
특히 이상한 hydration 이슈로 보낸 시간이 어마어마함
나는 React나 Next.js를 안 쓰는 편임
개인적으로는 HTML+CSS에 바닐라 JS를 곁들이는 쪽이 취향임
간단한 Next.js 랜딩 페이지가 Firefox에서 깨지는 것도 경험했음
더 심각한 건, 모든 콘텐츠 위에 까만 화면과 하얀 글씨로 "An application client side error has occurred"라는 메세지만 뜨는 식의 실패 형태였음
간단한 랜딩 페이지도 렌더링이 안될 정도라 놀랐고, JS 프론트 프레임워크 때문이라는 걸 알게 된 후엔 그냥 “그럴 만 하구나” 싶었음
사용자들을 설득하려는 사람들에겐 용납되지만, 업계 밖 사람에겐 당혹스러울 수 있음
Next는 이미 자체를 망가뜨린 사례라고 생각함
VC 사이클을 거친 곳은 결국 이런 식임
이제 못 쓰겠고, Vite가 기본 옵션임
가벼운 솔루션을 늘 더 선호함
Next.js에서 “middleware”란 용어는 오해를 낳기 쉬움
실제로는, 요청이 앱에 도달하기 전에 돌리는 가벼운 edge function임(헤더 체크, 라우팅, 간단한 가드 등)
edge 런타임에서 돌아가며, 앱 서버와는 별개의 환경임
저자도 edge와 서버 런타임을 혼동하는 듯함
나도 처음엔 경계가 헷갈렸었고, 자바스크립트 중심이다 보니 구분이 흐릿함
명확한 정신 모델이 필요하다고 생각함
Next.js의 복잡성을 탓하는 건 일종의 도구 상자에 망치 외에도 여러 도구가 들어있다는 걸 탓하는 느낌임
문제는 Next.js의 복잡성이 스스로 자초한 것임
미들웨어라는 용어는 거의 모든 프레임워크에서 이미 확실한 의미가 정립돼 있음
일반적으로 미들웨어는 런타임에서 요청 전에 불리는 함수들의 체인이고, 같은 프로세스에서 실행된다는 전제가 있음
Next.js는 이걸 edge에 배치해서 한 개만 허용하는 방식임
대부분의 앱에서는 edge 기능까지 쓸 필요 없이, 필요할 때에만 opt-in 하게 해야 함
도구상자 비유로 치면, 실제로 필요한 도구만 추가하는 게 맞음
Next.js에서 “middleware”란 용어를 이런 맥락에 써선 안 됨
이는 오용일 뿐만 아니라, 용어 남용임
미들웨어는 웹앱 업계에서 오래된 정의가 있으니, 전혀 다른 걸 의미한다면 쓰지 말았어야 했음
나는 Next.js 앱 라우터를 사용하며 만족하는 편임
Next.js로 프론트와 백엔드 오가기가 매우 쉬워서 사람들이 이 부분까지 추상화된 줄로 착각하는 것 같음
실제로는 아주 복잡한 시스템이고, 이 복잡성을 스스로 감당해야 함
복잡성이 높아진다고 항상 느리거나 비생산적이진 않음
프론트와 백이 분리된 시스템이 훨씬 다루기 쉽긴 한데 그만큼 귀찮기도 함
React를 알아도 Next.js는 완전히 새로 배우는 느낌이고, 직접 겪지 않고는 알 수 없는 부분이 많음
그래도 어느 정도 익숙해진다면, 프론트와 백엔드를 쉽게 넘나드는 매우 편리한 시스템임
내 댓글을 싫어요 누른 사람들이 많은데, 이유를 설명해줬으면 함
나는 언제든 배우고 싶음
이런 토론에서 맹목적 부정만 하지 말고 제대로 논의했으면 좋겠음
드디어 상식적인 의견을 봤다고 느낌
예를 들어 파이썬의 패키지/모듈과 Go의 모듈 개념을 아무 생각 없이 혼동하면, Go가 나쁘다고 불평하는 것과 같음
무엇이든 사용하는 기술에 대한 기본적인 이해는 필요함
Next.js가 앱 라우터로 바뀐 이후, 마치 express API를 개선하는 걸 부트캠프 졸업생들에게 맡긴 느낌이 들었음
모든 서버 인터페이스(서블릿, rack, plug 등)가 수년간 쌓아온 러시안인형식 설계와 맞아떨어진다는 점에서 express API는 그래도 성숙한 접근법임
형편없는 미들웨어 API뿐 아니라, 요청 파라미터를 없애고 cookies()/headers() 같은 글로벌 함수로 대체하는 것도 기이한 결정이었음
기본 설계적 제약이 숨어있는 것 같긴 한데, 외부에서 봤을 때는 기존의 모든 교훈을 다 버리고 실수들을 다시 반복하는 것처럼 보임
스트리밍에 대한 집착이 이런 제약을 만든 가장 큰 원인이라고 봄
여기에다가 lowest common denominator(가장 범용적인) edge 런타임 지원도 끼어들면서, 제약이 심해진 거라고 생각함
나는 항상 새로운 프로젝트에서는 다양한 스택을 써보려고 함
express+react, angular, vue, next, nuxt, go, .net, node, php 등등 프론트와 백엔드 모두 사용해왔음
대부분의 프레임워크에선 장단점을 발견하고, 새로 배우는 재미도 있음
Next.js만은 예외로, 상당히 큰 앱을 만들면서 시작부터 끝까지 하나하나가 이상하거나 느리거나 불편하거나 말도 안 되게 설계됐다고 느낌
아직도 유지보수 중인데, 내가 혐오하는 유일한 “무엇”임
생태계는 괜찮고 인기도 많다고들 하지만, 내 리얼 경험상 돌이킬 수 없을 만큼 부정적이었음
이상하지만, 현실임
Hacker News 의견
나는 100% 동의함, 나도 동일한 문제를 겪었고, 앞으로도 Next.js를 절대 사용하지 않을 거임, 회사 내 모든 팀에게도 다른 대안을 쓰라고 권장할 예정임
Next.js는 99.9999%의 프로젝트에서 필요 없는 엄청난 추상화 레이어가 있음, 정말로 이런 게 필요한 소수의 사례에서는 차라리 하위 레벨 부품으로 맞춤형 솔루션을 만드는 게 더 낫다고 생각함
내가 사용해 본 기술 중 Next.js가 단연 최악이었음
나 혼자만 이런 생각이 아니어서 정말 다행임
Next.js로 중간 복잡도의 수익 창출용 프로덕션 앱을 만들었고, 처음엔 Vercel과 Google Firebase를 썼다가 이후 직접 호스팅으로 바꾸고 Pocketbase로 교체했음
Pocketbase만 유일하게 괜찮은 경험이었고, 나머지는 전부 정말 끔찍했음
무한한 복잡성, 끊임없는 브레이킹 체인지, 접근하기 힘든 문서 등 어느 하나 쉬운 게 없었음
지난 5년간 FE 트렌드를 돌려서, 당시 존재했던 기술을 제대로 가르치는 데 집중했다면 지금보다 더 나은 상황이었을 거라고 확신함
복잡한 React 프론트엔드도 좀 만들었는데, React도 별로 좋아하진 않지만 Next.js는 더 심각했음
Go와 바닐라 JS로 CMS도 만들어 봤는데, DX는 조금 덜할지 몰라도, 무슨 일이 일어날지 내가 실제로 알고 있단 느낌을 받을 수 있었음
왜 React와 Next.js에서는 6년이 지난 지금도 항상 무슨 일이 벌어질지 추측해야 하는지 모르겠음
프레임워크의 꼬임을 수습할 수 있는 경험은 쌓았지만, 그냥 전체적으로 너무 지저분하고 나쁜 설계라는 느낌임
Go에서는 처음 6개월 빼고는 놀랄 일이 없었고, 오래된 코드베이스도 여전히 탄탄함
프론트엔드 쪽에서도 이런 경험을 만들 수 없는 게 안타까움
내 경험상 Next.js의 거친 부분들은 버그가 아니라 특징임
모든 게 사용자를 포기하게 만들어서 Vercel 호스팅에 묶이게 하려는 의도로 느껴짐
앞으로 상황이 더 악화될 것이라고 생각함
현재 PluralSight 같은 온라인 강의들도 React 관련 강좌에 Next.js만을 밀고 있음
이런 상황이 왜 만들어졌는지는 모르겠지만, 여기에 도달함
내 경우 Sharepoint가 더 더러운 기억이라서 Next.js는 두 번째로 최악임
Next.js에서 가장 답답한 점은 Rails, Wordpress, Meteor 같은 풀스택 프레임워크처럼 모든 걸 다 제공하는 척하면서, 실제로는 가장 재미없고 한정적인 부분(미들웨어, 이미지 리사이징, SSR 등)에만 의견을 내고, 정말로 가치 있는 결정(데이터베이스, ORM, 통신 프로토콜 등)은 사용자에게 떠넘긴다는 점임
실제로는 Rails/Wordpress/Meteor와 상당히 다르고, Framework가 인프라를 정의해야 하는데 오히려 인프라가 프레임워크를 좌지우지하는 상황이 되어버림
내 대시보드에서는 "Fluid Active CPU"와 "ISR Writes"가 상위 사용 항목이고, $20씩 내면서 100% 초과 안 하길 빌 뿐임
항목들의 이름이 스타트렉 같은 기술 용어로 가득하고, 다음 메이저 버전에서 또 바뀔 것 같아 공부하고 싶지도 않음
과거 Zeit에 열광했던 지인들 중 꽤 많은 사람들이 결국 프로젝트와 고객을 딴 데로 옮겼음
만약 Vercel이 내게 다음 메이저 릴리즈에서 무얼 바꿔야 하냐고 묻는다면, "App Router를 포함해 그 이후 모든 결정이 잘못됐음"이라고 밖에 얘기할 수 없음
이걸 어떻게 회복할 수 있을지 모르겠음
Next.js의 많은 문제들은 코드가 실제로 어디서 실행되는지 잘 모르는 데서 비롯된다고 생각함
브라우저, 미들웨어, edge와 node, SSR 등 모든 요소가 섞이면서 엄청난 복잡성이 생김
이렇게 까다로운 경우는 다음에 해당함
글로벌 유저 대상 B2C 서비스를 운영해 edge 세마틱스로 지연시간을 줄이고 싶을 때
Vercel의 고가 호스팅을 쓸 준비가 됐을 때
백그라운드 작업 필요 없이 복잡하지 않은 아키텍처만 요구될 때
그 외에는 react-vite SPA나 Rails같은 전통적 SSR이 훨씬 무난함
나는 위 조건에도 동의하지 않음
설사 Next.js와 맞더라도, 생산성과 유지보수성 하락이 전혀 그만큼의 값어치를 하는 것 같지 않음
나는 Gleam의 Lustre를 쓰고 있는데, 돌아볼 생각 없음
Elm 창립자의 키노트 또한 Next.js와는 반대되는 사례라 생각함
https://www.youtube.com/watch?v=sl1UQXgtepE
Vercel은 현대 웹의 암적인 존재라 평함
모든 프레임워크 생태계에 침투해 유료 플랜 영업 목적으로 남용하면서, 오픈소스와 경쟁, 웹의 발전을 위하는 척만 함
첫 번째 조건에 해당하는 경우에도, Vercel과 SSR을 쓴다고 해서 성능 병목이 해소된다고 생각하기 어려움
대부분의 성능 저하 원인은 너무 큰 번들 사이즈, 수많은 느린 API 호출 등 기본적인 곳에 있음
기본적인 프로파일링, 최적화, 단순화 등을 먼저 하는 게 아키텍처 복잡화보다 훨씬 효과적임
"코드가 어디에서 실행되는지 모르는 문제"라는 부분에 공감함
예전에는 자바스크립트 만능론이 장점이라 생각했지만, 지금은 오히려 그게 문제라 느낌
우리 회사는 Inertia.js + Vue를 쓰는데, 전체적으로 구성도 단순하고 프론트 렌더링의 힘은 그대로 있으면서 라우팅은 100% 서버 측에서 처리하고, 별도의 API도 필요 없음
React, Svelte에서도 Inertia를 쓸 수 있음
처음에는 Nuxt를 썼는데, 백엔드 서버랑 프론트엔드 서버 두 개를 동시에 운영해야 할 만큼 복잡했고, 코드가 어디서 도는지 알기 어려웠음
지금은 PHP는 서버, JS는 브라우저라는 구분 덕분에 전혀 고민이 필요 없음
이게 우리에게 엄청난 장점임
요지가 잘 정리된 것 같음
Vercel은 React Server Components, Partial Pre-rendering, Edge 서버, 스트리밍 등으로 성능 최적화를 추구하고 있음
특이한 설계나 API 결정들이 전부 여기에 기인함
필요한 경우엔 이런 게 도움이 될 수도 있지만, edge function 일부로 ssr만 적절히 활용해도 상당히 나아질 수 있음
피드백 남겨준 것에 감사함
Middleware에서 DX 이슈를 인지하고 있고, 15.5 버전에서 Node 런타임 지원을 큰 진전으로 제공함[1]
되돌아간다면 이름을 Routing Middleware나 Routing Handler같이, 라우팅 단계에서 CDN edge로 전달이 가능한 고급 escape hatch 용도로 오히려 바꿨을 것임
만약 로그가 필요하다면 OpenTelemetry를 활용해 instrumentation.ts 관행[2]에 따라 처리 가능함
[1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable
[2] https://nextjs.org/docs/app/api-reference/file-conventions/instrumentation
답변 감사함
그런데 instrumentation과 observability 얘기를 꺼내니, 단순히 로그 문제를 또 다른 복잡한 계층으로 푸는 것처럼 들림
모든 앱에 OpenTelemetry가 필요하지 않음
logger().info() 같은 평범한 방법이 왜 안 되는지 모르겠음
다른 언어나 프레임워크에는 다 있는데 이건 왜 이렇게 어려운지 이해가 안됨
여기 분위기가 부정적이라서 먼저 밝히고 싶음: Next.js는 실제 목적엔 잘 맞는 훌륭한 소프트웨어임
수백만 사이트를 뒷받침하는 소프트웨어 잘 만들었다고 생각함
문제는 자세한 레퍼런스와 문서 부족에서 오는데, 문서가 무엇이 있는지 알려주긴 하지만 실제로 어떻게 쓰는지, 실행 시점, 흔한 함정 등은 잘 안 다룸
초보자에겐 친절하지만, 복잡한 런타임 컨텍스트나 Derived complexity에 대한 안내가 부족함
이건 요즘 많은 프로젝트들에 보이는 트렌드임
User friendly함과 자세한 설명의 균형 맞추기가 굉장히 어려움
계속 발전 해주길 바람
소위 한 마디 거듭
이 글의 저자는, 도메인 차이를 파악하지 못하고 모든 곳에서 동일하게 함수를 호출하려고 했던 것임
Next.js의 오류는 원래 다른 성격의 도메인을 억지로 합치려 한 데서 나옴
이런 식으로 에지, SSR, Node, 클라이언트 사이를 뒤섞으려 하면 복잡성만 늘어남
문서로도 해결이 안되고, 오히려 혼란만 더할 뿐임
난 Reddit 댓글에서 instrumentation 방법을 추천받은 적이 있음
비슷한 시간 opentelemetry를 Next에 세팅하다가 문서가 달랐다고 해도, 이런 경험 후에 블로그 포스트 썼을 것임
이건 너희 잘못은 아니지만 거의 모든 opentelemetry 패키지가 실험적 표시가 있어서, 프로덕션에 쓸 때 신뢰가 안 생김
pino instrumentation 세팅도 아주 힘들었음
pino를 serverExternalPackages에 추가해야 제대로 작동함
자동계측은 import 순서에도 극도로 민감했고, pino의 디폴트 익스포트만 계측이 됨
모듈 로컬 변수도 기대한 대로 동작 안해서 globalThis를 써야 했음
이러고도 결국 https://github.com/vercel/next.js/issues/80445에도 걸렸음
결론적으로는 잘 작동하긴 했지만, 정말 세팅이 불편했음
수동 라우터(=vercel/otel 안 씀) 덕에 이런 경험이었음
서버사이드 미들웨어를 지원하는 결정이 이뤄졌다면, 왜 아직도 미들웨어 체인(여러 함수 연결)이 안 되고, 하나만 지원하는지 모르겠음
다른 서버 프레임워크는 다 제공하는 기능임
"여러 개의 미들웨어 체인 불가능"하다는 말이 정말인지 의심스러움
https://nextjs.org/docs/messages/nested-middleware
여러 개가 있으면 한 파일로 합쳐서 실행해야 한다니, 정말 믿기 어려움
내가 제대로 읽은 게 맞다면, Next.js가 여러 파일로 구조화하지 말고 하나로 합치라 주장하는 셈임?
스코핑 문제 때문에 여러 파일 사용이 힘든 건가? 프레임워크로선 너무 말도 안 되는 요구임
이런 어이없는 결정 대부분이 프레임워크의 이익이 아니라, Vercel 입장에 더 유리하기 때문에 내려진 거라는 의심을 지울 수 없음
Next.js를 처음 보고 Meteor.js가 바로 떠올랐음
개인 프로젝트로 꽤 투자해 배우긴 했는데, 너무 과도한 추상화와 경직성 탓에 프로토타입 이상 넘어가기 힘들었음
이런 “배터리 포함” 솔루션은 계속 나옴, 왜냐하면 세팅이 편리하기 때문임
최근 Hacker News에서도 Laravel vs Symphony 비교에서 복잡해지면 깨진다는 얘기들이 오갔음
이런 접근을 예전 NodeJS/React SPA 처럼 각자 맞춤 조립식으로 만드는 것과 비교하면, 각 부품이 저수준 추상화로 독립적이라 유연성이 높고, 부분 교체도 쉬움
단점도 있지만, 오버엔지니어링(즉, 쌓아 올린 복잡성)보다는 더 매끄러움
배터리 포함이 인기 있는 건 충분히 이해됨
각종 툴과 라이브러리를 조합해 호환성 맞추는 게 정말 번거롭기 때문임
이런 조립식 접근은 더 숙련된 사람이 세팅을 해줘야 잘 작동함
나는 asp.net에 익숙한데, 스타트업 쪽 개발 커뮤니티에선 안 좋은 평이 많지만, 실제론 굉장히 잘 설계된 프레임워크임
배터리 포함이긴 하지만 언제든 내가 프레임워크에서 빠져나와 오버라이드할 수 있었고, 한 번도 프레임워크와 싸운다는 느낌을 받은 적 없음
Blazor Server, Blazor Webasm 모두 프론트를 C#으로 쓸 수 있고, 둘 다 각각 내부 패널이나 SaaS 앱에 좋음
무엇보다 전통적 서버사이드 렌더링으로도 다 해결 가능함
누구든 웹프레임워크에 불만이 있다면 꼭 써보라고 권하고 싶음
이젠 크로스플랫폼 지원도 잘 되고, 속도도 빠르고, 배우기도 쉬움
러닝커브는 있지만 모듈 구조를 이해하면 바로 마음대로 오버라이드할 수 있었음
다른 프레임워크에 비해 한계에 부딪히는 일도 정말 드물었음
NodeJS/React SPA에서처럼 각 부품을 조립형으로 쓰는 요소가 Angular에서는 생소함
Angular는 라이브러리가 아니라 프레임워크라 대부분 필요한 기능이 잘 포함돼 있음
(RxJS 등은 러닝커브가 좀 있지만, 기본만 익히면 충분히 강력함)
보통 SPA에서 프레임워크와 씨름하는 경험이 별로 없었음
문서와 튜토리얼(Tour of Heroes 포함)도 아주 훌륭함
https://v17.angular.io/tutorial/tour-of-heroes
최신 문서는 https://angular.dev/에서 확인 가능함
Laravel은 오버엔지니어링 추상화의 성공 사례임
Laravel 덕분에 프로덕션에서 절대 후회한 적 없었음
약간 다른 얘기지만, 각종 조그맣게 호환이 안 되는 툴과 라이브러리를 계속 연결하는 게 완전히 내 업무임
우리 팀은 규모가 작아서 계속 최신화와 유지보수에 엄청난 시간을 소비하고 있음, 오래 전 지원 중단된 패키지 문제도 빈번함
경험 뿐만 아니라, 시스템 구축에 들어가는 초기 시간과 유지보수 비용이 생각보다 훨씬 큼
직접 해보면 Node로 조각조각 라이브러리 붙이는 것보다 Rails가 생산성이 10배는 높다고 느꼈음
프레임워크의 근간과 철학에 불만이 있다면(예: ActiveRecord가 싫은 경우)만 문제가 생길 뿐임
“복잡성이 오르면 다 깨진다”는 건 기술력이 부족해서임
나는 React 엄청 옹호하는 입장이고, class 컴포넌트에서 hooks로 바뀐 것도 좋아함
하지만 Next.js를 쓸 때마다 도대체 어디서부터 잘못된 건지 감이 없어짐
수많은 프레임워크와 이색적인 언어도 좋아하지만, Next.js만큼은 오류 메시지 절반도 이해 못하는 경험이 유일함
특히 이상한 hydration 이슈로 보낸 시간이 어마어마함
나는 React나 Next.js를 안 쓰는 편임
개인적으로는 HTML+CSS에 바닐라 JS를 곁들이는 쪽이 취향임
간단한 Next.js 랜딩 페이지가 Firefox에서 깨지는 것도 경험했음
더 심각한 건, 모든 콘텐츠 위에 까만 화면과 하얀 글씨로 "An application client side error has occurred"라는 메세지만 뜨는 식의 실패 형태였음
간단한 랜딩 페이지도 렌더링이 안될 정도라 놀랐고, JS 프론트 프레임워크 때문이라는 걸 알게 된 후엔 그냥 “그럴 만 하구나” 싶었음
사용자들을 설득하려는 사람들에겐 용납되지만, 업계 밖 사람에겐 당혹스러울 수 있음
Next는 이미 자체를 망가뜨린 사례라고 생각함
VC 사이클을 거친 곳은 결국 이런 식임
이제 못 쓰겠고, Vite가 기본 옵션임
가벼운 솔루션을 늘 더 선호함
Next.js에서 “middleware”란 용어는 오해를 낳기 쉬움
실제로는, 요청이 앱에 도달하기 전에 돌리는 가벼운 edge function임(헤더 체크, 라우팅, 간단한 가드 등)
edge 런타임에서 돌아가며, 앱 서버와는 별개의 환경임
저자도 edge와 서버 런타임을 혼동하는 듯함
나도 처음엔 경계가 헷갈렸었고, 자바스크립트 중심이다 보니 구분이 흐릿함
명확한 정신 모델이 필요하다고 생각함
Next.js의 복잡성을 탓하는 건 일종의 도구 상자에 망치 외에도 여러 도구가 들어있다는 걸 탓하는 느낌임
문제는 Next.js의 복잡성이 스스로 자초한 것임
미들웨어라는 용어는 거의 모든 프레임워크에서 이미 확실한 의미가 정립돼 있음
일반적으로 미들웨어는 런타임에서 요청 전에 불리는 함수들의 체인이고, 같은 프로세스에서 실행된다는 전제가 있음
Next.js는 이걸 edge에 배치해서 한 개만 허용하는 방식임
대부분의 앱에서는 edge 기능까지 쓸 필요 없이, 필요할 때에만 opt-in 하게 해야 함
도구상자 비유로 치면, 실제로 필요한 도구만 추가하는 게 맞음
Next.js에서 “middleware”란 용어를 이런 맥락에 써선 안 됨
이는 오용일 뿐만 아니라, 용어 남용임
미들웨어는 웹앱 업계에서 오래된 정의가 있으니, 전혀 다른 걸 의미한다면 쓰지 말았어야 했음
나는 Next.js 앱 라우터를 사용하며 만족하는 편임
Next.js로 프론트와 백엔드 오가기가 매우 쉬워서 사람들이 이 부분까지 추상화된 줄로 착각하는 것 같음
실제로는 아주 복잡한 시스템이고, 이 복잡성을 스스로 감당해야 함
복잡성이 높아진다고 항상 느리거나 비생산적이진 않음
프론트와 백이 분리된 시스템이 훨씬 다루기 쉽긴 한데 그만큼 귀찮기도 함
React를 알아도 Next.js는 완전히 새로 배우는 느낌이고, 직접 겪지 않고는 알 수 없는 부분이 많음
그래도 어느 정도 익숙해진다면, 프론트와 백엔드를 쉽게 넘나드는 매우 편리한 시스템임
내 댓글을 싫어요 누른 사람들이 많은데, 이유를 설명해줬으면 함
나는 언제든 배우고 싶음
이런 토론에서 맹목적 부정만 하지 말고 제대로 논의했으면 좋겠음
드디어 상식적인 의견을 봤다고 느낌
예를 들어 파이썬의 패키지/모듈과 Go의 모듈 개념을 아무 생각 없이 혼동하면, Go가 나쁘다고 불평하는 것과 같음
무엇이든 사용하는 기술에 대한 기본적인 이해는 필요함
Next.js가 앱 라우터로 바뀐 이후, 마치 express API를 개선하는 걸 부트캠프 졸업생들에게 맡긴 느낌이 들었음
모든 서버 인터페이스(서블릿, rack, plug 등)가 수년간 쌓아온 러시안인형식 설계와 맞아떨어진다는 점에서 express API는 그래도 성숙한 접근법임
형편없는 미들웨어 API뿐 아니라, 요청 파라미터를 없애고 cookies()/headers() 같은 글로벌 함수로 대체하는 것도 기이한 결정이었음
기본 설계적 제약이 숨어있는 것 같긴 한데, 외부에서 봤을 때는 기존의 모든 교훈을 다 버리고 실수들을 다시 반복하는 것처럼 보임
여기에다가 lowest common denominator(가장 범용적인) edge 런타임 지원도 끼어들면서, 제약이 심해진 거라고 생각함
나는 항상 새로운 프로젝트에서는 다양한 스택을 써보려고 함
express+react, angular, vue, next, nuxt, go, .net, node, php 등등 프론트와 백엔드 모두 사용해왔음
대부분의 프레임워크에선 장단점을 발견하고, 새로 배우는 재미도 있음
Next.js만은 예외로, 상당히 큰 앱을 만들면서 시작부터 끝까지 하나하나가 이상하거나 느리거나 불편하거나 말도 안 되게 설계됐다고 느낌
아직도 유지보수 중인데, 내가 혐오하는 유일한 “무엇”임
생태계는 괜찮고 인기도 많다고들 하지만, 내 리얼 경험상 돌이킬 수 없을 만큼 부정적이었음
이상하지만, 현실임
혹시 Vercel의 우편 주소 아는 사람 있나?
이 이슈는 내년이면 초등학교 입학 나이가 되는데 회사에 “학교 생활 잘 하세요!” 카드라도 보내고 싶음
https://github.com/vercel/next.js/issues/10084