소프트웨어 성능 테스트

왜 배우는가: 소프트웨어 성능 테스트는 시스템이 목표 사용자 수와 응답 시간을 만족하는지 확인하는 기본 활동이다. 시스템 대형화와 모바일화로 안정적 서비스의 중요성이 커졌고, 성능 저하 원인 분석과 용량 산정 문제가 기술사 시험에서 반복해서 출제된다.

출제 이력: 제117회 4교시 1번, 제95회 2교시 3번

1. 한 줄 정의와 핵심 키워드

소프트웨어 성능 테스트는 부하 상황에서 응답 시간·처리량·자원 사용률이 목표를 만족하는지 검증하는 비기능 테스트이다.

• 성능 테스트, 응답시간, 처리량, 동시 사용자, Think Time, 부하 테스트, 스트레스 테스트, 리틀의 법칙

2. 개념 풀이

쉽게 말하면 사용자가 많이 몰리거나 데이터가 커졌을 때 시스템이 느려지지 않고 제때 응답하는지 재는 시험이다. 기능이 맞는지는 기능 테스트가 보고, 얼마나 빠르고 많이 처리하는지는 성능 테스트가 본다.

정식으로는 정해진 부하 조건에서 시스템의 응답 시간, 처리량(Throughput), 자원 사용률(CPU·메모리·디스크)을 측정하고 목표 성능 요구사항과 비교하는 활동이다. 성능 목표는 보통 동시성 또는 처리량을 기준으로 세운다.

동시 사용자(Concurrent User)는 주어진 순간에 시스템을 동시에 사용하는 사용자 수의 최대치다. 로그인 절차로 최종 사용자를 식별하는 시스템에서 이 목표가 특히 의미가 있다. 최종 사용자 개념이 없는 시스템은 최대 처리량이나 트랜잭션 속도를 목표로 잡는 경우가 많다.

Think Time은 사용자가 한 요청의 응답을 받고 다음 요청을 보내기까지 쉬는 시간이다. 실제 사용 패턴을 흉내 내려면 Think Time을 넣어야 하며, 이를 빼면 부하가 실제보다 과대하게 나온다.

응답시간(Response Time)은 요청을 보낸 시점부터 응답이 도착할 때까지 걸린 시간이다. 처리량(Throughput)은 일정 시간 내 처리하는 트랜잭션 수이며, 보통 TPS 단위로 쓴다.

3. 등장 배경과 필요성

시스템 유지보수가 잦아지고 데이터가 계속 늘면 처음에는 문제없던 응답 속도가 점차 나빠진다. 사용자 수가 예상보다 몰리는 순간에 장애가 나면 서비스 중단과 신뢰도 하락으로 이어진다. 이런 위험을 배포 전에 수치로 확인하려고 성능 테스트가 필요해졌다.

대국민 서비스와 모바일 서비스는 접속 시점이 몰리는 특성이 있어 피크 부하 검증이 필수다. 용량을 미리 산정하지 않으면 서버 증설 시점과 규모를 판단할 근거가 없다. 성능 테스트 결과는 병목 구간을 찾아 코드와 구성을 고치는 근거가 된다.

동시 사용자 수와 응답 시간 목표를 정하면 필요한 스레드(Thread) 수를 계산할 수 있다. 예를 들어 Think Time과 목표 응답 시간이 주어진 시스템에서 동시 사용자 300명이면 활성 사용자 수를 응답시간과 Think Time의 관계로 계산해 스레드 수의 기준으로 삼는다(가상의 예). 이 계산은 부하 생성 도구의 설정값을 정하는 데 쓰인다.

성능 테스트 기준값은 조직마다 다르며 업계 공통의 통과 기준은 없다. 그래서 요구사항명세에 응답 시간과 처리량 목표를 명시하고 그 값에 맞춰 시험을 설계해야 한다.

4. 구성요소·원리·절차

성능테스트는 부하 발생기, 대상 시스템, 모니터링 계층으로 구성된다. 부하 발생기는 가상 사용자(VUser)를 만들어 요청을 보내고, 모니터링 계층은 응답시간·처리량·자원사용률을 수집한다.

원리는 동시 사용자 수와 응답시간, 대기시간의 관계에서 출발한다. 사용자 한 명이 한 주기 동안 요청하고 응답을 받은 뒤 생각하는 시간을 갖는다고 보면, 처리량은 동시 사용자 수를 주기로 나눈 값이 된다. 이 관계를 바탕으로 목표 TPS에서 필요한 Thread 수를 산정한다.

$TPS = \frac{Concurrent\ User}{Average\ Response\ Time + Average\ Think\ Time}$

• TPS: 초당 트랜잭션 수(건/s)
• Concurrent\ User: 동시 사용자 수(명)
• Average\ Response\ Time: 평균 응답시간(s)
• Average\ Think\ Time: 평균 생각 시간(s)

예를 들어 동시 사용자 300명인 경우 응답시간과 Think Time을 반영해 실제 활성 사용자 수를 계산하고, 이를 바탕으로 Thread 수를 산정한다. 이 값은 이상적 가정의 계산이므로 실제 시스템에서는 검증 테스트로 보정한다.

성능테스트 수행 절차는 다음과 같다.

• 성능 목표 설정: 동시 사용자 수, 목표 응답시간, 목표 TPS를 정한다.
• 시나리오 설계: 업무 흐름, Think Time, 데이터 조건을 정의한다.
• 테스트 환경 구축: 운영과 유사한 하드웨어·소프트웨어·데이터 규모를 맞춘다.
• 부하 생성과 실행: 점진적으로 부하를 올려 안정 상태에 도달시킨다.
• 모니터링과 측정: 응답시간, 처리량, 자원 사용률을 동시에 수집한다.
• 병목 분석과 개선: 원인을 찾아 코드, 설정, 용량을 조정한다.
• 재시험과 결과 보고: 목표 충족 여부를 같은 조건에서 다시 확인한다.

리틀의 법칙(Little's Law)은 시스템 내 평균 요청 수 L = \lambda W로 표현된다. 여기서 \lambda는 도착률, W는 평균 체류시간이다. 성능테스트에서는 이 관계로 동시 처리량과 응답시간 목표가 서로 맞는지 점검한다.

5. 관련 법령·기준·표준

소프트웨어 성능테스트에 직접 적용되는 법령 조문은 없다. 공공 정보화사업에서는 발주기관의 시험 지침과 계약 조건이 기준이 된다. 품질 특성의 기준은 국제표준 ISO/IEC 25010을 따른다. 이 표준은 ISO/IEC 9126을 대체하며 제품 품질 특성을 8개로 정의한다. 성능 효율성(Performance Efficiency)에는 시간 행태, 자원 활용, 용량 등 하위 특성이 포함된다.

위 표의 응답시간과 Think Time은 예시 항목이다. 실제 과제에서는 발주기관의 요구사항 값을 쓴다. ISO/IEC 25010의 개정 연도와 하위 특성 명칭은 해당 발행판을 기준으로 한다.

국내에서는 2025년 이후 AI 서비스 확산으로 GPU 메모리 용량이 처리량을 좌우한다는 시험 결과가 나왔다. 래블업 시험에서 특정 GPU가 동시 요청 증가 구간에서 처리량을 유지했다는 결과가 보도되었다. 이는 성능테스트 시나리오에 메모리 임계치를 포함해야 한다는 근거로 쓸 수 있다.

6. 유형과 비교

성능테스트는 목적과 측정 대상에 따라 여러 유형으로 나뉜다. 시험 문항은 대개 유형의 정의와 목적을 묻고, 여러 유형을 구분해 쓰게 한다. 아래 표는 부하 관점에서 주요 유형을 비교한 것이다.

위 표에서 부하테스트와 스트레스테스트는 부하의 크기 기준이 다르다. 부하테스트는 목표 수준 안에서 성능을 확인하고, 스트레스테스트는 목표를 넘어 한계를 찾는다.

성능테스트의 세부 유형은 시험 대상 구조에 따라서도 나뉜다. 아래 표는 Loop Back Test, Tier Test, Spike Test를 비교한 것이다.