매주 수작업으로 데이터를 갱신하고 워드프레스에 업로드하는 작업, 한두 번은 괜찮지만 사이트가 늘어나면 감당이 안 됩니다. 크론잡을 서버에 직접 걸자니 VPS가 없는 경우가 많고, 그렇다고 손으로 매번 업데이트하자니 비효율적입니다. 이번 글에서는 깃허브 액션으로 데이터를 자동 갱신하고, FTP로 워드프레스까지 배포하는 구조를 정리합니다.
핵심만 먼저 말하면, 깃허브 액션의 스케줄 트리거로 파이썬 스크립트를 주기 실행하고, FTP 배포 액션으로 그 결과물을 워드프레스 호스팅에 자동 업로드하면 됩니다. VPS 없이도 완전 자동화가 가능합니다.
전체 구조 이해하기
간단하게 말해서는 github action 기능을 사용해서 자동화해서 워드프레스에 FTP를 통해 배포하는 기능입니다. 그러기 위해서는 간단하게 자동화를 돌릴 workflow 스크립트가 필요하고요, FTP를 사용할 secret key가 필요합니다.
구조 자체는 단순합니다. 크게 두 단계로만 나뉩니다. 하나는 정해진 시간에 데이터를 새로 만드는 작업이고, 다른 하나는 그 결과물을 실제 서비스 서버로 옮기는 작업입니다.
실무에서 보면 많은 분들이 이 두 단계를 하나로 착각해서 헤맵니다. 깃허브 액션은 데이터를 생성하는 역할만 하고, 그 결과를 실제 사이트에 반영하는 건 별도의 배포 단계가 필요합니다. 이 둘을 분리해서 이해하면 이후 설정이 훨씬 수월해집니다.
1단계: 저장소와 스크립트 준비
먼저 깃허브에 저장소를 만들고, 정기적으로 실행할 스크립트를 넣습니다. 데이터를 수집하고 가공하는 로직은 파이썬이든 Node.js든 상관없지만, 결과물을 특정 경로의 JSON이나 정적 파일로 저장하도록 짜는 게 핵심입니다.
이건 직접 겪어보면 체감되는데, 처음부터 완벽한 파싱 로직을 짜려고 하면 진도가 안 나갑니다. 일단 파일을 덮어쓰는 구조부터 만들고, 실제 데이터 수집 로직은 나중에 고도화하는 순서로 접근하는 게 실전에서는 더 잘 먹힙니다.
- 저장소 생성 (Public 또는 Private)
- 데이터 생성 스크립트 작성 (예: crawler.py)
- 결과 파일이 저장될 폴더 구조 확정
- requirements.txt 등 의존성 파일 준비
2단계: 깃허브 액션 워크플로우 작성
가장 중요한 부분입니다. 워크플로우 파일은 반드시 저장소 루트가 아니라 .github/workflows/ 경로 안에 있어야 인식됩니다. 많이들 여기서 막히더라고요. 파일을 만들었는데 스케줄이 전혀 실행되지 않는다면 열에 아홉은 이 경로 문제입니다.
스케줄은 cron 표현식으로 지정합니다. 예를 들어 매주 월요일 한국시간 오전 9시에 실행하고 싶다면, 깃허브 액션 서버가 UTC 기준으로 동작하기 때문에 UTC 0시로 설정해야 합니다. 이 시차를 놓치면 원하는 시간과 다르게 실행되는 경우가 생깁니다.
실무 팁 — 스케줄만 걸어두면 실제로 잘 돌아가는지 매주 기다려야 해서 답답합니다. workflow_dispatch 트리거를 함께 넣어두면 깃허브 저장소 화면에서 버튼 클릭만으로 즉시 테스트할 수 있어 디버깅이 훨씬 빠릅니다.
여러 데이터를 동시에 갱신해야 한다면 매번 워크플로우 파일을 따로 만들 필요는 없습니다. matrix 전략을 쓰면 하나의 워크플로우로 여러 대상을 병렬 실행할 수 있어 관리 부담이 크게 줄어듭니다.
3단계: FTP 정보 등록
데이터 생성까지는 깃허브 안에서 끝나지만, 실제 워드프레스 사이트에 반영하려면 별도의 배포 단계가 필요합니다. VPS 환경이라면 서버에서 직접 git pull을 걸 수 있지만, 카페24나 가비아처럼 일반 호스팅을 쓴다면 FTP 배포 액션을 쓰는 편이 훨씬 접근성이 좋습니다.
FTP 서버 주소, 아이디, 비밀번호는 절대 워크플로우 파일에 직접 적으면 안 됩니다. 저장소의 Secrets 기능에 등록해서 워크플로우에서는 변수로만 참조하도록 구성해야 정보 노출 위험이 사라집니다.
Git Pull 방식 vs FTP 배포 방식 비교
| 구분 | Git Pull 방식 | FTP 배포 방식 |
|---|---|---|
| 필요 환경 | SSH 접속 가능한 VPS | 일반 공유 호스팅도 가능 |
| 설정 난이도 | 서버 접속, 크론탭 설정 필요 | 깃허브 액션 안에서 완결 |
| 실행 주체 | 서버가 직접 저장소를 당겨옴 | 깃허브가 서버로 파일을 밀어넣음 |
| 적합한 경우 | Vultr, AWS 등 VPS 사용자 | 카페24, 가비아 등 일반 호스팅 |
흔히 하는 실수
워크플로우 파일을 저장소 최상단에 만드는 경우가 가장 흔합니다. .github/workflows/ 경로가 아니면 깃허브는 아예 크론으로 인식하지 않기 때문에, 파일 자체는 존재해도 스케줄이 영원히 실행되지 않습니다.
또 하나는 FTP 배포 경로 문제입니다. 일부 호스팅은 서버 디렉토리 앞에 /www/나 /public_html/이 붙어야 하는데, 이걸 빼고 설정하면 배포 단계에서 경로를 찾지 못했다는 에러가 발생합니다. 액션은 성공했는데 실제 사이트는 그대로라면, 캐시 문제일 수도 있으니 CDN을 쓰는 경우 캐시 삭제도 함께 확인해야 합니다.
배포 전 체크리스트
- 워크플로우 파일이 .github/workflows/ 경로에 정확히 위치했는지 확인
- cron 시간이 UTC 기준으로 올바르게 환산됐는지 확인
- FTP 정보를 코드에 직접 적지 않고 Secrets로 등록했는지 확인
- server-dir 경로가 호스팅 구조와 일치하는지 확인
- workflow_dispatch로 수동 테스트를 먼저 진행했는지 확인
- 배포 후 사이트가 즉시 반영되지 않으면 캐시 여부 확인
지금 저장소의 Actions 탭에서 Run workflow 버튼으로 수동 실행부터 한 번 테스트해보시길 권합니다. 스케줄이 실제로 도는지 기다리기보다, 수동 실행으로 먼저 구조를 검증하는 게 훨씬 빠릅니다.
여러분은 자동화를 구축하면서 어떤 부분에서 가장 오래 막히셨나요? 워크플로우 경로 문제 말고도 겪었던 시행착오가 있다면 댓글로 공유해주시면 다른 분들께도 도움이 됩니다.
함께 보면 좋은 글: 깃허브 액션 시크릿 관리 시 고려해야 할 사항 정리, 워드프레스 FTP 자동 배포 오류 해결 가이드
본 포스팅은 정보 전달 목적이며, 실제 적용 시 발생하는 책임은 사용자에게 있습니다.