애플리케이션 성능 향상을 위한 실전 가이드
애플리케이션 성능은 사용자 경험과 전반적인 시스템 안정성에 직접적으로 영향을 미치는 중요한 측면 중 하나입니다. 이번 글에서는 애플리케이션 성능 저하의 주요 원인과 성능 분석, 품질 향상을 위한 다양한 방법에 대해 다뤄보겠습니다.
데이터베이스 성능 저하 원인
- 데이터베이스 락(DB Lock)
- 대량의 데이터 조회, 과도한 업데이트 시 발생하며, Lock 해제 시까지 대기하거나 타임아웃 된다.
- 불필요한 패치(DB Fetch)
- 결과 세트에서 커서를 옮기는 작업이 빈번할 때 발생한다.
- 연결 누수(Connection Leack)
- DB Connection 사용 후 반환하지 않을 경우 발생한다.
- Connection Pool 크기가 너무 작거나 크게 설정된 경우 발생한다.
내부 로직으로 인한 성능 저하 원인
- 파일 관련 오류
- 대량의 파일을 업로드하거나 다운로드할 때 발생한다.
- 코드 오류
- 코드 오류로 무한 반복 등이 수행될 때 발생한다.
외부 호출로 인한 성능 저하
- 외부서버와 인터페이스 시 장시간 수행되거나 타임아웃이 일어나 성능 저하가 발생
애플리케이션 성능 분석 지표
- 처리량(Throughput)
- 일정 시간 내에 애플리케이션이 처리하는 일의 양
- 응답 시간(Response Time)
- 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
- 경과 시간(Turn Around Time)
- 애플리케이션에 요청을 전달한 시간부터 처리가 완료될 때까지 걸린 시간
- 자원 사용률(Resource Usage)
- 애플리케이션이 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률
성능 분석 도구
- JMeter
- HTTP, FTP 등 다양한 프로토콜을 지원하는 부하 테스트 도구
- LoadUI
- OpenSTA
- HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구
모니터링 도구(APM)
- Scouter
- NMon
- Zabbix
- 웹기반 서버, 서비스, 애플리케이션 모니터링 도구
- Jeniffer
- 애플리케이션에서 서버로 유입되는 트랜잭션 수량, 처리시간, 응답시간, 자원 활용률 등을 모니터링
정형 기술 검토회의(FTR, Formal Technical Review)
- 개념
- 소프트웨어 엔지니어가 수행하는 소프트웨어 품질보증 활동
- 목적
- 산출물 요구사항 일치여부
- 소프트웨어가 미리 정한 기준에 따라 표현되었는가를 확인
- 검토지침
- 제작자가 아닌 제품의 검토에만 집중한다.
- 문제 영역을 명확히 표현한다.
- 제기된 모든 문제를 바로 해결하고자 하지 않는다.
- 검토자들은 사전에 작성한 메모들을 공유한다.
- 논쟁이나 반박을 제한한다.
- 의제를 정하고 그 범위를 유지한다.
- 참가자의 수를 제한하고, 사전 준비를 철저히 하도록 강요한다.
- 자원과 시간 일정을 할당한다.
- 모든 검토자에게 의미 있는 교육을 행한다.
- 검토의 과정과 결과를 재검토한다.
소스코드 품질 분석 (★)
- 동료 검토 (Peer Review)
- 2~3명이 진행하는 리뷰의 형태
- 작성자가 코드를 설명하고 이해 관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행하는 기법
- 워크스루(Walkthrough)
- 검토 자료를 회의 전에 배포해서 사전검토 한 후 짧은 시간 동안 회의를 진행하는 형태
- 리뷰를 통해 오류를 검출하고 문서화하는 기법
- 인스펙션(Inspection)
- 공식적 검사 회의
- 작업자 외 다른 전문가가 검사하는 가장 공식적인 리뷰 기법
- 계획 → 사전교육 → 준비 → 인스펙션 회의 → 수정 → 후속조치
소스코드 품질 분석 도구
- 개념
- 코딩을 하면서 발생하는 문제를 해결하기 위해 사용하는 도구
- 분석 도구 분류
- 정적 분석 도구
- 프로그램을 실행하지 않고 소프트웨어를 분석하는 방법
- 동적 분석 도구
- 프로그램을 실행하여 코드에 존재하는 메모리 누수나 스레드의 결함 등을 발견
분석 도구 종류
정적 분석 도구 |
도구명 |
설명 |
PMD |
주로 Java에서 사용하지만, Javascript, PLSQL, XML 등의 언어도 지원 |
checkstyle |
자바 코드에 대한 소스코드 표준 준수 검사, 다양한 개발 도구에 통합 가능 |
SonarQube |
중복코드, 복잡도, 코딩 설계 등을 분석하는 소스 분석 통합 플랫폼 |
ccpcheck |
C, C++코드에 대한 메모리 누수, 오버플로우 등 문제 분석 |
ccm |
다양한 언어의 코드 복잡도 분석 도구 |
cobertura |
자바 언어의 소스코드 복잡도 분석 및 테스트 커버리지 측정 |
동적 분석 도구 |
도구명 |
설명 |
Avalanche |
프로그램에 대한 결함 및 취약점 분석 |
Valgrind |
프로그램 내 존재하는 메모리 및 스레드 결함 등 분석 |
애플리케이션 성능 개선
- 코드 최적화
- 개념
- 알고리즘을 개선하거나 병목 현상을 제거
- 유지운영을 위해 소스코드를 다른 사람들이 읽기 쉽게 작성
- 코드 스멜(Code Smell)
- 컴퓨터 프로그래밍 코드에서 더 심각한 문제를 일으킬 가능성이 있는 프로그램 소스코드
코드 스멜의 종류
종류 |
해결책 |
중복된 코드 |
중복된 코드는 공통 함수를 만들어 제거한다. |
긴 메서드 |
하나의 메서드에 많은 기능이 담기지 않게 분리한다. |
큰 클래스 |
한 클래스는 하나의 책임만을 가져야 한다. |
클래스 동시 수정 |
의존 관계를 맺을 때 자주 변화하는 것보다 변화가 거의 없는 것에 의존해야 한다. |
코드 스멜 관련 용어
종류 |
해결책 |
스파게티 코드 (spaghetti code) |
소스코드가 복잡하게 얽힌 모습을 스파게티의 면발에 비유한 표현이다. |
외계인 코드 |
아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램 코드이다. |
- 리팩토링
- 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법
- 이미 작성한 소스코드에서 기능의 변경없이, 가독성과 유지보수성을 높이기 위해 내부 구조를 변경하는 것
- 클린코드
- 개념
- 의존성을 최소로 하고 사람이 이해할 수 있는 가독성, 목적성이 뛰어난 명확한 코드
클린코드 구현 방법
- 클래스명, 메서드명, 변수명은 명사를 사용하여 의미가 있는 이름을 짓는다.
- 불필요한 주석을 제거하고 의도를 명확히 기술한 주석을 작성
- 리팩토링을 통해 점진적인 개선을 통해 코드의 복잡도를 낮게 한다.
- 코드는 가급적 기능별로 간단하게 작성
- 코드의 중복을 최소화
- 누구든지 코드를 쉽게 읽을 수 있도록 작성
- 다른 모듈에 미치는 영향을 최소화하여 작성
- 프로그램 실행 시(런타임), 오류보다는 예외처리를 통해서 안정적인 종료를 유도한다.
클린코드 작성 원칙
- 가독성
- 단순성
- 의존성 배제
- 중복성 최소화
- 추상화
이렇게 다양한 영역에서 성능 저하를 방지하고 성능을 향상시키는 방법을 적용함으로써 안정적이고 효율적인 애플리케이션을 개발할 수 있습니다. 2024년에 정보처리기사를 따기 위해 노력하는 모두에게 행운을 빕니다!