피그마 변수 vs 스타일: 상황별 선택 가이드와 실무 활용법

디자인 시스템을 구축하다 보면 가장 먼저 마주치는 난관이 있습니다. 바로 “이 색상을 스타일(Styles)로 만들 것인가, 아니면 변수(Variables)로 만들 것인가?” 하는 문제입니다. 두 기능은 겉보기에 비슷해 보이지만, 시스템의 확장성과 개발 연동 측면에서 완전히 다른 DNA를 가지고 있습니다.

과거에는 모든 것을 ‘스타일’로 해결해야 했지만, 이제는 변수의 등장으로 더 정교한 논리 설계가 가능해졌습니다. 하지만 무턱대고 모든 요소를 변수로 바꾸는 것이 정답은 아닙니다. 20년 차 개발자이자 컨설턴트로서, 실무에서 겪은 시행착오를 바탕으로 어떤 상황에서 무엇을 선택해야 할지 명확한 기준을 정리해 드립니다.

변수(Variables): 논리적인 ‘데이터’의 힘

변수는 단순히 색상이나 수치를 저장하는 칸이 아닙니다. 프로그래밍에서의 변수처럼 ‘조건’과 ‘모드’에 따라 값이 변할 수 있는 동적인 데이터입니다. 실무에서 변수를 반드시 써야 하는 상황은 크게 세 가지입니다.

첫째, **모드 전환(Theming)**이 필요한 경우입니다. 라이트 모드와 다크 모드, 혹은 모바일과 데스크톱의 여백 값을 다르게 가져가야 할 때 변수는 압도적인 효율을 보여줍니다. ‘Surface-Primary’라는 하나의 변수에 라이트 모드용 하얀색과 다크 모드용 검은색을 각각 할당하면, 클릭 한 번으로 전체 화면의 테마를 전환할 수 있습니다.

둘째, **토큰 계층 구조(Aliasing)**를 설계할 때입니다. 원천이 되는 컬러(Raw Color)를 시맨틱 토큰(Semantic Token)에 연결하는 작업은 오직 변수에서만 가능합니다. 예를 들어 #3B82F6을 Blue-500이라는 변수로 만들고, 이를 다시 Button-BG라는 변수가 참조하게 만드는 방식이죠. 이렇게 하면 브랜드 컬러가 바뀌어도 최상위 변수만 수정하면 모든 컴포넌트가 자동으로 업데이트됩니다.

셋째, 수치 데이터 관리입니다. 간격(Gap), 패딩(Padding), 코너 곡률(Radius) 등을 변수로 관리하면 개발자와의 소통이 ‘몇 픽셀인가요?’에서 ‘어떤 간격 토큰인가요?’로 격상됩니다.

[💡 에디터의 실무 팁: 변수를 만들 때는 ‘Scope’ 설정을 활용해 보세요. 색상 변수가 텍스트에는 나타나지 않게 설정하면, 디자이너가 실수로 배경색을 글자에 입히는 사고를 방지할 수 있습니다.]

스타일(Styles): 복합적인 ‘시각 효과’의 영역

변수가 강력하긴 하지만, 여전히 스타일이 주인공이어야 하는 영역이 있습니다. 스타일은 여러 속성이 결합된 ‘패키지’라고 이해하면 쉽습니다.

가장 대표적인 것이 **그라데이션(Gradients)**입니다. 피그마 변수는 현재 단일 색상(Solid Color)만 지원합니다. 여러 색상이 섞이는 그라데이션은 스타일로 정의해야 합니다. 또한 **효과(Effects)**인 그림자(Drop Shadow)나 블러(Blur) 처리 역시 스타일의 전유물입니다. 그림자 하나를 구성하는 X, Y축 값, 퍼짐 정도, 색상을 하나의 묶음으로 관리해야 하기 때문입니다.

타이포그래피 역시 마찬가지입니다. 글꼴, 크기, 행간, 자간을 각각의 변수로 쪼개서 관리할 수도 있겠지만, 실무적으로는 이를 하나의 ‘H1’ 또는 ‘Body-Regular’ 스타일로 묶어서 적용하는 것이 훨씬 직관적이고 빠릅니다.

실무 트러블슈팅: 변수와 스타일의 충돌 해결하기

실무에서 가장 흔하게 발생하는 에러는 ‘스타일 내부에 변수를 넣을 수 있는가?’에 대한 혼란입니다. 다행히 피그마는 스타일 정의 시 색상 값에 변수를 참조(Alias)할 수 있는 기능을 지원합니다.

예를 들어, 그림자 스타일을 만들 때 그림자의 색상 부분을 미리 만들어둔 Shadow-Color-Token이라는 변수로 연결할 수 있습니다. 이렇게 설계하면 나중에 다크 모드로 전환했을 때, 그림자의 색상 변수 값만 바뀌면서 스타일 전체가 다크 모드에 어울리는 부드러운 그림자로 자연스럽게 변하게 됩니다.

결국 핵심은 **”단일 값인가, 복합 값인가?”**를 따지는 것입니다. 단일 수치나 색상은 변수로, 여러 속성이 결합된 시각 효과는 스타일로 관리하는 것이 현재 디자인 시스템 엔지니어링의 표준입니다.

[💡 에디터의 실무 팁: 개발 연동(Style Dictionary 등)을 고려한다면 가능한 한 많은 값을 변수로 추출하세요. 스타일은 코드화 과정에서 파싱(Parsing)이 까다로운 경우가 많지만, 변수는 순수한 JSON 데이터로 추출하기 매우 용이합니다.]

요약: 상황별 선택 가이드라인

표로 정리하면 다음과 같습니다.

구분	변수(Variables) 추천	스타일(Styles) 추천
색상	단일 색상, 테마 전환 필요 시	그라데이션, 복합 패턴
수치	여백, 곡률, 너비 제어	–
텍스트	문자열(String) 데이터	폰트 패밀리, 크기, 행간 묶음
효과	–	그림자, 블러, 오버레이
논리	토큰 간 참조(Alias) 가능	참조 불가 (독립적 존재)

자주 묻는 질문(FAQ)

Q1. 기존에 스타일로 다 만들어뒀는데, 변수로 꼭 바꿔야 하나요? 전면 교체보다는 ‘색상’과 ‘간격’부터 단계적으로 전환하는 것을 추천합니다. 특히 다크 모드 대응 계획이 있다면 변수로의 전환은 선택이 아닌 필수입니다.

Q2. 변수를 쓰면 디자인 파일이 무거워지지는 않나요? 오히려 반대입니다. 수십 개의 유사한 스타일을 만드는 것보다, 몇 개의 핵심 변수에 ‘모드’를 추가하는 것이 관리 포인트와 파일 용량 측면에서 훨씬 유리합니다.

Q3. 개발자가 변수 이름을 코드에서 그대로 쓸 수 있나요? 네, 피그마 변수는 개발자 모드(Dev Mode)에서 코드로 바로 확인 가능하며, API를 통해 JSON으로 추출하여 변수명을 100% 일치시킬 수 있습니다. 이것이 DesignOps의 시작입니다.