성능 테스트 심화 — 워크로드 모델링·용량 산정·병목 분석·튜닝 사이클

학습 목표

이 모듈 한 줄 요약 — "부하를 거는 법 말고, 결과를 해석하는 법". 도구로 부하를 거는 것은 배웠다. 현장에서 성능 시험이 실패하는 지점은 대개 도구가 아니다 — 현실과 다른 상황을 만들어 놓고 재거나, 나온 숫자가 무슨 뜻인지 모르거나, 어디가 막혔는지 못 찾는 것이다. 그 세 가지를 다룬다.

모듈 16(레슨 2·3·9)과 모듈 21에서 우리는 부하 테스트를 만드는 법을 배웠다. k6 스크립트를 쓰고, JMeter 스레드 그룹을 올리고, Locust·nGrinder로 부하를 분산시켰다. 그런데 현장에서 성능 테스트가 실패하는 지점은 대부분 도구가 아니다. 테스트가 재현하는 부하가 실제 트래픽과 다르고, 목표 숫자의 근거가 없고, 느린 이유를 짚지 못한 채 "서버를 늘려 보자"로 끝나는 것 이다. 이 모듈은 도구 다음에 오는 그 일을 다룬다.

네 개의 레슨은 성능 테스트 한 사이클을 순서대로 따라간다. 먼저 운영 로그에서 워크로드 모델을 뽑는다 — 어떤 시나리오가 몇 퍼센트인지, 피크 시각의 도착률이 얼마인지, 닫힌 모델과 열린 모델 중 무엇으로 부하를 만들지. 다음으로 그 모델 위에서 성능 요구사항과 용량을 산정한다 — 리틀의 법칙으로 동시 사용자·처리량·응답시간을 연결하고, 목표치를 "빨랐으면 좋겠다"가 아니라 합의 가능한 문장으로 쓴다. 그다음 병목을 계층별로 짚는다 — APM 트레이스와 프로파일러, USE·RED 방법으로 애플리케이션·DB·네트워크 중 어디가 포화인지 판정한다. 마지막으로 튜닝 사이클과 리포팅 이다. 측정·개선·재측정을 몇 바퀴 돌릴지 정하고, 백분위로 보고하며, 언제 멈출지를 합의한다.

이 모듈이 가정하는 독자는 이미 부하 스크립트를 한 번은 돌려 본 사람이다. 그래서 도구 사용법을 다시 설명하지 않는다. 대신 같은 k6·JMeter·Gatling 스크립트를 왜 그 모양으로 써야 하는지 를 다룬다. 응답 시간 평균이 0.9초인 시스템과 p99가 11초인 시스템은 같은 시스템일 수 있고, 후자만 장애가 난다. 숫자 하나를 더 보는 것이 아니라 부하의 모양과 분포의 꼬리 를 보는 눈이 이 모듈의 목표다.

성능 결과를 성적서·보고서에 적는 통계 규칙(백분위 합산의 오류, coordinated omission)은 모듈 31 레슨 4에서 이미 다뤘다. 여기서는 그 통계를 어떤 부하 위에서 만들어 내고, 어떻게 개선 판단으로 연결하는가 에 집중한다. 추론 서빙처럼 도메인 특화 성능 판정은 모듈 39 레슨 6을 함께 본다.

완료 후 할 수 있는 것

• 운영 액세스 로그·APM 데이터에서 시나리오 비율과 시간대별 도착률을 집계해 워크로드 모델 한 장으로 정리할 수 있다
• 닫힌 모델(VU + think time)과 열린 모델(arrival rate)의 차이를 설명하고, 검증하려는 질문에 맞는 쪽을 고를 수 있다
• 정상·피크·스파이크·내구 네 가지 부하 모양을 k6 시나리오 또는 JMeter·Gatling 설정으로 구현할 수 있다
• 리틀의 법칙(L = λ × W)으로 동시 사용자·처리량·응답시간 중 두 개에서 나머지 하나를 계산하고, 필요한 VU 수와 서버 대수를 근거 있게 산정할 수 있다
• 성능 요구사항을 워크로드·측정 지점·백분위·기간·허용 오류율이 모두 적힌 판정 가능한 문장으로 쓸 수 있다
• USE(자원)와 RED(요청) 방법으로 지표를 배치하고, APM 트레이스·프로파일러로 애플리케이션·DB·네트워크 계층 중 병목 계층을 판정할 수 있다
• N+1 쿼리, 커넥션 풀 고갈, GC 정지, 락 경합 같은 전형적 병목의 지표 패턴을 구분할 수 있다
• 측정·개선·재측정 사이클의 종료 조건을 정하고, p95·p99와 오류율·자원 여유를 함께 담은 한 장짜리 성능 리포트를 쓸 수 있다

채용시장에서의 위치

국내 공고에서 "성능 테스트 경험"은 대개 두 층으로 갈린다. 아래층은 "JMeter/k6로 부하 테스트를 수행해 본 경험"이고, 위층은 "성능 요구사항 정의 및 용량 산정", "병목 구간 분석 및 튜닝 협업", "성능 개선 전후 비교 리포트" 다. 아래층은 도구 사용 경험으로 증명되지만, 위층은 숫자와 판단의 흔적을 요구한다. 이 모듈이 겨냥하는 것은 위층이다.

면접에서 가장 약한 답은 "TPS 500까지 올려 봤습니다"이고, 가장 강한 답은 "운영 로그에서 피크 시간 도착률이 초당 42건이고 시나리오 비율이 조회 7 : 검색 2 : 주문 1이라는 걸 확인해 워크로드를 만들었고, 리틀의 법칙으로 필요한 앱 인스턴스를 4대로 산정했으며, p99가 목표를 넘는 원인이 주문 조회의 N+1 쿼리임을 APM 트레이스로 특정해 수정 후 p99를 3.8초에서 0.9초로 낮췄습니다" 처럼 워크로드·근거·원인·결과가 한 줄로 이어지는 답이다.

자격증으로는 ISTQB CT-PT(Certified Tester Performance Testing)가 이 영역을 직접 다룬다. 성능 테스트의 기본 개념, 측정 지표와 결과 집계, 생명주기 안에서의 성능 활동, 도구 선정이 챕터로 나뉘어 있어 이 모듈의 범위와 상당 부분 겹친다. SRE·플랫폼 엔지니어링 직군으로 넘어갈 때도 USE·RED와 SLO 언어는 그대로 쓰인다. 성능 QA는 QA 직군 중에서 개발·인프라 조직과 가장 자주 같은 표를 보며 일하는 자리이고, 그래서 이 모듈의 어휘가 그대로 협업 능력으로 평가된다.