멀티 사이트 컴포넌트를 사이트별 독립 정체성으로 전면 분리

멀티 사이트 구조에서 각 사이트가 완전히 다른 정체성을 갖도록 컴포넌트 레벨을 전면 손봤다.

왜 "완전히 다른" 정체성이 필요했나

Header, Footer, PostCard, Base 레이아웃 — 이 네 파일이 동시에 바뀐 걸 보면 맥락이 명확해진다. 하나의 코드베이스 위에서 여러 사이트를 운영하는 구조일 때, 초반에는 보통 "거의 같은 UI에 텍스트/색상만 다르게"로 시작한다. 근데 시간이 지나면서 각 사이트가 독자적인 방향성을 가지기 시작하면, 그 "거의 같음"이 오히려 족쇄가 된다. 사이트 A에 필요한 변경을 가하면 사이트 B가 같이 깨지고, B를 보호하려면 A에 조건 분기가 쌓이고. 그 시점이 "이제 진짜 분리하자"를 결정해야 할 때다.

이번 커밋의 completely distinct 라는 표현이 그 결단을 담고 있다. 미묘하게 다른 게 아니라, 명시적으로 다른 정체성.

변경된 파일들이 각각 의미하는 것

Base 레이아웃이 바뀐 게 포인트다. Base는 보통 건드리기 꺼려지는 파일 — 이게 바뀌면 모든 페이지에 영향을 주기 때문에. 근데 그걸 건드렸다는 건, 사이트 정체성을 "표면(컴포넌트) 레벨"이 아니라 "구조(레이아웃) 레벨"부터 나눴다는 뜻이다. 올바른 순서다.

Astro에서 멀티 사이트 정체성을 다루는 방법

Astro는 이런 상황을 위한 도구가 잘 갖춰져 있다. 내가 실제로 선호하는 패턴은 사이트 식별자를 props나 env로 흘려주는 방식보다, 아예 레이아웃/컴포넌트 파일 자체를 사이트별로 분리하는 것이다.

---
// src/layouts/Base.astro 예시 구조
const { site } = Astro.locals; // 또는 import.meta.env.SITE_ID
---

조건 분기를 컴포넌트 내부에 두는 순간부터 "이 컴포넌트는 두 사이트 중 어느 쪽 규칙을 따르는가"를 머릿속에서 계속 추적해야 한다. 그게 쌓이면 코드리뷰 때 팀원들이 "이 조건 왜 있어요?"를 반복하게 된다. 분리된 파일이 길어도, 명시적인 게 낫다.

src/
  sites/
    site-a/
      Header.astro
      Footer.astro
    site-b/
      Header.astro
      Footer.astro
  components/
    PostCard.astro  ← 공통 로직만

물론 이 커밋에서 어떤 구조를 택했는지는 파일 내용을 봐야 알지만, 네 파일이 함께 바뀐 패턴은 "공통 컴포넌트에서 분기 제거"보다 "각 사이트 전용으로 재정의"에 가까워 보인다.

회고

팀 리딩 관점에서 이런 작업은 타이밍이 전부다. 너무 일찍 분리하면 중복 코드가 늘고 유지보수 비용이 올라가고, 너무 늦게 분리하면 조건 분기 지옥 속에서 리팩터링 비용이 폭증한다. "지금이 맞다"는 판단을 내리는 게 기술적 역량이기도 하다.

PostCard까지 건드린 게 개인적으로 잘한 결정이라고 본다. 헤더/푸터만 분리하고 카드는 공통으로 두면, 결국 카드에도 나중에 사이트별 예외 처리가 생긴다. 콘텐츠의 표현 단위를 처음부터 정체성 레벨에서 다르게 가져가면, 각 사이트가 앞으로 독립적으로 성장할 수 있는 공간이 생긴다.

끝.

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

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

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