CMS 기반 타이틀로 홈 페이지 SEO 메타 신뢰성 확보

홈 페이지의 title 태그가 실제로 CMS에서 관리하는 SEO 메타 데이터(cms_site.meta.seo.title)를 반영하지 못하고 있던 버그를 발견했다. Base.astro 라는 루트 레이아웃 파일에서 타이틀을 직접 DB에서 가져오도록 배선을 수정했는데, 이게 생각보다 깊이 있는 선택 문제더라.

하드코딩이 남겨진 이유

정적 사이트 생성기나 프론트엔드 프레임워크에서 title 같은 메타 데이터는 보통 두 가지 방식으로 관리된다. 하나는 레이아웃 파일이나 설정 파일에 하드코딩하거나 기본값을 놓는 것이고, 다른 하나는 빌드 타임 또는 런타임에 CMS/데이터베이스에서 동적으로 가져오는 것이다.

홈 페이지처럼 전체 사이트를 대표하는 페이지의 경우, 작은 타이틀 변경 때문에 매번 배포할 필요가 없도록 DB 관리를 하는 게 정석이다. 그런데 이전 코드는 아마도 "홈은 가장 중요하니까 정성들여서 한 번만 설정하면 되겠지" 하는 가정 하에 하드코딩되어 있었을 것 같다.

실제로 CMS 운영팀이 타이틀을 수정했는데도 사이트에 반영이 안 됐다는 보고가 들어왔다. 그 순간 이게 단순한 버그가 아니라, 팀 간의 기대치 불일치라는 걸 깨달았다. 마케팅이나 운영팀 입장에서는 "CMS에 입력한 데이터가 사이트에 즉시 적용되는 게 당연하지 않나" 라고 생각하는데, 개발 쪽에서 "그건 프론트엔드 배포가 필요해" 라고 할 수 없는 노릇이다. 결국 사용자 관점의 "신뢰할 수 있는 CMS"라는 경험이 깨지는 셈이다.

Base.astro 에서의 변경 의도

Base.astro는 모든 페이지가 상속하는 루트 레이아웃이다. 여기서 title을 한 곳에서 관리하는 것의 장점은 일관성과 중앙화다. 만약 각 페이지마다 title을 따로 설정하게 놔두면, 누군가는 빼먹을 것이고, 누군가는 중복으로 설정할 것이다.

하지만 홈 페이지는 특별하다. 개별 게시글이나 상품 페이지처럼 동적 콘텐츠를 반영하는 페이지가 아니라, "사이트 대표"라는 역할을 하기 때문이다. 그래서 CMS의 사이트 전역 설정(site.meta.seo)에서 타이틀을 가져오는 게 맞다.

이 표가 보여주는 것은, 하드코딩이 항상 나쁜 건 아니지만, 운영이 자주 변경하는 데이터라면 분명 관리 포인트가 된다는 것이다. 우리 팀에서도 CMS 운영 중심이 마케팅팀이라면, 매번 개발자 손을 거쳐야 하는 구조는 병목이 될 수밖에 없다.

비슷한 메타 데이터 패턴들

사실 title만 해당 사항이 아니다. 오픈그래프(og:image), 메타 설명(description), canonical URL, structured data 같은 SEO 메타 정보들도 모두 같은 논리가 적용된다.

일부 팀은 이 모든 것을 구조화된 데이터로 CMS에 몰아놓고, 빌드 타임에 일괄 주입하는 방식을 쓴다. 장점은 성능(정적 파일에 미리 박혀 있음)인데, 단점은 "타이틀 하나 바꾸려고 전체 재빌드"를 해야 한다는 것. 또 다른 팀은 ISR(Incremental Static Regeneration) 같은 패턴으로 요청 시점에 검증해서 캐시를 갱신하는 방식을 쓴다.

우리의 경우 CMS 데이터 구조가 이미 cms_site.meta.seo로 잘 정리되어 있었으니, 거기서 바로 가져오는 게 가장 직관적인 선택이었다. 다만 한 가지 고려할 점은 "빌드/렌더 타임에 이 데이터를 가져올 때 CMS API가 항상 응답하는가" 같은 운영 안정성이다. API 지연이나 일시 다운 시 폴백(기본값) 전략도 함께 생각해야 한다.

회고와 배운 점

이 수정을 통해 깨달은 게 하나 있다. 개발자 입장에서는 "이건 버그야, 수정해야지" 정도로 끝낼 수 있지만, 팀 리더로서는 먼저 "왜 이런 불일치가 생겼나" 를 물어야 한다는 것. 요구사항이 명확하지 않았다면, 아니면 당시에 "홈은 자주 안 바뀌니까" 하는 가정이 있었다면, 그걸 먼저 풀어야 다음 비슷한 상황을 예방할 수 있다.

또 하나는 메타 데이터 관리의 중앙화의 중요성이다. 여러 곳에서 따로 관리되는 제목, 설명, 이미지 같은 것들을 하나의 CMS 데이터 스키마로 정리해두면, 운영팀의 부담도 줄어들고, 개발자가 신경 쓸 일도 줄어든다. Base.astro 처럼 레이아웃 한 지점에서 관리하면, 다음에 "og:image도 CMS에서 관리하도록 해달라" 같은 요청이 들어왔을 때 대응이 훨씬 수월하다.

사실 이런 "작은 버그"들이 누적되면 팀 간 신뢰도 떨어지고, 운영 프로세스도 꼬인다. 그래서 이번처럼 "왜 하드코딩이 남아있었나" 부터 시작해서, "앞으로 비슷한 메타 데이터는 어떻게 관리할 건가"까지 함께 생각하는 게 중요하다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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