CSS 토큰을 수집하는 것은 디자인 중심의 변덕이나 미학을 위한 미학이 아닙니다. 이는 시각적 결정을 표준화하고 프런트엔드 운영 비용을 줄이는 것을 목표로 하는 엔지니어링 관행입니다.
이 기사에서는 다음 내용을 다룰 것입니다.
- CSS 토큰과 값 수집의 차이
- 실제 프로젝트에서 나타나는 값의 예
- 수집을 통해 발견할 수 있는 문제
- 감사 과정에서 수집을 자동화하는 이유
CSS 토큰이 실제로 의미하는 것
디자인 토큰은 색상이나 간격 같은 디자인 결정에 이름을 붙인 것입니다. 반복되는 CSS 값을 수집하면 토큰 후보를 찾을 수 있지만, 반복된다는 이유만으로 토큰이 되지는 않습니다. 수집할 값의 예는 다음과 같습니다.
- 색상 (
#0d6efd,rgb(13,110,253)) - 글꼴 크기(
14px,1rem) - 줄 높이
- 간격(
8px,16px,24px) - 모서리 반경
- 그림자, z-index 값 등
전자상거래를 가정한 설명용 예시입니다.
.button-primary {
background: #005bff;
border-radius: 6px;
}
.checkout-button {
background-color: #005bff;
border-radius: 8px;
}
두 버튼의 배경색은 같지만 모서리 반경은 다릅니다. 값을 통합하기 전에 그 차이가 의도된 디자인인지 확인하세요.
토큰 수집으로 밝혀진 일반적인 문제
1. 거짓 다양성
SaaS 감사를 가정한 설명용 예시로 다음 값이 발견되었다고 해 보겠습니다.
- 27가지 독특한 블루 컬러
- 그 중 19개는 1~3개의 RGB 단위로 달랐습니다.
이는 다음과 같은 전형적인 증상입니다.
- Figma에서 수동 복사-붙여넣기;
- 팀 간의 디자인 계약 부재;
- 축적된 기술 부채.
2. 일관된 체계가 없는 간격
관리 인터페이스 예:
margin-bottom: 12px;
margin-bottom: 14px;
margin-bottom: 16px;
margin-bottom: 18px;
문제는 "어떤 간격이 올바른지"가 아닙니다. 진짜 질문은 왜 4개나 있지?.
토큰 수집을 통해 다음을 수행할 수 있습니다.
- 값의 분포를 시각화하기
- 비슷한 값의 그룹을 찾기
- 4포인트 또는 8포인트 그리드 등 적절한 척도 선택하기
3. 타이포그래피의 불일치
또 다른 설명용 예시는 다음 값을 사용하는 기업 포털입니다.
- 11가지 글꼴 크기
- 7개의 줄 높이 값
- 본문 텍스트의 5가지 글꼴 두께
용도별로 묶으면 세 가지 타이포그래피 역할로 정리될 수 있습니다. 나머지 값을 합치기 전에 실제 쓰임을 확인하세요.
CSS 토큰 수집이 기술적으로 작동하는 방식
기계적 수준에서 프로세스는 간단합니다.
- 페이지를 로드합니다.
- 모든 CSS(인라인 및 외부)를 수집합니다.
- 선언을 구문 분석합니다.
- 카테고리별로 값 집계:
- 색상
- 글꼴 크기
- 간격
- 모서리 반경
- 빈도를 계산합니다.
JSON 출력 예시:
{
"colors": {
"#005bff": 143,
"#ffffff": 98,
"#f5f7fa": 34
},
"spacing": {
"8px": 76,
"16px": 112,
"24px": 41
}
}
이 집계는 조사의 근거가 됩니다. 빈도만으로 값의 의미나 변경 우선순위가 결정되지는 않습니다.
수동 접근 방식이 확장되지 않는 이유
초기에는 팀이 규칙을 말로 공유할 수 있습니다. 하지만 다음과 같은 상황에서는
- 5명 이상의 개발자;
- 병렬 기능 분기;
- 다양한 디자인 소스;
구두 합의만 유지하기 어려워집니다.
값 수집을 자동화하지 않으면 다음과 같은 어려움이 생깁니다.
- 현실에 대한 믿을 만한 스냅샷이 부족합니다.
- 리팩토링의 영향을 측정할 수 없습니다.
- 회귀에 대한 통제력을 상실합니다.
설명용 시나리오: 개발을 멈추지 않고 스타일 정리하기
약 120페이지의 마케팅 사이트를 가정합니다. 아래 수치는 가능한 이전 과정을 설명하는 예이며, 검증된 고객 성과나 예측이 아닙니다.
이전:
- 4,000개 이상의 CSS 규칙
- 32색
- 19가지 글꼴 크기
취한 조치:
- 주요 페이지에서 값을 수집합니다.
- 빈도순으로 정렬합니다.
- 핵심 토큰을 정의합니다.
- 전체를 다시 작성하지 않고 점진적으로 이전합니다.
이후:
- 기본 색상 9개
- 타이포그래피 토큰 6개
- CSS 크기 18% 감소
- A/B 테스트 중 시각적 회귀 감소
성능 향상이 이루어지는 곳
CSS 토큰은 단지 디자인에 관한 것이 아닙니다.
- 중복 선언을 합치면 CSS가 작아질 수 있음
- 값을 공유하면 유지보수가 쉬워짐
- 규칙을 정리하면 캐스케이드 충돌이 줄어들 수 있음
- gzip/Brotli, 코드 커버리지, 핵심 CSS에 미치는 효과는 측정이 필요함
토큰 수집 자체가 페이지를 빠르게 만들지는 않습니다. 실제 코드 변경 뒤 전송량과 로딩 시간을 비교하세요.
이것을 감사 문제로 취급하는 이유
milten.io에서 CSS 토큰 수집은 다음과 같습니다.
- 진단, "예쁜 보고서" 생성기가 아닙니다.
- 부재해 보이는 구조를 노출시키는 방법;
- 표준화, 디자인 시스템 및 확장 가능한 프런트엔드 아키텍처의 진입점입니다.
토큰 후보를 정리하기 어렵다면 디자인 규칙과 예외를 살펴보세요. 그 사실만으로 디자인 시스템이 없다고 판단할 수는 없습니다.
요약
관리 로직으로 축소:
- 토큰이 없는 CSS = 관리되지 않는 자산
- 토큰 수집 = 인벤토리
- 빈도 = 우선순위
- 자동화 = 확장성
이것을 무시할 수 있습니다. 그러나 모든 재설계는 다음과 같이 시작됩니다. "스타일을 조심스럽게 조정하자" — 또 다른 혼란의 층으로 끝나게 됩니다.
프로젝트에서 실제로 쓰이는 값을 수집하고, 근거 있는 변경을 선택한 뒤 효과를 측정하세요.
