로딩 인디케이터는 이벤트 관점에서 사용자경험에 긍정적인 경험을 줄까?

로딩 인디케이터는 제품에서 사용자의 기다림을 완화하여, 작업이 진행중임을 알리는 핵심적인 요소입니다. 단순한 디자인 요소로 보이지만, 이벤트 중심 시스템에서 사용자와 애플리케이션 사이에서 소통을 돕는 중요한 역할을 합니다. 버튼 클릭, API 호출, 페이지 네비게이팅 등 다양한 이벤트의 결과를 시각적으로 피드백하며 사용자가 현재 상태를 이해하고 대처할 수 있도록 돕습니다.

이벤트 발행(Event Emission)과 로딩 인디케이터

1. 사용자 행동으로 인한 이벤트 발행

로딩 인디케이터는 사용자가 특정 행동(버튼 클릭, 검생 등등..)을 수행한 직후, 이벤트가 발행되었음을 알리는 신호탄의 역할을 합니다. 이 신호는 사용자가 본인의 요청이 시스템에서 처리 중임을 이해하게 만듭니다.

리액트를 사용하는 웹 프론트엔드에서 사용자가 로그인 버튼 클릭을 수행하면, 로딩 상태를 발행하는 이벤트 setLoading(true)를 발행합니다. 이 이벤트는 사용자가 로그인 버튼을 클릭했음을 알리는 신호이며, 로딩 인디케이터는 이 신호를 받아 로딩 상태를 표시하게 됩니다.

2. 비동기 작업의 진행 상태 전달

이벤트는 백엔드에서 발생하는 작업(데이터 조회, 파일 업로드 등)의 진행 상태를 프론트엔드로 전달합니다. 이를 통해 로딩 인디케이터는 작업의 시작과 끝을 시각적으로 명확하게 표시할 수 있습니다.

로그인 작업이 완료되면 로딩 상태가 종결되었다는 이벤트 setLoading(false)를 발행합니다. 이 이벤트는 로딩 인디케이터가 로딩 상태를 종료하고 원래 상태로 돌아가도록 합니다.

위 두가지 예시에서도 알 수 있듯이 이벤트 중심 시스템에서 로딩 인디케이터는 사용자가 특정 행동을 수행한 직후, 이벤트가 발행되었음을 알리는 신호로 사용됩니다.

Event Driven Architecture에서 둘중에 어떤걸 선택해야 할까?

Event Driven Architecture는 시스템이 이벤트 중심으로 동작하며, 데이터의 상태 변화와 작업 처리가 이벤트를 통해 비동기적으로 이루어지는 구조입니다. 이 관점에서 UI 설계는 이벤트의 결과를 Eventual Consistency(최종적 일관성)에 따라 표시해야 하며, 사용자 경험을 개선하기 위한 전략도 고려해야합니다.

로딩 인디케이터

로딩 인디케이터는 시스템에서 특정 이벤트(API 호출, 데이터 저장)가 처리 중임을 알리는 신호로 사용됩니다.

장점

• 사용자는 자신의 요청이 처리되고 있음을 인식하고, 작업이 중단되지 않았음을 확인할 수 있습니다.
• 비동기 작업중 특히 작업이 오래걸리는 경우 사용자가 혼란을 느끼지 않도록 할 수 있습니다.

단점

• 로딩 인디케이터는 사용자에게 대기해야한다는 메시지를 전달하지만, 다른 작업을 방해하는 요소입니다.
• 네트워크 지연이나 작업 실패 시, 부정적인 경험으로 이어질 수 있습니다.

낙관적 업데이트

낙관적 업데이트는 시스템에서 특정 이벤트(API 호출, 데이터 저장)가 처리가 성공적으로 완료될것이라고 가정하고 UI를 즉시 업데이트하는 전략입니다.

장점

• 사용자는 즉각적인 결과를 확인 할수 있어 시스템이 더욱 빠르고 직관적이라고 느낄 수 있습니다.
• 응답을 기다릴 필요 없이 UI가 즉시 업데이트 되므로 사용자의 행동의 흐름을 중단하지 않습니다.

단점

• 시스템이 이벤트 처리 실패한경우 초기 상태로 되돌려야하며, 이는 복잡도를 증가시킬 수 있습니다.
• 결과가 실패한 경우 사용자에게 혼란을 줄 수 있습니다.

도허티의 임계법칙(Dothity's Threshold)과 시스템 응답 시간

도허티의 임계법칙은 시스템의 응답 시간과 사용자의 생산성 간의 관계를 설명하는 중요한 원칙중 하나로, 사용자와 시스템 간의 상호작용 속도를 400ms이하로 유지해야 한다는 개념입니다.

이 기준을 충족하면 사용자는 시스템이 즉각적이고 반응이 빠르다고 느끼며, 그이상 시간이 걸리면 인내심이 줄어들며 사용자 경험이 저하된다고 안내합니다.

이 법칙에 따르면

• 0.4초 미만: 사용자는 시스템이 즉각적으로 반응한다고 느낍니다.
• 0.4초 ~ 2초: 사용자는 지연을 느끼지만, 작업의 흐름은 유지됩니다.
• 2초 이상: 사용자의 집중력이 흐트러지고 생산성이 저하됩니다.

이러한 임계값들은 로딩 인디케이터와 낙관적 업데이트 전략 선택에 중요한 기준이 됩니다:

• 0.4초 미만의 작업: 낙관적 업데이트가 적합합니다. 로딩 인디케이터를 표시하는 것이 오히려 불필요한 시각적 노이즈가 될 수 있습니다.
• 0.4초 ~ 2초의 작업: 상황에 따라 두 전략 모두 사용 가능합니다. 작업의 중요도와 실패 시 복구 비용을 고려해야 합니다.
• 2초 이상의 작업: 반드시 로딩 인디케이터를 사용하여 진행 상황을 표시해야 합니다. 가능한 경우 진행률도 함께 표시하는 것이 좋습니다.

EDA와 eventual consistency의 맥락에서 선택하기

한 국가에서만 제공하는 서비스에서 글로벌 서비스로 확장되는 경우, Event Driven Architecture는 분산 시스템을 효과적으로 관리할 수 있는 매력적인 시스템 설계입니다. 지리적으로 분산된 사용자들에게 일관된 서비스를 제공하면서도 시스템의 확장성과 유연성을 확보할 수 있기 때문입니다.

Event Driven Architecture 시스템에서 이벤트는 이미 발생한 과거의 사건을 의미하며, 이는 변경할 수 없는 사실(immutable fact)로 취급됩니다. 시스템의 모든 상태 변화는 이벤트를 통해 전파되며, 결과는 eventual consistency에 따라 처리됩니다. 이러한 특성을 고려할 때, UI/UX 설계에서 로딩 인디케이터와 낙관적 업데이트 중 선택은 다음에 따라 달려져야합니다.

작업의 중요도와 신뢰성

• 중요도가 높고 실패가 치명적인 작업이라면 로딩 인디케이터를 사용하는것이 좋습니다.
• 실패해도 복구가 비교적 쉬운 작업이라면 낙관적 업데이트를 사용하는것이 좋습니다.

즉 시각적인 피드백이 강조되어야 하는 경우에는 로딩 인디케이터를 사용하며, 사용자와 즉각적으로 상호작용을 강조해야 하는 경우에는 낙관적 업데이트를 사용해야합니다.

결론

도허티의 임계 법칙은 사용자 경험을 설계하는 데 있어 중요한 원칙입니다. 이 법칙은 사용자가 시스템의 응답을 400ms 이내에 받을 경우, 시스템과의 상호작용이 끊기지 않고 매끄럽게 느껴진다고 강조합니다. 이는 특히 Event-Driven Architecture(EDA)와 같은 비동기 환경에서 더 큰 의미를 가집니다.

물론 절대적인것은 아니며, 시스템 설계와 상황에 따라 다르게 적용되어야 합니다. EDA 환경에서 UI는 이벤트의 eventual한 상태를 고려하여 설계가 되어야합니다. 로딩 인디케이터와 낙관적 업데이트는 상호 배타적인 선택지가 아니며, 서비스의 성격에 따라 적절히 혼합하여 사용하는것이 중요합니다.