SAP 테스트 자동화, '어떻게'보다 '무엇을'이 먼저다: 4가지 기준

테스트 자동화 도구를 도입했습니다. 시나리오를 제작하는 법도 배웠고, 테스트 실행 속도도 빨라졌습니다. 그런데 다음 정기 업그레이드를 앞두고 화면을 켠 담당자의 머릿속에는 여전히 같은 질문이 떠 있습니다.

"그래서… 뭘 테스트하지?"

수천 개의 트랜잭션, 수백 가지 조건 조합, 릴리즈마다 쌓이는 변경 사항. 이 앞에서 자동화 도구는 답을 주지 않습니다. 도구가 풀어준 건 '어떻게(How)' 테스트하느냐였고, 정작 막막함의 정체인 '무엇을(What)' 테스트하느냐는 손도 대지 못한 채 그대로 남아 있기 때문입니다.

이번 포스팅은 바로 그 '무엇을'에 관한 이야기입니다.

'어떻게'와 '무엇을'은 다른 문제다

지금까지 SAP 테스트 자동화 이야기는 대부분 한 방향에 쏠려 있었습니다.

어떻게 하면 더 빠르게 실행할까, 어떻게 하면 UI가 바뀌어도 안 깨질까, 어떻게 하면 결과를 정확히 읽을까. 모두 실행을 잘하는 법, 즉 '어떻게'에 대한 질문입니다.

자동화 도구는 이 부분을 잘 해결합니다. 한번 시나리오를 만들어두면 사람보다 빠르고 일관되게 돌려줍니다.

그런데 도구가 빨라질수록 오히려 한 가지가 분명해집니다. 빠르고 정확하게 엉뚱한 걸 테스트할 수도 있다는 점입니다.

검증할 대상을 잘못 고르면, 실행이 아무리 완벽해도 정작 터질 곳은 검증되지 않은 채 남습니다. 그래서 진짜 차이는 실행을 시작하기 전에 갈립니다. 수많은 후보 중 무엇을 검증할지 고르는 단계에서요. 바로 이 부분을 자동화 도구는 채워주지 못합니다.

왜 '무엇을'이 어려운가: 흔한 세 가지 함정

'무엇을 테스트할지'가 막막한 건 실력이 부족해서가 아닙니다. 고르는 기준이 없기 때문입니다. 기준이 없으니 팀은 보통 세 가지 중 하나를 선택합니다.

첫째, 전부 다 하려는 것. "그냥 다 테스트하자"가 제일 안전해 보입니다. 하지만 업그레이드 적용 후 Go-live까지 주어진 시간은 며칠, 길어야 1~2주입니다. 전체를 다 넣으면 일정 안에 못 끝내고, 결국 중간에 범위를 줄이게 됩니다. 다 하겠다는 계획은 아무것도 못 끝내는 계획이 되기 쉽습니다.

둘째, 감으로 자르는 것. "핵심만 추리자"는 현실적입니다. 문제는 무엇이 '핵심'인지 정하는 기준이 없다는 점입니다. 결국 경험 많은 담당자의 감에 기대게 되고, 그 사람이 없다면 기준 자체가 사라집니다.

셋째, 하던 대로 돌리는 것. "지난번에 했던 걸 그대로 돌리자"가 제일 흔합니다. 그런데 이번 릴리즈에 새로 바뀐 부분이 지난번 회귀테스트 셋에 들어 있을 리 없습니다. 변경된 곳을 놓친 채 익숙한 것만 반복하면, 정작 위험해진 영역은 검증을 비껴갑니다.

이 세 가지 함정의 원인은 하나입니다.

무엇을 테스트할지 정하는 방법이 없다는 것. 그래서 필요한 건 더 빠른 도구가 아니라, 후보를 추려내는 기준입니다.

'무엇을' 정하는 4가지 기준

전체에서 검증할 것을 추려내는 데에는 네 가지 기준이 있습니다. 한 가지 짚어둘 점은, 각 기준은 그 판단에 필요한 적절한 '재료'가 손에 있어야 작동한다는 것입니다. 기준만 알아도 재료가 없으면 다시 감에 의존하는 것으로 돌아가게 됩니다. 그래서 아래에서는 각 기준이 무엇 인지와 함께, 그 판단에 무엇이 필요한지도 같이 짚어보겠습니다.

기준 1. 이번에 바뀐 것

가장 먼저 봐야 할 건 "이번 변경이 우리 시스템에서 실제로 무엇을 건드리는가"입니다. SAP 릴리즈 노트는 수백 페이지에 걸쳐 변경 사항을 나열하지만, 반기마다 쏟아지는 변경은 수천 건에 달하고 그중 우리 회사에 진짜 영향을 주는 건 일부입니다. 전체를 일일이 대조하는 건 현실적으로 불가능합니다.

SAP도 이 문제를 알고 있습니다. S/4HANA Cloud Public Edition(GROW with SAP) 환경에는 RASD(Release Assessment and Scope Dependency)라는 도구가 있습니다. 업그레이드를 앞두고 다가올 릴리즈를 고객의 실제 시스템 사용 현황과 비교해, 삭제·deprecated·신규·변경된 객체(앱, API, CDS View, Scope Item 등)를 우리 회사 범위에 맞춰 추려줍니다. 삭제·deprecated되는 항목이 어떤 커스텀 CDS View나 앱에 영향을 주는지(where-used)까지 보여주고, 변경 정도와 영향도에 따라 어디에 테스트를 집중할지도 제안합니다. Cloud ALM과 연동되어 업그레이드 작업으로 바로 넘길 수도 있습니다.

여기서 중요한 구분이 하나 생깁니다. RASD는 "무엇이 바뀌었고 무엇을 봐야 하는지"는 알려주지만, 그 항목들을 실제로 테스트해주지는 않습니다. 즉 RASD는 기준 1의 재료 — "이번 변경이 건드린 우리 시스템의 목록" — 을 손에 쥐어주는 도구입니다. 그 목록을 받아 실제로 검증 시나리오로 옮기는 일은 여전히 남습니다. 그리고 Public Edition이 아닌 환경이라면, 같은 판단을 위한 변경-사용 매핑을 다른 방식으로 확보해야 합니다.

결국 이 기준을 적용하려면 이번 릴리즈가 건드린 항목이 우리 시스템 어디에 걸리는지를 보여주는 매핑이 손에 있어야 합니다. 릴리즈 변경을 검증 범위로 옮기는 구체적인 방법은 S/4HANA 업그레이드 테스트 전략에서 다뤘습니다.

기준 2. 멈추면 회사가 멈추는 것

모든 프로세스가 같은 무게를 갖지는 않습니다. O2C(주문-수금)나 월말 마감처럼 멈추는 순간 매출과 결산이 바로 막히는 프로세스가 있고, 분기에 한 번 쓰는 리포트처럼 며칠 늦어도 괜찮은 것도 있습니다. 같은 결함이라도 어디서 터지는가에 따라 타격이 전혀 다릅니다.

그래서 검증 순서를 정할 땐 "이게 멈추면 무슨 일이 벌어지나"를 기준으로 매겨야 합니다. 다운스트림에서 몇 개의 후속 작업이 막히는지, 몇 명이 영향을 받는지, 매출·결산·감사 대응에 직접 걸리는지를 따져 우선순위를 세웁니다. 시간이 부족할수록, 영향 큰 것부터 채우는 게 합리적입니다.

이 판단의 출발점은 결국 "우리 회사의 핵심 업무 흐름이 무엇인가"입니다. 대개 O2C, P2P(구매-지급), R2R(기록-보고) 같은 표준 프로세스가 그 골격을 이루는데, 이 표준 흐름과 각 프로세스의 비즈니스 중요도가 미리 정리돼 있으면 무엇부터 봐야 할지 정하는 출발선이 훨씬 또렷해집니다.

기준 3. 데이터가 넘어가는 지점

실제 장애의 상당수는 개별 화면이 아니라 모듈과 모듈이 데이터를 주고받는 지점에서 터집니다. VA01에서 주문은 잘 생성되는데, 그 데이터가 출하 → 출고 확인 → 청구 → 회계 전표로 넘어가다가 중간에서 끊기는 식입니다. 개별 트랜잭션은 다 정상인데 전체 흐름이 멈추는 것입니다.

그래서 '무엇을' 고를 땐 화면 하나하나가 아니라 흐름 단위로 봐야 합니다. 어디서 데이터가 다음 모듈로 넘어가는지, 그 연결 지점이 어디인지를 흐름도로 그려두면 검증해야 할 지점이 보입니다. 화면 단위 체크리스트만으로는 이 연결 지점 자체가 시야에 들어오지 않습니다.

여기에 필요한 건 화면 목록이 아니라 프로세스 흐름도 — 어느 모듈에서 어느 모듈로 데이터가 넘어가는지, 그 핸드오프 지점을 단계로 그린 지도입니다. 표준 E2E 흐름이 정리돼 있으면 이 지도를 처음부터 그릴 필요 없이, 우리 환경에 맞게 손보는 것에서 시작할 수 있습니다. 이 흐름 단위 설계는 시나리오 기반 E2E 테스트 설계에서 자세히 다뤘습니다.

기준 4. 운영에만 있는 예외 케이스

깨끗한 샘플 데이터로는 정상 케이스만 통과합니다. 정작 장애는 특별 할인이 걸린 해외 판매, 다중 통화 결제, 면세 거래처럼 조건이 겹친 예외 케이스에서 터집니다. 일반 주문이 깨지면 금방 발견되지만, 특정 조건 조합에서만 나는 결함은 운영에서 조용히 퍼지다 월말 마감 때 한꺼번에 터집니다.

무엇을 테스트할지 정할 때, 실제 운영에서 어떤 예외가 얼마나 자주 생기는지를 보면 "놓치면 안 되는 경우의 수"가 드러납니다. 문제는 이 목록을 샘플 데이터로는 만들 수 없다는 점입니다. 어떤 조건 조합이 실제로 발생하는지는 운영 데이터 안에만 있기 때문입니다. 깨끗하게 정제된 테스트 데이터만 보는 시야로는 검증해야 할 예외 케이스의 존재 자체를 알 수 없습니다. 그래서 이 기준은 실제 운영 데이터를 들여다볼 수 있는지 여부에 달려 있습니다.

운영 실데이터를 검증에 활용하는 방법은 SAP 데이터 전환 테스트 전략에서 다뤘습니다.

판단에 필요한 재료

네 가지 기준은 결국 각자의 재료가 있어야 작동합니다. 그리고 그 재료의 출처가 서로 다릅니다.

기준 1의 재료 — 이번 변경이 건드린 우리 시스템 목록 — 은 앞서 봤듯이 SAP의 RASD 같은 도구가 점점 더 잘 채워주고 있습니다. 문제는 나머지 셋입니다. 표준 프로세스로 정리된 업무 골격, 모듈 간 핸드오프가 그려진 흐름도, 운영에만 있는 예외 케이스의 목록 — 이 재료들은 릴리즈 노트나 영향 분석 도구가 주지 않습니다.

PerfecTwin이 여기서 하는 일은 '무엇을 테스트할지'를 대신 정해주는 게 아니라, 이 재료들을 제공해주는 것입니다.

운영 DB에서 실제 거래 데이터를 뽑아내면 기준 4가 요구하는 "운영에만 있는 예외"의 목록이 생기고, SAP 표준 프로세스 템플릿은 기준 2·3이 출발점으로 삼는 업무 골격과 E2E 흐름도를 미리 깔아줍니다. RASD가 기준 1을, PerfecTwin이 나머지 기준의 재료를 받쳐주면, 네 기준 모두 감이 아니라 데이터 위에서 작동하게 됩니다. 판단은 여전히 사람이 하되, 그 판단이 설 자리가 단단해지는 셈입니다.

AI는 여기서 무엇을 거들 수 있나

흥미로운 건, '무엇을 테스트할지 정하는 판단' 자체가 지금 업계가 주목하는 영역이라는 점입니다. SAP 생태계 전반에서 데이터를 분석해 사람의 결정을 돕는 흐름이 빠르게 번지고 있고, 테스트도 예외가 아닙니다. 테스트 데이터와 SAP 기준정보를 분석해 "이번엔 이 시나리오 조합부터 보는 게 좋겠다"고 후보를 제안하는 방향은, 앞서 본 네 가지 기준을 사람이 더 빠르고 정확하게 적용하도록 돕는 자연스러운 다음 단계입니다.

여기서 중요한 것은 AI가 '무엇을'을 대신 정해주는 게 아니라, 사람의 판단을 돕는 보조라는 점입니다. 무엇을 검증할지에 대한 최종 책임은 여전히 그 업무를 아는 사람에게 있습니다. 다만 그 판단의 출발점을 데이터가 더 또렷하게 만들어주는 쪽으로 업계가 움직이고 있다는 것입니다.

마무리: 이제 차이는 '무엇을'에서 갈린다

'어떻게'는 도구가 풀었습니다. 시나리오 생성도, 빠른 실행도, 안정적인 반복도 이제 도구의 몫입니다.

남은 건 '무엇을'입니다. 막막한 전체에서 검증할 것을 골라내는 판단 — 이번에 바뀐 곳, 멈추면 안 되는 프로세스, 데이터가 넘어가는 지점, 운영에만 있는 예외 케이스.

이 네 가지를 데이터 위에서 따져본 팀은 터질 결함을 Go-live 전에 잡아내고, 감으로 범위를 자른 팀은 같은 결함을 Go-live 후 운영 장애로 마주합니다. 같은 업그레이드를 두고도 결과가 갈리는 건 바로 이 차이 때문입니다.

테스트 자동화 도구를 도입했는데도 막막하다면, 질문을 바꿀 때입니다. "어떻게 테스트할까"가 아니라 "무엇을 테스트 할까"로.

PerfecTwin이 이 판단을 어떻게 도와주는지 직접 보고 싶다면
→ 무료 데모 신청하기