SAP 테스트 전략 (2) S/4HANA Upgrade

1편에서는 ECC에서 S/4HANA로의 대규모 Migration 테스트 전략으로, 대규모 데이터 전환 검증 전략에 대해 살펴봤습니다. 2편에서는 SAP S/4HANA 업그레이드 테스트 전략에 대해 알아보겠습니다.

SAP S/4HANA는 분기마다 새로운 릴리즈가 나옵니다. 많은 기업들이 정기적으로 Upgrade를 수행하지만, 매번 예상치 못한 문제로 업무가 중단되는 상황이 반복됩니다. 왜 이런 일이 계속 발생하는 걸까요?

이 글에서는 SAP S/4HANA Upgrade 시 자주 발생하는 문제와 원인, 그리고 분기별 반복 작업에 최적화된 검증 전략을 소개합니다.

S/4HANA Upgrade 시 자주 발생하는 문제들

SAP S/4HANA를 최신 릴리즈로 업그레이드한 후, 많은 기업들이 동일한 문제에 직면합니다.

현장에서 실제로 일어나는 일:

• 영업팀: Fiori 앱에서 판매오더 조회 시 "App ID not found" 오류로 화면이 열리지 않음

• 구매팀: 발주 승인 프로세스에서 특정 필드가 사라져 워크플로우 중단

• 재무팀: 외부 시스템과 연계된 API 호출이 실패하여 전표 생성 불가

• IT팀: 커스텀 리포트가 CDS View 변경으로 데이터를 가져오지 못함

이런 문제들은 단순한 버그가 아닙니다. SAP 릴리즈 변경 과정에서 구조적으로 발생하는 이슈들입니다.

왜 이런 일이 발생할까?

S/4HANA Upgrade 실패의 가장 흔한 세 가지 원인이 있습니다.

1. Fiori 앱 ID 변경 및 Deprecated 필드

SAP는 릴리즈마다 Fiori 앱을 개선합니다. 그 과정에서 앱 ID가 변경되거나 특정 필드가 Deprecated 처리됩니다.

문제 발생 시나리오:

• 이전 릴리즈: 판매오더 조회 앱 ID F1234

• 신규 릴리즈: 앱 ID가 F1234A로 변경

결과: 기존 즐겨찾기, 권한 설정, 커스텀 타일이 모두 작동 중단

사용자들은 업그레이드 후 로그인 했을 때 평소 쓰던 앱이 "존재하지 않는다"는 오류 메시지만 보게 됩니다. Deprecated 필드가 있는 경우 화면은 열리지만 저장 시 오류가 발생하여 업무가 중단됩니다.

2. CDS View 및 OData 서비스 버전 변경

S/4HANA는 CDS View와 OData 서비스를 통해 데이터를 제공합니다. 릴리즈가 바뀌면 이 구조가 변경됩니다.

변경 유형:

• CDS View 이름 변경: I_SalesOrder → I_SalesOrderTP

• 필드 추가/삭제: 필수 필드가 추가되거나 기존 필드가 제거됨

• OData 버전 업: V2 → V4로 전환되면서 호출 방식 변경

한 건의 CDS View 변경이 수십 개의 리포트와 대시보드, 외부 연계 API를 동시에 중단시킵니다.

3. GUI와 Fiori 간 동작 차이

SAP 시스템에서는 GUI(SAP GUI)와 Fiori 앱이 공존합니다. 릴리즈 변경 시 두 인터페이스 간 미묘한 동작 차이가 발생합니다.

실제 사례:

• GUI 트랜잭션 ME21N: 정상 작동

• Fiori 구매오더 생성 앱: 동일 조건에서 필수 입력값 검증 실패

원인: Fiori 앱은 새로운 검증 로직을 적용하지만, GUI는 이전 로직 유지

실제 업무는 GUI와 Fiori를 혼용하므로, 각 인터페이스를 분리하여 테스트하면 전환 지점에서 발생하는 오류를 발견할 수 없습니다.

이러한 문제들은 SAP 릴리즈가 바뀔 때마다 구조적으로 발생합니다. ECC에서 S/4HANA로의 전환과 달리, Upgrade는 시스템 구조가 아닌 기능과 인터페이스가 변경되면서 발생하는 문제입니다.

그렇다면 많은 기업들이 Upgrade 전에 테스트를 수행하는데, 왜 이런 문제들을 미리 발견하지 못할까요?

기존 테스트 방식의 한계

대부분의 기업은 SAP Upgrade 전에 테스트를 수행합니다. 하지만 동일한 문제가 반복되는 이유는 테스트 방식 자체에 근본적인 한계가 있기 때문입니다.

1. 릴리즈 영향 범위 파악 불가

SAP 릴리즈 노트는 수백 페이지에 달하지만, 변경 사항만 나열할 뿐 우리 회사 시스템에 실제로 어떤 영향을 주는지는 알 수 없습니다.

예시) 릴리즈 노트 예시: "SAP Note 12345: Pricing condition logic enhanced"

파악하기 어려운 것들:

• 우리 회사가 이 가격 조건 로직을 사용하는가?

• 사용한다면 어떤 거래 유형이 영향받는가? (일반 판매, 특별 할인, 계약 가격)

• 수백 개의 노트와 수천 개의 트랜잭션을 일일이 대조 필요 → 현실적으로 불가능

영향도를 확신할 수 없어 전체 회귀 테스트를 실행합니다. 문제는 불필요한 영역에 시간을 쏟다가 정작 중요한 영역을 놓쳐 Go-live 후 업무가 중단되는 경우가 발생한다는 점입니다.

2. GUI·Fiori·API 통합 검증 부재

실제 업무는 Fiori로 판매오더 초안을 생성하고, GUI로 복잡한 가격 조건을 수정한 뒤, API로 외부 시스템에 전송하는 식으로 GUI, Fiori, API를 복합적으로 사용합니다.

분리 테스트의 맹점:

하지만 대부분의 테스트는 각각을 분리하여 검증합니다. Fiori에서 GUI로 전환할 때 필드 불일치 오류가 발생하고, API 호출 시 Fiori나 GUI에서는 정상이던 데이터가 Validation 실패로 거부됩니다.

• GUI만 테스트: VA01 트랜잭션 정상 작동 확인

• Fiori만 테스트: 판매오더 Fiori 앱 정상 작동 확인

인터페이스 전환 지점의 오류는 통합 시나리오를 검증하지 않으면 Go-live 후에야 발견됩니다.

3. 경계값과 예외 케이스 검증 누락

릴리즈 변경으로 인한 오류는 정상 케이스보다 경계값이나 예외 케이스에서 더 자주 발생합니다.

경계값 및 예외 케이스:

• 수량 0개나 999,999개 같은 경계값

• 특별 할인과 다중 통화, 세금 면제가 조합된 예외 케이스

수작업으로 모든 경계값과 예외 케이스를 테스트하는 것은 불가능합니다. 정상 케이스만 확인하고 Go-live하면, 실제 운영에서 예외 상황이 발생할 때 검증 로직 변경으로 인한 오류가 폭발적으로 나타납니다.

이런 문제들을 어떻게 해결할 수 있을까요? S/4HANA Upgrade에 최적화된 네 가지 핵심 전략을 소개합니다.

효과적인 S/4HANA Upgrade 테스트 전략

기존 테스트 방식의 한계를 극복하기 위해서는 근본적으로 다른 접근이 필요합니다. 여기서 소개하는 세 가지 전략은 분기별 반복 Upgrade에 최적화된 방법들입니다.

전략 1: 릴리즈 비교 기반 영향 분석

첫 번째 전략은 "무엇이 바뀌었는지" 정확히 파악하는 것입니다.

자동 영향 분석이 작동하는 방식:

이전 릴리즈와 신규 릴리즈를 자동으로 비교합니다. 예를 들어 SAP 릴리즈 노트에서 "CDS View 이름이 I_SalesOrder에서 I_SalesOrderTP로 변경"을 감지하면, 우리 회사의 모든 커스텀 리포트를 자동으로 스캔합니다.

이 CDS View를 사용하는 리포트 20개를 찾아냅니다. 그다음 각 리포트의 사용 빈도를 분석하여 영향도를 자동 분류합니다.

• Critical: 매일 사용하는 필수 리포트

• High: 주간으로 사용하는 중요 리포트

• Medium: 월간으로 사용하는 리포트

• Low: 분기/연간으로 사용하는 리포트

기대 효과:

• 영향 받는 영역만 선별 테스트하여 불필요한 회귀 테스트 감축

• 수작업 매칭의 실수를 제거하고 모든 연관 기능을 자동 추적

• 다음 분기에도 동일한 프로세스 재사용 가능

실제 사례: 이번 릴리즈에서 CDS View 변경이 20건이어도, 우리가 실제로 사용하는 것은 3건입니다. 나머지 17건은 테스트 제외하여 시간 85% 단축.

전략 2: 선별 회귀팩 자동 생성

두 번째 전략은 전략 1의 영향 분석 결과를 활용하여 테스트팩을 자동으로 만드는 것입니다.

자동 생성 프로세스:

릴리즈 영향 분석 결과를 바탕으로 영향받는 모듈만 선별합니다. SD 모듈에서 5개 트랜잭션이 영향을 받지만 MM 모듈은 영향이 없다면, MM 테스트는 제외합니다.

우선순위에 따라 테스트 순서를 자동 구성합니다.

• Critical → 즉시 실행

• High → 1순위 실행

• Medium/Low → 순차 실행

선별 회귀는 실제 영향받는 핵심 영역에 집중하므로 시간과 비용을 대폭 절감하면서도 중요한 오류는 모두 발견합니다.

전략 3: Fiori + GUI 통합 시나리오 실행

세 번째 전략은 실제 사용자 동선 그대로 검증하는 것입니다.

통합 시나리오 예시:

각 인터페이스를 따로 테스트하면 정상이지만, 실제로 Fiori → GUI → API로 이어지는 업무 흐름에서는 데이터 불일치 오류가 발생합니다. 통합 시나리오 검증으로 인터페이스 전환 지점의 문제를 사전에 발견할 수 있습니다.

[판매 프로세스]

Fiori 앱에서 판매오더 초안 생성 → GUI VA02로 가격 조건 수정 → Fiori 앱에서 출하 처리 → GUI VF01로 청구서 발행 → API로 외부 회계 시스템 전송

[구매 프로세스]

Fiori 앱에서 구매요청 생성 → GUI ME21N으로 발주서 작성 → Fiori 앱에서 입고 확인 → API로 공급업체 포털 전송

릴리즈 변경 시 Fiori와 GUI 간 동작 차이가 가장 자주 문제를 일으키므로, 통합 시나리오 검증은 필수입니다.

이 세 가지 전략을 통해 S/4HANA Upgrade의 리스크를 최소화하고, 분기별 반복 작업의 효율성을 극대화할 수 있습니다.

결론

S/4HANA Upgrade는 분기별로 반복되지만, 체계적인 전략으로 안정적으로 수행할 수 있습니다.

성공적인 Upgrade를 위한 핵심:

✅ 릴리즈 영향 분석 자동화

전체가 아닌 영향 영역만 정확히 식별하여 테스트 시간 감축 및 비용 절감

✅ 선별 회귀 실행

우선순위 기반 검증으로 핵심 영역에 집중, 효율성 극대화

✅ Fiori + GUI + API 통합 검증

실제 업무 동선 그대로 테스트하여 인터페이스 전환 지점 오류 사전 탐지

이 세 가지 전략을 갖춘 체계적인 검증 체계를 통해 S/4HANA Upgrade의 리스크를 최소화하고, 분기별 반복 작업의 효율성을 극대화할 수 있습니다. 체계적인 준비와 자동화된 검증으로 안정적이고 효율적인 Upgrade를 실현하시기 바랍니다.