SAP 성능 테스트: 부하, 동시성, 도구

SAP 성능 테스트는 많은 사용자와 작업이 동시에 실행될 때 핵심 트랜잭션, 백그라운드 작업, 인터페이스가 합의된 응답 시간을 충족한다는 것을 Go-Live 전에 증명합니다. 제 경험상 중요한 것은 동시성 테스트입니다. 운영 수준 물량의 마스킹 데이터로, 현업이 첫 실행 전에 합의한 통과 및 실패 기준에 따라 실행해야 합니다.

이 가이드는 RISE with SAP를 포함한 S/4HANA 프로젝트의 CIO, 프로젝트 디렉터, 테스트 리드를 위한 글입니다. 무엇을 테스트할지, 어떤 데이터가 필요한지, 인수 기준을 어떻게 작성할지, 어떤 도구가 쓸모 있는지, 누가 무엇을 책임지는지 다룹니다. 성능 테스트가 다른 테스트 유형 사이에서 어디에 위치하는지는 SAP 테스트 완전 정리부터 보십시오.

SAP 프로젝트의 성능 문제는 대개 뜻밖의 일이 아닙니다.

교대 근무가 시작될 때 수백 명이 로그인하면 Fiori 타일이 타임아웃됩니다. 누군가 매우 큰 테이블에 대해 조건 제한 없이 회계연도 전체를 조회하면 커스텀 보고서가 멈춥니다. 월 마감에 백그라운드 작업이 겹치면 전기 작업이 중단됩니다.

모두 예측 가능한 일입니다. 유일한 질문은 프로젝트가 이를 테스트했느냐, 아니면 실제 주문이 돌아가는 상황에서 현업이 발견하느냐입니다.

SAP Activate 전반의 성능 테스트

1. 01

   Explore

   설계에서 성능 위험을 찾아냅니다. 코드를 쓰기 전에 아키텍처와 보고서 구조가 결과를 결정합니다.

2. 02

   Realize

   구성이 안정되면 물량 테스트와 부하 테스트를 실행합니다. 일부만 구성된 상태에서는 오해를 부르는 결과가 나옵니다.

3. 03

   UAT 전

   전체 성능 테스트 사이클을 UAT의 일부가 아니라 UAT 전에 끝냅니다.

4. 04

   컷오버

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

5. 05

   하이퍼케어

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

기존 데이터베이스 위의 ECC 시스템에서 성능 테스트란 애플리케이션 서버와 데이터베이스, 즉 ABAP 런타임, SQL 성능, 작업 스케줄링에 대한 부하 테스트를 의미했습니다. 프런트엔드는 SAP GUI였고, 그쪽에서 놀랄 일은 거의 없었습니다.

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

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

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

SAP HANA 성능 테스트는 전환 프로젝트에서 고유한 변수가 있습니다. 안정적이던 ECC 코드도 인메모리 데이터베이스에서는 다르게 동작합니다. 많은 프로그램이 훨씬 빨라지지만, 일부는 특정 데이터 패턴에서 예상치 못한 성능 특성을 보입니다. 그래서 무거운 커스텀 코드에 대한 전환 전용 회귀 테스트는 선택 사항이 아닙니다.

통합 흐름에는 고유한 위험이 있습니다. 개발 환경에서 테스트 메시지 하나로는 잘 작동하던 흐름이 운영 물량에서는 대기열에 쌓이거나 조용히 실패할 수 있습니다. 증상은 다른 문제처럼 보입니다. 간헐적인 주문 실패, 송장 불일치, 한 시스템에는 있고 다른 시스템에는 없는 데이터 같은 것들입니다.

성능 테스트는 반드시 Go-Live 전에 해야 합니다. 제가 중요하게 다루는 것은 동시성 테스트입니다. 많은 사용자와 작업이 같은 트랜잭션, 테이블, 서비스에 같은 시간에 몰리는 상황을 테스트합니다.

사용자 한 명이 판매 오더를 2초 만에 처리했다는 것은 거의 아무것도 증명하지 못합니다. 150명이 주문을 입력하고, 백그라운드에서 출하 작업이 돌고, 인터페이스가 인바운드 메시지를 전기하는 가운데 같은 주문을 처리해 보는 것이 Go-Live 첫날을 예측하는 테스트입니다.

각 테스트 유형이 무엇을 증명하고 언제 실행해야 하는지 표로 정리했습니다.

테스트	증명하는 것	실행 시점	흔히 발견하는 것
동시성	많은 사용자와 작업이 같은 오브젝트에서 동시에 작업할 수 있음	Realize에서 구성이 안정된 뒤, 그리고 UAT 전에 다시	잠금 대기, 로그인 폭주, 게이트웨이 병목
부하	예상 최대 물량에서 응답 시간을 충족함	Realize에서 동시성 스크립트가 작동한 뒤	느린 OData 서비스, 무거운 커스텀 보고서
스트레스	설계 한도를 넘었을 때 시스템이 어디서 무너지는지	성장이 예상된다면 UAT 전	사이징 공백, 대기열 한도
소크	몇 시간 동안 지속되는 부하를 안정적으로 견딤	UAT 전, 가능하면 모의 마감 기간에 걸쳐	메모리 증가, 반복 실행 시 작업 체인 경합
엔드투엔드	사용자가 기다리는 전체 경로가 목표를 충족함	부하 테스트와 함께	계층별로 따로 테스트할 때는 보이지 않는 문제

부하 테스트의 핵심 단어는 ‘예상’입니다. 실제 트랜잭션 물량, 사용자 수, 세션 패턴이 필요합니다. 모두가 이미 낙관적이라고 알고 있던 물량 추정치로 만든 부하 테스트는 아무 의미 없는 통과를 줄 뿐입니다.

소크 테스트는 가장 자주 생략되는 테스트입니다. 일정이 압축될 때 프로젝트가 가장 자주 택하고 가장 많이 후회하는 지름길이 물량 테스트 전반의 생략입니다.

다음 시나리오를 먼저 스크립트로 만드십시오. 운영 환경까지 가는 실패의 대부분을 다룹니다.

1. 교대 전환과 최대 로그인. 수백 명의 사용자가 동시에 Fiori 런치패드를 열면 인증과 런치패드 렌더링에 부하가 급증합니다. 동시 로그인을 한 번도 테스트하지 않았다면, 한가한 시간에는 멀쩡한 시스템이 그 시간대에는 쓸 수 없게 될 수 있습니다.
2. 월 마감과 연 마감. 대량 전기, 순서가 엄격한 작업 체인, 고정된 마감 기한과 싸우는 재무팀이 함께 몰립니다. 마감 작업 체인을 하루 평균 건수가 아니라 마감 기간 물량으로 처음부터 끝까지 실행하십시오.
3. 겹치는 백그라운드 작업. 배치 작업은 보통 하나씩 테스트하는데, 이는 현실을 반영하지 않습니다. 최적화가 부족한 작업 하나가 다른 여러 작업을 막고, 마감이 정해진 시간을 넘깁니다.
4. 조건 제한 없는 커스텀 보고서. 테스트 데이터에서는 즉시 결과가 나오는 보고서가 회계연도 전체에서는 몇 분씩 걸릴 수 있습니다. 일반적인 조회 조건과 최악의 조회 조건을 테스트하고, 조건 제한 없는 조회는 막으십시오.
5. 여러 지역의 사용자. 네트워크 지연은 모든 트랜잭션에 영향을 줍니다. RISE는 호스팅을 SAP로 옮기지만, 지연은 여전히 선택한 리전과 사용자까지의 라우팅에 달려 있습니다. 가장 멀리 떨어진 사이트에서 테스트하십시오.

전환 테스트가 전체 계획의 어디에 들어가는지는 ECC에서 S/4HANA로의 마이그레이션 가이드에서 다룹니다.

운영 수준의 테스트 데이터

이 모든 것이 의미가 있느냐는 데이터가 결정합니다. 저는 운영 수준의 마스킹 데이터를 고집합니다. 운영 물량과 운영 수준의 현실성을 갖추고, 개인 정보와 민감한 필드는 마스킹한 데이터입니다.

미결 오더 라인이 200,000건인 고객과 5,000건인 고객은 다르게 동작합니다. 얇은 테스트 클라이언트에서는 즉시 결과가 나오는 필터가 운영 환경에서는 타임아웃됩니다. 고위험 영역에는 물량을 채워 넣고, 대표적인 트랜잭션 구성을 쓰고, 가능하면 실제 인터페이스 호출을 하십시오.

시스템 복사, 선택적 테스트 데이터 도구, 마스킹을 통해 그런 데이터를 안전하게 확보하는 방법은 SAP 테스트 데이터 관리 가이드에서 다룹니다. 리프레시는 대부분의 테스트 계획이 가정하는 것보다 오래 걸리므로 첫 성능 테스트 사이클 전에 계획하십시오.

어떤 테스트도 실행하기 전인 Prepare 단계에서 현업과 기준을 합의하십시오. 각 기준에는 트랜잭션이나 작업, 부하, 임계값이 명시되어야 합니다.

아래 예시는 형태를 보여 줍니다. 수치는 운영상 필요에 따라 직접 정하십시오.

항목	부하 조건	통과 기준	책임자
판매 오더 생성(VA01 또는 Fiori 앱)	동시 주문 입력 사용자 150명	트랜잭션의 95%가 3초 이내	Order to Cash 프로세스 오너
교대 시작 시 Fiori 런치패드 최초 로드	가장 큰 교대조의 최대 동시 로그인	사용자의 95%가 5초 이내	IT 운영 리드
월 마감 작업 체인	마감 기간 물량, 전체 순서	합의된 마감 시간 안에 중단 없이 완료	재무 관리자
인바운드 주문 인터페이스	시간당 최대 메시지 물량	15분 넘게 밀린 대기열 없음	통합 리드
대용량 커스텀 보고서	운영 데이터 전체 물량, 일반적인 조회 조건	60초 이내, 조건 제한 없는 조회는 차단	보고서 오너

‘시스템은 비즈니스 운영에 충분할 만큼 빨라야 한다’는 테스트할 수도, 인수할 수도 없습니다. 결과가 나온 뒤에 기준을 바꾸면 기준을 둔 의미가 사라집니다.

UAT 사용자가 빠르게 느껴진다고 해서 시스템이 통과했다면, 그것은 인수 기준이 아니라 의견입니다. SAP 품질 게이트 가이드에서 설명하는 방식대로 결과를 컷오버 전의 공식 게이트로 만드십시오. 테스트 단계별 진입 및 종료 기준을 포함한 전체 사이클 계획은 S/4HANA 테스트 전략에 들어가야 합니다.

SAP 성능 테스트 도구

성능 테스트에는 세 가지가 필요합니다. SAP 프로토콜을 구동할 수 있는 부하 생성기, SAP 측 모니터링, 테스트 케이스와 결과를 관리할 장소입니다. LoadRunner는 제가 SAP 프로젝트에서 팀이 쓰도록 한 부하 도구입니다. 라이선스, 부하 생성기, 스크립트 작성 역량을 갖추는 데 모두 시간이 걸리므로 테스트 계획에 도구를 일찍 명시하십시오.

2026년의 주요 선택지는 다음과 같습니다.

도구	역할	알아 둘 점
OpenText Professional Performance Engineering	부하 생성	이전 명칭은 LoadRunner Professional. 프로토콜 번들이 SAP, SAP GUI, SAP Web을 지원
Tricentis NeoLoad	부하 생성	Tricentis는 SAP GUI, Fiori, RFC, IDoc 지원을 명시하며, Tricentis Tosca 자산을 재사용 가능
Apache JMeter	부하 생성	오픈 소스. Fiori와 OData 호출 같은 HTTP 트래픽을 구동
SAP Cloud ALM	테스트 관리	수동 및 자동화 테스트 케이스를 준비하고 실행하며 결함을 추적. 부하 자체는 생성하지 않음
SAP Solution Manager	테스트 관리	메인스트림 유지보수가 2027년 12월 31일에 종료되므로 새 작업은 Cloud ALM으로 계획

기능 테스트 도구와 자동화 도구를 더 넓게 보려면 SAP 테스트 및 검증 도구 비교를 참고하십시오. 도구보다 중요한 것은 스크립트, 데이터, 기준입니다.

RISE with SAP는 책임을 나눕니다

RISE with SAP에서 SAP는 인프라를 책임집니다. 사이징, 하이퍼스케일러 리전, 네트워크, 플랫폼 가용성입니다. 애플리케이션 계층은 고객과 파트너가 책임집니다.

SAP의 RISE 역할 및 책임 문서는 이를 분명히 밝힙니다. 부하 테스트 실행과 비용이 큰 SQL 문 튜닝은 추가 요금이 붙는 SAP Cloud Application Services입니다. 이를 구매하지 않으면 그 작업은 고객이 해야 합니다.

RISE 프로젝트에서 흔한 실패는 SAP가 인프라를 운영하니 성능 문제도 잡아 주리라는 가정입니다. SAP는 인프라 문제를 잡아 줄 것입니다. 책임 분담을 프로젝트 헌장과 테스트 계획에 명시하십시오.

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

퍼블릭 클라우드는 범위를 좁힙니다

SAP 클라우드 ERP의 public edition에서 시스템은 SAP가 운영하는 공유 플랫폼에서 실행됩니다. 테넌트에 대한 부하 테스트를 계획하기 전에 허용되는지, 사전 통지가 얼마나 필요한지 SAP에 서면으로 문의하십시오.

그다음 테스트는 귀사의 몫인 부분으로 옮겨 갑니다. 커스텀 통합, 확장, 대용량 보고서, 마감 순서, 귀사 사이트로부터의 네트워크 경로입니다. 플랫폼 성능 문제는 SAP 지원으로 넘깁니다.

흔한 실수

1. 기능 테스트를 성능 테스트로 여기는 것. 기능 테스트는 트랜잭션이 올바른 결과를 낸다는 것을 증명합니다. 150명이 동시에 그 트랜잭션을 실행하는 상황에 대해서는 아무것도 알려 주지 않습니다.
2. 성능을 Basis에 맡겨 두는 것. Basis는 사이징과 작업 스케줄링을 책임집니다. 보고서 설계, OData 서비스 아키텍처, 통합 흐름 설계는 책임지지 않으며, 애플리케이션 성능을 좌우하는 것은 바로 이것들입니다.
3. 책임을 QA에만 맡기는 것. QA는 테스트를 실행하고 결과를 보고하지만, 성능 문제를 일으키는 결정은 설계 단계에서 내려집니다. 프로젝트 차원의 테스트 리드나 아키텍트가 이를 일찍 문제 삼을 권한을 가져야 하며, RACI에는 성능을 이유로 Go-Live를 막을 수 있는 사람이 명시되어야 합니다.
4. 공백을 알려진 이슈로 받아들이는 것. 운영 환경에서 성능 문제를 겪는 프로젝트 대부분은 테스트를 건너뛴 것이 아닙니다. 합의된 기준 없이 테스트했거나, 테스트한 뒤 일정 압박 속에서 실패를 받아들인 것입니다.

가장 위험한 트랜잭션과 작업에 대해 인수 기준 대여섯 개를 작성하고, 각각에 책임자를 이름으로 지정하십시오. 위의 표를 채울 수 없다면 아직 테스트할 준비가 되지 않은 것이며, 첫 번째 공백을 찾은 것입니다.

그다음 두 가지를 확인하십시오. 마스킹된 운영 물량 데이터의 리프레시가 계획에 들어 있는지, 그리고 동시성 테스트 사이클이 UAT 시작 전에 끝나는지입니다.

성능 테스트 계획이나 Go-Live 결정에 대해 독립적인 의견이 필요하시면 제가 도와드리고 있습니다. 여기에서 연락하실 수 있습니다.

SAP 성능 테스트란 무엇입니까?

현실적인 부하에서 SAP가 어떻게 동작하는지 확인하는 테스트입니다. 사용자 트랜잭션의 응답 시간, 백그라운드 작업의 실행 시간, 인터페이스의 처리량, 많은 사람이 동시에 작업할 때의 리소스 사용량을 봅니다. 반드시 Go-Live 전에 해야 합니다.

기능적 정확성과 성능은 서로 다른 특성입니다. 사용자 한 명에게 정상인 트랜잭션이 200명에게는 타임아웃될 수 있습니다.

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

아키텍처 선택이 성능 결과를 정하므로 위험 식별은 Explore에서 시작합니다. 실제 테스트는 결과가 의미를 가질 만큼 구성이 안정된 Realize에서 시작합니다.

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

SAP에서 부하 테스트와 동시성 테스트의 차이는 무엇입니까?

부하 테스트는 예상 최대 물량에서의 응답 시간을 확인합니다. 동시성 테스트는 많은 사용자와 작업이 같은 순간에 같은 트랜잭션, 테이블, 서비스에서 작업할 때 무슨 일이 일어나는지 확인합니다. 잠금 대기, 로그인 폭주, 게이트웨이 병목이 드러나는 곳이 바로 여기입니다.

제 경험상 중요한 것은 동시성 테스트입니다. 동시성 테스트를 먼저 실행하고, 그 위에 전체 부하 테스트를 쌓으십시오.

SAP 성능 테스트에는 어떤 테스트 데이터를 써야 합니까?

운영 수준의 마스킹 데이터입니다. 운영 물량과 현실성을 갖추고, 개인 정보와 민감한 필드는 마스킹한 데이터를 뜻합니다. 얇은 테스트 데이터는 Go-Live 첫날 나타날 느린 필터, 무거운 보고서, 긴 작업 실행 시간을 가립니다.

SAP 성능 테스트에는 어떤 도구를 사용합니까?

OpenText Professional Performance Engineering(이전 명칭 LoadRunner Professional), Tricentis NeoLoad, Apache JMeter 같은 부하 생성기가 부하를 만듭니다. SAP Cloud ALM이나 SAP Solution Manager가 테스트 케이스와 결과를 관리하고, SAP 측 모니터링이 부하 아래에서 시스템이 무엇을 했는지 보여 줍니다.

RISE with SAP에서 성능 테스트는 누가 책임집니까?

SAP는 사이징, 리전, 네트워크, 플랫폼 가용성 같은 인프라를 책임집니다. SAP의 RISE 역할 및 책임 문서에 따르면, 추가 요금이 붙는 SAP Cloud Application Services를 구매하지 않는 한 부하 테스트 실행과 비용이 큰 SQL 튜닝은 고객의 몫입니다.

애플리케이션 성능과 인수 결정은 고객과 파트너가 책임집니다. 각 임계값에 책임자가 있도록 책임 분담을 인수 기준에 명시하십시오.