다크 모드의 가장 큰 장애물은 바로
만드는 것이 쉽다고 생각하는 것이다
Figma에서 매년 개최하는 Config 콘퍼런스에서 올해인 2023년에도 많은 주제들로 나왔고(config 2023 링크), 작년인 2022년에도 많은 주제들이 나왔는데, 작년 Config 2022 영상 중 가장 흥미롭게 봤던 것은 'The hardest part about building dark mode is that people think it’s easy'라는 라는 제목의 Figma팀 발표입니다. (해당 영상)
처음에 제목을 보고 '그렇지, 다크 모드 만드는 거 어렵지..' 생각하며 근데 무엇이 그렇게 어렵다는 것일까? 피그마 팀에서는 어떻게 다크 모드를 만들었나 하고 영상을 봤는데 알고 보니 그저 다크 모드를 추가하는 것이 아닌 컬러 시스템의 기반을 재정의하는 내용이었어요.
정말 제목처럼 다크 모드의 가장 큰 장애물은 그저 모드 하나를 추가하면 된다고 생각하는, 즉 쉽다고 생각하하지만 그게 아닐 때 설득하는 것이 가장 어려웠겠구나 싶었습니다.
내용이 좋기도 했고, 실제로 이 세션을 바탕으로 제가 속해있는 회사 디자인 시스템의 컬러를 design token으로 적용하기도 하고 많은 참고가 됐기에 해당 세션의 내용을 요약해 글로 작성해 보았습니다.
솔직히 다크모드 만드는 거 짱쉬울줄 알았다. 심지어 피그마 디자이너분 중 한 분이 미디엄에 '다크모드 하루 만에 만들기(Dark theme in a day')라는 글로 포스팅도 작성했었다.
대부분의 사람들은 다크모드 만들자! 하면 가장 기본적인 접근으로는 hue를 다크 모드에 맞게끔 전환하고, 그렇게 컬러를 변경하는 것이다. (이게 젤 쉬운 방식이니까)
Figma에서는 다크 모드를 만들기로 했을 때 이미 프로덕트 디자이너들이 기존 화면에서 다크모드일 시 보이는 케이스를 만들어놨고, 개발자는 이 작업을 위해 리소스 또한 준비를 해둔 상태였다. 때문에 내가(디자인 시스템팀의 디자이너) 해야 할 일은 마지막에 조금 더 다듬고 작업하는 일이라 생각했다.
아프다 아파하지만 현실은 보이는 대부분의 모든 것을 끝내놓더라도 이와 관련된 엣지 케이스를 찾는 것이 일의 대부분이었다.
그래서 다크모드를 위해 모든 화면을 준비됐다고 생각하지만 이는 사실상 진짜 다크 모드를 만드는 데에 5% 정도만 진행된 것이다.
그 이유는 왜냐면, 라이트 모드에서의 컬러를 전환해 다크 모드로 만드는 것은 지속 가능한 방법이 아니기 때문이다. 이렇게 만들 경우 어떤 기능이 추가될 때마다 light mode / dark mode 2가지를 계속적으로 하나 하나 만들어내야 하기 때문이다.
여기서의 문제는 모드(theme)에 대한 스케일이 커질수록, 그만큼의 시간을 계속적으로 써야 한다는 것.
그 외 hue를 전환(invert, rotate)하는 방식으로 다크 모드를 만들면 크고 작은 문제점들이 많았는데, 예를 들면 카드 컴포넌트에 그림자가 있다고 할 경우, 다크 모드에서의 카드 그림자 값이 glow 되어 보이는 현상이 있었다.
또 다른 문제점으로는, Figma에서 내비게이션 영역은 더 빠른 메뉴를 탐색하기 위해 다크 모드로 남아있길 바랐는데 단순히 hue rotate(색상 전환)로 모드를 바꿀 수 있는 영역과 그러지 않은 영역에 있어서의 구분이 애매모호하다는 것.
그리고 모든 기능 및 컴포넌트마다 다 라이트 / 다크모드를 일일이 컬러 체인지로 진행하는 것은 작업자 입장에서 두 시스템 차이를 이해하지 못할 수 있다는 점도 문제였다.
그 외 그저 hue를 바꾸는 것이 아니라 미묘하게 신경 써야 하는 것들이 있었는데 이는 접근성과 관련된 것이 많았다.
우리는 이번에 다크 모드를 만들며 기존 가독성과 대비와 관련된 문제들도 함께 해결하고 싶었다.
기존 문제 중 하나로 브랜드 컬러가 다크모드에서 사용 시 맥락이 조금 다르게 쓰이고 있다는 점이다.
즉, 컬러 대비 또한 동일한 hue의 컬러라고 하더래도 라이트 모드와 다크 모드에서의 시각적 대비가 다르기 때문에 사용자가 느끼는 맥락이 다르다는 것이다.
예를 들어 아주 강한(saturated) 컬러를 다크모드와 라이트 컬러에 모두 올려본다고 하자. 이 강렬한
컬러를 다크모드에 올릴 경우 나는 ‘Neon-sign effect’라 부르는데, 이 색상을 라이트 모드에서 봤을 땐
다르게 보이는데 특히나 광도가 다르게 보이는 것을 알 수 있었다.
이처럼 인간의 눈에서는 두 개의 대비를 low light level 보다는 high light level에서 훨씬 잘 보게 되는데 이는 같은 색상이라 하더래도 다크 모드에서 훨씬 더 뚜렷하게 색상을 구분한다는 것이다.
이 말은 즉, 다크 모드를 만들기 위해선 파운데이션 레벨(기초)부터 다시 시작해야 하는 부분이라는 것.
때문에 우리는 컬러부터 재정의 하는 작업을 시작했다.
Step 1. Color ramps (컬러 팔레트)
우선 먼저 우리의 색상 히스토리를 공유하자면 우리는 빨강 색상의 팔레트가 있었는데 언제 어떻게 써야 하는지 그 누구도 모르고 있었다.
비슷하게 보라 색상 또한 동일한 문제가 있었다. 보라 색상은 FigJam 혹은 몇몇의 컴포넌트에서 쓰이고 있었는데, 여기서 또한 언제 어떻게 해당 팔레트(ex.purple-400, purple-500)를 써야 하는지 모르는 문제가 있었다.
이렇듯 우리는 기존 컬러에서 갖고 있는 문제도 같이 해결하기 위해 가장 본질적인 질문을 했는데, 첫 번째로는
‘What hue do you need?’
로 기존 컬러 시스템의 Core hue를 정리하려 했고,
두 번째로는
‘how relatively light or dark do you need that hue to be?’
로 라이트 모드와 다크 모드에 시각적 대비가 맞는 컬러를 제작하려 했다.
그래서 우린 다크 모드를 디자인하지만, 라이트 모드를 또한 계속 디자인했다. 이전에 공유한 문제처럼 몇몇의 컬러가 다크 모드에서 더 잘 보이는 이슈(neon sign effect)가 있었기에 컬러를 다크모드와 라이트 모드 각각 만들었다.
그래서 최종으로 작업한 컬러 팔레트는 이런 형태로 만들어졌다.
초반에 아주 많은 시간을 쏟아야 하지만, 다양한 모드를 만들 경우에는 초반에 많은 시간을 투자하는 것이 훨씬 더 지속가능하고 시각적인 효과도 뛰어나기 때문이다.
하지만 이렇게 했을 때 문제점이 있었는데 바로 35개의 컬러에서 190개 정도로 늘어남으로써 디자이너들이 어떤 컬러를 선택해야 하는지 너무 어렵다는 것이다.
컬러 가이드가 있었으면 좋겠다는 피드백에 달린 +1 스티커들...우리는 이 문제를 해결하면서 동시에 더 많은 컬러도 제공할 수 있는 방법을 위해 다음 방법을 진행했다.
Step 2. Semantic colors
바로 시멘틱 컬러를 사용하는 것!
네이밍을 정의하는 데 있어 크게
1.Semantic
2.Atomic
방식이 있는데 두 개의 차이는 Atomic 방식이란 ‘red-600’, ‘gray-100’처럼 컬러의 hue와 shade, 즉 컬러 그 자체를 이름에 표기하는 것이고, Semantic 방식이란 ‘bg-danger’, ‘text-brand’처럼 그 컬러가 사용되는 상황을 이름에 표기하는 방식이다.
컬러를 만들 때는 단편적으로 만들지 않고 시스템을 만들어야 한다.
예를 들어, 빨간 텍스트와 빨간 배경 색상에 텍스트의 위험을 뜻하는 형태가 있다고 치자.
이를 두 개 다 ‘text-danger’로 정의할 것인가? 단편적으로 두 경우 모두 ‘text-danger’ 표현한다면 실제로 두번째 경우는 텍스트 컬러 흰 색이기에 이렇게 단편적으로 상황을 보고 네이밍을 만들게 되면 엣지 케이스가 계속해서 발생할 수 있다.
그래서 엣지 케이스를 발생하지 않는 방향으로 시멘틱 스키마(Semantic Schema)를 만들었다. (네이밍 컨벤션과 비슷한 것!) 이를 피그마에서 어떻게 만들어나갔는지 예시로 알려주자면,
Type -
처음 단계로 각 요소마다 어떻게 그루핑할 수 있을지를 확인했다.
예시로 해당 이미지에서의 내비게이션 바는 앞에 있는 요소(아이콘, 텍스트 등)들과 뒤에 있는 요소(배경색 등)으로 컬러를 나눌 수 있어 ‘color-foreground’, ‘color-background’로 나눴다.
하지만 우린 좀 더 유연하게 정의하면 좋겠다고 생각해서
‘color-foreground’에 속했던 것들을 ‘color-border’, ‘color-icon’, ‘color-text’와 같이 나눴다.
Type - Color -
그다음 단계로는 이 아이템에 대한 컬러를 어떻게 표현할 것인지를 정했다.
예를 들어, 사진과 같이 수많은 컬러의 버튼이 있다고 치자. 우리는 보통 첫 번째 버튼을 '이건 파란색 버튼이야'라고 생각해 'color-bg-blue'라고 semantic tokens을 만들 수 있다.
하지만 문제는 이 버튼이 1. primary라는 맥락을 가지고 있는 버튼이고, 2. 어떤 서비스에서 이 버튼이 쓰이냐에 따라 버튼 색 자체가 달라질 수 있었다.
쉬운 예로 들자면, 이 파랑 버튼이 Figma에서는 파랑 버튼으로 보이지만, FigJam에서는 보라색 버튼으로 보이고 있다.
만약 ‘color-blue’로 표기한다면, Figjam에서는 이 ‘color-blue’를 모두 ‘color-purple’로 이름을 바꿔줘야 하는 것이다.
그래서 이를 시멘틱 한 방식으로 'color-brand'로 이 버튼의 semantic token으로 정의한다면 색상이 다르더래도 각 제품의 브랜드 컬러로 사용되는 컬러를 그대로 사용할 수 있다.
즉, color 그 자체로의 네이밍을 짓는 게 아닌 역할로 짓는 것이다.
Type - Color Role -
그렇다면 이 버튼 안에 있는 텍스트는 어떻게 적용할 수 있을까? 재밌는 점은 버튼의 텍스트 컬러는 버튼의 배경 색에 따라 달라질 수 있다는 점인데, 이 점을 이용해 우리는 추가적으로 prefix인 'on'을 추가해 표현하고 있다.
Type - Color Role - Prominence -
시멘틱 컬러는 매우 유연한 컬러 시스템을 제공하지만, 꼭 컬러에 국한되지 않고 더 나아가 다양한 곳에 적용할 수 있는데 바로 Prominence이다.(Hierarchy와 비슷한 개념)
이미지를 보면 텍스트와 컴포넌트 모두 위계에 따라 다르게 쓰이는 것을 알 수 있게 스키마에 위계를 표현하도록 했다.
Type - Color Role - Prominence - Interaction
마지막으로 우리의 시멘틱 스키마에 표현하는 것은 바로 interaction이다.
위의 이미지와 같이 이를 모두 적용하게 되면 'color-text-ondanger-secondary-hover'와 같이 길게 표현되지만, 이렇게 복잡한 스키마로 구현된다는 것은 곧 네가 만들고 있는 서비스의 다양한 인터렉션들과 다양한 테마들을 쉽게 적용할 수 있다는 뜻이다.
그래서 최종적으로 피그마가 쓰고 있는 스키마는 이와 같다.
이를 추후에 외부에 공개하는 것을 목적으로 하고 있다. 해당 자료를 초반에 만들 때 활용해 만들길 바란다.
여기까지가 바로 다크 모드를 만들기 위한 준비 단계로, 처음 시작 단계부터 이러한 과정들을 다듬고, 서비스의 컬러를 바꾸기 전에 스키마를 정의해야 하는 것인데, 이런 것들이 되어야 한다고 생각하지 못하니 다크모드로 전환하는 것이 쉽다고 생각하는 게 가장 장애물이라는 것!
이제부터는 이 과정 다음으로 피그마에서 다크 모드를 만들기 위해 어떻게 적용하고 도입했는지를 알려주고자 한다.
Step 3. Implementation (적용)
자 그럼 컬러 팔레트도 있고 역할에 대한 네이밍 정의도 했고 이제 제품에 적용하기만 하면 되는데, 피그마에는 몇 천 개의 인스턴스 컬러(hue color를 레퍼런싱한 컬러 네이밍들)가 있었고, 이와 같은 컬러를 우리가 정리한 방식으로 모두 업데이트해야 했다.
이와 같은 업무는 많은 작업이 필요로 할 테니 이 모든 것을 디자인 시스템이 하는 것이 아닌 전사적으로 진행해야겠다고 생각했다.
그렇게 하기 위해 'Dark Mode Week'를 만들어 다크 모드 적용에 대한 기대감을 높이고, 다크모드로 전환하는 프로세스를 병렬적으로 진행하게 만들었다.
이걸 실제로 잘 진행되기 위해 디자인 시스템 팀에서는 플레이북, 도큐먼트와 같은 문서를 만들어 스키마를 적용하는 방식과 어떻게 하면 잘 적용할 수 있는지를 안내하고자 했다.
또 다른 방법으로는 피그마 플러그인 툴을 만들었는데 바로 컬러의 레거시 토큰(Hex code)을 입력했을 시, 어떤 토큰(semantic color name)을 쓰면 되는지 토큰들을 제안해 주는 툴을 만들었다.
그리고 코드에서 쓸 수 있는 모든 토큰을 가져와 디자이너가 사용하는 피그마에서의 컬러 라이브러리와 연동해 디자인과 코드가 완벽하게 싱크 할 수 있도록 세팅했다.
우린 또한 컬러를 찾을 때의 사용성도 생각했는데 디자이너가 모든 컬러 토큰을 알 필요는 없기에 가장 많이 사용되는 토큰을 위에서 찾을 수 있도록 했다.
또한, 컴포넌트 단위에서 쓰이는 토큰일 시 인터렉션 토큰까지 다 볼 수 있도록 세트로 정리해서 볼 수 있게 했다.
Dark mode week를 진행하며 업무에 관련된 질문에 답하고, 풀 리퀘스트(PR) 및 토큰을 업데이트하는 중앙 팀도 운영했다.
물론 하면서 많은 문제들을 발견할 수 있었는데, 이를 빠르게 대처하기 위해 많은 사람들이 활발하게 스키마를 사용하고 있지만 더 유연한 방식으로 토큰이나 컬러를 변경하는 작업도 진행했다.
버그도 다양한 레이어에서 생길 수 있어서 컬러 팔레트의 밸류 값의 문제인지, 토큰에서 정의에서 발생한 것인지, 혹은 적용 시 잘못된 토큰으로 적용한 것인지 등을 체크해야 했기 때문에 이를 확인하며 버그를 고쳐나갔다.
정말 어려웠던 케이스는 바로 특정 케이스에서 토큰이 없었던 경우인데, 다시 돌아가서 토큰 정의를 해야 하는 경우였다. 예를 들어 scroll bar color 같은 경우가 있었는데 우리의 스키마에 포함되진 않는 특수 케이스의 시멘틱 토큰 정의가 필요하단 것을 알 수 있었다.
계속적으로 디버깅을 하면서 컬러나 토큰에 대한 것은 많이 해결할 수 있었고 버그 이슈는 점차적으로 사람들에게 토큰을 제대로 쓸 수 있게 교육하는 것만이 남을 수 있었다.
이처럼 우리는 다크 모드를 만들 수 있었다!
이 방식은 그저 다크 모드를 지원하기 위한 부분이 아닌, 어떤 모드가 오더래도 지원 가능한 형태로 제품을 만드는 것이다. 그래서 리브랜딩을 하거나, 새로운 제품을 론칭하거나 했을 때도 훨씬 쉽게 할 수 있을 것이다.
보고 나서
현재 회사에서 열심히 디자인 토큰을 사용해 디자인 시스템을 만들어 나가는 과정 중이다 보니 재밌게 봤던 config 2022 영상 중 하나였는데요.
첨에 제목만 봤을 땐 피그마에서 다크 모드 만드는 얘긴 줄 알았더니 그건 밑밥이고 사실 컬러 그 자체, 즉 foundation level의 중요성을 얘기하면서 생각 들었던 건 시스템을 만드는 건 우리가 이걸 어떤 목적으로 어떻게 사용할 것인지 구성원들과 함께 정의하는 게 가장 중요하구나 싶었습니다. 마치 문제를 해결할 때 문제 정의가 가장 중요한 것처럼 말이죠.
개인적으로 이러한 시스템들을 만들면서 가장 힘들었던 건 유연하게 쓸 수 있는 구조로 최대한 생각하고 만들다 보니 어디까지 고려하고 이후 다음 과정을 진행한다! 와 같은 가이드라인을 정하는 것에 있어서 어려움이 있었는데, 이 영상을 보며 결국 적용하면서 버그를 발견하고 점차적으로 수정해 나가는 프로세스는 있을 수밖에 없구나는 생각이 들었습니다. (피그마도 똑같구나.. 동병상련..)
이런 모든 것들을 정리하는 것도 어렵지만, 전사적으로 알리고 제품에 적용하는 게 정말 어렵다고 생각하는데 'Dark Mode Week'와 같은 방식으로도 적용할 수 있겠구나 싶고, 회사의 규모와 리소스 등을 고려해 현재 나는 어떻게 할 수 있을까 깊게 고민할 수 있었던 영상이었습니다.
