작동하는 소프트웨어와 부하 상태에서 작동하는 소프트웨어는 같지 않습니다. 어떤 기능은 모든 기능 테스트를 통과하고 깔끔하게 배포되더라도 실제 트래픽이 몰리는 순간 무너질 수 있습니다. 성능 테스트는 이러한 간극을 메우는 규율입니다. 시스템이 유휴 상태일 때 올바르게 작동하는지뿐만 아니라, 바쁜 상태일 때 어떻게 작동하는지를 측정합니다.
이 가이드는 성능 테스트가 무엇인지, 주요 유형, 결과를 정의하는 측정항목, 그리고 현대적인 테스트 프로세스에 어떻게 적용되는지를 설명합니다.
성능 테스트란 무엇인가
성능 테스트는 정의된 워크로드 하에서 시스템의 속도, 안정성 및 확장성을 평가합니다. 이것은 "이 기능이 작동하는가?"라고 묻지 않습니다. 대신 "얼마나 빠른가, 얼마나 많은 것을 처리할 수 있는가, 그리고 한계에 도달하면 어떻게 되는가?"를 묻습니다.
이러한 구별은 중요합니다. 기능 테스트와 성능 테스트는 서로 다른 질문에 답하고 다른 버그를 찾아냅니다. 로그인 엔드포인트는 항상 올바른 토큰을 반환하더라도 부하 상태에서는 처리하는 데 4초가 걸릴 수 있습니다. 기능 테스트는 통과하지만, 사용자는 떠납니다. 성능 테스트는 바로 이 두 번째 문제를 밝혀냅니다.
성능 테스트의 결과는 단순한 합격 또는 불합격이 아닙니다. 이는 프로필입니다. 즉, 이 부하에서 시스템은 이만큼 빠르게 응답하고, 이만큼의 처리량을 유지하며, 이 지점을 넘어서면 이런 방식으로 실패한다는 것입니다. 이 프로필을 통해 팀은 용량을 계획하고, 현실적인 서비스 수준을 설정하며, 출시 전에 회귀를 감지할 수 있습니다.
주요 성능 테스트 유형
성능 테스트는 각기 다른 질문에 답하기 위해 다른 형태의 부하를 적용하는 다양한 테스트 유형으로 구성됩니다.
기준선 테스트 (Baseline testing)는 정상적이고 예상되는 부하 상태에서 시스템을 실행하고 그 결과를 기록합니다. 이 기준선은 이후 모든 테스트가 비교하는 참조점입니다. 기준선이 없으면 어떤 숫자가 좋은지, 나쁜지, 아니면 단순히 다른지 알 수 없습니다.
부하 테스트 (Load testing)는 예상되는 최대 트래픽을 적용하여 시스템이 잘 작동하는지 확인합니다. 응답 시간은 예산 범위 내에 유지되고, 오류는 거의 발생하지 않아야 합니다. 이는 시스템이 정상적인 바쁜 날에도 견딜 수 있는지 검증합니다.
스트레스 테스트 (Stress testing)는 시스템이 저하되거나 실패할 때까지 의도적으로 용량을 초과하는 부하를 가합니다. 목표는 한계점을 찾아내고 실패 모드를 관찰하는 것입니다. 느려지더라도 서비스를 계속 제공하는 점진적 성능 저하(graceful degradation)는 허용되지만, 데이터 손실이나 연쇄적인 오류는 허용되지 않습니다.
스파이크 테스트 (Spike testing)는 부하를 갑자기 급격하게 증가시켰다가 다시 낮춥니다. 이는 반짝 세일, 뉴스 이벤트 및 기타 갑작스러운 트래픽 급증을 모델링합니다. 안정적인 트래픽에 맞춰 조정된 시스템도 충분히 빠르게 확장할 수 없기 때문에 스파이크에 실패할 수 있습니다.
용량 테스트 (Capacity testing)는 시스템이 목표를 충족하면서 처리할 수 있는 최대 부하를 찾습니다. 그 결과는 구체적인 숫자이며, 용량 계획 및 자동 확장 임계값에 직접 사용됩니다.
소크 테스트 (Soak testing)는 안정성 또는 내구성 테스트라고도 불리며, 메모리 누수, 리소스 고갈, 점진적인 성능 저하와 같은 느린 장애를 드러내기 위해 장시간 동안 적당한 부하를 유지합니다. 이러한 문제들은 짧은 실행에서는 보이지 않으며 몇 시간이 지나야 나타납니다.
대부분의 팀은 기준선, 부하, 소크 테스트를 표준적으로 실행하며, 높거나 예측 불가능한 트래픽이 있는 시스템에는 스트레스 및 스파이크 테스트를 추가합니다.
결과를 정의하는 측정항목
성능 테스트는 테스트에서 얻는 측정항목만큼만 유용합니다.
응답 시간 (Response time)은 요청부터 응답까지 걸리는 시간입니다. 항상 분포로 읽으십시오. 평균은 오해의 소지가 있습니다. 건강해 보이는 평균이 10배 더 나쁜 99번째 백분위수를 숨길 수 있습니다. 느린 꼬리(slow tail)는 실제 사용자들이 알아채고 불평하는 부분입니다.
처리량 (Throughput)은 단위 시간당 완료되는 작업량이며, 주로 초당 요청 수로 표현됩니다. 총 요청 수를 테스트 지속 시간으로 나누어 계산하며, 시스템의 실제 용량을 나타냅니다.
동시성 (Concurrency)은 동시 사용자 또는 연결의 수입니다. 시스템 용량은 응답 시간이 허용 가능한 임계값을 넘어서는 동시성 수준으로 자주 명시됩니다.
오류율 (Error rate)은 부하 상태에서 실패하는 요청의 비율입니다. 빠르게 유지되지만 높은 동시성에서 요청 실패가 시작되는 시스템은 통과한 것이 아닙니다. 신뢰성 없는 속도는 성능이 아닙니다.
CPU 및 메모리 사용률 (CPU and memory utilization)은 다른 수치들이 왜 변하는지 설명해줍니다. CPU가 100%로 고정된 상태에서 대기 시간이 증가하면 시스템은 계산 바운드(compute-bound) 상태입니다. CPU가 유휴 상태인데도 대기 시간이 증가하면 병목 현상이 하류(downstream)에 있는 것이며, 일반적으로 데이터베이스, 잠금 또는 외부 종속성 때문입니다.
완전한 결과는 마치 문장처럼 읽힙니다. 즉, 이 동시성에서 처리량은 여기서 최고조에 달했고, 95번째 백분위수 응답 시간은 이랬고, 오류율은 저랬으며, 서버는 이 리소스에 바운드되어 있었다는 식입니다.
프로세스에서 성능 테스트의 위치
성능 테스트는 과거에는 프로젝트 막바지에 한 번만 실행되는 단일 관문이었고, 전문가 팀에 의해 출시 전에 수행되었습니다. 이러한 모델은 지속적으로 배포되는 시스템에는 적합하지 않습니다. 거의 모든 변경 사항으로 인해 성능이 저하되기 때문입니다. 새로운 쿼리, 추가된 통합, 인덱싱되지 않은 열 등 각각은 기능 테스트로는 감지할 수 없는 지연 시간을 조용히 추가합니다.
더 나은 모델은 성능을 정확성처럼 다룹니다. 즉, 예산을 가지고 지속적으로 확인하는 것입니다. 중요 경로에 대한 응답 시간 및 오류율 예산을 정의하십시오. CI/CD에서 가벼운 부하 테스트를 실행하여 풀 리퀘스트 단계에서 성능 저하가 발생하면 빌드가 실패하도록 하십시오. 더 긴 실행 시간이 허용되는 예정된 출시 전 테스트를 위해 집중적인 스트레스 및 소크 테스트 실행을 남겨두십시오.
대부분의 시스템에서 성능 테스트를 할 때 가장 가치 있는 곳은 API 계층입니다. API는 핵심 로직을 담고 있으며, 빠르고 확정적으로 호출될 수 있고, 불안정한 UI와 씨름할 필요가 없습니다. 부하 상태에서 API를 테스트하면 저렴하게 신뢰할 수 있는 수치를 얻을 수 있습니다. API 성능 테스트는 이 집중적인 접근 방식을 자세히 다룹니다. 기능 API 테스트와 함께 성능 테스트를 유지하면 모든 변경 사항이 정확성과 속도 모두에 대해 한 번에 검사됩니다.
흔히 저지르는 성능 테스트 실수
성능 테스트는 확신을 주지만 틀린 답을 내는 방식으로 쉽게 수행될 수 있습니다. 몇 가지 실수는 계속해서 반복됩니다.
비현실적인 인프라에 대한 테스트. 개발자 노트북에서 실행하는 부하 테스트나, 프로덕션 리소스의 일부만 갖춘 스테이징 환경에 대한 테스트는 아무 의미 없는 숫자를 생성합니다. 감당할 수 있는 한 프로덕션과 가장 유사한 인프라에서 테스트하십시오.
웜업 효과 무시. 많은 시스템은 캐시가 채워지고 연결 풀이 열리는 실행 초기 몇 초 동안은 느립니다. 콜드 스타트와 안정 상태를 함께 측정하면 오해의 소지가 있는 평균이 나옵니다. 웜업 구간을 제외하거나 별도로 보고하십시오.
백분위수 대신 평균 읽기. 이 실수는 너무 흔해서 다시 강조할 가치가 있습니다. 200ms의 평균 응답 시간은 3초의 99번째 백분위수를 숨길 수 있습니다. 평균은 아무도 실제로 하지 않는 요청을 묘사하지만, 백분위수는 실제 사용자를 묘사합니다.
비현실적인 데이터 사용. 모든 요청을 동일한 사용자 ID 또는 동일한 제품으로 테스트하면 데이터베이스가 모든 것을 캐시에서 제공한다는 의미입니다. 실제 트래픽은 데이터 세트 전반에 걸쳐 분산되어 콜드 로우(cold rows) 및 캐시 미스(cache misses)를 발생시킵니다. 이에 맞게 테스트 데이터를 다양하게 변경하십시오.
단일 엔드포인트만 개별적으로 테스트. 실제 사용자들은 로그인, 탐색, 검색, 결제와 같은 워크플로를 통해 이동합니다. 단일 엔드포인트에만 집중하는 것은 여러 엔드포인트가 동일한 데이터베이스 및 연결 풀을 두고 경쟁할 때 발생하는 경합을 놓치게 됩니다. 개별 호출뿐만 아니라 현실적인 다단계 시나리오를 테스트하십시오.
테스트를 일회성으로 취급. 단 한 번의 출시 전 성능 테스트는 다음 기능이 배포되는 순간 효력을 잃습니다. 성능은 지속적으로 저하되므로, 테스트도 지속적으로 실행되어야 합니다.
이 여섯 가지 실수를 피하는 것이 의사결정에 도움이 되는 성능 테스트와 위안은 주지만 무의미한 녹색 체크 표시를 생성하는 성능 테스트를 구분하는 가장 중요한 요소입니다.
Apidog로 성능 테스트 실행하기
Apidog는 API 설계 및 기능 테스트에 사용되는 동일한 작업 공간에 부하 테스트를 통합하여, 성능 검사를 위해 별도의 도구나 API 정의 사본이 필요하지 않습니다.
엔드포인트 또는 다단계 테스트 시나리오를 가져와 기능적으로 통과하는지 확인한 다음, 구성된 가상 사용자 수로 정해진 시간 동안 실행합니다. Apidog는 부하를 점진적으로 증가시키고 응답 시간 백분위수, 처리량 및 오류율을 실시간으로 보고하여, 성능이 저하되기 시작하는 정확한 동시성 수준을 확인할 수 있습니다. 단일 머신을 초과하는 부하의 경우, 시나리오가 동일한 정의를 유지하면서 JMeter로 내보내집니다.
동일한 테스트 시나리오가 기능 및 성능 실행 모두에 사용되므로, 두 개 대신 하나의 아티팩트만 유지 관리하면 됩니다. 이미 가지고 있는 엔드포인트의 프로필을 작성하려면 Apidog를 다운로드하십시오.
자주 묻는 질문
성능 테스트와 기능 테스트의 차이점은 무엇인가요? 기능 테스트는 소프트웨어가 올바른 결과를 생성하는지 확인합니다. 성능 테스트는 부하 상태에서 얼마나 빠르고 안정적으로 그렇게 하는지 확인합니다. 둘 다 필요하며, 서로를 대체할 수 없습니다.
어떤 성능 테스트 유형을 먼저 실행해야 하나요? 기준선 테스트를 먼저 하고 그 다음 부하 테스트를 합니다. 기준선은 정상적인 조건에서의 참조점을 제공하며, 부하 테스트는 시스템이 예상되는 최대 트래픽을 견딜 수 있는지 확인합니다. 그 다음 스트레스, 스파이크, 소크 테스트를 추가하십시오.
평균 응답 시간 대신 백분위수를 사용하는 이유는 무엇인가요? 평균은 중앙으로 치우쳐 느린 꼬리(slow tail)를 숨깁니다. 95번째 및 99번째 백분위수는 가장 운이 없는 요청들이 겪는 것을 보여주며, 이 꼬리(tail)가 사용자들이 느끼는 부분입니다.
성능 테스트를 자동화할 수 있나요? 네, 가능합니다. 가벼운 부하 테스트는 모든 변경 사항에 대해 CI에서 잘 실행되며, 정의된 예산에 따라 성능 저하 발생 시 빌드를 실패시킵니다. 더 무거운 스트레스 및 소크 테스트는 모든 커밋마다 실행되기보다는 일반적으로 예정에 따라 실행됩니다.
개발 주기 중 언제 성능 테스트를 시작해야 하나요? 대부분의 팀이 생각하는 것보다 더 일찍 시작해야 합니다. 실제 인프라 없이는 최종 지연 시간 수치를 얻을 수 없지만, 설계 단계에서 예산을 설정하고 테스트 시나리오를 작성할 수 있습니다. 엔드포인트가 기능적으로 작동하는 즉시 기본적인 부하 테스트를 실행하면 문제가 저렴하게 수정될 수 있을 때 이를 발견할 수 있습니다.
성능 테스트는 누가 담당하나요? 현대적인 팀에서는 책임이 공유됩니다. 개발자는 자신의 변경 사항에 대해 가벼운 부하 검사를 실행하고, QA는 더 광범위한 테스트 시나리오와 예산을 담당하며, 운영 또는 SRE는 프로덕션과 유사한 인프라와 서버 측 측정항목을 제공합니다. 이를 한 전문가의 업무로만 취급하는 것이 성능 문제가 프로덕션으로 이어지는 방식입니다.
성능 테스트는 얼마나 오래 실행해야 하나요? 웜업 구간을 지나 안정 상태에 도달할 수 있을 만큼 충분히 오래 실행해야 합니다. 부하 테스트의 경우 일반적으로 몇 분입니다. 소크 테스트는 짧은 실행으로는 놓칠 수 있는 느린 성능 저하를 노출하는 것이 전체 목적이므로, 설계상 몇 시간 또는 며칠 동안 실행됩니다.