운영 중 에러 좁히는 체계

운영 중 에러는 정보가 부족하다. 사용자 보고만으로는 재현 조건을 알 수 없고, 로그도 여러 줄 중 어디를 봐야 하는지 막막하다. 문제를 크게 잡으면 모든 파일이 의심스러워진다.

먼저 현재 상태 파악하기

에러가 뜨자마자 손대기 전에 현재 상황부터 정리한다. 사용자가 언제 어떤 화면을 봤는지, 에러는 즉시 떴는지 재현되는지 같은 정보를 모은다. 로그, 응답, 네트워크 요청 중 눈에 보이는 부분부터 스크린샷을 남겨둔다.

로컬과 운영 비교하기

로컬에서 괜찮던 코드도 배포 환경에서는 다를 수 있다. 먼저 로컬에서 같은 조건을 만들어 재현하고, 그다음 운영 환경의 설정을 확인한다.

• 환경 변수 값
• 데이터베이스 상태
• 캐시 레이어 상태
• 의존성 버전

작은 변수부터 고정하기

"가능한 모든 원인"을 생각하다 보면 시간을 낭비한다. 대신 한 가지씩 확인하고 고정한다. 빌드 결과가 맞는지, 설정이 제대로 로드되는지, 데이터가 예상대로 들어오는지를 순서대로 본다.

# 빌드 결과 확인
npm run build

# 환경 설정 확인
echo $NODE_ENV

# 로그 실시간 추적
tail -f /var/log/app.log | grep -i error

응답과 로그에서 증거 남기기

"뭔가 안 된다"보다는 "응답 코드가 500인데 로그에는 XXX라고 적혀 있다"라고 적으면 나중에 훨씬 빨리 같은 상황을 진단할 수 있다.

• 응답 코드와 메시지
• 요청을 보낸 사용자 ID나 세션
• 타임스탬프
• 당시 서버 메모리/CPU 상태

한 번에 하나씩만 바꾸기

"이거도 시도, 저거도 시도"하면서 여러 설정을 동시에 수정하면 어느 것이 통했는지 알 수 없다. 한 가지만 고치고 재현되는지 확인한다. 그다음 롤백하고 다른 것을 시도한다.

최종 확인: 사용자 관점

문제를 고쳤다고 생각하면 사용자 경로를 다시 따라가본다. 화면이 제대로 뜨는지, 데이터가 저장되는지, 에러 메시지는 없는지 직접 본다. 로그만 깔끔해도 화면이 틀렸을 수 있다.

마지막으로, 이번 에러의 원인과 해결 과정을 짧게라도 남겨둔다. 같은 패턴이 또 나올 때 첫 번째보다 훨씬 빠르게 처리할 수 있다.