기획자용 버튼+칩+탭을 Variants로 한 번에 만들 수 있는 방법을 알려 드립니다.

기획자용 Figma UI 세트 만들기
: 버튼+칩+탭을 Variants로 한 번에

서론

Variants를 배웠다면, 이제는 “버튼만 잘 만드는 단계”를 넘어 기획서 시안에서 자주 쓰는 UI 세트를 한 번에 묶어두는 게 진짜 효율입니다.
화면마다 버튼·필터칩·탭을 매번 새로 만들면, 요구사항 변경이 올 때마다 수정이 퍼져서 시간이 새요.

이번 글에서는 버튼 → 칩(필터) → 탭 순서로 실무에서 바로 재사용 가능한 UI 세트를 만들고, Variants를 꼬이지 않게 설계하는 방법까지 정리합니다.

오늘의 목표: 버튼/칩/탭을 컴포넌트로 만들고, Variants로 상태/타입/크기를 “선택만으로” 바꾸는 구조를 완성한다.

본론

작업 준비: UI 세트 설계 원칙(꼬이지 않는 규칙)

UI 세트는 “예쁘게 만드는 것”보다 관리하기 쉽게 만드는 것이 더 중요합니다. 아래 원칙만 지키면 Variants가 급격히 덜 꼬입니다.

속성(Property)을 2~3개로 제한: 속성이 늘면 조합이 폭발합니다.
역할 분리: Type(용도) / Size(규격) / State(상황)을 섞지 않습니다.
Auto Layout 먼저: 레이아웃 안정화(패딩/간격) 후 컴포넌트화가 정석입니다.

추천 기본 속성(공통):
Type = Primary / Secondary / (Danger 선택)
Size = S / M / L
State = Default / Disabled / (Loading 선택)

1) 버튼 세트 만들기(Variants 기본 템플릿)

버튼은 UI 세트의 “기준점”입니다. 버튼을 먼저 안정화하면, 칩과 탭도 같은 규칙으로 정리하기 쉬워집니다.

1-1. 버튼 기본형 만들기(Auto Layout)

텍스트 + 배경(프레임)으로 버튼을 만들고 Auto Layout 적용
패딩(Padding)과 간격(Spacing)을 고정
텍스트가 늘어도 깨지지 않게 Hug/Fill을 점검

1-2. Variants 속성 설계

Type: Primary / Secondary / Danger(선택)
Size: S / M / L
State: Default / Disabled / Loading(선택)

1-3. 만들기 순서(꼬이지 않는 순서)

Type(Primary/Secondary) 먼저 만든다
각 Type에서 Size(S/M/L) 규격을 고정한다
마지막에 State(Default/Disabled/Loading)를 추가한다

팁: 처음부터 모든 조합을 만들지 말고
Primary/Secondary + M + Default/Disabled 정도로 시작하면 완주율이 높습니다.

2) 칩(필터) 세트 만들기(선택 상태 관리)

칩(Chip)은 필터/태그 UI에서 자주 등장합니다. 기획서에서는 특히 “필터 선택” 시나리오가 많아서 Selected 상태가 핵심입니다.

2-1. 칩 기본형 구성

텍스트 + (선택) 아이콘을 Auto Layout으로 구성
둥근 모서리 + 패딩을 고정 (작은 UI일수록 패딩 규칙이 중요)

2-2. 칩 Variants 속성(추천)

Type: Filter / Tag (둘 중 하나만 써도 OK)
Size: S / M
State: Default / Selected / Disabled

칩은 버튼과 달리 Selected가 자주 쓰이기 때문에, State에 Default/Selected/Disabled를 넣어두면 실전에서 가장 편합니다.

실무 팁: “Selected인데 텍스트가 더 굵다/체크 아이콘이 붙는다” 같은 변화는
State로 해결하고, 오버라이드는 최소화하는 게 관리에 유리합니다.

3) 탭 세트 만들기(활성/비활성 구조)

탭은 “활성 상태가 어디냐”가 본질입니다. 그래서 탭은 State를 단순하게 가져가는 것이 오히려 좋습니다.

3-1. 탭 기본형 구성

탭 텍스트를 Auto Layout으로 감싸고, 패딩/정렬을 고정
하단 인디케이터(밑줄) 또는 배경 강조 스타일을 준비

3-2. 탭 Variants 속성(추천)

Type: Underline / Pill (탭 스타일 2종 중 택1)
Size: M / L
State: Active / Inactive / Disabled

팁: 탭은 한 화면에서 여러 개가 “묶음”으로 쓰입니다.
탭 ‘개별’은 Variants로, 탭 ‘묶음(바)’은 Auto Layout 컨테이너로 관리하면 안정적입니다.

UI 세트 조립 예시: 화면에 붙여 써먹는 방법

이제 화면을 만들 때는 새로 그리는 대신, “세트에서 꺼내 조립”하면 됩니다.

상단: 탭(Active/Inactive) 배치
그 아래: 칩 필터(Selected/Default) 배치
하단/우측: 버튼(Primary/Secondary + Disabled/Loading) 배치

기획자 효율 포인트: 요구사항 변경이 오면 “버튼 타입만 바꾸기”처럼 선택으로 처리할 수 있어
화면 수정 속도가 체감으로 빨라집니다.

네이밍/정리 규칙(검색 잘 되는 구조)

UI 세트는 늘어날수록 “찾기”가 중요해집니다. 아래처럼 슬래시 구조로 통일하면 검색이 쉬워집니다.

Button/Base
Chip/Filter 또는 Chip/Tag
Tab/Underline 또는 Tab/Pill

Variants 속성명은 가급적 통일하세요: Type / Size / State

발행 전 체크리스트(1분 점검)

컴포넌트 원본은 별도 섹션(Components 구역)에 모아두었나?
속성(Property)이 2~3개를 넘지 않나?
State에 색상/스타일 이름이 섞이지 않았나?
Size 규격이 고정되어 있나(S/M/L이 실제로 다르게 보이나)?
오버라이드로 반복 예외를 만들고 있지 않나?
실제 시나리오(Selected/Disabled/Loading)로 한 번 테스트했나?

결론

UI 세트를 Variants로 묶어두면, 기획서 시안을 만들 때 “그리기”보다 “선택”이 많아집니다. 이 차이가 쌓이면 작업 속도와 일관성이 확 달라집니다.

오늘은 버튼 → 칩 → 탭 순서로 UI 세트를 만들며, Variants를 꼬이지 않게 유지하는 규칙과 구조를 정리했습니다.

FAQ

Q UI 세트는 꼭 버튼/칩/탭부터 시작해야 하나요?

A 가장 추천하는 이유는 “어디서나 반복되는 UI”이기 때문입니다. 다만 프로젝트가 폼 중심이라면 Text Field부터 시작해도 좋습니다.

Q 속성(Property)은 왜 2~3개가 적당한가요?

A 속성이 늘면 조합이 기하급수적으로 늘어납니다. 예를 들어 Type 3 × Size 3 × State 3만 해도 27개인데, 여기서 속성 하나만 추가해도 관리 난이도가 확 올라갑니다.

Q 오버라이드를 쓰면 안 되나요?

A “일회성 예외”에는 유용합니다. 하지만 반복되는 예외가 되면 Variants로 흡수하는 편이 일관성과 유지보수에 유리합니다.

Q 탭은 Variants로, 탭 묶음은 Auto Layout로 관리하라는 게 무슨 뜻인가요?

A 탭 ‘하나’의 상태(Active/Inactive)는 Variants가 담당하고, 탭 ‘여러 개를 나열’하는 간격/정렬은 Auto Layout 컨테이너가 담당하면 구조가 단단해지고 수정에도 강해집니다.

이 블로그 검색

AI야, 기획 아이디어 줄래?