GitHub Actions 매트릭스 빌드 완벽 가이드

GitHub Actions의 매트릭스 빌드 전략을 활용하여 다양한 환경에서 자동으로 테스트하는 방법을 배웁니다. 초급 개발자도 쉽게 따라할 수 있도록 실무 예제와 함께 설명합니다.

---

목차

1. matrix 전략 이해
2. 다중 OS 테스트
3. 다중 언어 버전 테스트
4. include와 exclude
5. fail-fast 전략
6. max-parallel 설정

---

1. matrix 전략 이해

김개발 씨는 오픈소스 라이브러리를 처음으로 배포하게 되었습니다. Node.js 16, 18, 20 버전에서 모두 테스트해야 한다는 이야기를 들었는데, 워크플로우 파일을 세 개나 만들어야 하는 걸까요?

선배 박시니어 씨가 웃으며 말했습니다. "매트릭스 전략을 쓰면 하나의 설정으로 충분해요."

매트릭스 전략은 하나의 워크플로우 정의로 여러 환경 조합을 자동으로 생성하는 기능입니다. 마치 엑셀의 표처럼 행과 열의 조합을 만들어낸다고 생각하면 됩니다.

이를 활용하면 중복 코드 없이 다양한 환경에서 테스트를 실행할 수 있습니다.

다음 코드를 살펴봅시다.

name: Matrix Build Example
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    # 매트릭스 전략 정의
    strategy:
      matrix:
        # node-version 변수에 세 가지 값을 지정
        node-version: [16, 18, 20]
    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 이번에 처음으로 팀의 오픈소스 라이브러리 관리를 맡게 되었습니다.

사용자들이 다양한 Node.js 버전을 사용하기 때문에, 최소한 세 가지 버전에서 테스트를 해야 한다고 합니다. 처음에 김개발 씨는 각 버전마다 별도의 워크플로우 파일을 만들어야 하나 고민했습니다.

test-node16.yml, test-node18.yml, test-node20.yml처럼 말이죠. 하지만 이렇게 하면 나중에 테스트 스크립트를 수정할 때 세 파일을 모두 고쳐야 합니다.

선배 개발자 박시니어 씨가 다가와 말했습니다. "매트릭스 전략을 써보세요.

한 번 정의하면 자동으로 여러 환경을 만들어줍니다." 그렇다면 매트릭스 전략이란 정확히 무엇일까요? 쉽게 비유하자면, 매트릭스는 마치 자동판매기의 버튼 조합과 같습니다.

음료 종류 버튼과 사이즈 버튼을 누르면 자동으로 조합이 만들어지듯이, 매트릭스도 정의한 값들의 모든 조합을 자동으로 생성합니다. 위 예제에서 node-version에 세 가지 값을 넣으면, 세 개의 독립적인 작업이 만들어집니다.

매트릭스가 없던 시절에는 어땠을까요? 개발자들은 각 환경마다 별도의 워크플로우를 작성해야 했습니다.

테스트 스크립트 하나를 수정하려면 모든 파일을 일일이 고쳐야 했습니다. 더 큰 문제는 새로운 버전이 추가될 때마다 파일을 복사해서 만들어야 한다는 점이었습니다.

바로 이런 문제를 해결하기 위해 매트릭스 전략이 등장했습니다. strategy 키워드 아래에 matrix를 정의하면, GitHub Actions가 알아서 모든 조합을 만들어줍니다.

변수 값은 ${{ matrix.변수명 }} 형태로 참조할 수 있습니다. 위의 코드를 살펴보겠습니다.

strategy 블록에서 matrix를 정의하고, node-version이라는 변수에 배열 형태로 16, 18, 20을 지정했습니다. 그러면 GitHub Actions는 자동으로 세 개의 병렬 작업을 생성합니다.

각 작업에서는 **${{ matrix.node-version }}**을 통해 현재 작업에 할당된 버전 값을 가져옵니다. setup-node 액션에 이 값을 전달하면, 해당 버전의 Node.js가 설치됩니다.

실제 현업에서는 라이브러리 개발 시 필수적으로 사용됩니다. npm에 배포하는 패키지라면 사용자들이 어떤 버전을 쓸지 모르기 때문입니다.

매트릭스를 활용하면 한 번의 푸시로 모든 지원 버전에서 테스트를 돌릴 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 단 하나의 워크플로우 파일로 세 가지 버전을 모두 테스트할 수 있게 되었습니다. 이제 새로운 Node.js 버전이 나와도 배열에 숫자 하나만 추가하면 됩니다.

실전 팁

💡 - 매트릭스 변수명은 자유롭게 정할 수 있습니다. node-version 대신 node나 version도 가능합니다.

• 매트릭스로 생성된 각 작업은 병렬로 실행되어 전체 테스트 시간을 단축합니다.

---

2. 다중 OS 테스트

김개발 씨가 만든 라이브러리가 점점 인기를 얻기 시작했습니다. 그런데 어느 날 Windows 사용자로부터 이슈가 올라왔습니다.

"제 컴퓨터에서는 작동하지 않아요." 알고 보니 파일 경로 처리 방식이 OS마다 달랐던 것입니다. 이제 여러 운영체제에서도 테스트해야 할 때가 왔습니다.

runs-on 속성도 매트릭스 변수로 지정할 수 있습니다. ubuntu-latest, windows-latest, macos-latest 등 여러 운영체제를 배열로 나열하면, 각 OS에서 동시에 테스트가 실행됩니다.

크로스 플랫폼 라이브러리 개발에 필수적인 기능입니다.

다음 코드를 살펴봅시다.

name: Multi-OS Test
on: [push]

jobs:
  test:
    # 매트릭스 변수를 runs-on에 적용
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        # 테스트할 운영체제 목록
        os: [ubuntu-latest, windows-latest, macos-latest]
        node-version: [18, 20]
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js ${{ matrix.node-version }} on ${{ matrix.os }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

오픈소스 라이브러리를 운영하다 보면 예상치 못한 곳에서 버그 리포트가 올라옵니다. 김개발 씨도 그런 경험을 하게 되었습니다.

Ubuntu에서는 완벽하게 동작하던 코드가 Windows에서는 오류를 일으킨 것입니다. 원인은 파일 경로 구분자였습니다.

Linux와 macOS는 슬래시(/)를 사용하지만, Windows는 백슬래시()를 사용합니다. 이런 차이를 미리 발견하지 못하면 사용자들에게 불편을 끼치게 됩니다.

박시니어 씨가 조언했습니다. "매트릭스에 OS도 추가해보세요.

한 번의 설정으로 세 가지 운영체제에서 테스트할 수 있어요." 다중 OS 테스트는 마치 자동차의 충돌 테스트와 같습니다. 다양한 조건에서 미리 시험해보면 실제 사용자 환경에서 문제가 생길 확률이 줄어듭니다.

개발자가 Mac을 쓴다고 해서 모든 사용자가 Mac을 쓰는 것은 아니니까요. 위 예제를 보면 os라는 매트릭스 변수를 새로 추가했습니다.

ubuntu-latest, windows-latest, macos-latest 세 가지 값을 배열로 지정했습니다. 그리고 runs-on 속성에 ${{ matrix.os }}를 적용했습니다.

여기서 흥미로운 점은 node-version과 os가 함께 있다는 것입니다. 매트릭스는 모든 변수의 조합을 생성합니다.

os가 3개, node-version이 2개이므로, 총 6개의 작업이 만들어집니다. Ubuntu + Node 18, Ubuntu + Node 20, Windows + Node 18, 이런 식으로 모든 조합이 생성됩니다.

실무에서 다중 OS 테스트가 특히 중요한 경우가 있습니다. CLI 도구를 개발할 때, 파일 시스템을 다룰 때, 네이티브 모듈을 사용할 때가 대표적입니다.

이런 경우 OS별 동작 차이가 버그로 이어질 수 있습니다. 주의할 점도 있습니다.

GitHub Actions의 무료 사용량에는 제한이 있는데, 운영체제마다 소비되는 분이 다릅니다. Linux가 1분이라면 Windows는 2분, macOS는 10분이 소비됩니다.

따라서 비용을 고려해야 하는 프로젝트에서는 macOS 테스트를 신중하게 결정해야 합니다. 김개발 씨는 이제 모든 주요 운영체제에서 라이브러리가 정상 동작하는지 자동으로 확인할 수 있게 되었습니다.

Windows 사용자로부터 더 이상 같은 종류의 버그 리포트가 올라오지 않았습니다.

실전 팁

💡 - macOS 러너는 비용이 높으므로, 꼭 필요한 경우에만 포함하세요.

• Windows에서는 셸 명령어가 다를 수 있으니, cross-platform 스크립트를 작성하세요.

---

3. 다중 언어 버전 테스트

팀의 백엔드 서비스가 Python으로 작성되어 있었습니다. 김개발 씨는 Python 3.9에서 개발했는데, 프로덕션 서버는 3.11을 사용하고 있었습니다.

"혹시 버전 차이로 문제가 생기면 어쩌지?" 걱정이 되기 시작했습니다.

매트릭스 전략은 Node.js뿐 아니라 모든 프로그래밍 언어에 적용할 수 있습니다. Python, Java, Go, Ruby 등 각 언어의 setup 액션과 함께 사용하면, 여러 버전에서 동시에 테스트를 실행할 수 있습니다.

마이너 버전 차이로 인한 호환성 문제를 사전에 발견할 수 있습니다.

다음 코드를 살펴봅시다.

name: Python Multi-Version Test
on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        # Python 3.9, 3.10, 3.11, 3.12 버전 테스트
        python-version: ['3.9', '3.10', '3.11', '3.12']
    steps:
      - uses: actions/checkout@v4
      - name: Set up Python ${{ matrix.python-version }}
        uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
      - name: Run tests
        run: pytest

프로그래밍 언어는 계속해서 발전합니다. Python 3.10에서 추가된 match 문, Python 3.11의 성능 개선, Python 3.12의 새로운 타입 힌트 기능 등 버전마다 변화가 있습니다.

이런 변화가 때로는 기존 코드와 충돌을 일으키기도 합니다. 김개발 씨의 팀은 개발 환경과 프로덕션 환경의 Python 버전이 달랐습니다.

로컬에서는 잘 되는데 배포하면 오류가 나는 상황, 개발자라면 한 번쯤 겪어봤을 것입니다. 다중 언어 버전 테스트는 마치 약의 임상시험과 같습니다.

다양한 조건에서 미리 검증해야 실제 사용 환경에서 문제가 없다는 것을 보장할 수 있습니다. 특히 라이브러리를 배포하는 경우, 사용자들이 어떤 버전을 쓸지 예측할 수 없으므로 더욱 중요합니다.

위 예제에서는 Python 3.9부터 3.12까지 네 가지 버전을 테스트합니다. setup-python 액션에 매트릭스 변수를 전달하면, 각 작업에서 해당 버전의 Python이 설치됩니다.

버전 값을 문자열로 지정한 것에 주목하세요. '3.10'처럼 따옴표로 감싸지 않으면, YAML이 이를 숫자 3.1로 해석할 수 있습니다.

이런 사소한 실수가 예상치 못한 버그로 이어질 수 있으니 주의해야 합니다. 다른 언어도 마찬가지입니다.

Java라면 setup-java 액션과 함께 java-version을, Go라면 setup-go 액션과 함께 go-version을 사용합니다. 패턴은 동일하니 한 번 익혀두면 어떤 언어에도 적용할 수 있습니다.

실무에서는 보통 최소 지원 버전과 최신 버전을 포함합니다. 예를 들어 Python 3.9가 최소 지원 버전이라면, 3.9와 가장 최신인 3.12를 반드시 포함하고, 중간 버전은 선택적으로 추가합니다.

김개발 씨는 이제 모든 지원 버전에서 테스트를 자동으로 실행합니다. 덕분에 프로덕션 배포 전에 버전 호환성 문제를 미리 발견할 수 있게 되었습니다.

실전 팁

💡 - 버전 번호는 반드시 문자열로 지정하세요. '3.10'이 아닌 3.10은 3.1로 해석될 수 있습니다.

• 모든 버전을 테스트할 필요는 없습니다. 최소 지원 버전과 최신 버전 위주로 선택하세요.

---

4. include와 exclude

김개발 씨는 매트릭스로 6개의 조합을 만들었습니다. 그런데 문제가 생겼습니다.

Windows에서 Node.js 16 조합은 테스트할 필요가 없었고, 대신 Ubuntu에서만 실험적인 Node.js 21 버전을 추가하고 싶었습니다. 모든 조합을 수동으로 나열해야 할까요?

include와 exclude는 매트릭스 조합을 세밀하게 제어하는 기능입니다. exclude는 특정 조합을 제외하고, include는 새로운 조합을 추가합니다.

마치 레스토랑 메뉴에서 "이 재료는 빼고, 저 토핑은 추가해주세요"라고 요청하는 것과 같습니다.

다음 코드를 살펴봅시다.

name: Matrix with Include/Exclude
on: [push]

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node-version: [16, 18, 20]
        # 특정 조합 제외
        exclude:
          - os: windows-latest
            node-version: 16
        # 새로운 조합 추가
        include:
          - os: ubuntu-latest
            node-version: 21
            experimental: true
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

매트릭스의 모든 조합이 항상 필요한 것은 아닙니다. 예를 들어 특정 운영체제에서 오래된 버전을 지원하지 않는다거나, 특별한 환경에서만 추가 테스트를 하고 싶을 때가 있습니다.

김개발 씨의 상황을 다시 살펴봅시다. os가 2개, node-version이 3개이면 총 6개의 조합이 만들어집니다.

하지만 Windows에서 Node.js 16은 더 이상 공식 지원되지 않아 테스트가 의미 없습니다. 반면 Ubuntu에서는 실험적으로 Node.js 21도 테스트해보고 싶습니다.

exclude는 마치 주문할 때 "이건 빼주세요"라고 말하는 것과 같습니다. 위 예제에서 exclude 블록은 Windows + Node.js 16 조합을 매트릭스에서 제거합니다.

이제 이 조합은 실행되지 않습니다. include는 반대로 "이건 추가해주세요"입니다.

기본 매트릭스에는 없는 새로운 조합을 추가할 수 있습니다. 위 예제에서는 Ubuntu + Node.js 21 조합을 추가했습니다.

여기에 experimental이라는 추가 속성도 함께 지정했습니다. include로 추가된 속성은 해당 조합에서만 사용할 수 있습니다.

위 예제에서 ${{ matrix.experimental }}은 Node.js 21 조합에서만 true가 되고, 다른 조합에서는 빈 값이 됩니다. 이를 활용해 조건부 로직을 구현할 수 있습니다.

실무에서 exclude가 자주 사용되는 경우는 비호환 조합을 제거할 때입니다. 예를 들어 특정 라이브러리가 구버전 Node.js와 Windows 조합에서 설치되지 않는다면, 해당 조합을 제외하는 것이 합리적입니다.

include는 엣지 케이스 테스트에 유용합니다. 대부분의 조합에서는 일반적인 설정을 쓰되, 특정 조합에서만 실험적 기능을 테스트하거나 추가 옵션을 적용할 수 있습니다.

김개발 씨는 이제 불필요한 조합은 제외하고, 필요한 조합만 추가하여 테스트 시간과 비용을 최적화할 수 있게 되었습니다.

실전 팁

💡 - exclude는 기존 매트릭스에서 조합을 제거하고, include는 새로운 조합을 추가합니다.

• include로 추가한 속성은 해당 조합에서만 접근 가능합니다.
• 복잡한 조합이 필요하다면 include만으로 전체 매트릭스를 구성할 수도 있습니다.

---

5. fail-fast 전략

매트릭스로 10개의 조합을 테스트하던 중, 첫 번째 조합에서 테스트가 실패했습니다. 그런데 나머지 9개의 작업도 계속 실행되고 있습니다.

"이미 실패한 거 알았는데, 나머지는 왜 계속 돌아가는 거지?" 김개발 씨는 GitHub Actions 사용량이 걱정되기 시작했습니다.

fail-fast는 매트릭스 작업 중 하나라도 실패하면 나머지 작업을 즉시 취소하는 옵션입니다. 기본값은 true로, 빠른 피드백을 위해 첫 실패 시점에 모든 작업이 중단됩니다.

하지만 때로는 모든 조합의 결과를 확인해야 할 때도 있어서, false로 설정할 수 있습니다.

다음 코드를 살펴봅시다.

name: Fail-Fast Strategy
on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      # 하나가 실패해도 나머지 계속 실행
      fail-fast: false
      matrix:
        node-version: [16, 18, 20]
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

  quick-check:
    runs-on: ubuntu-latest
    strategy:
      # 첫 실패 시 나머지 즉시 취소 (기본값)
      fail-fast: true
      matrix:
        check: [lint, typecheck, format]
    steps:
      - uses: actions/checkout@v4
      - run: npm run ${{ matrix.check }}

매트릭스 빌드에서 하나의 조합이 실패하면 어떻게 될까요? 기본적으로 GitHub Actions는 나머지 작업을 모두 취소합니다.

이것이 바로 fail-fast 전략입니다. 김개발 씨는 처음에 이 동작이 불편하다고 느꼈습니다.

Node.js 16에서 실패했는데 18과 20은 어떤지 알 수 없으니까요. 하지만 박시니어 씨는 다른 관점을 제시했습니다.

"대부분의 경우 하나가 실패하면 다른 것도 실패해요. 빨리 알고 빨리 고치는 게 효율적이죠." fail-fast: true는 마치 요리할 때 불이 꺼진 걸 발견하면 바로 확인하는 것과 같습니다.

다른 요리를 계속 만들어봤자 어차피 모두 설익게 될 테니, 일단 문제부터 해결하는 것이 현명합니다. 반면 fail-fast: false가 필요한 상황도 있습니다.

다양한 환경에서 호환성을 검증할 때, 어떤 환경은 성공하고 어떤 환경은 실패하는지 전체 그림을 봐야 할 수 있습니다. 특히 오픈소스 라이브러리에서 지원 환경을 결정할 때 유용합니다.

위 예제를 보면 두 가지 작업이 있습니다. test 작업은 fail-fast를 false로 설정하여 모든 Node.js 버전의 결과를 확인합니다.

반면 quick-check 작업은 기본값인 true를 명시하여, lint가 실패하면 typecheck와 format은 실행하지 않습니다. 실무에서는 상황에 따라 다르게 설정합니다.

PR 검증처럼 빠른 피드백이 중요하면 fail-fast를 true로 둡니다. 릴리스 전 최종 검증처럼 모든 환경의 결과가 필요하면 false로 설정합니다.

한 가지 주의할 점이 있습니다. fail-fast가 작동하려면 작업들이 병렬로 실행되어야 합니다.

만약 max-parallel을 1로 설정하면 작업이 순차적으로 실행되므로, 하나가 실패해도 이미 다음 작업이 시작된 후일 수 있습니다. 김개발 씨는 이제 상황에 맞게 fail-fast를 설정합니다.

빠른 피드백이 필요한 일반 개발 중에는 기본값을 유지하고, 릴리스 직전 전체 호환성을 확인할 때만 false로 변경합니다.

실전 팁

💡 - fail-fast의 기본값은 true입니다. 명시적으로 작성하면 의도가 더 명확해집니다.

• 모든 조합의 결과가 필요한 릴리스 검증에서는 fail-fast: false를 사용하세요.

---

6. max-parallel 설정

김개발 씨의 매트릭스가 점점 커졌습니다. OS 3개, Node.js 버전 4개, 추가 옵션까지 합치니 20개가 넘는 작업이 동시에 실행됩니다.

그런데 외부 API 서버가 동시 접속 제한에 걸려 테스트가 실패하기 시작했습니다. 병렬 실행을 조절할 방법이 필요했습니다.

max-parallel은 동시에 실행할 매트릭스 작업의 최대 개수를 제한하는 옵션입니다. 기본적으로 GitHub Actions는 가능한 모든 작업을 병렬로 실행하지만, 외부 서비스 제한이나 리소스 관리를 위해 동시 실행 수를 조절해야 할 때 사용합니다.

다음 코드를 살펴봅시다.

name: Controlled Parallel Execution
on: [push]

jobs:
  integration-test:
    runs-on: ubuntu-latest
    strategy:
      # 동시에 최대 2개 작업만 실행
      max-parallel: 2
      fail-fast: false
      matrix:
        test-suite: [auth, payment, inventory, shipping, notification]
    steps:
      - uses: actions/checkout@v4
      - name: Setup test environment
        run: npm ci
      - name: Run ${{ matrix.test-suite }} tests
        run: npm run test:${{ matrix.test-suite }}
        env:
          # 외부 API 사용하는 통합 테스트
          API_KEY: ${{ secrets.API_KEY }}

  unit-test:
    runs-on: ubuntu-latest
    strategy:
      # 단위 테스트는 제한 없이 병렬 실행
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run test:unit --shard=${{ matrix.shard }}/4

병렬 실행은 양날의 검입니다. 빠른 피드백을 위해 좋지만, 때로는 문제가 되기도 합니다.

김개발 씨가 겪은 상황이 바로 그런 경우입니다. 통합 테스트에서 외부 결제 API를 호출하는데, 이 API가 동시 접속을 5개까지만 허용했습니다.

매트릭스가 20개의 작업을 동시에 실행하니 rate limit에 걸려 테스트가 실패하기 시작했습니다. max-parallel은 마치 놀이공원의 입장 제한과 같습니다.

한 번에 너무 많은 사람이 들어가면 혼잡해지니, 적정 인원만 입장시키는 것입니다. 위 예제에서 max-parallel: 2는 동시에 2개의 작업만 실행되도록 제한합니다.

위 예제를 보면 두 가지 작업이 있습니다. integration-test는 외부 API를 사용하므로 max-parallel을 2로 제한했습니다.

5개의 테스트 스위트가 있지만, 한 번에 2개씩만 실행됩니다. 반면 unit-test는 외부 의존성이 없으므로 제한 없이 병렬로 실행됩니다.

max-parallel이 유용한 또 다른 상황이 있습니다. 셀프 호스티드 러너를 사용할 때입니다.

GitHub 호스티드 러너와 달리, 셀프 호스티드 러너는 서버 리소스가 제한적입니다. 동시에 너무 많은 작업이 실행되면 서버가 느려지거나 다운될 수 있습니다.

데이터베이스를 사용하는 테스트에서도 유용합니다. 동시에 여러 작업이 같은 데이터베이스에 접근하면 충돌이 발생할 수 있습니다.

max-parallel을 1로 설정하면 순차적으로 실행되어 이런 문제를 방지합니다. 주의할 점은 max-parallel이 전체 테스트 시간에 영향을 준다는 것입니다.

5개 작업을 동시에 실행하면 1개 작업 시간이 걸리지만, max-parallel: 1로 설정하면 5개 작업 시간이 걸립니다. 필요한 경우에만 사용해야 합니다.

김개발 씨는 이제 외부 API를 사용하는 테스트에만 max-parallel을 적용합니다. 덕분에 rate limit 오류 없이 안정적으로 테스트를 실행할 수 있게 되었습니다.

테스트 시간은 조금 늘어났지만, 실패하는 것보다는 훨씬 낫습니다.

실전 팁

💡 - max-parallel은 꼭 필요한 경우에만 사용하세요. 불필요하게 설정하면 테스트 시간이 늘어납니다.

• 외부 API rate limit, 셀프 호스티드 러너 리소스, 데이터베이스 동시 접근 문제에 유용합니다.
• max-parallel: 1로 설정하면 사실상 순차 실행이 됩니다.

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!