"라이트하우스 100점 찍으려고 가장 애용하던 Next.js 버렸습니다" 1인 개발자의 탈출기

요약 자신만의 블로그 서비스를 직접 만들던 한 1인 개발자가 구글 라이트하우스(Lighthouse) 성능 점수 100점 만점을 달성하기 위해 가장 애용하던 프레임워크인 Next.js를 완전히 들어내게 된 사연을 공개했습니다. 작성자는 기존의 미디엄(Medium), 블로거(Blogger), 워드프레스, 고스트(Ghost), 베어블로그(Bear Blog) 등이 기능이 과도하게 무겁거나, 마크다운/HTML 등 원본 코드 다루기가 번거롭거나, 자체 호스팅 및 에디터 유지보수 비용이 크다는 점에 불만을 품고 직접 빠르고 가벼운 블로그(bloffy.co)를 구축하기 시작했습니다. 처음에는 익숙한 Next.js를 도입하고 ISR(증분 정적 재생성)과 캐싱 옵션을 적극 활용했습니다. 그러나 글로벌 트래픽의 네트워크 지연을 해결하기 위해 클라우드플레어(Cloudflare) CDN과 이미지 변환 기능을 도입하자, Next.js 자체 캐싱과의 이중 캐시 무효화 관리만 복잡해지며 정적 웹사이트에서 프레임워크 수준의 캐싱 필요성이 희미해졌습니다. 결정적인 문제는 자바스크립트 번들 크기였습니다. 라이트하우스 측정 결과 대량의 미사용 레거시 자바스크립트가 지적되었는데, 작성자가 짠 코드가 아니라 Next.js 프레임워크 자체의 런타임 번들이었습니다. 인터랙션이 전혀 없는 순수 정적 페이지임에도 불구하고, 모든 클라이언트 컴포넌트를 제거하고 서버 컴포넌트만 남겨도 런타임 청크와 RSC 페이로드가 그대로 포함되었습니다. 심지어 next/link나 next/image 자체에도 'use client'가 포함되어 있어 런타임을 강제로 끌어왔고, App Router 자체의 런타임과 에러 바운더리 등 미사용 자바스크립트만 230KB 이상 발생했습니다. 렌더링된 HTML에서 강제로 스크립트를 뜯어내는 꼼수까지 고민하던 작성자는 결국 "이럴 거면 굳이 Next.js를 쓸 이유가 없다"고 판단하여 프레임워크를 걷어냈고, 마침내 라이트하우스 모든 카테고리에서 100점 만점을 기록했다고 전했습니다.