80명이 동시에 결제를 시도할 때 API에 어떤 일이 일어나는지 알고 싶을 것입니다. 그래서 Locust를 열면, 가장 먼저 파이썬 클래스를 작성하라고 요구합니다. `HttpUser`를 정의하고, `@task`로 메서드를 장식합니다. `locustfile.py`를 만들고, 가상 환경을 설정하고, 몇 가지 의존성을 고정(pin)하고, 그런 다음 인증 토큰이 요청 간에 재사용되지 않는 이유를 파악해야 합니다. 이 모든 것은 테스트 자체가 아닙니다. 테스트를 시작하기 전의 입장료인 셈입니다.
Locust는 훌륭한 도구이며, 코드 우선 설계가 그 핵심입니다. 그러나 목표가 "로그인 엔드포인트가 100명의 동시 사용자에게 견딜 수 있는가"에 대한 직접적인 답을 얻는 것이라면, 파이썬 하네스를 작성하고 유지 관리하는 것은 하나의 숫자를 위해 많은 불필요한 작업을 하는 것입니다. 이미 API 클라이언트에 있는 API 요청을 처리하고 싶을 때 더 빠른 방법이 있습니다. Apidog를 사용하면 기존 테스트 시나리오에 성능 테스트를 지정하고, 가상 사용자 수와 지속 시간을 설정한 다음, 실시간 차트에서 처리량, 응답 시간 및 오류율을 확인할 수 있습니다. `locustfile`도 없고, pip 설치도 필요 없으며, 파이썬도 전혀 필요 없습니다.
Locust가 실제로 잘하는 것
Locust는 파이썬으로 작성된 오픈 소스 부하 테스트 도구이며, 제작 목적에 맞게 잘 작동합니다. 사용자 행동을 코드로 설명합니다. 가상 사용자는 파이썬 클래스이고, 그 사용자가 수행하는 작업은 작업(task)으로 태그하는 메서드입니다. 다음은 `locustfile.py`의 일반적인 형태입니다:
from locust import HttpUser, task, between
class CheckoutUser(HttpUser):
wait_time = between(1, 3)
@task(3)
def browse_products(self):
self.client.get("/api/products")
@task(1)
def add_to_cart(self):
self.client.post("/api/cart", json={"sku": "AK-204", "qty": 1})
`locust -f locustfile.py` 명령으로 실행하고, `localhost:8089`에서 웹 UI를 열어 사용자 수와 스폰율을 설정한 다음 숫자가 상승하는 것을 지켜봅니다. 행동이 코드로 되어 있기 때문에, 진정한 표현력을 얻을 수 있습니다. 조건부 로직, 가중치 있는 작업 배포, 순차적인 사용자 여정, HTTP를 넘어서는 프로토콜을 위한 사용자 정의 클라이언트, 요청 간 공유 상태 등이 가능합니다. 위에서 `@task(3)` 대 `@task(1)` 가중치는 장바구니에 추가하는 것보다 탐색이 세 배 더 자주 발생한다는 것을 의미하며, 이는 단순한 요청 목록으로는 포착할 수 없는 현실감을 제공합니다.
Locust는 수평 확장도 가능합니다. 여러 워커 프로세스나 머신에 분산하여 실행하고 단일 마스터가 이를 조정하므로, 단일 장비가 생성할 수 있는 부하를 넘어설 수 있습니다. 내부적으로는 이벤트 기반으로 작동하므로, 각 워커는 사용자당 스레드가 메모리를 소비하지 않고 수천 명의 동시 사용자를 처리할 수 있습니다. 이미 파이썬 환경에서 작업하고, 부하 테스트를 버전 관리되는 코드로 취급하며, 복잡한 다단계 사용자 행동을 모델링해야 하는 팀에게 Locust는 강력한 선택입니다. 이 모든 것은 논쟁의 여지가 없습니다.
대가는 코드입니다. 모든 테스트는 작성하고 디버그하고 유지 관리해야 하는 프로그램입니다. API가 변경되면 `locustfile`도 변경됩니다. 새로운 엔지니어가 테스트를 실행해야 한다면, 일치하는 파이썬 환경이 필요합니다. 그리고 이미 파이썬을 사용하지 않는다면, 파이썬과는 아무런 관련이 없는 질문에 답하기 위해 언어 자체가 전제 조건이 됩니다.
코드 우선 모델이 마찰이 되는 지점
마찰은 세 가지 측면에서 나타납니다.
첫째, 설정입니다. 무언가를 측정하기 전에 파이썬을 설치하고, 가상 환경을 생성하고, `pip install locust`를 실행한 다음 하네스를 작성해야 합니다. "이 엔드포인트가 50명의 사용자를 감당할 수 있는가"와 같은 빠른 확인에는 페이로드보다 더 많은 준비 작업이 필요합니다.
둘째, 중복입니다. 아마도 이 요청들은 이미 어딘가에 정의되어 있을 것입니다. Postman에 있거나, `.http` 파일에 있거나, 팀이 매일 사용하는 API 클라이언트에 있을 수도 있습니다. `locustfile`은 인증 흐름, 헤더, 요청 본문을 포함하여 이미 존재하는 요청을 다시 설명합니다. 이제 동일한 API 지식의 두 가지 사본을 유지 관리하게 되며, 이들은 시간이 지남에 따라 달라질 수 있습니다.
셋째, 답변이 필요한 사람들입니다. QA 엔지니어, 출시를 앞두고 긴장하는 제품 관리자, 마케팅 이메일 발송 후 API가 정상 작동하는지 알고 싶은 프론트엔드 개발자 모두 부하 테스트 결과가 필요합니다. 그들은 그것을 받을 자격이 있기 위해 반드시 파이썬을 읽거나 쓸 필요는 없습니다. 테스트가 `locustfile` 뒤에 잠겨 있다면, 그 답은 특정 기술 세트 뒤에 잠겨 있는 것입니다.
부하 테스트에 실제로 분기 로직과 사용자 정의 프로토콜 클라이언트가 필요하다면, 그 마찰을 감수할 가치가 있으며 Locust가 적절한 도구입니다. 그러나 "동시 부하 하에 실제 API 요청을 실행하고 수치를 보여줘"와 같은 일반적인 경우에는 파이썬 계층이 어떤 이점을 제공하는지 질문해 볼 가치가 있습니다.
Apidog 접근 방식: 이미 가지고 있는 요청으로 부하 테스트 수행
Apidog는 부하 테스트에 다른 방식으로 접근합니다. 요청을 설명하는 스크립트를 작성하지 않습니다. 이미 구축한 요청을 가져와 부하 하에 실행합니다. 부하 테스트의 단위는 테스트 시나리오이며, 이는 환경, 변수 및 어설션이 이미 첨부된 순서 있는 API 요청 집합입니다. Apidog를 사용하여 엔드포인트를 테스트하거나 디버그했다면, 해당 요청은 이미 존재합니다. 성능 테스트는 이를 재사용합니다.
전체 흐름은 다음과 같습니다.
- 부하 테스트하려는 테스트 시나리오를 엽니다. 이는 일반 기능 테스트로 실행했을 시나리오와 동일하며, 동일한 요청과 동일한 환경 변수를 사용합니다.
- 단일 실행 대신 성능 테스트로 실행하도록 선택합니다.
- 가상 사용자 수를 설정합니다. Apidog는 최대 100명의 가상 사용자를 지원하며, 각 사용자는 전체 테스트 기간 동안 시나리오의 모든 요청을 병렬로 반복합니다.
- 테스트 지속 시간을 설정합니다. 이는 가상 사용자가 반복을 계속하는 시간입니다.
- 점진적으로 부하를 증가시키려면 램프업(ramp-up) 지속 시간을 설정합니다. Apidog는 처음 X분 동안 모든 사용자를 한 번에 시작하는 대신 점진적으로 온라인 상태로 만듭니다. 이를 0으로 설정하면 모든 가상 사용자가 즉시 시작됩니다.
- 시나리오가 데이터 기반인 경우 일치 모드를 선택합니다. "랜덤 매치(Random Match)"는 각 가상 사용자가 각 루프에서 테스트 데이터의 임의 행을 가져오게 하고, "순차 매치(Sequential Match)"는 행을 순서대로 진행합니다.
- 테스트를 시작하고 실시간 패널을 확인합니다.
차트는 실시간으로 업데이트됩니다. 시나리오의 각 API에 대해 총 요청 수, 평균 처리량, 평균 응답 시간, 최대 및 최소 응답 시간, 오류를 확인할 수 있습니다. 차트 위로 마우스를 가져가면 특정 시간대의 수치를 볼 수 있습니다. "오류(Error)" 탭은 실패한 요청을 분석하여 어떤 엔드포인트가 언제부터 문제가 생겼는지 확인할 수 있도록 합니다. 실행이 완료되면 "테스트 보고서(Test Reports)" 탭에 기록이 보관되어 변경 사항을 배포한 후 오늘의 실행 결과를 지난주와 비교할 수 있습니다.
핵심은 작성해야 할 `locustfile`도 없고 관리해야 할 파이썬 환경도 없다는 것입니다. 기능 테스트를 통과한 동일한 요청이 부하를 생성하는 요청입니다. 이것이 부하 테스트를 설명하는 것과 실행하는 것의 차이입니다. Apidog는 올인원 API 플랫폼이므로, 엔드포인트의 설계, 디버깅, 기능 테스트 및 부하 테스트가 모두 해당 엔드포인트의 단일 정의에 대해 이루어집니다.
구체적인 비교
로그인 엔드포인트가 100명의 동시 사용자를 2분 동안, 30초의 램프업으로 처리하는지 확인하고 싶다고 가정해 봅시다.
Locust에서는 자격 증명을 게시하는 작업을 포함하는 사용자 클래스를 작성하고, 응답이 반환하는 토큰을 처리하고, 후속 호출을 위해 저장하고, 파일을 저장한 다음, `locust -f login_test.py`를 시작하고, 웹 UI를 열어 100명의 사용자, 스폰율 및 실행 시간을 입력합니다. 토큰 처리가 잘못되면 API를 디버그하기 전에 파이썬을 디버그해야 합니다.
Apidog에서는 이미 구축한 로그인 테스트 시나리오를 열고, 성능 테스트로 전환한 다음, 가상 사용자에 100, 지속 시간에 2분, 램프업에 30초를 입력하고 시작합니다. 기능 테스트에서 이미 작동했던 인증은 동일한 시나리오이므로 여전히 작동합니다. 응답 시간 곡선과 오류율을 실시간으로 확인합니다.
둘 다 비슷한 종류의 답을 얻을 수 있습니다. 하나는 프로그램을 먼저 작성하고 유지 관리하도록 요구합니다. 다른 하나는 이미 가지고 있는 것을 재사용합니다. 복잡하고 코드 모델링된 사용자 여정의 경우 프로그램이 가치 있습니다. "내 엔드포인트가 부하 하에 빠르고 안정적인가"에 대해서는 재사용이 시간 면에서 유리합니다.
양측의 솔직한 한계
잘못된 도구를 선택하면 어차피 하루를 낭비하게 되므로, 장단점에 대해 명확하게 이해해야 합니다.
Apidog의 성능 테스트는 단일 실행에서 최대 100명의 가상 사용자로 제한되며, 부하는 앱을 실행하는 사용자 시스템에서 생성됩니다. 수만 명의 사용자를 시뮬레이션하거나 여러 지리적 지역에서 동시에 부하를 생성해야 하는 경우, 이는 인앱 성능 테스트 목표를 넘어섭니다. 이럴 때는 Locust 워커와 같은 분산 설정 또는 전용 부하 생성 클러스터가 올바른 선택입니다. 또한 Apidog는 모든 실패에 대해 전체 요청 및 응답 본문을 캡처하는 대신 실패한 요청을 통계적으로 기록하므로, 부하 테스트 도중 특정 실패한 호출에 대한 심층적인 포렌식 디버깅은 Apidog의 강점이 아닙니다.
Locust의 장단점은 이 글 전체에서 다루는 내용입니다. 강력함은 코드에서 나오며, 코드는 지속적인 비용입니다. 시나리오당 `locustfile`을 유지 관리하고, 파이썬 환경을 유지하며, 테스트를 실행하려는 사람은 파이썬을 읽고 이해해야 한다는 점을 받아들여야 합니다. 매우 높은 가상 사용자 수와 맞춤형 프로토콜 로직의 경우, 그 비용은 실질적인 가치를 제공합니다. 일상적인 API 부하 확인에는 오버헤드입니다.
합리적인 규칙: 테스트를 "이 요청들을 이 동시성으로 이 시간 동안 실행하라"고 설명할 수 있다면, 인앱 성능 테스트를 사용하십시오. 조건부 분기, 가중치 있는 작업 그래프, 사용자 정의 클라이언트 또는 십만 단위의 사용자 수가 필요한 경우에는 코드를 사용하십시오. 각 옵션이 어디에 적합한지에 대한 더 넓은 조사를 위해, 최고의 부하 테스트 도구 및 API별 부하 테스트 도구 비교에 대한 저희의 종합 정보를 참조하십시오.
얻게 되는 숫자 읽기
부하 테스트는 결과가 무엇을 의미하는지 알아야만 유용합니다. 네 가지 지표가 가장 중요합니다.
처리량 (RPS/TPS)은 초당 요청 또는 트랜잭션 수로, API가 실제로 처리한 비율입니다. 이는 시스템이 처리할 수 있는 최대치입니다. 가상 사용자를 계속 추가하는데 처리량이 정체된다면, 포화 지점을 찾은 것입니다.
응답 시간 (지연 시간)은 각 요청에 걸린 시간입니다. 평균을 주시하되, 최대값을 더 주의 깊게 보십시오. 평균은 양호하지만 최대값이 좋지 않다는 것은 대부분의 사용자는 괜찮더라도 일부 사용자는 좋지 않은 경험을 하고 있다는 의미입니다. 꼬리 지연 시간(Tail latency)은 실제 사용자가 고통을 느끼는 지점입니다.
오류율은 실패한 요청의 비율입니다. 낮은 부하에서는 깨끗하던 테스트가 가상 사용자가 증가하면서 500 에러나 시간 초과를 발생시키기 시작한다면, 시스템이 정확히 어디에서 고장나는지 알려주는 것입니다. 오류가 시작되는 지점은 종종 순수 처리량 숫자보다 더 흥미롭습니다.
동시성은 활성 가상 사용자 수입니다. Apidog에서는 설정한 가상 사용자 수이며, 램프업은 그 지점에 얼마나 빨리 도달하는지를 제어합니다. 램프업이 중요한 이유는, 점진적으로 100명의 사용자에게 도달했을 때 잘 처리되는 시스템도 모든 100명이 동시에 도착하면 여전히 문제가 발생할 수 있기 때문입니다.
이에 대한 더 심층적인 내용을 원하시면, API 성능 테스트 가이드에서 지표, 테스트 유형 및 곡선 읽는 방법을 다루며, 성능 테스트의 기본 원리는 더 넓은 분야를 다룹니다.
이것이 이미 비교하는 도구들과 어떻게 맞아 떨어지는가
JMeter를 사용해 본 경험이 있다면, Apidog와 유사한 사고 모델을 가지고 있을 것입니다. 둘 다 코드가 아닌 UI를 통해 부하 테스트를 구성할 수 있기 때문입니다. JMeter는 더 무거운 XML 기반 테스트 계획과 가파른 학습 곡선을 특징으로 합니다. 저희의 JMeter 부하 테스트 튜토리얼에서 자세히 다룹니다. Postman의 컬렉션 러너를 통해 부하를 실행해 본 경험이 있다면, Postman으로 부하 테스트에서 다루는 동일한 아이디어의 가벼운 버전을 보았을 것입니다. Apidog는 Postman 없이 API 테스트에도 사용할 수 있는 요청 외에 전용 성능 보고 기능을 추가합니다. Apidog는 사람들이 원하는 코드 없는 단순성과 별도의 하네스를 유지 관리할 필요가 없는 요청 재사용 사이에 위치합니다.
이 모든 것의 공통점은 부하 테스트가 이미 인코딩된 API 지식을 재사용해야 하며, 새로운 언어로 중복해서는 안 된다는 것입니다. Locust는 파이썬이 강점이기 때문에 파이썬으로 중복합니다. Apidog는 재사용이 강점이기 때문에 시나리오를 재사용합니다.
시작하기
요청이 이미 Apidog에 있다면, 다음 5분 안에 성능 테스트를 실행할 수 있습니다. 테스트 시나리오를 열고, 성능 테스트로 전환하고, 가상 사용자와 지속 시간을 설정한 다음 시작합니다. `locustfile`에서 전환하여 파이썬 계층을 유지 관리하는 데 지쳤다면, 앱에서 시나리오를 한 번만 다시 구축하면 해당 엔드포인트에 대한 부하 테스트 코드를 다시 작성할 필요가 없습니다.
Apidog를 다운로드하여 이미 테스트 중인 엔드포인트에 성능 테스트를 지정하십시오. 동등한 `locustfile`을 작성하는 것을 마치기도 전에 처리량, 지연 시간 및 오류율 곡선을 얻게 될 것입니다. Locust는 대규모 분산, 코드 모델링 부하에 대한 올바른 답변으로 남아 있습니다. 대부분의 개발자가 실제로 묻는 질문에 대해서는 이미 가지고 있는 요청을 실행하십시오.
자주 묻는 질문
Apidog가 Locust를 완전히 대체할 수 있나요?
모든 작업에 해당하지는 않습니다. 코드를 작성하지 않고 최대 100명의 가상 사용자로 API 요청을 부하 테스트하는 경우, Apidog는 기존 테스트 시나리오를 직접 실행하기 때문에 전체 Locust 워크플로우를 대체합니다. 매우 높은 사용자 수의 분산 부하나 코드로 모델링된 사용자 정의 비HTTP 프로토콜의 경우, Locust가 여전히 더 적합합니다.
Apidog에서 부하 테스트를 하려면 코드를 작성해야 하나요?
아니요. UI에서 가상 사용자, 테스트 지속 시간 및 램프업 시간을 구성하면, 테스트는 이미 구축한 테스트 시나리오의 요청을 실행합니다. `locustfile`도 없고 설정할 파이썬 환경도 없습니다.
Apidog는 몇 명의 가상 사용자를 시뮬레이션할 수 있나요?
단일 성능 테스트에서 최대 100명의 가상 사용자를 시뮬레이션할 수 있습니다. 각 사용자는 설정된 지속 시간 동안 시나리오의 모든 API를 병렬로 반복합니다. 그보다 훨씬 더 많은 사용자나 여러 지역에서 부하가 필요한 경우, Locust와 같은 분산 코드 기반 도구가 올바른 선택입니다.
Apidog 성능 테스트는 어떤 지표를 보고하나요?
시나리오의 각 API에 대해 총 요청 수, 평균 처리량, 평균 응답 시간, 최대 및 최소 응답 시간, 오류를 실시간 차트에서 업데이트된 상태로 확인할 수 있습니다. 오류 탭은 실패한 요청을 분석하고, 테스트 보고서 탭은 실행 기록을 보관하여 변경 사항에 따라 비교할 수 있습니다.
데이터 기반 요청으로 부하 테스트를 할 수 있나요?
네. 시나리오가 테스트 데이터에 의해 지원되는 경우, 각 가상 사용자가 각 루프에서 임의의 행을 가져오도록 "랜덤 매치(Random Match)"를 선택하거나, 행을 순서대로 진행하도록 "순차 매치(Sequential Match)"를 선택할 수 있습니다.
그래도 Locust를 사용해야 할 경우가 있나요?
네, Locust의 강점이 필요에 부합할 때 사용하십시오. 즉, 분기 및 가중치 있는 작업을 포함하는 코드 정의 사용자 행동, 사용자 정의 프로토콜 클라이언트, 그리고 100명 이상의 가상 사용자를 훨씬 넘어서는 분산 부하 생성의 경우입니다. 테스트 형태에 맞는 올바른 도구를 사용하십시오.