다크 모드 밝히

Figma의 다크 모드는 색상만 어둡게 바꾸는 단순한 프런트엔드 작업이 아니라, 제품 전반의 UI 상태와 접근성, 향후 테마 확장성을 함께 해결해야 하는 시스템 구축 프로젝트였다. Figma는 사용자 요청에 대응하는 동시에 시각적 접근성을 높이고, 새로운 기능이 처음부터 다크 모드를 지원하도록 만드는 것을 목표로 했다. 이를 위해 전체 UI를 조사하고 여러 팀의 공통 컴포넌트를 체계적으로 refactoring하는 방식을 택했다.

다크 모드가 필요했던 이유

• 다크 모드는 Figma 사용자들이 가장 많이 요청한 기능 중 하나였다.
• 야간 작업 시 밝은 화면으로 인한 불편을 줄일 수 있었다.
• 시각 장애나 특정 시각적 질환이 있는 사용자에게 다크 모드가 더 읽기 쉬울 수 있었다.
• 색상 대비는 WCAG 접근성 지침의 핵심 요소이므로, 다크 모드는 Figma의 “디자인을 모두에게 accessible하게 만든다”는 목표와도 연결됐다.
• 일반적으로는 라이트 모드가 시각적 수행 능력에 유리하지만, 백내장 등 특정 질환이 있는 사람은 다크 모드에서 더 나은 성능을 보일 수 있다.

단순한 색상 교체가 아니었던 이유

• 처음에는 모든 밝은 색을 어두운 색으로 바꾸면 된다고 생각했지만, 실제로는 UI의 상태와 맥락을 함께 고려해야 했다.
• 다크 모드 전환 시 다음 요소를 결정해야 했다.
  • 밝은 편집기 패널을 어둡게 바꾸고 아이콘과 텍스트를 밝게 할지
  • 라이트 모드에서도 이미 어두운 툴바와 메뉴를 그대로 유지할지
  • 캔버스 배경처럼 사용자가 만든 콘텐츠까지 테마에 따라 변경할지
  • C++ 렌더링 엔진이 그리는 투명도 격자 등의 색상도 변경할지
• Figma 전체가 아니라 편집기 등 특정 영역만 지원할지에 대한 제품 범위 결정도 필요했다.

전체 UI 감사와 범위 설정

• 개발에 앞서 각 팀원이 Figma 앱의 UI 표면을 조사하고, 다크 모드로 재구성하기 어려운 부분을 파악했다.
• 프로젝트 시작 당시 Figma에는 10개의 제품 엔지니어링 팀이 있었고, 각 팀이 모달, 패널, 툴바 등 주요 UI 영역을 담당했다.
• 하나의 UI 요소도 여러 상태와 복잡한 예외 상황을 포함할 수 있었다.
  • 특정 조건에서만 나타나는 상태
  • 여러 뷰와 화면
  • 숨겨진 서브모달과 드롭다운
• 따라서 표면적으로 보이는 화면뿐 아니라 모든 상태와 엣지 케이스까지 다크 모드 범위에 포함해야 했다.

확장 가능한 테마 시스템의 목표

• 목표는 현재 다크 모드만 구현하는 것이 아니었다.
• 두 가지 장기 목표를 세웠다.
  • 개발자가 새로운 기능을 다크 모드 지원과 함께 바로 만들 수 있도록 하기
  • 향후 Figma와 FigJam에 새로운 테마를 쉽게 추가할 수 있도록 하기
• 공통 UI 컴포넌트는 다크 모드를 지원해야 하지만, 다크 모드가 적용되지 않는 화면에서는 기존 동작과 외관을 유지해야 했다.
• 구현 과정에서 기존 기능을 깨뜨리지 않는 회귀 방지(regression-proof) 구조가 중요했다.
• 새로운 엔지니어의 온보딩과 향후 예측하지 못한 요구사항 대응까지 고려해, 적용과 유지보수가 쉬운 방식이 필요했다.

프로젝트 규모가 만든 엔지니어링 과제

• Figma의 UI가 여러 팀에 분산되어 있어 소수의 엔지니어만으로 전체를 처리하기 어려웠다.
• 각 팀이 소유한 컴포넌트와 화면을 공통 원칙에 맞게 바꿔야 했다.
• 단순히 색상 값을 교체하는 것이 아니라, 컴포넌트가 어떤 표면과 상태에서 사용되는지까지 체계적으로 분리해야 했다.
• 이 경험은 개별 기능을 추가하는 방식보다, 제품 전체에서 재사용할 수 있는 디자인·엔지니어링 시스템을 구축하는 접근이 필요하다는 점을 보여준다.

다크 모드처럼 겉보기에는 간단한 기능도 실제로는 UI 상태, 접근성, 팀 간 소유권, 공통 컴포넌트, 향후 확장성을 함께 설계해야 한다. 유사한 기능을 구현할 때는 특정 화면의 색상부터 바꾸기보다 전체 범위를 먼저 감사하고, 테마 토큰과 공통 컴포넌트를 중심으로 회귀를 방지할 수 있는 구조를 마련하는 것이 바람직하다.