웹 성능을 고민하는 개발자라면 Lighthouse 점수를 한 번쯤 들여다보게 된다. 성능, 접근성, 권장사항, SEO 네 영역에서 모두 100점을 받는 일은 생각만큼 쉽지 않다. 한 개인 개발자가 자신이 만든 블로그 플랫폼(bloffy.co)에서 전 항목 100점을 달성한 과정을 공개했는데, 그 결론이 다소 도발적이다. 가장 익숙하게 써 오던 프레임워크인 Next.js를 결국 제거해야 했다는 것이다. 모든 성능 측정은 pagespeed.web.dev를 기준으로 했다.
출발점은 플랫폼 선택이었다. 그는 가볍고 빠르면서 군더더기가 없고, 여러 블로그를 운영할 수 있으며 접근성까지 갖춘 블로그를 원했다. Medium과 Blogger는 기능이 과하고 성능도 만족스럽지 않았으며, Markdown·HTML·CSS 같은 원본 마크업을 직접 다루기 번거롭다는 점도 걸렸다. WordPress의 플러그인 지옥, 자체 호스팅이 필요하고 버전 업그레이드마다 에디터가 깨지는 Ghost, 설정이 여전히 성가신 Hugo 모두 성에 차지 않았다. 가장 마음에 든 것은 Bear Blog였지만, 극단적인 미니멀리즘과 에디터 UX가 본인에게는 단점이었다. 결국 그가 원한 것은 Bear Blog만큼 빠르면서 기능과 사용성이 조금 더 나은 SaaS였다.
캐싱에서 CDN으로, 그리고 Next.js의 재발견
성능 개선의 기본은 캐싱이다. Next.js는 ISR과 fetch의 next 옵션 등으로 캐싱을 편리하게 다룰 수 있어 이것만 잘 활용해도 상당한 성능을 얻는다. 문제는 전 세계 어디서나 접속할 수 있는 사이트라는 점이다. 같은 지역 안에서는 캐싱으로 빨라지지만, 다른 지역 방문자는 네트워크 지연을 그대로 감수해야 한다. 그래서 CDN이 필요하다. Next.js 앱을 Vercel에 배포하면 CDN이 기본 제공되지만, Pro 요금제가 처음부터 비싸고 서버리스 콜드 스타트 문제, 그리고 Vercel 생태계 의존성이라는 부담이 따른다.
대안으로 Cloudflare를 검토하자 생각이 한 걸음 더 나아갔다. 대규모 인프라와 대부분의 앱을 무료로 운영할 수 있는 CDN을 앞단에 두고 보니, 정적 사이트에는 CDN만으로 충분하며 Next.js의 캐싱 자체가 더는 필요 없다는 결론에 이른 것이다. 글을 발행할 때마다 두 개의 캐시를 무효화해야 하는 관리 부담도 사라진다. 이것이 Next.js를 버린 첫 번째 이유였다. 이미지 최적화 역시 과거에는 AWS Lambda로 압축·리사이즈하고 CloudFront를 CDN으로 붙이는 식이었지만, 이번에는 무료 구간에서 5,000장을 제공하는 Cloudflare Image Transformations로 간단히 해결했다.
정적 페이지에 남는 런타임이라는 벽
점수는 꽤 높게 나왔지만 '별표 없는' 깔끔한 100점에는 미치지 못했다. 원인을 파고드니, 직접 작성하지 않은 상당량의 레거시 JavaScript가 Next.js 프레임워크 런타임에서 번들로 딸려 오고 있었다. 상호작용이 전혀 없는 정적 페이지이고 모든 페이지를 ISR로 사전 렌더링했는데도 그랬다. 실험 삼아 클라이언트 컴포넌트를 전부 걷어내고 서버 컴포넌트만 남겨 다시 측정했지만 점수는 꿈쩍하지 않았다.
처음엔 하이드레이션을 의심했으나, 진짜 원인은 Next.js가 정적 페이지에도 항상 실어 보내는 클라이언트 런타임이었다. 서버 컴포넌트만 써도 런타임 청크와 하이드레이션, 라우터용 RSC 페이로드가 그대로 남는다. next/link와 next/image 자체가 'use client' 클라이언트 컴포넌트이기 때문에, 이 둘만 있어도 런타임이 끌려 들어오고 하이드레이션이 발생한다. 그 둘마저 제거해도 App Router 자체의 런타임, 라우터, 에러 바운더리는 남았다. 0으로 줄이는 공식적인 방법은 없었고, 렌더링된 HTML에서 스크립트를 떼어내는 편법만 남았다. 사용되지 않는 코드만 230,460바이트에 달하는 상황에서, 그는 '이럴 바에야 Next.js를 왜 쓰나'라는 생각에 도달했다.
Hono로의 이주와 남는 질문
고민 끝에 그는 블로그 품질을 위해 단 5점일지라도 Next.js를 완전히 걷어내기로 했다. 장기적으로 Next.js의 과한 기능이 필요 없으리라는 판단도 함께였다. 완전한 바닐라도 고려했지만 프레임워크가 주는 생산성과 인프라 이점은 포기하고 싶지 않아, '빠르고 단순함'을 내세우고 JSX까지 지원하는 Hono를 택했다. 이주 비용도 크지 않아 보였다. 결과적으로 전 항목 100점을 받았고, 사용되지 않는 코드는 407바이트까지 급감했으며 빌드 시간도 약 40% 줄었다. 화면에 무언가 그려지기 전 실행되는 긴 작업은 Next.js에서 309.3ms였던 것이 Hono에서는 68.01ms로, 약 78% 개선됐다. 참고로 테스트용 사이트가 검색 색인을 일부러 막아 둔 탓에 SEO만 69점으로 나왔다.
이 사례가 주는 실무적 함의는 분명하다. 상호작용이 거의 없는 정적 블로그나 문서 사이트라면 하이드레이션을 포함한 JS 페이로드는 대부분 불필요한 짐으로 남는다. 다만 이것이 Next.js에 대한 전면적인 평가는 아니다. 글쓴이 역시 상호작용이 많은 앱에는 Next.js가 훌륭한 프레임워크라고 못 박았고, 실제로 같은 블로그의 관리자 앱은 Next.js로 만들었다고 밝혔다. 핵심은 프레임워크의 우열이 아니라, 사이트의 성격에 맞춰 도구를 고르는 판단이다. 정적 전달이 본질인 곳에 풀스택 프레임워크의 런타임을 얹는 것이 과연 이득인지, 각자의 프로젝트에서 한 번쯤 따져 볼 만하다.