블로그를 만들 때 가장 먼저 정해야 하는 것은 프레임워크가 아닙니다. 이 페이지가 어떤 일을 해야 하는지입니다. 제품을 만드는 과정에서 생긴 판단과 기술 기록을 빠르게 읽히는 문서로 남기는 것이 첫 역할이라면, 서버부터 켜는 선택은 과할 수 있습니다.
사용자 계정도 없고, 결제도 없고, 실시간 상태도 없습니다. 이 조건에서 서버 렌더링을 기본값으로 두는 것은 오히려 불필요한 운영 면적을 늘립니다. 그래서 첫 아키텍처는 정적 사이트로 잡았습니다.
정적 사이트가 해결하는 문제
정적 사이트는 빌드 시점에 HTML을 만들어 둡니다. 방문자가 들어올 때마다 서버가 데이터베이스를 조회하고 템플릿을 조립하지 않습니다. 이 차이는 작은 블로그에서 특히 큽니다.
- 운영 비용이 낮다: 서버, 데이터베이스, 런타임 패치 부담이 줄어듭니다.
- 응답이 빠르다: 이미 만들어진 HTML과 정적 자산을 전달합니다.
- 장애 면적이 작다: 런타임 서버가 없으면 장애 유형도 줄어듭니다.
- SEO 기본기가 좋다: 검색엔진은 자바스크립트 실행을 기다리지 않아도 본문과 메타 정보를 읽을 수 있습니다.
물론 정적 사이트가 항상 정답은 아닙니다. 로그인 사용자별 화면, 실시간 개인화, 복잡한 관리자 기능이 필요하면 서버가 필요합니다. 하지만 지금의 블로그는 그런 문제가 없습니다. 현재 문제에 맞는 가장 단순한 해법을 고르는 것이 더 낫습니다.
Astro를 선택한 기준
Astro를 고른 이유는 “요즘 많이 쓰여서”가 아닙니다. 이 프로젝트의 조건과 맞았기 때문입니다.
첫째, 콘텐츠 중심 사이트에 필요한 라우팅과 Markdown 처리가 자연스럽습니다. 글은 콘텐츠 컬렉션으로 검증하고, 페이지는 정적 HTML로 출력할 수 있습니다.
둘째, 기본적으로 클라이언트 자바스크립트를 많이 보내지 않습니다. 블로그 본문을 읽는 데 필요 없는 런타임을 줄이는 것은 성능과 유지보수 모두에 도움이 됩니다.
셋째, 나중에 필요한 섬만 인터랙티브하게 만들 수 있습니다. 예를 들어 검색, 태그 필터, 배너 전환 같은 일부 영역은 동작을 붙일 수 있지만, 본문 전체가 앱처럼 동작할 필요는 없습니다.
SEO는 플러그인이 아니라 구조다
검색 노출을 개선한다고 해서 키워드를 많이 넣는 쪽으로 가면 금방 어색해집니다. 블로그의 SEO는 글 제목, 설명, URL, canonical, sitemap, RSS, 구조화 데이터, 내부 링크가 일관되게 맞물리는 구조에 더 가깝습니다.
현재는 다음 원칙을 둡니다.
- 한 페이지에는 하나의 명확한 주제가 있어야 한다.
- 제목과 설명은 클릭을 유도하되 본문과 어긋나지 않아야 한다.
- 한국어와 영어 페이지는 서로 alternate 링크로 연결한다.
- 글 상세 페이지는
BlogPosting구조화 데이터를 제공한다. - RSS와 sitemap은 배포 결과에 포함한다.
- 태그는 장식이 아니라 글 목록, RSS category, 구조화 데이터에 함께 쓰인다.
이 정도만 지켜도 얇은 자동 생성 페이지와는 결이 달라집니다. 검색엔진을 속이려는 구성이 아니라, 검색엔진이 이해하기 쉬운 문서 구조를 만드는 방향입니다.
확장은 나중에, 경계는 지금
정적 블로그로 시작하더라도 나중에 바뀔 수 있습니다. 제품과 문서가 늘어나면 블로그, 제품 소개, 문서, 앱 영역이 분리될 가능성이 있습니다. 그래서 지금부터 URL, locale, content, layout의 경계를 섞지 않으려고 합니다.
첫 버전의 좋은 아키텍처는 많은 기능을 넣는 것이 아닙니다. 나중에 필요한 기능이 드러났을 때 지금의 선택을 버리지 않고 이어갈 수 있게 만드는 것입니다. 정적 블로그는 그 출발점으로 충분히 강합니다.
이어서 읽기
프레임워크 선택을 더 직접적으로 비교한 글은 Next.js 없이 기술 블로그를 만든 이유에 정리했습니다. 실제 운영에서 검색 노출이 걱정된다면 GitHub Pages로 블로그를 만들면 SEO에 불리할까?를 함께 보면 좋습니다.