“다크 모드 넣을까요” 라는 질문은 대체로 취향 논쟁으로 흐릅니다. 그런데 이것은 취향 문제가 아니라 유지 비용을 두 배로 늘릴 것인가의 문제이고, 그렇게 놓고 보면 결정이 훨씬 쉬워집니다. 양쪽을 정직하게 적어 보겠습니다.
실제로 무엇이 두 배가 되는가
다크 모드는 색을 뒤집는 작업으로 시작하지만 거기서 끝나지 않습니다. 검증해야 할 화면이 통째로 한 벌 더 생깁니다.
가장 자주 간과되는 것이 대비비입니다. 밝은 화면에서 기준을 통과한 색 조합이 어두운 배경에서도 통과한다는 보장은 전혀 없습니다. 특히 브랜드 색이 중간 명도의 채도 높은 색이라면, 흰 배경에서는 충분하던 대비가 어두운 배경에서 부족해지는 일이 흔합니다. 두 벌을 각각 검증해야 합니다.
그다음이 이미지입니다. 흰 배경으로 저장된 도표나 로고는 어두운 화면에서 흰 사각형으로 뚫려 보입니다. 화면 캡처가 들어가는 문서 사이트라면 캡처를 두 벌 유지하거나 밝은 화면 캡처가 어두운 페이지에 박힌 상태를 감수해야 합니다.
그럼에도 넣어야 하는 경우
비용이 크다고 해서 넣지 말라는 얘기는 아닙니다. 분명한 근거가 있는 경우가 있습니다.
구분의 기준은 체류 시간입니다. 몇 분씩 화면을 응시하는 사이트에서는 어두운 배경이 실제로 편안함을 줍니다. 반면 방문자가 30초 머물다 문의 버튼을 누르는 소개 사이트에서는, 얻는 것에 비해 유지해야 할 표면만 늘어납니다.
넣기로 했다면 — 토큰이 먼저입니다
구현에서 성패를 가르는 것은 색을 어디에 적어 두었는가입니다. 컴포넌트마다 색 값을 직접 쓴 코드베이스에서 다크 모드를 추가하면, 수백 곳을 찾아 조건을 다는 작업이 됩니다. 반대로 의미 기반 토큰(표면 · 본문색 · 테두리 · 강조)으로 정리돼 있으면 토큰 정의만 한 벌 더 쓰면 됩니다.
상태가 셋이라는 점도 놓치기 쉽습니다. 사용자가 밝게 고른 상태, 어둡게 고른 상태, 그리고 아무것도 고르지 않아 운영체제 설정을 따르는 상태입니다. 세 번째가 기본값이므로, 시스템 설정 대응과 사용자의 명시적 선택이 서로를 덮어쓰지 않게 배치해야 합니다.
삽화를 코드로 그려 두었다면 이 대목에서 크게 유리합니다. 색이 토큰에서 오므로 모드 전환에 자동으로 따라오고, 그림 파일을 한 장도 다시 만들지 않습니다.
안 넣기로 했다면 — 그것도 정직하게
다크 모드를 지원하지 않기로 했다면, 지원하지 않는 상태를 제대로 만들어 두는 것이 남은 일입니다. 배경색과 글자색을 명시적으로 선언해 두면 어떤 환경에서도 의도한 대로 보입니다. 선언을 빠뜨리면 일부 브라우저나 확장 기능이 색을 임의로 뒤집어, 지원하지 않기로 한 화면이 절반만 어두운 상태로 나옵니다.
그리고 이 결정은 되돌릴 수 있습니다. 지금 토큰 구조만 갖춰 두면, 다크 모드는 나중에 필요해졌을 때 값 한 벌을 추가하는 일이 됩니다. 결정을 미루는 것과 준비를 미루는 것은 다릅니다.
토큰 구조를 처음부터 설계하는 방법은 디자인 토큰 연재에, 테마와 플러그인 선택이 유지 비용에 미치는 영향은 테마 · 플러그인 아카이브에 정리돼 있습니다. 운영 중인 사이트의 구조를 정리하면서 이런 결정을 함께 검토하고 싶다면 최적화 지원 사업을 참고하세요.