모달(Modal) vs. 별도 페이지: UX 의사결정 트리

아마 여러분도 이런 경험이 있을 것입니다. 사용자에게 모달(Modal)을 보여줄지, 아니면 별도의 새로운 페이지로 이동시킬지 어떻게 선택해야 할까요? 그리고 이것이 정말 중요할까요?

사실, 매우 중요합니다. 이 결정은 사용자의 흐름(flow), 맥락(context), 세부 정보를 찾아보는 능력, 그리고 그에 따른 **오류 빈도와 작업 완료(task completion)**에 영향을 미칩니다. 두 옵션 모두 잘못된 시점과 잘못된 장소에서 사용된다면 흐름을 방해하고 좌절감을 줄 수 있습니다.

따라서 올바르게 결정하는 것이 좋습니다. 그럼 어떻게 하면 좋을지 알아봅시다.

모달(Modals) vs. 다이얼로그(Dialogs) vs. 오버레이(Overlays) vs. 라이트박스(Lightboxes)

우리는 흔히 단일한 모달 UI 컴포넌트에 대해 이야기하지만, 다양한 유형의 모달 사이에 존재하는 미세하고 복잡한 뉘앙스는 무시하곤 합니다. 사실, 모든 모달이 동일한 것은 아닙니다. 모달(Modals), 다이얼로그(Dialogs), 오버레이(Overlays), 라이트박스(Lightboxes)는 모두 비슷하게 들리지만, 실제로는 상당히 다릅니다:

다이얼로그 (Dialog)
"대화" (사용자 ↔ 시스템)를 뜻하는 일반적인 용어입니다.
오버레이 (Overlay)
페이지 위에 표시되는 작은 콘텐츠 패널입니다.
모달 (Modal)
사용자가 오버레이와 상호작용해야 하며, 배경은 **비활성화(disabled)**됩니다.
논모달 (Nonmodal)
사용자가 오버레이와 상호작용할 수 있으며, 배경은 **활성화(enabled)**된 상태입니다.
라이트박스 (Lightbox)
모달에 주의를 집중시키기 위해 배경을 어둡게 처리한 형태입니다.

Anna Kaley가 강조했듯이, 대부분의 오버레이는 잘못된 시점에 나타나고, 중요한 작업 중에 사용자를 방해하며, 부적절한 언어를 사용하고, 사용자의 흐름을 끊습니다. 오버레이는 **본질적으로 방해적(interruptive)**이며, 강력한 필요성 없이도 일반적으로 높은 수준의 심각성을 동반합니다.

사용자의 행동 결과가 큰 영향을 미치는 경우에는 분명히 사용자의 속도를 늦추고 방해해야 하겠지만, 대부분의 시나리오에서는 논모달(non-modals)이 훨씬 더 미묘하며 사용자에게 무언가를 알리기에 더 친화적인 옵션입니다. 저는 무엇보다도 이것을 **기본값(default)**으로 사용할 것을 항상 권장합니다.

모달(Modals) → 단일하고 독립적인 작업을 위한 용도

디자이너로서 우리는 종종 모달(Modals)을 무관하고 짜증 나는 요소로 치부하곤 합니다. — 실제로 그런 경우도 많지만요! — 그럼에도 모달은 나름의 가치를 지니고 있습니다. 모달은 사용자에게 잠재적인 실수를 경고하거나 데이터 손실을 방지하도록 돕는 데 매우 유용할 수 있습니다. 또한 현재 페이지의 상태를 방해하지 않으면서 관련 작업을 수행하거나 세부 사항을 자세히 살펴보는(drill down) 데 도움을 줄 수 있습니다.

하지만 모달의 가장 큰 장점은 사용자가 현재 화면의 컨텍스트(context)를 유지할 수 있도록 돕는다는 점입니다. 이는 단순히 UI뿐만 아니라, 수정된 입력값, 스크롤 위치, 아코디언(accordions)의 상태, 필터 선택, 정렬 상태 등을 모두 포함합니다.

때때로 사용자들은 선택 사항을 빠르게 확인하고(예: 위에서 보여준 필터) 즉시 그 지점부터 작업을 진행해야 할 때가 있습니다. 물론 자동 저장(Auto-save) 기능이 동일한 목적을 달성할 수 있지만, 항상 필요하거나 원하는 방식은 아닙니다. 또한 UI를 차단(blocking)하는 것은 종종 좋은 아이디어가 아닙니다.

하지만 모달이 모든 작업에 사용되는 것은 아닙니다. 일반적으로 우리는 사용자가 뛰어들어 작업을 완료한 후 원래 있던 곳으로 돌아와야 하는 **단일하고 독립적인 작업(single, self-contained tasks)**을 위해 모달을 사용합니다. 당연하게도, 모달은 우선순위가 높고 짧은 상호작용(예: 알림(alerts), 파괴적인 작업(destructive actions), 빠른 확인)에 효과적입니다.

모달이 도움이 되는 경우:

🚫 모달은 종종 흐름을 방해하고, 침해적이며, 혼란을 줍니다.
🚫 비교하거나 복사하여 붙여넣기(copy-paste)를 어렵게 만듭니다.
✅ 하지만 모달은 사용자가 여러 컨텍스트를 유지할 수 있게 해줍니다.
✅ 되돌릴 수 없는 오류와 데이터 손실을 방지하는 데 유용합니다.
✅ 사용자를 새로운 페이지로 보내는 것이 흐름을 끊는 일이라면 유용합니다.

✅ 사용자가 그 방해를 가치 있게 여길 때만 모달을 표시하세요.
✅ 기본적으로는 차단하지 않는 대화 상자(“nonmodals”)를 선호하세요.
✅ 사용자가 나중에 대화 상자를 최소화, 숨기기 또는 복구할 수 있도록 하세요.
✅ 복잡한 입력을 검증하는 등 사용자의 속도를 늦춰야 할 때 모달을 사용하세요.
✅ “닫기(Close)”, ESC 키, 또는 박스 바깥 영역 클릭을 통해 빠져나갈 방법을 제공하세요.

페이지(Pages) → 복잡하고 다단계인 워크플로(Multi-Step Workflows)를 위한 용도

위저드(Wizards)나 **모달(Modals) 내의 탭 탐색(Tabbed Navigation)**은 복잡한 엔터프라이즈 제품(Enterprise Products)에서도 그리 잘 작동하지 않습니다. 그런 경우에는 일반적으로 사이드 패널(Side Panels)이나 드로어(Drawers)가 더 효과적입니다. 사용자가 데이터 포인트(Data Points)를 비교하거나 참조해야 할 때 문제가 발생하기 시작하는데, 모달은 이러한 동작을 차단하기 때문에 사용자는 대신 동일한 페이지를 여러 탭에 다시 열게 됩니다.

더 복잡한 흐름(Flows)과 다단계 프로세스(Multi-step Processes)의 경우, 독립된 페이지(Standalone Pages)가 가장 효과적입니다. 또한 페이지는 사용자의 완전한 주의(Full Attention)를 요구하거나, 이전 화면을 참조하는 것이 별로 도움이 되지 않을 때 더 잘 작동합니다. 그리고 드로어(Drawers)는 단순한 모달로 처리하기에는 너무 복잡하지만, 전체 페이지 탐색(Page Navigation)까지는 필요하지 않은 하위 작업(Sub-tasks)에 적합합니다.

모달을 피해야 할 때:

🚫 **에러 메시지(Error Messages)**를 위한 모달은 피하세요.
🚫 **기능 알림(Feature Notifications)**을 위한 모달은 피하세요.
🚫 **온보딩 경험(Onboarding Experience)**을 위한 모달은 피하세요.
🚫 복잡하고 **길고 단계가 많은 작업(Lengthy Multi-step Tasks)**을 위한 모달은 피하세요.
🚫 **중첩된 여러 개의 모달(Multiple Nested Modals)**을 피하고, 대신 이전/다음(Prev/Next) 방식을 사용하세요.
🚫 절대적으로 필요한 경우가 아니라면 **자동으로 트리거되는 모달(Auto-triggered Modals)**은 피하세요.

반복적인 작업의 경우 둘 다 피하세요

작업량이 많은 많은 복잡한 제품에서 사용자는 동일한 작업을 반복해서 수행하게 됩니다. 이 경우 모달과 새로운 페이지 탐색(Page Navigations) 모두 마찰(Friction)을 유발하는데, 이는 흐름을 방해하거나 사용자가 서로 다른 모든 탭이나 뷰(Views) 사이에서 누락된 데이터를 수집하도록 강요하기 때문입니다.

너무 자주, 사용자는 끝없는 확인창, 과장된 경고, 장황한 지침, 또는 참조할 지점의 부재로 가득 찬 망가진 경험을 하게 됩니다. Saulius Stebulis가 언급했듯이, 이러한 시나리오에서는 **확장 가능한 섹션(Expandable Sections)**이나 **인플레이스 편집(In-place Editing)**이 종종 더 효과적입니다. 이러한 방식은 작업을 현재 화면에 고정된 상태로 유지해 줍니다.

실제로 많은 시나리오에서 사용자들은 고립된 상태로 작업을 완료하지 않습니다. 작업을 수행하는 동안 데이터를 찾아보거나, 값을 복사하여 붙여넣거나, 여러 곳에 흩어진 항목을 수정하거나, 혹은 단순히 유사한 기록을 검토해야 할 필요가 있습니다.

오버레이 (Overlay)와 드로어 (Drawer)는 작업 중에 배경 데이터에 대한 접근성을 유지하는 데 더 유용합니다. 결과적으로 컨텍스트 (Context)가 항상 제자리에 유지되어 참조하거나 복사하여 붙여넣을 수 있습니다. 모달 (Modal)과 페이지 이동 (Page navigation)은 중단이 진정으로 가치를 더하는 순간, 특히 치명적인 실수를 방지해야 하는 순간을 위해 아껴두세요.

모달 (Modals) vs. 페이지 (Pages): 의사결정 트리

얼마 전, Ryan Neufeld는 디자이너들이 모달과 페이지 중 무엇을 선택할지 돕기 위해 매우 유용한 가이드를 정리했습니다. 이 가이드에는 유용한 PNG 치트 시트 (Cheatsheet)와 7개 섹션에 걸쳐 질문이 세분화된 Google Doc 템플릿이 포함되어 있습니다.

내용이 길고 매우 철저하지만, 따라하기 매우 쉽습니다:

다소 위압적으로 보일 수 있지만, 이는 꽤 간단한 4단계 프로세스입니다:

화면의 컨텍스트 (Context of the screen).
먼저, 사용자가 하위 화면의 컨텍스트를 유지해야 하는지 확인합니다.
작업의 복잡도 및 소요 시간 (Task complexity and duration).
단순하고 집중적이며 주의를 분산시키지 않는 작업에는 모달을 사용할 수 있지만, 길고 복잡한 흐름에는 페이지가 필요합니다.
하위 페이지 참조 여부 (Reference to underlying page).
그 다음, 사용자가 배경의 데이터를 자주 참조해야 하는지, 아니면 작업이 단순한 확인이나 선택인지 확인합니다.
적절한 오버레이 선택 (Choosing the right overlay).
마지막으로, 오버레이가 실제로 좋은 옵션이라면, 모달 (Modal)과 비모달 (Nonmodal) 중 무엇을 선택할지(비모달 쪽으로 기울어짐) 안내합니다.

마치며

가능한 한 전체 UI를 차단하는 것을 피하십시오. 대화 상자 (Dialog)가 UI 위에 떠서 일부를 가리되, 탐색 (Navigation), 스크롤 (Scrolling), 그리고 복사 및 붙여넣기 (Copy-pasting)가 가능하도록 만드십시오. 또는 모달 (Modal)의 내용을 사이드 드로어 (Side drawer)로 보여주거나, 대신 수직 아코디언 (Vertical accordion)을 사용할 수도 있습니다. 만약 아주 많은 세부 정보를 보여줘야 한다면 사용자를 별도의 페이지로 안내하십시오.

하지만 사용자의 효율성과 속도를 높이고 싶다면, 어떤 대가를 치르더라도 모달 (Modal)을 피하십시오. 모달은 사용자의 속도를 늦추거나, 주의력을 집중시키거나, 실수를 방지하기 위한 용도로만 사용하십시오. Therese Fessenden이 언급했듯이, 누구도 방해받는 것을 좋아하지 않지만, 만약 방해해야 한다면 그만한 가치가 반드시 있어야 합니다.

“Smart Interface Design Patterns”를 만나보세요

Smart Interface Design Patterns에서 모달 (Modal)과 그 대안에 관한 전체 섹션을 확인하실 수 있습니다. 이 과정은 실제 프로젝트에서 추출한 수백 개의 실무 사례를 담은 15시간 분량의 비디오 코스이며, 올해 말에 라이브 UX 트레이닝 (Live UX training)도 진행됩니다. 메가 드롭다운 (Mega-dropdowns)부터 복잡한 엔터프라이즈 테이블 (Enterprise tables)까지 모든 것을 다루며, 매년 5개의 새로운 세그먼트가 추가됩니다.