부하 테스트 시 테스트 유저 수

“부하 테스트 시 테스트 유저 수(Concurrent Users) 설정 기준과 이유”에 대한 답변을 정리해드릴게요.
이건 실제 면접이나 실무에서도 자주 나오는 질문이에요.


---

✅ 1. 부하 테스트의 목적 이해

부하 테스트(Load Test)는 단순히 “얼마나 많은 사용자를 버티는가”보다,
시스템이 안정적으로 동작하는 한계 지점과 병목 구간을 파악하기 위한 과정입니다.
그래서 테스트 유저 수는 “무작정 큰 수치”보다는 현실적·통계적 근거에 따라 정해야 합니다.


---

⚙️ 2. 테스트 유저 수 설정 기준

(1) 실제 트래픽 기반

실서비스의 평균 동시 접속자 수 (Concurrent Users)
예: 하루 10,000명 방문, 피크타임 동시 500명 접속이라면
→ 테스트 유저 수를 500명 ±20~30% 범위 (예: 600명) 로 설정.

과거 로그(Log)나 APM(NewRelic, Datadog, Pinpoint 등)으로 실제 트래픽 패턴을 기반으로 결정.


🧩 이유: 현실적인 시나리오를 반영해야 병목 원인을 정확히 찾을 수 있기 때문.


---

(2) 성장 예측 기반

신규 서비스라면 예상 성장률(예: 월 20% 증가)을 반영해 예측 피크값의 1.5~2배로 설정.
→ 예: 런칭 초기 300명 예상이면 600명 부하까지 테스트.


🧩 이유: 실서비스는 홍보, 이벤트 등으로 트래픽이 급상승할 수 있으므로
“버퍼(capacity margin)” 확보가 필수.


---

(3) 시스템 용량 기반

서버 스펙(CPU, 메모리, 네트워크 I/O)에 따라 예상 동시 처리량(throughput)을 계산.

예:

1요청 처리 시간: 200ms

1초에 처리 가능한 요청 수(QPS): 1000ms / 200ms = 5req

서버 1대당 처리 가능 유저: 5 × 60 = 300
→ 서버 3대라면 약 900명 수준부터 부하 테스트 시도.



🧩 이유: 병렬 처리 능력과 응답 지연 한계를 수치로 검증 가능.


---

(4) 서비스 SLA 기반

예: SLA(서비스 수준 목표)가 “95% 요청 2초 이내 응답”이라면,
테스트 유저 수는 그 SLA를 유지할 수 있는 최대 동시 접속자 수로 조정.


🧩 이유: 실제 운영 환경에서의 품질 보장 기준을 만족하는지 확인하기 위해.


---

🧮 3. 정리 예시

기준 설정 방식 테스트 유저 수 예시 비고

실제 트래픽 실제 동시접속자 + 20~30% 500명 + 30% = 650명 가장 현실적
성장 예측 예상 피크 × 1.5~2 400명 × 2 = 800명 신규 서비스
시스템 용량 서버 1대 처리유저 × 서버수 300 × 3 = 900명 하드웨어 기반
SLA 기준 응답속도 유지 가능한 한계 700명까지 2초 이내 품질보장 중심



---

🎯 4. 답변 요약 (면접용 한 문단 버전)

> 부하 테스트 시 테스트 유저 수는 실제 트래픽 로그와 시스템 처리능력, SLA 목표를 기준으로 설정합니다.
보통 피크타임 동시접속자 수에 202배 수준으로 설정합니다.
이렇게 해야 실제 운영 환경에서의 안정성과 확장성을 검증할 수 있습니다.




---

원하시면 이 내용을 JMeter / k6 기준으로 실제 테스트 시나리오 (user 수, ramp-up, duration 설정 예시) 형태로도 이어드릴까요?