[6월 TIL #7] 작업 회고: Modal & Nonmodal Dialogs

이 글은 Nielsen Norman Group의 Modal & Nonmodal Dialogs: When & Why to Use Them을 읽고 정리한 공부 기록이다. 구체적인 컴포넌트 스펙이 아니라 "언제 모달을 쓰고 언제 피해야 하는가"라는 개념을 다루는 글이다. 앞쪽은 글의 내용을 위키처럼 정리했고, 뒤쪽 TIL에 왜 이걸 공부했는지를 덧붙였다.

---

다이얼로그란 무엇인가

다이얼로그(dialog)는 시스템과 사용자 사이의 '대화'다. 인터페이스가 사용자에게 정보나 행동을 요청하는 상호작용을 가리킨다. 우리가 흔히 '팝업'이나 '모달창'이라 부르는 것들이 대부분 여기 속한다.

NN/g는 이 다이얼로그를 크게 두 종류로 나눈다. 모달(modal)과 비모달(nonmodal)이다. 그리고 둘을 가르는 기준은 생김새가 아니라 "배경을 막느냐"라고 못박는다.

모달 vs 비모달

모달은 메인 콘텐츠 위에 떠서 시스템을 특별한 모드로 전환한다. 사용자가 그 다이얼로그와 명시적으로 상호작용하기 전까지 뒤의 콘텐츠를 비활성화한다. 보통 화면 중앙에 뜨고 배경은 어둡게 깔린다. "이걸 처리하기 전엔 아무것도 못 한다"는 상태를 만드는 것이다.

비모달(modeless)은 반대다. 배경을 막지 않는다. 다이얼로그가 떠 있어도 사용자는 뒤의 화면과 계속 상호작용할 수 있고, 그것을 옮기거나 무시한 채 하던 일을 이어갈 수 있다. 덜 침투적이고, 병렬 작업을 허용한다.

구분	모달 (Modal)	비모달 (Nonmodal)
배경	비활성화 (막음)	그대로 사용 가능
긴급성	즉시 처리해야 함	미뤄도 됨
작업 흐름	끊긴다	이어진다
닫기	처리해야 사라짐	무시할 수 있음

생김새가 아니라 '배경을 막느냐'가 모달과 비모달을 가른다.

➕ 추가로 알아본 것 — 팝업·다이얼로그·알림·모달, 뭐가 뭔지

공부하면서 가장 헷갈렸던 건 팝업, 다이얼로그, 알림, 모달/비모달이라는 말이었다. 비슷한 자리에서 섞여 쓰이니 위계가 잡히지 않았다. 정리해보니 이 넷은 한 줄로 줄세우는 위계가 아니라, 서로 다른 질문에 답하는 말이었다.

용어	답하는 질문	뜻
팝업 (오버레이)	어떻게 보이나 (형태)	화면 위에 떠서 나타나는 것의 느슨한 통칭
다이얼로그	무엇을 하나 (역할)	정보·행동을 '요청'하는 대화 (응답이 필요)
알림 (notification)	무엇을 하나 (역할)	그냥 '알려주는' 메시지 (응답은 선택)
모달 / 비모달	배경을 막나 (동작)	막으면 모달, 안 막으면 비모달

그래서 헷갈렸던 거였다. 넷은 각각 '어떻게 보이나', '무엇을 하나', '배경을 막나'라는 다른 질문에 답한다. 덕분에 한 대상이 라벨을 여러 개 동시에 가진다. 예를 들어 삭제 확인창은 팝업(형태)이면서 다이얼로그(역할)이면서 모달(동작)이다. 토스트는 팝업(형태)이면서 알림(역할)이면서 비모달(동작)이다.

이렇게 갈라 두면 실무 판단도 또렷해진다. 가르는 기준은 '버튼이 있느냐'가 아니라 '응답이 필수냐'다. 토스트에 닫기(×)나 '실행 취소' 같은 버튼이 달려 있어도, 그건 눌러도 되고 말아도 되는 선택지일 뿐 꼭 응답해야 하는 것은 아니다(버튼 하나가 붙은 형태를 따로 스낵바라 부르기도 한다). 반면 모달은 응답하지 않으면 진행이 막힌다. 게다가 토스트는 배경도 안 막고 잠깐 떴다 사라져서 놓치기 쉽다. NN/g는 사라지는 토스트 에러를 못 본 사용자가 5분간 로딩을 기다린 사례를 든다. 그래서 꼭 처리해야 하는 정보나 에러는 모달, 응답을 강요하지 않고 알려주기만 하면 되는 것은 토스트다.

추가로 참고한 글: Nielsen Norman Group, Indicators, Validations, and Notifications · Modal & Nonmodal Dialogs

모달은 공짜가 아니다

모달은 강력한 만큼 비용이 크다. NN/g는 모달이 사용자 경험에 지우는 부담을 이렇게 정리한다.

• 강제된 주의: 본질적으로 강제적이라, 사용자가 즉시 반응하도록 만든다.
• 작업 흐름 중단: 원래 하던 일에서 사용자를 끌어낸다.
• 맥락 상실: 인지 부담 때문에 원래 작업의 세부를 잊게 만든다.
• 상호작용 비용 증가: 읽고, 이해하고, 결정해야 비로소 일로 돌아갈 수 있다.
• 콘텐츠 가림: 중요한 내용을 덮어 맥락을 없애서, 오히려 정확한 판단을 어렵게 한다.

그래서 모달은 '기본값'이 될 수 없다. 흐름을 끊을 만큼의 값어치가 있을 때만 꺼내는 도구다.

그래서, 언제 모달을 쓰나

NN/g는 모달이 정당화되는 경우를 이렇게 본다.

• 되돌리기 어려운 치명적 에러를 막을 때. 저장하지 않은 작업, 파일 덮어쓰기 경고 같은 것.
• 지금 이 작업을 계속하려면 반드시 필요한 정보를 받아야 할 때. 결제 도중의 로그인 같은 것.
• 복잡한 작업을 단계로 쪼갤 때. 위저드처럼. 단, 여러 단계라면 진행 표시기를 함께 보여줘야 한다.
• 사용자의 수고를 크게 덜어줄 수 있는 고가치 정보일 때.
• 결과가 되돌릴 수 없고 정보 손실로 이어질 때.

반대로 다음 경우엔 피하라고 말한다.

• 현재 흐름과 무관한 비필수 정보. 대표적인 게 이메일 뉴스레터 가입 모달인데, 사용자들이 본능적으로 싫어한다고까지 표현한다.
• 결제처럼 집중이 필요한 흐름을 끊는 것. 사용자를 흩트리거나 신뢰를 깎는다.
• 모달 안에 없는 추가 정보가 있어야 내릴 수 있는 결정. 좌석 현황도 모르는데 좌석 업그레이드를 결정하라는 식.

한 줄로 남는 원칙

NN/g가 글을 닫는 문장이 이 주제를 한 줄로 요약한다.

"아무도 방해받는 걸 좋아하지 않는다. 그래도 꼭 해야 한다면, 그 비용만큼 값어치가 있는지 확인하라."
No one likes to be interrupted, but if you must, make sure it's worth the cost.

모달을 쓸지 말지 고민될 때 이 한 문장이면 충분하다. "이 인터럽트는 사용자가 치르는 비용만큼의 값을 하는가?"

---

TIL — 왜 이걸 공부했는가

검토하다 생긴 찜찜함, 그리고 '모달을 의심하는 눈'

우리 제품에 새 기능들이 들어오면서, 개발자분이 모달을 넣어주는 경우가 늘었다. UX/UI를 검토하면서 매번 비슷한 질문이 떠올랐다. 이 상황에 꼭 모달이어야 할까. 이 모달 구성이 최선일까. 문제는 그 질문에 답할 내 기준이 또렷하지 않았다는 점이다. 찜찜하긴 한데 더 나은 안을 자신 있게 제시하기는 모호했고, 시간도 촉박했다. 그래서 큰 변경 없이 간단히만 다듬어서 넘기곤 했다.


이 글을 읽고 나니 그 찜찜함의 정체가 분명해졌다. 모달은 본질적으로 사용자의 흐름을 끊고 행동을 강제하는, 비용이 큰 도구다. 우리는 의도를 갖고 쓴다고 느끼지만, "의도가 있다"와 "모달이 최선이다"는 다른 이야기다. 그래서 검토할 때 던질 질문이 생겼다. 이건 흐름을 끊을 만큼 값어치가 있나. 비모달이나 인라인으로 같은 목적을 이룰 수는 없나. 대안을 알고 있어야 "모달 말고 이렇게요"라고 말할 수 있다. 그 대안의 목록을 갖추는 것이 지금 나에게 필요한 '눈'이다. 돌아보면 위에서 팝업·다이얼로그·알림·모달 같은 용어를 정리한 것도 그 목록의 첫 조각이었다. 떠 있는 것들이 무엇이고 어떻게 갈리는지 구조가 한번 잡히니, "모달 말고 이렇게요"의 '이렇게'를 조금은 구체적으로 댈 수 있게 됐다.

다음 공부, 그리고 메모

이 글은 스펙이 아니라 개념을 다뤄서 지금 목적에 잘 맞았다. 다만 '언제 쓰나'를 넘어, 모달을 쓰기로 했을 때 그 안을 어떻게 구성하는가까지 봐야 한다. 제목과 본문, 액션 버튼의 위치와 문구, 닫기 방식 같은 구성 요소를 뜯어보는 공부가 다음 차례다.

그리고 메모로 Atlassian Design System의 Inline message를 남겨둔다. 모달 뿐만 아니라, 양질의 경험을 위한 의사 결정의 집합으로서 디자인 시스템이 도출 되었고 그것을 코드화해서 정리된 모습을 보니까 궁극적인 이상향이라는 생각이 들었다. 굿..!