구글과 네이버는 왜 비밀번호를 평문으로 보낼까? (개발자 도구의 착시와 HTTPS의 진실)
The Problem: '개발자 도구'가 심어준 평문 전송의 공포와 오버엔지니어링
로그인 기능을 구현하던 중, 무심코 개발자 도구의 Network 탭의 Payload를 확인했습니다. 제가 입력한 비밀번호 mySecretPassword12!가 Body에 아주 날것의 평문으로 찍혀서 서버로 넘어가고 있었습니다.
"아니, 이렇게 다 보이면 중간에 해커가 패킷을 가로채서 다 털어가는 거 아니야?"
불안해진 저는 클라이언트(React) 단에서 AES나 RSA 알고리즘으로 비밀번호를 1차 암호화한 뒤, 백엔드에서 이를 복호화하여 다시 단방향 해시 처리를 하는 거창한 아키텍처를 구상했습니다. 그러다 문득 궁금해져서 구글, 네이버, AWS의 로그인 페이지를 열어 Network 탭을 까보았습니다. 결과는 충격적이었습니다. 세계 최고의 보안을 자랑하는 이 거인들조차 비밀번호를 평문 그대로 Request Body에 담아 보내고 있었기 때문입니다. 대체 왜 이런 걸까요?
The Solution: HTTPS의 진짜 역할과 개발자 도구의 '착시'
이 혼란의 원인은 '개발자 도구의 위치' 와 'HTTPS의 동작 구간' 을 정확히 구분하지 못한 데 있었습니다.
1. 개발자 도구는 '암호화되기 직전의 투명 유리창'이다 우리가 보는 크롬 개발자 도구는 네트워크 선을 타고 나가는 실제 패킷을 보여주는 것이 아닙니다. 브라우저라는 애플리케이션 '내부'에서, 자바스크립트가 생성한 데이터가 네트워크 모듈(TLS/SSL)로 넘어가기 직전의 순수한 상태 를 보여주는 것입니다. 비유하자면, 편지를 금고에 넣고 자물쇠를 채우기 전에 내 눈으로 편지를 읽고 있는 상태 일 뿐입니다. 내 눈에 보인다고 해서 도둑의 눈에도 보이는 것은 아닙니다.
2. HTTPS의 강력한 전송 구간 암호화
프론트엔드에서 출발한 평문 데이터(Header, Body, Cookie, URL Path 등)는 브라우저를 벗어나 실제 랜선(Network)이나 와이파이 전파를 타기 직전, HTTPS(TLS/SSL) 계층을 거치며 통째로 철저하게 암호화 됩니다.
따라서 카페의 공용 와이파이에서 해커가 패킷 스니핑 툴로 제 통신을 훔쳐보더라도, 그들이 볼 수 있는 것은 *&#$@!^... 같은 해독 불가능한 쓰레기 값뿐입니다. 네이버와 구글이 평문을 안심하고 쏘는 이유는 바로 이 강력한 표준 프로토콜을 믿기 때문입니다.
3. 프론트엔드 암호화의 모순 (무의미한 삽질) 만약 프론트엔드에서 비밀번호를 암호화해서 보낸다면 어떨까요?
- 네트워크 해킹 방어 관점: 어차피 HTTPS가 전체를 다 암호화해주므로 중복 작업이며 의미가 없습니다.
- 브라우저 해킹 방어 관점: 만약 해커가 악성 스크립트(XSS)를 심어 브라우저를 장악했다면, 애초에 유저가 키보드로 평문을 입력하는 순간(Keylogging)이나, 프론트엔드 코드 내에 있는 암호화 로직/키를 통째로 털어갈 수 있습니다. 즉, 클라이언트(공공장소)에서의 암호화는 보안의 근본적인 해결책이 되지 못합니다.
The Result & Retrospective
이 깨달음을 얻은 후, 저는 클라이언트 단의 무의미한 암호화 로직을 미련 없이 전부 폐기했습니다.
보안은 내가 직접 복잡하게 꼬아놓는다고 안전해지는 것이 아니라, 웹의 표준 프로토콜을 정확히 이해하고 올바른 위치에 책임을 위임할 때 비로소 견고해짐을 배웠습니다.
이후 저의 보안 아키텍처 철학은 명확해졌습니다.
- 전송 구간 (Transport): 어설픈 클라이언트 암호화 대신 HTTPS 를 100% 신뢰한다.
- 저장 구간 (Storage): 서버에 도달한 평문 비밀번호는 즉시 Bcrypt/Argon2 등 강력한 단방향 해시 함수로 암호화하여 DB에 저장한다.
- 클라이언트 방어 (Client): XSS 공격 방어(HttpOnly 쿠키 사용, React의 자동 HTML Escaping 신뢰)와 CSRF 방어에 집중한다.
"눈에 보인다고 해서 위험한 것이 아니고, 눈에 안 보인다고 해서 안전한 것이 아니다." 이번 트러블슈팅은 네트워크 OSI 계층과 브라우저의 역할을 입체적으로 이해하게 해주었습니다.