RISE with SAP 마이그레이션 테스트, 실무에서 부딪히는 5가지 문제와 해법

RISE with SAP으로의 마이그레이션을 앞둔 테스트 담당자라면, 이런 질문들이 머릿속을 맴돌 것입니다. "Mock Conversion을 몇 번이나 해야 하지?", "커스텀 코드가 얼마나 깨질까?", "테스트 기간은 이미 빠듯한데 뭐부터 해야 하지?"

문제는, 이 질문들의 답이 기존 온프레미스 S/4HANA 전환 때와 다르다는 것입니다.

먼저 짚고 갈 것: RISE with SAP, 정확히 뭐가 달라지는가

RISE with SAP을 단순히 "SAP를 클라우드로 옮기는 것"으로 이해하면, 테스트 전략을 잘못 짜게 됩니다.

RISE with SAP은 SAP의 BTaaS(Business Transformation as a Service) 번들입니다. S/4HANA Cloud, 기술 인프라, 마이그레이션 도구, SAP BTP 등이 하나의 패키지로 제공됩니다. 대부분의 RISE 도입 기업이 선택하는 것은 S/4HANA Cloud, Private Edition인데, 여기서 "Private"이라는 단어가 많은 혼동을 만듭니다.

"Private Cloud"이니까 우리 클라우드 계정에서 운영하는 거 아닌가요?

아닙니다. RISE의 Private Cloud는 "고객 전용 환경(다른 고객과 분리)"이라는 의미이지, 고객이 인프라를 소유하거나 통제한다는 뜻이 아닙니다. 하이퍼스케일러(AWS, Azure, GCP) 계정은 SAP 명의이고, SAP가 OS, DB, 시스템 모니터링을 담당합니다. 고객은 OS나 DB에 직접 접근할 수 없습니다.

이것이 테스트에 미치는 결정적 영향은 두 가지입니다.

① 테스트 시스템을 직접 리프레시할 수 없습니다. 온프레미스에서는 Basis 담당자가 운영 데이터를 테스트 시스템에 바로 복사할 수 있었습니다. RISE에서는 SAP에 서비스 요청(SR)을 제출하고, 승인 후 SAP가 실행하고, 완료된 시스템을 인계받는 절차를 거쳐야 합니다.

② Go-live 이후에도 SAP 주도의 분기별 업그레이드가 이어집니다. 업그레이드 시점을 기업이 결정했던 온프레미스와 달리, RISE에서는 정기적인 회귀 테스트가 운영의 일부가 됩니다.

이 두 가지를 생각한다면, 아래 5가지 문제가 왜 RISE 환경에서 특히 심각한지 이해가 쉬워집니다.

1. Mock Conversion 할 때마다 테스트 스크립트가 깨진다

S/4HANA 마이그레이션은 Go-live 전 2~3회 Mock Conversion(전환 리허설)을 거칩니다. 매 전환마다 거래처 코드, 품목 번호, 조직 구조가 조정되면서 이전 사이클의 테스트 스크립트가 통째로 깨집니다.

RISE 환경에서는 앞서 설명한 리프레시 제약 때문에 이 문제가 더 커집니다. 테스트 데이터를 갱신하려면 SAP에 SR을 제출하고 기다려야 하므로, "데이터 바꾸고 바로 재실행"이 안 됩니다. 시간이 갈수록 전환 품질 검증보다 스크립트 수정에 더 많은 시간을 쏟게 됩니다.

대응법: 데이터와 스크립트를 분리하라

테스트 시나리오(업무 흐름 로직)와 테스트 데이터(거래처, 품목, 금액 등)를 완전히 분리하세요. 시나리오는 한 번 만들어 두고, 전환 사이클마다 새로운 데이터만 교체하여 재실행합니다.

데이터는 수작업으로 만들지 말고, 운영 시스템에서 실제 거래 데이터를 추출하세요. 실제 거래에는 특별 할인, 다중 통화, 복잡한 세금 조건 같은 예외 케이스가 이미 포함되어 있고, 전환 사이클마다 재추출하면 됩니다.

데이터 기반 테스트 전략의 구체적인 방법은 SAP Migration 데이터 전환 검증 전략을 참고하세요.
→ SAP S/4HANA 전환 시대, 테스트 전략은 어떻게 달라져야 할까

2. 커스텀 코드가 얼마나 깨질지 감이 안 온다

ECC 시스템에는 수년간 쌓인 Z 프로그램, User Exit, 커스텀 리포트가 수백~수천 개 존재합니다. S/4HANA에서는 BSEG, BSIK 같은 테이블이 통합되고 CDS View 기반으로 바뀌면서, 이 중 상당수가 호환되지 않거나 다르게 동작합니다.

RISE는 "Clean Core" 원칙을 강조합니다. SAP 표준에 맞추고, 남는 커스텀은 SAP BTP 확장으로 분리하라는 방향입니다. "일단 가져가고 나중에 정리하자"는 접근이 통하기 어렵습니다.

대응법: 4분류로 나누고 각각 다르게 테스트하라

SAP Custom Code Migration Worklist를 실행하여 호환되지 않는 코드 목록을 뽑고, 4가지로 분류하세요.

• 삭제 대상 — 사용 빈도 로그를 6개월 이상 분석하세요. 월간·분기별로만 실행되는 코드를 놓치면 Go-live 후 결산에서 터집니다.

• 리팩토링 대상 — 동일 입력 데이터에 대해 ECC와 S/4HANA 출력 결과가 같은지 비교 검증합니다.

• BTP 분리 대상 — 기존 ECC 내부 호출이 API 기반으로 바뀌므로, 네트워크 지연과 에러 처리까지 포함한 인터페이스 테스트가 추가로 필요합니다.

• 현행 유지 대상 — 회귀 테스트에 포함시켜 지속 검증합니다.

  

  ---

3. 인터페이스가 "성공"이라고 뜨는데 데이터는 망가져 있다

SAP는 혼자 돌아가지 않습니다. MES, WMS, CRM, 은행 EDI, BI 시스템 — 대규모 조직은 1,000개 이상의 인터페이스 포인트를 갖고 있습니다.

RISE로 가면 SAP가 하이퍼스케일러 위에 올라가므로, 기존 온프레미스 주변 시스템과의 네트워크 경로 자체가 바뀝니다. 같은 네트워크 안에 있던 것들이 전용 연결(Direct Connect, ExpressRoute 등)을 통해 통신하게 되면서, 기존에 없던 지연이나 타임아웃이 발생할 수 있습니다.

문제는 이런 오류가 겉으로 안 보인다는 것입니다. 최근 SAP Community에 보고된 RISE 전환 사례에서, SAP Analytics Cloud로의 데이터 Import Job은 "성공"으로 표시되었지만, 실제 데이터를 열어보니 값이 0으로 채워져 있거나 포맷이 달라져 있었습니다. 기술적으로 "전송 성공"이라서, 누군가 직접 열어보기 전까지는 아무도 몰랐던 것입니다.

대응법: 전송 성공이 아니라 비즈니스 결과를 검증하라

인터페이스 테스트는 3단계로 나눠서 봐야 합니다.

• 1단계 — 연결 확인: 네트워크 경로 변경 후 기본 통신(RFC, API Call)이 정상인지

• 2단계 — 데이터 정합성: 수신 시스템에서 데이터를 열어 포맷, 필드, 값이 정확한지

• 3단계 — 비즈니스 결과: 수신 시스템에서 후속 프로세스(회계 전표 생성, 재고 업데이트 등)가 정상적으로 이어지는지

인터페이스가 수백 개라면 이 3단계를 수작업으로 반복하는 건 불가능합니다. SAP 트랜잭션에서 시작해서 MES, WMS, 은행 시스템 등 연계 시스템의 후속 처리까지를 하나의 E2E 시나리오로 묶어 자동 실행하는 방식이 필요합니다. SAP 쪽만 자동화하고 수신 쪽은 사람이 확인하는 방식으로는, 가장 위험한 3단계(비즈니스 결과)에서 결국 누락이 생깁니다.

4. Go-live 후 첫 월말 결산이 최대 공포

마이그레이션에서 가장 많은 장애가 터지는 시점은 Go-live 직후가 아니라, 첫 번째 월말 결산입니다.

일상 트랜잭션(주문, 발주)은 전환 직후 테스트에서 대부분 잡힙니다. 하지만 자산 감가상각, 원가 정산, 외화 평가, 수익 인식은 한 달에 한 번 실행되고, 여러 모듈 데이터가 복합적으로 얽혀 있습니다. 대부분의 프로젝트에서는 시간 부족으로 "대표 트랜잭션 몇 건 넣고 결산 돌리기"에서 끝나는데, 이러면 데이터 볼륨에서 오는 성능 이슈와 특정 조건 조합의 계산 오류를 놓칩니다.

대응법: 결산 시나리오를 독립 테스트 패키지로 분리하라

월말 결산은 일반 E2E 테스트와 분리하여 별도로 관리하세요.

• 데이터: 운영 시스템에서 결산용 실데이터(자산 마스터, 원가 센터, 세금 코드, 환율)를 추출합니다. 샘플이 아니라 실제 볼륨을 반영해야 합니다.

• 시나리오: FI 결산만 단독 테스트하지 마세요. SD 매출 → MM 원가 → CO 정산 → FI 결산의 전체 흐름을 하나로 묶어야 모듈 간 데이터 전달 오류를 잡을 수 있습니다.

• 비교 검증: ECC 결산 결과와 S/4HANA 결산 결과를 건별로 대조합니다. 특히 ACDOCA(Universal Journal) 통합이 기존 리포트에 주는 영향을 반드시 확인하세요.

5. 테스트가 끝나지 않는다 — 분기별 업그레이드

온프레미스에서는 "지금은 안정화에 집중하고, 업그레이드는 내년에"가 가능했습니다. RISE Private Cloud에서는 SAP가 분기별 업그레이드를 제공합니다. Go-live로 마이그레이션 테스트가 끝나는 것이 아니라, 매 분기 회귀 테스트가 반복되는 구조입니다.

마이그레이션 단계에서 수작업으로 테스트했다면, 3개월 후 또 같은 규모의 테스트를 사람이 해야 합니다. 그래서 마이그레이션은 테스트 자동화 체계를 구축하는 최적의 타이밍이기도 합니다.

대응법: 마이그레이션 테스트 자산을 회귀 테스트 자산으로 전환하라

마이그레이션을 위해 만든 시나리오를 프로젝트 종료와 함께 버리지 마세요. 자동화 도구로 구축된 시나리오는 데이터만 교체하면 분기마다 재실행할 수 있습니다.

RISE와 함께 제공되는 Cloud ALM을 테스트 관리 플랫폼으로, 별도 자동화 도구를 실행 엔진으로 분리하는 구조를 마이그레이션 초기에 설계하세요.

Cloud ALM의 역할과 한계는 Cloud ALM 테스트 관리 분석을 참고하세요.
→ SAP Cloud ALM 테스트 관리, 어디까지 되고 무엇이 부족한가

분기별 업그레이드 테스트 전략은 S/4HANA Upgrade 테스트 전략을 참고하세요. →SAP 테스트 전략 (2) S/4HANA Upgrade

결론

RISE with SAP 마이그레이션은 기존 온프레미스 전환 경험을 그대로 적용할 수 없는 영역이 존재합니다. Mock Conversion마다 깨지는 스크립트, Clean Core가 요구하는 커스텀 코드 검증, 겉으로 성공인데 안은 틀어진 인터페이스, 재현하기 어려운 월말 결산 시나리오, 그리고 Go-live로 끝나지 않는 분기별 업그레이드 테스트.

이 다섯 가지를 프로젝트 초기부터 설계에 반영하면, "Go-live 후 되던 게 안 되는" 상황을 예방할 수 있습니다.

RISE와 GROW의 차이가 먼저 궁금하다면 RISE vs GROW 비교 가이드를 참고하세요. → SAP 클라우드 전환: RISE vs GROW

데이터 전환 검증 전략은 SAP Migration 테스트 전략을 참고하세요. → SAP S/4HANA 전환 시대, 테스트 전략은 어떻게 달라져야 할까

PerfecTwin 무료 데모를 신청하시면, RISE 환경에서 SAP부터 연계 시스템까지 운영 실데이터 기반 E2E 테스트 자동화가 어떻게 작동하는지 직접 확인하실 수 있습니다.