01강
HTTP — 요청과 응답의 규칙
서로 모르는 컴퓨터 수십억 대가 같은 양식으로 대화하는 법
먼저 보면 좋은 강의: 웹 요청의 해부
단계별로 보기
스페이스바로 재생/정지, 좌우 화살표로 단계 이동, R로 처음으로 돌아갑니다.
대기 중1 / 4 단계 — 요청은 정해진 칸을 채운 서류다
브라우저가 보내는 것은 자유로운 문장이 아니라 칸이 정해진 서류입니다. 첫 줄에 "무엇을(GET) 어디에서(/articles/42)"를 적고, 아래에 부가 정보를 적습니다. 서버는 이 서류를 처음 받아보는 상대에게서 받았지만, 양식을 알기 때문에 읽을 수 있습니다.
이 강의를 마치면
- HTTP 요청이 메서드·경로·헤더·본문으로 나뉜다는 것을 설명한다.
- 가져오기(GET)와 바꾸기(POST)가 왜 구분되어야 하는지 근거를 든다.
- 상태 코드가 응답의 결과를 한 줄로 요약한다는 것을 이해한다.
- 중간 장치들이 내용을 몰라도 규칙만으로 일할 수 있는 이유를 설명한다.
공통 양식이라는 발명
앞 강의에서 브라우저가 서버에 "이 페이지를 주세요"라고 말하는 단계를 봤습니다. 이번에는 그 말을 정확히 어떤 형식으로 하는가를 봅니다.
생각해 보면 이상한 일입니다. 내 노트북과 지구 반대편의 서버는 만든 회사도, 운영체제도, 만들어진 연도도 다릅니다. 서로에 대해 아무것도 모릅니다. 그런데 어떻게 대화가 될까요?
답은 단순합니다. 모두가 같은 양식을 쓰기로 약속했기 때문입니다. 그 양식의 이름이 HTTP입니다.
관공서 민원 서류에 비유하면
민원실에 가면 종이 한 장을 씁니다. 그 종이에는 칸이 정해져 있습니다.
| 서류의 칸 | HTTP의 이름 | 예 |
|---|---|---|
| 무엇을 해달라는가 | 메서드 | 발급해 주세요 / 신고합니다 |
| 어떤 건에 대해서인가 | 경로 | 주민등록등본 |
| 부가 정보 | 헤더 | 신청인 연락처, 통수, 한국어로 |
| 첨부 내용 | 본문 | 신고서에 적을 내용 |
담당 직원이 누구든, 어느 지역 민원실이든 이 양식만 보면 무엇을 해야 하는지 압니다. 직원을 미리 알 필요가 없습니다. 양식을 알면 됩니다. HTTP가 하는 일이 정확히 이것입니다.
실제 요청은 이렇게 생겼습니다.
GET /articles/42 HTTP/1.1
Host: news.example.com
Accept-Language: ko첫 줄이 "무엇을(GET = 가져와 주세요) 어디에서(/articles/42)"이고, 아래가 부가 정보입니다.
가져오기와 바꾸기는 반드시 구분한다
메서드 중 실무에서 절대적으로 중요한 구분은 딱 하나입니다.
- GET — 가져오기만 합니다. 서버의 무엇도 바뀌지 않습니다.
- POST / PUT / DELETE — 서버의 무언가를 바꿉니다.
왜 이 구분이 중요할까요? GET은 마음대로 다시 해도 되지만, POST는 그렇지 않기 때문입니다.
네트워크가 잠깐 끊겨 응답을 못 받았다고 합시다. 요청이 서버에 도착했는지 안 했는지 알 수 없습니다. 이때 GET이면 그냥 한 번 더 보내면 됩니다. 기사를 두 번 읽는다고 문제가 생기지 않습니다. 하지만 POST가 "결제하기"였다면? 두 번 보내면 두 번 결제될 수 있습니다.
그래서 "새로고침하지 마세요"라는 경고 문구가 결제 화면에만 붙습니다. 조회 화면에는 붙지 않습니다. 이건 개발자의 변덕이 아니라 이 구분에서 나온 필연입니다.
응답의 첫 줄 — 상태 코드
서버의 답장도 정해진 양식입니다. 그리고 맨 앞에 세 자리 숫자가 붙습니다.
| 코드 | 뜻 | 누구 잘못인가 |
|---|---|---|
| 200 | 됐습니다 | — |
| 404 | 그런 건 없습니다 | 요청한 쪽 |
| 401 / 403 | 당신은 권한이 없습니다 | 요청한 쪽 |
| 500 | 우리 쪽이 고장났습니다 | 서버 쪽 |
| 503 | 지금은 감당이 안 됩니다 | 서버 쪽 |
숫자의 첫 자리만 봐도 성격을 알 수 있게 설계되어 있습니다. 2로 시작하면 성공, 4로 시작하면 보낸 쪽 문제, 5로 시작하면 받은 쪽 문제입니다.
이 규칙이 진짜로 벌어주는 것
여기가 이 강의의 핵심입니다. 요청과 응답 사이에는 사실 여러 장비가 끼어 있습니다. 캐시, 로드밸런서, 방화벽, 통계 수집기 같은 것들입니다.
이 장비들은 여러분의 서비스가 무엇을 하는 회사인지 모릅니다. 쇼핑몰인지 병원 예약 시스템인지 관심도 없습니다. 그런데도 유용한 일을 합니다.
- 캐시는
GET이라는 글자만 보고 "이건 저장해 뒀다 재사용해도 되겠군"이라고 판단합니다. - 로드밸런서는
500이 계속 나오는 서버를 보고 "저 서버는 빼자"라고 판단합니다. - 모니터링은
5xx비율만 세어 "장애입니다"라고 경보를 울립니다.
즉 공통 규칙은 중간에 있는 모두가 일할 수 있게 만드는 장치입니다. 만약 회사마다 자기 양식을 썼다면 이 중 아무것도 자동으로 동작하지 않았을 것입니다. 규칙이 지루한 약속처럼 보여도, 그 지루함이 인터넷 규모를 만들었습니다.
이 강의가 단순화한 것
교육용 모형은 언제나 무언가를 생략합니다. 무엇을 생략했는지 아는 것도 학습의 일부입니다.
전제한 것
- 요청 하나에 응답 하나가 대응한다고 본다. 실제 HTTP/2·HTTP/3에서는 한 연결 위로 여러 요청이 동시에 오간다.
- 메서드는 GET과 POST 중심으로만 다룬다. PUT·PATCH·DELETE·HEAD·OPTIONS는 성격만 언급한다.
- GET이 서버 상태를 바꾸지 않는다는 것은 규약상의 약속이지 기술적 강제가 아니다. 규약을 어기는 서버도 만들 수 있다.
- 헤더와 본문의 실제 바이트 인코딩, 압축, 청크 전송은 다루지 않는다.
다루지 않은 것
- HTTP/2의 헤더 압축(HPACK)과 스트림 다중화
- 쿠키·인증 헤더의 구체적 규격
- 조건부 요청(If-None-Match)과 캐시 제어 헤더의 세부 규칙
- CORS와 브라우저 보안 모델
더 읽을거리: RFC 9110 — HTTP Semantics · RFC 9112 — HTTP/1.1
이제 직접 만들어 보세요
읽어서 아는 것과 만들어서 아는 것은 다릅니다. 컴포넌트를 배치하고 트래픽을 흘려서 실제로 동작하는지 확인해 보세요.
이 강의에 물어보기
하루 5번이 강의 본문만 근거로 답합니다. 강의에 없는 내용은 지어내지 않습니다.