모달·스켈레톤·광고 사이즈를 한 번에 다듬은 이유

프론트 디자인 디테일이 쌓이는 시점마다 반드시 마주치는 작업이 있다. 모달, 스켈레톤, 광고 컨테이너 — 따로 보면 사소해 보이지만 한꺼번에 터지면 생각보다 손이 많이 간다.

왜 이 세 가지가 한 커밋에 묶였나

Base.astro와 [slug]/index.astro 두 파일만 바뀌었다. 레이아웃 레벨과 페이지 레벨이 동시에 수정됐다는 건, 변경 범위가 단일 컴포넌트에 국한되지 않았다는 의미다. 모달 디자인 수정은 레이아웃 전역에 영향을 주고, 스켈레톤 플레이스홀더는 콘텐츠 페이지([slug]) 로딩 UX에 직접 박혀 있고, 광고 사이즈 정리는 두 레이어 모두에 걸쳐 있을 가능성이 높다.

팀에서 이런 작업을 하나의 커밋으로 묶는 결정을 내릴 때 나는 보통 "같이 배포되지 않으면 의미가 없는 변경들인가"를 기준으로 판단한다. 모달 디자인만 나가고 스켈레톤이 없으면 로딩 구간이 더 어색해 보일 수 있고, 광고 사이즈가 안 맞으면 레이아웃이 깨진 채로 유저한테 노출된다. 세 가지가 하나의 시각적 완성 단위였던 셈이다.

각 작업이 실제로 어떤 의미였나

모달 디자인 수정

Base.astro에 전역 모달이 있다는 건, 이 서비스에서 모달이 여러 페이지에 걸쳐 재사용되는 구조라는 뜻이다. 레이아웃 레벨에 박힌 모달은 손대기 까다롭다. 수정 하나가 모든 페이지에 파급되기 때문에, 디자인 변경이라도 회귀 체크를 꼼꼼히 해야 한다.

일반적으로 전역 모달에서 디자인을 손볼 때 가장 자주 건드리는 부분은 아래 정도다.

/* before */
.modal-overlay {
  background: rgba(0, 0, 0, 0.4);
  border-radius: 8px;
}

/* after */
.modal-overlay {
  background: rgba(0, 0, 0, 0.6);
  border-radius: 12px;
  backdrop-filter: blur(4px);
}

수치 하나가 바뀌어도 모바일/데스크톱 양쪽에서 체크해야 하고, 포커스 트랩이나 스크롤 락 같은 접근성 동작이 깨지지 않는지도 봐야 한다. 디자인 픽스처럼 보여도 실제로는 테스트 포인트가 꽤 된다.

스켈레톤 플레이스홀더

[slug]/index.astro에 스켈레톤이 들어갔다는 건, 슬러그 기반 동적 페이지의 초기 로딩 경험을 개선하겠다는 의도다. 콘텐츠가 비동기로 채워지는 구조에서 스켈레톤 없이 빈 화면이나 스피너만 있으면 유저 체감 속도가 훨씬 느리게 느껴진다.

스켈레톤의 핵심은 실제 콘텐츠의 레이아웃을 최대한 닮아야 한다는 것이다. 폭/높이가 실제와 다르면 콘텐츠가 들어올 때 레이아웃 시프트가 발생하고, CLS(Cumulative Layout Shift) 수치가 올라간다.

<!-- 스켈레톤 예시 패턴 -->
{isLoading ? (
  <div class="skeleton-wrapper">
    <div class="skeleton title" />
    <div class="skeleton body" />
    <div class="skeleton body short" />
  </div>
) : (
  <ArticleContent data={content} />
)}

팀에서 스켈레톤을 처음 도입할 때 항상 나오는 논의가 "실제 컴포넌트 높이를 하드코딩할 거냐, 동적으로 맞출 거냐"다. 하드코딩은 빠르지만 콘텐츠 길이가 다양하면 시프트를 완전히 막기 어렵다. 이건 트레이드오프를 팀이 인식하고 선택하는 게 중요하다.

광고 사이즈 정리

광고 영역은 생각보다 자주 레이아웃을 오염시키는 원인이다. 광고 스크립트가 반환하는 실제 배너 사이즈와 컨테이너에 지정된 사이즈가 다를 때, 혹은 반응형 분기점에서 예약된 사이즈 바깥으로 광고가 튀어나올 때 레이아웃이 틀어진다.

광고 사이즈 "정리"라는 표현에서 알 수 있듯, 이건 새로 추가보다 기존에 제각각이던 것들을 하나의 기준으로 맞추는 작업이었을 가능성이 높다. 이런 정리 작업은 나중에 광고 슬롯을 추가하거나 교체할 때 기준 없이 흩어진 코드를 만나지 않게 해주는 기반 작업이기도 하다.

회고

레이아웃 + 페이지 두 파일만 건드렸지만, 실제로는 모달 전역 동작 / 동적 페이지 UX / 광고 안정성 세 개의 독립적인 관심사를 한 번에 처리했다. 작업 범위 대비 파일 수가 적다는 건 잘 추상화된 구조에서 일어나는 일이기도 하고, 반대로 레이아웃 파일 한 곳에 너무 많은 책임이 집중돼 있다는 신호일 수도 있다.

Base.astro가 모달도 들고 광고 컨테이너 기본 구조도 들고 있다면, 향후 이 파일의 변경 빈도가 높아질수록 충돌 포인트도 늘어난다. 팀 규모가 커질수록 레이아웃 파일을 쪼개거나 슬롯 방식으로 위임하는 구조를 검토할 타이밍이 온다. 이번 커밋이 그 신호를 보내고 있었는지도 모른다.

다음

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

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

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