체크박스 접근성과 실제 접근성 사이
프론트엔드 개발자라면 한 번쯤 이런 경험이 있을 겁니다. 기획서에 "TTS 기능 추가"라고 딱 한 줄 적혀 있고, 디자인 시안에는 스피커 아이콘 하나가 덩그러니 놓여 있는 상황. window.speechSynthesis 한 줄이면 '되긴 됩니다'. 문제는 '잘 되느냐'입니다. 사용자 입장에서 Chrome on macOS와 Samsung Internet on Android에서 동일한 TTS 경험을 기대하는 건, Figma에서 볼 때는 괜찮았는데 실제로 구현하면 폰트 렌더링이 달라지는 것과 본질적으로 같은 문제예요. 이번 주 눈에 띈 세 가지 소식을 교차해 보면, 이 '되는 것'과 '잘 되는 것' 사이의 간극이 접근성 영역에서 얼마나 넓은지 선명하게 드러납니다.
Web Speech API: 0원짜리 접근성의 함정
velog에 올라온 Next.js TTS 구현 가이드를 보면, useTTS 커스텀 훅으로 SpeechSynthesisUtterance를 감싸는 패턴이 깔끔하게 정리되어 있습니다. App Router의 "use client" 경계를 존중하면서 브라우저 API를 격리한 구조 자체는 나쁘지 않아요. 그런데 실제로 이걸 프로덕션에 올려본 사람이라면 알 겁니다—utterance.lang = 'ko-KR'을 설정해도 OS에 한국어 음성팩이 없으면 영어로 폴백되고, onend 이벤트가 Chrome에서는 정상 발화되는데 Safari에서는 긴 텍스트 중간에 씹히는 현상이 발생합니다. onboundary, onpause 같은 세부 이벤트까지 구독해야 isPlaying 상태가 실제 재생과 1:1로 매칭되죠.
기사에서도 언급하듯 결국 고품질 경험을 위해서는 서버사이드 AI TTS API로 마이그레이션해야 하고, 그 순간 Route Handler를 프록시로 쓰면서 API 키를 숨기고 audio/mpeg 스트리밍 응답을 처리하는 아키텍처가 필요해집니다. 접근성이 "추가 비용 없이 즉시 구현"에서 시작해도, 크로스 브라우저 일관성이라는 벽에 부딪히면 비용 구조가 완전히 달라진다는 게 핵심이에요. 이건 px 단위로 봐야 하는 문제입니다.
브레일센스 7: '잘 되는 것'의 물리적 증거
한국경제 보도에 따르면 셀바스헬스케어가 구글 Gemini를 점자 단말기에 공식 탑재한 '브레일센스 7'을 공개했습니다. 여기서 주목할 건 클라우드 Vertex AI와 온디바이스 Gemini Nano의 하이브리드 구조입니다. 시각장애인 사용자가 오프라인 환경—지하철, 시험장, 정전 상황—에서도 문서 요약과 사물 인식을 쓸 수 있다는 건, 우리가 웹에서 navigator.onLine만 체크하고 넘어가는 것과는 차원이 다른 UX 설계예요.
프론트엔드 개발자 관점에서 이 사례가 뼈아픈 이유가 있습니다. 우리는 네트워크 의존적 API 호출이 실패하면 "인터넷 연결을 확인해주세요" 토스트 하나 띄우고 끝내는 경우가 많잖아요. 그런데 점자 단말기 팀은 "연결이 안 될 때 이 기능이 없으면 사용자가 정보에서 완전히 차단된다"는 전제에서 출발합니다. 점자 키보드 입력 → AI 프롬프트 제어 → 점자 출력 + 음성 안내, 이 전체 플로우가 오프라인에서도 끊기지 않아야 한다는 요구사항은 '그레이스풀 디그레이데이션'의 교과서적 구현입니다.
번들 사이즈 12MB, 접근성 인프라의 무게
세 번째 퍼즐 조각은 Electrobun입니다. GeekNews를 통해 소개된 이 TypeScript 기반 데스크톱 프레임워크는 시스템 웹뷰를 기본으로 써서 자체 추출 번들 약 12MB를 달성합니다. Electron이 500MB 이상(압축 전 기준)을 차지하는 것과 비교하면 극적인 차이죠. bsdiff 기반 차등 업데이트로 패치 크기가 14KB까지 줄어든다는 건, 특히 접근성 소프트웨어 배포에서 중요한 의미를 갖습니다.
왜냐하면, 스크린 리더나 보조 기술 사용자를 위한 데스크톱 앱은 설치와 업데이트의 마찰이 곧 접근성 장벽이거든요. 500MB를 내려받는 동안 진행률 표시줄을 '볼 수 없는' 사용자를 상상해보세요. Electrobun의 OOPIF(Out-of-Process Iframe) 구현도 흥미로운데, Electron의 <webview> 태그가 Chromium에서 deprecated된 상태에서 프로세스 격리와 DOM 포지셔닝을 동시에 해결한 <electrobun-webview>는 접근성 트리(Accessibility Tree)와의 호환성 측면에서도 검증이 필요한 포인트입니다.
1px의 시사점
세 사례를 관통하는 메시지는 명확합니다. 접근성은 기능 체크리스트가 아니라 사용자 여정의 끝단까지 일관된 경험을 보장하는 엔지니어링이라는 것. Web Speech API로 TTS를 '넣었다'와 크로스 브라우저에서 '동일하게 작동한다'는 WCAG 2.1 기준으로도 완전히 다른 적합성 레벨이고, 온디바이스 AI를 '지원한다'와 오프라인에서도 '끊기지 않는다'는 사용자 입장에서 정보 접근 가능 여부 자체가 갈리는 문제입니다.
프론트엔드에서 접근성 구현을 논할 때, Lighthouse의 Accessibility 점수 100점이 전부가 아닙니다. aria-label 잘 달았다고 끝이 아니에요. 실제 스크린 리더로 탭 이동을 해보고, 실제 저사양 네트워크에서 TTS 폴백을 확인하고, 실제 12MB와 500MB의 설치 경험 차이를 체감해봐야 합니다. 브레일센스 7 팀이 온디바이스 AI까지 탑재하면서 오프라인 시나리오를 설계한 것처럼, "이 기능이 없으면 누군가가 완전히 배제된다"는 전제에서 시작하는 것—그게 '되는 것'과 '잘 되는 것'의 1px 차이를 만드는 디테일입니다.