Astro 7로 올리면서 블로그 구조를 다시 점검했다

기다리던 Astro 7이 나와서 블로그에 바로 적용했다. 정확히는 메인 브랜치에 바로 밀어 넣은 건 아니고, 평소처럼 dev 브랜치에서 먼저 처리했다. 이번 업데이트는 “올릴까 말까”를 오래 고민했다기보다, 나오면 바로 올려보고 싶었던 쪽에 가까웠다.

내 블로그는 Astro로 만들고 있다. 복잡한 서비스는 아니지만 Home, Archive, About, Post, RSS, sitemap, SEO, 검색, 댓글까지 블로그에 필요한 기본 구조는 어느 정도 갖춰져 있다. 최근에는 Home 목록 구조, About 문구, Footer, 전역 CSS, focus-ring, 읽는 시간 계산 로직 같은 부분을 계속 다듬고 있었다.

그래서 이번 Astro 7 업그레이드는 단순히 패키지 버전을 올리는 작업이라기보다, 최근에 손본 블로그 구조를 한 번에 다시 확인하는 작업이 됐다.

기다리던 업데이트

Astro 7은 속도 개선에 초점이 맞춰진 릴리즈다. .astro 컴파일러가 Rust 기반으로 바뀌었고, Markdown/MDX 처리도 Rust 기반 파이프라인으로 바뀌었다. 여기에 Vite 8, Advanced Routing, background dev server, structured logging 같은 변경도 포함됐다.

개인 블로그 입장에서 가장 눈에 들어온 건 Rust compiler와 Markdown/MDX 처리 개선이었다. 내 블로그는 글 중심 사이트라서 결국 Markdown을 얼마나 안정적으로 처리하고 빌드하느냐가 중요하다. 지금 블로그 규모에서 빌드 속도 차이가 극적으로 체감될 정도는 아닐 수 있지만, 블로그는 시간이 지날수록 글이 쌓이는 구조다. 글 목록, 아카이브, 태그, RSS, sitemap, 검색 인덱스 같은 것들이 같이 늘어난다.

그런 점에서 Astro 7의 방향은 꽤 반가웠다. 당장 새로운 기능을 많이 쓰지 않더라도, 글 중심 블로그의 기반이 더 단단해지는 업데이트처럼 느껴졌다.

dev 브랜치에서 바로 처리했다

업데이트는 dev 브랜치에서 바로 진행했다. 이번 작업의 느낌은 “대규모 마이그레이션”이라기보다, 기다리던 메이저 업데이트를 적용하고 기존 화면이 그대로 유지되는지 확인하는 쪽에 가까웠다.

메이저 버전 업데이트라고 해서 항상 큰 문제가 생기는 것은 아니다. 하지만 내 블로그에는 이미 여러 요소가 붙어 있다 보니, 빌드가 되는지만 보고 끝낼 수는 없었다. Home의 글 목록이 기존 의도대로 보이는지, Archive의 연도별 글 정렬이 유지되는지, About 페이지의 문구와 간격이 어색하지 않은지, Footer가 전체 분위기 안에서 자연스럽게 마무리되는지 확인했다.

글 상세 페이지에서는 제목, 본문, TOC, 읽는 시간, 댓글 영역을 봤고, SEO 메타, RSS, sitemap, 검색 인덱스 쪽도 함께 확인했다. 결국 이번 업데이트에서 가장 중요했던 건 “Astro 7의 새 기능을 얼마나 썼는가”가 아니었다. 내가 최근에 고친 블로그 구조가 업데이트 이후에도 그대로 유지되는지 확인하는 일이 더 중요했다.

Home과 About을 다시 보게 됐다

최근 Home 페이지를 손보면서 글 목록 구조를 꽤 고민했다. Home은 블로그의 첫 화면이다. 최근 글을 몇 개까지 보여줄지, 날짜와 제목 사이 간격을 어떻게 둘지, 데스크톱에서 너무 비어 보이지는 않는지 같은 작은 요소들이 첫인상을 만든다.

변수명도 고민했다. homePosts처럼 페이지 맥락을 드러낼지, recentPosts처럼 데이터의 의미를 드러낼지 같은 문제다. 작게 보면 별일 아니지만, 나중에 코드를 다시 봤을 때는 이런 이름이 꽤 중요하다.

About 페이지도 비슷했다. 처음에는 더 많은 설명을 넣을 수도 있었다. 하지만 내 블로그는 포트폴리오 사이트라기보다 기록 중심의 공간에 가깝다. 그래서 About도 과하게 나를 설명하기보다, 내가 어떤 것을 기록하고 쌓아가는 사람인지 보여주는 쪽이 더 어울렸다.

Astro 7로 올린 뒤에도 결국 확인한 건 이런 부분이었다. 업데이트 후에도 Home은 Home답게 보이는지, About은 과하지 않고 블로그 전체 톤과 맞는지. 기능적으로는 작은 페이지들이지만, 블로그의 인상을 만드는 데는 이런 페이지들이 더 중요하다.

읽는 시간 계산 로직을 내부 유틸로 옮겼다

이번에 같이 정리한 것 중 하나는 읽는 시간 계산 로직이었다. 겉으로 보이는 화면은 크게 달라지지 않았다. 글 상단에는 여전히 n분 읽기처럼 표시된다. 하지만 내부에서 그 값을 계산하는 방식은 바꿨다.

기존에는 별도의 remark-reading-time.mjs 파일에서 읽는 시간을 계산했다.

import getReadingTime from 'reading-time';
import { toString } from 'mdast-util-to-string';
 
export function remarkReadingTime() {
  return function (tree, { data }) {
    const textOnPage = toString(tree);
    const readingTime = getReadingTime(textOnPage);
    data.astro.frontmatter.minutesRead = readingTime.text;
  };
}

이 방식은 Markdown을 처리하는 Remark 단계에서 AST를 문자열로 바꾸고, 그 결과를 data.astro.frontmatter.minutesRead에 주입하는 구조였다. 빌드 타임에 계산된 값을 frontmatter처럼 사용할 수 있다는 장점은 있었지만, 읽는 시간 계산이 Markdown 처리 파이프라인에 묶여 있었다.

이번에는 이 로직을 내부 유틸로 옮겼다.

import getReadingTime from 'reading-time';
 
export function parseMinutes(input: string): number | null {
  const m = input.match(/\d+/);
  return m ? Number(m[0]) : null;
}
 
export function getPostReadingTime(body?: string) {
  return parseMinutes(getReadingTime(body ?? '').text);
}

변경 후에는 Remark 플러그인에서 frontmatter를 주입하지 않는다. 대신 필요한 곳에서 본문 body를 기준으로 읽는 시간을 계산한다. reading-time이 반환하는 표시용 문자열에서 숫자만 추출해, 내부에서는 분 단위 숫자를 다루도록 했다.

이렇게 바꾸니 역할이 조금 더 명확해졌다. 읽는 시간 계산은 Markdown 파이프라인의 책임이 아니라, 글 데이터를 화면에 보여주기 전에 처리하는 유틸의 책임이 됐다. UI에서는 이 숫자를 받아 n분 읽기 형태로 보여주면 된다.

작은 변경이지만 마음에 드는 부분은 데이터 형태가 더 단순해졌다는 점이다. 기존에는 readingTime.text처럼 표시용 문자열을 그대로 저장했다. 반면 지금은 내부에서는 숫자를 다루고, 표시 형식은 화면 쪽에서 결정할 수 있다.

블로그 글 메타 정보는 작아 보이지만 여러 곳에서 쓰일 수 있다. 글 상세 페이지, 글 카드, 목록, SEO용 데이터 등에서 필요할 수 있다. 그래서 이런 값은 가능하면 표시 문자열보다 의미 있는 값으로 들고 있는 편이 낫다고 느꼈다.

결과적으로 화면은 그대로지만, 내부 구조는 조금 더 단순해졌다. n분 읽기라는 작은 문구 하나도 결국 어디에서 계산하고, 어떤 형태로 넘기고, 어디에서 표시할지를 정해야 한다. 이번 Astro 7 업데이트를 하면서 이런 작은 로직까지 같이 정리한 셈이다.

Footer와 focus-ring 같은 작은 부분들

Footer도 다시 확인했다. Footer는 큰 기능이 있는 영역은 아니지만, 사이트의 마지막 인상을 만든다. 너무 건조하면 아쉽고, 너무 많은 내용을 넣으면 미니멀한 분위기가 깨진다. 그래서 최근에는 블로그 전체 톤에 맞게 조용히 마무리되는 방향으로 정리했다.

focus-ring도 마찬가지다. 개인 블로그라고 해도 키보드 접근성은 대충 넘기고 싶지 않았다. 포커스가 보이는지, hover 상태와 충돌하지 않는지, 레이어가 이상하게 올라오지 않는지 확인했다.

Tailwind를 쓰면 빠르게 스타일을 만들 수 있지만, 클래스가 길어질수록 나중에 읽기 어려워진다. 특히 임의 값을 많이 쓰면 당장은 편하지만, 나중에 다시 봤을 때 왜 그 값이 필요했는지 떠올리기 어렵다. 이번 Astro 7 업데이트는 이런 작은 스타일 결정들을 다시 훑어보는 계기이기도 했다.

업데이트보다 중요한 것

Astro 7로 올린 것 자체는 만족스럽다. 기다리던 업데이트였고, 블로그도 계속 Astro 기반으로 가져갈 생각이라 바로 따라가고 싶었다. 특히 글 중심 사이트 입장에서 Rust compiler와 Markdown/MDX 처리 개선은 방향이 좋다고 느꼈다.

다만 이번 작업을 하면서 다시 느낀 건, 프레임워크 업데이트보다 중요한 건 내가 만든 구조를 계속 이해하고 있는가였다. Home의 글 목록, About의 문장 톤, Footer의 마무리, focus-ring의 위치, 읽는 시간 계산 로직, SEO 메타 구조 같은 것들은 하나하나 보면 작은 수정이다. 하지만 전부 합치면 블로그의 인상과 유지보수성을 만든다.

Astro 7로 올렸다고 해서 블로그가 갑자기 좋아지는 것은 아니다. 좋은 업데이트는 기반을 더 단단하게 만들어줄 뿐이다. 그 위에서 어떤 구조를 유지할지, 어떤 문장을 남길지, 어떤 요소를 덜어낼지는 결국 내가 결정해야 한다.

이번 업데이트는 그래서 단순한 버전 업데이트라기보다, 기다리던 업데이트를 적용하면서 내 블로그의 읽기 경험과 구조를 다시 정리한 작업에 가까웠다. 블로그는 오래 남기 위한 공간이다. 그래서 최신 버전을 따라가는 것도 중요하지만, 그보다 더 중요한 건 업데이트 이후에도 내 블로그가 여전히 내 의도대로 읽히고 보이는지 확인하는 일이라고 느꼈다.