Purple Gauge

풀고 있는 문제

성능테스트는 대부분의 조직에서 “해야 하는데 못하는 일”입니다. 테스트 스크립트를 짤 줄 아는 사람이 제한적이고, 임계값을 어떻게 정해야 할지 모르고, 결과가 나와도 해석할 수 없습니다. 결국 전문 인력 한두 명에게 의존하게 되고, 그마저도 이벤트성으로 끝납니다.

특히 이커머스처럼 트래픽 변동이 큰 서비스에서는, 성능테스트가 특정 시점의 이벤트가 아니라 상시 수행 가능한 프로세스여야 합니다.

접근 방식

“운영 환경이 이미 알고 있는 것을 활용한다”

성능테스트의 가장 큰 진입 장벽은 “기준값을 어떻게 정할 것인가”입니다. 우리는 이미 운영 중인 APM(Application Performance Monitoring)에 답이 있다고 봤습니다.

베이스라인 자동 설정

APM에서 운영 환경의 응답시간, TPS, 에러율을 자동으로 수집합니다. 이 데이터를 K6의 threshold로 변환하면, “현재 운영 수준보다 나쁘지 않은가?”를 자동으로 판단할 수 있습니다.

개발팀이 임계값을 고민할 필요가 없어지는 것이 핵심입니다.

시나리오 템플릿

이커머스의 핵심 흐름(상품 조회 → 장바구니 → 결제)을 템플릿으로 제공합니다. 개발팀은 URL과 파라미터만 바꾸면 자신의 서비스에 맞는 시나리오를 즉시 사용할 수 있습니다.

인프라 추천

테스트 결과에서 병목 지점을 분석하고, 적정 인프라 구성(Pod 수, CPU/메모리)을 추천합니다. 성능테스트의 결과가 단순한 숫자가 아니라 실행 가능한 인프라 의사결정으로 이어지는 것을 목표로 합니다.

기술적 선택

영역	선택	이유
테스트 엔진	Grafana K6	JavaScript 기반으로 개발자 친숙, on-demand 컨테이너 실행
메트릭 연동	WhaTap Open API	이미 전사 표준 APM으로 운영 중
시각화	Grafana OSS	K6 결과와 자연스럽게 통합
백엔드	Python FastAPI	빠른 프로토타이핑 + 비동기 처리
프론트엔드	React + TypeScript	대시보드 UI에 적합

배운 것

• 진입 장벽을 낮추는 것이 자동화보다 중요하다. 완벽한 자동화보다 “5분 안에 첫 테스트를 돌릴 수 있는가”가 채택률을 결정합니다.
• 베이스라인이 있으면 결과 해석이 쉬워진다. “좋은 건지 나쁜 건지”를 판단하기 위해 비교 기준이 필수적입니다. 운영 메트릭이 자연스러운 기준선이 됩니다.
• 결과를 행동으로 연결해야 의미가 있다. 숫자만 보여주면 아무도 움직이지 않습니다. “Pod를 3개에서 5개로 늘려라”가 “TPS가 200에서 150으로 떨어졌다”보다 강력합니다.