회귀 범위를 줄이는 “축” 한 장으로 정리하기

릴리즈가 잦아질수록 회귀 목록은 기하급수적으로 늘어납니다. 문제는 테스트가 부족해서가 아니라, 무엇을 “이번에 반드시” 확인할지 합의가 없다는 점입니다. 저희는 변경의 성격(데이터, UI, API, 비기능)을 축으로 나누고, 각 축마다 최소한의 증거를 요구하는 방식을 권장합니다.

첫 번째 단계는 변경점을 문장이 아니라 표로 옮기는 일입니다. 두 번째 단계는 각 축에 대해 “이번 릴리즈에서 깨지면 운영에 바로 영향이 있는가?”를 질문으로 고정하는 것입니다. 마지막으로, 남은 항목만 자동화 스위트와 수동 탐색에 배분합니다.

이 접근은 완벽한 안전망을 약속하지 않습니다. 대신 팀이 같은 화면에서 우선순위를 논의할 수 있게 합니다. 멘토링에서는 표를 스크린샷으로 남기지 말고 링크로 공유하는 습관을 함께 다룹니다.

실무에서는 축이 흔들리는 경우가 많습니다. 그럴 때는 한 축만 다시 정의하고 나머지는 유지하는 편이 비용 대비 효과가 큽니다. 이 글의 프레임은 “테스트 데이터 설계 클리닉”과 연결해 읽으면 더 잘 맞습니다.