웹사이트가 안 열릴 때: HTTP 403·404·429·500·503을 구분하는 실습 가이드

👤 인스피

조회 수 7

1. 오류 화면은 어디에서 만들어졌을까요?

사용자는 브라우저에서 주소 하나를 열지만 요청은 여러 단계를 거칩니다. CDN이나 역방향 프록시를 쓰는 사이트라면 요청이 애플리케이션에 도착하기 전에 응답이 끝날 수 있습니다. 따라서 화면에 오류가 보인다는 이유만으로 데이터베이스가 고장 났다고 결론 내릴 수 없습니다.

직접 제작한 요청 흐름도입니다. 중간 서비스가 응답하면 원본 서버에 같은 요청의 기록이 없을 수 있습니다.

응답을 읽을 때는 세 가지를 묶어서 봅니다. 상태 코드는 처리 결과의 분류, 헤더는 이동 주소와 재시도 간격 같은 부가 정보, 본문은 화면이나 데이터입니다. 본문의 “실패”라는 단어와 실제 HTTP 상태 코드가 서로 다를 수도 있으므로 본문만 보고 판단하지 마세요.

원본 서버 로그에 요청이 보이지 않으면 먼저 중간 서비스의 보안 이벤트와 라우팅을 확인합니다. 로그에 남아 있다면 애플리케이션 로그를 이어서 확인합니다. 단, 로그 수집 지연이나 기록 대상 제외도 있을 수 있으므로 로그가 없다는 사실 하나만으로 차단 위치를 확정하지는 않습니다.

2. 자주 만나는 상태 코드와 첫 확인 항목

HTTP 상태 코드는 앞자리로 큰 범주를 구분합니다. 2xx는 성공, 3xx는 이동·캐시 관련 응답, 4xx는 요청을 처리할 수 없는 경우, 5xx는 서버 측 실패 범주입니다. 범주는 점검 방향을 좁히는 출발점이며, 4xx라고 해서 사용자 실수라는 뜻은 아닙니다. 아래 의미는 HTTP 표준의 상태 코드 정의를 바탕으로 정리했습니다.

코드	의미	첫 확인 항목
200	요청 성공	본문도 의도한 내용인지 확인
302	임시로 다른 주소 안내	`Location`과 최종 도착 주소
403	요청 이행 거부	권한·접근 정책·보안 이벤트
404	요청한 리소스를 찾지 못함	주소·게시글 존재 여부·라우팅
429	요청 횟수 제한	호출 주기·재시도 정책·제한 단위
500	처리를 막는 예상하지 못한 내부 상황	해당 시각의 애플리케이션 오류 로그
503	일시적으로 요청 처리 불가	유지보수·과부하·연결 가능한 의존 서비스

403과 404의 코드를 보는 것만으로 어느 설정을 바꿀지 결정할 수는 없습니다. 예를 들어 같은 게시글이 일반 브라우저에서는 열리고 명령줄에서는 막힐 수 있습니다. 주소는 같아도 쿠키, 요청 헤더, 접속 위치가 다르기 때문입니다. 둘의 차이를 적어 두면 원인 후보를 좁힐 수 있습니다.

429의 의미는 RFC 6585의 별도 정의를 참고할 수 있습니다. 제한의 대상이 IP인지 계정인지, 모든 주소인지 특정 API인지는 서비스가 정합니다. 코드만으로 제한 범위를 추측하거나 IP를 바꿔 우회하기보다 실제 적용 규칙과 정상 호출량을 대조해야 합니다.

3. Windows에서 응답 헤더만 확인하기

Windows 명령 프롬프트 또는 PowerShell에서 다음 명령을 실행합니다. 명령은 웹사이트 코드에 삽입하는 것이 아니라 자신의 컴퓨터에서 진단할 때 사용합니다. 로컬 서버를 아직 실행하지 않았다면 아래 명령은 연결 실패로 끝납니다. 서버 실행 방법은 다음 절에 있습니다.

curl.exe -sS -D - -o NUL "http://127.0.0.1:8765/ok"

-sS는 진행 표시를 줄이면서 연결 실패 메시지는 보여 줍니다. -D -는 응답 헤더를 터미널에 출력하고, -o NUL은 본문을 버립니다. Linux와 macOS에서는 curl과 /dev/null을 사용합니다. 이 명령은 GET 요청이며, -I로 만드는 HEAD 요청과는 다릅니다. 서버가 GET과 HEAD를 다르게 처리하면 결과가 달라질 수 있습니다.

실제 사이트를 확인할 때는 로컬 주소 대신 본인이 운영하는 정상 URL을 넣습니다. 몇 번의 비교 요청이면 충분합니다. 장애 확인을 위해 반복 호출 루프를 만들면 기존 부하와 진단 요청이 섞여 기록이 더 복잡해집니다. 세션 쿠키나 인증 토큰을 결과와 함께 공개하지 않는 것도 중요합니다.

브라우저에서는 Network의 문서 요청을 선택합니다

Chrome에서 F12를 눌러 개발자 도구를 열고 Network 탭으로 이동한 다음 페이지를 다시 엽니다. 문서 요청을 선택해 Status Code와 Response Headers를 확인하세요. 이미지나 광고 요청의 오류가 페이지 본문 오류처럼 보일 수 있으므로 요청 주소와 유형을 함께 확인합니다. 이동 과정을 보고 싶다면 Preserve log를 켭니다.

메인 문서는 200인데 사진 한 장만 404라면 전체 서버 장애로 처리할 이유가 없습니다. 반대로 화면은 열려도 데이터 조회 API가 500이면 일부 기능이 실패할 수 있습니다. 정상 페이지와 문제가 생긴 기능의 요청을 비교하면 확인해야 할 범위를 작게 유지할 수 있습니다.

4. 자신의 컴퓨터에서 오류 응답 7가지 만들기

빈 폴더에 http_status_demo.py 파일을 만들고 아래 코드를 저장합니다. 추가 패키지 없이 Python 표준 라이브러리만 사용합니다. 서버는 127.0.0.1에만 연결해 외부 공개를 의도하지 않습니다. 학습용 예제이므로 운영 서버로 배포하지 마세요.

from http.server import BaseHTTPRequestHandler, HTTPServer
from urllib.parse import urlsplit

class DemoHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        path = urlsplit(self.path).path
        routes = {
            '/ok': (200, '정상 응답', {}),
            '/missing': (404, '요청한 페이지가 없습니다', {}),
            '/forbidden': (403, '접근이 거부되었습니다', {}),
            '/limited': (429, '요청 횟수 제한 예시', {'Retry-After': '30'}),
            '/error': (500, '내부 오류 예시', {}),
            '/busy': (503, '일시적 이용 불가 예시', {'Retry-After': '60'}),
            '/redirect': (302, '다른 주소로 이동합니다', {'Location': '/ok'}),
        }
        status, message, headers = routes.get(
            path, (404, '등록하지 않은 경로입니다', {})
        )
        body = (message + '\n').encode('utf-8')
        self.send_response(status)
        self.send_header('Content-Type', 'text/plain; charset=utf-8')
        self.send_header('Content-Length', str(len(body)))
        self.send_header('Cache-Control', 'no-store')
        for name, value in headers.items():
            self.send_header(name, value)
        self.end_headers()
        self.wfile.write(body)

    def log_message(self, format, *args):
        pass

if __name__ == '__main__':
    print('실습 서버: http://127.0.0.1:8765/ok')
    print('종료하려면 Ctrl+C를 누르세요.')
    server = HTTPServer(('127.0.0.1', 8765), DemoHandler)
    try:
        server.serve_forever()
    except KeyboardInterrupt:
        pass
    finally:
        server.server_close()

명령 프롬프트에서 파일이 있는 폴더로 이동한 뒤 실행합니다. Windows Python Launcher가 없다면 설치 환경에 맞는 python 명령을 사용하세요. 실행 창은 그대로 두고 별도 터미널에서 curl 명령을 입력합니다.

py -3 http_status_demo.py

# 다른 터미널에서 실행
curl.exe -sS -D - -o NUL "http://127.0.0.1:8765/limited"
curl.exe -sS -D - -o NUL "http://127.0.0.1:8765/busy"

실제로 붙여 넣을 때 # 다른 터미널에서 실행은 설명이므로 Windows 명령 프롬프트에 입력하지 않아도 됩니다. 서버를 종료하려면 실행 창에서 Ctrl+C를 누릅니다. 이미 사용 중인 포트라는 메시지가 나오면 기존 실습 서버가 남아 있는지 확인하세요. 필요한 경우 코드의 8765와 확인 명령의 포트 번호를 같은 값으로 바꿉니다.

이 서버는 요청량을 측정해서 제한하는 프로그램이 아닙니다. /limited에 접근하면 항상 429를 보내도록 만든 교육용 예제입니다. /error도 예외를 발생시키는 대신 500 응답을 직접 보냅니다. 원인 재현과 응답 형식 재현은 다르다는 점을 구분해야 합니다.

5. 실제 실습 결과: 주소가 바뀌면 무엇이 달라질까?

예제 처리기를 로컬 HTTP 서버로 실행하고 아래 일곱 주소를 GET으로 호출했습니다. 리디렉션을 자동으로 따라가지 않는 클라이언트로 상태 코드와 헤더를 확인했습니다. 별도 확인에서는 /redirect를 따라가 최종 응답이 200인 것도 검증했습니다. 본문 바이트 수와 Content-Length의 일치도 확인했습니다.

실습 경로	확인한 코드	추가 확인
`/ok`	200	정상 메시지
`/missing`	404	없는 페이지 안내
`/forbidden`	403	거부 메시지
`/limited`	429	`Retry-After: 30`
`/error`	500	내부 오류 예시 메시지
`/busy`	503	`Retry-After: 60`
`/redirect`	302	`Location: /ok` · 따라가면 200

실습 A: 이동을 따라가기 전과 후 비교

curl.exe -sS -D - -o NUL "http://127.0.0.1:8765/redirect"
curl.exe -sS -L -D - -o NUL "http://127.0.0.1:8765/redirect"

첫 명령은 302와 이동 주소를 보여 줍니다. 두 번째 명령은 -L 때문에 이동을 따라가며, 이 예제에서는 302와 최종 200 응답 헤더를 차례로 볼 수 있습니다. 최종 결과만 저장하는 모니터링에서는 중간 이동이 잘 안 보일 수 있습니다. 로그인 페이지로 이동한 뒤 200이 나온 상황을 게시글 조회 성공으로 오해하지 않도록 최종 주소와 본문까지 확인해야 합니다.

실습 B: 재시도 안내를 읽어 보기

/limited에는 30, /busy에는 60이 표시됩니다. 이 예제의 숫자는 각각 기다릴 초를 뜻합니다. 실제 서비스의 Retry-After는 초 또는 HTTP 날짜 형태일 수 있으며, 헤더가 없는 경우도 있습니다. Retry-After 문서를 참고해 형식을 확인하세요.

중요한 차이는 curl이 이 헤더를 출력했다고 해서 현재 명령이 자동으로 기다리거나 재시도하지는 않는다는 점입니다. 반복 작업 프로그램에는 별도의 재시도 횟수와 대기 정책이 필요합니다. 요청 제한에서 즉시 재시도하면 제한이 계속될 수 있고, 상태 변경 요청을 무조건 재시도하면 중복 작업이 생길 수도 있습니다. 응답 코드와 요청의 성격을 함께 고려하세요.

6. 운영 사이트에서는 한 번에 하나씩 확인합니다

실습이 끝났다면 실제 사이트에서는 정상 주소 하나와 문제 주소 하나를 골라 비교합니다. 같은 시각, 같은 접속 환경에서 확인하면 차이를 해석하기 쉽습니다. 사진 오류라면 이미지 URL, 댓글 오류라면 댓글 요청을 선택하세요. 모든 페이지에 같은 설정을 적용하기 전에 영향 범위를 적는 것이 우선입니다.

기록: 발생 시각과 시간대, 요청 경로, 메서드, 코드, 로그인 여부를 남깁니다.
위치 확인: 프록시·CDN의 이벤트와 원본 서버 로그를 대조합니다. 요청 식별자가 있으면 함께 사용합니다.
비교: 정상 요청과 다른 쿠키·헤더·주소 조건을 찾아봅니다. 민감한 값은 공유하지 않습니다.
수정: 가장 근거가 있는 설정 하나를 바꿉니다. 변경 전 값과 되돌릴 방법을 기록합니다.
재확인: 문제 기능뿐 아니라 로그인, 글쓰기, 이미지 표시 같은 인접 기능도 확인합니다.

예를 들어 403을 봤다고 방화벽 전체를 끄거나, 503을 봤다고 데이터베이스를 바로 증설하지 마세요. 앞의 예제는 같은 작은 프로그램이 모두 다른 코드를 보낼 수 있음을 보여 줍니다. 실제 원인은 관련 로그와 적용된 규칙이 설명해야 합니다. 코드 자체는 원인 보고서가 아닙니다.

운영 기록은 길 필요가 없습니다. “오전 10시 한국 시간, 비회원 게시글 GET 403, 일반 브라우저는 정상, 명령줄만 실패, 원본 로그 미확인”처럼 관찰과 미확인 사항을 구분하면 됩니다. 이 기록을 남기면 다른 개발자에게 도움을 요청할 때도 추측 대신 재현 가능한 조건을 전달할 수 있습니다.

사용자에게 보이는 오류 안내도 점검하세요. “잠시 후 다시 시도하세요”라는 화면은 필요하지만 응답 상태까지 200으로 바꾸면 외부 점검 도구가 성공으로 읽을 수 있습니다. 오류 화면의 친절함과 상태 코드의 정확함을 함께 유지하는 편이 운영하기 쉽습니다. 단, 기존 API 클라이언트가 어떤 응답을 기대하는지는 수정 전에 확인해야 합니다.

7. 자주 묻는 질문

200이면 사이트가 완전히 정상인가요?

아닙니다. 여기서는 해당 요청이 성공 응답을 받은 것만 확인합니다. 화면 안의 다른 API, 이미지, JavaScript 실행은 따로 실패할 수 있습니다. 로그인 안내나 애플리케이션의 실패 메시지가 200 본문에 들어오는 경우도 있으므로 실제 내용과 기능을 점검하세요.

브라우저는 되는데 curl만 403이면 서버 오류인가요?

그 결과만으로는 확정할 수 없습니다. 브라우저의 쿠키, 보안 확인 과정, 헤더, 접속 위치가 다른지 확인합니다. 로컬 실습의 403은 예제 서버가 직접 반환했지만 실제 사이트의 403은 중간 서비스가 보냈을 수도 있습니다.

이 예제에서 429는 30초 뒤 200으로 바뀌나요?

아닙니다. 경로별로 고정 응답을 보내므로 계속 429입니다. 헤더를 읽는 연습을 위한 구조입니다. 실제 제한 해제를 시험하려면 시간과 호출 횟수를 관리하는 별도의 로직이 필요합니다.

503이면 사용자가 많다는 뜻인가요?

그럴 수 있지만 코드만으로 접속자 수를 알 수는 없습니다. 유지보수, 내부 의존 서비스 연결 실패 등 실제 프로그램의 처리 방식도 살펴봐야 합니다. 응답 본문과 로그가 없는 상태에서 방문자 증가로 단정하지 마세요.

curl 명령을 사이트 HTML에 넣어야 하나요?

아닙니다. 본문에 보이는 명령은 독자가 터미널에서 실행하는 진단 예제입니다. HTML 파일을 열어도 서버가 자동으로 실행되거나 외부 사이트에 요청을 보내지 않습니다.

참고 자료와 검증 범위

본문은 표준 정의를 그대로 번역해 옮긴 문서가 아니라, 독립적으로 구성한 점검 절차와 로컬 실습을 중심으로 작성했습니다. 상태 코드 의미와 도구 옵션을 확인할 때 사용한 자료는 다음과 같습니다.

검증한 범위는 로컬 예제의 GET 응답 7가지, 두 재시도 헤더, 이동 주소와 최종 200, 본문 길이입니다. 실제 사이트의 인증·방화벽·부하 제한·CDN 동작은 이 실습으로 검증하지 않았습니다. Windows 명령은 공식 curl 옵션에 맞춰 작성했으며 이번 실행 환경에서 Windows 자체를 시험한 것은 아닙니다.

이 문서의 도식과 예제 코드는 본문을 위해 직접 구성했습니다. 외부 이미지·폰트·광고·추적 스크립트 없이 열리는 단일 HTML 문서입니다.