'언어'에 빗대어 보는 Variable
Variable의 낭만적 해석
[목차]
1. Style과 Variable을 비교해보자
2. 언어에 빗대어보는 Variable
3. 인사이트
Hello, Config 2023! 2022년의 컨피그를 보면서 바리언트 기능을 꼼꼼히 분석했던 것이 엊그제같은데 벌써 일년이 지났다. 그 사이 피그마는 전진 또 전진, 이제는 정말 모든 사람이 알고 배우고 있는 ‘프로덕트 디자인 툴’의 대표명사가 되지 않았나 싶다.
이번에 config 2023에서 선보였던 기능 중 가장 큰 이슈는 아무래도 ‘variable’의 등장일 것이다. 기본 지식이 전혀 없었던 나로서는 ‘이게 대체 스타일 지정이랑 뭐가 다른데?’ 싶었지만, 곧 다른 디자이너 분들의 설명을 살펴보다 이것이 ‘시멘틱 컬러’나 ‘디자인 토큰’과 연결되어있는 개념이라는 것을 알 수 있었다.
그래서 내가 이해한 차이점을 아주 쉽게 푸는 것으로 글을 시작한다.
?? : 다 똑같은 거 아닌가요?1. Style과 Variable을 비교해보자
(1) 스타일 지정 vs Variable
지금까지 우리가 피그마에서 해왔던 스타일 지정은 아래와 같은 과정이다.
이렇게 이름이 주어진 '보라색' 스타일은 디자이너의 주관에 의해서 버튼에, 텍스트에, 배경 등에 쓰이게 되는데, 이 때 '보라색'이라는 이름은 사실 아무런 의미가 없다. 사실은 #737FF라는 숫자를 단순히 알기 쉬운 이름으로 치환하고 정해놓은 것 뿐. 시스템이라고 하기엔 뭣하다.
반면 Variable을 활용하는 디자인 토큰화는 아래와 같은 과정을 거친다.
색상에 이름을 붙인 뒤 바로 컴포넌트에 연결하는 것이 아니라, 컴포넌트의 역할과 목적을 지정하고, 그 '역할과 목적'을 중간다리 삼아 연결한다. '컴포넌트에 연결된 색상'의 관계가 아니라 '컴포넌트의 목적에 연결된 색상'의 관계가 성립되는 것. 즉 '메인카피에 쓰는 보라색'이라는 의미있는 이름이 붙여진다.
(2) Variable만 할 수 있는 일?
여전히 이게 무슨 차이가 있는지 헷갈리긴 한다. 스타일은 할 수 없지만, Variable이 할 수 있는 일을 알아보자.
스타일 지정의 한계스타일만을 사용한 경우 하나의 색상값에 다양한 컴포넌트가 직접적으로 붙게되는데, 같은 색상값에 묶여있기 때문에 컴포넌트를 분리해서 변경하기가 어려워진다. 이게 문제가 되는 이유는, '같은 색상을 썼다고 같은 목적을 가지는 것이 아니기 때문'이다. 아래 이미지를 보자.
스타일 지정의 한계 2위와 아래 텍스트 모두 #333333이라는 동일한 색상값을 사용했지만, 위의 텍스트는 '흰 바탕 위에서 잘 보이기 위해', 그리고 아래 텍스트는 '보라색 바탕 위에서 잘 보이기 위해' 사용했다. 그런데 이러한 목적을 스타일 지정으로 표현하기 어려웠기 때문에, 스타일에 지정된 색상을 바꾸게 되면 컴포넌트가 목적을 이루지 못하는 경우가 생긴다. (2번처럼.) 둘은 우연히 사용하는 색이 같았을 뿐, 그 목적은 완전히 달랐기 때문이다.
목적을 제대로 반영하려면 3번과 같이, 색상이 아닌 목적에 근거한 색상변경이 따로따로 적용되어야한다.
(3) Variable은 목적과 맥락이 더해진 Style이다.
Variable을 사용하면, 같은 색상값을 사용했더라도 각각의 목적에 따라 분기처리할 수 있다. 같은 검은색을'메인카피에 쓰는 검은색', '버튼에 쓰는 검은색' 등으로 분리해놓을 수 있는 것. 따라서 연결되어있는 색상을 변경하더라도 '같은 목적'을 공유하는 색상만 골라서 변경할 수 있게 된다.
결론적으로 스타일 지정이 디자인 프로젝트에서 어떤 색상과 값을 사용할지를 지정하는 편의 기능이라면, variable은 그렇게 정의한 디자인 요소와 실제 사용되는 컴포넌트를 연결하고 있는 '목적'을 논리적으로 정의해야만 유용하게 사용할 수 있는 심화 기능인 셈이다.
여기까지가 Practical한 설명이었고, 낭만적인 서술로 넘어가보자.
2. 언어에 빗대어보는 Variable
(1) 문자, 단어, 문장, 그리고 언어까지
단순한 숫자의 나열이었던 hex에서, 공통된 의미를 가지는 스타일을 지정하고, 맥락과 목적을 고려하여 점점 세세하게 조립되는 과정은 내게 글자로부터 문장, 문장으로부터 언어로 발전하는 과정을 상상하게 한다. 같은 색상을 사용하지만 다른 논리적 색상으로 분화되는 variable은 마치 같은 문자를 사용하더라도 목적과 환경, 맥락, 문화에 의해 다양하게 분화하는 언어와 비슷한 것 같다.
색상은 하나지만, 목적은 여러개인 Variable과 유사하다(2) 문자부터 단어까지, 스타일 지정
이름을 불러주었을 때 #7371ff는 나에게로 와서 purple-40이 되었다스타일 지정은 흩어져있는 글자들을 모아서, 최소의 의미 소통을 위해 하나의 단어로써 이름을 붙이는 것과 같다.우리가 알고 있는 hex값은 ㄱㄴㄷ와 같은 낱자로 생각하고, 이것들을 잘 조합해서 만든 색상값에 이름을 붙이면 디자이너가 활용하는 '단어'가 된다. '검은색', '파란색'과 같은 단어 정도가 되겠다.
단어에는 뜻이 있다. '엄마', '아빠'라는 객체, '좋다' '생기다'라는 감정이나 현상 등을 내포하고 있지만 서로 연결되지는 않는다. '엄마' '아빠' '좋다'라고 나열해도, 엄마가 아빠가 좋다는 것인지 아빠가 엄마가 좋다는 것인지, 아니면 발화자인 내가 엄마와 아빠가 좋다는 것인지 정확한 의미는 알 수 없다.
즉 낱자와 낱말로도 의사소통을 할 수는 있지만, '사실과 상황'을 기계적으로 나열하고 전달하는 데에 그칠 뿐, 무언가를 형용하거나 주장하는 등, 방향성있는 담화를 진행할 수는 없는 것이다. 효과적으로 논쟁하고 공유하기 위해선 위에서 만든 단어를 조합해야하고, 단어를 조합하기 위한 기초로는 '의도'와 '방향성'이 있어야한다.
(3) 문장부터 언어까지, Variable
이러한 연유로 variable이 등장한 셈이다. variable은 스타일 지정을 통해 만들어두었던 '단어'들을 목적 중심으로 결합해, '문장'을 생성한다. '잘 보이게 하기 위한 검은색', '브랜드 칼라를 반영한 파란색' 등이다. 여기서 그치지 않고 컴포넌트의 형태, 상태, 위치, 테마등을 더하여 문장의 선명도를 높인다.
무엇보다 중요한 것은 '목적'. 목적이 없는 상태에서 문장을 만들 수는 없다.이렇게 단어를 목적에 따라 알맞게 연결하면 문장이 완성된다. '모바일 화면의 a테마에서 가장 상단에 위치하는 cta버튼 백그라운드에 사용되는 색은 purple40이며, 그 헥스값은 #7371FF입니다.'와 같은 문장. 이러한 '문장'들이 중첩되면서 규칙화되면 '시스템'이 되고, 비로소 '언어'로써 작동하게 되는 것.
그래서... 이걸 언제 쓰지?
솔직히 이런 개념이 내 사랑 피그마에 등장해서 신나긴하다. 빠르게 실전에서 사용해보고 싶긴한데, 배우면 배울수록 웬만큼 큰 규모의 프로덕트가 아니고서야 이걸 체계적으로 설계해 볼 기회가 있을까 싶은 생각이 들기도 한다. 디자이너 한 명에 개발자 둘 붙어있는 작은 팀이라면, 페이지가 적은 프로덕트라면 이 기능까지가 구태여 필요할까? 시시때때로 프로덕트가 바뀌어야하는 긴급한 상황이라면 더더욱 어려울 것 같고. 심지어는 몸짓발짓해가면서 바꾸는 게 더 빠른 상황도 있을 것 같다.
손가락질 vs 말로 하기
그냥 손가락질 치니까 나와서 가져왔어요'지적확인 환호응답'이라는 개념이 있다. 운송, 건설, 산업 등에서 중요한 업무를 처리할 때 서로의 방향성이 어긋나지 않도록 손가락으로 가리키고, 대상을 이야기하고, 확인 후 응답하는 신호체계다.
미국의 언어학자 '마이클로 토마셀로'는 '생각의 기원'에서 손가락 가리키기를 통한 의사소통이 인간 언어의 기초가 되었다고 말한다. 사슴 사냥이라는 공동의 목적이 생기려면, 사슴을 사냥한다는 목적이 있어야하고, 그것이 상대방과 동일해야하며, 서로가 서로의 목적을 이해하고 있어야만한다. 이를 '공동지향성'이라고 말한다. 언어의 본질은 공동의 목표를 짚어내는 것이라고 할 수 있다.
이 얘기를 왜 하냐면, 나는 손가락 가리키기조차 제대로 못하는 경우가 허다하기 때문이다. 이런 상태에서 섣불리 체계를 만들어내려다가 고꾸라진 경험도 잔뜩 있다. 쌓았다 무너뜨리고, 쌓았다 무너뜨린 언어가 얼마나 되는지. 그런 시간들을 거치고 나니, 언어를 만들기 이전에 개발자와 기획자, 디자이너가 몸짓을 통한 투박한 대화를 거쳐 그들만의 문법을 축적하는 시간이 필요하다는 것을 깨닫게 되었다. 그런 의미에서 나는 잠시 variable을 실천하기보다는 지식의 영역으로 남겨두려고한다. 아직 나는 몸짓발짓으로 고군분투하며 배워갈 때라고 생각하기 때문.
그럼에도 불구하고 언젠가는 사용하게 될 variable을 언어의 영역에 빗대어 생각하면서, 내가 생각하는 프로덕트 디자이너의 역할이 선명해졌다. Variable은 프로덕트 디자이너에게 색상을 복잡하게 라벨링하는 권한이 아닌, 제품과 팀이 사용할 '언어'를 디자인하는 책임을 부여한다. 결국에는 프로덕트 디자이너는 페이지를 그려내는 디자이너가 아니라 나, 우리, 그리고 제품의 언어를 설계하는 디자이너인 것이다. 언젠가 페이지 하나하나의 디자인을 방어하지 않고, 나, 혹은 우리 팀의 언어를 방어할 수 있는 디자이너가 되고 싶다는 생각을 하게 된다. 지금은 아니더라도. 언젠가는.
