UKWRV.
BACK TO BLOG

Toast, Snackbar, Alert는 언제 다르게 써야 할까

알림의 위치와 지속 시간은 무엇을 기준으로 정해야 할까 성공, 경고, 오류, 정보 알림의 역할 구분

Toast, Snackbar, Alert는 언제 다르게 써야 할까

먼저 던질 질문

알림의 위치와 지속 시간은 무엇을 기준으로 정해야 할까

핵심 관점

Toast, Snackbar, Alert의 차이는 모양이 아니라 메시지가 사라져도 되는지에 있다. 사용자가 반드시 알아야 하는 정보는 화면에 남아야 한다.

상태가 잘 읽히는 장면

저장 완료는 짧은 Toast로 알려준다. 사용자는 현재 상태를 이해하고, 다음에 무엇을 할 수 있는지 알며, 행동의 결과를 어느 정도 예측할 수 있다.

삭제 후 Undo는 Snackbar로 제공한다.

사용자를 막는 상태

결제 실패를 자동으로 사라지는 Toast로만 보여준다.

여러 Toast를 동시에 쌓아 중요한 메시지를 읽기 어렵게 만든다.

상태 피드백 사례와 근거

차이는 긴급도, 지속 시간, 사용자의 조치 필요성이다

Material Design의 Snackbar는 앱이 수행했거나 수행할 작업을 짧게 알려주는 패턴에 가깝다. 저장 완료, 메시지 전송, 삭제 후 Undo 같은 짧은 피드백에 맞다.

WAI-ARIA Alert는 더 중요하고 시간 민감한 메시지를 보조 기술에 알리는 패턴이다. 결제 실패, 세션 만료, 보안 경고처럼 사용자가 조치해야 하는 정보는 사라지는 Toast보다 화면에 남는 안내가 필요하다.

실무 해석

GOV.UK의 Notification banner는 중요한 성공 또는 정보 메시지를 페이지 상단에 남기는 예시다. 자동으로 사라지는 알림에는 복구 불가능한 정보를 담지 않는 것이 안전하다.

피드백 설계 기준

  • 메시지가 자동으로 사라져도 되는지 판단한다
  • 사용자 액션이 필요한지 확인한다
  • 메시지가 어떤 화면 맥락과 연결되는지 본다

자주 빠지는 함정

에러를 Toast로만 처리하면 구현은 간단하지만 사용자는 해결 방법을 놓칠 수 있다. 특히 결제, 저장, 권한 오류는 사라지는 메시지에 맡기면 안 된다.

추가로 비교할 상태

  • Material Design Snackbar, iOS Toast류 알림, Bootstrap Alert 사례를 비교한다
  • Undo가 있는 Snackbar와 단순 Toast를 비교한다
  • 오류를 Toast로만 처리해 놓치기 쉬운 사례를 찾는다

상태 설계 질문

  • 사라져도 되는 정보와 남아야 하는 정보를 나눴는가
  • 알림 중복과 쌓임 문제를 다뤘는가

출처

  • Material Design 3, Snackbar: https://m3.material.io/components/snackbar/overview
  • WAI-ARIA APG, Alert Pattern: https://www.w3.org/WAI/ARIA/apg/patterns/alert/
  • GOV.UK Design System, Notification banner: https://design-system.service.gov.uk/components/notification-banner/
  • MDN Web Docs, ARIA live regions: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Guides/Live_regions