GitHub Actions로 Playwright를 매일 자동 실행하는 방법|schedule(cron) 완전 가이드

GitHub Actions에서 Playwright를 실행하는 글 대부분은 「코드를 push하면 실행한다」는 push/pull_request 트리거를 다룹니다. 하지만 실무에서는 「매일 정해진 시각에 프로덕션 환경의 상태를 점검하고 싶다」 「야간에 회귀 테스트를 돌려두고 싶다」는 요구도 적지 않습니다. 이 글에서는 GitHub Actions의 schedule(cron) 트리거를 사용해 Playwright를 매일 자동 실행하는 방법을, 알림 설정・프로덕션 테스트 시 주의점과 함께 소개합니다.

push/PR 트리거와 schedule(매일 실행) 트리거는 비슷해 보여도 운용 방식이 다릅니다. 무인으로 실행되는 것을 전제로 하기 때문에 신경 써야 할 포인트가 있습니다.

📌 이런 분께 추천합니다

  • Playwright 테스트를 push/PR 시점뿐 아니라 정기적으로도 실행하고 싶은 분
  • 프로덕션 환경의 상태를 매일 아침 자동으로 점검하는 체계를 만들고 싶은 분
  • 테스트 실패 시 Slack 등으로 자동 알림을 받고 싶은 분
  • 무인 실행 특유의 Flaky Test 대응에 고민이 있는 분

✅ 이 글을 읽으면 얻을 수 있는 것

  • GitHub Actions의 cron 문법과 타임존 관련 주의점을 알 수 있다
  • 실패 시 Slack 알림을 보내는 설정을 구현할 수 있다
  • 프로덕션 환경을 안전하게 테스트하는 사고방식을 알 수 있다

👤 이 글을 쓴 사람

QA 엔지니어·테스트 자동화 엔지니어로 15년 이상의 실무 경험을 가진 Yoshi가 작성했습니다. Playwright × GitHub Actions를 활용한 정기 모니터링·회귀 테스트 체계를 여러 프로젝트에서 구축해 왔습니다.

📌 결론

  • GitHub Actions의 schedule 트리거는 UTC 기준으로 동작하므로, 현지 시간과의 시차 변환을 잊지 말고 설정해야 한다
  • 실패를 사람이 알아차릴 수 있는 체계(Slack 알림 등)와 함께 도입하지 않으면 정기 실행의 의미가 옅어진다
  • 프로덕션 환경을 테스트할 때는 읽기 전용 조작으로 범위를 좁히는 등 안전 설계가 필수다

push/PR 트리거의 CI는 「코드 변경을 검증하는」 것이 목적이지만, 매일 실행되는 스케줄형 테스트는 목적이 다릅니다.

  • 코드는 바뀌지 않았더라도, 외부 API나 인프라 측 변화로 프로덕션 환경이 망가지지 않았는지 확인하고 싶다
  • 야간처럼 트래픽이 적은 시간대에 시간이 오래 걸리는 회귀 테스트를 돌리고 싶다
  • 아무도 PR을 보지 않는 시간대에 실패하더라도, 나중에 알아차릴 수 있게 하고 싶다

이 글에서는 이러한 요구에 대응하기 위한 구현 포인트를 순서대로 소개합니다.

① schedule(cron) 트리거의 기본

GitHub Actions에서는 on.schedule에 cron 문법을 지정함으로써 정해진 시각에 워크플로우를 자동 실행할 수 있습니다.

# .github/workflows/daily-playwright.yml
name: Daily Playwright Tests

on:
  schedule:
    - cron: "0 0 * * *"  # 매일 UTC 0:00에 실행

jobs:
  test:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: |
          pip install -r requirements.txt --break-system-packages
          playwright install --with-deps

      - name: Run Playwright tests
        run: pytest tests/ --alluredir=allure-results

      - name: Upload results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: allure-results
          path: allure-results/
⚠️ 주의:cron은 UTC 기준
GitHub Actions의 schedule은 UTC(협정 세계시)로 평가됩니다. 한국 시간(KST)으로 「매일 아침 9시에 실행하고 싶다」면, UTC 0:00(0 0 * * *)을 지정해야 합니다. KST는 UTC보다 9시간 빠르기 때문에, 변환을 잘못하면 의도하지 않은 시각에 실행되어 버립니다.
실행하고 싶은 KST 시각→대응하는 UTC cron
매일 아침 9:00→0 0 * * *
매일 새벽 3:00→0 18 * * *(전날 18:00 UTC)
평일에만 아침 9:00→0 0 * * 1-5
💡 실무 팁:GitHub Actions의 스케줄 실행은 시스템 부하가 높은 시간대에 수 분~십수 분 정도 지연될 수 있다고 공식적으로 안내하고 있습니다. 「반드시 그 시각 정각에 실행된다」는 전제로 설계하지 말고, 약간의 지연이 발생해도 문제없는 형태로 운용하세요.

② workflow_dispatch를 병용해 수동 실행도 가능하게 하기

스케줄 실행만으로는 「지금 바로 결과를 확인하고 싶다」는 상황에서 다음 실행 시각까지 기다려야 합니다. workflow_dispatch를 병용하면 GitHub UI에서 수동으로도 같은 워크플로우를 실행할 수 있게 됩니다.

on:
  schedule:
    - cron: "0 0 * * *"
  workflow_dispatch:  # ← 수동 실행 버튼이 추가된다
🔍 실무 경험담:스케줄 실행만 있는 워크플로우라면, 「어젯밤 테스트가 실패했으니 수정 후 바로 확인하고 싶다」는 상황에서 다음 날까지 기다릴 수밖에 없습니다. workflow_dispatch를 병용해두는 것만으로 이런 답답함을 대부분 해소할 수 있습니다.

③ 실패 시 Slack 알림 보내기

매일 실행되는 테스트는 push/PR 트리거와 달리 아무도 결과를 보러 가지 않는 경우가 많습니다. 실패했을 때 자동으로 알림이 오는 체계가 없으면 정기 실행의 의미가 옅어지고 맙니다.

jobs:
  test:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # ... 설정・테스트 실행 단계 ...

      - name: Run Playwright tests
        id: run_tests
        run: pytest tests/

      - name: Notify Slack on failure
        if: failure()
        run: |
          curl -X POST -H 'Content-type: application/json' \
            --data "{\"text\":\"❌ Daily Playwright tests failed. Run: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}\"}" \
            "${{ secrets.SLACK_WEBHOOK_URL }}"
⚠️ 주의:SLACK_WEBHOOK_URL과 같은 민감 정보는 워크플로우 파일에 직접 작성하지 말고, 반드시 GitHub Secrets에 등록해 secrets.를 통해 참조하세요. 실수로 리포지토리에 커밋해버리는 위험을 피할 수 있습니다.

④ 프로덕션 환경을 테스트할 때의 주의점

「매일 실행」의 목적 중 하나가 프로덕션 환경 모니터링이라면, 테스트 대상은 실제 사용자가 이용하는 서비스가 됩니다. 스테이징 환경과는 다른 주의가 필요합니다.

관점대응 방침
파괴적 조작을 피한다주문 확정・탈퇴 처리 등 실제 데이터에 영향을 주는 조작은 테스트 대상에서 제외하거나, 전용 테스트 계정 안에서만 완결시킨다
전용 테스트 계정을 준비한다실제 고객 데이터와 섞이지 않도록 모니터링 전용 테스트 계정・테스트 데이터를 분리한다
실행 빈도를 제한한다프로덕션 환경에 대한 부하와 GitHub Actions 실행 시간(무료 한도)을 고려해, 필요 이상으로 높은 빈도로 실행하지 않는다
민감 정보를 관리한다프로덕션 인증 정보는 GitHub Secrets로 관리하고, 로그에 출력되지 않도록 주의한다
💡 실무 팁:프로덕션 모니터링이 목적이라면 모든 기능을 테스트할 필요는 없습니다. 「로그인할 수 있다」 「홈페이지가 표시된다」 「결제 페이지가 열린다」처럼 서비스 전체에 영향을 주는 핵심 경로에 한정한 스모크 테스트로 만들면 리스크와 실행 시간을 모두 줄일 수 있습니다.

⑤ 무인 실행 특유의 Flaky Test 대응

push/PR 트리거라면 테스트가 실패했을 때 바로 재실행 버튼을 누를 수 있지만, 야간 스케줄 실행에서는 사람이 즉시 대응할 수 없습니다. 무인 실행에서는 Flaky Test로 인한 오탐이 아침 알림에 대한 신뢰도를 떨어뜨립니다.

- name: Run Playwright tests with retry
  run: pytest tests/ --reruns 2 --reruns-delay 3
⚠️ 주의:--reruns는 pytest-rerunfailures 플러그인이 제공하는 옵션으로, pytest 표준 기능이 아닙니다. 사용하려면 pip install pytest-rerunfailures가 필요합니다. 또한 리트라이는 근본 원인을 감추는 응급처치이므로, 자주 리트라이로 통과하는 테스트는 별도로 원인을 조사하는 것을 권장합니다.
🔍 실무 경험담:무인 실행의 Flaky Test를 방치하면 「또 그거겠지」라며 아침 알림이 점차 무시되게 됩니다. 이런 상태가 되면 정말 중대한 장애가 발생했을 때 감지가 늦어지는 원인이 되므로, Flaky Test 해소는 모니터링 체계 자체의 신뢰성과 직결됩니다.

실무에서 자주 발생하는 실수

① UTC와 현지 시간을 혼동해 의도하지 않은 시각에 실행된다

「매일 아침 9시에 실행하고 싶으니까」라며 cron: "0 9 * * *"라고 작성하면, 실제로는 UTC 9:00=KST 18:00에 실행되어 버립니다. cron 설정 후에는 실제 실행 로그의 타임스탬프로 의도한 시각이 맞는지 확인하세요.

② 실행 빈도가 너무 높아 Actions 무료 한도를 압박한다

「혹시 몰라서 1시간마다 실행」처럼 높은 빈도로 설정하면, GitHub Actions의 무료 이용 한도(플랜에 따라 다름)를 금방 소진해버릴 수 있습니다. 정말 그 빈도가 필요한지 목적으로 돌아가 검토하세요.

③ 알림 체계가 없어 실패를 며칠씩 알아차리지 못한다

스케줄 실행을 설정한 것만으로 만족해버리고, 알림 설정을 뒤로 미루는 경우입니다. GitHub Actions 탭을 매일 스스로 확인하는 운용은 오래가지 않으므로, Slack 알림 등은 초기 단계부터 함께 구축해두는 것을 추천합니다.

④ 리포지토리가 오래 업데이트되지 않아 스케줄 실행이 중단된다

GitHub Actions의 schedule은 기본 브랜치에 장기간 업데이트가 없는 리포지토리에서는 자동으로 비활성화되는 사양이 있습니다. 코드를 오랫동안 변경하지 않는 모니터링 전용 리포지토리의 경우, 이 동작으로 인해 자신도 모르는 사이에 모니터링이 멈춰 있을 수 있으므로 최신 조건은 GitHub 공식 문서에서 확인해두세요.

FAQ

Q. GitHub Actions의 무료 한도로도 매일 실행할 수 있나요?

플랜과 리포지토리 공개 설정(퍼블릭/프라이빗)에 따라 무료 한도의 실행 시간이 다릅니다. 하루 1회・수 분 정도의 테스트라면 대부분 무료 한도 안에 들어오지만, 테스트 수나 실행 빈도가 늘어나면 초과할 수 있으므로 GitHub 공식 요금 페이지에서 최신 한도를 확인하는 것을 추천합니다.

Q. cron의 실행 시각은 얼마나 정확한가요?

GitHub Actions의 스케줄 실행은 시스템 혼잡 상황에 따라 수 분~십수 분 정도 지연될 수 있다고 공식적으로 안내하고 있습니다. 초 단위의 정확성이 요구되는 용도에는 적합하지 않습니다.

Q. Slack 이외의 알림 방법도 있나요?

Slack 외에도 Discord・이메일(GitHub Actions의 알림 설정)・Microsoft Teams 등 Webhook을 지원하는 서비스라면 같은 방식으로 알림을 보낼 수 있습니다. 기본 원리는 「실패 시 HTTP 요청을 보낸다」는 점에서 공통입니다.

Q. push/PR 트리거와 schedule(매일 실행) 트리거를 같은 워크플로우 파일에서 병용할 수 있나요?

병용할 수 있습니다. on 아래에 push・pull_request・schedule・workflow_dispatch를 나란히 작성하면 각 조건에서 같은 워크플로우가 실행됩니다. 다만 테스트 내용이나 프로덕션/스테이징 대상을 조건에 따라 분기하고 싶다면, 워크플로우를 나누는 편이 관리하기 쉬운 경우도 있습니다.

Q. 프로덕션 환경에서 주문이나 결제 같은 중요한 기능을 확인하고 싶다면 어떻게 해야 하나요?

샌드박스 환경이 준비된 결제 서비스(테스트 모드 카드 번호 등)를 활용해, 실제 청구가 발생하지 않는 형태로 테스트하는 것이 기본입니다. 샌드박스가 없는 경우, 결제 확인 화면 직전까지 진행해 표시 내용을 확인하는 등 실제 데이터에 영향이 가지 않는 범위로 테스트를 제한하는 판단도 필요합니다.

📋 정리

  • schedule(cron) 트리거는 UTC 기준으로 동작하므로 현지 시간과의 시차 변환을 반드시 확인한다
  • workflow_dispatch를 병용하면 스케줄 실행과 수동 실행 양쪽 모두에 대응할 수 있다
  • 실패 알림(Slack 등)과 함께 도입하지 않으면 정기 실행의 효과가 발휘되지 않는다
  • 프로덕션 환경 테스트는 파괴적 조작을 피하고, 전용 계정・한정된 범위로 안전하게 설계한다

매일 실행 체계는 한 번 만들어두면 「모르는 사이에 망가져 있었다」를 막아주는 강력한 안전망이 됩니다. 먼저 핵심 경로에 한정한 스모크 테스트부터 시작해서, 알림 체계와 함께 운용에 올려보세요.

제목과 URL을 복사했습니다