· AI Testing
LLM Testing Vision AI Testing AI agent Testing Physical AI Testing· Data Validation
AI Ready 데이터 검증· Software Testing
SW Testing서비스를 오픈하기 직전, 마지막까지 마음을 졸이게 만드는 질문이 있습니다. “실제 사용자가 한꺼번에 몰려와도 우리 시스템이 버텨줄까?” 기능이 아무리 완벽해도 성능이 받쳐주지 못하면 서비스의 신뢰는 한순간에 무너집니다. 성능 테스트는 바로 이 불안을 사전에 검증하고 제거하기 위한 활동입니다.
이 글에서 다루는 내용 성능 테스트란 무엇이고 왜 필요한가 성능 테스트의 목적과 3가지 대표 유형 성능 테스트 수행 6단계와 결과 분석 · 보고서 작성 주요 성능 테스트 도구 비교 JMeter 구성 요소와 기본 부하 테스트 실습, 결과를 읽는 법 |
성능 테스트(Performance Testing)는 웹 서비스나 애플리케이션이 실제 운영 환경에서 기대하는 수준의 성능을 꾸준히 유지할 수 있는지 검증하는 테스트 활동입니다. 단순히 기능이 동작하는지를 보는 것을 넘어, 실제 사용 조건(부하) 아래에서의 품질을 평가한다는 점이 핵심입니다.
일반적으로 다음 지표를 측정하며, 부하 상황에서도 시스템이 안정적으로 동작하는지 확인합니다.
응답 시간(Response Time) — 요청에 대해 시스템이 반응하기까지 걸린 시간
처리량(Throughput) — 단위 시간당 처리 가능한 트랜잭션 또는 사용자 수
동시 사용자 수(Concurrency) — 같은 시점에 시스템을 사용하는 사용자 규모
자원 사용률(Resource Utilization) — CPU, 메모리, 디스크 I/O 등 서버 자원의 사용 정도
성능 문제는 사후 대응보다 사전 예방이 훨씬 저렴합니다. 다음 상황이라면 성능 테스트를 반드시 일정에 포함해야 합니다.
다수의 동시 접속자가 예상되는 서비스 오픈 전
마이크로서비스 전환 등 시스템 구조를 변경한 이후
대용량 데이터 처리나 배치 시스템을 운영할 때
SLA(서비스 수준 협약)를 명시해야 하는 외부 계약 시스템
용어 — SLA SLA(Service Level Agreement)는 서비스 제공자와 고객 사이에 합의된 서비스의 품질·성능 수준을 명시한 공식 계약입니다. 응답 시간, 가용성 등이 SLA의 대표 항목입니다. |
성능 테스트는 특정 시스템에 국한되지 않습니다. 시스템의 구조와 특성, 트래픽 규모, 요구 성능 수준에 따라 대상과 도구가 달라집니다.
| 구분 | 대상 시스템 예시 | 주로 쓰는 도구 |
|---|---|---|
웹 애플리케이션 | 포털, 쇼핑몰, 금융 서비스, 공공 웹사이트 | JMeter, LoadRunner, K6, NeoLoad |
모바일 앱 | 주문·예약 시스템, 커뮤니티, 실시간 알림 | Appium+JMeter, K6, Firebase Test Lab |
서버 및 API | RESTful API, GraphQL, 인증 서버 | Postman, JMeter, Gatling, K6 |
백엔드 시스템 | 배치 처리, 데이터 집계, 분석 파이프라인 | JMeter(Non-GUI), Locust, BlazeMeter |
인프라 구성 | DBMS, 캐시 서버(Redis), 로드 밸런서 | HammerDB, RedLine13, Tsung |
시스템 안정성·가용성 확보 — 예상 최대 부하에서도 중단 없이 동작하는지 확인
성능 병목 구간 식별 — 응답 지연, 과부하, 메모리 누수 등 저하 원인을 조기에 발견
시스템 자원 최적화 — CPU·메모리·네트워크가 효율적으로 쓰이는지 분석
SLA 검증 — 고객과 합의한 성능 수준 충족 여부를 객관적 수치로 증명
성능 기준 수립 — 향후 확장·운영·유지보수의 참고 기준치 마련
성능 테스트는 검증하려는 상황에 따라 여러 유형으로 나뉩니다. 가장 자주 쓰이는 세 가지는 다음과 같습니다.
정상적인 사용량 또는 점진적으로 증가하는 부하를 가해, 시스템이 정상 범위 내에서 성능을 유지하는지 확인합니다. 최대 동시 사용자 수 산정, 트랜잭션 처리 한계 파악, 자원 소비 균형 확인이 주된 목적입니다.
용어 — 트랜잭션(Transaction) 사용자가 시스템과 상호작용하는 일련의 작업 흐름 중, 시작부터 끝까지 하나의 완결된 업무 처리 단위를 말합니다. 예: ‘로그인 → 상품 조회 → 장바구니 담기’ 한 묶음. |
예상치를 넘어서는 과도한 부하를 가해 시스템이 실패하거나 비정상 동작하는 경계 지점을 찾습니다. 과부하 시 오류 발생 시점, 장애 후 복구 시간, 예외 처리의 정상 동작 여부를 평가합니다.
장시간 동안 일정 부하를 지속적으로 가해, 시간이 지나도 성능 저하나 자원 누수가 발생하지 않는지 검증합니다. 메모리 누수, 디스크·네트워크 자원 고갈, 장시간 사용 후 응답 속도가 주요 관찰 대상입니다. (자세한 내용은 2부에서 다룹니다.)
신뢰할 수 있는 결과를 얻으려면 성능 테스트도 체계적인 절차를 따라야 합니다. 더테스트는 전 과정을 다음 6단계로 나누어 진행합니다.
테스트의 전반적인 방향성과 기준을 정의합니다. 테스트 목표(응답 시간·처리량·자원 사용률), 범위(전체 시스템/특정 모듈/API), 성능 기준(SLA·TPS·Latency), 사용 도구, 리스크와 일정·인력 계획을 정리합니다.
실제 사용자 환경을 반영해 현실적인 부하 조건을 재현합니다. 핵심 사용자 행위 기반 시나리오를 정의하고, 사용자 수·동시 접속자·처리량 비율 등 워크로드를 모델링하며, 사용자 유형별 부하 패턴과 테스트 데이터 전략을 수립합니다.
운영 환경과 최대한 유사한 환경을 구성해야 신뢰도 높은 결과를 얻습니다. 서버·클라이언트·네트워크 구성, 도구 설치, 운영 환경과의 차이점 문서화, 모니터링 도구 연동, 환경 안정성 검증(Smoke Test)이 포함됩니다.
작성한 시나리오를 기반으로 부하를 주입하고 데이터를 수집합니다. 성능 지표를 실시간으로 모니터링하고, 단위 → 통합 → 임계 테스트 순으로 다양한 조건에서 반복 수행합니다.
수집한 데이터에서 병목 지점, 취약점, 개선 포인트를 식별합니다. 목표 기준과 비교하고(SLA 초과 여부), 지표 간 상관관계(예: 트래픽 증가 ↔ DB 응답 지연)를 분석해 병목 원인을 추정합니다.
수행 내역과 분석 결과를 문서화해 관련 부서·의사결정자와 공유합니다. 주요 성능 지표, 문제점과 병목, 개선 제안과 후속 계획을 그래프·지표와 함께 정리합니다.
| 지표 | 의미 | 확인 포인트 |
|---|---|---|
응답 시간 | 각 요청에 시스템이 반응한 시간 | 평균뿐 아니라 최대값·분포(95퍼센타일)까지 확인 |
처리량(TPS) | 단위 시간당 처리한 트랜잭션 수 | 목표치 도달 여부, 안정적으로 유지되는지 |
에러율 | 전체 요청 중 실패한 비율 | 특히 5xx 서버 에러는 내부 문제의 강력한 신호 |
자원 사용률 | CPU·메모리·디스크·네트워크 사용 정도 | 한계치(예: 90% 이상) 도달 시점 확인 |
결과 분석은 ① 주요 지표 확인 → ② 병목 현상 분석(저하 시점의 원인 추적) → ③ 성능 목표·SLA와 비교 → ④ 개선 후 재테스트 → ⑤ 보고서 작성·공유의 순서로 진행됩니다. APM이나 서버 모니터링 도구를 함께 활용하면 병목 지점을 정확히 짚어낼 수 있습니다.
보고서는 객관적이고 구조화된 형태여야 합니다. 더테스트가 권장하는 표준 목차는 다음과 같습니다.
개요 — 목적·배경, 범위, 테스트 대상 환경(HW/SW/네트워크)
테스트 설계·구성 — 시나리오, 워크로드 모델, 성능 지표 및 목표(SLA)
실행 결과 — 요약 결과표, 시간대별 그래프·차트, 이벤트 로그 요약
성능 분석·문제점 — 병목 현상, 비정상 패턴, 시스템 구성 이슈
개선 방안·권고 — 단기 조치와 장기 구조 개선을 분리해 제안
결론·참고 — 목표 달성 여부, 향후 계획, 설정값·로그·스크립트 첨부
성능 테스트 시 꼭 챙겨야 할 5가지 운영 환경과 일치하는 테스트 환경(서버 사양·네트워크·DB 설정 동일하게 유지) 현실적인 워크로드 설계(실제 사용 패턴 반영) 목표 기준의 명확화(응답 시간·처리량·자원 사용률 목표값 정의) 데이터 일관성 관리(중복·비정상 데이터로 인한 왜곡 방지, 초기화 전략 포함) 실시간 모니터링 및 로깅(이상 징후 시점 파악과 원인 분석의 필수 요소) |
도구는 테스트 환경, 시스템 특성, 예산, 분석 기능에 따라 선택해야 합니다. 현장에서 자주 쓰이는 주요 도구를 비교하면 다음과 같습니다.
| 도구 | 라이선스 | 특징 | 장 / 단점 | ||
|---|---|---|---|---|---|
Apache JMeter | 무료 | Java 기반 대표 오픈소스, 다양한 프로토콜 지원 | 커뮤니티·플러그인 풍부 / UI가 다소 복잡 | ||
LoadRunner | 유료 | Micro Focus 상용 도구, 대기업에서 다수 사용 | 실시간 모니터링 강력 / 고가, 학습 곡선 높음 | ||
K6 | 무료/유료 | JavaScript 기반 CLI 도구(Grafana) | DevOps 친화·클라우드 연계 / GUI 없음 | ||
Gatling | 무료/유료 | Scala 기반 고성능 부하 도구 | 경량·HTML 리포트 / 학습 곡선 있음 | ||
Locust | 무료 | Python 기반 경량 부하 도구 | 커스터마이징 쉬움 / 초기 셋업 난이도 | ||
BlazeMeter | 무료/유료 | JMeter 기반 클라우드 플랫폼 | 대규모 트래픽 / 유료 플랜 종속 | ||
왜 JMeter로 시작할까 무료 오픈소스라 도입 비용이 없고, 자료와 플러그인이 풍부합니다. GUI로 시나리오를 시각적으로 구성하면서도 Non-GUI(CLI) 모드로 대규모·장시간 테스트까지 소화할 수 있어, 입문부터 실무까지 폭넓게 쓰입니다. 이 가이드의 실습도 JMeter를 기준으로 합니다. |
JMeter는 Java로 개발된 오픈소스 성능 테스트 도구입니다. 별도의 설치 과정 없이 압축을 풀고 bin/jmeter.bat 을 실행하면 바로 사용할 수 있습니다(Java 설치 필요). 그래프 시각화를 위한 플러그인(Plugins Manager, Basic Graphs 등)을 더하면 분석이 한층 수월해집니다.
JMeter의 테스트 계획(Test Plan)은 트리 구조입니다. 아래 구성 요소를 조합해 ‘누가, 무엇을, 어떻게 요청하고, 결과를 어떻게 볼지’를 정의합니다.
| 구성 요소 | 역할 |
|---|---|
Thread Group | 부하의 양과 패턴을 정의하는 핵심 요소. 가상 사용자 수, 부하 증가 시간(Ramp-up) 등을 설정해 실제 트래픽을 모방 |
Sampler (HTTP Request) | 실제로 서버에 보내는 요청. 브라우저가 보내는 HTTP 요청을 정확히 모방해 부하를 가하고 응답을 받음 |
Config Element | 공통 설정. User Defined Variables(변수), HTTP Cookie Manager(세션 유지), CSV Data Set Config(데이터 주입) 등 |
Timer | 요청 사이의 ‘생각하는 시간(Think Time)’을 부여해 실제 사용자처럼 동작하게 함 |
Listener | 결과를 수집·표시. Summary Report, View Results Tree, 각종 그래프(jp@gc) 등 |
![제목: [그림 1] 구성 요소 추가 메뉴(우클릭 > Add) — Test Plan 트리에 요소를 더해 테스트를 조립한다 - 설명: [그림 1] 구성 요소 추가 메뉴(우클릭 > Add) — Test Plan 트리에 요소를 더해 테스트를 조립한다](https://api.wisestone.kr/Files/Temp/66cfcae1-254b-4038-a781-fedc5004066f_image.png)
[그림 1] 구성 요소 추가 메뉴(우클릭 > Add) — Test Plan 트리에 요소를 더해 테스트를 조립한다
이제 가장 기본이 되는 웹 부하 테스트를 직접 구성해 봅니다. 큰 흐름은 ‘변수 정의 → 리스너 추가 → Thread Group으로 부하 정의 → HTTP Request로 대상 지정 → 결과 리스너 추가 → 실행’ 순서입니다. 아래는 연습용 사이트 blazedemo.com 을 대상으로 한 예시이며, 화면을 그대로 따라 하면 됩니다.
Test Plan에서 마우스 오른쪽 클릭 → Add > Config Element > User Defined Variables 를 선택합니다.
이후 단계에서 반복해 쓸 값(서버 주소, 포트, 사용자 수 등)을 변수로 등록해 두면, 스크립트에서 ${변수명} 형태로 불러 쓸 수 있어 관리가 편합니다.
참고 변수는 필수가 아닙니다. 테스트 목적과 방법에 따라 항목이 달라지거나, 아예 설정하지 않고 값을 직접 입력해도 됩니다. |
![제목: [그림 2] Add > Config Element > User Defined Variables 선택 - 설명: [그림 2] Add > Config Element > User Defined Variables 선택](https://api.wisestone.kr/Files/Temp/cb9f5429-0a62-4796-ab68-cc50ec2dc176_image.png)
[그림 2] Add > Config Element > User Defined Variables 선택
Test Plan에서 우클릭 → Add > Listener > Transactions per Second 를 선택합니다. (초당 처리량을 그래프로 보기 위한 리스너로, Basic Graphs 플러그인이 설치되어 있어야 합니다.)
Test Plan에서 우클릭 → Add > Threads(Users) > Thread Group 을 선택합니다.
Thread Group이란? JMeter 부하 테스트의 핵심 요소입니다. 시스템에 가해질 부하의 양과 패턴을 정의하는 부분으로, 가상 사용자 수·부하 증가 시간 등을 설정해 실제 사용자 트래픽을 모방합니다. |
Thread Properties에 값을 입력합니다. 앞서 정의한 변수를 쓰려면 ${변수명} 형식으로 입력합니다.
Number of Threads (users) — 동시에 동작할 가상 사용자 수
Ramp-up period (seconds) — 지정한 사용자 수에 도달하기까지 걸리는 시간(부하를 서서히 올리는 구간)
Loop Count — 각 사용자가 시나리오를 반복할 횟수
![제목: [그림 3] Thread Group — Number of Threads · Ramp-up period 등 부하 설정 - 설명: [그림 3] Thread Group — Number of Threads · Ramp-up period 등 부하 설정](https://api.wisestone.kr/Files/Temp/d4d07d52-8233-4e52-b9a8-99b43e6613a9_image.png)
[그림 3] Thread Group — Number of Threads · Ramp-up period 등 부하 설정
Thread Group에서 우클릭 → Add > Sampler > HTTP Request 를 선택합니다.
HTTP Request를 쓰는 이유 실제 웹 브라우저가 웹 서버에 보내는 HTTP 요청을 정확히 모방해, 시스템에 부하를 가하고 응답을 받기 위함입니다. |
![제목: [그림 4] Add > Sampler > HTTP Request 선택 - 설명: [그림 4] Add > Sampler > HTTP Request 선택](https://api.wisestone.kr/Files/Temp/509f08c8-e437-4449-b5dc-7f4eb9b29fae_image.png)
[그림 4] Add > Sampler > HTTP Request 선택
1. Basic 탭에서 측정 대상 서버 정보를 입력합니다. 아래는 blazedemo.com 예시입니다.
| 항목 | 값(예시) |
|---|---|
① 프로토콜(Protocol) | https |
② 서버 주소(Server Name or IP) | blazedemo.com |
③ 포트 번호(Port Number) | 443 |
④ HTTP 메서드(Method) | GET |
⑤ 인코딩(Content encoding) | UTF-8 (공란으로 둬도 동작) |
![제목: [그림 5] HTTP Request Basic 탭 — 프로토콜·서버 주소·포트·메서드·인코딩(①~⑤) - 설명: [그림 5] HTTP Request Basic 탭 — 프로토콜·서버 주소·포트·메서드·인코딩(①~⑤)](https://api.wisestone.kr/Files/Temp/3bab78ad-8124-4f99-920d-bf4b2a1b4a33_image.png)
[그림 5] HTTP Request Basic 탭 — 프로토콜·서버 주소·포트·메서드·인코딩(①~⑤)
Advanced 탭으로 이동해 Client implementation > Implementation > HttpClient4 로 설정합니다.
HttpClient4 설정 이유 JMeter가 웹 서버와 통신하는 방식을 최적화해, 더 효율적이고 안정적인 부하 테스트를 수행할 수 있도록 합니다. |
HTTP Request에서 우클릭 → Add > Listener > Summary Report 를 추가합니다. (전체 결과를 수치로 요약)
같은 방식으로 Add > Listener > View Results Tree 를 추가합니다. (개별 요청의 상세 내용 확인)
모든 설정이 끝나면 상단의 녹색 실행 버튼(▶)을 클릭해 테스트를 실행합니다. 실행 중에는 각 리스너에서 결과가 실시간으로 채워집니다.
API 부하 테스트도 흐름은 같습니다 대상 주소를 API 엔드포인트로 지정하고 메서드(GET/POST/PUT/DELETE)와 경로(Path)만 바꾸면 됩니다. 로그인·인증이 필요한 API라면 HTTP Cookie Manager(Add > Config Element)를 더해 세션을 유지하거나 특정 쿠키를 강제로 전송할 수 있습니다. |
테스트가 끝나면 리스너로 결과를 확인합니다. 개별 요청은 View Results Tree로, 수치 요약은 Summary Report로, 시간 흐름에 따른 변화는 그래프로 보는 것이 효과적입니다.
각 요청의 성공 여부와 Request/Response 상세 내용을 확인할 수 있습니다. 응답 코드(Response code), 응답 시간(Load time), 응답 본문(Response Body)까지 볼 수 있어 시나리오가 의도대로 동작하는지 디버깅하는 데 유용합니다.
![제목: [그림 6] View Results Tree — 개별 요청의 Request/Response 상세 확인 - 설명: [그림 6] View Results Tree — 개별 요청의 Request/Response 상세 확인](https://api.wisestone.kr/Files/Temp/9375be9a-4c94-4233-a65c-67a89b6e7955_image.png)
[그림 6] View Results Tree — 개별 요청의 Request/Response 상세 확인
전체 결과를 표로 요약해 보여줍니다. 각 항목의 의미는 다음과 같습니다.
![제목: [그림 7] Summary Report — 요청별·전체(TOTAL) 성능 지표 요약 - 설명: [그림 7] Summary Report — 요청별·전체(TOTAL) 성능 지표 요약](https://api.wisestone.kr/Files/Temp/89681657-c0f5-4df1-8817-62a28bb38c30_image.png)
[그림 7] Summary Report — 요청별·전체(TOTAL) 성능 지표 요약
| 항목 | 의미 |
|---|---|
Label | Sampler(요청) 이름 |
Samples | 요청(request) 개수 |
Average / Min / Max | 응답 시간 평균 / 최소 / 최대 |
Std. Dev. | 응답 시간 표준편차 |
Error % | 에러율 |
Throughput | 시간당 처리량 |
Received / Sent KB/sec | 초당 받은 / 보낸 데이터(KB) |
Avg. Bytes | 평균 바이트 |
Basic Graphs 플러그인을 설치하면 시간 흐름에 따른 추이를 그래프로 볼 수 있습니다. 대표적으로 Transactions per Second(TPS)는 초당 처리된 트랜잭션 수를, Response Times Over Time은 평균 응답 시간의 변화를, Active Threads Over Time은 동시 활성 사용자 수를 보여줍니다. 부하가 늘어날 때 처리량과 응답 시간이 어떻게 반응하는지 한눈에 파악할 수 있습니다.
![제목: [그림 8] Transactions per Second 그래프 — 부하에 따른 초당 처리량 변화(성공/실패 구분) - 설명: [그림 8] Transactions per Second 그래프 — 부하에 따른 초당 처리량 변화(성공/실패 구분)](https://api.wisestone.kr/Files/Temp/35382592-3252-42d4-97c0-e8f944c441e3_image.png)
[그림 8] Transactions per Second 그래프 — 부하에 따른 초당 처리량 변화(성공/실패 구분)
마치며 — 2부 예고
여기까지가 성능 테스트의 기본 개념과 JMeter의 기본 동작입니다. 정의와 목적, 6단계 절차, 결과를 읽는 관점을 이해하고, JMeter로 기본 부하 테스트를 직접 구성해 실행해 봤습니다.
2부에서는 한 걸음 더 들어갑니다. 장시간 부하를 견디는지 보는 지구력(Soak) 테스트, CSV 데이터를 활용한 복합 시나리오, 브라우저 동작을 녹화하는 스크립트 레코더, HTML 리포트 자동 생성, 여러 PC로 부하를 키우는 분산 테스트, 그리고 PerfMon을 이용한 서버 자원 모니터링까지 — 실무에서 진짜 위력을 발휘하는 기능들을 다룹니다. 더불어 성능 목표·워크로드 설계 예시와 결과를 보고서로 풀어내는 4단계 분석법도 함께 정리합니다.
