부하 테스트를 위한 프록시 k6 및 JMeter

부하 테스트가 rate-limit, WAF 또는 지리적 로드 밸런싱에 부딪힐 때, 첫 번째 생각은 "다양한 IP에서 트래픽을 실행하겠다"입니다. 논리적으로 들리지만, 실제로 k6와 JMeter의 프록시는 제한된 작업 집합만 해결할 수 있으며, 나머지는 여전히 테스트 아키텍처로 수정해야 합니다. 이 기사에서는 두 도구에 프록시를 기술적으로 연결하는 방법, 어떤 유형의 IP가 적합한지, 그리고 프록시 서버의 책임 영역이 어디까지인지 살펴보겠습니다.

부하 테스트에 다양한 IP가 필요한 이유

기본적으로 k6와 JMeter는 모든 트래픽을 테스트가 실행되는 서버(또는 CI/CD의 클라우드 머신)에서 하나의 IP 주소로 전송합니다. 이는 90%의 시나리오에서 정상적이지만, 몇 가지 경우에는 하나의 IP로는 부족합니다:

IP 수준의 레이트 리미팅. 많은 API와 로드 밸런서(nginx limit_req, AWS WAF, Cloudflare)는 초당 하나의 주소에서 요청 수를 제한합니다. 실제 사용자들은 수천 개의 다양한 IP에서 접근하지만, 귀하의 테스트는 하나의 IP에서만 진행되어 실제 애플리케이션의 병목 현상에 도달하기 전에 제한에 부딪힙니다.
지리적 의존 로직 테스트. CDN, 타겟 콘텐츠, 지역 가격, 지리적 차단 등은 특정 국가의 IP로 확인해야 하며, 물리적으로 테스트 러너가 위치한 데이터 센터에서 확인할 수 없습니다.
로드 밸런서 및 anycast 네트워크 확인. 인프라가 클라이언트의 IP를 기반으로 트래픽을 지역별로 분산하는 경우, 하나의 주소에서의 테스트는 하나의 경로만 확인할 뿐 전체 네트워크를 확인하지 않습니다.
실제 트래픽 분산 모방. 프로덕션 트래픽의 IP는 제공업체, 서브넷, 때로는 모바일 운영자에 따라 분산되어 있으며, 이는 CDN, 캐시 및 엣지 로직의 동작에 영향을 미칩니다.

중요한 점은, 백엔드의 성능을 테스트하는 경우(귀하의 API가 얼마나 많은 RPS를 처리할 수 있는지) 프록시는 거의 필요하지 않다는 것입니다 — 여기서는 순수한 부하가 중요하며, 출처의 다양성은 중요하지 않습니다. 프록시는 테스트 시나리오가 클라이언트의 IP 주소에 의존할 때 필요합니다.

어떤 프록시가 적합한가: 데이터 센터, 주거용, 모바일

프록시 유형의 선택은 귀하가 테스트하는 내용에 직접적인 영향을 미칩니다 — 인프라의 대역폭 또는 "실제" IP에서 시스템의 동작을 테스트하는지 여부입니다.

프록시 유형	지연 및 속도	부하 테스트에서 사용할 때
데이터 센터 프록시	낮은 지연, 높은 대역폭	레이트 리미트 확인, "IP당 N 요청" 제한 우회, 다양한 서브넷에서 대량의 RPS 생성
주거용 프록시	지연이 더 높고, 속도는 실제 사용자의 채널에 의해 제한됨	지리적 로직 테스트, CDN 및 anti-bot 시스템 확인, 주거용 범위에 대해 데이터 센터보다 더 신뢰하는 경우
모바일 프록시	가장 높은 지연, 불안정한 속도	특정 시나리오: 모바일 API 테스트, IP가 자주 변경될 때의 동작(운영자가 클라이언트 주소를 동적으로 변경함)

RPS 및 레이트 리미트를 순수하게 확인하기 위해서는 데이터 센터 프록시가 거의 항상 충분합니다 — 이들은 안정적인 낮은 지연을 제공하며, 외부 네트워크 불안정성으로 인해 테스트 결과를 왜곡하지 않습니다. 주거용 및 모바일 IP는 지리적 테스트에서 현실감을 더하지만, 자체 지연을 추가하며, 이는 메트릭 분석 시 고려해야 합니다 — 그렇지 않으면 "프록시 네트워크가 느리다"와 "서버가 느리다"를 혼동하기 쉽습니다.

k6에서 프록시 설정하기

k6는 JavaScript로 작성된 도구(엔진은 Go로 작성되었으며, 스크립트는 JS로 작성됨)이며, 기본적으로 스크립트 옵션을 통한 HTTP 프록시 지원이 없습니다: k6에서 프록시는 환경 변수나 시스템 설정을 통해 설정되며, k6는 내부적으로 Go HTTP 클라이언트를 사용합니다.

가장 간단한 방법은 환경 변수를 사용하는 것입니다:

export HTTP_PROXY="http://login:password@proxy-host:port"
export HTTPS_PROXY="http://login:password@proxy-host:port"

k6 run script.js

이 방법은 모든 테스트 트래픽을 하나의 프록시를 통해 전송합니다 — "화이트" IP 서버에서 벗어나기만 하면 되는 경우에 적합합니다. 그러나 가상 사용자(VU)를 다양한 IP로 분산시키는 것이 목표라면, 프록시 목록과 스크립트 수준의 선택 로직이 필요합니다. k6는 기본적으로 per-VU 프록시를 지원하지 않기 때문에, 일반적인 우회 방법은 여러 개의 k6 프로세스를 병렬로 실행하는 것입니다. 각 프로세스는 자체 환경 변수와 프록시를 가지고 있습니다:

// run-with-proxies.sh
PROXIES=("proxy1:port" "proxy2:port" "proxy3:port")

for proxy in "${PROXIES[@]}"; do
  HTTP_PROXY="http://user:pass@$proxy" \
  HTTPS_PROXY="http://user:pass@$proxy" \
  k6 run --vus 50 --duration 5m script.js &
done
wait

이러한 접근 방식은 k6 Cloud와 함께 사용하거나 Kubernetes/Docker Compose를 통해 오케스트레이션할 때 잘 확장됩니다 — 각 컨테이너는 자체 프록시 변수를 가지고 시작됩니다. 스크립트 실행 내에서 IP 회전이 필요하다면, 프록시 공급자의 측면에서 회전하는 프록시를 사용하는 것이 더 합리적입니다(TTL이 있는 스티키 세션), JS 코드 내에서 회전하는 것보다.

JMeter에서 프록시 설정하기

JMeter에서 프록시는 환경 변수를 사용하지 않고, HTTP Request Defaults 요소 또는 HTTP Request Sampler의 설정에서 직접 설정할 수 있습니다:

Thread Group에 HTTP Request Defaults 구성 요소를 추가합니다.
Proxy Server 필드에 프록시의 호스트와 포트를 입력합니다.
프록시가 인증을 요구하는 경우 — 해당 호스트에 대한 로그인 및 비밀번호가 포함된 HTTP Authorization Manager 요소를 추가합니다.
Thread Group 내의 모든 HTTP Request Sampler는 자동으로 프록시 설정을 상속받습니다.

여러 프록시 간의 부하 분산을 위해 JMeter에서는 CSV Data Set Config를 사용하는 것이 편리합니다 — 프록시 목록이 포함된 파일이 각 스레드의 호스트 및 포트 변수에 삽입됩니다:

proxy_host,proxy_port,proxy_user,proxy_pass
proxy1.example.com,8000,user1,pass1
proxy2.example.com,8000,user2,pass2
proxy3.example.com,8000,user3,pass3

CSV Data Set Config를 Thread Group에 연결하고, Proxy Server/Proxy Port 샘플러 필드에 ${proxy_host} 및 ${proxy_port} 변수를 지정합니다 — 각 JMeter 스레드는 파일에서 자신의 행을 가져와 자신의 IP를 통해 진행합니다. 커맨드라인을 통해 실행할 때(헤드리스 모드, 실제 부하 테스트에 권장됨) 프록시를 플래그로 전달할 수도 있습니다:

jmeter -n -t test_plan.jmx -l results.jtl \
  -H proxy-host -P port \
  -u username -a password

이 방법은 전체 테스트에 대해 하나의 공통 프록시를 설정합니다 — 다수의 프록시 시나리오에서는 여전히 CSV Data Set Config 또는 분산 테스트(각각의 프록시가 구성된 여러 JMeter 슬레이브)를 사용해야 합니다.

IP 회전 및 부하 분산

부하 테스트에서 IP 분산에 대한 두 가지 근본적으로 다른 접근 방식이 있습니다:

스레드/VU에 대한 정적 IP 고정. 각 가상 사용자는 세션 전체에 대해 동일한 IP를 받습니다 — 하나의 주소를 가진 실제 사용자를 모방합니다. 스티키 세션 프록시를 통해 설정하거나 CSV/환경 변수에서 고정된 목록을 사용할 수 있습니다.
각 요청마다 IP 회전. 프록시는 각 HTTP 요청마다 출발 주소를 변경합니다 — 레이트 리미트 방어를 확인하는 데 유용하지만, IP가 매초 변경되지 않는 사용자들의 실제 동작을 잘 반영하지 않습니다.

현실적인 부하 테스트를 위해서는 90%의 경우 VU/스레드에 대해 세션 전체에 IP를 고정하는 것이 더 올바릅니다 — 이렇게 하면 테스트가 독립적인 사용자들의 행동을 정직하게 반영하며, 인위적인 노이즈를 생성하지 않습니다. 각 요청마다 회전을 포함하는 것은 좁은 시나리오에서만 의미가 있습니다 — 예를 들어, 레이트 리미트 규칙의 발동 여부를 확인할 때입니다.

프록시가 절대 대체하지 않는 것들

이 기사의 핵심 포인트입니다: 프록시는 "어떤 IP에서 요청이 오는가" 문제를 해결하지만, 실제로 부하 테스트가 확인하는 문제는 해결하지 않습니다.

테스트 러너의 대역폭. 부하 생성기(k6/JMeter가 실행되는 머신)가 CPU, 메모리 또는 네트워크 카드에 부딪히면 — 프록시는 이를 수정하지 않습니다. 프록시는 불필요한 네트워크 홉과 자신의 지연을 추가하며, 러너의 부하를 줄이지 않습니다.
테스트하는 서버의 실제 대역폭. 서버는 부하를 견디거나 견디지 못합니다 — 클라이언트의 IP 주소는 이에 영향을 미치지 않으며, IP에 대한 명시적인 레이트 리미트가 있는 경우를 제외하고는 그렇습니다.
응답 시간 메트릭의 신뢰성. 프록시는 자체 지연을 추가합니다(특히 주거용 및 모바일), 이는 귀하의 보고서에서 응답 시간의 일부로 포함됩니다. 프록시의 지연을 따로 빼내지 않으면, 최종 지연 보고서는 왜곡되어 프로덕션 메트릭과 비교할 수 없게 됩니다.
실제 트래픽에 대한 인프라의 확장성. 프록시를 사용한 부하 테스트는 특정 요청 패턴에 대한 동작을 보여주지만, 실제 프로덕션 로그를 기반으로 한 용량 계획, 자동 확장 및 부하 프로필을 대체하지 않습니다.
부하 하에서 비즈니스 로직의 정확성 확인. 레이스 조건, 데이터베이스의 잠금, 큐의 저하 — 이는 경쟁 테스트 및 프로파일링에서 확인해야 하며, 출발 IP 변경으로 해결되지 않습니다.

프록시는 "다양한 IP에서 트래픽을 에뮬레이트"하는 특정 작업을 위한 도구이지, 부하 테스트의 범용 증폭기가 아닙니다. 목표가 백엔드가 얼마나 많은 RPS를 견딜 수 있는지를 이해하는 것이라면, 대부분의 경우 프록시는 전혀 필요하지 않습니다: 적절하게 설정된 keep-alive와 연결 풀을 가진 몇 개의 테스트 러너만으로 충분합니다.

프록시를 통한 테스트에서의 일반적인 실수

실제로 프록시와 관련된 대부분의 문제는 몇 가지 반복되는 실수로 귀결됩니다.

프록시의 지연과 테스트 서비스의 지연 혼합. 기준 측정(프록시 없이 직접 요청)이 없으면, 프록시 서버가 추가하는 밀리초 수를 이해할 수 없습니다.
순수한 대역폭이 필요한 곳에서 모바일 또는 주거용 프록시 사용. 이러한 프록시는 최종 장치의 실제 채널에 의해 제한되며, 수만 RPS를 견디지 못합니다 — 순수한 부하에는 데이터 센터 프록시가 필요합니다.
대량의 VU에 대한 IP 풀이 부족함. 5000 가상 사용자에 대해 10개의 프록시 주소가 있다면, 테스트는 여전히 동일한 레이트 리미트에 부딪히며, 단지 지연이 추가됩니다 — 서비스는 "10 IP, 수천 요청" 패턴을 빠르게 인식할 것입니다.
프록시 측의 타임아웃 무시. 높은 경쟁 부하에서 프록시 서버가 연결을 거부하기 시작할 수 있습니다 — 프록시 공급자에게 동시 세션의 한계를 미리 확인하는 것이 중요합니다.
화이트리스트/인증 확인 없이 테스트 실행. 프록시가 IP 인증을 요구하는 경우, CI/CD에서 동적 주소의 러너로 테스트를 실행하면 — 요청이 407 Proxy Authentication Required로 실패하고, 테스트 결과는 무의미하게 됩니다.

테스트 실행 전 체크리스트

실제로 작업이 다양한 IP를 요구하는지, 아니면 하나의 주소로 테스트하는 것으로 충분한지 확인했습니다.
작업에 맞는 프록시 유형을 선택했습니다: RPS 및 레이트 리미트에는 데이터 센터, 지리적 로직에는 주거용/모바일을 선택했습니다.
프록시 없이 기준 측정을 수행하여 네트워크 지연과 프록시 지연을 분리했습니다.
필요한 VU 수준에 맞춰 프록시 공급자의 동시 연결 한계를 확인했습니다.
프록시 인증(로그인/비밀번호 또는 러너의 IP 화이트리스트)을 설정했습니다.
VU에 대한 스티키 세션이 필요한지, 각 요청마다 회전할지 결정했습니다.
구성을 확인하기 위해 전체 실행 전에 짧은 간격(1-2분)으로 테스트를 실행했습니다.

결론

k6와 JMeter의 프록시는 다양한 IP 주소에서 트래픽을 에뮬레이트하고, 레이트 리미트 및 지리적 의존 로직의 동작을 확인하는 효과적인 방법입니다. 그러나 이는 부하 테스트의 올바른 계획을 대체할 수는 없습니다: 서버의 대역폭, 경쟁 부하에서의 백엔드 안정성 및 실제 용량 계획은 프록시가 확인하거나 개선하지 않습니다. 프록시는 IP 주소에 의존하는 테스트에서만 특정하게 사용해야 하며, 범용 도구로 사용해서는 안 됩니다.

IP에 대한 한계를 확인하고 높은 대역폭의 대량 트래픽을 시뮬레이션하는 것이 목표라면, 데이터 센터 프록시로 시작하는 것이 합리적입니다 — 이들은 최소한의 지연을 제공하며, 많은 동시 세션을 견딥니다. 지리적 로직 및 트래픽 출처에 대한 anti-bot 시스템의 신뢰를 기반으로 한 테스트에는 주거용 프록시가 더 적합하며, 모바일 트래픽과 관련된 특정 시나리오에는 모바일 IP가 더 적합합니다.