← 전체 글로 돌아가기

웹 개발

낙관적 업데이트를 운영 중에 다시 보기

낙관적 업데이트는 편하지만, 배포 후 문제가 터졌을 때는 화면만으로는 원인을 알기 어렵다.

낙관적 업데이트(optimistic update)를 쓰면 사용자 경험이 좋아진다. 하지만 그만큼 문제가 복잡해진다. 화면에서는 업데이트된 것처럼 보이는데 서버에서는 다른 상태를 가지고 있을 수 있기 때문이다.

운영 중에 이런 불일치를 발견했을 때는 화면 하나만 봐서는 절대 원인을 찾을 수 없다. 로그와 실제 응답을 함께 봐야 한다.

사용자가 보는 것 vs 서버가 가진 것

낙관적 업데이트 문제는 항상 이 불일치에서 시작한다. 내가 학습한 확인 순서는:

  • 사용자가 보는 화면 상태
  • 서버의 실제 데이터 상태
  • 네트워크 요청 기록

이 세 가지를 함께 보면 대부분의 경우 원인을 찾을 수 있다.

빌드는 성공했는데...

코드는 문제없이 빌드됐는데 실행 결과가 이상하면, 보통 비동기 처리나 상태 동기화 문제다:

npm run build

빌드가 통과했다면 다음 단계는 개발자 콘솔에서 네트워크 탭을 열고 실제 요청을 관찰하는 것이다.

로컬과 운영의 차이를 기록하기

로컬에서는 정상인데 운영 환경에서 문제가 나오는 경우가 많다. 이럴 때는 환경 차이를 명확히 기록해둬야 한다. 캐시, 타이밍, 네트워크 조건 등이 영향을 줄 수 있다.

수정 전 확인 체크리스트

낙관적 업데이트를 수정하려고 할 때, 먼저 다음을 확인하자:

  1. 재현 조건이 명확한가?
  2. 같은 조건에서 다시 발생하는가?
  3. 로그에서 바뀐 부분을 한 줄로 설명할 수 있는가?

이 세 가지 중 하나라도 못 하면 아직 원인을 모르는 것이다. 더 관찰해야 한다.

기록하는 습관

낙관적 업데이트 같은 복잡한 기능은 수정한 내용을 반드시 기록해야 한다. 같은 실수를 반복하지 않기 위해서다.