[더 나은 서비스를 위한 고민] 모달.. 어떻게 사용해야할까?

2015년부터 2021년까지 에이전시를 운영하거나 자사 서비스를 기획/개발하며 여러 서비스를 만들어본 것 같습니다. 
여러 서비스들을 만들어보면서 다른 서비스들을 벤치마킹하다보니 여러 가지를 배우고 느끼고 고민해보게 되었는데 
제가 고민했던 것 중 이번엔 모달(Modal)에 대해서 저의 개인적인 생각을 말씀드리고 적절한 구성 방법 등을 알아보며 여러분들의 다양한 의견을 나누고 고민해보려고 합니다.

 

1. 모달(Modal)의 개념

모달(Modal)은 사용자의 이목을 끌기 위해 사용하는 화면전환 기법을 의미합니다. 

모달 창이 팝업창과 다른 차이점은 기존의 브라우저 페이지 위에 새로운 윈도 창을 띄우는 팝업창과는 
다르게 현재 띄워져있는 화면에 또 하나의 레이어를 까는 것입니다. 

기존의 팝업창은 띄워놓으면 닫기 위해 꼭 X 버튼을 눌러야 닫아지지만 모달 창은 dim 영역을 누르거나 닫기 버튼을 누르면 닫을 수 있다는 것이 좀 더 사용자가 사용하기 편하게 만들어주죠. 또한 모달이 뜨는 동시에 백그라운드 화면이 어두워지거나 밝아지는데, 이를 ‘라이트 박스’라고 합니다.  

 

팝업창보다 더욱 새로운 레이어에 대해 강조하여 보여줄 수 있으며 컨텐츠에 대한 집중도도 높일 수 있습니다.
보통 모달창은 간단한 입력 폼이나 컨트롤 폼, 강조하고자 하는 컨텐츠를 보여주기 위해 사용됩니다.

하지만 잘못된 모달 사용은 오히려 사용자를 집중시키기보다는 사용자의 행동 흐름을 막거나 사용자 경험을 떨어뜨리게 만들기도 하는데요.

그럼 어떻게 모달을 적절하게 잘 활용할 수 있을까요?

 

 

2. 모달(Modal)은 주의해서 사용해야 한다

 

저도 항상 기획이나 개발을 하다보면 ‘모달로 처리해볼까?’라는 생각을 많이 하게 됩니다. 
그러다보니 적절하지 않은 부분에서 모달을 처리하는 경우가 종종 발생하여 서비스 기능이 확장되거나 변경되었을 때 
모달이 중첩되어 뜬다던지 레이아웃 구성에 어려움을 겪는다던지 링크 공유 같은 부분에서 어려움을 겪는 등등 다양한 문제점에 부딪히곤 하였습니다. 

 

‘페이지를 따로 분리해야할 거 같긴 한데 그러기엔 너무 들어갈 레이아웃이 단순하고.. 내용도 많지 않은데… 그냥 모달로 띄울까?’라는 생각에 그냥 모달로 띄우거나 하는 경우가 많이 있었죠. 또 '개발할때 모달 처리가 페이지를 하나 더 만드는 것보다 공수가 더 적게 들지 않을까?' 라고 생각하는 경우도 많은 것 같습니다.

 

---

‘페이지를 따로 분리해야 할 거 같긴 한데 그러기엔 너무 들어갈 레이아웃이 단순하고.. 내용도 많지 않은데… 그냥 모달로 띄울까?’

 

먼저 분명 분리되어 독립적인 페이지가 있어야 할 거 같은데 레이아웃이나 들어갈 내용이 비교적 단순하다는 이유로 모달로 처리한다는 것은 장기적으로 다양한 문제점을 나을 수 있습니다.

 

가령 우리가 어떤 교육 플랫폼에 들어가서 마음에 드는 교육 컨텐츠 썸네일이 보여 클릭했을 경우 모달로 해당 교육 컨텐츠 내용을 보여줬다고 가정해본다면 다른 친구에게 이 교육 컨텐츠를 공유하여 보여줄 수 있을까요?

 

음.. 개발자에게 해당 기능을 넣어달라고 요청 한다면 가능은 할 겁니다.
하지만 개발 소스는 예외처리가 많아질 거고 점점 이러한 모달이

많아지면 유지보수가 힘들어질 수도 있을 겁니다.
이렇게 되면 알 수 없는 사이드 이펙트(부작용)가 생겨날 수도 있고 그것을 고치기 위해 소스 복잡도는 더 올라갈 수도 있을 겁니다.

 

 

또한 어떤 교육 컨텐츠가 더 많이 보여 졌고 유저들이 얼마나 관심 있게 해당 컨텐츠를 보았는지, 스크롤이 된다면 화면 어느 부분에서 관심을 많이 가지는지 다양한 데이터를 트래킹 하는데도 어려움이 있을 수 있으며 이를 트래킹 하려면 페이지를 빼는 것보다 더 많은 공수가 들어갈 수도 있겠죠.

 

---

'개발할 때 모달 처리가 페이지를 하나 더 만드는 것보다 공수가 더 적게 들지 않을까?'

 

모달 창 안에 들어가는 화면 구성도 똑같은 화면이고 페이지 또한 화면입니다. 어느 정도에 공수 차이가 있긴 하겠지만 ‘큰 차이가 없다’ 라는 것이 제가 개발을 해왔을 때의 생각입니다. 사실 개발자가 힘들어야 좋은 서비스가 나온다는 말도…

 

추가적으로 FE개발자로서의 견해를 살짝 더한다면 모달 사용이 너무 잦아지면 어느 페이지에 어떠한 모달이 사용되는지 어떤 모달 컴포넌트들이 존재하는지 파악이 어려워지는 문제점도 있습니다. 독립적이며 중요한 기능을 하는 화면은 모달보다는 페이지로 빼는게 좀 더 효율적인 유지보수를 위해 더 좋을 수도 있을거 같다는 것이 개발자로써의 의견이기도 하겠네요. 물론 무분별하게 페이지를 생산해내는 것이 좋은 것은 아니긴 하지만요..^^

 

---

'사용자 경험에 좋지 않은 것은 결국 유저 이탈로 이어진다'

 

또 다른 경우로는 복잡한 입력 폼이나 컨트롤 폼 등을 모달로 처리한다면 부가적인 모달을 중첩하여 띄워줘야 할 수도 있고 뒤로 가기에 대한 처리가 이루어지지 않은 모달에서는 실수로 (특히 모바일에서) 뒤로 가기를 눌렀을 경우 모달 창만 닫히는 게 아닌 페이지 자체가 이동되어 버릴 수도 있습니다.

 

이는 바로 사용자 이탈률(Bounce Rate)에 큰 영향을 줄 수도 있을 겁니다.

 

이런 유저 이탈을 막기 위해 모달을 기획/개발할 때 모달이 열려있는 상태에서 뒤로 가기 처리는 상당히 중요합니다.
PC 화면을 개발하다 보면 모달이 열렸을 때 뒤로 가기를 누를 경우는 별로 없습니다.
그냥 닫기 버튼을 누르거나 dim영역을 눌러 모달을 닫는 게 더욱 편하니까요.

 

하지만 Mobile에서는 유저의 행동은 확연히 다릅니다.

유저는 '지금 나에게 보이는 화면이 모달이구나~ 그럼 이걸 닫으려면 닫기 버튼을 눌러야겠구나~'라고 생각하지 않으며 무의식적으로 모달 창을 닫기 위해 뒤로 가기 버튼을 누르거나 아이폰의 경우 swipe를 하곤 하죠.

 

페이지 이동에 영향을 받는 모달 창은 모달이 아닌 페이지로 빼는 것이 가장 좋긴 하지만 더욱 나은 사용자 경험을 위해 모달을 기획/개발할 때 뒤로 가기에 대한 처리는 제가 이제껏 서비스를 만들 때 정말 중요하다고 느꼈던 부분입니다.

 

 

3. 다양한 모달 가이드와 모달 여부 의사결정 방법

3-1. 구글 개발 가이드 MATERIAL DESIGN ‘DIALOGS’

구글의 개발 가이드인 Material Design에서는 ‘Dialog’라는 요소로 모달 사용을 정리합니다.
Dialog는 사용자에게 작업에 대해 알리고 중요한 정보를 포함하거나, 결정을 요구하는 등 여러 작업을 포함할 수 있습니다.

 

이용 방법은 다음과 같습니다.

 

1. Focused (사용자 주의를 집중하여 해당 내용이 처리되도록 합니다.)

2. Direct (정보를 전달하고 직무를 완수하는데 전념해야 합니다.)

3. Helpful (관련 작업 또는 상황 별 정보와 함께 사용자 작업 또는 작업에 대한 응답으로 나타나야 합니다.)

[출처 : https://material.io/components/dialogs#usage]

 

 

3-2. 애플 HUMAN INTERFACE GUIDELINES ‘MODALITY’

 

1. Minimize the use of modality (사용을 최소화한다.)

2. Provide an obvious and safe way to exit a modal task. (작업을 종료할 수 있는 명확하고 안전한 방법을 제공한다.)

3. Keep modal tasks simple, short, and narrowly focused. (단순하고, 짧고, 좁은 곳에 집중하도록 한다.)

4. Display a title that identifies a task, if necessary. (필요한 경우 작업을 식별하는 제목을 표시한다.)

5. Reserve alerts for delivering essential—and ideally actionable—information. (이상적으로 행동 가능한 정보를 제공하기 위한 경고를 준비한다.)

6. Respect notification preferences. (알림 환경 설정을 존중한다.)

7. Don’t display a modal view above a popover. (팝오버 위에 모달 뷰를 표시하지 않는다.)

[출처 : https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/modality]

 

 

 

3-3. Modal & Page 결정

모달 구성 방법을 알아보기 위해 우선 Modal과 Non-Modal, 라이트박스에 대해 좀 더 정리해보겠습니다.

 

Modal과 Non-Modal의 차이는 모달을 띄운 페이지를 모달이 열려있는 상태에서도 조작이 가능한가 가능하지 않은가의 차이 입니다.

 

레벨업지지(lvup.gg)에서 Notification 모달 창이나 채팅 모달 창을 열어도 뒤에 있는 페이지를 조작할 수 있습니다.
이를 바로 Non-Modal이라고 하며 조작하지 못하는 그 외에 모달을 Modal이라고 합니다.

 

** 토스트 메시지, 스낵바 등도 Non-Modal의 종류로 포함됩니다.

 

 

 

그럼 어떨 때 Non-Modal로 해야 하는지 어떨때 Modal로 해야하는지 아니면 Page로 처리해야 하는지 어떤 기준으로 정리를 할 수 있을까요?

솔직히 말한다면 저 또한 저의 경험이나 주관적인 생각을 기반으로 결정을 많이 하였는데요.
UX Planet에서 이 의사결정 프레임웍을 정리한 자료를 번역을 하여 다시 한번 정리한 좋은 자료가 있어서 가져와 보았습니다!

 

[출처 : https://tech.toktokhan.dev/2021/07/21/about-modal/]

 

해당 포스트에서도 말하고 있지만 무조건 이대로 따라야 한다는 건 아닙니다.

하지만 이 의사결정 프레임웍을 기반으로 Modal/Non-Modal/Page 여부를 결정하는데 어느 정도 기준을 세우면서 실무에 적용한다면 더 완성도가 높은 서비스가 만들어지지 않을까 생각이 됩니다.

 

 

---

 

처음에는 모달과 토스트, 다이얼로그에 대해 글을 적어보려고 하였는데 적다 보니 '사실 이 모든 게 모달이겠구나..' 라는 생각을 하면서 모달에 대해 중점적으로 글을 적었던 거 같습니다.

 

개인적으로 이러한 주제를 선택하게 된 이유는 기술 중심의 포스트보다는 기획/디자인/개발 모두 함께 우리가 만들고 있는 서비스에 대해 부족한 부분이 있는지 더 함께 고민해보고 더 나은 UX와 완성도 높은 서비스를 만들어가는데 필요한 포스트를 써보는 게 어떨까 라는 생각이 들어서 FE개발자로서 또는 예전 기획과 개발을 같이 하였던 경험과 개인적인 견해를 담아 조금이라도 도움이 되고 싶어 다소 포괄적인 주제를 선택하게 되었습니다.

 

원래 이런 포스트를 잘 작성하지 않아서 부족함이 많은 포스트일 수 있습니다... ㅠㅠ
그래도 재밌게 봐주시고 잘못된 내용이나 피드백이 있으시다면 얼마든지 말씀 부탁드리겠습니다!!