Cloud ALM 시대, SAP 테스트 자동화 구축 실전 가이드
지난 1편에서는 SolMan 종료와 Cloud ALM 전환이라는 구조적 변화 속에서 "왜 지금 테스트 전략을 다시 설계해야 하는가"를 다뤘습니다. 2편에서는 Cloud ALM의 테스트 관리 강점과 한계를 분석하고, 자동화 도구를 선택할 때 확인해야 할 5가지 핵심 기준을 제시했습니다.
이번 3편의 질문은 하나입니다. "우리 회사에 실제로 어떻게 적용하는가?"
기준은 이해했지만, 실무에 적용하려면 구체적인 그림이 필요합니다. Cloud ALM 위에서 테스트 자동화 도구가 어떤 역할을 하는지, 5가지 기준이 실제 업무 환경에서 어떻게 작동하는지, 그리고 어디서부터 시작해야 하는지를 이번 편에서 다룹니다.
1. 아키텍처 설계: 오케스트레이션과 실행의 분리 모델
2편에서 Cloud ALM은 "지휘자"이고 테스트 자동화 도구는 "연주자"라고 설명했습니다. 이 비유를 실제 아키텍처로 옮기면 다음과 같은 구조가 됩니다.
Cloud ALM 레이어 (오케스트레이션)
Cloud ALM은 테스트의 "무엇을, 왜, 언제" 하는지를 관리합니다. 비즈니스 프로세스와 요구사항을 테스트 케이스로 연결하고, 실행 상태를 추적하며, 결함을 관리합니다. SAP Activate 방법론에 따라 프로젝트 단계별 테스트 범위를 정의하고, 대시보드로 전체 진행 상황을 가시화합니다.
테스트 자동화 도구 레이어 (실행)
테스트 자동화 도구는 "어떻게" 테스트하는지를 담당합니다. 테스트 시나리오를 구축하고, 테스트 데이터를 준비하며, 수백~수천 건의 테스트를 실행하고, 결과를 검증합니다. Cloud ALM에서 생성한 테스트 케이스의 "껍데기" 안에 실제 실행 로직을 채우는 역할입니다.
두 레이어의 연결
두 레이어는 API로 연결되어 하나의 워크플로우로 작동합니다. Cloud ALM에서 테스트 실행을 트리거하면 자동화 도구가 시나리오를 실행하고, 결과가 Cloud ALM 대시보드에 자동으로 반영됩니다.
이 분리 모델의 핵심 장점은 각 레이어를 독립적으로 최적화할 수 있다는 점입니다. Cloud ALM은 거버넌스에 집중하고, 자동화 도구는 실행력에 집중합니다. 나중에 ALM 플랫폼이 변경되더라도 자동화 도구에 축적된 테스트 시나리오, 데이터, 실행 이력 등의 테스트 자산은 그대로 보존됩니다.
그렇다면 이 "실행" 레이어에서 2편의 5가지 기준이 실무에서 어떻게 작동할까요?
2. 5가지 기준의 실무 적용: PerfecTwin을 사례로
2편에서 제시한 5가지 선택 기준을 추상적으로 두지 않고, SAP 특화 테스트 자동화 도구 PerfecTwin을 사례로 각 기준이 실무에서 어떻게 작동하는지 구체적으로 살펴보겠습니다.
기준 ① SAP 전문성 — SAP 컴포넌트를 위해 만든 도구의 차이
2편에서 첫 번째 기준으로 제시한 것은 도구가 SAP를 얼마나 깊이 이해하는가였습니다.
범용 자동화 도구는 SAP 화면을 일반 웹 페이지나 데스크톱 애플리케이션과 동일하게 취급합니다. 화면의 버튼, 텍스트 필드, 드롭다운을 일반적인 UI 요소로 인식할 뿐입니다. 하지만 SAP 화면에는 일반 웹과 다른 고유한 컴포넌트들이 존재합니다. ALV 그리드, 트리 구조, 탭 스트립, SAP 고유의 팝업과 메시지 처리 방식 등이 그렇습니다. 범용 도구는 이런 SAP 고유 컴포넌트 앞에서 제대로 동작하지 못하거나, 별도의 복잡한 설정을 요구합니다.
PerfecTwin은 처음부터 SAP 컴포넌트를 대상으로 개발된 도구입니다. SAP 고유의 모든 UI 컴포넌트에 완전히 대응하며, 각 필드의 내부 정보(필드 타입, 입력 조건, 필수값 여부, 연관 테이블 등)를 보유하고 있습니다. 이 때문에 테스트 실행 시, 즉 시나리오를 재현할 때 단순 UI 리플레이에서 흔히 발생하는 오류들 — 필드 인식 실패, 팝업 미처리, 동적 화면 전환 오류 등 — 이 원천적으로 발생하지 않습니다.
이 SAP 전문성이 시나리오 구축에서도 직접적인 차이를 만듭니다. PerfecTwin은 SAP 표준 업무 프로세스(O2C, P2P, R2R 등)를 Pre-built 템플릿으로 제공합니다. 처음부터 시나리오를 설계할 필요 없이, 이미 검증된 템플릿을 기반으로 자사 프로세스에 맞게 커스터마이징하면 됩니다. SAP 프로세스 구조를 깊이 이해하고 있기 때문에 가능한 접근이며, 초기 구축 시간을 최대 70% 단축할 수 있는 구조입니다.
기준 ② 시나리오 구축 및 유지보수 효율성 — 유닛 기반 노코드 시스템
2편의 두 번째 기준은 "누가 시나리오를 만들 수 있는가"와 "재사용 구조가 있는가"였습니다.
PerfecTwin의 유닛(Unit) 시스템은 이 두 가지 질문에 동시에 답합니다.
유닛은 테스트 시나리오의 가장 기본적인 빌딩 블록입니다. 하나의 유닛은 "VA01에서 판매오더 생성", "VL01N에서 출하 지시", "VF01에서 청구서 발행"과 같은 단일 업무 단위를 담고 있습니다. 사용자는 이 유닛들을 드래그앤드롭으로 조립하여 E2E 시나리오를 구성합니다. 코딩이 필요 없기 때문에 개발자가 아닌 QA 담당자나 현업 사용자도 직접 시나리오를 구축하고 수정할 수 있습니다.
이 원리는 시나리오 기반 E2E 테스트 설계 가이드에서 다뤘던 "공통 컴포넌트 분리" 전략과 정확히 같습니다. 로그인, 조직 코드 입력, 마스터 데이터 조회 등 모든 테스트에서 반복되는 동작을 하나의 '부품'으로 만들어, 하나의 유닛만 수정하면 이를 사용하는 모든 시나리오에 자동 반영됩니다.
유닛은 팀 단위로 공유됩니다. 한 팀원이 만든 유닛을 다른 팀원이 자신의 시나리오에서 재사용할 수 있어, 팀 전체의 생산성이 시나리오가 축적될수록 올라갑니다.
이 구조가 장기적으로 중요한 이유는 유지보수 비용 때문입니다. S/4HANA 환경에서는 분기마다 업그레이드가 반복되고, 비즈니스 프로세스도 변경됩니다. 테스트 자동화의 진짜 비용은 초기 구축이 아니라 이후의 유지보수에서 발생합니다. 유닛 기반 구조에서는 변경이 발생한 유닛 하나만 수정하면 해당 유닛을 사용하는 모든 시나리오에 자동 반영되므로, 수백 개의 스크립트를 일일이 고치는 상황을 원천적으로 방지합니다. 분기별 업그레이드가 반복될수록 이 누적 효율 차이는 점점 더 커집니다.
기준 ③ 실행 안정성 — 백엔드 직접 전송 방식
2편의 세 번째 기준은 "Fiori가 분기마다 업데이트될 때, 기존 테스트 스크립트가 여전히 작동하는가"였습니다.
대부분의 테스트 자동화 도구는 UI 리플레이 방식으로 작동합니다. 사용자가 화면에서 수행한 동작을 녹화하고, 이를 그대로 재생하여 테스트합니다. 직관적이지만 구조적 한계가 있습니다. SAP가 분기별 릴리즈를 통해 Fiori 앱 ID를 변경하거나, 필드를 추가·삭제하거나, 화면 레이아웃을 조정하면, UI에 의존하는 스크립트는 즉시 깨집니다. S/4HANA Upgrade 테스트 전략에서 다뤘던 Fiori 앱 ID 변경, Deprecated 필드 문제가 바로 이 지점에서 발생합니다.
PerfecTwin은 백엔드 직접 전송(Backend Direct Transmission) 방식을 사용합니다. UI를 거치지 않고 SAP 백엔드 시스템에 직접 트랜잭션 데이터를 전송하여 테스트를 실행합니다.
백엔드 직접 전송은 UI 변경과 무관하게 작동합니다. Fiori 앱 ID가 바뀌든, 필드 레이아웃이 변경되든, 백엔드 비즈니스 로직이 동일하면 테스트 시나리오는 그대로 유효합니다. 분기마다 Fiori가 업데이트되는 S/4HANA 환경에서 "업그레이드할 때마다 깨진 스크립트를 수정하는" 반복 작업 자체가 사라집니다. 자동화 도구를 도입한 목적 — 반복 작업의 제거 — 이 실행 방식 차원에서 보장되는 것입니다.
기준 ④ 대량 실행 속도 — 프로젝트 일정을 좌우하는 현실적 차이
2편의 네 번째 기준은 "수백~수천 건의 회귀 테스트를 프로젝트 일정 내에 완료할 수 있는가"였습니다.
UI 리플레이 방식은 사람이 화면을 조작하는 속도를 시뮬레이션하므로, 테스트 한 건당 수 분이 걸립니다. 반면 백엔드 직접 전송 방식은 UI 렌더링 과정을 건너뛰고 데이터를 직접 처리하므로, 건당 수 초 단위로 실행됩니다.
이 속도 차이를 구체적인 숫자로 비교해 보겠습니다. 분기별 S/4HANA 업그레이드 시 500건의 회귀 테스트를 실행한다고 가정합니다.
UI 리플레이 방식(건당 평균 5분): 500건 × 5분 = 약 42시간 (5일 이상)
백엔드 직접 전송 방식(건당 평균 수 초): 500건을 하루 이내에 완료
PerfecTwin의 백엔드 전송 방식은 UI 기반 도구 대비 최대 50배 빠른 실행 속도를 보여줍니다.
업그레이드 일정은 보통 주말이나 연휴에 맞춰 빠듯하게 잡힙니다. 테스트 실행 자체가 5일 이상 걸린다면, 선택지는 두 가지뿐입니다. Go-live를 지연하거나, 테스트 범위를 줄이거나. 둘 다 비즈니스 리스크입니다.
실행 속도는 단순한 편의성이 아니라 프로젝트 일정과 테스트 커버리지를 동시에 확보할 수 있는지를 결정하는 핵심 요소입니다.
기준 ⑤ 테스트 데이터 확보 — Data Extractor로 Cloud ALM의 공백을 채우다
2편의 다섯 번째 기준은 "Cloud ALM에 없는 테스트 데이터 준비 기능을 어떻게 해결하는가"였습니다.
ECC to S/4HANA Migration 테스트 전략에서 상세히 다뤘듯이, 샘플 데이터로는 실제 운영 환경의 복잡성을 재현할 수 없습니다. 수천 개의 거래처, 수만 개의 품목, 다중 통화와 특수 세금이 조합된 실제 거래 패턴은 샘플 데이터에 존재하지 않습니다.
PerfecTwin의 Data Extractor는 이 문제를 직접 해결합니다. 운영 환경의 실제 거래 데이터를 조회하고 추출하여 테스트 데이터로 활용할 수 있는 기능을 제공합니다. 업무 유형과 추출 기간을 설정하면, 해당 조건에 맞는 실제 거래 데이터를 운영 DB에서 가져옵니다.
이 데이터에는 실제 업무에서 발생한 다양한 경우의 수가 포함됩니다. 특별 할인이 적용된 거래, 다중 통화로 결제된 거래, 복잡한 세금이 계산된 거래, 반품과 취소가 발생한 예외 케이스까지. 의도적으로 설계한 샘플이 아니라, 실제로 일어난 거래이기 때문에 현실의 복잡성이 그대로 반영됩니다.
특히 Migration이나 Upgrade 프로젝트에서는 전환 사이클마다 데이터가 달라집니다. Data Extractor를 사용하면 매번 새로운 데이터를 재추출하여 테스트에 적용하면 되므로, 최신 데이터로 검증을 반복할 수 있습니다.
3. 도입 로드맵: 어디서부터 시작하는가
5가지 기준이 실무에서 어떻게 작동하는지 확인했다면, 다음 질문은 "우리 회사에서 어떤 순서로 도입하는가"입니다.
한 번에 모든 것을 구축하려는 접근은 현실적이지 않습니다. S/4HANA 전환이나 업그레이드 프로젝트 자체만으로도 일정이 빠듯한데, 테스트 자동화 인프라까지 동시에 완성하려 하면 결국 어느 쪽도 제대로 되지 않습니다. 단계별 접근이 필요합니다.
Phase 1: 파일럿 (1~2개월)
목표: 핵심 프로세스 3~5개로 작동 검증
가장 빈도가 높고 비즈니스 영향이 큰 프로세스를 선정합니다. 예를 들어 O2C(주문-수금), P2P(구매-지급), 월말 결산 프로세스 등입니다.
이 프로세스들에 대해 PerfecTwin의 Pre-built 템플릿을 기반으로 시나리오를 구축하고, Data Extractor로 운영 데이터를 연결하여 실행합니다. Cloud ALM 테스트 관리 앱과의 연동도 이 단계에서 확인합니다.
파일럿의 핵심은 "우리 환경에서 작동하는가"를 가장 적은 비용으로 검증하는 것입니다.
Phase 2: 확장 (2~3개월)
목표: 전체 E2E 시나리오 커버리지 확보, 팀 역량 내재화
파일럿에서 검증된 방식을 전체 핵심 비즈니스 프로세스로 확장합니다. 팀원들에게 유닛 시스템 교육을 진행하고, 각 팀원이 자신의 담당 업무 영역에서 유닛을 직접 만들기 시작합니다.
이 단계에서 유닛 라이브러리가 본격적으로 축적됩니다. 한 팀원이 만든 "거래처 마스터 조회" 유닛을 SD, MM, FI 담당자가 각자의 시나리오에서 재사용하면서, 개별적으로 시나리오를 만들 때보다 구축 속도가 점점 빨라집니다.
Phase 3: 자산화 (3개월~)
목표: 지속 가능한 테스트 자동화 체계 완성
축적된 시나리오와 유닛이 조직의 테스트 자산이 됩니다. 분기별 업그레이드 시 회귀 테스트가 자동으로 실행되는 루틴이 정착되고, Cloud ALM 대시보드에서 테스트 진행 상황과 결과를 실시간으로 확인할 수 있습니다.
이 단계에서 기존 시리즈에서 다뤘던 전략들이 하나의 체계 위에서 실현됩니다. Migration 테스트 전략의 운영 실데이터 기반 검증은 Data Extractor가, Upgrade 테스트 전략의 선별 회귀 테스트는 백엔드 직접 전송이, 시나리오 기반 E2E 설계의 공통 컴포넌트 재사용은 유닛 시스템이 각각 담당합니다. 그리고 Cloud ALM이 이 모든 것의 계획·추적·보고를 오케스트레이션합니다.
결론: ALM 전환은 위기가 아니라 기회
SolMan에서 Cloud ALM으로의 전환을 "해야 할 숙제"로만 바라보면, 기존 체계를 그대로 옮기는 데 급급해집니다.
하지만 시각을 바꾸면, 이 전환은 테스트 체계를 근본적으로 재설계할 수 있는 드문 기회입니다.
많은 기업이 SolMan 시대에도 엑셀 기반의 수동 관리에서 벗어나지 못했습니다. Cloud ALM 전환은 이 관행을 끊고, 체계적이고 자동화된 테스트 프레임워크를 새로 세울 수 있는 시점입니다.
Cloud ALM이 테스트 거버넌스를 담당하고, 그 위에 PerfecTwin의 실행력이 결합되면 완성된 SAP 테스트 체계가 만들어집니다. 계획과 추적은 Cloud ALM이, 시나리오 구축과 데이터 준비, 대량 실행과 결과 검증은 PerfecTwin이 맡는 구조입니다.
이 체계 위에서 Migration 검증, 분기별 Upgrade 회귀 테스트, 크로스 모듈 E2E 검증이 모두 하나의 프레임워크 안에서 실행됩니다. 더 이상 프로젝트마다 새로운 테스트 환경을 셋업하거나, 엑셀에서 테스트 케이스를 관리하거나, 수작업으로 수백 건의 테스트를 실행할 필요가 없습니다.
2027년까지 남은 시간이 점점 줄어들고 있습니다. 지금이 시작할 때입니다.
[다음 편 예고] "좋은 건 알겠는데, 우리가 이걸 직접 할 수 있을까?" 4편에서는 S/4HANA 전환 프로젝트만으로도 벅찬 기업이 Cloud ALM 셋업부터 테스트 자동화 구축까지 전문가에게 맡기고, 작동하는 상태로 인수받는 턴키 접근법을 소개합니다.
PerfecTwin이 Cloud ALM 환경에서 어떻게 작동하는지 직접 확인하고 싶으신가요? 무료 데모 신청하기 → Click
[관련 포스트]
SAP 테스트 케이스 설계: 시나리오 기반 E2E 테스트 가이드
SAP 테스트 전략 (1): ECC to S/4HANA Migration
SAP 테스트 전략 (2): S/4HANA Upgrade