UX 관점에서 보는 로딩 상태

🍀 이 글을 작성하게 된 이유

로딩 중에 로딩 상태를 표현하는 것이 UX 측면에서 중요하다는 것은 많은 프론트엔드 개발자들이 잘 알고 있습니다. 그래서 흔히 스피너나 스켈레톤 UI 등 다양한 방식으로 로딩 처리를 적용하죠.

하지만, 왜 UX에 도움이 되는지, 어떤 원리에 기반한 것인지 본질적으로 궁금해하는 개발자들은 적은 것 같습니다. 저 역시 그랬고요.

그래서 이번 글에서는 로딩 상태 표현이 UX에 긍정적인 이유. 그리고 상황, 속도, 방식에 따라 어떤 접근이 더 효율적인지를 이론적으로도 정리해보고자 합니다.

🍀 그냥 기다리면 안되나?

사용자가 어떤 기능을 실행했을 때, 화면이 멈춘 듯 아무런 반응이 없다면 어떤 생각이 들까요?

아마도 "렉 걸린건가?", “잘못 들어왔나?"라는 불안함이 먼저 들 겁니다. 이 순간이 UX와 직결되는 지점입니다.
단순히 기다리게 하는 것이 아니라, 사용자가 기다릴 수 있다고 ‘느끼게’ 만드는 것이 UX 설계의 핵심입니다.

✏️ 도허티 임계

“사용자의 인내심은 짧다”

도허티 임계는 시스템의 응답 시간이 0.4초 이내일 때 사용자 경험이 최적화된다는 원칙입니다.

책 “UI/UX의 10가지 심리학 법칙”에서는 도허티 임계값을 아래와 같이 정리했습니다.

• ~0.1초: 반응이 즉각적이라고 인지
• 0.1초~0.3초: 지연이 감지되는 수준이라 인지
• 0.4초~1초: 사용자의 주의가 분산되기 시작
• 1초~: 사용자는 이미 집중하기 어려워지며, 필요한 정보를 놓치게 됨

즉, 0.4초 이내에 피드백을 주어야 사용자 경험이 최적화되며, 1초를 넘기면 체감 만족도는 급격히 떨어질 수 있습니다.

✏️ 로딩 시간별 이탈률

Google에서 조사한 로딩 시간별 사용자 이탈률을 보면, 도허티 임계에서 제시한 1초를 넘기는 시점부터 이탈률이 증가하기 시작하고, 3초 이후에는 급격히 상승하는 것을 확인할 수 있습니다.

(물론 1초 이전에도 이탈은 있겠지만, 유의미한 기준점으로 1초를 설정한 것으로 보입니다.)

근본적으로 로딩 시간을 줄이는 것이 최선이지만, 모든 상황에서 처리하긴 어렵습니다.

따라서 로딩 중이라도 즉각적인 시각 피드백을 제공해 사용자에게 렉이나 오류가 아니라 정상적으로 작동 중임을 인식시켜주는 것이 중요합니다.

물론 누군가는 ‘그렇게 중요한가?’ 라고 생각할 수도 있습니다.

하지만 개발자 입장에서, 로딩 이후에 보여줄 기능을 심혈을 기울여 만들었다고 가정해봅시다.

그런데 서비스의 첫 사용자가 “문제가 있나?”, “너무 느리다”고 느끼고 이탈해버린다면, 그 기능은 사용조차 되지 않은 채 버려지는 셈이 됩니다.

🍀 로딩 상태 처리

✏️ 종류

표현 방법도 여러가지입니다.

1. 로딩 스피너

2. 프로그래스 바

3. 스켈레톤 UI

우리가 즐겨쓰는 유투브나 인스타그램에서도 스켈레톤 UI를 볼 수 있습니다.

4. 애니메이션

로딩 애니메이션 처리를 잘 한 서비스로 토스가 유명합니다.
로딩 처리를 한 가지만이 아니라 여러가지를 경우에 따라서 섞어서 사용하는 것을 볼 수 있습니다.

• 애니메이션 속에 스켈레톤 UI도 볼 수 있다.

• '한도 찾는중' 처리할 때 우측에 스피너도 볼 수 있다.

✏️ 나누는 기준

세계적인 UX 리서치 그룹 닐슨 노먼은 Progress Indicator에 대한 중요성을 강조하며 아래와 같은 주요 지침을 이야기 하였습니다.

1. 약 1초 이상 걸리는 작업에는 Progress Indicator를 사용하십시오.
2. Loop Animation은 빠른 동작에만 사용하십시오.
3. Percent-done Animation은 10초 이상 걸리는 작업에 사용하십시오.
4. Static Indicator는 사용하지 마십시오.

그리고 카카오페이 테크 블로그 글에서는 Skeleton UI가 항상 좋은 것은 아니라고 말합니다.

예를 들어, 지연 시간이 100ms인 상황에서 Skeleton UI를 사용하면 너무 짧은 시간만 노출되어 깜빡이는 듯한 불편한 경험을 줄 수 있습니다.

반면, 300ms의 경우 Skeleton UI가 자연스럽게 동작해 더 빠르고 부드러운 UX를 느낄 수 있었고, 100ms 상황에서는 Skeleton UI를 제거했을 때 훨씬 부드러운 전환이 가능했다고 합니다.

이 글에서는 200ms를 기준으로 Skeleton UI의 노출 여부를 결정합니다. React Suspense와 함께 DeferredComponent를 활용하여, 200ms 이내 응답 시 Skeleton을 보여주지 않고, 그 이후에는 Skeleton UI를 노출하는 전략이죠.

물론 이 경우 250~300ms의 사용자에게는 짧은 시간 동안 스켈레톤이 노출되지만, 전체 사용자 중 약 15%에 불과하기 때문에 85% 이상의 사용자에게 더 나은 경험을 제공하는 전략적 트레이드오프라고 설명합니다.

즉, 모든 사용자보다 최대 다수를 위한 설계인 셈입니다.

이와 관련해 다른 블로그 글에서는,
확실히 느린 3G 환경에서는 위에서 처리했던 저 200ms 조차 아껴서 처음부터 스켈레톤을 보여주게 처리하여 개선하기도 했습니다.

주관적인 생각으로는, 200ms는 사용자가 체감하기 어려울 정도로 빠른 속도라고 봅니다. 그래서 제가 개선한다면, API 응답 시간이 200ms 이내일 경우에는 빈 화면을 그대로 보여주고, Skeleton UI가 적용되는 경우라면, 최소 200ms 동안은 Skeleton이 유지된 후 실제 화면이 나타나도록 처리할 것 같습니다.

즉, UX적으로 주는 이점을 저울질 했을 때, 밑과 같이 결론지은 것입니다.

깜빡임 개선 > 조금이라도 빠른 로딩 속도

(이 부분은 코드를 작성하면 또 글을 올리겠습니다.)

결론적으로, 도허티 임계 + Progress Indicator + 기술 글 을 바탕으로,
내가 정리한 로딩 UX 설계 기준 조합은 다음과 같습니다.

• 0 ~ 0.2초: 아무것도 노출하지 않음

• 0.2 ~ 1초: Skeleton UI (최소 200ms 유지)

• 1 ~ 3초: 스피너 or 애니메이션

• 3 ~ 9초: 프로그래스 바

• 10초 이상: 정확한 백분율 표시기

• 정적 진행률 표시기: 사용 X

물론 일반적인 예시로, 필요에 따라 하나가 아닌 여러가지를 조합하면 더 좋을 것입니다.

🍀 마무리하며

어찌보면 정말 사소한 부분입니다.

단 1초도 안 되는 찰나의 순간, 그 인식을 조금 더 나아지게 만들기 위해
관련된 원칙과 사례들을 찾아보고 고민하면서,
이 작은 개선을 위해 얼마나 세심한 시선과 설계가 필요한지를 깨달을 수 있었습니다.

또, 사용자 경험은 눈에 보이지 않는 추상적인 개념으로,
“UX를 개선했다”는 말은 쉽게 할 수 있습니다.
하지만 실질적인 근거를 담기 위해선 단순한 감각이 아닌, 깊이 있는 고민과 반복적인 검증이 필요하다는 것을 체감했습니다.
그리고 제가 이전에는 얼마나 이 부분을 가볍게 넘겨왔는지를 돌아보게 되었습니다.

🌐 참고 링크

• Progress Indicators Make a Slow System Less Insufferable
• 무조건 스켈레톤 화면을 보여주는게 사용자 경험에 도움이 될까요?
• 로딩 화면을 어떻게 보여줄까?