결론 부터 말씀드리면 커스터마이징의 한계 때문에 티스토리를 떠난 내가, 이번엔 국내 공유호스팅(카페24·가비아)이 아니라 해외 VPS인 Vultr를 골랐다. 이유는 하나로 압축된다 — 내가 원한 건 서버를 통째로 통제하는 것이었고, 그건 공유호스팅으로는 애초에 안 되는 일이었다. 국내에도 VPS·클라우드가 있지만, 시간당 과금·투명한 요금·서울 … 더 읽기
결론부터 말씀드리면 티스토리에서 Vultr에 직접 구축한 워드프레스로 블로그를 옮겼다. 데이터가 적어서 수동 복붙으로 이전했고, 그건 의외로 깔끔했다. 커스터마이징 자유와 데이터 소유권은 확실히 만족스럽다. 다만 솔직히 말하면 좋기만 하진 않았다 — 월 약 $6의 비용과 관리 부담이 새로 생겼고, 다음(Daum) 검색 … 더 읽기
서버가 죽어 있으면 큰일이라 외부 업타임 모니터링을 붙였다. 서버 바깥에서 1분마다 ddlabx.com을 두드려보고, 페이지에서 특정 키워드가 사라지면 디스코드로 즉시 알려주는 구조다. 흔히 쓰는 UptimeRobot 무료는 상업용 사이트를 금지해서 피했고, 무료·상업용 허용에 1분 감지가 되는 HetrixTools를 골랐다. 그런데 키워드를 DDlabx(마지막 x를 … 더 읽기
10편에서 매일 자동 백업을 세웠다. 그런데 마지막에 정직하게 인정한 한계가 있었다. 그 백업은 전부 같은 서버 안에 있다는 것. 서버가 통째로 죽으면 백업도 함께 사라진다. 이번 편은 그 절반을 마저 채운다. 백업을 rclone으로 Cloudflare R2에 자동으로 올려서, 서버가 죽어도 백업은 … 더 읽기
지난 세 편으로 사이트를 빠르게 만들었다. 이제 방향을 바꾼다. 안정성이다. 티스토리를 쓸 때는 백업을 신경 쓴 적이 없었다. 플랫폼이 알아서 해줬으니까. 하지만 서버를 직접 빌린 순간부터, 백업은 온전히 내 몫이다. 서버가 한 번 죽으면 그동안 쓴 글과 설정이 통째로 사라진다. … 더 읽기
7편은 캐시로, 8편은 이미지로 속도를 잡았다. 이번 편은 서버 안쪽 — OPcache, PHP-FPM 워커 수, MariaDB 버퍼풀을 손볼 차례였다. 검색하면 “이 설정 복붙하면 빨라진다”는 글이 넘친다. 나도 그 값들을 그대로 넣고 before/after를 쟀다. 그리고 결론은 예상과 정반대였다. 튜닝했는데 안 빨라졌다. … 더 읽기
7편에서 FastCGI 캐시를 붙였고, 이번엔 글을 발행할 때마다 캐시를 자동으로 비우는 “자동 퍼지”를 붙이려 했다. Nginx Helper 플러그인만 깔면 5분이면 끝날 줄 알았다. 결론부터 말하면 반나절을 썼다. 권한을 의심하고, 경로를 의심하고, 해시를 손으로 계산하고, 급기야 플러그인 소스 코드까지 열어봤다. 그리고 … 더 읽기
7편에서 FastCGI 캐시로 서버가 페이지를 내주는 시간을 잡았습니다. 하지만 방문자 브라우저가 실제로 낑낑대며 내려받는 건 대개 글자가 아니라 이미지입니다. 이번 편에서는 같은 서버에서 이미지 용량 자체를 줄입니다. 방법은 1편과 같습니다. 플러그인은 설치하지 않고, 심지어 글의 HTML도 한 글자 고치지 않습니다. … 더 읽기
6편에서 SSL을 붙여 주소창의 자물쇠까지 채웠습니다. 이제 사이트는 안전합니다. 그런데 빠른 건 아니었습니다. 워드프레스는 방문자가 페이지를 열 때마다 PHP를 돌리고 데이터베이스에 몇 번씩 질문을 던져 HTML을 새로 조립합니다. 방문자가 늘면 이 조립 작업이 그대로 서버 부하가 되고, 느려지고, 이탈로 이어집니다. … 더 읽기
5편에서 도메인이 붙었습니다. 그런데 주소창을 보면 ddlabx.com 옆에 “주의 요함”이 붙어 있죠. 크롬이 방문자에게 “이 사이트 안전하지 않다”고 말하고 있는 겁니다. 애드센스를 노리는 블로그에 이건 치명적입니다. 이번 편에서 없앱니다. 명령어 한 줄이면 됩니다. 진짜 어려운 건 발급이 아니라 90일마다 돌아오는 … 더 읽기