디자인 시스템, 변수부터 제대로 잡아야 하는 이유

변수는 컴포넌트와 화면이 올라가는 가장 아래층입니다.

 

 

프로젝트를 하다 보면 이런 장면을 자주 만나게 됩니다. 디자이너는 시안에 "메인 파란색"이라고 적어 두었는데, 개발자는 코드에서 #3366FF를 쓰고, 다른 화면에서는 누군가 #3465FE를 넣어 둡니다. 눈으로 보면 거의 같은 색이지만, 이런 작은 차이가 쌓이면 QA 기간마다 "이 버튼 색이 왜 달라요?"라는 이슈가 수십 개씩 올라오게 되죠.

 

이 문제를 근본적으로 줄여 주는 도구가 바로 변수(Variables)입니다. 피그마에서는 "변수", 개발 쪽에서는 보통 "토큰(Token)"이라고 부르지만 가리키는 대상은 같습니다. 색상, 간격, 글자 크기처럼 반복해서 쓰이는 값에 이름을 붙여 한곳에서 관리하는 방식입니다. 디자이너와 개발자가 같은 이름을 쓰기 시작하면 소통이 빨라지고, 구현이 쉬워지고, 화면 전체의 일관성이 자연스럽게 유지됩니다.

 

변수는 어떤 종류로 나누면 좋을까

처음 변수를 만들 때 가장 막막한 부분이 "무엇을, 어떻게 묶을까"입니다. 정답이 하나로 정해져 있지는 않지만, 대부분의 서비스는 아래 여섯 가지 묶음으로 시작하면 충분합니다.

 

 

 

하나씩 살펴보겠습니다.

 

1. 색상: 브랜드 색과 UI 색을 나눠서

색상 변수는 크게 두 층으로 나누는 것이 좋습니다. 첫 번째는 브랜드 색상입니다. 파랑 50부터 파랑 900까지처럼, 회사가 가진 모든 색을 밝기 단계별로 쭉 나열해 둔 팔레트죠. 여기에는 "어디에 쓰는지"가 아니라 "어떤 색인지"만 담깁니다.

 

두 번째는 UI 색상입니다. 브랜드 팔레트의 색을 가져와서 "어디에 쓰는 색인지"를 이름에 담습니다. 보통 사용처를 기준으로 배경, 텍스트, 선, 아이콘으로 나누고, 그 안에서 다시 역할별로 주요(primary), 보조(secondary), 오류(error), 성공(success)을 둡니다. 예를 들어 text-error는 "입력값을 확인해 주세요" 같은 안내 문구에, bg-success는 "결제가 완료되었습니다" 토스트 배경에 쓰는 식입니다.

 

 

 

클릭할 수 있는 요소라면 한 가지를 더 챙겨야 합니다. 바로 상태입니다. 버튼 하나에도 기본, 마우스를 올렸을 때, 누르고 있을 때, 비활성일 때의 색이 모두 다르죠. 이 상태들은 변수 이름을 따로 늘리기보다 피그마의 모드(Mode) 기능으로 묶어 두면 관리가 훨씬 편합니다. 같은 bg-primary라도 모드만 바꾸면 상태에 맞는 색이 자동으로 들어갑니다. 요즘 많이 요청받는 다크 모드도 같은 원리로 대응할 수 있습니다.

 

 

2. 선 두께: 단순할수록 좋다

선 두께는 생각보다 많이 필요하지 않습니다. 보조 버튼의 테두리, 목록 사이 구분선처럼 대부분 한 가지 두께로 해결되니까요. line-1 하나만 두고 시작해도 충분합니다.

 

다만 아이콘을 직접 그리는 팀이라면 선택적으로 아이콘용 두께를 추가해 볼 만합니다. 작은 12px 아이콘과 큰 24px 아이콘에 같은 선 두께를 쓰면 작은 아이콘이 유난히 굵어 보이거든요. icon-stroke-12, icon-stroke-24처럼 크기별로 두께를 정해 두면 아이콘끼리 시각적 무게가 고르게 맞춰집니다.

 

 

3. 간격: 개발자가 쓰는 개념 그대로

간격 변수는 개발 코드의 개념을 그대로 따라가는 것이 핵심입니다. CSS에는 간격이 세 종류 있습니다.

 

Gap은 한 컨테이너 안에 있는 요소들 사이의 간격입니다. 상품 카드 목록에서 카드와 카드 사이 거리가 대표적이죠.

Padding은 요소 안쪽의 여백으로, 버튼 글자와 테두리 사이의 공간을 떠올리면 됩니다.

Margin은 요소 바깥쪽 여백인데, 이건 가끔만 씁니다. 예를 들어 관리자 화면의 게시판 목록 아래에 "전체 목록 엑셀로 받기" 버튼을 다른 버튼들과 조금 떨어뜨려 두고 싶을 때처럼, 특별히 구분이 필요한 경우에만 사용하는 것이 좋습니다. 피그마의 오토 레이아웃은 margin 개념과 잘 맞지 않아서, 남발하면 반응형 대응이 어려워지기 때문입니다.

 

이름은 서비스 성격에 맞춰 정하면 됩니다. 모바일 앱만 만든다면 gap-8, padding-16처럼 실제 픽셀 값을 이름에 넣는 방식이 직관적입니다. 반대로 PC와 모바일을 모두 지원해서 화면 크기마다 값이 달라진다면 gap-small, gap-medium처럼 크기 단계로 이름을 짓고, 기기별 모드에 실제 값을 연결하는 편이 유연합니다. 참고로 국내 실무에서는 4의 배수(4, 8, 12, 16, 24, 32…)로 간격 단계를 맞추는 경우가 많은데, 처음 시작할 때 기준으로 삼기 좋습니다.

 

 

4. 텍스트: 스타일을 이루는 재료들

텍스트는 여러 속성이 모여 하나의 스타일이 됩니다. 그래서 스타일 전체를 변수로 만들기보다, 스타일을 이루는 재료를 각각 변수로 만들어 두는 방식이 좋습니다.

 

기본적으로 필요한 재료는 글꼴(font-family), 크기(font-size), 굵기(font-weight), 줄 높이(line-height), 자간(letter-spacing)입니다. 실무에서는 Pretendard나 Noto Sans KR처럼 한글 가독성이 좋은 글꼴을 쓰는 경우가 많고, 한글은 영문보다 글자가 빽빽해 보이기 쉬워서 자간을 살짝 좁히고 줄 높이는 넉넉하게 주는 편입니다.

 

크기에 이름을 붙일 때는 heading-1, body, caption처럼 역할로 부르거나 size-16처럼 값으로 부를 수 있습니다. 앞의 간격과 마찬가지로, 화면 크기에 따라 값이 바뀐다면 역할 기반 이름이 더 유리합니다. PC에서는 제목이 36px인데 모바일에서는 24px로 줄어드는 경우, heading-2 하나에 기기별 값을 모드로 연결하면 끝이니까요.

 

 

5. 모서리 둥글기: 크기별로 몇 단계만

모서리 둥글기(radius)는 3~5단계 정도면 충분합니다. 태그나 뱃지처럼 작은 요소에는 radius-small, 버튼과 입력창에는 radius-medium, 카드와 팝업에는 radius-large, 완전히 둥근 알약 모양 버튼에는 radius-full을 쓰는 식입니다. 단계를 너무 잘게 나누면 결국 아무도 기준을 지키지 않게 되니, 적게 시작해서 꼭 필요할 때만 늘리는 것이 좋습니다.

 

 

6. 애니메이션: 속도와 움직임도 규칙으로

의외로 많은 팀이 놓치는 부분이 애니메이션입니다. 바텀시트가 올라오는 속도, 토스트가 사라지는 속도가 화면마다 제각각이면 서비스 전체가 어수선하게 느껴집니다. 그래서 움직임도 변수로 정해 두면 좋습니다.

 

 

기본은 두 가지입니다. 지속 시간(duration)은 duration-fast(100ms), duration-normal(200ms), duration-slow(400ms)처럼 세 단계 정도로 나누고, 가속 곡선(easing)은 ease-out, ease-in, ease-in-out 정도를 준비해 둡니다. 작은 요소일수록 빠르게, 화면을 크게 덮는 요소일수록 느리게 움직이는 것이 자연스럽습니다. 개발자와 "바텀시트는 slow에 ease-out"처럼 짧게 합의할 수 있어서, 기획서나 디자인 가이드에 애니메이션을 설명하는 수고도 크게 줄어듭니다.

 

 

한눈에 정리하기

색상은 브랜드 팔레트와 사용처별 UI 색상으로 나누고, 클릭 요소의 상태는 모드로 관리합니다. 선 두께는 한 가지로 시작하고, 필요하면 아이콘용 두께를 추가합니다. 간격은 gap, padding, margin으로 나누되 margin은 최소한으로 씁니다. 텍스트는 글꼴, 크기, 굵기, 줄 높이, 자간을 각각 변수로 만들어 조합합니다. 모서리는 몇 단계만 두고, 애니메이션은 지속 시간과 가속 곡선을 정해 둡니다.

 

처음부터 완벽한 변수 체계를 만들 필요는 없습니다. 오히려 지금 서비스에서 가장 자주 어긋나는 값, 예를 들어 버튼 색이나 카드 간격부터 변수로 묶어 보는 것이 현실적인 출발점입니다. 무엇보다 중요한 건 디자이너와 개발자가 같은 이름으로 같은 값을 부르는 것입니다. 다음 스프린트 회의에서 개발팀과 함께 변수 이름 목록을 한 번 맞춰 보는 것부터 시작해 보세요. 그 작은 합의가 QA 이슈를 줄이고, 디자인 시스템을 오래 살아 있게 만드는 가장 확실한 방법입니다.

 

 

출처:

https://medium.com/design-systems-collective/design-system-best-practices-variables-d8e4c351a430