WordPress 홈페이지를 정적으로 바꾸고 GitHub → Xserver 자동 배포로 전환한 이유

2026년 9월, 저는 criver.site의 홈페이지를 WordPress에서 분리했습니다. WordPress를 버린 것은 아닙니다. 글을 관리하는 CMS로는 계속 사용하고, 홈페이지만 정적 HTML/CSS/JavaScript로 바꿔 GitHub에서 Xserver로 자동 배포하도록 구성했습니다.

이유는 간단했습니다. 게임과 작은 웹앱이 늘어나면서 사이트 입구, 블로그, 실제 작품이 모두 같은 WordPress 구조에 묶여 있을 필요가 없다고 느꼈기 때문입니다.

변경 전의 문제

모든 것을 WordPress에 넣어두면 테마나 플러그인 변경이 홈페이지까지 영향을 줄 수 있습니다. 더 기본적인 문제도 있었습니다. GitHub에 push했다고 해서 실제 사이트가 자동으로 바뀌는 것은 아니었습니다. FileZilla로 수동 업로드하던 시기에는 GitHub는 최신인데 운영 서버는 예전 파일인 경우도 있었습니다.

현재 구조

  • 홈페이지: 정적 HTML/CSS/JavaScript
  • 소스 관리: GitHub
  • 배포: GitHub Actions → Xserver
  • 글: WordPress
  • 게임/웹앱: WordPress와 독립

가장 큰 교훈: push와 deploy는 다르다

Git을 처음 쓸 때는 “GitHub에 push 완료”를 거의 “사이트 업데이트 완료”처럼 생각했습니다. 하지만 ORA Quest 개발 중, 로컬과 GitHub의 JavaScript는 수정됐는데 운영 환경은 여전히 예전 파일을 쓰는 일을 겪었습니다.

그 뒤부터는 실제 운영 URL을 확인하는 단계까지를 배포로 생각합니다.

자동화해도 실패는 생긴다

FTPS 호스트를 잘못 설정해 SSL 연결 오류가 난 적도 있고, 캐시 때문에 오래된 JavaScript가 계속 보인 적도 있습니다. 자동화의 장점은 오류가 사라지는 것이 아니라, 연결·전송·캐시·운영 확인 중 어디가 문제인지 찾기 쉬워진다는 점입니다.

역할을 분리하니 관리가 쉬워졌다

홈페이지는 이제 작품으로 안내하는 입구 역할에 집중합니다. 예를 들어 ORA Quest와 1분 기억 게임 Oboete Iruka?가 있습니다. WordPress는 제작 과정과 실패, 개선을 기록하는 역할을 맡습니다.

저에게 맞는 답은 “전부 WordPress”도 “WordPress를 전부 버리기”도 아니었습니다. 둘을 나누어 쓰는 방식이 훨씬 잘 맞았습니다.

コメント