Variables와 스타일로 확장 가능한 시스템 만들기

값을 복사하는 파일에서 값을 연결하는 파일로

피그마를 처음 배울 때는 색을 직접 고르고, 숫자를 직접 입력하고, 텍스트 크기를 직접 바꾸는 방식이 자연스럽습니다. 버튼 배경색이 파란색이면 Fill에 파란색을 넣고, 카드 안쪽 여백이 16이면 Padding에 16을 입력합니다. 화면이 한두 개일 때는 이 방식이 빠릅니다. 문제는 화면이 늘어나는 순간부터 시작됩니다.

로그인 화면, 회원가입 화면, 설정 화면, 결제 화면에 같은 파란색 버튼이 있다고 생각해 봅시다. 어느 날 브랜드 컬러가 조금 더 진한 파란색으로 바뀌었습니다. 직접 입력한 값이 30곳에 흩어져 있다면 우리는 30번 찾아가서 수정해야 합니다. 더 무서운 일은 그중 2곳을 놓치는 것입니다. 사용자는 큰 차이를 느끼지 못할 수도 있지만, 팀원은 금방 알아봅니다. '왜 이 버튼만 색이 다르죠?'라는 질문이 시작됩니다.

Variables는 이런 문제를 줄이기 위한 기능입니다. 한국어로 풀어 말하면 '변수'입니다. 어떤 값을 한곳에 저장해 두고, 여러 UI가 그 값을 가져다 쓰게 만드는 방식입니다. 값 자체를 복사하는 것이 아니라, 값이 들어 있는 기준점에 연결하는 것입니다.

Components와 Variants가 반복되는 UI의 모양과 상태를 정리한다면, Variables는 그 UI들이 사용하는 색상, 간격, 반경, 문구 같은 값을 한 단계 더 체계적으로 관리합니다. 컴포넌트가 '반복되는 덩어리'를 재사용하게 해 준다면, Variables는 그 덩어리 안에 들어 있는 '기준 값'을 재사용하게 해 줍니다.

Styles와 Variables는 무엇이 다를까

피그마에는 이미 Styles라는 기능이 있습니다. 텍스트 스타일과 컬러 스타일에서 살펴본 것처럼, Styles는 자주 쓰는 시각 속성을 이름 붙여 저장하는 기능입니다. 예를 들어 Text/Title/24, Text/Body/16, Color/Primary, Shadow/Card처럼 등록해 두면 여러 레이어에서 같은 스타일을 적용할 수 있습니다.

Variables도 값을 저장합니다. 그래서 처음에는 Styles와 Variables가 비슷해 보입니다. 하지만 실무에서는 역할이 조금 다릅니다. Styles는 디자이너가 빠르게 적용하기 좋은 '표현 묶음'에 가깝고, Variables는 화면 곳곳에서 바뀔 수 있는 '기준 값'에 가깝습니다.

조금 더 쉽게 비유해 보겠습니다. Styles가 '완성된 양념장'이라면 Variables는 '소금, 설탕, 간장 같은 재료'입니다. 양념장을 만들어 두면 매번 같은 맛을 내기 쉽습니다. 하지만 재료의 기준을 관리하면 여러 양념장의 맛을 한꺼번에 조절할 수 있습니다.

텍스트를 예로 들어 보겠습니다. 제목의 글꼴, 크기, 굵기, 줄 높이를 한 번에 적용하고 싶다면 Text Style이 편합니다. 반면 버튼 문구를 구매하기에서 예약하기로 바꾸거나, 특정 프로토타입 상황에서 안내 문장을 바꾸고 싶다면 문자열 Variable이 더 어울립니다. 텍스트의 '모양'은 Styles가 잘하고, 텍스트의 '값'은 Variables가 잘하는 셈입니다.

색상도 마찬가지입니다. 예전에는 Primary/Blue 같은 컬러 스타일을 만들어 모든 버튼에 적용했습니다. 이제는 color/action/primary 같은 컬러 Variable을 만들고, 라이트 모드에서는 진한 파란색을, 다크 모드에서는 조금 밝은 파란색을 연결할 수 있습니다. 같은 이름을 쓰지만 모드에 따라 값이 달라지는 구조가 가능해집니다.

💡 팁 박스: Styles와 Variables를 싸우게 만들지 마세요

둘 중 하나만 써야 하는 것은 아닙니다. 실무에서는 함께 쓰는 경우가 많습니다. Text Styles는 제목과 본문 체계를 잡는 데 여전히 좋고, Variables는 색상·간격·반경·문자열처럼 바뀌기 쉬운 값을 관리하는 데 좋습니다. 핵심은 '무엇을 저장할 것인가'입니다. 표현 묶음은 Styles, 변해야 하는 기준 값은 Variables로 생각하면 쉽습니다.

Variables의 네 가지 기본 타입

Variables는 여러 종류의 값을 담을 수 있습니다. 피그마에서 주로 만나는 타입은 색상, 숫자, 문자열, 불리언입니다. 각각의 용도를 이해하면 어떤 값을 변수로 만들어야 할지 판단하기 쉬워집니다.

색상 변수는 Fill, Stroke, 텍스트 색상 등에 연결합니다. 라이트 모드와 다크 모드를 만들 때 가장 많이 사용합니다. 예를 들어 color/bg/surface라는 변수는 라이트 모드에서 흰색 카드 배경이 되고, 다크 모드에서는 어두운 회색 카드 배경이 될 수 있습니다.

숫자 변수는 간격, 패딩, 너비, 높이, 모서리 반경 같은 값에 사용합니다. Auto Layout에서 아이템 사이 간격을 매번 8, 12, 16으로 직접 입력하는 대신 space/2, space/3, space/4 같은 변수를 연결할 수 있습니다. 이렇게 하면 나중에 전체 간격 체계를 조정할 때 훨씬 편합니다.

문자열 변수는 텍스트 레이어의 문구처럼 글자 값을 다룰 때 사용합니다. 예를 들어 온보딩 화면의 제목을 처음 오셨군요로 보여 주다가, 특정 상태에서는 다시 오신 걸 환영해요로 바꾸는 식입니다. 모든 문구를 변수로 만들 필요는 없지만, 프로토타입에서 문구가 바뀌거나 여러 테마에서 카피가 달라지는 경우에는 유용합니다.

불리언 변수는 참 또는 거짓을 담습니다. 쉽게 말해 스위치처럼 켜짐과 꺼짐을 표현합니다. 프로토타입에서 특정 상태를 저장하거나 조건 분기를 만들 때 사용합니다. 예를 들어 isLoggedIn 값이 참이면 홈 화면으로 보내고, 거짓이면 로그인 화면으로 보내는 흐름을 만들 수 있습니다.

중요한 것은 모든 값을 변수로 만들 필요가 없다는 점입니다. 변수는 '반복되고', '바뀔 가능성이 있고', '여러 곳에 영향을 주는' 값일수록 효과가 큽니다. 반대로 한 화면에서 한 번만 쓰는 장식용 값까지 모두 변수로 만들면 관리가 오히려 복잡해집니다.

Collection, Mode, Alias 이해하기

Variables를 제대로 쓰려면 세 가지 개념을 알아야 합니다. Collection, Mode, Alias입니다. 이름은 조금 낯설지만 구조는 어렵지 않습니다.

Collection은 변수들을 담는 큰 서랍입니다. 색상 변수만 모은 서랍, 간격 변수만 모은 서랍, 테마 관련 변수만 모은 서랍처럼 생각하면 됩니다. 예를 들어 Primitive, Theme, Component라는 Collection을 만들 수 있습니다.

Mode는 같은 변수 이름에 여러 값을 담는 방식입니다. 대표적인 예가 라이트 모드와 다크 모드입니다. color/bg/page라는 변수 하나를 만들고, Light Mode에서는 밝은 회색을, Dark Mode에서는 거의 검정에 가까운 회색을 넣을 수 있습니다. 레이어는 여전히 color/bg/page를 바라보고 있지만, 선택된 Mode에 따라 실제 색상이 바뀝니다. 사용할 수 있는 모드 수나 팀 라이브러리 게시 같은 기능은 플랜에 따라 달라질 수 있으므로, 팀 환경에서 가능한 범위를 확인하는 것이 좋습니다.

Alias는 변수가 다른 변수를 참조하는 것입니다. 말로 들으면 복잡하지만, 실무에서는 아주 강력합니다. 예를 들어 color/gray/0은 실제 값 #FFFFFF를 가지고 있고, color/bg/surface는 직접 흰색을 입력하는 대신 color/gray/0을 바라보게 만들 수 있습니다. 이렇게 연결하면 실제 색상 값과 사용 목적을 분리할 수 있습니다.

이 구조를 이해하면 디자인 시스템의 뼈대가 보입니다. 가장 아래에는 실제 색상 값이 있습니다. 그 위에는 배경, 텍스트, 액션처럼 UI에서의 의미가 있습니다. 가장 위에는 버튼, 카드, 탭 같은 컴포넌트별 값이 있습니다.

초보자가 가장 많이 하는 실수는 컴포넌트에 Primitive 값을 바로 연결하는 것입니다. 버튼 배경에 color/blue/600을 직접 연결하면 당장은 문제가 없어 보입니다. 하지만 나중에 주요 액션 색상을 초록색으로 바꾸고 싶다면 이름이 어색해집니다. 버튼은 여전히 blue/600을 보고 있는데 실제 값은 초록색이 될 수 있기 때문입니다.

그래서 실무에서는 버튼에 color/action/primary처럼 의미가 있는 변수를 연결하는 편이 좋습니다. 실제 색상이 파란색인지, 초록색인지, 보라색인지는 그 아래 단계에서 결정합니다. UI는 색상 이름보다 역할을 바라보는 것이 안전합니다.

🧭 팁 박스: 이름에 색을 넣을 때와 넣지 않을 때

팔레트 단계에서는 blue, gray, red처럼 실제 색상 이름을 써도 됩니다. 하지만 UI에 적용하는 단계에서는 primary, surface, danger, success처럼 역할 이름을 쓰는 것이 좋습니다. blue는 색이고, primary는 의미입니다. 화면은 색보다 의미를 오래 유지합니다.

라이트 모드와 다크 모드 컬러 구조 만들기

이제 라이트 모드와 다크 모드를 만들 수 있는 기본 구조를 잡아 보겠습니다. 먼저 Primitive Collection에 실제 색상 값을 준비합니다. 이 단계는 색연필 상자를 만드는 일과 비슷합니다.

그다음 Theme Collection을 만들고 Mode를 Light와 Dark로 나눕니다. 여기에는 실제 색상 이름이 아니라 UI 역할을 담습니다.

여기서 핵심은 직접 색상 값을 넣는 대신 Alias를 사용하는 것입니다. color/bg/surface의 Light 값은 실제 흰색이 아니라 color/gray/0을 바라봅니다. Dark 값은 color/gray/800을 바라봅니다. 이렇게 하면 색상 팔레트와 테마 역할을 분리할 수 있습니다.

이제 카드 배경에 color/bg/surface를 연결해 봅시다. 라이트 모드에서는 흰색 카드가 되고, 다크 모드에서는 어두운 회색 카드가 됩니다. 텍스트에는 color/text/primary를 연결합니다. 그러면 라이트 모드에서는 어두운 글자, 다크 모드에서는 밝은 글자가 자동으로 적용됩니다. 디자이너가 레이어를 하나씩 선택해서 색을 바꾸는 것이 아니라, 구조가 알아서 바뀌는 것입니다.

⚠️ 주의 박스: 다크 모드는 단순히 색을 뒤집는 기능이 아닙니다

라이트 모드의 흰색을 검정으로, 검정 글자를 흰색으로 바꾸면 다크 모드가 완성될 것 같지만 실제로는 그렇지 않습니다. 순수한 검정과 순수한 흰색 조합은 눈이 피곤할 수 있고, 배경과 카드의 깊이도 사라질 수 있습니다. 다크 모드에서는 배경, 카드, 테두리, 보조 텍스트의 대비를 따로 확인해야 합니다.

숫자 Variables로 간격과 반경을 통제하기

색상만 변수로 만들면 절반만 성공한 것입니다. 실제 화면의 완성도는 간격에서 많이 갈립니다. 어떤 카드는 안쪽 여백이 16이고, 어떤 카드는 18이고, 어떤 버튼은 좌우 패딩이 20인데 다른 버튼은 22라면 전체 화면이 묘하게 흔들립니다.

Auto Layout을 배운 뒤에는 간격 값을 자주 입력하게 됩니다. Gap, Padding, Width, Height, Radius 같은 숫자가 계속 등장합니다. 이 값들을 Number Variable로 관리하면 화면의 리듬을 일정하게 유지할 수 있습니다.

기본 간격 체계는 너무 복잡할 필요가 없습니다. 처음에는 4의 배수나 8의 배수로 시작하면 충분합니다.

반경도 마찬가지입니다. 모서리 둥글기를 매번 직접 입력하면 카드와 버튼의 인상이 조금씩 달라집니다.

Auto Layout 프레임을 선택한 뒤 오른쪽 Design 패널에서 Gap이나 Padding 값 옆에 변수 연결 아이콘이 보이면 해당 숫자 변수를 적용할 수 있습니다. 버튼의 좌우 패딩에 space/4, 위아래 패딩에 space/3, 아이콘과 텍스트 사이 Gap에 space/2를 연결하는 식입니다.

이렇게 해 두면 버튼 크기를 조정할 때 단순히 눈대중으로 늘리고 줄이는 것이 아니라, 시스템의 간격 규칙 안에서 움직이게 됩니다. 화면이 갑자기 정돈되어 보이는 이유는 대단한 장식을 넣어서가 아니라, 반복되는 숫자가 일정해졌기 때문입니다.

⌨️ 단축키 박스: Variables와 함께 자주 쓰는 조작

Shift + A : 선택한 레이어에 Auto Layout을 적용합니다.

Alt 또는 Option 누른 채 마우스 이동 : 주변 레이어와의 거리 값을 확인합니다.

⌘ + / 또는 Ctrl + / : Quick Actions를 열고 필요한 기능을 검색합니다. Variables 패널이나 관련 명령을 찾을 때 유용합니다.

⌘ + D 또는 Ctrl + D : 선택한 요소를 복제합니다. 라이트 모드 화면을 복제해 다크 모드 비교용으로 만들 때 편합니다.

텍스트 값은 어디까지 변수로 만들까

텍스트는 조금 신중하게 다뤄야 합니다. 모든 문구를 변수로 만들면 파일이 오히려 읽기 어려워집니다. 예를 들어 화면에 있는 모든 제목, 설명, 버튼 문구를 text/title/1, text/body/1, text/button/1처럼 변수로 만들면 나중에 무엇이 어디에 쓰이는지 찾기 힘듭니다.

문자열 변수는 다음과 같은 상황에서 특히 유용합니다. 프로토타입에서 버튼을 누른 뒤 문구가 바뀌어야 할 때, 동일한 컴포넌트가 상황에 따라 다른 안내 문장을 보여 줘야 할 때, 언어나 테마에 따라 짧은 문구가 달라질 때입니다.

예를 들어 회원가입 버튼을 누르면 버튼 문구가 가입하기에서 처리 중...으로 바뀌는 흐름을 만들 수 있습니다. 또는 빈 상태 카드에서 아직 저장한 항목이 없어요라는 문구를 보여 주다가, 필터 결과가 없을 때는 조건에 맞는 항목이 없어요로 바꿀 수 있습니다.

하지만 본문 스타일 자체는 여전히 Text Styles로 관리하는 편이 좋습니다. 글꼴, 크기, 굵기, 줄 높이, 자간은 여러 속성이 묶여 있기 때문입니다. Variables는 텍스트의 내용이나 일부 숫자 값을 바꾸는 데 유용하고, Text Styles는 텍스트의 시각 체계를 유지하는 데 유용합니다.

실무에서는 보통 다음처럼 역할을 나눕니다. 제목과 본문 모양은 Text Styles로 적용하고, 버튼 문구나 상태 메시지처럼 프로토타입에서 바뀌는 문장은 String Variable로 연결합니다. 이 정도만 지켜도 파일이 훨씬 단단해집니다.

컴포넌트와 Variables를 연결하는 실무 흐름

버튼 컴포넌트를 만들었다면, 이제 그 안에 Variables를 연결해 보겠습니다. 버튼은 디자인 시스템을 연습하기 가장 좋은 재료입니다. 배경색, 글자색, 패딩, 간격, 반경, 상태가 모두 들어 있기 때문입니다.

먼저 버튼의 기본 구조를 떠올려 봅시다. 버튼 프레임은 Auto Layout으로 되어 있고, 내부에는 텍스트 레이어가 있습니다. 버튼 프레임의 Fill에는 color/action/primary를 연결합니다. 텍스트 색상에는 color/action/on-primary를 연결합니다. 버튼의 위아래 Padding에는 space/3, 좌우 Padding에는 space/4, Corner radius에는 radius/md를 연결합니다.

이제 이 버튼은 단순한 파란 사각형이 아닙니다. 시스템의 값을 따라 움직이는 컴포넌트입니다. 라이트 모드와 다크 모드에서 액션 컬러가 달라지면 버튼 색상도 같이 바뀝니다. 간격 체계를 조정하면 버튼의 내부 여백도 같이 바뀝니다.

Variants와 연결하면 더 강력해집니다. 예를 들어 버튼 Variant에 state=default, state=pressed, state=disabled를 만들 수 있습니다. 각 상태는 다른 변수를 바라보게 설계합니다.

처음부터 Component 단계 변수를 모두 만들 필요는 없습니다. 작은 프로젝트라면 color/action/primary 같은 Semantic 변수만으로도 충분합니다. 하지만 앱이 커지고 버튼 종류가 늘어나면 Component 단계 변수를 추가하는 것이 좋습니다. 그러면 버튼만의 상태 색상을 더 정교하게 조정할 수 있습니다.

카드 컴포넌트도 비슷합니다. 카드 배경에는 color/bg/surface, 테두리에는 color/border/default, 제목에는 color/text/primary, 설명에는 color/text/secondary를 연결합니다. 카드 안쪽 Padding은 space/4, 카드 내부 Gap은 space/3, 모서리 반경은 radius/lg를 사용합니다.

이런 방식으로 컴포넌트가 Variables를 바라보게 만들면, 컴포넌트는 더 이상 고정된 그림이 아닙니다. 디자인 시스템의 규칙을 따르는 살아 있는 UI가 됩니다.

💡 팁 박스: 컴포넌트에는 가능한 한 의미 변수를 연결하세요

버튼 배경에 color/blue/600을 바로 연결하지 말고 color/action/primary를 연결하세요. 카드 배경에 color/gray/0을 바로 연결하지 말고 color/bg/surface를 연결하세요. 나중에 색상 팔레트가 바뀌어도 컴포넌트 이름과 역할이 흔들리지 않습니다.

Prototype에서 Variables가 빛나는 순간

Variables는 정적인 디자인 파일을 정리할 때도 유용하지만, Prototype에서 더 재미있어집니다. 버튼을 눌렀을 때 특정 변수 값을 바꾸고, 그 값에 따라 화면 흐름을 다르게 만들 수 있기 때문입니다. 다만 프로토타입에서 Variables를 사용하는 기능은 플랜, 권한, 조직 설정에 따라 보이는 메뉴나 사용 가능 범위가 달라질 수 있습니다. 실무에서는 팀 계정에서 지원되는 범위를 먼저 확인하세요.

예를 들어 로그인 프로토타입을 만든다고 해 봅시다. isLoggedIn이라는 Boolean Variable을 만들고 초기값을 false로 둡니다. 로그인 버튼을 눌렀을 때 Set variable 액션으로 isLoggedIn을 true로 바꾸는 Interaction을 추가합니다. 이후 시작 버튼을 눌렀을 때 isLoggedIn이 true라면 홈 화면으로, false라면 로그인 화면으로 이동하도록 조건을 줄 수 있습니다.

테마 전환도 비슷한 원리로 생각할 수 있습니다. 라이트 모드와 다크 모드를 Mode로 구성해 두었다면, 프로토타입에서 지원되는 Set variable mode 액션을 사용해 현재 페이지의 변수 모드를 바꿀 수 있습니다. 실제 제품처럼 토글을 누르면 배경과 텍스트 색상이 바뀌는 경험을 시연할 수 있습니다. 단, 특정 오브젝트에 모드가 명시적으로 적용되어 있으면 페이지 레벨 모드 전환과 다르게 동작할 수 있으므로 테스트가 필요합니다.

물론 초보 단계에서 복잡한 조건문까지 모두 익힐 필요는 없습니다. 먼저 기억할 것은 하나입니다. Variables는 단지 값 저장소가 아니라, 프로토타입 안에서 상태를 표현하는 도구가 될 수 있습니다. '사용자가 무엇을 눌렀는가', '지금 어떤 상태인가', '다음에 무엇을 보여 줄 것인가'를 변수로 다룰 수 있습니다.

간단한 예를 들어 보겠습니다. 쇼핑 앱의 상품 카드에 좋아요 버튼이 있습니다. isLiked라는 Boolean Variable을 만들고, 하트 아이콘의 상태를 이 값과 연결할 수 있습니다. 사용자가 하트를 누르면 isLiked 값이 바뀌고, 그에 따라 채워진 하트와 빈 하트를 다르게 보여 줄 수 있습니다. 이렇게 하면 단순히 화면을 넘기는 프로토타입이 아니라, 상태가 변하는 프로토타입을 만들 수 있습니다.

변수 이름 규칙을 정하는 법

Variables는 이름이 절반입니다. 이름이 좋아야 팀원이 이해하고, 나중의 내가 다시 열어도 헷갈리지 않습니다. 이름 규칙이 없으면 변수는 금방 정체불명의 목록이 됩니다. blue, blue2, newBlue, buttonBlueFinal 같은 이름이 늘어나기 시작하면 이미 위험 신호입니다.

가장 추천하는 방식은 슬래시로 단계와 역할을 나누는 것입니다. 피그마는 슬래시가 들어간 이름을 계층처럼 보여 주기 때문에 목록을 정리하기 좋습니다.

이름을 정할 때는 작은 원칙을 세우는 것이 좋습니다. 첫째, 같은 종류의 값은 같은 시작 단어를 씁니다. 색상은 color, 간격은 space, 반경은 radius처럼 시작합니다. 둘째, 실제 색상보다 역할을 우선합니다. 셋째, 너무 구체적인 화면 이름은 피합니다.

예를 들어 login/button/blue라는 이름은 로그인 화면에 갇혀 있습니다. 나중에 회원가입 화면에서도 같은 버튼을 쓰면 이름이 어색해집니다. 대신 button/bg/primary/default라고 만들면 여러 화면에서 사용할 수 있습니다. 이름은 지금 화면이 아니라 앞으로 확장될 구조를 기준으로 붙이는 것이 좋습니다.

🧩 팁 박스: 변수 이름 규칙 추천

종류/역할/세부역할/상태 순서로 생각해 보세요.

색상 예시: color/text/primary, color/bg/surface, color/border/default

컴포넌트 예시: button/bg/primary/default, button/bg/primary/pressed, button/text/disabled

숫자 예시: space/4, radius/md, size/icon/md

변수 구조가 무너지는 흔한 실수

Variables를 처음 쓰면 모든 것이 멋져 보입니다. 그래서 너무 많이 만들고 싶어집니다. 하지만 디자인 시스템은 변수 개수가 많다고 좋아지는 것이 아닙니다. 오히려 필요한 만큼만 정확히 만드는 것이 중요합니다.

첫 번째 실수는 색상 차이만으로 상태를 이해하는 것입니다. Default, Hover, Pressed, Disabled 상태를 모두 비슷한 파란색으로만 만들면 사용자가 차이를 느끼기 어렵습니다. 상태는 색상뿐 아니라 투명도, 테두리, 커서 느낌, 텍스트 대비까지 함께 고려해야 합니다. 특히 Disabled 상태는 '누를 수 없음'이 분명히 보여야 합니다.

두 번째 실수는 Variant와 Variable을 중복해서 늘리는 것입니다. 예를 들어 버튼 크기, 색상, 상태, 아이콘 유무, 로딩 여부를 모두 Variant로만 만들면 조합이 폭발합니다. 반대로 모든 것을 Variables로만 처리하려고 해도 관리가 어렵습니다. 모양의 종류와 상태는 Variants가 잘하고, 그 안에서 쓰이는 값은 Variables가 잘합니다.

세 번째 실수는 이름 규칙이 중간에 바뀌는 것입니다. 처음에는 color/bg/page라고 만들다가 나중에는 background/main, 또 다른 곳에서는 page-bg라고 만들면 검색과 정리가 어려워집니다. 한 번 정한 규칙은 완벽하지 않아도 꾸준히 지키는 것이 좋습니다. 바꾸어야 한다면 팀원과 합의하고 한 번에 정리해야 합니다.

네 번째 실수는 실제 값을 너무 위쪽에 직접 넣는 것입니다. 컴포넌트에 원시 색상을 직접 연결하면 빠르지만, 장기적으로 유연성이 떨어집니다. Primitive는 재료, Semantic은 의미, Component는 사용처라는 층을 기억하세요. 작은 프로젝트에서는 두 단계만 써도 괜찮지만, 역할과 실제 값은 가능하면 분리하는 습관을 들이는 것이 좋습니다.

실무에서는 이렇게 시작하면 충분하다

처음부터 거대한 디자인 시스템을 만들려고 하면 손이 멈춥니다. 변수 이름 하나 정하는 데 10분, 컬렉션 나누는 데 30분, 모드 구조 고민에 하루가 지나갈 수 있습니다. 초보자에게 필요한 것은 완벽한 시스템이 아니라, 변경에 강한 최소 구조입니다.

작은 프로젝트라면 세 개의 Collection으로 시작해도 충분합니다. Primitives에는 실제 색상 팔레트를 넣습니다. Theme에는 라이트·다크 모드에서 바뀌는 의미 색상을 넣습니다. Scale에는 간격, 반경, 아이콘 크기 같은 숫자 값을 넣습니다.

처음 만들 변수도 많을 필요가 없습니다. 배경, 카드, 주요 텍스트, 보조 텍스트, 주요 액션, 기본 테두리 정도면 첫 화면을 만들 수 있습니다. 숫자도 4, 8, 12, 16, 24, 32 정도면 대부분의 기본 UI를 구성할 수 있습니다.

실무 파일에서 중요한 것은 모든 상황을 예측하는 것이 아니라, 자주 바뀌는 값을 흩어지지 않게 두는 것입니다. 버튼 색상이 바뀌었을 때 한곳에서 수정할 수 있는가. 카드 간격을 조정했을 때 여러 카드가 함께 바뀌는가. 다크 모드를 만들 때 레이어를 일일이 뒤집지 않아도 되는가. 이 질문에 '그렇다'고 답할 수 있다면 좋은 출발입니다.

✅ 작업 습관 박스: Variables 적용 순서

1. 먼저 자주 쓰는 색상과 숫자를 찾습니다.

2. 실제 값은 Primitive나 Scale에 저장합니다.

3. 화면에 적용할 때는 bg, text, action처럼 의미가 드러나는 변수를 씁니다.

4. 컴포넌트에는 가능한 한 Semantic 또는 Component 변수를 연결합니다.

5. 라이트 모드와 다크 모드를 나란히 복제해 눈으로 비교합니다.

핵심 요약

Variables는 색상, 숫자, 문자열, 불리언 같은 값을 한곳에서 관리하고 여러 UI에 연결하는 기능입니다. 변경에 강한 파일을 만들려면 같은 값을 복사해서 쓰는 대신, 재사용 가능한 기준 값으로 관리해야 합니다.

Styles와 Variables는 역할이 다릅니다. Text Styles는 글자의 모양을 묶어 관리하기 좋고, Variables는 색상·간격·반경·문구처럼 바뀌기 쉬운 값을 관리하기 좋습니다. 둘 중 하나를 선택하기보다, 표현 묶음은 Styles로, 변하는 기준 값은 Variables로 나누는 것이 실무적입니다.

Collection은 변수들을 담는 서랍이고, Mode는 같은 변수에 여러 상황별 값을 넣는 방식입니다. Alias는 변수가 다른 변수를 참조하게 만드는 기능입니다. 이 세 가지를 사용하면 라이트 모드와 다크 모드처럼 테마가 바뀌는 구조를 만들 수 있습니다.

변수 이름은 시스템의 지도입니다. color/bg/surface, color/text/primary, space/4, radius/md처럼 종류와 역할이 드러나게 이름을 붙이면 팀원이 이해하기 쉽고, 나중에 확장하기도 쉽습니다.

Auto Layout, Components, Variants, Prototype은 Variables와 함께 사용할 때 더 강력해집니다. 간격 변수는 Auto Layout의 Gap과 Padding에 연결하고, 색상 변수는 컴포넌트 상태에 연결하며, 불리언과 문자열 변수는 프로토타입의 상태 변화에 활용할 수 있습니다. 단, 프로토타입에서 변수와 모드를 사용하는 기능은 팀 플랜과 권한에 따라 지원 범위가 다를 수 있으므로 실제 프로젝트에서는 한 번 테스트한 뒤 적용하세요.

실습 과제: 라이트·다크 테마 버튼과 카드 UI 만들기

이번 실습에서는 간단한 카드와 버튼을 만들고, Variables로 라이트 모드와 다크 모드를 전환할 수 있는 구조를 만들어 봅니다. 완벽한 디자인보다 '값을 직접 입력하지 않고 변수로 연결하는 경험'에 집중하세요.

1단계: 변수 Collection 만들기

피그마 파일에서 Variables 패널을 열고 다음 세 가지 Collection을 만듭니다. UI 위치는 피그마 업데이트에 따라 조금 달라질 수 있지만, 값 입력 칸 옆의 변수 아이콘이나 Variables 관련 메뉴를 통해 접근할 수 있습니다.

Primitives에는 다음 색상 변수를 만듭니다.

Theme에는 Light와 Dark Mode를 만들고 다음 변수를 추가합니다. 값은 가능하면 직접 색상을 입력하지 말고 Primitives의 색상 변수를 Alias로 연결합니다.

Scale에는 다음 숫자 변수를 만듭니다.

2단계: 카드 UI 만들기

새 프레임을 만들고 배경 Fill에 color/bg/page를 연결합니다. 그 안에 카드 프레임을 하나 만듭니다. 카드 프레임에는 Auto Layout을 적용하고 방향은 세로로 설정합니다. 카드의 Fill에는 color/bg/surface, Stroke에는 color/border/default를 연결합니다.

카드의 Padding은 상하좌우 모두 space/4를 연결합니다. 카드 내부 Gap은 space/3을 연결합니다. Corner radius는 radius/lg를 연결합니다.

카드 안에는 제목 텍스트와 설명 텍스트를 넣습니다. 제목은 이번 주 인기 강의, 설명은 초보자도 따라 할 수 있는 피그마 실습을 모았어요라고 입력해 봅니다. 제목 색상은 color/text/primary, 설명 색상은 color/text/secondary를 연결합니다. 텍스트 모양은 Text Styles가 있다면 적용하고, 없다면 제목은 조금 더 굵고 크게, 설명은 작고 가볍게 설정합니다.

3단계: 버튼 만들기

카드 안에 버튼 프레임을 만듭니다. 버튼에도 Auto Layout을 적용하고 텍스트 레이어를 넣습니다. 버튼 문구는 자세히 보기로 입력합니다.

버튼 Fill에는 color/action/primary, 버튼 텍스트 색상에는 color/action/on-primary를 연결합니다. 버튼의 위아래 Padding은 space/3, 좌우 Padding은 space/4, Corner radius는 radius/md를 연결합니다.

버튼을 Component로 만들어 봅니다. 시간이 있다면 state=default와 state=disabled Variant를 추가해 보세요. Disabled 상태에는 별도의 변수를 만들지 않아도 좋습니다. 처음에는 투명도를 낮추거나 보조 색상을 적용해 '비활성' 느낌이 나는지 확인하는 정도면 충분합니다.

4단계: 라이트 모드와 다크 모드 비교하기

완성한 프레임을 복제합니다. 왼쪽 프레임은 Light Mode, 오른쪽 프레임은 Dark Mode로 설정합니다. 프레임 또는 상위 영역에서 적용 Mode를 바꾸면 연결된 색상들이 함께 바뀌어야 합니다.

이때 카드 배경, 페이지 배경, 제목 색상, 설명 색상, 버튼 색상이 모두 자연스럽게 바뀌는지 확인합니다. 다크 모드에서 글자가 너무 흐리거나 버튼이 너무 튀면 Theme 변수의 Dark 값을 조정해 보세요. 레이어 하나를 직접 수정하지 말고, 변수 값을 바꿔서 전체가 함께 바뀌는지 확인하는 것이 이번 실습의 핵심입니다.

5단계: 점검 질문

실습이 끝나면 다음 질문에 답해 보세요.

• 카드 배경색을 직접 입력하지 않고 color/bg/surface로 연결했나요?

• 버튼 배경색을 실제 파란색이 아니라 color/action/primary로 연결했나요?

• 카드의 Padding과 Gap을 숫자 직접 입력이 아니라 space 변수로 연결했나요?

• 라이트 모드와 다크 모드에서 같은 카드가 서로 다른 색상으로 자연스럽게 보이나요?

• 색을 바꾸고 싶을 때 레이어가 아니라 Variables 패널에서 수정할 수 있나요?

이 다섯 가지에 모두 답할 수 있다면, 이제 여러분의 피그마 파일은 단순한 화면 모음에서 한 단계 올라섰습니다. 값이 흩어진 파일이 아니라, 기준이 연결된 파일이 된 것입니다. 이 구조 위에 Prototype을 얹으면 클릭하고 이동하며 상태가 변하는 화면까지 만들 수 있습니다.