[정보처리기사 실기 공부] 애플리케이션 성능 개선

애플리케이션 성능 향상을 위한 실전 가이드

애플리케이션 성능은 사용자 경험과 전반적인 시스템 안정성에 직접적으로 영향을 미치는 중요한 측면 중 하나입니다. 이번 글에서는 애플리케이션 성능 저하의 주요 원인과 성능 분석, 품질 향상을 위한 다양한 방법에 대해 다뤄보겠습니다.

---

데이터베이스 성능 저하 원인

• 데이터베이스 락(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년에 정보처리기사를 따기 위해 노력하는 모두에게 행운을 빕니다!