개인 서버인 맥미니에서 워드프레스를 운영하면서 HTTPS가 필요했습니다. 도메인은 카페24에서 구입했지만, 제가 필요했던 무료 HTTPS 인증서 서비스는 제공되지 않았습니다. 별도의 유료 인증서를 구입하지 않고 HTTPS를 적용할 방법을 찾다가 Cloudflare의 무료 서비스를 이용하게 됐습니다.
이 글은 운영자의 실제 사용·운영 경험과 작성 당시 확인 가능한 자료를 바탕으로 정리했습니다. AI는 구성과 문장 편집을 보조했으며, 공개 전 사실관계·링크·적용 조건은 운영자가 최종 검토했습니다. 자세한 기준은 콘텐츠 제작·AI 활용 원칙에서 확인할 수 있습니다.
Cloudflare는 정말 편리했습니다. 무료 요금제만으로 HTTPS를 적용할 수 있었고, 인증서 갱신도 알아서 처리해 줬습니다. 인증서 만료일을 기억하거나 매번 다시 발급할 필요가 없다는 점이 특히 좋았습니다. 비용 부담 없이 안정적인 서비스를 이용할 수 있다는 것도 참 고마웠습니다.
다만 Cloudflare를 적용한 뒤 사이트 속도가 느려졌습니다. 처음에는 접속이 조금 늦는 정도라고 생각해 대수롭지 않게 넘겼습니다. 사이트가 열리지 않는 것도 아니었고 HTTPS도 정상적으로 작동했기 때문입니다. 하지만 계속 사용하다 보니 페이지가 반응하기까지 기다리는 시간이 점점 답답하게 느껴졌습니다.
느려진 속도를 확인해 보니 658ms였습니다
WordPress 사이트 건강 화면에서 확인해 보니 페이지 캐시는 작동하고 있었지만, 서버 응답시간 중앙값은 658ms였습니다. 권장 한계로 표시된 600ms보다 느렸고, 다른 측정에서는 713ms도 확인됐습니다.
페이지 캐시는 작동했지만 서버 응답시간은 658ms로 측정됐습니다.
DNS 조회는 수 밀리초 수준으로 빨랐습니다. 반면 실제 웹 문서의 첫 응답에는 약 0.5~0.9초가 걸렸고, 응답 헤더에서는 Cloudflare의 홍콩(HKG) 구간을 경유한다는 사실을 확인할 수 있었습니다.
국내 방문자가 국내에 있는 제 맥미니에 접속하는데 웹 요청은 홍콩 프록시를 거쳐 서버에 도착하고, 응답도 다시 같은 경로로 돌아오고 있었습니다.
변경 전 경로: 방문자 → Cloudflare 홍콩 구간 → 맥미니 → Cloudflare 홍콩 구간 → 방문자
물론 Cloudflare가 언제나 느리다는 뜻은 아닙니다. 정적 파일이 가까운 엣지 서버에 캐시되거나 서버와 방문자의 위치가 다르면 좋은 결과가 나올 수도 있습니다. 다만 제 환경에서는 캐시되지 않는 워드프레스 HTML 요청과 홍콩 경유가 겹치면서 지연이 분명하게 나타났습니다.
“그렇다면 인증서를 내 서버에서 관리하면 되지 않을까?”
그렇다고 Cloudflare 프록시를 바로 끌 수도 없었습니다. 당시에는 무료 HTTPS를 Cloudflare에 의존하고 있었기 때문입니다. 프록시를 끄면 방문자가 맥미니로 직접 접속하므로, 이제 제 서버가 브라우저에서 신뢰할 수 있는 인증서를 직접 제공해야 했습니다.
그러다 이런 생각이 들었습니다.
무료 인증서 때문에 해외 프록시를 계속 거쳐야 한다면, 차라리 내 서버에서 무료 인증서를 발급받고 자동으로 갱신하면 되지 않을까?
이번 작업은 이 질문에서 시작했습니다. Cloudflare 인증서를 다른 인증서로 단순히 바꾼 것이 아닙니다. Cloudflare 웹 프록시 경로를 제거하고, 맥미니가 Let’s Encrypt 인증서를 발급받아 HTTPS를 직접 제공하도록 구조를 바꿨습니다.
맥미니에는 이렇게 구성했습니다
먼저 Homebrew로 Certbot을 설치했습니다. Let’s Encrypt는 외부 인증기관이고, Certbot은 그곳에서 인증서를 발급받고 갱신해 주는 프로그램입니다.
brew install certbot
certbot --version
이 서버에는 Certbot 5.7.0이 설치됐습니다.
다음으로 Let’s Encrypt가 도메인 소유 여부를 확인할 수 있도록 Apache에 HTTP-01 확인 경로를 열었습니다. 워드프레스 요청은 내부 서버로 전달하되, 인증서 확인에 사용하는 주소만 맥미니가 직접 제공하도록 예외를 둔 것입니다.
Alias "/.well-known/acme-challenge/" "/Library/WebServer/.well-known/acme-challenge/"
<Directory "/Library/WebServer/.well-known/acme-challenge/">
Options None
AllowOverride None
Require all granted
</Directory>
ProxyPass "/.well-known/acme-challenge/" "!"
이 예외가 일반 워드프레스 프록시 규칙보다 먼저 적용되도록 설정한 뒤, 실제로 운영하는 메인 도메인과 서브도메인을 한 장의 인증서에 포함해 발급했습니다. 아래 명령의 도메인은 각자의 환경에 맞게 바꿔야 합니다.
sudo certbot certonly --webroot \
-w /Library/WebServer \
--key-type ecdsa \
-d example.com \
-d www.example.com \
-d sub.example.com
발급이 끝난 뒤 Apache의 HTTPS 설정이 Let’s Encrypt 인증서와 개인키를 읽도록 연결했습니다.
SSLEngine On
SSLCertificateFile "/etc/letsencrypt/live/example.com/fullchain.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/example.com/privkey.pem"
개인키 파일의 내용은 복사하거나 외부에 공개하면 안 됩니다. Apache가 필요한 경로에서 직접 읽도록 두는 것이 안전합니다.
설정을 바꾼 뒤에는 바로 재시작하지 않고 먼저 문법을 확인했습니다. 문제가 없다는 것을 확인한 다음 Apache가 새 인증서를 읽도록 반영했습니다.
sudo apachectl configtest
sudo apachectl graceful
인증서 자동 갱신과 재부팅까지 준비했습니다
Let’s Encrypt 인증서는 무료지만 유효기간이 짧기 때문에 자동 갱신이 중요합니다. 한 번 발급받고 끝내면 언젠가 인증서가 만료돼 사이트에 보안 경고가 나타날 수 있습니다.
제 맥미니에서는 Certbot 갱신 작업을 macOS의 LaunchDaemon으로 등록했습니다. 설정 파일은 다음 위치에 있습니다.
/Library/LaunchDaemons/com.khoonlabs.certbot-renew.plist
이 작업은 맥미니가 부팅될 때 한 번 실행되고, 이후 매일 오전 3시 17분과 오후 3시 17분에 갱신 필요 여부를 확인합니다.
아직 갱신할 때가 아니라면 아무것도 바꾸지 않습니다. 인증서가 실제로 갱신됐을 때만 Apache가 새 인증서를 읽도록 다시 불러옵니다.
LaunchDaemon에 등록한 핵심 명령은 다음과 같습니다.
/opt/homebrew/bin/certbot renew \
--quiet \
--no-random-sleep-on-renew \
--deploy-hook "/usr/sbin/apachectl graceful"
--deploy-hook이 중요한 부분입니다. 인증서가 갱신된 뒤 Apache를 부드럽게 다시 불러와 새 인증서가 실제 웹서비스에 반영되도록 해 줍니다.
또한 RunAtLoad를 사용해 서버가 재부팅돼도 갱신 작업이 자동으로 올라오도록 했습니다. Apache 웹서비스도 부팅 후 자동으로 시작되므로, 재부팅할 때마다 인증서나 웹서버를 사람이 다시 실행할 필요가 없습니다.
마지막으로 자동 갱신이 실제로 작동할지 모의시험을 진행했습니다.
sudo certbot renew --dry-run --run-deploy-hooks
프록시를 끄기 전과 끈 뒤 모두 시험에 성공했습니다. Apache 설정, 인증서 신뢰 여부, 메인 도메인과 서브도메인의 HTTPS 응답도 함께 확인했습니다.
Cloudflare는 DNS로 남기고 프록시만 껐습니다
인증서 발급과 자동 갱신 시험까지 마친 뒤 Cloudflare DNS 레코드를 프록시됨에서 DNS 전용으로 바꿨습니다. Cloudflare 계정을 해지하거나 네임서버를 옮긴 것은 아닙니다. Cloudflare는 도메인이 어느 서버를 가리키는지 알려주는 DNS 서비스로 계속 사용하고 있습니다.
이제 웹 요청은 홍콩 프록시를 거치지 않고 맥미니로 직접 들어옵니다. 대신 Cloudflare의 CDN 캐시, WAF, DDoS 방어와 원본 IP 은닉 같은 프록시 기반 기능은 방문 경로에서 빠지게 됩니다. 속도만 보고 무조건 프록시를 끄기보다는 각자의 서버 위치와 보안 환경을 함께 살펴보는 것이 좋습니다.
응답시간이 658ms에서 12ms로 줄었습니다
전환을 마친 뒤 같은 WordPress 사이트 건강 화면에서 다시 측정해 봤습니다. 페이지 캐시는 정상적으로 감지됐고, 서버 응답시간 중앙값은 12ms로 표시됐습니다.
프록시 경로를 제거하고 직접 HTTPS로 전환한 뒤 측정된 응답시간은 12ms였습니다.
658ms에서 12ms로 줄었으니 이번 두 측정값만 비교하면 약 98.2% 감소한 결과입니다. 이 비율은 같은 사이트 건강 화면에서 얻은 두 측정값의 비교입니다. 방문자 전체의 페이지 로딩 속도나 모든 지역의 접속이 55배 빨라졌다는 뜻은 아닙니다. 브라우저에서 사이트를 열었을 때의 반응도 예전처럼 빠르게 돌아왔습니다. 이렇게까지 달라지는 모습을 보니 정말 놀라웠습니다.
다만 Let’s Encrypt 인증서 자체가 사이트를 55배 빠르게 만든 것은 아닙니다. 가장 큰 변화는 홍콩을 거치던 Cloudflare 프록시 경로가 빠지고, 방문자가 국내 맥미니에 직접 연결하게 됐다는 점입니다. 워드프레스 페이지 캐시도 작동하고 있었으므로, 이 두 측정만으로 경로 변경과 캐시의 효과를 각각 구분할 수는 없습니다.
마무리
Cloudflare는 무료 HTTPS를 처음 적용할 때 정말 유용했습니다. 인증서 갱신까지 알아서 처리해 준 점도 무척 고마웠습니다. 이번 변경은 Cloudflare의 장점을 부정하려는 것이 아닙니다. 제 서버와 방문자의 위치에서는 홍콩 프록시 경로가 잘 맞지 않는다는 것을 확인했고, 지금 환경에 더 어울리는 방식으로 바꾼 것입니다.
현재 Cloudflare는 DNS 서비스로 남겨 두고 웹 프록시만 제거했습니다. 맥미니는 Let’s Encrypt 인증서를 직접 제공하고 Certbot이 갱신 시기를 확인합니다. 인증서가 갱신되면 Apache에 자동으로 반영되며, 서버를 재부팅해도 필요한 서비스가 다시 시작됩니다.
결국 이번 작업은 인증서 하나를 교체한 것이 아닙니다. 불필요한 해외 프록시 경로를 제거하고, HTTPS 발급부터 자동 갱신과 재부팅 복구까지 개인 서버에서 직접 운영하도록 바꾼 작업입니다.