스페이싱 스케일 생성기: --space-* 토큰과 유틸 클래스로 간격 규칙을 일관되게 만드는 방법

스페이싱(spacing)은 UI의 리듬을 결정합니다. 버튼은 예쁜데 화면이 어수선해 보인다면, 대부분 간격 규칙이 흔들리는 경우가 많습니다. 이 페이지의 스페이싱 스케일 도구는 base(px)와 steps를 기반으로 간격 토큰(--space-*)과 간단한 유틸 클래스(p-/m-/gap-)를 자동 생성해 줍니다. 간격을 토큰으로 관리하면 페이지가 늘어나도 일관성이 유지되고, 팀원 간 협업도 쉬워집니다.

스페이싱 규칙이 중요한 이유

간격은 시각적 계층을 만듭니다. 제목과 본문 사이, 카드와 카드 사이, 버튼과 입력창 사이의 간격이 일관되면 화면이 정돈되어 보이고, 사용자는 정보를 더 쉽게 이해합니다. 반대로 간격이 페이지마다 다르면 UI가 산만해지고 “대충 만든 느낌”이 날 수 있습니다.

  • 리듬: 섹션 단위의 반복 패턴을 만들면 읽기 쉬워집니다.
  • 우선순위: 중요한 요소에 더 큰 여백을 주면 자연스럽게 시선이 이동합니다.
  • 반응형: 화면이 바뀌어도 일정한 규칙을 유지하기 쉬워집니다.
  • 협업: 토큰 이름으로 소통하면 “몇 px?” 논쟁이 줄어듭니다.

추천: 간격은 “많은 값”보다 “적은 값의 반복”이 더 강력합니다. 8~16개 정도의 토큰이면 대부분의 UI를 커버할 수 있습니다.

스케일 설계: base와 steps의 의미

base는 간격의 최소 단위를 의미합니다. 흔히 4px 그리드(4, 8, 12, 16…)가 많이 쓰이며, 모바일과 데스크톱 모두에서 무난합니다. steps는 몇 단계까지 확장할지 결정합니다. steps가 너무 적으면 큰 섹션 여백이 부족하고, 너무 많으면 규칙이 복잡해집니다.

  • base 4: 가장 흔한 선택. 세밀한 조정이 가능
  • base 8: 값이 단순해지지만 미세 조정은 어려움
  • steps 12~16: 대부분의 컴포넌트/섹션에 충분
  • 라벨 방식: 숫자(0..n) 또는 참고값(rem 표시)로 팀 스타일에 맞추기

rem 기반 표기를 함께 쓰면 접근성(사용자 글꼴 크기 설정)에 더 유리할 수 있습니다. 다만 팀의 CSS 운영 방식에 맞춰 선택하는 것이 중요합니다.

생성기 사용 방법(권장 흐름)

  1. prefix 설정: space, gap 등 프로젝트 규칙에 맞는 이름을 선택합니다.
  2. base 선택: 4px 또는 8px에서 시작해 제품 톤에 맞춥니다.
  3. steps 설정: 섹션 여백까지 커버할 만큼 충분히 둡니다.
  4. 라벨 방식: 숫자/참고값 중 협업하기 쉬운 방식을 선택합니다.
  5. 출력 확인: 변수 + 유틸이 실제로 원하는 범위를 커버하는지 검증합니다.
  6. 복사/저장: 결과를 복사하고 프리셋으로 저장해 반복 사용합니다.

스페이싱을 정했다면, 카드/패널 UI의 보더/섀도우와 조합해 화면의 톤을 완성할 수 있습니다. 보더/라디우스, 섀도우를 함께 참고하면 더 자연스럽습니다.

토큰 vs 유틸 클래스: 운영 방식

토큰 방식은 CSS 변수로 의미를 정의하고, 컴포넌트 CSS에서 이를 참조합니다. 유틸 방식은 클래스 조합으로 빠르게 적용합니다. 어느 쪽이든 “규칙을 고정”하는 것이 핵심입니다.

  • 토큰 장점: 디자인 시스템과 궁합이 좋고, 재매핑(테마/리브랜딩)이 쉬움
  • 유틸 장점: 빠른 프로토타이핑과 단순 페이지에 유리
  • 혼합: 토큰을 만들고 유틸은 제한적으로 제공하는 방식도 많이 씁니다
  • 문서화: 어떤 토큰이 어떤 간격을 의미하는지 간단한 규칙을 남기면 좋음

팀에 따라 “유틸을 금지”하거나 “유틸을 적극 사용”하는 문화가 다르므로, 생성기의 출력 중 필요한 부분만 선택해 사용하면 됩니다.

레이아웃과의 연결(container/grid/flex)

간격은 레이아웃 시스템과 연결됩니다. 컨테이너 폭이 바뀌면 섹션 패딩도 달라지고, 그리드의 gap도 달라집니다. 따라서 스페이싱 토큰을 정한 뒤에는 주요 레이아웃 요소를 함께 맞추는 것이 좋습니다.

이렇게 연결하면 “여백이 예쁜 UI”가 자동으로 만들어지고, 페이지가 늘어나도 품질이 유지됩니다.

자주 묻는 질문(FAQ)

  • Q. base는 4가 좋나요 8이 좋나요? A. 대부분의 UI는 4가 유연합니다. 단순한 프로젝트나 큰 컴포넌트 위주면 8도 선택지입니다.
  • Q. steps를 많이 두면 더 좋나요? A. 너무 많으면 규칙이 복잡해집니다. 12~16 정도면 대부분 충분합니다.
  • Q. 유틸 클래스가 오히려 지저분해 보여요. A. 유틸은 제한된 범위에서만 쓰거나, 토큰 중심으로 운영해 필요할 때만 유틸을 쓰는 혼합 방식이 좋습니다.
알림