GUI도 TUI만큼 키보드로 완전히 조작할 수 있어야 한다

키보드 접근성은 일반적인 접근성과 함께 종종 무시되거나 완전히 잊혀지는 것 중 하나입니다. 재미있는 점은 전자가 보통 후자에서 파생된다는 것입니다.

비난의 일부는 인기 있는 UI 프레임워크(또는 그러한 프레임워크를 사용하지 않기로 선택한 개발자)의 책임입니다. 오래된 프레임워크는 이 작업을 상당히 쉽게 만드는 경향이 있습니다. 예를 들어, Cocoa/AppKit(맥 네이티브 UI 프레임워크)에서는 시각적으로만 전체 UI를 적절한 키보드 탐색에 연결하는 것이 꽤 쉽습니다(주로 컨트롤 간에 nextKeyView 아울렛을 연결하여 탭 포커스의 논리적 체인을 만드는 것으로 구성됩니다). 키 단축키를 정의하는 것도 간단합니다. 명령에 대한 메뉴 항목을 추가하고 해당 단축키를 설정하면 됩니다(이를 통해 사용자는 시스템 설정에서 단축키를 자유롭게 다시 바인딩할 수 있습니다).

그러한 설계는 불행히도 최신 프레임워크에서는 선호되지 않게 되었습니다. 새로운 선호 스타일은 개발자가 어떤 부분을 채울지 선택하는 와이어프레임인 것 같으며, 종종 가장 기본적인 필수 요소만 포함됩니다.

파워 유저 경험은 일반적인 사용자 경험과 같지 않습니다. 모든 개발자 도구가 키보드 중심이어야 한다는 주장을 하고 싶다면, 그렇게 하세요. 하지만 대부분의 사람들은 키보드 중심 GUI의 학습 곡선을 기꺼이 감수하지 않으며, 그것은 괜찮습니다. 우리는 그것을 강요해서는 안 됩니다.

HN이 모든 사용자가 아치 리눅스 효율성 완벽주의 해커 유형인 것처럼 행동하는 것은 몹시 진부합니다.

(이 글은 의도보다 더 가혹하게 읽힙니다. 죄송합니다. 저는 아치 리눅스 사람들을 사랑합니다. 다만 평범한 사람을 위한 서비스가 파워 유저를 위한 완벽한 도구를 만드는 것보다 덜 고귀하지 않다고 생각할 뿐입니다.)

그렇다면 GUI가 키보드로 구동된다는 것은 무엇을 의미할까요?

가장 확실한 방법은 모든 동작에 단축키를 할당하는 것입니다.

제 반박은 그것이 진정한 키보드 구동이 아니라 단지 키보드 호환일 뿐이라는 것입니다.

발견 가능성 문제가 있습니다. 현재 모범 사례는 버튼의 단축키를 툴팁, 메뉴 항목 또는 다른 단축키를 눌렀을 때 표시하는 것 같습니다.

저는 버튼이 키보드와 근본적으로 맞지 않는다고 주장합니다. 키보드 중심 UI에는 버튼이 없어야 합니다.

문제는 CLI나 TUI와 같은 진정한 키보드 중심 UI는 발견 가능성이 매우 낮아서 마우스 중심 UI가 처음부터 존재하는 이유입니다. 그렇다면 마우스 클릭만큼 직관적인 키보드 중심 UI를 가질 수 있을까요?

마지막으로 CRUD 앱을 만들었을 때(약 24년 전쯤) 저는 이것을 하기로 마음먹었습니다. 급여 담당자들이 터미널 모드의 VAX VMS 애플리케이션을 그렇게 빠르고 능숙하게 사용하는 것을 보고, 어떤 유닉스 관리자도 부끄러워할 만큼의 속도와 손놀림에 감탄하며 이렇게 생각했습니다. '아, 그렇구나, 90년대의 모든 클릭 앤 포인트 GUI는 다 잘못됐어. 직장에서 시스템을 많이 사용해야 하는 사람들은 더 쉬운 학습 곡선(손재주를 발견 가능성과 맞바꾸는)보다 학습 곡선을 거친 후의 속도, 편안함, 손재주를 선호할 거야.'

그것은 웹앱 프레임워크였지만... 모든 탐색/목록 화면에는 행 ID와 포커스된 텍스트 상자가 포함되어 있어서 행 ID를 입력하고 Enter를 누르면 선택되도록 했습니다. 모든 동작 버튼에는 어떤 Ctrl-Shift 단축키가 트리거되는지 나타내는 밑줄이 있었습니다. 모든 편집 화면은 첫 번째 편집 가능한 텍스트 상자에 기본적으로 포커스가 맞춰졌고, 어떤 순간에도 마우스는 실제로 필요하지 않았습니다. 마지막으로, 로드 시간은 75ms를 목표로 최적화했습니다.

재미있게도, 사용자 피드백은 "키보드 제어는 꽤 좋은데, 더 빠르게 만들어 주시겠어요?"였습니다.

제가 크롬이라고 생각했던 것이 결국 사용자들이 불편하지 않도록 하는 데 결정적이었습니다.

동의합니다. 하지만 키보드로 사용할 수 있는 것만으로는 충분하지 않다고 생각합니다. 단축키는 발견하고 기억하기 어려운 경우가 많기 때문입니다. 이상적인 것은 좋은 TUI처럼 GUI도 키보드로 탐색하는 방법에 대한 명확한 힌트를 화면에 표시하는 것이라고 생각합니다.

일반적인 플랫폼(웹 포함!)을 위한 GUI 프레임워크가 이런 방식으로 설계되고 일반적인 동작에 대한 공통 단축키에 대한 의견을 제시하여 표준화할 수 있다면 정말 좋을 것입니다.

저자는 훌륭한 지적을 합니다. TUI를 만들기 위해 만들어진 형편없는 터미널 UI가 너무 많습니다. 종종 제대로 구성되지 않았거나 효과적/생산적이기 위한 충분한 고려가 부족합니다.

하지만 GUI 앱의 더 큰 추세는 키보드 사용자에게 생산성을 제공하는 것이 아니라 시장 점유율을 목표로 하는 것이었습니다. 80년대와 90년대에 Photoshop, Illustrator 등은 강력한 키보드 단축키 배열을 사용하여 전문가가 매우 효율적으로 작업할 수 있도록 하는 데 집중했기 때문에 오늘날의 강자가 되었습니다. 2026년에 소프트웨어 회사가 고객을 끌어들이는 구독 모델을 만드는 데 제품 관리를 평가하는 KPI 중독으로 죽어가고 있을 때, 키보드 사용자에게 실제로 생산성을 제공하는 데 대한 관심은 종종 부차적인 것으로 여겨집니다. 모바일 앱에는 키보드 단축키가 없고, 데스크톱 앱은 점점 더 수억 명의 대상 사용자만 있는 좁은 "엣지 케이스"로 취급되는 반면, 모바일 기기에는 수십억 명의 사용자가 있습니다. 키보드 단축키의 힘을 활용하여 GUI를 고도로 생산적이고 키보드로 완전히 사용할 수 있게 만드는 데 진지하게 임하는 사람들에게는 기회입니다. 모든 결점에도 불구하고 Microsoft는 VSCode에서 이것을 제대로 해냈습니다.

현대 컴퓨터 키보드는 지금까지 발명된 UI 중 가장 훌륭하고 훌륭한 것 중 하나입니다.

마우스, 스타일러스보다 훨씬 뛰어나며, 그것들은 터치스크린보다 훨씬 우월합니다.

> 실제로 많은 GUI 프레임워크 애플리케이션 가이드라인은 GUI 애플리케이션 개발자에게 권장합니다.

대신 개발자를 우회할 수 있도록 (적어도) 프레임워크 수준에서 일관된 방식으로 설계되어야 합니다. 개발자들이 집단적으로 "키보드에 능숙"해지는 때는 결코 없을 것이기 때문입니다.

최근에 확장된 qwerty 미디 컨트롤러 앱을 만들면서 깨달음을 얻었습니다. 이 앱은 수정자 키를 포함한 모든 키의 상태와 기능을 영구적으로 표시합니다.

이것이 소프트웨어를 설계하는 훌륭한 방법이라는 생각이 들었습니다. 키보드 단축키를 이미 보고 있기 때문에 즉시 알 수 있습니다. 저는 qwerty 미디 키보드 컨트롤러(hammerspoon 기반)를 위해 만든 것을 일반적인 인터페이스로 만들어 모든 종류의 앱에 적용할 수 있도록 작업 중입니다.

최종 목표가 키보드 단축키를 통해 앱을 탐색하고 제어하는 것이라면, 왜 GUI 설계 자체에 그것을 포함하지 않을까요?

제 프로젝트가 궁금하시다면: https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon