프론트엔드 품질을 이야기할 때 우리는 보통 두 개의 다른 대화를 한다. 하나는 개발자 자신이 느끼는 체감 속도—핫 리로드가 빠른지, 빌드가 버벅이지 않는지. 다른 하나는 사용자가 느끼는 인터랙션 품질—탭 키를 눌렀을 때 포커스가 사라지지 않는지, 스크린 리더가 의미 있는 구조를 읽는지. 이 두 대화가 같은 자리에서 이뤄지는 경우는 드물다. 그런데 최근 dev.to에 올라온 두 편의 글이 마침 같은 시점에, 이 두 축의 '소리 없는 비용'을 각자의 방식으로 드러냈다.
첫 번째는 Vite HMR에 관한 글이다. 요지는 단순하다. 맥북 팬이 계속 돌고 있다면, 범인은 크롬도 슬랙도 아닐 수 있다. Vite의 기본 HMR 설정이 파일을 수정하지 않는 동안에도 웹소켓 연결을 유지하고 파일 변경을 폴링하면서 번들을 공격적으로 재빌드하고 있을 가능성이 높다. 필자는 macOS 환경에서 감사한 6개 프로젝트 중 6건에서 이 패턴을 확인했고, HMR을 끈 뒤 M2 에어 기준 CPU 사용률이 30~50% 낮아졌으며 하루 배터리 수명이 4시간에서 6시간으로 늘었다고 보고한다.
흥미로운 건 이 문제가 '숨겨진 결함'이라는 점이다. Vite의 공식 문서는 HMR을 기본값으로 당연히 켜두고, 성능 비용은 FAQ 한 켠에만 언급한다. 대부분의 React 튜토리얼은 Vite를 설치하고 pnpm dev를 실행하는 것으로 끝낸다. 결과적으로 개발자들은 'Vite는 빠르다'는 전제 아래 하루 8시간 동안 팬을 켜놓은 채 작업한다. 해결책은 단 두 줄이다. package.json에 dev:cold 스크립트를 추가하고, 파일을 실제로 편집하지 않는 세션—코드 리뷰, 문서 열람, 화면 공유—에서는 HMR=off vite로 실행하는 것. 기능 개발 세션에서는 HMR을 켜고, 나머지에서는 끄는 컨텍스트 인식이 핵심이다.
두 번째 글은 결이 다르다. React로 완전히 접근 가능한 메인 내비게이션 컴포넌트를 처음부터 구축하는 시리즈의 일부로, 이번 편은 단일 리스트에서의 키보드 핸들링에 집중한다. HOME/END 키, 좌우 화살표 키로 리스트 내 포커스를 순환시키는 구현—겉보기엔 사소해 보이지만, 이게 없으면 키보드만으로 화면을 탐색하는 사용자는 내비게이션에서 길을 잃는다.
필자가 짚는 핵심 문제의식이 날카롭다. 많은 개발자들이 키보드 핸들링을 '브라우저가 알아서 해주는 것'으로 여긴다는 것. 실제로 기본 HTML 요소는 어느 정도 그렇다. 하지만 커스텀 위젯—드롭다운 내비게이션, 탭 패널, 콤보박스 같은 것들—은 다르다. WAI-ARIA의 APG(Authoring Practices Guide)가 명시하는 키보드 패턴을 개발자가 직접 구현해야 한다. 스크린 리더 사용자만의 문제가 아니다. 스크린과 키보드를 함께 쓰는 사용자—예컨대 마우스를 쓰기 어려운 사람들—는 페이지를 선형으로만 탐색할 수 있고, 포커스가 예상치 못한 곳으로 튀거나 사라지면 그 사이트는 '망가진 것처럼' 느껴진다.
구현 관점에서 흥미로운 선택이 있다. 리스트 내 각 링크와 버튼이 별개의 컴포넌트로 렌더링되는 구조상, 한 요소가 형제 요소를 알 방법이 없다. 이를 해결하기 위해 NavigationListProvider라는 컨텍스트 프로바이더를 도입하고, 각 포커서블 요소가 마운트 시 자신을 등록하는 패턴을 사용한다. 상태 관리에는 useState 대신 useReducer를 선택했는데, 여러 컴포넌트에 걸친 상태 업데이트와 이전 상태 의존 로직을 다루기 위한 적절한 판단이다. TypeScript + React 19 + Next.js 조합으로 작성된 코드는 GitHub에 릴리스(0.4.0) 단위로 공개되어 있어 단계별 추적이 가능하다.
이 두 글이 같이 읽힐 때 드러나는 공통 구조가 있다. 둘 다 '기본값의 함정'을 다룬다. Vite HMR은 켜져 있는 게 기본이고, 커스텀 키보드 핸들링은 없는 게 기본이다. 두 경우 모두 그 기본값을 그대로 받아들이면 누군가의 경험이 소리 없이 나빠진다. 전자는 개발자의 배터리와 집중력을, 후자는 키보드 사용자의 탐색 흐름을 갉아먹는다. 그리고 두 경우 모두, 문제를 알아채는 데 실패하는 이유가 '문서화의 부재'가 아니라 '시작 경험에서의 부재'라는 점도 닮아 있다.
프론트엔드 품질 기준을 다시 세운다면, 출발점은 이 두 질문이어야 한다. 지금 이 개발 세션에서 HMR이 켜져 있어야 할 맥락인가? 지금 이 컴포넌트를 키보드만으로 완전히 탐색할 수 있는가? 첫 번째 질문은 30초, 두 번째 질문은 탭 키 몇 번으로 답이 나온다. 비용 대비 효과가 이 정도로 비대칭인 체크리스트는 흔하지 않다. DX와 접근성, 이 둘을 별개의 전문 영역으로 나눠두는 관행이 결국 개발자와 사용자 모두의 경험을 동시에 나쁘게 만든다는 사실을 두 글은 나란히 증명하고 있다.