프론트엔드 기초 다시 쌓기 챌린지 21일차.
Part 3: 네트워크 기초 시작!Part 1에서 "코드가 사용자 화면까지 가는 과정"을,
Part 2에서 "비밀 정보 관리"를 배웠다면,
Part 3에서는 그 사이에서 일어나는 대화 — 네트워크를 배운다.
오늘의 핵심 질문:
"브라우저와 서버는 어떤 규칙으로 대화하는가?"
🍳 오늘의 비유: "주문서와 영수증"
손님이 아무렇게나 소리 지르면?
→ "야 뭐 좀 줘!" → 주방: "뭘요...?"
규칙이 있는 주문서를 쓰면?
→ 메뉴명, 수량, 테이블 번호가 적혀있음
→ 주방이 정확히 이해하고 음식을 보내줌HTTP는 이 "주문서 양식"이다.
브라우저와 서버가 대화할 때 지키는 규칙.
HTTP = HyperText Transfer Protocol
= 하이퍼텍스트를 전송하는 규칙(프로토콜)📤 HTTP 요청 (Request) = "주문서"
브라우저가 서버에 보내는 메시지. 3가지 파트로 구성된다.
GET /api/products HTTP/1.1 ← 1. 요청 라인
Host: www.myshop.com ← 2. 헤더
Accept: application/json
Authorization: Bearer eyJhbGci...
Cookie: session=abc123
← 빈 줄
(본문 없음) ← 3. 본문 (GET은 보통 없음)1. 요청 라인 (Request Line) — "뭘 원하는지"
GET /api/products HTTP/1.1
GET → HTTP 메서드 (어떤 행동?)
/api/products → URL 경로 (어떤 자원?)
HTTP/1.1 → HTTP 버전2. 헤더 (Headers) — "부가 정보"
Host: www.myshop.com → 어떤 서버에 보내는지
Accept: application/json → 어떤 형식으로 받고 싶은지
Authorization: Bearer eyJ... → 내가 누군지 (인증 정보)
Cookie: session=abc123 → 이전에 받은 쿠키3. 본문 (Body) — "보내는 데이터"
GET 요청: 보통 본문 없음 (달라고만 하니까)
POST 요청: 본문에 데이터를 담아 보냄POST /api/products HTTP/1.1
Content-Type: application/json
{
"name": "새 상품",
"price": 29000
}📥 HTTP 응답 (Response) = "영수증 + 음식"
서버가 브라우저에 보내는 메시지. 마찬가지로 3가지 파트.
HTTP/1.1 200 OK ← 1. 상태 라인
Content-Type: application/json ← 2. 헤더
Content-Length: 256
Set-Cookie: session=xyz789
← 빈 줄
{ ← 3. 본문 (실제 데이터)
"products": [
{ "id": 1, "name": "티셔츠", "price": 29000 },
{ "id": 2, "name": "모자", "price": 15000 }
]
}1. 상태 라인 — "결과가 어떤지"
HTTP/1.1 200 OK
200 → 상태 코드 (숫자)
OK → 상태 메시지 (사람이 읽기 위한)2. 헤더 — "부가 정보"
Content-Type: application/json → 데이터 형식이 JSON
Content-Length: 256 → 데이터 크기
Set-Cookie: session=xyz789 → 이 쿠키를 저장해주세요3. 본문 — "실제 데이터"
서버가 보내주는 JSON, HTML, 이미지 등 실제 내용.
🔍 Chrome DevTools에서 직접 보기
1. F12 → Network 탭 열기
2. 아무 사이트 접속
3. 요청 하나 클릭
4. Headers 탭 → 요청 라인, 헤더 확인
5. Response 탭 → 본문(실제 데이터) 확인
6. Status 열 → 200, 304, 404 같은 상태 코드Day 3에서 Network 탭을 배울 때 봤던 것들이 다 HTTP 요청/응답이었다.
Day 3에서 본 것: "브라우저가 JS, CSS 파일을 받아온다"
Day 21에서 아는 것: "GET 요청으로 파일을 달라고 하면 200 OK와 함께 파일이 온다"💡 HTTP의 특징 2가지
1. 무상태 (Stateless) — "기억력이 없다"
HTTP는 이전 요청을 기억하지 못한다.
요청 1: "로그인할게요" → 응답: "성공!"
요청 2: "내 주문 내역 보여줘" → 응답: "누구세요...?"그래서 매 요청마다 "나 이 사람이에요"라는 인증 정보를 같이 보내야 한다.
쿠키, 세션, JWT 같은 기술이 이 문제를 해결한다. (Day 30에서 자세히!)
2. 요청-응답 (Request-Response) — "물어봐야 답한다"
서버는 먼저 말을 걸지 않는다. 항상 브라우저가 먼저 요청해야 응답이 온다.
✅ 브라우저: "상품 목록 줘" → 서버: "여기 있어"
❌ 서버: "새 상품 나왔어요!" → (이런 건 안 됨)"그럼 실시간 알림은?" → Day 32에서 배울 WebSocket이라는 다른 기술이 해결한다.
🔗 여러분 프로젝트와 연결
// 이게 사실 HTTP 요청이다!
const res = await fetch('/api/products');
const data = await res.json();이 한 줄이 뒤에서 하는 일:
1. fetch가 HTTP 요청 생성 → GET /api/products HTTP/1.1
2. 서버로 요청 전송
3. 서버가 데이터를 찾아서 200 OK + JSON 데이터 응답
4. res.json()이 응답 본문을 파싱
5. data 변수에 상품 목록 저장Day 19에서 배운 CSRF도 연결된다.
<img src="우리사이트/api/delete?id=123">이 위험한 이유가,
img 태그가 GET 요청을 자동으로 보내기 때문이다!
🍳 레스토랑 비유 업데이트
| 레스토랑 | 서버 |
|---|---|
| 주문서 | HTTP 요청 (Request) |
| 영수증 + 음식 | HTTP 응답 (Response) |
| 주문서 양식 규칙 | HTTP 프로토콜 |
| "파스타 1개요" (뭘 원하는지) | 요청 라인 (GET /api/products) |
| "테이블 5번, VIP입니다" (부가 정보) | 헤더 (Host, Authorization) |
| "이 재료로 만들어주세요" (데이터) | 본문 (Body) |
| "주문 성공! 음식 나갑니다" | 200 OK |
| 직원이 기억상실증 | 무상태 (Stateless) |
| 주문해야 음식 나옴 | 요청-응답 (Request-Response) |
🎯 오늘 배운 것 최종 정리
- HTTP란: 브라우저와 서버가 대화하는 규칙 (주문서 양식)
- 요청 3가지 구성: 요청 라인(뭘 할지) + 헤더(부가 정보) + 본문(데이터)
- 응답 3가지 구성: 상태 라인(결과) + 헤더(부가 정보) + 본문(실제 데이터)
- 무상태 (Stateless): 이전 요청 기억 못 함 → 매번 인증 정보를 같이 보내야 함
- 요청-응답: 서버는 먼저 안 말함, 항상 브라우저가 먼저 요청
- fetch()의 정체: HTTP 요청을 만들어서 서버에 보내고 응답을 받는 것
🧪 이해도 체크
Q1. HTTP 요청의 3가지 구성 요소는?
→ 정답: 요청 라인(어떤 메서드로 어떤 경로에 요청할지) + 헤더(부가 정보) + 본문(보내는 데이터)
Q2. HTTP가 무상태(Stateless)라는 건?
→ 정답: 이전 요청을 기억하지 못한다. 그래서 매 요청마다 인증 정보(쿠키, JWT 등)를 같이 보내야 서버가 "아 이 사람이구나" 알 수 있다.
Q3. fetch('/api/products') 실행 시 뒤에서 일어나는 일은?
→ 정답: GET /api/products HTTP/1.1 요청 생성 → 서버 전송 → 서버가 200 OK + JSON 응답 → res.json()으로 파싱 → 데이터 저장
💭 회고
fetch()를 매일 쓰면서도 이게 HTTP 요청을 보내는 거라는 걸 제대로 의식하지 못하고 있었다.
오늘 HTTP 요청/응답 구조를 배우고 나니, Network 탭에서 보이는 것들이 전부 의미있게 다가온다.
Day 3에서는 "파일을 받아오는구나" 정도였는데,
이제는 "GET 요청으로 JS 파일을 달라고 하면 200 OK와 함께 파일이 오는 것"이라는 걸 안다.
HTTP가 무상태라는 것도 재밌었다. 서버가 매번 "누구세요?"하는 건데,
그래서 쿠키나 JWT 같은 인증 기술이 필요한 거였다.
Day 19에서 배운 CSRF도 여기서 연결된다 — 쿠키가 자동으로 같이 가니까 공격이 가능한 것.
매일 배울수록 이전에 배운 것들이 연결되는 게 느껴진다.
📚 다음 학습 예고
Day 22: HTTP 메서드 (GET, POST, PUT, DELETE) + REST API
오늘 배운 "요청 라인"에서 GET만 봤는데,
POST, PUT, DELETE는 뭐가 다른지, REST API는 어떤 규칙인지 배운다.
#프론트엔드 #HTTP #네트워크 #요청 #응답 #fetch #2년차개발자 #기초다시쌓기
