화면을 오래 다룬 개발자라면 스크롤바를 별생각 없이 쓴다. 마이크로소프트의 오랜 기술 블로그 '올드 뉴 씽(The Old New Thing)'이 정리한 스크롤바 단축키의 역사는, 이 사소해 보이는 컨트롤이 실은 운영체제 세대와 UI 프레임워크에 따라 제각각 동작한다는 사실을 드러낸다. 결론부터 말하면, 편리한 조작법이 하나 있어도 요즘 환경에서는 그것이 어디서 작동할지 장담하기 어렵다.
다섯 개의 조작점에서 시작된 컨트롤
윈도우 초기 20년 동안 스크롤바는 매우 단순했다. 세로 스크롤바를 기준으로 보면 조작 지점은 다섯 개다. 양 끝의 화살표는 한 줄씩 스크롤하고, 화살표와 썸(thumb, 드래그하는 막대) 사이의 빈 공간(거터)을 누르면 한 페이지씩 이동하며, 썸 자체를 잡아 끌면 원하는 위치로 직접 이동할 수 있다. 오랫동안 이 구조가 표준이었다.
윈도우 7에서 스크롤바에 우클릭 메뉴가 추가됐다. 이 메뉴에는 기존 마우스 조작과 겹치는 항목 넷, 키보드 조작과 겹치는 항목 둘, 그리고 완전히 새로운 항목 하나가 담겼다. 새 항목이 바로 '여기로 스크롤(Scroll Here)'이다. 긴 문서에서 멀리 이동하고 싶을 때, 썸을 잡아 목적지까지 끌고 갈 필요 없이 도착하고 싶은 지점을 우클릭한 뒤 이 항목을 고르면 된다. 출발점이 아니라 도착점에만 집중하면 되므로 장거리 이동에 특히 편하다.
같은 시기에 더 감춰진 단축키도 들어갔다. Shift를 누른 채 스크롤바를 클릭하면 썸이 그 지점으로 곧장 점프한다. 글을 쓴 필자조차 최근에야 이 단축키를 알았고, 그전까지는 줄곧 우클릭 메뉴에 의존했다고 털어놓는다. 다만 댓글에서는 이 스냅 동작이 윈도우 XP에도 이미 있었으며, 2006년 첫 크로미움 스크롤바 구현이 바로 그 XP 동작을 기반으로 만들어졌다는 증언이 나온다. 즉 Shift+클릭 자체는 윈도우 7보다 훨씬 오래된 기능일 가능성이 크다.
프레임워크마다 갈라진 동작
문제는 오늘날 순수 Win32 스크롤바를 쓰는 앱이 거의 없다는 점이다. 대부분의 애플리케이션은 각자의 커스텀 스크롤바를 제공하는 프레임워크 위에서 돌아간다. 일렉트론을 비롯한 웹 앱은 크로미움 스크롤바를 쓰는데, 여기에는 우클릭 메뉴가 없지만 Shift+클릭 점프는 구현돼 있다. 데스크톱 계열에서는 WPF XAML이 메뉴와 Shift+클릭을 모두 지원하는 것으로 보이는 반면, 후속인 WinUI XAML은 둘 다 없다. 최신 프레임워크가 오히려 기능을 잃은 셈이며, 이를 요청한 사용자도 이미 있다.
Qt는 접근 방식이 다르다. 여러 커스터마이즈 지점을 열어 두어 결국 앱 개발자의 선택에 맡긴다. SH_ScrollBar_ContextMenu로 우클릭 메뉴를, SH_ScrollBar_LeftClickAbsolutePosition으로 좌클릭 위치 점프를, SH_ScrollBar_MiddleClickAbsolutePosition으로 중간 클릭 점프를 각각 켤 수 있다. 유연하지만 뒤집어 말하면 앱마다 동작이 다를 수 있다는 뜻이다. 참고로 macOS에서는 거터를 Option+클릭하면 그 지점으로 바로 이동하는데, 이 역시 널리 알려져 있지 않다.
실무자에게 남는 함의
조작법이 표준화돼 있지 않다는 점 외에, 동작 자체가 어긋나는 사례도 보고된다. 윈도우 10과 서버 2016~2022의 현대적 앱에서는 거터 클릭이 한 화면보다 약간 덜 스크롤됐는데, 설정 앱에서는 오히려 한 화면보다 더 많이 넘어가 되돌려야 하는 불편이 있었다. 윈도우 11이 이를 부분적으로 고쳐 정확히 한 화면을 넘기게 됐지만, 창 하단에 반쯤 걸친 텍스트 줄이 페이지 다운 후에도 여전히 반만 보이는 문제는 남는다. 또 스크롤하는 동안 폭이 동적으로 바뀌는 목록에서는, 썸을 끌 때 목록이 넓어지며 스크롤바가 마우스의 잡기 영역 밖으로 밀려나 순식간에 목록 최상단으로 튀어 오르는 버그도 있다. 과거 윈도우 업데이트 화면에서 재현이 쉬웠고, 최근에는 같은 UI를 쓰는 서드파티 앱에서도 관찰됐다.
실무 관점에서 얻을 교훈은 두 가지다. 첫째, Shift+클릭이나 우클릭 '여기로 스크롤'은 알아 둘 가치가 있는 조작법이지만, 사내에서 쓰는 앱이 어떤 프레임워크로 만들어졌는지에 따라 될 수도, 안 될 수도 있으니 '항상 되는 기능'으로 전제하지 않는 편이 안전하다. 둘째, UI 프레임워크를 고르거나 마이그레이션할 때 스크롤바 같은 기본 상호작용의 이식 여부까지 점검 항목에 넣어야 한다는 점이다. 새 프레임워크가 최신이라는 이유만으로 오래된 편의 기능을 그대로 물려받지는 않는다. 스크롤바 하나가 보여주듯, 표준처럼 보이는 요소일수록 실제로는 각 계층의 구현 선택에 좌우된다.