기획자도 바로 쓰는 Variants: 버튼 상태 관리가 쉬워지는 3가지 규칙
기획자도 바로 쓰는 Variants
: 버튼 상태 관리가 쉬워지는 3가지 규칙
서론
컴포넌트까지 만들었는데, 버튼 관리가 아직도 힘들다면 이유는 보통 하나입니다.
화면마다 “살짝 다른 버튼”이 계속 생기기 때문이죠. 기본/비활성/로딩… 거기에 Primary/Secondary까지 섞이면,
버튼이 어느새 20~30종이 되어버립니다. (복붙이 번식하는 속도는 대체로 토끼급입니다 🐇)
이때 필요한 기능이 Figma Variants입니다.
Variants는 “같은 컴포넌트의 여러 버전(상태/크기/타입)”을 한 세트로 묶어
선택만으로 바꾸게 만드는 방법입니다.
다만 Variants는 아무 기준 없이 늘리면 오히려 더 꼬입니다. 그래서 오늘은 Type / Size / State라는 “3가지 축(규칙)”으로 버튼 Variants를 깔끔하게 설계하는 방법을 정리합니다.
.png "기획자도 바로 쓰는 Variants, 출처 : AI 생성")
📚 목차
본론
1) Figma Variants가 정확히 뭐예요?
Variants는 하나의 컴포넌트 세트 안에
“서로 다른 버전”을 묶어서 관리하는 기능입니다.
예를 들어 버튼 컴포넌트가 있을 때,
Primary/Secondary, S/M/L, Default/Disabled/Loading 같은 변형을
한 컴포넌트의 옵션처럼 선택하게 만들 수 있습니다.
결과적으로 화면에서는 “버튼 A를 버튼 B로 교체”하는 게 아니라, 같은 버튼에서 옵션만 바꾸는 방식으로 관리가 됩니다.
2) 왜 Variants가 꼬일까? (원인 3가지)
-
축(규칙) 없이 Variants를 늘림
→ “빨간 버튼”, “큰 버튼”, “비활성 버튼”처럼 기준이 뒤섞이면 관리가 폭발합니다. -
상태(State)와 타입(Type)을 혼합
→ Disabled(상태)와 Secondary(타입)을 같은 레벨로 섞으면 네이밍/선택이 꼬입니다. -
오버라이드(Override)를 남발
→ 반복되는 예외는 Variants로 흡수해야 일관성이 유지됩니다.
3) 규칙 1) Type: 버튼의 ‘위계/용도’를 정한다
Type은 버튼이 “어떤 역할인지(중요도/위계)”를 뜻합니다. 기획서 화면에서 가장 많이 쓰는 조합은 아래 3개면 충분한 경우가 많습니다.
- Primary: 주요 액션(가입, 결제, 저장)
- Secondary: 보조 액션(취소, 뒤로, 상세보기)
- Danger: 파괴적 액션(삭제, 해지)
포인트는 “색상”이 아니라 역할로 분리하는 것입니다. Primary가 파란색이든 검정이든, 역할이 Primary면 동일 타입으로 묶습니다.
4) 규칙 2) Size: 버튼의 ‘규격’을 고정한다
Size는 버튼의 높이/패딩/폰트를 포함한 “규격”입니다. 여기서 규칙이 흔들리면, 화면마다 버튼이 미묘하게 달라져서 검수 난이도가 올라갑니다.
- S: 좁은 영역(툴바, 카드 내부)
- M: 기본 버튼(대부분의 화면)
- L: 강조 버튼(온보딩, CTA 영역)
(S는 32, M은 40, L은 48처럼 팀 기준을 잡아두면 깔끔합니다.)
5) 규칙 3) State: 버튼의 ‘상황’을 관리한다
State는 버튼이 현재 어떤 상태인지(사용 가능/동작 중/비활성 등)를 뜻합니다. 상태는 “인터랙션/사용 가능 여부”에만 집중하는 게 가장 단순합니다.
- Default: 기본
- Disabled: 비활성
- Loading: 처리 중
- Hover / Pressed: 웹 UI에서 필요하면 추가(선택)
포인트는 상태를 “색상 이름”으로 만들지 않는 것입니다.
예: Gray는 상태가 아니라 스타일 표현이라, State에 넣으면 관리가 복잡해집니다.
6) 실전 세팅: Type/Size/State로 Variants 만들기
아래는 가장 추천하는 “기본 세트”입니다. 이 3축만으로도 대부분의 버튼 변형을 커버할 수 있습니다.
| 속성(Property) | 값(Values) 예시 | 의미 |
|---|---|---|
| Type | Primary / Secondary / Danger | 버튼의 위계/용도 |
| Size | S / M / L | 규격(높이/패딩/폰트) |
| State | Default / Disabled / Loading | 상황(기본/비활성/처리중) |
6-1. 만들기 순서(실무에서 안 꼬이는 방식)
- 버튼 “기본형”을 먼저 만든다 (Auto Layout으로 패딩/정렬 고정)
- Type별(Primary/Secondary/Danger)로 스타일만 바꾼 버전을 만든다
- 각 Type에서 Size(S/M/L) 규격을 고정한다
- 마지막으로 State(Default/Disabled/Loading)를 추가한다
7) 네이밍 템플릿(검색 잘 되는 구조)
컴포넌트 이름이 정리되어 있어야 Variants가 늘어도 찾기 쉽습니다. 아래 템플릿을 추천합니다.
- 컴포넌트 이름:
Button/Base또는Button - Variants 속성:
Type,Size,State
예시(인스턴스에서 선택되는 조합):
- Type=Primary, Size=M, State=Default
- Type=Primary, Size=M, State=Disabled
- Type=Secondary, Size=S, State=Default
- Type=Danger, Size=L, State=Loading
8) 초보가 자주 하는 실수 7가지(해결 포함)
-
Type/Size/State가 아닌 항목을 속성으로 추가
→ 먼저 3축으로 커버 가능한지 확인하고, 정말 필요할 때만 확장하세요. -
State에 색상/스타일 이름을 넣음
→ State는 “상황”만. 스타일은 Type에서 관리하세요. -
Size 규격이 화면마다 달라짐
→ S/M/L 기준(높이/패딩/폰트)을 고정하세요. -
오버라이드를 반복적으로 사용
→ 반복되는 예외는 Variants로 흡수해야 관리가 쉬워집니다. -
조합을 너무 많이 한 번에 만들다가 포기
→ 처음엔 Type 2개(Primary/Secondary) + Size 2개(S/M) + State 2개(Default/Disabled)부터 시작해도 충분합니다. -
로딩(Loading) 상태에서 텍스트/아이콘 정렬이 깨짐
→ Auto Layout 정렬/간격을 먼저 안정화하고 로딩 인디케이터를 추가하세요. -
Hover/Pressed를 모바일에도 억지로 적용
→ 플랫폼별로 State를 최소화하면 더 깔끔합니다(모바일은 Default/Disabled/Loading 위주).
결론
Variants는 “버튼을 많이 만드는 기술”이 아니라, 버튼이 늘어나도 관리가 쉬운 구조를 만드는 기술입니다. 그 구조의 핵심이 바로 Type / Size / State 3가지 규칙입니다.
이 3축으로 설계하면, 화면에서 버튼을 바꾸는 일이 “새로 만들기”가 아니라 “선택해서 변경”이 됩니다. 결과적으로 반복 수정 시간과 검수 비용이 확 줄어듭니다.
다음 편에서는 이 규칙을 버튼에서 더 확장해, 입력 폼(텍스트 필드)이나 카드에도 Variants를 적용하는 방법을 다루면 기획서 시안 전체가 훨씬 단단해집니다.
FAQ
Q Variants는 컴포넌트랑 뭐가 다른가요?
A 컴포넌트는 “원본과 재사용”의 개념이고, Variants는 “그 컴포넌트의 여러 버전을 한 세트로 묶는 방식”입니다. 즉, 컴포넌트의 확장 기능이라고 이해하면 쉽습니다.
Q Type/Size/State 말고 더 추가해도 되나요?
A 가능합니다. 다만 속성이 늘수록 조합이 폭발적으로 증가합니다. 먼저 3축으로 대부분을 커버하고, 정말 반복되는 예외가 생길 때만 확장하는 걸 추천합니다.
Q Hover/Pressed 같은 상태는 꼭 만들어야 하나요?
A 웹 UI에서 필요할 때만 추가하면 됩니다. 모바일 중심이라면 Default/Disabled/Loading만으로도 실무에 충분한 경우가 많습니다.
Q Variants가 자꾸 꼬일 때 가장 먼저 확인할 건 뭔가요?
A 속성(Property)이 “역할(Type) / 규격(Size) / 상황(State)”으로 분리되어 있는지 먼저 확인하세요. 대부분의 꼬임은 이 축이 섞여서 발생합니다.