성능 테스트(종류, 지표, 도구)

성능 테스트는 소프트웨어의 기능이 올바르게 동작하는지를 검증하는 기능 테스트와 달리, 특정 작업 부하(Workload) 하에서 시스템의 응답성, 안정성, 그리고 자원 사용률과 같은 비기능적인 측면을 측정하고 평가하는 테스트 유형입니다. 성능 테스트의 주된 목표는 단순히 버그를 찾는 것이 아니라, 시스템의 성능 저하 지점, 즉 병목(Bottleneck)을 식별하고 제거하는 데 있습니다.

 

1. 성능 테스트의 종류

성능 테스트는 하나의 개념이 아닌, 각기 다른 목적을 가진 여러 테스트의 집합입니다. '새로 지은 다리의 안정성을 검사한다'는 상황을 통해  각 테스트의 목표를 알아보겠습니다.

• 부하 테스트 (Load Testing): 출퇴근 시간대의 교통량 테스트
  • 목표: 시스템이 예상되는 최대치의 정상적인 부하(예: 피크 타임 트래픽)를 처리할 수 있는지 확인합니다. 시스템이 사전에 정의된 성능 목표치(응답 시간, 처리량 등)를 만족하는지 검증하는 것이 주목적입니다.
  • ex: 이 다리가 평일 오후 5시의 출퇴근 시간대 교통량을 정체 없이 소화할 수 있는가?
• 스트레스 테스트 (Stress Testing): 다리가 견딜 수 있는 한계 트럭 대수 테스트
  • 목표: 시스템의 한계점을 파악하기 위해 의도적으로 정상 처리 용량을 초과하는 매우 높은 부하를 가합니다. 시스템이 언제, 어떻게 실패하는지, 그리고 부하가 제거되었을 때 정상적으로 복구되는지를 확인하여 시스템의 안정성과 회복성을 측정합니다.
  • ex: 화물을 가득 실은 트럭을 몇 대까지 올려야 다리가 휘기 시작하는가? 그리고 트럭을 치웠을 때 다리는 원래 상태로 돌아오는가?
• 스파이크 테스트 (Spike Testing): 갑작스러운 인파가 몰리는 상황 테스트
  • 목표: 매우 짧은 시간 동안 사용자가 폭발적으로 급증하는 상황을 시뮬레이션합니다. 티켓 예매, 선착순 이벤트, 대규모 할인 행사와 같이 순간적인 트래픽 폭증이 예상되는 시스템의 대응 능력을 검증하는 데 필수적입니다.
  • ex: 1만 명의 사람이 갑자기 다리 위로 한꺼번에 뛰어 올라갔을 때 다리는 어떻게 반응하는가?
• 내구성/담금 테스트 (Endurance/Soak Testing): 24시간 내내 계속되는 교통량 테스트
  • 목표: 비교적 평이한 수준의 부하를 장시간(수 시간에서 수 일) 동안 지속적으로 가하여 시스템의 장기적인 안정성을 확인합니다. 이 테스트를 통해 메모리 누수(Memory Leak), 데이터베이스 연결 문제, 시스템 리소스 고갈 등 시간이 지나야 드러나는 문제를 발견할 수 있습니다.
  • ex: 출퇴근 시간대의 교통량을 48시간 동안 쉬지 않고 흘려보냈을 때, 다리 구조에 피로 균열이 생기지는 않는가?

이 외에도 대용량의 데이터를 처리할 때의 성능을 측정하는 볼륨 테스트(Volume Testing), 사용자나 데이터 볼륨 증가에 따른 시스템의 확장 능력을 평가하는 확장성 테스트(Scalability Testing) 등이 있습니다.

 성능 테스트 유형별 요약

테스트 유형	주요 목표	부하 프로파일	테스트 기간	주요 사용 사례
부하 테스트	예상된 피크 부하 상황에서 성능 목표치 충족 여부 확인	예상되는 최대 부하	보통 수 분 ~ 수 시간	일반적인 서비스의 피크 타임 성능 검증
스트레스 테스트	시스템의 한계점 및 장애 발생 지점, 회복 능력 확인	한계치를 초과하는 과부하	비교적 짧음	장애 허용 범위 및 복구 전략 수립
스파이크 테스트	순간적인 트래픽 폭증에 대한 시스템 대응 능력 확인	매우 짧은 시간 내의 급격한 부하 증가	매우 짧음	티켓 예매, 선착순 이벤트, 플래시 세일
내구성 테스트	장시간 운영 시 안정성 및 잠재적 문제(메모리 누수 등) 확인	예상되는 평균 수준의 부하	수 시간 ~ 수 일	24/7 운영되는 서비스의 안정성 검증

---

2. 핵심 지표

시스템의 상태를 모니터링하는 데 사용되는 네 가지 핵심 지표를 SRE의 Four Golden Signals을 통해 알아보겠습니다.

4가지 골든 시그널

1. 처리량 (Throughput): "얼마나 많이" 처리하는가?
   • 정의: 단위 시간당 시스템이 성공적으로 처리한 요청의 수를 의미합니다.
   • 주로 TPS(Transactions Per Second) 또는 RPS(Requests Per Second)로 표현됩니다. 하나의 사용자 트랜잭션(예: '상품 구매')은 여러 개의 HTTP 요청(예: 장바구니 추가, 결제 정보 전송, 주문 완료 페이지 요청)으로 구성될 수 있습니다.
     
   • Four Golden Signals의 원문은 핵심 시표를 Traffic 설명하나, "성능을 측정하고 개선"하기 위한 목적에 부합하기 위해서는 '시스템이 실제로 얼마나 많은 요청을 감당해냈는가', 즉, Traffic(들어오는 요청의 양, 부하)을 성공적으로 처리해 내는 비율을 의미하는 Throughput이 적합하다 생각ㅎ
2. 지연 시간 / 응답 시간 (Latency / Response Time): "얼마나 빨리" 응답하는가?
   • 정의: 요청이 시작된 시점부터 응답이 완료될 때까지 걸리는 시간입니다.
   • 평균값의 함정: '평균 응답 시간'은 성능을 평가할 때 좋지 못한 지표일 수 있습니다. 수천 개의 빠른 응답 속 몇 개의 매우 느린 응답이 평균값에 의해 희석되어 문제를 인지하지 못할 수 있기에 주의해야합니다.
   • 백분위수(Percentile)의 힘: 실제 사용자 경험을 더 정확하게 파악하기 위해 백분위수 지표를 사용해야 합니다.
     • P95 (95th Percentile): "95%의 사용자는 응답 시간이 X ms 이하입니다." 극단적인 예외를 제외한 대다수 사용자의 경험을 나타냅니다.
     • P99 (99th Percentile): "99%의 사용자는 응답 시간이 Y ms 이하입니다." 간헐적으로 발생하는 심각한 성능 저하를 파악하는 데 매우 중요합니다.
     • ex: 100개의 요청 중 98개가 50ms, 2개가 2000ms 걸렸다고 가정했을 때, 평균 응답 시간은 ((98*50) + (2*2000)) / 100 = 89ms로 양호해 보입니다. 하지만 P99 응답 시간은 2000ms로, 일부 사용자는 좋지 않은 경험을 하고 있음을 파악할 수 있습니다.
3. 에러율 (Error Rate): "얼마나 자주" 실패하는가?
   • 정의: 전체 요청 중 실패한 요청(예: HTTP 5xx 서버 에러)의 비율을 의미합니다.
   • 부하가 증가함에 따라 에러율이 0%를 넘어서기 시작하는 것은 시스템이 한계에 도달했다는 신호일 수 있습니다.
4. 포화도 (Saturation): "얼마나 가득 찼는가?"
   • 정의: CPU, 메모리, 디스크 I/O, 네트워크 대역폭 등 시스템의 주요 자원이 용량 한계에 얼마나 근접했는지를 나타내는 지표입니다.
   • 포화도는 미래의 지연 시간 증가와 에러 발생을 예측하는 선행 지표입니다. 포화도가 높다는 것은 곧 성능 저하가 임박했음을 의미합니다.

용어 정리

• 가상 사용자 (Virtual User, VU): 실제 사용자의 행동을 시뮬레이션하는 가상의 개체로, 부하 테스트에서는 VU의 수를 조절하여 시스템에 가해지는 부하 수준을 제어합니다.
• 램프업 (Ramp-Up): 테스트 시작 시 VU의 수를 0에서 목표 수준까지 점진적으로 늘리는 구간입니다. 이는 시스템에 갑작스러운 충격을 주는 것을 방지하고, 부하가 증가함에 따라 성능이 어떻게 변화하는지 관찰할 수 있게 해 줍니다.
• 병목 (Bottleneck): 시스템 전체의 처리량을 제한하는 특정 구성 요소나 리소스를 의미합니다. 성능 테스트 분석의 최종 목표는 바로 이 병목 지점을 찾아내는 것입니다.

지표들은 개별적으로만 측정하기보다, 가상 사용자(VU)가 증가함에 따라 처리량(TPS)이 어떻게 변하고, 어느 시점부터 응답 시간(Latency)이 급증하며 에러율(Error Rate)이 나타나는지를 함께 분석해야 합니다. 이 상관관계를 통해 시스템의 성능 곡선을 그리고, '정상 구간', '포화 구간', '과부하 구간'을 명확히 구분할 수 있습니다. 이를 통해, "이 시스템은 200명의 동시 사용자가 접속했을 때 최대 500 TPS를 처리하며, 이 지점을 넘어서면 응답 시간이 급격히 저하되기 시작한다"와 같은 구체적이고 의미 있는 결론을 낼 수 있습니다.

---

3. 부하 테스트 도구

Java/Spring Boot 생태계에서 널리 사용되는 부하 테스트 오픈소스 도구는 JMeter, nGrinder, Gatling 세 가지가 대표적입니다.

• Apache JMeter
  • 오랫동안 업계 표준으로 자리 잡아온 순수 Java 기반의 GUI 도구입니다.
  • 장점: 방대한 커뮤니티와 풍부한 문서, 수많은 플러그인을 통해 HTTP, JDBC, JMS 등 다양한 프로토콜을 지원합니다. 직관적인 GUI 덕분에 초보자도 간단한 테스트 시나리오를 쉽게 작성할 수 있습니다.
  • 단점: GUI 자체가 상당한 시스템 자원을 소모하므로, 대규모 부하 테스트 시에는 CLI 모드 사용이 권장됩니다. 테스트 계획이 XML 파일로 저장되어 버전 관리나 코드 리뷰에 불편함이 있습니다. 스레드 기반 모델은 최신 도구에 비해 메모리 효율이 떨어질 수 있습니다.
• nGrinder
  • 네이버에서 The Grinder를 기반으로 개발한 오픈소스 도구로, 중앙 웹 컨트롤러를 통해 에이전트, 스크립트, 테스트 실행을 통합 관리하는 것이 특징입니다.
  • 장점: 컨트롤러-에이전트 아키텍처 덕분에 손쉽게 테스트 규모를 확장할 수 있습니다. 웹 UI는 테스트 관리, 스케줄링, 모니터링을 간소화합니다. 스크립트를 Groovy(JUnit 스타일)나 Jython으로 작성하므로 XML보다 개발자 친화적이며, IDE에서 사전 디버깅이 가능합니다.
  • 단점: JMeter에 비해 커뮤니티 규모가 작고, 구형 스레드 기반 엔진을 사용합니다.
• Gatling
  • 'Test as Code' 철학을 기반으로 한 현대적인 도구입니다. 테스트 시나리오를 Scala, Java, Kotlin 같은 프로그래밍 언어로 작성합니다.
  • 장점: Akka/Netty 기반의 비동기 메시지 구동 아키텍처 덕분에 적은 자원으로 매우 높은 부하를 생성할 수 있어 성능이 뛰어납니다. 코드로 테스트를 관리하므로 Git, 코드 리뷰, CI/CD 파이프라인과 완벽하게 통합됩니다. 기본적으로 생성되는 HTML 리포트의 가독성과 정보량이 매우 뛰어납니다.
  • 단점: 코드 작성에 익숙해야 하며, 특히 Scala DSL에 대한 약간의 학습 곡선이 존재합니다. 기본 지원 프로토콜의 종류는 JMeter보다 적습니다.

부하 테스트 도구별 비교

특징	JMeter	nGrinder	Gatling
주요 사용 방식	GUI 기반 (CLI 실행 권장)	웹 UI 기반	코드 기반 (DSL)
스크립트 언어	XML (GUI 설정)	Groovy, Jython	Scala, Java, Kotlin
리소스 모델	스레드/사용자	스레드/사용자	비동기/메시지 구동
CI/CD 친화성	보통 (XML 관리 불편)	좋음 (스크립트 파일 관리)	매우 좋음 (코드 기반)
리포팅 품질	보통 (플러그인 필요)	좋음 (웹 UI 통합)	매우 좋음 (기본 HTML 리포트)
추천 대상	GUI 환경 선호, 다양한 프로토콜 테스트 필요 시	중앙 관리형 테스트, 쉬운 확장성, 코드와 UI의 균형 필요 시	개발자 친화적 환경, CI/CD 통합, 고성능 부하 생성 필요 시

 

 

 

참고자료:

https://engineering-skcc.github.io/performancetest/Performance-Testing-Terminologies/

성능 테스트 유형 알아보기

https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals

Google SRE monitoring ditributed system - sre golden signals

https://firehydrant.com/blog/4-sre-golden-signals-what-they-are-and-why-they-matter/

4 SRE Golden Signals (What they are and why they matter)