Figma Seoul 무대 위에 서기까지
함께 만든 디자인 시스템 그리고 Makers collective 회고
Figma Makers Collective : Seoul에서 우리 디자인 시스템팀이 사례 발표를 해달라는 제안을 받게 되었다. 제안을 받았을 땐 솔직히 망설였다. 우리 디자인 시스템은 아직 완성되지 않았고, 부족한 부분도 많았다.
아직 부족한 것이 많았고 만드는 과정에 있었기에 쉽게 결정하지 못했던 것도 사실이다.
하지만 팀원들과 이야기해 보았을 때,
“도전해 보고 후회하자. 어차피 우리의 목표는 오픈소스화고, 피드백을 받아야 할 때가 있을 거야. 그 시작이 지금일 수 있다"라는 결론이 모아졌다. 우리는 피드백에 목말라있었고, 그 첫걸음을 이 발표로 삼기로 했다.
우리 스쿼드의 리더가 'Figma to code : 디자인 시스템의 가치를 실현하는 방법'이라는 주제 스피커로 참여하게 되었고 함께 발표를 준비하며 자연스럽게 지난 디자인 시스템을 만들고 고도화된 과정을 톺아보게 되었다.
설레고 뿌듯했던 발표 현장사실 우리 회사에는 이미 디자인 시스템이 존재했다. 문제는 그것이 공식적으로 관리되는 시스템이 아니었다는 점이다. 관심 있는 개발자와 디자이너가 시간 날 때마다 새 컴포넌트를 추가했지만, 추상화 기준이나 컴포넌트 구조에 대한 합의가 없어서 점점 무분별하게 확장되고, 그레이존이 생기기 시작했다.
그러던 중 회사 차원의 조직 개편이 있었다. 다행히 우리 조직은 디자인 시스템의 중요성을 인식하고 있었기에 전담 디자인 시스템 팀을 만들 수 있었고, 그동안 시스템에 꾸준히 기여해 온 두 명의 프로덕트 디자이너 중 한 명이었던 내가, 그 팀의 일원으로 합류하게 되었다. 그리고 1년간 우리가 만들어온 수많은 시행착오 속에서, 가장 중심에 두고 고민했던 주제를 발표주제로 꺼내게 되었다.
디자인과 개발의 일치를 어떻게 만들어낼 것인가
전담 팀이 생기고 우리가 가장 먼저 한 일은,“디자인 시스템의 원칙”을 정하는 일이었다. 특히 우리처럼 팀 규모가 작고, 여러 제품을 동시에 다루는 조직에서는 명확한 철학 없이 컴포넌트를 정리하는 것이 오히려 팀의 혼란을 가중시킨다는 걸 그동안 뼈저리게 겪어왔다.
우리가 안고 있던 문제는 이랬다:
우리는 5개의 제품을 관리하고 있으며, 제품마다 사용하는 컴포넌트에 대한 요구가 달랐고, 어떤 기능은 이쪽에서만 필요하고, 어떤 건 다른 쪽에서만 쓰였다. 하나의 기준으로 모든 제품의 특징이나 사용성을 아우를 수는 없었다.
그래서 첫 번째 원칙은 유연성으로 정했다.
서비스의 특성에 맞게 디자인 시스템을 유연하게 적용할 수 있도록, 최소한의 일관성을 유지한 채 상황에 맞게 조정 가능해야 한다는 의미다. 그 또 최소한의 기준을 접근성으로 삼고 기능과 형태를 정의했다.
타 디자인 시스템의 포지션두 번째는 디자인과 개발의 동기화.
디자인 시스템의 존재 이유는 결국 업무의 생산성을 높이고, 커뮤니케이션 비용을 줄이는 것이다. 서로 다른 언어를 쓰는 디자이너와 개발자가 같은 기준 안에서 일할 수 있어야 했다.
이 원칙을 토대로 파운데이션과 컴포넌트들을 재 설계하기 시작했고, 디자인시스템 3.0, Vapor가 탄생하게 되었다.
구조를 잡기 위한 실험과 선택들
우리가 처음 시도한 건 컴파운드 패턴이었다. 컴파운드 패턴은 React 같은 컴포넌트 기반 프레임워크에서 자주 사용되는 구조 설계 방식으로, 하나의 컴포넌트가 여러 개의 하위 컴포넌트로 구성되어 있고, 이들을 유연하게 조합해서 사용할 수 있도록 만든다.
예를 들어 카드 컴포넌트를 만든다고 할 때, 다음과 같이 쓸 수 있다.
카드 컴파운드 패턴Figma에선 이 구조를 구현하기 위해 slot 개념을 도입했고, 디자이너는 Slot을 사용해 내부의 콘텐츠를 자유롭게 변경할 수 있었다. 이를 통해 디자인 측면의 유연성을 확보할 수 있었다.
Slot 예시동시에 우리는 Figma의 variant와 React의 props를 일치시키는 것도 시도했다.
디자이너가 variant를 조정하는 방식이, 개발자가 props로 상태를 정의하는 구조와 동일하다면 두 직군 간의 해석 차이를 최소화할 수 있을 거라 봤기 때문이다. 이 과정에서, 개발자에겐 불필요한 설정이 디자인에선 꼭 필요했고, 디자인 안에서만 존재하는 내용이 개발에선 의미가 없는 경우도 많았다. 그래서 우리는 이러한 설정 값들을 ‘Design only’ variant로 관리하게 되었다.
Design only로 관리하던 시절하지만 여기서 간과한 게 있었다. 디자이너와 개발자가 사용하는 도구는 본질적으로 다르다는 것이었다. slot을 과도하게 사용하다 보니, Figma 내에서 컴포넌트를 조작하는 일이 너무 복잡해지고 불편해졌다. 또 ‘Design only’가 무분별하게 늘어나게 되어 앱단 개발자들이 시안을 볼 때 Design only인지 판단해야 하는 불편을 겪게 되었다. 원칙에만 집중하다 보니 디자인 시스템이 생산성을 높이기보단 오히려 작업을 방해하게 되었던 것이다.
이때 우리는 다시 한번 중심을 되짚었다. 디자인 시스템의 기준은 무엇이어야 할까?
우리가 세운 대전제는 이거였다:
Figma = 진실의 원천(Single Source of Truth)
피그마는 절대적인 진실의 원천이 되고, 코드는 이를 따르되 완전히 일치가 가능한 영역과 부분적인 일치가 가능한 부분을 나눈다. 이 과정에서 파운데이션과 이미지, 아이콘은 완전한 일치가 가능한 영역으로 컴포넌트와 텍스트, 레이어는 부분적인 일치가 가능한 영역으로 분리했다.
이 정의를 기반으로 다시 한번 Variants와 Props를 맞춰가는 작업을 시작했고, 특히 Slot, Design only로 표현되는 요소들을 집중하게 되었다.
"Slot, Design only로 표현되는 요소들의 공통점은 없을까? "
이 과정에서 우리는 인터랙션 요소와 내부 콘텐츠 구조가 대부분 Design only라는 걸 발견하게 되었다.
컴포넌트의 레이어 구조Figma에서는 이 구조를 컴포넌트에 레이어를 쌓는 방식으로 표현했다.
특히 인터랙션과 콘텐츠 레이어는 별도의 컴포넌트로 제작해 조합했고, 이를 Nested instance로 구성함으로써 디자이너는 복잡한 Variants를 훨씬 쉽게 관리할 수 있었다.
인터랙션/콘텐츠 레이어Nested instance는 Figma의 Dev 모드에서 개발자에게는 보이지 않기 때문에, 디자인 전용 속성과 개발 연동 속성을 자연스럽게 분리할 수 있다는 장점이 있다. 덕분에 디자이너는 표현의 유연성을 유지하면서도, 개발자는 불필요한 정보에 혼란 없이 시스템을 사용할 수 있었다.
AI 시대, 왜 구조와 규칙이 더 중요해졌는가
우리는 지금, AI가 빠르게 프로덕트 제작 환경에 들어오는 시대에 살고 있다. 이미 많은 팀이 디자인 자동화, 코드 생성, 반복 작업 최적화에 AI를 도입하고 있다. 하지만 이 모든 자동화는 ‘일관된 구조와 명확한 규칙’ 위에서만 정확하게 작동한다.
디자인 시스템은 단순히 예쁜 컴포넌트를 모아둔 곳이 아니다. 디자인과 개발이 같은 언어로 일하고, 같은 기준으로 판단하게 만드는 프레임워크다. 그래서 우리는 지금처럼 컴포넌트의 구조를 정리하고, Variants와 Props를 맞추며, 의미 있는 규칙을 만드는 작업이 AI 시대에 더더욱 중요하다고 느낀다. AI는 룰을 잘 따르지만, 혼란 속에서 정확하게 판단하진 못한다. 결국 시스템이 정돈되어 있어야, AI도 진짜 협업자가 될 수 있다.
그래서 우리는 다음을 준비하고 있다. 디자인 시스템을 도입하는 것만으로도 개발 생산성은 꽤 올라간다. 하지만 우리는 거기서 멈추지 않기로 했다. 현재 우리는 이 디자인 시스템을 실제 코드와 문서로 연결하고, 디자인과 개발이 실시간으로 연결될 수 있는 서버 구조, MCP 서버를 준비 중이다.
궁극적으로는 디자이너가 만든 컴포넌트를 개발자가 거의 그대로 사용할 수 있도록, 디자인에서 정의한 규칙이 코드로 자연스럽게 전달될 수 있도록 만드는 것이 목표다. 시스템이 정돈되면, 사람은 더 창의적인 일에 집중할 수 있지 않을까? 그게 우리가 디자인 시스템을 정교하게 만들고, 계속해서 다듬어 나가는 이유이자 방향성이 될 것이라고 생각한다.
우리가 배운 것들
우리가 겪었던 고민과 실험은 더 많은 것들이 있었다. 이미지, 아이콘의 일치/ 텍스트, 레이아웃은 어떻게 관리하고 있는가 등등 더 자세히, 많이 이야기하고 싶었지만 발표 시간의 한계가 있어 덜어내게 되었다.
대신 우리의 고민이 담긴 내용들을 Figma Community에 공개했다. 우리의 고민이 담긴 컴포넌트들이 궁금하다면 아래 링크에서 직접 확인해 보기!
이번 글에서는 Figma Makers Collective : Seoul에서 발표한 내용 전체를 다 담지는 못했다. 짧은 시간 안에 전달하기 어려운 구조적 맥락이나 실제 작업 사례들이 발표에서는 더 많았기 때문이다. 더 자세한 궁금하다면, 발표 자료를 참고해 보면 좋겠다.
1년 동안 디자인 시스템을 구축하고 운영하는 경험을 통해 몇 가지 중요한 사실을 배웠다.
디자인 시스템은 개발자와 디자이너 사이의 밀접한 커뮤니케이션 없이는 작동하지 않는다.
서로의 도구와 언어를 이해하려는 노력이 있어야 한다.
디자인 시스템을 만든다는 건 언어를 새로 만드는 일과 비슷해서 어렵고 막막하지만, 어떤 규칙이 딱 맞아떨어지는 순간의 쾌감은 아주 강렬하다.
그런 순간들을 함께 겪고, 끝까지 고민하며 시스템을 함께 만들어준 우리 팀원들에게 진심으로 고맙다.
그 덕분에 이번 Figma Makers Collective 행사는 단순한 발표 이상의 의미가 있었다.
