k6로 API 부하 테스트하기

k6 부하 테스트를 잘 쓴다는 말은 도구 사용법을 많이 아는 것이 아니라 **성능 수치를 만들기보다 시스템 한계를 설명하는 것** 를 달성하는 테스트 체계를 만든다는 뜻이다. 이 글은 API와 백엔드의 용량 계획 및 릴리즈 검증에서 어떤 테스트가 신뢰를 만들고, 어떤 테스트가 단지 느린 노이즈가 되는지를 구분한다.

테스트 전략이 흔들리는 이유

테스트가 많아도 실패 원인을 빠르게 설명하지 못하면 팀은 결국 CI를 신뢰하지 않게 된다.
k6 부하 테스트를 만능 해법처럼 쓰면 더 싼 계층에서 잡을 버그를 비싼 곳에서 발견하게 된다.
좋은 테스트 전략은 수량이 아니라 발견 위치와 운영 비용으로 평가해야 한다.

핵심 설계 모델

부하 테스트의 목적은 멋진 TPS 숫자가 아니라 시스템이 어디서 무너지는지 이해하는 것이다. 따라서 테스트를 설계할 때는 먼저 이 계층이 무엇을 증명해야 하는지 정하고, 나머지 계층과 역할이 겹치지 않게 분리해야 한다.

실전에서 유효한 패턴

실패 원인을 짧게 만들기

실제 사용자 행동을 반영한 시나리오와 데이터 분포가 먼저다.

테스트 경계를 분명히 하기

응답 시간뿐 아니라 오류율, 자원 사용량, 다운스트림 포화까지 같이 봐야 한다.

운영 정책으로 묶기

기준선 테스트와 점진적 ramp-up을 같이 두면 회귀를 읽기 쉬워진다.

실전 예시

가벼운 smoke 부하와 응답 시간 임계값을 함께 두는 기본 예시다.

export const options = {
  stages: [
    { duration: "1m", target: 50 },
    { duration: "3m", target: 200 },
    { duration: "1m", target: 0 },
  ],
  thresholds: {
    http_req_duration: ["p(95)<400"],
  },
};

트레이드오프와 안티패턴

부하 테스트는 인프라 비용이 크지만, 실제 병목을 릴리즈 전 발견하는 가치가 크다.
너무 인공적인 시나리오는 성능 착시를 만든다.
성능 숫자는 단독으로 해석하면 위험하다.

대표적인 안티패턴은 다음과 같다.

단일 최고 TPS 숫자만 보고 판단하는 것
프로덕션과 전혀 다른 데이터 크기로 테스트하는 것
앱 지표와 인프라 지표를 분리해서 보는 것

검토 체크리스트

이 테스트가 가장 먼저 잡아야 할 결함 종류가 명확한가
같은 버그를 더 비싼 계층에서 중복 검증하고 있지 않은가
실패 메시지가 원인 추적에 충분한가
flaky를 격리하고 소유자를 지정하는 운영 규칙이 있는가
릴리즈 게이트와 개발 피드백 게이트가 분리돼 있는가

마무리 판단

k6는 성능 자랑 도구가 아니라 시스템 이해 도구다. 시나리오, 지표, 해석 기준이 함께 설계될 때만 용량 판단이 의미를 가진다.

다음으로 읽기 좋은 글

🧪 Test

AI 서비스 개발, 운영, 성능개선을 하나의 루프로 연결합니다