04 · Patterns · 피드백 · 상태
확인 다이얼로그Confirmation
“정말 하시겠습니까?”는 아무 데나 붙이는 게 아닙니다. 되돌릴 수 없거나 영향이 큰 행동 앞에서만, 구체적인 결과와 함께.
언제 쓰나
- 되돌릴 수 없는 행동 — 영구 삭제, 헌금 송금, 제출, 전송.
- 결과가 사용자의 데이터에 크게 영향 — 계정 비활성화, 뉴스레터 해지.
- 되돌릴 수 있더라도 영향 범위가 큰 경우 — 여러 항목 일괄 변경.
‘저장’ 같은 일상적 행동에 확인창을 붙이면 사용자는 귀찮아 스킵하는 훈련을 받고, 정작 중요한 확인창도 습관적으로 통과해버립니다.
3가지 유형
단순 확인
영향이 경미하고 대부분 ‘예’를 고름.
위험 확인
결과가 영구적이고 실수 비용이 큼.
입력 확인
이름을 타이핑하는 등 의도적 마찰.
문구의 규칙
- 제목은 질문이 아닌 결정문으로. “게시글을 삭제할까요?” → “게시글 삭제”.
- 본문은 결과의 구체성. “이 게시글과 하위 23개 댓글이 영구 삭제됩니다”.
- 버튼 텍스트는 동사 + 대상. ‘확인’ → ‘삭제’, ‘취소’ → ‘취소’.
Do· 구체적인 버튼
“신청 취소” · “취소 안 함”처럼 버튼 하나만 보고도 결과가 명확해야 합니다. 다이얼로그 본문을 건너뛴 사용자도 실수하지 않도록.
Don't· 추상적 ‘OK / Cancel’
“확인” / “취소” 쌍은 맥락이 사라진 순간 어떤 버튼이 ‘취소 안 하기’인지 애매합니다. 특히 ‘취소를 취소’하는 상황에서 치명적.
입력 확인 (파괴적 한정)
교적 삭제, 계정 제거처럼 매우 되돌리기 어려운 행동은 단순 버튼 클릭을 넘어 이름 타이핑을 요구할 수 있습니다.
- 타이핑한 문자열이 일치할 때만 파괴적 버튼 활성화.
- 요구 문자열을 명확히 표시: “삭제하려면
my-account를 입력하세요”. - 과도하게 쓰지 말 것. 1년에 10번 만날까 말까 한 행동에만.
확인 대신 ‘실행 취소’
가능하다면 확인 다이얼로그보다 실행 취소(Undo)가 더 좋은 선택입니다. 사용자의 흐름을 끊지 않으면서 복구 경로를 제공해 잘못된 확인보다 더 안전합니다. 삭제 → 즉시 반영 + 하단에 “삭제됨 · 실행 취소” Toast가 대표 패턴.
접근성
- 네이티브
<dialog>+showModal()은 모달 배경 비활성화·포커스 트랩을 기본으로 제공합니다. role="dialog" aria-modal="true" aria-labelledby aria-describedby세트.- ESC·배경 클릭은 취소로. 파괴적 다이얼로그에서 실수로 파괴 버튼이 눌리는 위치에 두지 마세요.