TL;DR

HTTP는 암호화되지 않은 전송 프로토콜이고, HTTPS는 TLS 기반 암호화·무결성·인증을 제공하는 안전한 프로토콜이다. 오늘날 모든 서비스는 HTTPS가 기본이며, HTTP는 제한적 내부망·테스트 환경에서만 사용해야 한다.

1. Executive Summary

인터넷 기반 서비스가 폭발적으로 증가함에 따라 보안은 단순한 선택이 아니라 필수가 되었다. HTTP는 웹 통신의 초석이었지만 암호화가 없어 현대의 위협 환경에서는 취약하다. HTTPS는 HTTP 위에 TLS(Transport Layer Security)를 결합하여 기밀성(Confidentiality), 무결성(Integrity), **인증(Authentication)**을 보장한다. 조직 관점에서는 HTTPS 도입이 브랜드 신뢰성, 규제 준수, 고객 데이터 보호의 핵심이다.

2. Technical Overview

2.1 HTTP (HyperText Transfer Protocol)

계층: Application Layer
포트: 80
특징: 평문(plaintext) 통신, 암호화 없음
장점: 단순, 프로토콜 오버헤드 적음
단점: 도청, 변조, 세션 하이재킹 공격에 취약

2.2 HTTPS (HTTP Secure)

계층: Application Layer + TLS Layer
포트: 443
구성: HTTP + TLS(SSL의 진화 표준)
보안 기능:
- TLS Handshake 기반 서버 인증
- 암호화를 통한 기밀성 보장
- MAC 기반 무결성 보장

3. Security Architecture: HTTP vs HTTPS

3.1 암호화(Encryption)

HTTP: 데이터가 평문으로 전송 → 네트워크 스니핑으로 쉽게 노출됨.
HTTPS: AES/GCM 등 대칭키 암호화로 보호. 키 교환은 ECDHE 같은 비대칭 암호 기반.

3.2 무결성(Integrity)

HTTP: 패킷 변조를 탐지할 방법이 없음.
HTTPS: TLS record layer의 MAC/AEAD로 변조 탐지.

3.3 인증(Authentication)

HTTP: 서버의 진짜 여부를 검증할 수 없음.
HTTPS: CA(Certificate Authority)의 인증서 체인을 통해 서버 신원 보장.

4. TLS Handshake Deep Dive

Client Hello (지원 암호 스위트)
Server Hello + Certificate 전달
키 교환(ECDHE)
세션키 생성
TLS Record Layer로 암호화된 데이터 송수신

결과: 이후 모든 HTTP 메시지는 TLS로 암호화된 상태에서 전달됨.

5. Performance Considerations

5.1 TLS 오버헤드 (예전 문제)

초기 handshake 비용은 HTTP/2 + TLS 1.3으로 극적으로 감소
대규모 서비스에서도 오버헤드는 일반적으로 전체 비용의 1~3% 수준

5.2 HTTP/2 & HTTP/3 시너지

HTTPS 환경에서만 HTTP/2/3 사용 가능:

멀티플렉싱
헤더 압축(HPACK/QPACK)
HOL(Head-of-line) blocking 해소

결론: 현대 웹 성능은 HTTP보다 HTTPS가 더 빠른 경우가 많다.

6. Operational Differences

6.1 인증서 관리 필요 (HTTPS)

유형: DV, OV, EV 인증서
발급: Let’s Encrypt, DigiCert, GlobalSign
로테이션 자동화: Certbot, AWS ACM, GCP Managed Certificates

6.2 로드밸런서/프록시 구성

HTTPS는 TLS termination 필요
내부 트래픽은 TLS offloading 여부 선택 가능

7. Threat Model Comparison

공격 유형	HTTP	HTTPS
패킷 스니핑	매우 취약	사실상 불가능
MITM 공격	매우 취약	인증서 검증으로 방어
패킷 변조	탐지 불가	AEAD로 탐지 및 차단
세션 하이재킹	매우 취약	세션 쿠키 TLS 보호로 완화

8. SEO, 브랜드·비즈니스 영향

Google은 HTTPS를 검색 랭킹 신호로 사용
Chrome은 HTTP 사이트에 대해 “Not Secure” 표기
고객 데이터 보호 규제(GDPR, CCPA)에 HTTPS 필요

9. When to Use What?

HTTP를 사용할 수 있는 경우 (아주 제한적)

로컬 개발
보안 필요 없는 임시 테스트 서버
사설 망 내부에서 이미 mTLS가 별도로 깔린 환경

HTTPS가 필수인 경우

모든 공개 서비스
사용자 인증/개인정보 처리
결제/금융/실시간 제어 시스템
API Gateway / 모바일 앱 백엔드

현대 표준: “HTTP는 개발용, HTTPS는 운영용”.

10. Migration Playbook: HTTP → HTTPS

리소스 전체 경로 점검(이미지, JS, API mixed content 제거)
인증서 발급 및 자동화
로드밸런서/Ingress에서 TLS termination 적용
모든 HTTP 요청을 301 HTTPS로 리다이렉트
HSTS 적용(Strict-Transport-Security)
모니터링(에러율, TLS handshake 시간, 인증서 만료)

11. Decision Checklist

사용자 데이터가 오가는가? → HTTPS
인증/세션이 필요한가? → HTTPS
대중에게 공개되는 서비스인가? → HTTPS
운영 팀이 인증서 자동화할 수 있는가? → Yes → HTTPS

12. Final Recommendation

오늘날의 인터넷 서비스는 HTTPS가 단일 표준이다. 성능에서도 유리하며 보안·규제·신뢰·비즈니스 관점에서 HTTP를 선택할 이유는 거의 없다. HTTP는 개발용 혹은 폐쇄망에서만 제한적으로 사용해야 한다.

필요하다면 다음을 추가해드릴 수 있어요:

1페이지 Executive Summary 버전(PDF)
HTTP ↔ HTTPS 실제 트래픽 흐름 다이어그램
TLS 1.3만 따로 깊게 파는 기술 부록
EX 서비스 구조 기준으로 HTTP/HTTPS 권장 아키텍처 지도

HTTP vs HTTPS