성능테스트 설계와 부하 상황별 시스템 검증
성능테스트의 핵심 지표와 부하 테스트 유형, 실행 절차를 바탕으로 시스템 용량·병목·가용성을 검증하는 방법을 정리한다.
2026-08-14 · 최초 발행 2025-05-23
출시 전에 확인해야 할 시스템의 한계
성능테스트는 최대 동시 사용자 수, 예상 최대 업무량, 업무 유형을 바탕으로 시스템 성능과 용량이 요구사항에 맞는지 검증하는 과정이다. 출시 전에 잠재적인 병목과 성능 문제를 찾아 대응할 수 있으며, 운영에서 일어날 수 있는 여러 부하 조건을 재현해 시스템의 한계도 파악할 수 있다.
이 과정은 단순히 시스템이 동작하는지 확인하는 데 그치지 않는다. 비즈니스 요구사항을 충족하는지를 객관적인 지표로 판단하는 검증 수단이다.
관측할 성능 지표
응답시간은 사용자가 요청한 뒤 시스템이 응답할 때까지 걸리는 시간이다. 웹 애플리케이션은 일반적으로 3초 이내의 응답시간을 권장하며, 이 시간에는 데이터베이스 쿼리, 네트워크 지연, 서버 처리 시간이 함께 영향을 준다.
처리 능력은 TPS(Transaction Per Second)와 OPS(Operation Per Second)로 살핀다. TPS는 초당 처리할 수 있는 트랜잭션 수이고, OPS는 초당 처리 가능한 작업 수다. 두 지표는 시스템 전체의 처리 능력을 보여준다.
자원사용량에서는 CPU 사용률, 애플리케이션 메모리 사용량, 디스크 I/O, 네트워크 대역폭을 확인한다. CPU 사용률은 프로세서 사용 정도를 백분율로 나타내고, 디스크 I/O는 저장장치의 읽기·쓰기 작업량을 뜻한다.
효율성은 자원을 얼마나 활용해 결과를 산출하는지 나타내며 백분율(%)로 표현한다. tpmc(Transactions Per Minute C)는 TPC-C 벤치마크에서 쓰는 처리량 단위다. 반환시간은 작업을 제출한 시점부터 완료될 때까지의 전체 시간으로, 배치 작업이나 대용량 처리에서 특히 중요하다.
안정성은 가용도와 신뢰도로 나눠 본다. MTBF(Mean Time Between Failures)는 장애 사이의 평균 시간이고, MTTR(Mean Time To Repair)은 장애 이후 복구까지 걸리는 평균 시간이다. 신뢰도는 정해진 기간 동안 장애 없이 운영될 확률을 의미하며 장기적인 안정성 측정에 사용된다.
검증 대상에 따라 나누는 테스트
단위성능 테스트는 개별 컴포넌트 또는 모듈을 대상으로 한다. 특정 부분이 설계 요구사항을 충족하는지 확인하는 방식이며, 특정 API 엔드포인트의 응답 시간을 측정하는 경우가 이에 해당한다.
복합성능 테스트는 여러 컴포넌트가 연동된 상태의 전체 성능을 측정한다. 웹서버, 애플리케이션 서버, 데이터베이스 사이의 상호작용을 대상으로 하므로 통합 지점의 병목을 찾는 데 적합하다.
임계성능 테스트는 시스템이 감당할 수 있는 최대 부하를 확인한다. 장애 직전의 한계와 성능 저하 없이 처리할 수 있는 최대 사용자 수 또는 트랜잭션 수를 파악하는 것이 목적이다.
부하를 주는 방식과 확인 범위
반복 트랜잭션으로 병목을 찾는 루프백 테스트
루프백 테스트는 동일한 트랜잭션을 반복 실행해 병목 지점을 찾는다. 특정 기능이나 프로세스에 집중해 한계를 측정할 수 있으며, 로그인 프로세스를 수천 번 반복해 인증 시스템 성능을 확인하는 방식이 예다.
급격한 유입을 재현하는 스파이크 테스트
스파이크 테스트는 짧은 시간 안에 갑작스러운 대량 트랜잭션을 발생시켜 시스템 반응을 관찰한다. 이벤트 시작 시점처럼 대규모 접속이 몰리는 상황을 시뮬레이션해 예상하지 못한 트래픽 증가에서도 안정적으로 동작하는지 검증한다.
확장 정책과 장시간 운영을 검증하는 테스트
확장성 테스트는 사용자 수나 데이터 양을 점차 늘리면서 시스템의 확장성을 검증한다. 더 강력한 하드웨어를 사용하는 수직적 확장과 서버를 늘리는 수평적 확장의 효과를 측정하며, 클라우드 환경에서는 자동 확장(Auto-scaling) 정책 검증에도 활용한다.
가용성 테스트는 장시간 운영 중 안정성과 가용성을 확인한다. 장애 발생 시 자동 복구 메커니즘도 검증 대상이며, 24시간 이상 계속 부하를 가하면서 시스템을 모니터링하는 방식이 사용될 수 있다.
계층별로 지연을 분리하는 티어 테스트
티어 테스트는 시스템 아키텍처의 각 계층 성능을 측정한다. 웹 티어, 애플리케이션 티어, 데이터베이스 티어 등에서 병목을 분리해 보고, 티어 간 상호작용에서 발생하는 지연 요소를 분석한다.
계획부터 재검증까지의 운영 흐름
테스트를 시작할 때는 목표와 성공 기준을 정하고, 환경·도구·시나리오·스크립트를 결정한다. 이후 실제 운영 환경과 유사한 테스트 환경을 구성하고, 모니터링 및 성능 측정 도구와 테스트 데이터를 준비한다.
실행 단계에서는 기본 부하에서 기준 성능을 먼저 측정한다. 부하를 점진적으로 높이며 시스템 반응을 관찰하고, 임계점까지 증가시켜 최대 처리 용량을 파악한다.
수집한 데이터에서는 병목과 성능 이슈를 식별하고 개선 권고사항을 도출한다. 최적화 조치를 적용한 뒤에는 재테스트로 개선 효과를 검증하며, 운영 이후에도 성능을 지속적으로 모니터링할 체계를 마련한다.
도구 선택의 기준
Apache JMeter는 HTTP, HTTPS, SOAP, REST, FTP 등 여러 프로토콜을 지원하는 오픈소스 성능 테스트 도구다. 분산 테스트와 클러스터링 기능을 제공한다.
LoadRunner는 HP(현 Micro Focus)에서 개발한 상용 도구로, 엔터프라이즈급 시스템 테스트에 적합하며 다양한 프로토콜과 환경을 지원한다.
Gatling은 Scala 기반의 오픈소스 부하 테스트 도구다. 높은 확장성과 실시간 결과 분석 기능, 개발자 친화적인 스크립팅 방식을 특징으로 한다.
Locust는 Python 기반의 오픈소스 도구다. 분산 사용자 시뮬레이션을 지원하고 실시간 웹 인터페이스에서 테스트를 모니터링할 수 있다.
금융 시스템에서 확인된 병목과 개선
대형 은행의 인터넷뱅킹 시스템 리뉴얼 프로젝트에서는 동시 접속자 10만 명과 피크 시간 TPS 1,000 이상이 요구사항이었다. 연말정산처럼 특정 시기에 트래픽이 집중되는 특성도 고려해야 했다.
테스트는 평소 트래픽 수준인 3만 명 동시 접속에서 기본 성능을 측정하는 것으로 시작했다. 이후 요구사항 수준인 10만 명까지 단계적으로 부하를 올렸고, 1분 내 5만 명 동시 접속을 만드는 스파이크 테스트와 7만 명 동시 접속 상태를 12시간 유지하는 내구성 테스트를 수행했다.
그 결과 동시 접속자 8만 명을 넘기면 데이터베이스 연결 풀이 고갈됐고, 대출 신청 거래에서는 응답 시간이 급증했다. 파일 업로드 기능에서는 메모리 누수도 확인됐다.
대응 과정에서는 데이터베이스 연결 풀과 관리 로직을 개선하고, 대출 신청 프로세스의 쿼리를 최적화하며 캐싱을 적용했다. 파일 업로드 처리 로직과 메모리 관리를 보완하고, 로드밸런서 구성 및 세션 관리 정책도 수정했다.
최적화 이후 시스템은 최대 12만 명 동시 접속을 처리할 수 있었고, 모든 트랜잭션 유형에서 2초 이내 응답 시간을 달성했다. 24시간 연속 운영 테스트도 통과했으며 가용성은 99.99%였다.
결과의 신뢰도를 좌우하는 조건
테스트 환경은 실제 운영 환경과 가능한 한 유사해야 한다. 하드웨어, 네트워크, 소프트웨어 구성의 일치성을 확보하지 못하면 결과를 운영 환경에 적용하기 어렵다.
테스트 데이터도 현실적인 볼륨과 분포를 가져야 하며, 다양한 데이터 패턴을 포함해야 한다. 사용자 시나리오에는 실제 행동 패턴과 생각 시간(Think Time)을 반영한다.
부하는 처음부터 최대치로 올리기보다 단계적으로 증가시키며 반응을 관찰한다. 문제가 확인되면 해당 부하 수준에서 원인을 집중 분석할 수 있다. 또한 인프라, 애플리케이션, 네트워크 전 계층을 함께 모니터링하고 APM(Application Performance Management) 도구로 상세 분석을 수행해야 한다.