정보시스템 성능 요구사항의 주요 성능지표

1. 개요

가. 정의

정보시스템이 충족해야 할 성능 목표를 정량적·측정 가능하게 정의한 비기능 요구사항(NFR). 응답시간·처리량 등 수치 목표로 표현되며, 설계·구축·검수·SLA 계약의 객관적 기준이 된다.

성능 요구사항은 "무엇을 한다(기능)"가 아니라 "얼마나 빠르고 안정적으로 한다(품질)"를 규정한다. 기능 요구가 충족되어도 성능이 부실하면 시스템은 실패로 간주된다 — 예컨대 조회는 되지만 30초가 걸린다면 사용자는 그 시스템을 쓰지 않는다. 따라서 성능은 기능 못지않은 핵심 요구사항으로 다뤄야 한다.

나. 등장 배경 및 필요성

성능 요구가 "빠르게, 안정적으로" 같은 모호한 표현으로 남으면, 개발자·발주자·검수자가 서로 다른 기대를 갖게 되어 준공 단계에서 분쟁이 생긴다. "3초 이내"인지 "10초 이내"인지에 따라 필요한 서버 대수와 아키텍처가 완전히 달라지기 때문이다. 정량화된 성능지표는 (1) 용량산정과 아키텍처 설계의 근거가 되고, (2) 부하시험의 합격 기준을 제공하며, (3) SLA·과업 이행 여부를 객관적으로 판정하게 해준다. 이것이 성능 요구를 처음부터 수치로 못 박아야 하는 이유다.

2. 주요 성능지표

flowchart LR
  R[응답시간<br/>사용자 체감] --- T[처리량 TPS<br/>시스템 능력]
  T --- C[동시사용자<br/>부하 규모]
  C --- U[자원사용률<br/>여력·병목]
  U --- A[가용성<br/>신뢰성]

성능지표는 서로 연결되어 움직인다. 동시사용자가 늘면 처리량 요구가 커지고, 처리량이 한계에 다다르면 자원사용률이 포화해 응답시간이 급증한다. 따라서 지표들을 개별이 아니라 함께 정의해야 한다.

응답시간(Response Time): 사용자가 요청을 보낸 뒤 결과를 받기까지 걸리는 시간으로, 사용자 체감 성능을 직접 반영한다. 단순 평균만 쓰면 소수의 느린 요청이 가려지므로, "95퍼센타일 3초 이내"처럼 백분위(percentile) 기준으로 정의하는 것이 실무적이다.
처리량(Throughput/TPS): 단위 시간당 처리 건수(초당 트랜잭션)로, 시스템이 감당 가능한 일의 양(능력) 을 나타낸다. 응답시간이 개별 요청 관점이라면 처리량은 전체 처리 관점이다.
동시 사용자 수(Concurrency): 같은 시점에 접속·처리 중인 사용자 규모로, 부하의 크기를 정의한다. '접속자'와 '실제 요청을 발생시키는 활성 사용자'를 구분해야 과대·과소 산정을 피한다.
자원 사용률(Utilization): CPU·메모리·디스크 I/O·네트워크의 사용 비율로, 여력과 병목을 보여준다. 통상 CPU 70~80%를 임계치로 두어 피크에도 여유를 남긴다.
가용성(Availability): 가동률(예: 99.9% → 연간 약 8.8시간 다운 허용)로 표현되는 신뢰성 지표로, MTBF/MTTR 로 뒷받침된다.
확장성(Scalability): 부하가 늘 때 자원을 추가해 성능을 유지하는 능력으로, 스케일업/아웃 여부를 규정한다.

지표	관점	정의 예시
응답시간	사용자 체감	95%ile 3초 이내
처리량(TPS)	시스템 능력	500 TPS
동시 사용자	부하 규모	활성 1만 명
자원 사용률	여력·병목	피크 CPU 80% 이하
가용성	신뢰성	99.9%, MTTR 30분
확장성	성장 대응	오토스케일 대응

3. 작성 시 고려사항

성능 목표는 측정 조건과 함께 정의되어야 의미가 있다. "500 TPS"라는 숫자도 그것이 평시인지 피크인지, 데이터가 10만 건일 때인지 1억 건일 때인지에 따라 달성 난이도가 전혀 다르기 때문이다. 따라서 다음을 함께 명시한다.

측정 조건 명시: 피크/평시 구분, 데이터 적재량, 동시성 수준을 전제로 못 박는다.
정량·검증 가능성: 수치·단위·목표치와 측정 방법을 함께 규정해 "어떻게 확인할지"까지 합의한다.
피크 부하 기준: 연말정산·수강신청처럼 순간 폭주가 있는 시스템은 최대 부하 시점을 기준으로 산정해야 실제 장애를 막는다.
SLA 연계: 계약된 서비스 수준(예: 가용성 99.9%, 응답시간 목표)과 요구사항 수치를 일치시켜 책임 경계를 명확히 한다.

4. 검증 방법

정의한 목표는 반드시 시험으로 검증한다. 성능(부하) 테스트는 목표 부하에서 지표 충족 여부를, 스트레스 테스트는 한계점(임계 부하)을, 내구성(soak) 테스트는 장시간 운영 시 메모리 누수 등 열화를 확인한다. BMT(벤치마크 테스트) 는 후보 제품·아키텍처를 동일 조건에서 비교해 목표 달성 가능성을 사전 검증하며, 운영 단계에서는 APM 으로 실제 지표를 상시 모니터링해 SLA 위반을 조기에 포착한다.

방법	시점	확인 대상
성능·부하 테스트	구축·검수	목표 부하 지표 충족
스트레스 테스트	구축	한계점·장애 거동
BMT	도입 전	제품·아키텍처 비교
APM 모니터링	운영	상시 지표·SLA

5. 고려사항 및 시사점

설계와의 직결: 성능 요구는 용량산정·아키텍처(캐시·부하분산·DB 인덱싱)를 결정하므로 요구정의 초기에 확정해야 하며, 후반에 바꾸면 재설계 비용이 크다.
병목 분석과 튜닝: 목표 미달 시 무작정 서버를 늘리기보다 프로파일링으로 병목(느린 쿼리·락 경합)을 먼저 찾아, 스케일업/아웃과 코드·쿼리 튜닝을 조합한다.
트레이드오프: 성능·비용·복잡도는 상충한다. 과도한 성능 목표는 비용 낭비이므로 실제 업무량에 근거한 적정 수준을 정한다.
전망·연계: 클라우드 오토스케일과 관측성(Observability) 으로 성능 관리가 자동화·상시화되고 있으며, MSA 환경에서는 서비스별 지표와 분산 트레이싱이 성능 관리의 핵심이 된다.

한 줄 요약: 성능 요구사항은 응답시간·처리량(TPS)·동시사용자·자원사용률·가용성 등을 피크 부하·측정조건과 함께 정량·검증 가능하게 정의한 비기능 요구로, 용량산정·아키텍처의 근거가 되며 성능 테스트·BMT·APM으로 검증·관리한다.