김동영

Bottom sheet의 handle 요소는 항상 포함되어야 할까?

시트가 사라지는 방향과 handle이 의미하는 것

14분

모바일 앱에서 화면 하단으로부터 올라오는 시트를 열면, 맨 위에 짧은 회색 막대가 하나 붙어 있는 경우가 많습니다. handle이라고 부르는 요소예요. 습관처럼 handle을 잡고 끌어 올렸는데 시트가 꿈쩍도 하지 않았던 경험이 있으신가요? 저는 꽤 자주 겪었고, 그때마다 handle이 왜 거기 있는지 궁금했습니다.

디자인 시스템에서 바텀 시트(Bottom sheet) 컴포넌트를 설계하다 보면 handle을 어떻게 다룰지 정해야 하는 순간이 옵니다. 대부분의 시트에 붙어 있으니 일단 넣고 보는 게 안전해 보이죠. 그런데 handle은 장식이 아니라 사용자에게 특정 동작이 가능하다고 알려 주는 시각적 단서입니다. 단서를 주었다면 그 동작이 실제로 가능해야 해요.

이 글에서는 handle이 무엇을 의미하는지부터 정의하고, 그 의미에 따라 handle과 닫기 버튼을 각각 언제 두면 좋을지 정리해 보려고 합니다.

handle은 무엇을 의미할까#

저는 handle을 '잡는 곳'으로만 생각했습니다. 시트의 높이를 조절하거나 시트를 끌어내려 닫으려면 handle을 잡아야 한다고요. 그런데 요즘 앱에서 시트를 다뤄 보면 handle을 잡지 않아도 되는 경우가 대부분입니다. 시트의 아무 곳이나 잡고 아래쪽으로 끌어도 닫히고, 내용을 위로 스크롤하면 시트가 함께 확장되기도 해요. 이 글에서 '드래그'는 이렇게 시트를 손가락으로 끌어 움직이는 동작이고, 따로 밝히지 않으면 아래쪽으로 끌어내려 닫는 동작을 말합니다.

높이 조절과 드래그로 닫는 동작이 시트 자체의 책임이니, handle은 그 동작을 시작하는 유일한 지점이 아닙니다. 이 시트에서 어떤 동작이 가능한지 알려 주는 단서에 가까워요. 정확히 말하면 높이를 조절하거나 드래그로 닫을 수 있다는 것 자체가 어포던스(Affordance)이고, handle은 그런 어포던스가 있다고 알려 주는 시그니파이어(Signifier)입니다. 그래서 질문은 "handle을 끌면 무엇이 되는가"가 아니라 "handle이 있다는 사실이 사용자에게 무엇을 의미하는가"가 됩니다.

handle이 의미하는 동작은 높이 조절과 드래그로 닫기, 두 가지입니다. 높이가 조절되면서 드래그로 닫히기도 하는 시트라면, 어느 의미로 보든 handle을 두면 되니 고민할 게 없습니다. 문제는 높이가 고정되어 있지만 드래그로는 닫히는 시트예요. handle을 높이 조절의 단서로 보면 이 시트에는 handle이 필요 없고, 닫기의 단서로 보면 필요합니다. 같은 시트를 두고 정반대의 답이 나오니, 두 의미 중 어느 쪽을 handle의 주된 의미로 볼지 정해야 했어요.

아래에서 올라왔으니 아래로#

처음에는 높이 조절이 handle의 주된 의미라고 생각했습니다. handle을 보고 시트를 끌어 올렸다가 아무 반응이 없던 경험이 쌓였고, iOS의 시트 가이드라인도 높이가 조절되는 시트에 handle을 넣으라고 하기 때문이에요. 그 기준대로라면 높이가 고정되어 있는 시트에는 handle을 둘 이유가 없습니다.

생각을 바꾼 건 시트가 사라지는 방향이었습니다. 바텀 시트는 화면 아래에서 올라옵니다. 등장한 방향으로 다시 퇴장시키면, 사용자는 시트를 화면 아래에서 잠시 꺼냈다가 다시 넣어 두는 물체처럼 인식하기 쉬워요. 화면 요소가 등장한 방향으로 퇴장해야 화면의 공간 구조가 흐트러지지 않는다는 원칙과도 맞습니다. 실제로 iOS와 Android의 기본 시트는 드래그로 닫는 동작을 지원하고, 이 동작은 이미 보편화되어 있어요.

드래그로 닫기가 시트의 기본 동작이 되면, handle이 붙은 시트는 거의 모두 드래그로 닫히고 높이 조절은 그중 일부에서만 가능합니다. 사용자가 handle을 보고 떠올리는 동작도 자주 겪는 쪽, 그러니까 드래그로 닫기 쪽으로 기운다고 봅니다. 이 관점에서 보면 handle의 주된 의미는 '이 시트는 드래그로 닫을 수 있다'에 가깝습니다. 국내의 몇몇 앱은 높이를 조절할 수 없는 시트에도 handle을 두고 드래그로 닫히게 합니다. handle을 '드래그로 닫을 수 있는 시트'의 단서로 사용하는 셈이에요. 그래서 저는 handle의 주된 의미를 드래그로 닫기로 보고, 드래그로 닫을 수 있는 시트라면 높이를 조절할 수 있든 없든 handle을 둡니다.

다만 비용이 하나 있습니다. handle 자체는 방향을 구분해 주지 않아요. 높이가 고정되어 있는 시트에 handle이 있으면, 저처럼 handle을 끌어 올렸다가 꿈쩍도 하지 않는 시트에 당황하는 사용자가 생깁니다. 이 비용을 줄이는 방법도 있습니다. 위로 끌어 올리면 시트가 손가락을 따라 약간 올라오다가 더는 확장되지 않고, 손을 떼면 원래 위치로 복귀하게 하는 거예요. 아무 반응이 없는 것보다, '여기까지가 이 시트의 높이'라고 동작으로 알려 주는 편이 오해를 덜 남깁니다. 높이가 고정되어 있는 시트에 handle을 둔다면, 이 되돌아오는 움직임까지 함께 설계해야 합니다.

단서는 하나만 보여 준다#

그럼 handle이 있는 시트에 오른쪽 위의 닫기 버튼도 함께 두어야 할까요? 드래그에만 기대면 시트를 닫지 못하는 사용자가 생기는 것은 사실입니다. 길게 드래그하는 동작은 손을 정밀하게 움직이기 어려운 사용자에게 장벽이 돼요. 웹 접근성 기준(WCAG)도 드래그로 실행하는 기능은 한 번 누르는 동작으로도 실행할 수 있어야 한다고 정해 두었습니다.

그런데 드래그 없이 닫는 방법이 꼭 닫기 버튼일 필요는 없습니다. 뒤에 어두운 배경이 깔리는 시트는 배경을 누르면 닫히고, Android에서는 뒤로 가기로도 닫혀요. 국내의 한 디자인 시스템은 이 두 가지를 시트가 지원해야 할 동작으로 권장하기도 해요. 시트 아래쪽에 '취소'나 '확인' 같은 버튼이 있다면 그 버튼도 드래그 없이 시트를 떠나는 방법입니다. 이 버튼은 시트를 치우는 신호가 아니라 작업을 끝내는 액션이라, handle과 함께 있어도 사용자가 고를 일이 없어요. 이렇게 드래그 없이 닫는 방법이 있다면 handle과 닫기 버튼을 함께 두는 건 과하다고 생각합니다.

언뜻 닫는 방법이 여러 개면 사용자의 선택지가 넓어지는 것처럼 보입니다. 하지만 handle과 닫기 버튼이 함께 있으면, 사용자는 시트를 열 때마다 두 단서 중 어느 쪽을 따를지 고르게 돼요. 시트에 따라 둘 다 있거나 하나만 있으면 혼란은 더 커지고요. 시트를 닫는 방법을 알리는 단서가 시트의 종류마다 하나로 정해져 있어야, 사용자는 그 프로덕트의 시트를 다루는 방식을 한 번 익히고 계속 믿을 수 있습니다.

두 시트를 비교한 그림. 왼쪽은 드래그로 닫을 수 있는 시트로, 맨 위에 handle만 있다. 오른쪽은 고정되어 있어서 드래그나 높이 조절을 할 수 없는 시트로, handle 없이 오른쪽 위에 닫기 버튼만 있다
드래그로 닫을 수 있는 시트와 고정되어 있어서 드래그나 높이 조절을 할 수 없는 시트. 어느 쪽이든 시트를 닫는 방법을 알리는 단서는 하나입니다.

드래그로 닫는 시트

고정 높이 시트

시트를 열고 직접 닫아 보세요. 왼쪽은 handle을 아래로 끌어 닫고, 위로 끌면 조금 따라오다 제자리로 돌아옵니다. 오른쪽은 닫기 버튼으로만 닫힙니다.

드래그로 닫히는 시트에는 handle만, 그렇지 않은 시트에는 닫기 버튼만 둡니다. 사용자는 시트를 보는 순간 하나의 단서로 닫는 방법을 파악해요.

드래그로 닫을 수 없는 시트#

드래그로 움직이는 시트라면, 드래그로 닫는 것까지 가능해야 합니다. 높이가 여러 단계인 시트도 마찬가지예요. 드래그할 때마다 한 단계씩 내려가다가, 가장 낮은 단계에서 한 번 더 드래그하면 닫히면 됩니다. 드래그에 반응하면서도 끝내 닫히지 않는 시트에서는, 사용자가 드래그를 시도해 본 뒤에야 닫기 버튼을 찾게 돼요.

드래그로 닫을 수 없는 시트는 기본으로 삼을 만한 선택은 아니라고 봅니다. handle이 없어도 사용자는 습관처럼 드래그하니, 아무 일도 일어나지 않으면 글 첫머리의 꿈쩍도 하지 않는 시트와 비슷한 실패예요. 드래그로 닫기를 차단해야 할 것 같은 경우도 대부분 다른 방법으로 해결됩니다. 작성 중인 내용이 있어 실수로 닫히면 곤란하다면, 차단하기보다 닫으려 할 때 한 번 더 확인을 받으면 됩니다. 내용 스크롤과 시트 드래그가 겹친다면, 내용이 맨 위에 닿기 전에는 내용만 스크롤되게 하면 되고요. 사용자가 반드시 답해야 하는 결정이라면, 시트보다 다이얼로그가 적합합니다.

이 방법들로도 해결되지 않는 분명한 이유가 있을 때만 드래그로 닫기를 차단합니다. 내용이 길어서 스크롤이 잦은 데다 실수로 닫히면 잃는 것이 큰 시트가 그렇습니다. 입력 요소가 많아 스크롤되는 작성 시트나 긴 약관을 읽고 동의하는 시트에서는, 내용을 맨 위까지 되돌린 뒤의 드래그를 스크롤 규칙으로는 막지 못하니까요. 그때는 드래그에 반응하지 않는, 높이가 고정되어 있는 시트로 만들고 handle 대신 닫기 버튼을 둡니다. 차단하는 건 드래그뿐이고, 배경 누르기로는 여전히 닫혀요. 드래그해도 닫히지 않는 시트에 handle을 두면, 사용자는 handle이 의미하는 동작을 실제로는 할 수 없으니까요.

닫기 버튼이 더 필요한 시트#

드래그로 닫을 수 있는 시트라도, 드래그 없이 닫는 방법이 마땅치 않으면 닫기 버튼이 필요합니다.

화면 대부분을 덮는 시트에서 이 문제가 두드러집니다. 나중에 읽을 글을 저장해 두는 한 앱은 화면 거의 전체를 덮는 시트를 띄웠는데, 이 시트는 드래그로만 닫혔다고 해요. handle이 화면 맨 위에 있다 보니 끌어내리려다 휴대폰의 알림 패널을 열기 쉬웠고, 제대로 잡아도 한참을 드래그해야 했고, 누를 배경도 거의 없었다고 해요. 화면 대부분을 덮는 시트는 페이지처럼 보여서, 사용자가 페이지의 관례대로 위쪽에서 닫기를 찾기도 해요. 가능하다면 처음 열리는 높이를 낮춰 누를 수 있는 배경을 남기는 것도 방법이에요.

웹에서는 사정이 조금 다릅니다. 브라우저의 뒤로 가기는 시트를 닫는 대신 이전 페이지로 이동하기 쉽고, 키보드로 화면을 다루는 사용자는 배경을 누를 수도 드래그할 수도 없어요. ESC 키로 닫히더라도 그 사실은 눈에 보이지 않고요. 그래서 웹의 시트에는 시트가 작아도 보이는 닫기 수단이 하나는 있어야 합니다.

어느 경우든 그 수단이 꼭 오른쪽 위의 닫기 버튼일 필요는 없습니다. 시트 아래쪽에 취소나 닫기 버튼이 있다면 그것으로 충분해요. 아래쪽 버튼은 엄지에 가까워 오른쪽 위의 닫기 버튼보다 누르기 쉽고, 거기에 닫기 버튼까지 더하면 닫는 신호가 handle, 취소, 닫기 버튼 셋이 됩니다. 아래쪽에 버튼이 없는 시트라면 그때 handle과 닫기 버튼을 함께 둡니다. 앞에서 단서는 하나만 보여 준다고 한 것과 부딪히지만, 저는 누구나 시트를 닫을 수 있어야 한다는 쪽이 먼저라고 봅니다. 결국 handle과 닫기 버튼을 함께 두는 건, 화면 대부분을 덮거나 웹에서 열리는데 아래쪽에 버튼이 없는 시트처럼 드래그 없이 닫는 방법이 눈에 보이지 않는 시트로 한정됩니다.

스크롤과 겹칠 때#

시트 전체를 드래그할 수 있게 되면서 생긴 문제도 있습니다. 시트 안의 내용이 길어서 스크롤되는 경우예요.

사용자가 시트 안에서 아래로 드래그했을 때, 이 동작이 지나온 내용으로 되돌아가는 스크롤인지 시트를 내리는 동작인지 모호해집니다. 보통은 내용이 맨 위에 닿은 뒤부터 시트가 내려가도록 처리하지만, 사용자는 그 경계를 정확히 알기 어려워요. 한 음악 학습 앱에서는 레슨 내용을 스크롤하던 사용자가 실수로 시트를 드래그해 닫는 바람에 홈 화면으로 돌아가 버린 사례도 있어요.

이런 시트에서는 handle 영역이 다시 '잡는 곳'의 역할을 합니다. 내용과 상관없이 시트만 움직이는 확실한 자리가 필요하기 때문이에요. 한 플랫폼 가이드는 handle이 있을 때 시트 위쪽 48dp 영역 전체를 조작 영역으로 두라고 합니다. 본래는 누르기 쉬운 크기를 확보하려는 목적이지만, 스크롤과 겹치지 않는 자리를 마련하는 효과도 있어요. 슬라이더나 지도처럼 끌어서 다루는 요소가 시트 안에 있다면, 그 요소 위에서 시작한 드래그는 스크롤 영역처럼 그 요소가 받고 나머지 영역을 끌 때만 시트가 내려오게 합니다. 그래도 스크롤이 길고 실수로 닫힐 때 잃는 것이 크면, 앞 장에서 말한 대로 드래그로 닫기를 차단하는 쪽이 맞습니다. 시트를 드래그로 닫히게 한 만큼, 실수로 닫히는 경우까지 함께 설계해야 합니다.

시트가 감당하는 정보의 양#

여기까지는 시트를 유지한다는 전제였습니다. 한 걸음 물러서면, 시트가 맞는 선택인지도 handle과 함께 정해야 해요. 정보가 많아서 시트를 최대 높이로 확장해야 한다면, 처음부터 전체 화면 페이지로 넘기는 게 낫지 않을까요?

그래야 할 것 같지만, iPhone의 메시지와 메일 앱에서 새 메시지나 메일을 작성하는 시트는 처음부터 거의 전체 높이로 열려요. 정보량이 많아도 시트를 유지한 건, 작성을 마치면 원래 화면으로 돌아간다는 시트의 성격이 그대로이기 때문이라고 봅니다.

반대의 사례도 있습니다. 한 쇼핑 앱은 상품 상세 화면을 시트로 열었는데, 그 안에서 리뷰를 누르면 시트 위에 시트가 또 쌓였다고 해요. 사용자는 뒤로 가기 버튼과 닫기 버튼 중 무엇을 눌러야 할지 헷갈리게 되죠. 문제의 핵심은 정보량보다 시트 안에서 다른 곳으로 이동한다는 점이었어요.

그래서 시트를 페이지로 넘길지는 정보의 양보다, 사용자가 시트 안에서 다른 화면으로 이동하는지, 아니면 작업을 마치고 원래 화면으로 돌아오는지로 판단합니다. 이 기준을 통과한 시트에 대해서만 handle을 고민하면 됩니다.

그래서 handle은 언제 둘까#

지금까지의 내용을 판단 순서로 정리하면 이렇습니다.

handle을 둘지 판단하는 순서. 시트 안에서 다른 화면으로 이동하면 페이지로 넘긴다. 드래그로 닫을 수 있는 시트가 기본이고, 높이와 상관없이 handle을 둔다. 드래그도 높이 조절도 안 되는 시트는 handle 없이 닫기 버튼을 둔다. 드래그 없이 닫는 방법이 눈에 보이지 않으면 닫기 버튼을 더한다. 내용이 스크롤되면 handle 영역을 시트만 움직이는 자리로 둔다. 닫는 방법의 단서는 되도록 하나만 보여 준다
handle을 둘지는 시트를 설계하는 마지막 단계의 질문입니다. 시트가 맞는 선택인지부터 묻습니다.

판단은 시트가 맞는 선택인지에서 시작합니다. 시트를 유지한다면 드래그로 닫히는 시트를 기본으로 두고, 닫는 방법을 알리는 단서는 handle 하나로 유지해요. 드래그로 닫기를 차단할 분명한 이유가 있을 때만 handle 대신 닫기 버튼을 두고, 둘을 함께 두는 건 드래그 없이 닫는 방법이 눈에 보이지 않는 시트뿐입니다.

남은 질문#

이 기준으로도 답하지 못한 것이 있습니다. 사용자가 handle을 실제로 '드래그로 닫을 수 있다'는 단서로 읽는지 정량적으로 확인한 연구는 찾지 못했어요. 이 해석은 여러 앱의 선택과 제 판단을 합친 것이고, handle을 높이 조절의 단서로 다루는 플랫폼 가이드와는 거리가 있습니다.

제가 디자인하고 있는 JDS(젝트 디자인 시스템)의 Sheet도 이 기준을 따릅니다. JDS의 시트는 높이를 조절하는 단계가 없어서 모두 높이가 고정되어 있는 시트인데, 아래에서 올라오는 시트는 기본으로 handle만 두고 드래그로 닫히게 했어요. 시트가 화면 대부분을 덮어도 같습니다. 드래그 없이 닫는 수단은 시트 아래쪽의 취소나 닫기 버튼이 맡고, 그 버튼이 없을 때만 오른쪽 위에 닫기 버튼을 함께 둡니다. 입력 요소가 많은 작성 시트나 긴 약관에 동의하는 시트처럼 드래그로 닫을 수 없게 한 고정형 시트에는 handle 없이 닫기 버튼만 두고요. JDS는 웹에서 사용하는 디자인 시스템이라 마우스로도 끌어서 닫히고, 배경 누르기와 ESC 키로도 닫힙니다.

다만 시트 아래쪽의 취소 버튼이 키보드 사용자에게 충분한 닫기 수단인지, handle만 있는 시트를 마우스 사용자가 드래그로 닫을 생각을 하는지는 아직 확인하지 못했습니다. 실제 사용자가 JDS의 시트를 다루는 모습을 지켜본 뒤에야 답할 수 있을 것 같아요.

참고 자료#