모바일 개발에서의 Load Test — 정의, 시나리오 및 수행 방법

Load Test란 무엇인가?

Load Test는 시스템이 예상되는 동시 요청 또는 사용자 수 아래서 어떤 성능을 보이는지 확인하는 과정입니다. 모바일 개발의 맥락에서 Load Test는 서버 측(API, 데이터베이스, 캐시)과 클라이언트 측(push 알림 처리, 데이터 동기화) 모두에 적용됩니다. 스트레스 테스팅과의 주요 차이점은 Load Test가 극한이 아닌 실제 부하를 시뮬레이션한다는 점입니다. AWS Well-Architected Framework(2024)에 따르면, 부하 테스팅은 실제 사용 분석에 기반한 부하 프로파일을 사용하여 수행해야 합니다.

Load Test는 API에 대한 HTTP 요청, WebSocket 연결, 또는 데이터베이스 트랜잭션 수준에서 수행할 수 있습니다. 목적은 각 요청의 응답 시간이 지정된 임계치(보통 API의 경우 500–1000 ms)를 초과하지 않고, 스루푸트(RPS — 초당 요청 수)가 요구 사항을 만족시키는 것입니다. Google Cloud Armor(2024)는 백분위를 기반으로 임계치를 정의합니다: 중요 엔드포인트의 경우 p95 응답 시간이 2초를 초과해서는 안 됩니다.

모바일 백엔드의 부하 테스팅에는 일반적인 시나리오 시뮬레이션이 포함됩니다: 회원가입, 인증, 피드 로딩, 폼 제출. 시나리오는 HAR 파일(HTTP Archive)로 기록되고 부하 테스팅 도구에 의해 재생됩니다. k6 문서(2025)에 따르면, HAR 변환을 통해 Load Test 준비 시간을 60% 줄일 수 있습니다.

부하 테스팅의 목적

Load Test의 첫 번째 목적은 시스템 스루푸트 확인입니다. 사양이 1000 RPS를 처리할 것을 요구하는 경우, 부하 테스트는 20% 여부를 두고 확인해야 합니다. Netflix Tech Blog(2024)에 따르면, Netflix에서는 피크 부하의 2배 여부를 두고 부하 테스팅을 수행합니다: 10000 RPS가 예상되면 테스트는 20000 RPS를 확인합니다. 이 접근 방식은 갑작스러운 트래픽 포급에서 안정성을 보장합니다.

둘째 목적은 아키텍처의 병목 틄다이스(병목 현상)를 식별하는 것입니다. 모바일 백엔드의 일반적인 병목 현상은 데이터베이스(늘린 쿼리), 캐시(잘못된 무효화 전략), 그리고 외부 API(늘린 제3자 서비스)입니다. 분산 추적(Jaeger, Zipkin)은 특정 서비스 또는 요청 수준에서 문제를 파악하는 데 도움입니다.

셜 째 목적은 포화점(포화 시점)을 결정하는 것입니다. 새로운 사용자를 추가해도 스루푸트가 더 이상 증가하지 않는 순간입니다. 모바일 애플리케이션에서 포화점은 보통 데이터베이스 서버의 CPU 부하가 70–80%일 때 나타닙니다. 오토 스케일링은 포화점에 도달하기 전에 작동해야 합니다.

부하 테스팅 시나리오

스파이크 테스트 — 아침 push 알림 발송 또는 마케팅 캠페인 시작과 같은 갑작스러운 활동 급드기를 시뮬레이션합니다. Grafana k6(2025)에 따르면, Spike Test는 30초 동안 100에서 10000 RPS로 부하가 증가하는 것을 시뮬레이션합니다. 시스템은 요청을 잃지 않고 응답 시간이 50%를 초과하지 않도록 처리할 수 있어야 합니다.

지속 테스트(Endurance Test) — 부하 아래에서 장시간 운영하는 동안 시스템의 안정성을 확인합니다. 일반적인 지속 시간은 1–4시간입니다. Endurance Test는 서버 애플리케이션의 메모리 누수, 데이터베이스 커넥션 풀 문제, 그리고 캐시 성능 저하를 드러냅니다. PostgreSQL 커넥션 풀은 적절한 구성 없이 장시간 부하가 가해지면 2–3시간 내에 사용 가능한 커넥션을 다 소진할 수 있습니다.

단계 부하 테스트(Step Load Test) — 2–5분마다 10–20%씩 부하를 점진적으로 증가시킵니다. 이 시나리오는 시스템이 성능이 떨어지는 정확한 계기를 찾는 데 도움이 됩니다. InfluxDB와 Prometheus는 각 단계에서 메트릭스를 수집하여 응답 시간 대 RPS 그래프를 만듭니다.

Load Test 메트릭스

응답 시간

응답 시간(Response Time)은 Load Test의 주요 메트릭스입니다. 밀리초로 계정되고 백분위(p50, p95, p99)로 분석됩니다. Google SRE(2024)는 REST API의 경우 p95가 1000 ms 이하, gRPC의 경우 200 ms 이하를 권장합니다. 백분위는 평균보다 더 중요한데, 그 이유는 사용자가 처음으로 인식하는 가장 나쁜 요청의 동작을 보여주기 때문입니다. Apdex(애플리케이션 성능 지수)는 만족, 참을 수 있는, 그리고 실망한 사용자의 비율을 고려한 복합 메트릭스입니다.

스루푸트

스루푸트(Throughput) — 단위 시간 당 성공적인 요청 수입니다. RPS(초당 요청 수) 또는 TPS(초당 트랜잭션 수)로 계정됩니다. “시간 — RPS” 좌표의 Throughput 그래프는 포화점까지 선형적이어야 합니다. 부하 증가에 따른 Throughput의 급격한 하락은 시스템의 한계에 도달했음을 나타냅니다. Apache Bench와 wrk는 개발 중 빠른 Throughput 확인을 위한 간단한 CLI 도구입니다.

오류율

오류율(Error Rate) — 전체 요청 수 중 HTTP 상태 4xx 또는 5xx를 반환하는 비율입니다. 수용 가능한 임계치는 1% 미만입니다. 높은 부하 상황에서 429(Too Many Requests) 및 503(Service Unavailable) 오류는 레이트 리미팅과 오토 스케일링을 구성할 필요가 있음을 나타냅니다. API Gateway에서의 레이트 리미터는 허용되는 부하를 초과하지 않도록 백엔드를 보호합니다. 지수적 백오프가 있는 재시도 정책은 클라이언트가 일시적인 오류를 올바르게 처리하도록 돕습니다.

Load Test 도구

k6 (Grafana)

k6 — Grafana의 선도적인 오픈 소스 부하 테스팅 도구입니다. 스크립트는 JavaScript로 작성되며, 모듈형 시나리오, 임계치, 그리고 Prometheus 및 InfluxDB와의 통합을 지원합니다. k6는 CLI와 Grafana Cloud k6 클라우드 모두에서 실행할 수 있습니다. Grafana Cloud는 Load Test 결과로 부터 자동으로 대시보드를 구축하고 이력 데이터와 비교합니다. k6는 별도의 k6/net/grpc 모듈을 통해 Protocol Buffers와 gRPC를 지원합니다.

Apache JMeter

Apache JMeter — 그래픽 인터펄이스를 가진 고전적인 Load Test 도구입니다. HTTP, JDBC, JMS, FTP, TCP를 포함한 광범위한 프로토콜을 지원합니다. JMeter는 다양한 요청 유형을 가진 복잡한 시나리오에 더 적합하지만, k6에 비해 더 많은 수동 구성이 필요합니다. JMeter 플러그인은 WebSocket 및 gRPC 테스팅을 위한 기능을 확장합니다. 분산 실행을 위해 JMeter는 하나의 컨트롤러를 가진 마스터-슬레이브 아키텍처를 사용합니다.

Locust

Locust — 코드에서 부하 시나리오를 설명할 수 있는 Python 기반 도구입니다. Locust는 Python을 주요 자동화 언어로 사용하는 팀에게 편리합니다. k6와 JMeter와 달리, Locust는 바로 가능한 분산 실행을 지원합니다: 하나의 마스터 노드가 여러 워커 노드를 조율합니다. 분산 실행을 통해 여러 기계에서 100000 RPS까지 부하를 생성할 수 있습니다. Locust는 커스텀 확장을 통해 WebSocket 테스팅도 지원합니다.

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

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

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

k6에서 Load Test 작성 예제

위에 제시된 k6 스크립트는 일반적인 부하 테스트 구조를 보여줍니다. Options는 부하 프로파일을 정의합니다: 2분 동안 100명의 사용자로 램프업, 그 다음 5분 동안 지속 부하, 그리고 다시 200명의 사용자로 램프업합니다. 임계치는 테스트 합격 기준을 정의합니다: p95 요청 시간 500 ms 미만, 오류율 1% 미만. 임계값을 초과하면 k6가 냩 제로 코드로 종료합니다 — 이를 통해 Load Test를 CI/CD에 통합할 수 있습니다.

모바일 개발에서는 서버 측의 Load Test가 추가 부하를 유발하는 새로운 기능(좋아요, 댓글, 스트리밍)을 출시할 때 특히 중요합니다. 권장 — 프로덕션으로 배포하기 전에 각 staging에서 Load Test를 실시하십시오. API 디자인 단계에서 기저용 부하 프로파일을 만들면 다양한 아키텍처 문제를 후출 단계에서 피할 수 있습니다.