토스트

Toast

개념

화면 한쪽에 몇 초 동안 떴다가 스스로 사라지는 알림으로, 방금 한 동작이 처리됐다는 것을 알릴 때 씁니다.

등장 배경

동작의 결과를 알리는 방법이 창을 띄우는 것뿐이던 시절이 있었습니다. 저장했습니다라는 문장과 확인 버튼이 화면 가운데에 떠서, 사용자는 하던 일을 멈추고 버튼을 눌러 그 창을 치운 다음에야 다음 일을 했습니다. 알림 하나마다 흐름이 한 번씩 끊긴 셈입니다.

페이지덱 초기 화면이 그랬습니다. 문서를 고칠 때마다 저장 확인창이 떴고, 민서가 사용성 테스트를 돌려 보니 참가자 다섯 명 전부가 문장을 읽지 않고 확인 버튼만 눌렀습니다. 한 사람은 30분 동안 그 버튼을 열두 번 눌렀습니다. 알리려던 내용은 전달되지 않았고 남은 것은 클릭 열두 번이었습니다.

토스트는 그 통지를 화면 가운데에서 여백으로 밀어낸 것입니다. 읽을 사람은 읽고 나머지는 하던 일을 이어갑니다. 대신 조건이 하나 붙습니다. 놓쳐도 괜찮은 내용만 담아야 한다는 것입니다. 몇 초 뒤에 사라지는 자리에 놓인 말은 못 본 사람에게는 없던 말과 같습니다.

작동 방식

동작이 끝난 직후 화면 한쪽에 나타나 정해진 시간이 지나면 스스로 사라집니다. 사용자가 아무것도 하지 않아도 정리된다는 점이 다른 알림과 갈리는 지점입니다.

정해 둘 것은 여섯 가지입니다.

  1. 자리. 화면 아래 가운데나 위 오른쪽 가운데 하나로 고정합니다. 화면마다 자리가 달라지면 사용자가 알림을 찾느라 눈을 옮기게 되고, 그 사이에 알림이 사라집니다.
  2. 유지 시간. 한 줄이면 4초 안팎을 기준으로 잡고 글자가 길어지면 늘립니다. 읽는 속도보다 짧으면 떴다는 사실만 남고 내용은 전달되지 않습니다.
  3. 겹침 처리. 여러 동작이 연달아 끝나면 위로 쌓거나 차례로 내보냅니다. 화면에 동시에 세 개까지만 두고 나머지는 기다리게 하는 것이 무난합니다.
  4. 닫기. 사용자가 먼저 치울 수 있게 닫기 버튼을 둡니다. 마우스를 얹고 있는 동안에는 타이머를 멈춰야 읽던 문장이 중간에 사라지지 않습니다.
  5. 내용. 한 문장으로 무엇이 어떻게 됐는지만 적습니다. 오류의 원인이나 해결 방법 설명은 이 자리에 들어가지 않습니다.
  6. 소리 내 읽히게 하기. 화면을 눈으로 보지 않는 사용자에게도 전달되도록 ARIA가 정한 알림 영역으로 표시해 둡니다. 이 표시가 없으면 스크린 리더는 방금 무슨 일이 있었는지 말해 주지 않습니다.

여섯 가지를 관통하는 규칙은 하나입니다. 결정이나 행동을 요구하지 않습니다. 3초 뒤에 사라지는 자리에 버튼을 놓으면 그 버튼은 3초 안에 눌러야 하는 버튼이 됩니다.

쓰이는 곳

사용자가 방금 한 동작의 결과를 알릴 때 씁니다. 문서가 저장됐다, 링크를 복사했다, 초대 메일을 보냈다, 설정이 반영됐다처럼 성공을 알리는 한 문장이 대표적입니다. 사용자가 이미 자기가 무엇을 했는지 알고 있어서 문장을 놓쳐도 손해가 없는 자리입니다.

맞지 않는 자리는 셋입니다.

  1. 되돌릴 기회를 줘야 하는 동작. 되돌리기 버튼이 붙는 알림은 스낵바가 맡습니다. 삭제나 보관처럼 잘못 눌렀을 때 손해가 생기는 동작이 여기 해당합니다.
  2. 사용자가 답해야 하는 것. 정말 지울지 묻는 질문은 뒤 화면을 막고 뜨는 모달로 갑니다. 답을 받아야 다음이 결정되는 일은 사라지는 자리에 둘 수 없습니다.
  3. 계속 남아 있어야 하는 공지. 결제가 실패했거나 저장 용량이 다 찼다는 소식은 화면 위에 걸려 유지되는 배너로 둡니다.

사용자가 고쳐야 하는 오류도 토스트로 보내지 않습니다. 필수 항목이 비었다는 안내는 그 입력 칸 아래에 붙여야 어디를 고쳐야 하는지가 같이 전달됩니다. 문구는 짧게 쓰되 무엇이 됐는지는 남겨야 해서, 화면에 들어가는 짧은 문구를 다루는 마이크로카피의 규칙을 그대로 적용합니다. 완료됐습니다보다 초대 메일 3통을 보냈습니다가 낫습니다.

실무 용례

"이건 토스트로 빼죠. 확인 버튼까지 누르게 할 내용은 아니에요."

알림의 무게를 낮춰 흐름을 끊지 말자는 제안입니다.

"토스트에 되돌리기를 넣으면 3초 안에 눌러야 하는 버튼이 됩니다. 스낵바로 가야 해요."

사라지는 알림에 행동을 붙이면 안 된다는 지적입니다.

"결제 실패를 토스트로 띄우면 안 됩니다. 자리를 비우면 못 본 채로 지나갑니다."

놓쳐도 되는 내용인지가 이 요소를 고르는 기준이라는 뜻입니다.

민서가 저장 확인창을 토스트로 바꾼 뒤 문서를 고치는 동안의 불필요한 클릭이 사라졌습니다. 같은 작업에서 참가자가 멈추는 횟수도 줄었습니다. 그런데 한 달 뒤에 다른 불만이 들어왔습니다. 문서를 실수로 지웠는데 되돌릴 방법을 찾지 못했다는 것이었습니다.

확인창을 걷어 내면서 삭제까지 같이 토스트로 처리한 것이 원인이었습니다. 삭제됐습니다라는 문장이 4초 뒤에 사라지고 나면 사용자에게 남는 단서가 없었습니다. 민서는 삭제만 되돌리기 버튼이 붙은 알림으로 옮기고, 성공 통지는 토스트에 그대로 뒀습니다. 요소를 하나로 통일하는 것이 아니라 동작의 성격에 따라 갈라 쓰는 쪽이 기준이 됐습니다.

흔한 오해

알림을 조용하게 만드는 방법이라고 읽는 경우가 가장 많습니다. 창을 띄우지 않으니 사용자를 방해하지 않는다는 점이 먼저 보이기 때문입니다. 그런데 방해하지 않는다는 말은 전달을 보장하지 않는다는 말과 같습니다. 중요한 소식을 토스트로 옮기는 것은 조용하게 만드는 일이 아니라 사라지게 만드는 일입니다. 용량이 찼다는 안내를 토스트로 바꾼 뒤 문의가 늘어나는 식으로 나타납니다.

짧게 뜨니 접근성에는 문제가 없다고 읽는 것도 흔합니다. 화면을 가리지 않는 것이 배려처럼 느껴지는 탓입니다. 하지만 4초는 누구에게나 같은 4초가 아닙니다. 스크린 리더가 읽어 주기 전에 사라지거나, 화면을 확대해 쓰는 사용자의 보이는 영역 밖에서 떴다 지는 일이 생깁니다. 최소 유지 시간을 정해 두고 마우스나 키보드 초점이 머무는 동안 타이머를 멈추는 규칙이 함께 있어야 합니다.

자주 헷갈리는 용어

용어무엇을 더 담는가토스트와의 차이
스낵바결과 알림에 되돌리기 같은 동작 하나를 함께 담습니다버튼이 붙으니 사용자가 누를 시간을 줘야 해서 유지 시간이 더 길고, 화면 아래쪽에 고정되는 경우가 많습니다. 토스트는 읽히기만 하면 되고 누를 것이 없습니다

같이 보면 좋은 페이지

  • UI 컴포넌트

    이 요소가 어느 갈래의 한 부품인지 봅니다

  • 스낵바

    가장 자주 섞어 쓰는 옆 요소를 나란히 봅니다

마지막 업데이트 2026-09-16