회귀 테스트를 통과했는데, 왜 같은 결함이 또 나올까
판매 주문이 회계로 넘어가며 손익 계정이 비정상 처리되는 결함이 안정화 기간 중에 발견됩니다.
개발팀이 패치를 제공하고, QA가 회귀 테스트를 다시 돌립니다. 통과합니다.
며칠 뒤, 같은 위치에서 결함이 다시 보고됩니다. 이번엔 조건이 약간 다릅니다.
패치도 했고 회귀 테스트도 통과했는데 왜 같은 결함이 또 나올까요.
원인은 단순합니다. 회귀 테스트가 결함이 발생한 단위가 아닌 모듈 단위로 돌아갔기 때문입니다. 패치는 한 모듈 안의 동작을 고쳤고, 회귀 테스트는 그 모듈이 정상이라고 확인해줬지만, 결함이 실제로 발생한 모듈 사이의 데이터 전달 지점은 검증 범위 밖에 있었던 것입니다.
이 글에서는 그 구조적 함정과, 회귀 테스트의 단위를 흐름 단위로 재설계하는 방법을 정리합니다.
1. 패치는 통과시키지만 결함은 막지 못하는 회귀 테스트
회귀 테스트가 "통과"라고 말할 때, 그것이 무엇을 검증한 결과인지 정확히 봐야 합니다.
패치는 보통 한 모듈 안의 동작을 고치는 작업입니다. 분개 생성 로직을 수정하거나, 검증 규칙을 보강하거나, 매핑 규칙을 갱신합니다. 회귀 테스트가 그 모듈 안에서 돌면, 패치는 통과합니다. 분개 생성 화면을 열어 정상 케이스를 실행하면 의도한 대로 작동합니다.
문제는 결함이 발생한 위치가 패치를 적용한 모듈 안이 아니라, 그 모듈에서 다른 모듈로 데이터가 넘어가는 사이라는 점입니다. 판매에서 회계로 데이터가 전달되는 지점, 출고에서 송장으로 이어지는 지점, 청구에서 분개로 옮겨가는 지점 — 한 트랜잭션 안에서 이런 전달 지점이 여러 개 존재합니다.
패치는 한 쪽 모듈의 동작을 수정합니다. 하지만 양쪽 모듈을 연결하는 데이터 전달 규칙, 매핑 로직, 인터페이스 설정은 그대로 남아 있습니다. 그래서 패치 후 회귀 테스트가 통과하더라도, 그 통과는 "한 모듈이 정상 작동한다"는 증명일 뿐 "이 결함이 다시 나오지 않는다"는 증명은 아닙니다.
같은 결함이 며칠 뒤 다른 조건에서 다시 나오는 이유는 여기에 있습니다. 결함이 발생한 진짜 위치가 검증의 범위 밖에 있었던 것입니다.
2. 모듈 단위 회귀 테스트가 검증해주지 않는 3가지
대부분의 SAP 회귀 테스트는 모듈 단위로 짜여 있습니다. 판매 모듈 회귀 테스트, 회계 모듈 회귀 테스트, 구매 모듈 회귀 테스트가 따로 존재합니다. 이 구조에서 패치 후에 검증해주지 않는 것이 세 가지 있습니다.
1) 결함이 발생한 흐름을 그대로 재현하지 못합니다
판매 주문 단독으로는 정상이고, 회계 분개 단독으로도 정상인데, 두 모듈 사이의 데이터 전달 과정에서만 결함이 발생합니다. 모듈 단위 회귀 테스트는 각 모듈 안에서 거래를 만들고 검증하므로, 결함이 발생한 정확한 데이터 전달 경로를 재현할 방법이 없습니다. 결함의 진짜 원인이 무엇이었는지 모듈 단위 테스트로는 잡히지 않습니다.
2) 패치가 인접 모듈로 미친 영향을 확인하지 못합니다
패치는 한 모듈을 수정하지만, 그 수정이 인접 모듈로 데이터를 보내는 방식까지 함께 바뀐 경우가 많습니다. 분개 생성 로직을 손봤더니 손익 반영에 들어가는 데이터의 구조가 미세하게 달라지는 식입니다. 모듈 단위 회귀 테스트는 패치를 적용한 모듈만 검증하므로, 패치가 인접 모듈로 넘어가는 시점에서 새로운 결함을 만들었는지 확인할 수 없습니다.
3) 다음 변경 때 같은 함정이 다시 반복됩니다
이번 결함의 원인이 어디였는지 모듈 단위 테스트로는 정확히 짚을 수 없으므로, 다음번 변경에서 비슷한 함정에 다시 빠질 가능성이 그대로 남습니다. 검증의 범위가 바뀌지 않는 한, 결함이 발생한 같은 종류의 위치에서 또 다른 결함이 나옵니다.
3. 결함이 발생한 흐름 전체를 재현하는 회귀 — 판매-회계 예시
도입부에서 든 결함을 흐름 단위로 다시 짜보면 어떻게 될까요.
기존의 모듈 단위 테스트는 이렇게 작동합니다.
판매 모듈 테스트: 주문 생성, 출고 처리, 청구 발행을 각각 검증 → 통과
회계 모듈 테스트: 분개 생성, 손익 처리를 각각 검증 → 통과
결함은 청구 → 분개 전달 시점에서 발생 → 어느 모듈 테스트도 잡지 못함
대신 결함이 지나간 단계를 따라 흐름 시나리오를 만들어봅니다.
: 주문 생성 → 출고 확정 → 청구 발행 → 분개 생성 → 손익 반영
이 흐름 자체가 하나의 회귀 테스트 시나리오가 됩니다. 결함이 발생한 모듈 사이의 전달 지점이 시나리오 안에 그대로 포함되므로, 패치 적용 후 이 시나리오를 다시 돌리면 두 가지가 한 번에 검증됩니다.
패치가 의도한 위치(분개 생성)에서 결함을 해결했는지
패치가 인접 단계(손익 반영)로 넘어가면서 새 결함을 만들지 않았는지
핵심 원칙은 단순합니다. 결함이 발생한 단위와 테스트가 검증하는 단위를 맞추는 것입니다. 결함이 흐름에서 발생했으면, 테스트도 흐름 단위로 짜야 합니다.
흐름 단위로 짜인 회귀 테스트가 통과했을 때 그 통과의 의미는 달라집니다. "한 모듈이 작동한다"가 아니라 "이 결함이 발생한 흐름 전체에서 패치가 작동하고, 인접 단계에 새 문제를 만들지 않았다"가 됩니다. 같은 결함이 며칠 뒤 다른 조건에서 다시 나오는 패턴이 끊깁니다.
4. 흐름 단위 회귀 테스트 설계 3단계
판매-회계 예시의 원리를 모든 회귀 테스트에 적용하는 방법은 3단계로 정리됩니다.
Step 1. 핵심 비즈니스 흐름을 식별합니다
회귀 테스트 대상이 될 비즈니스 흐름부터 정의합니다. 주문-청구-수금(O2C), 구매-입고-지급(P2P), 재무 결산, 재고 평가 같은 흐름이 후보입니다. 모듈 관점이 아닌 업무 관점으로 흐름을 그리는 게 핵심입니다.
Step 2. 각 흐름을 검증 가능한 단계로 분해합니다
각 비즈니스 흐름을 구성하는 액션 단위로 분해합니다.
예: O2C 흐름 → 주문 생성 → 신용 한도 확인 → 출고 지시 → 출고 확정 → 청구 발행 → 수금 처리
단계 단위로 분해하는 이유는, 패치가 적용됐을 때 그 영향이 어느 단계까지 미쳤는지 단계별로 추적해야 하기 때문입니다. 한 덩어리의 시나리오로만 짜두면 어디서 통과하고 어디서 어긋났는지 확인이 어려워집니다. 시나리오 기반 E2E 테스트 설계의 원리와 동일한 출발점입니다.
Step 3. 결함이 발생한 흐름을 시나리오로 만들어 패치 후 전체를 재검증합니다
결함이 발견되면 그 결함이 지나간 단계들로 시나리오를 구성합니다. 도입부의 판매-회계 결함이라면 "주문 생성 → 출고 확정 → 청구 발행 → 분개 생성 → 손익 반영" 다섯 단계가 시나리오가 됩니다.
패치 적용 후 이 시나리오 전체를 다시 실행합니다. 패치한 단계만 보는 게 아니라, 그 앞뒤 단계가 패치 전과 동일하게 작동하는지까지 확인합니다. 이 단계에서 회귀 테스트의 의미가 비로소 "한 모듈이 작동한다"에서 "이 결함 패턴 전체가 해결됐다"로 옮겨집니다.
흐름 단위 회귀 테스트가 실무에서 작동하려면 한 가지 전제 조건이 있습니다.
패치 → 재검증 사이클이 일정 안에 끝날 수 있어야 한다는 점입니다. 결함이 발생한 흐름을 매번 처음부터 끝까지 다시 돌려야 하므로, 시나리오 수가 늘어날수록 실행 시간이 부담됩니다. UI 리플레이 방식은 사람의 화면 조작을 그대로 재현하기 때문에 흐름 단위 시나리오에서 특히 느려집니다. PerfecTwin은 UI를 거치지 않고 SAP 백엔드에 직접 데이터를 전송하는 방식으로, 흐름 단위 회귀 시나리오를 짧은 시간 안에 반복 실행할 수 있게 합니다.
결론: "통과"의 의미를 결함의 단위로 맞춰야 한다
같은 결함이 패치 후에도 재발하는 진짜 이유는 회귀 테스트의 "통과"가 결함의 단위와 다른 단위를 검증하고 있기 때문입니다. 결함은 모듈을 넘어가는 흐름에서 발생하는데, 통과는 모듈 안에서 결정됩니다. 그래서 패치를 적용해도, 회귀 테스트가 통과해도, 같은 위치에서 다른 조건의 결함이 다시 나옵니다.
해결의 출발점은 회귀 테스트의 단위를 결함의 단위와 맞추는 것입니다. 결함이 흐름에서 발생하면 테스트도 흐름 단위로 짜고, 패치 후에는 그 흐름 전체를 다시 돌립니다. 이때 비로소 "통과"라는 결과가 "이 결함이 더 이상 나오지 않는다"의 의미를 가집니다.
회귀 테스트 사이클 자체의 속도 병목, 자동화 도구의 유지보수 부담, 결과 판독의 신뢰성 같은 다른 구조적 문제들은 SAP Hypercare를 길게 만드는 회귀 테스트 사이클: 5가지 구조적 병목과 해법에서 정리한 적이 있습니다. 이 글에서 다룬 "회귀 테스트의 단위" 문제는 그 다섯 가지 병목과 별개의 축이지만, 같은 결과(안정화 기간 장기화, 패치-재발 사이클 반복)로 이어집니다.
PerfecTwin은 백엔드 직접 전송 방식으로 흐름 단위 회귀 시나리오를 빠르게 반복 실행할 수 있게 합니다. 패치 후 전체 흐름 재검증 사이클이 일정 안에 끝나는 실제 모습을 직접 확인해 보세요.