개발 slecs

SEO 메타 정보를 DB에서 동적으로 관리하는 구조로 전환

목차

SEO 메타 정보를 데이터베이스에서 동적으로 가져오는 헬퍼 함수를 Python과 JavaScript로 각각 구현했다. 정적인 메타 정보 관리에서 벗어나 확장성 있는 구조로 개선하는 작업이었다.

정적 SEO의 한계와 DB-driven 접근

처음엔 SEO 메타 태그(og:title, og:description, canonical 등)를 정적 설정이나 코드에 박아두는 방식이 많았다. 간단하고 빠르지만, 문제가 생긴다. 콘텐츠가 업데이트될 때마다 코드를 수정해야 하고, 다양한 페이지나 엔티티(상품, 카테고리, 사용자 프로필 등)별로 다른 메타 정보를 관리하기 어렵다. 특히 타사 크롤러나 SNS 프리뷰 생성 시점에 최신 데이터를 반영하려면 데이터베이스에서 실시간으로 가져와야 한다.

DB-driven 방식은 메타 정보의 원본을 데이터베이스에 두고, 필요한 시점에 쿼리를 통해 가져오는 구조다. 이렇게 하면 콘텐츠 변경이 즉시 SEO에 반영되고, 페이지 종류별로 다른 로직을 쉽게 적용할 수 있다. 단, 데이터베이스 접근 오버헤드를 고려해야 한다.

양쪽 언어로의 구현 의미

이 작업에서 seo_db.pyseo_db.mjs를 함께 만들었다는 것은 시스템이 풀스택(또는 멀티스택)이라는 신호다. 예를 들어:

  • 백엔드(Python): 초기 페이지 렌더링 시 메타 정보를 DB에서 가져와 HTML에 삽입
  • 프론트엔드/Node(JavaScript): 클라이언트 사이드 렌더링이나 동적 페이지 생성 시 같은 로직 사용

이렇게 분리하면 두 환경에서 동일한 비즈니스 로직(메타 정보 조회, 폴백, 포매팅)을 실행할 수 있다. 다만 이상적으로는 한 곳에서만 정의하고 공유하는 게 낫다. 현실적으로는 각 스택의 생태계와 성능 특성을 고려해 분리하게 된다.

구현할 때 고려해야 할 패턴들

항목 정적 메타 DB-driven 메타
업데이트 빈도 배포 시 실시간
성능 매우 빠름 DB 쿼리 레이턴시 의존
확장성 낮음(타입별로 다시 작성) 높음(동일 헬퍼로 처리)
캐싱 필요 불필요 필수(응답 시간 최적화)
데이터 신선도 느림 빠름

DB에서 매번 가져오면 성능 저하가 생길 수 있으니, 보통 몇 가지를 함께 고려한다:

  • TTL 기반 캐싱: 메타 정보는 자주 바뀌지 않으니 5~10분 정도 캐시
  • 뜨거운 경로 최적화: 가장 많이 방문하는 페이지(홈, 인기 상품 등)부터 우선 캐싱
  • DB 쿼리 최적화: 조인이 많거나 복잡하면 전용 테이블이나 뷰로 분리
  • 에러 처리: DB 접근 실패 시 폴백 메타 데이터 준비

이 작업을 통한 회고

개인적으로 이 작업을 하면서 느낀 점은, 초반에 "단순함"과 "확장성" 사이의 트레이드오프를 명확히 하는 게 얼마나 중요한지였다. SEO 메타 정보가 정말로 정적인지, 얼마나 자주 변하는지, 몇 종류의 페이지가 있는지를 미리 파악했으면 더 빨리 결정했을 것 같다.

또한 Python과 JavaScript 양쪽을 유지하려니 코드 중복이 생겼다. 이건 팀과 함께 "언어별로 구현하되 테스트 케이스는 동일하게"라는 규칙을 정해서 최소한 동작 일관성은 보장하려 했다. 나중에 공통 로직이 점점 많아지면, 그때 마이크로서비스나 공유 라이브러리로 리팩토링하는 방안도 계획하고 있다.

다음엔 캐싱 레이어와 모니터링을 추가해서, DB 접근 패턴을 실제로 분석하고 성능을 검증하려 한다.


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

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

댓글 0

첫 댓글 달아줘.