모달

화면에는 되돌릴 수 없는 동작이 섞여 있습니다. 문서를 지우는 일, 팀에서 사람을 내보내는 일, 결제를 확정하는 일이 그렇습니다. 이런 동작도 다른 동작과 똑같이 버튼 하나로 실행되기 때문에, 손이 미끄러지거나 옆 버튼을 잘못 누르면 그대로 일어납니다.

같은 화면 안에 안내 문구를 넣는 방법이 먼저 나왔습니다. 버튼 아래에 "이 동작은 되돌릴 수 없습니다" 라고 적어 두는 식입니다. 잘 듣지 않았습니다. 사용자는 자기가 하려는 것에 눈이 가 있어서 그 주변 문장을 읽지 않고, 읽었더라도 버튼을 누르는 동작은 이미 손에 붙어 있습니다.

페이지덱에서도 같은 일이 있었습니다. 문서 목록에서 더 보기를 누르면 이름 바꾸기 아래에 삭제가 붙어 있었는데, 한 달 동안 삭제 문의가 열한 건 들어왔습니다. 대부분 "이름을 바꾸려다 지웠다" 였습니다. 문구를 굵게 바꾸고 삭제를 빨간색으로 만들어도 숫자는 거의 줄지 않았습니다.

모달은 문구 대신 흐름을 끊는 쪽을 택한 방법입니다. 뒤 화면을 덮어 버리고 창 하나만 남겨서, 예 또는 아니오를 답하기 전에는 아무것도 못 하게 만듭니다. 막는 것 자체가 목적이고, 그래서 막을 만한 자리에만 씁니다.

화면 위에 두 겹을 얹어 만듭니다. 아래는 뒤를 덮는 반투명 막이고 위는 내용을 담은 창입니다. 이 둘이 제대로 동작하려면 다섯 가지가 함께 붙습니다.

1. 덮는 막 — 뒤를 어둡게 만들어 시선을 앞으로 모으고, 동시에 뒤쪽의 모든 누르기를 가로챕니다. 어둡게만 하고 누르기를 막지 않으면 사용자가 뒤 버튼을 눌러 두 화면이 동시에 반응합니다.
2. 초점 가두기 — 키보드 탭 키로 이동할 수 있는 범위를 모달 안으로 제한합니다. 이게 없으면 탭을 누를 때마다 보이지 않는 뒤 화면의 버튼으로 초점이 넘어가고, 화면을 읽어 주는 프로그램을 쓰는 사용자는 지금 무엇이 떠 있는지조차 모릅니다. 접근성에서 모달이 자주 지적받는 자리가 여기입니다.
3. 닫는 길 — 닫기 버튼, Esc 키, 막 누르기 셋이 기본입니다. 다만 되돌릴 수 없는 결정에서는 막 누르기를 일부러 막아 둡니다. 실수로 옆을 눌러 창이 닫히면 앞에서 끊은 흐름이 도로 이어집니다.
4. 뒤 화면 잠금 — 모달이 떠 있는 동안 뒤 화면의 스크롤을 멈춥니다. 잠그지 않으면 창 위에서 손가락을 움직였을 때 뒤 목록이 흘러가서, 닫고 나면 아까 보던 자리를 잃습니다.
5. 초점 되돌리기 — 닫을 때 처음 눌렀던 버튼으로 초점을 돌려 놓습니다. 키보드만 쓰는 사용자가 목록 맨 위로 튕겨 가지 않게 하는 마무리입니다.

세 자리에 씁니다. 공통점은 지금 답하지 않으면 다음 단계가 없다는 것입니다.

1. 되돌릴 수 없는 동작의 확인 — 삭제, 내보내기, 결제 확정이 여기 들어갑니다. 확인 창에는 무엇이 지워지는지를 그대로 적습니다. "정말 삭제할까요" 보다 "문서 12건을 삭제합니다" 가 사람을 멈추게 합니다.
2. 흐름을 끊고 받아야 하는 짧은 입력 — 새 문서 제목을 받거나 팀원을 초대하는 자리입니다. 항목이 두셋을 넘지 않을 때만 맞습니다.
3. 지금 막아야 하는 안내 — 결제 카드가 만료돼 다음 동작이 아예 불가능한 경우처럼, 읽고 무언가 하기 전에는 진행할 수 없는 상태입니다. 이때는 닫기 버튼을 두지 않거나, 닫으면 앞 화면으로 되돌아가게 만듭니다.

쓰지 않는 자리도 분명합니다. 입력 항목이 다섯을 넘으면 창 안에서 스크롤이 생기고 뒤 화면 맥락도 사라져서, 화면을 하나 만드는 편이 낫습니다. 모달 위에 모달을 또 띄우는 것도 피합니다. 사용자가 몇 겹 안에 있는지 잃어버립니다. 놓쳐도 되는 결과는 토스트로 띄웁니다. 잠깐 떴다 사라지는 알림이라 흐름을 끊지 않습니다.

"삭제는 모달로 한 번 막아 주세요. 실행 취소가 없어서요."

되돌릴 방법이 없으니 실행 전에 흐름을 끊자는 요청입니다.

"이건 모달 말고 화면을 하나 만드는 게 낫겠어요. 입력 항목이 아홉 개예요."

창 안에 다 들어가지 않는 양이라 다른 방식이 맞다는 판단입니다.

"모달 열고 탭 누르면 뒤 화면 버튼으로 초점이 가요."

초점 가두기가 빠져서 키보드 사용자에게는 막힌 상태가 아니라는 지적입니다.

페이지덱은 삭제 문의 열한 건을 보고 삭제 확인 모달을 넣었습니다. 민서가 창 안의 문구를 "이 문서를 삭제합니다" 대신 문서 제목을 그대로 넣은 형태로 만들었고, 실행 버튼도 오른쪽이 아니라 왼쪽에 두자는 의견이 나왔다가 다른 화면과 어긋나서 되돌렸습니다. 다음 달 삭제 문의는 두 건이었습니다.

태오는 여기에 두 가지를 더 넣었습니다. 막을 눌러도 창이 닫히지 않게 했고, 삭제 버튼에 초점이 처음부터 가 있지 않게 했습니다. Enter 키를 누르고 있던 사용자가 창이 뜨자마자 삭제를 실행하는 일을 막으려는 것이었습니다. 대신 취소 버튼에 초점을 두어서, 아무 생각 없이 Enter 를 눌러도 아무 일이 일어나지 않게 했습니다.

중요한 내용은 모달로 띄우면 된다고 여기기 쉽습니다. 실제로 가장 확실하게 보이는 방법이니 자연스러운 생각입니다. 문제는 사용자가 모달을 내용이 아니라 장애물로 학습한다는 데 있습니다. 새 기능 안내, 설문 요청, 할인 공지가 차례로 뜨면 사람들은 창이 뜨는 순간 내용을 읽지 않고 닫기부터 누릅니다. 그렇게 길든 다음에는 정말 막아야 할 삭제 확인 창도 같은 속도로 닫힙니다. 모달을 아껴 쓰는 이유는 예의가 아니라 이 효력 때문입니다. 한 사용자에게 띄우는 안내성 모달을 한 주에 하나로 제한해 두는 팀이 많은 것도 같은 이유입니다.

화면을 새로 만드는 것보다 모달이 가볍다고 보는 것도 잦은 오해입니다. 만드는 값만 보면 맞습니다. 그런데 모달은 대개 주소를 갖지 않아서 몇 가지가 함께 사라집니다. 브라우저 뒤로 가기를 누르면 창이 닫히는 게 아니라 앞 화면으로 나가 버리고, 새로고침하면 창이 사라지고, 그 상태를 링크로 보낼 수도 없습니다. 초대 화면을 모달로 만들었다면 "여기 들어가서 초대하세요" 라고 보낼 주소가 없습니다. 공유하거나 다시 찾아올 일이 있는 화면은 모달에 담지 않습니다.