회귀 테스트 범위는 코드 변경량이 아니라 무엇으로 정해야 할까

회귀 테스트 범위는 얼마나 많은 코드가 바뀌었는가보다 그 변경이 잘못됐을 때 어디까지 영향을 주고 얼마나 늦게 발견되며 얼마나 어렵게 되돌릴 수 있는가로 정해야 한다.

변경된 파일 수와 코드 줄 수를 무시하자는 뜻은 아니다. 변경량은 리뷰와 검증에 필요한 작업량, 변경의 복잡성과 불확실성을 추정하는 보조 정보다. 그러나 영향 범위를 결정하는 출발점으로 쓰기에는 부족하다. ISTQB도 회귀 테스트 전에 영향 분석을 수행하도록 설명하며 범위를 결정할 때 변경 위험, 기존 시스템의 크기, 변경의 크기를 함께 고려한다. (istqb.org)

한 줄짜리 권한 조건 변경이 여러 역할의 접근 통제를 무너뜨릴 수 있다. 반대로 수백 줄의 코드가 바뀌었더라도 외부 인터페이스가 그대로이고 독립된 내부 모듈에 갇혀 있다면 필요한 회귀 범위는 비교적 좁을 수 있다.

회귀 범위를 정할 때 물어야 할 질문은 다음과 같다.

이 변경이 틀렸다면 어떤 사용자 행동, 권한, 데이터, 연동이 잘못될 수 있는가? 그 실패는 얼마나 큰 결과를 만들며 우리는 얼마나 빨리 알아차리고 되돌릴 수 있는가?

이를 개념적으로 정리하면 다음과 같다.

회귀 범위 = 영향의 도달 범위 × 실패 결과 × 변경의 불확실성 × 통제 난이도

이 표현은 숫자를 곱해 점수를 만들라는 뜻이 아니다. 검토해야 할 질문의 순서를 나타낸다.

영향 후보를 찾는 일과 실행 범위를 고르는 일은 다르다

회귀 테스트 선정에는 서로 다른 두 단계가 있다.

첫 번째는 무엇이 영향받을 수 있는지 찾는 일이다. 요구사항, 변경, 코드, 테스트와 결함 사이의 연결을 따라가며 영향 후보를 만든다.

두 번째는 그 후보 중 이번 변경에서 어떤 테스트를 실제로 실행할지 정하는 일이다. 이 글은 두 번째 단계만 다룬다.

영향 후보에 포함됐다고 모든 테스트를 실행해야 하는 것은 아니다. 반대로 직접적인 연결이 보이지 않는다는 이유만으로 테스트를 제외할 수도 없다. 공통 구성요소, 권한 정책, 데이터 흐름, 외부 시스템처럼 간접 영향이 큰 경계가 있기 때문이다.

ISTQB의 Test Analyst 지침도 하나의 선택 기법이 모든 상황에서 우월하지 않다고 설명한다. 위험 기반 선택, 과거 결함 이력, 사용 패턴, 커버리지와 영향 분석을 상황에 맞게 결합해야 한다. (istqb.org)

회귀 범위를 세 수준으로 나눈다

이 글에서는 회귀 범위를 다음 세 수준으로 구분한다.

Focused Regression

변경이 실제로 국소화됐다는 근거가 있을 때 사용한다.

변경된 동작, 바로 연결된 소비자, 대표적인 정상·실패 흐름과 관련된 과거 결함 테스트를 확인한다. 단순히 커밋이 작다는 이유로 이 수준을 선택해서는 안 된다.

Expanded Regression

변경이 하나의 중요한 사용자 여정이나 권한·데이터·연동 경계를 건드리지만 영향 범위가 특정 영역으로 제한될 때 사용한다.

영향받는 사용자 여정 전체와 주요 예외 흐름, 역할, 데이터 상태, 외부 연동 분기, 공통 구성요소의 알려진 소비자를 포함한다.

Broad / Release-level Regression

여러 핵심 사용자 여정의 공통 경계가 변경됐거나, 실패 영향이 크고 발견·복구가 어려울 때 사용한다.

관련 핵심 여정군, 역할과 권한 조합, 주요 데이터 생명주기, 외부 연동, 환경·설정 차이까지 Release 수준에서 확인한다.

Broad Regression이 모든 테스트를 무조건 실행한다는 뜻은 아니다. 이 수준에서도 위험과 관련성이 낮은 테스트는 제외할 수 있다. 차이는 특정 기능 주변이 아니라 릴리스 전체의 중요한 실패 경계를 범위로 삼는다는 데 있다.

Change Impact × Regression Scope Matrix

아래 매트릭스는 회귀 테스트 수를 계산하는 점수표가 아니다. 각 축을 검토한 뒤, 근거가 있는 가장 높은 수준을 이번 변경의 회귀 범위로 삼는다.

1. 영향의 도달 범위

실제 사용 패턴을 이용한 회귀 선택은 빈번하고 중요한 업무 프로세스를 우선하도록 한다. 인증·인가는 정상 로그인만이 아니라 역할 간 접근과 수평·수직 권한 상승까지 확인해야 한다. 데이터 변경은 CRUD 생명주기, 무결성, 접근 통제와 일관성 문제로 이어질 수 있으며 외부 연동은 데이터 변환·통신 흐름·프로토콜·End-to-End 기능까지 살펴야 한다. (istqb.org)

2. 변경의 성격과 불확실성

과거 결함 이력은 “결함이 많았던 코드니까 무조건 위험하다”는 낙인이 아니다. 유사한 변경에서 실제로 결함을 발견했던 테스트와 민감하게 반응했던 영역을 다시 선택하는 근거다. 반대로 기록이 없다는 사실만으로 낮은 위험을 입증할 수는 없다. ISTQB는 과거 실행에서 결함을 드러냈거나 유사 변경에 민감했던 테스트를 회귀 범위에 포함하는 History-based Testing을 제시한다. (istqb.org)

설정 변경도 코드 변경보다 작아 보인다는 이유로 좁게 다루면 안 된다. Google SRE가 공개한 사례처럼 전역 구성은 예상하지 못한 의존성과 상호작용을 통해 광범위한 장애를 만들 수 있다. (sre.google)

3. 실패 결과와 통제 가능성

탐지 가능성과 롤백 난이도는 회귀 테스트 자체의 기능 분류는 아니지만 검증 범위를 정할 때 중요한 통제 조건이다. 실패를 빠르게 볼 수 없거나 잘못된 변경을 되돌리기 어렵다면, 운영에서 발견하겠다는 가정에 의존하기보다 사전 범위를 넓혀야 한다. Google SRE는 실제 트래픽에서만 드러나는 문제와 불분명한 Canary 신호를 설명하고 있으며 검증하지 않은 롤백 절차가 장애 시간을 늘린 사례도 공개한다. (sre.google)

롤백 가능한 배포를 실제로 구현하는 방법은 별도의 배포 아키텍처 문제다. 여기서는 롤백이 어렵다는 사실을 회귀 범위의 상향 신호로만 사용한다.

점수를 평균내지 말고 가장 강한 근거로 범위를 올린다

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의 자동 조건은 아니다.

범위 선택 결과는 간단한 결정 기록으로 남긴다

회귀 테스트 목록만 남기면 다음 변경에서 같은 논의를 반복하게 된다. 이번에 무엇을 포함했고 왜 제외했는지를 함께 기록해야 한다.

변경:
영향 후보:

범위를 올린 축:
- Critical User Journey:
- Permission / Authentication:
- Data Mutation:
- External Integration:
- Shared Component:
- Configuration:
- Dependency:
- Failure Impact:
- Change Novelty:
- Historical Defect Evidence:
- Detectability:
- Rollback Difficulty:

선택한 범위:
Focused | Expanded | Broad / Release-level

포함한 테스트:
제외한 테스트와 근거:
실행 중 범위를 확대할 조건:

실행 중 새로운 실패, 문서화되지 않은 소비자, 예상하지 못한 데이터 상태가 발견되면 처음 정한 범위를 고정하지 않는다. 범위 선택은 테스트 시작 전에 한 번 작성하고 끝내는 계획이 아니라, 새 증거에 따라 갱신되는 판단이다.

변경량은 작업량을 말하지만 위험의 방향까지 말해주지는 않는다

코드 줄 수와 파일 수는 검토에 드는 시간과 복잡성을 추정하는 데 유용하다. 그러나 사용자가 어떤 일을 실패하게 되는지, 권한과 데이터가 어떻게 바뀌는지, 외부 시스템과 공통 구성요소에 어디까지 퍼지는지까지 알려주지는 않는다.

회귀 테스트 범위를 결정하는 질문은 “얼마나 많이 바뀌었나”가 아니다.

이 변경이 잘못됐을 때 어디까지 망가질 수 있으며 우리는 그 실패를 얼마나 빨리 발견하고 안전하게 되돌릴 수 있는가?

그 답이 국소적이고 명확하면 Focused Regression을 선택한다. 하나의 중요한 경계로 이어지면 Expanded Regression을 선택한다. 여러 핵심 여정의 공통 경계, 큰 실패 결과, 낮은 탐지 가능성이나 어려운 롤백이 겹치면 Broad / Release-level Regression으로 넓힌다.

이렇게 선택한 회귀 결과는 출시 판단의 중요한 증거가 된다. 그러나 회귀 테스트를 넓게 수행했다는 사실만으로 출시 가능 여부가 결정되지는 않는다.