React 낙관적 업데이트, 롤백보다 먼저 정할 오류 처리 기준

“저장 버튼을 누르자마자 목록은 바뀌었는데, 실패하면 어디까지 되돌려야 할까?”

“네트워크 오류가 나면 저장 실패인지, 응답만 못 받은 것인지 어떻게 구분하지?”

“같은 항목을 연달아 수정했을 때 이전 요청이 나중에 돌아오면 화면은 무엇을 보여줘야 하지?”

낙관적 업데이트에서는 화면을 빨리 바꾸는 것보다 서버 결과가 불확실한 동안 임시 변경을 어떻게 보관하고 확정할지를 먼저 정해야 합니다. 롤백은 모든 오류에 적용하는 동작이 아니라, 서버 거절과 결과 미확정, 충돌을 구분한 뒤 선택하는 복구 정책입니다.

관리자 화면처럼 상태 변경이 잦은 기능에서는 즉시 반영한 값과 서버가 마지막으로 확인한 값을 같은 상태로 취급하지 않는 편이 좋습니다. 알레오에서 프론트엔드 개발자로 웹 서비스의 화면 경험과 사용자 흐름을 다루는 관점에서도, 이 둘이 섞이면 오류 안내와 재시도 흐름이 빠르게 복잡해집니다.

낙관적 업데이트는 언제 롤백해야 할까요?

서버가 변경을 명확히 거절했을 때는 롤백을 검토하고, 요청 결과를 알 수 없을 때는 곧바로 원상 복구하지 말고 확인 가능한 상태로 남겨야 합니다. 화면에서 같은 오류처럼 보여도 사용자가 다음에 취할 행동은 달라지기 때문입니다.

낙관적 업데이트는 사용자의 작업 직후 임시 화면 상태를 먼저 보여 주는 방식입니다. React의 상태 관리 방식이나 사용하는 데이터 처리 도구와 무관하게, 임시 변경과 서버 확인 데이터를 구분하는 기준은 별도로 필요합니다.

오류를 아래처럼 나누면 롤백 기준을 정하기 쉽습니다.

예를 들어 공개 여부를 바꾸는 토글이 서버의 검증이나 권한 조건 때문에 거절됐다면, 이전 값으로 되돌리고 저장되지 않은 이유를 알려주는 흐름을 설계할 수 있습니다. 반면 타임아웃에서는 서버가 요청을 받지 못했는지, 처리했지만 응답을 돌려주지 못했는지 화면만으로 판단하기 어렵습니다.

이때 즉시 롤백하면 실제 서버 값과 화면 값이 다시 엇갈릴 수 있습니다. 저장 확인 중처럼 불확실성을 드러내고, 재조회 또는 중복 실행 위험을 고려한 재시도 중 무엇을 제공할지 정하는 편이 낫습니다.

왜 원본 데이터를 바로 덮어쓰면 오류 처리가 어려워질까요?

마지막으로 확인한 데이터와 대기 중인 변경을 분리해야 실패한 요청만 제거하거나 최신 상태를 다시 확인할 수 있습니다. 원본 배열이나 객체를 곧바로 바꾸면 구현은 짧아도, 어떤 요청을 되돌려야 하는지 추적하기 어려워집니다.

목록 항목의 상태를 바꿀 때는 변경 후 값뿐 아니라 다음 정보를 남겨 둘 필요가 있습니다.

1. 어떤 항목을 바꿨는가
2. 변경 전의 확인 값은 무엇인가
3. 어떤 요청이 이 임시 변경을 만들었는가
4. 요청이 대기, 성공, 실패 중 어디에 있는가
5. 실패하면 이전 값으로 복원할지, 최신 데이터를 다시 받을지

예를 들어 confirmedData와 optimisticChanges를 분리하는 구성을 생각할 수 있습니다. 화면은 확인 데이터를 기본으로 그리고, 대기 중인 변경만 별도 레이어로 적용합니다. 성공 시에는 확인 데이터를 갱신하고 해당 임시 변경을 제거합니다. 실패 시에는 그 임시 변경만 제거하거나 실패 상태로 남길 수 있습니다.

이 구조가 모든 화면의 정답은 아닙니다. 변경 범위가 작고 동시 수정 가능성이 낮은 단일 토글이라면 변경 전 값을 지역적으로 보관하는 방식도 충분할 수 있습니다. 다만 목록 수정, 정렬 변경, 여러 필드 저장처럼 요청이 겹칠 수 있는 화면에서는 원본과 임시 변경을 나눠 두는 편이 복구 규칙을 설명하고 확장하기 쉽습니다.

같은 항목을 연달아 수정하면 무엇을 기준으로 확정해야 할까요?

같은 대상의 변경 요청이 겹칠 때는 응답 도착 순서만으로 화면을 확정하지 말고, 사용자의 마지막 의도와 서버의 확인 값을 함께 기준으로 삼아야 합니다. 오래된 요청의 응답이 나중에 도착해 새 화면을 덮어쓰지 않도록 규칙을 정해야 합니다.

가령 상태를 대기 → 처리 중 → 완료로 빠르게 바꾸는 흐름을 생각해 볼 수 있습니다. 첫 요청의 처리가 늦고 두 번째 요청이 먼저 끝났을 때, 첫 응답을 그대로 반영하면 화면이 사용자가 마지막으로 고른 값과 다른 상태로 돌아갈 수 있습니다.

이런 기능에서는 다음 선택지를 기능 특성에 맞춰 검토할 수 있습니다.

• 대상별 요청 식별자를 둡니다. 항목 ID와 요청 ID를 연결해 현재 대기 중인 변경과 무관한 응답을 화면 확정에서 제외합니다.
• 같은 항목의 연속 변경을 제한합니다. 저장 중에는 관련 조작을 잠시 막거나, 마지막 변경만 보내는 방식을 고려할 수 있습니다.
• 최신 서버 상태를 확인하는 시점을 정합니다. 순서가 중요하거나 여러 사용자가 같은 데이터를 바꿀 수 있다면, 성공 응답만으로 끝낼지 재조회를 할지 정해야 합니다.

삭제와 복원, 순서 변경, 권한 변경처럼 앞선 작업의 의미를 다음 작업이 바꿀 수 있는 기능은 항목 단위의 요청 직렬화가 더 단순할 수 있습니다. 반대로 서로 독립적인 행을 수정하는 표라면 모든 요청을 막기보다 행별 대기와 실패 상태를 분리해 보여 주는 편이 작업을 덜 방해할 수 있습니다.

오류 메시지와 재시도는 어떻게 연결해야 할까요?

오류 메시지는 실패 사실뿐 아니라 사용자가 지금 할 수 있는 행동과 데이터의 신뢰 상태를 알려야 합니다. 저장에 실패했습니다만으로는 다시 시도해도 되는지, 값을 고쳐야 하는지, 최신 데이터를 불러와야 하는지 판단하기 어렵습니다.

오류 UI를 설계할 때는 다음을 확인해 보세요.

• 어떤 항목의 어떤 변경이 실패했는가
• 화면이 이전 값으로 돌아갔는가, 저장 여부를 확인 중인가
• 재시도가 같은 변경을 중복 실행할 가능성은 있는가
• 최신 상태를 다시 불러오는 행동이 필요한가

서버가 입력을 거절한 경우에는 같은 요청을 반복하기보다 수정할 내용을 알려주는 편이 맞을 수 있습니다. 일시적인 연결 문제라면 재시도가 의미 있을 수 있지만, 변경 API가 중복 실행을 어떻게 처리하는지 정하지 않은 상태에서 자동 재시도를 붙이면 의도하지 않은 변경이 생길 수 있습니다. 재시도 정책은 API의 중복 처리 방식과 함께 결정해야 합니다.

오류를 인라인으로 보여 줄지 토스트로 알릴지도 영향 범위에 따라 달라집니다. 한 행의 상태 변경 실패라면 해당 행 가까이에 오류와 다음 행동을 두는 편이 맥락을 보존합니다. 여러 화면에 영향을 주는 저장 실패라면 상단 알림과 함께 재조회 결과를 명확히 보여 주는 구성이 더 이해하기 쉬울 수 있습니다.

결론

낙관적 업데이트의 품질은 화면을 얼마나 빨리 바꾸는지가 아니라, 서버 결과가 불명확할 때도 사용자가 현재 상태를 오해하지 않게 하는 데 달려 있습니다. 롤백부터 정하기보다 실패를 서버 거절, 결과 미확정, 충돌로 나누고 각 경우의 복구 행동을 정하세요.

구현 전에는 아래 순서로 점검하면 됩니다.

1. 이 변경은 실패 시 즉시 이전 값으로 돌아가도 안전한가
2. 응답을 받지 못했을 때 서버 반영 여부를 어떻게 확인할 것인가
3. 같은 항목의 요청이 겹치면 무엇을 최신 의도로 볼 것인가
4. 확인 데이터와 대기 중인 변경을 분리해야 하는가
5. 사용자에게 재시도, 수정, 재조회 중 무엇을 제공할 것인가

롤백은 오류 처리의 시작일 뿐입니다. 더 중요한 기준은 불확실한 요청을 확정된 결과처럼 보이지 않게 만드는 것입니다.

자주 묻는 질문

낙관적 업데이트를 모든 저장 기능에 적용해도 될까요?

아니요. 실패했을 때 사용자가 혼란 없이 복구할 수 있는 변경부터 적용하는 편이 좋습니다. 임시 반영이 업무상 위험을 키우거나 확정 전 표시가 오해를 낳는 기능은 먼저 복구 흐름을 설계해야 합니다.

타임아웃이 발생하면 무조건 롤백하면 안 되나요?

아니요. 타임아웃만으로는 서버가 요청을 처리하지 않았다고 단정하기 어렵습니다. 즉시 이전 값으로 돌리기보다 저장 확인 중 상태를 보여 주고, 기능 특성에 맞춰 재조회 또는 재시도를 제공하는 방식을 검토하세요.

React의 useOptimistic만 쓰면 롤백 설계가 해결되나요?

아니요. 임시 UI 상태를 다루는 도구와 API 오류의 의미, 연속 요청의 확정 규칙은 별개로 설계해야 합니다. 상태 전이, 서버 확인 시점, 실패 복구 정책은 기능마다 달라질 수 있습니다.

목록 화면에서는 항목 전체를 다시 불러오는 편이 나을까요?

상황에 따라 다릅니다. 단순한 변경은 해당 항목만 갱신할 수 있지만, 권한, 정렬, 다른 사용자의 수정처럼 주변 데이터에 영향을 주는 변경은 재조회가 더 적합할 수 있습니다.

제 도움이 필요하시다면

알레오에서 프론트엔드 개발자로 웹 서비스의 화면 경험과 사용자 흐름을 다루고 있습니다. 관리자 화면의 변경 기능에서 낙관적 상태와 확인 상태를 어떻게 나눌지, 오류와 재시도 화면을 어떤 순서로 둘지 검토가 필요하다면 실패 시나리오부터 함께 정리할 수 있습니다.

특히 목록 편집, 상태 변경, 콘텐츠 발행처럼 사용자의 작업이 연속되는 화면에서 상태가 꼬이거나 오류 안내가 모호한 경우에 적합합니다. 서비스와 운영 환경은 알레오 공식 웹사이트에서 확인할 수 있습니다.