프리랜서 디자이너 5년 차에 접어들던 어느 날, 30장이 넘는 화면의 다크 모드 시안을 납품했다가 개발팀에게서 "컬러가 화면마다 달라요"라는 피드백을 받은 적이 있습니다. 밤새 버튼 배경색을 바꿔놓고 그 위 텍스트 컬러는 깜빡한 것이었습니다. 그때부터 피그마 Variables를 제대로 써야겠다고 마음먹었고, 직접 써봤더니 작업 방식이 완전히 달라졌습니다.
컬러 시스템을 구조부터 다시 짠다는 것
저도 처음엔 디자인 토큰 방식으로 버텼습니다. 여기서 디자인 토큰(Design Token)이란 컬러, 타이포그래피, 간격 같은 디자인 속성을 이름과 값으로 저장해두는 방식으로, 일종의 디자인 변수 사전이라고 보면 됩니다. 라이트 모드 시안을 완성한 뒤 다크 모드는 수작업으로 컬러를 하나씩 교체했는데, 화면 수가 늘어날수록 불일치 오류가 기하급수적으로 쌓였습니다.
피그마 Config 2023 이후 정식 도입된 Variables 기능은 이 문제를 구조적으로 해결합니다. 핵심은 컬러를 두 층으로 분리하는 데 있습니다. 먼저 베이스 컬러(Base Color)는 팔레트 그룹에 원색 그 자체를 저장합니다. 이를테면 #1A73E8 같은 파란색을 'base-blue'라는 이름으로 등록해두는 것입니다. 그리고 시맨틱 컬러(Semantic Color)는 그 베이스 컬러를 참조하되, 용도 기반의 이름을 붙입니다. 여기서 시맨틱 컬러란 색상 자체가 아닌 색상의 역할과 용도를 이름에 담은 변수를 의미합니다. 예를 들어 'bg-surface', 'text-active', 'theme-primary' 같은 식입니다.
이 구조가 왜 중요하냐면, 나중에 테마 컬러를 파란색에서 초록색으로 바꾸고 싶을 때 베이스 컬러 하나만 수정하면 그 값을 참조하는 시맨틱 컬러 전체, 나아가 시안 전체가 자동으로 바뀌기 때문입니다. 제가 직접 써봤는데, 30장짜리 시안의 테마 컬러를 바꾸는 데 5초도 걸리지 않았습니다.
텍스트 위계와 투명도 체계
텍스트 컬러 위계를 투명도로 관리하는 방식도 실무에서 자주 사용합니다. 예를 들어 가장 강조되는 텍스트인 'text-active'는 불투명도 85%, 보조 텍스트인 'text-muted'는 45%로 설정하는 방식입니다. 라이트 모드에서는 다크 톤 기반으로, 다크 모드에서는 화이트 톤 기반으로 같은 투명도 체계를 적용하면 모드가 바뀌어도 텍스트 위계 구조가 자연스럽게 유지됩니다.
피그마 Variables에서 컬러 시스템을 설계할 때 지켜야 할 핵심 원칙을 정리하면 다음과 같습니다.
- 베이스 컬러와 시맨틱 컬러를 반드시 분리하여 관리한다
- 시맨틱 컬러는 용도 기반 네이밍(bg-surface, text-active 등)을 사용한다
- 변수명은 소문자 영문과 대시(-) 조합으로 통일하며, 언더바와 한글은 사용하지 않는다
- 헥스코드나 RGBA 직접 입력 대신 시맨틱 컬러 변수를 참조하도록 작업한다
- 라이트/다크 두 모드를 Variables 컬렉션 내에서 동시에 관리한다
실제로 컬러 가이드라인에서 헥스코드를 직접 사용하지 말고 시맨틱 컬러를 참조하라는 원칙이 중요한데, 이 습관이 자리 잡히면 이후 유지보수 비용이 눈에 띄게 줄어들었습니다. 컬러 가이드 문서를 별도로 만들 필요가 없어지는 건 보너스고요.
디자인 시스템 구축 관련 업계 동향을 보면, 컴포넌트 기반 디자인 시스템에 변수 레이어를 도입하는 방식이 점차 표준으로 자리 잡고 있습니다. 실제로 W3C의 Design Tokens Community Group에서도 이러한 토큰 계층화 방식을 공식적으로 논의하고 있으며, 관련 표준 문서를 지속적으로 업데이트하고 있습니다.
개발자 핸드오프가 달라지다
피그마 Dev Mode는 개발자가 시안을 열었을 때 디자인 속성을 코드 형태로 확인할 수 있는 기능입니다. 여기서 Dev Mode란 피그마에서 개발자가 디자인 스펙을 직접 열람하고 CSS나 코드 속성을 추출할 수 있는 전용 뷰를 말합니다. 이 Dev Mode에서 Variables가 코드로 어떻게 표시되는지가 핸드오프의 핵심입니다.
변수명을 'bg-surface'로 지정했다면, 개발자는 Dev Mode에서 그 이름을 그대로 확인할 수 있습니다. 즉, 디자이너와 개발자가 같은 변수명으로 대화할 수 있게 되는 것입니다. 제 경험상 이건 단순한 편의 기능이 아닙니다. 디자이너가 'bg-surface'라고 부르는 것과 개발자가 CSS에서 --bg-surface라고 쓰는 것이 1:1로 대응되면, 디자인과 구현 사이의 해석 오류가 사라집니다.
변수명 규칙을 처음부터 개발팀과 합의하는 것도 이 과정에서 자연스럽게 이루어집니다. 소문자 영문, 대시(-) 구분, 언더바와 한글 금지라는 원칙은 CSS 변수 작명 관행과도 일치하기 때문에 개발자 쪽에서도 거부감이 없었습니다.
Variables에는 조준 아이콘 기능도 있는데, 특정 토큰이 시안 내 어느 요소에 적용되어 있는지 화면에서 바로 확인할 수 있습니다. 제가 직접 써봤는데, 컬러 매칭 검증 작업에서 이 기능이 특히 유용했습니다. "이 변수가 지금 어디에 쓰이고 있지?"를 손으로 따라가지 않아도 되니까요.
다만 아쉬운 점도 있습니다. 베타 버전 특성상 Variables 연결이 간혹 끊기는 버그가 존재하고, 다크 모드 컬러값은 여전히 직접 손으로 입력해야 합니다. 라이트 모드 컬러를 기반으로 다크 모드 값을 자동 제안해주는 기능이 있었으면 했는데, 아직 그 수준은 아닙니다. 이 점에서는 일반적으로 Variables가 모든 작업을 자동화해준다고 알려져 있지만, 실제로는 초기 설정에 상당한 시간이 필요하다고 보는 게 맞습니다.
피그마의 공식 커뮤니티 사이트인 Figma Community에서도 다양한 Variables 활용 템플릿과 컬러 시스템 예시를 공개하고 있어, 시작점을 잡는 데 도움이 됩니다.
Variables를 제대로 구축해두면 라이트/다크 전환이 원클릭으로 가능해지고, 체감상 작업 시간이 70% 이상 단축되는 효과가 있었습니다. 컬러 스펙 문서를 따로 만들 필요가 없어진다는 것만으로도 충분히 도입할 이유가 됩니다.
다크 모드 대응이 처음이거나, 매번 수작업으로 컬러를 교체하다 지친 분이라면 Variables 컬렉션을 하나 만들어 베이스 컬러부터 채워보시길 권합니다. 처음 설정이 조금 번거롭더라도, 한 번 구조를 잡아두면 이후 프로젝트에도 재사용할 수 있어 복리로 시간을 돌려받게 됩니다.