결론 부터 말씀드리면 커스터마이징의 한계 때문에 티스토리를 떠난 내가, 이번엔 국내 공유호스팅(카페24·가비아)이 아니라 해외 VPS인 Vultr를 골랐다. 이유는 하나로 압축된다 — 내가 원한 건 서버를 통째로 통제하는 것이었고, 그건 공유호스팅으로는 애초에 안 되는 일이었다. 국내에도 VPS·클라우드가 있지만, 시간당 과금·투명한 요금·서울 … 더 읽기
결론부터 말씀드리면 티스토리에서 Vultr에 직접 구축한 워드프레스로 블로그를 옮겼다. 데이터가 적어서 수동 복붙으로 이전했고, 그건 의외로 깔끔했다. 커스터마이징 자유와 데이터 소유권은 확실히 만족스럽다. 다만 솔직히 말하면 좋기만 하진 않았다 — 월 약 $6의 비용과 관리 부담이 새로 생겼고, 다음(Daum) 검색 … 더 읽기
10편에서 매일 자동 백업을 세웠다. 그런데 마지막에 정직하게 인정한 한계가 있었다. 그 백업은 전부 같은 서버 안에 있다는 것. 서버가 통째로 죽으면 백업도 함께 사라진다. 이번 편은 그 절반을 마저 채운다. 백업을 rclone으로 Cloudflare R2에 자동으로 올려서, 서버가 죽어도 백업은 … 더 읽기
지난 세 편으로 사이트를 빠르게 만들었다. 이제 방향을 바꾼다. 안정성이다. 티스토리를 쓸 때는 백업을 신경 쓴 적이 없었다. 플랫폼이 알아서 해줬으니까. 하지만 서버를 직접 빌린 순간부터, 백업은 온전히 내 몫이다. 서버가 한 번 죽으면 그동안 쓴 글과 설정이 통째로 사라진다. … 더 읽기
7편은 캐시로, 8편은 이미지로 속도를 잡았다. 이번 편은 서버 안쪽 — OPcache, PHP-FPM 워커 수, MariaDB 버퍼풀을 손볼 차례였다. 검색하면 “이 설정 복붙하면 빨라진다”는 글이 넘친다. 나도 그 값들을 그대로 넣고 before/after를 쟀다. 그리고 결론은 예상과 정반대였다. 튜닝했는데 안 빨라졌다. … 더 읽기
7편에서 FastCGI 캐시로 서버가 페이지를 내주는 시간을 잡았습니다. 하지만 방문자 브라우저가 실제로 낑낑대며 내려받는 건 대개 글자가 아니라 이미지입니다. 이번 편에서는 같은 서버에서 이미지 용량 자체를 줄입니다. 방법은 1편과 같습니다. 플러그인은 설치하지 않고, 심지어 글의 HTML도 한 글자 고치지 않습니다. … 더 읽기
6편에서 SSL을 붙여 주소창의 자물쇠까지 채웠습니다. 이제 사이트는 안전합니다. 그런데 빠른 건 아니었습니다. 워드프레스는 방문자가 페이지를 열 때마다 PHP를 돌리고 데이터베이스에 몇 번씩 질문을 던져 HTML을 새로 조립합니다. 방문자가 늘면 이 조립 작업이 그대로 서버 부하가 되고, 느려지고, 이탈로 이어집니다. … 더 읽기
3편에서 500 오류를 잡고 사이트가 IP로 떴습니다. 여기서 바로 도메인 연결로 넘어가고 싶은 마음을 한 번만 눌러주세요. 서버는 켜진 순간부터 공격받고 있습니다. 비유가 아니라 사실입니다. 제 서버를 만든 지 하루도 안 돼서 로그를 봤더니 이랬습니다. 세 자리 숫자가 나왔습니다. 아무한테도 … 더 읽기
2편에서 LEMP를 올리고 phpinfo까지 확인했습니다. 그다음 워드프레스 파일을 풀고, wp-config.php에 DB 정보와 보안 키를 채워 넣고, 설레는 마음으로 브라우저를 켰습니다. 그리고 이 화면을 봤습니다. “페이지가 작동하지 않습니다. HTTP ERROR 500.” 끝입니다. 힌트가 없어요. 이럴 때 대부분은 구글에 “워드프레스 500 에러”를 … 더 읽기
1편에서 티스토리를 떠나 서버를 직접 빌린 이유를 적었습니다. 이번 편은 그 다음 이야기입니다. 결제만 끝난 텅 빈 우분투 한 대에 SSH로 들어가서, 웹서버·데이터베이스·PHP를 손으로 올리고, 브라우저에서 PHP가 도는 걸 확인하는 데까지. 관리형 호스팅도, 원클릭 설치 이미지도 쓰지 않았습니다. 명령어는 전부 … 더 읽기