2026년 10월, Chrome 154가 “Always Use Secure Connections”를 기본으로 켠다. 평문 http:// 공개 사이트로 이동하면 브라우저가 로드하기 전에 멈추고 경고한다 — 지금 잘못된 인증서에 대해 하는 것과 똑같이. Google이 2025년 10월에 발표했고, 단계적으로 푼다: Enhanced Safe Browsing 사용자는 4월에, 나머지 전부는 여섯 달 뒤에.
그게 결승선이다. 은유가 아니라 — 날짜가 박힌, 실제로 출시되는 이벤트다. 평문 HTTP가 웹이 하는 정상적인 일이길 멈추고, 브라우저가 당신을 가로막고 물어보는 일이 되는 날.
분명히 해두자, 이건 좋은 일이다. 웹 전체를 암호화한 게 실수였다고 주장할 생각은 없다. 인터넷 역사에서 진짜로 완결된 몇 안 되는 보안 프로젝트 중 하나고, 여기에 15년을 쏟은 사람들 — EFF, Let’s Encrypt, 브라우저 보안 팀 — 은 그 승리를 받을 자격이 있다. EFF는 2010년에 HTTPS Everywhere 확장을 내놓기 시작했다. 사이트를 TLS에 올리는 게 CA에 돈을 내고 OpenSSL과 씨름하는 일이던 시절이다. 그들은 2022년에 그 확장을 조용히 접으면서 모두에게 그냥 브라우저 내장 HTTPS-only 모드를 쓰라고 했다. 브라우저가 마침내 그 확장을 불필요하게 만들었으니까. 승리는 그렇게 생겼다: 도구가 쓸모없어진다.
그래서 우리는 이겼다. 그런데 계속 마음에 걸리는 게 있다: 우리는 이길 수 있는 전쟁을 이긴 것이다.
풀 수 있는 문제
전송 암호화는, 돌이켜보면 풀 수 있는 문제였다. 앞으로 풀 무언가에서 바라는 모든 성질을 갖췄다.
검증 가능했다 — 연결이 암호화됐다는 걸 양쪽 끝에서 기계적으로 증명할 수 있다. 자동화 가능했다 — Let’s Encrypt가 2015년에 나와 인증서 발급을 구매 주문에서 90초짜리 스크립트로 바꿨고, 그게 채택률이 수직으로 오른 유일한 이유다. 깔끔한 성공 지표가 있었다 — HTTPS로 로드된 페이지 비율, Google이 투명성 보고서에 수년째 공개해온 그 숫자는 2015년 약 40%에서 2020년 95% 너머까지 올랐다. 그리고 강제 장치가 있었다: HTTP/2와 HTTP/3가 존재하는데, 어느 브라우저도 둘 중 하나를 평문으로 구현하지 않는다. 더 빠른 프로토콜을 원하면 암호화를 함께 가져가야 했다. 빠져나갈 구멍이 없었다.
공학 문제에 공학적 답, 올라가는 숫자, 그리고 결국 브라우저가 대신 정해준 마감. 그건 풀리는 문제다. 우리는 풀었다.
문제는 우리가 그 숫자를 너무 오래 가리켜온 나머지, 그걸 스코어보드 전체로 착각하기 쉬워졌다는 것이다.
자물쇠가 사준 적 없는 것
HTTPS는 딱 하나를 보장한다: 당신과 서버 사이의 누구도 바이트를 읽거나 변조할 수 없다는 것. 그건 반대편에 누가 있는지나 그를 믿어도 되는지에 대한 진술이었던 적이 없다. 여기에 매달린 사람은 다 그걸 알았다. 그 단서 — 암호화됐다는 게 안전하다는 것과 같지 않다 — 는 늘 각주에 적혀 있었다.
이제 모두가 HTTPS를 갖게 되니, 그 각주가 문서 전체다. 피싱 사이트의 압도적 다수가 유효한 인증서를 다는 마당에 — 실제로 그렇다, 인증서가 무료고 자동이니까, 정당한 사이트가 그걸 갖는 것과 똑같은 이유로 — 암호화의 존재는 의도에 대해 아무것도 말해주지 않는다. HTTPS는 신호에서 바닥으로 내려갔다. 바닥은 있을 만하다. 하지만 건물에 바닥이 있다고 축하하지는 않는다.
그리고 암호화된 파이프 아래, 반대편을 믿어도 되는지를 실제로 결정하는 부분들은 전부 2015년에 망가져 있던 그 방식 그대로 여전히 망가져 있다.
신뢰 모델 자체부터 보자. 당신 브라우저는 대략 150개 인증 기관을 신뢰하고, 그중 누구든 지구상 어느 도메인에 대해서든 유효한 인증서를 발급할 수 있다. 연결을 암호화하는 것은, 당신이 누구와 이야기하는지에 대한 보장이 150개 조직 집합에서 가장 못 믿을 구성원에게 걸려 있다는 사실에 대해 아무것도 하지 않는다. Certificate Transparency — 발급된 모든 인증서의 공개·추가 전용 로그, Chrome이 2018년부터 새로 발급되는 모든 인증서에 요구해온 — 는 신뢰 모델을 고칠 수 없어서 지켜보기라도 하려고 덧댄 패치다. 예방이 아니라 탐지다. 우리는 실패 양식을 불가능하게 만드는 대신 감사 가능하게 만들고는, 그걸로 하루를 마쳤다.
다음은 폐기(revocation), 아무도 똑바로 보고 싶어 하지 않는 문제다. 인증서는 만료될 때까지 유효한 주장이다 — 키가 도난당하지 않는 한. 그럴 땐 인증서를 일찍 죽여야 한다. 그걸 하는 두 메커니즘 OCSP와 CRL은 십 년째 조용히 실패해왔다. 브라우저는 OCSP 검사를 soft-fail한다(검사가 타임아웃되면 어깨를 으쓱하고 계속 간다. hard-fail하면 OCSP 응답기가 딸꾹질할 때마다 웹이 멈추니까). 즉 작정한 공격자는 그냥 검사를 막으면 된다. Let’s Encrypt는 OCSP 지원을 아예 끝내고 브라우저가 집계하는 CRL로 물러선다고 발표했다. 15년의 암호화 진보, 그런데 “이 인증서가 나빠졌으니 그만 믿어라”에 대한 답은 여전히 “그럭저럭, 언젠가, 브라우저가 업데이트를 받았다면”이다. 암호화는 키가 좋다고 가정한다. 키가 나쁠 때 무슨 일이 벌어지는지에 대해서는 할 말이 없다.
그리고 내가 가장 조용히 뼈아프다고 느끼는 것: HTTPS는 당신이 무엇을 보내는지를 암호화하지, 어디로 가는지를 암호화하지 않는다. Server Name Indication 필드 — 서버가 어느 인증서를 제시할지 알도록 브라우저가 TLS 핸드셰이크 맨 앞에서 알리는 호스트명 — 는 평문으로 나간다. 회선을 지켜보는 누구든 암호화된 세션이든 아니든 당신이 정확히 어느 사이트에 연결하는지 본다. 그 수정판인 Encrypted Client Hello는 존재하고 실재하지만 배포는 얇다 — 소수의 큰 제공자와 부분적인 브라우저 지원. 게다가 당신 DNS 조회는 몇 밀리초 앞서 같은 호스트명을 이미 흘렸다. 우리는 15년을 들여 아무도 당신 트래픽을 못 읽게 만들고는, 봉투 겉면에 주소를 남겨뒀다.
끝난 미션의 위험
이 중 어느 것도 HTTPS의 잘못이 아니다. 암호화는 제 일을 했다. 문제는 완결된 미션이 주의력에 하는 짓이다.
“HTTPS Everywhere”가 작동한 건 부분적으로 그것이 깔끔한 선을 그어 안쪽에 승리를 선언할 수 있는 경계를 가졌기 때문이다. 바로 그게 그걸 이길 수 있게 만들었고 — 바로 그게 남은 문제들을 다르게 만든다. 신뢰, 신원, 폐기, 메타데이터: 어느 것도 100까지 올라가 거기 머무는 백분율을 갖지 않는다. 어느 것도 10월에 기본으로 수정을 내보내 티켓을 닫는 Chrome 버전을 갖지 않는다. 그것들은 결코 끝나지 않는 종류의 문제고, 최근 웹 보안에서 우리의 근육 기억 전체는 끝나는 문제를 중심으로 만들어졌다.
그래서 2026년 10월에 우리 모두가 받게 될 초록 체크마크의 진짜 위험은 그게 틀렸다는 게 아니다. 그게 끝처럼 느껴진다는 것이다. 15년의 “자물쇠를 찾아라, 인증서를 받아라, HTTPS를 켜라”가 한 산업을 훈련시켜 전송 보안이 보안 이야기라고 믿게 만들었다. 이제 그 이야기의 마지막 장이 기본값으로 브라우저에 쓰이고 있고, 긴 프로젝트를 끝낸 인간의 자연스러운 반응은 그 범주가 처리됐다고 믿는 것이다.
처리되지 않았다. 우리는 여전히 안정적으로 신원을 확인할 수 없는 목적지로, 개별로는 보증할 수 없는 150명의 문지기가 지키는, 대체로 작동하지 않는 폐기 시스템과 길 건너 누구든 읽을 수 있는 표지판을 낀, 완벽하게 암호화된 도로를 놓았다. 그건 HTTPS가 고치겠다고 약속한 게 애초에 아니었다. 그저 그게 제 일을 다 하고 나서 남은 것일 뿐이다.
쉬운 쪽은 끝났다. 그게 좋은 소식이자 문제 전체다, 동시에.