1부에서는 성능 테스트의 개념과 절차, 그리고 JMeter가 웹·API 부하 테스트를 다루는 기본 동작 원리를 살펴봤습니다. 2부에서는 실무에서 진짜 위력을 발휘하는 심화 기능을 소개합니다. 단발성 요청을 넘어 장시간·복합 시나리오·대규모 부하를 다루고, 결과를 보고서로 풀어내는 방법까지 정리합니다.

지구력 테스트는 평균적인 부하를 장시간 지속적으로 가해, 시간이 지나도 시스템이 버티는지 확인합니다. 짧은 테스트에서는 드러나지 않는 메모리 누수, 리소스 고갈, 점진적 성능 저하(응답 시간 증가·처리량 감소)를 잡아내는 데 목적이 있습니다.

STEP 1. Thread Group 추가하기

Test Plan에서 우클릭 → Add > Threads(Users) > Thread Group 을 선택합니다.

STEP 2. 부하 설정하기

Thread Properties에서 평균 부하 수준에 맞게 값을 설정합니다.

• Number of Threads (users) — 예: 50~200 (유지할 동시 사용자 수)

• Ramp-up period (seconds) — 예: 300 (지정한 사용자 수에 도달하기까지의 시간)

• Loop Count — Infinite로 두면 정지 전까지 시나리오를 계속 반복합니다.

[그림 1] Thread Group — Number of Threads 50 · Ramp-up 300 · Loop 무한 설정

STEP 3. HTTP Request로 시나리오 구성하기

Thread Group에서 우클릭 → Add > Sampler > HTTP Request 를 선택하고, 실제 사용자 흐름을 모방하도록 요청을 구성합니다.

STEP 4. Think Time을 위한 Timer 추가하기

Thread Group에서 우클릭 → Add > Timer > Constant Timer 를 선택합니다.

[그림 2] Add > Timer > Constant Timer 선택

STEP 5. 결과 수집용 리스너 추가하기

HTTP Request → Add > Listener 로 다음 리스너들을 추가합니다.

• Summary Report — 전체 성능 지표 요약

• jp@gc - Transactions per Second — 초당 처리량 추이

• jp@gc - PerfMon Metrics Collector — 서버 자원(CPU·메모리 등) 모니터링 (6장 참고)

STEP 6. Non-GUI(CLI) 모드로 실행하기

장시간 테스트는 반드시 Non-GUI 모드로 실행합니다. 명령 프롬프트(cmd)에서 jmeter.bat이 있는 bin 폴더로 이동한 뒤 다음 명령을 입력합니다.

• -n : Non-GUI 모드 /  -t : 테스트 계획(jmx)  /  -l : 결과 파일(jtl)  /  -e -o : 종료 후 HTML 리포트 생성

[그림 3] Non-GUI 모드 실행 — summary 로그로 진행 상황(처리량·응답시간·에러) 확인

STEP 7. 결과 확인하기

1. 실행이 끝나면 jp@gc - PerfMon Metrics Collector 의 Filename에서 Browse... 로 결과 파일(.jtl)을 선택해 서버 자원 사용량 그래프를 확인합니다.

2. -e -o 옵션으로 생성된 HTML 리포트 폴더의 index.html에서도 응답 시간·처리량·에러율 등 종합 결과를 볼 수 있습니다.

단일 요청이 아니라 ‘접속 → 회원가입 페이지 이동 → 회원가입 → 로그인 → 로그아웃’처럼 여러 단계로 이어지는 실제 사용자 흐름을 측정하는 방식입니다. 실제 서비스의 성능은 이런 ‘흐름’ 단위에서 드러나기 때문에, 복합 시나리오는 현장에서 매우 자주 쓰입니다.

두 가지 핵심 장치

• HTTP Cookie Manager — 각 단계에서 서버가 발행하는 쿠키를 자동 저장·전달해 로그인 세션을 유지합니다. 여러 요청에 걸쳐 사용자 상태를 이어가야 하므로 복합 시나리오에서는 거의 필수입니다.

• CSV Data Set Config — 가상 사용자마다 서로 다른 ID·비밀번호 등을 쓰도록, CSV 파일에서 한 줄씩 읽어 변수에 할당합니다. 스크립트에서는 ${변수명} 형식으로 사용합니다.

CSV Data Set Config의 주요 설정

구성이 끝나면 실제 사용자의 행동 순서대로 각 단계를 HTTP Request로 배치하고, 결과는 View Results Tree(요청별 디버깅 — 변수가 실제 값으로 잘 치환됐는지 확인)와 Summary Report(요청별·전체 성능 통계)로 확인합니다.

복잡한 시나리오를 일일이 손으로 만드는 대신, 실제 브라우저 동작을 ‘녹화’해 테스트 스크립트를 자동 생성하는 기능입니다. JMeter를 프록시로 두고 브라우저로 사이트를 사용하면, 발생한 요청들이 Recording Controller 아래에 그대로 쌓입니다.

녹화를 위해서는 브라우저의 프록시를 JMeter(기본 포트 8888)로 향하게 하고, HTTPS 트래픽을 캡처하려면 JMeter가 생성한 루트 인증서(ApacheJMeterTemporaryRootCA.crt)를 브라우저에 신뢰 인증서로 등록해야 합니다. 불필요한 요청(이미지·광고 등)은 Include/Exclude 필터로 걸러낼 수 있습니다. 녹화가 끝나면 레코더를 끄고, 쌓인 요청을 그대로 부하 테스트에 활용합니다.

[그림 1] 녹화로 생성된 요청 트리(Recording Controller)와 결과 그래프

JMeter는 결과를 보기 좋은 HTML 보고서로 자동 변환해 줍니다. 먼저 결과를 .csv 파일로 저장한 뒤, 상단 메뉴 Tools > Generate HTML Report에서 결과 CSV와 jmeter.properties 파일, 그리고 비어 있는 출력 폴더를 지정하면 됩니다. 생성된 폴더의 index.html을 열면 응답 시간·처리량·에러율 등이 그래프와 표로 정리된 종합 보고서를 확인할 수 있습니다.

[그림 2] Generate HTML Report — 결과 CSV·properties·출력 폴더 지정

단일 PC에서 만들 수 있는 가상 사용자는 사양에 따라 보통 500~1,000명 내외입니다. 그 이상을 무리하게 생성하면 JMeter 자체가 과부하로 병목이 되어, 정작 테스트 대상 서버가 아니라 ‘부하를 만드는 PC’가 한계에 부딪힙니다. 이를 해결하는 것이 분산 테스트입니다.

[그림 3] 분산 테스트 구성도 — Master가 여러 Slave를 제어해 대규모 부하를 생성

Master에는 제어할 Slave들의 IP를 등록하고, Slave에서는 에이전트(jmeter-server)를 실행해 대기시킵니다. 이후 Master에서 Run > Remote Start All로 모든 Slave를 동시에 가동합니다.

응답 시간·TPS만으로는 성능 저하의 ‘원인’을 규명하기 어렵습니다. 부하를 주는 동안 서버의 CPU·메모리·디스크 I/O·네트워크를 함께 수집해야, 어디서 병목이 생겼는지 체계적으로 추정할 수 있습니다. JMeter의 PerfMon 플러그인이 이 역할을 합니다.

모니터링 대상 서버에 Server Agent를 실행해 두고, JMeter 테스트 계획에 PerfMon Metrics Collector 리스너를 추가한 뒤 서버의 IP와 수집할 지표(CPU·Memory·Network I/O·Disk I/O)를 지정합니다. 테스트를 실행하면 부하에 따른 서버 자원 변화를 실시간 그래프로 확인할 수 있고, 결과는 .jtl 파일로 저장해 상세 분석에 활용합니다.

[그림 4] PerfMon Metrics Collector — 부하에 따른 서버 CPU·메모리·네트워크 변화

7.1 가상 서비스(Virtual Service)를 활용한 테스트

테스트 대상이 의존하는 외부·연계 시스템이 항상 가용한 것은 아닙니다. 이때 실제 시스템의 동작을 모방(Mocking/Stubbing)하는 가상 서비스로 응답을 미리 정의하면, 안정적인 테스트 환경을 확보하고 종속성에 따른 불확실성을 제거할 수 있습니다.

7.2 응답 코드(Response Code) 이해하기

응답 코드는 시스템이 요청에 어떤 결과를 반환했는지 보여주는 중요한 지표입니다. 성공률 계산, 오류 분포 분석, 응답 코드별 응답 시간 비교에 활용됩니다.

7.3 성능 목표 설정 예시

성능 목표는 측정 가능해야 하며, SLA와 프로젝트 특성을 고려해 고객사와 협의해 최종 확정합니다. 아래는 일반적인 예시입니다.

7.4 워크로드 설계 예시

워크로드 모델링은 실제 사용 환경을 시뮬레이션해 현실적인 데이터를 얻기 위한 핵심 단계입니다. 시간대·요일·이벤트 등 다양한 시나리오를 반영하고, 실제 운영 데이터를 기반으로 고객사와 협의해 검증합니다.

• 동시 사용자 수 — 최대 500명 시뮬레이션, 일반 사용자(400)·관리자(100) 등 유형 구분

• 트랜잭션 비율 — 로그인 20% / 조회 50% / 입력 25% / 로그아웃 5% (실제 통계 기반)

• 테스트 시간 — Ramp-up 10분(0→500명), Steady State 60분 유지, Ramp-down 10분

• 기타 조건 — 운영과 동일 스펙의 스테이징 서버, 네트워크 지연 50ms·패킷 손실 없음 등 명시

 7.5 성능 분석과 개선 방안 — 4단계 프로세스

테스트 결과를 해석하고 문제 유형을 분류해, 개발팀이 즉시 조치할 수 있는 근거를 보고하는 4단계 프로세스입니다. 테스터는 ‘해결사’가 아니라 ‘안내자’로서 어디를 검토해야 할지 방향을 제시합니다.

1단계 · 전반적 성능 분석 (현상 파악)

응답 시간(평균·최대·분포), 처리량(TPS), 에러율(특히 5xx), 자원 사용률(한계 도달 여부)을 확인해 ‘무엇이’ 일어나는지 객관적으로 파악합니다.

2단계 · 문제 유형 식별 (원인 진단)

3단계 · 원인 추정 및 보고 (근거 정리)

• 병목 — 시간대별 성능 지표와 서버 자원 지표를 교차 분석하고, 저하 시점의 에러 로그를 증거로 첨부. 예: “사용자 100명 도달 시 DB CPU 95%, 평균 응답 1초→5초”

• 비정상 패턴 — 기능별로 개별 테스트해 느린 기능을 특정하고 자원 사용량을 관찰. 예: “‘마이페이지 조회’만 단독 평균 2.5초”

• 시스템 구성 — 관찰 현상 기반으로 가설을 세워 ‘수정’이 아닌 ‘확인 요청’ 관점으로 전달. 예: “TPS가 150에서 정체되는데 CPU는 50% 여유 → 스레드/커넥션 풀 설정 확인 필요”

4단계 · 개선 방안 및 권고 작성

• 병목 — 예: “DB CPU 100% 도달이 주원인. 관련 쿼리 튜닝 또는 DB 자원 증설 검토 요청”

• 비정상 패턴 — 예: “해당 API 내부 로직이 비효율적. 데이터 조회·처리 과정 상세 분석 권고”

• 시스템 구성 — 예: “자원 여유에도 처리량이 정체. WAS 스레드 풀 또는 DB 커넥션 풀 설정값 검토 필요”

7.6 서버 자원 모니터링 도구

서버 모니터링은 전문 도구나 JMeter 자체 기능으로 수행합니다. 일반적으로 DataDog, New Relic, WhaTap 등을 많이 활용하며 시각화·알림 기능이 강력합니다. JMeter만으로 진행한다면 6장의 PerfMon 플러그인으로 CPU·메모리·네트워크·디스크 I/O 지표를 수집할 수 있습니다. 테스트 환경에 따라 전용 솔루션과 JMeter 내장 기능을 선택적으로 활용하세요.

2부에서는 지구력 테스트, CSV 복합 시나리오, 스크립트 레코더, HTML 리포트, 분산 테스트, PerfMon 모니터링까지 JMeter의 심화 기능을 살펴보고, 성능 목표·워크로드 설계와 4단계 분석법으로 결과를 보고서로 풀어내는 방법을 정리했습니다.

성능 테스트는 한 번의 이벤트가 아니라 품질을 지키는 꾸준한 활동입니다. 1·2부의 내용을 토대로, 서비스에 맞는 시나리오와 목표를 정의하고 반복적으로 측정·개선해 나가시길 바랍니다.