HTTPS 보안 설정(SSL/TLS) 완전 정리 — 웹 프로토콜 개념부터 광고 집행 전 반드시 끝내야 하는 이유까지

- HTTPS는 별도 기술이 아니라 HTTP를 TLS로 감싼 것입니다. 기밀성·무결성·인증 세 가지를 보장하며, 'SSL 인증서'는 관행적 표현일 뿐 실체는 TLS 인증서입니다.
- 보안 미적용 사이트로 광고를 돌리면 클릭 비용을 내고도 경고창에서 이탈하고, 전환 측정까지 깨집니다. 구글은 접근 불가·비정상 목적지를 정책 위반으로 다룹니다.
- 크롬은 2026년 10월(Chrome 154)부터 모든 사용자에게 HTTP 경고를 기본 적용합니다. 지금이 사실상 마지막 정비 시점입니다.
광고를 클릭한 잠재고객이 랜딩페이지 대신 "이 사이트는 보안 연결을 지원하지 않습니다"라는 회색 경고 화면을 만난다면, 그 클릭은 어떻게 될까요. 비용은 이미 지불됐고, 방문자는 대부분 뒤로가기를 누릅니다. 광고 성과가 나오지 않는 원인을 소재나 키워드에서만 찾다 보면 놓치기 쉬운 것이 이 지점입니다.
이 글은 웹 프로토콜의 개념부터 SSL/TLS 인증서의 작동 원리, 광고 집행 전에 반드시 해결해야 하는 이유, 그리고 구글·네이버의 관련 광고 정책까지 광고 실무자의 관점으로 정리했습니다.
1. 웹 프로토콜 개념 — HTTP는 무엇이고 HTTPS는 무엇이 다른가
프로토콜은 통신 규약, 쉽게 말해 "이런 형식으로 주고받자"는 약속입니다. 웹에서 브라우저가 서버에 페이지를 요청하고 서버가 응답하는 이 약속이 HTTP(HyperText Transfer Protocol)입니다. 우리가 주소창에 입력하는 http://가 바로 그것이고, 웹의 출발점부터 지금까지 쓰이는 기본 규약입니다.
문제는 HTTP가 설계될 당시 보안이 고려되지 않았다는 점입니다. HTTP로 오가는 데이터는 암호화되지 않은 평문입니다. 같은 네트워크(공용 와이파이 등)에 있는 누군가가 그 내용을 들여다보거나, 중간에서 내용을 바꿔치기해도 사용자는 알 수 없습니다. 접속한 서버가 진짜 그 회사의 서버인지 확인할 방법도 없습니다.

이 세 가지 빈틈을 메우기 위해 HTTP 위에 암호화 계층을 덧씌운 것이 HTTPS입니다. 여기서 암호화를 담당하는 규약이 TLS(Transport Layer Security)이고요. 즉 HTTPS = HTTP + TLS이며, HTTPS는 새로운 언어가 아니라 기존 HTTP 대화를 봉인된 봉투에 넣어 보내는 방식이라고 이해하시면 정확합니다.
SSL과 TLS, 무엇이 맞는 말인가
실무에서는 "SSL 인증서 설치했나요?"라고 말하지만, 엄밀히 SSL(Secure Sockets Layer)은 TLS의 옛 이름입니다. SSL 3.0까지 발전한 뒤 보안 취약점 때문에 폐기됐고, 후속 규격이 TLS라는 이름으로 이어져 현재는 TLS 1.2와 TLS 1.3이 사용됩니다. 시장에서 'SSL 인증서'라는 표현이 굳어져 그대로 쓰일 뿐, 여러분이 오늘 발급받는 인증서는 모두 TLS 인증서입니다. 견적서나 호스팅 관리 화면에서 두 용어가 섞여 나와도 같은 것을 가리킨다고 보시면 됩니다.
2. 인증서는 무엇을 보장하나 — TLS 핸드셰이크의 이해

사용자가 주소를 입력하는 순간, 브라우저와 서버 사이에서 핸드셰이크라는 절차가 진행됩니다. 서버가 인증서를 제시하면 브라우저는 그 인증서가 신뢰할 수 있는 발급기관(CA)의 서명을 받았는지, 도메인이 일치하는지, 유효기간이 지나지 않았는지를 확인합니다. 통과하면 양측만 아는 세션 키를 만들어 이후 통신을 암호화하고, 통과하지 못하면 우리가 아는 그 경고 화면이 뜹니다.
여기서 중요한 것은 인증서가 보장하는 것이 암호화 하나가 아니라 세 가지라는 점입니다.
내용을 감추는 기밀성, 중간 변조를 잡아내는 무결성, 그리고 "이 서버가 정말 그 도메인의 주인이 맞다"는 인증. 광고 관점에서 특히 의미 있는 것은 세 번째입니다. 잠재고객이 우리 브랜드를 사칭한 페이지가 아니라 진짜 우리 사이트에 도착했다는 것을 브라우저가 대신 보증해 주는 셈이니까요.
인증서 종류는 검증 수준에 따라 DV·OV·EV로 나뉩니다. 도메인 소유만 확인하는 DV는 무료 발급(Let's Encrypt 등)도 가능하고 대부분의 홈페이지·랜딩페이지에는 충분합니다. 사업자 실체까지 확인하는 OV는 결제·회원정보를 다루는 쇼핑몰과 기업 사이트에서 선호됩니다. 가장 엄격한 EV는 과거 주소창에 회사명이 표시되는 이점이 있었으나 브라우저 UI가 바뀌면서 시각적 차별점은 거의 사라졌습니다. 암호화 강도 자체는 세 종류가 동일합니다 — 차이는 '누가 발급받았는지를 얼마나 검증했는가'에 있습니다.
3. 왜 '광고 집행 전에' 끝내야 하는가

① 클릭 비용은 냈는데, 랜딩에 도달하지 못합니다
가장 직접적인 손실입니다. 검색광고든 디스플레이든 클릭은 이미 과금됐는데 방문자는 경고 화면에서 이탈합니다. 전환율이 떨어지는 정도가 아니라 방문 자체가 성립하지 않습니다. 그리고 이 위험은 지금 급격히 커지고 있습니다. 구글은 크롬에서 안전하지 않은 연결을 경고하는 '항상 보안 연결 사용' 기능을 2026년 4월 Chrome 147에서 일부 사용자에게 먼저 적용했고, 2026년 10월 Chrome 154부터는 모든 사용자에게 기본값으로 적용한다고 공식 발표했습니다. 참고로 구글이 밝힌 현재 공개 사이트의 HTTPS 접속 비율은 윈도우 98%, 안드로이드·맥 99% 이상입니다. 남은 소수에 우리 사이트가 포함돼 있다면, 곧 모든 방문자가 경고를 보게 된다는 뜻입니다.
② 광고 심사와 목적지 정책에 걸립니다
광고 매체는 랜딩페이지를 자동으로 크롤링해 정상 작동 여부를 확인합니다. 인증서 오류로 크롤러가 접근하지 못하거나 오류를 반환하면 심사가 반려되거나 게재 중이던 광고가 중단될 수 있습니다. 상세 정책은 아래 4·5장에서 따로 정리했습니다.
③ 전환 측정이 조용히 무너집니다
실무자가 가장 늦게 발견하는 문제입니다. HTTPS 페이지에 HTTP 리소스가 섞인 혼합 콘텐츠(mixed content)는 브라우저가 차단하는데, 이때 광고 픽셀이나 전환 태그가 함께 막히면 전환이 집계되지 않습니다. 또한 최근 브라우저는 Secure 속성이 없는 쿠키의 동작을 제한하므로, 방문자 식별과 리타게팅 모수 축적에도 구멍이 생깁니다. 광고는 정상 집행 중인데 리포트상 전환이 0에 수렴한다면 소재를 고치기 전에 이 부분부터 확인해야 합니다. 전환 데이터가 부정확하면 퍼포먼스 마케팅의 자동입찰 AI도 잘못된 신호를 학습하게 됩니다.
④ 개인정보를 평문으로 받게 됩니다
문의 폼으로 들어오는 이름·연락처·주소가 암호화 없이 전송됩니다. 광고의 목적이 DB 수집이라면 이는 성과 문제 이전에 관리 책임의 문제입니다. 개인정보를 취급하는 페이지에서 전송 구간 암호화는 사실상 기본 요건으로 요구되며, 브라우저 역시 비보안 페이지의 입력창에 별도 경고를 표시합니다.
⑤ 검색 노출과 자연유입도 함께 잃습니다
검색엔진은 동일 조건이라면 HTTPS 페이지를 선호하고, 인증서 만료·자체 서명 인증서·도메인 불일치는 검색 로봇의 수집 실패로 이어집니다. 광고를 멈춰도 남아야 할 자연유입 자산까지 함께 깎이는 셈입니다.
4. 구글 광고 정책 — 목적지(Destination) 요구사항
구글애즈는 광고 소재뿐 아니라 도착 페이지(목적지)에 대한 정책을 별도로 두고 있습니다. HTTPS를 직접 명시한 조항이라기보다, 보안 문제가 아래 항목의 위반으로 연결되는 구조라고 이해하는 것이 정확합니다.
| 정책 항목 | 기준 | SSL 미비 시 발생하는 상황 |
|---|---|---|
| 작동하지 않는 목적지 (Destination not working) | 광고의 목적지와 콘텐츠가 일반적인 브라우저·기기에서 정상 작동해야 하며, 구글 AdsBot 크롤러에 HTTP 오류 코드를 반환해서는 안 됩니다. | 인증서 오류·설정 불량으로 크롤러가 페이지를 정상 확인하지 못하면 위반으로 처리될 수 있습니다. |
| 접근할 수 없는 목적지 (Destination not accessible) | 타겟팅한 지역에서 목적지에 접근 가능해야 합니다. | 특정 환경·브라우저에서만 경고나 차단이 발생하는 경우 접근성 문제로 이어집니다. |
| 목적지 불일치 (Destination mismatch) | 표시 URL의 도메인과 최종 URL이 일치해야 하며, 리디렉션으로 다른 도메인에 보내면 안 됩니다. | HTTP→HTTPS 전환 과정에서 리다이렉트를 잘못 설정하면 도메인 불일치로 판정될 수 있습니다. |
실무적으로 기억할 점은 두 가지입니다. 첫째, 사람이 보는 화면과 크롤러가 보는 화면이 다를 수 있습니다. 담당자 PC에서는 경고를 한 번 무시한 뒤라 잘 열리는데 크롤러는 막히는 경우가 흔합니다. 둘째, 리다이렉트 설계가 정책과 직결됩니다. http에서 https로 넘길 때는 도메인을 유지한 채 301로 한 번에 보내야 하고, 광고 최종 URL 자체를 https로 교체해 두는 것이 가장 안전합니다.
5. 네이버 광고 정책 — 사이트 검수와 로봇 수집
네이버 검색광고 역시 등록된 사이트가 정상적으로 접속·운영되는지를 검수합니다. 접속이 되지 않거나 광고 내용과 사이트 내용이 일치하지 않는 경우, 또는 검색 로봇이 사이트를 정상적으로 확인할 수 없는 경우 광고 등록이 제한되거나 노출이 중단될 수 있습니다. 실무에서 자주 마주치는 유형은 다음과 같습니다.
- 인증서 만료 — 갱신 시기를 놓쳐 만료되면 방문자에게는 경고가, 로봇에게는 접근 실패가 발생합니다. 가장 흔하고 가장 허무한 사고입니다.
- 자체 서명(사설) 인증서 — 공인 발급기관이 아닌 자체 발급 인증서는 브라우저와 로봇 모두 신뢰하지 않습니다.
- 도메인 불일치 — www 포함/미포함 중 한쪽에만 인증서가 적용된 경우, 특정 주소로만 접근이 막힙니다.
- 혼합 콘텐츠 — https 페이지 안에 http 이미지·스크립트가 남아 있으면 자물쇠가 깨지고 일부 기능이 차단됩니다.
- robots.txt 차단·과도한 리다이렉트 — 로봇 접근을 막아두거나 리다이렉트가 여러 단계로 이어지면 최종 페이지 확인에 실패합니다.
PC와 모바일에서 서로 다른 주소를 쓰는 사이트라면 양쪽 모두 인증서와 리다이렉트를 점검해야 합니다. 모바일 페이지만 http로 남아 있는 사례가 의외로 많고, 파워링크 유입의 다수가 모바일이라는 점을 생각하면 손실이 더 큽니다. 파워링크 성과 자체를 끌어올리는 방법은 파워링크 전환 8대 체크포인트에서 별도로 다뤘습니다.
6. 광고 집행 전 HTTPS 점검 8단계

순서대로 확인하시면 됩니다. 특히 5번(광고 최종 URL 전수 교체)은 사이트를 https로 바꾼 뒤에도 예전 캠페인 소재에 http 주소가 남아 있는 경우가 많아, 실제 사고가 가장 자주 나는 항목입니다.
추가로 알아두실 흐름이 하나 있습니다. 인증서의 최대 유효기간이 계속 짧아지고 있습니다.
국제 표준 기구(CA/Browser Forum)의 결정에 따라 기존 398일에서 2026년 3월부터 단계적으로 축소되기 시작했고, 2029년 3월에는 47일까지 줄어듭니다. 사람이 달력에 적어두고 갱신하는 방식으로는 감당하기 어려운 주기이므로, 자동 갱신이 되는 환경인지를 지금 확인해 두시는 편이 좋습니다.

7. 좋은 광고는 계정 밖에서 시작됩니다
광고 대행 상담을 하다 보면 "키워드를 어떻게 잡을까요", "소재를 어떻게 바꿀까요"라는 질문을 먼저 받습니다. 물론 중요합니다. 다만 저희가 계정 진단을 할 때 가장 먼저 보는 것은 랜딩페이지가 제대로 열리는가입니다. 보안 경고, 느린 로딩, 깨진 모바일 화면, 작동하지 않는 전환 스크립트 — 이런 것들은 광고 계정 안에서는 보이지 않지만 성과를 가장 크게 갉아먹습니다.
이노빈은 캠페인을 켜기 전에 이 기술적 토대를 먼저 점검합니다. 인증서와 리다이렉트, 전환 스크립트 발동 여부, 모바일·인앱 브라우저 실제 확인까지 마친 뒤에 예산을 태웁니다. 순서를 지키면 같은 예산에서 더 많은 방문이 남고, 남은 방문이 정확히 측정되며, 측정된 데이터가 다시 매체 AI를 학습시킵니다. 이런 부분까지 확인하고 시작하는 광고와 그렇지 않은 광고의 차이는, 3개월 뒤 리포트에서 분명하게 드러납니다.
광고는 트래픽을 만드는 일이고, 사이트는 그 트래픽을 받아내는 그릇입니다. 그릇을 먼저 고치는 것이 가장 확실한 성과 개선입니다.
광고 시작 전, 사이트부터 진단받아 보세요
인증서·리다이렉트·혼합 콘텐츠·전환 스크립트까지 광고 집행에 영향을 주는 기술 요소를 무료로 점검해 드립니다. 개선이 필요한 항목은 우선순위로 정리해 드립니다.
사이트·광고 무료 진단 신청