브라우저와 HTTP 기초: HTML 요청부터 응답 헤더 읽기까지

실행 환경 준비

별도 프로그램 설치는 필요하지 않습니다.

Chrome 또는 Edge 같은 Chromium 계열 브라우저에서 다음 순서로 DevTools를 엽니다.

웹페이지 열기
→ F12
→ Network 탭
→ 페이지 새로고침

Network 탭을 연 뒤 새로고침해야 첫 HTML 문서 요청부터 확인하기 쉽습니다.

처음 실습할 때는 요청이 너무 많으면 Type 필터에서 Doc 또는 Fetch/XHR를 선택해도 됩니다.

TaskFlow 개발 서버가 준비되어 있다면 그 페이지를 사용하고, 아직 없다면 현재 접속 가능한 일반 웹페이지에서도 같은 방법으로 연습할 수 있습니다.

브라우저와 서버 사이에서 일어나는 일

브라우저가 웹페이지를 연다는 것은 대략 다음 흐름입니다.

브라우저
→ 서버에 HTTP 요청
→ 서버가 HTTP 응답
→ 브라우저가 응답을 해석
→ 필요한 CSS·JavaScript·이미지를 추가 요청
→ 화면 구성

여기서 중요한 점은 화면이 한 번에 내려오는 것이 아니라는 점입니다.

HTML 문서가 먼저 도착한 뒤 HTML 안에서 참조한 자원이 있으면 별도 요청이 이어집니다.

예를 들어 다음 HTML이 있다고 가정합니다.

<link rel="stylesheet" href="/style.css">
<script src="/app.js"></script>
<img src="/logo.webp" alt="로고">

브라우저는 HTML을 받은 뒤 style.css, app.js, logo.webp를 각각 요청할 수 있습니다.

따라서 화면 일부만 깨졌다면 전체 페이지 요청이 실패한 것이 아니라 특정 자원 요청만 실패했을 가능성도 있습니다.

HTTP 요청 구성 확인

Network에서 가장 위에 있는 document 요청을 하나 선택합니다.

Headers 영역에서 먼저 다음 항목을 확인합니다.

Request URL
Request Method
Status Code
Request Headers
Response Headers

Request URL은 실제 요청한 주소입니다.

https://example.com/tasks

Request Method는 서버에 어떤 종류의 작업을 요청하는지 나타냅니다.

가장 자주 보는 Method는 다음과 같습니다.

GET     데이터 조회
POST    새 데이터 전송
PUT     전체 수정에 자주 사용
PATCH   일부 수정에 자주 사용
DELETE  삭제에 자주 사용

Method 이름만 보고 서버 동작을 완전히 단정할 수는 없습니다. 실제 의미는 서버 API 설계에 따라 달라질 수 있습니다.

그래도 프론트엔드에서 Network를 볼 때 GET인지 POST인지 확인하면 요청 목적을 빠르게 파악할 수 있습니다.

Request Headers는 무엇인가

HTTP 요청에는 URL과 Method 외에도 부가 정보가 포함됩니다.

예를 들어 다음과 같은 Header가 있습니다.

Accept
Content-Type
Authorization
Cookie
Origin
Referer
User-Agent

모든 요청에 모든 Header가 들어가는 것은 아닙니다.

지금은 각각을 외우기보다 요청에 본문 외의 추가 정보가 함께 전달될 수 있다는 구조를 이해하면 됩니다.

3회차에서는 Cookie·Authorization·Origin을 인증과 CORS 관점에서 다시 봅니다.

HTTP 응답 구성 확인

서버는 요청을 처리한 뒤 응답을 보냅니다.

응답에서 중요한 것은 크게 세 가지입니다.

Status Code
Response Headers
Response Body

HTML 문서를 요청했다면 Response 탭에 HTML이 보일 수 있습니다.

API 요청이라면 JSON이 보일 수 있습니다.

예를 들어 서버가 다음 JSON을 반환할 수 있습니다.

{
  "id": "task-1",
  "title": "HTTP 공부하기",
  "completed": false
}

Network에서는 이 데이터가 브라우저에 도착했는지 직접 확인할 수 있습니다.

화면에 데이터가 보이지 않더라도 Network 응답이 정상이라면 문제는 그 이후 JavaScript 처리나 화면 렌더링 단계일 수 있습니다.

상태 코드 읽기

Status Code는 요청 결과를 빠르게 분류하는 단서입니다.

200

요청이 정상적으로 처리되었음을 의미합니다.

200 OK

다만 200이라고 해서 화면 전체가 반드시 정상이라는 뜻은 아닙니다.

HTTP 요청은 성공했지만 JavaScript 코드에서 오류가 발생할 수도 있습니다.

304

브라우저가 가진 캐시를 다시 사용할 수 있음을 알려주는 응답입니다.

304 Not Modified

304는 오류가 아닙니다.

5회차에서 ETag와 Cache-Control을 배우면 왜 304가 발생하는지 자세히 연결합니다.

404

서버에는 도달했지만 요청한 리소스를 찾지 못한 경우 자주 보입니다.

404 Not Found

중요한 점은 404가 DNS 실패와 다르다는 것입니다.

404가 보였다는 것은 적어도 HTTP 응답을 받을 단계까지는 도달했다는 의미입니다.

500

서버가 요청을 처리하는 과정에서 내부 오류가 발생한 경우 대표적으로 보입니다.

500 Internal Server Error

프론트엔드에서는 요청 URL과 전송 데이터가 올바른지 먼저 확인하고, 서버 로그를 볼 수 있는 환경이라면 서버 측 원인도 함께 확인해야 합니다.

HTML 이후 추가 요청 확인

Network의 Type 열을 보면 요청 종류를 구분할 수 있습니다.

document
stylesheet
script
image
fetch
xhr
font

예를 들어 HTML은 200인데 JavaScript 파일이 404라면 페이지 틀은 나오지만 기능이 작동하지 않을 수 있습니다.

API fetch가 500이라면 정적 UI는 보이지만 서버 데이터만 표시되지 않을 수 있습니다.

이런 식으로 요청 하나씩 분리해서 보는 습관이 중요합니다.

첫 요청 관찰 실습

Network에서 document 요청 하나를 고르고 다음 내용을 직접 적어봅니다.

URL:
Method:
Status:
Content-Type:
응답 종류:
추가로 이어진 요청:

예시입니다.

URL: https://example.com/
Method: GET
Status: 200
Content-Type: text/html
응답 종류: HTML 문서
추가 요청: CSS, JavaScript, 이미지

정답을 외우는 실습이 아니라 실제 브라우저에서 요청과 응답을 찾는 실습입니다.

자주 하는 오해

Network와 Console은 같은 역할입니다

다릅니다.

Network는 요청과 응답을 확인하는 데 적합하고 Console은 JavaScript 오류나 로그를 확인하는 데 적합합니다.

둘을 함께 사용해야 원인을 더 정확히 분리할 수 있습니다.

200이면 기능도 정상입니다

그렇지 않습니다.

서버 응답은 정상인데 프론트엔드 코드에서 JSON 처리나 렌더링에 실패할 수 있습니다.

Network 200
+ Console JavaScript 오류
= 네트워크 이후 프론트엔드 문제 가능성

304는 오류입니다

아닙니다.

캐시 재사용 과정에서 정상적으로 나타날 수 있습니다.

404는 인터넷 연결 실패입니다

일반적으로 다릅니다.

404는 서버가 HTTP 응답을 보낸 상황이고, DNS나 연결 자체가 실패하면 HTTP 상태 코드가 아예 보이지 않을 수도 있습니다.

독자 질문과 실전 확인

독자 질문

페이지는 열리는데 버튼이 작동하지 않으면 첫 HTML 요청이 성공했다고 기능까지 정상이라고 볼 수 있을까요?

웹 개발 사례

TaskFlow의 HTML은 200이지만 app.js 요청이 404이거나 JavaScript 실행 오류가 발생하면 화면 틀만 보일 수 있습니다. Network의 Document·JS 요청을 각각 선택하고 Console 오류를 따로 확인합니다.

직접 확인할 문제

Network를 연 뒤 새로고침하세요. Document 요청의 URL·Method·Status·Content-Type을 적고, JavaScript 파일 한 건의 Status를 비교하세요. 200인 문서와 404인 script가 보인다면 어느 단계부터 조사해야 할까요?

예상 결과와 판단

문서 응답 성공은 전체 기능 성공을 뜻하지 않습니다. script URL과 배포된 파일 경로를 먼저 대조하고 Console의 실행 오류도 확인합니다. 실제 사이트에서 두 상태가 반드시 나온다는 예측은 아닙니다.

검증 범위

예시의 200·404는 가상 조건입니다. 실제 Network 결과나 TaskFlow 배포 상태는 이번 편집에서 실행 검증하지 않았습니다.

다음 학습: 2회차에서는 HTTP 요청 전의 DNS·연결·TLS 단계를 분리합니다.

학습 완료 체크리스트

• HTTP 요청과 응답을 구분할 수 있습니다.
• Network에서 Request URL과 Method를 찾을 수 있습니다.
• Request Headers와 Response Headers 위치를 찾을 수 있습니다.
• 200·304·404·500의 기본 의미를 구분할 수 있습니다.
• HTML 이후 CSS·JavaScript·이미지 요청이 이어질 수 있음을 이해했습니다.
• 화면 오류와 HTTP 요청 오류가 항상 같은 문제는 아니라는 점을 설명할 수 있습니다.

브라우저
→ HTTP 요청
→ HTTP 응답
→ HTML 해석
→ 추가 자원 요청

Request URL
Request Method
Status Code
Request Headers
Response Headers
Response Body

페이지가 열림
↓
왜 열리는지는 확인하지 않음

페이지가 열림
↓
어떤 URL에 어떤 Method로 요청했는지 확인
↓
서버가 어떤 Status와 응답을 보냈는지 확인
↓
추가 자원 요청이 이어지는지 확인

→ 1. 브라우저·HTTP 요청/응답
○ 2. DNS·TCP·TLS
○ 3. 쿠키·세션·토큰·CORS
○ 4. CSRF·XSS
○ 5. HTTP 캐시
○ 6. 프로세스·스레드·메모리
○ 7. 통합 장애 진단

cs-step-01-http-basics

다음 학습

HTTP 요청은 갑자기 서버에 도착하지 않습니다.

다음 글: URL을 입력하면 무슨 일이 일어날까: DNS·TCP·TLS 연결 흐름