techlist.io
KREN
figma

피그마 패턴 라이브 (새 탭에서 열림)

figmadesign-systemsaccessibilitydesign-tokenscssrest-apiui-componentsdark-mode

UI3 개편은 Figma 내부 디자인 시스템이 오랜 성장 과정에서 파편화되었다는 문제를 드러냈고, 이를 해결하기 위해 Figma Pattern Library(FPL)를 처음부터 다시 구축하게 만들었습니다. 디자이너와 엔지니어가 페어 프로그래밍에 가까운 방식으로 협업해 디자인 의도와 코드 구현을 연결하고, 변수·REST API·테마 모드를 기반으로 일관되고 접근성 높은 제품 개발의 기반을 마련했습니다. FPL은 단순한 컴포넌트 모음이 아니라 조직 전체의 공통 언어이자 UI3를 확장하기 위한 단일 진실 공급원으로 설계되었습니다.

UI3가 드러낸 내부 디자인 시스템의 문제

  • Figma는 다른 팀의 디자인 시스템 구축을 돕는 제품을 만들고 있었지만, 내부 시스템은 오랜 기간의 급속한 성장과 제품 확장으로 분리되어 있었습니다.
  • 동일해야 할 컴포넌트가 서로 조금씩 달랐고, 연결이 끊긴 컴포넌트 인스턴스가 누적되었습니다.
  • UI3를 모든 Figma 제품에 적용하려면 새로운 화면 디자인만으로는 부족했습니다.
  • 여러 팀이 일관되고 효율적으로 작업할 수 있는 견고한 기반 시스템이 필요했습니다.

디자이너와 엔지니어의 페어 협업

  • Wayne Sun과 Tom Williams는 디자이너와 엔지니어로 구성된 5명의 소규모 팀을 만들었습니다.
  • 개발에서 한 사람이 코드를 작성하고 다른 사람이 실시간 검토하는 페어 프로그래밍처럼, 디자이너와 엔지니어가 긴밀하게 짝을 이루어 작업했습니다.
  • 디자이너는 시각적·사용자 경험 의도를 전달하고, 엔지니어는 이를 실제 컴포넌트와 토큰 시스템으로 구현했습니다.
  • 이 방식은 디자인 파일과 제품 코드 사이의 간극을 줄이고, 양쪽이 공유할 수 있는 시스템 언어를 만드는 데 목적이 있었습니다.
  • 그 결과 새로운 내부 디자인 시스템인 Figma Pattern Library(FPL)가 탄생했습니다.

스타일과 스프레드시트에서 변수 중심 구조로 전환

  • 기존 시스템은 Figma의 변수 기능이 등장하기 전에 만들어졌습니다.
  • 디자이너는 Figma 스타일을 사용했지만, 엔지니어는 별도의 Google Sheets에서 색상 토큰을 관리했습니다.
  • 스프레드시트가 제품 변경 사항을 즉시 반영하지 못하면서 디자인 파일과 실제 코드의 색상이 달라지는 문제가 발생했습니다.
  • 팀은 Figma 변수와 REST API를 활용해 디자인과 코드가 자동으로 동기화될 수 있는 구조를 만들었습니다.
  • 타이포그래피 변수를 새로 만들고, 기존 타이포그래피 스타일이 이 변수들을 별칭으로 참조하도록 구성했습니다.
  • 색상 스타일은 중앙 관리가 가능한 색상 변수로 마이그레이션했습니다.
  • 색상 변수에 CSS 정의도 추가해 Dev Mode의 검사 패널에서 개발자가 올바른 변수명과 코드 표현을 확인할 수 있게 했습니다.

Primitive와 Semantic 변수로 색상 체계 정리

  • 색상은 밝기와 어두움이 체계적으로 이어지는 color ramp를 기반으로 구성했습니다.
  • 기본 색상 단위인 Primitive 변수는 색상 계열별로 정리하고, 100부터 1000까지 단계적으로 구분했습니다.
  • 실제 UI 용도를 나타내는 Semantic 변수는 Primitive 변수를 별칭으로 참조합니다.
  • 예를 들어 특정 색상값을 직접 사용하는 대신 배경, 텍스트, 테두리 같은 의미 기반 변수로 연결할 수 있습니다.
  • Semantic 변수는 다음과 같은 테마와 제품별 모드를 지원하도록 설계되었습니다.
    • 라이트 모드와 다크 모드
    • Figma Design
    • FigJam
    • Slides
    • Dev Mode
  • 이 구조 덕분에 하나의 공통 컴포넌트가 제품이나 테마에 따라 색상만 자연스럽게 바꿀 수 있습니다.
  • Primitive 변수의 값을 수정하면 이를 참조하는 Semantic 변수와 컴포넌트에 변경 사항을 일괄 적용할 수 있습니다.

FPL의 역할

  • FPL은 UI3의 시각적 스타일을 정의하는 동시에, 이를 실제 제품에 일관되게 구현하기 위한 기술적 기반입니다.
  • 디자인과 엔지니어링을 분리된 단계로 처리하지 않고, 초기 설계부터 함께 검증하는 협업 모델을 채택했습니다.
  • 변수와 모드 기반의 구조는 여러 제품과 테마를 지원하면서도 공통된 사용자 경험을 유지하도록 돕습니다.
  • 중앙화된 토큰과 컴포넌트는 중복 구현과 미세한 시각적 차이를 줄이고, 향후 변경 사항을 더 빠르게 확산시킬 수 있습니다.

FPL 사례는 디자인 시스템을 단순한 UI 컴포넌트 저장소가 아니라 디자인 토큰, 테마, 코드 연동, 협업 방식까지 포함하는 조직의 공통 인프라로 다뤄야 한다는 점을 보여줍니다. 특히 디자인 파일과 코드가 서로 다른 토큰을 관리하지 않도록 변수와 자동 동기화를 도입하는 것이 규모가 큰 제품 조직에 실용적인 출발점입니다.