SAP Cloud ALM 테스트 관리, 어디까지 되고 무엇이 부족한가
오케스트레이션은 갖췄다. 그런데 실행은 준비되었는가?
Cloud ALM 테넌트를 열고 테스트 관리(Test Management) 앱을 처음 써본 실무자들의 반응은 대체로 비슷합니다. "관리 화면은 확실히 SolMan보다 깔끔하다. 그런데… 자동화 테스트 실행은 어디서 하는 거지?"
지난 1편에서 우리는 2027년 SolMan 종료와 함께 테스트 관리 체계 자체가 달라진다는 사실, 그리고 Cloud ALM 시대의 핵심 구조 변화인 "오케스트레이션과 실행의 분리"를 다뤘습니다. SolMan에서 전환하는 기업이든, SAP Cloud를 처음 도입하면서 Cloud ALM을 만난 기업이든, 결국 같은 질문 앞에 서게 된다는 것도 확인했습니다.
1편은 그 질문을 세 가지로 정리했습니다. ① 테스트 자산을 Cloud ALM 체계에서 어떻게 구축·관리할 것인가, ② Cloud ALM 위에서 실행할 테스트 자동화 도구는 무엇으로 할 것인가, ③ SAP 프로젝트 일정 안에서 이 테스트 체계를 어떻게 세울 것인가.
이번 편에서는 그중 가장 핵심적인 두 번째 질문 — 테스트 자동화 도구 선택에 집중합니다. Cloud ALM의 테스트 관리가 실무에서 어디까지 커버되는지 솔직히 평가하고, 어디서부터 별도의 도구가 필요한지를 짚겠습니다. 그리고 도구를 선택할 때 반드시 확인해야 할 5가지 핵심 기준을 제시합니다.
1. Cloud ALM 테스트 관리가 잘하는 것
Cloud ALM의 테스트 관리 기능을 구체적으로 살펴보기 전에, 이 플랫폼이 실무에서 어디까지 커버하는지를 먼저 정리하겠습니다.
완전한 추적성(Traceability)
Cloud ALM의 가장 큰 강점은 프로세스 → 요구사항 → 테스트 케이스를 하나의 체계로 연결하는 추적성입니다. SAP Activate 방법론의 각 단계에 맞춰 테스트 활동이 정렬되고, 요구사항에 연결된 테스트 케이스가 어떤 프로세스를 검증하는지, 실행 결과가 어떤 결함과 이어지는지를 하나의 대시보드에서 추적할 수 있습니다. Go-live 의사결정에 필요한 테스트 커버리지 가시성이 확보되는 것입니다.
통합 대시보드와 수동 테스트 워크플로우
테스트 계획 수립, 실행 진행률 모니터링, 결함(Defect) 관리가 하나의 플랫폼에서 이루어집니다. 테스트 시퀀스(Test Sequences) 기능을 통해 어떤 테스트를 어떤 순서로, 누가 실행할지도 체계적으로 관리할 수 있습니다. 수동 테스트에 한해서라면, Cloud ALM만으로도 충분히 체계적인 테스트 관리가 가능합니다.
정리하면,
Cloud ALM은 "테스트를 어떻게 계획하고, 추적하고, 보고할 것인가"라는 거버넌스 문제를 잘 해결합니다. SolMan 시대에 많은 기업이 결국 엑셀로 관리했던 것을 생각하면, 이것만으로도 의미 있는 진전입니다.
하지만 문제는 여기서부터입니다.
2. Cloud ALM만으로 부족한 영역
Cloud ALM이 테스트 "관리"에 강하다는 것은 곧, 테스트 "실행"은 다른 곳에서 해야 한다는 뜻이기도 합니다. 구체적으로 어떤 영역이 부족한지 살펴보겠습니다.
자체 자동화 엔진이 없다
이것이 가장 핵심적인 구조적 한계입니다. Cloud ALM에서 자동 테스트 케이스(Automated Test Case)를 생성하면, 실제로 만들어지는 것은 "껍데기"입니다. 테스트 케이스의 이름, 연결된 프로세스, 실행 상태 같은 메타 정보만 Cloud ALM에 존재하고, 실제 테스트 스크립트(무엇을 클릭하고, 어떤 값을 입력하고, 무엇을 검증할지)는 외부 자동화 도구에서 만들어야 합니다.
1편에서 비유한 것처럼, Cloud ALM은 오케스트라의 "지휘자"입니다. 어떤 곡을 연주할지, 어떤 순서로 진행할지를 관리하지만, 실제 연주는 별도의 악기(도구)가 담당합니다. SAP도 공식적으로 Cloud ALM은 자체 자동화 엔진을 제공하지 않으며 서드파티 통합에 개방적인 구조라고 밝히고 있습니다.
기존에 SolMan의 CBTA(Component-Based Test Automation)를 사용해왔던 기업이라면 특히 주의가 필요합니다. CBTA는 SolMan과 함께 지원이 종료되며, Cloud ALM으로 이관되지 않습니다. 기존 자동화 자산을 그대로 가져갈 수 없다는 뜻입니다. Cloud ALM 전환은 곧 테스트 자동화 도구를 새로 선택해야 하는 시점이기도 합니다.
기본 제공 자동화(Tricentis TTA)의 현실적 제약
"잠깐, Cloud ALM에 Tricentis 자동화가 기본으로 포함되어 있지 않나?"라고 생각하실 수 있습니다. 맞습니다. SAP Enterprise Support 고객에게는 Tricentis Test Automation(TTA)이 추가 비용 없이 제공됩니다.
하지만 이 기본 제공 버전에는 현실적인 제약이 있습니다.
지원 범위의 제약: 기본 제공 TTA는 웹 기반 SAP 애플리케이션(Fiori, Ariba, SuccessFactors 등)의 자동화를 지원합니다. SAP GUI 기반 트랜잭션이나 API 테스트, 복잡한 크로스 모듈 E2E 시나리오까지 커버하려면 별도의 상위 라이선스가 필요합니다.
실행 방식의 제약: TTA는 UI 리플레이(화면 녹화·재생) 방식으로 테스트를 실행합니다. 이 방식은 직관적이지만, 뒤에서 자세히 다룰 속도와 안정성 측면에서 구조적 한계를 갖고 있습니다.
테스트 데이터 관리 공백
Cloud ALM에는 테스트 데이터를 준비하는 기능이 없습니다. 어떤 데이터로 테스트할지, 운영 환경의 실제 거래 패턴을 어떻게 반영할지는 전적으로 사용자의 몫입니다.
이전 시리즈 Migration 편에서 다뤘듯이, 샘플 데이터만으로는 운영 환경의 복잡성을 재현할 수 없습니다. 수천 개의 거래처, 수만 개의 품목, 다중 통화와 특수 세금이 조합된 실제 거래 데이터를 테스트에 활용하려면 별도의 데이터 추출·준비 체계가 필요합니다. 이 영역은 Cloud ALM의 커버 범위 밖에 있습니다.
대량 회귀 테스트의 현실
S/4HANA 환경에서는 분기별 업그레이드마다 수백에서 수천 건의 회귀 테스트를 반복해야 합니다. UI 리플레이 방식의 자동화는 건당 수분이 소요되며, 화면 로딩 지연이나 UI 변경에 취약합니다. 테스트 건수가 수백 건만 되어도 상당한 시간이 필요합니다.
프로젝트 일정이 빠듯한 업그레이드 상황에서 테스트 실행 시간이 일정을 좌우하는 변수가 되어서는 안 됩니다.
정리하면,
Cloud ALM은 훌륭한 지휘자입니다. 하지만 지휘자만으로는 연주회를 열 수 없습니다. 이제 그 "연주자"를 어떤 기준으로 선택해야 하는지 이야기하겠습니다.
3. 테스트 자동화 도구 선택 시 확인해야 할 5가지 기준
Cloud ALM 위에서 작동할 테스트 자동화 도구를 선택할 때, 단순히 "유명한 도구"나 "SAP 공식 파트너 도구"라는 이유만으로 결정하면 실무에서 한계에 부딪힐 수 있습니다. SAP 환경의 특수성을 고려했을 때, 다음 5가지 관점에서 도구를 평가해야 합니다.
기준 ① SAP 특화 깊이
가장 먼저 확인해야 할 전제 조건입니다. 이 도구가 SAP를 얼마나 깊이 이해하는가?
범용 자동화 도구는 SAP 화면을 일반적인 웹 페이지나 데스크톱 앱과 동일하게 취급합니다. 작동은 하지만, SAP 환경 특유의 복잡성 — T-Code 간 데이터 연계, 모듈 간 전표 흐름, 비즈니스 로직 구조 — 을 이해하지는 못합니다. SAP 전문 도구와 범용 도구의 차이는 시나리오 구축 속도와 커버리지 깊이에 직접 영향을 미칩니다.
SAP 테스트는 단순히 "화면이 뜨는지" 확인하는 것이 아니라, 업무 프로세스 전체가 정상적으로 흘러가는지를 검증하는 것입니다. 도구가 SAP의 비즈니스 구조를 이해하지 못하면, 시나리오를 만드는 것 자체가 비효율적이 됩니다.
기준 ② 시나리오 구축 및 유지보수 효율
테스트 자동화의 장기적 성공은 초기 구축보다 지속적인 유지·확장에 달려 있습니다. 두 가지 관점에서 확인이 필요합니다.
첫째, 누가 시나리오를 만들고 수정할 수 있는가. 전문 개발자만 다룰 수 있는 도구라면, 시나리오 생성과 수정에 항상 개발 리소스 병목이 생깁니다. 비즈니스 담당자나 QA 엔지니어가 직접 다룰 수 있는 접근성이 확보되어야 자동화가 실무에 정착됩니다.
둘째, 시나리오 간 재사용 구조가 있는가. 반복되는 동작을 모듈화하여 여러 시나리오에서 재사용할 수 있는 구조가 없으면, 하나의 변경이 수백 곳의 수정으로 이어집니다.
기준 ③ 실행 방식의 안정성
S/4HANA 환경에서 반드시 확인해야 할 기준입니다. 분기별 Fiori 업데이트가 있을 때, 기존 테스트 스크립트가 그대로 작동하는가?
SAP는 분기마다 Fiori 앱을 업데이트하며, 그 과정에서 앱 ID 변경, 필드 추가·삭제, 화면 레이아웃 변경이 발생합니다. 만약 도구가 화면 UI에 의존하여 테스트를 실행한다면, 이런 변경이 있을 때마다 스크립트를 수정해야 합니다. 반대로 UI 변경에 영향받지 않는 실행 방식이라면 유지보수 부담이 근본적으로 줄어듭니다. 이 차이는 분기별 업그레이드가 반복되는 환경에서 누적 유지보수 비용을 결정짓는 구조적 차이입니다.
기준 ④ 대량 실행 속도
수백에서 수천 건의 회귀 테스트를 프로젝트 일정 내에 완료할 수 있는가? 도구에 따라 테스트 소요 시간이 수십 배까지 차이 날 수 있습니다.
업그레이드 일정 내에 테스트가 끝나지 않으면 Go-live를 지연시키거나, 검증 범위를 축소해야 합니다. 둘 다 비즈니스에 직접적인 리스크입니다. 도구 선택 단계에서 "우리 규모의 회귀 테스트를 현실적인 시간 내에 처리할 수 있는가"를 반드시 검증해야 합니다.
기준 ⑤ 테스트 데이터 확보 능력
앞서 확인했듯이 Cloud ALM에는 테스트 데이터를 준비하는 기능이 없습니다. 그렇다면 자동화 도구 차원에서, 또는 도구와 연계된 방식으로 이 공백을 메울 수 있는지 확인해야 합니다.
이전 시리즈 Migration 편에서 다뤘듯이, 샘플 데이터로는 운영 환경의 복잡성을 재현할 수 없습니다. 실제 거래 패턴과 예외 케이스를 포함한 운영 데이터를 테스트에 활용할 수 있는 경로가 있는지, 전환이나 업그레이드 때마다 데이터를 효율적으로 갱신할 수 있는지가 핵심입니다.
4. 정리: Cloud ALM + 테스트 자동화 도구 = 완성된 테스트 체계
Cloud ALM은 훌륭한 "지휘자"입니다. 테스트 계획, 추적성, 대시보드, 결함 관리 — 테스트 거버넌스의 핵심을 담당합니다. SolMan 시대에 엑셀로 관리하던 것과는 차원이 다른 체계를 제공합니다.
하지만 실제 테스트 "연주"는 별도 도구가 맡아야 합니다. 자동 테스트 스크립트 작성, 대량 회귀 테스트 실행, 테스트 데이터 준비 — 이 영역은 Cloud ALM의 설계 범위 밖에 있으며, 전용 테스트 자동화 도구가 채워야 할 공간입니다.
여기서 중요한 것은 관점의 전환입니다. "지휘자"에 맞춰 "연주자"를 선택하는 것이 아닙니다. 비즈니스가 요구하는 테스트 품질 기준으로 도구를 선택하고, 그 도구가 Cloud ALM과 잘 연동되는지를 확인하는 순서가 맞습니다. 앞서 제시한 5가지 기준이 그 판단의 출발점이 될 것입니다.
다음 편 예고:
이 기준들을 실무에 적용하면 어떤 모습이 될까요? 다음 편에서는 Cloud ALM 위에서 테스트 자동화를 실제로 구축하는 실전 가이드를 다룹니다. 오케스트레이션과 실행이 결합된 아키텍처, 각 기준을 충족하는 구체적인 도구 기능, 단계별 도입 로드맵, 그리고 기존 시리즈에서 다뤘던 Migration·Upgrade·E2E 전략이 이 체계 위에서 어떻게 실현되는지를 보여드리겠습니다.