낙관적 로딩과 낙관적 저장 바로 옆 어딘가에는 앱을 더 빠르게 체감하게 만드는 또 다른 기법이 존재한다. 바로 낙관적 커밋이다.

Flickr가 좋은 예다. 사진 업로드 화면으로 이동하면 일종의 대기실 같은 공간에 들어서게 되는데, 거기서 큰 Upload 버튼을 누르기 전에 사진을 끌어다 놓고 순서를 바꾸며 이름과 태그를 붙이는 등 업로드를 미리 준비할 수 있다.

하지만 Flickr는 사용자가 결국 그 버튼을 누를 것이라고 낙관적으로 가정하고, 사진을 끌어다 놓는 순간부터 무거운 사진 파일들을 백그라운드에서 천천히 업로드하기 시작한다.

다른 모든 낙관적 기법과 마찬가지로, 사용자에게 더 친절해지는 만큼 Flickr의 디자이너와 엔지니어에게는 일이 복잡해진다. 어쨌든 사용자가 실제로 업로드를 확정하면 여전히 정식 업로드 모달이 나타나니까 말이다…

…그래서 조용한 스테이징 영역에서의 업로드와 공식적으로 보이는 업로드라는 두 가지 상태를 조율하고 계속 동기화해야 한다.

또한 낙관적으로 시작했다가 결국 취소된 업로드는 서버에서 정리해야 한다.

마지막으로 안내 표시(signposting) 문제가 있다. 데이터 전송이 실제로는 일어나지 않는 것처럼 현실을 단순화하는 가벼운 낙관적 로딩 기법들과 달리, 여기서의 낙관적 커밋은 작은 인디케이터를 통해 실제로 눈에 보인다:

나는 이러한 투명성이 반갑다고 생각한다. 과거에 Meta(또 누구겠는가!)는 낙관적 커밋을 남용했다가 곤욕을 치른 적이 있다:

페이스북에서 친구 담벼락에 바로 올리려고 동영상을 촬영했다가 마음에 들지 않아 버리고 다시 찍은 적이 있는가? 그 민망한 초안 영상은 삭제됐다고 생각했을지 모르지만, 페이스북은 복사본을 보관하고 있었다. 회사는 이를 ‘버그’ 탓으로 돌리며 이제는 버려진 동영상들을 삭제하겠다고 맹세한다. 이번에는 정말이라고 새끼손가락까지 걸고 약속한다.

이런 맥락에서 Flickr가 데이터가 서버로 전송되고 있음을 분명히 알려주는 것은 좋은 일이다. 신뢰를 쌓는 데 도움이 된다고 생각한다.

투명성에 더해, 이 과정이 업로드 진행 상황을 매우 정밀하게 보여준다는 점도 좋다고 생각한다. 파일 간의 진행 상황뿐만 아니라 각 파일 내부의 진행 상황까지 말이다. 인터넷 연결 속도는 지역마다 다를 뿐 아니라 같은 장소에서도 상황에 따라 크게 달라지기 때문에, 이는 실제로 매우 유용하다. 클라우드로의 자동 저장은 연결이 장시간 끊기지 않는 한 굳이 사용자를 신경 쓰게 할 필요가 없는 경우가 많지만, 지금 같은 상황에서는 마법 같은 처리보다 명확함이 더 낫다고 느껴진다.