brunch

You can make anything
by writing

C.S.Lewis

by 우종규 Jul 20. 2020

다크 모드 적용기 (1)

다크 모드 적용기 1탄 : 다크 모드의 당위성과 컬러 픽

화면에 대한 유저들의 의존도는 날이 가면 갈수록 높아진다. 휴대폰을 끼고 살다시피 하는 사람들도 많고, 아침에 일어나자마자 휴대폰을 확인하고, 자기 직전까지 휴대폰을 보다 자는 사람들이 너무나도 많아졌다. 변화무쌍한 삶의 여러 상황에서의 매 순간 최적화된 UI를 제공하기 위한 노력에서 다크 모드는 시작되었을 듯싶다.

이번 프로젝트를 시작하면서 다크 모드를 지원할지에 대한 화두를 던졌다. 사실 처음부터 다크 모드는 해야 한다고 생각했다. 하지만 하자고 하면 뚝딱하고 되는 게 아니기 때문에 투입될 개발 리소스보다 다크 모드가 가지는 장점이 더 커야 했다.

왜 꼭 다크 모드를 지원해야 할까?

일단 다크 모드 자체가 가지는 장점은 아래와 같다.

첫 번째, 어두운 색을 사용할수록 전력 소모가 현저히 줄어든다.

이건 사실 OLED 디스플레이일 경우에만 해당되는 이야기이다. 하지만 날이 갈수록 OLED의 점유율은 높아지고 있고, 현재도 많은 휴대폰들이 OLED이다. 만약 #000000의 컬러를 사용할 경우 OLED 패널을 아예 꺼버리기 때문에 전력 소모는 거의 0에 가깝다.

두 번째, 어두운 환경에서의 눈의 피로도로 줄인다.

당연한 이야기다.

세 번째, 어두운 환경에서의 콘텐츠 몰입도를 높일 수 있다.

단적인 예로 영화관이 왜 어두운지 생각해보면 된다.

영화관과 같은 몰입도를 주기 위해 항상 어두운 넷플릭스의 UI

위의 상황은 사실 다크 모드를 '지원'해야 하는 이유는 아니다. 그냥 다크한 UI를 만들면 되기 때문이다. 우리가 다크 모드를 '지원'해야 하는 이유는 아래와 같다.

첫 번째, 시스템(OS)에서 나이트 모드를 지원하기 때문이다.

시스템에서 화이트 모드를 사용하는 유저가 있을 수도 있고 다크 모드를 사용하는 유저가 있을 수도 있다. 자동모드를 사용하는 유저도 많다. 시스템 UI에 주로 노출되던 유저가 우리 어플케이션으로 진입했을 때 생기는 이질감을 유동적으로 최소화해야 한다.

두 번째, 그냥 취향이다

유저마다 좋아하는 취향이 다르다. 밝은 UI를 좋아하는 사람이 있고, 어두운 UI를 좋아하는 사람이 있다. 취향은 기왕이면 선택하게 하는 게 사용자 경험 측면에서 좋다.

세번째, 지금 고려하면 나중에 편하다.

어차피 해야 한다. 앞서 말했듯 OS에서 지원하고 있고, 이제 거의 대부분의 애플리케이션이 다크 모드를 지원하는 방향으로 흘러가고 있다. 지금 미리 컬러에 대한 정의를 명확히 하고 라이트 모드와 다크 모드에 대한 연결고리를 잘 만들어두면 나중에 리팩터링에 대한 고생을 줄일 수 있다.

그래서 지원하기로 했다.

레퍼런스 탐색

다크 모드를 고려하기로 했으니 레퍼런스를 찾아볼 필요가 있었다. 다크 모드에 대한 가이드를 찾다 보니 가장 눈에 띄는 건 구글의 Material Design의 가이드와 애플의 Human interface의 가이드가 큼지막한 차이를 보인다는 점이다.

다크 모드의 배경 컬러로 Material Design은 #121212의 Dark Grey를, Human Interface는 #000000의 Black을 권장하고 있다. 심지어 Material Design은 왜 Black(#000000)을 사용하면 안 되는지 상세하게 기술하고 있다.

배경컬러에 대한 가이드가 상반된다.

Dark Grey를 사용해야 하는 이유는 이렇게 이야기하고 있다.

1. 넓은 범위의 컬러, 깊이, 높이를 표현하기 용이하다. (#000000 보다 그림자 사용이 용이하기 때문)

2. 밝은 본문과의 대비를 살짝 낮춰 눈의 피로도를 줄인다.

3. OLED의 경우 (#000000)을 사용하면 화면 변화 시 페널을 껐다키게 되는데 이때 미세한 딜레이가 발생한다.

반면, Human Interface에서는 Black을 사용해야 하는 이유를 이야기하고 있는데,

1. 배경 위에 올라가는 컴포넌트들과의 명확한 대비를 줄 수 있다.

2. 베젤과의 경계를 없애 확장된 UI경험을 줄 수 있다.

Material Design은 편안함과 활용에 대한 가이드를 제시하는 반면, Human interface는 명확함과 UI에 대한 집중도를 강조하고 있다. 그렇다면 다른 어플리케이션들은 어떤 배경 컬러를 사용하고 있을까? 몇 가지 어플리케이션만 확인해보았다.

막 골랐는데 매우 적절한 예시였다.

일단 아티클을 주로 다루는 Medium은 우리 프로젝트랑 가장 성격이 비슷했다. 장시간 글을 봐야 하는 어플리케이션인 만큼 보다 편안한 컬러인 #121212를 사용하고 있었다. 반면 원티드는 #000000을 사용했다. 평소에도 뚜렷한 구분감을 느꼈던 UI이다. 지니 같은 경우는 primary color인 하늘색 빛이 도는 짙은 회색인 #14171E을 사용하고 있었다. Primary color 사용에 있어서도 자연스럽게 사용할 수 있고 UI 자체에서 지니 냄새(?)가 풍기도록 했다. 굳이 따지자면 구글에 가까운 느낌이다.

자, 그럼 우리는 어떻게 할까?

우리는 이걸로 간다.

결론부터 말하면 미디움 + 지니 쪽을 선택했다. 텍스트가 대부분인 서비스이기 때문에 유난히 텍스트가 동동 떠다니는 느낌의 #000000은 후보에서 제외했다. 구글의 가이드는 어느 정도 참조하면서도 약간의 primary color인 보랏빛이 도는 회색(#121214)을 선택했다. 사실 짙은 회색에서는 별 차이가 나지 않지만 옅은 단계의 회색을 정의할수록 보랏빛이 살짝 묻은 느낌을 주기 좋았다.

배경 컬러에 대한 가이드들이 서로 많이 다르다는 것은 사실 뭘 써도 나쁘지 않다는 이야기일 수도 있다. 다만 모든 가이드들이 공통적으로 이야기하고 있는 것이 하나 있다. 그건 바로, 채도와 대비에 대한 정의이다.

채도와 대비에 대한 표준 규격

Material Design, Human Interface는 물론 다른 여러 가이드들에서도 공통적으로 텍스트/배경의 최소 채도와 대비에 대해서 WCAG를 이야기하고 있다.

WCAG(Web Contents Accessibility Guidelines) 표준규격

W3C 웹 콘텐츠 접근성 가이드라인 표준 권고안은 웹 사이트/애플리케이션에서 충족해야 하는 기준을 정의하여 장애가 있는 사용자가 보다 쉽게 이용할 수 있도록 준수해야 하는 지침

WCAG에서는 배경 컬러와 본문(body) 색상에 대한 대비 수준은 이렇게 정의하고 있다.

텍스트에 대한 시각적 인지는 최소한 4.5:1 이상의 대비 수준을 가져야 한다. 아래의 경우를 제외하고, (Level AA)

- Large-scale의 텍스트나 이미지일 경우에는 최소 3:1 대비 수준을 가진다.
- 텍스트나 이미지가 UI 컴포넌트 상의 비활성화 상태의 일부일 경우 대비 요건이 없다.
- 텍스트가 브랜드의 이름 혹은 로고의 일부분일 경우 대비 요건이 없다.

대비 수준을 쉽게 알 수 있는 figma 플러그인 Able

이러한 기준에 따라 우리 프로젝트에서도 텍스트 컬러에 대한 정의를 진행했다. 이런 대비 수준에 대해서 쉽게 확인할 수 있는 방법을 찾아보니 Able이라는 좋은 figma의 플러그인이 있었다.

이런 식으로 컬러 간의 대비 수준과 규격 부합 여부를 알 수 있다.

우리는 MainText를 완전한 화이트(#ffffff)가 아닌 아주 조금 어두운 #F9F9FD를 선택했다. 대비를 살짝 낮추면서 흰 글씨에 대한 이질감을 줄이기 위해서다. SubText도 WCAG 규격 Level AA에 부합하는 컬러인 #818088로 정의했다.