scrollbar 디자인에 관하여

Mac 환경에서 트랙패드만 사용해 HTML과 CSS를 개발하다 보면 스크롤 영역에 대한 확인이 부족해지는 경우가 많습니다. 트랙패드는 스크롤 동작이 자연스럽고, macOS에서는 스크롤바가 필요할 때만 나타나는 오버레이 방식으로 표시되는 경우가 많기 때문입니다.

문제는 이렇게 제작한 사이트를 Windows 환경이나 Mac에서 마우스로 확인할 때 드러납니다. 운영체제와 브라우저 설정에 따라 스크롤바가 항상 표시되거나, 스크롤 영역의 폭이 레이아웃에 영향을 주면서 콘텐츠가 밀려 보일 수 있습니다. 특히 스크롤바를 고려하지 않은 고정 폭 레이아웃이나 커스텀 스크롤 영역은 예상보다 어색한 화면을 만들기 쉽습니다.

트랙패드 중심의 개발에서 발생하는 스크롤바 문제

트랙패드는 손가락으로 화면을 밀어 스크롤하기 때문에 사용자가 스크롤바의 크기나 형태를 직접 확인하지 않아도 자연스럽게 페이지를 탐색할 수 있습니다. macOS에서는 사용자 설정에 따라 스크롤바가 스크롤할 때만 나타나거나 자동으로 숨겨질 수 있습니다. 이처럼 스크롤바의 표시 방식은 운영체제와 사용 환경에 따라 달라질 수 있습니다.

이러한 환경에 익숙한 상태에서 페이지를 제작하면 다음과 같은 문제를 놓치기 쉽습니다.

스크롤바가 차지하는 공간을 레이아웃 계산에 반영하지 못하는 경우
Windows에서 스크롤바가 항상 표시되어 콘텐츠 영역이 좁아지는 경우
Mac에서 마우스를 사용할 때 스크롤바가 예상보다 두껍거나 어색하게 보이는 경우
가로 스크롤 영역에서 세로 스크롤바와 콘텐츠가 겹치는 경우
고정된 높이를 가진 내부 스크롤 영역에서 스크롤 가능 여부가 명확하지 않은 경우

결국 트랙패드에서 부드럽게 보이던 화면이 Windows 또는 마우스 환경에서는 전혀 다른 인상을 줄 수 있습니다. 특히 카드 목록, 테이블, 모달, 사이드 패널처럼 별도의 스크롤 영역을 사용하는 UI에서 이러한 차이가 더욱 크게 나타납니다.

운영체제에 따라 스크롤바가 다르게 보이는 이유

스크롤바는 단순한 브라우저 UI처럼 보이지만, 실제로는 운영체제와 브라우저의 영향을 함께 받습니다. macOS는 스크롤바를 콘텐츠 위에 겹쳐 표시하는 오버레이 방식으로 처리하는 경우가 많습니다. 이때 스크롤바는 레이아웃의 실제 너비를 차지하지 않을 수 있습니다.

반면 Windows에서는 스크롤바가 콘텐츠 영역 안에서 일정한 너비를 차지하는 방식으로 표시되는 경우가 많습니다. 동일한 CSS를 적용하더라도 스크롤바의 너비만큼 콘텐츠 영역이 줄어들 수 있으며, 이로 인해 다음과 같은 시각적 차이가 생깁니다.

버튼이나 입력창의 오른쪽 여백이 달라짐
카드가 한 줄에 배치되지 않고 다음 줄로 내려감
고정 폭 요소와 유동 폭 요소의 정렬이 어긋남
모달 내부 콘텐츠가 스크롤바와 지나치게 가까워짐
페이지 진입 전후로 전체 화면이 좌우로 미세하게 움직임

특히 화면 중앙에 고정된 모달이나 좌우 정렬이 중요한 페이지에서는 스크롤바의 표시 여부만으로도 레이아웃이 흔들리는 문제가 발생할 수 있습니다.

WebKit 프리픽스를 이용한 스크롤바 커스터마이징

많은 개발자가 스크롤바 디자인을 조정하기 위해 다음과 같은 WebKit 전용 의사 요소를 사용합니다.

::-webkit-scrollbar {
  width: 8px;
}

::-webkit-scrollbar-track {
  background: transparent;
}

::-webkit-scrollbar-thumb {
  background: #bbb;
  border-radius: 4px;
}

이 방식은 Chromium 계열 브라우저와 Safari 등에서 스크롤바의 너비, 트랙, 썸 부분을 세밀하게 조정할 수 있다는 장점이 있습니다. 브랜드 색상에 맞춰 스크롤바를 디자인하거나 특정 콘텐츠 영역의 스크롤바를 눈에 덜 띄게 만들 때 유용합니다.

하지만 WebKit 프리픽스 방식에는 몇 가지 한계가 있습니다. 우선 표준화된 모든 환경에서 동일하게 동작한다고 보기 어렵습니다. 브라우저마다 지원 범위와 표현 방식이 다를 수 있고, 운영체제의 기본 스크롤바 정책에 따라 실제 표시 결과가 달라질 수 있습니다.

특히 스크롤바를 지나치게 얇게 만들거나 트랙과 썸의 색상 대비를 낮추면 사용성이 떨어질 수 있습니다. 사용자가 스크롤바를 시각적인 조작 요소로 인지하지 못하면, 마우스로 썸을 선택해 드래그하는 방식으로 스크롤하기 어려워집니다. 스크롤바가 존재한다는 사실이나 현재 위치를 파악하기도 힘들어지므로, 단순히 화면에서 덜 보이게 만드는 것보다 충분한 너비와 색상 대비를 유지하는 것이 좋습니다.

또한 다음처럼 html 또는 body를 기준으로 스크롤바를 스타일링하더라도, 실제 스크롤 주체가 어디인지에 따라 적용 결과가 달라질 수 있습니다.

html::-webkit-scrollbar {
  width: 10px;
}

body::-webkit-scrollbar {
  width: 10px;
}

브라우저에 따라 문서 전체의 스크롤 영역이 html에 연결되기도 하고, body가 스크롤 컨테이너처럼 동작하기도 합니다. 여기에 특정 레이아웃에서 body에 overflow: hidden을 적용하거나 별도의 래퍼 요소에 overflow: auto를 설정하면, 개발자가 예상한 대상과 실제 스크롤 대상이 달라질 수 있습니다.

따라서 스크롤바를 커스텀할 때는 스타일을 적용할 요소뿐만 아니라 실제로 스크롤이 발생하는 컨테이너도 함께 확인해야 합니다. 다양한 브라우저와 운영체제에서 스크롤바의 식별 가능성, 충분한 색상 대비, 마우스 드래그 가능 여부를 테스트하는 것도 중요합니다.

Root 스크롤바를 직접 제어하기 어려운 이유

페이지 전체의 스크롤바를 제어하려면 일반적으로 html 또는 body에 스타일을 적용하게 됩니다. 그러나 브라우저는 문서 전체의 스크롤 영역을 일반적인 div 요소와 동일하게 처리하지 않을 수 있습니다.

예를 들어 다음과 같이 문서 전체에 스크롤바 스타일을 적용했다고 가정해 보겠습니다.

html {
  overflow-y: scroll;
}

html::-webkit-scrollbar {
  width: 12px;
}

html::-webkit-scrollbar-thumb {
  background: #888;
}

이 코드는 일부 환경에서는 의도한 대로 작동하지만, 다른 환경에서는 기본 스크롤바가 나타나거나 body 쪽 스타일이 적용되는 것처럼 보일 수 있습니다. 브라우저의 viewport 처리 방식, 운영체제의 오버레이 스크롤바 설정, 상위 요소의 overflow 속성 등이 복합적으로 영향을 주기 때문입니다.

따라서 root 영역의 스크롤바를 디자인할 때는 단순히 WebKit 의사 요소를 추가하는 것만으로 충분하지 않습니다. 실제로 어느 요소가 스크롤을 담당하는지 먼저 확인해야 하며, html과 body의 높이 및 overflow 설정도 함께 점검해야 합니다.

표준 속성과 WebKit 방식의 차이

최근에는 일부 브라우저에서 표준 속성인 scrollbar-width와 scrollbar-color를 사용할 수 있습니다.

* {
  scrollbar-width: thin;
  scrollbar-color: #999 transparent;
}

이 방식은 코드가 간결하다는 장점이 있지만, WebKit 계열에서 제공하는 것처럼 스크롤바의 모든 부분을 세밀하게 디자인할 수 있는 것은 아닙니다. 반대로 ::-webkit-scrollbar는 더 다양한 디자인이 가능하지만 브라우저와 운영체제에 따른 차이를 고려해야 합니다.

실무에서는 특정 브라우저만을 기준으로 스크롤바를 완전히 변경하기보다는, 기본 스크롤바를 사용해도 레이아웃과 가독성이 유지되도록 설계하는 것이 안전합니다. 커스텀 스타일은 보조적인 디자인 요소로 활용하고, 스크롤 기능 자체가 정상적으로 전달되는지를 우선 확인해야 합니다.

개발 과정에서 확인해야 할 환경

스크롤 영역을 포함한 페이지를 제작했다면 트랙패드 환경만으로 최종 확인해서는 안 됩니다. 최소한 다음과 같은 조건에서 화면을 점검하는 것이 좋습니다.

macOS에서 트랙패드를 사용하는 환경
macOS에서 마우스를 사용하는 환경
Windows에서 마우스를 사용하는 환경
Chrome, Safari, Edge 등 주요 브라우저
스크롤바 항상 표시 설정과 자동 표시 설정
브라우저 확대 비율이 100%가 아닌 환경
페이지 전체 스크롤과 내부 스크롤이 함께 존재하는 화면

또한 스크롤바가 나타나거나 사라질 때 레이아웃이 움직이는지 확인해야 합니다. 필요하다면 scrollbar-gutter 속성을 검토할 수 있습니다.

html {
  scrollbar-gutter: stable;
}

scrollbar-gutter: stable은 스크롤바가 표시될 공간을 미리 확보해 스크롤바의 표시 여부에 따라 콘텐츠가 흔들리는 현상을 줄이는 데 도움을 줄 수 있습니다. 다만 브라우저 지원 범위와 실제 적용 대상은 프로젝트 환경에 맞춰 확인해야 합니다.

스크롤바 디자인보다 중요한 사용성

스크롤바를 브랜드 디자인에 맞게 변경하는 것은 가능하지만, 지나치게 얇거나 배경과 비슷한 색을 사용하면 사용자가 스크롤 가능 여부를 알아차리기 어려울 수 있습니다. 특히 데스크톱에서 마우스를 사용하는 사용자는 스크롤바를 직접 드래그해 콘텐츠를 이동하는 경우가 많습니다.

따라서 커스텀 스크롤바를 적용할 때는 다음 기준을 고려하는 것이 좋습니다.

스크롤바 썸과 배경의 명도 차이를 충분히 확보할 것
너비를 지나치게 얇게 설정하지 않을 것
모달이나 테이블처럼 스크롤이 중요한 영역에서는 스크롤바를 숨기지 않을 것
키보드 방향키, Page Up, Page Down, Home, End 키로도 이동할 수 있도록 할 것
모바일과 데스크톱에서 스크롤 방식이 다를 수 있음을 고려할 것

스크롤바는 장식 요소이면서 동시에 사용자가 현재 콘텐츠의 위치와 이동 가능 여부를 확인하는 인터페이스입니다. 디자인을 변경하더라도 기능적인 의미가 약해지지 않도록 해야 합니다.

결론

Mac에서 트랙패드만 사용해 웹사이트를 개발하면 스크롤 동작은 자연스럽게 확인할 수 있지만, 스크롤바가 실제 화면에 어떻게 표시되는지 놓치기 쉽습니다. 특히 Windows 환경이나 Mac의 마우스 환경에서는 스크롤바의 너비와 표시 방식이 달라져 레이아웃이 어긋나거나, 커스텀 스크롤바가 어색하게 보일 수 있습니다.

::-webkit-scrollbar와 같은 WebKit 프리픽스는 스크롤바를 디자인하는 데 유용하지만, root 영역의 스크롤바는 브라우저와 운영체제의 처리 방식에 따라 제어가 일관되지 않을 수 있습니다. 따라서 html, body, 내부 스크롤 컨테이너 중 실제 스크롤 주체를 먼저 확인하고, 여러 운영체제와 입력 장치에서 결과를 검증해야 합니다.

결국 중요한 것은 특정 환경에서만 보기 좋은 스크롤바를 만드는 것이 아니라, 어떤 운영체제와 브라우저에서도 콘텐츠가 안정적으로 배치되고 사용자가 스크롤 가능 여부를 명확히 인식할 수 있도록 설계하는 것입니다. 트랙패드 중심의 개발 습관에서 벗어나 마우스와 Windows 환경까지 함께 점검한다면 스크롤 영역에서 발생하는 많은 품질 문제를 사전에 줄일 수 있습니다.