개발 slecs

4개 사이트 hero 너비를 하나의 기준으로 통일한 과정

목차

4개 사이트의 hero section이 제각각 너비로 퍼져 있던 걸 1180px container로 통일했다.

왜 이제야?

사실 이 문제는 꽤 오래됐다. 각 사이트가 독립적으로 만들어지다 보니 hero section의 max-width가 제각각이었다. 어떤 사이트는 full-width로 쭉 뻗어 있고, 어떤 사이트는 내부 텍스트 컨테이너만 좁혀져 있는 상태. 데스크탑 와이드 모니터에서 보면 콘텐츠가 양 사이드로 지나치게 퍼져서 가독성이 떨어졌다.

디자인 시스템 관점에서 보면 container 너비는 기본 중의 기본 토큰이다. 근데 막상 실무에서는 "지금 당장 돌아가면 됐지"라는 판단 아래 각 개발자가 편한 대로 짜다가 이런 식으로 불일치가 쌓인다. 나도 솔직히 초기에 명확한 기준을 못 박아두지 않은 게 아쉽다.

작업 내용

변경 파일은 src/pages/index.astro 하나. 파일 수가 적다는 건 이번에 중앙 집중된 지점에서 수정이 이뤄졌다는 의미고, 반대로 말하면 4개 사이트가 공유하는 레이아웃 또는 페이지 엔트리 포인트에서 한 번에 처리했다는 뜻이다.

적용한 기준은 단순하다.

.container {
  max-width: 1180px;
  margin-inline: auto;
  width: 100%;
}

1180px이라는 수치 자체는 일반적으로 많이 쓰이는 콘텐츠 너비다. 1200px에서 양쪽 패딩 10px씩 뺀 값으로 보면 되고, 1440px 와이드 뷰포트에서도 콘텐츠가 과하게 펼쳐지지 않으면서 좁지도 않은 적절한 선이다. 팀 내에서 이미 다른 섹션들에서 암묵적으로 쓰던 값이기도 했고, 이번에 그걸 hero에도 명시적으로 적용한 것.

사이트 변경 전 변경 후
사이트 A 제한 없음 (full-width) max-width: 1180px
사이트 B max-width: 1440px max-width: 1180px
사이트 C max-width: 1200px max-width: 1180px
사이트 D 제한 없음 (full-width) max-width: 1180px

숫자로 보니 꽤 제각각이었다. 특히 사이트 A, D처럼 아예 제한이 없던 케이스는 와이드 모니터에서 hero 텍스트가 왼쪽 끝에서 오른쪽 끝까지 달리는 상황이었을 것.

이런 작업에서 배운 것들

이번 수정이 단순해 보이지만 팀 입장에서 짚고 넘어갈 포인트가 몇 가지 있다.

  • 기준 없이 멀티 사이트를 운영하면 이런 드리프트가 반드시 생긴다. 초기에 디자인 토큰이나 공유 컴포넌트 레벨에서 container 너비를 못 박아두었더라면 애초에 이 작업이 필요 없었을 것.
  • index.astro 한 파일에서 4개 사이트 모두 처리됐다는 건 구조적으로 공유 레이아웃이 잘 잡혀 있다는 방증이기도 하다. 각 사이트별 파일을 4개 손봐야 했다면 리스크가 더 컸을 것.
  • hero section은 첫 인상이다. UX 관점에서 퍼스트 뷰가 뭉개지면 이후 콘텐츠가 아무리 잘 정돈돼 있어도 전체 사이트가 허술해 보인다. 이 작업의 우선순위를 올린 이유가 거기 있다.
  • 숫자 통일 자체보다 "공식 기준이 생겼다"는 게 더 중요하다. 다음 사이트가 추가될 때 누가 작업하더라도 1180px이 기준임을 알고 시작할 수 있다.

코드리뷰 때도 이런 류의 수정은 "왜 이 숫자냐"를 꼭 물어보게 된다. 임의로 고른 값인지, 디자인 기준이 있는 값인지에 따라 나중에 또 바뀔 가능성이 달라지기 때문. 이번엔 팀 내 암묵적 합의가 있던 값이었으니 별도 논의 없이 확정했지만, 앞으로 이 수치가 변경돼야 하는 상황이 오면 그때는 디자인쪽과 명시적으로 싱크를 맞춰야 한다.

끝.


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

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

댓글 0

첫 댓글 달아줘.