HTTPS 보안 설정 방법 — 무료 SSL 설치 3가지 경로와, 정식 구성 vs 광고용 약식 구성의 차이

- SSL 인증서는 세 경로 모두 무료로 적용할 수 있습니다 — 호스팅·웹빌더 원클릭, 서버 직접 설치(Let's Encrypt), CDN(Cloudflare) 앞단.
- 유료 인증서는 암호화 강도를 사는 것이 아니라 기업 실체 검증·보증·기술지원을 사는 것입니다. 대부분의 홈페이지·랜딩은 무료로 충분합니다.
- 광고 경고만 급히 막는 '약식'(Cloudflare Flexible)은 CDN 뒤 구간이 평문입니다. 문의 폼·로그인이 있다면 절대 쓰면 안 되고, 쓰더라도 정식 전환 일정을 함께 잡아야 합니다.
앞선 글 HTTPS 보안 설정 완전 정리에서 '왜 광고 전에 끝내야 하는가'를 다뤘다면, 이번 글은 '그래서 어떻게 하는가'입니다. 실무에서 가장 많이 받는 질문 세 가지 — 정말 무료로 되는지, 우리 사이트는 어떤 방법을 써야 하는지, 그리고 급할 때 쓰는 '약식'이 괜찮은지 — 에 기술적으로 답해 보겠습니다.
0. 먼저, 내 사이트가 어떤 환경인지 확인하세요
설치 방법은 서버를 누가 관리하느냐에 따라 갈립니다. 아래 셋 중 하나에 반드시 해당합니다.

- 카페24·가비아·아임웹·윅스·워드프레스(관리형) 등을 쓴다 → 경로 A. 관리 화면에 무료 SSL 버튼이 있습니다.
- 리눅스 서버(Nginx·Apache)를 직접 운영한다 → 경로 B. Let's Encrypt로 직접 발급합니다.
- 서버를 손댈 수 없거나, 담당 개발자가 없다 → 경로 C. 도메인 앞에 Cloudflare를 두는 방법입니다.
참고로 도메인 등록기관(가비아·후이즈 등)과 호스팅 업체가 다를 수 있습니다. SSL은 '사이트가 실제로 돌아가는 곳(호스팅/서버)'에 설치하는 것이므로, 어디에 설치할지 헷갈릴 때는 웹사이트 파일이 올라가 있는 곳을 기준으로 생각하시면 됩니다.
1. 경로 A — 호스팅·웹빌더 무료 SSL (가장 쉽고, 이미 정식입니다)
국내 주요 호스팅과 웹빌더는 대부분 무료 SSL을 기본 제공합니다. 관리 화면에서 신청 버튼을 누르면 인증서가 자동 발급되고 갱신까지 자동으로 처리됩니다. 별도 비용도, 서버 지식도 필요 없습니다.
- 순서 — 도메인을 호스팅에 정상 연결 → 관리 화면의 'SSL 보안 서버 인증서' 또는 'HTTPS 설정' 메뉴 → 무료 인증서 신청 → 발급 완료 대기(보통 수 분~수십 분)
- 주의 1 — 도메인 연결(DNS)이 먼저 완료돼야 발급이 됩니다. 도메인을 방금 바꿨다면 전파를 기다린 뒤 신청하세요.
- 주의 2 — 발급 후 "HTTPS로 자동 연결" 옵션을 반드시 켜야 http 접속이 https로 넘어갑니다. 이 옵션을 안 켜서 인증서는 있는데 경고가 계속 뜨는 경우가 흔합니다.
- 주의 3 —
www포함 주소와 미포함 주소가 모두 발급 대상에 들어갔는지 확인하세요.
2. 경로 B — 서버 직접 설치: Let's Encrypt + Certbot
직접 운영하는 서버라면 비영리 인증기관 Let's Encrypt를 씁니다. 전 세계에서 가장 널리 쓰이는 무료 인증서이며, 브라우저·검색 로봇이 모두 신뢰하는 정식 공인 인증서입니다. 발급 도구는 Certbot이 표준입니다.
설치 명령 (Ubuntu + Nginx 기준)
# 1) Certbot 설치 sudo apt update sudo apt install certbot python3-certbot-nginx # 2) 인증서 발급 + Nginx 자동 설정 (www 포함/미포함 함께) sudo certbot --nginx -d example.com -d www.example.com # 3) 자동 갱신이 정상 동작하는지 시뮬레이션 sudo certbot renew --dry-run
Apache를 쓴다면 --nginx 대신 --apache를 사용합니다. 발급 과정에서 "http를 https로 리다이렉트할까요?"라고 물으면 리다이렉트를 선택하세요. 그 한 번의 선택으로 앞 글에서 강조한 301 전환이 함께 처리됩니다.
유효기간과 자동 갱신 — 여기가 핵심입니다
Let's Encrypt 인증서의 유효기간은 90일입니다. 짧다고 느끼실 수 있지만 의도된 설계이며, 업계 전체가 이 방향으로 가고 있습니다. Let's Encrypt는 2025년부터 6일짜리 초단기 인증서 옵션을 제공하기 시작했고, 기본 유효기간도 단계적으로 줄여 2027년 2월 64일, 2028년 2월 45일로 전환할 계획을 공개했습니다. 앞 글에서 소개한 국제 표준 기구의 47일 단축 로드맵과 같은 흐름입니다.
--dry-run 명령으로 한 번만 확인해 두시면 됩니다.와일드카드가 필요하다면
서브도메인이 여러 개(m.example.com, shop.example.com 등)라면 와일드카드 인증서가 편합니다. Let's Encrypt도 무료로 발급하며, 이때는 도메인 DNS에 인증용 레코드를 추가하는 DNS-01 방식을 사용합니다.
sudo certbot certonly --manual --preferred-challenges dns \ -d example.com -d *.example.com
ZeroSSL 등 다른 무료 발급기관도 있지만, 자동화 생태계와 자료의 양을 감안하면 Let's Encrypt가 사실상 표준입니다.
3. 경로 C — Cloudflare 앞단 적용, 그리고 '약식'의 실체
서버를 직접 손대기 어려운 상황에서 가장 많이 쓰이는 방법입니다. 도메인의 네임서버를 Cloudflare로 바꾸면 무료 플랜에서도 Universal SSL이 자동 적용되어, 방문자 눈에는 즉시 자물쇠가 보입니다. 서버에 접속할 필요조차 없습니다.
문제는 여기서부터입니다. Cloudflare에는 암호화 모드가 4가지 있고, 어느 것을 고르느냐에 따라 '실제 보안 수준'이 완전히 달라집니다. 자물쇠는 네 경우 모두(Off 제외) 똑같이 보이기 때문에, 이 차이를 모르면 보안이 된 줄 착각하게 됩니다.

Flexible = 흔히 말하는 '약식 버전'
Flexible 모드는 방문자~Cloudflare 구간만 암호화하고, Cloudflare~원본 서버 구간은 평문(HTTP)으로 전달합니다. 서버에 인증서를 설치하지 않아도 되니 5분이면 적용되고, 크롬 경고도 사라지며, 광고 심사도 통과합니다. 그래서 "일단 광고부터 켜야 한다"는 상황에서 자주 선택됩니다.
하지만 실체는 절반짜리 암호화입니다. 방문자가 입력한 이름·연락처가 뒷구간에서 평문으로 흐르고, 사용자는 자물쇠를 보며 안전하다고 믿습니다. Cloudflare 공식 문서 역시 원본으로의 악의적 연결을 막기 위해 Full 또는 Full (Strict) 사용을 강력히 권고합니다. 여기에 실무적 부작용도 있습니다 — 원본 서버가 자체적으로 https를 강제하고 있으면 리다이렉트 무한 루프가 발생해 사이트가 아예 열리지 않는 사고가 자주 납니다.
정식으로 쓰려면 — Full (Strict) + Origin CA
Cloudflare를 쓰면서도 정식 구성을 만들 수 있습니다. Cloudflare가 Origin CA 인증서를 무료로 발급하므로, 이것을 원본 서버에 설치한 뒤 모드를 Full (Strict)로 올리면 양쪽 구간이 모두 암호화되고 원본 인증서 검증까지 이뤄집니다. 서버에 인증서를 한 번 설치하는 수고만 감수하면, 무료로 완전한 구성이 됩니다.
4. 상황별 판단 — 약식으로 가도 되는 경우, 안 되는 경우

정리하면 판단 기준은 의외로 단순합니다. 호스팅이나 서버를 손댈 수 있으면 무조건 정식으로 가세요. 어차피 무료이고 시간도 얼마 걸리지 않습니다. 약식이 검토 대상이 되는 경우는 서버를 당장 손댈 수 없는데 광고 일정이 코앞인, 그리고 개인정보 입력이 없는 소개형 페이지뿐입니다. 그 경우에도 저희는 2주 내 정식 전환을 조건으로 권합니다. 임시 조치가 영구가 되는 순간, 위험은 그대로 남아 있으면서 아무도 그 사실을 기억하지 못하게 되기 때문입니다.
5. 설치 후 마무리 6가지 — 여기까지 해야 끝납니다

전체 301 리다이렉트
http로 들어온 방문자를 https로 넘깁니다. 서버 설정 예시는 아래와 같습니다.
# Nginx
server {
listen 80;
server_name example.com www.example.com;
return 301 https://\$host\$request_uri;
}
# Apache (.htaccess)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)\$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
HSTS 헤더
한 번 https로 접속한 브라우저가 이후 무조건 https로만 접속하도록 강제합니다. 다만 전 페이지가 https로 정상 동작하는 것을 확인한 뒤에 적용해야 합니다.
Strict-Transport-Security: max-age=31536000; includeSubDomains
혼합 콘텐츠·TLS 버전·광고 URL
본문 내 http:// 리소스를 모두 교체하고, TLS 1.2 이상만 허용하도록 정리한 뒤, 광고 캠페인의 최종 URL을 전수 점검합니다. 사이트는 https로 바꿨는데 오래된 캠페인 소재에 http 주소가 남아 있는 사례가 가장 흔한 사고입니다. 서치어드바이저·서치콘솔 재등록과 전환 스크립트 재확인까지 마치면 마무리입니다.

6. 검증 — 제대로 됐는지 확인하는 방법
- SSL Labs 등급 테스트 —
ssllabs.com/ssltest에 도메인을 넣으면 구성 등급이 나옵니다. A 등급이면 정상입니다. B 이하라면 TLS 버전이나 인증서 체인 문제가 있다는 뜻입니다. - 브라우저 개발자도구 콘솔 — 페이지를 열고 콘솔에 mixed content 경고가 없는지 확인합니다.
- http로 강제 접속 — 주소창에
http://를 직접 입력해 https로 자동 전환되는지 확인합니다. - 실제 단말·인앱 브라우저 — 스마트폰과 카카오톡·인스타그램 인앱 브라우저에서 경고 없이 열리는지 확인합니다. 광고 유입의 다수가 여기로 들어옵니다.
- 테스트 전환 1건 — 폼을 실제로 제출해 전환이 리포트에 집계되는지 확인하면 완전히 끝납니다.
7. 순서를 지킨 광고가 결국 이깁니다
여기까지가 광고를 켜기 전에 끝내야 하는 작업입니다. 대부분 무료이고, 대부분 하루 안에 끝납니다. 그런데도 이 과정이 자주 생략되는 이유는 간단합니다 — 광고 계정 안에서는 보이지 않기 때문입니다. 클릭수도 나오고 노출도 나오는데 문의만 없는 계정을 열어보면, 랜딩페이지에서 이미 절반이 사라지고 있는 경우가 정말 많습니다.
이노빈은 캠페인 세팅 전에 이 항목들을 먼저 확인하고, 광고주가 직접 처리하기 어려운 부분은 호스팅사·개발 담당자에게 전달할 수 있도록 구체적인 요청 사항으로 정리해 드립니다. "SSL을 적용해 주세요"가 아니라 "무료 인증서 발급 후 https 자동 연결 옵션을 켜고, www 포함 주소도 발급 대상에 넣어 주세요"처럼요. 그래야 실제로 처리가 됩니다.
기술적 준비는 광고의 전제 조건이지 옵션이 아닙니다. 그릇을 먼저 고치고 물을 붓는 것, 그 순서 하나가 3개월 뒤 리포트를 바꿉니다.
우리 사이트, 지금 어떤 상태인지 확인해 드립니다
인증서 적용 여부와 구성 수준, 리다이렉트·혼합 콘텐츠·전환 스크립트까지 무료로 진단해 드립니다. 필요한 조치는 호스팅사에 그대로 전달할 수 있는 형태로 정리해 드립니다.
사이트·광고 무료 진단 신청