들어가며
언제부턴가 우리는 많은 일을 웹에서 처리하고 있습니다.
은행 업무, 쇼핑, 메신저, 심지어 병원 진료까지.
근데 말이에요,
이런 생각 해보신 적 있으신가요?
“내가 입력한 정보, 혹시 누가 훔쳐보면 어쩌지?”
실제로 인터넷 초창기에는 그런 일이 정말로 있었습니다.
예를 들어, 누군가가 같은 와이파이에 접속해 있다면,
당신이 어떤 웹사이트에 로그인했는지, 어떤 내용을 입력했는지 들여다보는 게 가능했어요.
물론, 지금은 그렇지 않죠. 다행히도요.
하지만 이게 가능했던 이유는 단순합니다.
우리가 흔히 접하는 HTTP(HyperText Transfer Protocol)라는 통신 방식이
“보안을 고려하지 않고” 설계되었기 때문입니다.
쉽게 말해, 정보를 암호화하지 않고 그냥 주고받았던 거죠.
그냥 엽서에 글 써서 우체통에 넣는 느낌? 누구든 중간에서 슬쩍 보면 끝입니다.
그리고 어느 순간, 사람들이 이렇게 묻기 시작했어요.
“왜 아무 보호도 없이 이렇게 중요한 걸 주고받고 있는 거지?”
그 질문에 대한 해답으로 나온 것이 바로 HTTPS입니다.
‘보안이 추가된 HTTP’, 정확히는 암호화가 적용된 통신 방식이죠.
지금부터 이야기할 HTTP와 HTTPS는 단순한 기술 용어 그 이상입니다.
우리가 매일 사용하는 인터넷을 ‘믿을 수 있게’ 만든 근간이니까요.
HTTP란?
HTTP는 HyperText Transfer Protocol, 말 그대로 “하이퍼텍스트를 전송하기 위한 약속(프로토콜)"입니다.
인터넷에서 우리가 웹사이트를 이용할 때,
브라우저는 클라이언트, 웹사이트는 서버라고 부릅니다.
이 둘 사이에서 정보를 주고받아야 하겠죠?
그때 서로가 약속한 방식대로 대화를 나누는데,
그 대화 방식의 규칙이 바로 HTTP입니다.
즉, HTTP는 웹 브라우저와 웹 서버가 '어떻게 말할지' 정한 대화법이에요.
언제부터 쓰였을까?
HTTP는 1989년, 팀 버너스 리(Tim Berners-Lee)라는 물리학자가 만들었습니다.
당시 그는 전 세계 과학자들이 연구 자료를 쉽게 공유할 수 있는 시스템을 만들고 싶어 했고,
그렇게 해서 등장한 게 바로 WWW (월드 와이드 웹), 그리고 그 핵심 기술인 HTTP였죠.
처음엔 단순한 텍스트 전송이 전부였지만,
점점 이미지, 동영상, 로그인 정보 같은 복잡한 데이터까지 처리하게 되면서
웹은 지금처럼 거대한 플랫폼으로 성장했습니다.
어떻게 작동할까?
HTTP는 클라이언트(보통은 여러분의 웹 브라우저)가 서버에 요청(request)을 보내고,
서버는 거기에 맞는 응답(response)을 보내주는 구조입니다.
이 방식은 서버-클라이언트 모델이라고 불러요.
예를 들어볼까요?
누군가 네이버를 검색하려고 주소창에 **www.naver.com**을 입력하면
브라우저는 그 요청을 네이버 서버에 보내고,
서버는 홈페이지 내용을 담은 응답을 돌려주는 식이죠.
기본적으로 HTTP는 80번 포트를 통해 통신합니다.
브라우저는 이 포트를 통해 서버에게 요청을 보내고,
서버는 같은 포트에서 그 요청을 기다리고 있어요.
프로토콜이란?
프로토콜은 간단히 말하면 ‘약속된 규칙’이에요.
컴퓨터나 기기들이 서로 정확히 소통하려면
"어떤 형식으로 말할지"를 정해야 하잖아요?
그걸 정해놓은 게 프로토콜입니다.
우리가 누군가와 문자를 주고받을 때
문장 맨 끝에 마침표를 찍는다거나,
‘안녕하세요’라는 인사말로 시작하는 것도 일종의 프로토콜이에요.
HTTP의 구조
HTTP는 웹 애플리케이션에서 사용되는 애플리케이션 계층 프로토콜입니다.
그 아래에는 TCP/IP라는 더 기본적인 통신 방식이 깔려 있고요.
HTTP 요청이나 응답은 보통 다음과 같은 구조를 가집니다:
- Method (예: GET, POST 등)
- Path (어떤 경로의 정보를 요청하는지)
- Version (HTTP/1.1, HTTP/2 등)
- Headers (추가 정보들)
- Body (요청/응답의 실제 내용)
이 구조는 표준화돼 있어서,
브라우저와 서버가 서로 정확하게 해석하고 처리할 수 있도록 도와줍니다.
HTTP의 단점
HTTP는 기본적으로 모든 데이터를 '평문(plain text)'으로 주고받습니다.
즉, 중간에 누군가가 통신을 엿본다면?
비밀번호, 주민번호, 카드번호… 그대로 보일 수 있어요.
실제로 예전에는 공공 와이파이에서 로그인했다가 계정이 털리거나,
민감한 정보가 중간에서 탈취되는 사고도 꽤 많았어요.
그래서 등장한 게 바로 HTTPS입니다.
이건 HTTP에 ‘암호화(Encryption)’ 기능을 추가한 보안 버전이에요.
HTTPS란?
HTTPS는 HyperText Transfer Protocol Secure의 약자로, HTTP에 보안을 더한 버전입니다.
그 핵심은 바로 암호화에 있어요.
이 암호화를 담당하는 기술이 바로
SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security)입니다.
처음에는 SSL이 주로 사용되었지만,
지금은 보안이 강화된 TLS가 표준으로 자리잡았습니다.
다만 여전히 업계에서는 ‘SSL 인증서’라는 표현을 관성적으로 쓰고 있어요.
실제로는 대부분 TLS 기반 인증서라고 보시면 됩니다.
왜 HTTPS가 필요할까?
앞서 이야기한 HTTP는 데이터를 ‘그냥 평문’으로 주고받는 방식이었어요.
즉, 누가 중간에서 들여다보면 그대로 볼 수 있었습니다.
비밀번호, 신용카드 번호, 주민등록번호까지…
그래서 등장한 게 바로 HTTPS입니다.
HyperText Transfer Protocol Secure, 말 그대로
"보안이 강화된 HTTP"입니다.
기존 HTTP 위에 암호화 기술을 덧붙여,
누가 중간에서 몰래 엿본다고 해도 알아볼 수 없도록 만든 거예요.
HTTPS는 HTTP와 달리 443번 포트를 사용하고,
데이터가 오가는 모든 과정에서 암호화를 적용합니다.
HTTPS는 어떻게 정보를 보호할까?
HTTPS는 두 가지 암호화 방식을 모두 사용합니다.
빠른 처리 속도와 강력한 보안성을 동시에 얻기 위해서죠.
대칭키 암호화
- 클라이언트와 서버가 같은 키를 사용해서 암호화/복호화
- 빠르지만, 키가 노출되면 보안이 깨짐
→ 실제 데이터 전송엔 이걸 사용함
비대칭키 암호화
- 공개키와 개인키 한 쌍을 사용
- 공개키로 암호화하면, 개인키로만 복호화 가능 (그 반대도 가능)
- 느리지만 안전함
→ 키를 안전하게 전달할 때 사용함
공개키/개인키, 어떻게 다를까?
- 공개키(Public Key): 누구에게나 공개 가능한 키
- 개인키(Private Key): 오직 서버만 알고 있는 비밀 키
✔️ 공개키로 암호화 → 개인키로만 복호화 가능
✔️ 개인키로 암호화 → 공개키로만 복호화 가능 (즉, ‘내가 보냈다’는 걸 증명할 수 있음)
이걸 활용하면 다음과 같은 일이 가능해져요:
- 누가 보내는지를 증명할 수 있고
- 누가 볼 수 있는지도 제한할 수 있죠
HTTPS는 어떻게 동작할까? (핸드셰이크 과정)
HTTPS 연결은 처음부터 데이터를 막 주고받지 않아요.
“우리, 안전하게 대화하자”라는 합의부터 시작합니다.
이걸 핸드셰이크(Handshake) 과정이라고 해요.
흐름을 간단히 정리하면 다음과 같습니다:
- 브라우저가 서버에 “연결하자”고 요청함
- 서버는 공개키가 포함된 인증서를 브라우저에게 전달
- 브라우저는 이 인증서를 검사함 (진짜 맞는 서버야?)
- 문제가 없으면 세션키(대칭키)를 생성하고,
- 서버의 공개키로 암호화해서 다시 서버에게 보냄
- 서버는 자신의 개인키로 복호화하여 같은 세션키를 얻음
- 이제부터는 같은 세션키로 암호화된 데이터만 주고받음
📌 즉, 처음엔 비대칭키로 세션키를 안전하게 전달하고,
이후 본격적인 데이터 교환은 빠른 대칭키로 처리하는 거예요.
인증서는 어떻게 발급받을까?
그렇다면 이 공개키가 들어있는 인증서는 어디서 왔을까요?
바로, 신뢰할 수 있는 인증기관(CA, Certificate Authority)이 발급해줍니다.
인증서 발급 과정은 이렇게 진행돼요:
- 서버(A 기업)는 공개키/개인키 쌍을 생성
- 인증기관(CA)에 돈을 주고 인증서 발급을 요청
- CA는 A기업의 정보와 공개키를 확인하고,
- 자신(CA)의 개인키로 암호화한 인증서를 생성해 전달
- A 기업은 이 인증서를 서버에 설치
- 브라우저는 이 인증서를 확인하고,
- 미리 내장된 CA의 공개키로 복호화해 신뢰성을 검증
인증서에 A 기업의 공개키가 담겨있기 때문에,
그걸 이용해 안전하게 세션키를 주고받을 수 있는 거죠.
HTTP와 HTTPS
HTTP는 암호화가 적용되지 않은 프로토콜이기 때문에,
누군가 중간에서 정보를 가로채면 내용이 그대로 노출될 수 있습니다.
반면 HTTPS는 암호화 기능이 추가된 버전이라,
데이터를 안전하게 주고받을 수 있다는 큰 장점이 있어요.
특히 로그인 정보나 결제 정보처럼 민감한 데이터를 다룰 땐 필수죠.
하지만 단점이 아예 없는 건 아닙니다.
- HTTPS는 암호화/복호화 과정이 있기 때문에
- HTTP보다 약간 느릴 수 있어요.
- 또 하나는 비용입니다.서버 운영 측면에서 약간의 비용과 관리 부담이 추가될 수 있습니다.
- HTTPS를 사용하려면 인증서를 발급받고 관리해야 하기 때문에
그럼 언제 HTTP를 쓰고, 언제 HTTPS를 써야 할까요?
- 개인정보, 로그인, 결제 등 민감한 데이터를 다룬다면
→ 무조건 HTTPS를 써야 합니다. - 단순히 공개된 정보(예: 뉴스 기사, 이미지 등)를 조회하는 수준이라면
→ HTTP를 사용할 수도 있어요.
하지만 요즘은 대부분의 웹사이트가 전체를 HTTPS로 운영하고 있고,
구글도 HTTPS 사용 여부를 검색 순위에 반영하기 때문에
가능한 한 HTTPS를 기본값으로 생각하는 게 좋습니다.