실제 트래픽 모양에서 성능 테스트를 설계하라

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

성능 테스트에서 먼저 익혀야 할 것은 JMeter나 nGrinder 사용법이 아니다. 테스트 대상의 성격을 이해하는 일이다. 도구는 부하를 만들지만 어떤 부하가 의미 있는지는 트래픽 모델이 정한다.

시나리오를 작성하기 전에 예상 유입을 뽑는다. 회원 수, 평소 접속량, 새 기능이 만드는 행동을 재료로 삼는다. 추정치는 완벽할 수 없다. 그래도 팀이 목표를 정하고 무엇보다 트래픽의 모양을 설명하게 해준다.

순간 스파이크와 장시간 부하는 다른 실패를 찾는다

정해진 시각에 열리는 이벤트는 요청이 한꺼번에 몰릴 수 있다. 이때는 실제처럼 급격한 부하를 줘야 한다. 같은 처리량에 천천히 도달하는 테스트는 이벤트에서 생길 실패를 놓칠 수 있다.

푸시 알림 캠페인은 모양이 다르다. 유입을 분산하려고 알림 자체를 여러 묶음으로 나눠 보낼 수 있다. 그러면 모든 사용자가 같은 초에 서비스에 들어온다고 가정하기보다 그 발송 정책을 따라 테스트하는 편이 낫다.

반복적인 파동이나 지속 부하가 중요한 서비스도 있다. 이 경우 짧은 피크 테스트에서 보이지 않는 메모리나 안정성 문제를 장시간 테스트로 살필 수 있다. 이를 위해 퇴근 전에 걸어 두고 다음 날 확인하는 테스트를 사용한 경험도 있다. 시간 자체가 규칙인 것은 아니다. 발견하려는 실패에 따라 정한다.

순서는 다음과 같다.

1. 어느 정도 요청이 들어올지 추정한다.
2. 한 번에, 단계적으로, 반복해서, 계속 들어오는지 설명한다.
3. 어떤 실패를 확인하려는지 정한다.
4. 그 설명을 따라 부하 모양을 만든다.

무한 트래픽 대신 의도적인 여유를 둔다

예상치와 정확히 같은 수준만 검증하면 다음 증가가 곧바로 엔지니어링 여유를 소진한다. 실무에서는 예상 부하의 약 세 배를 작업용 여유로 잡아 본 적이 있다. 이 숫자는 보편 기준이 아니라 한 가지 실용적 예시다. 중요한 것은 작은 증가마다 시스템을 다시 만들지 않도록 여유 폭을 명시적으로 정하는 것이다.

예상값도 관찰 가능한 근거에서 가져와야 한다. 리뷰 화면에 리액션 버튼을 추가한다면 기존 리뷰 조회와 행동량을 바탕으로 새 엔드포인트 호출 수를 대략 계산할 수 있다. 피크, 평상시, 지속 구간의 목표는 서로 다를 수 있다.

모든 팀에 같은 의식을 강요하지 않는다

트래픽 장애를 반복해서 겪은 팀은 성능 테스트를 자연스럽게 일상으로 만든다. 소수 운영자만 쓰는 어드민 기능은 같은 수준의 절차가 필요하지 않을 수 있다. 모든 기능에 같은 부하 테스트를 요구하면 위험을 줄이지 못한 채 작업만 늘어날 수 있다.

조직 차원의 일관성이 필요하다면 큰 기능을 배포할 때 예상 규모와 유입 패턴을 먼저 기록하게 할 수 있다. 그리고 팀이 정한 기준을 넘는 경우에만 운영 배포 전 성능 테스트 기록을 요구한다. 기준은 해당 시스템의 위험에서 정해야지 다른 팀의 예시 처리량을 그대로 가져오면 안 된다.

이 방식은 결정의 근거를 남긴다. 위험이 낮은 기능은 왜 테스트가 필요 없는지 설명할 수 있다. 위험이 큰 기능은 예상 부하를 다루지 않은 채 테스트를 건너뛸 수 없다.

성능 테스트는 도구가 아니라 서비스를 모델링할 때 쓸모가 생긴다. 사용자와 이벤트, 유입 패턴, 허용할 수 없는 실패를 먼저 안 뒤에야 얼마나 세게, 얼마나 오래 부하를 줄지 정할 수 있다.