SAP 성능 테스트: IT 리더가 알아야 할 것

SAP 성능 테스트는 Go-Live 전에, 핵심 트랜잭션과 백그라운드 잡, 인터페이스가 운영 물량에서 합의된 응답 시간을 충족함을 입증하는 일입니다. 설계 단계에서 시작하고, 구성이 안정된 Realize 단계에서 볼륨 테스트와 부하 테스트를 수행하며, 사용자 인수 테스트(UAT) 전에 사이클을 마치고, 그 결과를 컷오버 게이트로 삼으십시오. 이 가이드는 RISE with SAP를 포함한 S/4HANA 프로젝트의 CIO, 프로그램 디렉터, 테스트 리드를 위한 것입니다. 무엇을 테스트할지, 누가 책임지는지, 합격 기준을 어떻게 쓰는지, 클라우드에서 무엇이 달라지는지를 다룹니다. 합격 기준 표부터 시작하십시오. 그 표를 채울 수 없다면 테스트할 준비가 되지 않은 것입니다.

SAP 프로젝트의 성능 문제는 거의 언제나 Go-Live 이후에 발견됩니다. 교대 시간에 300명이 동시에 로그인하면 Fiori 타일이 타임아웃됩니다. 누군가 5,000만 건의 레코드가 있는 테이블에 범위를 제한하지 않고 회계연도 전체를 조회하면 Z 리포트가 멈춥니다. 월 마감 중에 백그라운드 잡이 겹치면서 전기 실행이 중단됩니다.

SAP 프로젝트의 성능 문제는 갑작스럽게 찾아오는 경우가 드뭅니다. 대부분 예측할 수 있었는데 대비하지 않았을 뿐입니다. 흔한 패턴은 이렇습니다. 기능 테스트는 철저했습니다. 볼륨 테스트는 계획되어 있었지만, 일정이 빠듯해지자 뒤로 밀렸습니다. 그 결과는 가동 첫 몇 주 안에 닥쳤습니다.

이것들은 예외적인 경우가 아닙니다. 예측할 수 있는 일입니다. 남은 질문은 프로젝트가 미리 테스트했는지, 아니면 실제 주문이 돌아가는 상황에서 현업이 발견하는지 하나뿐입니다.

SAP Activate 전반의 성능 테스트

1. 01

   Explore

   설계 단계에서 성능 리스크를 식별합니다. 아키텍처와 리포트 구조가 코드를 쓰기도 전에 결과를 좌우합니다.

2. 02

   Realize

   구성이 안정되는 대로 볼륨 테스트와 부하 테스트를 수행합니다. 구성이 미완성이면 오해를 부르는 결과가 나옵니다.

3. 03

   UAT 전

   전체 성능 테스트 사이클을 UAT의 일부로 하지 말고 UAT 전에 끝냅니다.

4. 04

   컷오버

   의견이 아니라 사전에 합의한 합격 기준에 따라 컷오버를 승인합니다.

5. 05

   하이퍼케어

   실가동 KPI를 30일에서 60일 동안 지켜봅니다. 대부분의 성능 저하는 첫 마감 사이클에서 드러납니다.

기존 데이터베이스 위에서 돌아가는 ECC 시스템에서 성능 테스트란 애플리케이션 서버와 데이터베이스를 부하 테스트하는 것이었습니다. ABAP 런타임, SQL 성능, 잡 스케줄링이 대상이었습니다. 프런트엔드는 SAP GUI였고, 이쪽에서 놀랄 일은 드물었습니다.

Fiori 프런트엔드, SAP BTP 확장, SAP Cloud Integration(CPI)을 통한 연계가 있는 S/4HANA에서는 성능이 여러 계층에 동시에 좌우됩니다. 느린 Fiori 타일의 원인은 오래 걸리는 ABAP 호출일 수도, 게이트웨이 타임아웃일 수도, 동시 요청을 염두에 두지 않고 설계된 OData 서비스일 수도, 하이브리드 구성의 네트워크 지연일 수도 있습니다. 백엔드만 테스트해서는 찾지 못합니다. 전체 경로를 테스트해야 찾을 수 있습니다.

1. 01타일 실행교대 시작 시점의 로그인 폭주
2. 02OData 호출게이트웨이 타임아웃, 동시성을 고려하지 않은 서비스
3. 03ABAP 처리오래 걸리는 ABAP 호출
4. 04데이터베이스 읽기대용량 테이블에 대한 조건 없는 조회
5. 05렌더링원거리 사이트의 네트워크 지연까지 더해짐

엔드투엔드로 측정하는 하나의 응답 시간

연계 플로는 고유한 리스크를 더합니다. 개발과 QA에서 테스트 메시지 한 건으로는 잘 돌던 플로가 운영 물량에서는 대기열에 쌓이거나 아무 신호 없이 실패할 수 있습니다. 메시지 큐의 크기가 실제 부하에 맞게 잡혀 있지 않으면 지연이 누적됩니다. 증상은 다른 문제처럼 보입니다. 간헐적인 주문 실패, 송장 불일치, 한 시스템에는 있는데 다른 시스템에는 없는 데이터입니다.

1. 부하 테스트는 예상 물량에서의 동작을 확인합니다. 핵심 단어는 ‘예상’입니다. 실제 트랜잭션 물량, 사용자 수, 동시 세션이 필요합니다. 많은 부하 테스트가 실패합니다. 모두가 이미 낙관적이라고 알고 있던 물량 추정치를 썼기 때문입니다.
2. 스트레스 테스트는 설계 한계를 넘어 시스템이 어디서 무너지는지 찾습니다. 물량이 18개월 안에 두 배가 될 예정이라면, 아키텍처가 이를 감당할지, 그리고 다음 인프라 검토 전에 사이징이 문제가 될지를 알려 줍니다.
3. 소크 테스트는 일정한 부하를 장시간 걸어, 시간이 지나며 쌓이는 문제를 드러냅니다. 메모리 누수, 단편화, 반복 실행 시 잡 체인 간 경합이 그것입니다. 가장 자주 생략되는 테스트이며, 아래에 설명하는 월 마감 장애를 잡아낼 수 있었을 테스트입니다.
4. 엔드투엔드 테스트는 사용자가 거치는 전체 경로를 따라갑니다. 타일 실행, OData 호출, ABAP 처리, 데이터베이스 읽기, 렌더링입니다. 각 계층을 따로 테스트할 때는 보이지 않는 문제를 찾아내는 유일한 방법입니다.

교대 시간과 피크 로그인. 오전 8시에 200명이 Fiori 런치패드를 열면 인증과 런치패드 렌더링 부하가 급증합니다. 비피크 시간대에는 문제없던 시스템도 동시 로그인을 한 번도 테스트하지 않았다면 그 시간대에는 쓸 수 없게 될 수 있습니다. 제조, 유통, 금융 서비스 전반에서 로그인 폭주는 가동 첫날 가장 눈에 띄는 불만을 낳습니다.

월 마감과 연 마감. 대부분의 프로젝트에서 리스크가 가장 큰 시나리오입니다. 대량 전기, 순서가 엄격한 잡 체인, 고정된 마감 시한에 쫓기는 재무팀이 겹칩니다. 마감 잡 체인은 일평균 건수가 아니라 마감 기간의 물량으로 처음부터 끝까지 실행해 보십시오.

배치 잡은 보통 개별적으로 테스트하는데, 이는 현실을 반영하지 못합니다. 월말에는 백그라운드 처리가 정점에 이르고, 많은 프로그램이 같은 자원을 놓고 병렬로 실행됩니다. 최적화가 부족한 잡 하나가 다섯 개의 다른 잡을 막을 수 있고, 마감은 정해진 시간대를 넘겨 버립니다.

ECC에서 S/4HANA로의 전환. 안정적이던 ECC 코드도 HANA에서는 다르게 동작합니다. 많은 프로그램이 훨씬 빨라지지만, 일부는 특정 데이터 패턴에서 예상치 못한 실행 프로파일을 보입니다. 전환에 특화된 회귀 테스트는 선택 사항이 아닙니다. 이것이 전환 계획의 어디에 들어가는지는 제 ECC에서 S/4HANA로의 마이그레이션 가이드에서 다룹니다.

여러 지역의 사용자. 네트워크 지연은 모든 트랜잭션에 영향을 줍니다. 호스팅 국가에서 2초가 걸리는 판매 오더가, 아무도 그곳에서 테스트해 보지 않았다면 3,000마일 떨어진 곳에서는 고장 난 것처럼 느껴질 수 있습니다. RISE는 호스팅을 SAP로 옮기지만, 지연 시간은 여전히 선택한 리전과 사용자까지의 라우팅에 달려 있습니다.

어떤 테스트든 실행하기 전, Prepare 단계에서 현업과 기준을 합의하십시오. 각 기준에는 트랜잭션 또는 잡, 부하, 임계값이 명시됩니다. 아래 예시는 형식을 보여 줄 뿐이며, 숫자는 운영상의 필요에 따라 직접 정하십시오.

항목	부하 조건	합격 임계값	책임자
판매 오더 생성(VA01 또는 Fiori 앱)	오더 입력 사용자 150명 동시 접속	트랜잭션의 95%가 3초 이내	주문-수금 프로세스 오너
교대 시작 시점의 Fiori 런치패드 최초 로딩	가장 큰 교대조의 피크 동시 로그인	사용자의 95%가 5초 이내	IT 운영 리드
월 마감 잡 체인	마감 기간 물량, 전체 시퀀스	중단 없이 합의된 마감 시간대 안에 완료	재무 컨트롤러
인바운드 주문 인터페이스	시간당 피크 메시지 물량	15분보다 오래된 큐 적체 없음	연계 리드
대용량 커스텀 리포트	운영 데이터 전체 물량, 일반적인 선택 조건	60초 이내, 조건 제한이 없는 조회는 차단	리포트 오너

“시스템은 업무 운영에 충분히 빨라야 한다”는 테스트할 수도, 인수할 수도 없습니다. 결과가 나온 뒤에 기준을 바꾸면 기준을 두는 의미가 사라집니다.

다음 항목을 하나씩 이름을 들어 요구하십시오.

기대 사항	제공되어야 할 것	중요한 이유
성능 서비스 수준	트랜잭션, 인터페이스, 잡별 임계값과 합격 및 불합격 판정 기준	UAT의 의견이 증거를 덮어쓰는 일을 막음
리스크 기반 범위	사용자 수, 연계 지점, 데이터 의존성에 따른 우선순위	테스트 사이클을 중요한 워크로드에 집중
팀 간 참여	실행 중 Basis, 인프라, 기능, 보안, 연계 담당이 함께 참석	문제가 드러났을 때 책임 떠넘기기를 방지
도구와 환경 준비	사이클 시작 전에 부하 생성기(OpenText LoadRunner, Tricentis NeoLoad, Apache JMeter), 모니터링, 데이터 리프레시가 갖춰져 있을 것	시뮬레이션을 현실적으로 만듦
현실적인 테스트 데이터	운영 물량 수준의 마스터 데이터, 실제 인터페이스 호출, 대표성 있는 트랜잭션 구성	결과가 Go-Live 이후 동작을 예측하게 함
성능 리포팅	부하 구성, 응답 시간, CPU 및 메모리, 잡 실행 시간, 오류율	컷오버 승인에 증거 기반을 제공
Go-Live 이후 모니터링 계획	처음 30~60일 동안 지켜볼 KPI	실가동 시스템이 테스트한 한계 안에 머무는지 확인

성숙한 딜리버리 모델을 갖춘 대기업에서도 가장 자주 나오는 실수는 네 가지입니다.

기능 테스트를 성능 테스트로 취급하는 것. 기능 테스트는 트랜잭션이 올바른 결과를 내는지를 입증합니다. 150명이 동시에 실행할 때의 일은 아무것도 말해 주지 않습니다.

적은 데이터 물량으로 테스트하는 것. 미결 주문 라인이 200,000개인 고객은 5,000개인 고객과 다르게 동작합니다. 테스트에서는 즉시 결과가 나오던 필터가 운영에서는 타임아웃됩니다. 고위험 영역에는 물량을 미리 채워 두십시오.

성능을 Basis에 맡겨 두는 것. Basis는 사이징과 잡 스케줄링을 책임집니다. 리포트 설계, OData 서비스 아키텍처, 연계 플로 설계는 Basis의 소관이 아닌데, 애플리케이션 성능을 좌우하는 것은 바로 그것들입니다.

책임을 QA에만 주는 것. QA는 테스트를 실행하고 결과를 보고합니다. 성능 문제를 일으키는 결정은 설계 단계에서 기능, 기술, Basis 팀이 내립니다. 프로젝트 차원의 테스트 리드나 아키텍트에게 그런 결정에 일찍 이의를 제기할 권한이 있어야 하며, RACI에는 성능을 이유로 Go-Live를 막을 수 있는 사람이 누구인지 적혀 있어야 합니다.

RISE는 책임을 나눕니다

RISE with SAP에서 인프라는 SAP가 책임집니다. 사이징, 하이퍼스케일러 리전, 네트워크, 플랫폼 가용성이 여기에 속합니다. 애플리케이션 계층은 고객과 파트너의 몫입니다. SAP의 RISE 역할 및 책임 문서는 이 점을 분명하게 밝힙니다. 비용이 큰 SQL 문을 찾아 튜닝하는 일은 SAP의 추가 애플리케이션 서비스를 구매하지 않는 한 고객에게 남습니다.

RISE 프로젝트에서 흔한 실패는 SAP가 인프라를 운영하니 성능 문제도 잡아 줄 것이라는 가정입니다. SAP는 인프라 문제는 잡아냅니다. 잘못 설계된 OData 서비스, 비효율적인 ABAP 잡, 확장되지 않는 연계 플로는 잡아내지 못합니다. 이 역할 분담을 헌장과 테스트 계획에 명시하십시오.

1. SAP: 인프라 가용성과 플랫폼 수준의 응답
2. 파트너: 확장과 연계 플로를 포함해, 정의된 부하에서의 애플리케이션 성능
3. 고객: 마감 소요 시간, 주문 처리량 같은 프로세스 수준의 성과, 그리고 인수 결정

Public Edition과 GROW는 범위를 좁힙니다

보통 GROW with SAP를 통해 구매하는 S/4HANA Cloud Public Edition에서는, SAP가 자체 제품 표준의 일환으로 멀티테넌트 플랫폼의 성능 테스트를 수행하며, 고객이 공유 시스템에 부하 테스트를 하기를 기대하지 않습니다. 고객의 테스트는 고객 몫인 영역으로 옮겨 갑니다. 커스텀 연계, 확장, 대용량 리포트와 분석, 마감 및 연결 결산 시퀀스, 그리고 각 사이트에서 오는 네트워크 경로입니다. 플랫폼 자체의 성능 문제는 SAP 지원으로 넘깁니다.

AI는 스크립트에는 도움이 되지만 아키텍처에는 아닙니다

부하 테스트 벤더들은 스크립트 유지보수와 결과 분석에 AI를 추가하고 있으며, 사이클 사이에 애플리케이션이 바뀌는 프로젝트에서는 도움이 됩니다. 비용을 지불하기 전에 자사 시스템 환경에서 그 주장을 직접 검증하십시오. SAP Cloud ALM은 테스트 케이스와 요구사항 생성을 도울 수 있고, AI 어시스턴트는 프로세스 설명에서 시나리오 초안을 작성해 줄 수 있습니다.

이 중 어느 것도 아키텍처를 고쳐 주지는 않습니다. OData 서비스를 다르게 설계했어야 했다거나, 리포트가 감당할 물량에 비해 너무 무겁다는 것을 AI가 알려 주지는 않습니다. 그런 판단은 여전히 사람이, 어떤 테스트도 실행되기 전의 설계 단계에서 내립니다.

운영에서 성능 문제를 겪는 프로젝트 대부분은 테스트를 완전히 생략한 것이 아닙니다. 합의된 기준 없이 테스트했거나, 테스트를 하고도 일정 압박 속에서 그 격차를 알려진 이슈로 받아들였습니다. 핵심은 도구가 아니라 기준과 그 기준의 집행에 있습니다. 성능이 다른 테스트 유형 사이에서 어디에 놓이는지는 제 SAP 테스트 및 검증 도구 비교와 SAP 품질 게이트 가이드를 참고하십시오.

SAP 성능 테스트란 무엇이며 왜 중요합니까?

현실적인 부하에서 SAP가 어떻게 동작하는지 확인합니다. 사용자 트랜잭션의 응답 시간, 백그라운드 잡의 실행 시간, 인터페이스의 처리량, 동시 작업 시의 자원 사용량이 대상입니다.

기능적 정확성과 성능은 서로 다른 속성입니다. 사용자 한 명에게는 올바르게 동작하는 트랜잭션도 200명에게는 타임아웃될 수 있습니다. 테스트 데이터로는 10분 걸리던 잡이 운영 물량에서는 몇 시간씩 돌 수 있습니다. 이것을 Go-Live 이후에 발견하면 운영이 흔들리고, 긴급 변경이 불가피해지며, 정착이 가장 취약한 시기에 사용자의 신뢰가 손상됩니다.

SAP 프로젝트에서 성능 테스트는 언제 시작해야 합니까?

리스크 식별은 Explore 단계에서 시작합니다. 아키텍처 선택이 성능 결과를 정하기 때문입니다. 본격적인 테스트는 구성이 결과에 의미가 생길 만큼 안정된 Realize 단계에서 시작합니다. 구성이 미완성이면 오해를 부르는 수치가 나옵니다.

마지막 사이클은 UAT 중이 아니라 UAT 전에 끝내십시오. UAT에서 발견된 성능 결함은 남은 일정을 압박하고, 알려진 이슈로 받아들이라는 압력을 만듭니다.

SAP 성능 테스트는 누가 책임져야 합니까?

QA 단독이 아니라 프로젝트 전체가 책임집니다. QA는 실행하고 보고하지만, 성능을 좌우하는 결정은 설계 단계에서 기능, 기술, Basis 팀에 걸쳐 내려집니다. 중앙의 아키텍트나 프로젝트 차원의 테스트 리드에게 그런 결정에 일찍 이의를 제기할 권한이 있어야 합니다.

RACI에 명확히 적으십시오. 누가 합격 기준을 승인하는지, 기준을 충족하지 못했을 때 누가 개선을 책임지는지, 성능을 이유로 누가 Go-Live를 막을 수 있는지입니다.

RISE with SAP는 성능 테스트 책임을 어떻게 바꿉니까?

인프라는 SAP가 책임집니다. 사이징, 리전, 네트워크, 플랫폼 가용성입니다. 애플리케이션 성능은 고객과 파트너가 책임집니다. 구성, 확장, OData 및 Fiori 설계, 연계 플로, 프로세스 KPI가 여기에 속합니다. SAP의 RISE 역할 및 책임 문서는 추가 SAP 서비스를 구매하지 않는 한 SQL 튜닝을 고객의 몫으로 둡니다.

이 역할 분담을 합격 기준에 명시해 각 임계값에 책임자가 있도록 하십시오.

SAP Fiori에서 가장 흔한 성능 문제는 무엇입니까?

네 가지 패턴이 대부분을 설명합니다. 교대 시작 시점의 로그인 폭주로, 이때 인증과 런치패드 렌더링 부하가 급증합니다. 큰 결과 집합을 반환하거나 상호작용 한 번에 여러 번의 백엔드 호출을 일으키는 OData 서비스입니다. 게이트웨이 계층 자체가 병목이 되는 경우로, 테스트 중에 반드시 모니터링해야 합니다. 그리고 표준 성능 가정이 적용되지 않는 커스텀 앱이나 대폭 수정된 앱입니다.

SAP의 성능 합격 기준은 어떻게 정의합니까?

트랜잭션, 부하, 임계값을 명시합니다. 예를 들면 이렇습니다. “주문 입력 역할의 동시 사용자 150명 조건에서 주문 생성이 트랜잭션의 95%에서 3초 이내에 완료된다.” 이것은 테스트할 수 있습니다.

“시스템은 충분히 빨라야 한다”는 테스트할 수 없습니다. 기준은 Prepare 단계에서 실제 운영상의 필요를 바탕으로 현업과 합의하고, 결과가 나온 뒤에는 바꾸지 마십시오.

성능 테스트를 생략하거나 축소하면 어떻게 됩니까?

문제가 운영에서 드러납니다. 잡이 정해진 시간대를 넘겨 다른 잡을 막고, 피크 시간에 Fiori 앱이 타임아웃되고, 월 마감이 두 배로 길어져 보고 기한을 놓치고, 인터페이스 큐가 쌓입니다.

첫 몇 주 안에 성능 문제를 겪은 사용자는 시스템에 대해 부정적인 인식을 갖게 되고, 이는 되돌리기 어렵습니다. 그리고 가동 중에 하는 긴급 개선은 테스트에 들었을 비용보다 더 큽니다. Realize 단계에서는 설계상의 결정이었던 것이 긴급한 아키텍처 변경이 되기 때문입니다.