모바일 개발의 스트레스 테스트: 정의, 목적 및 수행 방법

Stress Test란?

Stress Test(스트레스 테스트) — 설계 값을 초과하는 조건에서 시스템의 작동 능력을 평가하는 프로세스입니다. 모바일 애플리케이션의 경우 정상 1000개 대신 10000개의 동시 푸시 알림, 백엔드의 경우 예상 5000 대신 50000 RPS일 수 있습니다. Load Test와의 주요 차이점은 목표가 성능 확인이 아니라 설계 용량을 초과한 시스템의 동작을 연구하는 것입니다. Netflix Engineering (2024)은 Stress Test를 “시스템이 예측 가능하게 고장난다는 가설을 테스트하는 것”으로 정의합니다.

스트레스 테스트에는 두 가지 필수 단계가 있습니다: 장애까지의 부하와 복구 관찰입니다. 복구(recovery) — 과부하 제거 후 시스템이 정상 작동으로 돌아가는 능력. 재시작 없이 복구할 수 없는 시스템은 단기 과부하를 견디더라도 취약한 것으로 간주됩니다. AWS Well-Architected Framework (2024)에 따르면, Stress Test 후 복구 시간은 5분을 초과해서는 안 됩니다.

모바일 클라이언트의 경우 Stress Test에는 프로세스 강제 종료, 네트워크 연결 끊김, RAM 소진 시 작동 확인이 포함됩니다. Android Low Memory Killer는 RAM 부족 시 백그라운드 프로세스를 종료할 수 있습니다 — 스트레스 테스트는 이러한 종료 후 애플리케이션이 상태를 적절히 복구하는지 확인해야 합니다. Apple UIKit (2024)은 애플리케이션의 각 화면에서 메모리 경고 시나리오를 테스트할 것을 권장합니다.

스트레스 테스트의 목적

장애 지점 결정

Stress Test의 첫 번째 목적은 장애 지점 결정(breaking point)입니다. 주요 성능 지표 중 하나가 임계 값을 초과하는 순간입니다: p95 응답 시간 10초 초과, HTTP 5XX 오류율 5% 초과, 또는 처리량이 기준선의 50% 미만으로 감소. 장애 지점을 기록하면 팀이 시스템의 확장 한계를 사전에 알 수 있습니다. Capacity planning은 Load Test가 아닌 Stress Test 데이터에 의존합니다. Load Test는 한계 조건을 확인하지 않기 때문입니다.

복구 메커니즘 확인

두 번째 목적은 복구 메커니즘 확인입니다. 부하가 정상 수준으로 감소한 후 시스템이 정상 지표로 돌아와야 합니다. 데이터베이스 연결 풀이 해제되지 않거나 캐시가 무효화되지 않으면 Stress Test가 이 문제를 식별합니다. Circuit breaker(Hystrix, Resilience4j)는 과부하 시 작동하고 안정화 후 자동으로 연결을 복구해야 합니다. Health check 엔드포인트는 테스트 중 각 서비스의 상태 모니터링에 도움이 됩니다.

Auto-scaling 검증

세 번째 목적은 auto-scaling 검증입니다. 인프라가 Kubernetes 또는 AWS Auto Scaling을 사용하는 경우, Stress Test는 새 pod 또는 인스턴스가 충분히 빠르게 생성되는지 확인합니다. Google Kubernetes Engine (2024)에 따르면, HPA(Horizontal Pod Autoscaler) 메트릭 트리거에서 새 pod 배포까지 30초를 초과해서는 안 됩니다. HPA는 CPU, 메모리 및 사용자 정의 메트릭을 기반으로 확장해야 합니다. Cluster Autoscaler는 현재 노드가 pod를 수용할 수 없을 때 새 노드를 추가합니다.

Stress Test 방법론

점진적 부하 증가(Ramp-up Stress Test) — 가장 일반적인 시나리오입니다. 초기 부하는 예상치의 50%로 설정되고, 2분마다 10%씩 증가하여 시스템이 실패할 때까지 계속됩니다. 이 시나리오는 복원력의 정확한 한계를 찾을 수 있게 해줍니다. Grafana Cloud k6 (2025)은 응답 시간의 부드러운 그래프를 위해 10% 이상의 증가를 권장하지 않습니다.

급격한 부하 스파이크(Spike Stress Test) — 부하가 10%에서 500%로 10–30초 사이에 증가합니다. 이 시나리오는 바이럴 콘텐츠 확산이나 DDoS 공격과 같은 상황을 모델링합니다. Spike Stress Test는 성능보다 시스템의 생존성을 테스트합니다: 완전히 중단되지 않고 안정화 후 작동으로 돌아가는 능력입니다. API Gateway는 급격한 스파이크로부터 백엔드를 보호하기 위해 속도 제한을 설정해야 합니다.

장기간 과부하 유지(Sustained Stress Test) — 시스템을 30–60분 동안 과부하 상태로 유지합니다. 이 시나리오는 단기 테스트에서는 나타나지 않는 리소스 누수를 발견합니다. 메모리 누수는 Java/Kotlin 애플리케이션에서 20–40분의 집중 작동 중에 축적되며 Sustained Stress Test만이 이를 감지합니다.

장애 지점 및 복구 분석

장애 지점은 세 가지 기준으로 결정됩니다: 응답 시간, 오류율 및 처리량. 일반적으로 먼저 응답 시간 임계값을 초과합니다 — 요청이 설정된 제한 시간보다 오래 걸립니다. 그 다음 오류율이 증가합니다: 서버가 요청을 처리할 수 없어 503을 반환합니다. 마지막으로 처리량이 감소합니다 — 시스템이 최소 부하도 처리할 수 없게 됩니다. 장애 지점 메트릭은 용량 계획을 위해 부하 프로파일에 기록됩니다.

복구 분석에는 세 단계가 있습니다: 즉시 대응(부하 제거 후 처음 30초), 안정화(1–5분), 완전 복구(5–30분). 즉시 대응 단계에서는 응답 시간이 기준선 아래로 떨어져야 합니다 — 시스템이 큐에서 해제됩니다. 그렇지 않으면 문제는 부하가 아니라 축적된 상태에 있습니다. Graceful degradation — 과부하 시 시스템이 부분적 기능을 유지하는 능력 — 은 아키텍처 성숙도의 핵심 지표입니다.

Chaos Engineering은 의도적인 장애 도입을 통해 Stress Test를 보완합니다: 데이터베이스 서버 중단, 네트워크 지연, 마이크로서비스 중지. Chaos Monkey(Netflix, 2024)는 프로덕션에서 무작위로 프로세스를 종료하여 시스템의 복원력을 테스트합니다. 모바일 애플리케이션의 경우 Chaos Engineering은 다음 시나리오 테스트를 의미합니다: 네트워크 부재, API 사용 불가, 빈 서버 응답.

Stress Test 도구

ramping-arrival-rate 지원 k6

k6는 ramping-arrival-rate 설정으로 `execution` 모듈을 통해 Stress Test를 지원합니다. 이 모드는 각 요청의 실행 시간과 관계없이 초당 요청 수를 증가시킵니다. Load Test와 비교하여 k6의 Stress Test는 더 공격적인 임계값 설정과 급격한 장애 시뮬레이션을 위한 gracefull-stop 비활성화가 필요합니다. Grafana Cloud는 응답 시간 그래프의 꺾인 지점에서 자동으로 장애 지점을 감지합니다. k6-operator for Kubernetes를 사용하면 클러스터에서 분산 Stress Test를 실행할 수 있습니다.

Ultimate Thread Group 지원 JMeter

JMeter는 Ultimate Thread Group 플러그인을 통해 Stress Test를 구성할 수 있습니다 — 이 플러그인은 테이블 형식으로 부하 프로파일을 정의합니다: 스레드 수, 워밍업 시간, 유지 시간, 쿨다운 시간. Ultimate Thread Group은 복잡한 다단계 시나리오에 편리합니다. JMeter Backend Listener는 장애 지점 그래프 작성을 위해 InfluxDB로 메트릭을 전송합니다. Stress Test의 경우 JMeter에서 연결 시간 초과를 비활성화하여 과부하 시 동작을 더 정확하게 측정하는 것이 좋습니다.

Chaos Engineering을 위한 Gremlin

Gremlin — 인프라 Stress Test를 위한 Chaos Engineering 플랫폼입니다. Gremlin은 네트워크 차단, CPU 부하, 디스크 채우기, Kubernetes 개별 pod에서 프로세스 종료를 가능하게 합니다. SRE 팀은 Gremlin을 k6와 함께 사용하여 종합적인 Stress Test를 수행합니다: k6가 부하를 생성하고 Gremlin이 장애를 도입합니다. Game Day — Gremlin을 사용한 정기적인 Stress Test 세션으로, 시스템 복원력 분석을 위해 “chaos report”에 문서화됩니다.

k6의 Stress Test 예제

다음 k6 스크립트는 장애까지 부하를 점진적으로 증가시키는 Stress Test를 보여줍니다. Ramping-arrival-rate는 각 요청의 실행 시간과 관계없이 초당 요청 수를 증가시킵니다. 임계값은 공격적인 성능 저하 감지를 위해 설정됩니다: p95는 2000 ms 이내, 오류율은 5% 이내. 임계값을 초과하면 k6가 오류 코드로 테스트를 종료하여 Stress Test를 CI/CD 파이프라인에 통합할 수 있습니다.

import http from 'k6/http'
import check from 'k6'

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

export default function() {
    const res = http.get('https://api.example.com/health')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
}

스트레스 테스트 모범 사례

staging에서 Stress Test 시작 — 프로덕션 스트레스 테스트는 고급 모니터링과 롤백 계획이 필요합니다. Google SRE (2024)는 아키텍처와 용량에서 프로덕션을 재현하는 100% 격리된 환경에서 Stress Test를 수행할 것을 권장합니다. staging에서 테스트 성공 후 SRE 감독 하에 프로덕션으로 전환할 수 있습니다. Feature flag를 통한 과부하 시 기능 중단 — 필수 요소입니다.

CI/CD에서 Stress Test 자동화 장애 지점의 회귀 분석을 위해. 새 버전 애플리케이션의 장애 지점이 이전보다 20% 낮으면 릴리스 전에 수정해야 할 회귀입니다. Baseline breaking point는 메트릭에 저장되고 각 Stress Test 결과와 자동으로 비교됩니다. 장애 지점이 10% 감소하면 알림이 작동합니다.

각 Stress Test 문서화: 부하 프로파일, 장애 지점, 복구 동작 및 발견된 문제 목록. Netflix Engineering (2024)은 “Game Day”를 운영합니다 — 정기적인 Stress Test 세션으로, 그 결과는 “chaos report”에 문서화됩니다. 스트레스 테스트 보고서에는 장애 지점이 표시된 “RPS — 응답 시간” 그래프가 포함되어야 합니다.