Confirm Dialog는 정말 필요한가
먼저 던질 질문
확인창은 사용자를 보호하는가, 흐름을 방해하는가
핵심 관점
Confirm Dialog의 핵심 질문은 정말 물어볼 것인가가 아니라, 사용자가 아직 모르는 정보를 제공하는가이다. 새 정보가 없다면 확인창은 안전장치보다 마찰에 가깝다.
회복 가능성이 보이는 장면
계정 삭제처럼 복구가 어렵고 손실이 큰 작업은 확인창이 필요하다.
이때 확인창은 삭제 대상, 사라지는 데이터, 복구 불가능성을 구체적으로 말해야 한다.
API Key 재발급은 기존 연동을 중단시킬 수 있다.
확인창은 기존 키가 비활성화되는 시점과 영향을 받는 시스템을 알려줘야 한다.
Confirm Dialog는 실수를 막는 장치이지만, 반복 노출되면 사용자가 내용을 읽지 않는 통과 절차가 된다.
위험이 커지는 흐름
체크리스트 완료나 즐겨찾기 해제처럼 복구 가능한 반복 작업마다 확인창이 뜨면 사용자는 확인창을 읽지 않고 누르게 된다.
이 경우 사용자는 화면의 의도를 스스로 추측해야 한다. UX가 나빠지는 순간은 대개 사용자가 다음 행동을 알 수 없을 때다.
"정말 진행하시겠습니까?"처럼 대상과 결과가 없는 문구는 사용자에게 새로운 정보를 주지 못한다.
행동 보호 사례와 근거
확인창은 새 정보를 줄 때만 안전장치가 된다
저장소 삭제 흐름은 삭제 대상, 되돌리기 어려운 결과, 대상 이름 재입력까지 포함해 사용자가 감수할 결과를 구체화한다. 이때 확인창은 단순한 "정말 진행할까요?"가 아니라 의사결정 보조 장치다.
클라우드 리소스 종료처럼 비용, 서비스 중단, 데이터 손실 가능성이 있는 작업도 강한 확인이 필요하다. 반면 이메일 보관이나 체크리스트 완료처럼 반복적이고 복구 가능한 작업은 Undo가 더 자연스럽다.
실무 해석
WAI-ARIA Dialog 패턴은 모달이 외부 콘텐츠를 비활성화하고 포커스를 내부에 가둔다는 점을 전제로 한다. 이 비용을 감수할 만큼 중요한 결정인지 먼저 판단해야 한다.
위험 판단 기준
- 작업이 되돌릴 수 있는지 확인한다
- 결과가 비용, 보안, 데이터 손실을 만드는지 판단한다
- Confirm, Undo, Soft Delete 중 가장 덜 방해되는 보호 방식을 고른다
자주 빠지는 함정
확인창을 많이 넣으면 안전해진다고 믿기 쉽다. 하지만 반복 확인은 사용자의 주의를 무디게 만들어 실제 위험한 순간에도 읽히지 않는다.
추가로 비교할 회복 흐름
- 저장소 삭제 확인, 클라우드 리소스 삭제 확인, 이메일 Undo를 비교한다
- 반복 작업에서 확인창이 과한 관리자 도구 사례를 찾는다
- 프로젝트명 입력 확인처럼 강한 확인이 필요한 사례를 모은다
위험 설계 질문
- 확인창이 새 정보를 주는지 판단하는 기준이 있는가
- 복구 가능한 작업과 불가능한 작업을 충분히 나눴는가
출처
- GitHub Docs, Deleting a repository: https://docs.github.com/en/repositories/creating-and-managing-repositories/deleting-a-repository
- AWS Docs, Terminate Amazon EC2 instances: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html
- Google Gmail Help, Send or unsend Gmail messages: https://support.google.com/mail/answer/2819488?hl=en
- WAI-ARIA APG, Dialog Modal Pattern: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
- Material Design 3, Dialogs: https://m3.material.io/components/dialogs/overview