제대로 쓰는 사람만 아는 피그마 변수 활용법 5가지

정적인 스타일에서 값 제어 기반 설계로 넘어가는 실무의 변화

디자인 시스템을 운영하다 보면 반복되는 질문이 많다. 텍스트 스타일을 더 나눠야 하는지, 색상 토큰을 어디까지 확장해야 하는지, 테마가 늘어나면 지금의 스타일만으로 충분한지 같은 질문들이다. 피그마는 오랫동안 컬러와 텍스트, 효과 스타일처럼 화면의 시각적 속성을 공통 모듈로 저장해 재사용하는 방식을 중심으로 발전해 왔다. 이 구조는 효율적이지만 어디까지나 정적인 속성을 표준화하는 데 초점이 맞춰져 있다. 스타일은 특정 색상 값이나 라인하이트처럼 변하지 않는 기준선을 만든다.

하지만 실제 제품은 정적인 상태로만 존재하지 않는다. 라이트와 다크 모드처럼 테마가 바뀌고, 이벤트 기간에는 색상이 달라지고, 사용자 유형이나 설정에 따라 화면 구성까지 변화한다. 스타일만으로 이런 복잡한 변화를 안정적으로 관리하기는 어렵다. 그래서 등장한 개념이 변수이다. 피그마가 이 기능을 스타일과 구분해 변수라고 명명한 이유는 단순한 속성 저장이 아니라, 상황에 따라 값이 전환되는 구조임을 강조하기 위해서다.

스타일이 제품의 기본값을 정리하는 언어라면, 변수는 상황을 제어하는 언어에 가깝다. 스타일이 기준선을 정하면, 변수는 그 기준선을 조건에 따라 바꾼다. 둘은 대체재가 아니라 상호 보완적인 관계이고, 함께 사용할 때 디자인 시스템은 정적인 표준화와 유연한 변화 대응을 동시에 갖추게 된다.

이번 글에서는 실제 제품 개발 과정에서 가장 큰 효용을 만들어내는 실무형 변수 활용 7가지를 살펴보고자 한다. 단순히 기능 소개를 넘어, 변수를 값 제어 기반 설계 방식으로 바라볼 때 어떤 변화가 나타나는지 정리했다.

1. 테마 전환하기

디자인 시스템에서 가장 빠르게 복잡해지는 영역은 색상이다. 특히 라이트와 다크 모드가 공존하는 환경이라면 두 모드를 각각 별도의 스타일 파일로 운영할 때 유지보수 비용이 순식간에 커진다. 모드별로 색상을 전부 확인해야 하고, 버튼과 배지 등 구성요소마다 특정 색상이 누락되는 문제도 자주 발생한다. 예를 들어, 금융 서비스에서는 위험도에 따라 색상 기준이 달라지는데, 이를 라이트·다크모드 각각에서 수동으로 조정하는 것은 현실적으로 부담이 크다.

색상 변수를 도입하면 구조는 명확해진다. Primary, Foreground, Background, Surface 등 의미 기반 토큰을 먼저 정의하고, 같은 토큰에 라이트와 다크 값만 바인딩해 두면 된다. UI는 hex 값 자체를 바라보지 않고, 의미 기반 토큰을 바라보는 구조가 되기 때문에, 모드 전환은 값 세트를 바꾸는 일만으로 끝난다. 이커머스 서비스에서 다크모드를 뒤늦게 도입하면서 기존 화면을 거의 수정하지 않고도 테마를 구현했던 사례가 대표적이다.

브랜드 리뉴얼처럼 색상 전면 개편이 필요한 상황에서도 장점이 크다. 기존 방식이라면 수십 개 화면에서 색을 하나씩 교체해야 했지만, 변수 기반 구조에서는 토큰값만 교체하면 전체 UI가 한 번에 정리된다. 색상이 많은 서비스일수록, 화면이 복잡한 서비스일수록 변수 기반 색상 구조는 유지보수 효율을 극적으로 높여준다.

2. 다국어 카피 대응하기

UI에서 문구는 가장 자주 바뀌는 요소다. 가격정책 개편으로 버튼 문구가 달라지고, 온보딩 배너는 캠페인에 따라 주 단위로 수정되며, 법무 검토가 필요한 정책 문구는 수시로 업데이트된다. 기존 방식이라면 화면을 일일이 열어 같은 문구가 어디에 있는지 찾아야 하고, 누락되기 쉽다. QA 단계에서 특정 화면만 지난 문구가 남아 있는 문제가 반복되는 것도 이 때문이다.

Text 변수를 사용하면 이 문제는 구조적으로 해결된다. 로그인 CTA라면 cta_login, 가입 버튼이라면 cta_signup, 이벤트 설명이라면 copy_event_desc처럼 변수로 분리해 UI에 연결해 두면, 문구 변경은 변수값 수정만으로 끝난다. 글로벌 서비스를 운영하는 팀은 locale별로 Value set을 구성해 언어 전환도 즉시 가능하다. SaaS 서비스 중에는 언어가 10개를 넘는데 Text 변수를 적용해 QA 시간을 절반 정도 줄인 사례도 있다.

정책 문구는 특히 변수로 관리할 실익이 크다. 예를 들어, 결제 환불 규정이 법 개정으로 바뀌었다면 기획자나 법무팀 요청에 따라 한 문장만 변수에서 고치면 모든 화면에 일괄 반영된다. 단순한 편의 기능을 넘어, 제품 운영의 리스크까지 줄여주는 구조다. 자체 플러그인을 만들어서 구글 시트나 노션에서 관리하는 정책을 변수로 불러오는 것까지 연결한다면 금상첨화다.

3. 토글 상태 관리하기

버튼이나 카드 같은 컴포넌트는 기본적으로 상태가 많다. 활성, 비활성, 로딩, 오류, 선택됨 같은 상태가 늘어날수록 Variant도 빠르게 늘어난다. 피그마는 이런 상태를 간단하게 조정할 수 있도록 컴포넌트 Boolean 프로퍼티를 제공하지만, 이 방식은 결국 개별 컴포넌트 안에서만 의미를 갖는 지역적 상태다. 컴포넌트 단위에서 아이콘을 보이게 하거나 배지를 숨기는 정도라면 충분하지만, 서비스 전체에서 반복되는 조건을 이 방식으로 관리하려 하면 문제가 금방 드러난다.

실제 프로젝트에서는 Boolean 프로퍼티가 기능적으로는 같지만 이름이 서로 다른 형태로 쉽게 늘어난다. 예를 들어, 로그인 여부를 제어하는 조건을 초기에 isLogin으로 만들었다가, 다른 화면에서 hasLogin, LoggedIn 같은 이름을 별도로 만들기 시작하면 컴포넌트마다 같은 조건을 다르게 표현하게 되고, 시간이 지나면 어떤 프로퍼티가 실제로 쓰여야 하는지 판단하기 어려워진다. 개발자 입장에서는 모두 동일한 로그인 여부 조건인데, 피그마 안에서 상태명이 제각각이기 때문에 실수나 누락이 반복되는 구조다.

Boolean 변수를 사용하면 이 문제를 구조적으로 해결할 수 있다. isLogin이라는 변수를 하나만 정의해두고, 로그인 여부가 필요한 모든 컴포넌트는 이 변수를 바라보도록 연결하면 된다. 그러면 UI 전체에서 로그인 여부가 단일한 조건으로 통일되고, 컴포넌트마다 제각각 만들어진 Boolean 프로퍼티를 유지할 필요가 없다. 특정 화면에서만 필요하던 로컬 스위치를 전역 상태로 승격시키는 방식이다.

카드 컴포넌트라면 isSelected, isVIP, isUnread 같은 반복되는 조건들도 모두 변수로 통합할 수 있다. 예를 들어, VIP 사용자인 경우 여러 화면에서 배지, 하이라이트, 가격 표시 방식이 동시에 달라져야 한다면, 각각의 컴포넌트에서 showVIPBadge 같은 프로퍼티를 따로 켜는 것이 아니라 isVIP 변수를 true로 바꾸는 것만으로 UI 전체가 연결된다. 상태가 컴포넌트 내부에 종속되지 않고, 화면을 가로지르는 전역 조건이 되는 셈이다.

컴포넌트 Boolean 프로퍼티는 특정 UI 조각을 제어하는 스위치라면, Boolean 변수는 여러 UI 조각이 함께 반응하는 전역 로직이다. 조건이 컴포넌트 하나를 넘어서 서비스 전체에서 반복되는 패턴이라면 변수로 다루는 것이 구조적으로 더 안정적이고, 상태 확장에 대응하는 데도 효율적이다. UI를 조건 기반으로 설계하는 팀일수록 Boolean 변수를 도입했을 때 얻는 이점이 크다.

4. 간격, 곡률, 투명도 일괄 관리하기

UI 품질이 무너질 때 가장 먼저 드러나는 문제는 간격의 불규칙성이다. 홈 화면에서는 카드 간 간격이 16px인데, 검색 화면은 12px, 상세 화면은 20px처럼 화면마다 기준이 미묘하게 갈라지기 시작하면 전체적인 리듬이 흐트러지고 사용자 경험도 일관성을 잃는다. 조직이 커질수록 이런 드리프트는 눈에 띄게 늘어나고, 디자인 시스템을 도입했음에도 불구하고 화면마다 간격이 들쭉날쭉해지는 문제가 반복된다.

Spacing 변수를 사용하면 이 문제는 구조적으로 해결된다. spacing-100 = 8px, spacing-200 = 12px, spacing-300 = 16px처럼 스케일을 정의하면 padding, margin, gap뿐 아니라 카드형 리스트와 섹션 간격까지 하나의 기준선으로 환원된다. 모바일과 웹 간 간격 정책을 분리하고 싶을 때도 Value set만 전환하면 되고, 리디자인 과정에서 전체 간격 스케일을 8px에서 4px로 바꿔야 할 때도 변수값만 조정하면 UI 전체가 동시에 정리된다. 간격을 디자이너 개인의 감각이 아니라 시스템에 맞기기 때문에 화면 간 리듬이 단단해진다.

간격이 UI의 구조적 리듬을 담당한다면, 제품의 분위기와 브랜드 톤을 결정하는 요소는 디테일 값이다. 모서리 반경이 6px인지 12px인지, 그림자가 깊은지 옅은지, 오버레이 투명도가 어느 정도인지 같은 요소들은 작아 보이지만 제품의 성격을 결정하는 핵심 표현이다. 시간이 지나면 이런 값이 화면마다 따로 설정되면서 UI 전체의 일관성이 흐려지고, 특정 페이지만 어색해 보이는 문제가 생긴다.

Number 변수를 사용하면 이런 디테일 값도 시스템 차원에서 통합 관리할 수 있다. radius.sm = 6, radius.md = 8, radius.lg = 12처럼 스케일을 정의해두면 컴포넌트와 페이지의 모서리 값이 자연스럽게 정렬된다. 그림자, 오버레이 opacity 같은 스타일 요소도 변수 기반으로 통제하면 테마 전환에 따라 자동으로 값이 전환되기 때문에 라이트·다크 환경에서도 표현의 균형을 유지하기 쉽다. 대규모 리뉴얼 과정에서 전체 라운드 값이나 그림자 스타일을 바꿔야 할 때도 변수만 교체하면 UI 분위기를 빠르게 새로 정리할 수 있다.

간격과 디테일 값은 UI의 ‘기초 뼈대’와 ‘브랜드 감도’를 결정하는 요소다. 두 영역을 변수 기반으로 일관되게 관리하면 화면 수가 늘어나도 흔들리지 않는 UI 리듬을 유지할 수 있고, 서비스의 확장과 개편에도 안정적으로 대응할 수 있다.

5. 프로토타입에 활용하기

제품의 흐름을 보여주는 프로토타입은 중요하지만 피그마에선 그동안 대부분 정적인 화면 전환 수준에 머물렀다. 사용자가 선택한 옵션에 따라 다음 화면이 달라지는 구조나, 특정 값이 화면마다 이어지는 구조를 표현하기 어려웠기 때문이다. Prototype 변수는 이런 한계를 어느 정도 해결한다. 사용자가 선택한 값을 변수로 저장해두고, 이후 화면에서 해당 값에 따라 UI 요소가 바뀌도록 만들 수 있다. 예를 들어, 요금제 화면에서 사용자가 Premium을 선택하면 변수에 해당 값이 저장되고, 결제 화면에서는 Premium 요금제의 가격과 혜택 정보를 자동으로 노출할 수 있다.

여행 앱에서도 여행지와 날짜를 선택한 뒤 다음 화면에서 조건에 맞는 추천 상품을 보여주는 구조를 실제 서비스처럼 재현할 수 있다. 금융 서비스의 신청 플로우처럼 조건 분기가 많은 경우에도 유용하다. 예를 들어, 직업 정보를 프리랜서로 선택한 사용자에게만 특정 추가 문서 안내를 노출하는 방식도 Prototype 변수로 구현할 수 있다. 프로토타입을 단순한 화면 모음이 아니라 기능 로직에 가까운 구조로 바꿔주는 기능이다.

마치며: 변수를 활용한 디자인은 디자이너의 역할을 확장시킨다

변수를 중심으로 UI를 설계하는 방식은 단순히 편의 기능을 하나 더 익히는 차원을 넘어, 제품을 바라보는 관점을 바꾸는 일에 가깝다. 기존의 스타일 중심 설계가 정적인 화면을 기준으로 구조를 정리했다면, 변수 기반 설계는 제품이 실제로 동작하는 조건과 상태를 UI 레벨에서 모델링하는 구조다.

이 방식이 도입된 팀에서는 화면 수가 줄어들고 상태 관리가 단순해지며, 테마 추가나 정책 변경 같은 대규모 대응도 빠르게 해결된다. 무엇보다 기획자와 개발자 간 커뮤니케이션 비용이 줄어들어 디자인이 제품 논리에 한층 더 가까워지는 변화가 생긴다. 변수는 색상, 텍스트, 상태, 간격, 디테일 값, 테마 조합, 프로토타입 로직까지 UI의 다양한 요소를 하나의 조건 기반 시스템으로 묶어주는 역할을 한다.

앞으로 디자인 도구들은 점점 더 변수 중심 구조로 이동할 가능성이 높다. 디자인 시스템은 단순히 화면을 정리하는 일을 넘어, 상태와 논리를 설계하는 방향으로 확장되고 있다. UI를 구성하는 값을 구조적으로 관리할 수 있는 디자이너는 제품 전체의 흐름을 더 깊이 이해하게 되고, 팀 내에서 더 큰 영향력을 갖게 될 것이다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.