True lies of Optimistic UI - 옵티미스틱 UI의 계산된 거짓말

True lies of Optimistic UI - 옵티미스틱 UI의 계산된 거짓말

2016. 12. 8. 07:55ㆍUI 가벼운 이야기
Joe Park

이 글은 Denys Mishunov가 2016년 11월 SMASHING MAGAZINE에 게재한 글입니다. 피엑스디에서 저자의 서면 허락을 받고 번역, 게재하였으며, 저자의 허락없이 복사하여 사용하는 것은 절대 안됩니다.

원문 링크: "True lies of Optimistic UI" by Denys Mishunov
SMASHING MAGAZINE, November 15th, 2016

들어가며 - 세 UI의 이야기

세 UI(User Interface)는 술집에 간다. 첫 UI는 술을 한 잔 주문하고, 그 후로도 몇 번 더 주문한다. 몇 시간 후, 그는 계산을 하고 취해서 술집을 나선다. 또다른 UI는 한 잔을 시키면서 계산을 먼저하고, 이후로도 먼저 계산하고 마시기를 반복하다 취해서 술집을 나간다. 마지막 UI는 술집에 들어서자마자 취해서 바로 다시 나온다. - 그는 술집에서 늘 일어나는 뻔한 상황을 잘 알고 있으며, 시간을 낭비할 만큼 한가하지 않다. 여러분은 이 UI의 이야기를 들어본 적이 있는가? 그가 바로 “옵티미스틱 UI(Optimistic UI)”다.

옵티미스틱 UI(Optimistic UI)는 '낙관적으로 웹을 보는 것'이 아니다 – 아니, 적어도 거기에 그치는 것은 아니다.

최근, 프론트엔드 개발과 UX에 관련된 다수의 컨퍼런스에서 심리학적 퍼포먼스 최적화(psychological performance optimization)에 대해 논의하면서, 필자는 옵티미스틱 UI(Optimistic UI)에 대한 논의의 자리가 너무 없다는 것에 적잖이 놀랐다. 솔직히 말하자면, 개념에 대한 정의조차 잘 되지 않은듯 하다. 본 글에서는, 이 개념에 깔려있는 관점과 심리학적 배경, 그리고 몇 가지 예시를 살펴보려고 한다. 그리고 이런 UX 테크닉의 적용에 대한 우려의 시각들과 시사점도 정리해보고자 한다.

시작에 앞서 한가지 진실을 고백하자면, “옵티미스틱 UI(Optimistic UI)”라는 특정한 인터페이스의 형태는 없다. 형태보다는 인터페이스를 구현하는 관점, 즉, 멘탈 모델mental model로 이해하는 것이 낫다. 이제 옵티미스틱 UI(Optimistic UI) 디자인의 역사와 흐름을 살펴보자.

초기: 옛날 옛적에

아주 오래 전 — “트윗 Tweet”이 새가 지저귄다는 의미로 쓰이고, 애플은 파산 위기에 놓였으며, 사람들은 여전히 명함에 팩스 번호를 찍고 있을 때 — 웹 인터페이스는 있는 그대로의 과정을 정직하게 보여주었다. 액션의 성공을 미리 예측할 수 있는 힌트나 좋은 느낌을 갖기 어려웠다. 예를 들어, 버튼의 인터랙션은 다음 과정을 거쳤다.

1. 사용자가 버튼을 클릭하면,

2. 버튼이 비활성화 상태로 바뀐다.

3. 서버에 신호가 가면,

4. 서버에서는 다시 페이지로 응답을 보낸다.

5. 응답 결과를 보여주는 페이지가 새로 로딩된다.

옛 인터페이스는 성공을 예측하는 신호나 좋은 느낌을 찾기 어려웠다.

2016년 현시점에서 보면 이는 꽤나 비효율적으로 보인다. 그러나, 놀랍게도 여전히 이같은 시나리오는 많은 웹페이지와 애플리케이션에서 발견되고 있으며, 많은 제품의 인터랙션 과정의 일부로 작용한다. 이런 인터랙션은 예측이 가능하고 오류가 나타날 가능성이 적기 때문이다: 사용자는 서버로 신호가 간 것을 알고 있으며(비활성화된 버튼이 이를 알려준다.), 서버가 응답을 하면 페이지가 업데이트되면서 이러한 클라이언트-서버-클라이언트 인터랙션이 끝났음을 확실하게 보여준다. 하지만 이런 종류의 인터랙션에서 나타나는 문제점들은 분명하다:

첫째, 사용자의 인내심이 필요하다. 이쯤 되면, 서버 최소 응답시간이 해당 페이지 뿐 아니라 브랜드 이미지 전체에 부정적인 영향을 미친다는 것을 알 수 있다.

둘째, 응답은 꽤나 공격적인데(기존 페이지의 업데이트가 아닌 새로운 페이지 업로드), 이는 작업 중이던 사용자의 맥락을 끊고, 몰입을 깨트린다. 멀티태스킹을 하고 있지 않더라도 이러한 갑작스런 맥락의 끊김이 달갑지는 않다. 따라서, 액션이 본질적으로 맥락의 전환을 의도하는 것이 아니라면(온라인 지불 같은 경우, 전환이 자연스럽게 이루어진다.), 그런 식의 응답은 사용자와 시스템 간의 대화에 찬물을 끼얹게 될 것이다.

근래: 좋았던 날들

이 후, 소위 웹2.0이 등장하였다. XMLHttpRequest와 AJAX를 통해 웹페이지 간에는 새로운 인터랙션 방식이 이루어졌다. 이러한 인터랙션은 “spinners(진행중임을 나타내는 팽이같은 지표, 이하 스피너)”를 통해 완전해졌다: Progress Indicator(진행중을 나타내는 지표)의 가장 깔끔한 포맷인 스피너는, 사용자에게 시스템이 작업을 수행하느라 바쁘다는 것을 알려주고자 만들어진 도구이다. 이제는 서버에서 응답을 받은 후 페이지를 다시 로딩할 필요가 없어졌다; 대신, 이미 만들어진 페이지의 일부를 업데이트 해주기만 하면 된다. 이는 웹을 훨씬 다이나믹 하게 만들어주는 동시에, 더 자연스럽게 사용자를 끌어들이는 사용자경험이 가능하게 했다. 이제 버튼을 이용한 인터랙션의 전형적인 모습은 이렇게 바뀌었다:

1. 사용자가 버튼을 누르면,

2. 버튼이 비활성화 되면서, 스피너가 버튼 위에 보이고 시스템이 진행중임을 알려준다.

3. 서버에 신호가 가고,

4. 서버에서 다시 페이지로 응답을 보낸다.

5. 응답에 따라 버튼과 페이지의 모습이 업데이트 된다.

이 새로운 인터랙션 모델은 앞서 살펴본 예전 인터랙션의 문제점 중 한가지를 해결한다: 페이지의 업데이트가 공격적인 액션 없이 이루어져서 사용자가 맥락을 유지하면서 인터랙션에 몰입하기 훨씬 좋아진 것이다.

XMLHttpRequest와 스피너는 옛방식의 한가지 문제(서버 응답 후의 일방적인 맥락 전환)를 해결했다.

이러한 인터랙션 방식은 디지털 미디어에서 다양하게 사용 되었다. 하지만 여전히 한가지 문제가 있다: 사용자는 여전히 서버로부터의 응답을 기다려야 한다. 그렇다, 우리는 서버의 응답 속도를 더 빠르게 만들 수는 있지만, 그것이 얼마나 빨라지든, 여전히 사용자는 기다려야 하는 것이다. 다시 한번 말하지만, 사용자는 기다리기 싫어한다. 예를 들어, 한 조사에 따르면 78%의 소비자는 느리거나 신뢰도가 떨어지는 웹사이트에 대해 부정적인 감정을 표한다. 더욱이, Tealeaf(유명한 소프트웨어 회사) Harris Interactive에서 시행한 설문조사에 따르면, 23%의 사용자는 휴대폰에 대고 욕을 한 적이 있으며, 11%는 소리를 질렀고, 4%는 온라인 거래를 하며 문제가 발생되자 정말로 핸드폰을 집어던졌다고 한다. 이런 문제들의 발단은 시간 지연이다.

78%의 소비자는 느리거나 신뢰도가 떨어지는 웹사이트에 대해 부정적인 감정을 표한다.

이제는 정말 참신한 방법으로 보여주지 않는 이상, 사용자가 기다리는 동안 진행중 지표를 보여주는 것만으로는 충분치 않다. 대부분의 경우, 사람들은 스피너가 시스템의 느린 정도를 보여주는 것으로 인식하게 되었다. 스피너는 수동적인 기다림, 즉, 사용자가 서버 응답을 기다리거나 탭/앱을 종료하는 것 외의 선택권이 없다는 의미로 받아들여진다. 그러니 우리는 여기서 한단계 더 발전하는 인터랙션을 논의해 보고자 한다; 옵티미스틱 UI(Optimistic UI)의 개념부터 살펴보자.

옵티미스틱 UI(Optimistic UI)

앞서 이야기 했듯이, 옵티미스틱 UI(Optimistic UI)는 human-computer interaction에 대응하는 한 가지 방법에 지나지 않는다. 여기 깔린 핵심 아이디어를 이해하기 위해 우리는 “사용자가 버튼을 누른다”는 시나리오를 계속 가져갈 것이다. 하지만 그 과정을 낙관적으로 만드는 원리는 다른 대부분의 인터랙션에서와 크게 다르지 않다. Oxford English Dictionary에 따르면:

낙관적 Optimistic, 형. 미래에 대해 희망과 확신이 있는

그럼 “미래에 대한 확신” 부분부터 시작해보자.

다음의 질문을 생각해보라: 당신의 서버 응답은 얼마나 자주 에러가 나는가? 예를 들어, 당신이 버튼을 클릭할 때 API가 자주 실패하는가? 아니면 링크를 클릭할 때? 솔직히 말해, 나는 그렇게 생각하지 않는다. 물론 이것은 당신이 프론트엔드 개발자나 UX 전문가로서 개입하고 싶지 않은 것들, 즉, API, 서버로딩, 오류에 대응하는 수준과 다른 기타 요소에 따라 다양하게 나타날 수 있다. 하지만 API가 안정적이고 예측가능한 수준이며, 프론트엔드가 UI에 적절한 액션을 취하는 한, 유저가 처음에 취한 행동에 대한 응답으로 오류가 뜰 확률은 상당히 낮을 것이다. 필자가 봤을 때는 오류 상황이 1-3%정도에 머무른다. 이는 다시 말하자면, 97-99%의 경우에 사용자가 웹사이트에서 버튼을 클릭 했을 때 서버의 응답은 오류없이 성공적으로 돌아온다는 것이다. 이는 좀 더 색다른 관점으로 볼 필요가 있다:

옵티미스틱 UI(Optimistic UI)는 유저가 버튼을 클릭 했을 때, 서버 응답이 97-99% 성공적으로 돌아온다는 가정에 기반한다.

다음을 잠시 생각해보라: 우리가 97-99%의 성공 응답을 확신할 수 있다면, 우리는 미래의 응답 상황에 있어 확신이 있는 것이다. — 아니면, 적어도 슈뢰딩거의 고양이(물리학자 에르빈 슈뢰딩거의 양자역학 실험으로, 불완전함을 상징한다)의 미래보다는 훨씬 큰 확신이 있는 것이다. 우리는 버튼 인터랙션에 대해 완전히 새로운 이야기를 써 내려갈 수 있는 것이다:

1. 사용자가 버튼을 클릭한다.

2. 버튼은 곧바로 성공을 알리는 시각적 상태로 바뀐다.

바로 이거다! 적어도 사용자의 관점에서는, 그것이 전부다. — 기다리는 것도, 비활성화된 버튼을 쳐다보는 것도, 그렇다고 짜증을 일으키는 또다른 스피너와 마주하는 것도 아니다. 인터랙션은 끊김이 없으며, 시스템이 중간에 끼어들어와 유저에게 손을 흔드는 일도 없다.

옵티미스틱 UI(Optimistic UI)는 비활성화 버튼이나 스피너를 거절한다.

개발자 관점에서의 완전한 사이클은 다음과 같을 것이다:

1. 사용자가 버튼을 클릭 한다.

2. 버튼은 곧바로 성공을 알리는 시각적 상태로 바뀐다.

3. 서버에 신호가 간다.

4. 서버에서 페이지로 응답을 보낸다.

5. 97-99%의 경우, 우리는 응답이 성공적일 것임을 알기에, 사용자를 방해할 필요가 없다.

6.단지 실패한 응답의 경우에만 시스템은 목소리를 낼 것이다. 지금 당장은 이에 대해 걱정하지 말라. — 이 부분에 대해서는 본 글의 후반부에서 다룰 예정이다.

낙관적 인터랙션의 몇가지 예시를 살펴보자. 당신은 아마도 페이스북이나 트위터에서 보이는 “좋아요” 버튼에 꽤 익숙할 것이다. 트위터부터 살펴보도록 하자.

시작은 당연히 버튼을 클릭하는 것이다. 그러나 사용자가 더이상 버튼을 누르고 있거나 마우스를 올려놓지 않을 때의 시각적 상태에 주목하라. 단숨에 성공모드로 바뀌어 있다!

좋아요 버튼이 클릭 되면, 트위터는 곧바로 성공을 알리는 시각적 상태로 바뀐다.

그렇다면 같은 시각, 브라우저의 개발 툴에서 “네트워크”탭에는 무슨 일이 일어나고 있는지 확인해보자.

버튼의 시각적 상태는 아직 진행중인 서버 요청과는 달리 업데이트 되었다.

“네트워크”탭에서는, 서버 요청이 보내졌지만 아직 진행중임을 볼 수 있다. “좋아요” 숫자는 아직 증가하지 않았지만 서버 응답을 받기도 전에 색의 변화와 인터페이스는 유저에게 명확하게 성공을 이야기 하고 있다.

서버로부터 성공적인 응답을 받은 후, 숫자는 업데이트 되지만 변화는 색의 즉각적인 변화에 비해 미묘하다. 이는 유저에게 기다림을 인지하지 않으면서, 매끄럽고 방해받지 않는경험을 제공한다.

좋아요 버튼은 시각적으로 성공 상태를 보이지만, 숫자는 서버의 응답이 성공을 알린 후에야 업데이트 된다.

또다른 예시는 페이스북 고유의 좋아요 버튼에서 보여주는 낙관적 인터랙션이다. 버튼의 색 뿐 아니라 숫자도 서버의 응답을 기다리지 않고 곧바로 바뀐다는 점을 빼곤 꽤 유사한 시나리오다.

페이스북은 버튼의 시각적 상태와 함께 숫자도 즉시 업데이트한다는 점에서 차이를 보이지만, 트위터와 같은 낙관적 인터랙션을 취한다.

그래도 한가지 주목할 점이 있다. 서버의 응답시간을 확인해보면, 1초를 조금 넘는 것을 볼 수 있다. RAIL model recommends(퍼포먼스에 관한 사용자 중심의 모델)에서 간단한 인터랙션에 적합한 응답시간이 100밀리세컨드(0.1초)라는 것을 생각해보면, 이것은 보통의 상황에서는 너무 긴 시간으로 여겨진다. 그러나 이 상황에서 사용자가 대기 시간을 인지하지 못하는 것은 인터랙션의 낙관적인 특성 덕분이다. 아주 좋다! 이는 psychological performance optimization의 또다른 예시라고 할 수 있다.

하지만 직시하자: 여전히 1-3%의 확률로 서버는 오류 상태로 돌아올 것이다. 혹은 단순히 유저가 오프라인일 수도 있다. 혹은, 더 가능성 있는 경우는, 기술적으로는 서버가 성공응답을 보내지만 여전히 클라이언트에 의해 더 진행되어야 하는 정보가 포함되어 있는 경우다. 결과적으로, 유저는 실패를 알려주는 사인을 받진 않겠지만, 우리는 그것을 성공응답이라고 볼 수도 없다. 이런 경우를 대응하기 위해서 우리는 왜, 그리고 어떻게 옵티미스틱 UI(Optimistic UI)가 심리학적으로 작동하는지 부터 먼저 이해해야 한다.

옵티미스틱 UI(Optimistic UI) 뒤에 깔린 심리

아직까지도, 나는 앞서 이야기했던 소셜 네트워크에서의 낙관적 인터랙션에 대해 불만을 표한 사람의 얘기를 들어본 적이 없다. 그런 점에서, 옵티미스틱 UI(Optimistic UI)가 제대로 작용된다고 해보자. 하지만 어떻게 사용자에게 이것이 먹히는 것일까? 그것은 정말 단순히 사람들이 기다리는 것을 싫어하기 때문이다. 그게 전부다! 이제 이 글의 다음 파트로 넘어가도 된다.

하지만 아직 당신이 이 글을 읽고 있다면, 아마도 왜 이런 일이 일어나는 것인지에 대해 궁금할지도 모르겠다. 그러니 조금 더 깊게 들어가서 심리학적 관점으로 접근해보자.

뇌연구는 옵티미스틱 UI(Optimistic UI)뒤에 깔린 심리를 이해하는 데에 도움을 준다.

옵티미스틱 UI(Optimistic UI)는 심리학적 분석의 가치가 있는 다음의 2가지 기본 재료를 가진다:

• 사용자의 액션에 대한 빠른 응답

• 서버, 네트워크, 또는 어느 곳에서든 발생하는 잠재적 실패에 대한 대응

사용자의 액션에 대한 빠른 응답

우리가 옵티미스틱 UI(Optimistic UI)디자인을 이야기할 땐, human-computer interaction에서의 최적화된 응답시간을 이야기하는 것이다. 그리고 이런 종류의 커뮤니케이션에 대한 제안은 그 옛날 1968년 즈음부터 시작했다. 당시 Robert B.Miller는 자신의 세미나 글 “Response Time in Man-Computer Conversational Transactions 인간-컴퓨터 대화형 상호작용의 응답시간”을 발표하면서, 유저가 컴퓨터로부터 받을 수 있는 17가지 종류의 응답에 대한 정의를 내렸다. 그 중 Miller가 “활성화 작용을 통제하기 위한 응답” — 자판을 뗄 때부터 시각적 피드백이 나타나기까지의 지체 — 이라 칭하는 한 종류가 있다. 그 옛날 1968년에도 그 과정은 0.1-0.2초를 넘으면 안되는 것이었다. 그렇다, RAIL model은 이를 처음 주장하지 않았다 — 이러한 권유는 50여 년전부터 시작되었다. 그래도 밀러는 이렇게 짧은 피드백의 지연조차 능숙한 사용자들에게는 너무 느린 것이라고 말했다. 이것은, 이상적으로 볼 때 사용자가 자신의 액션에 대해 100밀리세컨드 내외에 인지해야함을 의미한다. 이는 인간의 몸이 수행할 수 있는 가장 빠른 무의식적 행동의 범주에 들어간다 — 바로 눈의 깜빡임이다. 이러한 이유로, 100밀리세컨의 시간 단위는 그 즉시로 인지된다. 런던 대학 신경학 연구소University College London’s Institute of Neurology의 Davina Bristow는 “대부분의 사람은 분당 15번 정도 눈을 깜빡이며 깜빡임은 평균 100-150 미리세컨 정도 유지된다.”라고 했으며 이는 우리가 1년에 9일 정도의 시간을 눈을 깜빡이는 데에 소비함을 의미한다.

그 즉각적인 시각적 반응(실제 요청이 끝나기도 전에)으로 인해 옵티미스틱 UI(Optimistic UI)는 psychological performance optimization에서 쓰인 조기완료 테크닉의 예시가 되었다. 하지만 사람들이 눈을 깜빡이는 것처럼 반응하는 인터페이스를 좋아한다는 사실은 우리 대부분에게 정말 놀라운 일은 아니다. 그리고 이를 달성하는 것은 어려운 일 또한 아니다. 과거에도 우리는 버튼이 클릭된 그 즉시 더이상 눌리지 않도록 만들었고, 이는 종종 사용자의 인풋을 인식하게 만들기에 충분했다. 하지만 인터페이스 요소의 비활성화 상태는 수동적 기다림을 의미한다: 사용자는 아무 것도 할 수 없으며 그 과정에 대해 통제할 수 없다. 그리고 이는 사용자에게 절망적인 것이다. 이것이 우리가 옵티미스틱 UI(Optimistic UI)에서 비활성화 상태를 통째로 건너뛰는 이유이기도 하다 — 우리는 사용자가 기다리도록 하는 대신에 낙관적 결과로 소통하는 것이다.

잠재적 실패에 대응하다

이제는 옵티미스틱 UI(Optimistic UI)디자인에 있어 두번째로 흥미로운 심리학적 측면에서 —잠재적 실패에 대한 대응— 을 살펴보자. UI 오류에 대응할 수 있는 최선의 방법에 대한 정보와 글은 많다. 이 글의 후반부에서 실패에 대응하는 법에 대해 다룰 텐데, 옵티미스틱 UI(Optimistic UI)에 있어 가장 중요한 점은 우리가 오류를 '어떻게 대응 하냐'가 아니라, '언제 대응하냐'이다.

인간은 본능적으로 자신의 활동에 대한 주목적 혹은 부차적 목적을 세우고, 그 활동의 달성까지를 하나의 덩어리로 분류한다. 가끔 우리는 이 덩어리들을 “사고의 흐름”, “사고의 몰입”, 또는 단순하게 “몰입”이라고 부른다. 이 몰입의 상태는 최상의 즐김, 열정적인 집중력과 창의적인 집중이라는 특징을 가진다. 몰입상태에 젖어있을 동안 사용자는 그 활동에 완전히 빠져있게 된다. Tammy Everts의 트윗은 이를 아주 잘 표현한다:

(트윗내용: 몇시간 동안 눈을 깜빡이는 것을 까먹는다는 점만 빼면, 난 몰입 상태의 모든 것이 좋다. 이 그림은 지금 내 눈알의 상태다.)
가끔, 몰입 상태에 빠진 사람을 발견하기란 꽤 쉬운 일이다.

웹 상에서 그러한 활동의 덩어리가 유지되는 시간은 훨씬 짧다. 여기서 잠시 Robert B.Miller의 연구로 다시 돌아가보자. 그가 명시한 응답 유형은 다음을 포함한다:

• 나열된 정보형태의 단순한 요청에 대한 응답

• 그래픽 형태의 복잡한 요청에 대한 응답

• “시스템, 너 내 말 알아 들었니?”에 대한 응답

그는 이 모두를, 사용자가 관련성 있는 응답을 받기 까지 걸리는 2초 내외의 시간단위로 묶는다. 더 깊이 파고들 것도 없이 우리는 이런 시간 간격이 사람의 작업 메모리(사람이 머릿속에 특정 양의 정보를 담아둘 수 있고, 더 중요하게는 통제할 수 있는 시간)에 따라 달렸다는 점을 알아두어야 한다. 우리 개발자와 UX전문가들에게 있어 이것은 요소와 인터랙션을 하는 2초의 시간동안 유저는 몰입상태에 빠지고 그들이 기대하는 응답에 초점을 맞추고 있을 것임을 의미한다. 이 기간 동안 서버가 오류를 응답하게 되면, 말하자면 사용자는 계속해서 인터페이스와 대화중인 것이다. 이것은 두 사람간의 대화에서 당신이 무언가 말을 했는데 상대가 부드럽게 당신의 의견에 반대하는 것과 비슷하다. 상대가 오랫동안 동감하는 듯이 고개를 끄덕이다가(UI가 성공 상태를 알리는 지표를 보이는 것과 같다) 마지막에는 “아니”라고 이야기한다고 상상해보라. 어색하지 않은가? 그래서 옵티미스틱 UI(Optimistic UI)는 몰입상태의 2초 내외에서 실패를 알려야 하는 것이다.

옵티미스틱 UI(Optimistic UI)는 유저에게 조심스럽지만 명확하게 실패를 알려야한다. 가장 중요한 것은, 그것이 유저의 몰입 상태에서 2초 내외로 이루어져야 한다는 것이다.

옵티미스틱 UI(Optimistic UI)에서 실패에 대응하는 법에 대한 심리학을 기억하고, 이제 요청이 실패한 1-3%를 살펴보자.

옵티미스틱 UI(Optimistic UI) 디자인의 비관적 측면

아직까지 내가 들은 가장 흔한 소견은 옵티미스틱 UI(Optimistic UI)디자인이 black pattern 같다는 것이다 — 속임수라는 것이다. 다시 말해서, 그 방법을 도입함으로써 우리는 인터랙션의 결과에 대해 사용자에게 거짓말을 한다는 것이다. 법적으로 보면, 어떤 법원이라도 이런 의견에 손을 들어줄 것이다. 하지만 여전히 필자는 이 기술을 예측이나 희망이라고 생각한다. (“낙관적”의 정의를 기억하는가? 이 점이 우리에게 “희망”이라는 여지를 줄 수 있는 부분이다.) “거짓말”과 “예측”의 차이점은 당신이 그 1-3%의 실패된 요청에 어떻게 대응하는지에서 온다. 이제 트위터의 낙관적 “좋아요” 버튼이 오프라인에서 어떻게 나타나는지 살펴보자.

먼저, 옵티미스틱 UI(Optimistic UI)의 패턴을 따라 버튼은 클릭하자 마자 성공 상태로 전환된다 — 이번에도, 유저가 온라인인 상태에서의 버튼과 똑같이, 사용자가 더 이상 버튼을 누르거나 왔다갔다 하는 경우 없이 말이다.

오프라인일 때, 트위터의 좋아요 버튼은 여전히 클릭 후 시각적으로 업데이트 된다.

하지만 사옹자가 오프라인이기 때문에, 요청은 실패한다.

그래서 사용자의 몰입 상태 안에서 실패는 최대한 빨리 알려져야 한다. 이번에도 그러한 몰입 상태가 지속되는 시간은 2초이다. 트위터는 아주 간단하게도 버튼의 상태를 되돌리는 것으로 최대한 미묘하게 알려준다.

요청이 실패한 후, 트위터는 아무 소란스러움 없이 미묘하게 좋아요 버튼의 시각적 상태를 되돌린다.

아주 세심한 독자는 여기서 이러한 실패 대응법에서 한단계 더 나아가, 사용자에게 요청이 보내지지 않았거나 오류가 발생했다고 알릴 수 있다고 얘기할 것이다. 이것은 시스템을 가능한 한 투명하게 만들 수 있다. 하지만 몇가지 유의할 점이 있다:

어떤 종류의 알림이라도 화면에 갑자기 나타나는 것은 사용자의 맥락을 전환할 것이며, 이는 그들에게 실패 뒤에 가려진 이유에 대해 분석하도록 할 텐데, 이 이유는 아마 오류 메시지에서 나타날 것이다.

어떤 종류의 오류 메시지나 알림과 같이, 이 또한 사용자를 새로운 맥락에서 다음 액션을 취할 수 있는 정보를 제공함으로써 가이드를 제시해야 한다.

그러한 액션을 취할 수 있는 정보는 또다른 맥락을 만들어낼 것이다.

그렇다, 이쯤에서 우리는 모두 이 과정이 점점 복잡해져 감을 인정할 수 있다. 이러한 오류 대응법이, 예를 들어, 아주 큰 형태의 웹사이트에서는 합리적으로 여겨지겠지만 , 버튼을 누르는 것과 같은 단순한 액션에 대해서는 과잉이다 — 기술적인 개선의 필요나 유저의 작업 메모리 측면 모두에서 말이다.

따라서, 우리는 옵티미스틱 UI(Optimistic UI)의 실패에 대해서 열려있어야 하며 우리의 낙관성이 거짓말이 되지 않도록 최선을 다해 알려주어야 한다. 하지만 이는 맥락에 따라 이루어져야 한다. 실패한 좋아요에 대해선 미묘하게 버튼을 원래의 상태로 되돌려 놓는 것으로 충분하다고 보여진다 — 남자친구나 여자친구의 상태에 좋아요를 누르는 것이 아닌 이상은 말이다. 그런 경우는 애초에 좋아요가 실패하면 큰일날테니.

극도의 비관론

또다른 의문점이 생길 수 있다: 만약에 사용자가 성공을 알리는 지표는 얻었지만 서버로부터 응답이 돌아오기 전에 브라우저 탭을 닫는다면 어떤 일이 생길까? 최악의 경우는 사용자가 서버에 요청이 보내지기도 전에 탭을 닫는 경우일 것이다. 하지만 사용자가 극도로 날렵하거나 시간을 늘이는 능력이 있지 않는 한 이것은 거의 불가능하다.

만약 옵티미스틱 UI(Optimistic UI)가 제대로 작동하고, 인터랙션이 2초이상 서버 응답을 대기하지 않는 요소에만 적용된다면, 사용자는 브라우저탭을 그 2초 안에 닫아야 할 것이다. 그것은 자판을 누르는 방법으로는 그리 어려운 일은 아니다; 하지만 우리가 살펴 보았듯, 97-99%의 경우에 요청은 탭이 열려있든 아니든 성공적일 것이다.(단지 클라이언트에게그 응답이 돌아가지 않을 뿐이다.)

따라서 이 문제점은 서버 오류가 뜨는 1-3%의 사람들에게만 나타날 것이다. 그렇다면 다시, 2초 안에 서둘러 탭을 닫는 사람은 얼마나 되는가? 탭 닫기 대회에 참가한 것이 아닌 이상, 필자는 그 수가 그렇게 엄청날 것 같진 않다. 하지만 이것이 만약 당신의 특정 프로젝트와 연관되고 부정적 결과를 가져오게 된다면, 사용자 행동을 분석할 수 있는 툴을 써보아라; 그러한 시나리오의 확률이 충분히 높다면, 낙관적 인터랙션을 중요하지 않은 요소들에 한정 하라.

필자는 의도적으로 요청이 인위적으로 연장된 케이스에 대해서는 언급하지 않았다; 이 경우들은 옵티미스틱 UI(Optimistic UI)디자인의 상황과 일반적으로 맞지 않는다. 더욱이, 우리는 비관적 측면에 필요 이상의 시간을 보냈으니, 이제는 좋은 옵티미스틱 UI(Optimistic UI)의 시행과 관련된 주요 포인트를 요약해보자.

경험의 법칙

(Rule of thumb, 체계적인 이론이 아닌 경험에 의거한 법칙)

필자는 진심으로 본 글이 옵티미스틱 UI(Optimistic UI)디자인의 뒤에 숨겨진 주요 개념을 이해하는 데에 도움이 되기를 바란다. 어쩌면 당신은 다음 프로젝트에서 관심을 갖고 이 접근을 시도해 볼지도 모른다. 그렇다면, 시작하기 전에 기억해야할 것들이 몇가지 있다:

우리가 여지껏 이야기 해온 모든 것들에 앞서: 당신이 사용하는 API가 안정적이며 예측가능한 결과값을 보여주는지 확실하게 확인하라. 이 부분은 충분히 얘기한 것 같다.

해당 인터페이스는 서버에 요청이 보내지기 전에 잠재적 오류와 문제점을 발견해야 한다. 하지만 더 좋은 것은, API의 오류에서 올 수 있는 모든 것을 제거하는 것이다. UI 요소가 간단할 수록 그를 낙관적으로 만드는 것 또한 간단해 질 것이다.

낙관적 패턴을 성공 또는 실패 응답 이상을 기대할 수 없는 이분법적인 요소들에 적용하라. 예를 들어, 버튼의 클릭이 “예”, “아니오”, 또는 “어쩌면”과 같은 서버 응답을 가정한다면(모든 경우가 다양한 정도로 성공을 의미할 수 있는), 그러한 버튼은 낙관적 패턴이 없는 것이 낫겠다.

당신의 API의 응답시간을 알라. 이것은 중요하다. 특정한 요청에 대한 응답시간이 절대 2초 밑으로 내려가지 않는다는 것을 알면, 먼저 API에 약간의 낙관성을 더하는 것이 최선일 것이다. 언급했듯이, 옵티미스틱 UI(Optimistic UI)는 서버 응답시간이 2초 미만일 때 가장 잘 작동한다. 그 이상 넘어가는 것은 예상치 못한 결과를 낳게 되고 유저는 좌절할 것이다. 스스로에게 경고장을 던졌다고 생각하면 된다.

옵티미스틱 UI(Optimistic UI)는 단순히 버튼 클릭에 관한 것이 아니다. 이 접근은 페이지 로딩을 비롯한 페이지의 라이프 사이클 동안에 발생하는 다양한 인터랙션들과 이벤트들에 적용될 수 있다. 예를 들어, skeleton screens(역자: 유저에게 진행이 즉각적으로 이루어진다는 느낌을 주기 위해 빈 페이지에서 차례차례 페이지 요소가 채워지는 화면)는 같은 관점을 따른다: 당신은 서버가 성공응답을 보낼 것이라 예측하고 유저에게 보이는 화면을 먼저 채워나간다.

옵티미스틱 UI(Optimistic UI) 디자인은 사실 웹에서 새로운 것이라고 볼 수는 없으며, 우리가 확인했듯이 특별히 진보된 기술도 아니다. 이는 단지 당신의 제품에 대해 인지되는 수행능력을 관리하는 것을 돕는 또다른 접근이자 멘탈 모델이다. human-computer interaction의 심리학적 측면에서 기반한 옵티미스틱 UI(Optimistic UI)디자인은 지혜롭게만 활용한다면, 아주 적은 노력을 들이면서 끊김없는 웹 경험을 만드는 것을 도울 수 있다. 하지만 이 패턴을 진짜 효과적으로 만들면서 사용자들에게 거짓말하는 제품이 되는 것을 막으려면, 우리는 옵티미스틱 UI(Optimistic UI)디자인의 작동원리에 대해 반드시 이해할 필요가 있다.