블로그를 직접 호스팅하고 운영한다는 것은 마치 나만의 집을 짓는 것과 같다.
때로는 예기치 못한 비바람이 몰아치기도 한다.
오늘은 구글 클라우드 플랫폼(GCP)에서 워드프레스를 운영하는 분들이라면 한 번쯤 마주하게 될, 그러나 마주할 때마다 등줄기에 식은땀을 흐르게 하는
‘보안 인증서(SSL) 오류’**와 그에 따른 ‘SEO 설정 불일치’ 문제를 완벽하게 해결하는 과정을 기록해 보려 한다.
그러나, 지금도 전문가는 아니고 매 번 이슈가 생길 때마다 AI과 함께 고난과 역경을 함께하며 늘 해결책을 찾아 나서고 있다.
또한, 복잡한 서버 명령어 앞에서도 당황하지 않고 내 소중한 블로그를 지켜낼 수 있는 기술적 자신감을 얻고 있는 것을 기록으로 남긴다.
1. 사건의 발단: “내 블로그가 위험한 사이트라고?”
평화롭게 포스팅을 준비하던 중, 워드프레스 관리자 페이지 상단에 뜬 Rank Math의 경고 메시지가 모든 사건의 시작이었다.
“Rank Math에 연결한 후 사이트 URL이 변경된 것 같습니다. 다시 연결하려면 여기를 클릭하십시오.”라는 메시지였다. 기획 및 운영자면 늘, 이 빨간색 에러메시지를 외면하지 못하고 해결점을 찾게 된다.
단순한 플러그인 설정 오류인 줄 알고 대수롭지 않게 사이트에 접속한 순간, 경악을 금치 못했다. 브라우저 화면 전체를 가득 채운 것은 제가 밤새워 작성한 글이 아니라, 붉은색 경고 삼각형과 함께 나타난 “연결이 비공개로 설정되어 있지 않습니다”라는 문구였다.
(솔직히 울고 싶었다. 네*버, 티*토리 등 그냥 제공 하는 블로그를 쓸 껄이라는 생각도 엄청했다.)
에러 코드
NET::ERR_CERT_AUTHORITY_INVALID. 이는 웹 브라우저가 현재 사이트의 보안 인증서를 신뢰할 수 없다는 강력한 경고였고,
방문자들에게는 이 사이트가 해킹되었거나 개인정보를 탈취하는 곳으로 보일 수 있는 치명적인 상황이였다.
2. 문제 분석: 왜 이런 일이 발생했을까?
원인을 파악하기 위해 AI와 함께 점검에 나섰다.
워드프레스의 [설정] > [일반] 메뉴를 확인해달라고 했고, 워드프레스 주소와 사이트 주소가 모두 보안이 적용되지 않은 https://dophiplan.com으로 설정되어 있었다.
해당 값은 기본 값이였고, https로 바꾼다는 것을 미처 알지 못했다.
검색 엔진, 특히 구글은 HTTPS(보안 연결)가 적용되지 않은 사이트의 점수를 낮게 평가할 뿐만 아니라, 사용자 보호를 위해 접속 자체를 차단하기도 한다.
이 문제는 바로 서버 단의 SSL 인증서 설정이 꼬이면서, Rank Math와 같은 SEO 도구들이 현재의 불안정한 URL 상태를 감지하고 경고를 보낸 것이었다.
3. 기술적 추적: 사라진 서버를 찾아서
처음에 AI는 도메인 연결 하는 곳을 가보라고 했다. 그래서 가비아에 갔더니 자기네 호스팅을 쓰지 않았다고 했고, AI에 대시 물어보니 구글 클라우드로 모든 내용이 향했다.
해결을 위해 구글 클라우드 콘솔로 달려갔지만, 여기 또한 새로운 문제를 만나게 되었다.
분명히 어제까지 잘 돌아가던 wordpress-1-vm 인스턴스가 목록에서 보이지 않는 것이었다. AI한테 분명 어제까지 보였던게 안보인다고 ‘총 VM: 0’이라는 환경을 캡쳐떠서 보내주었다.
GCP의 ‘프로젝트 관리 체계’를 이해해야 한다는 것이었다. 현재 보고 있던 ‘My First Project’는 말 그대로 기본 프로젝트였고, 실제 블로그 서버는 다른 프로젝트 이름인 food data나 qwer 아래에 들어있거나, 단순히 ‘전체’ 리소스 탭 속에 숨어 있었다.
또는, 여러개의 이메일을 사용하는 경우 프로젝트 생성한 아이디가 아닌 다른 아이디로 로그인 되어있었을 가능성도 높았다.
****만약 여러분도 VM이 사라졌다면 당황하지 말고 상단 프로젝트 선택창에서 [전체] 탭을 클릭해 보는 것을 추천한다.
4. 서버 심폐소생술: Certbot과의 사투
드디어 찾아낸 wordpress-1-vm 인스턴스 옆의 [SSH] 버튼을 눌러 터미널에 접속했다.
이제 진짜 전문가의 영역인 명령줄과의 대화가 시작되었다.(물론 AI가 시키는데로 나는 착실히 수행함)
목표는 무료 보안 인증서인 Let’s Encrypt를 설치하고 적용하는 것이었다.
하지만 첫 시도는 가혹했다. sudo certbot 명령어를 입력하자마자 sudo: certbot: command not found라는 냉정한 응답이 돌아왔다.
이전의 설치 프로세스가 비정상적으로 중단(Abort)되었기 때문이였다.
시스템 패키지 목록을 최신화하고 수동으로 Certbot을 재설치하기 시작했다.
sudo apt-get update: 서버의 패키지 지도를 최신 버전으로 갱신sudo apt-get install -y certbot python3-certbot-apache: 아파치 서버용 Certbot 도구를 강제로 설치
다행히 수많은 설치 텍스트가 흘러가고, 드디어 시스템에 Certbot이 안착했다.
5. 인증서 발급: 세밀한 설정의 묘미
터미널에 sudo certbot --apache -d dophiplan.com을 입력하여 인증서 발급 프로세스를 가동했다. 이 단계에서는 기계와 인간 사이의 세밀한 대화가 필요하다.
- 이메일 주소 입력: 인증서 만료 전 알림을 받을 본인의 이메일을 입력하고, 입력 과정에서 오타로 인해
UnicodeEncodeError를 겪기도 했지만, 다시 정확하게 입력하여 통과함 - 약관 동의: 서비스 이용을 위해 대문자
A를 입력하여 동의함 - 가상 호스트(vhost) 선택: 서버가 어떤 설정 파일에 보안을 적용할지 묻었고, 기본값 대신 워드프레스 전용으로 최적화된
wordpress-https.conf를 선택함 - 강제 리다이렉트 설정: [핵심] 번호를 선택할 때 반드시
2(Redirect)를 선택하여,http접속자들을 강제로 안전한https로 넘겨주도록 설정
잠시 후, 터미널 화면에 “Congratulations!”라는 감격적인 메시지가 떴다. 2026-0*-**까지 유효한 강력한 보안 인증서가 제 블로그에 이식된 순간이었다.
6. 최종 마무리: 워드프레스와 Rank Math의 재결합
서버라는 ‘하드웨어’ 설정이 끝났으니, 이제 워드프레스라는 ‘소프트웨어’ 설정을 맞출 차례이다
가장 먼저 워드프레스 관리자 페이지의 [설정] > [일반]으로 돌아가, 주소창의 http를 모두 https로 정성스럽게 수정했다.
저장을 누르는 순간 사이트가 잠시 로그아웃되었지만, 다시 로그인했을 때 주소창 왼쪽의 자물쇠 아이콘을 확인하며 안도의 한숨을 내쉬었다.
마지막으로, 모든 사건의 발단이었던 Rank Math 알림 창에서 [다시 연결하려면 여기를 클릭하십시오]를 눌러 구글 계정과 내 블로그의 새로운 보안 URL을 연동해 주었습니다. 이제 모든 설정이 유기적으로 맞물려 정상 작동하기 시작했다.
7. 에러는 성장의 또 다른 이름입니다
이번 복구 과정을 통해 다시 한번 깨달았다.
기술적인 에러는 우리를 당황하게 만들지만, 그것을 해결해 나가는 과정에서 우리는 단순한 ‘블로거’를 넘어 ‘엔지니어’로 성장하는 느낌을 주었다.
어디서 본적이 있다.
해외에서 완벽하게 아무것도 하지 않은 밀키트를 판매 했는데 성적이 저조했다. 그 이유는 “요리”하는 느낌이 들지 않았단 이유로 반조리 상태였던 과거의 상품을
찾는 품귀현상이 일어났다.
이것과 같이 너무 자동화가 된다면 성장(?) 할 시간 조차 없었을 것 같다
특히 GCP와 같은 독립 서버 환경에서 블로그를 운영한다는 것은 높은 자유도만큼이나 큰 책임이 따른 다는 것을 알게 되었다.
나의 시행착오로 공유 된 일화가 모두의 시행착오를 줄여주는 든든한 등대가 되길 바란다. (근데, 이렇게 해놓고 오랫동안 하지 않으면 또 AI에게 물어 볼 것 같다)