Optimistic UI, 서버를 기다리지 않는 디자인

한 줄로

사용자가 좋아요를 누르면 즉시 빨갛게 변하고, 그 다음에 서버에 알립니다. 실패하면 롤백합니다. 이게 optimistic UI입니다.

어디서 왔나

전통적 UI 패턴은 다음과 같습니다. 사용자가 좋아요를 누르면 로딩 스피너를 표시하고, 서버에 요청하고, 서버 응답을 기다리고, 응답 받으면 화면을 업데이트합니다.

문제는 응답이 늦으면 사용자가 "안 눌렸나?" 다시 누른다는 점입니다.

Optimistic UI 패턴은 "서버가 성공할 거라고 낙관적으로 가정"합니다. 사용자가 좋아요를 누르면 즉시 빨간 하트를 표시하고, 백그라운드에서 서버 요청을 보내고, 만약 실패하면 롤백과 에러 메시지를 띄웁니다.

이 패턴은 Twitter가 2015년경 본격 적용하면서 표준 용어가 됐습니다. 그 전부터 Facebook, Instagram이 비슷하게 동작했지만 "optimistic UI"라는 이름이 굳어진 건 그 무렵입니다.

작동 조건

이 패턴이 잘 작동하는 조건은 다음과 같습니다.

성공률이 매우 높은 동작(95%+).
실패해도 큰 손실 없음(좋아요는 OK, 결제는 NO).
롤백이 가능(UI를 이전 상태로 되돌릴 수 있어야 함).
사용자에게 명확히 알릴 수 있음(실패 시 알림).

좋은 사용처는 좋아요·즐겨찾기, 게시물 작성(서버 저장은 백그라운드), 메시지 전송(보낸 직후 회색으로, 확인되면 진하게)입니다.

나쁜 사용처는 결제(실패하면 사용자가 두 번 결제할 수 있음), 삭제(잘못 알리면 데이터를 잃은 것처럼 보임), 민감한 데이터 수정(보안 비밀번호 변경 등)입니다.

구현 도구

React + SWR / TanStack Query: 자동 optimistic update 지원.
Apollo Client: GraphQL의 optimistic response.
Redux: 미들웨어로 직접 구현.

바이브 메이커가 챙길 한 가지

본인 도구의 자주 누르는 동작에 optimistic UI를 적용하면 체감 속도가 크게 올라갑니다. 사용자는 0.5초의 차이를 명확히 느낍니다. 단, 실패 시 알림이 명확해야 합니다. 사용자가 좋아요가 사실 안 됐다는 걸 모르면 더 나쁩니다.

관련

Doherty Threshold, Skeleton screen, Toast