핵심 요약 (Summary)
로딩 스피너와 스켈레톤 UI 중 무엇이 더 좋은가에 대한 정답은 없습니다. 유명 테크 기업 플랫폼 10여 곳을 직접 살펴본 결과, 공통된 패턴이 있었습니다. 리스트나 콘텐츠 영역에는 스켈레톤 UI를, 버튼이나 액션에는 로딩 스피너를 사용하는 방식이었습니다. 결국 선택의 기준은 "어떤 상황인가"였습니다.
왜 이런 고민이 생기나요? (Why)
프로젝트를 진행하다 보면 반드시 이 질문과 마주칩니다. 사용자가 데이터를 기다리는 동안 무엇을 보여줄 것인가. 팀 내에서도 의견이 갈립니다. 스피너가 익숙하고 구현이 빠르다는 입장이 있고, 스켈레톤이 더 세련되어 보인다는 입장이 있습니다. 하지만 두 의견 모두 "어떤 것이 사용자에게 덜 지루한가", "이탈률을 줄이는 데 어떤 것이 효과적인가"라는 질문에 정확하게 답하지 못합니다.
그래서 직접 확인하기로 했습니다. 평소 자주 사용하거나 참고하는 플랫폼 10여 곳을 열고, 로딩 상황에서 각 서비스가 어떤 선택을 하는지 살펴봤습니다. YouTube, Linear, Notion, GitHub, Vercel, Figma, Slack, X(Twitter), Airbnb, Shopify 등이었습니다.
직접 살펴본 결과
공통된 패턴이 있었습니다.
리스트와 콘텐츠 영역에는 대부분 스켈레톤 UI를 사용합니다.
YouTube는 동영상 목록이 로딩될 때 썸네일, 제목, 채널명 자리에 회색 블록을 보여줍니다. GitHub의 피드, Linear의 이슈 목록, Notion의 페이지 리스트, Airbnb의 숙소 카드도 마찬가지입니다. 공통점은 모두 "레이아웃이 확정된 콘텐츠"라는 점입니다. 카드가 몇 개 나올지, 어떤 구조로 배치될지 미리 알고 있기 때문에 그 형태를 먼저 그려두는 것이 가능합니다.
버튼을 눌렀을 때, 그리고 액션이 진행 중일 때는 스피너를 사용합니다.
폼 제출 버튼, 저장 버튼, 삭제 버튼에는 스피너가 들어갑니다. Vercel의 배포 버튼, Slack의 메시지 전송, Shopify의 주문 처리 버튼 모두 클릭 직후 버튼 내부에 작은 스피너가 등장하고, 버튼은 비활성 상태가 됩니다. "지금 무언가가 처리되고 있다"는 즉각적인 피드백이 필요한 상황이기 때문입니다.
왜 이런 패턴이 정착됐을까요?
스켈레톤 UI가 리스트에 효과적인 이유는 지각된 대기 시간(Perceived Wait Time) 때문입니다. 사람은 아무것도 없는 빈 화면보다, 구조가 있는 화면을 보며 기다릴 때 시간이 더 빨리 가는 것처럼 느낍니다. 스피너는 "기다리고 있어요"라는 메시지를 전달하지만, 스켈레톤은 "곧 이런 내용이 나올 거예요"라는 메시지를 전달합니다. 사용자 입장에서 후자가 훨씬 덜 불안합니다.
반면 버튼 액션처럼 레이아웃이 확정되지 않은 상황에서 스켈레톤을 쓰는 것은 오히려 어색합니다. 버튼을 누른 뒤 화면 어딘가에 스켈레톤이 나타난다면, 사용자는 "내 액션이 처리되고 있는 건가?"를 직관적으로 파악하기 어렵습니다. 이때는 버튼 자체가 변해야 합니다. 텍스트가 스피너로 바뀌고 버튼이 비활성화되는 것이 가장 명확한 피드백입니다.
정리 (Conclusion)
두 가지 원칙을 기준으로 삼으면 대부분의 상황에서 판단이 빨라집니다.
- 레이아웃을 예측할 수 있는 리스트, 카드, 콘텐츠 영역: 스켈레톤 UI
- 사용자의 액션에 반응해야 하는 버튼, 폼 제출, 처리 중 상태: 로딩 스피너
단, 이것도 절대적인 규칙은 아닙니다. 검색 결과처럼 레이아웃을 예측하기 어려운 경우에는 스피너가 자연스럽고, 버튼이 아닌 인라인 액션 영역이라면 스켈레톤이 더 적합할 수 있습니다. 결국 기준은 하나입니다. 사용자가 지금 무슨 일이 일어나고 있는지를 가장 빠르게, 가장 덜 불안하게 파악할 수 있는 방법은 무엇인가.