CI가 너무 느려서 아무도 보지 않게 됐다｜실행 시간을 단축하는 7가지 방법

「CI가 끝날 때까지 기다릴 수 없다」「어차피 통과하겠지」——CI 실행 시간이 너무 길어서 생기는 「아무도 기다리지 않는·아무도 보지 않는」문화와, 실행 시간을 단축하는 7가지 구체적인 방법을 해설합니다. pytest-xdist 병렬화·Stage 분할·캐시 설계·목업화 등, 실무에서 바로 사용할 수 있는 CI 고속화 방법을 소개합니다.

CI는 「망가졌을 때」보다 「너무 느릴 때」 쪽이, 서서히 팀을 망가뜨립니다. 「30분 기다려서 빨간 CI」와 「3분만에 빨간 CI」는, 같은 실패여도 팀에 주는 영향이 전혀 다릅니다.

「CI 끝났어？」「아, 아직 돌고 있어. 일단 머지하자」——이 대화가 한 번이라도 일어났다면, CI의 속도 문제는 이미 문화 문제가 됐습니다.

Flaky 테스트와 달리, CI 속도 문제는 「테스트가 실패」하는 것이 아닙니다. 조용히, 서서히, 「CI를 확인하는 문화」를 침식해 갑니다. 이 기사에서는 CI 지연이 일으키는 붕괴 프로세스와, 구체적인 고속화 방법을 해설합니다.

CI 속도 문제가 「아무도 보지 않게 된다」로 이어지는 프로세스란？

CI가 느려지는 7가지 원인

「왠지 느리다」인 채로 두면 영원히 개선되지 않습니다. 먼저 어떤 원인으로 느린지를 특정하는 것이 고속화의 첫 번째 단계입니다.

대책①：pytest-xdist로 병렬 실행한다

가장 즉효성이 높은 대책입니다. pytest-xdist를 사용하면 테스트를 여러 CPU 코어로 병렬 실행할 수 있습니다. 테스트 수가 많을수록 효과가 크고, 100건 이상의 테스트 스위트에서는 실행 시간이 2〜4배 단축되는 경우가 많습니다.

# 설치
# pip install pytest-xdist

# 로컬：CPU 코어 수를 자동 감지하여 병렬 실행
pytest tests/ -n auto

# GitHub Actions：워커 수를 명시적으로 지정
pytest tests/ -n 4

# CI 한정으로 유효화（권장 - 로컬 디버깅과의 충돌을 피하기 위해）
# pytest.ini의 addopts가 아닌 GitHub Actions의 run 스텝에 설정：
#   run: pytest tests/ -n auto
#
# ⚠️ addopts에 -n auto를 상시 설정하면
# VSCode Test Explorer・디버거・coverage 계측・Flaky 조사와 충돌이 발생할 수 있습니다

대책②：CI를 Stage로 분할하여 조기 피드백을 얻는다

「모든 테스트가 끝나지 않으면 아무것도 알 수 없는」설계는 아무리 빠르게 해도 한계가 있습니다. 단위 테스트→통합 테스트→E2E 테스트의 순서로 Stage를 나누면 버그를 빠른 단계에서 감지할 수 있습니다.

# GitHub Actions Stage 분할 예（.github/workflows/test.yml）
# 참고：대규모 프로젝트에서는 reusable workflow나 composite action도 검토하세요
name: CI Pipeline
on: [push, pull_request]
jobs:
  # Stage 1：단위 테스트（목표：1분 이내）
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
          cache: "pip"              # 내장 pip 캐시 - 별도 캐시 스텝 불필요
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run unit tests
        run: pytest tests/unit/ -n auto --tb=short

  # Stage 2：통합 테스트（목표：3분 이내）
  # 단위 테스트가 통과한 경우에만 실행
  integration-tests:
    needs: unit-tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
          cache: "pip"
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run integration tests
        run: pytest tests/integration/ -n auto

  # Stage 3：E2E 테스트（목표：5분 이내）
  # 통합 테스트가 통과한 경우에만 실행
  e2e-tests:
    needs: integration-tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
          cache: "pip"
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Install Playwright browsers
        run: playwright install chromium --with-deps
      - name: Run E2E tests
        run: pytest tests/e2e/ -n 2

대책③：의존성 캐시로 매번의 설치를 생략한다

매번 pip install을 실행하면 그것만으로 2〜5분이 걸리는 경우가 있습니다. 의존성이 변하지 않은 경우는 캐시를 이용하여 설치 시간을 거의 제로로 할 수 있습니다.

# GitHub Actions 캐시 설정 예
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # ✅ 방법A：setup-python 내장 pip 캐시（간단）
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
          cache: "pip"   # requirements.txt가 변경됐을 때만 무효화

      - name: Install dependencies
        run: pip install -r requirements.txt

      # ✅ Playwright 브라우저 바이너리 캐시
      - name: Cache Playwright browsers
        uses: actions/cache@v4
        with:
          path: ~/.cache/ms-playwright
          key: playwright-${{ hashFiles('requirements.txt') }}

      - name: Install Playwright browsers（캐시가 없을 경우에만）
        run: playwright install chromium --with-deps

대책④：외부 I/O를 목업화하여 CI 환경의 대기 시간을 삭감한다

실제 DB・외부 API・메일 발송 등을 사용하는 테스트는, 네트워크 지연·외부 서비스의 응답 시간이 CI의 병목이 되는 경우가 있습니다.

from unittest.mock import patch, MagicMock
import requests
import pytest

from sqlalchemy import create_engine
from sqlalchemy.orm import Session, declarative_base

# Base 정의 예（실제 프로젝트에서는 모델 파일에서 선언 완료 상정）
# from sqlalchemy.orm import declarative_base
# Base = declarative_base()
Base = declarative_base()

# ❌ 느림：실제 외부 API를 매번 호출
def test_send_notification():
    result = requests.post(
        "https://api.slack.com/api/chat.postMessage",
        json={"channel": "#test", "text": "테스트 완료"}
    )
    assert result.status_code == 200
    # 네트워크 왕복으로 200〜500ms 걸린다

# ✅ 빠름：외부 API를 목업화하여 즉시 반환
@patch("requests.post")
def test_send_notification_fast(mock_post):
    mock_post.return_value = MagicMock(status_code=200)
    result = requests.post(
        "https://api.slack.com/api/chat.postMessage",
        json={"channel": "#test", "text": "테스트 완료"}
    )
    assert result.status_code == 200
    # 목업이므로 1ms 이하로 완료

# ✅ DB도 픽스처로 인메모리를 사용한다
@pytest.fixture
def db_session():
    """SQLite 인메모리 DB를 사용한 고속 DB 픽스처"""
    engine = create_engine("sqlite:///:memory:")
    Base.metadata.create_all(engine)
    with Session(engine) as session:
        yield session
    # with 블록을 벗어나면 자동으로 close・rollback

대책⑤：time.sleep을 배제하여 명시적 대기로 교체한다

100건의 테스트에 time.sleep(2)가 1개씩 있으면 그것만으로 3분 초과의 고정 로스가 됩니다. sleep은 Flaky의 원인이기도 하며, CI 고속화 관점에서도 맨 먼저 배제해야 할 대상입니다.

# time.sleep 사용 부분을 일괄 검색（asyncio.sleep 등과의 혼동을 피하기 위해 명시적으로 지정）
# grep -R "time.sleep(" ./tests

# ❌ 느림：고정 대기
import time
time.sleep(3)
driver.find_element(By.ID, "result").click()

# ✅ 빠름：조건이 충족되면 즉시 다음으로
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 10)
element = wait.until(EC.element_to_be_clickable((By.ID, "result")))
element.click()
# 요소가 클릭 가능해진 순간에 실행（평균 0.3초, sleep보다 대폭 단축）

대책⑥：실행 시간이 긴 테스트를 가시화하여 정리한다

실행 시간 프로파일링으로 「느린 테스트 상위 10건」을 가시화하는 것만으로 개선의 우선순위가 명확해집니다.

# pytest 표준 기능으로 실행 시간이 긴 테스트를 표시（추가 플러그인 불필요）
pytest tests/ --durations=20

# 실무 권장：1초 이상 걸리는 테스트만 표시（짧은 테스트의 노이즈 제거）
pytest tests/ --durations=20 --durations-min=1.0

# ❌ 문제 있는 패턴：
# - 단위 테스트가 3초 이상 걸린다 → 외부 I/O가 혼입되어 있을 가능성
# - E2E 테스트가 20초 이상 걸린다 → 테스트의 스코프가 너무 넓을 가능성
# - 「같은 시나리오를 미묘하게 변경한」테스트가 다수 있다 → parametrize로 통합을 검토

대책⑦：테스트 피라미드를 재검토하여 E2E 편중을 시정한다

CI가 근본적으로 느린 경우, 원인은 종종 「테스트 피라미드의 역전」에 있습니다. E2E 테스트만 늘어나고 단위·통합 테스트가 적은 상태가 이것입니다.

「아무도 보지 않게 되기 전에」대처하는 예조 체크리스트란？

3개 이상 해당되면 지금 당장 개선을 시작하는 신호입니다.

FAQ

CI는 「코드 품질을 지키기 위한 것」이지만, 너무 느리면 「아무도 기다리지 않는 것」이 됩니다. 기술적인 문제인 것 같지만, 방치하면 문화적인 문제로 변합니다. 오늘 실행 시간을 계측하고, 1가지만 개선해 보세요. 「5분 CI를 기다릴 수 있는 팀」과 「30분 CI를 포기한 팀」은 1년 후 품질에 큰 차이가 생깁니다.