블로그에 Next.js를 쓰지 않은 이유는 성능 점수 때문이 아니라 생명주기 때문이다. 글을 발행하는 사이트와 사용자가 로그인하는 제품 앱은 같은 속도로 변하지 않는다. 둘을 처음부터 한 런타임에 묶으면, 블로그는 필요 이상의 운영 비용을 떠안고 제품 앱은 콘텐츠 배포 리듬에 끌려간다.
Next.js는 좋은 프레임워크다. 문제는 “좋은 프레임워크”가 “모든 프로젝트의 기본값”은 아니라는 점이다. 기술 블로그를 만들 때도 마찬가지다. 글을 보여주는 사이트에 필요한 것은 서버 컴포넌트, API 라우트, 인증, 동적 렌더링이 아닐 수 있다.
이 조건에서는 Next.js보다 Astro가 먼저 맞다. 지금 필요한 것은 앱이 아니라 문서 사이트에 가깝기 때문이다.
기술 블로그의 첫 번째 요구는 읽히는 것이다
기술 블로그의 핵심 화면은 글 상세 페이지다. 사용자는 제목을 보고 들어와 본문을 읽고, 관련 글로 이동하거나 닫는다. 이 흐름에는 복잡한 클라이언트 상태가 거의 없다.
그렇다면 우선순위는 다음과 같다.
- 본문이 빠르게 보일 것
- 검색엔진이 HTML을 바로 읽을 수 있을 것
- 글 목록과 상세 URL이 안정적일 것
- 발행일, 수정일, 태그, 다국어 링크가 흔들리지 않을 것
- 운영 비용이 낮을 것
이 조건에서는 정적 HTML 생성이 강하다. 페이지를 요청할 때 서버가 조립하지 않아도 되고, 빌드 결과가 곧 서비스 결과가 된다.
이 판단은 프레임워크 선호가 아니라 요구사항의 모양에서 나온다.
| 요구사항 | 블로그에서의 중요도 | Next.js가 유리한 경우 | Astro가 유리한 경우 |
|---|---|---|---|
| 로그인/세션 | 낮음 | 사용자별 화면이 필요할 때 | 공개 글만 보여줄 때 |
| 서버 API | 낮음 | 화면과 API가 함께 움직일 때 | 빌드 시점 데이터로 충분할 때 |
| 본문 SEO | 높음 | SSR을 세밀하게 제어할 때 | 정적 HTML로 충분할 때 |
| 배포 비용 | 높음 | 앱 서버가 이미 필요할 때 | 서버 없이 Pages로 충분할 때 |
| 콘텐츠 검증 | 높음 | 직접 CMS 흐름을 만들 때 | Content Collections로 검증할 때 |
Next.js가 필요한 순간
Next.js가 필요해지는 순간은 분명히 있다. 사용자별 대시보드, 로그인 기반 개인화, 서버 액션, API와 화면이 강하게 연결된 제품, 관리자 기능이 한 저장소 안에서 같이 움직여야 하는 경우다.
예를 들어 작은 제품이 나중에 실제 앱으로 확장되고, 사용자 데이터와 결제, 대시보드, 알림, 개인화 홈이 생긴다면 Next.js는 매우 자연스러운 선택지가 된다.
하지만 블로그만 놓고 보면 그 장점이 과할 수 있다. 필요한 기능보다 런타임과 배포 고려사항이 먼저 들어온다. 작은 제품의 초기에 이 비용은 생각보다 크다.
Astro를 고른 이유
Astro는 콘텐츠 중심 사이트에 맞는 기본값을 제공한다. Markdown과 콘텐츠 컬렉션을 통해 글 데이터를 검증하고, 대부분의 페이지를 정적 HTML로 생성한다. 인터랙션이 필요한 부분만 섬처럼 붙일 수 있다는 점도 블로그와 잘 맞는다.
기술 블로그에서 인터랙션이 필요한 영역은 많지 않다. 배너 전환, 태그 필터, 언어 전환 정도면 충분하다. 본문을 읽는 데 무거운 클라이언트 런타임이 필요하지 않다.
기술 선택은 유행보다 부하의 위치를 봐야 한다. 이 프로젝트의 부하는 런타임 요청 처리보다 콘텐츠 품질과 SEO 구조에 있다. 그래서 프레임워크도 그 방향에 맞췄다.
현재 글 데이터는 이런 frontmatter로 검증된다.
---
title: "Next.js 없이 기술 블로그를 만든 이유"
description: "기술 블로그에 Next.js를 쓰지 않은 이유를 렌더링 방식, 운영 비용, SEO, 확장성 기준으로 비교했습니다."
lang: "ko"
translationKey: "why-not-nextjs-static-blog"
category: "Engineering"
tags: ["nextjs", "astro", "static-site"]
publishedAt: "2026-07-01"
updatedAt: "2026-07-01"
draft: false
---이 값은 목록, RSS, sitemap, BlogPosting JSON-LD에 다시 쓰인다. 프레임워크 선택의 핵심은 여기 있다. 블로그에서는 런타임 기능보다 콘텐츠 데이터가 흔들리지 않는 것이 더 중요했다.
나중에 Next.js로 갈 수 있나
가능하다. 중요한 것은 지금 Astro를 쓰는 것이 나중의 Next.js 선택을 막지 않도록 경계를 유지하는 것이다.
현재 구조에서는 블로그 콘텐츠가 src/content/posts 아래에 있고, 라우팅은 언어와 slug 기준으로 정리되어 있다. 글 메타데이터도 frontmatter에 있다. 나중에 블로그를 별도 패키지로 분리하거나, 제품 앱을 Next.js로 만들더라도 콘텐츠와 앱의 경계가 비교적 선명하다.
즉 “Astro냐 Next.js냐”보다 더 중요한 질문은 이것이다. 블로그와 앱이 같은 생명주기를 가져야 하는가? 지금 답은 아니다.
결론
Next.js를 쓰지 않는 판단은 Next.js가 부족해서가 아니다. 현재 문제에 Next.js가 과하기 때문이다. 정적 HTML, 낮은 운영 비용, Markdown 기반 글 관리, SEO 메타 자동화가 더 중요한 조건이라면 Astro 쪽이 더 작은 해법이다.
좋은 기술 선택은 가장 강한 도구를 고르는 일이 아니다. 지금의 문제를 가장 적은 운영 비용으로 정확하게 해결하는 도구를 고르는 일이다.
이어서 읽기
호스팅과 SEO가 걱정된다면 GitHub Pages로 블로그를 만들면 SEO에 불리할까?를 읽으면 된다. 기록을 가볍게 유지하는 방식은 글을 가볍게 남기는 방식에 더 자세히 정리했다.