다크 모드 강제 사용 금지 요청

• 웹사이트가 다크 모드만 제공하면 긴 글을 읽는 일부 사용자에게 눈의 피로와 불편을 만들 수 있어, 선택권이나 편안한 색 조합이 필요함
• 핵심은 다크 모드 자체가 아니라 텍스트와 배경의 명암 대비율이며, 순백색 텍스트와 완전한 검은 배경은 21:1 대비로 부담이 커질 수 있음
• 검은 배경에 #888888 회색 텍스트를 쓰면 대비율이 5.9:1로 낮아져, 과도한 대비보다 읽기 편한 다크 모드 예시가 됨
• WCAG 2.1은 일반 텍스트에 최소 대비율 4.5:1만 요구하고 최대 대비 제한은 두지 않아, 21:1 조합도 규칙상 접근 가능한 것으로 취급될 수 있음
• WCAG 3.0 초안의 Maximum text contrast 요구사항은 2025년 9월 4일 업데이트에서 제거됐고, 강제 다크 모드 글은 현재 CSS를 직접 덮어쓰는 식의 임시 대응이 필요함

---

강제 다크 모드가 읽기를 어렵게 만드는 경우

• 다크 모드 전용으로 설계된 웹사이트와 개인 블로그가 많고, 일부 사이트는 한 문단도 읽기 전에 눈이 불편해질 수 있음
• 다크 모드는 특정 상황에서 유용하지만, 사용자에게 선택권 없이 강제 적용되면 나쁜 사용자 경험이 됨
• 긴 다크 모드 글을 읽은 뒤에는 눈이 바로 적응하지 못해 수평 줄무늬가 계속 보이는 것처럼 느껴질 수 있음

문제의 중심은 명암 대비율

• 다크 모드에서 불편함을 좌우하는 핵심 요소는 텍스트와 배경 사이의 명암 대비율임
• 순백색 텍스트를 완전한 검은 배경 위에 두면 대비율이 21:1이 됨
  • 이 조합은 눈에 부담을 주고 읽기 어렵게 만들 수 있음
• 검은 배경 위에 #888888 회색 텍스트를 쓰면 대비율이 5.9:1로 낮아짐
  • 같은 다크 모드라도 더 편하게 읽을 수 있는 색 조합의 예시임
• 대비율이 높을수록 항상 좋은 것이 아니며, 다크 모드에서는 과도한 대비가 오히려 불편함을 키울 수 있음

WCAG 기준이 놓치는 부분

• 현재 WCAG 2.1 SC 1.4.3은 일반 텍스트에 대해 최소 대비율 4.5:1을 요구함
• WCAG 2.1에는 최대 대비율 제한이 없음
  • 순백색 텍스트와 완전한 검은 배경처럼 21:1 대비를 가진 조합도 규칙상 완전히 접근 가능한 것으로 간주될 수 있음
  • 많은 사용자에게 불편함을 줄 수 있어도, 기존 지침은 다크 모드의 과도한 대비 문제를 다루지 않음
• WCAG 3.0에는 탐색적 요구사항으로 Maximum text contrast가 추가될 예정이었음
  • 2025년 12월 업데이트에 따르면 이 요구사항은 2025년 9월 4일 WCAG 3.0 초안 업데이트에서 제거됨
  • 대비율 수학에 대한 GitHub Issue는 여전히 열려 있음

현재 가능한 우회 방법

• 중요한 글이 강제 다크 모드로만 제공되면 브라우저 개발자 도구에서 CSS를 덮어써 색상을 반전할 수 있음
• 별도 플러그인을 쓰고 싶지 않은 경우, 더 나은 해결책이 나오기 전까지 개발자 도구가 임시 대응책으로 남아 있음

다크 모드가 잘 맞는 상황

• 다크 모드 자체를 거부하는 입장은 아니며, 다음 상황에서는 다크 모드를 선호함
  • 불이 꺼진 방에서 OLED 화면으로 글을 읽을 때, 예를 들어 잠들기 전 휴대폰으로 글을 읽는 경우
  • 코드를 작성할 때, 거의 모든 IDE가 기본적으로 편안한 대비율의 다크 모드를 제공함
  • 웹사이트의 다크 모드가 편안한 대비율을 갖췄을 때
• 글 이후 Hacker News 토론에서는 동의와 비판이 함께 나왔고, 초기 OEM의 다크/라이트 모드 선택, 대비율의 중요성, 개인적 경험, 의학적 조건, 접근성 문제, 우회 방법 등이 논의됨

[GN⁺]

Hacker News 의견들

• 다크 모드가 원래 전통적인 기본값에 가까웠음
  초기 녹색/호박색 글자와 검은 단색 디스플레이, 검은 배경의 회색 DOS 텍스트 모드, C-64의 짙은 파란 배경에 밝은 파란 글자, Apple II의 검은 배경 위 회색/흰색이 그랬음
  GUI에서도 Amiga는 기본 Workbench가 짙은 파란 배경이었고, 모든 팔레트를 사용자가 고를 수 있었음
  대부분의 앱에서 종이와 비슷하다는 이유로 흰 화면에 검은 글자를 기본으로 만든 건 Microsoft Windows였고, 종이는 흰색이어도 빛나는 흰색은 아니어서 그 전환이 고통스러웠음
  다크 모드가 돌아와서 반갑지만 강제 다크 모드가 아니라 선택지가 필요하고, 라이트 모드도 가능하면 최대 밝기의 흰색이 아니었으면 함

  • 다크 모드가 전통적 기본값은 아니며, 종이는 흰 배경에 검은 글자였음
    기기나 모니터를 빛나는 흰색으로 두면 안 되고, 옆에 놓인 종이와 비슷하게 보이도록 밝기를 낮춰야 함
    패러다임을 바꾼 것도 Windows가 아니라 널리 보급된 소비자 기기로는 Mac이 먼저였고, 내장 CRT도 전통적인 사무실 조명에서는 종이보다 덜 밝았음
    초기 컴퓨터가 어두운 배색을 쓴 건 해상도가 낮고 픽셀 밝기가 번져서 읽기 쉬웠기 때문이며, 기술이 좋아지면서 그 문제가 사라졌고 화면이든 인쇄물이든 밝은 배경의 어두운 글자가 눈에 더 편함
  • 오래된 CRT의 명암비는 현대 LCD/IPS/OLED 화면과 완전히 다름
    호박색과 녹색도 흰색 글자보다 편하다고 여겨졌고, 비교 자체가 어려울 정도로 차이가 큼
    완전한 검은색 대신 어느 정도 밝기가 있는 배경이면 다크 모드가 더 많은 사람에게 괜찮을 수 있지만, 그러면 OLED의 장점 대부분을 잃게 됨
  • 전통적 기본값이라는 건 절대적인 말이 아님
    초기 PC의 DOS/Unix가 당시 디스플레이 특성상 검은 배경을 쓴 건 맞지만, 그 전에는 흰 종이로 정보를 공유했고 인터넷 초기는 흰 배경에 검은 글자를 다시 가져왔음
    결국 정통 기본값 같은 건 없고 언제 합류했느냐에 달림
  • 그 시기는 모든 것이 정해지던 아주 짧은 순간이었고, 개인 취향이나 인체공학보다 비용 제약이 컴퓨팅 성능과 표시 방식을 좌우했음
    Amiga Workbench가 짙은 파란 배경이었던 것도 비용 때문임. 많은 사람이 합성 영상 출력으로 TV에 연결해 볼 것으로 예상됐고, 흰 글자와 파란 배경은 TV가 잘 표시하는 조합이었음
    1080 모니터는 A1000 가격의 3분의 1 정도였고, 많은 A500이 크리스마스에 개봉된 뒤 한동안 TV에 연결됐을 가능성이 큼
    Amiga용 워드프로세서를 거의 다 써봤는데 WordPerfect를 빼면 모두 흰 배경에 검은 글자였고, WordPerfect도 바꿀 수 있었지만 DOS와 맞추려고 기본 파란색/흰색을 유지했을 뿐임
  • 다크 모드는 CRT 초기에 정상적이었고, 당시 대부분의 CRT는 60Hz 이하로 갱신됐음
    어두운 배경은 깜빡임을 덜 눈에 띄게 했고, 1990년대에 더 높은 주사율의 CRT가 보편화되면서 깜빡임 문제가 줄어 라이트 모드가 기본이 됨

• 잠깐, 어떤 웹사이트가 밝은 글자와 어두운 배경만 갖고 있다면 그건 그 사이트의 테마와 분위기임
  다크 모드는 라이트 모드가 있을 때만 존재하고, 반대도 마찬가지임
  원하지 않는 웹사이트에 두 가지 모드를 모두 유지하라고 강제할 수는 없음

  • 그건 글 첫머리에 이미 나온 내용임
    다크 모드가 브랜드 특성이라면 텍스트에 편안한 명암비를 선택하라고 되어 있음

• 기본값이면서 설정 불가능한 라이트 모드는 오래 있었고, 이를 보완하려고 Dark Reader 같은 플러그인도 있음
  하지만 반대로 라이트 모드를 강제하는 인프라는 별로 없음
  대부분의 상황에서는 라이트 모드가 다크 모드보다 낫다고 봄. 다크 모드가 더 나은 유일한 상황은 화면이 유일한 광원인 어두운 방에 앉아 있을 때인데, 대개 건강한 환경이 아님
  다크 모드는 보조도구에 가깝고, 불을 켜거나 자는 편이 나음
  빛이 없는 환경에서는 라이트 모드가 읽기 거슬릴 수 있지만, 밝은 환경에서는 다크 모드가 거의 읽기 불가능함. 한여름 밝은 날 휴대폰에서 다크 모드 UI를 읽어보면 밝기를 최대로 올려도 잘 안 보임

  • 내 시스템의 Dark Reader 플러그인에는 라이트 테마를 강제하는 옵션도 있음
    사실 브라우저에는 기본 배경색과 글자색을 설정하는 기능이 있으니, 웹사이트가 정말 필요할 때가 아니면 이 기본값을 존중하기만 해도 확장은 필요 없을 것임
    “내 선호를 실제로 존중하라”는 확장이 필요한 세상은 불행하지만, 필요하다면 적어도 양쪽 옵션을 모두 지원한다는 점은 알아둘 만함. 전체 상황은 꽤 바보 같지만 우회책은 있음
  • 의학적 이유도 없는데 어두운 방에 동굴 트롤처럼 앉아 있고 싶어 하는 사람이 많은 건 늘 이상했음
    이제는 운영체제가 모두 전환 가능한 모드를 갖고 있고 이를 브라우저에 알려줄 수 있음. 브라우저는 운영체제가 보고한 설정에 맞춰 적응할 수 있고 그래야 함
    UI 디자인은 Paul Fitts 같은 몇몇 합리성의 섬을 제외하면 대체로 잘못 적용된 분위기와 유행의 연쇄임
    처음엔 대비가 나쁘다고 해서 대비를 부족하게 쓰고, 다음엔 밝기가 나쁘다고 해서 밝기를 부족하게 씀. 그러다 대비와 밝기가 왜 원래부터 중요했는지 다시 깨닫고 순환이 계속됨
  • 백내장이 있었던 입장에서는 라이트 모드가 읽기 매우 어려웠음
    자동차 상향등을 정면으로 보는 느낌이었고, Dark Reader 플러그인을 쓰긴 했지만 사이트가 제대로 다크 모드를 지원하는 것과는 달랐음
  • 화면 밝기를 부적절하게 높게 설정한 경우에도 다크 모드가 더 나을 수 있음
  • 내 화면에서는 검은 픽셀이 실제로 꺼지기 때문에 Pure Black 모드를 좋아함
    대낮에도 훨씬 보기 편함. 일부 Android 앱처럼 Pure Black 모드가 다크/라이트 모드와 별도 옵션이었으면 좋겠음
    지금은 Dark Reader에서 밝기를 최소화해 버티지만 좀 투박함

• 이 블로그 자체가 기기 설정을 따르지 않고 독자에게 라이트 모드를 강제함
  글쓴이는 중간에 입장을 바꿔 문제가 다크 모드가 아니라 색 대비라고 결론 내림

  • 글쓴이의 블로그도 명시적으로 color: #111;와 background-color: #fdfdfd;를 정의하고 있고, 이는 18.56:1 명암비임
  • 실제 요지는 명암비라서 제목은 조금 부정직하게 느껴짐
    아이러니하게도 마지막에는 우회책으로 반전 필터를 쓰겠다고 하는데, 다크 모드를 선호하는 사람이 글쓴이의 강한 흰 배경/검은 글자 사이트에 Vivaldi의 Invert Mode 같은 걸 쓰면 글쓴이가 불평하는 바로 그 다크 명암비가 나옴

• 사용자에게 낮은 명암비를 강제하지 않았으면 함
  모두가 100니트 초과로 보정된 화면과 밝지만 합리적인 주변 조명에서 콘텐츠를 보는 것은 아님
  권장된 회색-회색 조합은 예를 들어 완전한 암실에서 밝기 0으로 보거나 직사광선 아래에서 볼 때 읽기 힘들 수 있음
  전체 SDR 색상 범위는 쓰라고 있는 것이고, 사용자를 눈멀게 하지 않기 위해 제한해야 하는 HDR이 아님

  • 회색-회색 조합은 나이 든 사람들에게도 어려울 수 있음

• 라이트 대 다크만의 문제가 아님. 웹사이트가 전반적으로 내 시스템 선호를 존중했으면 좋겠음
  내 운영체제 테마가 노란 벽돌 배경 위 보라색 Comic Sans 텍스트라면 브라우저도 그걸 존중해야 함
  텍스트를 브라우저 전체 너비로 읽고 싶은데 가운데 5인치짜리 좁은 열로만 봐야 한다면, 브라우저 설정에서 마법을 부리거나 덮어쓰기 CSS를 소환하거나 확장을 설치할 필요가 없어야 함
  브라우저는 그냥 “웹 개발자야, 어쩔 수 없다. 사용자 선호가 이긴다”라고 해야 함
  브라우저는 사용자가 원하는 것을 무시할 수 있도록 개발자에게 통제권을 너무 많이 넘겼고, “사용자 에이전트”라는 말이 무색함. 이제는 개발자 에이전트에 더 가까움

  • 노란 배경은 어쩔 수 없더라도, Comic Sans 강제는 Firefox 설정에서 선호 글꼴로 지정하고 “페이지가 자체 글꼴을 선택하도록 허용”을 끄면 쉽게 됨
    나도 그렇게 쓰고 있고 웹 탐색이 훨씬 나아짐
  • 데스크톱 앱이나 다른 것들이 실제로 그런 설정을 존중하나?
  • 나는 그렇게 원하지 않고, 사이트나 앱마다 스킴을 따로 선택하고 싶음
    어떤 곳은 다크 모드가 훌륭하고, 어떤 곳은 말도 안 됨. 흰색 테마도 마찬가지임
  • 기본으로 읽기 모드를 쓰고 싶은 것처럼 들림. 일부 브라우저는 그걸 허용함

• 너무 많은 웹 개발자가 모두가 다크 모드를 좋아한다고 가정하고 기본값으로 둔 뒤, Dark/Light Mode 토글 버튼이 있다고 정당화함
  새로 만든 웹사이트조차 사용자 선호를 감지하지 않고 고정해두는 경우가 많아 놀라움
  개발자라면 CSS의 color-scheme 속성으로 요소가 어떤 색 구성에서 편안하게 렌더링될 수 있는지 표시할 수 있음
  :root { color-scheme: light dark; }
element { light-dark(light-color-code, dark-color-code); }
  macOS 사용자로서는 메뉴 막대나 IDE처럼 다크 모드가 좋은 경우도 있지만, 읽기·쓰기·브라우징은 라이트가 좋아서 선호가 섞여 있음
  System Preferences에서 테마를 LIGHT로 설정한 뒤 defaults write -g NSRequiresAquaSystemAppearance -bool Yes를 실행하고, 로그아웃 후 System Preferences에서 테마를 DARK로 설정하면 됨
  기본 테마로 되돌리려면 defaults write -g NSRequiresAquaSystemAppearance -bool No를 실행함

  1. https://developer.mozilla.org/en-US/docs/Web/CSS/color-schem...

• 웃긴 건 블로그의 “읽기 쉬운 텍스트” 예시가 나에겐 낮은 대비 때문에 정말 읽기 어렵다는 점임
  어떤 눈 상태나 모니터를 쓰는 건지 궁금함

  • 추측하자면 디자이너용으로 나온 매우 비싼 HDR 모니터를 쓰고, 모든 것에 전체 색역을 쓰는 것 같음
  • 회색 위 회색 위 회색 같은 가독성 파괴 집착을 이해할 수 없음
    못 견디겠고, 못생겼고, 읽기 어렵다. 모두 그만했으면 좋겠음
  • 나도 라이트 모드를 선호하지만, 내 약 300달러짜리 화면에서는 회색 글자가 흰 글자보다 훨씬 읽기 편함

• 사용자가 다크 모드인지 알아내는 웹 API가 있으니 그걸 쓰면 됨
  @media (prefers-color-scheme: dark) { CSS Rules here... }

• 다크 모드는 실수였음
  초기 LCD가 어두워서 모두가 이를 보완하려고 흰색을 강하게 올렸고, 이제 LCD가 따라잡으면서 상당수 사람들의 눈을 태우는 수준이 됨
  그래서 점점 두 가지 모드를 지원해야 하고, Apple의 우스꽝스럽게 못생긴 다크 모드 아이콘은 이걸 잘하기가 얼마나 어려운지 보여줌
  이상적으로는 밝은 CRT가 표준이던 시절처럼 컴퓨터 인터페이스의 기본색을 다시 회색으로 돌리는 것이라고 봄
  그러면 UI 요소에 깊이 단서를 줄 수 있다는 장점도 있고, 이것도 다시 가져와야 함

  • 그건 그냥 개인 취향일 뿐임
    핵심은 사용자가 자기 선호를 설정할 수 있도록 구성 가능해야 한다는 것임
    개인적으로는 라이트 모드가 눈부시고 눈이 아프며 피로해짐. 사람마다 다름
  • CRT에는 밝기와 대비를 쉽게 조절하는 다이얼도 있어서, 누구나 흰 배경에 검은 글자든 그 반대든 자기 선호에 빠르게 맞출 수 있었음
  • “기본색을 회색으로”라는 건 대부분의 경우 다크 모드가 이미 하는 일 아닌가?
    라이트 모드는 대체로 완전한 흰색이 아니고, 다크 모드는 회색 계열임