키보드로 전부 조작되는 GUI는 취향인가, 설계 품질의 지표인가
키보드로 전부 조작되는 GUI는 취향인가, 설계 품질의 지표인가
마우스 없이도 모든 기능에 닿을 수 있어야 한다는 요구는 터미널을 좋아하는 소수의 취향인가, 아니면 그 UI가 제대로 설계되었는지를 드러내는 지표인가.
도입
2026년 8월 28일, Charalampos Kardaris가 자신의 블로그에 「GUIs should be fully keyboard-driven」이라는 짧은 글을 올렸다. 이 글은 하루 만에 Hacker News 첫 페이지에 올라 1054점과 528개의 댓글을 모았다. 분량으로 보면 화면 한 장 남짓한 글이고, 새로운 기술도 벤치마크도 없다. 그럼에도 이 정도 반응이 나왔다는 사실 자체가 하나의 데이터다.
발단은 그 전주에 같은 커뮤니티에서 벌어진 논쟁이었다. 애플리케이션 개발자들에게 터미널 사용자 인터페이스(TUI) 만들기를 그만두고 그래픽 사용자 인터페이스(GUI)에 집중하라고 권하는 글이 올라왔고, 찬반이 격렬하게 갈렸다. Kardaris는 자신을 “헤비 터미널 사용자”라고 밝히면서도 양쪽 모두에 일리가 있다고 인정한다. 그가 문제 삼은 것은 논쟁 전체가 아니라, TUI 편에서 반복적으로 등장하는 논거 하나였다. “TUI는 키보드로 조작되기 때문에 더 낫다”는 주장이다.
그의 반박은 간단하다. 키보드 구동성은 TUI의 본질적 속성이 아니며, GUI가 그것을 못 하는 것도 아니다. 다만 많은 GUI 개발자가 하지 않을 뿐이다. 글의 마지막 문장은 이렇게 정리된다. 실현 가능성의 문제가 아니라 애플리케이션 개발자의 의지의 문제다.
논증 자체는 짧고 얇다. 그런데도 1054점이 붙었다는 것은, 이 글이 새로운 주장을 해서가 아니라 이미 많은 사람이 매일 겪고 있던 결핍에 정확한 이름을 붙였기 때문이다. 그렇다면 물어야 할 것은 저자의 주장이 옳은가가 아니라, 그 결핍이 어디서 왔고 무엇을 뜻하는가다. 키보드 완전 조작 가능성은 vim 사용자들의 취향 문제인가, 아니면 UI 설계 품질을 재는 지표인가.
원문의 주장과 즉각적인 반응
먼저 원문의 논증을 정확히 옮겨 두자. Kardaris는 이론상 GUI 프레임워크의 능력이 TUI 프레임워크의 능력을 포함하는 상위집합이므로 GUI가 선호되어야 한다는 GUI 옹호 논거를 이해한다고 밝힌다. 동시에 터미널 안에 “머무르면서” 필요를 모두 충족시켜 주는 TUI들을 매우 고맙게 여긴다고도 쓴다. 어느 한쪽 진영의 글이 아니라는 점을 먼저 못 박은 셈이다.
그가 반대하는 것은 딱 하나다. 무작위로 GUI 하나와 TUI 하나를 집으면 후자가 완전한 키보드 구동일 확률이 더 높다는 것은 사실로 인정한다. 그러나 그 사실이 GUI 대신 TUI를 개발할 근거가 되지는 않는다는 것이 그의 논지다. 그 확률 차이가 실제로 가리키는 것은 “많은 GUI 애플리케이션에서 키보드 내비게이션이 부실하다”는 사실이지, “GUI는 키보드 내비게이션을 할 수 없다”는 사실이 아니다.
근거로 그는 GNOME 휴먼 인터페이스 가이드라인을 인용한다. 포인팅 장치로 수행할 수 있는 모든 동작은 키보드로도 수행할 수 있어야 하며, 사용자 인터페이스의 모든 부분을 키보드만으로 이동하고 상호작용할 수 있어야 한다는 두 문장이다. 즉 이것은 소수 취향의 요구가 아니라 주요 GUI 프레임워크의 공식 지침에 이미 명문화된 규범이라는 것이다. 그는 개발자 모자를 쓴 자신 역시 첫 GUI 애플리케이션인 Klisi에서 사용 가능한 액션 전 범위를 겨냥한 키보드 단축키를 구현하는 데 시간을 들였다고 밝힌다.
HN 토론은 이 주장을 곧바로 현장 증언으로 검증했다. 한 이용자는 요즘 GUI 중에 Tab 키로 입력 필드와 선택 버튼을 순회하는 최소한의 기능조차 지원하지 않는 것을 점점 더 많이 본다고 적었다. 그가 덧붙인 관찰은 뼈아프다. 그 기능은 기억하기로 Windows 3.0 무렵에 도입된 것이다 (@walrus01). 30년 전에 기본값이었던 것이 지금은 예외가 되어 있다는 뜻이다.
규범의 위치를 짚은 지적도 나왔다. 웹에서 키보드 접근 가능한 UI는 WCAG 2.1.1 레벨 A 요구사항이며, 이는 “실패”를 등급으로 치지 않는 한 접근성 표준의 가장 기본 등급이다. 웹사이트나 웹 앱이 그것조차 달성하지 못했다면 충분히 노력하지 않은 것이라는 진단이다 (@onion2k). 즉 이 논의는 취향의 영역이 아니라 이미 최저 기준선이 문서화되어 있는 영역이다.
물론 반대 방향의 반응도 많았다. TUI는 혐오스러운 물건이고 대부분의 GUI는 그냥 웹이어야 한다는 강경한 의견 (@sublinear), UI의 역진화를 스피드런하는 것이냐는 냉소 (@dcrazy)가 상위에 올랐다. 가장 많이 인용된 한 줄은 “우리 엄마가 vim을 배울 리는 없다”였다 (@olivewong). 이 반응에는 곧바로 교정이 붙었다. 글의 주장은 “GUI가 키보드 내비게이션을 요구해야 한다”가 아니라 “모든 것이 키보드로도 가능해야 한다”는 것이라는 지적이다 (@Arainach). 이 오독은 사소해 보이지만 논쟁 전체를 관통한다. 키보드 경로를 추가하라는 요구와 키보드를 강제하라는 요구를 혼동하는 순간, 논의는 곧바로 파워 유저 대 일반 사용자의 진영 싸움으로 미끄러진다.
접근성에서 따라 나오는 것, 프레임워크 세대가 잃어버린 것
이 논쟁에서 가장 밀도 높은 논거는 접근성 쪽에서 나왔다. 키보드 접근성은 접근성 일반과 함께 양탄자 밑으로 쓸려 들어가거나 아예 잊히는 부류의 항목인데, 재미있는 것은 전자가 대개 후자에서 자연히 따라 나온다는 지적이다 (@cosmic_cheese). 스크린 리더를 쓸 수 있게 만들려면 각 컨트롤의 역할과 상태와 이름을 명시해야 하고, 그것을 하고 나면 키보드 도달 가능성은 대부분 부수적으로 확보된다.
같은 참가자는 책임의 상당 부분이 인기 UI 프레임워크에 있다고 본다. 그가 든 대비는 구체적이다. 예전 프레임워크들은 이 일을 상당히 쉽게 만들었다. macOS 네이티브 UI 프레임워크인 Cocoa/AppKit에서는 컨트롤 사이에 nextKeyView 아웃렛을 연결해 논리적인 체인을 만들어 주는 것만으로 UI 전체의 키보드 내비게이션을 거의 시각적으로 배선할 수 있었다. 단축키 정의도 단순해서, 명령에 해당하는 메뉴 항목을 추가하고 거기에 단축키를 지정하면 끝이었고, 그 결과 사용자가 시스템 설정에서 그 단축키를 마음대로 재바인딩할 수 있게 되는 이점까지 따라왔다. 그런데 그런 설계가 새 프레임워크들에서 인기를 잃었다는 것이다. 요즘 선호되는 방식은 개발자가 어느 부분을 채워 넣을지 고르는 와이어프레임에 가깝고, 대개는 최소한의 필수 요소만 채워진다.
이것이 핵심이다. 문제는 개발자 개개인의 게으름이 아니라 기본값의 방향이 뒤집힌 것이다. 표준 위젯을 쓰면 키보드 내비게이션이 거의 공짜로 딸려오던 시대에는 그것을 없애려면 노력이 필요했다. 지금은 반대로, 그것을 얻으려면 노력이 필요하다. 한 참가자는 Microsoft가 Windows와 그 위의 앱들의 접근성을 기본 요건으로 삼은 배경에 미국 정부 기관과 대기업의 조달 환경이 있었다고 지적하면서, 표준 위젯을 쓰면 거의 공짜로 얻는 것을 왜 마다하겠느냐고 반문했다 (@marshray).
흥미롭게도 원문이 예로 든 macOS는 이 대목에서 반례로도 쓰인다. macOS에는 의도적인 키보드 지원 구멍이 있다. 모든 요소에 키보드로 도달하려면 접근성 설정에서 전체 키보드 접근을 켜야 하고, 기본값은 대다수 사용자가 마우스로 조작한다는 전제 위에 있다 (@dpark). 수십 년 동안 macOS를 키보드만으로 다루는 데 애를 먹었으며 오히려 Windows의 오래된 컴포넌트들이 훨씬 접근성이 좋았다는 반대 증언도 나왔다 (@pathartl). 이 기본값을 옹호하는 쪽은 마우스가 갓 등장했을 때 개발자들에게 마우스 지원을 사실상 강제해야 했던 초기 Mac의 유산이라고 설명한다 (@danaris). 어느 쪽 해석을 택하든 결론은 같다. 플랫폼이 정한 기본값이 그 위에 올라가는 앱 전체의 품질 분포를 결정한다.
접근성이 소수만을 위한 비용이라는 통념에 대한 반박도 있었다. 연석 경사로 효과, 즉 장애인을 위해 만든 설계가 결과적으로 모두를 이롭게 하는 현상이 ADA 시행 과정 전반에서 잘 연구되어 있다는 지적이다 (@keerthiko). 바퀴 달린 여행 가방이 보도 경사로 보급 직후에 흔해진 것이 우연일 리 없다는 관찰 (@apothegm), 유모차를 끌어 보기 전에는 “거의” 접근 가능한 공간이 얼마나 많은지 몰랐다는 증언 (@my-huge-pony)이 뒤따랐다.
그리고 이 논쟁에서 가장 강한 주장은 접근성이 아니라 설계 품질 쪽에서 나왔다. 마우스는 훌륭하고 GUI가 마우스를 버려야 한다는 말이 아니지만, 데이터 입력 같은 작업에서 손을 키보드에 붙여 둘 수 있다는 것은 대단한 가치가 있으며, 무엇보다 키보드와 마우스 양쪽 입력을 모두 고려해 설계하면 한쪽만 설계할 때는 마주칠 일이 없었을 UI 설계의 거친 모서리들을 검토하게 되고 그래서 앱이 결과적으로 더 좋아진다는 것이다 (@bigstrat2003).
왜 그런지는 조금 더 밀고 나가 볼 가치가 있다. 마우스 전용 설계는 여러 질문에 답하지 않아도 된다. 좌표만 있으면 되기 때문이다. 반면 키보드 경로를 만들려면 UI를 선형화해야 하고, 그 과정에서 다음 질문들에 명시적으로 답해야 한다. 지금 포커스는 어디에 있는가. 그 다음은 어디인가. 그 순서는 사람이 화면을 읽는 순서와 같은가. 모달이 열렸을 때 그 뒤의 요소들은 여전히 포커스를 받는가. 목록에서 한 행을 지웠을 때 포커스는 어디로 가는가. 화면 밖으로 밀려난 요소가 탭 순서에 남아 있지는 않은가. 이 질문들에 답이 없다는 것은 키보드 사용자가 불편하다는 뜻만이 아니다. 그 화면의 상태 모델이 설계되어 있지 않다는 뜻이다. 키보드 경로는 그것을 드러내는 리트머스 시험지다.
이 규범을 무조건 밀어붙이는 것에 대한 반론도 공정하게 다뤄야 한다.
첫째는 비용이다. 좋은 키보드 구동 UI를 만드는 데는 상당한 감각과 추가 노력이 들고, UI가 바뀔 때마다 다시 손봐야 하는 이중 작업이라는 지적이 있었다. 같은 참가자는 반대 방향의 실패도 짚었다. 화려한 키보드 워크플로를 갖춰 놓고도 가장 사소한 작업조차 두 손을 키보드에 올려야 하는 경우가 있는데, 때로는 그냥 한 손을 트랙패드로 뻗고 싶을 뿐이라는 것이다 (@hombre_fatal). “해야 한다”는 규범이 복합적 책임의 압제로 이어지며, 대안 입력 경로를 추가하는 것이 프로젝트의 초기 및 유지보수 비용 한계를 넘길 수 있다는 경고도 나왔다 (@waffletower). 대형 사이트의 접근성 감사와 수정 비용이 기업 바깥에서 생각하는 것보다 훨씬 크다는 실무 증언도 있었다 (@stillpointlab). 다만 그 반대편에는 유럽 접근성법 아래에서 공공 서비스와 상당수 웹사이트가 이미 WCAG AA 수준을 요구받고 있어 선택 사항이 아니게 되었다는 지적이 놓인다 (@Cthulhu_).
둘째는 입력 양식의 적합성이다. GUI의 큰 장점은 상호작용 가능한 2차원 좌표 입력, 즉 포인터와 제스처인데 키보드는 바로 그것을 결여하고 있으므로, GUI 전체를 키보드로 구동 가능하게 강제하는 것은 GUI의 주된 장점을 제한하는 일이 될 수 있다는 반론이다. 이 참가자는 키보드와 포인터가 시너지를 내며 함께 쓰이는 Emacs나 Plan 9 스타일을 선호한다고 밝히며 영상 편집기, DAW, 2D/3D 씬 에디터를 예로 들었다 (@binary132). 가능한 곳에는 단축키를 두고 적절한 곳에는 스크린 리더가 읽을 수 있는 레이블을 붙이되, 자신은 OneNote와 Macromedia Freehand를 스타일러스로 쓴다며 용도마다 맞는 도구가 따로 있다고 정리한 의견도 같은 맥락이다 (@WillAdams).
셋째는 발견 가능성이다. 키보드로 쓸 수 있다는 것만으로는 충분하지 않은데, 단축키는 발견하기도 기억하기도 어렵기 때문이며 좋은 TUI처럼 GUI도 화면에 키보드 내비게이션 힌트를 명확히 띄워야 한다는 요구가 나왔다 (@marklar423). 모든 UI가 탭 가능해야 하지만 그것만으로는 키보드 사용자에게 여전히 비참한 경험이라는 진단과 함께, 즉시 발견 가능한 단축키를 제공하는 세 가지 방법이 정리되기도 했다. 모든 요소를 격자에 배치해 방향키로 이동 가능하게 만드는 방법은 디자이너에게 큰 제약이고, 모든 버튼 옆에 단축키를 표시하는 방법은 툴팁에 숨겨서는 안 되므로 공간을 잡아먹으며, 커맨드 팔레트를 추가하는 방법은 가장 쉽지만 모든 액션을 팔레트에 미러링해야 하고 집합의 각 항목마다 같은 액션이 붙는 경우에는 잘 맞지 않는다는 것이다 (@SebastianKra). 만드는 노력만이 아니라 쓰는 노력도 든다는 점, 그래서 “vim을 어떻게 빠져나오지”라는 밈이 존재하며 좋은 UI에는 사용자가 헤엄을 배우는 동안 물 위에 머리를 둘 수 있는 탈출구가 필요하다는 지적도 정확하다 (@halfcat).
커맨드 팔레트는 왜 살아남았는가, 그리고 실무자는 무엇을 할 수 있는가
그렇다면 실제로 확산에 성공한 패턴은 무엇인가. 답은 하나로 모인다. 커맨드 팔레트, 즉 범용 명령 검색창이다. 많은 웹 UI가 최근 추가한 유일한 UI 발명이 이것이며, JetBrains IDE에서 10년 넘게 쓰여 왔고 메뉴를 뒤지는 것에 비해 눈에 띄는 개선이었다는 증언이 나왔다. 이 참가자는 KeyPromoter 확장을 켜 둔 덕에 시간이 지나며 단축키까지 익혔다고 덧붙이며, 지금은 이 범용 명령 검색이 Cloudflare나 Mercury 같은 웹 서비스 어디에나 있다고 관찰했다 (@arjie). 커맨드 팔레트는 명령을 키보드만으로 접근 가능하게 만들면서 동시에 발견 가능하게 만든다는 평가도 뒤따랐다 (@FranklinMaillot).
왜 이 패턴만 살아남았는가. 학습 비용을 사용자에게 선불로 청구하지 않기 때문이다. 진입점이 하나뿐이고, 그 하나만 알면 나머지는 검색으로 해결된다. 사용자는 명령의 이름을 몰라도 되고 근사치를 입력하면 목록이 좁혀 준다. 반면 모달 편집기는 정반대다. vim은 쓸모를 내주기 전에 모드 모델 전체를 먼저 요구한다. 게다가 팔레트는 자기 문서화 장치이기도 하다. 목록 자체가 기능 목록이자 단축키 대조표이므로, 발견 가능성 문제를 별도의 도움말이 아니라 UI 안에서 해결한다. 그리고 숙달 경로가 연속적이다. 검색으로 시작해 반복하다 보면 옆에 표시된 단축키가 눈에 익고, 준비된 사용자만 다음 단계로 올라간다. 어떤 사용자도 강제로 승급당하지 않는다.
같은 논리는 플랫폼 기본값에도 적용된다. macOS 대부분의 앱에서 특정 조합으로 메뉴바 검색을 열 수 있고 이를 통해 앱 기능 대부분을 키보드에서 꺼낼 수 있는데, 커맨드 팔레트만큼은 아니어도 그에 근접하며 무엇보다 개발자가 옵트인할 필요 없이 앱 메뉴만 제대로 채워 두면 된다는 지적이다 (@cosmic_cheese). 이것은 원문 저자의 진단을 뒤집어 볼 여지를 준다. 개발자들이 집단적으로 “키보드에 밝아지는” 날은 오지 않을 테니, 대신 사용자가 프레임워크 차원의 일관된 방식으로 개발자를 우회할 수 있도록 설계되어야 한다는 의견이 그 지점을 정확히 찔렀다 (@eviks).
웹 앱에서 키보드 경로를 확보하는 방법은 이미 상당히 표준화되어 있다. 순서대로 정리하면 이렇다.
첫째, 시맨틱 요소를 먼저 쓴다. 버튼을 div로 만들지 않는 것만으로 포커스 가능성, Enter와 Space에 의한 활성화, 스크린 리더가 읽는 역할이 공짜로 따라온다. 그것을 div와 tabindex와 키 핸들러로 재현하기 시작하는 순간 비용이 발생하고, 대개 몇 가지를 빠뜨린 채 끝난다.
둘째, 네이티브 요소로 만들 수 없는 커스텀 컨트롤에는 W3C의 ARIA 오소링 프랙티스 패턴을 따른다. 자동완성 드롭다운이 붙은 검색창 같은 것을 만들 때 역할과 상태와 키보드 상호작용이 명확히 문서화되어 있다는 실무 추천이 있었다 (@rhdunn). 다만 그 비용의 실제 크기도 함께 기록해 둘 만하다. 스타일이 입혀진 드롭다운 하나를 제대로 만들기 위해 ARIA 콤보박스 문서를 일주일 내내 열어 두고 씨름했고 그러고도 몇 가지가 여전히 빠져 있다는 증언이 나왔다 (@phatskat).
셋째, 포커스 관리다. 모달을 열 때 포커스를 안으로 옮기고 그 안에 가둔 뒤(포커스 트랩) 닫을 때 원래의 트리거로 되돌린다. 라우팅으로 화면이 바뀌면 포커스를 초기화한다. 목록에서 항목을 지웠을 때 포커스가 문서 최상단으로 튕기지 않게 한다. 탭 순서는 DOM 순서를 따르므로, 양수 tabindex로 순서를 조작하는 대신 시각적 배치 순서와 DOM 순서를 일치시키는 것이 옳은 해법이다.
넷째, 단축키 충돌이다. 브라우저와 OS와 스크린 리더가 이미 예약한 조합을 피하고, 텍스트 입력 중에는 단일 문자 단축키를 비활성화하며, 재바인딩 수단을 제공한다. AppKit이 메뉴 항목의 단축키를 시스템 설정에서 재바인딩 가능하게 만들었던 것이 여기서 다시 참고가 된다.
그러나 이 규범을 어디에나 같은 강도로 적용하는 것이 이 논쟁의 가장 흔한 오류다. 정보 밀도가 높은 기술 UI와 일반 소비자 앱은 구분해야 한다.
대시보드, 어드민 콘솔, 데이터 입력 화면은 소수의 전문 사용자가 같은 화면을 하루에 수백 번 반복하는 곳이다. 여기서 키보드 경로는 편의가 아니라 처리량 그 자체다. 2000년대 초 사무직 인력이 레거시 시스템에서 웹으로 옮겨 갈 때 tabindex 순서를 정하는 일이 대단히 중요한 사안이었으며, 업무의 90퍼센트를 키보드로 처리할 수 있게 해 주면 그들은 날아다녔고 그렇지 않으면 프로젝트 말미에 매우 화가 난 고객을 만나게 되었다는 회고가 있었다. 이 참가자는 그것이 접근성 문제이기 이전에 그냥 좋은 UI 설계라고 정리했다 (@theeyescanner). 회계 애플리케이션을 만들 때 올바른 탭 순서를 종이 문서로 적어 두고 정기적으로 점검하고 갱신했으며 그러지 않았다면 POS 담당자들에게 살해당했을 것이라는 증언도 같은 이야기다 (@nottorp). 이 영역에서는 단축키 밀도와 탭 순서에 예산을 쓰는 것이 정당하고, 발견 가능성은 온보딩과 치트시트로 보완할 수 있다.
반면 한 달에 한 번 열리는 소비자 앱에서 사용자는 단축키를 외울 동기가 없다. 여기서 필요한 것은 모달 편집기가 아니라 하한선이다. 모든 기능이 키보드로 도달 가능할 것, 포커스가 눈에 보일 것, 탭 순서가 읽는 순서와 같을 것. WCAG 2.1.1 레벨 A가 요구하는 바로 그 수준이다. 커맨드 팔레트조차 여기서는 과할 수 있다. TUI 회귀에 대한 냉소도, “우리 엄마는 vim을 못 배운다”는 반응도, 실은 전자의 규범을 후자에 통째로 옮겨 붙이는 것에 대한 거부 반응이다. 그리고 그 반대 방향의 오류, 즉 소비자 앱의 기준을 어드민 콘솔에 적용하는 것은 조용히 처리량을 갉아먹는다.
입력 양식 자체가 다른 맥락도 잊어서는 안 된다. 스타일러스로 그리는 노트 앱이나 터치 전용 모바일 화면에서는 물리 키보드가 아예 없다. 모두가 마우스를 가진 것도 아니지만 모두가 화면 아닌 키보드를 가진 것도 아니라는 반문 (@Joker_vD)에 대한 답은 이미 나와 있다. 그러니 양쪽 선택지를 모두 제공하자는 것이다 (@sejje). 하한선은 “키보드 우선”이 아니라 “단일 입력 양식에 종속되지 않을 것”이다.
향후 시나리오는 셋으로 갈린다. 낙관적으로 보면 유럽 접근성법 같은 규제와 커맨드 팔레트의 관성이 겹쳐 프레임워크 기본값이 다시 뒤집힌다. 현실적으로는 규제 대상 대기업과 개발자 도구에서만 개선이 일어나고 나머지는 정체한다. 비관적으로는 즉시 모드 GUI 계열처럼 접근성 처리가 사실상 부재한 툴킷이 새 세대 앱으로 확산한다. 실제로 그 계열이 디버그용을 넘어 널리 쓰이는 것이 문제이며 애초에 그렇지 않더라도 접근성 부재는 문제라는 지적이 토론에 있었다 (@ethin).
한 가지 새 변수는 LLM이다. LLM이 모든 파워 유저 기능의 밑바탕에 깔린 발견 가능성 문제를 해결하며, 이전에는 목표 달성의 전제 조건이던 도메인 지식 없이도 원하는 바를 서술할 수 있게 되었다는 관찰이 나왔다 (@TonyStr). 다만 이것은 “명령을 찾는 문제”를 해결할 뿐 “포커스와 순서”라는 구조 문제를 해결하지 않는다. 오히려 에이전트가 GUI를 대신 조작하려 할수록 키보드 경로와 시맨틱 구조가 기계가 읽을 수 있는 유일한 표면이 된다. 이것이 있으면 AI도 고마워할 것이라는 짧은 댓글 (@sciencesama)은 농담이지만 방향은 맞다.
결론
돌아가서 처음 질문에 답하자면, 키보드 완전 조작 가능성은 취향이 아니라 지표다. 다만 지표인 것은 “모든 것을 키보드로 해야 한다”는 결과가 아니라 “키보드 경로를 설계했는가”라는 과정 쪽이다. 키보드 경로는 마우스 좌표가 감춰 주던 질문들을 강제로 꺼내 놓는다. 포커스는 어디 있고, 다음은 어디이며, 이 컨트롤의 상태는 무엇이고, 모달 뒤편은 어떻게 되는가. 이 질문들에 답이 없다면 키보드 사용자가 불편한 것이 아니라 그 화면에 상태 모델이 없는 것이다. 양쪽 입력을 모두 설계하면 UI 자체가 좋아진다는 주장이 이 논쟁에서 가장 강한 이유가 여기에 있다.
동시에 원문의 진단, 즉 이것이 실현 가능성이 아니라 개발자 의지의 문제라는 결론은 절반만 맞다. 의지에 의존하는 품질은 확산하지 않는다. nextKeyView 하나로 탭 체인을 배선할 수 있던 프레임워크와 메뉴만 채우면 명령 검색이 따라오는 플랫폼이 보여 준 것은 의지가 아니라 기본값의 힘이다. 실제로 널리 퍼진 유일한 패턴인 커맨드 팔레트도, 사용자에게 학습 비용을 선불로 청구하지 않았기 때문에 퍼졌다. 규범을 외치는 대신 기본값을 바꾸는 쪽이 언제나 더 멀리 간다.
그래서 남는 질문은 이렇다. 지금 만들고 있는 화면에서 Tab을 열 번 눌러 보라. 포커스가 지금 어디에 있는지 눈으로 확인할 수 있는가. 그 이동 순서는 사람이 화면을 읽는 순서와 같은가. 둘 중 하나라도 답할 수 없다면, 그것은 키보드 사용자만의 문제인가 아니면 아직 설계되지 않은 화면인가.
출처: