Next.js는 짜증나요

• Next.js의 미들웨어는 로깅 설정이 제한적이며, 기본 로깅이 개발 환경에서만 활성화되어 생산 환경에서 문제 추적이 어려움
• 미들웨어에서 헤더만 전달 가능하며, 다중 미들웨어 체이닝이 불가능해 복잡한 로깅 구현이 제한됨
• AsyncLocalStorage를 사용한 로깅은 Edge 런타임에서 예상치 못한 동작을 보이며, 페이지와 미들웨어 간 컨텍스트 공유가 제대로 작동하지 않음
• 커스텀 서버를 사용해도 로깅 문제를 해결하기 어렵고, Next.js의 설계 제약이 개발자를 특정 방식으로 강제함
• Vercel의 SvelteKit은 유연한 미들웨어와 데이터 전달 메커니즘을 제공하며, Next.js보다 개발자 친화적인 설계를 보여줌

---

Next.js의 로깅 문제 배경

• Next.js 서비스를 운영하며 프로덕션 로그 기록을 시도할 때, 기본 로그 기능이 개발 환경에만 활성화됨을 알게 됨
• 운영 환경에 적합한 로깅 시스템 구현이 필요한 상황에서 Next.js의 한계에 직면함

미들웨어의 한계

• 공식 문서에 따르면 미들웨어는 라우팅 전 실행되며 인증, 로깅, 리다이렉션 같은 기능 구현에 적합함
• 실제로 미들웨어에 전달 가능한 파라미터가 4개로 제한되고, 오직 헤더만 실질적으로 전달 가능
• 여러 개의 미들웨어를 체이닝하거나 조합하는 구조를 지원하지 않음
• Node.js에는 Express 등에서 확립된 미들웨어 관행이 존재하지만, Next.js에서는 이를 제대로 적용 불가함

AsyncLocalStorage로 우회 시도

• pino와 AsyncLocalStorage를 사용해 미들웨어 레벨에서 로깅 인스턴스 관리 시도
• 미들웨어에서 요청마다 고유 콘텍스트로 로그 저장이 가능하나, 브라우저 환경에서만 정상 동작하는 현상 확인
• 이는 Next.js 미들웨어가 기본적으로 edge 런타임을 사용하기 때문이며, nodejs 런타임으로 설정해도 프로젝트 상황에 따라 불안정함

페이지 컴포넌트에서의 장애

• 실제 페이지나 레이아웃 컴포넌트에서 로깅 함수 호출 시, logger()가 null을 반환함
• 미들웨어에서 생성한 logger 콘텍스트가 비동기 렌더링 맥락으로 전달되지 않는 구조적 문제 존재
• 해결책은 헤더에 requestId 등 로깅 정보를 실어 전달하는 방법뿐이며, 코드가 복잡해지고 import 구조도 혼란스러워짐
• 클라이언트 컴포넌트에서도 유사한 구조적 분리가 추가 요구됨

커스텀 서버 도입 시도

• 공식 문서의 커스텀 서버 예제를 따라 http.createServer와 next.js의 app.getRequestHandler 활용 실험 진행
• 이 환경에서 AsyncLocalStorage를 다시 활용하고자 했으나, 미들웨어–페이지–커스텀 서버 사이 콘텍스트 연동 불가 현상 반복
• 근본적으로 Next.js 내부에서만 AsyncLocalStorage를 제대로 사용하고 있으며, 개발자에게는 동일한 권한 제공 안 함
• 미들웨어에서 페이지로 전달 가능한 방식이 사실상 응답 헤더(change) 및 리다이렉트/리라이트 경로 이동 뿐임
• 사용자 입장에서 유연한 확장이나 커스텀 콘텍스트 전달이 매우 어려움

SvelteKit과의 비교

• Vercel의 SvelteKit은 Next.js보다 유연한 미들웨어 시스템 제공
  • event.locals 객체를 통해 요청 데이터를 자유롭게 전달 가능
  • 다중 handle 함수를 정의해 체이닝 가능, 복잡한 로직 구현 용이
• SvelteKit은 개발자 친화적 설계를 보여주며, Next.js의 제약과 대조됨
  • SvelteKit은 Vercel의 제품이지만, Next.js보다 부차적 프로젝트로 간주됨에도 더 나은 경험 제공

이슈 트래커 및 생태계 문화 비판

• Next.js의 공식 GitHub 이슈 트래커는 사용자 피드백에 거의 응답하지 않는 상황 발생
• 인기 이슈나 버그도 오랜 기간 답변이나 해결 없이 방치되는 경우 빈번함
• 미니멀 재현 코드를 준비해 이슈를 올려도 실질적 응답이나 후속 조치 없음

결론 및 반성

• Next.js에서 발견되는 버그와 구조적 테두리는 반복적으로 개발자의 생산성을 해치며, 근본적 개선이 필요한 양상임
• 타 프레임워크(SvelteKit 등) 비교 시 Next.js가 주력 제품임에도 사용성에서 밀림
• 당장 Next.js를 대체할 계획은 어렵지만, 향후 프로젝트에선 다른 선택지를 고려하고 싶은 마음 생김

[bichi]

리엑트가 생산성 해치는건 아직 생각을 못했나 보네요

[ahwjdekf]

이번에 개인적인 흥미만 가지고 원래 개발하던 분야와 전혀 상관없는 분야인 웹 개발을 한번 해봤습니다. next.js v15 app router 로 게시판 만든건데.. 이런 글 볼 때마다 웹 쪽은 뭔가 새로 해보고 싶은 의욕이 없어지는 거 같네요. 왜 이리 생태계가 불안정 할까요. 이러다가 또 새로운 거 나오면 우루루 몰려가서 좀 쓰다가 또 욕하면서 다른거 찾는건가요. 웹 개발쪽은 참 어렵겠네요.

[preserde]

업계 특성상 변화가 빠르다는 게 장점이기도 하지만 단점이기도 하죻ㅎ 근데 본문의 문제는 근본적으로는 vercel의 분탕질이 원인입니다. 프론트 하실거면 버셀을 좀 요주의하실 필요가 있습니다 ㅠㅠ

[joyfui]

제가 커리어를 웹으로 시작해서 그런지 몰라도 웹은(특히 프론트는) 원래 그런 맛(?)으로 개발합니다ㅎㅎ
휙휙 변화무쌍한 맛...

[regentag]

JS쪽이 좀 그런 느낌이에요. 뭔가 좋다는것들이 한무더기 있는데 조금식 다 문제가 있고 유행따라 금방금방 바뀌는...
제가 Java, EJB, Struts를 주력으로 했었어서 그렇게 느끼는 것일수도 있지만요.

[GN⁺]

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

[bth15923]

밑에 달리는 Hacker News 의견에 있는 말이 정확하네요.

"Next.js는 99.9999%의 프로젝트에서 필요 없는 엄청난 추상화 레이어가 있음, 정말로 이런 게 필요한 소수의 사례에서는 차라리 하위 레벨 부품으로 맞춤형 솔루션을 만드는 게 더 낫다고 생각함"

쓸데없이 과도하게 복잡한 API, 불안정하고 불완전하면서도 꿋꿋하게 production ready라고 홍보하는 작태, vercel에 대한 엄청난 의존성 때문에 vercel 아니면 본격적으로 운영하기도 어려움.