인터넷을 쓰다 보면 한 번쯤은 마주치게 되는 화면이 있다. "404 Not Found"라는 메시지가 화면 한가운데 떡하니 자리 잡고, 내가 찾던 페이지는 어디론가 사라져 버린 상황. 당황스럽기도 하고, 약간의 허탈함도 느끼게 된다. 그런데 이 404라는 숫자가 단순히 '오류'를 뜻하는 아무 숫자가 아니라는 사실을 알고 있는가?
HTTP 상태 코드는 웹 브라우저(크롬, 사파리 등)가 서버에 "이 페이지 보여주세요"라고 요청했을 때, 서버가 돌려보내는 세 자리 숫자 신호다. 1996년 HTTP/1.0(RFC 1945)이 표준화되면서 공식 도입된 이 체계는, 요청이 성공했는지, 실패했는지, 아니면 서버에 문제가 있는지를 컴퓨터가 자동으로 판단할 수 있게 만든 국제 표준 규칙이다.
이 글에서는 404를 포함한 모든 HTTP 에러 코드의 의미를 첫 번째 숫자 기준으로 체계적으로 분류하고, 각 코드가 발생하는 원인과 사용자 입장에서 취할 수 있는 대응법까지 구체적으로 다룬다. 웹사이트 운영자든, 개발자든, 일반 사용자든 이 세 자리 숫자의 규칙만 알면 인터넷 오류 앞에서 더 이상 당황할 필요가 없다.
HTTP 상태 코드의 구조와 역사 - 세 자리 숫자에 담긴 규칙
웹 초창기에는 지금처럼 숫자로 된 상태 코드가 존재하지 않았다. 요청이 실패하면 그냥 텍스트로 설명을 보내거나, 아예 연결을 끊어 버리는 시절이었다. 1996년 IETF(국제 인터넷 표준화 기구)가 HTTP/1.0을 RFC 1945로 공식 표준화하면서 세 자리 상태 코드 체계가 도입되었고, 이후 1999년 HTTP/1.1(RFC 2616), 2022년 최신 표준인 RFC 9110까지 지속적으로 발전해왔다.
HTTP 상태 코드의 핵심 규칙은 첫 번째 숫자에 있다. 첫 자리만 보면 현재 어떤 상황인지 즉시 파악할 수 있도록 설계되었다.
| 첫 번째 숫자 | 분류 | 의미 | 사용자에게 보이는가? |
|---|---|---|---|
| 1xx | 정보(Informational) | 요청을 받았고 처리 중 | 거의 보이지 않음 |
| 2xx | 성공(Success) | 요청이 정상적으로 처리됨 | 보이지 않음 (정상 페이지 표시) |
| 3xx | 리다이렉션(Redirection) | 다른 주소로 이동 필요 | 거의 보이지 않음 (자동 이동) |
| 4xx | 클라이언트 에러(Client Error) | 요청한 쪽에 문제 있음 | 자주 보임 |
| 5xx | 서버 에러(Server Error) | 응답하는 서버에 문제 있음 | 자주 보임 |
첫 번째 숫자 뒤에 붙는 두 자리 숫자는 구체적인 상세 내용을 나타낸다. 예를 들어 404에서 4는 "클라이언트 측 문제", 04는 "요청한 리소스를 찾을 수 없음"이라는 세부 사항인 셈이다.
일반 사용자가 웹 브라우저에서 직접 보게 되는 상태 코드는 대부분 4xx와 5xx** 두 가지뿐이다. 1xx, 2xx, 3xx는 서버와 브라우저 사이에서 자동으로 처리되기 때문에 사용자 화면에 노출될 일이 거의 없다.
이 모든 상태 코드는 IETF에서 정의하고 IANA(Internet Assigned Numbers Authority, 인터넷 주소자원 총괄 관리 기관)에서 공식 레지스트리를 관리한다. 새로운 코드가 추가되거나 기존 코드가 폐기될 때도 이 기관을 통해 공식적으로 갱신된다.
** HTTP 상태 코드는 웹 서버마다 동일하게 적용되는 국제 표준이지만, Cloudflare, Nginx, IIS 같은 특정 서버 소프트웨어가 자체적으로 추가한 비표준 코드도 존재한다. 비표준 코드는 해당 환경에서만 통용되므로 범용적으로 해석하면 안 된다.
1xx - 3xx 상태 코드 - 눈에 보이지 않지만 항상 작동하는 코드들
1xx 정보 응답 (Informational)
1xx 코드는 서버가 "요청을 받았고, 현재 처리 중"이라는 중간 보고를 보내는 신호다. 일반 사용자에게는 사실상 보이지 않는다.
100 Continue는 클라이언트가 대용량 데이터를 보내기 전에 서버가 "보내도 괜찮다"고 허락하는 신호이고, 101 Switching Protocols는 웹소켓 같은 다른 프로토콜로 전환할 때 사용된다. 103 Early Hints는 비교적 최근에 추가된 코드로, 서버가 최종 응답을 준비하는 동안 브라우저가 미리 CSS나 JS 파일을 불러올 수 있게 힌트를 주는 역할을 한다.
2xx 성공 응답 (Success)
2xx 코드는 "요청이 성공적으로 처리되었다"는 뜻이다. 가장 대표적인 200 OK는 우리가 웹 페이지를 정상적으로 볼 때마다 뒤에서 발생하는 코드다. 하루에도 수백 번 200 코드를 받지만, 성공이기 때문에 화면에 노출되지 않는다.
201 Created는 새로운 리소스가 생성되었을 때(회원가입, 게시글 작성 등), 204 No Content는 요청은 성공했지만 돌려줄 내용이 없을 때 사용된다. 206 Partial Content는 대용량 파일 다운로드를 중단했다가 이어받을 때 등장하는 코드다.
3xx 리다이렉션 (Redirection)
3xx 코드는 "요청한 리소스가 다른 곳으로 이동했으니 그쪽으로 가라"는 응답이다. 서버가 브라우저에게 새 주소를 알려주면, 브라우저가 자동으로 이동시키기 때문에 사용자는 대부분 인식하지 못한다.
| 코드 | 이름 | 설명 | SEO 영향 |
|---|---|---|---|
| 301 | Moved Permanently | 영구 이동. 검색엔진이 새 주소를 색인함 | 링크 가치(link equity) 전달 |
| 302 | Found | 임시 이동. 원래 주소가 여전히 유효 | 링크 가치 전달 안 됨 |
| 303 | See Other | POST 요청 후 GET으로 다른 페이지 안내 | 제한적 |
| 304 | Not Modified | 캐시된 버전 사용 가능 | 없음 (대역폭 절약) |
| 307 | Temporary Redirect | 임시 이동이지만 요청 방식 유지 | 302와 유사 |
| 308 | Permanent Redirect | 영구 이동이면서 요청 방식 유지 | 301과 유사 |
웹사이트 주소를 영구적으로 변경할 때는 반드시 301 리다이렉트**를 사용해야 한다. 302를 잘못 사용하면 검색엔진이 새 주소를 정식으로 인식하지 않아 SEO 순위가 하락할 수 있다. 실제로 조사 결과 약 62%의 웹사이트가 리다이렉트 코드를 잘못 적용하고 있다는 분석이 있다.
4xx 클라이언트 에러 - 사용자 측 문제를 알려주는 에러 코드 28종
4xx 에러는 요청을 보낸 쪽(브라우저, 사용자)에 문제가 있다는 신호다. 잘못된 URL, 인증 실패, 권한 부족 등이 원인이며, 사용자가 가장 자주 마주치는 에러 그룹이다.
가장 흔한 4xx 에러 코드
400 Bad Request - 서버가 요청 자체를 이해하지 못한 경우다. URL에 잘못된 문자가 포함되었거나, 요청 데이터의 형식이 깨졌을 때 발생한다. 브라우저 캐시를 삭제하거나 URL을 다시 확인하면 해결되는 경우가 많다.
401 Unauthorized - 이름은 "Unauthorized(권한 없음)"이지만 실제 의미는 "인증되지 않음(Unauthenticated)"에 더 가깝다. 로그인이 필요한 페이지에 로그인하지 않고 접근하거나, API 키가 누락되었을 때 발생한다.
403 Forbidden - 401과 혼동하기 쉽지만 완전히 다른 코드다. 서버가 요청자가 누구인지 알고 있지만, 해당 리소스에 접근할 권한이 없다고 거부하는 것이다. 로그인을 다시 해도 해결되지 않는다.
| 구분 | 401 Unauthorized | 403 Forbidden |
|---|---|---|
| 핵심 원인 | 인증(로그인) 안 됨 | 인증은 됐지만 권한 부족 |
| 해결 방법 | 로그인 또는 API 키 입력 | 관리자에게 권한 요청 |
| 재시도 의미 | 올바른 자격증명으로 재시도 가능 | 재시도해도 결과 동일 |
| 실생활 비유 | 회사 건물에 출입증 없이 들어가려는 것 | 출입증은 있지만 임원 전용 층에 가려는 것 |
404 Not Found - HTTP 상태 코드 중 가장 유명한 코드다. 서버와의 통신 자체는 성공했지만, 요청한 페이지나 파일을 서버에서 찾을 수 없을 때 반환된다. URL 오타, 페이지 삭제, 주소 변경(리다이렉트 미설정) 등이 주요 원인이다. 전설적인 이야기로는 CERN(유럽 입자물리연구소)의 404호실에서 최초의 웹 서버가 운영되었고, 팀 버너스 리가 자주 자리를 비워 "404 - 찾을 수 없음"이 되었다는 일화가 전해진다. 역사적으로 확인된 사실은 아니지만, 이 이야기가 404 코드를 더욱 상징적으로 만들었다.
404 에러를 만났을 때 가장 먼저 해야 할 일은 URL 오타 확인이다. 그 다음으로 브라우저 캐시에 오래된 주소가 남아 있을 수 있으므로 새로고침(Ctrl+Shift+R)**을 해보고, 그래도 안 되면 해당 사이트를 검색엔진에서 직접 검색해 이동한 주소를 찾는 것이 가장 효과적이다.
405 Method Not Allowed - 서버가 해당 URL에 대해 요청된 HTTP 메서드(GET, POST, PUT, DELETE 등)를 허용하지 않을 때 발생한다.
408 Request Timeout - 서버가 클라이언트의 요청을 기다리다가 시간이 초과된 경우다. 인터넷 연결이 불안정하거나 서버 부하가 높을 때 나타난다.
409 Conflict - 요청이 서버의 현재 상태와 충돌할 때 발생한다. 동시에 같은 리소스를 수정하려는 경우가 대표적이다.
410 Gone - 404와 비슷하지만 결정적 차이가 있다. 404는 "못 찾겠다(나중에 다시 생길 수도 있음)"이고, 410은 "의도적으로 삭제했고 다시 돌아오지 않는다"는 확정적 메시지다. SEO 관점에서 410을 사용하면 검색엔진이 해당 페이지를 색인에서 더 빠르게 제거한다.
429 Too Many Requests - 짧은 시간에 너무 많은 요청을 보냈을 때 서버가 속도 제한(Rate Limiting)을 걸어 반환하는 코드다. API를 호출하는 개발자들이 자주 만나게 되며, 일정 시간 대기 후 재시도하면 해결된다.
특이한 4xx 에러 코드
402 Payment Required - 디지털 결제 시스템을 위해 예약된 코드지만, 표준화된 적이 없다. Google API에서 일일 요청 한도를 초과하거나, Shopify에서 요금 미납 시 사용되는 등 특정 서비스에서만 제한적으로 활용된다.
418 I'm a Teapot - HTTP 역사상 가장 유명한 이스터 에그다. 1998년 만우절에 IETF가 발표한 RFC 2324 "HTCPCP(Hyper Text Coffee Pot Control Protocol)"에서 정의된 코드로, "나는 찻주전자라서 커피를 내릴 수 없다"는 의미다. 실제 웹 서버에서 구현될 목적으로 만들어진 것이 아니지만, Google을 비롯한 여러 기업이 이스터 에그로 구현해두었다. 2017년에는 이 코드의 폐기가 논의되었지만, 15세 개발자가 "Save 418" 캠페인을 벌여 살아남기도 했다.
451 Unavailable For Legal Reasons - 법적 이유(정부 검열, 저작권 등)로 콘텐츠에 접근할 수 없을 때 반환되는 코드다. 레이 브래드버리의 디스토피아 소설 화씨 451도(Fahrenheit 451)에서 숫자를 따왔다. 소설에서 451은 책이 자연 발화하는 온도로, 책(정보)을 불태우는 검열 사회를 상징한다. 2015년 RFC 7725로 공식 표준이 되었다.
** 401과 403을 혼동하면 보안 설계에 심각한 문제가 생길 수 있다. 401은 "누구인지 확인이 안 된다"는 뜻이고, 403은 "누구인지 알지만 허락할 수 없다"는 뜻이다. 로그인하지 않은 사용자에게 403을 보내면, 해당 리소스가 존재한다는 정보를 노출하는 셈이 된다.
5xx 서버 에러 - 내 잘못이 아닌데 오류가 뜨는 이유
5xx 에러는 요청 자체에는 문제가 없지만 서버 쪽에서 처리를 실패했다는 신호다. 사용자 입장에서 할 수 있는 일이 제한적이며, 대부분 서버 관리자의 조치가 필요하다.
500 Internal Server Error - 가장 포괄적인 서버 에러다. 서버 내부에서 예상치 못한 오류가 발생했지만, 더 구체적인 코드를 줄 수 없을 때 반환된다. PHP 코드 오류, 데이터베이스 연결 실패, 잘못된 서버 설정 등 원인이 다양하다.
502 Bad Gateway - 서버가 다른 서버(업스트림 서버)로부터 잘못된 응답을 받았을 때 발생한다. 서버끼리 통신하는 중간 단계에서 문제가 생긴 것이다. 리버스 프록시(Nginx, Apache)나 CDN을 사용하는 환경에서 자주 발생한다.
503 Service Unavailable - 서버가 일시적으로 요청을 처리할 수 없는 상태다. 서버 과부하, 예정된 유지보수, 트래픽 폭주 등이 원인이다. 보통 일시적이므로 잠시 후 재접속하면 해결되는 경우가 많다.
504 Gateway Timeout - 502와 비슷하지만 차이가 있다. 502는 "잘못된 응답을 받았다"이고, 504는 "아예 응답을 받지 못해 시간이 초과되었다"는 뜻이다.
| 코드 | 이름 | 핵심 원인 | 사용자 대응법 |
|---|---|---|---|
| 500 | Internal Server Error | 서버 내부 코드 오류 | 새로고침 후 재시도, 지속 시 관리자 문의 |
| 502 | Bad Gateway | 중간 서버가 잘못된 응답 수신 | 잠시 대기 후 재시도 |
| 503 | Service Unavailable | 서버 과부하 또는 점검 | 시간을 두고 재접속 |
| 504 | Gateway Timeout | 중간 서버가 응답 대기 시간 초과 | 잠시 대기 후 재시도 |
| 505 | HTTP Version Not Supported | 서버가 요청의 HTTP 버전 미지원 | 브라우저 업데이트 |
| 507 | Insufficient Storage | 서버 저장 공간 부족 (WebDAV) | 서버 관리자 문의 |
| 508 | Loop Detected | 서버가 무한 루프 감지 (WebDAV) | 서버 관리자 문의 |
| 511 | Network Authentication Required | 네트워크 인증 필요 | 와이파이 로그인 페이지 확인 |
5xx 에러가 발생하면 사용자 입장에서 가장 효과적인 대처법은 브라우저 새로고침과 시간 간격을 두고 재접속**하는 것이다. 502, 503, 504는 대부분 일시적인 통신 장애이므로 몇 분 후 정상화되는 경우가 잦다. 에러가 계속된다면 해당 서비스의 공식 상태 페이지나 SNS 채널에서 장애 공지를 확인하는 것이 좋다.
Cloudflare 전용 5xx 에러 코드
전 세계 웹사이트의 약 20% 이상이 Cloudflare CDN을 사용하고 있어, Cloudflare 자체 에러 코드를 마주칠 확률도 상당히 높다. 이 코드들은 HTTP 표준은 아니지만, Cloudflare가 원본 서버(Origin Server)와의 통신 과정에서 발생하는 문제를 세분화하기 위해 만든 것이다.
520 Web Server Returned an Unknown Error는 원본 서버가 빈 응답이나 예상치 못한 응답을 반환했을 때, 521 Web Server Is Down은 원본 서버가 아예 연결을 거부했을 때, 522 Connection Timed Out은 Cloudflare가 원본 서버와의 TCP 연결에 실패했을 때, 523 Origin Is Unreachable은 DNS 설정 오류 등으로 원본 서버에 도달 자체가 불가능할 때, 524 A Timeout Occurred는 TCP 연결은 됐지만 HTTP 응답을 받지 못한 채 시간이 초과되었을 때 각각 발생한다. 525 SSL Handshake Failed는 SSL/TLS 인증서 협상에 실패한 경우이고, 526 Invalid SSL Certificate는 원본 서버의 SSL 인증서가 유효하지 않을 때 나타난다.
** Cloudflare 전용 에러 코드(520-526)는 HTTP 공식 표준이 아니다. Cloudflare를 사용하지 않는 서버에서는 절대 발생하지 않으며, 이 코드들이 뜨면 문제의 원인은 Cloudflare와 원본 서버 사이의 통신에 있다. 사용자 입장에서는 VPN을 끄거나 다른 네트워크로 접속해 보는 것도 한 가지 방법이다.
실전에서 자주 만나는 에러 코드 TOP 7과 즉시 대응법
수십 개의 HTTP 상태 코드 중에서 실제로 일반 사용자가 체감할 수 있는 코드는 한정적이다. 웹 서버 로그 분석 결과, 사용자에게 가장 빈번하게 노출되는 에러 코드 상위 7개를 뽑으면 아래와 같다.
1위 404 Not Found - 존재하지 않는 페이지 접근. 원인의 약 68%가 URL 오타이고, 나머지는 삭제된 페이지나 변경된 주소다. 오타를 확인하고, 캐시를 지우고(Ctrl+Shift+Delete), 검색엔진에서 해당 페이지를 직접 검색하는 순서로 대응한다.
2위 403 Forbidden - 접근 권한 없음. 관리자 전용 페이지에 일반 사용자가 접근하거나, IP 차단이 걸려 있을 때 발생한다. VPN 사용 중이라면 끄고 재시도해 본다.
3위 500 Internal Server Error - 서버 내부 오류. 사용자가 할 수 있는 건 새로고침과 재접속뿐이다.
4위 502 Bad Gateway - 서버 간 통신 오류. 대형 서비스 장애 시 가장 흔하게 보이는 코드로, 대부분 수 분 내 복구된다.
5위 503 Service Unavailable - 서버 과부하 또는 점검. "잠시 후 다시 시도해 주세요"라는 의미와 동일하다.
6위 429 Too Many Requests - 요청 속도 제한. 페이지를 너무 빠르게 새로고침하거나, 자동화 도구로 대량 요청을 보낼 때 발생한다. 잠시 기다렸다 재시도한다.
7위 401 Unauthorized - 인증 필요. 로그인이 필요한 페이지인데 로그인 상태가 아닐 때 발생한다.
** 4xx 에러와 5xx 에러의 대응 전략은 근본적으로 다르다. 4xx는 내가(요청자가) 뭔가 잘못한 것이므로 URL, 로그인 상태, 권한을 점검해야 하고, 5xx는 서버 측 문제이므로 시간을 두고 재시도하거나 관리자에게 연락해야 한다. 이 원칙만 기억해도 에러 대응 속도가 확연히 달라진다.
HTTP 상태 코드는 1996년 도입된 이후 30년 가까이 인터넷의 기본 언어로 기능해왔다. 세 자리 숫자 속에 담긴 규칙은 간단하지만 강력하다. 첫 번째 숫자로 상황을 분류하고, 나머지 두 자리로 구체적인 원인을 특정하는 이 체계 덕분에 전 세계 수십억 대의 기기가 동일한 기준으로 소통할 수 있다.
이 글에서 다룬 핵심을 한 문장으로 압축하면 이렇다. 4로 시작하면 내 탓, 5로 시작하면 서버 탓이다. 404를 만나면 당황하지 말고 URL부터 확인하고, 502나 503을 만나면 커피 한 잔 마시며 잠시 기다려 보자. 그리고 혹시 418을 만난다면, 찻주전자에게 커피를 요청한 건 아닌지 한 번 웃어보는 것도 좋다.
웹사이트를 운영하는 입장이라면 Google Search Console에서 크롤링 에러를 정기적으로 확인하고, 삭제된 페이지에는 적절한 리다이렉트(301)나 상태 코드(410)를 설정해두는 습관을 들이는 것이 SEO와 사용자 경험 모두에 이롭다. 지금 바로 본인 웹사이트의 에러 페이지 상태를 점검해 보는 것부터 시작해보자.