개념
"성능 테스트"는 하나가 아니다
"성능 테스트 좀 해주세요"라는 요청은 사실 애매하다. 정확히 무엇을 확인하고 싶은지에 따라 서로 다른 방식의 테스트가 필요하다.
부하 테스트(Load Testing)
예상되는 정상 범위의 트래픽에서 시스템이 잘 견디는지 확인한다.
질문: "평소 예상하는 동시 사용자 수(예: 1,000명)에서 응답 시간이 괜찮은가?"이건 모듈 4(레슨 4)에서 배운 일정·용량 산정과 비슷한 개념이다 — "이 정도 규모를 감당할 수 있는가"를 실제로 확인하는 것이다.
스트레스 테스트(Stress Testing)
시스템이 감당할 수 있는 한계가 어디까지인지를 찾기 위해, 점점 부하를 늘려가며 어느 지점에서 무너지는지 확인한다.
질문: "동시 사용자가 10,000명, 20,000명으로 계속 늘어나면 언제 시스템이 죽는가?"모듈 5(레슨 6)에서 배운 "한계까지 밀어붙이기"라는 탐색적 접근의 정신이, 여기서는 부하라는 축에 체계적으로 적용된 것이다. 한계를 알아야, "우리 시스템은 최대 이 정도까지는 버틴다"는 근거를 갖고 용량 계획을 세울 수 있다.
스파이크 테스트(Spike Testing)
트래픽이 갑자기 폭증했다가 갑자기 줄어드는 상황을 재현한다.
질문: "평소 1,000명이던 사용자가 이벤트 시작 순간 갑자기 20,000명으로
폭증하면 시스템이 버티는가? 폭증이 끝난 뒤 정상으로 잘 돌아오는가?"블랙프라이데이 세일, 티켓 예매 오픈처럼 예측 가능한 특정 순간에 몰리는 트래픽을 다루는 서비스에서 특히 중요하다 — 부하가 서서히 늘어나는 부하 테스트와 달리, 급격한 변화 자체가 시스템에 주는 충격을 확인한다.
내구성 테스트(Soak Testing / Endurance Testing)
오랜 시간 동안 지속적인 부하를 줘서, 짧은 테스트에서는 안 보이는 문제를 찾는다.
질문: "평소 수준의 부하를 24시간, 며칠간 계속 줬을 때도 문제없이 도는가?"모듈 9(레슨 4)에서 배운 메모리 누수 같은 문제는 짧은 테스트에서는 드러나지 않고, 시간이 누적되어야 나타난다 — 내구성 테스트가 이런 문제를 잡는 방법이다.
네 가지 테스트 비교
| 테스트 | 확인하는 것 | 부하 패턴 |
|---|---|---|
| 부하 | 예상 범위에서 괜찮은가 | 정상 수준 유지 |
| 스트레스 | 한계가 어디인가 | 점점 증가시킴 |
| 스파이크 | 급격한 변화에 버티는가 | 순간적으로 폭증 |
| 내구성 | 오래 견디는가 | 정상 수준을 장시간 유지 |
실무에서 왜 필요한가
"성능 테스트 했어요"라는 말만으로는 무엇을 확인했는지 알 수 없다 — "평소 트래픽에서는 확인했지만, 이벤트 시작 순간의 폭증 시나리오는 확인 안 됐다"처럼 구체적으로 구분해서 말할 수 있어야 실제로 무엇이 검증됐고 무엇이 안 됐는지 팀이 정확히 판단할 수 있다. 이건 모듈 6(레슨 5)에서 배운 정직한 지표 보고 원칙과 같은 맥락이다.