funeral 섹션 레이아웃이 전역 스타일에 눌리던 문제 해결

스타일 시트 두 군데를 동시에 손댔다. 변경 통계가 미지정이지만 public/styles.css와 styles.css 두 파일 모두 수정된 걸 보면, 빌드 결과물과 소스 원본이 따로 관리되는 구조다. 바꾼 줄 수는 몇 줄 안 됐겠지만 — 전형적인 핀포인트 수정.

배경: "전역 룰이 특정 섹션을 짓누르고 있었다"

site-main에 max-width: 1180px + padding: 24px를 전역으로 박아두는 패턴은 흔하다. 대부분의 페이지에서 콘텐츠 너비를 일정하게 맞추려면 이 룰 하나로 깔끔하게 정리되니까. 근데 문제는 항상 "예외"에서 터진다.

funeral 섹션은 hero 영역 특성상 화면 가득 채우거나, 반대로 좁고 집중된 레이아웃을 의도적으로 쓰는 경우가 많다. 거기에 site-main 전역 룰이 그대로 내려오면 max-width가 hero 자체의 여백 설계를 덮어버린다. 즉, hero 컴포넌트가 자기 padding을 갖고 있어도 부모의 강제 너비에 눌려서 의도한 대로 안 보이는 거다.

/* 수정 전 — site-main 전역 룰이 funeral 에도 그대로 적용 */
.site-main {
  max-width: 1180px;
  padding: 24px;
  margin: 0 auto;
}

/* funeral hero 는 자체 padding 이 있었지만 부모 룰에 덮임 */
.funeral .hero {
  padding: 48px 32px;  /* 사실상 무력화 */
}

/* 수정 후 — funeral 맥락에서만 site-main 룰 해제 */
.funeral .site-main {
  max-width: none;
  padding: 0;
}

/* 이제 hero 자체 padding 이 살아남 */
.funeral .hero {
  padding: 48px 32px;  /* 의도대로 동작 */
}

작업 내용

핀포인트 수정이지만 파일을 두 군데 동시에 고쳐야 한다는 게 좀 걸렸다. 소스 CSS와 public/ 빌드 결과물이 분리돼 있는 구조라면, 이런 수정이 생길 때마다 두 파일 간 싱크 여부를 수동으로 확인해야 한다. 빌드 자동화가 완전히 붙어 있지 않다는 신호일 수 있어서, 팀 내에서 "이 두 파일 중 어디가 source of truth냐"는 질의응답이 자연스럽게 나오게 되는 시점이기도 하다.

회고: 전역 룰과 예외 처리의 트레이드오프

이런 류의 수정이 반복되면 팀 차원에서 짚어야 할 게 생긴다.

• 전역 레이아웃 룰을 얼마나 좁게 정의할 것인가. site-main이 "모든 페이지의 컨테이너"라는 전제로 설계됐다면, 예외 섹션이 생길 때마다 이런 오버라이드 패턴이 쌓인다.
• 컴포넌트가 자기 여백을 책임지는 방향. hero처럼 맥락에 따라 레이아웃이 달라지는 컴포넌트는 부모에 의존하지 않고 자체 padding/max-width를 갖는 게 장기적으로 낫다.
• 빌드 파이프라인 정비. public/styles.css를 수동으로 같이 고쳐야 한다면, 언젠가 한 쪽만 고치고 머지하는 실수가 반드시 나온다. 코드리뷰에서 "두 파일 동시에 수정됐는지" 체크포인트를 추가하거나, 아예 빌드 단계에서 소스만 관리하도록 구조를 바꾸는 게 맞다.

몇 줄짜리 CSS 수정이지만, 이 commit 하나가 "전역 스타일 설계 방식 재검토"로 이어질 수 있다는 걸 팀원들에게 공유해두는 게 포인트였다. 당장 리팩토링까지 가지 않더라도, 이 패턴이 계속 쌓이고 있다는 걸 인식하는 것부터 시작이다.

끝.

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

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

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