손가락 친화적인 상호작용을 설계하는 일, 그리고 손과 뇌의 놀라운 능력을 존중하는 인터페이스에 관한 글.
Marcin Wichary
18 June 2026/ 7,700 words/ 38 playgrounds
백여 년 전쯤, 한 가지 문제가 있었다. 사람들은 그저 너무 빨리 타이핑하고 있었다.
무슨 생각을 하는지 안다. 그 시대의 원시적인 타자기에게는 너무 빠르게 타이핑했다는 이야기라고. 하지만 대중의 믿음과는 달리, 타자기는 결코 그렇게까지 원시적이지 않았다. 최초의 대중적 타자기에서도 정말 빠르게 칠 수 있었고, QWERTY 배열은 실제로 바로 그것이 가능하도록 설계되었다.
아니, 사람들은 우리 몸이 할 수 있다고 생각한 것보다 더 빨리 타이핑하고 있었다. 뇌 안에서 이동하는 뉴런, 감각 처리, 손가락의 물리적 능력에 대한 당시의 이해로는, 타이피스트는 분당 40단어를 조금 넘는 수준에서 한계에 도달했어야 했다.
그런데 그들은 일상적으로 분당 70단어 이상을 쳤다.
알고 보니 손가락은 시간 여행자다. 어느 한 순간에도 각각의 손가락은 조금씩 다른 시간 속에 산다. 한 손가락이 키를 누르기 위해 아래로 움직이는 동안, 다른 손가락은 이미 다음 키로 향하고 있고, 당신의 뇌는 몇 개의 키 앞을 미리 생각하며 손이 올바른 위치로 움직이는 모습을 그려본다.
1897년 Michigan Central Railroad의 배차실 사진, 두 대의 타자기가 보인다
손과 뇌가 손가락들을 비교적 독립적으로 다루고, 다른 손가락(같은 손에 있는)들이 끝나기를 기다리지 않고 각자 자기 속도로 움직이게 하는 능력.
이 중 어느 것도 터치 타이핑을 필요로 하지 않는다. 결국 우리가 오버래핑이라 부르게 된 현상은, 당신이 어색한 “hunt”와 “peck”의 교차점 어딘가에 머물러 있어도 일어난다. 오버래핑은 눈앞에서 벌어지는 작은 기적이며, 거의 모든 사람에게서 일어난다.
그리고 그것만이 유일한 기적도 아니다. 우리의 손은 놀랍고, 손가락은 놀랍고, 우리의 뇌도 놀랍다. 모두 합쳐서, 얼마 전까지만 해도 과학적으로 전혀 말이 되지 않던 일들, 그리고 때로는 오늘날에도 여전히 설명되지 않는 일들까지 해낼 수 있다.
예술가와 연주자들은 수세기 동안 이를 직관적으로 알고 있었다. 오늘날에는 많은 창의성과 또한 생산성이 화면 위에서 일어나지만, 우리의 인터페이스는 예전의 도구들이 그랬던 방식으로 손가락을 존중하지 않는 경우가 많다.
나는 그것에 대해, 그리고 디자이너로서 당신이 반드시 그렇게 되도록 해야 할 책임에 대해 더 이야기하고 싶다.
소리를 끄고, 작업을 추적하고, 화면 상단의 메뉴를 사용해 탐색할 수 있습니다.
진행 상황은 세션 간에 저장됩니다.
컴퓨터가 1960년대의 최고급 냉방 기술이 웅웅거리는 방 안에 숨어 있던 냉장고 크기의 기계였을 때, 그것들과의 상호작용도 그에 걸맞게 차가웠다. 그들이 허용하는 유일한 접촉은 터미널을 통한 원격 접속이었다.
터미널은 비싼 부품을 들어낸 책상 위 컴퓨터였다. CPU는 형편없고, 메모리는 적었으며, 논리 회로도 빈약했다. 초기에는 화면조차 없어서, 사람과 맞닿는 인터페이스로 프린터나 심지어 타자기를 사용했다.
현장 기술자와 운영자를 위한 콘솔이 달린 오래된 컴퓨터, 그리고 실제 사용자를 위한 멀리 떨어진 터미널의 예. 콘솔과 터미널이라는 개념은 오늘날 소프트웨어 형태로 살아남아 있다.
이런 제약 아래에서 키보드 동작을 구현하는 가장 단순한 방법은 이랬다. 각 키 입력은 느린 모뎀을 통해 멀리 있는 큰 컴퓨터까지 모두 이동해야 했고, 그 입력이 도착했음을 The Machine이 확인한 뒤에야 되돌아온 에코가 인쇄되었다.
그 왕복은 지연을 만들었다. 그리고 그 지연은 타이핑을 극도로 불쾌하게 만들었다.
Terminal
Latency
Input inhibited
여기서 경험하는 것보다 때로는 더 불쾌하기도 했다. 귀를 찢는 비프음이 울리거나, 거기에 더해 터미널이 물리적으로 키보드를 잠가 버리기도 했다. (계단을 내려가다가 한 칸이 더 있을 거라고 생각해 발을 세게 내리쳤던 느낌을 아는가? 그것이 하루 종일, 손가락에서 계속 일어난다고 상상해 보라.)
이 문제에 대한 첫 번째 해법은 버퍼를 만드는 것이었다. 그러면 다음 키를 치기 위해 기다릴 필요가 없었다. 이제 잠금이나 비프음은 당신이 너무 빨리 입력해서 버퍼 전체를 가득 채웠을 때만 발생했다.
Terminal
Latency
Buffers
Buffers in use
Bfr overrun
지연은 여전히 존재했다. 하지만 키 자체가 더럽거나 끈적이지 않다면, 그게 중요할까? 결국 손가락은 너무나 뛰어나서 눈의 확인이 필요 없다. 손가락은 너무나 뛰어나서, 때로는 당신이 보지 않아도, 심지어 인식하지도 못하는 사이에, 이전 키 입력이 잘못되었다는 것을 스스로 감지하고는 Backspace를 대신 눌러 주기도 한다.
그리고 당신은 원래 키보드를 보고 있으면 안 된다. 사실 이것은 운동 기억이 발달하는 데 중요하다!
하지만 1960년대에 이르러 타이핑은 단순한 메모 재입력에서 창작, 프로그래밍, 그리고 더 덜 경직된 형태의 키보드 사용으로 진화했다. 먼저 화살표 키가 등장했고, 곧 디스플레이가 등장했으며, 그다음에는 전체 화면 메뉴가 그 화면 안으로 들어왔다. 키보드를 보고 있지 않다면, 당신은 화면 말고 또 어디를 보겠는가? 게다가 그 화면은 끊임없이, 절망적으로 지연되고 있다.
1960년대와 1970년대 컴퓨터 키보드 사용의 진화 – 명령줄에서 폼을 거쳐 메뉴로
그래서 다음 발명은 “local echo”라 불리는 것이었다.
행동의 확인이 서버나 컴퓨터에서 다시 전송되기 전에 즉시 화면에 표시되는 경우. 이는 UI가 실제보다 더 빠르게 작동하는 것처럼 보이게 하기 위해 수행된다. 중요한 업데이트의 경우, 업데이트 확인이 끝내 도착하지 않을 때 이를 점검하고 사용자에게 전달하기 위한 특별한 배려가 필요하다(예를 들어 그 낙관이 잘못된 경우).
로컬 에코는 하얀 거짓말이었다. 이제 당신의 키 입력은 컴퓨터에 무사히 도달할 것이라고 낙관적으로 가정하며 즉시 화면에 표시되었다. 가장 당연한 해결책처럼 보이지만, 이전 방식보다 복잡성이 추가된다. 이제 터미널은 더 이상 진정한 dumb 터미널일 수 없고, 시스템 양쪽을 조정해 에코가 0개도 아니고… 2개도 아닌, 정확히 1개만 존재하도록 해야 한다.
Terminal
Local
Remote
Echo
하지만 느린 전송 속도는 이미 이 시대 소프트웨어에 흔적을 남겼고, Unix의 수수께끼 같은 짧은 명령과 인기 편집기 vi의 극도로 수수께끼 같은 인터페이스는 둘 다 곧 사라질 시대에 최적화된 것으로 전해진다.
이렇게 해서 우리는 새로 얻은 계산 능력의 일부를 소비해, 이미 50년 전에 가지고 있던 무언가를 다시 만들어 냈다. 손가락의 속도로 작동하는 타이핑 말이다.
이것이 이 에세이의 한 가지 주제가 될 것이다.
“50년 전”은 1910년대였다. 우리가 타이핑을 분석하고 이해하기 시작한 첫 시대 말이다. 하지만 초기 대량생산 타자기는 그보다 또 반세기 먼저 등장했고, 피아노 건반은 그보다도 더 오래되었다. 이는 손가락과 타이핑에 대한 깊은 이해가 대부분 타자기보다 앞서서 도착한 것이 아니라, 타자기와 나란히 도착했다는 뜻이다.
1870s First QWERTY typewriters
1890s Experiments in touch typing
1910s QWERTY and touch typing standardized
1940s First work in ergonomics (a.k.a. human factors)
1950–70s Institutional computers
1980–90s Home (micro)computers
Late 2000s Modern multitouch smartphones and tablets
키보드 사용의 초기 연대표
가장 좋은 예? 터치 타이핑의 부상이다. 최초의 대중적 QWERTY 타자기는 빠르게 쓰기 위해 설계되었다. 가장 초기의 용도 중 하나는 모스 부호 신호를 실시간으로 받아 적는 일이었고, 그런 속도는 가볍게 분당 50단어에 이르렀다. 놀랍게도 그 속도는 오늘날 우리가 헌트 앤 펙이라 부를 방식으로도 가능했다.
터치 타이핑 교본 표지들
타자기에서의 터치 타이핑은 영어 기준 약 150wpm으로 추정되는 인간 음성의 전사 속도에는 끝내 도달하지 못했다. 이를 위해서는 음절 단위로 입력하고 코딩처럼 여러 키를 동시에 누를 수 있게 하는 특수한 steno keyboards가 필요하다.
키보드의 등장은 사람들로 하여금 더 많은 꿈을 꾸게 했고, 그중에는 누군가의 말을 실시간으로 받아 적는다는 선망의 개념도 있었다. 그 꿈을 좇으며 여러 사람이 “터치 타이핑”을 조금씩 다듬어 갔다. 아홉 손가락을 키보드 위에 두고, 눈은 키보드에서 떼는 것이다. 이 노력은 완성되기까지 수십 년이 걸렸고, 이를 유행으로 보는 사람도 많았으며, 몇 년 더 지나도록 무엇이 “올바른” 방식인지 완전히 합의하지 못했다.
1910년대에 이르러 터치 타이핑은 제대로 자리 잡았고 꽤 대중화되었으며, 타자기의 시대가 끝날 때까지 함께했다. 하지만 1940년대, 1950년대, 1960년대의 초기이면서도 어색한 컴퓨터(와 터미널)는 거칠고 투박한 “실험실” 키보드를 달고 있었고, 이는 종종 초기 타자기보다도 더 나빴다. 이해할 만했다. 원격 에코와 버퍼의 부재가 터치 타이핑을 불가능하게 만든다면, 왜 터치 타이핑을 신경 쓰겠는가?
20세기 컴퓨터의 “실험실 키보드”들
하지만 인체공학적 진보는 고르지 않을 수 있다. 불과 10년 뒤인 1970년대에는 상황이 극적으로 바뀐다. 컴퓨터가 더 작고 더 빨라지고 점점 덜 원격적이 되었으며, 에코와 버퍼를 갖추게 되자 키보드도 더 좋아질 필요가 있었다. 그들은 이전의 훌륭한 타자기들로부터 많은 교훈을 훔쳐 왔고, 기계식 타이프바의 제약에서 벗어나 타자기가 결코 될 수 없었던 만큼 훨씬 더 인체공학적으로 변했다. 그리고 그 덕분에 조작자의 손가락은 정말, 정말 빠르게 움직일 수 있게 되었다.
그리고 기계적 이점에 지리적 이점도 더해졌다. 이제 컴퓨터가 키보드에서 몇 인치밖에 떨어져 있지 않거나, 문자 그대로 키보드 안에 숨어 있다면, 로컬 에코와 버퍼는 역사적 호기심으로 끝나는 것 아닐까?
꼭 그렇지는 않았다. 더 작은 컴퓨터는 큰 컴퓨터들보다 훨씬 느리기도 했기 때문이다. 게다가 이제는 키와 타이핑만 빠르게 느껴지면 되는 것이 아니었다. 키보드의 키는 버튼일 뿐이다. 1970년대와 1980년대에 컴퓨터 화면 에도 버튼이 생겼다. 처음에는 새로 발명된 화살표 키가 달린 키보드로, 그다음에는 마우스로 조작되었다. 오래된 개념들이 다시 중요해졌다.
“손가락의 시간”으로 반응하지 않는 이 버튼들을 눌러 보고, 얼마나 불쾌한지 느껴 보라.
Mouse event latency
Button processing time
Busy
Reset
과거에서 배운 대로라면, 여기에도 버퍼링을 추가하는 것을 상상할 수 있다. 이는 유용하지만, 어느 정도까지만 그렇다. 동작은 버퍼에 들어가 가능한 한 빨리 처리될 수 있지만, 마우스 이벤트 역시 줄을 서서 기다려야 한다. 그래서 버튼 위에 마우스를 올렸을 때나 눌렀을 때 다른 상태를 즉시 그려 줄 만큼 충분히 빠른 컴퓨터라도, 버퍼가 소진될 때까지는 그렇게 하는 것이 허용되지 않는다.
Mouse event latency
Button processing time
Buffers in use
Busy
Reset
“Haptic”은 촉각과 관련된 것을 뜻하며, “haptics”는 기술적 물체의 촉각 반응, 그리고 물체를 더 좋게 느끼게 만드는 인간 촉감에 대한 물리적 반응을 흉내 내는 현대 과학을 뜻한다. 예: 현대 Apple 트랙패드의 합성 클릭, 또는 스마트폰의 진동 모터.
이 역시 여전히 끔찍하게 느껴진다. 현실에서 더럽고 끈적한 버튼도 이미 불쾌할 것이다. 그런데 여기서는, 실제 세계의 햅틱 신호가 없어 뇌가 무슨 일이 일어나는지 이해할 수조차 없는, 심하게 이질적인 방식으로 버튼이 더럽고 끈적하게 느껴진다. 옛 타자기에서 키를 물리적으로 잠그는 것은 나쁜 느낌이었다. 하지만 컴퓨터가 처리할 준비가 되지 않았다는 이유로 인터페이스를 잠깐이라도 정지시키는 것도 마찬가지로 나쁘다.
인터페이스가 반응하는 것을 완전히 막는 동작을 가리킨다. 현대 운영체제에서는 마우스 커서 자체가 막히지는 않지만, 반응하지 않는 버튼과 다른 컨트롤, 혹은 필드에 입력하거나 창을 드래그할 수 없는 상태를 뜻할 수 있다.
전문 용어로는 이를 흔히 UI blocking이라고 부른다.
(당신의 디자이너가 UI blocking을 열정적으로 싫어하지 않는다면, 새 디자이너가 필요하다.)
짧은 시간 안에 많이 발생하는 작은 이벤트들을 다루고 완화하는 방법. 현실의 스위치 (예: 전등 스위치)에서 유래했는데, “꺼짐”에서 “켜짐”으로의 물리적 변화가 지저분하고(튀고), 두 상태를 아주 빠르게 여러 번 오갈 수 있기 때문이다.
싸고 간단한 해법 하나는 디바운싱이다. 무거운 동작에 대한 반응을 약간 늦춰, 컴퓨터가 더 무거운 일을 맡기 전에 인터페이스가 단순한 것들을 따라잡을 수 있게 하는 것이다. 이것은 로컬 에코 개념의 먼 메아리와 다름없다.
이것이 오늘날 모든 컴퓨터에서 마우스 포인터가 작동하는 방식이다. 마우스 포인터 이동은 언제나 별도의 CPU 스레드에서 이루어지므로, 멈춰서 환상을 깨뜨리지 않는다. 하지만 스마트폰의 터치 키보드는 그렇지 않을 수 있고, UI blocking 상태에 빠져 불안할 정도로 반응을 멈추기도 한다.
하지만 가장 좋은 답은 컴퓨터의 주의를 두 갈래로 나누는 것이다. “백엔드의 뇌”는 무거운 동작을 처리하고 필요하면 버퍼링할 수 있고, 동시에 병렬로 작동하는 “프런트엔드의 뇌”는 인터페이스 이벤트를 실시간으로 처리하여, 사용자 인터페이스가 막힐 가능성을 완전히 0으로 만든다.
Button processing time
Buffers in use
Busy
Reset
하지만 이 방법에도 여전히 주의할 점이 있다. 일단 무언가를 버퍼에 넣으면, 버퍼는 스스로 소진되어야 한다.
우리 모두 이런 경험이 있다. 어떤 물체를 움직이기 위해 화살표 키를 누른 채로 있었다가, 컴퓨터가 생각보다 느리다는 걸 깨닫고, 반대 방향 화살표를 누르기 시작하고, 다시 지나쳐 버려 이상하고 짜증 나는 진동 게임에 빠지는 것이다.
↑ Key repeat time ↓ Window move time
Buffers in use
Busy
Emergency stop
이 문제에는 쉬운 해법이 없다.
위의 Emergency Stop 버튼은 다소 농담 같지만, Esc나 ⌘. 같은 특별한 단축키로 버퍼를 즉시 비우는 것은 상상해 볼 수 있다. 다만 사용자가 그것을 알아야 하며, 정의상 그 단축키 자체는 버퍼에 넣을 수 없는데, 그것 역시 문제가 될 수 있다.
버튼을 누르고 있는 것과 여러 번 누르는 것을 구분해, 그 차이를 반영하려고 시도할 수도 있다. 아래에는 두 방식이 모두 구현되어 있다.
↑ Key repeat time ↓ Window move time
Buffers in use
Busy
Emergency stop
하지만 최고의 답은 언제나 그렇듯 상호작용을 가능한 한 빠르게 만들어, 지연이 생기지 않게 하고, 버퍼가 거의 필요 없게 만드는 것이다. 손가락의 속도에 맞춰 사용자에게 피드백을 보여 주기 위해 당신이 할 수 있는 모든 일을 하는 것이다.
다행히 오늘날의 초고속 컴퓨터라면 그것이 너무나 쉬운 일이어야 하지 않을까?
물론 까다로운 점은, 오늘날의 컴퓨터가 1990년대보다 반드시 더 빠른 것은 아니라는 점이다. 안다, 기술적으로는 더 빠르다. 하지만 종종 Moore의 법칙이 가져온 발전은 컴퓨터에게 우리가 요구하는 새로운 것들이나, 그 사이에 들어선 새로운 추상화 계층들에 소비된다.
당신의 컴퓨터가 부하 때문에 버거워하고 있다면, 1980년대에 해결된 위의 사소한 예시들 중 많은 것들이 오늘날에도 당신의 손가락에게는 여전히 너무 느릴 수 있다. 그리고 이제 우리가 컴퓨터에게 기대하는 일들은 더 이상 사소하지 않다. 이것을 가장 잘 보여 주는 예는 아마도 입력하면서 동시에 결과를 보여 주는 search-as-you-type일 것이다. 이것을 훌륭하게 느끼게 할 계산 능력 자체는 1990년대, 아니 어쩌면 그 이전부터 이미 가능했다.
하지만 인터넷은 1960년대의 원격 문제 일부를 다시 끌어왔고, 인터넷 브라우저라는 새로운 중개자(그리고 나중에는 JavaScript 라이브러리들)는 속도의 이점을 많이 갉아먹었으며, 운영체제에서 정성껏 구현된 에코와 버퍼가 웹사이트에 자동으로 제공되지는 않았다.
오늘날에도 형편없이 조합된 검색 중 다수는 여전히 UI blocking 상태를 만들어, 키를 입력할 때마다 기다리게 한다. 다른 것들은 결과가 이미 날아들고 있는 도중 사용자가 검색어를 바꾸는 흔한 상황을 잘 다루지 못한다.
Search
Latency (average)
Emergency stop
우리는 이 모든 것을 잘 처리하면서 언제나 날렵하게 느껴지는 검색을 당연하게 여긴다. Google의 Autocomplete나 Raycast 같은 것들 말이다. 그들의 비밀? 그들도 거짓말이 괜찮다는 걸 알고 있다.
사람들은 로딩 상태의 역할이 진행 막대, 회전 표시, 다가올 것들의 “skeletons”, 귀여운 애니메이션 등을 통해 사용자에게 정확히 무엇이 로딩 중이며, 얼마나 걸릴지를 알려 주는 것이라고 말한다. 하지만 내가 로딩 상태에 대해 배운 것이 하나 있다면, 꼭 그렇지만은 않다는 점이다. 로딩 상태의 유일하고 단 하나뿐인 목적은, 무슨 수를 써서든 소프트웨어가 가능한 한 빠르게 느껴지게 만드는 것이다.
느린 인터페이스로 가는 길은 빠르려는 의도로 포장되어 있다. 첫 번째 구성 요소는 작업에 맞는 올바른 로딩 상태를 고르는 것이다. 너무 무거운 로딩 상태는 인터페이스를 더 느리게 느끼게 만들고, 사용자가 직관적으로 자신도 느려지게 만들 수 있다.
Delay
위에서 모든 로딩 상태는 기능적으로는 올바르지만, 그중 많은 것들이 무겁거나 과하다는 느낌을 받을 수 있다. 필요 이상으로 로딩이라는 사실 자체에 주의를 끌기 때문이다.
죄송하지만, 나는 이 농담에 사로잡혀 있다.
그래서 두 번째 구성 요소는, 언제 등장하지 말아야 하는지 아는 것이다. 때로는 그냥 참고 기다리고, 때로는 낙관적 업데이트를 통해 실제보다 더 빠른 척하는 것이다.
Delay
특히 당신의 손가락에 곧바로 붙어 있는 것들은 로딩 상태에 참여할 수 없다. 당신의 뇌는 기다림을 이해할 수 있다. 하지만 손가락은 언제나 실시간으로 작동하기 때문에 그렇지 않다.
내가 주로 떠올리는 숫자는 이렇다. 기분 좋게 느끼려면 마우스는 30fps 이상, 그러니까 33ms 이하가 필요하고, 터치는 60fps(17ms) 이상, 펜슬은 120fps(8ms), 키보드는 소프트웨어 측 지연이 50ms에 이르면 느려지기 시작한다(소프트웨어 지연은 하드웨어에서 이미 발생하는 보통 20–40ms 지연에 더해진다).
이것은 키와 버튼에도 해당된다. 물리적으로든 비프음으로든 키를 막는 것이 결코 통할 수 없었다는 이야기를 이미 했다. 하지만 더 복잡한 상호작용에 적용되면 더욱 중요해진다. 물체를 터치하는 것은 한 가지 일이다. 물체를 붙들고 있는데 실시간으로 반응하지 않는 것은 훨씬 더 불안하게 느껴진다.
여기서 고전적인 예는 Macintosh in 1984이다. 창을 드래그하거나 크기를 조절할 때 작은 윤곽선만 보여 주었다. 그 윤곽선은 컴퓨팅 파워가 실시간 처리를 해낼 수 없다는 인정이었지만, 동시에 영리한 로딩 상태이기도 했다. 느리지만 완전한 충실도보다, 거친 근사치라도 빠른 속도가 훨씬 더 중요하다는 것을 이해한 것이다.
Window move time
Window move time
그리고 로딩 상태의 속임수에는 더 많은 것이 있다. 무언가를 빠르게 느끼게 만드는 기술은 너무도 미로 같아서, 때로는 오히려 좋은 이유로 지연을 의도적으로 도입하고 싶을 수도 있다.
아마 당신이 한 번도 의식하지 못했을 간단한 예가 있다. Mac으로 이 글을 읽고 있다면, ⌘Tab을 누르되 ⌘를 놓지 말아 보라. 최근에 사용한 앱들의 아이콘이 보여야 한다.
Windows 95의 첫 현대적 시각 작업 전환기
그런데 이제 ⌘Tab을 빠르게 눌렀다 떼 보라. 인터페이스는 나타나지 않는다. 앱 전환기의 주요 사용 사례가 최근 두 앱 사이를 빠르게 오가는 것이라면, 수많은 아이콘이 갑자기 나타났다 사라지는 것은 그저 산만함일 뿐이다. 그래서 인터페이스의 가시적 부분은 언제나 약간 지연된다.
Threshold
Hold before showing
또 다른 예: Chrome은 탭을 영리하게 재배치하기 전에 잠깐 기다려, 당신이 ×를 여러 번 연속으로 쉽게 누를 수 있게 한다. 매번 탭의 닫기 상자를 다시 찾아 위치를 맞출 필요가 없도록 말이다.
Delayed tab rearranging
Tab drag dead zone
AI 상호작용을 위한 현대의 “streaming” 인터페이스도 이것을 잘 활용한다. 때로는 전체 대화가 더 늦게 도착한다 하더라도, 더 작은 덩어리로 더 빠르게 보여 주는 방식을 택한다.
Paragraph/Remote speed
Word/Local speed
Streaming is waiting
Emergency stop
이 작은 지연은, 역설적으로, 불필요한 중간 검색 쿼리가 네트워크를 포화시키지 않게 해 주어 검색을 더 빠르게 만들 수 있다.
그리고 search-as-you-type으로 돌아가 보자. 이 모든 것은 고칠 수 있다. 하지만 우리가 이미 배운 것들을 세심하고 미묘하게 조합해야 한다. 키 입력은 예외 없이 즉시, 낙관적으로 출력되어야 한다. 검색은 인터페이스를 막아서는 안 되고, 각 키 입력 후 100ms 정도 디바운싱된 다음 온라인으로 요청을 보내야 한다. 돌아오는 결과는 그 순간 존재하는 검색어와 비교되어, 일치할 때만 표시되어야 한다. 결과는 캐시되어야 하고, 정말 잘한다면 손가락이 이미 하는 것처럼 미래를 예상해야 한다. 조용히 백그라운드에서 검색을 자동완성하고, 결과를 미리 큐에 넣어 사용자가 타이핑을 끝내는 즉시 보여 줄 준비를 해 두는 것이다.
이것이 잘 이루어지면 마법처럼 느껴진다. 서로를 스쳐 지나가는 오버래핑된 손가락과 오버래핑된 네트워크 요청들이, 아름답게 혼란스러운 안무를 이룬다.
Search
Latency (average)
Debouncing active
Cached
Rejected
Result
하지만 손가락의 마술 레퍼토리는 오버래핑을 넘어선다. 더 깊이 들어가려면, 우리는 시간을 되감아 불편한 진실 하나를 마주해야 한다. Caps Lock은 Shift보다 먼저 존재했다.
사용자 동작이 수행되는 동안 지속되는 모드. 그 동작이 끝나는 순간 인터페이스는 이전 상태로 되돌아간다(마치 스프링의 도움을 받는 것처럼). 다른 예로는 비디오게임의 push-to-talk 키, 창 드래그, iOS의 텍스트 선택 확대경이 있다. 이 아이디어의 특정한 버전으로는 dead man’s switch가 있는데, 기계 전체가 스프링으로 누르고 있을 때만 작동하는 경우다. (Jef Raskin은 그의 훌륭한 책 The Humane Interface에서 장난스럽게 “quasimode”라는 이름을 제안하려 했다.)
직관에 어긋나는 것처럼 느껴지지만, 생각해 보면 말이 된다. Caps Lock은 Shift의 개선형이 아니다. 둘은 같은 아이디어를 위한 두 개의 인터페이스일 뿐이다. Caps Lock은 전통적인 모드 토글이고, Shift는 순간적 토글, 때로는 스프링 장착 모드라 불리는 것이다.
소문자를 처음 도입한 첫 타자기에는 두 개의 키가 있었다. 하나는 대문자를 켜고, 다른 하나는 대문자를 끄는 키였다. 둘로 쪼개진 Caps Lock이었던 셈이다…
…그리고 쓰기에는 그다지 즐겁지 않았다.
Hello
Caps Lock
하지만 이 모든 일은 터치 타이핑의 여러 발명이 세상을 흔들고 있던 무렵에 벌어지고 있었고, 누군가 이런 생각을 했다. 타이피스트에게 보통 다른 손의 손가락이… 손쉽게 준비되어 있다는 사실을 왜 이용하지 않지?
방정식 하나가 있다. 사용자가 현재 가리키고 있는 위치(마우스나 손가락으로)에서 무언가가 멀수록, 그 대상을 더 크게 만들어야 속도와 정확성을 유지할 수 있다는 내용이다.
그래서 Shift가 탄생했다. 세 개의 키를 순서대로 누르는 대신, 한 손으로 글자를 잡고 다른 손으로 거의 동시에 Shift를 누르는 것이다. 더 나은 개선? 키보드 양쪽에 같은 키를 두어 모든 손에 Shift를 하나씩 주는 것. 또 다른 개선? Fitts’s Law를 만족시키도록 키를 더 크게 만드는 것!
1901년에 한 환상적인 타자기가 이를 해냈고, 엄청나게 잘 팔렸다. 그 배열은 그 이후로 우리가 계속 사용해 온 것이다.
Underwood №5, 타자기 산업의 첫 진짜 대히트작
그 무렵에는 결국 사라진 다른 아이디어들도 많이 떠돌았다. Shift가 두세 개 있는 것부터, Shift가 아예 없는 것까지.
19세기 후반의 타자기들: Helios (세 개의 shifts), Blickensderfer (두 개의 shifts), 그리고 Caligraph (shifts 없음!)
그리고 이 글을 읽는 당신들 중 일부는 아마 이미 그다음 뻔한 아이디어를 떠올렸을지도 모른다. 사실 Caps Lock과 Shift 둘 다 필요하지는 않다. Caps Lock을 누르는 것과 Shift를 누르고 있는 것은 상호 배타적인 동작이므로, 둘이 하나의 키에 공존하지 못할 이유는 없다.
일본만 빼고.
만약 이것이 19세기가 다음 세기에 바통을 넘기던 시절에 고려되었다면, 아마 기계식 세계에는 너무 복잡했을 것이다. 그러나 이후 컴퓨터가 등장하자, Ctrl이 “A 옆의 큰 키”라는 선망의 위치를 둘러싼 전투에서 Caps Lock에게 패배한 것에 영원히 불만인 몇몇 엔지니어들은 키보드 소프트웨어를 수정해 정확히 그렇게 만들기 시작했다. 그들의 키보드에서 Shift는 보통처럼 작동하지만, 한 가지가 추가된다. 일반 키처럼 한 번 누르면 Caps Lock이 하는 일을 한다. 그러면 Caps Lock 키 자체는, 어떤 식으로 보더라도 그 키보드 위치에 과분한 존재이므로, 다른 용도로 다시 할당할 수 있다.
Hello
Caps Lock
NeXT 키보드에는 기능 키를 없애거나 스페이스바 아래에 Command 막대를 두는 등 더 흥미로운 아이디어들이 있었지만, 그중 어느 것도 1997년 Mac과의 재통합 이후 살아남지 못했다.
나는 이 해법이 왜 정착하지 못했는지 궁금하다. 내가 본 가장 대중적 성공에 가까운 사례는 정확히 그렇게 했던 NeXT 키보드였고, 그것을 “AlphaLock”이라 불렀으며, 양쪽 Shift 키에 불까지 달아 놓았다.
그런데도 합쳐진 Shift/Caps Lock 키의 정신은 오늘날 당신의 Mac에도 살아 있다. F3 (Exposé) 키를 눌러 보면, 빠르게 누를 때와(그리고 다시 눌러 돌아갈 때), 누르고 있을 때(이 경우 키를 놓는 것이 원상 복구를 담당한다) 동작이 다르다. 앞서 나온 Mac 키보드의 또 다른 예도 있다.
Press vs. hold threshold
100
Timer after
Mode
뒤의 quasimode는 손가락이 조금 더 빠르게 움직이고 싶어 하는 사람들에게 보내는 또 하나의 친절한 제스처다. 대부분의 메뉴도 마찬가지다. 메뉴를 열기 위해 클릭하고 다시 관련 항목을 클릭할 수도 있지만, 클릭한 채 드래그 하여 조금 더 빠르고 유연하게 항목을 선택할 수도 있다.
Menus active
Menus active
Drag
이것은 iOS 메뉴에서도 손가락으로 작동한다. 심지어 키보드에서도 그렇다. 키를 하나씩 탭하는 대신 손가락을 키들 위로 드래그할 수 있다.
이것은 느린 키 입력이 빠른 제스처 로 변하는 마법 같은 일을 가능하게 한다. 하지만 여기에도 조심해야 할 점이 있다.
공항에서 경험한 가장 스트레스 큰 순간 중 하나는 비행과는 아무 관련이 없었다.
오늘날까지 살아남은 NeXT의 관습 하나.
나는 대서양 횡단 비행기에 탑승하려던 참이었다. 컴퓨터를 꺼내 무심코 비밀번호를 입력했는데, 모든 창이 열리는 대신 비밀번호 창이 흔들리고 그대로 있었다.
대수롭지 않게 여겼다. 손가락 하나가 미끄러졌겠거니 했다. 비밀번호를 다시 입력했지만, 같은 실망스러운 반응이 돌아왔다.
세 번째가 되자 조금 걱정되기 시작했다. 위에서 말한 “무심코”라는 말이 핵심이었다. 비밀번호는 오직 손끝에만 존재하는 것처럼 느껴지며, 거기서 그것을 꺼내 오려 하면 대개 곤란해진다. 누군가가 당신에게 비밀번호나 자주 쓰는 단축키를 물었는데, 당신이 정말로 대답하지 못했던 적이 얼마나 많았는가? 그것을 공유하는 유일한 방법은… 실제로 당신의 손가락이 그것을 입력하는 모습을 보는 것뿐이었다. 마치 그 손가락이 남의 것인 양.
나는 더 의식적으로 비밀번호를 다시 입력하기 시작했다. 그러면서도 의식적인 입력이 상황을 더 악화시킨다는 것을 알고 있었다. (춤, 스키, 심지어 계단 오르기도 자신의 움직임을 생각하지 않을 때 더 잘 되며, 그 생각을 하는 순간 우리는 느려지고 실수한다.) 그래도 소용이 없었다. 게다가 또 다른 시한폭탄도 있었다. 컴퓨터는 비밀번호를 정말 잊어버린 사람과 흔한 비밀번호를 차례로 시도하며 계정을 해킹하려는 사람을 구분할 수 없다. 그래서 어느 시점부터는 후자를 막기 위해 도입된 인위적인 지연이 나타나기 시작했다. 이제 다시 시도하기 전에 1분을 기다려야 했다. 그다음은 2분. 그다음은 5분.
지연이 하나씩 늘어날수록 나는 비밀번호를 더 집요하게 생각하게 되었다. 내가 정말로 비밀번호를 바꿨던가? 컴퓨터에 무슨 문제가 있는 건가? 긴 비행 동안 아무것도 하지 못할지 모른다는 생각은 끔찍했다.
그렇게 이 스트레스 상황에 빠진 지 30분이 훌쩍 지나서야, 나는 화면 한쪽 구석의 무언가를 발견했다. 내 키보드가 어쩐 일인지 헝가리어로 전환되어 있었던 것이다. 어떻게 그런 일이 벌어졌는지는 전혀 몰랐다. 나는 내내 올바른 키를 누르고 있었지만, 잘못된 pasword를 입력하고 있었다.
배열을 영어로 바꾸고, 운영체제가 다시 시도할 수 있게 해 줄 때까지 기다린 다음, 실수하면 15분을 더 잃게 된다는 걸 알면서도, 백만 번 하던 바로 그 방식으로 긴장한 채 비밀번호를 입력했다. 들어갔다.
우리 뇌가 움직임을 학습하여 자동적이고 능숙하게 반복하는 능력. 흔히 “muscle memory”라고 알려져 있다.
이것은 건망증 있는 사용자 이야기나, 적대적인 컴퓨터 이야기나, 사용성과 보안 사이의 오래된 긴장에 대한 이야기가 아니다. 이것은 운동 기억의 힘에 대한 이야기다.
헤.
알고 보니 비밀번호와 키보드 단축키는 정말로 당신의 손끝에 존재한다. 물론 비유적으로 말이다. 여전히 뇌가 총괄하지만, 다른 규칙을 가진 별도의 뇌 영역이 관여한다. 일반적인 선언적 기억과 운동 기억 사이에는 장벽이 있다. 그래서 비밀번호를 너무 자주 입력해 생각조차 하지 않게 된 뒤에는, 손가락에게 그 비밀번호가 무엇인지 물어보기 어려운 것이다.
운동 기억의 “전혀 생각하지 않기”라는 성질은, 생각하면서 타이핑하고, 누군가와 대화하면서 타이핑하고, TV를 보면서 타이핑하고, 마우스로 무언가를 본능적으로 드래그하는 등의 놀라운 일을 가능하게 한다. 운동 기억은 너무나 강력해서 몇 년간 당신과 함께한다. 아니, 몇십 년 동안 함께한다.
키보드 단축키라는 이름은 적절하다. 그것은 뇌의 일부 단계를 건너뛰게 해 주며, 그 부분들을 덜 부담스럽게 만들어 더 중요한 것에 집중하게 해 준다.
물론 이것은 잠재적 해커에 대한 힌트였을 수도 있었다.
하지만 소프트웨어는 운동 기억을 존중해야 한다. 어느 시점에 내 Mac은, 현대 운영체제가 Caps Lock이 켜져 있을 수 있다고 경고하듯이, 내가 비밀번호를 원래 입력했던 언어와 다른 언어의 키보드가 선택되어 있을지도 모른다고 힌트를 주었어야 했다.
그래서 그렇다. 운동 기억은 독자적인 생명을 지니고 있으며, 때로는 아주 위험하게 느껴질 수도 있다. 하지만 하드웨어와 소프트웨어가 그것의 미묘함과 힘을 이해할 때, 아름다운 순간들이 일어난다.
예를 들어, 또 다른 힘겹게 얻어낸 발명인 undo를 보자. 16자 키보드 버퍼조차 큰 비용이던 초기 컴퓨터에서는, 사용자가 마음대로 되돌아볼 수 있는 행동 이력에 메모리를 쓰는 것을 상상하기 어려웠다. undo는 처음 몇십 년간 존재하지 않았고, 다단계 undo가 등장하기 시작한 것은 1990년대 후반에 와서였다. 컴퓨터는 undo를 위해 거의 타자기가 종이에서 글자를 들어 올리는 제대로 된 Backspace를 기다린 만큼 오래 기다렸다.
1980년의 개발 중이던 Apple Lisa에서 본, 고전적 네 가지 단축키의 초기 시도와 대체 우주의 한 단면.
Backspace와 마찬가지로, 우리는 undo와 그것이 제공하는 실험의 안전성을 당연하게 여긴다. 그리고 undo의 비밀스러운 힘 일부는 그 훌륭한 단축키에 있다. ⌘Ctrl Z의 “Z”는 사실 기억술적으로 별 의미가 없다. 그냥 함께 누르기 재미있고 빠른 조합일 뿐이다. 하지만 그것이 중요했다. 누르기 쉽다는 것은 운동 기억에 더 빨리 자리 잡는다는 뜻이고, 더 습관적으로 쓰게 된다는 뜻이며, 이전에는 두려워했던 컴퓨터 작업도 더 안전하게 느끼게 된다는 뜻이다.
선순환이다.
운동 기억을 오버래핑과, 바쁠 때조차도 안정적으로 반응하는 인터페이스와 연결하면, ⌘Ctrl Z는 영리한 키 조합 그 이상이 된다. 어쩌면 어떤 면에서는 그것보다… 덜한 것이 된다. 당신의 의식이 개입하지 않아도 손가락이 그냥 해 버리는 무언가가 된다. 그것은 손가락이 자신의 삶을 가진 두 번째 뇌가 되도록 해 준다.
내가 가장 좋아하는 설계된 상호작용의 사례들은, 사람들이 이런 모든 것을 배워 잘 적용했다는 것이 분명히 보이는 경우다.
또 다른 예로는 cut/copy/paste를 서로 가깝게 배치하거나, Mac의 ⌘Tab(앱 전환)과 ⌘`(앱 내 창 전환)을 함께 둔 경우가 있다.
단순한 것일 수도 있다. ⌘Ctrl G로 다시 찾기는 일반적인 ⌘Ctrl F 찾기 바로 옆에 위치해 있어 파일을 정말 빠르게 훑어갈 수 있다.
Debouncing delay
일부 키보드는 Shift 상호작용 자체도 진화시켰다. 생각해 보면 Shift는 여전히 다소 비효율적이다. Shift가 글자 키보다 먼저 내려가야 하므로, 특정 순서로 키를 눌러야 한다. 하지만 둘을 동시에 누를 수 있다면 어떨까? 이것이 까다로운 이유는 어느 쪽이 먼저 도착할 수도 있기 때문이다. 타자기의 기계식 세계는 하나의 특정한 순서만 허용하지만, 컴퓨터는 우리의 손가락만큼이나 시간을 휘게 만들 수 있다.
실제로 나는 많은 Thumb Shift 키보드가 이 새로운 상호작용을 강제했고, 고전적인 방식은 지원하지 않았다고 믿지만, 아래 놀이터는 두 방식 모두를 지원한다.
1980년대에 몇몇 일본 엔지니어들이 그것을 시도했다. 그들은 키보드 소프트웨어를 수정해, Shift나 출력 키 중 어느 것으로 시작하든 잠깐 다른 키가 도착하기를 기다린 다음, 둘을(디바운싱해서!) 합쳤다. 이제 이전처럼 Shift를 쓸 수도 있었고, 동시에 짝이 되는 키와 거의 같은 순간에 빠르게 눌러도 동작했다. 조금 늦어도 괜찮았다.
이것은 소프트웨어 마법이었지만, 하드웨어에도 마법이 조금 있었다. 스페이스바가 있던 자리에 thumb shifts가 있었고, 그 창안자들은 엄지가 얼마나 과소활용되는지 이해하고 있었다. 시간이 지나며 이것은 Thumb Shift 키보드로 알려지게 되었다.
1 more image
1 more
1
두 개의 thumb shift 키(그리고 그 아래에 관련 없는 엄지 키 두 개 더)가 있는 Fujitsu Oasys 키보드
(당신의 엄지 아래로 Shift 키를 옮길 수는 없으니, 스페이스바를 가상의 thumb shift로 사용해 주세요. 그리고 공백을 넣으려면 Tab을 누르세요.)
Hello
Threshold (before and after)
100
Timer before
100
Timer after
일본만 빼고.
Mac의 Finder 제작자들 역시 이런 점을 고민했다. Finder에서는 스페이스를 눌러 어떤 항목이든 빠르게 미리 볼 수 있다. 스페이스바는 이를 위한 완벽한 키다. 이 맥락에서는 비어 있다. 크기도 크다. 그리고 두 개의 손가락이 배정된 호사를 누리는 유일한 키다.
미리 보기는 위에서 언급한 대시보드 트릭처럼 동작하기도 한다. 스페이스바를 두 번 누를 수도 있고, 누르고 있다가 놓을 수도 있다. 이것 역시 낙관적이다. 렌더링이 느리거나 원격 네트워크에 있는 항목을 미리 보더라도, 창은 여전히 빠르게 뜬다.
다시 말해, 몇 번만 써 보면 이 조합은 특정 키를 의도적으로 누르는 선택처럼 느껴지지 않고, 오히려… 슬쩍 들여다보는 행위처럼 느껴지기 시작한다.
Press vs. hold threshold
100
Timer after
Mode
마지막 예는 Twitter다. 그곳이야말로 유연한 입력 필드를 대중화한 공로를 인정받을 만하다.
이론적으로는 여기서 영리한 키보드 상호작용이 보이지 않는다. 필드는 140자로 제한되므로, 자연스러운 방식은 140자에서 딱 멈추게 하는 것일 수 있다.
하지만 140자에 도달하는 길 위에서 당신은 더 긴 문장을 초안으로 쓸 수 있고, 손가락은 생각 없이 단어를 움켜쥐고 수정하거나 옮겨 놓을 수 있다. 그것을 허용하기 위해, 필드는 실제로 140자로 제한되지 않았다. 당신은 원하는 것을 무엇이든 할 수 있었다. 단지 글자 수를 줄이기 전까지는 게시할 수만 없었을 뿐이다.
Input inhibited
Commit failed
바로 위의 입력 필드 같은 것은 실수처럼 보일 수 있다. 그 순간 “150/140”을 보는 것은 버그처럼 느껴진다. 이것은 전형적이다. 손가락을 이해하는 정교한 인터페이스는 실수처럼 보이는 행동을 할 수 있지만, 그것들은 당신 이 실수하는 것을 막기 위해 존재한다.
내가 가장 좋아하는 예는 이것일지도 모른다. 페이지가 막 로드된 직후 Chrome은 합쳐진 reload/stop 버튼을 1초의 일부 동안 비활성화한다. 이는 많은 사람이 쓰는 중요한 위치에서의 사려 깊은 상호작용이다. “손이 눈보다 빠르다”는 말이 생리학적으로는 사실이 아니더라도, 먼저 시각적으로 보고 그다음 인지적으로 무슨 일이 일어나는지 처리하는 데 걸리는 아주 짧은 시간이, 그사이에 잘못된 것을 클릭하게 만들기에는 충분할 수 있음을 인정한 결과다. 멈춰 버린 페이지에서 새로운 로드를 강제로 하려고 stop 버튼 쪽으로 손을 움직이기 시작했는데, 움직이는 도중 페이지가 하필 로드를 마치면, 방금 로드된 페이지를 실수로 다시 불러오게 된다.
버튼을 잠깐 비활성화하면 그런 일을 막을 수 있다.
Temporary reload block
Delayed tab rearranging
Tab drag dead zone
장치의 중심(예: 조이스틱)이나 화면 위 물체 주변의 작은 영역으로, 그 안에서는 어떤 움직임도 허용되지 않는다. 이는 정지 상태에서의 우발적인 작은 움직임을 막고, 컨트롤러 드리프트를 보정하기 위해서다.
또 다른 예: 좋은 인터페이스는 당신이 그냥 스치기만 했을 때는 창을 움직이지 않는다. 흐름 속에서 빠른 클릭이 사실은 아주 작은 드래그로 바뀔 수도 있다는 점을 이해하기 때문이다. dead zone이라는 개념, 즉 커서 주변 몇 픽셀의 비밀스러운 사각형은, 절대 중심에서 벗어나기 위해 약간 더 힘이 필요했던 비행기 조종간에서 이어져 온 것이다.
비슷하게, dead zone 안의 작은 드래그는 여전히 클릭으로 해석된다. 자세히 보기 시작하면 이것 역시 버그처럼 느껴질 수 있다…
Dead zone threshold
Dead zone
Reset
…하지만 그렇지 않다. (또한 더블클릭이 조금 덜 정밀해도 되게 해 준다. 두 번의 클릭이 dead zone 안에서 일어나기만 하면 더블클릭으로 볼 수 있다.)
오늘날의 iOS에서 Google Maps도 Apple Maps도, 때로는 버튼 위에 손가락을 올린 상태에서 패닝을 시작하게 되며, 그 패닝 제스처가 그 뒤의 캔버스로 전달되어야 한다는 사실을 이해하지 못했다.
또 다른 예: 좋은 인터페이스는 손가락 제스처가 별도의 평면에서 작동하며, 때로는 아래에 무엇이 있는지 신경 쓰지 않을 수 있다는 점을 이해한다. 어떤 브라우저에서는 × 상자에서 탭 드래그를 시작할 수 있고, 그 상자는 손가락에게 투명해진다. 논리적으로는 말이 되지 않는다. 하지만 “손가락의 논리”에는 맞다.
Ignore close box when dragging
Tab drag dead zone
좋은 인터페이스는 빠르게 움직이는 손가락이 어수선할 수 있음을 이해하고, 수정 키를 드래그 전에 누르거나, 드래그 후에 눌러도 허용한다.
(현대 소프트웨어 역사에서 내가 겪은 가장 불쾌한 기계적 경험 중 하나는 After Effects에서 만들던 긴 영화의 여러 요소 크기를 실수로 조절해 버렸고, 그것을 며칠 뒤에야 알아차렸던 때다. undo는 이미 한참 지나간 뒤였고, 다른 변경도 했기 때문에 오래된 파일로 그냥 되돌릴 수도 없었다. 자기 일을 다시 하는 것보다 더 나쁜 것은, 세부를 기억하지 못하는 일을 다시 하는 것이다.)
Before drag
After drag
Axis lock allowed
Axis lock active
Reset
좋은 인터페이스는 Backspace와 undo에게 또 하나의 동맹이 있다는 것을 이해한다. 바로 유서 깊은 Esc 키다. 그 키는 소프트웨어의 Emergency Stop이어야 한다. 언제나 문제에서 벗어나게 해 줄 수 있어야 한다.
많은 사람들은 Model M 키보드를 클릭감 있는 소리와 현대적 화살표 키 배열을 확립한 공로로 사랑한다. 나는 그 키보드가 Esc에게 자기만의 작은 섬을 준 점이 좋다. 다시 한 번 Fitts‘s Law를 이해한 것이다.
혼란스럽거나 답답하거나, 아니 솔직히 말해 그냥 평범한 창작 작업 도중에 왼손으로 Esc를 세게 내려치는 것은 강력하면서도 과소평가된 행위다. Esc가 닫기 상자나 Cancel 버튼을 가리키는 것보다 훨씬 빠를 수 있다는 점만이 아니다. 우리가 여기서 논의하는 많은 것처럼, 그것이 의식 아래에서 작동하는 제스처 가 될 수 있다는 점이다. 하지만 이것은 오직 당신이 그 제스처가 일관되고 신뢰할 수 있게 작동하는 환경을 만들 때만 가능하다.
내가 가장 좋아하는 이런 순간은 Canon Cat이라는 잊힌 기계에서 나왔다.
Canon Cat에는 간결한 검색 인터페이스가 있었는데, Fujitsu가 Thumb Shift를 둔 바로 그 자리에 두 개의 독특한 Leap 키를 배치했다. Leap을 누른 채 타이핑하면, 그것은 강화된 ⌘Ctrl F와 같다. 커서는 추가 키 입력 없이 즉시 첫 번째 일치 구문으로 점프한다. 그런데 오타를 냈거나, 더 나쁘게는 마음이 바뀌면 어떻게 할까?
Cat의 제작자 Jef Raskin은 이상할 만큼 만족스러운 해법을 생각해 냈다. Esc를 세게 치는 대신(Cat에는 Esc가 없었다), 그냥 키 자체를 마구 내리치는 것이다. 그러면 거의 확실히 문서 어디에도 존재하지 않는 키 입력 열이 생성될 것이고, 커서는 시작 위치로 튕겨 돌아간다.
Leap active
Leap failed
Cat은 당신의 키를 잠그지 않았고, 처리하고 확인해야 하는 에러 메시지 대화 상자도 띄우지 않았다. 효율적인 손가락 조작을 추구하는 과정에서도, 실수 처리 역시 손가락의 속도로 이루어져야 한다는 사실을 잊지 않았다.
나는 Canon Cat의 짧은 생애 동안 그 자리에 있지 않았다. 이 이야기 속 더 이른 많은 순간들에도 없었다. 하지만 2007년의 혁명은 그것이 벌어지는 바로 그 순간 목격한 기억이 있다.
1984년 Mac의 탄생 당시에는 그 마우스에 많은 관심이 쏠렸고, 흥미로웠던 키보드는 상대적으로 덜 주목받았다. iPhone의 등장은 그 상황을 뒤집었다. 이제 모두가 키보드 이야기를 하고 있었다. iPhone의 마우스에 해당하는 것에 대한 언급은 “slide to unlock”을 감탄하거나, 핀치로 확대하기를 찬양하는 수준으로 밀려나 있었다.
하지만 이 순간의 진짜 주인공은 스크롤링이었다. TL; DR: Apple의 모멘텀 스크롤링은 완벽하다. 고무줄 같은 탄성 메커니즘은 첫날부터 극도로 잘 조정되어 있었다. 천천히 정밀하게 움직일 수도 있었고, 빠르게 미끄러뜨리면서도 무슨 일이 일어나는지 이해할 수 있었으며, 손가락으로 관성을 더해 줄 수도 있었다. 그러다가 1초 뒤 탭 한 번으로 그 움직임을 멈춰 세울 수도 있었다. (그리고 그 탭은 누름으로 해석되지 않게 막아 주었다.) Video 9
2007 announcement keynote에서 iPhone의 스크롤링을 시연하는 Steve Jobs
내 본업은 이런 상호작용의 개선을 제안하는 일인데, 여기서 내가 개선하고 싶은 것은 단 하나도 떠오르지 않는다. 이것은 특정한 의미에서 초자연적 이었고, 지금도 그렇다. 마치 자연 자체를 개선해 놓은 것 같은 느낌이다.
Jef Raskin 저
1979년에 작성됨
이것은 거리의 보통 사람(Person In The Street, 줄여서 PITS)을 위해 설계된 컴퓨터의 개요다. 정말 쓰기 즐겁고, 사용자가 “나는 컴퓨터에 대해 첫 번째 것도 몰라요”라고 말할 수 있다는 뒤틀린 기쁨을 위협하는 일을 아무것도 하지 않아도 되며, 판매, 서비스, 소프트웨어 제공 모두에서 수익성이 있어야 한다.
이 기준을 염두에 두고 설계된 컴퓨터는 이미 많지 않겠느냐고 생각할 수 있다. 하지만 그렇지 않다. 어떤 이유로든 사용자가 내부를 보아야 하는 시스템은 이 명세를 충족하지 못한다. PITS가 별도의 가전제품으로 이해할 수 있는 것 외에는 추가 ROMS, RAMS, 보드, 액세서리가 있어서는 안 된다. 예를 들어 보조 프린터는 팔 수 있지만, 병렬 인터페이스는 안 된다. 경험칙으로 말하자면, 스스로 탁자 위에 독립적으로 놓일 수 없고, 자기만의 케이스가 없거나, 그 자체로 완전한 소비자 제품처럼 보이지 않는다면 금지다.
컴퓨터를 수리를 제외한 어떤 이유로든 열어야 한다면(그리고 이 점에서 우리의 잠재적 사용자는 무능하다고 가정해야 한다), 심지어 판매점에서조차 그렇다면, 그것은 우리의 요구를 충족하지 못한다.
속을 보는 것은 금기다. 소켓에 꽂힌 것들도 금기다(너무 큰 초기 비용을 지우지 않으면서 수리 비용을 낮추기 위한 경우는 예외). 키보드에 수십억 개의 키가 있는 것도 금기다. 컴퓨터식 말투도 금기다. 두꺼운 매뉴얼, 또는 많은 매뉴얼도 금기다(두꺼운 매뉴얼은 나쁜 설계의 확실한 신호다). 자기주도 학습 프로그램은 금기가 아니다.
설정이 지나치게 많아서는 안 된다. 메모리 용량을 다양하게 두느니, 케이스 색상을 다양하게 제공하는 편이 낫다. 전원 코드 외에 외부 선이 하나도 없게 하는 편이, 여러 형태의 메모리를 두는 것보다 낫다. Early American, Contemporary, Louis XIV 버전으로 제조하는 편이 더 낫다.
전원 코드까지 없앨 수 있다면 10점을 주겠다.
사용자 매뉴얼에 문서화할 필요가 없는 모델 간 차이는 괜찮다. 그 외의 차이는 모두 안 된다.
이 명세에 맞춰 만들어진 어떤 컴퓨터에서든 동일한 소프트웨어가 실행된다는 점이 가장 중요하다. I/O, 속도, 메모리 크기, 구성, 액세서리 가능성 등 어떤 면에서도 기계 간 차이가 있어서는 안 된다.
(액세서리 이야기가 나왔으니 말인데, 즉흥적으로 떠오르는 판매 가능한 액세서리는 프린터뿐이다. 이것마저도 모든 기계에 내장할 수 있다면, 액세서리가 아예 필요 없을 이유가 거의 없어진다. 그것이 최적이다.) [지금까지는 가격 제약과 네트워크라는 만연한 개념 때문에 이것이 약간 달라졌다.]
소프트웨어 판매는 이 컴퓨터의 수익 전략에서 중요한 부분이 될 것으로 예상된다.
이 인간친화적 컴퓨터가 2년 반 안에 100,000대 미만으로 팔릴 것으로 예상된다면, 이 프로젝트는 시작하지 말아야 한다.
컴퓨터는 한 덩어리여야 한다. 현재 기술을 기준으로 말하면, 4인치 또는 5인치 CRT(향후 1년 내 더 나은 디스플레이가 나오지 않는다면), 키보드, 디스크가 하나의 패키지에 통합되어야 한다는 뜻이다. 휴대 가능해야 하고, 20파운드 이하여야 하며, 손잡이가 있어야 한다. “Apple V”는 나쁘지 않은 손잡이 이름일 것이다. 비행기 좌석 아래에 들어가야 한다. 완전히 충전했을 때 최소 두 시간 동안 작동할 수 있는 배터리가 있으면 가장 좋다.
선택하기 쉬운 것도 있다. 보통의 컴퓨터 과학적 의미에서의 성능은 그다지 중요하지 않다. 8-bit CPU, 64K RAM 칩 여덟 개, RS-232 인터페이스 하나, 전화 잭 하나, 디스켓에 200K바이트 정도면 충분하다. 배터리 구동 시계-달력이 반드시 있어야 한다.
더 고르기 어려운 것들도 있다. 분명 BASIC은 있어야 한다. 그리고 BASIC을 통해 도달할 수 있는 어떤 기반 시스템 언어도 있어야 해서, OEN 소프트웨어 하우스(그리고 우리 프로그래머들)가 필요한 일을 할 수 있어야 한다. 이 용도에 적합한 아주 작고 저렴하며 컴팩트한 언어로 FORTH가 있다. 외부 개발 시스템을 써야만 한다면, 기계의 성장과 판매에 방해가 될 것이다.
이 기계의 최종 사용자 가격은 $500 이하여야 하며, 1982년 초(혹은 더 좋게는 1981년 크리스마스 이전)에 판매되어야 한다.
프린터. 아마도.
시스템에는 모드도 레벨도 없어야 한다. 사용자는 언제나 자신이 어디에 있는지 안다. 있을 수 있는 곳이 단 하나뿐이기 때문이다.
언어는 순수 인터프리트 방식이어야 한다. 모든 시스템 명령은 언어 안에 포함되어야 하고, 언어의 모든 문장은 명령이어야 한다. 프로그램은 사용자가 중단할 수 있어야 하고(그리고 프로세스 중단도 가능해야 하며), 변경된 후에도 다시 이어서 실행할 수 있어야 한다. 사용자가 할 수 있는 일은 프로그램도 할 수 있어야 하고, 그 반대도 마찬가지여야 한다.
일관성이 중요하다. 파일 이름이든 변수 이름이든 배열 이름이든, 모든 이름은 같은 문법을 가져야 한다. 상수를 쓸 수 있는 곳에는 표현식도 쓸 수 있어야 한다. 문자열은 다른 배열과 다르게 행동해서는 안 된다. 모든 배열은 동적으로 할당되어야 한다.
선언은 금기다.
아니, 정확히는 선언을 요구하는 것이 금기다.
그래픽은 내부 스피커를 통한 사운드 생성과 함께 언어 안에 포함되어야 한다. 현재의 사운드 생성 칩 집합은 고려 대상이 아니다.
커서 조작은 키보드 위에 있어야 하고, 그래픽 입력이 필요할 때 사용되어야 한다. Apple III 키보드는 이상형에 가깝다.
표준 RS-170 비디오 출력은 나쁜 생각이 아니다. 특히 학교에서 사용될 예정이라면 더 그렇다. 방금 두 글자짜리 단어 다섯 개를 연속으로 썼다. 하지만 비디오 출력은 필수는 아니다.
사실 RS-232 포트도 필수는 아니다. 하지만 있으면 좋을 것 같다는 예감이 든다. 아마 전화 잭에는 여분의 두 가닥 선이 있으니, 어댑터를 통해 RS-232의 최소형(3선) 포트가 될 수도 있을 것이다. 손가락, 드라이버(금속이든 액체든), EMI, 또는 집게벌레가 기어들 수 있는 구멍은 케이스에 가능한 한 적은 것이 바람직하다. 어댑터는 액세서리로 괜찮을 것 같다.
옛 그 전화 잭을, 원한다면 여러 키보드를 연결하는 데 써도 되리라, 예컨대 저 오르간 같은 것에 달린 키보드처럼.
그리고 그 전화 잭에 이야기 상대가 있다면, 곧 네트워크가 된다면, 컴퓨터의 효용은 결정적으로 증대된다. 네트워크는 Annie라는 아이디어의 필수 부분이다. 그리고 내가 말하는 것은 ABC, CBS, PBS, NBC, Mutual이 아니다.
그것은 봄이 막 지난 직후의 맑고 따뜻한 날씨를 뜻한다.
저렴한 컴퓨터를 만들어 보자.
최초 iPhone 체크보드의 시뮬레이션. 빠르게 위아래로 스크롤해 그 동작을 확인해 보라.
출시 당시에도 환상적이었고, 가로 스크롤을 처음으로 실용적으로 만들었으며, 시간이 지나면서 더 많은 잘 만들어진 상호작용의 기반이 되었다. 처음에는 pull to refresh, 그리고 결국에는 홈 버튼을 대체하는 제스처까지. 그 뒤 수십 년 동안 나는 특허 모양의 해자 때문에 이 메커니즘에서 멀어진 모든 Android 사용자들이 안타까웠다.
스크롤 내용을 정확히 보여 줄 수 없을 때 체크보드를 넣은 Apple 팀의 판단이 좋았다. 이는 수십 년 전 Mac이 창 크기 조절에서 썼던 바로 그 트릭이었다. 경쟁사들이 그 상호작용이 정말로 일정한 60fps로 돌아가는지 확인하기 위해 고속 카메라로 촬영했다는 이야기도 전해진다.
하지만 이에 대한 내 경탄이 정점에 달한 것은 몇 년 뒤였다. 내가 작업하던 프로토타입 중 하나에서, 페이지가 스크롤되는 동안 무언가를 하도록 JavaScript 코드를 추가했는데… 코드의 절반이 실행되지 않았다. 무슨 일이 벌어지는지 이해하는 데 몇 시간이 걸렸다. 그리고 그것은 원래 일어나서는 안 되는 일이기 때문에 더 이해하기 어려웠다. iOS는 스크롤이 가능한 한 매끄럽도록 보장하기 위해, 내 코드를 함수 한가운데에서 멈춰 세웠다. 어떤 현대 프로그래밍 언어도 감히 당신의 함수를 중간에서 끊지 않을 것이다. iOS는 사용자의 손가락에 너무나 헌신적이어서 프로그래밍의 기본 계약까지 깨뜨린 것이다.
하지만 iPhone의 스크롤링은 갑자기 하늘에서 떨어진 것이 아니었다. 그것의 관성 물리는 여러 세대의 iPod click wheels에서 연마되었다. 그리고 또 하나의 핵심 구성 요소가 있었는데, 혁명적이라는 사실을 깨닫지 못한 채 나도 이전에 사용했던 것이었다. 2005년 PowerBooks에 도입된 두 손가락 스크롤이다. 얼마나 훌륭하게 느껴졌는지 충격적이었다. 존재하기 전부터 이미 하고 있던 일처럼 느껴질 만큼 직관적인 무언가라니!
사랑받던 PowerBook G4 12"는 두 손가락 스크롤을 처음 도입한 기계들 가운데 하나였다
어떤 면에서는 이것이 iPhone의 스크롤링보다 더 어려웠다. 트랙패드는 이미 10년 넘게 한 손가락 동작, 즉 포인터 이동을 갖고 있었기 때문이다. 두 손가락으로 패닝을 추가한 사람들은 이 두 양식 사이를 문제없이 쉽게 전환할 수 있게 만들어야 했다.
이런 전환은 잘못 구현되면 서툴고, 잘 구현되면 과소평가된다. 그리고 손가락이 빠르게 움직이려 할수록 더욱 중요해진다.
예를 하나 들어 보자. 화면에서 무언가를 드래그하고 있는데, 공간이 부족하다는 걸 깨달았다. 필요한 공간은 저기 있지만, 거기 가려면 스크롤해야 한다. 예전 세계에서는 물건을 내려놓고 스크롤바를 잡아 공간을 만든 뒤, 다시 물건을 집어야 했다. 아니면 물건을 잡은 채 가장자리로 옮겨 자동 스크롤을 켤 수도 있었는데, 유망해 보였지만 치명적인 결함이 있었다. 상호작용의 역사상 그 부분을 제대로 해낸 사람은 아무도 없었다.
Edge scrolling
오늘날 트랙패드에서는, 물건을 그냥 잡은 채로 놓지 않고 다른 두 손가락으로 이동할 수 있다.
앞서 이야기한 그 대시보드/데스크톱 트릭, 키를 누르고 있다가 놓는 유연한 순간 말이다. 그 위에 무언가를 더 쌓을 수 있다. 무언가를 쥔 채로 데스크톱을 보이게 하거나 다시 숨기고, 하나의 유연한 제스처 안에서 항목을 한 장소에서 다른 장소로 옮길 수 있다.
Press vs. hold threshold
100
Timer after
Mode
이런 예시는 잘 숙고된 인터페이스 전반에 걸쳐 존재한다.
⌘Tab의 미묘함을 기억하는가? 그 상호작용의 훌륭한 점 중 하나는 그것이 키보드에만 갇혀 있지 않다는 것이다. 왼손으로 그것을 호출하고, 즉시 오른손을 겹쳐 원하는 앱을 가리킬 수 있다. 새로운 우주에서 다시 등장한 Shift의 교훈이다.
Threshold
Hold before showing
이것은 왼손잡이에게는 조금 더 어렵기도 하다. 그래도 내가 이야기를 들어 본 몇몇 사람들은 여전히 오른손으로 마우스나 트랙패드를 쓰는 쪽을 택한다고 했다.
(이 많은 상호작용에서 왼손과 Shift, ⌘ 같은 수정 키가 자주 등장하는 이유는, 1968년에 Doug Engelbart가 키보드 왼쪽에 keyset을 두고 오른쪽에 마우스를 놓은 이유와 같다. 이것은 두 손의 힘을 결합하고, 1980년대 형사 콤비 코미디처럼 한 손에게는 “느슨한 가리키기” 임무를, 다른 손에게는 “정밀한 버튼 누르기” 임무를 맡긴다.)
keyset, 키보드, 그리고 최초의 마우스
또 다른 예: Finder의 미리 보기가 스페이스를 영리하게 활용한다는 것을 기억하는가? 그 위에 또 쌓을 수 있다. 한 손으로 스페이스를 누른 채, 다른 손으로 화살표 키를 눌러 더 많은 파일을 빠르게 미리 볼 수 있다. 그리고 우리가 배운 대로, 화려한 미리 보기 전환은 중단된다.
Press vs. hold threshold
100
Timer after
Mode
이것의 또 다른 버전은 앞서 말한 spring-loading을 확장한다. 아이콘을 폴더 안의 폴더로 드래그하려 하는데, 그 폴더를 아직 열지 않았다는 것을 깜빡했다면, 그 폴더 위에 1~2초쯤 머물기만 하면 된다. 그러면 항목을 내려놓지 않아도 자동으로 열린다(거의 다 왔다는 것을 알려 주는 깜빡임도 함께). 이 과정을 계속하면 꽤 깊이 들어갈 수도 있다. 보너스? 원하는 곳에 항목을 떨어뜨리면, 자동으로 열린 것들은 다시 닫혀 준다.
그리고 이것보다 더 좋아질 수도 있다. 새 창이 뜰 때까지 잠깐 기다려야 하는 것이 답답하다면, 가장 친근한 키를 사용해 그것을 더 빠르게 만들 수 있다. 짐작하겠지만, 바로 스페이스다. (그리고 물론, 어느 순간이든 Esc를 통해 이 카드 쌓기 전체를 포기할 수도 있다.)
Spring-loading delay
Before spring-loading
현실에서도 양손에 장을 들고 있을 때 쉽게 열리는 문을 감탄할 만하듯이.
사람들이 이런 식으로 여러 동작을 결합할 수 있게 하는 인터페이스를 만드는 것이야말로 진정으로 숙련을 가능하게 하는 일이며, 충분히 감탄할 가치가 있다.
내가 Gmail을 포기하게 된 이야기는 정확히 그 반대편에 있다.
하루에도 여러 번, 나는 이런 일을 겪었다. 트랙패드로 Reply를 클릭하고, 답장 작성 창이 예상대로 열리는 것을 본다. 손가락은 타이핑을 시작하기 위해 트랙패드에서 키보드로 이동한다. 그런데 그다음, 짜증 나는 방식으로, Gmail UI는 이제 내가 수신자 이름 위에서 마우스를 움직이고 있다고 해석하고, 그 사람에 대한 hovercard를 띄운다.
Video 10 그 hovercard는 단지 짜증 나고 산만한 정도가 아니다. 그것만으로도 이미 작은 위반이겠지만. 그것은 바로 내가 타이핑하려던 정확한 영역을 덮어 버린다. 매.번.정.말.
이제 나는 hovercard를 쫓아내기 위해 손가락을 다시 마우스로 옮겨야 했다. 아마 하루에 스무 번은 넘게, 일주일 내내, 1년 52주, 수없이 많은 해 동안 그렇게 했을 것이다. 그 일이 벌어질 때마다 5센트씩 받았다면, 나는 구리 중독에 걸렸을 것이다.
왜 이렇게 짜증 났을까? 우리가 배운 바로 그것 때문이다. 운동 기억과는 협상할 수 없다. 다른 모든 곳에서는 버튼이 잘 작동하고, 운영체제는 내가 타이핑을 시작하면 마우스 커서를 부드럽게 숨겨, 그것이 방해가 될 수 있다는 걸 안다. 수년간의 연습은 이 동작을 어디서나 믿을 수 있는 제스처 로 만들었다. Gmail만 빼고.
1984년 첫 Macintosh가 타이핑 중 마우스 포인터를 숨기는 모습
이것은 손가락을 이해하지 못하는 인터페이스였고, Google의 대표 생산성 앱이라 할 만한 곳에서 나온 것이었다. 이것은 “마지막 입력 양식이 승리한다”는 점을 이해하지 못한 인터페이스였다. 그리고 다시 마우스가 움직이기 전에는, 키보드 이벤트 뒤에 마우스 관련 동작을 실행해서는 안 된다는 것도 몰랐다. 우리가 그것을 알아낸 지 30년이 지나서도 그런 식으로 동작했다는 것은 변명의 여지가 없었다. 그리고 그것이 오늘날에도 여전히 그렇다는 것(방금 확인했다)은 더 심하다.
나는 한때 이런 “작은 거대한 디테일” 블로그들에 짜증이 났었다. 최악의 경우, 그것들은 즐겁게 보이지만 실제로는 무언가를 잘 사용하는 데 해로운 것들을 보여 주었기 때문이다. 다 소진될 때까지 기다려야 하는 전환. 주변 시야에서 산만함을 만드는 애니메이션. 스트레스나 공황의 순간에 실제로는 혼란스럽기만 한 귀여운 문구.
가끔 사람들은 자신감은 자신감의 부재라고 말한다. 우리가 일상적으로 자신감을 어떤 종류의 마초성으로 축소해 버린다는 뜻이다. 절대 틀렸다고 인정하지 않는 것, “강하고 말없는 유형”, 그런 것들 말이다. 하지만 진정한 자신감은 더 깊은 종류의 강함이다. 취약함, 신뢰성, 실수를 인정하는 것.
같은 방식으로, 나는 종종 기쁨도 기쁨의 부재라고 생각한다. 빠른 손가락을 환영하는 장소와 앱에서, 기쁨은 전환이나 귀엽지만 치명적인 무언가를 삼가는 것 일 수 있다. 올바른 종류의 기쁨을 추구한다는 것은 프레임워크와 오랜 싸움을 벌여 단 한 프레임의 지연이라도 줄이는 것을 의미할 수 있다. CSS를 다듬어 아이콘 사이에 단 한 픽셀도 낭비되지 않게 하여 망설임 없이 빠르게 클릭하게 만드는 것일 수 있다. 표면을 넘어서는 접근성 이해, 그리고 키보드 포커스가 끊기지 않도록 테스트하고 미세 조정하는 것일 수 있다. 언제나 올바른 필드에 있고, 결코 지연되지 않으며, 무작위 팝업에게 빼앗기지 않는 포커스 말이다.
그리고 업계의 우리가 이것을 완전히 내면화했는지는 잘 모르겠다.
우리는 물리적 도구를 더 잘 판단한다. 균형이 맞지 않는 망치, 삐걱거리는 문, 물컹한 비디오게임 컨트롤러 버튼. 전문 카메라 리뷰는 조작계의 느낌에 대해 시간을 들여 이야기한다. 당신의 손가락이 그것들을 매일 몇 시간씩 사용할 것임을 잘 알기 때문이다. 기계식 키보드 제작자들이 같은 이유로 재료 과학과 윤활에 집착하는 것도 마찬가지다.
내 카메라의 여러 디테일들. 조작을 더 신뢰성 있게 쓰게 하거나, 조작들 사이를 구분하게 하거나, 그저 더 좋은 촉각 경험을 주는 다양한 설계 기법을 보여 준다.
하지만 화면 인터페이스 설계에 대해서는 같은 태도를 보지 못한다. 인터페이스 버그는 신고하기도 답답하고, 신고되더라도 흔히 “있으면 좋은 것”, 혹은 “빠른 후속 작업”, 아니면 운이 좋다면 “미래의 작은 개선 가능성” 정도로 축소된다. 우리는 Apple의 하드웨어와 소프트웨어를 아주 다르게 판단한다. 상황이 정말 심각할 때에만 반란을 일으킨다.
나는 이런 것들에 신경 쓴다. 각각 따로 떼어 보면 작아 보이지만, 결국은 끊임없이 불복종하고 사람을 짜증 나게 하는 기기들과 함께하는 삶을 이루기 때문이다. 도시의 소음, 수도관의 납, 깜빡이는 형광등 같은 것이다.
바로 위에서 Gmail을 언급했다. 나는 다른 모든 앱에서 형성된 운동 기억을 Notion의 선택 메커니즘이 존중하지 않기 때문에 Notion을 쓸 수 없다. Apple에게 많은 찬사를 보냈지만, 최근 몇 년의 Finder는 한때 지녔던 키보드 유연성을 너무 많이 잃어버렸고, 답답한 포커스 문제와 어설픈 전환에 빠져 있다. 그리고 내 Mac의 Notes는 이제 내가 타이핑하는 속도를 따라오지 못한다. Apple이 그 강력한 프로세서를 탑재한 기계에서 그 오래된 군수품 광고를 얼마든지 되살릴 수 있을 정도인데도 말이다.
타이핑을 따라오지 못하는 것은 아마도 이 모든 문제 중 가장 심각한 것일 것이다. 왜냐하면 바로 여기서 이 에세이가 시작되었기 때문이다. 우리는 이 문제를 한 세기 전에 이미 해결했다. 우리는 전사 유창성이라는 것을 안다. 분당 30단어 정도를 넘기면 타이핑은 의식적 활동이기를 멈추고, 대신 손가락이 저절로 해내는 무언가가 된다는 생각 말이다. 그리고 우리는 이 생각을 모든 상호작용으로 확장하는 flow도 안다.
나는 이 에세이에 평소의 나치고는 다소 과장된 제목을 붙였다. 이것은 August Dvorak이 1936년 저서 Typewriting Behavior에서 사용한 그 문구를 기념하기 위해서였다.
Dvorak은 논쟁적인 인물이고, 그의 방법론은 의심을 받고 있다. 그럼에도 이 책은 손가락의 정교하고 경이로운 동작을 실제로 중요한 것들과 연결하려고 시도한다는 점에서 여전히 매혹적인 읽을거리다.
그렇다. Terminal 앱은 1960년대 터미널의 직계 후손이다!
이것은 너무 훌륭해서 현대판 Esc가 되었다. 앱 깊숙한 곳에 갇혔을 때는, 정석대로 홈 화면으로 돌아가는 길을 찾는 것보다 아래쪽 가장자리에서 그것을 쓸어 올려 날려 버리고 다시 실행하는 편이 더 쉬울 때도 있다.
내가 하루에도 여러 번 사용하는 Mac의 두 손 접근법을 Dvorak은 분명 좋아했을 것 같다. 물체를 잡아 터미널 위로 드래그한 채, 그 항목을 아직 붙들고 있는 상태에서 터미널 안에 무언가를 입력할 수 있기 때문이다! 그는 또한 iPhone의 swipe up 제스처도 좋아했을 것 같다. 그것은 상호작용 설계의 마스터클래스다. 언제나 신뢰할 수 있고, 느린 움직임과 빠른 움직임뿐 아니라, 그 중간의 몇몇 제스처들까지 허용한다.
이 둘은 타이밍, 디바운싱, 오버래핑, spring-loading, dead zones, optimistic updates를 모두 영리하게 결합한다. 둘 다 손가락이 실제로 어떻게 작동하는지 이해하고 있으며, 오직 기기와 그 소프트웨어가 우리의 손가락과 그 힘과 그 필요를 진정으로 이해할 때에만, 우리는 컴퓨터와 싸우는 대신 더 나은 일을 위해 컴퓨터를 진정으로 사용 할 수 있다는 것을 이해하고 있다.
당신이 사랑하는 사례는 무엇인지 궁금하다. 부디 알려 달라!
초기의 타이핑 시대, 손가락의 능력이 우리를 그토록 놀라게 했던 시절과, 로컬 에코와 지연 같은 기본기를 많이 알아냈던 초기 컴퓨팅 시대 이후로 우리는 많은 것을 배웠다. 기술이 바뀌더라도 이런 배움은 늘 푸를 것이다. 왜냐하면… 우리의 손가락이 그렇기 때문이다. 현대의 VR 헤드셋, AI 제품과 기기, 전기차 모두 이런 교훈의 혜택을 받는다.
위에서 내가 쓴 모든 것은 힘겹게 얻은 발견들이다. Dvorak은 더 나은 타이핑을 위해 싸웠고, Lilian Gilbreth는 인체공학과 그 사회적 측면의 이해를 위해, Doug Engelbart는 새로운 통찰로 이어지는 입력 숙련을 위해, Jef Raskin은 이전 것들에 대한 사려 깊은 재발명을 위해 싸웠다. 우리 모두보다 훨씬 더 똑똑했거나(혹은 적어도 더 운이 좋았던) 다른 많은 이름 모를 사람들이 그중 많은 것을 밝혀냈다. 이것들은 최소한의 기준이며, 우리는 그 기준에 머무를 책임을 져야 한다.
당신이 그런 결정을 내리는 디자이너이든, 무엇을 기대해야 하는지 아는 사용자이든, 당신의 손이 가져다주는 기묘한 힘에 경의를 표하길 바란다.
그럴 자격이 있다.
Glossary
Dead zone
장치의 중심(예: 조이스틱)이나 화면 위 물체 주변의 작은 영역으로, 그 안에서는 어떤 움직임도 허용되지 않는다. 이는 정지 상태에서의 우발적인 작은 움직임을 막고, 컨트롤러 드리프트를 보정하기 위해서다.
Debouncing
짧은 시간 안에 많이 발생하는 작은 이벤트들을 다루고 완화하는 방법. 현실의 스위치 (예: 전등 스위치)에서 유래했는데, “꺼짐”에서 “켜짐”으로의 물리적 변화가 지저분하고(튀고), 두 상태를 아주 빠르게 여러 번 오갈 수 있기 때문이다.
Fitts’s Law
사용자가 현재 가리키고 있는 위치(마우스나 손가락으로)에서 무언가가 멀수록, 그 대상을 더 크게 만들어야 속도와 정확성을 유지할 수 있다는 내용을 설명하는 방정식.
Haptic
“Haptic”은 촉각과 관련된 것을 뜻하며, “haptics”는 기술적 물체의 촉각 반응, 그리고 물체를 더 좋게 느끼게 만드는 인간 촉감에 대한 물리적 반응을 흉내 내는 현대 과학을 뜻한다. 예: 현대 Apple 트랙패드의 합성 클릭, 또는 스마트폰의 진동 모터.
Latency
특히 기술적 맥락에서 쓰이는, 지연이나 랙을 뜻하는 다소 거창한 말.
Motor memory
우리 뇌가 움직임을 학습하여 자동적이고 능숙하게 반복하는 능력. 흔히 “muscle memory”라고 알려져 있다.
Optimistic update
행동의 확인이 서버나 컴퓨터에서 다시 전송되기 전에 즉시 화면에 표시되는 경우. 이는 UI가 실제보다 더 빠르게 작동하는 것처럼 보이게 하기 위해 수행된다. 중요한 업데이트의 경우, 업데이트 확인이 끝내 도착하지 않을 때 이를 점검하고 사용자에게 전달하기 위한 특별한 배려가 필요하다(예를 들어 그 낙관이 잘못된 경우).
Overlapping
손과 뇌가 손가락들을 비교적 독립적으로 다루고, 다른 손가락(같은 손에 있는)들이 끝나기를 기다리지 않고 각자 자기 속도로 움직이게 하는 능력.
Spring-loaded mode
사용자 동작이 수행되는 동안 지속되는 모드. 그 동작이 끝나는 순간 인터페이스는 이전 상태로 되돌아간다(마치 스프링의 도움을 받는 것처럼). 다른 예로는 비디오게임의 push-to-talk 키, 창 드래그, iOS의 텍스트 선택 확대경이 있다. 이 아이디어의 특정한 버전으로는 dead man’s switch가 있는데, 기계 전체가 스프링으로 누르고 있을 때만 작동하는 경우다. (Jef Raskin은 그의 훌륭한 책 The Humane Interface에서 장난스럽게 “quasimode”라는 이름을 제안하려 했다.)
UI blocking
인터페이스가 반응하는 것을 완전히 막는 동작을 가리킨다. 현대 운영체제에서는 마우스 커서 자체가 막히지는 않지만, 반응하지 않는 버튼과 다른 컨트롤, 혹은 필드에 입력하거나 창을 드래그할 수 없는 상태를 뜻할 수 있다.
