피그마 Makers Colletive:Seoul 후기
디자인시스템 팀의 고민과 플랫폼 디자이너의 회고
지난 5월 27일, 피그마 Makers Colletive: Seoul 행사가 열렸습니다.
그리고 저희 팀의 리더가 'Figma to Code: 디자인 시스템의 가치를 실현하는 방법'이라는 주제로 스피커로 참여하게 되어 팀원으로서 행사에 참여하게 되었습니다. 그 과정에서 우리 디자인 시스템에 대한 약 500명의 참여자분들의 반응을 살펴볼 수 있었습니다. 팀원이자 플랫폼 디자이너로서 후기를 공유합니다.
저희 팀은 사내에서 디자인 시스템을 만들고 있고 저는 플랫폼 디자이너 역할로 함께하고 있습니다. 사실 제가 속한 조직은 CDO가 계시기 때문에 비교적 디자인 시스템을 빠르게 도입하고 활용해 왔는데요. 하지만, 스타트업 조직인만큼 조직의 규모, 팀과 제품이 늘어나며 으레 알려진 방식으로 디자인 시스템을 활용하기에 불편함이 생겼었습니다.
그래서 작년부터 디자인 시스템만을 담당하는 조직이 구성됐고, 평소 디자인 시스템에 대한 관심이 많던 저는 비공식(?)적으로 기존 소속된 팀의 제품 디자인 업무에 더해 겸업을 시작하게 됐습니다. 그렇게 1여 년간 개발자 넷, 디자이너 둘이 모여 조직의 문제를 해결하기 위한 새로운 디자인 시스템을 고안하는데 머리를 싸맸었습니다.
그리고 그 과정에서 Shadcn, Radix, 당근 Seed, 원티드 라이브러리 등 많은 시중 디자인 시스템을 찾아보며 유연함이라는 컨셉 하에 토큰 기반의 디자인 시스템을 만들어왔습니다.
저희 팀이 고민했던 문제는 아래와 같습니다.
어떻게 여러 제품, 비즈니스에 적합한 유연한 구조를 만들 수 있을까?
개발과 디자인의 일치를 통해 효율을 높일 수 있지 않을까?
그리고 이런 고민을 푸는 과정에서 '애초에 개발과 디자인 도구가 다른데 완전한 일치가 가능할까?'라는 의문을 갖게 되고, 개발에서 흔히 언급되는 Single Source of Truth 즉 SSOT 개념을 도입했습니다. 피그마를 단일 진실의 원천으로 삼고 코드가 이를 따르는 방향으로 설계하되, 완전한 일치를 이룰 수 있는 영역과, 부분적인 일치가 유리한 부분을 나눴습니다.
예를 들어 컬러, 둥글기, 크기와 같은 디자인 토큰은 Figma Variables 기능을 통해 관리하며 완전히 코드와 일치시켰습니다. 그리고 앞서 고민으로 언급했던 유연성 문제의 해결 방안으로 Variables mode를 활용해 특정 모드에 따라 토큰 값이 전환될 수 있도록 했습니다. 이를 통해 초등 타겟의 제품에선 더 크고 둥글둥글한, 개발자 타겟의 개발 도구 제품에선 밀도 있는 UI를 각각 제공할 수 있게 되었습니다.
Variables Mode 예시(Appearance 영역에서 특정 퍼센트 선택 시 값이 변경된다.)
mode 적용 예시(사내에서는 Primary 컬러 변경도 지원하고 있다.)반면에 컴포넌트 설계의 경우 코드와 동일하게 만드는 데 어려움을 겪었는데, 개발 도구에선 속성(React Props)으로 정의하지 않는 Hovered와 같은 상태가 피그마에선 시각적인 차이가 발생하기에 Variants로 표기해야 하는 등 DEV Only, Design Only와 같은 예외 케이스들이 생겨났었습니다.
이런 예외 케이스를 막기 위해 부분적인 SSOT 영역으로 합의하고 규칙을 정했습니다.
접근성이나, 형태에 영향을 주지 않는 기본 기능은 개발 도구(Props)에만 표기를, 개발 로직에 의해 적용되는 disabled, invalid와 같은 논리적 상태와 시각적 차이가 발생하는 상태는 피그마와 개발(Variants=Props)의 완전한 일치를 하는 것으로 정의했습니다.
여기에 더해 앞서 언급한 Hovered, Focused와 같이 상호작용에 의한 상태나 디자이너의 편의를 위해 필요한 요소는 개발에서 정의하지 않는 기능임으로 별도 레이어로 구분해 관리하는 것으로 합의했습니다.
별도 레이어가 될 요소는 컴포넌트로 만들어 복사본(Instance)을 하위 레이어로 포함시키는 방식으로 진행했습니다. 이렇게 함으로써 피그마에서 Nested Instance 기능으로 디자이너가 작업 시 하위 레이어의 속성을 쉽게 변경할 수 있되, DEV Mode로 확인하는 개발자는 해당 속성이 노출되지 않아 오직 개발과 일치한 상위 컴포넌트의 Variants만을 확인할 수 있습니다.
Button 컴포넌트의 레이어 구조예를 들어 버튼은 상호작용 상태를 가지고, 내부에 아이콘과 함께 사용할 수 있습니다. 이때 코드에선 상호작용 상태를 정의하지 않고, 아이콘 또한 구현하지 않고 React Children을 사용합니다. 그래서 디자이너와 개발자의 효율적인 의사소통을 위해 상호작용 상태를 정의한 InteractionLayer와 내부 요소를 정의한 ContentLayer는 디자이너는 조작할 수 있지만 개발자는 보이지 않도록 분리했습니다.
디자인 모드와 Dev 모드에서 확인하는 버튼 속성 이런 방식을 통해 기존엔 버튼 컴포넌트의 Variants로 모두 제공해야 했던 상호작용 상태와 아이콘 유무를 분리해 관리할 수 있어 Variants 개수를 줄이고 컴포넌트를 경량화할 수 있었습니다.
(디자인 시스템 파일을 관리해 본 디자이너라면 파일 경량화의 중요성을 공감할 수 있을 겁니다..)
이 외에도 저희 조직은 AI에 진심이라 MCP를 활용해 우리 디자인시스템을 학습시킴으로써 업무 효율을 높이기 위한 시도를 하고 있고, 이 내용을 공유할 수 있었습니다.
그리고 발표 현장 반응은 꽤나 좋았는데요. 사진을 찍으시는 분들도, 객석에서 공감과 감탄의 반응도 들을 수 있었습니다. 그리고 공감하시는 분들을 통해 우리가 했던 고민이 의미 없는 일이 아니었다는 응원을 받을 수 있었습니다.
관심사가 맞는 동료와 하나의 목표를 향해 함께 전력으로 최선을 다하는 경험은 정말 소중하다고 생각합니다. 이 행사뿐 아니라 팀으로 함께하는 내내 속된 말로 '개쩌는 디자인 시스템을 만들자'라는 목표를 공유하며 함께 달려온 경험이 저의 커리어에 큰 전환점이 되었다고 생각합니다.
앞으로의 저는 플랫폼 디자이너로 더 성장하기 위해 이직을 택했지만, 현 회사에서 마지막 업무로 이 행사를 함께할 수 있었음에 감사한 마음을 남기며 마칩니다!
저희의 고민이 담긴 디자인 시스템은 피그마 커뮤니티에서 확인할 수 있습니다. 많은 관심 보내주시길!
https://www.figma.com/community/file/1508829832204351721/vapor-design-system
