솔직히 이해하기 어려움. 정적 블로그에 Next.js는 애초에 필요하지 않았음. 출퇴근에 Ferrari가 필요 없다는 걸 깨닫고 버스로 바꿔 돈을 아꼈다는 글과 다를 바 없어 보임.
Next.js는 완전한 정적 내보내기를 지원하니 그걸 쓰면 됐을 것임.
나도 Next.js의 정적 내보내기로 동적 웹사이트를 운영함. 소개 페이지와 문서는 완전히 정적으로 만들고, 로그인과 사용자 대시보드는 Next.js가 아닌 별도 백엔드에 REST 요청을 보냄. 운영 환경에 Node.js나 SSR 없이도 매우 빠르게 작동함.
Next.js는 대부분의 애플리케이션에 적합하지 않으며, 사실 처음부터 그랬음. Vercel의 끊임없고 과도한 마케팅이 주니어 개발자들에게 적합한 도구라고 믿게 하려 했을 뿐임.
입문자에게 잘못 가르친 선배 개발자들의 책임을 물어야 한다고 봄. 정적 블로그에 무거운 SPA를 사용하는 일이 드물지도 않기 때문임.
그보다는 자전거나 도보로도 출퇴근할 수 있다는 사실을 이제야 깨달은 것에 가까움. 이전에는 그런 선택지가 있다는 것조차 몰랐던 셈임.
Zola나 Hugo 같은 정적 사이트 생성기만 쓰면 끝날 일임.
대다수 웹사이트에는 Next.js나 React가 필요하지 않음. 페이지 구조 안에서 동적·모듈식 갱신이나 상태 관리가 필요할 때나 유용함. 이름이 잘 알려져 있고 관성에 이끌린 탓에 React를 기본값으로 삼게 됐지만, 일반적인 웹사이트에 좋은 프레임워크는 아님.
그런 경우에도 React나 Next.js가 필요한지는 의문임. 웹 컴포넌트로도 구현할 수 있고 LLM도 이를 능숙하게 다루므로, 대형 프레임워크의 효용이 점점 줄어든다고 느낌.
HTML과 순수 JavaScript로 제법 복잡한 CRUD 애플리케이션을 만들었음. JavaScript를 압축하지도 않았는데, 지금까지 만든 다른 모든 웹사이트보다 훨씬 빠르게 로드됨.
빠르다는 것 자체는 당연해서 흥미롭지 않음. 핵심은 그 속도를 유지하면서도 효율적인 개발 경험을 어떻게 확보하느냐임.
이제 AI가 프레임워크 없이도 순수 웹페이지를 생성하고 빠르게 수정할 수 있어, 개발 편의성을 위한 프레임워크가 필요한지라는 질문은 상당 부분 무의미해짐.
기술 인플루언서들은 자기 전문 분야에서 무능함을 드러내는 글을 계속 발표해도 지겹지 않은지 궁금함.
이 사람은 누구인지? 블로그에는 이 글 하나뿐임.
블로그를 Hugo로 만들어 GitHub Pages에 게시함. 방문할 때 충분히 빨라서 성능을 신경 쓴 적이 없는데, 방금 확인하니 PageSpeed 점수가 100점임.
정적 HTML 블로그의 매력은 성능을 고민하지 않아도 된다는 데 있음. 문제의 한 범주가 통째로 사라짐.
회사 사이트를 개편하면서 WordPress에서 Hugo로 이전함. AI로 오래된 WordPress 테마를 수정하는 건 만족스럽지 않았음.
새 브랜드와 스타일 가이드를 준비해 두니 Claude가 빠르게 Hugo로 옮겨 줬고, CDN 없이도 Google 속도 평가가 매우 좋게 나옴.
아내의 사이트 뼈대를 Claude로 만들면서 Hugo, Netlify 무료 요금제, Decap CMS를 사용함. CMS 이외의 부분에서는 JavaScript를 전혀 쓰지 않도록 강제함.
Gulp로 배포 시점에 파일을 포함해 미리 컴파일하는 정적 사이트로 SEO에서 대형 사이트들을 이기고 있음. 순수 JavaScript와 CSS만 사용함.
Next.js도 제대로 쓰면 100점을 받을 수 있음. 다른 도구와 마찬가지로, 쓰는 방식에 따라 복잡성이 늘어날 수 있을 뿐임.
내 Next.js 정적 생성 블로그도 쉽게 100점을 받고 거의 즉시 로드됨. 다만 HN에서 Next.js를 두고 합리적으로 토론하려는 게 무슨 의미가 있나 싶음.
내가 뭔가 놓친 건지? Next.js 정적 내보내기로 해결할 수 있었을 것 같음. Cloudflare Pages에 올리고 앞단에 CDN을 두면 끝임.
다만 Astro가 Next.js보다 가벼울 수는 있음.