요약 (TL;DR)
SoapUI의 느린 성능은 JVM 시작 오버헤드, 대규모 프로젝트에 비해 너무 낮은 기본 메모리 설정, 그리고 WSDL 파싱 지연에서 비롯됩니다. 특정 해결책(힙 크기 튜닝, WSDL 캐싱, 프로젝트 분할)은 속도를 크게 향상시킬 수 있습니다. 팀에서 이러한 병목 현상을 완전히 피하는 더 빠른 도구가 필요하다면, Apidog는 Java 런타임 없이 실행됩니다.
서론
SoapUI는 느립니다. 몇 주 이상 사용해 보셨다면, 30초의 시작 시간, 대규모 WSDL을 파싱하는 동안 응답 없는 UI, 수백 개의 테스트 단계가 있을 때 기어가는 듯한 테스트 실행을 경험하셨을 것입니다. 이것들은 버그가 아닙니다. 이는 SoapUI가 구축된 방식의 자연스러운 결과입니다.
이 가이드는 SoapUI가 느린 구체적인 기술적 이유를 설명하고, 각 문제에 대한 실제적인 해결책을 제공하며, 한계를 설명합니다. 일부 느린 현상은 해결할 수 있지만, 일부는 도구를 전환하지 않고는 해결할 수 없습니다.
근본 원인 1: JVM 시작 오버헤드
SoapUI는 Java Swing 애플리케이션입니다. 이를 실행할 때마다 Java 가상 머신(JVM)을 시작하고, 수백 개의 클래스 파일을 로드하고, Spring 프레임워크를 초기화하고, 프로젝트를 로드하며, Swing 인터페이스를 렌더링합니다. SSD가 장착된 최신 머신에서는 20-60초가 소요됩니다. 구형 하드웨어에서는 90초를 초과할 수 있습니다.
발생 이유: Java 애플리케이션은 네이티브 애플리케이션에는 없는 시작 비용을 지불합니다. JVM은 실행을 시작하기 전에 바이트코드를 해석하거나 JIT 컴파일해야 합니다. Swing UI 초기화도 여기에 추가됩니다.
해결책:
SoapUI를 계속 열어 두십시오. 가장 간단한 해결책은 테스트 실행 사이에 SoapUI를 닫지 않는 것입니다. 일단 JVM이 실행되면 따뜻한 상태를 유지합니다.
빠른 디스크를 사용하십시오. 회전식 하드 디스크에서 SoapUI를 실행하고 있다면 SSD로 옮기십시오. 클래스 로딩 단계는 많은 작은 파일을 읽는데, 이는 SSD가 HDD보다 뛰어난 정확한 지점입니다.
Java 8 대신 Java 11 또는 17을 사용하십시오. 최신 JVM 버전은 시작 시간이 개선되었습니다. soapui.bat (Windows) 또는 soapui.sh (Linux/Mac)에서 SoapUI가 사용하도록 구성된 JDK를 확인하십시오. 첫 번째 줄은 Java 홈 경로를 설정합니다. 최신 JDK로 전환하면 시작 시간을 줄일 수 있습니다.
AppCDS(애플리케이션 클래스 데이터 공유)를 활성화하십시오. 이 JVM 기능은 클래스 로딩 데이터를 미리 캐시합니다. 한 번의 설정이 필요하지만, 이후 시작 시간을 줄여줍니다. JVM 인수에 -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa를 추가하십시오.
근본 원인 2: 기본 메모리 설정이 너무 낮음
SoapUI는 기본 힙 크기 설정이 낮게 제공됩니다. 대규모 프로젝트를 열거나 긴 테스트 스위트를 실행하면 JVM이 가비지 컬렉션에 시간을 소비하게 되어 애플리케이션이 일시 중지되고 느려지는 느낌을 줍니다.
기본 설정 (soapui.vmoptions 또는 soapui.bat에서):
-Xms128m
-Xmx768m
이는 SoapUI가 128MB의 힙으로 시작하며 최대 768MB를 사용할 수 있다는 의미입니다. 최신 머신은 8-32GB의 RAM을 가지고 있습니다. SoapUI를 768MB로 두면 대규모 프로젝트에서 지속적인 가비지 컬렉션 압력이 발생합니다.
해결책: 힙 크기 늘리기
Windows에서 <SoapUI_Install>/bin/SoapUI.vmoptions를 편집하십시오:
-Xms512m
-Xmx2048m
macOS에서 SoapUI.app/Contents/vmoptions.txt를 편집하거나 soapui.sh를 찾으십시오:
JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"
Linux에서 <SoapUI_Install>/bin/soapui.sh를 편집하십시오:
JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"
권장 사항:
-Xms(초기 힙)를 여유 RAM이 있다면 512MB 이상으로 설정하십시오. 이렇게 하면 점진적인 힙 확장을 방지할 수 있습니다.-Xmx(최대 힙)를 중간 프로젝트의 경우 2GB로, 대규모 프로젝트의 경우 4GB로 설정하십시오. 사용 가능한 RAM의 절반 이상으로 설정하지 마십시오.- Java 9+를 사용하고 있다면
-XX:+UseG1GC를 추가하십시오. G1GC는 기본 가비지 컬렉터에 비해 일시 정지 시간을 줄여줍니다. - 메타스페이스(클래스 메타데이터)가 무제한으로 증가하는 것을 방지하기 위해
-XX:MaxMetaspaceSize=512m를 추가하십시오.
해결책 확인: SoapUI를 다시 시작한 후 도움말 > 시스템 속성 대화 상자를 여십시오. 업데이트된 힙 값을 볼 수 있을 것입니다. 작업 관리자를 모니터링하여 SoapUI가 새 할당을 사용하고 있는지 확인하십시오.
근본 원인 3: 대규모 프로젝트 파일
SoapUI는 모든 것을 단일 XML 파일에 저장합니다. 많은 테스트 스위트, 큰 요청 본문 또는 인라인 바이너리 데이터를 포함하는 프로젝트는 이 파일을 비대하게 만듭니다. 10MB 프로젝트 파일을 열고 저장하는 것은 500KB 파일보다 눈에 띄게 느립니다.
이 문제의 징후:
- 저장(Ctrl+S) 시 SoapUI가 몇 초간 일시 중지됩니다.
- 디스크의 프로젝트 파일 크기가 수 메가바이트입니다.
- SoapUI가 이미 실행 중인데도 프로젝트를 여는 데 10초 이상 걸립니다.
해결책:
대규모 프로젝트 분할. SoapUI는 테스트 스위트를 디렉토리에 별도의 XML 파일로 저장하는 복합 프로젝트를 지원합니다. 프로젝트 > 설정 > 복합 프로젝트에서 이 기능을 활성화하십시오. 이를 통해 부분 로딩 및 더 빠른 저장이 가능합니다.
사용하지 않는 테스트 케이스 제거. 더 이상 관련 없는 테스트 케이스를 보관하거나 삭제하십시오. 스크립트와 요청 데이터를 포함하는 각 테스트 케이스는 XML 크기를 증가시킵니다.
대규모 요청 본문 외부화. 테스트 단계에서 대규모 XML 또는 JSON 본문을 인라인으로 사용한다면, 이를 매개변수화하고 SoapUI의 파일 기반 DataSource를 사용하여 외부 파일에서 로드하는 것을 고려하십시오.
"종료 시 저장" 자동 백업 비활성화. SoapUI는 종료 시 백업 복사본을 생성합니다. 종료 시 추가 디스크 쓰기를 피하기 위해 환경설정 > UI 설정에서 이 기능을 비활성화하십시오.
근본 원인 4: WSDL 파싱 지연
SoapUI가 WSDL 파일을 참조하는 프로젝트를 열 때, 시작 시 또는 인터페이스 트리를 확장할 때 해당 WSDL을 다시 파싱할 수 있습니다. WSDL이 원격 서버에 호스팅되어 있거나 크다면(많은 작업, 복잡한 유형), 이 파싱은 상당한 지연을 추가합니다.
이 문제의 징후:
- 인터페이스를 확장할 때 SoapUI가 멈추거나 로딩 표시기를 보여줍니다.
- 테스트 시작 전에 연결 시간 초과 오류로 실패합니다.
- 다른 머신에서 프로젝트를 다른 속도로 로드합니다 (네트워크 종속성).
해결책:
WSDL을 로컬에 캐시하십시오. SoapUI에서 인터페이스를 마우스 오른쪽 버튼으로 클릭 > 정의 업데이트를 선택하십시오. 정의 URL을 원격 URL 대신 WSDL의 로컬 파일 복사본을 가리키도록 변경하십시오. 이렇게 하면 로드 시마다 네트워크 지연이 제거됩니다.
정의 URL을 file:// 경로로 설정하십시오. WSDL의 로컬 복사본이 있다면, 인터페이스 정의 URL을 file:///path/to/your/service.wsdl로 업데이트하십시오. SoapUI는 이를 디스크에서 즉시 로드합니다.
정의 자동 업데이트 비활성화. 환경설정 > WS-Security 설정에서 시작 시 WSDL 재검증을 강제하는 옵션의 선택을 해제하십시오.
HTTP 시간 초과 설정 증가. 네트워크 WSDL이 느리게 응답하는 경우, 환경설정 > HTTP 설정으로 이동하여 연결 시간 초과를 늘리십시오. 이는 느린 WSDL 서버에서 SoapUI가 무기한으로 멈추는 것을 방지합니다.
근본 원인 5: 대규모 스위트에서의 테스트 실행 성능
수백 개의 테스트 케이스가 포함된 테스트 스위트를 실행하는 것은 느릴 수 있으며, 특히 각 테스트 단계에 복잡한 Groovy 스크립트, 어설션 또는 네트워크 호출이 있는 경우 더욱 그렇습니다.
해결책:
- 스위트를 병렬로 실행. SoapUI는 병렬 테스트 스위트 실행을 지원합니다. 테스트 스위트 러너에서 "테스트 케이스 동시 실행" 옵션을 활성화하십시오. SOAP 서비스가 동시 연결을 처리하는지 확인하십시오.
- 불필요한 어설션 비활성화. SoapUI가 평가하는 각 어설션은 처리 시간을 추가합니다. 테스트 단계를 감사하고 의미 없는 것을 확인하지 않는 어설션을 제거하십시오.
- Groovy 스크립트 최적화. Groovy 스크립트는 SoapUI에서 해석되어 실행됩니다. 모든 테스트 단계에 대해 실행되는 스크립트(문자열 파싱, 정규식, 대규모 객체 생성)에서 비용이 많이 드는 작업을 피하십시오. 공유 로직을 프로젝트 수준 스크립트 라이브러리로 이동하십시오.
- 응답 시간 어설션 신중하게 사용. 응답 SLA 어설션은 실패하기 전에 전체 시간 초과를 기다립니다. 신뢰할 수 없는 엔드포인트에 긴 시간 초과를 가진 엄격한 SLA 어설션이 있다면, 전체 스위트를 차단할 수 있습니다.
- 로깅 상세도 줄이기. SoapUI는 기본적으로 모든 요청과 응답을 로깅합니다. 대규모 스위트의 경우 이 I/O가 누적됩니다. 환경설정 > HTTP 설정으로 이동하여 테스트 실행 중 로깅되는 내용을 줄이십시오.
해결할 수 없는 것
일부 SoapUI 성능 문제는 구조적입니다. 아무리 튜닝해도 변하지 않는 것은 다음과 같습니다.
- Swing UI 렌더링. 인터페이스는 항상 네이티브 또는 웹 앱보다 느리게 느껴질 것입니다. Swing은 2000년대에 최첨단이었지만, 지금은 그렇지 않습니다.
- JVM 시작. 줄일 수는 있지만, 없앨 수는 없습니다.
- 단일 스레드 WSDL 파싱. SoapUI는 WSDL을 순차적으로 파싱합니다. 많은 스키마를 가져오는 크고 복잡한 WSDL은 시간이 걸리며, 구성할 병렬 처리 기능이 없습니다.
- 메모리 오버헤드. JVM, Swing, Spring 프레임워크는 프로젝트 크기와 관계없이 함께 메모리를 소비합니다. 유휴 상태에서 300-400MB는 일반적입니다.
다른 도구로 전환해야 할 때
위에서 제시된 해결책을 적용했음에도 SoapUI가 여전히 워크플로우를 방해한다면, 병목 현상이 설정으로 해결되지 않을 수 있습니다.
Apidog는 JVM이 아닌 Node.js 클라이언트 기반의 웹 애플리케이션으로 실행됩니다. 몇 초 만에 열립니다. 테스트 실행에는 머신에 Java 런타임이 필요하지 않습니다. SoapUI의 시작 시간과 UI 응답성이 주된 병목 현상인 팀의 경우, 지속적인 JVM 튜닝보다 도구를 전환하는 것이 더 생산적입니다.
한 가지 단점: Apidog는 WSDL을 파싱하지 않습니다. 새로운 서비스 온보딩을 위해 SoapUI의 WSDL 가져오기에 의존한다면, Apidog에서 일상적인 테스트를 실행하는 동안 해당 특정 작업을 위해 SoapUI를 계속 사용할 수 있도록 하는 것이 좋습니다.
자주 묻는 질문 (FAQ)
대규모 프로젝트(50개 이상의 테스트 스위트)에서 SoapUI에 권장되는 힙 크기는 얼마입니까? -Xmx를 최소 2GB로 설정하고, 머신에 16GB 이상의 RAM이 있다면 이상적으로 4GB로 설정하십시오. 점진적인 힙 확장을 피하기 위해 -Xms를 512MB에서 1GB로 설정하십시오. 더 나은 가비지 컬렉션 동작을 위해 -XX:+UseG1GC를 사용하십시오.
SoapUI의 현재 힙 사용량을 확인할 수 있습니까? 예. 도움말 > 시스템 속성으로 이동하십시오. 여기에는 힙 설정을 포함한 JVM 인수가 표시됩니다. SoapUI 로그에서 가비지 컬렉션 활동을 보려면 JVM 옵션에 -verbose:gc를 일시적으로 추가할 수도 있습니다.
최신 JDK로 전환하면 SoapUI 성능이 향상됩니까? 대부분의 경우 예. Java 8에 비해 Java 11 및 17에서는 JVM 시작 시간과 가비지 컬렉션이 개선되었습니다. 일부 최신 JDK 버전은 이전 SoapUI 릴리스와 호환성 문제가 있을 수 있으므로 권장 JDK 버전에 대한 SoapUI의 릴리스 노트를 확인하십시오.
몇 시간 동안 테스트를 실행한 후 SoapUI가 느려지는 이유는 무엇입니까? 시간이 지남에 따라 메모리 단편화 및 가비지 컬렉션 오버헤드가 증가합니다. SoapUI를 닫고 다시 열면 JVM 상태가 재설정됩니다. -Xmx를 늘리고 G1GC를 사용하면 이러한 저하를 지연시키지만 완전히 제거하지는 못합니다.
서버에서 (헤드리스) SoapUI를 실행하면 성능이 향상됩니까? 예, 어느 정도 그렇습니다. 헤드리스 모드(-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false 및 유사 플래그)는 Swing 렌더링 오버헤드를 줄입니다. 최상의 성능을 위해 GUI 대신 CI/CD용 명령줄 테스트 러너를 사용하십시오.
Apidog는 SoapUI에 비해 대규모 컬렉션을 어떻게 처리합니까? Apidog는 컬렉션을 클라우드에 저장하고 필요할 때 로드합니다. 파싱할 로컬 XML 파일이 없습니다. 테스트 실행은 JVM 초기화가 필요 없는 로컬 CLI 러너를 사용합니다.
대부분의 SoapUI 성능 문제에는 해결책이 있습니다. 힙 크기 변경만으로도 종종 즉각적이고 눈에 띄는 효과를 가져옵니다. 더 복잡한 해결책을 시도하기 전에 여기부터 시작하십시오.