웹 요청은 브라우저에서 컨트롤러로 바로 들어오지 않고 DNS, TCP, TLS, HTTP, CDN/WAF, Load Balancer, Reverse Proxy, Application, DB/외부 API를 지난다.
장애 대응의 첫 질문은 “왜 실패했는가”보다 “요청이 어느 계층까지 도달했고 누가 응답을 만들었는가”다.
백엔드 개발자는 curl, access log, trace id, 브라우저 DevTools, 인프라 로그를 연결해 추측을 검증 가능한 가설로 바꿔야 한다.
핵심 정리
전체 요청 지도는 Web-Network 문서들의 기준점이다. DNS 문서는 이름 해석을, TCP/TLS 문서는 연결과 암호화 경계를, HTTP 문서는 메시지 의미를, Proxy/LB 문서는 애플리케이션 앞단의 응답 주체를 설명한다.
HTTP 응답을 받았다는 사실은 요청이 “어떤 계층”까지 도달했다는 뜻이지, 반드시 애플리케이션 코드가 실행됐다는 뜻은 아니다. CDN, WAF, Gateway, Reverse Proxy도 403, 429, 502, 503, 504를 만들 수 있다.
App log에 요청이 없으면 애플리케이션이 정상이라는 뜻이 아니라, 요청이 앱 앞단에서 끝났거나 로그 연결 키가 끊긴 것일 수 있다. CDN/LB/proxy/app 로그를 request id나 trace id로 연결해야 한다.
curl -w의 DNS, connect, TLS, first byte, total 시간은 장애 계층을 줄이는 빠른 증거다. first byte만 길면 앱 처리, DB, 외부 API, lock, pool을 보고, connect가 길면 TCP, 방화벽, 라우팅을 먼저 본다.
브라우저는 단순 HTTP 클라이언트가 아니다. 서버가 200을 반환해도 CORS, SameSite, Secure cookie, mixed content, CSP, cache 정책 때문에 JavaScript에는 실패처럼 보일 수 있다.
좋은 장애 가설은 계층, 증상, 증거, 검증 방법, 다음 행동을 포함한다. “네트워크 문제 같다”가 아니라 “Gateway가 backend target을 unhealthy로 보고 502를 반환하는지 target health와 probe log로 확인한다”처럼 말해야 한다.
헷갈리는 지점
5xx가 보이면 애플리케이션 예외라고 단정하기 쉽다. HTTP status code는 최종 결과일 뿐 응답을 만든 계층을 알려 주는 충분한 증거가 아니기 때문이다.
핵심 판단 포인트는 Server, Via, X-Cache, LB/proxy access log, app access log를 함께 보며 응답 주체를 좁히는 것이다.
curl이 성공하면 브라우저도 정상이어야 한다고 생각하기 쉽다. curl은 브라우저의 CORS, cookie, mixed content, CSP 정책을 적용하지 않기 때문이다.
핵심 판단 포인트는 DevTools Network/Console에서 Origin, preflight OPTIONS, Set-Cookie blocked reason, response header를 확인하는 것이다.
App log에 요청이 없으면 백엔드가 볼 일이 없다고 착각하기 쉽다. 실제로는 backend port, health check, WAF rule, proxy rewrite 같은 백엔드 운영 경계에서 막혔을 수 있기 때문이다.
핵심 판단 포인트는 “우리 코드가 실행됐는가”보다 “우리 서비스 경계까지 요청이 왔는가”를 먼저 확인하는 것이다.
장애 중에 원인을 빨리 말하는 것이 능숙함이라고 오해하기 쉽다. 검증되지 않은 원인 선언은 팀 간 확인 범위를 흐리고 잘못된 rollback을 유도할 수 있다.
핵심 판단 포인트는 확인한 정상 계층, 아직 모르는 계층, 다음 검증 명령을 분리해서 말하는 것이다.
확인 질문
웹 요청 흐름을 전체 지도로 보는 이유는 무엇인가?
장애를 DNS, TCP, TLS, HTTP, CDN/WAF, LB, proxy, application, DB/외부 API, browser policy 중 어느 구간의 문제인지 좁히기 위해서다.
HTTP 응답을 받았다는 사실만으로 알 수 있는 것은 무엇인가?
요청이 응답을 만든 어떤 계층까지는 도달했다는 점이다. 그 계층이 애플리케이션인지 edge/proxy인지 확인하려면 헤더와 계층별 로그가 필요하다.
request id나 trace id가 중요한 이유는 무엇인가?
여러 계층에 흩어진 로그 조각을 같은 요청으로 묶어, 요청이 어디까지 갔고 어느 지점에서 상태와 지연이 바뀌었는지 확인할 수 있기 때문이다.