Blog

GitHub Actions, GitLab, Jenkins에서 자동화된 야간 API 테스트 설정 방법

API의 야간 빌드를 설정하세요. Apidog CLI를 사용하여 CI에서 자동화된 회귀 테스트를 예약하세요. GitHub Actions, GitLab, Jenkins cron 설정을 복사하여 붙여넣어 아침까지 실패를 포착하세요.

Ashley Innocent

Ashley Innocent

15 June 2026

GitHub Actions, GitLab, Jenkins에서 자동화된 야간 API 테스트 설정 방법

Apidog 엔터프라이즈

온프레미스 배포

SSO & RBAC

SOC 2 준수

Apidog Enterprise 살펴보기

API 테스트는 모든 풀 리퀘스트에서 통과합니다. 빌드는 초록색입니다. 배포합니다. 그러다 오전 9시에 다른 시간대의 누군가가 결제에서 500 에러가 발생한다고 보고하고, 아무도 결제 코드를 변경하지 않았습니다. 변경된 것은 타사 결제 샌드박스, 밤새 실행된 데이터베이스 마이그레이션, 또는 조용히 만료된 토큰이었습니다. 리포지토리 내에서 아무것도 변경되지 않았기 때문에 커밋별 테스트로는 이를 잡아내지 못했습니다.

이것이 야간 빌드가 메우는 격차입니다. 야간 빌드는 코드 변경 사항에 대해서만 실행되는 것이 아니라, 일반적으로 새벽에 실제 서비스 및 환경에 대해 하루에 한 번 실행되는 예약된 전체 테스트 실행입니다. 이는 커밋 사이에 존재하는 오류, 즉 데이터 드리프트, 불안정한 통합, 만료된 자격 증명, 느린 성능 저하, 그리고 제어할 수 없는 서비스에서 발생하는 계약 위반 등을 잡아냅니다. 특히 API의 경우, 야간 회귀 테스트 실행은 설정할 수 있는 가장 저렴한 조기 경보 시스템입니다.

이 가이드는 Apidog를 사용하여 해당 시스템을 처음부터 끝까지 구축하는 방법을 안내합니다. 회귀 테스트 스위트를 설계하고, Apidog CLI로 명령줄 실행을 생성하고, GitHub Actions, GitLab, Jenkins의 예약된 CI 작업에 연결하여 스탠드업 전에 보고서를 받아볼 수 있습니다. 야간 실행이 몇 시간 더 일찍 알려줬을 장애를 디버깅해본 적이 있다면, 이 워크플로우가 그 시간을 되찾아 줄 것입니다.

button

왜 커밋별 테스트만으로는 충분하지 않은가

지속적 통합(CI)은 모든 푸시에 대해 테스트하도록 훈련시켰습니다. 이는 좋은 방법이며 계속해야 합니다. 하지만 커밋별 테스트는 "이 변경 사항이 무언가를 망가뜨렸는가?"라는 좁은 질문에 답합니다. 이 테스트는 빠르게 자주 실행되며, 개발자가 막히지 않도록 범위가 제한됩니다. 바로 이 제한된 범위 때문에 특정 유형의 문제들을 놓치게 됩니다.

야간 빌드는 더 넓은 질문에 답합니다: "누군가가 건드렸는지 여부와 관계없이 지금 시스템은 여전히 건강한가?" 이 차이는 중요합니다. 왜냐하면 프로덕션 환경에는 커밋으로는 절대 볼 수 없는 움직이는 부분들이 있기 때문입니다.

따라서 패턴은 양자택일이 아닌 두 계층으로 구성됩니다. 빠른 스모크 테스트가 각 커밋을 보호합니다. 더 심층적인 회귀 테스트 스위트는 예약된 시간에 실행됩니다. 야간 계층은 너무 느리거나, 너무 광범위하거나, 실시간 환경에 너무 의존적이어서 내부 루프에 포함하기 어려운 모든 것을 배치하는 곳입니다.

야간 API 회귀 테스트 스위트에는 무엇이 포함되어야 하는가

무엇이든 예약하기 전에, 야간 실행이 실제로 무엇을 확인하는지 결정해야 합니다. 야간 스위트는 커밋 게이트 스모크 테스트보다 광범위하며, 빠른 상태 확인보다 더 철저합니다. 조용히 오류가 발생했을 때 당황하지 않도록 충분한 커버리지를 목표로 하십시오.

견고한 야간 API 스위트가 다루는 내용은 다음과 같습니다.

이러한 구조화된 케이스를 작성해 본 적이 없다면, API 테스트 케이스 템플릿 및 예제가 좋은 시작점이며, API 어설션은 응답 본문, 상태, 헤더 및 타이밍을 정확하게 검증하는 방법을 다룹니다.

1단계: Apidog에서 회귀 테스트 스위트 구축

Apidog는 테스트를 추가 기능이 아닌 API 수명 주기의 일등 시민으로 취급합니다. 엔드포인트를 설계한 다음, 이를 실제 워크플로우를 반영하는 테스트 시나리오로 연결합니다. 시나리오는 각 단계가 어설션을 포함한 API 요청이며, 데이터가 한 단계에서 다음 단계로 흐르는 순서가 지정된 단계 목록입니다.

다음은 결제 회귀 시나리오의 형태입니다.

  1. POST /auth/login: 자격 증명 전송, 200 확인, 응답에서 accessToken을 변수로 추출.
  2. POST /carts: 토큰을 사용하여 카트 생성, 201 확인, cartId 추출.
  3. POST /carts/{cartId}/items: 제품 추가, 200 확인, 응답 본문의 total이 예상 가격과 동일한지 확인.
  4. POST /checkout: 카트 제출, 200 확인, order.status가 "confirmed"인지 확인.
  5. GET /orders/{orderId}: 주문을 다시 읽어오고, 올바른 품목으로 지속되었는지 확인.

Apidog에서는 이를 시각적으로 구축합니다. 각 단계는 상용구 코드 작성 없이 어설션을 얻습니다: "응답 상태는 200" 또는 "JSONPath $.order.status는 confirmed와 같습니다"와 같은 시각적 어설션입니다. 스키마 준수를 위해 Apidog는 엔드포인트에 저장된 OpenAPI 정의에 대해 응답을 자동으로 검증할 수 있으므로, 모든 필드에 대한 검사를 수동으로 작성할 필요가 없습니다.

몇 가지 설계 규칙을 통해 야간 스위트의 유지보수성을 확보할 수 있습니다.

다른 도구에서 오셨다면, 이 내용은 익숙한 개념에 깔끔하게 매핑됩니다. 시나리오를 함께 연결하는 더 넓은 그림은 API 테스트 오케스트레이션 가이드에 있으며, Apidog에서 구조화된 테스트를 실행해 본 적이 없다면 Apidog로 API 테스트하는 방법이 단계별 시작점입니다. 더 읽기 전에 Apidog를 다운로드하여 하나의 시나리오를 구축하십시오. 이 가이드의 나머지 부분은 실행할 스위트가 있다고 가정합니다.

2단계: 명령줄에서 스위트 실행

야간 빌드는 무인으로 실행되므로, 헤드리스 러너가 필요합니다. 그것은 Apidog CLI로, 어떤 터미널에서든 GUI 없이 저장된 테스트 시나리오를 실행하는 npm 패키지입니다. 이는 CI/CD 파이프라인 내의 자동화된 실행을 위해 정확히 구축되었습니다.

전역으로 설치하십시오. CLI는 Node.js v16 이상이 필요합니다.

npm install -g apidog-cli

온라인 시나리오(Apidog 프로젝트에 있는 시나리오)를 실행하려면 두 가지가 필요합니다: 액세스 토큰과 시나리오 또는 스위트 ID. Apidog의 CI/CD 설정에서 "액세스 토큰 추가" 버튼을 통해 토큰을 생성하십시오. 이 토큰은 비밀번호처럼 취급해야 하며, 리포지토리가 아닌 비밀 저장소에 보관해야 합니다.

단일 테스트 시나리오를 실행하는 명령은 다음과 같습니다.

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t 123456 \
  -e 789 \
  -r cli,html \
  --out-dir ./apidog-reports

실제 Apidog CLI 옵션을 사용하여 플래그별 설명:

다른 플래그들도 야간 실행에 사용될 수 있습니다. -n, --iteration-count <n>은 불안정성을 드러내기 위해 실행을 반복합니다. -d, --iteration-data <path>는 CSV 또는 JSON 파일을 공급하여 하나의 시나리오가 여러 데이터 행에 걸쳐 실행되도록 합니다. 이는 경계 테스트에 완벽합니다. --env-var "key=value" 및 --global-var "key=value"는 런타임에 값을 주입하여 저장된 시나리오에서 자격 증명을 제외하는 방법입니다.

이것을 모두 외울 필요는 없습니다. Apidog가 정확한 명령을 생성해 줍니다: 클라이언트에서 CI/CD 패널을 열고, 시나리오 또는 스위트를 선택한 다음, 준비된 apidog run 라인을 파이프라인 설정에 바로 복사하십시오. 예약하기 전에 먼저 로컬에서 한 번 실행하여 초록색(성공)인지 확인하십시오.

3단계: 야간 빌드로 예약

야간 빌드는 타이머에 따라 실행되는 이 명령입니다. 모든 CI 플랫폼은 cron 구문을 통해 예약된 작업을 지원합니다. 패턴은 모두 동일합니다: 매일 트리거, 비밀 저장소의 액세스 토큰, CLI 실행, 그리고 아티팩트로 보관된 보고서입니다.

GitHub Actions

GitHub Actions는 표준 cron을 사용하는 schedule 트리거를 지원합니다. 이 워크플로우는 매일 UTC 02:00에 실행되며, workflow_dispatch를 통해 수동 실행 버튼도 제공합니다.

name: Nightly API Regression

on:
  schedule:
    - cron: '0 2 * * *'   # 02:00 UTC daily
  workflow_dispatch:        # allow manual runs

jobs:
  regression:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run nightly regression suite
        run: |
          apidog run \
            --access-token $APIDOG_ACCESS_TOKEN \
            --test-suite ${{ vars.APIDOG_SUITE_ID }} \
            -e ${{ vars.APIDOG_ENV_ID }} \
            -r cli,html \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: Upload HTML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-nightly-report
          path: ./apidog-reports

업로드 단계의 if: always()는 중요합니다. 실행이 실패하더라도 보고서가 보관되기를 원할 것입니다. 왜냐하면 실패했을 때야말로 보고서를 읽어야 할 때이기 때문입니다. GitHub의 예약된 작업은 UTC로 실행되며 피크 로드 시 지연될 수 있으므로, 정확히 정해진 시간에 실행되어야 하는 것은 예약하지 마십시오.

GitLab CI/CD

GitLab은 YAML 파일에서가 아니라 UI(CI/CD > Schedules)를 통해 파이프라인을 예약합니다. 그런 다음 규칙 조건에 따라 작업이 예약된 시간에만 실행되고 모든 푸시에는 실행되지 않도록 합니다.

nightly-regression:
  image: node:20
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  before_script:
    - npm install -g apidog-cli
  script:
    - apidog run
        --access-token "$APIDOG_ACCESS_TOKEN"
        --test-suite "$APIDOG_SUITE_ID"
        -e "$APIDOG_ENV_ID"
        -r cli,html
        --out-dir ./apidog-reports
  artifacts:
    when: always
    paths:
      - apidog-reports/
    expire_in: 30 days

APIDOG_ACCESS_TOKEN을 마스킹되고 보호된 CI/CD 변수로 설정한 다음, 0 2 * * *와 같은 cron 표현식으로 파이프라인 스케줄을 생성하십시오. rules 블록은 이 작업이 일반 커밋에서 실행되지 않도록 합니다.

Jenkins

Jenkins에서는 cron 트리거가 있는 pipeline이 동일한 작업을 수행합니다. 토큰을 자격 증명으로 저장하고 withCredentials로 가져오십시오.

pipeline {
    agent any
    triggers {
        cron('H 2 * * *')   // around 02:00, H spreads load
    }
    stages {
        stage('Install CLI') {
            steps { sh 'npm install -g apidog-cli' }
        }
        stage('Nightly regression') {
            steps {
                withCredentials([string(credentialsId: 'apidog-token',
                                        variable: 'APIDOG_ACCESS_TOKEN')]) {
                    sh '''
                        apidog run \
                          --access-token $APIDOG_ACCESS_TOKEN \
                          --test-suite $APIDOG_SUITE_ID \
                          -e $APIDOG_ENV_ID \
                          -r cli,html \
                          --out-dir ./apidog-reports
                    '''
                }
            }
        }
    }
    post {
        always {
            archiveArtifacts artifacts: 'apidog-reports/**', allowEmptyArchive: true
        }
    }
}

H 2 * * *의 H는 Jenkins의 유용한 기능입니다: 이는 시간 내에서 안정적인 분을 선택하여 모든 야간 작업이 정확히 02:00에 한꺼번에 몰리는 것을 방지합니다.

이 cron 필드는 세 플랫폼 모두에서 동일합니다. 0 2 * * *는 매일 0분 2시를 의미합니다. 문제를 더 빨리 발견하기 위해 밤에 두 번 실행하고 싶다면? 0 2,14 * * *. 주중에만 실행하려면? 0 2 * * 1-5. 스테이징 환경이 조용하고 외부 샌드박스가 활성화된 시간을 선택하십시오.

4단계: 실패를 무시할 수 없게 만들기

아무도 읽지 않는 로그에 실패하는 야간 실행은 야간 실행이 없는 것보다 더 나쁩니다. 그것은 잘못된 확신을 줍니다. 핵심은 알림입니다. 팀이 이미 확인하는 곳으로 결과를 연결하십시오.

CLI의 종료 코드가 연결 고리입니다. 시나리오가 실패하면 apidog run은 0이 아닌 값으로 종료되므로, CI는 자동으로 작업을 빨간색으로 표시합니다. 여기에서 다음을 수행합니다.

야간 빌드를 신뢰할 수 있게 유지하는 한 가지 원칙: 달리 증명될 때까지 실패를 실제 버그로 간주하십시오. 야간 스위트를 무력화하는 가장 빠른 방법은 불안정한 테스트로 인해 모든 사람이 빨간색(실패)을 무시하도록 훈련시키는 것입니다. 시나리오가 간헐적으로 실패한다면, 테스트 또는 환경을 수정하십시오. 무시하지 마십시오. 시나리오를 반복하기 위해 -n을 사용하여 실행하거나, 시나리오가 의존하는 데이터를 안정화하면 일반적으로 실제 불안정성을 드러낼 수 있습니다.

Apidog가 야간 패턴에 적합한 이유

야간 API 파이프라인을 별개의 부품들로 조립할 수 있습니다: 설계를 위한 도구 하나, 테스트 작성을 위한 또 다른 도구, 헤드리스로 실행하기 위한 세 번째 도구, 그리고 스키마 유효성 검사기가 추가될 수 있습니다. 많은 팀이 그렇게 운영하며, 각 부품이 동기화되지 않을 때까지는 잘 작동합니다. 마찰은 새벽 2시에 러너가 실행하는 테스트가 실제로 배포한 API와 더 이상 일치하지 않을 때 나타납니다.

Apidog는 이를 하나의 워크플로우로 통합합니다. 설계하는 엔드포인트, 테스트하는 시나리오, 유효성 검사하는 스키마, 그리고 예약하는 명령이 모두 동일한 진리의 원천을 참조합니다. 엔드포인트를 변경하면 시나리오와 스키마 검사도 함께 이동합니다. 내보내기 단계도, 조용히 오래되어 버리는 컬렉션도, 동기화해야 할 계약의 두 번째 사본도 없습니다. 실제 진리의 원천이 아닌 Postman 컬렉션의 고통을 겪어본 적이 있다면, 이러한 단일 소스 설계가 바로 그 차이입니다.

CLI는 GUI와 동일한 엔진이므로, 책상에서 시각적으로 디버깅한 시나리오는 새벽 2시의 CI에서도 동일하게 실행됩니다. 완전한 가시성으로 테스트를 구축하고 수정하며, 하나의 명령으로 헤드리스로 실행합니다. 이러한 대칭성이 야간 빌드를 관리해야 하는 것이 아닌 신뢰할 수 있는 것으로 만듭니다.

자주 묻는 질문

야간 빌드와 지속적 통합의 차이점은 무엇입니까?

지속적 통합(CI)은 새로운 커밋의 회귀를 잡기 위해 모든 코드 변경 시 테스트를 실행합니다. 야간 빌드는 변경 사항 유무와 관계없이 정해진 일정(일반적으로 밤새)에 실행됩니다. CI는 팀이 망가뜨리는 것을 잡고, 야간 실행은 외부 세계가 망가뜨리는 것, 즉 만료된 토큰, 변경된 의존성, 데이터 변경, 느린 성능 저하 등을 잡습니다. 성숙한 파이프라인은 이 둘을 모두 실행합니다. 빠른 스모크 테스트는 각 커밋을 막고, 더 광범위한 회귀 스위트는 야간에 실행됩니다.

야간 빌드는 언제 실행되어야 합니까?

테스트 환경이 유휴 상태이고 의존하는 외부 서비스에 도달할 수 있는 시간을 선택하십시오. 많은 팀에게 이는 현지 시간으로 오전 1시에서 4시 사이입니다. API가 타사 샌드박스를 호출하는 경우, 해당 시간에 샌드박스가 활성화되어 있는지 확인하십시오. 일부 공급업체는 밤새 트래픽을 제한하거나 일시 중지할 수 있습니다. 수천 개의 작업이 동시에 트리거되는 공유 CI에서는 정각에 정확히 예약하는 것을 피하십시오. 몇 분 정도 오프셋(또는 Jenkins의 H 구문 사용)하면 부하를 분산할 수 있습니다.

프로덕션 환경에 대해 야간 스위트를 실행할 수 있습니까?

프로덕션 환경에 대해 읽기 전용 검사는 안전하게 실행하십시오. 데이터를 쓰는 모든 작업의 경우, 야간 스위트를 실제 데이터가 있는 전용 스테이징 또는 사전 프로덕션 환경으로 지정하거나, 멱등성 작업과 정리 단계를 사용하십시오. 일반적인 패턴은 스테이징에 대한 전체 읽기/쓰기 회귀 실행과 프로덕션에 대한 소규모 읽기 전용 스모크 실행을 추가하여 라이브 시스템이 도달 가능하고 올바르게 응답하는지 확인하는 것입니다.

이것은 모니터링과 어떻게 다릅니까?

업타임 모니터링은 "API가 작동 중인가?"에 답합니다. 야간 회귀 스위트는 "API가 올바른가?"에 답합니다. 모니터링은 엔드포인트에 핑을 보내 200을 확인합니다. 회귀 실행은 전체 워크플로우를 실행하고, 스키마에 대해 응답 본문을 검증하며, 인증 경계를 확인하고, 비즈니스 규칙을 어설션합니다. 이 둘은 상호 보완적입니다. 모니터링은 지속적이고 얕으며, 야간 테스트는 주기적이고 심층적입니다.

API 테스트를 예약하기 위해 코드를 작성해야 합니까?

아니요. Apidog에서 스크립팅 없이 시각적으로 시나리오를 구축한 다음, CI/CD 패널에서 생성된 apidog run 명령을 복사합니다. 유일한 "코드"는 CI 플랫폼에 언제 실행할지 알려주는 몇 줄의 YAML 또는 파이프라인 설정이며, 이는 위 템플릿에 있습니다. 명령줄 러너가 일반적으로 어떻게 비교되는지 더 자세히 보고 싶다면 Postman CLI vs Newman 및 Newman 없이 CI에서 컬렉션 실행에서 대안을 다룹니다.

첫 번째 야간 실행 설정

작게 시작하십시오. 로그인 흐름이나 결제 경로와 같은 하나의 중요한 워크플로우를 선택하고, 실제 어설션을 포함한 단일 Apidog 시나리오로 구축하십시오. CLI로 로컬에서 초록색(성공)이 될 때까지 실행하십시오. 생성된 명령을 위 템플릿 중 하나를 사용하여 예약된 작업에 넣으십시오. 실패 시 팀 채팅으로 알림을 연결하십시오. 이렇게 하면 오후에 작동하는 야간 빌드를 만들 수 있습니다.

거기에서 스위트를 확장하십시오. 다음으로 중요한 여정에 대한 시나리오를 추가하고, 전반적으로 스키마 유효성 검사를 켜고, 주요 엔드포인트에 성능 예산을 설정하십시오. 일주일 안에 커밋별 테스트가 결코 볼 수 없도록 설계되지 않은 오류를 잡아내는 회귀 테스트망을 갖게 될 것이며, 오전 9시의 고객으로부터가 아니라 새벽 2시의 채팅 메시지로부터 그 오류에 대해 듣게 될 것입니다.

button

Apidog에서 API 설계-첫 번째 연습

API를 더 쉽게 구축하고 사용하는 방법을 발견하세요

무료 회원가입다운로드