마우스 중심 UI는 정말 진보였을까: 594표가 다시 꺼낸 키보드 우선 논쟁

마우스는 컴퓨터 대중화의 일등 공신입니다. 그런데 최근 594표를 받은 문제 제기가 오래된 질문을 다시 불러냈습니다. 마우스 중심 인터페이스는 정말 모두를 위한 진보였을까요?

GUI의 발전은 마우스의 승리였을까

명령어를 직접 입력하던 시절에 비하면 그래픽 사용자 인터페이스는 혁명이었습니다. 파일을 아이콘으로 보여주고, 메뉴를 클릭해 원하는 기능을 실행할 수 있게 됐습니다.

문제는 그다음부터입니다. GUI가 발전하면서 ‘화면에서 보이는 것을 포인터로 누른다’는 방식이 기본으로 자리 잡았습니다. 키보드는 글자를 입력하거나, 단축키를 외운 사람만 쓰는 보조 장치처럼 뒤로 밀려났습니다.

하지만 클릭은 생각보다 손이 많이 갑니다. 손을 키보드에서 떼고 포인터를 찾은 다음, 작은 목표물까지 옮겨 다시 클릭해야 합니다. 버튼 하나를 누를 때는 편하지만 같은 작업을 수십 번 반복하다 보면 흐름이 자주 끊깁니다.

키보드 중심 도구가 개발자와 전문 사용자에게 꾸준히 사랑받는 이유도 여기에 있습니다. 손이 오가는 거리가 짧고, 작업 순서를 명령처럼 이어갈 수 있기 때문입니다.

키보드 우선 설계라고 해서 기능마다 복잡한 단축키를 붙여야 하는 것은 아닙니다. 기본은 훨씬 단순합니다.

Tab으로 다음 요소로 이동하고, Shift+Tab으로 돌아갈 수 있어야 합니다. Enter와 Space로 버튼을 실행하고, Esc로 열린 창을 닫을 수 있어야 합니다. 지금 어디가 선택돼 있는지도 화면에 분명하게 보여야 합니다.

흔히 생기는 실수도 있습니다. 개발자가 일반 텍스트 영역인 div에 클릭 기능만 연결하는 경우입니다. 마우스로 누르면 버튼처럼 작동하지만 키보드로는 초점을 맞출 수 없습니다. 화면 낭독기에도 이것이 버튼이라는 사실이 전달되지 않습니다.

반면 HTML의 실제 button 요소를 사용하면 기본적인 키보드 동작과 의미가 함께 따라옵니다. 접근성은 별도 기능을 덧붙이는 일이라기보다, 처음부터 알맞은 부품을 고르는 일에 가깝습니다.

마우스를 쓰기 어려운 사람들의 사정은 저마다 다릅니다. 손이나 팔을 움직이기 힘든 사용자도 있고, 화면을 확대해서 보기 때문에 포인터 위치를 찾기 어려운 사용자도 있습니다. 화면 낭독기와 키보드를 함께 사용하는 시각장애인도 있습니다.

상황이 달라지면 누구나 같은 문제를 겪을 수 있습니다. 손목을 다쳤을 수도 있고, 노트북 터치패드가 고장 났을 수도 있습니다. 흔들리는 이동 수단에서 작은 버튼을 눌러야 할 때도 있습니다.

그래서 국제 웹 접근성 지침은 주요 기능을 키보드로 조작할 수 있어야 한다고 요구합니다. 특별한 편의 기능이라기보다 입력 장치를 선택할 권리에 가깝습니다.

키보드 접근성을 제대로 갖추면 서비스의 자동화와 테스트도 쉬워집니다. 화면을 이루는 요소와 이동 순서가 또렷해지기 때문입니다. 접근성을 고려해 정돈한 구조가 결국 제품의 전반적인 품질도 높여줍니다.

물론 마우스를 없애자는 이야기는 아닙니다. 처음 접하는 기능을 둘러볼 때는 아이콘과 포인터가 편합니다. 그림을 그리거나 지도를 움직일 때도 마우스가 자연스럽습니다.

반대로 반복 작업을 하거나 빠르게 이동할 때는 키보드가 강합니다. 검색창을 여는 /, 명령 팔레트를 호출하는 단축키, 방향키로 움직이는 목록이 대표적입니다. 좋은 인터페이스는 둘 중 하나만 쓰라고 강요하지 않습니다.

설계하는 순서도 바꿔볼 만합니다. 먼저 키보드만으로 주요 작업을 끝낼 수 있는지 확인합니다. 그 위에 마우스와 터치가 주는 편리함을 더합니다. 이렇게 만들면 기능의 구조가 단순해지고, 포인터에만 의존할 때 생기는 숨은 장벽도 줄어듭니다.

이번 논쟁은 594표라는 반응을 얻었지만, 최근 한 달 동안 이어진 커뮤니티 사례는 충분히 확인되지 않았습니다. 그래도 문제의식은 분명합니다. 다음에 웹사이트나 앱을 열었을 때, 마우스를 치우고 원하는 작업을 끝까지 해볼 수 있으신가요?