본문으로 건너뛰기
피드

라이트 모드 인플레이션: macOS UI 밝기가 16년간 71%에서 100%까지 올라간 이유

frontend 약 3분
vote
0
댓글
북마크

macOS 스크린샷을 Pillow로 분석한 결과, 라이트 모드 윈도우 크롬의 평균 밝기가 Snow Leopard(71%)에서 Tahoe(100%)까지 16년간 꾸준히 상승해왔음. Big Sur에서 85%→97% 점프가 다크 모드 전환의 결정적 계기였고, iOS 26은 HDR로 100%를 넘는 밝기까지 도입함

  • 1

    macOS 라이트 모드 밝기가 16년간 71%에서 100%로 꾸준히 상승

  • 2

    Big Sur 업데이트에서 85%→97% 급등이 다크 모드 전환 트리거

  • 3

    밝기 편향: 더 밝은 디자인이 깔끔해 보이는 심리적 효과가 원인

  • 4

    iOS 26은 HDR로 100% 화이트를 초과하는 UI 요소 도입

  • 5

    50% 회색 UI를 제안하며 밝기 인플레이션 악순환 경고

  • macOS의 라이트 모드 밝기가 지난 16년간 꾸준히 상승해왔다는 분석 결과가 나옴. 예전에는 "라이트 모드"라는 개념 자체가 없었고, 그냥 컴퓨터가 원래 그런 거였음
  • 분석 방법은 512 Pixels의 macOS 스크린샷 라이브러리에서 각 버전별 스크린샷을 다운받아 윈도우 크롬 영역을 크롭한 뒤, Python Pillow로 평균 밝기를 측정한 것임
  • Snow Leopard(2009) 시절 윈도우 평균 밝기가 71%였는데, macOS Tahoe에서는 완전한 100%에 도달함. 그래프로 그려보면 우상향 추세가 명확하게 보임
  • 특히 Big Sur 업데이트가 결정적이었음. 밝기가 85%에서 97%로 한 번에 크게 뛰면서, 이때 많은 사람들이 다크 모드로 전환하게 된 계기가 됨
  • Tahoe 기준으로 라이트 모드 윈도우에서 가장 어두운 색상이 비활성 설정 창의 97% 밝기임. Snow Leopard에서는 90%가 가장 밝은 쪽에 속했던 것과 완전히 대조됨
  • 이런 현상이 발생하는 이유는 "밝기 편향" 때문임. 두 디자인을 비교하면 더 밝은 쪽이 "깔끔해 보이는" 착각이 들고, 어두운 쪽으로 돌아가면 "때가 낀 것 같은" 느낌이 드는 심리적 효과가 있음
  • iOS 26에서는 한 발 더 나아가 HDR 디스플레이를 활용해 일부 UI 요소가 100% 화이트를 넘는 밝기로 표시됨. SDR로 표시되는 일반 UI가 상대적으로 회색빛으로 보이게 되면서, 더 밝게 만들고 싶은 유혹이 커질 수밖에 없음
  • 글쓴이는 하루 종일 macOS를 보는 직업이라 100% 화이트가 눈을 공격하는 라이트 모드를 도저히 쓸 수 없다고 함. 하지만 대안이 꼭 거의 검정일 필요는 없고, 중간 회색이면 충분하다는 입장
  • 다크 모드의 단점도 언급됨. 텍스트 에디터, IDE, 터미널, 브라우저, Finder 전부 검정이라 창 간 구분이 안 되는 문제가 있음
  • 결론: 인터페이스나 웹사이트를 만든다면 과감하게 50% 회색을 선택하라는 제안. 밝기 인플레이션의 악순환을 끊을 필요가 있음

디자인 결정에서 '더 밝으면 더 깔끔하다'는 편향이 누적되면 결국 사용자를 다크 모드로 내몰게 됨. HDR 시대에는 이 인플레이션이 더 가속될 수 있어서, 의식적으로 중간 밝기를 선택하는 것이 접근성과 사용성 측면에서 중요함

댓글

댓글

댓글을 불러오는 중...

frontend

타입스크립트 7.0, Go 네이티브 포팅으로 빌드가 8~12배 빨라졌다

마이크로소프트가 타입스크립트 7.0을 출시하면서 기존 자바스크립트 기반 구현을 Go로 네이티브 포팅했다. 전체 빌드는 평균 8~12배 빨라졌고, VS코드 빌드는 125.7초에서 10.6초로 줄었으며, 슬랙은 CI 타입 검사 시간을 7.5분에서 1.25분으로 낮췄다.

frontend

타입스크립트 7 공개, 고 포팅으로 빌드가 최대 10배 이상 빨라짐

마이크로소프트가 고(Go)로 네이티브 포팅한 타입스크립트 7을 공개했다. 전체 빌드는 보통 8~12배 빨라지고, VS 코드 코드베이스에서는 125.7초가 10.6초로 줄었으며, 편집기 첫 오류 표시도 17.5초에서 1.3초 미만으로 내려갔다.

frontend

“98% 지원”이 생각보다 별로 안 넉넉한 이유

브라우저 기능 지원률 98%는 얼핏 높아 보이지만, 실제 서비스에서는 2%의 사용자를 깨진 화면 앞에 세우는 숫자일 수 있다는 글이다. 특히 일반 통계와 내 서비스 방문자 분포는 다를 수 있고, 실제 사례로 어떤 사이트는 최신 중첩 CSS 기능 지원 브라우저가 방문자의 약 70%뿐이었다.

frontend

메타, AI가 읽고 쓰는 디자인 시스템 ‘Astryx’ 오픈소스로 공개

메타가 내부 디자인 시스템 Astryx를 오픈소스로 공개했다. React와 StyleX 기반의 150개 이상 접근성 지원 컴포넌트, 디자인 토큰, 테마, 템플릿, CLI를 제공하며, 특히 AI 에이전트가 컴포넌트 구조를 이해하고 UI를 생성·수정할 수 있도록 MCP 서버까지 포함한 점이 핵심이다.

frontend

shadcn/ui, 기본 컴포넌트 라이브러리를 Radix에서 Base UI로 변경

shadcn/ui가 새 프로젝트의 기본 컴포넌트 라이브러리를 Radix가 아니라 Base UI로 바꿨어. Radix 지원은 계속되지만, Base UI가 안정화됐고 주간 다운로드 600만 이상, shadcn/create 신규 프로젝트 선택 비율 2대1이라는 이유로 기본값을 바꾼 거야. 동시에 채팅 UI용 MessageScroller와 관련 컴포넌트, headless 패키지인 @shadcn/react도 공개됐어.