# GitHub은 더 이상 Toasts를 사용하지 않음

> Clean Markdown view of GeekNews topic #25017. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25017](https://news.hada.io/topic?id=25017)
- GeekNews Markdown: [https://news.hada.io/topic/25017.md](https://news.hada.io/topic/25017.md)
- Type: news
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-12T10:11:01+09:00
- Updated: 2025-12-12T10:11:01+09:00
- Original source: [primer.style](https://primer.style/accessibility/toasts/)
- Points: 16
- Comments: 1

## Summary

**GitHub은 더 이상 Toast 알림을 사용하지 않습니다.** 자동으로 사라지는 일시적 알림 구조가 WCAG 기준을 충족하지 못하고, 시각적·기능적 접근성을 저해할 수 있기 때문입니다. GitHub은 **배너**나 **다이얼로그**처럼 사용자가 직접 인지하고 제어할 수 있는 지속적 피드백 방식을 대안으로 제시하며, Primer 디자인 시스템 전반에서도 Toast 컴포넌트를 단계적으로 제거하고 있습니다.

## Topic Body

- **Toast 알림 UI**는 접근성 문제로 인해 GitHub에서 더 이상 권장되지 않음  
- 자동으로 사라지는 **일시적 알림 구조**가 시각적·기능적 접근성 기준(WCAG)을 위반할 위험 존재  
- GitHub은 **배너(banner)** , **다이얼로그(dialog)** 등 **지속적이고 접근 가능한 피드백 방식**을 대안으로 제시  
- Toast는 **큰 화면, 멀티태스킹, 배너 무시 현상** 등 사용성 문제도 다수 포함  
- 접근성과 일관된 사용자 경험을 위해 **Primer 디자인 시스템 전반에서 Toast 사용 중단**  
  
---  
  
### Toasts 개요  
- Toast는 화면 하단 모서리에 잠시 나타나는 **작은 직사각형 알림 창**으로, 사용자 또는 시스템 동작에 의해 트리거됨  
- 일정 시간이 지나면 자동으로 사라지는 구조로, **접근성과 사용성 문제**가 내재함  
- GitHub은 이러한 이유로 **보다 안정적이고 접근 가능한 커뮤니케이션 방식**을 권장함  
  
### Toast 대체 방안  
- 사용 목적에 따라 적절한 UI 선택 필요  
  - 단순 성공 알림은 별도 피드백 없이 **결과 화면 자체로 확인 가능**  
  - 복잡한 작업은 **배너**나 **점진적 콘텐츠 표시**로 성공 상태 전달  
  - 실패한 작업은 **배너** 또는 **다이얼로그**를 통해 오류 정보 제공  
- **폼 제출**의 경우 단순 폼은 별도 확인 불필요, 복잡한 폼은 **중간 확인 페이지**나 **배너** 사용  
- **입력 검증**은 Primer의 기존 **폼 검증 컴포넌트** 활용  
- **장시간 작업**은 배너 또는 이메일·푸시 알림 등 **다른 채널**을 통해 완료 상태 전달  
- **세션 비동기화** 발생 시 다이얼로그나 배너로 **새로고침 필요성 안내**  
  
### 접근성 고려사항 (Accessibility Considerations)  
- Toast UI는 여러 **WCAG 성공 기준**을 위반할 가능성 있음  
  - **2.2.1 Timing Adjustable (A)** : 사용자가 직접 닫기 전까지 유지되어야 함  
  - **1.3.2 Meaningful Sequence (A)** : DOM 순서와 시각적 순서 불일치로 보조기술 사용 시 혼란 발생  
  - **2.1.1 Keyboard (A)** : 키보드로 토스트 내 인터랙션 제어 가능해야 함  
  - **4.1.3 Status Messages (AA)** : 보조기술에 비방해적으로 존재를 알려야 함  
- 추가로 위반 가능성이 있는 기준  
  - **1.4.4 Resize text (AA)** : 텍스트 크기 조정 시 화면 가림 또는 오버플로 발생 위험  
  - **1.4.10 Reflow (AA)** : 수평 스크롤 시 키보드 접근성 확보 필요  
  - **2.4.3 Focus Order (A)** : 포커스 순서 혼란 가능성  
  - **3.2.4 Consistent Identification (AA)** : 코드 일관성 유지 필요  
  
### 사용성 고려사항 (Usability Considerations)  
- **대형 화면**에서는 토스트가 시야 밖에 위치해 인식되지 않을 수 있음  
- **자동 해제** 시 사용자가 다른 작업 중이면 메시지를 놓칠 위험 존재  
- **UI 가림 현상**: 토스트가 하단 버튼 등 중요한 요소를 덮을 수 있음  
- **화면 확대 사용자**는 확대 영역 밖의 토스트를 보지 못할 수 있음  
- **작업 기억 문제**: 자동 사라짐으로 정보 재확인 불가  
- **배너 무시 현상**: 과도한 사용으로 사용자가 무시하는 경향  
- **위치 불일치**: 트리거된 UI와 토스트의 물리적 거리로 인한 연관성 혼란  
- **잘못된 닫기 동작**: Esc 키로 다른 UI까지 함께 닫히는 문제 발생 가능  
  
### 추가 참고 자료  
- [Notification messaging - Primer](https://primer.style/product/ui-patterns/notification-messaging/)  
- [A toast to an accessible toast… - Scott O’Hara](https://www.scottohara.me/blog/2019/07/08/a-toast-to-a11y-toasts.html)  
- [Defining ‘Toast’ Messages - Adrian Roselli](https://adrianroselli.com/2020/01/defining-toast-messages.html)  
- [The problem with toast messages and what to do instead - Adam Silver](https://adamsilver.io/blog/the-problem-with-toast-messages-and-what-to-do-instead/)

## Comments



### Comment 47635

- Author: neo
- Created: 2025-12-12T10:12:01+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46196831)   
- 접근성에 대해 강의하면서 클릭 후 **3초 지연**이 생겨 아무 반응이 없는 것처럼 느껴지는 상황을 겪었음  
  - 배너를 클릭하면 아무 표시도 없이 기다리게 되고, 나중에 관련 없는 페이지로 이동하는 식이라 답답했음  
  - 로딩 중임을 알려주는 **피드백 부재**가 문제라고 생각함  
  - 어떤 이는 그건 단순한 `` 링크라며, 페이지가 불필요하게 커서 생기는 지연일 뿐이라고 말함  
  - 또 다른 사람은 느린 4G에서도 즉시 반응한다며, 브라우저나 네트워크 문제일 가능성을 제기함  
- **GitHub Primer** 문서를 흥미롭게 읽었음  
  - 모든 내용에 동의하지 않아도 배울 점이 있고, 감으로 하는 것보다 훨씬 낫다고 느낌  
  - 참고로 Apple과 Android도 각각 **디자인 가이드라인**을 제공하고 있음  
- 드디어 이런 **트렌드**가 확산되길 바람  
  - 토스트 알림 때문에 놓친 메시지가 너무 많았음  
  - 다른 사용자는 “토스트는 접근성 문제로 사용을 권장하지 않는다”는 문구에 전적으로 동의하며, **알림 센터**가 있었다면 그나마 나았겠지만 여전히 나쁜 방식이라고 강조함  
- 나는 토스트를 **비방해적 확인용**으로는 좋아하지만, 중요한 정보를 전달하는 용도로는 부적절하다고 생각함  
  - 다른 사람은 토스트의 사용 맥락을 구체적으로 나눠 설명함  
    - 버튼 클릭 즉시 반응 → 버튼 자체에서 피드백을 주는 게 낫고  
    - 단축키 반응 → 괜찮음  
    - 오래 걸리는 작업 완료 알림 → 괜찮지만 **지속적인 알림함**이 필요함  
    - 페이지 진입 시 경고 표시 → 중요하다면 페이지 내에 **영구적 알림**으로 보여야 함  
  - React에서 전역 `toast()` 호출이 쉬워 남용되는 경향이 있지만, `useAlerts()` 같은 구조로 바꾸는 게 훨씬 낫다고 제안함  
- 토스트는 내게 **지혈대 같은 존재**임  
  - 급한 문제를 임시로 막는 데 유용하지만, 장기적으로 유지하면 안 됨  
  - 새 프로젝트에서 피드백이 부족할 때 임시로 붙였다가, UI를 개선하면서 하나씩 제거하는 식으로 써야 함  
  - GitHub처럼 큰 조직은 이런 임시방편이 필요 없지만, 작은 팀은 다를 수 있음  
- GitHub 문서에서 말한 “대량 Issue 생성 시 추가 피드백이 필요하다”는 부분이 마음에 듦  
  - **GitHub Actions**에서도 이런 피드백이 있으면 좋겠음, 실행 후 결과가 나타나기까지 너무 오래 걸림  
- UI 전반의 **행동 로그**로 토스트를 활용하는 아이디어가 마음에 듦  
  - 클릭할 때마다 사라지는 피드백 대신, Sonner처럼 잘 구현된 예시가 있음  
- 브라우저 차원에서 **토스트의 네이티브 지원**을 고려할 때가 된 것 같음  
  - 타이밍 조절, 알림 센터, 스크린 리더 통합 등 접근성 개선이 가능할 것 같음  
  - 시각적으로는 괜찮지만, 너무 빨리 사라져 놓치는 경우가 많음  
  - 시각장애인이 겪는 문제를 직접 이해하긴 어렵지만, 그들의 접근성을 높이는 방법을 듣고 싶음  
- 토스트의 장점은 **구현이 쉽고 디자인 부담이 적음**임  
  - 단점은 놓치기 쉽고, 다른 정보 위에 겹칠 위험이 있음  
  - 여유가 있다면 토스트를 모두 없애는 게 낫다고 생각함  
  - 다른 사람은 “쉽게 만들 수 있어서 **문제 해결을 가장한 미봉책**으로 남용된다”고 지적함  
  - 또 다른 사람은 토스트를 단순한 **안심용 피드백**으로 사용했다고 함  
  - 반면 어떤 이는 “토스트는 저중요 이벤트에 즉각적 피드백을 주는 유용한 도구”라며, 모달창이나 고정 영역보다 효율적이라고 주장함  
  - 도구의 남용을 이유로 완전히 배제하는 **흑백논리**를 비판함  
- “GitHub의 토스트 제거가 접근성에 나쁜 소식”이라는 글을 봤음  
  - 어떤 이는 그 주장이 이상하다고 느낌  
    - GitHub이 토스트를 없앤 대신 W3C를 통해 브라우저 표준을 만들었어야 한다는 건 비약이라고 생각함  
    - 이미 생성된 아이템이 리스트에 나타나는 것만으로도 충분한 피드백이라고 봄  
  - 또 다른 사람은 “토스트가 접근성과 UX에 나쁘다고 하면서, GitHub이 그것을 브라우저에 표준화하지 않았다고 비판하는 건 모순”이라고 말함