1. 정보시스템 성능 요구사항의 개요
정의: 시스템이 비즈니스 목적을 달성하기 위해 주어진 부하 조건 하에서 처리해야 하는 속도, 처리량, 자원 효율성 등에 대한 정량적 목표치.
중요성: 설계 단계에서 명확한 성능 요구사항이 정의되지 않을 경우, 운영 단계의 성능 저하로 인한 서비스 중단 및 튜닝 비용 급증의 원인이 됨.
2. 성능 요구사항 작성 시 고려해야 하는 주요 성능지표 및 내용
성능지표는 크게 사용자가 체감하는 응답성과 시스템이 감당하는 처리 능력, 그리고 자원 효율성으로 구분됩니다.
가. 사용자 체감 성능 지표 (User Perspective)
| 성능 지표 | 상세 내용 및 작성 기준 | 비고 |
| 응답 시간 (Response Time) | 사용자가 요청 후 첫 응답을 받을 때까지의 시간 (예: 평균 2초 이내) | 대기 시간 + 실행 시간 |
| 반환 시간 (Turnaround Time) | 업무 처리를 위해 시스템에 입력한 후 결과 출력이 완료될 때까지의 시간 | 배치 작업의 주요 지표 |
| 지연 시간 (Latency) | 데이터가 네트워크를 통해 전달되는 과정에서 발생하는 병목 시간 | 네트워크 인프라 성능 |
나. 시스템 처리 능력 지표 (System Perspective)
| 성능 지표 | 상세 내용 및 작성 기준 | 비고 |
| 처리량 (Throughput) | 단위 시간당 시스템이 처리하는 트랜잭션 또는 데이터의 양 (예: 500 TPS) | 시스템 용량 산정 근거 |
| 동시 사용자 (Concurrent User) | 특정 시점에 시스템에 접속하여 실제 트랜잭션을 발생시키는 사용자 수 | 부하 테스트의 기준 |
| 최대 부하 (Peak Load) | 특정 이벤트나 시간대에 집중되는 예상 최대 트랜잭션 양 | 확장성(Scalability) 지표 |
다. 자원 효율성 및 안정성 지표 (Resource Perspective)
| 성능 지표 | 상세 내용 및 작성 기준 | 비고 |
| 자원 이용률 (Utilization) | CPU, 메모리, 디스크 I/O 등 시스템 자원의 사용 비율 (예: 평균 70% 이하 유지) | 병목 현상(Bottleneck) 탐지 |
| 가용성 (Availability) | 전체 운영 시간 중 정상적인 서비스 제공 시간의 비율 (예: 99.99%) | 신뢰성 요구사항 연계 |
3. 성능 요구사항 정의 및 검증 프로세스
성능 요구사항은 분석 단계에서 정의되고 테스트 단계에서 정량적으로 검증되어야 합니다.
요구사항 분석: 과거 데이터 및 비즈니스 예측을 통한 목표 성능 정의(SLO/SLA).
성능 모델링: 아키텍처 설계 단계에서 예측 모델(Queuing Theory 등)을 통한 용량 산정.
성능 테스트 수행:
부하 테스트 (Load Test): 목표 부하에서의 정상 작동 확인.
스트레스 테스트 (Stress Test): 한계 상황에서의 시스템 거동 및 복구 능력 확인.
결과 분석 및 튜닝: 지표 미달 시 병목 지점(DB 인덱스, 로직, 네트워크 등) 개선.
4. 성능 요구사항 기술 시 기술사적 제언
구체적 수치 제시: "응답 속도가 빨라야 함"과 같은 모호한 표현 대신 "사용자 1,000명 동시 접속 시 평균 응답 시간 3초 이내"와 같은 **정량적 수치(SMART 원칙)**를 명시해야 함.
임계치(Threshold) 설정: 단순 평균치가 아닌 95th Percentile(상위 5% 응답 시간) 등을 도입하여 꼬리 지연(Tail Latency) 문제를 관리해야 함.
결언: 클라우드 네이티브 환경에서는 고정된 성능 지표보다 오토스케일링(Auto-scaling)과 연계된 탄력적 성능 요구사항 설계가 중요함. 기술사는 성능을 단순한 기능 지원이 아닌 기업의 경쟁력으로 인식하고 생애주기 전반의 성능 거버넌스를 확립해야 함.
댓글 없음:
댓글 쓰기