성능 / 부하 테스트 2026 — k6 v1 / Artillery / Locust / JMeter / Gatling / Vegeta / oha 심층 비교

"당신이 운영 환경에서 가장 처음 보게 되는 부하는, 부하 테스트에서 본 적이 없는 모양이다." — Tammy Bützer, Grafana k6 maintainer, KubeCon EU 2024

성능 테스트(Performance testing)는 소프트웨어 엔지니어링에서 가장 오래된 분야 중 하나지만, 2026년의 풍경은 2016년과 거의 닮지 않았습니다. 한쪽에는 1998년에 처음 등장해 25년 넘게 살아남은 Apache JMeter가 여전히 가장 많은 설치 수를 자랑하고, 다른 한쪽에서는 Grafana가 2021년에 인수한 k6가 2024년 v1.0 GA를 찍으며 사실상의 "모던 표준"으로 자리잡았습니다. 그 사이에 Locust, Gatling, Artillery 같은 코드 우선 도구들이 자리를 잡았고, Vegeta·hey·wrk·oha·autocannon·Bombardier 같은 CLI 한 줄 벤치마크 도구들이 "굳이 시나리오를 짜기 전에 일단 RPS만 보자" 라는 요구를 채워줍니다.

이 글은 2026년 5월 현재 부하 테스트(Load testing)와 브라우저 성능 측정(Browser performance) 도구 풍경을 한 번에 훑는 심층 가이드입니다. 백엔드 부하 테스트 도구 16종 + 브라우저 도구 4종 + Core Web Vitals + 한국·일본 사례까지 다룹니다.

1. 2026년 부하 테스트 지도 — DSL / 스크립팅 / CLI 벤치마크 / 브라우저 perf

부하 테스트 도구는 단일 카테고리가 아닙니다. "도구 X와 도구 Y 중 무엇이 좋은가" 라는 질문은, 사실 다른 박스에 들어있는 두 도구를 비교하고 있을 가능성이 높습니다. 2026년 시점에서 가장 깔끔한 분류는 다음 4개 박스입니다.

카테고리	대표 제품	무엇을 하는가
스크립팅(코드 우선) 부하 테스트	k6, Artillery, Locust, Gatling, JMeter	사용자 시나리오를 코드/DSL로 정의, 분산 실행, 시계열 메트릭
한 줄 CLI 벤치마크	hey, wrk, oha, Vegeta, autocannon, Bombardier	단일 URL을 정해진 RPS/동시성으로 두드리고 p50/p95/p99만 본다
엔터프라이즈 SaaS / On-prem	BlazeMeter, LoadRunner, NeoLoad, Azure Load Testing	GUI·레코딩·결재·규제 산업 대응, JMeter/k6 호환
브라우저 perf / RUM	Lighthouse, WebPageTest, SpeedCurve, Calibre, Cloudflare RUM	실제 브라우저에서 LCP/INP/CLS 측정, 회귀 감시

이 글의 핵심 주장은 단순합니다. 2026년에 새 부하 테스트 프로젝트를 시작한다면 90%의 팀은 k6로 시작해야 하고, 10%는 Locust 또는 JMeter를 골라야 한다. Locust는 팀이 100% Python 친화일 때, JMeter는 규제·결재 산업에서 검수 대상이 GUI 스크립트일 때입니다. 한 줄 벤치마크가 필요할 때는 oha 또는 Vegeta 한 가지를 PATH에 깔아두면 충분합니다.

이 결론에 어떻게 도달했는지가 이 글의 나머지입니다.

2. k6 v1.0 (Grafana) — JS 스크립팅의 표준

Grafana k6는 2017년 Load Impact가 Go로 작성해 오픈소스로 공개한 부하 테스트 도구입니다. 2021년 Grafana Labs가 Load Impact를 인수하면서 풀타임 메인테이너가 붙었고, 2024년 봄 k6 v1.0이 정식 출시되며 API가 동결됐습니다. 2026년 현재 GitHub 스타 27k 이상, 주간 다운로드 수에서 JMeter를 빠르게 추월하고 있습니다.

k6의 핵심 선택은 "Go 런타임 안에서 goja(JavaScript 인터프리터)를 돌린다" 입니다. 사용자는 JS/TS로 시나리오를 짜지만 실제 부하 발생기는 Go이므로, 단일 머신에서 동시성 수만 이상을 안정적으로 만들 수 있습니다. Python 기반의 Locust나 JVM 기반의 JMeter/Gatling보다 메모리·CPU 효율이 좋습니다.

기본 스크립트는 다음과 같이 생겼습니다.

import http from 'k6/http'
import { check, sleep } from 'k6'

export const options = {
  scenarios: {
    ramp_up: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '30s', target: 100 },
        { duration: '2m',  target: 100 },
        { duration: '30s', target: 0 },
      ],
    },
  },
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1500'],
    http_req_failed:   ['rate<0.01'],
  },
}

export default function () {
  const res = http.get('https://api.example.com/products')
  check(res, {
    'status is 200': (r) => r.status === 200,
    'body has items': (r) => r.json('items').length > 0,
  })
  sleep(1)
}

executor(생성기) 종류가 7가지로 풍부합니다. constant-vus(고정 가상 사용자), ramping-vus(증·감), constant-arrival-rate(고정 도착률 — 이게 진짜 RPS), ramping-arrival-rate, per-vu-iterations, shared-iterations, externally-controlled. 실무에서는 "이 API를 5분간 1000 RPS로 두드리고 싶다" 같은 요구를 constant-arrival-rate로 정확히 표현할 수 있다는 점이 결정적입니다.

thresholds(임계치)는 부하 테스트를 CI 게이트로 만드는 핵심 기능입니다. p95가 500ms를 넘으면 종료 코드 99로 빠지고, GitHub Actions가 빨갛게 변합니다. 이게 없으면 부하 테스트는 그냥 그래프 구경에 그칩니다.

2024년 v1.0 이후 추가된 주요 기능을 정리하면:

Browser 모드: Playwright Chromium을 띄워 실제 페이지를 측정. CWV(LCP, INP, CLS)를 부하 테스트와 동시에 추적
gRPC, WebSocket, Redis, Kafka 프로토콜 모듈
Extensions(xk6): Go로 모듈을 작성해 k6 바이너리에 빌드해 합치는 방식. 60개 이상 공식/커뮤니티 익스텐션
Distributed mode: Kubernetes 오퍼레이터 (k6-operator)로 다중 노드 실행
k6 Cloud → Grafana Cloud k6: 매니지드 부하 발생기 + 대시보드 통합

CLI 출력은 텍스트 한 화면이 핵심입니다.

running (2m00.0s), 000/100 VUs, 11947 complete and 0 interrupted iterations
ramp_up        [======================================] 100/100 VUs  2m0s

     checks.........................: 100.00% 23894 ✓  0 ✗
     http_req_duration..............: avg=87.2ms p(95)=312.5ms p(99)=482.1ms
     http_req_failed................: 0.00%   0 / 23894
     http_reqs......................: 23894   199.117/s
     iteration_duration.............: avg=1.08s
     ✓ http_req_duration..p(95)<500
     ✓ http_req_duration..p(99)<1500
     ✓ http_req_failed..rate<0.01

k6의 약점은 두 가지입니다. 첫째, JavaScript지만 goja는 Node.js가 아닙니다. npm install로 임의 패키지를 못 씁니다. 별도 번들러(k6-browserify 또는 webpack)로 트랜스파일·번들 후 import해야 합니다. 둘째, 비동기/async-await가 v0.43 이후 일부 모듈만 지원합니다. 복잡한 비즈니스 로직을 시나리오에 넣으면 디버깅이 어렵습니다.

그럼에도 2026년 새 프로젝트의 기본값은 k6입니다. 단일 바이너리, JS 시나리오, 단단한 임계치, Grafana 통합 — 이 네 가지 조합을 다른 도구가 따라잡지 못합니다.

3. Artillery — Node.js + 서버리스 워커

Artillery는 2015년 Hassy Veldstra가 Node.js로 작성한 부하 테스트 도구입니다. 2022년 시리즈 A를 받고 회사화됐고(Artillery Inc.), 2026년 현재 OSS 버전과 Artillery Cloud(SaaS) 두 라인을 운영합니다.

Artillery의 큰 특징은 두 가지입니다. 첫째, 시나리오를 YAML로 적습니다. 함수형 JS 코드 대신 선언형 YAML이라는 점이 분기점입니다. 둘째, AWS Fargate / Azure Container Instances로 워커를 launch해서 사실상 무한대의 분산 부하 발생이 됩니다(Artillery Pro / Cloud).

YAML 시나리오는 다음과 같이 생겼습니다.

config:
  target: https://api.example.com
  phases:
    - duration: 60
      arrivalRate: 10
      name: warm up
    - duration: 300
      arrivalRate: 100
      name: sustained load
  defaults:
    headers:
      User-Agent: artillery-loadtest
  ensure:
    p95: 500
    maxErrorRate: 1

scenarios:
  - name: browse and buy
    flow:
      - get:
          url: /products
          capture:
            - json: $.items[0].id
              as: productId
      - get:
          url: /products/{{ productId }}
      - post:
          url: /cart
          json:
            productId: "{{ productId }}"
            quantity: 1
      - think: 2

YAML이라는 선택은 호불호가 갈립니다. 비개발자 QA가 시나리오를 작성할 때는 진입 장벽이 낮지만, 분기·반복·계산이 들어가면 JS/플러그인을 호출해야 합니다. Artillery는 processor: ./hooks.js 로 JS 함수를 끼울 수 있는 확장점을 제공합니다.

2024년 추가된 Artillery Pro AI는 OpenAPI/Swagger 스펙을 받아 자동으로 시나리오 YAML을 생성합니다. 100개 엔드포인트를 가진 마이크로서비스에 5분 만에 기본 시나리오를 만들어주는데, 실무에서는 "초안 90% + 사람이 다듬는 10%" 모델로 잘 동작합니다.

Artillery의 진짜 강점은 분산입니다. artillery run-fargate scenario.yml --count 20 --region us-east-1 한 줄로 20개의 Fargate 워커를 띄워 합산 RPS를 만듭니다. k6에서 같은 작업을 하려면 k6-operator + Kubernetes 클러스터가 필요합니다. CI에서 "기존 인프라 없이 즉시 폭발적 부하"가 필요한 팀에 적합합니다.

약점은 OSS 버전의 기능 제약(분산·Cloud 대시보드는 유료)과 시나리오가 커지면 YAML이 빠르게 추해진다는 점입니다.

4. Locust — Python 분산

Locust는 2011년 Jonatan Heyman이 시작한 Python 기반 부하 테스트 도구입니다. 2026년 현재 GitHub 스타 25k, 사실상 Python 진영의 표준입니다.

Locust의 정체성은 "파이썬 코드로 사용자(User)를 정의한다"는 한 문장에 다 담깁니다.

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 3)
    host = "https://api.example.com"

    def on_start(self):
        self.client.post("/login", json={"user": "test", "pw": "demo"})

    @task(3)
    def browse_products(self):
        with self.client.get("/products", catch_response=True) as resp:
            if resp.elapsed.total_seconds() > 0.5:
                resp.failure("Too slow")

    @task(1)
    def view_product(self):
        self.client.get("/products/42")

    @task
    def search(self):
        self.client.get("/search?q=keyboard")

@task(weight)로 액션 비중을 정하고, wait_time으로 사용자의 사고 시간(Think time)을 흉내냅니다. Python답게 SQLAlchemy·Pandas·Numpy 같은 라이브러리를 시나리오에 끌어다 쓸 수 있습니다. 데이터 과학팀이나 ML 추론 서버를 테스트할 때 결정적인 차이가 됩니다.

분산 실행은 master/worker 모드로 단순합니다.

# master
locust -f locustfile.py --master --expect-workers 4

# 워커 4대 (Docker Swarm·k8s·EC2 어디든)
locust -f locustfile.py --worker --master-host master.example.com

Web UI(기본 8089 포트)가 함께 떠서 그래프와 실시간 메트릭을 보여주는 점은 비개발자 PM/QA에게 큰 장점입니다. 2024년 추가된 --processes 옵션은 단일 머신에서 멀티프로세스로 GIL을 우회해 CPU 코어를 다 활용합니다.

약점은 두 가지입니다. 첫째, GIL과 gevent 의존 때문에 단일 워커의 부하 생성량이 k6의 1/3~1/5 수준입니다. 분산이 사실상 필수입니다. 둘째, 그래프와 임계치가 빈약합니다. CI 게이트로 쓰려면 종료 후 stats CSV를 읽어 직접 판정 스크립트를 짜야 합니다.

그래도 팀이 100% Python이라면 첫 선택지로 손색이 없습니다.

5. JMeter 5.6 — Apache 클래식

Apache JMeter는 1998년 첫 출시 이후 27년째 살아 있는 부하 테스트의 살아있는 화석입니다. 2024년 출시된 5.6 버전이 2026년 현재 LTS, 6.0 알파가 일부 사용자에게 풀려있습니다.

JMeter는 GUI 우선 도구입니다. 시나리오를 .jmx라는 XML 파일로 저장하고, GUI에서 트리(Thread Group → HTTP Sampler → Listener)를 만들어 시나리오를 짭니다. 코드를 한 줄도 안 쓰고 5분 만에 첫 부하 테스트를 만들 수 있습니다. 이 진입 장벽이 낮다는 점이 2026년에도 JMeter가 안 죽는 이유입니다.

<jmeterTestPlan version="1.2">
  <hashTree>
    <TestPlan testname="Demo Test"/>
    <hashTree>
      <ThreadGroup testname="Users">
        <intProp name="num_threads">100</intProp>
        <intProp name="ramp_time">30</intProp>
      </ThreadGroup>
      <hashTree>
        <HTTPSamplerProxy testname="Get products">
          <stringProp name="HTTPSampler.domain">api.example.com</stringProp>
          <stringProp name="HTTPSampler.path">/products</stringProp>
          <stringProp name="HTTPSampler.method">GET</stringProp>
        </HTTPSamplerProxy>
        <hashTree>
          <ResponseAssertion>
            <stringProp name="Assertion.test_field">Assertion.response_code</stringProp>
            <stringProp name="EQUALS">200</stringProp>
          </ResponseAssertion>
        </hashTree>
      </hashTree>
    </hashTree>
  </hashTree>
</jmeterTestPlan>

CI에서는 GUI 없이 jmeter -n -t plan.jmx -l results.jtl 식의 non-GUI 모드로 돌립니다. GUI는 시나리오를 만들 때만, 실행은 항상 non-GUI 가 공식 권장입니다(GUI는 자체 부하가 큼).

JMeter의 진짜 무기는 샘플러(Sampler) 풀의 깊이입니다. HTTP·HTTPS는 물론 JDBC, LDAP, SOAP, SMTP, IMAP, JMS, FTP, MongoDB까지 — 한 도구로 거의 모든 프로토콜에 부하를 줍니다. 2010년대 SOA 시대에 자라난 엔터프라이즈 시스템을 테스트할 때 결정적입니다.

2026년에도 JMeter를 골라야 하는 경우는 명확합니다.

규제 산업(금융·의료·공공): 재현 가능한 GUI 스크립트가 감사(Audit) 산출물로 요구됨
대기업 QA 조직: 사내 표준이 JMeter이고 50명 이상이 사용 중
SOAP·JMS·JDBC 같은 비-HTTP 프로토콜 비중이 50% 이상
BlazeMeter SaaS와 짝지어 클라우드 분산을 쓰고 싶음

새 그린필드 프로젝트라면 권하지 않습니다. XML 파일은 Git 머지가 지옥이고, 임계치는 빈약하며, 메모리 사용량이 큰 편입니다(단일 JVM에서 1000 VU 넘기면 GC 압박).

6. Gatling — Scala/Kotlin DSL

Gatling은 2012년 Stéphane Landelle이 Scala로 만든 부하 테스트 도구입니다. 2026년 현재 OSS Gatling 3.11과 상용 Gatling Enterprise(구 FrontLine)가 있습니다. 2023년 Kotlin DSL과 Java DSL이 정식 지원되면서 Scala 진입 장벽이 사라졌습니다.

Gatling의 두 가지 자랑은 (1) 타입 안전한 빌더 DSL과 (2) HTML 리포트의 아름다움입니다.

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._

class DemoSimulation extends Simulation {
  val httpProtocol = http
    .baseUrl("https://api.example.com")
    .acceptHeader("application/json")

  val browse = scenario("Browse")
    .exec(http("get products").get("/products").check(status.is(200)))
    .pause(1)
    .exec(http("get product 42").get("/products/42"))

  setUp(
    browse.inject(
      rampUsersPerSec(1).to(100).during(30.seconds),
      constantUsersPerSec(100).during(2.minutes)
    )
  ).protocols(httpProtocol)
   .assertions(
     global.responseTime.percentile(95).lt(500),
     global.failedRequests.percent.lt(1)
   )
}

rampUsersPerSec, constantUsersPerSec 같은 injection 프로파일이 풍부하고, .check() DSL이 컴파일 타임에 검증돼 오타가 나면 빌드가 깨집니다. 실행이 끝나면 HTML 리포트가 자동 생성되는데, percentile 분포·시간대별 응답 시간·요청 종류별 그래프가 한 화면에 깔끔하게 정리됩니다. 임원 보고용으로 그냥 던지면 됩니다.

Kotlin DSL 예시:

import io.gatling.javaapi.core.CoreDsl.*
import io.gatling.javaapi.http.HttpDsl.*

class DemoSimulation : Simulation() {
  val httpProtocol = http.baseUrl("https://api.example.com")

  val browse = scenario("Browse")
    .exec(http("get").get("/products").check(status().`is`(200)))

  init {
    setUp(browse.injectOpen(rampUsers(100).during(30)))
      .protocols(httpProtocol)
  }
}

Gatling이 빛나는 자리는 JVM 백엔드(Spring Boot, Quarkus, Micronaut)를 테스트하는 JVM 팀입니다. 같은 Maven/Gradle 빌드 안에서 부하 테스트가 돌고, JVM 튜닝 노하우가 그대로 적용되며, 리포트가 한국 대기업 임원이 좋아할 만큼 예쁩니다. 약점은 진입 학습 비용(Scala/Kotlin 어느 쪽이든 JVM DSL이 처음이면 며칠 걸림)과 OSS 분산 기능이 약하다는 점입니다(분산은 Enterprise 유료).

7. Vegeta / hey / wrk / oha / autocannon / Bombardier — CLI 벤치마크

부하 테스트의 80%는 시나리오가 필요 없습니다. "이 URL을 1000 RPS로 30초 두드리면 어떻게 되나" 한 가지만 알고 싶은 경우가 압도적입니다. 이때 쓰는 도구가 한 줄 CLI 벤치마크입니다.

hey (구 boom). Go로 작성, 가장 단순. 옵션은 -z(duration), -c(concurrency), -q(QPS) 셋이면 됩니다.

hey -z 30s -c 50 -q 100 https://api.example.com/products

wrk. C로 작성, 단일 머신 성능 최고. Lua 스크립팅으로 헤더·바디·요청 분기 가능. 단점은 macOS의 Homebrew에서 빌드 옵션이 자주 어긋나고, 출력이 텍스트뿐이라 후처리가 번거롭다는 점.

wrk -t 8 -c 100 -d 30s --latency https://api.example.com/products

Vegeta. Go로 작성, attack | report | plot 파이프라인 모델이 결정적. 결과를 binary로 떨어뜨려 여러 리포트(JSON, HTML, plot)로 가공할 수 있습니다.

echo "GET https://api.example.com/products" | \
  vegeta attack -duration=30s -rate=100/s | \
  tee results.bin | \
  vegeta report -type=text

vegeta report -type=json < results.bin > results.json
vegeta plot < results.bin > plot.html

oha. Rust로 2021년 등장. 2026년 현재 가장 핫한 CLI 벤치마크 도구입니다. hey와 호환되는 CLI에 TUI(터미널 차트)가 실시간으로 그려집니다. 한 번 보면 hey로 돌아갈 이유가 없습니다.

oha -z 30s -c 50 -q 100 https://api.example.com/products

TUI 화면에서 RPS, latency p50/p95/p99, status 분포가 실시간 ASCII 차트로 갱신됩니다. CI에서는 --no-tui --json으로 JSON을 떨굽니다.

autocannon. Node.js로 작성. npx autocannon 한 줄로 즉시 실행되고, Node 서버를 테스트할 때 같은 런타임이라는 점이 친근. Fastify 팀의 공식 벤치마크 도구.

npx autocannon -c 100 -d 30 https://api.example.com/products

Bombardier. Go로 작성. HTTP/2 지원, JSON 출력, 단일 바이너리. 윈도우즈에서 가장 무난하게 동작합니다.

bombardier -c 100 -d 30s -l https://api.example.com/products

6개 도구를 한 표로 정리하면:

도구	언어	스크립팅	TUI/그래프	HTTP/2	추천 상황
hey	Go	없음	없음	X	가장 단순, 옛날부터 익숙
wrk	C	Lua	없음	X	단일 머신 최대 성능
Vegeta	Go	없음	HTML plot	X	결과를 binary로 가공
oha	Rust	없음	실시간 TUI	O (HTTP/2)	2026년 첫 선택
autocannon	Node	함수 fn	없음	O	Node 서버 친화
Bombardier	Go	없음	없음	O	윈도우즈, JSON 출력

2026년의 권장은 단순합니다. oha를 PATH에 깔고 일단 그걸 쓴다. TUI가 있어 처음 보는 사람도 무슨 일이 벌어지는지 즉시 이해하고, Vegeta처럼 결과 파일로 후처리할 일이 생기면 그때 Vegeta를 추가합니다.

8. BlazeMeter / LoadRunner / NeoLoad — 엔터프라이즈

엔터프라이즈 SaaS 시장은 OSS 도구와 다른 세계입니다. 핵심 차별점은 (1) 결재·감사 문서, (2) 클라우드 분산 부하 발생기, (3) GUI 레코딩(브라우저 액션을 녹화해 시나리오로 변환), (4) APM 통합 네 가지입니다.

BlazeMeter (Perforce, 구 CA). JMeter·Gatling·k6·Selenium 스크립트를 그대로 받아 클라우드에서 분산 실행합니다. 2024년 AI Co-Pilot 출시로 시나리오 자동 생성·결과 자동 분석을 제공합니다. 한 번에 100만 동시 사용자까지 합법적으로 만들 수 있는 인프라가 그들의 진짜 상품입니다.

LoadRunner (Micro Focus, 2023년 OpenText에 인수). 1994년 Mercury Interactive에서 시작한 부하 테스트의 원조. 2026년 현재 LoadRunner Professional, LoadRunner Enterprise, LoadRunner Cloud 세 라인. SAP, Oracle Forms, Citrix, RDP 같은 레거시·산업용 프로토콜에서 거의 독점입니다. 라이선스 비용이 비싸기로 유명(연 수만~수십만 달러).

NeoLoad (Tricentis). 2014년 Neotys가 시작, 2021년 Tricentis가 인수. JMeter·Selenium 스크립트 호환에 CI/CD 통합이 강합니다. 2025년 출시된 NeoLoad Web 2.0은 SaaS 전환을 가속화했습니다. 유럽계 대기업(특히 금융)에서 채택률이 높습니다.

Azure Load Testing (Microsoft). 2022년 GA. 본질적으로 매니지드 JMeter + k6 입니다. .jmx나 k6 JS 파일을 업로드하면 Azure가 부하 발생기를 띄워 실행하고 Application Insights와 연동된 메트릭을 보여줍니다. Azure 중심 조직에는 결재 절차 없이 바로 쓸 수 있다는 장점이 큽니다.

Cloudflare Load Balancing test mode. 2025년 추가된 기능. 운영 트래픽을 그림자(shadow)로 새 origin에 흘려보내 부하·정확성을 동시에 검증합니다. 엄밀히는 부하 "테스트" 도구가 아니라 production shadowing 도구지만, 같은 박스에 둘 만합니다.

엔터프라이즈 SaaS를 골라야 하는 신호 3가지:

사내 보안팀이 "외부 인터넷에서 우리 서버에 부하를 주는 도구의 출처를 감사하라" 라고 요구할 때
100만 동시 사용자 같은 거대 규모가 필요한데 자체 k6/k8s 운영 인력이 없을 때
SAP, Citrix, Oracle Forms 같은 레거시 프로토콜 테스트 — LoadRunner 외에는 답이 없음

그 외의 경우, OSS k6 + Grafana Cloud k6의 SaaS 조합이 압도적으로 비용 효율이 좋습니다.

9. ChaosMesh + 카오스 엔지니어링 — 인접 영역

엄밀히 카오스 엔지니어링은 부하 테스트의 형제이지 같은 도구가 아닙니다. 부하 테스트가 "정상 상황에서 트래픽이 늘면 어떻게 되나" 를 본다면, 카오스 엔지니어링은 "비정상 상황(노드 다운, 네트워크 지연, 디스크 풀)에서 시스템이 어떻게 무너지나" 를 봅니다.

2026년 주요 카오스 도구는 다음과 같습니다.

도구	환경	특징
Chaos Mesh	Kubernetes	CNCF Graduated(2024), 11종 fault 유형, dashboard
LitmusChaos	Kubernetes	CNCF Incubating, ChaosHub 실험 라이브러리
Gremlin	SaaS	상용, 안전장치(blast radius), 엔터프라이즈
AWS Fault Injection Service (FIS)	AWS	매니지드, EC2/RDS/ECS/EKS 액션
Azure Chaos Studio	Azure	매니지드, Azure 리소스 fault

부하 테스트와 카오스 엔지니어링을 짝지어 돌리는 패턴이 2025년부터 자리잡았습니다. k6로 500 RPS를 만든 상태에서 Chaos Mesh로 pod 30%를 죽이면, HPA·readiness probe·circuit breaker가 모두 잘 작동하는지 한 번에 검증됩니다. CNCF의 Chaos Engineering Working Group이 2026년 베스트프랙티스 문서를 발표할 예정입니다.

10. 브라우저 perf — Lighthouse / WebPageTest / SpeedCurve / Calibre

브라우저 성능은 백엔드 부하 테스트와 완전히 다른 박스입니다. 백엔드 부하는 "서버가 RPS를 견디나" 를 묻지만, 브라우저 perf는 "사용자가 페이지를 빨리 본다고 느끼나" 를 묻습니다.

Lighthouse. Google이 만든 OSS 감사 도구. Chrome DevTools에 내장, CLI/Node API 제공, CI 통합(lighthouse-ci). 단일 페이지를 한 번 측정해서 Performance/Accessibility/Best Practices/SEO 점수를 100점 만점으로 매깁니다. 단일 측정이라 변동성이 크다는 게 약점.

npx lighthouse https://example.com \
  --output=json --output=html --output-path=./report

WebPageTest (현 Catchpoint). 2008년 Patrick Meenan이 시작, 2020년 Catchpoint가 인수. 전 세계 50+ 지역의 실제 브라우저(Chrome, Firefox, Edge)에서 페이지를 측정합니다. Waterfall, filmstrip, video 출력이 최고 수준. 무료 인터랙티브 UI 외에 WebPageTest API와 사설 인스턴스 옵션 제공.

# WebPageTest API 호출
webpagetest test https://example.com \
  --location ec2-us-east-1:Chrome \
  --connectivity 4G --runs 3 --first

SpeedCurve. Mark Zeman/Steve Souders가 만든 유료 SaaS. 합성(Synthetic) + 실사용자(RUM) 모니터링을 한 대시보드에 결합. 매일 자동 측정·회귀 알림. UX/디자인 친화적 시각화가 강점.

Calibre. Karolina Szczur가 만든 유료 SaaS. Lighthouse + WebPageTest를 결합해 perf budget을 코드로 정의(YAML)하고 CI 게이트로 만듭니다. 작은 팀이 합리적인 비용으로 도입할 수 있는 포지션.

# .calibre.yml 예시
budgets:
  - metric: largest-contentful-paint
    budget: 2500
  - metric: cumulative-layout-shift
    budget: 0.1
  - metric: interaction-to-next-paint
    budget: 200

RUM 측정 도구(Real User Monitoring): Cloudflare Web Analytics, Vercel Speed Insights, Google Search Console의 CrUX, Sentry Performance, New Relic Browser, Datadog RUM. 실제 사용자 브라우저에서 보낸 CWV 텔레메트리를 집계합니다.

브라우저 perf는 합성 측정(Synthetic, 통제된 환경의 반복 측정) 과 RUM(Real User Monitoring, 실사용자 텔레메트리) 두 가지가 함께 있어야 합니다. 합성만 보면 "랩에서는 빠른데 사용자 폰에서는 느린" 차이를 못 잡고, RUM만 보면 회귀 원인을 디버깅하기 어렵습니다.

11. Core Web Vitals — INP가 FID를 대체

Core Web Vitals(CWV)는 Google이 2020년 발표한 사용자 체감 성능 3대 지표입니다. 2024년 3월 INP(Interaction to Next Paint)가 FID(First Input Delay)를 공식 대체하면서 측정 방식이 바뀌었습니다. 2026년 5월 현재 공식 3대 지표는 다음과 같습니다.

지표	정의	Good	Needs Improvement	Poor
LCP (Largest Contentful Paint)	가장 큰 콘텐츠가 그려진 시점	`<2.5s`	`2.5s-4s`	`>4s`
INP (Interaction to Next Paint)	모든 상호작용 중 가장 느린 지연	`<200ms`	`200-500ms`	`>500ms`
CLS (Cumulative Layout Shift)	누적 레이아웃 이동 점수	`<0.1`	`0.1-0.25`	`>0.25`

INP가 FID를 대체한 이유는 명확합니다. FID는 첫 입력 하나만 측정해 "이미 너무 쉽다(거의 모든 사이트가 Good)"는 비판이 있었고, 사용자의 실제 경험과 괴리됐습니다. INP는 페이지 수명 동안의 모든 상호작용을 추적해 98 퍼센타일(또는 P98) 값을 봅니다. 이게 사용자가 "끊긴다" 라고 느끼는 진짜 순간입니다.

INP에 영향을 주는 가장 큰 요인은 메인 스레드 작업 시간입니다. React/Vue/Svelte의 무거운 렌더, 비대해진 hydration, 동기 third-party 스크립트가 주범입니다. 2024-2025년 사이 React 19 Server Components, Next.js 15 PPR(Partial Prerendering), Astro Islands 같은 메인 스레드 부담 줄이기 흐름이 가속화된 이유가 여기에 있습니다.

CWV 회귀를 잡는 실무 워크플로는 다음 4단계입니다.

합성 측정(Lighthouse CI 또는 Calibre)으로 main 브랜치 머지 시점에 변동 감지
RUM(Vercel/Cloudflare/Sentry)으로 실사용자 P75/P98 추적
WebPageTest로 회귀가 발생한 페이지를 깊이 디버깅(filmstrip, waterfall)
실험(A/B)으로 수정 적용 후 RUM 메트릭이 회복되는지 확인

12. AI in 부하 테스트 — k6 Studio, Artillery Pro AI

2024-2025년에 부하 테스트 도구에 AI가 본격적으로 들어왔습니다. 두 가지 흐름이 있습니다.

첫째, 시나리오 생성. 브라우저에서 사용자 액션을 녹화해 자동으로 스크립트를 만드는 흐름. 2024년 출시된 k6 Studio는 데스크톱 앱으로, 사용자가 브라우저에서 클릭하면 HAR을 캡처해 정제된 k6 JS 시나리오를 만들어 줍니다. 토큰화·파라미터화도 자동입니다. Artillery Pro AI는 OpenAPI 스펙을 받아 시나리오 YAML을 생성합니다.

둘째, 결과 분석. 부하 테스트 결과(시계열 메트릭 + 로그 + APM)를 LLM이 읽어 "병목은 데이터베이스 connection pool 고갈로 보입니다, p99가 1.5s에서 8s로 튀는 구간이 새 인덱스가 적용되지 않은 쿼리와 일치합니다" 같은 자연어 진단을 내립니다. BlazeMeter AI Co-Pilot, Grafana Sift, Datadog Bits 가 대표적입니다.

2026년 시점에서 AI는 초안 생성과 결과 요약에 강하고, 임계치 결정과 인과 분석에는 약합니다. 사람이 "이 API에서 p95가 500ms를 넘으면 안 된다" 라고 결정하는 일은 여전히 사람의 몫이고, AI는 데이터를 빠르게 정리하고 의심 후보를 줄여주는 어시스턴트 역할입니다.

13. 한국 / 일본 — 네이버, 토스, Mercari

네이버. 네이버 D2 블로그에 따르면 검색·페이·웹툰 같은 핵심 서비스는 자체 부하 테스트 프레임워크 + JMeter 조합을 오래 써왔습니다. 최근 글(2024)에서는 일부 신규 서비스에 k6를 도입한 사례를 공유했고, 사내 부하 테스트 플랫폼이 JMeter .jmx + k6 JS 양쪽을 모두 수용하는 방향으로 갑니다.

토스 (Toss). 토스는 결제·은행 등 금융 서비스 특성상 부하 테스트가 출시 게이트로 강제됩니다. 토스 기술 블로그에는 k6 + 자체 메트릭 파이프라인 + Grafana 조합으로 매 배포마다 부하 회귀를 잡는 사례가 여러 차례 공개됐습니다. "사용자 1명이 결제 1회를 완료하는 시나리오를 코드로 정의해 RPS가 아니라 TPS(Transaction Per Second)로 본다"는 접근이 인상적입니다.

카카오. 카카오 기술 블로그는 카카오톡 메시지 전송 같은 대규모 시스템에 Gatling을 오래 써왔다고 공유했습니다. JVM 백엔드(Spring) 비중이 높은 조직 구조와 잘 맞습니다.

일본 — Mercari. Mercari 엔지니어링 블로그(engineering.mercari.com)는 2023-2025년 사이 k6를 메인 부하 테스트 도구로 표준화한 여정을 공개했습니다. 특히 GraphQL 게이트웨이의 부하 테스트에 k6 + GraphQL extension을 쓰는 패턴이 일본 커뮤니티에 큰 영향을 줬습니다.

일본 — Yahoo Japan / LINE. LINE은 메시지 백엔드에 Locust + 자체 분산 클러스터를 운영합니다. Yahoo Japan은 검색 백엔드에 JMeter + 자체 사설 인프라를 오래 써왔습니다.

일본 — SmartHR, freee, MoneyForward. SaaS 스타트업들은 일관되게 k6를 첫 선택지로 도입했습니다. JS/TS 친화 백엔드(Node, Go)와 잘 맞고, 일본어 자료도 풍부합니다.

한·일 사례에서 공통된 흐름은 명확합니다. 레거시·엔터프라이즈는 JMeter/Gatling, 신규·SaaS는 k6. 그리고 둘 다 합성 부하 테스트 + 운영 RUM을 짝지어 봅니다.

14. 누가 무엇을 골라야 하나 — 백엔드 / 프론트엔드 / 엔터프라이즈 / 1인

도구 추천을 페르소나별로 정리합니다.

페르소나	1순위	2순위	한 줄 평
모던 백엔드 팀 (Node/Go/Rust)	k6 v1	oha (CLI)	JS 시나리오 + Grafana 통합
Python ML/데이터 팀	Locust	k6	시나리오 안에서 pandas/numpy 쓰고 싶을 때
JVM 팀 (Spring/Quarkus)	Gatling	k6	빌드와 통합 + 예쁜 리포트
규제 산업 (금융/의료)	JMeter	LoadRunner	GUI 산출물이 감사 요구
엔터프라이즈 대규모 (100만+)	BlazeMeter	NeoLoad	인프라까지 위탁
빠른 한 줄 벤치마크	oha	Vegeta	TUI로 즉시 이해
Node 서버 친화	autocannon	k6	npx 한 번이면 끝
SaaS 스타트업 1인	k6 + oha	Vercel Speed Insights	무료 OSS로 시작
프론트엔드 성능 회귀 감시	Lighthouse CI	Calibre	PR마다 자동 측정
합성 + RUM 결합	SpeedCurve	Calibre + Cloudflare RUM	UX팀 친화
카오스 엔지니어링 짝지어	Chaos Mesh + k6	LitmusChaos	k8s에서 부하 + 장애 동시
AWS 중심	Azure Load Testing(?) AWS FIS + k6	BlazeMeter	매니지드가 편함
Azure 중심	Azure Load Testing	k6 + Azure Chaos Studio	결재 절차 없이 즉시

마지막으로 하나만 고르라면: 모던 백엔드 + 모던 프론트엔드를 모두 다루는 풀스택 팀이라면, k6 v1 (부하) + Lighthouse CI (브라우저) + oha (한 줄 벤치마크) 세 가지 조합이 2026년 5월 기준 최적해입니다. 세 도구 모두 OSS이고, 단일 바이너리 또는 단일 패키지로 즉시 시작할 수 있으며, CI 게이트로 만들기 쉽습니다.

부하 테스트는 절대 일회성 이벤트가 아닙니다. 매 배포의 회귀 감시 게이트가 되어야 하고, 운영 RUM과 짝지어 "랩에서 봤던 숫자와 실제 사용자가 보는 숫자의 차이"를 늘 의식해야 합니다. 도구는 단지 그 워크플로를 가능하게 해주는 부품일 뿐입니다.

15. 참고 / References

Grafana k6 official site — https://k6.io
k6 v1.0 release announcement — https://grafana.com/blog/2024/05/15/k6-v1.0-release/
k6 GitHub — https://github.com/grafana/k6
k6 Studio — https://grafana.com/blog/2024/10/k6-studio-test-builder/
Artillery — https://www.artillery.io
Artillery Pro AI — https://www.artillery.io/blog/ai
Locust — https://locust.io
Locust docs — https://docs.locust.io
Apache JMeter — https://jmeter.apache.org
JMeter 5.6 release notes — https://jmeter.apache.org/changes_history.html
Gatling — https://gatling.io
Gatling Java/Kotlin DSL — https://docs.gatling.io/reference/install/oss/
Vegeta — https://github.com/tsenart/vegeta
hey — https://github.com/rakyll/hey
wrk — https://github.com/wg/wrk
oha — https://github.com/hatoo/oha
autocannon — https://github.com/mcollina/autocannon
Bombardier — https://github.com/codesenberg/bombardier
BlazeMeter — https://www.blazemeter.com
OpenText LoadRunner — https://www.opentext.com/products/loadrunner-professional
Tricentis NeoLoad — https://www.tricentis.com/products/performance-testing-neoload
Azure Load Testing — https://learn.microsoft.com/en-us/azure/load-testing/
Cloudflare Load Balancing — https://developers.cloudflare.com/load-balancing/
Chaos Mesh — https://chaos-mesh.org
LitmusChaos — https://litmuschaos.io
Gremlin — https://www.gremlin.com
AWS Fault Injection Service — https://aws.amazon.com/fis/
Azure Chaos Studio — https://learn.microsoft.com/en-us/azure/chaos-studio/
Lighthouse — https://developer.chrome.com/docs/lighthouse/overview
Lighthouse CI — https://github.com/GoogleChrome/lighthouse-ci
WebPageTest — https://www.webpagetest.org
SpeedCurve — https://www.speedcurve.com
Calibre — https://calibreapp.com
Vercel Speed Insights — https://vercel.com/docs/speed-insights
Cloudflare Web Analytics — https://www.cloudflare.com/web-analytics/
web.dev INP — https://web.dev/articles/inp
Core Web Vitals 2024 update — https://web.dev/blog/inp-cwv-march-12
Mercari Engineering blog (k6) — https://engineering.mercari.com/en/blog/
Naver D2 blog — https://d2.naver.com
Toss tech blog — https://toss.tech
Kakao tech blog — https://tech.kakao.com