개념
k6와 무엇이 다른가
레슨 3에서 배운 k6는 코드로 부하 테스트 시나리오를 작성했다. JMeter는 같은 목적(부하 테스트)을 GUI 화면에서 요소를 클릭하고 설정값을 채워 만든다는 점이 가장 큰 차이다.
| k6 (레슨 3) | JMeter | |
|---|---|---|
| 작성 방식 | 코드(JavaScript) | GUI(트리 구조 화면 구성) |
| 진입 장벽 | 코드를 읽고 쓸 줄 알아야 함 | 코드 지식 없이도 시작 가능 |
| 버전 관리 | 텍스트 파일이라 Git과 잘 맞음 | XML 설정 파일 — Git으로 관리는 가능하지만 diff 읽기가 어려움 |
| CI 통합 | 스크립트 실행이라 자연스럽게 연결(모듈 14) | 가능은 하지만 추가 설정이 더 필요 |
| 오래된 정도 | 비교적 최근 도구 | 오래되고 검증된 도구, 국내 레거시 시스템에서 여전히 널리 쓰임 |
둘 중 뭐가 더 좋다는 게 아니다. 팀에 코드를 다루는 사람이 적거나, 이미 JMeter 자산(저장된 테스트 계획)이 쌓여있는 조직이라면 JMeter가 합리적인 선택이다.
JMeter의 핵심 구성요소
JMeter는 왼쪽 트리에 요소를 쌓아 넣는 방식으로 시나리오를 만든다.
Test Plan (전체 테스트 계획)
└─ Thread Group (가상 사용자 그룹 — k6의 vus에 해당)
├─ HTTP Request (실제 요청 — 어떤 API를 호출할지)
├─ Assertion (응답 검증 — k6의 check()에 해당)
└─ Listener (결과를 보는 화면 — 표, 그래프 등)- Thread Group — 가상 사용자 수(Number of Threads), 얼마나
빨리 늘릴지(Ramp-up Period), 몇 번 반복할지(Loop Count)를
설정한다. 레슨 3에서 배운
vus와duration이 여기에 대응한다. - HTTP Request Sampler — 실제로 호출할 URL, 메서드(GET/POST 등), 파라미터를 설정한다. 모듈 12에서 배운 API 요청 구조를 그대로 화면에 채워 넣는 것이다.
- Assertion — "응답 코드가 200인가", "응답 시간이 500ms 이내인가" 같은 조건을 검증한다.
- Listener — 결과를 표(View Results Tree)나 그래프(Summary
Report)로 보여준다. 레슨 3에서 본
http_req_duration,http_req_failed와 같은 지표를 여기서도 확인할 수 있다 — 도구는 달라도 읽어야 할 지표(평균, p95, 실패율)는 똑같다.
부하 늘려가기
레슨 3에서 배운 "부하를 점점 늘려가며 한계 지점을 찾는" 스트레스 테스트도 JMeter로 똑같이 만들 수 있다. Thread Group 여러 개를 단계적으로 배치하거나, Ramp-up Period를 조정해 사용자가 점진적으로 늘어나게 설정한다.
결과를 읽는 눈은 도구를 넘나든다
JMeter의 Summary Report에 나오는 Average, 90% Line, Error % 같은
값은, 레슨 3에서 배운 k6의 avg, p(95), http_req_failed와
같은 개념을 다른 이름으로 부르는 것뿐이다. 도구 하나의
화면 구성을 외우기보다, "평균은 왜곡될 수 있고 백분위수를 봐야
한다"는 레슨 3의 원칙을 이해하고 있으면 어떤 도구를 만나도
같은 방식으로 결과를 해석할 수 있다.
실무에서 왜 필요한가
이미 JMeter로 만들어진 테스트 자산이 있는 조직에 QA로 합류하면, k6만 알아서는 그 자산을 활용할 수 없다. 반대로 코드를 다루는 개발자가 많은 팀에서는 k6가 CI 파이프라인(모듈 14)에 훨씬 자연스럽게 녹아든다. 실무에서 중요한 건 "어느 도구가 우월한가"가 아니라, 우리 팀의 구성과 기존 자산에 맞는 도구를 고르고, 결과를 정확히 해석할 수 있는가다.