부하 테스트 톺아보기

부하 테스트의 오해

이번 부하 테스트를 주제로 작성한 내용을 보완하고자 한다. 나는 지금까지 부하테스트 = 스트레스 테스트 로 자주 이야기 했다.

특히 이 문서의 타이틀인 “WebSocket Stress Test 이해하기 02”와 메인 타이틀인 “부하 테스트의 오해”만 봐도 잘못된 부분이 있다. 이 글을 읽고 난 후에는 무엇이 다르고 왜 잘못된 것인지 알게 된다.

이는 엄연히 다른 카테고리의 이야기이다. 결론부터 말하자면 부하테스트는 “성능 테스트”의 하위 개념이고 서로 목적 또한 다르다.

성능 테스트 (Performance Test)

부하 테스트를 말하기 위해 우리는 “성능 테스트”가 무엇인지 알고 넘어가야 한다.

성능 테스트는 시스템이 특적 조건에서 어떤 성능을 보이는지 검증하는 모든 테스트의 총칭이다.

단순히 “빠른가?”를 보는 테스트는 아니다.

보통은 성능 테스트를 통해 다음을 확인한다.

요청을 얼마나 많이 처리할 수 있는가
응답 시간은 어느 시점부터 느려지는가
리소스(CPU, 메모리, 네트워크)는 어떻게 사용되는가
장애 상황에서 시스템은 어떻게 무너지는가
트래픽 증가에 따라 수평 확장이 가능한가

즉, 성능 테스트는 시스템 한계, 안정성, 확장성까지 포함하는 매우 넓은 개념이다.

성능 테스트의 주요 종류

성능 테스트는 보통 다음과 같은 테스트를 포함한다.

부하 테스트 (Load Test) 예상되는 정상 트래픽을 시스템이 감당할 수 있는가?
- 목표: 정상적인 최대 트래픽에서의 안정성 확인
- 관점:
  - 평균 응답 시간
  - TPS / RPS
  - 에러율
  - 리소스 사용량
- 예:
  - 동적 10,000명일 때, 서버는 어떻게 반응하는가? 실서비스 기준선을 잡기 위한 테스트
스트레스 테스트 (Stress) 한계를 넘으면 시스템은 어떻게 무너지는가?
- 목표: 시스템 임계점(Breaking Point) 확인
- 관점:
  - 언제 타임아웃이 발생하는가
  - 어떤 컴포넌트부터 죽는가
  - 복구는 가능한가
- 예:
  - 동적 10,000명일 때, 서버는 어떻게 반응하는가? 장애 대응과 복구 전략을 위한 테스트
스파이크 테스트 (Spike) 트래픽이 순간적으로 튀면 버틸 수 있는가?
- 목표: 급격한 트래픽 변화 대응 능력 확인
- 관점:
  - 급증 시 에러 발생 여부
  - 오토스케일링 반응 속도
- 예:
  - 이벤트 시작과 동시에 트래픽이 10배 증가 이벤트성 트래픽, 알림 푸시, 배치 작업 이후에 중요
확장성 테스트 (Scalability) 서버를 늘리면 성능도 비례해서 늘어나는가?
- 목표: 수평/수직 확장의 효율성 검증
- 관점:
  - 서버 추가 대비 처리량 증가 비율
  - 병목 구간 식별
- 예:
  - 서버를 2대 → 4대로 늘리면 TPS도 2배가 되는가? MSA, 클라우드 환경에서 특히 중요
볼륨 테스트 (Volume) 데이터가 많아지면 시스템은 어떻게 되는가?
- 목표: 대용량 데이터 처리 안정성 확인
- 관점:
  - DB 성능 저하
  - 인덱스 영향
  - 쿼리 시간 변화
- 예:
  - 로그 데이터가 1억 건일 때도 정상 동작하는가? 장기 운영 서비스에서 반드시 필요

실제로 작업 하는 부하 테스트 이해하기

이번에 부하 테스트를 담당하면서 도대체 무얼 어떻게 해야 하는지 감을 잡지 못했다.

확실한 건 내가 무엇을 하는지 알아야 했기 때문에 부하 테스트가 무엇인지부터가 시작이라 생각했다.

지금 보면 내가 담당한 부하 테스트는 성능 테스트의 일부로, 부하와 스트레스에 대한 테스트를 담당하고 그 부하를 눈으로 확인할 수 있게 모니터링 환경을 구축하는 것이다.

즉, 고객사에서 생각하는 접속자와 그 접속자를 감당할 수 있는 소켓 서버인가를 검증해내야 한다.

단위 테스트처럼 에러를 만들어내는 단계와 달리 실제 서비스에 가깝게 시나리오를 만들고, 정상 상태에서의 지표를 수집하고, 모니터링과 함께 보는 환경을 결과물로 만들어야 한다.

부하 테스트는 말 그대로 “부하”에 대한 테스트이다.

때문에 소켓 서버의 부하라 함은 n명의 접속자가 보내는 정상 트래픽을 감당할 수 있는지에 대한 것이다.

n명의 접속자를 받아들이는가?
접속자를 받을 때 CPU와 메모리 중 어느 쪽에 부하가 많이 걸리는가?
n명 접속 후 얼마나 소켓을 안정적으로 유지하는가?
리소스의 사용량이 얼마나 되는가?

그 외 많은 것을 뽑아낼 수 있겠지만 대표적으로 생각나는 테스트 검증 항목은 위와 같다.

스트레스 테스트의 경우 다음과 같이 검증할 수 있다.

n명의 접속자 요청이 어느 정도 발생해야 서버가 죽는가?
어느 정도 트래픽이 발생해야 임계치가 되는가?
한계에 도달 할 때 어떤 대응을 할 수 있는가?
동시 접속자를 최대치로 설정했을 때 서버는 어떤 상태가 되는가?

이 두 가지 테스트를 모니터링과 연계해서 서버가 어떤 상태인지, 어떻게 변하는지 기록하고 각 상태를 어떻게 해석해야 하는지를 정리해 내는게 나의 담당 업무라 생각한다.

성능 테스트 중 두 가지 이외의 테스트는 기회가 되면 다뤄보려한다.

마무리

각 테스트는 성격이 다르지만 비슷한 점이 있다. 이 비슷한 점을 없애지는 못해도 목표와 추출해야 하는 요소와 이유를 명확히 한다면 각 테스트 환경을 구축하고 설정하는데 도움이 되지 않을까 생각한다.

중구난방으로 “대충 이런거겠지”해버리면 이후에 잘못 설계해서 중복된 값을 추출하거나 각 테스트 업무 자체가 모호해질 수 있기 때문이다.

📅 작성일: 2026-01-10
✍️ 작성자: 김경남