부하 테스트 용어집

부하 테스트(Load Testing)란?

부하 테스트는 예상 트래픽 및 피크 조건에서 시스템 성능, 안정성, 용량을 평가하기 위해 실제 사용자 트래픽을 시뮬레이션하는 기법입니다. 다음과 같은 질문에 답합니다:

시스템이 몇 명의 동시 사용자를 처리할 수 있는가?
지속 가능한 최대 처리량은 얼마인가?
극한 부하에서 성능은 어떻게 저하되는가?
시스템 병목은 어디에 있는가?

부하 테스트 유형

Load Testing (부하 테스트)

일반적인 조건에서의 성능을 측정하기 위해 현실적인 예상 부하를 시뮬레이션하는 테스트. 주요 목표는 정상~피크 사용 환경에서 응답 시간, 처리량, 리소스 사용률을 측정하는 것입니다.

사용 시점: 릴리스 전 정기 성능 검증, 벤치마크 수립.

Stress Testing (스트레스 테스트)

장애 지점과 임계값을 파악하기 위해 시스템을 정상 용량 이상으로 밀어붙이는 테스트. 시스템이 실패할 때까지 부하를 점진적으로 증가시킵니다.

목표: 최대 용량 및 우아한 성능 저하(graceful degradation) 동작 확인.

핵심 질문: 설계 한계를 초과하면 어떤 일이 발생하는가?

Spike Testing (스파이크 테스트)

단시간에 부하를 급격히 증가시켜 회복력을 테스트하는 방법. 예상치 못한 트래픽 급증(플래시 세일, 바이럴 트윗, DDoS)을 시뮬레이션합니다.

예시: 정상 부하 1,000명 → 갑자기 2분간 50,000명 → 다시 1,000명.

측정 항목: 회복 시간, 스파이크 중 오류율, 스파이크 후 리소스 정리.

Soak Testing (소크 테스트)

장시간(수 시간~수 일)에 걸쳐 중간 수준의 부하를 지속 적용해 다음 문제를 탐지합니다:

애플리케이션 코드의 메모리 누수
커넥션 풀 고갈
시간 경과에 따른 리소스 저하
캐시 포화 문제
디스크 공간 소진

기간: 시스템에 따라 일반적으로 8~48시간.

Capacity Testing (용량 테스트)

성능 SLO를 충족하면서 시스템이 처리할 수 있는 최대 사용자/트랜잭션 수를 결정하는 테스트. 스트레스 테스트와 달리 성능이 허용 가능한 “최적 최대값”을 찾습니다.

Endurance Testing (내구성 테스트)

장기간 테스트(소크 테스트와 유사)로, 특히 오랜 운영 후에만 나타나는 문제를 검증합니다.

주로 발견하는 문제:

점진적 저하를 유발하는 리소스 누수
디스크 공간을 소진하는 로그 파일 증가
오래되어 무효화된 데이터베이스 통계

핵심 성능 메트릭

Response Time / Latency (응답 시간 / 레이턴시)

요청을 보낸 시점부터 완전한 응답을 받을 때까지의 시간.

전체 응답 시간 = 네트워크 지연 + 서버 처리 + 렌더링

왜 중요한가: 사용자 경험에 직접 영향을 미칩니다. 응답 시간이 100ms 증가할 때마다 전환율이 약 1% 감소합니다.

측정 시 주의:

사용자가 응답을 읽거나 처리하는 시간은 포함되지 않음
엔드포인트/트랜잭션마다 다름
부하 및 시간대에 따라 변동

Throughput (처리량)

단위 시간당 처리된 요청 수.

처리량 (RPS) = 전체 요청 수 / 전체 시간(초)

주요 단위:

RPS: 초당 요청 수 (Requests Per Second)
TPS: 초당 트랜잭션 수 (Transactions Per Second)
IOPS: 초당 I/O 작업 수
Mbps: 초당 메가비트 (데이터 처리량)

왜 중요한가: 최대 처리량이 확장성 한계를 결정합니다.

Error Rate (오류율)

전체 요청 대비 실패 요청의 비율 또는 횟수.

오류율 (%) = (실패 요청 수 / 전체 요청 수) × 100

허용 기준:

프로덕션: < 0.1% (성공률 99.9%)
테스트 기준선: 피크 부하에서 2배 이상 증가하지 않아야 함
스트레스 테스트: 기준 완화, 우아한 성능 저하 여부 확인

오류 유형:

5xx (서버 오류)
4xx (클라이언트/유효성 검사 오류)
타임아웃
연결 거부
Assertion 실패

Percentile Latency / P50 / P95 / P99 / P99.9 (백분위 레이턴시)

순위 정렬된 응답 시간의 특정 백분위수에서의 레이턴시. 중요: 평균 레이턴시만 측정하면 절대 안 됩니다.

P95 레이턴시: 전체 요청의 95%가 이 값보다 빠르게 완료됨
사용자의 80%는 P95 이하의 레이턴시를 경험
20%는 더 느린 레이턴시(꼬리 레이턴시)를 경험

비교 예시: P95 = 200ms, P99 = 500ms인 경우

100명 중 95명은 200ms 이하 응답
100명 중 99명은 500ms 이하 응답
최악 1%는 500ms 초과 (최대 레이턴시까지)

백분위수가 중요한 이유:

[100, 100, 100, 100, 10000]의 평균 = 2060ms (오해 유발!)
P95 = 100ms (실제 사용자 경험을 더 잘 반영)

권장 모니터링 지표:

P50 (중앙값)
P95 (우수한 사용자 경험 기준)
P99 (꼬리 레이턴시 문제 식별)
Max (최악의 케이스)

CPU and Memory Utilization (CPU 및 메모리 사용률)

테스트 중 소비되는 시스템 리소스 비율.

확인할 수 있는 것:

리소스 효율성
시스템이 성장을 감당할 수 있는지
용량 계획 필요성

위험 신호:

CPU가 지속적으로 > 80%: 여유 공간(headroom) 부족
시간이 지남에 따라 증가하는 메모리: 메모리 누수 가능성
메모리 급증: 버퍼 할당 문제

Concurrent Users vs. Request Rate (동시 사용자 vs. 요청 속도)

부하를 정의하는 두 가지 방법:

Concurrent Users (동시 사용자):

100명의 동시 사용자 = 동시에 활성화된 사용자 100명
각 사용자는 X초마다 1개의 요청 전송 (Think Time에 따라 다름)
총 RPS는 Think Time에 의존

Request Rate (요청 속도):

1000 RPS = 사용자 수와 무관하게 초당 1000개 요청
서버 부하를 더 직접적으로 측정
응답 시간이 다른 1000 RPS ≠ 동일한 CPU 부하

변환:

대략적 RPS = 동시 사용자 수 / 평균 Think Time
예시: 100명 사용자 × (60초 Think Time / 300초 전체 = 0.2 RPS) = 20 RPS

부하 테스트 패턴

Constant Load (일정 부하)

테스트 전체 기간 동안 X명의 동시 사용자/RPS를 일정하게 유지.

사용자: ════════════════════
시간:   0                  30분

사용 사례: 기준 성능 측정, 안정성 검증.

Ramp-up Pattern (점진적 증가 패턴)

시스템 안정화를 허용하면서 0에서 목표 부하까지 점진적으로 증가.

사용자: ╱════════════════════
시간:   0  5분             30분
(5분에 걸쳐 100명까지 증가)

이유: 실제 사용 패턴을 반영하지 않는 인위적 트래픽 급증 방지.

일반적인 Ramp-up 기간: 1시간 미만 테스트는 1~~5분, 더 긴 테스트는 5~~15분.

Staircase (Step Load) Pattern (계단형 부하 패턴)

일정 간격으로 부하를 단계적으로 증가시키며 성능 저하 지점 파악.

사용자: ╱╱╱╱
       ════════════
시간:   0    10분
(2분마다 25명씩 증가)

사용 사례: 용량 테스트, 임계점 파악.

Spike Pattern (스파이크 패턴)

갑작스러운 부하 증가 후 기준선으로 복귀.

사용자: ═══╱════╲═══
시간:   0  5  8  15분

측정: 회복 능력, 급격한 급증 시 오류 처리.

Wave Pattern (파형 패턴)

시간대별 트래픽 패턴을 모방하는 주기적 증가/감소.

사용자: ╱╲╱╲╱╲
시간:   0      30분

사용 사례: 이커머스, 뉴스 사이트 등 현실적인 트래픽 시뮬레이션.

Think Time (생각 시간)

정의: 사용자가 콘텐츠를 읽거나 처리하는 시간을 시뮬레이션하기 위한, 사용자 액션 사이의 지연.

Think Time = 한 요청의 끝과 다음 요청의 시작 사이의 시간

애플리케이션 유형별 예시:

이커머스: 5~30초 (상품 상세 페이지 탐색)
뱅킹: 10~60초 (거래 내역 읽기)
API 호출: 0~2초 (백엔드 간 통신)
모바일 앱: 앱 동작에 따라 다양

테스트에 미치는 영향:

Think Time 없음: 인위적 급증, 실제 동작 미반영
Think Time 있음: 현실적인 점진적 요청, 더 나은 부하 분산

// 부하 테스트: 100명의 동시 사용자, Think Time 15초
실제 RPS = 100명 / 15초 = 약 7 RPS

Headroom & Capacity Planning (여유 공간 및 용량 계획)

Headroom (여유 공간)

정상 운영 부하와 최대 용량 사이의 안전 마진.

Headroom = (최대 용량 - 예상 피크 부하) / 최대 용량

예시:
- 시스템 최대 처리량: 10,000 RPS
- 예상 피크: 7,000 RPS
- Headroom = 3,000 / 10,000 = 30%

권장 Headroom: 안전을 위해 20~30%.

왜 필요한가:

예측을 초과하는 트래픽 급증
배포 중 일시적인 성능 저하
긴급 스케일링 한계

Headroom 부족 시 결과:

예상치 못한 부하에 대한 버퍼 없음
오토스케일링 지연으로 성능 저하
연쇄 장애 가능성

주요 병목 유형

Database (데이터베이스)

느린 쿼리, 커넥션 풀 고갈, 또는 Lock 경합.

징표:

CPU는 정상이지만 응답 시간이 높음
서버를 추가해도 처리량이 증가하지 않음
특정 엔드포인트만 느리고 다른 것은 빠름

CPU

애플리케이션이 요청을 효율적으로 처리하지 못하는 상태.

징표:

CPU가 지속적으로 > 80%
부하에 비례해 응답 시간 증가
용량을 추가해도 도움이 안 됨 (요청당 응답 시간 자체가 높음)

Memory (메모리)

가비지 컬렉션 일시 정지나 스왑 사용을 유발하는 RAM 부족.

징표:

레이턴시 급등에서 Young Generation GC 일시 정지 확인
메모리가 꾸준히 증가 (누수)
특정 부하 수준에서 애플리케이션 크래시

Network Bandwidth (네트워크 대역폭)

데이터 전송에 필요한 네트워크 용량 부족.

징표:

응답당 데이터 볼륨이 큼
리소스가 충분한데도 처리량이 정체
네트워크 인터페이스 > 70% 사용률

Disk I/O

로깅, 캐싱, 데이터 저장에 불충분한 디스크 속도.

징표:

CPU 메트릭에서 높은 I/O 대기
순차 쓰기가 많은 작업이 느림
SSD 마이그레이션 후 성능 향상

테스트 결과 해석

허용 가능한 응답 시간 기준

웹 애플리케이션: 사용자 facing 요청 < 2초
백엔드 API: 내부 호출 < 200ms
모바일: < 3초 (레이턴시 허용 범위가 더 넓음)
실시간 시스템: < 100ms

용량 결정 방법

예상 피크의 25%, 50%, 75%, 100%, 125%로 부하 테스트
처리량(RPS) vs. 응답 시간 그래프 작성
응답 시간이 급격히 상승하는 “무릎(knee)” 지점 파악
해당 지점 × 0.75~0.85 = 권장 용량 상한

회귀(Regression) 탐지

테스트 결과를 Baseline과 비교:

응답 시간 저하 > 15%: 조사 필요
처리량 감소 > 10%: 코드 분석 필요
오류율 > 0.1%: 심각한 문제

피해야 할 안티패턴

❌ Think Time 없이 테스트: 비현실적인 트래픽 급증을 유발함

❌ 평균 레이턴시만 측정: 꼬리 레이턴시 문제를 놓침

❌ 단일 페이로드 크기로 테스트: 실제 환경에서는 다양한 크기가 존재함

❌ DB 상태 무시: 데이터 볼륨이 쿼리 성능에 영향을 줌

❌ 단일 위치에서 테스트 실행: 네트워크 레이턴시는 지역마다 다름

❌ 테스트 사이에 데이터 정리 안 함: 이전 데이터가 새 테스트의 유효성에 영향을 줌

이 가이드를 내 서비스에 직접 적용해 보세요.

TestForge 무료 스캔 시작 →