2026년도 벌써 시작되었고, 이 블로그를 운영한 지도 15년이 훌쩍 넘었다. 그러다 보니 계속해서 꽤 많은 생각이 든 것 같다. 가장 먼저 하고싶던 일은 블로그를 대대적으로 손보는 것이었다. 다른것보다 블로그가 너무 느렸다. 마침 이제 한국에서 관리하던 서비스도 다 정리하고, 굳이 GCP의 인스턴스가 필요하지 않게 되었다. 오랜만에 서버를 만졌다.
GCP, 그리고 맞지 않는 옷
사실 구글 클라우드(GCP)를 쓴다는 건 나에게 있어 일종의 ‘엔지니어로서의 자존심’ 같은 거였다. 마치 음악을 제대로 하지도 않으면서 고가의 신디사이저를 질러놓고 뿌듯해하는 심리랄까. “언젠가 트래픽이 터지면 오토스케일링 해야지”, “Cloud Run으로 최신 아키텍처를 써봐야지” 하는 막연한 기대감. 하지만 현실은 트래픽은 고요한데 비용만 매달 8만 원씩 꼬박꼬박 나가고 있었다.
상세 내역을 뜯어보니 기가 찼다. 나는 e2-small 인스턴스를 쓰고 있었다. 이건 CPU를 공유하는 모델이라 조금만 부하가 걸려도 구글이 강제로 성능을 깎아버린다. 1TB나 잡아놓은 디스크 용량은 텅텅 비어있었고, 그 공기를 데우는 비용을 내가 내고 있었던 것이다.
결국 내가 진짜 원하는 게 뭐였을까? 거창한 인프라? 아니면 그냥 내 글을 끄적일 수 있는 안정적이고 가성비 좋은 공간? 어쩌면 나는 내 상황에 맞지 않는, 너무 큰 옷을 입고 있었던 건 아닐까. 그래서 결정했다. 복잡한 GCP를 떠나 AWS Lightsail로 가자. 월 $5의 고정 비용, 이 깔끔함이 지금 나에게 딱 필요한 모듈이었다.
(3개월은 무료라니 거참.. 이걸 진작할껄..)
Bitnami, 과거 유산과의 조우
기본적으로 AWS Lightsail은 bitnami를 사용해서 각종 인스턴스 환경을 자동으로 구축하고 배포하는 시스템이다. 뭐 이거야 GCP도 비슷하게 있으니깐. 솔직히 말해서 bitnami이거 내생각엔 10년도 넘은 것 같은데, 그나마 php 8 등 계속해서 업데이트 하는 인프라인 것에 감사해야 한다고 해야할까. 개인적인 느낌인데, AWS던 GCP던 서버 가상화나 kubernetes등의 컨테이너화가 대충 2015~2020년에 다 마무리되고 최근에는 다 ML쪽 인스턴스로 집중하는 느낌이랄까. 다른건 다 그냥 왠지모르게 레거시다. php도 레거시고 bitnami도 레거시고.. Redmine 이건 내가 2011년에 쓰던 툴인데 이런거 있는거 보면 진짜 ㅎㅎ
하기사 요즘은 no-code로 firebase studio같은데서 바이브 코딩으로 cloud run까지 한방에 배포하는 시대인데 이제 더이상 웹프레임워크가 뭐가 중요할까. gemini cli나 claude code한테 웹 어플리케이션 개발 시키면 vite나 react로 tailwind써다가 알아서 숙숙 만드는데, 그럴 때일수록 이젠 저런 ‘짜임새 있는’ 프레임워크는 더 이상 개발자나 운영자가 이해할 필요는 없다는 생각이 든다.
이사짐 싸기, 그리고 페이월(Paywall)의 벽
호기롭게 인스턴스를 파고 데이터를 옮기려는데, 95GB나 되는 데이터 용량이 발목을 잡았다. 확인해보니 워프 루트폴더 안에 예전 백업 파일들이 2중, 3중으로 똬리를 틀고 있었다. 어떻게보면 당연하지. 10년 넘게 워드프레스 백업 복원을 오고가면서 파일들을 정리할 생각조차 안했는걸. 과감하게 rm -rf를 날리고 3.5GB로 압축했다.
그런데 여기서 문제가 생겼다. 제미나이가 추천해준 All-in-One WP Migration 플러그인으로 백업을 GCP 에서 하고 (.wpress 확장자로 나옴) lightsail 인스턴스에서 복구를 시도하니 “이 기능은 유료 확장팩이 필요합니다”라며 결제 창을 띄우는 게 아닌가. 와.. 이럴꺼면 아니 플러그인 설치할때 알려주던가. 기껏 용량을 줄여서 SFTP로 직접 파일까지 옮겼는데, 리스토어 버튼 하나 누르는 데 돈을 내라니. 참 머리가 띵 했다.
결국 엔지니어로서의 오기가 발동했다. 플러그인 UI에 의존하는 것을 포기하고, wpress-extractor라는 툴을 구해 터미널에서 직접 압축을 풀었다. 근데 이것도 제대로 안되서 그냥 파일 옮기고 DB는 CLI로 직접 밀어 넣었다. 어쩌면 GUI 뒤에 숨겨진 상술을 기술로 뚫어내는 과정, 이게 진짜 개발자가 하는 일이 아닐까 하는 생각이 들었다. gemini yolo로 해서 저 All-in-One WP Migration 페이월 뜯어내라고 했는데 잘 못하더라. 느낌이지만 백엔드 일부분 코드를 특정 서버를 통해서만 받아오는 느낌이었다. 여튼 복구는 완료.
무한 리다이렉트와 레거시의 역습
그렇게 접속이 되나 싶더니 이번엔 ERR_TOO_MANY_REDIRECTS가 뜨며 사이트가 먹통이 되었다. 개인적으로 모든 서비스마다 Cloudflare를 사용해서 HTTPS를 강제하는데, 서버(Apache)는 HTTP로 들어왔다며 다시 튕겨내는 무한 핑퐁. 오랜만에 겪는 문제였다. 문제는 DB단에서 URL에 www가 빠진거로 되어 있는데 cloudflare는 www를 붙여서 redirect해서 생기는 문제였다. 도메인을 www.matthew.kr 로 통일하고, DB에 박혀있던 수천 개의 http 링크들도 wp search-replace 명령어로 싹 https로 치환했다. 에러를 뿜던 구형 플러그인들은 다 쳐내고, 꼭 필요한 것들만 남겼다.
하지만 산 넘어 산이라고, 이번엔 PHP 8.0 환경이 문제였다. GCP 시절 쓰던 오래된 플러그인들이 최신 PHP 문법을 견디지 못하고 ‘치명적인 오류’를 뿜으며 사망했다. 솔직히 이건 웹에서 정말 매번 겪는 문제. 근데 더 솔직히 말해서 더이상 삽질하고 싶지도 않았다. 그냥 에러 다 싹 긁어다 Gemini한테 고치라고 시켰고, gemini는 알아서 wp-cli 명령어 알아서 만들어주고, deactivate 시켜줬다. 아 진짜 예전에 서버 이관하며 라이브러리 버전 올리면서 삽질하는거 다 필요없구나.. 솔직히 이 과정에서 좀 희열을 느꼈다. (다신 하고싶지 않지만.)
Comfort Zone을 정리하며
결국 이번 마이그레이션은 단순히 비용을 8만 원에서 $12로 줄인 것 이상의 의미가 있었다. 무턱대고 좋다는 툴(GCP)을 쓰는 게 아니라, 내 상황에 맞는 최적의 툴(Lightsail)을 선택하고, 레거시를 털어내고, 시스템의 구조를 깊이 있게 이해하는 과정이었다.
여하튼 긴 삽질을 통해 서버가 아주 쾌적해졌다. 참 삶이란 게 그렇다. 막상 뜯어보기 전에는 알 수 없는 것 같다. 이제 비용 걱정도 없고, 더 마음을 졸여야 할 에러도 없는 시점에서 어쩌면 점차 나태해질 수 있는 블로깅 라이프를 다시 끌어올리려고 하는, 일련의 필요한 과정들이 아니었을까. 어쨌건 중요한 것은, 환경을 탓하지 않고 내 손으로 해결해 나가는 것이다. 이제 쾌적해진 새 보금자리에서, 다시 글쓰기에 집중해야겠다.
