Skip to content
Go DevBJ
Go back

Astro 동적 OG 이미지, 템플릿과 캐시를 분리해서 봐야 한다

Edit page

Astro 블로그를 운영하다 보면 OG 이미지가 신경 쓰인다.

글을 공유했을 때 제목과 설명이 들어간 카드가 예쁘게 보이면 좋다.

그래서 글마다 OG 이미지를 자동 생성하고 싶어진다.

하지만 여기서 바로 구현으로 들어가면 금방 복잡해진다.

템플릿은 어디에 둘까?
이미지는 언제 만들까?
글이 바뀌면 어떻게 다시 만들까?
매번 빌드할 때 전부 다시 만들어야 할까?

이 문제는 템플릿과 캐시를 나눠서 봐야 편하다.

Astro 동적 OG 이미지 템플릿 삽화

OG 이미지는 글의 포스터다

OG 이미지는 본문에 보이는 이미지와 역할이 다르다.

본문 삽화가 글을 읽는 사람을 위한 이미지라면,
OG 이미지는 글을 공유하거나 검색 결과에 노출될 때 보이는 포스터에 가깝다.

그래서 보통 다음 정보를 담는다.

너무 많은 정보를 넣으면 오히려 읽기 어렵다.

템플릿은 디자인 문제다

OG 이미지 템플릿은 시각 규칙이다.

예를 들어:

배경색
제목 위치
설명 줄 수
사이트 이름
카테고리 라벨
강조 색상

이 템플릿은 코드로 만들 수 있지만,
본질은 디자인 시스템에 가깝다.

한 번 정하면 모든 글에 적용되므로 너무 자주 바꾸지 않는 편이 좋다.

렌더링은 빌드 작업이다

템플릿에 글 데이터를 넣어 실제 PNG를 만드는 과정은 빌드 작업이다.

보통은 이런 흐름이다.

post data
→ OG template
→ SVG/HTML render
→ PNG output

도구로는 Satori, Resvg, Sharp 같은 조합을 쓸 수 있다.

이 작업은 단순 HTML 생성보다 무겁다.

그래서 글이 많아지면 빌드 시간이 늘어난다.

캐시는 운영 문제다

OG 이미지 자동 생성에서 진짜 중요한 부분은 캐시다.

글 제목과 설명이 그대로라면 이미지는 다시 만들 필요가 없다.

캐시 키는 이런 값으로 만들 수 있다.

slug
title
description
template version

템플릿 버전을 넣는 이유는,
디자인을 바꿨을 때 모든 이미지를 다시 만들 수 있어야 하기 때문이다.

템플릿 변경과 글 변경을 구분한다

글 하나의 제목만 바뀌었다면 그 글의 OG 이미지만 다시 만들면 된다.

하지만 템플릿이 바뀌었다면 전체 이미지를 다시 만들어야 한다.

그래서 캐시 정책은 두 변화를 구분해야 한다.

글 데이터 변경
→ 해당 글만 재생성

템플릿 변경
→ 전체 재생성

이 기준이 없으면 캐시가 있더라도 운영이 헷갈린다.

public에 둘지 캐시에 둘지 나눈다

직접 만든 대표 삽화는 public/images에 두기 좋다.

하지만 자동 생성 OG 이미지는 빌드 산출물 성격이 강하다.

그래서 별도 캐시 폴더를 쓰고,
빌드할 때 필요한 결과만 배포물에 복사하는 구조가 더 자연스럽다.

og-cache/
  hash-a.png
  hash-b.png

dist/posts/example/index.png

중요한 건 배포 URL은 안정적으로 유지하는 것이다.

미리보기 페이지가 있으면 편하다

OG 이미지는 실제 공유 전까지 문제를 놓치기 쉽다.

그래서 개발 중에는 템플릿 미리보기나 샘플 렌더링이 있으면 좋다.

확인할 것:

특히 한글 제목은 줄 길이에 민감하므로 꼭 테스트해야 한다.

오늘 포인트

Astro 동적 OG 이미지는 한 덩어리 기능처럼 보이지만,
실제로는 세 가지를 나눠 봐야 한다.

템플릿 = 디자인 규칙
렌더링 = 빌드 작업
캐시   = 운영 정책

이 구분이 있어야 글이 늘어도 빌드 시간이 감당 가능하고,
템플릿을 바꿀 때도 예측 가능하다.

한 줄 요약

Astro 동적 OG 이미지는 템플릿, 렌더링, 캐시를 분리해서 설계해야 글이 늘어도 빌드와 운영이 덜 흔들린다.


Edit page
Share this post on:

Previous Post
Visual Traceroute Sandbox, 네트워크 경로를 안전하게 실험하는 도구
Next Post
Astro dev에서는 되는데 build 후 깨질 때 보는 순서