01 / 15
SESSION 23 · Part 5 웹 개발

HTTP —
웹의 공용어

요청과 응답, 상태 코드로 말한다

02 / 15
🎯

이 세션에서
배우는 것

📮
HTTP 메서드
GET/POST/PUT/DELETE의 용도를 구분한다
🚦
상태 코드
2xx/3xx/4xx/5xx의 의미를 이해한다
📦
요청 구조
메서드, URL, 헤더, 바디의 역할을 안다
03 / 15
💭

왜 HTTP를
알아야 할까?

웹의 모든 데이터 교환은 HTTP로 이루어진다.
API 연동, 로그인, 결제 — 모두 요청/응답의 반복이다.

HTTP를 이해하면 서버 개발과 디버깅의 절반은 해결된다.

04 / 15

주요 메서드

CRUD(Create/Read/Update/Delete)와 1:1로 대응된다.

📥
GET
조회 (Read)
📝
POST
생성 (Create)
✏️
PUT
전체 수정
🔧
PATCH
부분 수정
🗑️
DELETE
삭제
🔍
HEAD
헤더만 조회
⚙️
OPTIONS
지원 옵션 확인
🔗
CONNECT
터널 연결
05 / 15
📮

HTTP 메서드 —
더 깊게 이해하기

GET과 POST는 단순히 데이터 방향의 차이가 아니다 — 설계 철학이 다르다.

1
GET — 데이터 조회 (안전, 멱등)
URL에 파라미터가 노출된다 (?q=검색어). 북마크·공유 가능. 민감한 데이터는 절대 쓰지 않는다.
2
POST — 데이터 전송 (바디에 포함)
회원가입, 로그인 — 민감 정보가 바디에 들어가 URL에 노출되지 않는다. 반복 클릭 시 중복 주의.
3
PUT vs PATCH
PUT은 전체 교체, PATCH는 부분 수정. 닉네임만 바꾸려면 PUT 전체보다 PATCH가 효율적이다.
4
DELETE — 리소스 삭제
서버의 데이터를 삭제한다. 성공 시 200(OK) 또는 204(No Content)를 반환한다.
06 / 15

요청과 응답의 구조

클라이언트는 편지를 보내고, 서버는 답장을 보낸다.

🧑 클라이언트
→
📨 Request
method + URL + 헤더 + 바디
→
🖥️ 서버
🧑 클라이언트
←
📬 Response
상태 코드 + 헤더 + 바디
←
🖥️ 서버
POST /api/login HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer abc123

{ "email": "a@b.com", "password": "****" }
07 / 15
🗺️

카카오맵 지도 로딩 —
실제로는 어떻게?

지도 앱을 열면 겉보기에 하나의 화면이지만, 내부에서는 수십 번의 HTTP 요청이 발생한다.

📱 앱 실행
GET /api/map
→
🖥️ 서버
타일 계산
→
🗺️ 이미지 타일
GET 수십 개
→
📍 핀·경로
JSON 응답

핵심: 지도 한 장은 여러 조각(타일)으로 나뉘어 병렬 GET 요청으로 받아온 후 화면에 조합된다 — HTTP의 효율적 설계가 빠른 지도를 만든다.

08 / 15

상태 코드 — 3자리 숫자의 의미

첫 자리로 결과의 큰 방향을 알 수 있다.

200
OK — 정상 응답
201
Created — 생성 완료
301
Moved — 영구 이동
304
Not Modified — 캐시 사용
400
Bad Request — 잘못된 요청
401
Unauthorized — 인증 필요
404
Not Found — 자원 없음
500
Server Error — 서버 오류

2xx 성공 · 3xx 리다이렉트 · 4xx 클라이언트 오류 · 5xx 서버 오류

09 / 15
📱

실생활에서
이렇게 쓰여요

우리가 매일 사용하는 앱과 서비스 속에 HTTP가 녹아 있다.

🗺️
카카오맵 지도 로딩
화면에 보이는 지도 타일을 GET 요청으로 받아온다 — 스크롤하면 새 타일을 추가 요청
📝
회원가입
이메일·비밀번호를 POST 요청의 바디에 담아 서버로 전송, 201 Created 응답을 받는다
💳
결제
결제 정보를 HTTPS POST로 암호화해 전송 — 중간에 가로채도 내용을 알 수 없다

💡 이 개념이 없다면 서버와 클라이언트가 대화할 규칙이 없어 인터넷 자체가 동작하지 않는다.

10 / 15
💡

자주 하는
오해 바로잡기

이렇게 생각하기 쉽지만, 실제로는 조금 다릅니다.

❌ 흔한 오해
  • HTTPS는 HTTP보다 훨씬 느리다
  • 상태 코드 200이면 항상 완전히 성공한 것이다
  • 쿠키는 해킹 도구다
✓ 실제로는
  • HTTPS의 TLS 암호화 오버헤드는 현대 하드웨어에서 미미하다 (체감 불가)
  • 200 OK는 서버가 응답했다는 것 — 비즈니스 로직 오류는 바디를 봐야 안다
  • 쿠키는 로그인 상태 유지 등 정상적인 기술 — 악용될 수 있지만 그 자체는 도구
11 / 15
✉️

HTTP는 우편 시스템이다

편지를 보내고 답장을 받는 것과 정확히 같은 구조.

📮 우편 비유
수신자 주소
=
URL — 어디로 보낼까
우표·반송 주소
=
헤더 — 메타 정보
편지지 내용
=
바디 — 실제 데이터
우체국 답장
=
Response — 상태 코드 + 데이터
등기 우편
=
HTTPS — 암호화된 안전 통신
12 / 15
🤖

이걸 알면
AI와 이렇게 대화해요

HTTP 개념을 이해하면 Claude나 ChatGPT를 훨씬 잘 활용할 수 있다.

👤
API 호출하는 코드 짜주세요.
🤖
어떤 API인가요? GET인가요 POST인가요? 인증은 어떻게 하나요? 응답 형식은 JSON인가요?
👤
JavaScript fetch로 https://api.example.com/posts에 GET 요청을 보내고 JSON 응답을 파싱하는 코드 작성해줘. Authorization: Bearer 토큰도 헤더에 추가해줘.
🤖
fetch('https://api.example.com/posts', { headers: { Authorization: 'Bearer TOKEN' } }).then(r => r.json()).then(data => console.log(data)); — 이렇게 하면 됩니다!
13 / 15
✅

이렇게
이해하셨나요?

✅
맞게 이해하셨어요
GET은 데이터를 요청하고, POST는 데이터를 전송(생성)한다
❌
이렇게는 아니에요
HTTP와 HTTPS는 완전히 다른 프로토콜이다 (HTTPS는 HTTP에 TLS 암호화를 추가한 것)
✅
맞게 이해하셨어요
404는 클라이언트 오류(요청한 자원이 없음), 500은 서버 오류다
❌
이렇게는 아니에요
HTTP는 상태를 기억한다 (HTTP는 무상태 프로토콜 — 매 요청이 독립적이다)

💪 요청과 응답 구조를 이해했다면, API 연동과 서버 개발의 첫 걸음을 뗀 겁니다!

14 / 15
📌

핵심 정리

📮
메서드
GET/POST/PUT/DELETE
CRUD와 대응
🚦
상태 코드
200/404/500
결과의 종류
📬
헤더 + 바디
메타 정보와
실제 데이터
🔄
요청/응답
무상태(stateless)
단발성 대화
🔒
HTTPS
TLS로 암호화된
안전한 HTTP
🌐
API
HTTP 위에서
서비스가 대화한다
15 / 15
🚀

다음 세션
Session 24 · 반응형 웹 디자인

모바일부터 데스크탑까지 — 화면 크기에 맞게 유연한 웹을 만든다.
미디어 쿼리, 브레이크포인트, Tailwind의 개념을 배운다.

💡 기억할 것: 웹의 모든 대화는 요청과 응답이다.

슬라이드 목록