AJAX 에러 원인, 응답 패턴으로 범인 찾기

가장 막막한 장애는 서버에서 아무 흔적도 찾을 수 없을 때 시작됩니다. 사용자는 “화면이 안 된다”고 말합니다. 그런데 서버 로그에 눈에 띄는 에러가 없습니다. APM 알림도 없고, API 에러율도 평소와 크게 다르지 않아 보입니다. 이때 문제는 서버가 아니라 관측 지점에 있을 수 있습니다. 사용자가 경험한 실패는 브라우저에서 발생했지만, 우리가 확인하는 지표는 서버에 도달한 요청을 중심으로 구성되어 있기 때문입니다. 즉, 범인이 숨어 있는 것이 아니라 처음부터 우리가 보고 있던 범위 밖에 있을 수도 있습니다.

‍

서버가 정상이어도 화면이 이상한 이유

웹 페이지가 브라우저에 뜬 뒤에도 화면은 계속 움직입니다. 검색창 자동완성, 장바구니 수량 갱신, 결제 버튼 응답처럼 화면 일부만 바뀌는 동작은 페이지를 새로 고치지 않고 서버와 데이터를 주고받는 AJAX(Asynchronous JavaScript and XML) 요청으로 이루어집니다.

문제는 사용자가 보는 화면의 성공 여부가 서버의 성공 여부와 항상 일치하지 않는다는 점입니다. 요청이 서버에 도달하기 전에 브라우저의 보안 정책이나 네트워크 환경에서 차단될 수 있고, 서버가 응답을 보냈더라도 브라우저가 그 응답을 받기 전에 페이지 이동, 네트워크 단절, 요청 취소가 발생할 수 있습니다.

이 경우 서버 로그만 보면 문제가 작아 보이거나 아예 보이지 않을 수 있습니다. 하지만 사용자 입장에서 버튼이 멈추고, 화면 일부가 비어 있고, 결제나 인증 단계가 진행되지 않는 문제로 나타납니다. 그래서 AJAX 에러를 볼 때는 서버 로그만이 아니라 브라우저에서 요청이 어떻게 끝났는지를 봐야 합니다.

‍

서버 로그만으로 설명하기 어려운 신호, 상태 코드 0

AJAX 에러를 볼 때 가장 까다로운 값 중 하나가 상태 코드 0입니다.

‍

HTTP 상태 코드는 원래 서버가 응답으로 내려주는 값입니다. 200은 성공, 401은 인증 실패, 404는 리소스 없음, 500은 서버 오류를 의미합니다. 그런데 상태 코드 0은 일반적인 HTTP 응답 코드가 아닙니다. 브라우저가 정상적인 HTTP 응답을 받지 못했거나, 응답을 사용할 수 없는 상태에서 표시되는 값에 가깝습니다.

그래서 상태 코드 0은 원인이 아니라 결과입니다. “서버가 0이라는 코드를 내려줬다”는 뜻이 아니라, 브라우저 입장에서 요청이 정상적인 응답으로 끝나지 않았다는 신호입니다.

대표적인 상황은 다음과 같습니다.

1. 타임아웃 요청을 보낸 뒤 정해진 시간 안에 응답을 받지 못해 클라이언트에서 요청을 종료한 경우입니다.
2. CORS 차단 다른 출처로 보낸 요청이 브라우저의 보안 정책에 의해 차단된 경우입니다. 서버가 응답했더라도 브라우저가 그 응답을 사용할 수 없으면 요청 실패처럼 보일 수 있습니다.
3. 네트워크 단절 사용자의 네트워크가 끊겼거나, 프록시·방화벽·VPN·모바일 네트워크 구간에서 연결이 중단된 경우입니다.
4. 요청 취소 페이지 이동, 컴포넌트 언마운트, 사용자 동작, 또는 JavaScript 코드의 abort() 호출로 요청이 중단된 경우입니다.

상태 코드 0이 까다로운 이유는 여기서부터입니다. 이 값만 보고는 원인을 단정할 수 없습니다. 서버에 요청이 도달하지 않았을 수도 있고, 서버는 응답했지만 브라우저가 응답을 받거나 사용할 수 없었을 수도 있습니다. 또는 사용자가 페이지를 떠나면서 요청이 중간에 취소되었을 수도 있습니다.

따라서 상태 코드 0을 봤다면 “서버가 왜 0을 내려줬을까?”가 아니라 “브라우저는 왜 정상적인 응답으로 처리하지 못했을까?”라고 질문을 바꿔야 합니다. 이때부터 상태 코드 하나만 보지 말고 발생 시점, 엔드포인트, 사용자 환경, 응답 시간 변화를 함께 봐야 합니다.

‍

응답 패턴으로 범인 좁히기

상태 코드 0을 포함한 AJAX 에러는 상태 코드 하나만으로 원인을 단정하기 어렵습니다. 대신 발생 패턴을 나눠 보면 확인해야 할 범위를 빠르게 좁힐 수 있습니다.

먼저 세 가지 질문으로 시작합니다.

첫 번째 질문. 언제부터 발생했는가?

특정 시점부터 갑자기 늘었다면 그 직전의 변화를 봅니다. 배포, API 변경, 인증·CORS 설정 변경, 인프라 변경이 출발점이 될 수 있습니다. 반대로 오래전부터 반복되던 문제라면 구조적인 지연이나 타임아웃 설정을 의심해볼 수 있습니다.

두 번째 질문. 어디서 발생했는가?

특정 엔드포인트에서만 반복된다면 해당 API를 먼저 봅니다. 여러 엔드포인트에서 동시에 발생한다면 인증, 공통 헤더, CORS, CDN, 네트워크 경로처럼 공통 레이어를 확인해야 합니다.

세 번째 질문. 누구에게 발생했는가?

특정 브라우저, 기기, 지역, 네트워크 환경에 집중된다면 사용자 환경의 차이를 봅니다. 브라우저 호환성, 모바일 네트워크, 프록시·방화벽, CDN 경로 문제가 후보가 될 수 있습니다.

세 질문은 따로 보는 것보다 조합해서 볼 때 더 유용합니다. 예를 들어 특정 시간대에만 몰린다면 서버 응답 시간과 클라이언트 타임아웃 설정값을 함께 봅니다. 특정 엔드포인트에서 반복된다면 API 변경 이력과 브라우저 콘솔의 CORS 오류를 확인합니다. 특정 지역이나 기기에서만 발생한다면 네트워크 경로, 프록시, 방화벽, 브라우저 호환성을 확인합니다.

응답 패턴은 원인을 바로 알려주지는 않습니다. 대신 어디부터 확인해야 하는지 알려줍니다. AJAX 에러를 볼 때 중요한 것은 “무슨 상태 코드인가”에서 멈추지 않고, “언제, 어디서, 누구에게 같은 방식으로 반복되는가”를 보는 것입니다.

‍

느려지다 에러가 났는가, 바로 에러가 났는가

에러는 응답 시간의 흐름과 함께 봐야 합니다. 응답 시간 변화 없이 에러가 갑자기 늘었다면 코드 변경, API 경로 변경, 인증 만료, 권한 정책 변경처럼 비교적 명확한 트리거가 있을 수 있습니다. 배포 직후라면 배포 전후의 에러 건수, 새로 등장한 상태 코드, 특정 엔드포인트 집중 여부를 먼저 비교합니다.

반대로 느린 응답이 먼저 늘어난 뒤 타임아웃이나 상태 코드 0이 뒤따라 나타났다면, 처리 지연이 사용자 실패로 번졌을 가능성이 있습니다. 서버 자원, DB 쿼리, 외부 API 호출, 클라이언트 타임아웃 설정을 함께 확인합니다.

‍

에러 비율과 경로를 함께 보세요

에러율은 숫자만으로 판단하기 어렵습니다. 같은 1%라도 결제, 로그인, 회원가입 같은 핵심 경로에서 발생하면 즉시 확인해야 할 문제입니다. 반대로 부가 기능에서 발생한 에러라면 사용자 영향도는 다를 수 있습니다. 그래서 AJAX 에러는 전체 에러율보다 어떤 화면과 사용자 행동에서 발생했는지를 먼저 봐야 합니다. 이 기준이 있어야 대응 우선순위를 정하기 쉽습니다.

‍

엔드포인트를 특정했다면 서버로 넘어가세요

문제가 반복되는 엔드포인트를 좁혔다면 그다음은 서버 처리 흐름을 확인합니다. 해당 API의 트랜잭션, DB 쿼리, 외부 호출, 캐시, 서버 자원 상태를 따라가며 병목이나 실패 지점을 찾습니다.

브라우저에서는 사용자가 경험한 실패가 보이고, 서버에서는 요청이 내부에서 어떻게 처리되었는지가 보입니다. 두 지점을 연결해야 “사용자는 실패했는데 서버만 보면 정상처럼 보이는” 간극을 줄일 수 있습니다.

‍

마치며

서버 로그가 깨끗한데 화면이 이상하다면, 서버 안에서만 원인을 찾으려 하지 않아도 됩니다. 사용자가 경험한 실패는 브라우저에서 먼저 드러날 수 있기 때문입니다. 상태 코드 0은 그중 하나의 신호입니다. 브라우저가 정상적인 HTTP 응답으로 처리하지 못했다는 뜻에 가깝고, 타임아웃, CORS 차단, 네트워크 단절, 요청 취소처럼 여러 원인으로 이어질 수 있습니다.

중요한 것은 상태 코드 하나로 원인을 단정하지 않는 것입니다. 언제부터 발생했는지, 어디서 반복되는지, 누구에게 집중되는지를 나눠 보고, 응답 시간의 변화와 사용자 경로를 함께 확인해야 합니다. 브라우저에서 시작한 단서를 서버 처리 흐름까지 연결할 수 있다면, “서버는 정상인데 화면은 이상한” 문제의 윤곽도 훨씬 빠르게 잡을 수 있습니다.

와탭 브라우저 모니터링 14일 무료 체험 시작하기

‍

더 읽을거리

와탭 브라우저 모니터링 공식 문서

MDN: HTTP 응답 상태 코드

MDN: 교차 출처 리소스 공유(CORS)

MDN: XMLHttpRequest