Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
Tags
- 데이터베이스
- 보안
- devops
- 웹개발
- http
- SnowFalke
- 네트워크
- JPA
- 백엔드개발
- 인증
- 클린코드
- AbstractAggregateRoot
- db
- Spring
- Spring Boot
- 프론트엔드
- java
- 캐시
- redis
- 백엔드개발자
- 백엔드
- 백엔드기초
- 세션
- spring event
- DEVIEW2023
- CS
- 성능최적화
- interceptor
- 웹성능최적화
- 인프라
Archives
- Today
- Total
이것저것 개발기록
HTTP vs HTTPS 차이와 SSL/TLS 동작 원리 본문
"로그인 기능을 만들었는데, 왜 브라우저에서 '주의 요함'이 뜰까요?"
이제 HTTPS는 선택이 아닌 필수입니다. 단순히 보안 때문일까요? 그 속에서 일어나는 마법 같은 과정을 알아봅시다.
1. HTTP와 HTTPS의 결정적인 차이점
가장 큰 차이는 역시 '보안(Security)'입니다. HTTP는 데이터를 평문으로 전송하지만, HTTPS는 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 데이터를 암호화합니다.
| 비교 항목 | HTTP | HTTPS |
|---|---|---|
| 포트 번호 | 80 | 443 |
| 암호화 여부 | X (평문) | O (SSL/TLS) |
| 검색 엔진 최적화(SEO) | 불리함 | 우선순위 높음 |
2. 어떻게 암호화하나요? (SSL Handshake)
단순히 암호를 거는 게 아니라, 클라이언트와 서버가 "어떤 비밀키로 대화할지" 합의하는 과정이 필요합니다. 이를 Handshake라고 부릅니다.
- Client Hello: 클라이언트가 서버에게 가용 암호화 방식을 보냅니다.
- Server Hello: 서버가 암호화 방식을 선택하고 인증서를 전달합니다.
- Key Exchange: 대칭키를 암호화하여 주고받으며 서로를 확인합니다.
결국 HTTPS는 대칭키 암호화의 속도와 비대칭키 암호화의 안전함을 섞어 만든 영리한 프로토콜입니다.
그래서!?
저도 주니어 시절에는 "로컬에서 잘 되는데 왜 굳이 복잡하게 인증서를 붙여야 하지?"라고 생각했어요. 하지만 실무에서 고객의 개인정보가 탈취되는 사고를 한 번이라도 본다면 생각이 달라질 겁니다.
꿀팁 하나! 요즘은 Let's Encrypt 같은 무료 CA를 통해 누구나 쉽게 HTTPS를 적용할 수 있어요. 배포 단계에서 무조건 적용하는 습관을 들여보세요. 인프라를 이해하는 개발자로 보이는 가장 쉬운 지름길입니다.
"기능 구현도 중요하지만, 사용자의 데이터를 안전하게 지키는 것이 백엔드 개발자의 진짜 자존심입니다."
'IT 이야기' 카테고리의 다른 글
| REST API 제대로 설계하기 (멱등성 완벽 이해) (0) | 2025.12.27 |
|---|---|
| "왜 내 DB는 느릴까?" 인덱스(Index)의 기본 원리 (0) | 2025.12.27 |
| 코딩은 AI가 더 잘합니다, 이제 '기초' 없는 개발자는 살아남을 수 없는 이유 (0) | 2025.12.27 |
| 서버 없이 구현하는 AI 트레이딩, MCP 아키텍처가 바꾸는 개발 패러다임 (1) | 2025.12.27 |
| 만들면서 배우는 클린 아키텍처 - 헥사고날 아키텍처 (0) | 2023.09.19 |