웹 앱의 동작이 예측 불가능할 때 확인 순서

웹 앱이 예측 불가능하게 작동하면 운영 중에 작은 이상 신호도 빨리 분리해서 봐야 한다. 문제를 크게 잡으면 해결 시간이 오래 걸린다.

핵심은 문제 해결 전체 흐름에서 원인을 좁히는 것이다. 재현 조건, 로그, 응답처럼 눈으로 확인할 수 있는 값들을 먼저 모아야 한다.

처음 보이는 증상 파악하기

문제의 흐름을 먼저 끊어서 본다. 특히 재현 조건이 명확하지 않으면 다른 부분을 고쳐도 결과가 바뀌지 않을 수 있다.

• 언제 문제가 발생하는가?
• 어떤 액션을 했을 때 발생하는가?
• 모든 상황에서 발생하는가, 특정 경우에만 발생하는가?

이 세 가지를 명확히 하면 범위를 크게 줄일 수 있다.

원인을 나누는 기준

로그를 확인하면 에러의 출처를 파악할 수 있다. 클라이언트 에러인지, 서버 에러인지, 아니면 네트워크 에러인지 구분해야 한다.

npm run build

프로덕션 빌드로 테스트하는 것이 중요하다. 로컬 개발 서버와 프로덕션 빌드는 다르게 작동할 수 있다.

설정을 먼저 확인하기

환경 변수, 빌드 설정, 런타임 설정 중 하나가 빠졌거나 잘못되었을 가능성이 높다. 정상 상태를 먼저 정해둬야 한다.

그래야 현재 상태가 정상 상태와 정확히 무엇이 다른지 파악할 수 있다.

바로 확인할 값들

1. 브라우저 콘솔의 에러 메시지
2. 네트워크 탭의 API 응답
3. 로컬 스토리지와 세션 스토리지의 값
4. 서버 로그의 에러

이 네 가지를 모두 모아야 원인을 찾을 수 있다.

명령어로 보는 방법

변경한 코드가 실제로 배포되었는지 확인한다. 브라우저 캐시 때문에 예전 코드가 실행되고 있을 수도 있다.

사용자 영향을 먼저 파악하기

모든 사용자에게 영향을 주는가, 특정 사용자에게만 영향을 주는가? 이 정보만으로도 원인 후보를 줄일 수 있다.

결과를 해석하는 방법

테스트를 여러 번 반복해서 일관성이 있는지 본다. 일관성이 없다면 타이밍 문제거나 경합 상태일 수 있다.

체크리스트

1. 원래 증상이 같은 조건에서 다시 나는지 확인한다
2. 브라우저 콘솔과 네트워크 탭에서 에러를 본다
3. npm run build로 프로덕션 빌드를 테스트한다
4. 환경 변수와 설정을 확인한다
5. 로그에서 바뀐 부분을 한 줄로 설명한다

마지막에는 실제 화면이나 공개 URL까지 확인해야 작업이 끝난다. 관련 기록을 짧게라도 남겨두면 다음 확인이 훨씬 빨라진다.