확인 테스트와 리그레션 테스트를 함께 운영하는 방법

수정한 결함과 변경의 부작용은 검증 대상이 다르다

결함을 수정한 뒤에는 해당 문제가 사라졌는지 확인해야 한다. 동시에 수정·기능 추가·환경 변경이 기존 경로에 예상하지 못한 영향을 남기지 않았는지도 살펴야 한다. 전자는 확인 테스트(Confirmation Test), 후자는 리그레션 테스트(Regression Test)가 맡는다.

확인 테스트는 보고된 결함을 수정한 뒤 문제를 재현했던 조건으로 다시 실행해, 수정 지점에서 결함이 제거됐는지 검증한다. 관심사는 수정된 결함 그 자체다.

리그레션 테스트는 변경 이후 기존 기능을 전체 또는 선택한 범위에서 재검증한다. 변경 영향 범위를 따라 테스트를 선별하고 자동화해, 수정의 부작용을 검출하는 데 초점을 둔다. 흐름으로 보면 소프트웨어 변경에서 변경 영향 범위를 식별하고 회귀 테스트로 이어지는 과정이다.

변경이 발생했을 때 범위와 우선순위를 정하는 기준

신규 기능 추가, 리팩토링, 인터페이스 변경은 리그레션 테스트를 시작하는 대표적인 계기다. OS 업그레이드처럼 Windows 7에서 10으로 바뀌거나 런타임·DB·라이브러리 버전이 달라지는 경우도 여기에 포함된다. 성능 저하나 장애 핫픽스 이후 안정화를 확인해야 할 때 역시 같은 관점이 필요하다.

테스트 범위는 변경 파일만으로 결정하기 어렵다. 코드 의존성 그래프, 커버리지 히트맵, 변경 파일과 관련 테스트의 매핑을 이용해 영향도를 추적한다. 결제·인증 같은 핵심 도메인에는 더 높은 가중치를 두고, 외부 연동과 컨커런시 영역을 우선 확인한다. 마이크로서비스 경계, DB 스키마, 메시지 스키마, 캐시 무효화도 영향 범위에 포함해야 한다.

전체 실행과 선택 실행 사이의 운영 방식

전 범위를 다시 실행하는 Reset All은 신뢰도를 높이는 대신 비용과 시간이 많이 든다. 영향 분석 결과에 따라 일부 스위트만 돌리는 Selective 방식은 효율적이지만, 매핑이 부정확하면 누락 위험을 관리해야 한다. Priority 방식은 중요도·사용량·리스크에 따라 순서를 정해 조기 피드백을 얻고, 배포 게이트와 함께 쓰기 좋다.

유형	목적	성능(실행 시간)	확장성(스위트 유지)	일관성(결과 안정성)	안정성(누락 위험)	운영 편의(자동화)
Reset All	전 기능 신뢰 극대화	낮음(시간 가장 김)	중간(스케일 비용 증가)	높음	매우 낮음	중간(리소스 요구 큼)
Selective	변경영향 효율 검증	높음	높음(맵핑 자동화 시)	중간	중간(맵핑 정확도 의존)	높음
Priority	위험 기반 조기 피드백	높음	높음	중간	중간	높음(게이트와 궁합)

여기서 성능은 실행 시간을 줄일 수 있는 정도를 뜻한다. 확장성은 테스트 스위트가 커질 때 유지하기 쉬운지를, 일관성은 결과 변동성을 줄이는지를 본다. 안정성은 결함을 놓칠 위험이며, 운영 편의는 자동화와 관리 난이도에 대한 평가다.

환경을 고정하고 품질 게이트로 배포를 판단한다

테스트 환경은 버전 핀(versions pinning), 시드 데이터, 테스트 더블, 계약 테스트를 중심으로 표준화한다. CI에서는 변경을 감지한 뒤 선택 또는 우선순위 테스트를 실행하고, 품질 게이트와 리포팅으로 연결할 수 있다.

플래키 테스트도 별도 관리 대상이다. 재시도 정책과 격리(Quarantine) 목록을 운영하고, 불안정한 테스트를 제거하는 주기를 둔다. 패스율, 결함 누수율(Defect Leakage), 변경 대비 커버리지(Change Coverage), MTTR/MTTD를 관찰하며 스프린트·릴리스 단위의 회귀 실패 패턴과 모듈별 결함 밀도를 추적한다.

게이트는 변경 커버리지 ≥ 80%, 중대도 High 실패=배포 차단, 플래키 허용치 ≤ 2%처럼 설정할 수 있다.

결함 수정부터 배포 승인까지의 흐름

확인 테스트는 결함 수정 직후 수행하고, 이후 리그레션 테스트로 영향 범위를 재검증한다. 실패가 발견되면 재현 절차와 영향을 다시 관리하며 테스트 범위를 조정한다.

⤢✕

변경 유형에 따라 회귀 전략을 조합한다

버그를 수정한 직후에는 확인 테스트로 수정 결과를 검증한 뒤, 변경 파일과 테스트 케이스의 매핑을 기반으로 Selective RT를 실행한다. 이때 변경 커버리지 ≥ 80% 기준을 적용할 수 있다.

대규모 리팩토링이나 모듈화에서는 Priority RT로 핵심 경로를 먼저 보호하고, 야간에 Reset All을 수행한다. 서비스 경계는 계약 테스트로 안정화하고 스키마 호환성 검사도 포함한다.

OS·런타임·DB 환경을 업그레이드할 때는 호환성 스모크 테스트, 성능 기준선 비교, 회귀 스위트 병렬 실행을 이어간다. 컨테이너 이미지의 다중 버전 매트릭스와 데이터 마이그레이션 리허설도 함께 검토한다.

GitHub Actions로 선택 회귀와 전체 회귀를 함께 실행하기

전제조건은 Python 3.10+, pytest ≥ 7, pytest-testmon ≥ 2, GitHub Actions 사용 환경이다. 변경 영향 기반 선택 실행에는 pytest-testmon을 사용하고, 주간 전체 회귀인 Reset All을 병행한다. pytest-rerunfailures로 플래키를 완화하며 테스트 영향 데이터 캐시를 활용한다.

# .github/workflows/regression.yml
name: regression-tests

on:
  push:
    branches: [ "main" ]
  workflow_dispatch:
  schedule:
    - cron: "0 3 * * 1"  # 매주 월 03:00 UTC 전체 회귀

jobs:
  regression:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install dependencies
        run: pip install -U pytest pytest-testmon pytest-rerunfailures

      - name: Restore testmon cache
        uses: actions/cache@v4
        with:
          path: .testmondata
          key: ${{ runner.os }}-testmon-${{ hashFiles('**/requirements*.txt') }}-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-testmon-${{ hashFiles('**/requirements*.txt') }}-

      - name: Selective regression on push
        if: github.event_name == 'push'
        run: pytest --testmon --reruns 2 --maxfail=1 -q

      - name: Weekly reset-all
        if: github.event_name == 'schedule'
        run: pytest -q --reruns 1

테스트 데이터는 시드와 픽스처로 고정하고, 외부 연동은 Mock·Stub·Contract로 격리한다. 플래키 테스트 격리 목록을 유지하면서 변경 대비 커버리지 리포트를 업로드하고 품질 게이트와 연동한다.

품질과 운영 부담에 미치는 영향

결함 누수율은 20~~40% 감소하고, 고위험 경로의 회귀 건수는 단위 기간 대비 절반 수준에 도달할 수 있다. 선택·우선순위 회귀를 적용하면 평균 실행 시간을 30~~70% 단축할 수 있다.

야간 전체 회귀와 주간·릴리스 게이트 체계를 운영하면 인력 투입을 25% 이상 절감할 수 있다. 변경 커버리지, 패스율, 플래키 비율의 추세를 관리하면 릴리스 예측 가능성도 높아진다.