Loading UI와 Skeleton UI는 언제 다르게 써야 할까

먼저 던질 질문

사용자의 기다림을 줄이는 UI는 무엇이 다른가

핵심 관점

Loading UI의 목적은 기다림을 예쁘게 꾸미는 것이 아니라 불확실성을 줄이는 것이다. Spinner, Skeleton, Progress는 각각 다른 종류의 불확실성에 답한다.

상태가 잘 읽히는 장면

뉴스 피드처럼 카드 구조가 예측 가능한 화면에서 Skeleton을 사용한다.

사용자는 곧 콘텐츠가 채워질 위치를 예상할 수 있다.

파일 업로드처럼 시간이 오래 걸리는 작업에는 Progress와 남은 상태를 보여준다.

사용자를 막는 상태

구조가 불확실한 화면에 Skeleton을 사용해 실제 콘텐츠가 들어올 때 크게 흔들린다.

긴 작업에 Spinner만 보여줘 사용자가 멈춘 것인지 진행 중인지 알 수 없다.

상태 피드백 사례와 근거

로딩 UI는 기다림의 이유를 설명해야 한다

Nielsen의 응답 시간 기준은 사용자가 즉각성, 흐름 유지, 주의 이탈을 시간 구간에 따라 다르게 느낀다는 점을 설명한다. 로딩 UI는 장식이 아니라 시스템이 살아 있고 요청을 처리 중이라는 증거다.

Spinner는 짧고 불확실한 작업에 적합하지만, 콘텐츠 구조가 예측 가능한 목록과 카드에는 Skeleton UI가 더 많은 단서를 준다. 사용자는 어떤 종류의 정보가 나타날지 미리 이해할 수 있다.

실무 해석

Skeleton은 실제 콘텐츠와 같은 공간을 예약해야 한다. web.dev의 CLS 지표가 말하듯 로딩 후 레이아웃이 흔들리면 사용자는 성능과 신뢰를 동시에 낮게 평가한다.

피드백 설계 기준

• 얼마나 오래 기다릴 가능성이 있는지 판단한다
• 콘텐츠 구조를 예측할 수 있는지 확인한다
• 기다리는 동안 사용자가 할 수 있는 행동을 정한다

자주 빠지는 함정

Skeleton을 쓰면 항상 더 좋아 보인다고 생각하기 쉽다. 실제 콘텐츠 구조와 다르면 로딩 후 레이아웃 변화가 더 큰 불신을 만든다.

추가로 비교할 상태

• YouTube, Medium, 커머스 목록의 Skeleton UI를 비교한다
• 파일 업로드나 결제처럼 긴 작업에서 Progress가 필요한 사례를 모은다
• 잘못된 Skeleton으로 레이아웃이 흔들리는 사례를 찾는다

상태 설계 질문

• Skeleton을 쓰면 안 되는 조건을 충분히 설명했는가
• 접근성에서 로딩 장식을 어떻게 처리할지 포함했는가

출처

• Nielsen Norman Group, Response Time Limits: https://www.nngroup.com/articles/response-times-3-important-limits/
• Material Design 3, Progress indicators: https://m3.material.io/components/progress-indicators/overview
• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Cumulative Layout Shift: https://web.dev/articles/cls