[네트워크] HTTP라는 용어를 나는 이해하고 개발하고 있을까

💬 서론 및 개요

개발을 하다 보면 HTTP라는 용어를 정말 많이 접하게 되는데요. 하지만 문득 “내가 이 프로토콜을 진짜 제대로 이해하고 쓰고 있는 걸까?”라는 의문이 생겼습니다.

이번 글에서는 김정환 님의 강의를 듣고 이해하면서 그동안 은연중에 넘어가던 하이퍼텍스트의 개념부터 데이터가 오가는 약속인 HTTP의 구조, 그리고 실무에서 마주치는 상태 코드들의 상세한 의미까지 깊게 파보며 정리해 보았습니다.

1️⃣ 하이퍼텍스트(HyperText)가 대체 뭘까?

우리가 흔히 보는 일반적인 책은 1페이지 다음엔 2페이지, 그다음엔 3페이지… 이렇게 순서대로 읽어야 하는데 이걸 **‘선형적’**이라고 합니다.

하지만, 하이퍼텍스트는 초월적이라는 뜻의 Hyper + 텍스트가 합쳐진 용어입니다. 웹사이트에서 글을 읽다가 링크 영역을 클릭하면 다른 문서나 페이지로 이동하는 것처럼, 글을 읽다 순서에 얽매이지 않고 이 정보 저 정보 옮겨 다닐 수 있는 비선형적인 텍스트를 말합니다. 그걸 ‘초월적이다’라고 어렵게 표현하게 되었지만 쉽게 웹페이지로 이해하면 될 것 같습니다.

2️⃣ HTML 문서를 어떻게 옮길까? HTTP로!

이 하이퍼텍스트를 내 컴퓨터에서 가져와서 보려면 어떻게 해야 할까요? 전 세계 컴퓨터 종류가 수만 가지인데, 서로 자기 마음대로 데이터를 보내면 못 알아듣습니다. 그래서 영어처럼 만국 공용어를 두고 형식을 갖춰 대화하자고 한 게 바로 HTTP입니다.

“우리가 하이퍼텍스트를 주고받을 때는 이런 형식으로 대화하자!”라고 정한 표준 규칙이 HTTP입니다. HTTP의 핵심 키워드를 뜯어보면 다음과 같습니다.

Transfer (전송): 서버에 있는 HTML 파일을 내 브라우저(로컬)로 물리적으로 옮기는 행위입니다.
Protocol (규칙, 통신 규약): “주문은 GET으로 하고, 성공하면 200이라는 숫자를 붙여주자” 같은 약속입니다. 이 약속이 없으면 서버가 데이터를 줘도 브라우저가 해석을 못 합니다.

1) HTTP는 문서를 나누기 위해 태어났다

처음엔 ‘연구소의 논문을 편하게 공유하자’는 아주 단순한 생각에서 시작됐습니다. 1991년의 HTTP/0.9는 정말 단순했는데, 팀 버너스리가 하이퍼텍스트(링크)를 통해 문서를 연결하려고 만들었습니다. 0.9 버전에서 시작해 우리가 지금 쓰는 1.1, 2, 그리고 최근의 3(UDP/QUIC 기반)까지 진화하며 속도와 보안이 개선되어 온 것입니다.

🤝 3. HTTP의 흐름: 통신에도 예의가 있다

데이터를 주고받기 전에 먼저 통로를 뚫어야 합니다. 이를 3-Way Handshake라고 하는데, 우리가 일상에서 전화를 거는 과정에 비유하면 아주 명확합니다.

3-Way Handshake (통로 확보)
- 내가 상대방에게 전화를 겁니다.
- 연결음이 나오기 전, 상대방에게 통화를 연결할 수 있는지 내 통화는 잘 연결되어 있는지 확인합니다.
- 확인이 완료되면, 통화가 가능하다고 인식되어 통화연결음이 들려옵니다.
전송/수신 (데이터 교환)
- 연결이 된 후 “여보세요”라고 말하며 용건을 전달합니다. 이게 실제 HTTP 메시지를 던지고 받는 단계입니다.
종료 (연결 해제)
- 볼일 다 봤으면 “수고하셨습니다” 하고 전화를 끊듯이 연결을 해제합니다. 무작정 끊는 게 아니라 서로 확인하고 끊는 것이 통신의 예의입니다.

🔍 4. 실습: 구글 서버는 어떻게 응답할까?

이론으로 배운 내용을 확인하기 위해 터미널에서 curl 명령어로 구글 서버에 요청을 보내보았습니다. 실제 로그를 통해 HTTP의 동작 과정을 상세히 볼 수 있었습니다.

① `curl -v https://google.com` : 301 리다이렉트 응답 확인

curl -v https://google.com 요청에서는 서버 연결과 TLS 협상 이후, 301 Moved 리다이렉트 응답이 내려오는 과정을 확인할 수 있습니다.

로그를 보면 Connected to google.com 메시지와 함께 TLS handshake(Client hello, Server hello, CERT verify)가 진행됩니다. 이후 HTTP/2 301과 location: https://www.google.com/ 헤더가 내려오고, 하단에는 301 Moved HTML 본문이 함께 출력됩니다.

② `curl -v https://www.google.com` : 200 응답 헤더 확인

curl -v https://www.google.com으로 다시 요청하면, 리다이렉트 대상 주소에서 HTTP/2 200 정상 응답을 확인할 수 있습니다.

즉, 첫 요청(google.com)에서 받은 리다이렉트 안내를 따라 실제 서비스 주소(www.google.com)로 접속하면, content-type, set-cookie 같은 응답 헤더와 함께 정상 응답(200)을 받는 흐름입니다. 이번 실습은 이 두 단계 로그(2_1, 2_2) 기준으로 정리했습니다.

📍 5. URL = 인터넷상의 상세 주소

우리가 주소창에 치는 URL은 사실 여러 조각으로 나뉘어 각각의 역할을 수행합니다.

http://localhost:3000/ch01.txt?query=name#title

http://: 프로토콜 (어떤 규칙으로 대화할 건지 정합니다.)
localhost: 도메인 (어느 컴퓨터(서버)로 찾아갈 건지 정합니다.)
3000: 포트 (그 컴퓨터의 몇 번 문으로 들어갈 건지 정합니다.)
ch01.txt: 경로 (그 집의 어느 방에 있는 파일인지 위치를 지정합니다.)
?query=name: 쿼리 스트링 (서버에 전달할 추가 옵션입니다.)
#title: 프래그먼트 (페이지 내 특정 위치로 바로 점프하는 책갈피 역할입니다.)

✉️ 6. 메시지의 구조: 요청과 응답

HTTP 통신은 클라이언트의 요청(Request)과 서버의 응답(Response)이라는 메시지 형식을 따릅니다.

📤 요청(Request) 메시지

메서드, 경로, 헤더, 본문으로 구성됩니다.

메서드 종류: GET(조회), POST(생성), PUT(전체 수정), PATCH(부분 수정), DELETE(삭제) 등.
구조 예시:

GET /index.html HTTP/1.1 (시작줄: 메서드, 경로, 버전)
Host: example.com (헤더: 보내는 이의 정보)
(한 줄 띄고)
(본문: POST 등의 경우 데이터를 담음)

📥 응답(Response) 메시지

상태 코드, 응답 헤더, 응답 본문으로 이루어져 있습니다.

구조 예시:

HTTP/1.1 200 OK (시작줄: 버전, 상태코드)
Content-Type: text/html (헤더: 데이터의 정체)
(한 줄 띄고)
<html>...</html> (본문: 실제 웹페이지 내용)

🚥 7. HTTP 상태 코드 (Status Code) 상세 의미

서버가 나에게 보내는 “결과 보고서”입니다. 첫 숫자에 따라 의미가 완전히 달라집니다.

분류	의미	상세 설명 및 주요 코드
1xx	조건부 응답	요청을 받았으며 작업을 계속 진행 중임을 알림.
2xx	성공	요청이 성공적으로 처리됨. (200 OK, 201 Created 등)
3xx	리다이렉션	주소가 바뀌었으니 다른 곳으로 가라는 등의 추가 동작 지시. (301, 304 등)
4xx	클라이언트 오류	요청이 잘못됨. (400 Bad Request, 403 Forbidden, 404 Not Found 등)
5xx	서버 오류	서버가 처리를 못 함. (500 Internal Error, 502 Bad Gateway, 503 Service Unavailable 등)

😱 8. HTTP가 없다면 어떻게 될까?

전 세계 어디서 만든 콘센트든 우리나라 220V 구멍에 딱 맞는 이유는 **‘규격’**이 있기 때문입니다. 규격이 없으면 이사 갈 때마다 변압기를 직접 만들어야 하겠죠. HTTP가 없다는 건 다음과 같은 대혼란을 의미합니다.

언어의 파편화: 서버와 브라우저가 서로 다른 방식으로 데이터를 주고받으려 해 말이 안 통합니다.
데이터 해석 불가: Content-Type 정보가 없다면, 브라우저는 0과 1의 덩어리를 보고 이게 고양이 사진인지 알 길이 없습니다.
상태 파악 불능: 404 같은 공통 코드가 없다면, 에러 처리를 위해 수천 가지 경우의 수를 코딩해야 합니다.
보안 부재: 표준화된 암호화 규칙을 만들 수 없어 해커들이 데이터를 가로채기가 너무 쉬워집니다.

🔚 끝으로

요약하자면 HTTP는 페이지(HyperText)를 주고받기 위해 만든 전 세계 공용 대화 규칙입니다. HTML은 이 페이지를 만들기 위한 언어이고, 우리는 이를 편하게 사용하기 위해 모두가 약속한 HTTP를 써서 소통하고 있는 것입니다.

주니어 개발자로서 당연하게만 여겼던 HTTP의 기반을 다져보니, 편리한 웹 환경이 얼마나 정교한 약속 위에 세워졌는지 새삼 느끼게 되었습니다. 다음 글에서는 더 깊이 있는 네트워크 주제로 돌아오겠습니다.

읽어주셔서 감사합니다 😊