'접근성'이라는 단어를 들으면 대부분의 개발자는 ARIA 속성이나 스크린 리더 지원을 떠올린다. 물론 그것도 중요하다. 하지만 접근성에는 훨씬 덜 주목받는 영역이 하나 더 있다. 사용자가 운영체제 수준에서 이미 설정해 놓은 선호를 우리 앱이 얼마나 존중하느냐다.
생각해보면 당연한 이야기다. 사용자가 macOS나 Windows에서 '동작 줄이기(Reduce Motion)'를 켜 두었다면, 그건 단순한 취향 문제가 아닐 수 있다. 전정 기관 장애(vestibular disorder)를 가진 사람에게 화려한 슬라이드 전환 애니메이션은 실제 물리적 불쾌감을 유발한다. 고대비 모드를 쓰는 사람에게는 시각적 구분이 생존에 가까운 편의다. 우리 앱이 이 신호들을 무시한다면, 그건 '미구현 기능'이 아니라 접근 장벽이다.
dev.to에 공개된 'Building Accessible React Components with Hooks'는 이 문제를 정면으로 다룬다. 브라우저는 prefers-reduced-motion, prefers-contrast, prefers-color-scheme 같은 CSS 미디어 쿼리를 통해 OS 설정을 노출한다. 이를 window.matchMedia로 직접 읽는 것도 가능하지만, SSR 환경 대응, 이벤트 리스너 정리, 반복 보일러플레이트 등 신경 써야 할 것이 많다. ReactUse 라이브러리가 제공하는 useReducedMotion, usePreferredContrast, usePreferredColorScheme 같은 훅들은 이 패턴을 깔끔하게 추상화해 준다.
여기서 중요한 건 훅의 존재 자체가 아니라 그것을 어떻게 쓰느냐다. useReducedMotion이 true를 반환할 때 단순히 애니메이션을 끄는 것으로 끝내면 안 된다. 핵심은 '동작 없이도 동등한 경험을 제공하는 것'이다. 500ms 동안 페이드인되던 카드가 모션 감소 설정 사용자에게는 즉시 나타나야 한다. 콘텐츠는 동일하고, 전달 방식만 달라지는 것이다. usePreferredContrast는 한발 더 나아가 대비 강화 요청 시 전경·배경 색상 차이를 키우고, 폰트 굵기를 높이고, 테두리를 뚜렷하게 만드는 방식으로 반응해야 한다. 훅을 쓴다는 건 단순히 API 호출이 아니라 사용자의 의사결정을 UI로 번역하는 행위다.
같은 맥락에서 dev.to의 또 다른 글 'The Small Details That Make a Website Feel Finished'는 더 넓은 시각을 던진다. 저자는 "대부분의 웹사이트는 기능이 부족해서 미완성처럼 느껴지는 게 아니라, 주의가 부족해서 그렇게 느껴진다"고 말한다. 스크롤바 스타일, 텍스트 선택 색상, 호버 트랜지션, 포커스 아웃라인—이것들은 빌드를 실패시키지 않는다. 하지만 사용자는 이것들을 의식적으로 알아채지 못하면서도 감정적으로 감지한다.
이 두 시각이 만나는 지점이 흥미롭다. OS 수준 설정을 읽는 React 훅은 기술적 구현의 문제다. 포커스 아웃라인을 제거하지 않고 브랜드와 통일하는 것은 CSS 감각의 문제다. 그런데 그 결과는 같다. 사용자가 느끼는 '이 서비스는 나를 생각했구나'라는 신뢰. 접근성이 특정 장애 그룹만을 위한 것이 아닌 이유가 여기에 있다. 고대비 모드 사용자에게 명확한 버튼 경계를 제공하는 것과, 일반 사용자에게 일관된 호버 피드백을 주는 것은 같은 철학에서 나온다. 배려는 전파된다.
프로덕트 관점에서 보면 이건 단순한 품질 이슈가 아니다. 접근성과 퍼포먼스, 그리고 신뢰는 생각보다 강하게 연결되어 있다. 두 번째 글의 저자가 Lighthouse를 '점수판'이 아닌 '습관 형성 도구'로 재정의한 순간, 그의 사이트는 더 빨라졌을 뿐 아니라 더 가벼워지고 더 믿음직스러워졌다고 말한다. 불필요한 자바스크립트 제거, 레이아웃 시프트 방지, 올바른 시맨틱 HTML 사용—이것들은 동시에 접근성 개선이고, 성능 개선이고, 유지보수성 향상이다. 케어는 cascading된다.
그렇다면 우리가 지금 당장 바꿀 수 있는 것은 무엇일까. 거창한 리팩토링이 필요 없다. useReducedMotion 훅 하나를 공통 애니메이션 컴포넌트에 연결하는 것. 포커스 아웃라인을 outline: none으로 지워두었다면 되살리되 브랜드 컬러로 다듬는 것. 버튼 요소를 <div onClick> 대신 진짜 <button>으로 바꾸는 것. Lighthouse를 incognito 탭에서 한 번 돌려보는 것. 각각의 변화는 작지만, 그것들이 쌓이면 사용자가 느끼는 완성도의 질이 달라진다.
앞으로의 방향도 명확하다. React 19와 컴파일러 최적화, Next.js의 Partial Prerendering이 성능의 기본값을 높여가는 것처럼, OS 선호 감지와 적응형 UI는 점점 프론트엔드의 기본 기대치가 될 것이다. 지금 이것을 선택적 개선으로 두는 팀과, 설계 초기부터 내재화하는 팀 사이의 UX 격차는 시간이 갈수록 벌어진다. 가장 좋은 접근성은 나중에 추가하는 것이 아니라, 처음부터 없었던 적 없는 것이다.
결국 사용자를 존중하는 프론트엔드는 어떤 특별한 기술 스택의 문제가 아니다. useReducedMotion을 쓰든, 포커스 링을 살려두든, Lighthouse를 습관처럼 돌리든—그 바탕에는 하나의 질문이 있다. "이 경험이 사용자에게 진짜 도움이 되는가?" 코드를 짜기 전에 그 질문을 먼저 던지는 것, 그게 신뢰를 만드는 프론트엔드의 시작점이다.