TL;DR: pane, 키보드 선택, 마우스 호버 세 상태를 분리 관리하면 키보드 네비게이션의 안정성과 마우스 호버의 즉각적 피드백을 동시에 확보할 수 있습니다.
이 모델은 TUI 스타일 키보드 네비게이션을 웹 UI에 적용할 때 사용합니다. 사용자가 hjkl나 방향키로 pane과 항목을 이동하고, 마우스로 항목을 가리키며, 두 입력 방식을 충돌 없이 혼용할 수 있게 합니다.
이 모델은 세 가지 핵심 상태와 하나의 파생 값으로 구성됩니다. 첫 번째는 activePane으로, 현재 키보드 명령이 적용되는 영역(예: 탐색기, 결과 창, 미리보기 창)을 의미합니다. 좌우 화살표(h/l)로 전환됩니다. 두 번째는 selectedItem으로, 활성 pane 내에서 키보드(위아래 화살표 j/k)로 선택된 항목입니다. 이 상태는 URL 쿼리 파라미터와 동기화되어 브라우저 히스토리에 남을 수 있습니다. 세 번째는 hoveredItem으로, 마우스가 현재 가리키는 항목으로, 일시적 상태이며 마우스가 벗어나면 사라집니다. 마지막으로 previewItem이라는 파생 값이 있는데, 이는 화면에 실제로 표시할 미리보기 항목을 결정합니다. hoveredItem ?? selectedItem 규칙으로, 즉 호버 중일 때는 호버된 항목을, 그렇지 않으면 키보드 선택 항목을 보여줍니다.
동작 규칙은 다음과 같습니다. h(왼쪽) 또는 l(오른쪽) 키를 누르면 활성 pane만 변경되며, 선택 항목은 그대로 유지됩니다. 활성 pane에서 j(아래) 또는 k(위) 키를 누르면 해당 pane의 selectedItem이 변경됩니다. 탐색기 pane에서는 선택 변경이 즉시 필터 적용으로 이어질 수 있습니다. 문서 열기는 항목 클릭, Enter 키, 미리보기 pane의 전용 버튼으로만 가능하며, l 키는 pane 이동 전용으로 문서를 열지 않습니다. 호버 처리에 있어 마우스 호버는 selectedItem을 대체하지 않습니다. 호버는 previewItem에만 영향을 주어 미리보기 내용을 즉시 갱신하되, 키보드 선택 맥락은 유지합니다.
이 모델의 설계 트레이드오프로는 몇 가지 장점과 단점이 있습니다. 장점으로는 키보드 사용자에게 선택 상태가 예측 가능하게 유지되고, 마우스 사용자가 호버로 빠르게 미리보기를 확인할 수 있으며, URL을 통해 선택 상태를 공유하거나 북마크할 수 있다는 점이 있습니다. 단점으로는 상태 변수가 많아 관리가 복잡해지고, 사용자가 키보드 선택과 마우스 호버라는 두 종류의 "선택"을 학습해야 한다는 점이 있습니다. 이 모델은 문서 브라우저, 파일 관리자, 대시보드 등 키보드로 빠르게 이동해야 하는 정보 집약적 인터페이스에 적합합니다. 반면, 단순 폼이나 모달 대화상자처럼 상호작용이 짧고 포커스가 명확한 경우에는 부적합할 수 있습니다.
구현 시 핵심 원칙은 세 가지입니다. 첫째, URL 동기화로 selectedItem 상태는 URL 쿼리 파라미터와 동기화하여 히스토리 오염을 최소화하는 방식으로 관리해야 합니다. 둘째, 이벤트 관리로 키보드 이벤트는 전역에서 수신하되, 입력 필드 등에서는 적절히 비활성화해야 합니다. 호버 상태는 onMouseEnter/onMouseLeave로 관리하며, onMouseLeave 시 previewItem이 selectedItem으로 복귀합니다. 셋째, 시각적 피드백으로 pane 이동 시 테두리 강조 등 시각적 단서를 제공해 현재 활성 pane을 명시해야 합니다.
관련 항목으로는 URL 상태 동기화 (쿼리 파라미터로 UI 상태 유지), React에서의 전역 키보드 이벤트 관리, 접근성을 고려한 키보드 네비게이션 설계가 있습니다.
미해결 질문으로는 모바일 터치 환경에서 이 모델을 어떻게 적용할 것인가 (호버 개념이 없음)와 중첩된 목록이나 트리 구조에서 j/k 이동을 어떻게 확장할 것인가가 남아 있습니다.