피그마 Variables로 끝내는 디자인 시스템 효율화

기술 선택 배경

디자인 시스템은 단순히 화면을 빠르게 제작하기 위한 도구가 아니라, 장기간 운영과 반복적인 수정이 전제되는 기반 구조라는 점을 비젠드 작업을 하면서 깨닫게 되었다. 서비스가 추가되거나 디자인을 개선할 때 정리된 규칙이 얼마나 중요하고, 초기 구축 단계에서의 편의성보다, 이후 유지보수 과정에서 누구나 이해하고 수정할 수 있는 구조를 가져야 한다는 점을 깨달았다.

그래서 당장 화면을 빨리 만들어내는 속도보다 서비스가 확장되고 담당자가 바뀌어도 이 구조가 흔들리지 않고 고치기 쉬운 시스템을 만드는 것에 집중했고, 특정 작업자에게 의존하지 않고 최소한의 인력으로도 안정적으로 운영될 수 있는 시스템을 설계하기 위해 컴포넌트 구조와 Variables를 표준화하고, AI를 활용해 반복 작업과 수정 범위를 최소화할 수 있는 구조를 작업했다.

Variables 기반 설계가 필요한 이유

피그마 파일에는 크게 두 가지 형태의 정보가 존재한다. 원시값과 의미가 정의된 값이다. 원시값은 색상, 크기, 간격 등이 단순히 시각적으로 적용된 상태이다. 작업자는 화면을 통해 의도를 유추할 수 있지만, 해당 작업에 참여하지 않은 다른 사람이나 시스템 입장에서는 값의 목적과 사용 기준을 이해하기 어렵다.

반면 의미가 정의된 값은 Primary Color, Spacing, Radius처럼 역할과 목적이 명확하게 정의된 상태를 말한다. 이러한 구조는 다른 작업자뿐 아니라 AI 및 자동화 도구 역시 동일한 기준으로 해석할 수 있도록 만든다. 이때 의미가 있는 값으로 구조화하는 장치가 바로 피그마의 Variables 기능이다.

예를 들어 원시값을 사용할 경우, 특정 색상이 브랜드의 Primary 컬러인지 혹은 임시로 사용된 값인지 구분하기 어렵고, 폰트 사이즈 또한 어떤 상황에서 사용되는 규칙인지 파악하기 힘들다. Variables를 활용하면 해당 값이 브랜드 컬러인지, 혹은 디바이스 별 spacing 규격인지 명확히 정의되며, 이러한 정보는 코드 구조와 매핑되어 자동화 및 유지보수 과정에서도 효율적으로 활용될 수 있다.

자동화의 흐름을 살펴보면, 디자인 토큰은 구조화된 데이터로 변환되고 이를 기반으로 AI와 플러그인이 값을 해석하며 코드 매핑, 자동 변환, 그리고 유지보수 단계로 이어진다. Variables는 단순한 스타일 관리 기능이 아니라, 디자인을 시각적인 결과물에서 구조화된 데이터로 전환하여 AI와 자동화 도구가 디자인 의도를 이해하고 활용할 수 있도록 만드는 핵심 엔진이 된다.

특히 디자인 환경에서 지원하는 모드별 컬러 전환은 Variables를 통해 효율적으로 관리할 수 있다. 이를 활용하면 서비스별 브랜드 컬러 변경이나 테마 확장 시 개별 화면을 수정할 필요 없이 일관된 기준으로 빠르게 적용할 수 있다. 이러한 구조는 단기적인 제작 효율 향상에 그치지 않고, 장기적으로 유지보수 비용을 줄이고 예상치 못한 문제로 수정이 필요할 때 시간을 단축시키는 데에도 기여한다.

토큰 구조 설계

디자인 시스템을 구축하면서 토큰을 Primitive → Semantic → Component 3단계 구조로 설계했다. 이는 단순한 값 정리가 아니라, 디자인 변경이 발생했을 때 영향 범위를 명확히 분리하고 유지보수 효율을 높이기 위한 구조이다.

1) Primitive Token

Primitive는 색상, 간격, radius와 같은 가장 기본이 되는 원시 값을 정의하는 단계이다. Primitive는 시스템의 기준 값 역할만 하며, 직접 컴포넌트에 매핑하지 않는 것을 원칙으로 한다. 이는 특정 값 변경 시 예상하지 못한 UI 변화가 발생하는 것을 방지하기 위함이다.

2) Semantic Token

Semantic은 Primitive 값에 의미와 역할을 부여하는 계층이다. 디자인 의도를 표현하는 단계라고 볼 수 있다. Semantic 토큰은 반드시 Primitive를 참조하도록 설계했다. 이 구조를 통해 실제 색상이 변경되어도 Semantic 의미는 유지되며, 시스템 전체 수정 범위를 최소화할 수 있다.

3) Component Token

Component 토큰은 실제 UI 컴포넌트에서 사용하는 값이다. 버튼, 인풋, 카드 등 특정 컴포넌트의 상태와 맥락에 맞게 정의된다. Component 토큰은 직접 Primitive를 사용하지 않고, 반드시 Semantic 토큰을 참조하도록 규칙을 설정했다.

Component → Semantic → Primitive 이 계층 구조를 통해 디자인 변경 시 수정 지점을 명확히 분리할 수 있으며, 컴포넌트 단위 유지보수가 쉬워진다.

디자인 시스템 구축 과정에서의 시행착오와 개선

디자인 시스템을 구축하면서 중요한 점 중 하나는, 지나치게 세밀한 케이스까지 정의하는 것이 반드시 좋은 결과로 이어지지는 않는다는 점이다. 컴포넌트를 모든 상황에 맞게 세분화하면 오히려 사용성이 제한되고, 실제 작업 과정에서는 컴포넌트를 그대로 활용하기 어려워 Detach하여 사용하는 상황이 발생한다. 이러한 방식은 결국 시스템과 실제 작업 사이의 괴리를 만들고, 장기적으로 유지보수를 어렵게 만든다. 이에 따라 개별 케이스를 무한히 늘리기보다 컴포넌트의 조합을 패턴으로 정의하는 방향으로 구조를 개선했다.

문제 해결 과정

1) 파일 구조 분리

초기에는 디자인 시스템을 하나의 파일에서 관리했지만, Primitive 토큰은 수정 빈도가 낮기 때문에 파일을 분기하며 기초 데이터를 안전하게 보호하고 상위 컴포넌트만 업데이트 및 배포할 수 있어 운영사고를 줄일 수 있다. 이를 통해 안정적인 라이브러리 관리와 작업 파일 간 책임 분리가 가능하다.

2) 과도한 컬러 토큰 세분화 개선

초기 설계 단계에서는 컴포넌트 컬러를 매우 세밀하게 관리하려 했고, 그 결과 디자인 토큰의 수가 과도하게 증가했다. 토큰이 많아질수록 명확성이 높아질 것이라 예상했지만, 실제로는 관리 포인트가 늘어나면서 오히려 사용 기준이 모호해지고 유지보수 리스크가 커지는 문제가 발생했다. 이에 따라 사용 빈도와 역할을 기준으로 토큰을 재정리하는 방향으로 개선했다.

3) 네이밍 규칙 통일

토큰과 컴포넌트가 증가하면서 용어 불일치가 작은 혼란을 만들기 시작했다. 이를 해결하기 위해 네이밍 규칙을 재정립하고 동일한 의미는 동일한 용어로 표현하도록 기준을 통일했다. 이 과정은 협업 효율뿐 아니라 AI 및 자동화 도구가 구조를 해석하는 데에도 중요한 기반이 된다.

4) MUI 구조와의 정렬

개발 환경과의 간극을 줄이기 위해 MUI의 토큰 및 컴포넌트 구조를 참고하며 설계를 진행했다. 디자인과 개발 구조를 최대한 유사하게 맞춤으로써 디자인 결과가 실제 구현 단계에서 자연스럽게 연결될 수 있도록 했다.

현재 상태와 앞으로의 방향

현재 디자인 시스템은 여전히 구축 과정에 있으며, 새로운 문제를 발견하거나 구조가 변경될 가능성도 남아 있다. 초기에는 완벽한 구조를 한 번에 설계하고자 했지만, 실제 프로젝트에서는 반복적인 시도와 수정 과정을 통해 점진적으로 개선해 나가는 방식이 더 현실적이라는 점을 배웠다. 초기 시행착오들은 결과적으로 더 안정적이고 확장 가능한 디자인 시스템을 만드는 기반이 되었다고 생각한다.

기술 변화와 AI 활용에 대한 관점

AI 기반 디자인 도구와 자동화 기술이 빠르게 발전하면서, 디자인 시스템 구축 과정 역시 점차 자동화될 가능성이 높아지고 있다. 따라서 특정 도구나 방식에 고정되기보다 프로젝트 방향성에 맞는 기술을 적극적으로 검토하고 활용하려는 태도가 중요하다. 또한 향후 기술 발전에 유연하게 대응할 수 있도록 초기 설계 단계에서부터 구조를 미리 정리해 두는 것이 필요하다. 결국 디자인 시스템은 완성된 결과물이 아니라, 협업과 기술 변화 속에서 지속적으로 발전하는 운영 체계에 가깝다고 생각한다.

Eykim