19. 애플리케이션 성능 개선 - 1과목 소프트웨어 구축
이번 파트에서는 클린코드와 리팩토링 등이 주요한 용어입니다. 글의 순서를 보면 왜 애플리케이션의 성능이 떨어지는 지 확인하고 검토하고 찾은 다음 개선하기 위한 방식을 찾는 것입니다. 개선하는 것을 리팩토링을 하는 것이며, 리팩토링할 때 클린 코드를 써야하는 것입니다.
목차
애플리케이션 성능 저하의 원인
애플리케이션 성능 저하 문제들은 주로 애플리케이션의 내부 로직이나 데이터베이스 쿼리의 최적화 부족으로 발생합니다.
성능 문제를 해결하기 위해서는 데이터베이스 쿼리의 튜닝과 인덱스의 최적화, 불필요한 쿼리나 데이터 조회를 줄이는 것, 그리고 데이터베이스 연결을 올바르게 관리하여 연결 누수를 방지하는 것이 필요합니다.
또한 캐싱 기법을 사용하여 반복적인 데이터 조회를 최소화하고, 트랜잭션 처리를 최적화하여 데이터베이스 락이 발생하지 않도록 해야 합니다.
데이터베이스 관련 성능 저하
데이터베이스 락(DB Lock)
데이터베이스 락은 한 프로세스나 트랜잭션이 데이터를 접근 중일 때, 다른 프로세스나 트랜잭션이 해당 데이터를 변경하거나 접근하는 것을 막는 메커니즘입니다. 데이터베이스 락은 데이터의 일관성을 유지하기 위해 사용되지만, 대량의 데이터 조회나 과도한 업데이트가 발생할 경우 락이 발생하여 성능에 영향을 줄 수 있습니다.
불필요한 패치(DB Fetch)
불필요한 패치는 애플리케이션이 데이터베이스로부터 필요 이상으로 많은 데이터를 조회하는 것을 의미합니다. 이는 데이터베이스와의 네트워크 트래픽을 증가시키고, 애플리케이션에서 불필요한 작업을 수행하게 됨으로써 성능을 저하시킬 수 있습니다.
연결 누수(Connection Leak)
연결 누수는 데이터베이스와의 연결을 올바르게 종료하지 않아 발생하는 문제입니다. 데이터베이스와의 연결은 유한한 자원이기 때문에 연결을 종료하지 않으면 시스템의 리소스가 고갈되어 다른 요청을 처리할 수 없게 됩니다. 이는 시스템의 성능을 저하시키고, 시스템이 정상적으로 동작하지 않을 수 있습니다.
파일 관련 오류 (출제빈도 낮음)
파일 관련 오류는 주로 파일을 열거나 읽고 쓸 때 발생하는 문제를 가리킵니다. 이는 파일에 액세스하거나 조작하는 동안 발생할 수 있는 다양한 문제를 포함합니다.
예를 들어, 파일이 존재하지 않거나 액세스 권한이 없는 경우, 파일이 잘못된 형식으로 저장되어 있는 경우, 파일이 잘못된 위치에 저장되어 있는 경우 등이 있습니다.
이러한 오류는 주로 파일 시스템과의 상호 작용에서 발생하며, 적절한 예외 처리를 통해 관리할 수 있습니다.
외부 호출로 인한 성능 저하(출제빈도 낮음)
외부 호출로 인한 성능 저하는 주로 네트워크 호출, 파일 시스템 액세스 또는 데이터베이스 액세스와 같은 외부 리소스를 사용할 때 발생할 수 있습니다.
외부 호출은 주로 I/O 작업을 수행하거나 다른 서비스와의 통신을 위해 사용됩니다. 이러한 호출은 시스템의 성능을 저하시킬 수 있으며, 특히 호출이 블로킹되는 경우에는 더욱 그러합니다.
이러한 성능 문제를 해결하기 위해서는 비동기적인 호출을 사용하거나 호출을 최적화하여 대기 시간을 최소화하는 것이 필요합니다. 또한 캐싱과 같은 기술을 사용하여 호출의 빈도를 줄이고 성능을 향상시킬 수 있습니다.
애플리케이션 성능 분석 지표
지표 | 설명 |
처리량 thoughput |
애플리케이션이 단위 시간당 처리하는 작업의 양 또는 트랜잭션 수. 이는 시스템이 얼마나 많은 작업을 처리할 수 있는지를 나타냅니다. |
응답시간 response time |
요청을 받은 후 응답을 완료하는 데 걸리는 시간. 이는 사용자가 요청을 보낸 후에 애플리케이션이 응답을 받는 데까지 걸리는 시간을 측정합니다. |
경과시간 turn around time |
특정 작업이나 프로세스가 완료되기까지 소요된 총 시간. 이는 애플리케이션 내에서 특정 작업의 처리에 걸리는 전체 시간을 측정합니다. |
자원 사용률 resource usage |
CPU, 메모리, 디스크, 네트워크 등의 자원을 얼마나 효율적으로 사용하는지를 나타내는 지표. 이는 시스템의 성능과 안정성을 평가하는 데 중요한 역할을 합니다. |
성능 분석 도구
- JMeter
- Apache JMeter는 성능 테스트를 위한 오픈 소스 도구로, 다양한 프로토콜을 지원하며 웹 애플리케이션, 웹 서비스, FTP 서버 등의 성능을 테스트할 수 있습니다.
- LoadUI
- LoadUI는 웹 서비스 및 API의 성능을 테스트하기 위한 도구로, 사용자 친화적인 인터페이스와 강력한 테스트 시나리오 작성 기능을 제공합니다.
- OpenSTA
- OpenSTA는 웹 애플리케이션의 성능을 테스트하기 위한 무료 오픈 소스 도구로, 다양한 프로토콜과 플러그인을 지원하여 다양한 시나리오를 테스트할 수 있습니다.
모니터링 도구
- Scouter
- Scouter는 분산 시스템의 성능 모니터링 및 분석을 위한 오픈 소스 도구로, 실시간으로 시스템의 성능 지표를 수집하고 시각화합니다.
- NMon
- NMon은 리눅스 및 AIX 시스템의 성능을 모니터링하는 도구로, 시스템의 CPU, 메모리, 네트워크, 디스크 등의 성능 지표를 실시간으로 확인할 수 있습니다.
- Zabbix
- Zabbix는 네트워크 및 서버 등의 IT 인프라를 모니터링하기 위한 오픈 소스 도구로, 다양한 유형의 장치와 애플리케이션을 모니터링하고 경고를 설정할 수 있습니다.
- Jeniffer
- Jeniffer는 네트워크 트래픽 분석 및 모니터링을 위한 도구로, 실시간으로 네트워크 트래픽을 캡처하고 분석하여 보안 문제나 성능 저하를 식별합니다.
정형 기술 검토 회의
출제 빈도가 매우 낮아서 이런 개념이 있다는 것만 알고 지나가시면 됩니다.
FTR(Formal Technical Review)의 개념
- FTR은 소프트웨어 공학에서 사용되는 형식화된 기술적 검토 프로세스입니다.
- 개발된 소프트웨어나 문서 등의 작업물을 전문가 그룹이 형식적으로 검토하는 과정을 의미합니다.
- FTR은 오류를 발견하고 수정하는 데 중점을 두며, 품질 향상과 신뢰성 향상을 목표로 합니다.
FTR의 목적
- 소프트웨어의 오류를 발견하고 수정하여 품질을 향상시키는 것을 주요 목적으로 합니다.
- 소프트웨어의 요구 사항과 설계 명세에 대한 일치 여부를 확인하여 소프트웨어 제품의 품질을 보장합니다.
- 개발 프로세스의 초기 단계에서 오류를 식별하여 수정하므로 후속 작업의 비용을 절감하고 개발 일정을 준수할 수 있습니다.
- 팀 간 의사 소통을 촉진하고 지식 공유를 촉진하여 개발자 간의 학습과 개선을 도모합니다.
검토지침
- 제작자가 아닌 제품의 검토에만 집중한다
- 명확한 목표와 범위를 설정하고 검토를 진행합니다.
- 제기된 모든 문제를 바로 해결하고자 하지 않는다.
- 검토 대상에 대한 사전 준비를 완료하고 관련 문서와 자료를 제공합니다.
- 검토 참가자들을 선정하고 검토 진행 방법과 일정을 미리 공지합니다.
- 검토 시 사용할 기준과 가이드라인을 정의하고 검토 과정을 체계적으로 수행합니다.
- 발견된 오류나 개선 사항을 문서화하고 추적하여 수정 및 개선 사항에 대한 통합 관리를 진행합니다.
소스코드 품질 분석
동료검토 (Peer Review)
- 동료검토는 소프트웨어 개발 과정에서 다른 개발자나 팀원들이 소스코드를 검토하는 과정을 의미합니다.
- 주로 실제 개발이 이루어지기 전에 코드의 품질과 로직을 검토하고 피드백을 주고받습니다.
- 주로 비공식적인 방법으로 이루어질 수 있으며, 빠르게 피드백을 받을 수 있는 장점이 있습니다.
워크스루 (Walkthrough)
- 워크스루는 소프트웨어 개발 과정에서 요구 사항이나 설계 문서, 소스코드 등을 팀원들과 함께 리뷰하고 토론하는 활동입니다.
- 보통 초기 개발 단계에서 사용되며, 개발자들 간의 의견을 나누고 설계 결정을 검토하기 위해 사용됩니다.
- 주로 비공식적인 환경에서 이루어지며, 소프트웨어의 품질을 향상시키고 오류를 발견하는 데 도움이 됩니다.
인스펙션 (Inspection)
- 인스펙션은 소프트웨어 개발 과정에서 코드나 문서 등을 시스템적이고 체계적인 방법으로 검토하는 과정입니다.
- 공식적인 절차에 따라 진행되며, 사전에 정의된 기준과 규칙을 준수하여 검토합니다.
- 보통 동료검토나 워크스루보다 엄격하고 체계적으로 이루어집니다.
- 주로 소프트웨어의 결함을 발견하고 개선하기 위해 사용되며, 품질 관리에 큰 도움이 됩니다.
소스코드 품질 분석 도구
코딩을 하면서 발생하는 문제를 해결하기 위해 사용하는 도구
소스코드 품질 분석 도구 분류
분류 | 특징 |
정적분석 도구 | - 소스코드를 컴파일하거나 실행하기 전에 분석하여 오류를 찾고 품질을 검증합니다. |
- 코드의 구조, 복잡성, 코드 스타일, 코딩 규칙 등을 검토하고 피드백을 제공합니다. | |
- 보통 코드 정적 분석을 수행하며, 코드 리뷰 도구, 정적 분석 도구 등이 포함됩니다. | |
동적분석 도구 | - 소스코드를 실행하고 실행 중에 동적으로 분석하여 오류를 찾고 성능을 검증합니다. |
- 코드의 런타임 동작을 분석하며, 메모리 누수, 성능 병목, 보안 취약점 등을 검사합니다. | |
- 보통 코드 테스트 도구, 디버깅 도구, 프로파일러 등이 포함됩니다. |
소스코드 품질 분석 도구 종류
꼼꼼히 외울 필요는 없습니다. 주요 도구만 기억해주시면 됩니다.
도구 | 특징 | |
정적 분석 도구 | PMD | - 자바 소스코드를 정적으로 분석하여 오류, 취약점, 일반적인 코딩 규칙 위반을 검사합니다. |
- 코드 복잡성, 중복 코드, 불필요한 코드 등을 검출하여 코드 품질을 향상시킵니다. | ||
checkstyle | - 자바 소스코드의 코딩 스타일을 검사하고 적절하지 않은 패턴을 식별합니다. | |
- 코드 포맷, 네이밍 규칙, 주석, 들여쓰기 등의 코딩 스타일을 확인하여 준수 여부를 판단합니다. | ||
SonarQube | - 다양한 프로그래밍 언어에 대해 소스코드를 정적으로 분석하여 품질 지표를 제공합니다. | |
- 코드 복잡성, 중복 코드, 보안 취약점, 코드 커버리지 등을 평가하여 품질을 개선합니다. | ||
ccpcheck | - C 및 C++ 소스코드를 정적으로 분석하여 메모리 누수, 버퍼 오버플로우 등을 검사합니다. | |
ccm | - 소스코드의 복잡성을 측정하고 분석하여 이해하기 쉬운 구조로 개선하는 데 도움을 줍니다. |
|
covertura | - 자바 소스코드를 테스트 커버리지에 따라 분석하여 테스트가 충분한지 확인합니다. | |
동적 분석 도구 | Avalanche | - 소프트웨어의 성능, 안정성, 보안을 평가하기 위해 소스코드를 동적으로 분석합니다. |
Valgrind | - C, C++ 소스코드를 실행하고 메모리 오류, 메모리 누수 등을 식별하여 보고합니다 |
애플리케이션 성능 개선하기
코드 최적화의 개념
알고리즘을 개선하거나 병목현상을 제거
코드스멜
컴퓨터 프로그래밍 코드에서 더 심각한 문제를 일으킬 가능성이 있는 프로그램 소스코드
"코드 스멜"은 코드 내에서 발견되는 특정한 문제나 힌트를 가리키는 용어입니다. 이러한 코드 스멜은 코드의 품질을 저하시키거나 유지보수를 어렵게 만들 수 있습니다.
중복된 코드 (Duplicated Code)
- 중복된 코드는 같거나 유사한 코드 조각이 여러 곳에 반복되어 사용되는 것을 의미합니다.
- 중복된 코드는 유지 보수가 어려워지며, 코드 변경 시 모든 중복된 부분을 일관되게 수정해야 합니다.
- 중복 코드를 발견하고 제거함으로써 코드의 가독성을 향상시키고 유지보수성을 높일 수 있습니다.
긴 메서드 (Long Methods)
- 긴 메서드는 코드 내에 많은 라인을 포함하는 메서드를 의미합니다.
- 긴 메서드는 이해하기 어려우며, 하나의 메서드가 여러 기능을 수행할 가능성이 있습니다.
- 긴 메서드를 작은 단위로 분리하고 각각의 기능을 수행하는 작은 메서드로 재구성함으로써 가독성과 유지보수성을 향상시킬 수 있습니다.
큰 클래스 (Large Classes)
- 큰 클래스는 많은 인스턴스 변수와 메서드를 포함하는 클래스를 의미합니다.
- 큰 클래스는 단일 책임 원칙(Single Responsibility Principle)을 위배하고, 클래스의 응집성을 낮출 수 있습니다.
- 클래스를 작은 단위로 분리하고 각각의 책임에 맞는 작은 클래스로 재구성함으로써 클래스의 응집성을 높일 수 있습니다.
클래스 동시 수정 (Concurrent Modification of Classes)
- 여러 명의 개발자가 동시에 같은 클래스를 수정하는 경우 발생할 수 있는 문제입니다.
- 클래스의 동시 수정은 충돌을 일으키고 소스 코드의 일관성을 해치며, 코드의 버전 관리를 어렵게 만듭니다.
- 이를 방지하기 위해 협업 환경에서는 코드 변경을 조율하고, 소통과 협업을 통해 동시 수정을 최소화해야 합니다.
코드 스멜 관련 용어
- 스파게티 코드 (Spaghetti Code):
- 스파게티 코드는 코드가 지나치게 복잡하고 읽기 어렵게 얽혀있는 코드를 의미합니다.
- 코드의 흐름이 여러 번 꼬여있고, 제어 흐름이 명확하지 않으며, 전역 변수를 과도하게 사용하는 등의 특징을 갖습니다.
- 스파게티 코드는 유지보수가 어렵고 버그를 찾기 어려울 뿐만 아니라 새로운 기능을 추가하기도 어렵습니다.
- 외계인 코드 (Alien Code 또는 Legacy Code):
- 외계인 코드는 이해하기 어려운 코드를 의미하며, 새로운 개발자들이 익숙하지 않은 코드를 가리킵니다.
- 주로 오래된 시스템이나 레거시 코드에서 발견되며, 현재의 요구사항과 기술에 맞지 않는 코드를 포함합니다.
- 외계인 코드는 문서화가 부족하거나 주석이 부실하여 코드의 의도나 동작을 파악하기 어렵습니다.
리팩토링
리팩토링은 소프트웨어 코드를 변경하지 않고 내부 구조를 개선하여 코드를 이해하기 쉽고 수정하기 쉽게 만드는 과정입니다. 주로 코드의 가독성을 향상시키고 중복을 제거하여 유지보수성을 향상시킵니다.
주요 특징
- 비기능적 변경: 리팩토링은 코드의 동작을 변경하지 않습니다. 코드의 내부 구조를 변경하여 코드를 더 잘 이해하고 유지할 수 있도록 만듭니다.
- 작은 단계로 진행: 리팩토링은 한 번에 큰 변경을 시도하지 않고 작은 단계로 진행됩니다. 각 단계는 코드베이스를 조금씩 개선하여 안전성을 보장합니다.
- 지속적인 과정: 리팩토링은 지속적으로 발생하는 활동입니다. 코드베이스가 변경될 때마다 필요한 리팩토링을 수행하여 코드의 품질을 유지합니다.
클린코드
의존성을 최소로 하고 사람이 이해할 수 있는 가독성, 목적성이 뛰어난 코드
클린코드 구현 방법
- 의미 있는 변수명 사용하기
- 변수명, 함수명, 클래스명 등에는 의미 있는 이름을 사용하여 코드를 이해하기 쉽게 만듭니다.
- 작은 함수와 메서드 사용하기
- 함수나 메서드는 작고 명확하게 구성되어야 합니다. 한 가지 기능만 수행하도록 만들어 코드의 읽기 쉽고 이해하기 쉽게 합니다.
- 주석 최소화 및 코드 자체 설명하기
- 코드 자체가 설명되도록 변수명, 함수명 등을 잘 선택하고, 주석은 필요한 경우에만 사용합니다. 주석은 코드의 의도나 비즈니스 로직을 설명하는데 사용됩니다.
- 중복 코드 제거하기
- 중복 코드는 유지보수성을 저하시키고 버그 발생 가능성을 높입니다. 중복 코드를 발견하고 함수나 클래스 등으로 리팩터링하여 중복을 제거합니다.
- 단일 책임 원칙(Single Responsibility Principle) 적용하기
- 각 클래스나 함수는 한 가지 기능에 집중되어야 합니다. 단일 책임 원칙을 준수하여 클래스나 함수의 역할을 명확하게 정의합니다.
- 테스트 주도 개발(Test-Driven Development, TDD) 적용하기
- TDD를 통해 코드를 작성하기 전에 테스트를 먼저 작성하고, 그에 맞춰 코드를 구현합니다. 이를 통해 코드의 품질을 높이고 버그를 최소화할 수 있습니다.
- 의존성 주입(Dependency Injection) 사용하기
- 의존성 주입을 통해 클래스 간의 의존성을 최소화하고 결합도를 낮춥니다. 이를 통해 유연하고 확장 가능한 코드를 작성할 수 있습니다.
- 예외 처리하기
- 예외 처리는 예상치 못한 상황에 대비하여 코드의 안정성을 보장합니다. 각종 예외 상황에 대한 적절한 예외 처리 코드를 작성합니다.
- 코드 리뷰(Code Review) 및 피드백 받기
- 다른 개발자들과 코드 리뷰를 통해 코드의 품질을 개선하고 피드백을 받습니다. 피드백을 통해 개선할 점을 발견하고 수정하여 클린 코드를 구현합니다.
- 지속적인 리팩터링(Continuous Refactoring)
- 지속적인 리팩터링을 통해 코드를 개선하고 품질을 유지합니다. 코드베이스가 변화할 때마다 필요한 리팩터링을 수행하여 코드를 깔끔하게 유지합니다.
클린코드 작성원칙
원칙 | 설명 |
가독성 | 코드는 다른 사람이 쉽게 이해할 수 있어야 합니다. 명확하고 간결한 코드 작성을 지향합니다. |
단순성 | 코드는 복잡성을 최소화하고 간결하게 작성되어야 합니다. 단순한 설계와 직관적인 로직을 유지합니다. |
의존성 배제 | 코드 간의 의존성을 최소화하여 유연하고 재사용 가능한 코드를 작성합니다. |
중복성 최소화 | 코드 중복을 최소화하여 유지보수성을 높이고 코드의 일관성을 유지합니다. |
추상화 | 코드는 필요한 부분만 추상화되어야 하며, 불필요한 추상화는 피해야 합니다. 코드의 목적과 의도를 명확하게 표현합니다. |
'정보처리기사' 카테고리의 다른 글
21. 제품 소프트웨어 패키징 - 국제 표준 제품 품질 특성 - 1과목 소프트웨어 구축 (0) | 2024.03.29 |
---|---|
20. 소프트웨어 유지 보수 - 1과목 소프트웨어 구축 (0) | 2024.03.28 |
18. 애플리케이션 통합테스트 - 1과목 소프트웨어 테스트 관리 (2) | 2024.03.28 |
17. 애플리케이션 테스트케이스설계 - 1과목 소프트웨어 구축 (2) | 2024.03.26 |
[정처기실기] 16. 객체지향 설계 - 1과목 소프트웨어 구축 (1) | 2024.03.26 |
댓글