부하 테스트, 접속자 수보다 시나리오가 중요합니다

실제 사용자 행동을 요청 묶음으로 만듭니다

부하 테스트는 같은 URL을 반복 호출하는 것보다 실제 사용자 행동을 재현해야 의미가 있습니다. 목록 조회, 상세 보기, 검색, 로그인과 쓰기 작업은 서버에 주는 부담이 다릅니다. 1단계로 중요한 사용자 흐름과 각 흐름의 비율을 정합니다. 사용자가 다음 행동까지 기다리는 시간과 요청 데이터의 다양성도 반영합니다. AWS의 공식 부하 테스트 원칙은 운영 부하를 감당하는지와 성능 병목을 검증하는 목적을 설명합니다. 결과를 접속자 수 하나로 발표하면 어떤 행동을 가정했는지 사라집니다. 최종 보고에는 시나리오, 요청 데이터, 실행 위치, 캐시 상태와 테스트 환경을 반드시 함께 적어야 다른 조건과 혼동하지 않습니다.

중단 기준과 시험 데이터의 경계를 정합니다

2단계에서는 실행해도 되는 환경과 영향 범위를 정합니다. 운영 서비스를 시험한다면 고객에게 영향을 줄 수 있으므로 승인된 시간과 중단 조건, 연락 담당자를 마련합니다. 외부 결제나 메일 발송, 유료 API는 시험 모드나 대체 경로를 사용합니다. 권한 없는 외부 서비스에 대량 요청을 보내는 방식으로 테스트하지 않습니다. 부하 생성기 자체의 CPU와 네트워크가 먼저 포화될 수도 있으므로 생성기 지표도 관찰합니다. 오류율, 응답 지연, 데이터 손상, 외부 의존성의 이상 중 어떤 조건에서 즉시 중단할지 미리 적습니다. 테스트가 계속 돌아간다는 사실보다 안전하게 멈추고 원인을 보존할 수 있는 구성이 중요합니다.

평균 처리량은 시나리오 가정에서 계산합니다

가정으로 가상 사용자 100명이 각자 10초에 한 번 요청을 보낸다면 단순 평균은 100÷10=초당 10요청입니다. 사용자마다 요청 3개를 순차 수행하는 행동을 같은 10초마다 반복한다면 요청 수 기준 평균은 초당 30요청이 됩니다. 이는 실제 동시 접속 수와 서버 수용량의 측정값이 아닙니다. 응답 지연이 늘면 반복 주기가 달라질 수 있고, 한 요청에서 내부 작업이 여러 개 발생할 수도 있습니다. 이 예시의 최종 결과는 사용자 수만으로 서버 부하를 결정할 수 없다는 점입니다. 독자는 행동당 요청 수와 대기 시간을 시나리오에 적고 실제 발생한 초당 요청, 오류, 응답 분포를 함께 기록합니다.

단계별 증가와 회복 과정을 모두 관찰합니다

3단계는 낮은 부하부터 점진적으로 늘리며 병목이 나타나는 지점을 찾는 것입니다. 짧은 급증과 오랜 지속 부하는 서로 다른 문제를 드러낼 수 있습니다. 연결 수, 메모리, 데이터베이스 대기와 큐 길이가 어떻게 변하는지 기록하고 부하를 낮춘 뒤 정상으로 돌아오는지도 봅니다. 테스트가 끝난 순간 지표가 괜찮아도 데이터 중복이나 지연 작업이 남아 있을 수 있으므로 결과 데이터를 검증합니다. 개선 후에는 같은 시나리오와 조건으로 다시 실행해야 비교가 가능합니다. 최종 결론은 최대 수용 사용자라는 단정 대신 어떤 요청 구성과 환경에서 어떤 응답·오류 수준을 관찰했는지로 적습니다. 필요한 여유 용량은 예상 피크와 장애 시 남는 자원까지 고려해 결정합니다.

성능 최적화 실행 전 점검표

• 실제 행동과 요청 비율을 정의했다
• 외부 연동의 시험 경로를 준비했다
• 중단 기준과 담당자를 정했다
• 부하 감소 후 회복과 데이터를 검증했다