C-2: HTTP와 웹 통신

안녕하세요, 홍순구 튜터입니다. CS 기초 여덟 번째 시간이에요.

지난 시간 우리는 네트워크를 계층으로 펼치고, 그 위에서 TCP와 UDP로 데이터를 주고받는 토대를 깔았어요. TCP는 연결을 맺고 신뢰성을 꼼꼼히 챙기는 쪽, UDP는 연결 없이 빠르게 던지는 쪽이었죠. 그런데 그 위에서 "실제로 무슨 말을 주고받느냐"는 아직 안 봤습니다. 여러분이 브라우저에 주소를 치고 사이트가 열리는 그 순간, 브라우저와 서버는 어떤 약속된 말투로 대화할까요? 그 말투가 바로 오늘의 주인공 HTTP(HyperText Transfer Protocol)예요.

HTTP는 신뢰성이 중요한 통신이라, 지난 시간 배운 그 TCP 위에서 돕니다. 계층의 맨 위 응용 계층에 자리한 약속이죠. 우리가 웹에서 하는 거의 모든 일 — 페이지 열기, 로그인, 사진 올리기, 좋아요 누르기 — 이 전부가 HTTP 요청과 응답의 주고받음이에요. 오늘은 이 요청과 응답이 어떻게 생겼는지, 어떤 메서드로 부탁하고(GET·POST), 응답에 붙는 세 자리 숫자가 뭘 뜻하는지(200·404·500), 로그인 상태를 무상태인 HTTP가 어떻게 기억하는지(쿠키·세션), 그리고 그 대화를 도청으로부터 지키는 HTTPS와 TLS까지 한 겹씩 벗겨봅니다.

지난 시간 끝에 흘려둔 이야기도 오늘 회수해요. "빠르지만 못 믿을 UDP 위에 신뢰성을 다시 얹은 QUIC, 그걸 쓰는 HTTP/3" 말이에요. HTTP가 1.1에서 2로, 다시 3으로 진화하며 왜 굳이 TCP를 버리고 UDP 위로 옮겨갔는지 — 지난 시간 배운 TCP vs UDP의 트레이드오프가 그 답의 열쇠가 됩니다. 오늘의 마지막 Step에서 만나요.

HTTP는 기술 면접에서 네트워크만큼이나 단골입니다. "GET과 POST의 차이가 뭔가요"·"쿠키와 세션은 어떻게 다른가요"·"HTTPS는 어떻게 동작하나요"·"멱등성이 뭔가요"·"HTTP/2와 3의 차이는요" — 이 다섯은 거의 반드시 나와요. 오늘 원리부터 잡아서, 외운 한 줄이 아니라 풀어서 답할 수 있게 만듭니다.

오늘 우리가 걸을 길은 이렇습니다.

   오늘의 여정 — HTTP와 웹 통신

   ① HTTP란 — 웹의 공용어, 요청과 응답 (무상태)
   ② 요청·응답 들여다보기 — 메시지의 해부
   ③ HTTP 메서드와 멱등성 — GET·POST·PUT·PATCH·DELETE (면접 빈출)
   ④ 상태 코드 — 응답의 세 자리 숫자 (2xx·3xx·4xx·5xx)
   ⑤ 쿠키 vs 세션 — 무상태를 어떻게 기억하나 (면접 빈출)
   ⑥ 대칭키 vs 비대칭키 — 암호화의 두 열쇠
   ⑦ HTTPS와 TLS 핸드셰이크 — 대화를 도청에서 지키기 (면접 빈출)
   ⑧ HTTP 버전 진화 — 1.1 → 2 → 3, 그리고 QUIC (면접 빈출)

①~④는 "HTTP가 어떻게 생겼나"입니다. 무엇을 주고받고, 어떤 메서드로 부탁하고, 어떤 숫자로 답하는지죠. ⑤~⑧은 "그 위에 무엇을 더 얹나"예요. 무상태를 보완하는 쿠키·세션, 통신을 암호로 지키는 HTTPS, 그리고 더 빠르게 진화한 HTTP 버전들을 봅니다. 기본 골격을 먼저 세운 뒤 그 위에 살을 붙이는 흐름이에요.

💡 오늘 수업의 핵심 — "HTTP는 TCP 위에서 요청-응답으로 도는 무상태 약속이다. 메서드로 의도를 밝히고(멱등성), 상태 코드로 결과를 알리며, 쿠키·세션으로 상태를 기억하고, TLS로 암호화하면 HTTPS가 되고, 1.1→2→3으로 진화하며 더 빨라졌다" 🎯

🎯 학습 목표

• HTTP가 TCP 위에서 요청-응답으로 도는 무상태(stateless) 약속임을 이해하고, 요청·응답 메시지의 구조(시작줄·헤더·바디)와 주요 헤더를 읽어냅니다.
• 면접 1순위인 GET vs POST와 멱등성을 메서드의 성격으로 막힘 없이 답하고, 상태 코드(2xx/3xx/4xx/5xx)로 응답 결과를 분류하며, 쿠키 vs 세션으로 무상태를 보완하는 두 방식을 구분합니다.
• 대칭/비대칭 키의 차이에서 출발해 HTTPS와 TLS 핸드셰이크가 어떻게 통신을 암호화하는지 설명하고, HTTP 1.1 → 2 → 3(QUIC) 진화를 멀티플렉싱과 UDP 트레이드오프로 풀어냅니다.

Step 1: "HTTP란 — 웹의 공용어, 요청과 응답"

HTTP(HyperText Transfer Protocol)는 웹에서 브라우저와 서버가 데이터를 주고받기 위해 약속한 말투예요. 한국 사람끼리는 한국어로, 영어권 사람끼리는 영어로 대화하듯, 웹에서는 HTTP라는 공용어로 대화합니다. 여러분이 주소창에 무언가를 치거나 링크를 클릭하면, 브라우저는 이 HTTP 형식에 맞춰 서버에 말을 걸어요.

여기서 지난 시간 이야기가 바로 이어집니다. HTTP는 한 글자도 틀리면 안 되는 통신이라, 신뢰성을 보장하는 TCP 위에서 돕니다. C-1에서 본 계층 그림을 떠올리면, HTTP는 맨 위 응용 계층에 있고 그 아래 전송 계층의 TCP가 데이터를 안전하게 날라주는 구조예요. 그래서 HTTP를 쓰면 우리는 "데이터가 빠지거나 순서가 뒤바뀌면 어쩌지"를 걱정할 필요가 없어요. 그 일은 아래층 TCP가 알아서 해주니까요. (단 하나, 가장 최신인 HTTP/3는 UDP 위에서 도는데, 그 반전은 오늘 마지막 Step에서 다룹니다.)

HTTP의 대화에는 분명한 규칙이 하나 있습니다. 항상 클라이언트가 먼저 묻고, 서버가 답한다는 거예요. 브라우저(클라이언트)가 "이 페이지 줘"라고 요청(request)을 보내면, 서버가 "여기 있어"라고 응답(response)을 돌려줍니다. 이 한 쌍의 주고받음이 HTTP의 기본 단위예요. 중요한 건, 서버가 먼저 클라이언트에게 말을 걸 수는 없다는 점입니다.

   HTTP 는 항상 클라이언트가 먼저 묻고, 서버가 답한다

   Client ──── 요청(Request): "이 페이지 줘" ────▶ Server
   Client ◀─── 응답(Response): "여기 있어"   ─────  Server

   한 번의 요청에 한 번의 응답. 서버가 먼저 말을 걸 수는 없다.

이제 HTTP의 가장 중요한 성격 하나를 짚을게요. HTTP는 무상태(stateless)입니다. 무슨 뜻이냐면, 서버가 이전 요청을 전혀 기억하지 않는다는 거예요. 각 요청은 완전히 독립적이라, 방금 전에 같은 사람이 다른 요청을 보냈다는 사실조차 서버는 모릅니다. 매번 처음 보는 손님처럼 대하는 점원을 떠올리면 돼요. 전에 백 번을 왔어도, 방금 막 주문했어도, 늘 "처음 뵙겠습니다"로 시작하는 점원이죠.

왜 이렇게 만들었을까요? 서버가 모든 손님의 상태를 일일이 기억하려면 부담이 큽니다. 무상태로 두면 서버는 요청 하나하나만 처리하면 되니 단순하고, 서버를 여러 대로 늘리기도 쉬워요(아무 서버나 요청을 받아 처리하면 되니까). 이 단순함과 확장성이 무상태의 힘입니다. 하지만 곧바로 의문이 생기죠. "서버가 날 기억 못 하면, 로그인은 어떻게 유지되지?" 바로 그 문제를 푸는 게 뒤에서 배울 쿠키와 세션이에요. 일단 "HTTP 자체는 기억을 못 한다"는 사실만 단단히 잡아둡시다.

🎯 면접에서는 이렇게 답하세요

"HTTP는 웹에서 클라이언트와 서버가 데이터를 주고받는 응용 계층 프로토콜입니다. 신뢰성이 필요해 보통 TCP 위에서 돌고, 클라이언트의 요청과 서버의 응답이 한 쌍을 이루는 요청-응답 구조죠. 가장 큰 특징은 무상태(stateless)입니다. 서버가 이전 요청을 기억하지 않아 각 요청이 독립적이에요. 덕분에 서버가 단순해지고 수평 확장이 쉽지만, 로그인 같은 상태 유지는 HTTP 혼자 못 해서 쿠키·세션으로 보완합니다."

Step 2: "요청·응답 들여다보기 — 메시지의 해부"

HTTP가 요청과 응답을 주고받는다는 건 알았어요. 그럼 그 요청과 응답은 실제로 어떻게 생겼을까요? 겉보기엔 복잡해 보여도, 뜯어보면 누구나 읽을 수 있는 글자(텍스트)입니다. 요청도 응답도 똑같이 네 토막으로 이뤄져 있어요. 시작줄 · 헤더 · 빈 줄 · 바디입니다.

먼저 요청 메시지를 봅시다.

   HTTP 요청 메시지 — 위에서 아래로 4토막

   [시작줄]  GET /users/1 HTTP/1.1         ← 메서드 + 경로 + 버전
   [헤더]    Host: api.example.com         ← 어느 서버로
             Accept: application/json      ← 어떤 형식을 원하는지
             Authorization: Bearer eyJ...  ← 인증 정보
   [빈 줄]   (헤더의 끝을 알리는 빈 줄)
   [바디]    (GET 은 보통 비어 있음)

맨 위 시작줄(요청줄)이 핵심이에요. GET /users/1 HTTP/1.1을 풀면 "GET이라는 방식으로(메서드), /users/1이라는 자원을(경로), HTTP/1.1 버전으로 요청한다"는 뜻입니다. 그 아래 헤더는 요청에 대한 부가 정보예요. 한 줄에 하나씩 이름: 값 형식으로 적어요. 어느 서버로 보내는지(Host), 어떤 형식의 응답을 원하는지(Accept), 내가 누구인지 증명하는 인증 정보(Authorization) 같은 것들이죠. 헤더가 끝나면 빈 줄 하나로 "헤더 여기까지"를 알리고, 그 뒤에 바디(본문)에 실제 데이터를 싣습니다. GET처럼 그냥 조회만 하는 요청은 보낼 데이터가 없어 바디가 비어요.

응답 메시지도 구조가 똑같습니다. 시작줄만 이름이 달라 상태줄이라고 불러요.

   HTTP 응답 메시지 — 같은 4토막

   [상태줄]  HTTP/1.1 200 OK                   ← 버전 + 상태코드 + 사유구절
   [헤더]    Content-Type: application/json
             Content-Length: 51
   [빈 줄]
   [바디]    { "id": 1, "name": "jaehoon" }    ← 실제 데이터

응답의 상태줄 HTTP/1.1 200 OK은 "HTTP/1.1 버전으로, 200이라는 상태 코드로 답한다(OK는 그 숫자의 사람용 설명)"는 뜻이에요. 이 상태 코드가 Step 4의 주제입니다. 헤더에는 바디가 어떤 형식인지(Content-Type), 길이가 얼마인지(Content-Length) 같은 정보가 담기고, 바디에 진짜 데이터가 실려요. 자주 쓰는 헤더 몇 개만 짚어둘게요.

실제로 한번 들여다보고 싶다면, 터미널에서 curl -v https://example.com을 쳐보면 됩니다. 이때 화면에 우리가 보낸 요청 헤더와 서버가 돌려준 응답 헤더, 그리고 맨 위 상태줄(200 OK 같은)이 그대로 찍혀요. 브라우저 개발자 도구의 Network 탭에서도 똑같이 볼 수 있고요. HTTP가 결국 사람이 읽을 수 있는 글자 덩어리라는 게 눈으로 확인됩니다.

🎯 면접에서는 이렇게 답하세요

"HTTP 요청과 응답은 둘 다 시작줄 · 헤더 · 빈 줄 · 바디 네 부분으로 이뤄집니다. 요청의 시작줄에는 메서드·경로·버전(GET /users/1 HTTP/1.1)이, 응답의 시작줄(상태줄)에는 버전·상태코드·사유구절(HTTP/1.1 200 OK)이 들어갑니다. 헤더는 이름: 값 형식의 부가 정보로 Host·Content-Type·Authorization 같은 게 담기고, 빈 줄로 헤더의 끝을 알린 뒤 바디에 실제 데이터를 싣습니다. 결국 HTTP 메시지는 사람이 읽을 수 있는 텍스트라는 점이 핵심입니다."

Step 3: "HTTP 메서드와 멱등성"

요청 시작줄의 맨 앞에 오는 메서드(method)는 "이 요청으로 뭘 하고 싶은가"라는 의도를 밝히는 동사예요. 같은 자원(예: /users/1)이라도 어떤 메서드로 요청하느냐에 따라 조회가 되기도, 수정이 되기도, 삭제가 되기도 합니다. 자주 쓰는 다섯 개를 봅시다.

가장 많이 쓰는 둘은 GET과 POST예요. 면접에서 "GET과 POST의 차이"는 거의 반드시 나오니 확실히 잡고 갑시다. GET은 데이터를 조회할 때 써요. 가져올 정보를 주소(URL)에 담아 보내고, 바디는 보통 비어 있습니다. 주소에 다 드러나니 북마크하거나 캐시(저장해두고 재사용)하기 좋아요. POST는 데이터를 생성하거나 제출할 때 씁니다. 회원가입, 댓글 작성, 파일 업로드처럼요. 보낼 데이터를 바디에 담아 보내고, 서버의 상태를 바꿉니다.

여기서 두 가지 성격이 나와요. 안전성(safe)은 "서버의 상태를 바꾸지 않는가"예요. GET은 그냥 읽기만 하니 안전하고, POST·PUT·DELETE는 뭔가를 바꾸니 안전하지 않습니다. 그래서 GET으로 데이터를 변경하게 만들면 안 돼요. 검색 엔진 크롤러가 링크를 훑다가 실수로 데이터를 지워버릴 수도 있거든요.

면접 단골인 멱등성(idempotent)은 한 단계 더 들어갑니다. "같은 요청을 여러 번 보내도 결과(서버 상태)가 한 번 보낸 것과 같은가"예요. 엘리베이터 버튼을 떠올리면 쉬워요. 버튼을 한 번 누르나 열 번 누르나 엘리베이터는 한 번 오죠(멱등). 반면 자판기 버튼은 누를 때마다 음료가 하나씩 나옵니다(비멱등).

• GET은 몇 번을 조회해도 서버는 그대로 → 멱등.
• PUT은 "이 자원을 이 값으로 통째 교체"라, 같은 요청을 열 번 보내도 결과는 그 값 하나 → 멱등.
• DELETE는 "이 자원을 지워"라, 한 번 지우면 없고 또 보내도 여전히 없음(결과는 '없음'으로 동일) → 멱등.
• POST는 "새로 만들어"라, 열 번 보내면 똑같은 게 열 개 생김 → 비멱등.

멱등성이 왜 중요하냐면, 네트워크가 불안해 응답을 못 받았을 때 안전하게 재시도할 수 있느냐를 가르기 때문이에요. GET·PUT·DELETE는 응답이 안 와도 다시 보내면 그만이지만, POST를 무턱대고 재시도하면 결제가 두 번 되거나 댓글이 두 개 달릴 수 있습니다. 그래서 "이 요청은 재시도해도 안전한가?"를 따질 때 멱등성이 기준이 돼요.

🎯 면접에서는 이렇게 답하세요

"GET은 데이터를 조회할 때 쓰고 파라미터를 URL에 담으며 서버 상태를 바꾸지 않아 안전하고 멱등합니다. POST는 데이터를 생성·제출할 때 쓰고 바디에 담으며 서버 상태를 바꿔 안전하지도 멱등하지도 않죠. 멱등성이란 같은 요청을 여러 번 보내도 결과가 한 번과 같은 성질인데, GET·PUT·DELETE는 멱등이고 POST·PATCH는 비멱등입니다. 이게 중요한 이유는 재시도 안전성입니다. 멱등한 요청은 응답을 못 받아도 다시 보내면 되지만, POST를 함부로 재시도하면 결제가 중복될 수 있어서요."

Step 4: "상태 코드 — 응답의 세 자리 숫자"

요청을 받은 서버는 응답의 맨 앞 상태줄에 상태 코드(status code)라는 세 자리 숫자를 붙여요. "네 요청이 어떻게 됐는지"를 숫자 하나로 알려주는 거예요. 우리가 흔히 보는 404가 바로 이 상태 코드입니다. 숫자가 수십 개라 외울 엄두가 안 나지만, 백의 자리 숫자로 다섯 무리만 나누면 한눈에 들어와요.

   상태 코드 — 백의 자리로 다섯 무리

   1xx  정보    "처리 중이에요" (거의 안 봄)
   2xx  성공    "요청대로 잘 됐어요"
   3xx  리다이렉션  "다른 데로 가세요"
   4xx  클라이언트 오류  "당신 요청이 잘못됐어요"
   5xx  서버 오류    "내(서버) 쪽이 문제예요"

핵심은 4xx와 5xx의 책임이 다르다는 점이에요. 4xx는 요청을 보낸 클라이언트 잘못이고, 5xx는 받은 서버 잘못입니다. 이 구분만 잡아도 장애가 났을 때 "내 요청이 틀렸나, 서버가 터졌나"를 코드만 보고 가늠할 수 있어요. 무리별로 자주 보는 코드를 짚어봅시다.

면접에서 즐겨 묻는 두 쌍이 있어요. 첫째, 401과 403의 차이입니다. 401 Unauthorized는 "네가 누구인지 모르겠다"는 인증 실패예요. 로그인을 안 했거나 토큰이 없는 경우죠. 403 Forbidden은 "네가 누군지는 알지만, 이건 네 권한 밖이다"입니다. 로그인은 했는데 관리자 전용 페이지에 들어가려는 경우 같은 거예요. 신분 확인(401)과 권한 확인(403)이 갈리는 지점입니다.

둘째, 301과 302의 차이예요. 둘 다 "다른 주소로 가라"는 리다이렉션이지만, 301은 영구 이전(주소가 아예 바뀜)이라 브라우저와 검색 엔진이 새 주소를 기억하고, 302는 임시 이전(잠깐만)이라 원래 주소를 계속 기억합니다. 사이트 도메인을 바꿀 땐 301, 잠시 점검 페이지로 보낼 땐 302를 써요.

🎯 면접에서는 이렇게 답하세요

"상태 코드는 백의 자리로 나뉩니다. 2xx 성공, 3xx 리다이렉션, 4xx 클라이언트 오류, 5xx 서버 오류죠. 핵심은 4xx는 요청한 쪽 잘못, 5xx는 서버 쪽 잘못이라는 구분입니다. 자주 헷갈리는 401과 403은, 401은 '누군지 모르겠다'는 인증 실패, 403은 '누군진 알지만 권한이 없다'는 인가 실패예요. 301과 302는 둘 다 리다이렉트지만 301은 영구 이전이라 새 주소를 기억하고, 302는 임시라 원래 주소를 유지합니다. 200(성공)·404(없음)·500(서버 오류) 정도는 숫자로 바로 떠올릴 수 있어야 하고요."

Step 5: "쿠키 vs 세션 — 무상태를 어떻게 기억하나"

Step 1에서 HTTP는 무상태라 서버가 이전 요청을 기억 못 한다고 했죠. 그런데 우리가 쓰는 사이트는 분명히 로그인 상태를 유지합니다. 한 번 로그인하면 페이지를 넘겨도 계속 로그인된 채로 있죠. 무상태인 HTTP 위에서 이걸 어떻게 해낼까요? 답은 매 요청에 "나 아까 그 사람이야"를 증명하는 표를 함께 보내는 것이고, 그 장치가 쿠키와 세션이에요.

쿠키(cookie)는 서버가 클라이언트에게 발급해 브라우저에 저장시키는 작은 데이터 조각입니다. 동작은 이래요.

   쿠키로 무상태 HTTP 가 로그인 상태를 기억하는 흐름

   ① 로그인      Client ──── ID/PW ────▶ Server    처음 한 번
   ② 쿠키 발급   Client ◀── Set-Cookie ── Server   응답 헤더에 sid=abc123
   ③ 저장        브라우저가 sid=abc123 보관
   ④ 재요청      Client ──── Cookie ───▶ Server    매 요청에 sid=abc123 자동 첨부
   ⑤ 인식        Client ◀── "너구나!" ── Server    서버가 sid 로 알아봄

로그인에 성공하면 서버가 응답 헤더에 Set-Cookie: sid=abc123을 실어 보냅니다(Step 2 헤더 표에서 본 그 헤더예요). 브라우저는 이 쿠키를 보관해뒀다가, 이후 그 사이트로 가는 모든 요청에 자동으로 Cookie: sid=abc123을 붙여요. 서버는 그 값을 보고 "아, 아까 로그인한 그 사람이구나" 하고 알아봅니다. 무상태 HTTP가 상태를 기억하는 것처럼 보이는 비결이 바로 이 자동으로 따라다니는 표예요.

여기서 갈림길이 나옵니다. 실제 정보를 어디에 두느냐예요. 쿠키에 사용자 정보를 직접 담으면(예: user=jaehoon; role=admin) 그 정보가 브라우저에 그대로 노출되고, 누가 쿠키를 훔치거나 조작하면 위험합니다. 그래서 보통은 세션(session)을 함께 써요. 세션은 실제 정보는 서버가 보관하고, 브라우저에는 그 정보를 가리키는 세션 ID만 쿠키로 넘기는 방식이에요. 쿠키에는 의미 없는 sid=abc123만 들어 있고, "abc123은 재훈이고 관리자"라는 진짜 내용은 서버 안에만 있습니다.

정리하면, 쿠키는 브라우저에 저장하는 작은 데이터라는 저장 방식의 이름이고, 세션은 정보를 서버에 두고 ID만 쿠키로 주고받는 상태 관리 방식이에요. 둘은 대립한다기보다, 세션이 쿠키를 도구로 쓰는 관계입니다. 참고로 서버에 상태를 두지 않고 서명된 토큰 자체에 정보를 담는 방식(JWT 같은)도 있는데, 그 깊은 설계는 백엔드·보안 과목에서 다뤄요. 여기선 "무상태 HTTP가 쿠키와 세션으로 상태를 흉내 낸다"는 원리까지 잡으면 충분합니다.

🎯 면접에서는 이렇게 답하세요

"HTTP가 무상태라 로그인 유지를 못 하니, 쿠키와 세션으로 보완합니다. 쿠키는 서버가 Set-Cookie로 발급해 브라우저에 저장하는 데이터로, 이후 요청마다 자동으로 따라붙어 서버가 사용자를 알아봅니다. 세션은 실제 정보를 서버에 두고 세션 ID만 쿠키로 주고받는 방식이고요. 차이는 저장 위치입니다. 쿠키 단독은 클라이언트에 정보가 있어 노출·조작 위험이 있지만 서버 부담이 없고, 세션은 서버에 둬서 안전하지만 사용자가 많으면 서버 메모리 부담과 서버 확장 시 세션 공유 문제가 생깁니다."

Step 6: "대칭키 vs 비대칭키 — 암호화의 두 열쇠"

지금까지 본 HTTP에는 큰 약점이 하나 있어요. 평문(암호화 안 된 글자)이라는 점입니다. Step 2에서 HTTP 메시지가 사람이 읽을 수 있는 텍스트라고 했죠. 그 말은, 중간에서 누가 가로채면 그대로 읽힌다는 뜻이기도 해요. C-1에서 본 것처럼 패킷은 목적지까지 가며 여러 장비를 거치는데, 그중 누군가 엿보면 로그인 비밀번호든 카드 번호든 다 들여다보입니다. 이 도청과 조작을 막으려면 암호화가 필요해요.

HTTPS의 암호화를 이해하려면 그 바탕인 두 가지 암호화 방식을 먼저 알아야 합니다. 대칭키와 비대칭키예요.

   대칭키 — 같은 열쇠 하나로 잠그고 푼다

   평문 ──[ KEY ]──▶ 암호문 ──[ KEY ]──▶ 평문
   잠글 때와 풀 때 똑같은 KEY. → 빠르다.
   문제: 이 KEY 를 상대에게 어떻게 안전하게 건네지? (전달 중 도청되면 끝)

   비대칭키 — 짝을 이루는 두 열쇠 (공개키 + 개인키)

   평문 ──[ 공개키 ]──▶ 암호문 ──[ 개인키 ]──▶ 평문
   공개키로 잠그면 짝꿍 개인키로만 풀린다.
   공개키는 막 뿌려도 안전(잠그기 전용). 개인키는 나만 보관. → 느리다.

대칭키(symmetric key) 방식은 잠그는 열쇠와 푸는 열쇠가 같습니다. 하나의 비밀 열쇠로 암호화하고, 받는 쪽이 똑같은 열쇠로 복호화해요. 연산이 단순해 빠른 게 장점입니다. 그런데 치명적인 문제가 있어요. 양쪽이 같은 열쇠를 가져야 하는데, 그 열쇠를 상대에게 어떻게 안전하게 전달하지? 열쇠를 그냥 보내면 그 과정에서 도청당하고, 그러면 암호가 통째로 풀려버립니다. 이게 대칭키의 근본 고민이에요.

비대칭키(asymmetric key) 방식은 이 문제를 영리하게 풉니다. 짝을 이루는 두 개의 열쇠 — 공개키(public key)와 개인키(private key)를 써요. 공개키로 잠그면 오직 짝꿍 개인키로만 풀리고, 그 반대도 됩니다. 핵심은 공개키는 아무에게나 줘도 안전하다는 거예요. 공개키는 잠그기만 할 수 있고 푸는 건 개인키만 할 수 있으니까요. 자물쇠를 만방에 뿌려도, 그걸 여는 열쇠는 나만 갖고 있는 셈이죠. 대신 연산이 복잡해 대칭키보다 느립니다.

여기서 자연스러운 발상이 나와요. 둘을 합치면 어떨까? 비대칭키로 "대칭키를 안전하게 전달"하는 문제만 풀고, 그다음부터는 빠른 대칭키로 실제 데이터를 암호화하는 거예요. 느린 비대칭키는 열쇠 교환에 잠깐만 쓰고, 무거운 본 통신은 빠른 대칭키가 맡는 하이브리드 방식이죠. 바로 이게 다음 Step에서 볼 TLS가 하는 일입니다. 두 방식의 장점만 취하는 거예요.

🎯 면접에서는 이렇게 답하세요

"대칭키는 잠그는 열쇠와 푸는 열쇠가 같아서 빠르지만, 그 열쇠를 상대에게 안전하게 전달하는 게 어렵습니다. 비대칭키는 공개키와 개인키 한 쌍을 쓰는데, 공개키로 잠그면 개인키로만 풀려요. 공개키는 아무에게나 줘도 되니 열쇠 전달 문제가 없지만 느립니다. 그래서 실제 HTTPS는 둘을 합쳐, 비대칭키로 대칭키를 안전하게 주고받은 뒤, 그 대칭키로 빠르게 본 통신을 암호화하는 하이브리드 방식을 씁니다. 느린 비대칭은 열쇠 교환에만, 빠른 대칭은 본 통신에 쓰는 거죠."

Step 7: "HTTPS와 TLS 핸드셰이크 — 대화를 도청에서 지키기"

이제 조각을 맞출 차례예요. HTTPS는 별게 아니라 HTTP에 보안(S)을 입힌 것입니다. 정확히는 HTTP 메시지를 TLS(Transport Layer Security)라는 보안 계층으로 감싸 암호화한 거예요. 기본 포트도 HTTP의 80번 대신 443번을 씁니다. 브라우저 주소창의 자물쇠 아이콘이 바로 "이 연결은 TLS로 암호화됐다"는 표시예요. (TLS는 예전 SSL의 후신이고, 지금 표준은 TLS 1.3입니다. 옛 버전인 1.0·1.1은 취약점 때문에 폐기됐어요.)

TLS가 푸는 문제는 두 가지예요. 암호화(엿봐도 못 읽게)와 인증(상대가 진짜 그 서버가 맞는지). 암호화는 Step 6의 하이브리드 방식으로 해결합니다. 그럼 인증은요? 여기서 인증서(certificate)가 등장해요. 서버는 CA(Certificate Authority, 인증기관)라는 믿을 만한 third party에게서 "이 서버는 진짜 example.com이 맞다"는 도장이 찍힌 인증서를 미리 발급받아 둡니다. 인증서 안에는 서버의 공개키도 들어 있어요. 브라우저는 이 인증서의 CA 서명을 검증해, 지금 통신하는 상대가 가짜가 아닌지 확인합니다. 정부가 발급한 신분증을 믿는 것과 같은 원리예요.

이 모든 게 TLS 핸드셰이크라는 절차에서 일어납니다. C-1의 3-way handshake가 TCP 연결을 맺는 인사였다면, TLS 핸드셰이크는 그 위에서 암호화 통신을 트는 인사예요. TLS 1.3 기준으로 간략히 보면 이렇습니다.

   TLS 핸드셰이크 (TLS 1.3) — 암호화 통신을 트기 전의 인사

   클라이언트(Client)                               서버(Server)
       │                                                    │
       │  ① ClientHello ──────────────────────────────────▶ │   "이런 암호 방식들 쓸 수 있어요"
       │                                                    │
       │  ◀── ② ServerHello + Certificate ───────────────── │   "이걸로 합시다 + 내 인증서(공개키)"
       │                                                    │
       │  ③ 인증서 검증 + 세션키 합의 ────────────────────▶ │   "신분 확인! 이 대칭키로 가요"
       │                                                    │
       ▼                                                    ▼
     이후 빠른 대칭키로 암호화 통신 (Application Data)

① 클라이언트가 ClientHello로 "내가 쓸 수 있는 암호 방식은 이런 것들이에요"라며 인사를 건넵니다. ② 서버가 ServerHello로 "그럼 이걸로 합시다"라고 답하며 자기 인증서(공개키 포함)를 함께 보내요. ③ 클라이언트가 그 인증서를 검증해 상대가 진짜임을 확인하고, 양쪽이 이번 통신에 쓸 대칭키(세션키)를 안전하게 합의합니다. 이 합의 과정에 Step 6의 비대칭키가 쓰여요. 핸드셰이크가 끝나면, 그 뒤로는 합의한 빠른 대칭키로 실제 데이터를 암호화해 주고받습니다.

정리하면, HTTPS는 인증서로 상대가 진짜인지 확인하고(인증), 비대칭키로 대칭키를 안전하게 합의한 뒤(키 교환), 그 대칭키로 본 통신을 빠르게 암호화(기밀) 하는 거예요. Step 6에서 깔아둔 하이브리드 발상이 실제로 동작하는 자리입니다. 참고로 이 TLS 1.3은 다음 Step에서 볼 HTTP/3가 반드시 요구하는 보안 토대이기도 해요.

🎯 면접에서는 이렇게 답하세요

"HTTPS는 HTTP를 TLS로 감싸 암호화한 것으로, 443 포트를 씁니다. TLS는 인증과 암호화 두 문제를 풀어요. 먼저 서버가 CA가 서명한 인증서(공개키 포함)를 제시하면 브라우저가 그 서명을 검증해 상대가 진짜인지 확인합니다(인증). 그다음 비대칭키로 대칭키(세션키)를 안전하게 합의하고, 이후 본 통신은 빠른 대칭키로 암호화합니다. 즉 느린 비대칭키는 키 교환과 인증에만 쓰고, 무거운 본 통신은 빠른 대칭키가 맡는 하이브리드 구조예요. 이 협상 전 과정이 TLS 핸드셰이크입니다."

Step 8: "HTTP 버전 진화 — 1.1 → 2 → 3, 그리고 QUIC"

HTTP도 세월 따라 진화했어요. 같은 요청-응답 원리는 그대로 두되, 더 빠르게 주고받으려고 버전을 올려왔습니다. 이 진화를 따라가면 자연스럽게 지난 시간 흘려둔 QUIC 이야기까지 닿아요.

HTTP/1.1은 오래도록 웹의 기본이었어요. 연결을 매번 새로 맺지 않고 재사용하는 keep-alive로 한 번 맺은 TCP 연결에서 여러 요청을 처리했죠. 그런데 한계가 있었습니다. 한 연결에서 요청을 한 줄로 세워 순서대로 처리하다 보니, 앞 요청이 느리면 뒤 요청이 전부 기다려야 했어요. 이걸 HOL 블로킹(Head-of-Line blocking, 줄 맨 앞이 막힘)이라고 합니다. 그래서 브라우저는 꼼수로 연결을 여러 개 열어 우회했어요.

   HTTP/1.1 — 한 연결에서 요청을 한 줄로 (앞이 막히면 뒤도 대기)

   요청A ──▶ [처리…] ──▶ 응답A
                          요청B ──▶ [처리…] ──▶ 응답B   ← A 끝나야 B 시작 (HOL)

   HTTP/2 — 한 연결에서 여러 요청을 동시에 (멀티플렉싱)

   요청A ──▶ ┐
   요청B ──▶ ┼─ 한 연결에 섞어 흘려보냄 ─▶ 응답 A·B·C 도착하는 대로
   요청C ──▶ ┘

HTTP/2가 이 문제를 정면으로 풉니다. 핵심은 멀티플렉싱(multiplexing)이에요. 한 연결에서 여러 요청·응답을 동시에 흘려보내는 기술이죠. 더 이상 줄을 서지 않고, 요청 A·B·C를 한 연결에 섞어 보낸 뒤 준비되는 대로 받습니다. 여기에 헤더를 압축하고(같은 헤더를 매번 다 보내지 않음), 데이터를 사람이 읽는 텍스트 대신 효율적인 바이너리로 다뤄 속도를 끌어올렸어요. HTTP 레벨의 HOL 블로킹이 사라진 겁니다.

그런데 HTTP/2에도 숨은 한계가 있었어요. HTTP 위층에선 줄을 없앴지만, 그 아래 TCP에는 여전히 줄이 있었거든요. TCP는 데이터를 순서대로 보장하느라, 패킷 하나가 유실되면 그게 재전송될 때까지 그 뒤 모든 데이터를 멈춰 세웁니다. 멀티플렉싱으로 위에서 여러 요청을 섞어 보내도, 아래 TCP에서 패킷 하나가 빠지면 다 같이 막히는 거죠. HTTP 레벨 HOL은 풀었지만 TCP 레벨 HOL이 남은 셈이에요.

HTTP/3가 바로 이 마지막 줄을 끊으려고 등장했어요. 방법이 과감합니다. TCP를 아예 버리고 UDP 위로 옮겨갔어요. 지난 시간 흘려둔 그 이야기가 여기서 회수됩니다. "신뢰성 없는 UDP 위에 신뢰성을 다시 얹은" 프로토콜이 QUIC이고, 그 위에서 도는 HTTP가 HTTP/3예요. TCP가 모든 데이터를 한 줄로 묶어 순서를 보장했던 것과 달리, QUIC은 요청마다 줄을 따로 둬서 한 패킷이 빠져도 그 줄만 기다리고 나머지는 계속 흐르게 했습니다. TCP 레벨 HOL까지 없앤 거죠. 게다가 연결을 트는 인사와 TLS 핸드셰이크를 하나로 합쳐, 처음 연결도 더 빠릅니다(그래서 HTTP/3는 Step 7의 TLS 1.3을 의무로 요구해요).

그럼 왜 TCP를 고치지 않고 UDP로 갈아탔을까요? 지난 시간 트레이드오프가 답이에요. TCP는 수십 년간 운영체제와 전 세계 중간 장비에 단단히 박혀 이제 와 바꾸기가 거의 불가능합니다. 반면 UDP는 "그냥 던진다"는 최소한의 약속만 있어, 그 위에 신뢰성을 새로 설계할 자유가 있었죠. 굳어버린 TCP를 고치는 대신, 가벼운 UDP를 토대 삼아 새로 지은 겁니다.

2026년 현재 분포를 짚어둘게요. HTTP/2가 가장 많이 쓰이고(전체 웹 요청의 약 절반), HTTP/1.1이 그다음, HTTP/3는 약 5분의 1로 빠르게 늘었다가 최근 정체 중이에요. HTTP/3는 더 이상 "미래 기술"이 아니라 이미 큰 사이트들이 쓰는 주류 중 하나입니다. 다만 모든 서버와 중간 장비가 새 프로토콜을 지원해야 퍼지는 데다, TCP도 여전히 충분히 안정적이라 교체가 단번에 일어나진 않아요.

🎯 면접에서는 이렇게 답하세요

"HTTP/1.1은 keep-alive로 연결을 재사용했지만, 한 연결에서 요청이 줄을 서는 HOL 블로킹이 있었습니다. HTTP/2는 멀티플렉싱으로 한 연결에서 여러 요청을 동시에 처리해 HTTP 레벨 HOL을 풀었고 헤더 압축·바이너리도 더했죠. 다만 TCP 레벨 HOL은 남았어요. 패킷 하나가 빠지면 TCP가 전체를 멈추니까요. HTTP/3는 아예 TCP를 버리고 UDP 기반 QUIC 위로 옮겨, 스트림을 독립시켜 TCP HOL까지 없애고 핸드셰이크도 통합해 더 빨라졌습니다. TCP가 굳어 고치기 어려우니, 가벼운 UDP 위에 신뢰성을 새로 얹은 거예요. HTTP/3는 TLS 1.3을 의무로 요구하고요."

마무리

오늘 배운 핵심 세 가지

🎯 하나, HTTP는 웹에서 클라이언트와 서버가 주고받는 약속으로, 신뢰성이 필요해 보통 TCP 위에서 돌고 요청-응답이 한 쌍을 이룹니다. 가장 중요한 성격은 무상태예요. 서버가 이전 요청을 기억하지 않아 단순하고 확장이 쉽지만, 로그인 유지는 혼자 못 합니다. 요청·응답 메시지는 시작줄·헤더·빈 줄·바디 네 토막으로 이뤄지고, 시작줄의 메서드(GET·POST·PUT·PATCH·DELETE)가 의도를 밝혀요.

🎯 둘, 면접 단골 셋을 잡았습니다. GET vs POST는 조회(URL·안전·멱등) 대 생성(바디·상태 변경)이고, 멱등성은 같은 요청을 여러 번 보내도 결과가 같은 성질로 재시도 안전성을 가릅니다. 상태 코드는 백의 자리로 2xx(성공)·3xx(리다이렉션)·4xx(클라 잘못)·5xx(서버 잘못)로 나뉘고요. 그리고 무상태를 보완하는 쿠키 vs 세션은 저장 위치(클라이언트냐 서버냐)가 가르는 트레이드오프였어요.

🎯 셋, HTTPS는 HTTP를 TLS로 감싼 것으로, 인증서로 상대를 확인하고 비대칭키로 대칭키를 합의한 뒤 빠른 대칭키로 본 통신을 암호화하는 하이브리드 구조입니다. 그리고 HTTP는 1.1(keep-alive) → 2(멀티플렉싱) → 3(QUIC/UDP) 으로 진화하며 HOL 블로킹을 차례로 풀었어요. HTTP/3가 굳어버린 TCP 대신 가벼운 UDP 위에 신뢰성을 새로 얹었다는 게, 지난 시간 TCP vs UDP 트레이드오프의 결론이었습니다.

다음 시간 예고

오늘 우리는 웹 통신의 언어인 HTTP를 요청부터 응답, 암호화, 버전 진화까지 한 겹씩 벗겨봤어요. 그런데 아직 풀리지 않은 큰 그림이 하나 있습니다. 여러분이 주소창에 www.instagram.com을 치고 엔터를 누른 그 한순간, 실제로 무슨 일들이 순서대로 일어나서 화면에 사진이 뜨는 걸까요?

다음 시간(C-3)에는 이 과목 네트워크 파트의 종착지인 "URL을 치면 일어나는 일"을 한 호흡에 꿰어봅니다. 주소를 IP로 바꾸는 DNS부터, 지난 시간 배운 TCP 3-way handshake, 오늘 배운 TLS 핸드셰이크와 HTTP 요청·응답, 그리고 받은 데이터를 화면에 그리는 렌더링까지 — 지금껏 따로 배운 조각들이 하나의 여정으로 이어지는 순간이에요. 이건 기술 면접에서 가장 자주, 가장 깊게 묻는 질문이기도 합니다. 오늘 배운 HTTP가 그 여정의 핵심 한 조각이니, 단단히 챙겨두고 다음 시간에 만나요.

과제

[기초] 요청과 응답을 직접 읽어보기

연필과 종이, 혹은 브라우저만 있으면 됩니다. 오늘 배운 메시지 구조와 상태 코드를 손에 익혀봐요.

1. 아래 HTTP 요청을 보고 메서드 · 경로 · 어느 서버로 보내는지를 각각 찾아 적어보세요. 그리고 이 요청이 서버의 상태를 바꾸는지(안전한지), 여러 번 보내도 결과가 같은지(멱등한지)도 판단해 한 줄로 쓰세요.

   GET /posts/42 HTTP/1.1
   Host: api.example.com
   Accept: application/json
   

2. 다음 상태 코드 다섯 개를 무리(2xx~5xx) 로 나누고, 각각 한 줄로 무슨 뜻인지 적어보세요: 200 · 301 · 403 · 404 · 500. 그중 4xx와 5xx의 책임이 어떻게 다른지도 한 문장으로 정리하세요.
3. (선택) 브라우저에서 아무 사이트나 연 뒤 개발자 도구의 Network 탭을 열어, 실제 요청 하나의 상태 코드와 Content-Type 헤더가 무엇인지 확인해 적어보세요.

[응용] 시나리오마다 메서드와 멱등성 판단하기

아래 상황에서 어떤 메서드가 어울리는지 고르고, 그 요청이 멱등한지 아닌지와 그래서 네트워크 오류 시 재시도해도 되는지를 한 줄씩 설명해보세요.

1. ① 게시글 하나를 조회 ② 새 댓글을 작성 ③ 프로필의 이름만 수정 ④ 게시글을 삭제. 각각 GET/POST/PATCH/DELETE 중 무엇이 맞는지 고르고, 멱등성을 판단하세요.
2. ②번 "새 댓글 작성"에서, 사용자가 제출 버튼을 눌렀는데 응답이 안 와서 한 번 더 눌렀습니다. 이게 왜 문제가 되는지 멱등성 개념으로 설명하고, 어떻게 하면 중복을 막을 수 있을지 한 가지 아이디어를 떠올려보세요.
3. ④번 "게시글 삭제"는 한 번 지운 글을 또 지우려 하면 어떻게 될까요? 결과(서버 상태) 관점에서 DELETE가 왜 멱등으로 분류되는지 설명해보세요.

[심화] "HTTPS는 어떻게 동작하나요" 면접 답변 만들기

조사하고 정리하는 과제입니다. 오늘 배운 Step 6·7을 엮어 면접 답변을 직접 써봅니다.

1. "HTTPS는 어떻게 동작하나요?"에 대한 자기만의 답변을, ① 인증서로 상대 확인 → ② 비대칭키로 대칭키 합의 → ③ 대칭키로 본 통신 암호화 세 단계로 정리해 적어보세요.
2. 이어질 꼬리 질문에 대비해보세요. "왜 비대칭키만 계속 쓰지 않고 대칭키로 바꾸나요?"에 대한 답을 속도 트레이드오프로 두세 문장 준비하세요. 그리고 "주소창에 자물쇠가 있으면 안전한 사이트인가요?"에 대한 답도, 암호화와 신뢰의 차이로 준비하세요.
3. (선택) "HTTP/2와 HTTP/3의 차이가 뭔가요?"에 대한 답을, 멀티플렉싱과 TCP→UDP(QUIC) 를 축으로 정리해보세요. 지난 시간 배운 TCP vs UDP 트레이드오프를 끌어오면 좋습니다.

생각해볼 주제

1. 무상태는 불편한데 왜 HTTP는 굳이 무상태를 고수할까?

무상태인 HTTP는 로그인 하나 유지하려고 쿠키·세션이라는 장치를 따로 얹어야 합니다. 번거롭죠. 차라리 서버가 "이 사람은 아까 로그인한 재훈이"라고 처음부터 기억하면(상태를 가지면) 더 간단할 것 같기도 해요. 그런데 거의 모든 웹이 무상태를 기본으로 삼습니다. 서버가 모든 사용자의 상태를 일일이 기억할 때 생기는 부담과, 서버를 여러 대로 늘릴 때 무상태가 주는 자유로움을 떠올려보세요. "기억하지 않음"이 어떻게 오히려 확장의 힘이 되는지, 그리고 그 대가로 무엇을 치르는지 저울에 올려보세요.

2. HTTPS 자물쇠가 떠 있으면 정말 안전한 걸까?

자물쇠는 통신이 암호화됐고 상대가 인증서상의 그 도메인이 맞다는 걸 보장합니다. 하지만 그 도메인의 주인이 선한 사람인지는 보장하지 않아요. 그래서 가짜 도메인을 단 피싱 사이트도 버젓이 자물쇠를 달 수 있습니다. "암호화됐다"는 것과 "믿을 만하다"는 것은 어떻게 다를까요? 기술이 보장해주는 것과 보장하지 못하는 것의 경계를 생각해보세요. 그리고 사용자가 자물쇠를 "이 사이트는 안전하다"로 오해할 때 생기는 위험을, 기술과 사람의 인식 사이의 틈으로 풀어보세요.

3. 더 빠른 HTTP/3는 왜 단번에 HTTP/2를 밀어내지 못할까?

HTTP/3는 HOL 블로킹을 더 깊이 풀고 연결도 빠른, 분명히 더 진보한 기술입니다. 그런데 2026년 현재도 HTTP/2가 더 많이 쓰이고, HTTP/3의 확산은 최근 정체돼 있어요. 더 좋은 기술이 곧장 표준이 되지 못하는 이유가 뭘까요? 양쪽 모두가 지원해야 통신이 성립한다는 점, 일부 환경이 UDP를 막는다는 점, 그리고 기존 기술도 충분히 쓸 만하다는 점을 떠올려보세요. 기술의 우수함과 그것이 실제로 퍼지는 속도가 왜 다른지, 표준이 바뀌는 일에 드는 보이지 않는 비용을 생각해보세요.