![\"k6](\"/assets/etc.png\" "\\"k6")
성능 문제는 사용자가 느끼기 전에 발견하기 어렵다. 로컬에서는 빠른데 스테이징에서 느리고, 스테이징에서는 괜찮은데 프로덕션에서만 터지는 일은 흔하다. 그래서 부하 테스트는 여전히 가장 비싼 보험 중 하나다. 잘못하면 시간만 쓰고 결론은 “뭔가 느림”으로 끝나지만, 잘하면 배포 전에 회귀를 잡고, 용량 계획과 SLO 논의의 근거가 된다.
\n이 글은 Grafana k6를 기준으로, 스크립트 작성부터 시나리오 설계, 지표 읽기, CI에 게이트로 묶는 방법까지 한 흐름으로 정리한다. 특정 클라우드 벤더에 종속되지 않으려는 팀에도 맞도록 구성했다.
\n부하 도구는 JMeter, Gatling, Locust 등 선택지가 많다. k6가 자주 선택되는 이유는 대략 다음과 같다.
\n반면 브라우저 렌더링이나 복잡한 GUI 시나리오는 다른 도구가 나을 수 있다. k6는 주로 HTTP/gRPC 등 프로토콜 레벨 부하에 강하다.
\n아래는 개념을 보여주는 예시다. 실제 URL·헤더·페이로드는 서비스에 맞게 바꾼다.
\nimport http from \"k6/http\";\nimport { check, sleep } from \"k6\";\n\nexport const options = {\n vus: 10,\n duration: \"30s\",\n};\n\nexport default function () {\n const res = http.get(\"https://example.com/api/health\");\n check(res, {\n \"status is 200\": (r) => r.status === 200,\n });\n sleep(1);\n}실행은 k6 run script.js 한 줄로 끝난다. 여기서 중요한 것은 “돌아간다”가 아니라 “무엇을 측정하는가”다.
용어를 정확히 쓰자.
\n잘못된 부하 테스트의 대표는 “그냥 VU 1000으로 때려본다”다. 현실 트래픽 패턴과 다르면, 병목이 엉뚱한 곳으로 보이거나 반대로 숨는다.
\nk6에서는 scenarios로 여러 패턴을 동시에 돌릴 수 있다. 팀은 “우리 서비스의 피크 시간대 그래프”를 대략이라도 그려 두고 시나리오에 반영해야 한다.
부하 테스트의 산출물은 그래프가 아니라 합격/불합격 기준이어야 한다. k6의 thresholds는 그 역할을 한다.
export const options = {\n thresholds: {\n http_req_duration: [\"p(95)<500\"],\n http_req_failed: [\"rate<0.01\"],\n },\n};여기서 p95 지연 500ms 미만 같은 숫자는 어디서 오는가? 하늘에서 떨어지지 않는다. 제품의 SLO(예: “핵심 API p95 300ms”)에서 완화된 버전을 두거나, 스테이징 환경 한계를 반영해 조정한다. 중요한 것은 이 숫자를 서비스 오너와 합의했다는 사실이다.
\ncheck()는 요청 단위 검증이다. 비즈니스적으로 “장바구니 합계가 맞는가” 같은 것도 넣을 수 있다.thresholds는 전체 집계에 대한 패스 조건이다.둘 다 없으면 “높은 RPS인데 전부 500 에러” 같은 상황을 놓칠 수 있다.
\n부하 테스트는 프로덕션에서 함부로 돌리면 안 된다는 말이 먼저다. 데이터가 오염되거나, 결제·알림이 실제로 발송될 수 있다.
\n권장 패턴은 다음과 같다.
\nk6 기본 메트릭 중에서 특히 자주 보는 것은 다음과 같다.
\n여기에 애플리케이션 메트릭(CPU, GC, DB 커넥션 풀 대기, 쿼리 지연)을 함께 봐야 병목이 어디인지 알 수 있다. k6만 보면 “느리다”밖에 안 나온다.
\nHTTP 외 프로토콜을 쓴다면 별도 모듈·스크립트 패턴이 필요하다. 핵심은 동일하다. 동시성 모델, 페이로드 크기, 스트림 특성을 반영해 시나리오를 나눈다.
\n“매 PR마다 풀 부하”는 비용과 안정성 문제로 어렵다. 현실적인 타협은 다음과 같다.
\nk6 run이 exit code 0이면 통과, 임계값 실패 시 비제로로 실패하게 한다.YAML 예시는 환경마다 다르므로, 여기서는 단계만 적는다.
\nk6 run + 임계값이렇게 해야 “어제까지 됐는데 오늘 느려짐”을 코드 변경과 연결할 수 있다.
\n도구만으로는 부족하다. 다음이 있어야 한다.
\nk6는 이런 문화를 코드와 숫자로 고정하는 역할을 한다.
\n한 번 찍고 끝내면 부하 테스트는 금방 썩는다. 같은 시나리오를 주기적으로 돌리고, 커밋 해시·환경 버전·DB 사이즈를 메타데이터로 남겨라. 그래프가 “예전보다 느려졌다”를 증명할 수 있다.
\nk6는 학습 곡선이 비교적 완만하고, 코드 리뷰 가능한 부하 시나리오를 만든다는 점에서 팀 도구로 잘 맞는다. 핵심은 도구가 아니라 부하 모델과 임계값을 비즈니스와 합의하는 일이다. 그 합의가 있으면 CI 게이트는 자연스럽게 생기고, 성능 이슈는 “누군가의 감”이 아니라 계약이 된다.
\n서비스가 커질수록 성능은 기능과 같다. 사용자는 changelog를 읽지 않는다. 체감 속도로 평가한다. k6는 그 체감을 배포 전에 재현하게 돕는 도구다. 오늘 스테이징에서 한 번, 임계값을 적어 보고 실패해 보아라. 실패가 보이면 그건 좋은 신호다. 프로덕션에서 터지기 전에 터진 것이니까.
\n마지막으로, 부하 테스트 결과는 회의 자료 한 장으로 남기길 권한다. 그래프 스크린샷, 임계값 표, 환경 스펙(DB 사이즈, 인스턴스 타입), 실행한 k6 버전까지. 3개월 뒤의 성능 이슈는 거의 항상 “그때와 지금이 다른가?”에서 시작하니까, 기록이 곧 방패다.
\n이 세 가지만 지켜도, 6개월 뒤의 자신이 고마워할 것이다.
\nexport const options 안에 scenarios를 정의하면, 한 번의 k6 run으로 서로 다른 트래픽 패턴을 병렬에 가깝게 섞을 수 있다. 예를 들어 “일반 조회 API”와 “무거운 리포트 API”를 동시에 때려 리소스 경합을 본다. 실제 피크 시간에는 사용자 행동이 단일 패턴이 아니기 때문이다.
설계할 때는 각 시나리오에 명확한 exec 함수를 나누고, 공통 헬퍼는 import로 묶는다. 이렇게 해야 스크립트가 길어져도 리뷰 가능한 구조를 유지한다.
// 개념 예시 — 실제 옵션 키는 k6 문서와 버전을 확인할 것\nexport const options = {\n scenarios: {\n browse: {\n executor: \"ramping-vus\",\n startVUs: 0,\n stages: [\n { duration: \"2m\", target: 50 },\n { duration: \"5m\", target: 50 },\n { duration: \"2m\", target: 0 },\n ],\n exec: \"browseFlow\",\n },\n spike: {\n executor: \"constant-vus\",\n vus: 200,\n duration: \"1m\",\n startTime: \"3m\",\n exec: \"spikeFlow\",\n },\n },\n};\n\nexport function browseFlow() {\n /* ... */\n}\nexport function spikeFlow() {\n /* ... */\n}startTime으로 시나리오 간 시간 순서를 주면, “점진적 증가 후 갑자기 스파이크” 같은 현실적인 시퀀스를 연출할 수 있다.
VU 기반 모델은 “사용자 동시성”에 직관적이지만, 목표 처리량을 고정하고 싶을 때는 constant-arrival-rate 같은 실행기를 쓴다. 예를 들어 “초당 500건의 주문 생성 요청을 유지할 수 있는가?”처럼 비즈니스 KPI와 직결된 질문에 맞춘다.
이때 주의할 점은, 시스템이 목표 RPS를 감당하지 못하면 iteration이 밀리고 VU가 부족하다는 신호가 뜬다는 것이다. 그래서 VU 상한을 넉넉히 잡거나, 목표 RPS를 단계적으로 올린다.
\nHTTP 지연만으로는 부족할 때가 있다. 예를 들어 결제 API는 200이어도 응답 본문의 status: \"failed\"일 수 있다. 이때 Counter나 Rate를 정의해 비즈니스 실패율을 따로 본다.
import { Rate } from \"k6/metrics\";\n\nconst bizFail = new Rate(\"biz_payment_failed\");\n\nexport default function () {\n const res = http.post(/* ... */);\n const body = res.json();\n bizFail.add(body.ok !== true);\n}그리고 thresholds에 biz_payment_failed를 걸어 “HTTP는 성공인데 장사는 실패”를 잡는다.
한 대의 k6 프로세스는 네트워크·CPU 한계로 RPS 상한이 있다. 더 높은 부하가 필요하면 k6 분산 실행(execution segments)이나 클라우드 실행을 검토한다. 이때는 동일 시나리오 버전을 고정하고, 클럭 동기화 이슈를 의식해야 한다.
\n반대로 “우리 회사 노트북 한 대로 프로덕션과 같은 수준”을 기대하면 안 된다. 부하 생성기 자체가 병목이 되면 수치가 왜곡된다. CPU 사용률을 모니터링하라.
\n짧은 스파이크만 돌리면 메모리 누수, 커넥션 풀 고갈, 디스크 채움 같은 느린 문제를 놓친다. 몇 시간 이상 일정한 부하를 유지하는 소크 테스트는 별도 일정으로 잡는 것이 좋다. 특히 캐시 TTL, 배치 작업, 로그 로테이션과 겹치는 시간대를 고른다.
\n실제 워크플로는 조직의 러너·시크릿 정책에 맞춰야 한다. 아래는 개념을 잡기 위한 스케치다.
\n# .github/workflows/k6-smoke.yml (개념)\n# on:\n# pull_request:\n# branches: [main]\n# jobs:\n# k6:\n# runs-on: ubuntu-latest\n# steps:\n# - uses: actions/checkout@v4\n# - name: Install k6\n# run: |\n# sudo gpg -k\n# sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69\n# echo \"deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main\" | sudo tee /etc/apt/sources.list.d/k6.list\n# sudo apt-get update\n# sudo apt-get install k6\n# - name: Run k6 smoke\n# env:\n# BASE_URL: ${{ secrets.STAGING_BASE_URL }}\n# run: k6 run ./load/smoke.js시크릿 이름, k6 설치 방식, 캐시는 팀 표준에 맞게 조정한다. 중요한 것은 PR마다 동일한 스테이징을 바라보게 하고, 임계값 실패 시 워크플로가 빨간불을 켠다는 점이다.
\n가능하다면 k6 실행 ID를 헤더로 넘기고, 애플리케이션 로그·분산 트레이스(OpenTelemetry 등)에 같은 ID를 남긴다. 그러면 “느린 요청” 하나를 골라 DB 쿼리·외부 API·큐 지연까지 한 줄로 따라갈 수 있다. 부하 테스트는 관측 가능성과 세트일 때 가장 강해진다.
\n스테이징이든 어디든, 타사에 피해를 주는 부하를 절대 보내지 말 것. 허용 IP, WAF, rate limit을 먼저 확인한다. 사내 규정에 부하 테스트 승인 절차가 있다면 따른다.
\n프로덕션 장애가 났을 때, 같은 트래픽 패턴을 k6로 재현하면 수정이 빨라진다. 이때 “그때의 페이로드 분포”를 대략이라도 복원하는 것이 핵심이다. 로그 샘플링이나 대표 트레이스를 모아 시나리오를 버전 관리하라.
\n같은 p95 지표라도 요청 분포가 다르면 의미가 달라진다. 소수의 극단적 아웃라이어가 p95를 밀어 올린 것인지, 전체가 고르게 나빠진 것인지 확인하라. 전자라면 특정 쿼리·특정 테넌트 문제일 수 있고, 후자라면 전체 용량 문제일 가능성이 크다.
\n히스토그램을 Grafana에 보낼 수 있다면, 시간대별로 겹쳐 보는 것이 좋다. 배포 직후에만 지연이 튀었다면, 캐시 콜드 스타트, JIT 컴파일, 커넥션 풀 워밍업 같은 일시적 이유일 수 있다.
\n체크리스트가 형식이 아니라 회의록 한 줄이라도 남으면, 부하 테스트는 팀의 자산이 된다.
\n또 한 가지, 지역(latency) 차이를 기억하라. 부하 생성기가 서울에 있고 API가 버지니아에 있으면 RTT만으로도 p95가 커진다. CI 러너 위치와 스테이징 리전을 맞추거나, 결과를 비교할 때 항상 같은 네트워크 경로를 전제로 문서화하라.
\n부하 테스트는 한 번의 이벤트가 아니라 제품의 지속적인 질문이다. “우리는 얼마나 버틸 수 있는가?”에 대한 답은 코드 한 줄이 아니라, 시나리오·임계값·관측이 합쳐졌을 때 비로소 신뢰를 얻는다. k6는 그 답을 자동화하기 좋은 도구다. 이 글이 스테이징에서의 첫 thresholds 실패를, 프로덕션의 미래의 성공으로 바꾸는 데 도움이 되기를 바란다.