HTTP 502 vs 504: 게이트웨이 오류의 차이와 해결 방법

운영 환경에서 가장 당혹스러운 에러 중 하나가 500번대 게이트웨이 오류입니다. 특히 502(Bad Gateway)와 504(Gateway Timeout)는 비슷해 보이지만, 문제의 원인이 '연결 끊김'인지 '응답 지연'인지에 따라 대응 방식이 완전히 달라집니다.

1) HTTP 502 Bad Gateway (잘못된 게이트웨이)

502 오류는 중간 서버(Nginx, AWS ALB 등)가 업스트림 서버(백엔드 앱)로부터 **"유효하지 않은 응답"**을 받았을 때 발생합니다.

핵심 의미: "백엔드 서버와 통신은 시도했으나, 백엔드가 응답을 제대로 못 주거나 프로세스가 죽어 있다."
주요 원인:
- 백엔드 프로세스(Node.js, Spring, Python 등)가 다운됨
- 서버 재시작 중 요청이 들어옴
- 백엔드가 사용하는 포트가 닫혀 있거나 잘못 설정됨
- 메모리 부족(OOM)으로 프로세스가 즉시 킬(Kill)됨

504 오류는 중간 서버가 업스트림 서버에 요청을 보냈지만, "설정된 시간 내에 응답이 오지 않았을 때" 발생합니다.

핵심 의미: "백엔드 서버가 살아는 있지만, 작업을 처리하는 데 너무 오래 걸려서 중간 서버가 기다리다 포기했다."
주요 원인:
- 복잡한 DB 쿼리나 대량의 데이터 처리 로직
- 백엔드 애플리케이션의 성능 저하 (CPU/메모리 부하)
- 백엔드 내부에서 호출하는 외부 API의 지연
- Nginx나 로드밸런서의 proxy_read_timeout 설정이 너무 짧음

문제가 발생했을 때 가장 먼저 확인해야 할 흐름은 다음과 같습니다.

상태 코드 확인: 502인가 504인가?
백엔드 생존 확인 (502의 경우):
- 백엔드 프로세스가 떠 있는가?
- 포트 바인딩(0.0.0.0 vs 127.0.0.1)은 정확한가?
백엔드 로그 확인 (504의 경우):
- 특정 요청에서 응답 시간이 튀는가?
- DB Slow Query 로그에 찍히는 쿼리가 있는가?
인프라 설정 확인:
- 로드밸런서(ALB, Nginx)와 백엔드 간의 Keep-alive 설정이 맞는가?
- Timeout 설정이 애플리케이션의 처리 시간보다 긴가?

502가 무작위로 발생한다면: 백엔드 서버의 소켓 큐(Socket Queue)가 꽉 찼거나, Keep-alive 타임아웃 불일치를 의심해 보세요.
504가 특정 요청에서만 발생한다면: 해당 비즈니스 로직을 비동기(Background Job)로 전환하거나 쿼리를 튜닝해야 합니다.
클라우드 환경(AWS 등): ALB의 Idle Timeout 설정이 백엔드 서버의 타임아웃보다 길어야 504 대신 의도한 에러 처리가 가능합니다.

상태 코드의 정확한 정의와 범주는 HTTP Status Lookup 도구에서 빠르게 검색해 볼 수 있습니다.