SEO와 공유를 먼저 설계한 초기 페이지 구조
목차
프로젝트 초반 페이지 뼈대를 잡으면서, 단순히 "페이지를 하나씩 만들어보자"가 아니라 공유 가능한 구조부터 다졌다. 그룹·멤버·앨범·일정 같은 여러 도메인을 지원하되, 각 페이지가 SNS에서 제대로 카드로 떠야 한다는 판단이 있었기 때문이다.
왜 초부터 SEO와 임베드(Embed)인가
이커머스나 소셜 서비스를 만들다 보면, 사용자가 링크를 공유했을 때 제목·설명·이미지가 제대로 나와야 한다는 게 생각보다 중요하다. 초기에는 "요청 들어오면 그때 고쳐도 되지 않나"라고 생각했지만, 그 결정이 얼마나 비용이 높은지 알게 됐다.
- 데이터와 메타 태그의 동기화 문제: 앨범 정보가 바뀌는데 OG 태그 생성 로직이 따라가지 못하면 캐시 삭제 전략부터 논쟁이 시작됨
- 동적 라우팅 + 정적 생성의 충돌: 페이지를 동적으로 만드는데 검색 엔진 크롤링은 정적 HTML을 원함 (Astro의 SSR vs SSG 선택)
- 레이아웃 일관성: 페이지마다 다르게 구현되면, 나중에 메타 태그 규칙을 바꿀 때 전체 페이지를 뒤져야 함
그래서 처음부터 Base 레이아웃에 SEO와 Embed 컴포넌트를 끼워 넣기로 했다.
초기 아키텍처가 결정한 것들
변경 파일들을 보면, 이 한 커밋이 얼마나 많은 선택을 담고 있는지 느껴진다:
| 파일 | 역할 | 의도 |
|---|---|---|
src/layouts/Base.astro |
모든 페이지가 상속하는 부모 레이아웃 | 헤드 영역과 기본 구조 일관성 보장 |
src/components/Seo.astro |
메타 태그, JSON-LD 생성 | 검색 엔진이 이해할 수 있는 구조화 데이터 |
src/components/Embed.astro |
OG 태그 (Open Graph), 트위터 카드 | SNS 공유 시 썸네일·설명 표시 |
src/lib/db.ts |
데이터 접근 계층 | 페이지에서 직접 SQL 쓰는 걸 방지, 나중에 캐싱/쿼리 최적화 여지 남김 |
src/pages/albums/[slug].astro |
동적 라우팅으로 앨범 상세 페이지 | 각 앨범마다 URL 자동 생성 |
이 파일들이 한 번에 들어간다는 건, "앨범 이 뼈대 위에 계속 붙을 것이다"라는 신뢰가 담겨 있다는 뜻이다.
의사결정: Base 레이아웃을 먼저 다진 이유
팀과 대화할 때 나온 질문이 있었다: "앨범 페이지 먼저 만들고, 필요해지면 Base 를 뽑아내면 안 되나?"
하지만 초기에 그렇게 하면, 나중에 SEO나 메타 구조를 바꾸려 할 때 여러 페이지를 동시에 손져야 한다. 특히 그룹·멤버·일정 같은 다른 도메인이 추가될수록 복잡해진다. 나는 이것을 "기술 부채를 초기에 갚는" 작업이라고 봤다.
<!-- Base.astro 기본 구조 -->
<html>
<head>
<Seo title={title} description={description} image={image} />
<Embed ogTitle={title} ogImage={image} />
</head>
<body>
<slot />
</body>
</html>
이렇게 Base에 Seo와 Embed를 품으면, 앨범·일정·멤버 페이지에서는 각자의 데이터만 맞춰서 넘기면 된다. 일관성도 보장되고, 메타 규칙을 바꿀 때도 한 곳만 수정하면 전체에 반영된다.
db.ts가 해주는 것
src/lib/db.ts를 별도 계층으로 뺀 것도 마찬가지 철학이다. 페이지에서 직접 쿼리를 짜지 않고, 데이터 접근을 함수로 감싸면:
- 캐싱을 나중에 삽입 가능:
getAlbumBySlug(slug)함수에 Redis 한 줄 추가하면 모든 페이지가 자동으로 혜택 - 쿼리 최적화가 쉬움: N+1 문제를 발견했을 때, 함수 안에서만 조인·배칭 로직을 손대면 됨
- 테스트 가능: 모킹이 간편함
회고: 초기 설계의 위험과 안정성
이 커밋을 머지할 때, "페이지가 아직 하나도 렌더링되지 않는데 뼈대에만 시간을 쓰는 건 아닌가" 하는 압박이 있었다. 하지만 지금 생각해보면, 초기에 이 구조를 잡지 않았다면:
- 앨범과 일정 페이지가 각자 다른 방식으로 메타 태그를 생성했을 것
- 나중에 SEO 수정 요청이 들어올 때 여러 페이지를 동시에 건드렸을 것
- db.ts가 없어서 페이지마다 직접 쿼리를 짰을 것 (코드 중복, 보안 위험)
결국 초기 아키텍처 결정이 3개월 후의 개발 속도를 결정한다는 걸 느꼈다. 뼈대가 잘 짜여 있으면, 새 페이지를 추가할 때 "데이터를 넘기면 나머지는 자동"이 된다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.