변경량은 출발점이 아니라 보조 정보다
회귀 테스트 범위는 얼마나 많은 코드가 바뀌었는가보다 그 변경이 잘못됐을 때 어디까지 영향을 주고 얼마나 늦게 발견되며 얼마나 어렵게 되돌릴 수 있는가로 정해야 합니다.
변경된 파일 수와 코드 줄 수를 무시하자는 뜻은 아닙니다. 변경량은 리뷰와 검증에 필요한 작업량, 변경의 복잡성과 불확실성을 추정하는 보조 정보입니다. 그러나 영향 범위를 결정하는 출발점으로 쓰기에는 부족합니다. ISTQB도 회귀 테스트 전에 영향 분석을 수행하도록 설명하며, 범위를 결정할 때 변경 위험, 기존 시스템의 크기, 변경의 크기를 함께 고려합니다.[2][6]
한 줄짜리 권한 조건 변경이 여러 역할의 접근 통제를 무너뜨릴 수 있습니다. 반대로 수백 줄의 코드가 바뀌었더라도 외부 인터페이스가 그대로이고 독립된 내부 모듈에 갇혀 있다면 필요한 회귀 범위는 비교적 좁습니다.
회귀 범위를 정할 때 물어야 할 질문은 이렇습니다. 이 변경이 틀렸다면 어떤 사용자 행동, 권한, 데이터, 연동이 잘못될 수 있는가. 그 실패는 얼마나 큰 결과를 만들며 우리는 얼마나 빨리 알아차리고 되돌릴 수 있는가.
이를 개념적으로 정리하면 회귀 범위 = 영향의 도달 범위 × 실패 결과 × 변경의 불확실성 × 통제 난이도입니다. 이 표현은 숫자를 곱해 점수를 만들라는 뜻이 아닙니다. 검토해야 할 질문의 순서를 나타냅니다.
영향 후보를 찾는 일과 실행 범위를 고르는 일은 다르다
회귀 테스트 선정에는 서로 다른 두 단계가 있습니다. 첫 번째는 무엇이 영향받을 수 있는지 찾는 일입니다. 요구사항, 변경, 코드, 테스트와 결함 사이의 연결을 따라가며 영향 후보를 만듭니다. 두 번째는 그 후보 중 이번 변경에서 어떤 테스트를 실제로 실행할지 정하는 일입니다. 이 글은 두 번째 단계만 다룹니다.
영향 후보에 포함됐다고 모든 테스트를 실행해야 하는 것은 아닙니다. 반대로 직접적인 연결이 보이지 않는다는 이유만으로 테스트를 제외할 수도 없습니다. 공통 구성요소, 권한 정책, 데이터 흐름, 외부 시스템처럼 간접 영향이 큰 경계가 있기 때문입니다.
ISTQB의 Test Analyst 지침도 하나의 선택 기법이 모든 상황에서 우월하지 않다고 설명합니다. 위험 기반 선택, 과거 결함 이력, 사용 패턴, 커버리지와 영향 분석을 상황에 맞게 결합해야 합니다.[1][7]
실행 결과의 신뢰를 지키는 유지관리 — 변경에 강한 식별자로 실행하고 실패 원인을 분류해 보완한 뒤 다시 검증합니다.
회귀 범위를 세 수준으로 나눈다
이 글에서는 회귀 범위를 Focused Regression, Expanded Regression, Broad / Release-level Regression 세 수준으로 구분합니다. 세 수준의 정의는 아래와 같습니다.
Broad Regression이 모든 테스트를 무조건 실행한다는 뜻은 아닙니다. 이 수준에서도 위험과 관련성이 낮은 테스트는 제외할 수 있습니다. 차이는 특정 기능 주변이 아니라 릴리스 전체의 중요한 실패 경계를 범위로 삼는다는 데 있습니다.[3]
- Focused Regression
- Focused Regression은 변경이 실제로 국소화됐다는 근거가 있을 때 씁니다. 변경된 동작, 바로 연결된 소비자, 대표적인 정상·실패 흐름과 관련된 과거 결함 테스트를 확인합니다. 커밋이 작다는 이유로 고르는 수준이 아닙니다.
- Expanded Regression
- Expanded Regression은 변경이 하나의 중요한 사용자 여정이나 권한·데이터·연동 경계를 건드리지만 영향 범위가 특정 영역으로 제한될 때 씁니다. 영향받는 여정 전체와 주요 예외 흐름, 역할, 데이터 상태, 외부 연동 분기, 공통 구성요소의 알려진 소비자를 포함합니다.
- Broad / Release-level Regression
- Broad / Release-level Regression은 여러 핵심 사용자 여정의 공통 경계가 변경됐거나 실패 영향이 크고 발견·복구가 어려울 때 씁니다. 핵심 여정군, 역할과 권한 조합, 주요 데이터 생명주기, 외부 연동, 환경·설정 차이까지 Release 수준에서 확인합니다.
Change Impact × Regression Scope Matrix
아래 Matrix는 회귀 테스트 수를 계산하는 점수표가 아닙니다. 각 축을 검토한 뒤, 근거가 있는 가장 높은 수준을 이번 변경의 회귀 범위로 삼습니다. 축은 세 그룹입니다. 영향의 도달 범위 다섯 축, 변경의 성격과 불확실성 네 축, 실패 결과와 통제 가능성 세 축입니다.
실제 사용 패턴을 이용한 회귀 선택은 빈번하고 중요한 업무 프로세스를 우선하도록 합니다. 인증·인가는 정상 로그인만이 아니라 역할 간 접근과 수평·수직 권한 상승까지 확인해야 합니다. 데이터 변경은 CRUD 생명주기, 무결성, 접근 통제와 일관성 문제로 이어질 수 있으며, 외부 연동은 데이터 변환·통신 흐름·프로토콜·End-to-End 기능까지 살펴야 합니다.[7]
과거 결함 이력은 "결함이 많았던 코드니까 무조건 위험하다"는 낙인이 아닙니다. 유사한 변경에서 실제로 결함을 발견했던 테스트와 민감하게 반응했던 영역을 다시 선택하는 근거입니다. 반대로 기록이 없다는 사실만으로 낮은 위험을 입증할 수는 없습니다. ISTQB는 과거 실행에서 결함을 드러냈거나 유사 변경에 민감했던 테스트를 회귀 범위에 포함하는 History-based Testing을 제시합니다.[7]
설정 변경도 코드 변경보다 작아 보인다는 이유로 좁게 다루면 안 됩니다. Google SRE가 공개한 사례처럼 전역 구성은 예상하지 못한 의존성과 상호작용으로 광범위한 장애를 일으킵니다.[8]
탐지 가능성과 롤백 난이도는 회귀 테스트 자체의 기능 분류는 아니지만 검증 범위를 정할 때 중요한 통제 조건입니다. 실패를 빠르게 볼 수 없거나 잘못된 변경을 되돌리기 어렵다면, 운영에서 발견하겠다는 가정에 의존하기보다 사전 범위를 넓혀야 합니다. Google SRE는 실제 트래픽에서만 드러나는 문제와 불분명한 Canary 신호를 설명하고, 검증하지 않은 롤백 절차가 장애 시간을 늘린 사례도 공개합니다.[8][9]
롤백 가능한 배포를 실제로 구현하는 방법은 별도의 배포 아키텍처 문제입니다. 여기서는 롤백이 어렵다는 사실을 회귀 범위의 상향 신호로만 사용합니다.
그룹 | 평가 축 | Focused Regression | Expanded Regression | Broad / Release-level Regression |
|---|---|---|---|---|
| 영향의 도달 범위 | Critical User Journey | 변경이 비핵심·단일 단계에 한정된다. 해당 동작과 바로 앞뒤 흐름을 확인한다. | 하나의 핵심 여정이나 주요 예외 분기가 영향받는다. 해당 여정 전체를 확인한다. | 여러 핵심 여정의 공통 진입점·종료점·상태 전이가 변경된다. 관련 핵심 여정군을 확인한다. |
| 영향의 도달 범위 | Permission / Authentication | 권한 규칙·세션·인증 토큰에는 변화가 없고 특정 역할의 표시·동작만 바뀐다. | 특정 역할·리소스·행위 또는 로그인·세션 흐름이 변경된다. 역할 간 허용·거부와 음성 케이스를 포함한다. | 중앙 인증 미들웨어, SSO, 세션 정책, 공통 권한 모델이 변경된다. 관련 역할과 핵심 행위를 Release 수준에서 확인한다. |
| 영향의 도달 범위 | Data Mutation | 데이터 저장 상태를 바꾸지 않거나, 독립된 조회·표현만 변경된다. | 하나의 엔터티에 생성·수정·삭제, 검증 또는 매핑 변화가 있다. 해당 데이터 생명주기와 실패 처리를 확인한다. | 스키마·마이그레이션·공통 트랜잭션·중복 처리·교차 엔터티 정합성이 변경된다. 여러 여정과 데이터 상태를 포함한다. |
| 영향의 도달 범위 | External Integration | 계약·인증·데이터 매핑·재시도 조건이 그대로이고 로컬 어댑터 내부만 변경된다. | 하나의 외부 연동에서 계약, 인증, 매핑, 타임아웃, Webhook 또는 실패 처리가 바뀐다. 성공·실패·재시도 흐름을 확인한다. | 공통 Gateway, 여러 공급자, 공유 계약 또는 되돌리기 어려운 외부 부수 효과가 변경된다. End-to-End 연동군을 확인한다. |
| 영향의 도달 범위 | Shared Component | 사용처가 하나이거나 경계가 명확하게 격리돼 있다. | 여러 알려진 소비자가 사용하는 공통 모듈·컴포넌트가 바뀐다. 주요 소비자를 포함한다. | 인증·검증·라우팅·공통 UI·공용 라이브러리처럼 여러 핵심 여정이 의존하는 중앙 구성요소가 바뀐다. |
| 변경의 성격과 불확실성 | Configuration | 특정 기능이나 한 환경에만 적용되는 지역 설정이며 경계가 명확하다. | 환경·Tenant·Region·Feature Flag에 따라 다른 경로가 열린다. 대표 설정 조합을 확인한다. | 전역 라우팅·보안·권한·트래픽·공통 정책 설정이 변경되거나 숨은 의존성이 불명확하다. |
| 변경의 성격과 불확실성 | Dependency | 실행 동작이나 인터페이스가 변하지 않는 격리된 수정이다. | 직접 Dependency의 버전·계약·직렬화·호출 방식이 변한다. 주요 소비자와 계약을 확인한다. | 여러 서비스가 공유하는 런타임·라이브러리, 전이적 Dependency, 주요 버전 또는 호환성이 불명확한 변경이다. |
| 변경의 성격과 불확실성 | Change Novelty | 팀이 반복해 온 익숙한 변경이며 유사 변경의 검증 근거가 있다. | 처음 구현하는 분기·연동·상태 또는 익숙하지 않은 기술이 포함된다. | 새로운 아키텍처·런타임·데이터 흐름처럼 비교할 과거 근거가 거의 없고 실제 입력에서 어떻게 동작할지 불확실하다. |
| 변경의 성격과 불확실성 | Historical Defect Evidence | 유사 변경과 대표 테스트의 최근 결과가 안정적으로 축적돼 있다. | 비슷한 변경에서 결함이 발생했거나 특정 테스트가 반복해서 민감하게 반응했다. | 동일 영역에서 회귀 결함이 반복되거나 여러 구성요소에 걸친 구조적 결함 이력이 있다. |
| 실패 결과와 통제 가능성 | Failure Impact | 실패가 즉시 복구 가능한 불편에 머물고 권한·금전·민감 데이터·핵심 업무에는 영향이 없다. | 핵심 여정 중단, 복구 가능한 데이터 오류, 업무 지연이나 일부 고객 영향이 가능하다. | 무단 접근, 금전 오류, 데이터 무결성·개인정보·규제 문제, 광범위한 서비스 중단으로 이어질 수 있다. |
| 실패 결과와 통제 가능성 | Detectability | 실패 결과가 즉시 나타나며 테스트 판정과 운영 신호가 명확하다. | 오류가 지연되거나 간헐적이고 일부 사용자·역할·데이터 상태에서만 드러난다. | 조용한 데이터 훼손, 권한 노출, 중복 처리처럼 겉으로 성공해 보이거나 현재 관측으로 식별하기 어렵다. |
| 실패 결과와 통제 가능성 | Rollback Difficulty | 변경이 국소적이고 상태를 남기지 않으며 검증된 방식으로 즉시 되돌릴 수 있다. | 데이터 재처리, 캐시 정리, 외부 시스템 조정 등 추가 복구 절차가 필요하다. | 비가역적 데이터 변경, 외부 부수 효과, 장시간 복구 또는 검증되지 않은 롤백이 예상된다. |
점수를 평균 내지 말고 가장 강한 근거로 범위를 올린다
12개 축에 낮음·중간·높음 점수를 붙여 평균을 내는 방식은 간단해 보이지만 중요한 위험을 희석합니다. 권한 변경 하나가 다른 축의 낮은 위험 여러 개와 평균돼 낮은 등급이 되어서는 안 됩니다. 데이터 무결성이나 되돌릴 수 없는 외부 부수 효과도 마찬가지입니다.
그래서 범위는 아래 네 가지 규칙으로 선택하는 편이 낫습니다.
- 1. Focused는 기본값이 아니라 격리됐다는 결론이다
- 커밋이 작아서 Focused를 선택하는 것이 아닙니다. 사용자 여정, 권한, 데이터, 연동, 공통 구성요소에 영향이 없고 실패를 쉽게 발견·복구할 수 있다는 근거가 있어야 합니다.
- 2. 가장 강한 상향 요인을 따른다
- 중앙 권한 모델이나 공유 데이터 계층을 변경했다면 다른 항목이 단순하더라도 Broad가 됩니다.
- 3. 축 사이의 상호작용을 본다
- 외부 연동 변경만으로는 Expanded일 수 있습니다. 그 연동이 데이터를 생성하고 중복 처리가 금전 결과를 만들며 실패가 늦게 발견되고 롤백도 어렵다면 Broad로 올라갑니다.
- 4. 모르는 상태도 범위를 넓히는 근거다
- Dependency의 실제 소비자, 구성 변경의 영향, 외부 시스템의 실패 동작을 알 수 없다면 그 불확실성을 낮은 위험으로 처리해서는 안 됩니다. 추가 분석으로 경계를 확인하거나 더 넓은 범위를 선택합니다.
작은 변경이 Broad Regression을 요구하는 경우
권한 조건 한 줄을 수정한 경우를 봅니다. 코드 변경은 한 줄일 수 있습니다. 하지만 공통 권한 미들웨어의 조건이라면 여러 역할과 핵심 행위가 영향을 받습니다. 이 변경은 Permission / Authentication, Shared Component, Failure Impact, Detectability 축을 건드립니다. 관련 역할별 허용·거부, 수평·수직 권한 이동, 세션 상태와 핵심 행위를 포함한 Broad Regression이 타당합니다.
외부 Webhook의 재시도 설정만 바꾼 경우도 같습니다. 설정 파일의 값 하나를 바꾸더라도 외부 이벤트가 데이터를 생성하거나 상태를 변경한다면 중복 실행, 순서 역전, 부분 실패가 생깁니다. 하나의 연동과 제한된 데이터에만 영향을 준다는 근거가 있으면 Expanded로 시작해도 됩니다. 같은 정책이 여러 연동에 공유되거나 금전·주문·정산처럼 되돌리기 어려운 결과가 있다면 Broad로 올립니다.
제품 맥락을 지키며 실행 규모를 조정 — 고정 리드가 기준과 이력을 이어가고 구간별 스쿼드의 실행 결과를 출시 판단의 근거로 모읍니다.
큰 변경이 반드시 Broad Regression을 뜻하지 않는 경우
독립된 내부 보고서 모듈을 대규모로 리팩터링했지만 외부 인터페이스, 권한, 저장 데이터, 공통 라이브러리와 사용자 핵심 흐름이 변하지 않았다고 가정합니다. 변경된 코드량은 많아도 영향 경계가 명확하고 결과를 쉽게 비교할 수 있으며 롤백도 단순하다면 Focused 또는 Expanded Regression으로 충분합니다.
단, "독립됐다"는 판단은 추측이 아니라 의존성과 소비자 확인으로 입증해야 합니다. 큰 변경량은 검토 작업과 불확실성을 높이지만 그 자체가 Broad의 자동 조건은 아닙니다.[4]
범위 선택 결과는 간단한 결정 기록으로 남긴다
회귀 테스트 목록만 남기면 다음 변경에서 같은 논의를 반복하게 됩니다. 이번에 무엇을 포함했고 왜 제외했는지를 함께 기록해야 합니다. 아래 일곱 항목이면 충분합니다.
실행 중 새로운 실패, 문서화되지 않은 소비자, 예상하지 못한 데이터 상태가 발견되면 처음 정한 범위를 고정하지 않습니다. 범위 선택은 테스트 시작 전에 한 번 작성하고 끝내는 계획이 아니라, 새 증거에 따라 갱신되는 판단입니다.[5]
항목 | 기록할 내용 |
|---|---|
| 변경 | 무엇이 바뀌었는가. 커밋·PR·설정 변경의 식별자 |
| 영향 후보 | 요구사항, 변경, 코드, 테스트, 결함의 연결을 따라 찾은 영향 후보 |
| 범위를 올린 축 | 12개 축 가운데 Expanded 또는 Broad로 판정된 축과 그 근거 |
| 선택한 범위 | Focused | Expanded | Broad / Release-level |
| 포함한 테스트 | 이번 변경에서 실제로 실행하기로 한 테스트 |
| 제외한 테스트와 근거 | 후보였지만 실행하지 않기로 한 테스트와 그 이유 |
| 실행 중 범위를 확대할 조건 | 새 실패, 문서화되지 않은 소비자, 예상 밖 데이터 상태가 발견됐을 때의 대응 |
변경량은 작업량을 말하지만 위험의 방향까지 말해 주지는 않는다
코드 줄 수와 파일 수는 검토에 드는 시간과 복잡성을 추정하는 데 유용합니다. 그러나 사용자가 어떤 일을 실패하게 되는지, 권한과 데이터가 어떻게 바뀌는지, 외부 시스템과 공통 구성요소에 어디까지 퍼지는지까지 알려 주지는 않습니다.
회귀 테스트 범위를 결정하는 질문은 "얼마나 많이 바뀌었나"가 아닙니다. 이 변경이 잘못됐을 때 어디까지 망가질 수 있으며 우리는 그 실패를 얼마나 빨리 발견하고 안전하게 되돌릴 수 있는가입니다.
그 답이 국소적이고 명확하면 Focused Regression을 선택합니다. 하나의 중요한 경계로 이어지면 Expanded Regression을 선택합니다. 여러 핵심 여정의 공통 경계, 큰 실패 결과, 낮은 탐지 가능성이나 어려운 롤백이 겹치면 Broad / Release-level Regression으로 넓힙니다.
이렇게 선택한 회귀 결과는 출시 판단의 중요한 증거가 됩니다. 그러나 회귀 테스트를 넓게 수행했다는 사실만으로 출시 가능 여부가 결정되지는 않습니다.
