SEO 메타데이터를 DB로 옮겨 배포 없이 운영팀이 직접 수정

DB 드리븐 SEO 메타 데이터 패턴(getSiteSeo)을 구현했다. 정적 하드코딩에서 동적 관리로 전환하는 작업이었다.

정적 SEO 구성의 한계

그동안 Astro 프로젝트의 SEO 메타 태그들은 설정 파일이나 코드에 박혀 있었을 거다. 사이트 제목, 기본 description, Open Graph 이미지 같은 것들 말이다. 이 방식이면 메타 태그 하나 바꿀 때마다 배포가 필요했다. 운영자가 간단한 텍스트 수정을 위해 개발팀을 기다려야 하는 상황이 반복되면, 팀 간 마찰도 생기고 운영 속도도 떨어진다.

또 다른 문제는 A/B 테스트나 동적 최적화가 거의 불가능했다는 점. 어떤 OG 이미지가 더 잘 작동하는지, 어떤 description이 CTR을 높이는지 실험하려면 코드 변경 → 배포 → 대기를 반복해야 했다. 스타트업이나 성장 단계의 서비스라면, 이런 병목이 상당한 기회 손실이다.

DB 드리븐 패턴의 설계

이번엔 getSiteSeo 함수를 구현해서 SEO 메타 데이터를 DB에서 조회하도록 했다. 기본 구조는 대략 이렇다:

// DB에 저장된 SEO 설정
{
  "siteId": 1,
  "title": "서비스명",
  "description": "한 줄 설명",
  "ogImage": "https://cdn.../og.png",
  "ogImageAlt": "이미지 설명",
  "updatedAt": "2026-06-02T..."
}

// 런타임에 조회
async function getSiteSeo() {
  return await db.siteSeo.findOne({ siteId: 1 });
}

src/layouts/Base.astro 에서 이 함수를 호출하면, 페이지 빌드 시점이나 요청 시점에 최신 메타 데이터를 반영할 수 있다. 변경 파일을 보면 astro.config.mjs를 건드린 것도 마찬가지 — 아마도 DB 커넥션 설정이나 빌드 타임 데이터 페칭 옵션을 추가했을 것 같다.

기본 레이아웃에 적용한 의미

Base.astro는 거의 모든 페이지가 상속하는 루트 레이아웃이다. 이 자리에 getSiteSeo를 심는다는 건, 곧 전체 사이트의 SEO 기초를 동적으로 관리한다는 뜻이다.

잠재적 트레이드오프:
- 빌드 성능: 정적 데이터 vs. 매 빌드마다 DB 쿼리. Astro는 기본적으로 정적 SSG 모드인데, DB 호출이 들어가면 빌드 시간이 늘어난다. 다만 대부분의 경우 캐싱 헤더나 revalidation 설정으로 충분히 보상 가능하다.
- 런타임 의존성: DB가 일시적으로 느리거나 장애나면 메타 태그 로딩이 지연될 수 있다. 폴백(fallback) 메타 데이터를 준비해두는 게 좋다.
- 초기 복잡도: 세팅할 것들이 늘어난다. package.json에 새로운 의존성도 추가됐을 테고, 데이터 스키마도 정의해야 한다.

배운 점 & 고민 지점

이 작업을 하면서 느낀 건, 정적 구성에서 동적 구성으로의 전환은 기술적 결정이면서 조직적 결정이라는 것. 코드만 잘 짜서는 안 되고, 실제로 운영팀이나 마케팅팀이 이 기능을 제대로 사용할 수 있도록 문서화하고 교육하는 게 중요하다.

또 하나는 점진적 전환의 가치다. 처음부터 모든 메타 데이터를 DB로 옮기려 하기보다, 우선순위가 높은 것들(사이트 제목, 기본 OG 이미지 등)부터 시작하고, 나머지는 기존 방식을 유지하면서 천천히 마이그레이션하는 게 리스크를 줄인다.

마지막으로, 팀원들과 코드리뷰할 때는 "이게 왜 필요한가"를 명확히 하는 게 좋다. 단순히 "DB에서 가져오자"는 기술 얘기보다, "운영팀이 직접 메타 태그를 수정하고 싶어 했다", "A/B 테스트를 빠르게 실행해야 한다" 같은 비즈니스 배경을 공유하면, 팀원들도 설계의 의도를 더 잘 이해하고 유지보수도 쉬워진다.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.