옵티미스틱 UI

누른 뒤 서버 응답을 기다리는 동안 화면은 멈춘 것처럼 보입니다. 0.6초는 숫자로 보면 짧지만 손끝으로는 깁니다. 문서 이름을 고치면 불러오는 중임을 알리는 로딩 상태로 원이 잠깐 돌다가 새 이름이 나타나는데, 이름 다섯 개를 이어서 고치는 사람은 그 원을 다섯 번 기다리게 됩니다.

이 기다림은 대개 헛것이었습니다. 이름 바꾸기 요청이 실패하는 경우는 백 번에 한 번도 되지 않습니다. 나머지 아흔아홉 번을 위해 모든 사용자가 매번 응답을 기다리는 셈입니다.

그래서 순서를 뒤집는 방식이 나왔습니다. 대개 성공할 일이라면 성공한 모습을 먼저 보여 주고 드물게 실패했을 때만 되돌리는 쪽이 낫다는 계산입니다.

세 단계로 돌아갑니다.

1. 사용자가 무언가를 하면 서버에 요청을 보내면서 화면을 성공한 모습으로 바로 바꿉니다. 이름을 고쳤으면 목록에 새 이름이 그 자리에서 나타나고, 좋아요를 눌렀으면 숫자가 바로 올라갑니다.
2. 응답이 성공으로 돌아오면 화면에서는 아무 일도 일어나지 않습니다. 이미 맞는 모습이 떠 있기 때문입니다.
3. 실패로 돌아오면 바꿨던 화면을 이전 모습으로 되돌리고, 문제가 생겼음을 알리는 오류 상태를 그 자리에 붙입니다. 조용히 되돌려 놓기만 하면 사용자는 자기가 한 일이 사라진 이유를 모릅니다.

3번을 할 수 있으려면 바꾸기 전의 값을 들고 있어야 합니다. 이름을 고치기 전의 이름, 좋아요를 누르기 전의 숫자를 어딘가에 남겨 두고 실패하면 그것으로 되돌립니다. 서버가 만들어 주는 값이 있으면 그 자리는 임시값으로 채워 두고 응답이 온 뒤에 갈아 끼웁니다.

쓸 자리는 두 조건으로 가릅니다. 실패가 드물어야 하고, 되돌려도 사용자가 잃는 것이 없어야 합니다. 결제, 삭제, 메일 보내기 같은 동작은 두 번째 조건에 걸립니다. 보냈다고 표시한 뒤에 되돌리면 사용자는 이미 상대가 받았다고 믿은 상태이고, 그 신뢰는 회전하는 원 0.6초보다 훨씬 비쌉니다.

"이름 바꾸기는 옵티미스틱으로 갑시다. 실패하면 되돌리면 돼요."

실패가 드물고 되돌려도 손해가 없는 동작이라는 판단입니다.

"삭제는 옵티미스틱 쓰지 마세요. 지웠다고 보여 준 뒤에 되살아나면 더 이상합니다."

되돌림 자체가 사용자에게 손해가 되는 자리라는 지적입니다.

"실패했을 때 그냥 원래대로 돌아가기만 해요. 왜 안 됐는지 알려 줘야 합니다."

되돌리면서 이유를 알리지 않으면 사용자가 자기 조작을 의심한다는 요청입니다.

페이지덱에서는 민서와 태오가 목록 화면의 동작을 둘로 나눴습니다. 이름 바꾸기와 즐겨찾기는 옵티미스틱으로 바꿔 기다림을 없앴고, 문서 삭제는 서버 응답을 기다린 뒤에 목록에서 지웁니다.