iPhone Safari가 ‘탭하면 맨 위로 이동’이라는 당연한 제스처를 망가뜨린다는 글을 쓰고 있을 무렵, 소셜 미디어의 한 대화가 이 탭 컨트롤이 이상하게 동작하는 또 다른 지점을 짚어냈다.

Safari를 일반적인 방식으로 쓰면 사이트가 두 그룹으로 나뉘어 보인다. 오른쪽에는 일반 탭 모음이, 왼쪽에는 ‘프라이빗’ 페이지가 있다(Chrome에서는 이를 ‘시크릿 모드’라고 부른다):

예상대로 두 레이블 중 하나를 탭하면 해당 그룹으로 쉽게 전환된다:

밀어서 넘길 수 있을 것 같은 느낌도 든다 — 실제로 넘길 수도 있다, 다만…

…바로 Scroll Lock 문제를 마주하게 된다. 당신이 드래그하는 건 알약(pill)이 아니라 알약 아래에 깔린 내용이다. 전환하려면 오히려 반대 방향으로 가야 한다:

전체 시스템에 깔린 불쾌한 복잡성을 바로 직감할 수 있다 — 단순히 “엉뚱한 방향으로 가는” 것 때문만이 아니라, 조작이 끝난 뒤 공간을 만들고 다시 닫는 과정이 두 단계에 걸쳐 따로 일어나는 방식 때문에도 그렇다.

이유는 초기 두 개 말고도 더 많은 사이트 그룹을 가질 수 있기 때문이다. 심지어 새 사이트 그룹이 생길 자리까지 드래그해서 이런 식으로 만들 수도 있다:

나는 보통 이런 종류의 가속기(accelerator)는 환영하는 편이다. 하지만 여기서는 과하게 설계되어 혼란스럽다. 마치 탭을 드래그(drag)한 게 아니라 약을 먹인(drugged) 것 같은 느낌이다. 프라이빗으로 보내줘야 할 당연하고 안전한 제스처인 왼쪽 스와이프가, 이제는 거의 쓸 일 없는 무시무시한 전체 화면/키보드가 튀어나오는 플로우로 당신을 밀어 넣는다.

이 문제가 시스템 디자인과 연결되는 이유는 iOS에서 온/오프 토글이 최근 길쭉한 알약 형태로 재설계되었기 때문이다:

저 토글들은 예상대로 드래그에 반응한다:

같은 맥락에서 스프링보드의 페이지네이션 알약에서는 오른쪽으로 드래그하면 다음 페이지로 넘어간다:

그러니 이제 시스템은 분열적이다. 똑같이 생긴 디자인 프리미티브가 정반대의 의미를 갖는다. 마치 컴퓨터 자체가 무작위로 Scroll Lock을 계속 눌러대서, 시스템에 대한 확실한 이해는커녕 몸에 배는 기억조차 제대로 만들지 못하게 하는 것 같다.

여기서 저지른 실수는 두 가지였다고 생각한다. 첫째, 디자인은 불필요한 두 가지에 과도하게 최적화됐다. 사람들이 실제로 사이트 그룹을 쓰는 경우(흔하지 않다)와 사이트 그룹을 쉽게 만드는 일(중요하지 않다)이 그것이다. 약간 냉소적인 나의 가설은 이 디자인이 데모에서는 아주 멋지게 보였고, 그래서 프로젝트가 궤도를 이탈하기도 한다는 것이다. 더 냉소적인 가설은 이것이 “우연한 발견”을 만들어 사이트 그룹 지표를 더 좋아 보이게 했다는 것이다.

둘째, 그리고 더 중요한 부분은, 이 특정 디자인이 받을 자격도 없는 예외를 받았다는 점이다. 비슷한 UI 요소가 정반대로 동작한다는 시스템적 문제를 아무도 알아차리지 못했거나, 알아차린 사람들도 제대로 제동을 걸지 못했다. 새로운 기능 발견에 대한 지표는 만들기 쉽지만, 사용자의 혼란이나 좌절에 대한 지표는 보통 존재하지 않는다.

인터랙션 시스템은 이렇게 천천히 무너진다. 1부에서 언급했듯, Safari의 예외는 이제 ‘공인된’ 것으로 간주되어 더 퍼져나갈 가능성이 높다. 시간이 충분히 지나면 점점 더 많은 알약들이 드래그했을 때 제각기 원하는 방향으로 가게 될 것이고 — 사람들은 그 어떤 것도 믿지 않게 될 것이다.

이 기능의 정식 명칭이 “탭 그룹”이라는 건 알고 있지만, 의도적으로 “사이트 그룹”이라고 불렀다. 그렇지 않으면 탭 그룹을 제어하는 탭 컨트롤이 되어버려 이야기가 아주 빠르게 헷갈리기 때문이다. 그리고 이 글의 계기를 만들어준 Martin Hoffman에게 감사한다.