HTTP 상태 코드로 CDN 읽기: 304·404·502·504가 알려주는 것
🤖 AI Summary
HTTP 상태 코드의 첫 자리만 봐도 문제의 성격이 갈립니다. RFC 9110 기준으로 2xx는 요청이 성공적으로 수신·이해·수락됐다는 뜻이고, 3xx는 추가 조치가 필요하다, 4xx는 클라이언트가 잘못한 것 같다, 5xx는 서버가 자신의 오류를 인지했다는 의미예요. CDN 관점에서 특히 중요한 것은 5xx 중 502와 504입니다. RFC는 이 둘을 각각 "게이트웨이나 프록시로 동작하며 인바운드 서버로부터 유효하지 않은 응답을 받았다", "업스트림 서버로부터 제때 응답을 받지 못했다"로 정의하는데, CDN이 바로 그 게이트웨이 자리에 있죠. 304는 조건부 요청에 대한 응답으로 캐시 재검증의 핵심이고, 206은 Range 요청의 부분 응답, 404와 410은 없음과 영구 삭제를 구분합니다. 근거는 전부 RFC 9110 원문입니다.
블로그 목차
첫 자리로 큰 그림을 먼저 읽는다
상태 코드는 세 자리 숫자지만, RFC 9110은 "첫 자리가 응답의 클래스를 정하고, 뒤 두 자리는 분류 역할을 하지 않는다"고 규정합니다. 그러니 문제를 만났을 때 첫 자리부터 보면 성격이 금세 잡히죠. RFC 9110 기준으로 2xx는 "요청이 성공적으로 수신·이해·수락됐다", 3xx는 "요청을 완료하려면 추가 조치가 필요하다", 4xx는 "클라이언트가 잘못한 것으로 보인다", 5xx는 "서버가 자신이 오류를 냈음을 인지했다"는 뜻입니다.
여기서 CDN의 위치를 떠올리면 상태 코드가 더 잘 읽힙니다. CDN은 사용자와 오리진(원본 서버) 사이에 선 게이트웨이이자 프록시예요. 그래서 같은 5xx라도 오리진이 낸 것인지, CDN과 오리진 사이에서 난 것인지가 코드로 갈립니다. 이 글은 CDN 운영에서 자주 만나는 코드를 클래스별로, 특히 그 위치 관점에서 정리합니다.
CDN이 게이트웨이라서 생기는 5xx: 502·503·504
CDN 운영에서 가장 신경 쓰이는 것이 5xx입니다. 그중 502와 504는 게이트웨이·프록시 전용 코드라 CDN과 직접 얽혀요. RFC 9110은 502 Bad Gateway를 "게이트웨이나 프록시로 동작하는 서버가 인바운드 서버로부터 유효하지 않은 응답을 받았다"고 정의합니다. 504 Gateway Timeout은 "게이트웨이나 프록시로 동작하는 서버가 업스트림 서버로부터 제때 응답을 받지 못했다"는 뜻이고요. CDN이 바로 그 게이트웨이 자리에 서 있으니, 이 둘은 오리진과의 통신에서 뭔가 어긋났다는 신호입니다. 실제로 지난 AWS CloudFront 장애 글에서 다룬 사고도 504를 포함한 5xx가 치솟은 사례였죠.
503은 결이 조금 다릅니다. RFC 9110 기준 503 Service Unavailable은 "일시적 과부하나 예정된 유지보수로 서버가 현재 요청을 처리할 수 없다"는 의미예요. 502·504가 "중간에서 오리진 응답이 잘못됐거나 없었다"라면, 503은 "지금은 감당이 안 된다"에 가깝습니다. 그리고 500 Internal Server Error는 RFC가 "서버가 요청을 수행하지 못하게 만든 예기치 않은 상황을 만났다"고 정의하는, 가장 일반적인 서버 오류입니다. 5xx를 만나면 코드 하나로 오리진 문제인지, 게이트웨이 구간 문제인지, 과부하인지를 먼저 갈라 보는 것이 진단의 출발점이에요.
캐시와 만나는 코드: 304·206·404·410
CDN은 캐시 계층이라, 캐시 거동과 직결되는 코드들이 있습니다. 대표가 304 Not Modified입니다. RFC 9110은 304를 "조건부 GET 또는 HEAD 요청을 받았고, 조건이 거짓으로 평가되지 않았다면 200 OK가 됐을 상황"이라고 정의해요. 캐시가 ETag나 Last-Modified로 재검증했는데 내용이 그대로일 때 오리진이 304를 돌려주고, 본문 없이 캐시를 재사용하게 합니다. 전송량을 아끼는 이 흐름은 Cache-Control TTL 설계 글에서 더 다뤘습니다.
206 Partial Content는 RFC 기준 "서버가 Range 요청을 충족해 선택된 표현의 한 부분 이상을 전송한다"는 뜻으로, 대용량 파일을 부분 전송할 때 나옵니다. 없음을 알리는 코드는 둘로 갈려요. 404 Not Found는 "오리진 서버가 대상 리소스의 현재 표현을 찾지 못했다", 410 Gone은 "대상 리소스가 오리진 서버에 더 이상 없으며 이 상태가 영구적일 가능성이 높다"입니다. 404는 "지금은 없다", 410은 "영구히 사라졌다"에 가까워, 캐시 정책이나 검색엔진 처리에서 다르게 다뤄집니다.
리다이렉트: 301·302·308의 차이
3xx 중 자주 쓰는 것이 리다이렉트입니다. RFC 9110 기준 301 Moved Permanently는 "대상 리소스에 새 영구 URI가 부여됐다", 302 Found는 "대상 리소스가 일시적으로 다른 URI에 있다"는 뜻이에요. 영구 이전이면 301, 임시 이전이면 302를 씁니다. 여기에 308 Permanent Redirect는 RFC가 "새 영구 URI가 부여됐고, 사용자 에이전트는 요청 메서드를 바꾸면 안 된다"고 정의합니다. 301과 비슷하지만 메서드 보존을 보장한다는 점이 다르죠. CDN에서 도메인 통합이나 HTTPS 강제, 경로 변경을 처리할 때 이 코드들을 어떤 의미로 쓰는지가 캐시와 검색엔진 동작에 영향을 줍니다. 영구 리다이렉트는 오래 캐시되고 검색엔진이 URL을 이전하는 신호로 받아들이니, 임시 변경에 301을 잘못 쓰면 되돌리기가 번거로워집니다.
이것만 기억하세요
상태 코드는 첫 자리로 성격이 갈립니다. 2xx 성공, 3xx 추가 조치, 4xx 클라이언트 오류, 5xx 서버 오류예요(RFC 9110). CDN은 게이트웨이라 502는 오리진이 유효하지 않은 응답, 504는 오리진 응답 지연, 503은 과부하·유지보수로 갈라 읽습니다. 304는 재검증 성공으로 캐시를 재사용하고, 404(없음)와 410(영구 삭제)은 구분해 다룹니다.
자주 묻는 질문 (FAQ)
Q. 502와 504는 무엇이 다른가요?
둘 다 게이트웨이·프록시 전용 5xx입니다. RFC 9110 기준 502 Bad Gateway는 게이트웨이가 인바운드 서버로부터 유효하지 않은 응답을 받은 경우이고, 504 Gateway Timeout은 업스트림 서버로부터 제때 응답을 받지 못한 경우입니다. 502는 응답이 왔는데 잘못됐다, 504는 응답이 시간 안에 오지 않았다로 이해하면 됩니다. CDN이 그 게이트웨이 자리에 있습니다.
Q. 상태 코드로 문제 위치를 어떻게 좁히나요?
첫 자리로 먼저 갈라 보면 됩니다. 4xx는 클라이언트 요청 자체의 문제, 5xx는 서버 쪽 문제입니다. 5xx 중에서도 502·504는 CDN과 오리진 사이 통신, 503은 과부하나 유지보수, 500은 오리진의 일반적 서버 오류로 좁혀집니다. 코드 하나가 어느 구간을 봐야 하는지 방향을 알려줍니다.
Q. 304 Not Modified는 왜 좋은 신호인가요?
재검증에 성공해 전송량을 아꼈다는 뜻이기 때문입니다. RFC 9110 기준 304는 조건부 GET 또는 HEAD 요청에 대해, 조건이 거짓으로 평가되지 않았다면 200이 됐을 상황을 가리킵니다. 내용이 그대로라 오리진이 본문 없이 304만 돌려주고, 캐시가 저장된 응답을 재사용합니다. 304 비율이 높다는 것은 캐시 재검증이 잘 작동하고 있다는 신호입니다.
Q. 404와 410은 어떻게 다르게 다뤄야 하나요?
핵심은 일시적이냐 영구적이냐입니다. 404 Not Found는 현재 표현을 찾지 못했다는 뜻으로 일시적일 수 있고, 410 Gone은 리소스가 영구적으로 사라졌을 가능성이 높다는 뜻이에요. 영구히 없앤 페이지라면 410을 주는 편이 의미가 정확하고, 검색엔진이 색인에서 더 빠르게 제거하도록 돕습니다. 캐시 정책도 두 코드를 다르게 잡을 수 있습니다.
Q. 리다이렉트에 301과 302 중 무엇을 써야 하나요?
영구 이전이면 301, 임시 이전이면 302입니다. RFC 9110 기준 301은 새 영구 URI가 부여된 경우, 302는 일시적으로 다른 URI에 있는 경우입니다. 요청 메서드까지 보존해야 하는 영구 이전에는 308을 씁니다. 임시 변경에 301을 잘못 쓰면 오래 캐시되고 검색엔진이 URL 이전으로 받아들여 되돌리기가 번거로워지니 주의해야 합니다.
