스크롤바, 그냥 드래그만 하셨죠?
윈도우에서 긴 문서를 볼 때 스크롤바를 어떻게 쓰세요? 대부분 휠을 굴리거나 막대를 잡아서 끌 거예요. 그런데 스크롤바에는 수십 년 전부터 숨어 있던 조작법이 꽤 있어요. 마이크로소프트에서 30년 넘게 윈도우를 만들어 온 Raymond Chen이 자신의 블로그 The Old New Thing에서 이 스크롤바 단축 조작들이 어떻게 생겨났는지 역사를 짚었는데요, 오늘은 그 내용을 바탕으로 스크롤바라는 작은 UI 부품이 왜 생각보다 깊은 물건인지 이야기해 볼게요.
이게 뭐냐면: 스크롤바의 세 가지 영역
스크롤바는 크게 세 부분으로 나뉘어요. 양 끝의 화살표 버튼, 가운데를 오가는 막대(thumb, 엄지손가락처럼 생겼다고 이렇게 불러요), 그리고 막대가 움직이는 긴 통로(track 또는 shaft)예요. 이 세 영역이 각각 다른 동작을 해요. 화살표를 누르면 한 줄씩, 통로의 빈 곳을 누르면 한 페이지씩, 막대를 끌면 원하는 위치로 곧장 이동하죠.
여기서 첫 번째 숨은 조작이 나와요. 통로의 빈 곳을 그냥 클릭하면 한 페이지 넘어가지만, Shift를 누른 채 클릭하면 막대가 클릭한 지점으로 바로 점프해요. 1000페이지짜리 문서에서 대략 70% 지점으로 가고 싶을 때 페이지 단위로 수십 번 클릭할 필요 없이 한 번에 가는 거예요. macOS 쓰시는 분들은 Option+클릭이 같은 역할을 하고, 시스템 설정에서 아예 기본 동작을 '클릭한 위치로 이동'으로 바꿀 수도 있어요. 이 기능이 있다는 걸 모르는 분이 정말 많아요.
오른쪽 클릭 메뉴, 그리고 왜 모든 앱에서 공짜로 되는가
두 번째는 스크롤바 위에서 마우스 오른쪽 버튼을 누르는 거예요. 그러면 '여기로 스크롤', '맨 위', '맨 아래', '페이지 위로', '페이지 아래로', '위로 스크롤', '아래로 스크롤' 같은 메뉴가 나와요. 윈도우 95 시절 새 UI와 함께 자리 잡은 기능인데, 재미있는 건 개발자가 이 메뉴를 위해 아무 코드도 쓰지 않아도 된다는 점이에요.
왜 그러냐면, 윈도우의 스크롤바는 앱에게 '사용자가 뭘 눌렀는지'를 알려주는 게 아니라 '얼마나 어디로 움직이고 싶어 하는지'만 알려주거든요. 스크롤바 컨트롤은 사용자가 화살표를 누르든, 통로를 클릭하든, 오른쪽 클릭 메뉴에서 '페이지 아래로'를 고르든, 앱에게는 똑같이 WM_VSCROLL 메시지에 SB_PAGEDOWN이라는 코드를 붙여서 보내요. Shift+클릭이나 '여기로 스크롤'은 SB_THUMBPOSITION으로 위치값을 실어 보내고요. 앱은 이 메시지만 처리하면 되니까, 나중에 운영체제가 새로운 조작법을 추가해도 기존 앱에서 자동으로 작동해요. 입력 방법과 의도를 분리해 둔 덕분에 30년 전에 짜인 프로그램이 오늘 추가된 단축 조작을 이해하는 거예요. 설계 관점에서 꽤 배울 점이 있는 구조죠.
참고로 여기엔 유명한 함정도 하나 있어요. 막대를 끌 때 메시지에 실려 오는 위치값은 16비트로 잘려서 들어오기 때문에, 65,535줄이 넘는 긴 목록에서는 값이 틀어져요. 그래서 실제 위치는 GetScrollInfo로 따로 읽어와야 해요. Win32를 만져본 분이라면 한 번쯤 밟아봤을 지뢰예요.
마우스 휠은 생각보다 늦게 왔어요
지금은 당연한 마우스 휠도 처음부터 있었던 게 아니에요. 1996년 마이크로소프트 IntelliMouse가 나오면서 휠이 대중화됐고, 윈도우는 WM_MOUSEWHEEL이라는 메시지를 새로 만들어서 대응했어요. 초기에는 드라이버가 휠 입력을 기존 스크롤바 메시지로 바꿔서 옛날 앱에서도 돌아가게 흉내를 냈고요. 휠 한 칸에 몇 줄이 움직이는지가 시스템 설정으로 정해져 있는 것도 이때부터예요. 이후 좌우로 기울이는 틸트 휠이 나오면서 가로 스크롤용 메시지가 따로 추가됐고, 그전까지는 Shift+휠로 가로 스크롤을 흉내 내는 관습이 앱마다 퍼져 있었어요.
왜 웹 개발자도 알아야 하나요
요즘 웹이나 Electron 앱에서는 브라우저 기본 스크롤바를 숨기고 직접 그린 커스텀 스크롤바를 쓰는 경우가 많아요. 디자인은 예쁜데, 그 순간 위에서 이야기한 Shift+클릭, 오른쪽 클릭 메뉴, 키보드 접근성 같은 것들이 전부 사라져요. 사용자는 이유도 모른 채 '이 앱은 뭔가 불편하다'고 느끼게 되고요. 가상 스크롤(virtualized list)을 직접 구현할 때도 마찬가지예요. 스크롤 위치를 픽셀이 아니라 항목 인덱스로 관리하다 보면, 운영체제가 보내주는 '이 위치로 점프해' 신호를 제대로 소화하지 못하는 경우가 생겨요.
정리하면, 플랫폼이 수십 년 동안 다듬어 온 기본 컨트롤에는 눈에 안 보이는 기능이 잔뜩 들어 있어요. 그걸 대체하려면 최소한 뭘 잃는지는 알고 결정해야 해요. 그리고 '입력 방식과 의도를 분리한다'는 스크롤바의 설계 원칙은 여러분이 만드는 컴포넌트에도 그대로 적용할 수 있어요. 버튼 클릭이든 단축키든 음성 명령이든, 컴포넌트 안쪽에서는 하나의 명령으로 수렴하게 만들면 나중에 입력 방식을 추가할 때 훨씬 편하거든요.
마무리
스크롤바 하나에도 30년 치 설계 결정이 쌓여 있고, 그 핵심은 '입력과 의도의 분리'예요. 오늘 당장 Shift+클릭 한 번 해보세요.
여러분은 커스텀 스크롤바를 써본 적 있으세요? 그때 어떤 기능이 사라졌는지 눈치채셨나요? 그리고 여러분이 만든 컴포넌트 중에 입력 방식마다 별도 코드로 처리해서 나중에 고생한 경험이 있다면 공유해 주세요.
🔗 출처: Hacker News