[정보처리기사 올인원] 2-4-3.애플리케이션 성능 개선

https://youtu.be/SavmR5UTTEE?si=0-7krZWlqIBxHAIG

1. 애플리케이션 성능 개선

1-1. 성능 측정과 용어 이해
- 성능 측정의 어려움과 여러 지표를 설명함
- '애플리케이션 성능 분석 도구'에서 '성능 점검 도구'와 '모니터링 도구'의 차이를 언급함
- 성능 점검 도구는 성능 측정, 모니터링 도구는 자원 사용 상태 판단을 지원함
- '성능 점검 도구'와 '모니터링 도구'를 구분하는 것이 중요함
- 측정과 지원의 차이를 명확히 이해해야 함

1-2. 성능 저하 원인과 개선 방안
- 데이터 과다, 불필요한 업데이트, 잘못된 환경 등이 성능 저하의 원인임
- (중요) 손님이 너무 많거나, 연결/쿼리 실행 시 오류가 발생하면 시스템 마비될 수 있음
- 인터넷 접속이 불량하거나, 큰 파일 업/다운로드 시 처리 시간이 길어지면 성능 저하가 나타남
- 잘못된 환경(설정 크기, 전송 실패/지연 등)이 성능 저하의 원인이 될 수 있음
- 개선 방안으로 소스코드 최적화 기법을 소개함

1-3. 소스코드 최적화
- 소스코드 최적화 기법은 코드의 복잡도를 줄이고, 가독성과 이해를 높임
- (중요) 클린코드는 정제된 코드, 의존성이 낮고, 중복이 최소화된 코드임
- 클린코드 작성은 코드 최적화에 도움이 되고, 테스트 및 보완이 가능함
- 클린코드 품질 분석 도구는 코드의 복잡도, 메모리 누수 현황 등을 파악함
- 증명은 미션 크리티컬한 업무에 사용, 결과 비교를 통해 품질을 평가함

2. 소프트웨어 리팩토링과 유지보수 전략

2-1. 소프트웨어 리팩토링과 가독성 개선
- 리팩토링은 코드의 가독성과 안정성을 향상시키는 방법임
- 코드를 재사용함으로써 가독성 향상과 함께 유지 보수 비용을 절감할 수 있음
- 리팩토링을 통해 구조를 개선하면 안정성과 가독성을 확보할 수 있음
- 소프트웨어 유지보수는 소프트웨어 기능을 개선하고 만족도를 향상시키는 작업임
- 유지보수는 표준화되지 않은 요소들을 문서화하고 가독성을 높이는 것이 중요함

2-2. 소프트웨어 유지보수 유형과 방안
- 유지보수 유형은 하자 보수, 완전 보수, 적응 보수, 예방 보수로 나뉨
- (중요) 하자 보수는 버그나 잠재적 오류의 원인을 제거하는 것임
- 완전 보수는 성능 문제뿐 아니라 모든 문제에 대한 수정과 보완을 완벽하게 하는 것임
- 적응 보수는 환경 변화에 적응하여 유지 보수를 실시하는 것임
- 예방 보수는 사용자의 요구를 미리 예측하여 반영하는 것임

2-3. 소프트웨어 품질 평가와 신뢰도 측정
- 소프트웨어 품질 평가 에스큐에이는 기능과 요구사항의 일치 여부를 확인하는 체계적인 시스템임
- 정형 기술 검토는 요구사항 일치 여부, 표준 준수, 결함 발생 여부 등을 검토하는 방법임
- 평균 시간을 이용하여 시스템의 신뢰도를 측정할 수 있음
- 평균 무장애 시간, 평균 장애 시간, 평균 복구 시간 등을 측정하여 신뢰도를 평가함
- (중요) 평균 복구 시간은 수리가 완료될 때까지의 수리 시간 평균을 의미함

00:00
세 번째 섹션 애플리케이션 성능 개선에 대해서 같이 보도록 하겠습니다. 여기도 마찬가지 성능을 개선하기 위한 도구라든지 용어라든지 지표 이런 단어들이 많이 나오겠죠. 하나씩 보도록 하죠. 일단 성능 측정 자체가 어려운 단어는 아니니까요? 그건 넘어가도록 하고요. 성능 측정하기 위한 지표가 이렇게 있는데, 요거 시스템이나 플랫폼하고 용어가 비슷하죠. 학습하실 때 참고하시기 바라고요. 어플리케이션 성능 분석 도구가 있습니다. 두 가지가 있는데, 크게 성능 부하 스트레스 점검 도구 그러니까 성능 점검이라고 보시면 돼요. 그다음에 모니터링 도구 이렇게 나와 있는데, 성능 점검 도구는 말 그대로 성능을 측정하는 형태고요. 모니터링은 현재 어떤 자원을 쓰고 있는지 어떤 상태인지 그런 것들을 판단해서 안정적인 운영을 지원하는 용도로 사용을 합니다. 측정과 지원 이렇게 보시면 됩니다.

00:52
자 내려가서 자 이 부분은 성능 점검에 쓰이는 도구와 모니터링에 쓰이는 도구를 나눠 놓은 거예요. 실제 문제는 이 설명 도구에 대한 설명이 나온 게 아니라 성능 점검에 해당하는 예를 들어서 뭐 도구가 아닌 것은 프로그램이 아닌 것은 모니터링에 해당하는 프로그램은 뭐 이런 식으로 질문이 나온 적이 있습니다. 그래서 도구명을 적어 놓은 거고요. 거기에 오른쪽에 간단하게 설명이 나와 있는데, 설명을 보시면 서로가 구분될 만한 게 많지 않아요. 그래서 여기 보면은 뭘 지원한다. 웹 서비스를 다양한 프로토콜을 하면서 비슷한 키워드가 굉장히 많거든요. 그래서 각각의 도구에 대한 설명을 물어보는 그런 문제가 나올 확률은 좀 적고요. 확실하게 구분되지가 않기 때문에 다만 여기서 분류는 확실하게 나뉘어져 있기 때문에 이 분류에 따른 문제가 나올 수 있다. 이렇게 해석을 하고 있습니다. 이 정도만 파악을 하시면 일단은 될 것 같아요.

01:47
넘어가서 자 성능이 저하되는 원인에 대해서 분석이 되어 있는데, 뭐 생각해보면은 당연한 요소들이 적혀 있습니다. 데이터를 항상 사람이라고 손님이라고 생각하면은 접근하기가 그렇게 어렵지 않아요. 예를 들어서 첫 번째 db 연결 및 쿼리 실행에서는 대량의 데이터 조회 과도한 업데이트 많은 양의 데이터 요청 불필요한 확정 뭐 이런 말 나와 있죠. 손님이 갑자기 너무 많이 몰린다든지 아니면 손님이 쉽게 표현하자면 진상을 부리는 거죠. 그럴 때는 당연히 시스템 업무가 마비될 수밖에 없겠죠. 그런 부분에 대한 이야기라고 보시면 돼요. 어려운 개념은 아니고요. 다음으로는 내부 로직 인터넷 접속이 불량하든가 아니면 인터넷에 접속은 잘 되어 있는데, 그 인터넷을 통해서 너무 큰 너무 많은 양의 파일을 업로드하거나 다운로드할 때 처리 시간이 길어질 수 있다.

02:43
뭐 당연한 이야기죠 이 부분은 그다음에 예외 처리 오류 처리 로직과 실제 처리 로직을 분리하지 않은 경우에는 예외 처리를 할 때 실제 처리 로직이 멈춰 있겠죠. 그렇기 때문에 성능이 저하될 수 있다. 이렇게 되어 있는 겁니다. 다음으로, 외부 호출이라고도 되어 있는데, 이거는 읽어보시면 타임아웃이라는 단어가 있죠. 타임아웃이라는 거는 뭔가를 호출하거나 요청을 했는데 그쪽에서 소식이 없을 때 일정 시간 소식이 없을 때 타임아웃이라는 개념이 생겨요 그래서 호출이 취소되거나 아니면은 뭐라 그럴까요? 멈추거나 하는 그런 현상입니다. 그런 것들을 타임아웃이라고 한다고 보시면 돼요. 자 넘어가서 잘못된 환경 잘못된 환경은 여기에 적혀있는 두 가지 말고도 굉장히 많아요. 그렇기 때문에 그냥 두루뭉술하게 보시면 됩니다. 크기를 어떤 특정 설정 크기를 너무 작게 너무 크게 설정을 한 경우 그다음에 전송이 실패되거나 전송이 지연되는 이런 형태 때문에 문제가 생길 수 있다. 이렇게 되어 있습니다.

03:42
이것뿐 아니라 여러 가지 다른 설정이라든지. 아니면은 뭔가 서로의 간섭 때문에 문제가 언제든지 생길 수 있습니다. 자 이 정도 보구요. 자 그러면 성능 저하 원인은 봤구요. 이번엔 두 번째 포인트로 어플리케이션 성능 개선 방금은 저하에 대해서 봤고요. 그럼 개선하려면 어떻게 해야 되냐 가장 첫 번째로, 소스코드 최적화라고 되어 있습니다. 배드코드와 클린코드가 나와 있는데요. 베드코드는 말 그대로 안 좋은 거겠죠. 자 그래서 로직의 제어코드들이 정제되지 않고 정리되어 있지 않고라고 보시면 됩니다. 서로 얽혀서 알아보기 힘들게 얽혀 있어서 이걸 스파게티 코드라고 해요. 식별자들의 정의를 알 수 없고 동일한 로직이 중복 작성된 코드 말 그대로 복잡하고 불필요한 애들이 얼기설기 설켜있다. 뭐 그런 뜻입니다. 당연히 코드의 복잡도가 증가를 하게 되겠고요. 잦은 오류가 발생할 가능성이 높아지겠죠. 분석이 어려우니까요?

04:38
이런 것들을 배드 코드 보기 어렵다라는 얘기죠 자 클린 코드는 단어 뜻 그대로 깔끔하다는 얘기예요. 첫 번째 줄에 나와 있죠. 가독성이 높고 단순하고 의존성이 낮고 중복이 최소화된 코드 정말 필요한 것만 깔끔하게 나와 있는 코드예요. 그러면 당연히 코드에 대한 이해가 쉽고요. 프로그래밍 속도도 마찬가지 빨라지겠죠. 원칙 여러 가지 나와 있는데, 긍정적이고 깔끔한 느낌을 주는 단어들을 다 생각해 보시면 됩니다. 가독성 단순성 의존성 최소화 중복성 최소화 추상화 등이 있다 라고 되어 있습니다. 추상화는 앞에서도 잠깐잠깐 설명을 하고 있었죠. 읽어보시면 좋을 것 같고요. 다음에 소스 코드 최적화 기법 나와 있습니다. 최적화 기법이 아닌 것은 이런 식으로 문제가 나올 수 있습니다. 그러니까 클린 코드를 작성하는 방법이라고 생각을 하셔도 되겠죠. 자 그래서 5가지 나와 있는데, 이런 류의 문장이 나오는 거예요. 이 문장이 꼭 나오는 게 아니구요. 그러니까 이해를 하셔야 돼요.

05:37
클래스는 하나의 역할만 수행하도록 응집도를 높인다. 우리 응집도 얘기했었죠. 그다음에 클래스가 의존성을 최소화해서 결합도를 약하게 한다. 이 얘기도 우리가 모듈 얘기하면서 했었어요. 그다음에 올바른 코딩 스타일 올바른 코딩 스타일을 파악해서 가독성을 높이고요. 개혁하기 쉽고 발음이 쉬운 용어나 접두어 등을 사용해서 이름을 정의한다. 요 얘기예요. 이 얘기 적절한 주성문을 사용하여 소스코드에 대한 내용을 보충한다. 가독성이죠. 그래서 이 클린코드가 실제로 코드코드 최적화하는데 굉장히 도움이 된다. 이렇게 보시면 되겠습니다. 그러면 클린코드로 작성된 코드가 얼마나 좋은 품질을 가지고 있는지 판단을 해봐야 할 텐데 우리가 하는 게 아니라 품질 분석 도구가 할 수 있습니다. 여러 가지 쭉 나와 있죠. 결함도 발견할 수 있고요. 코딩의 표준 복잡도 그다음에 메모리 누수 현황 이런 것들을 다 파악할 수 있다고 되어 있어요.

06:34
품질이라는 거는 이런 것들을 다 아우르는 개념입니다. 일반적인 테스트를 비롯해서 이런 것들 할 수 있다라고 되어 있어요. 자 인스펙션은 확인하고 검사하고 찾아내는 그런 애들을 이야기합니다. 그래서 코드 인스펙션이면은 코드에 존재하는 무언가를 확인하는 거예요. 이렇게 보시면 될 것 같고요. 그다음에 아래쪽 내려가서 증명이라고도 되어 있죠. 증명은 품질이 아주아주 중요한 경우에 활용이 되는 건데 어떤 식이냐면 대략 모든 기대 결과와 실제 결과를 하나하나 다 비교하는 거예요. 그래서 미션 크리티컬한 업무에 사용이 된다. 이렇게 보시면 되겠죠. 다음으로, 리팩토링이라고 되어 있습니다. 이것도 문제의 실기에도 나온 적이 있어요. 코드의 기능 변경 없이 기능의 변경은 없어요. 구조를 개선해서 안정성과 가독성을 확보한다고 되어 있습니다. 가령 a를 5번 더 한다고 생각을 해볼까요?

07:32
이렇게 이렇게 되어 있는 코드가 있다고 생각을 해보죠. 자 그러면 a를 5번 더 하는 거죠. 리팩토링은 어떻게 하는 거냐면 이렇게 하는 겁니다. a를 5번 더한다. a에 5를 곱하는 거랑 똑같은 개념이죠. 이렇게 하면 훨씬 더 가독성이 좋아질 수 있어요. 예시입니다. 이런 식으로 구조를 개선하면 안정성과 가독성을 확보할 수 있다. 이렇게 보시면 되겠죠. 다음으로, 마찬가지 이것도 소스코드 정적 분석 도구와 동적 분석 도구가 있는데, 각각에 대한 설명도 간단하게 적어놨지만 보통은 정적 분석 도구와 동적 분석 도구를 구분할 수 있으면 돼요. 다음 중 정적 분석 도구가 아닌 것은 다음 중 뭐 동적 분석 도구인 것은 이런 식으로 문제가 나올 수 있습니다. 그런 부분을 잘 체크해 주시면 됩니다. 이번에는 소프트웨어 유지 보수에 대해서 나와 있어요. 유지 보수는 말 그대로 유지를 하는 거잖아요.

08:29
지속적으로 소프트웨어 기능을 개선을 하고 만족도를 향상시킨다. 이 개념이고요. 그다음에 표준화되어 있지 않은 이런 것들 이런 것들은 유지 보수가 어렵다 다 이걸 위해서 문서화를 하고 가독성을 높이는 겁니다. 유지보수로 인해서 부작용이 발생하지 않도록 회귀 테스트가 필요합니다. 회귀 테스트 앞에서 계속 나오고 있죠. 뭔가 변경됐을 때 변경된 부분에 다시 같은 테스트를 진행해서 뭔가 문제가 새로 생겼는지 판단하는 거죠. 자 부작용이 여러 가지가 있는데, 코드 부작용 데이터 부작용 문서 부작용이 있어요. 코드의 변경으로 발생하는 건 코드 부작용이고 데이터 구조를 변경하면서 발생하는 건 데이터 부작용이고 뭐 이런 느낌입니다. 그래서 어려운 개념은 아니구요. 자 그런 다음 소프트웨어 유지보수 유형이 네 가지가 나와 있는데요. 자 요것도 영어 단어 외우듯이 연결해서 외워주시면 돼요. 하자 보수는 말 그대로 하자 버그나 잠재적 오류의 원인을 제거하는 거예요. 하자를 제거하는 거죠.

09:28
그래서 하자 보수구요. 그다음에 완전 보수는 가장 많은 비용을 소모하는데 성능 문제뿐만 아니라 모든 문제에 대한 수정과 보완을 완벽하게 할려고 노력하는 그런 형태입니다. 당연히 그러니까 비용이 많이 들겠죠. 다음은 적응 보수입니다. 적응 보수는 환경에 적응하기 위해서 유지 보수를 하는 거예요. 그래서 운영 환경이 변화됐다. 예를 들어서 뭐 32비트 컴퓨터에서 64비트 컴퓨터로 갔다든지 운영체제가 바뀌었다든지 그랬을 때 문제가 없도록 환경의 변화 사항을 소프트웨어에 반영시켜주는 걸 적응 보수라고 한다. 라는 거고요. 다음에 예방 보수는 미리 예측하는 거죠. 예방 보수니까 예측을 하는 거예요. 사용자 요구를 미리 예측해서 반영하는 걸 예방보수라고 한다. 그래서 하자 완전 적응, 예방 이렇게 보시면 되겠습니다.

10:23
하자는 버그 완전은 전부 다 적응은 환경 예방은 예측 이렇게 보시면 되겠네요. 다음으로, 유지보수도 개발의 한 단계기 때문에 당연히 비용이 들겠죠. 비용을 측정하는 방법이 나와 있습니다. 각 방법별로 대표 공식이 나와 있고요. 그 공식에 사용된 각 변수들에 대한 설명도 제가 오른쪽에다 다 적어놨는데 사실 이 오른쪽에 변수에 대한 설명이 문제로 나오지는 않습니다. 보통은 방법이 아닌 것은 뭐 이런 식으로 문제가 나오는 편이에요. 많이 봐줘도 공식 정도만 있으면 충분할 겁니다. 근데 뭐 공식까지는 당장에 외울 필요 없이 제가 이렇게 체크한 부분만 해서 서로가 아닌 것만 고를 수 있게끔 그 정도만 하셔도 아마 충분하실 거예요. 이 정도만 보고 넘어가도록 하구요. 이번에는 소프트웨어 품질 평가입니다. 소프트웨어 품질 보증 에스큐에이라고 하는데요. 기능과 요구사항이 일치하는지를 확인하는 체계적인 시스템 자체를 에스큐에이다. 이렇게 이야기하는 거고요. 정형 기술 검토라는 개념이 있어요.

11:22
가장 일반적으로 정형화된 기술 검토 방법을 정형 기술 검토라고 하는데 뭐 똑같은 말이죠. 요구사항 일치 여부나 표준 준수 결함 발생 여부 이런 것들을 검토하는 정적 분석 기법이라고 되어 있습니다. 문제로 나왔던 건 아래쪽이에요. ftr의 원칙 ftr의 원칙이 두 페이지에 걸쳐서 요렇게 나와 있는데, 뭐 이것저것 많죠 그런데 보면은 대부분 다 제한이에요. 뭔가 제한을둡니다. 자원시간 일정 할당하고요. 의제를 제한하고 제품의 검토 자체만 다른 걸 제한한다는 뜻이죠. 그다음에 논쟁과 반박을 제한하고 참가자의 수를 제한하고 해결책이나 개선책에 대해서 논하지 않고 이런 식으로 여러 가지 뭔가 제한을 두는 딱 정해진 것만 하는 이런 형태의 원칙이 있습니다. 그래서 이게 정형기술검토예요.

12:12
여기 정형기술검토 그래서 문장을 보실 때 항상 어떤 부분에만 집중하고 그 이외의 부분은 제한을 두고 뭐 요런 개념을 잡고서 암기를 하시면은 그렇게 어렵지는 않을 겁니다. 넘어가서요 소프트웨어 품질 목표 항목 자 이거는 우리가 앞에서도 플랫폼이네 시스템이네 어플리케이션이네 여러 가지 요소를 이야기했잖아요. 문제도 자주 나오는데요. 요 부분에서 지금 처음 본 단어가 거의 없으실 거예요. 정확 신뢰 효율 무결성 무결성은 본 적이 없으시겠다. 유지 보수 용이성 사용 용이성 검사 용이성 인식성 상호 운용성 유연성 재사용성 다 한 번씩은 나왔던 단어들입니다. 그래서 세부 항목들에 대한 설명도 마찬가지 영어 단어 외우듯이 외울 수 있게끔 연결을 해서 암기를 해 주시는 게 좋습니다.

13:00
그리고 대충 보면은 다 긍정적인 용어들이기 때문에 보통은 이게 부정적인 용어라든지 전혀 동떨어져 있는 의미를 가진 용어들을 이제 정답으로 보기 정답으로 내는 편이기 때문에 맞추는데 그렇게 어렵지 않을 거예요. 요 정도 보시면 될 것 같고, 마지막으로, 시스템 신뢰도를 측정하는 방법입니다. 소프트웨어 신뢰도를 평가하는 데 기준이 되는 요소 중에 하나인 평균 시간이라는 것들이 있는데, 이 시간이 총 세 가지가 있어요. 평균 무장애 시간 평균 장애 시간 평균 복구 시간이 있습니다. 좀 단어가 헷갈려요 그래서 체크를 잘 해주셔야 돼요. 일단은 무장애시간은 평균장애 발생 간격 평균이에요. 이게 무슨 얘기냐면 평균 무장애 시간이 예를 들어서 10초다라고 하면 10초는 너무 짧은데 뭐 10분이라고 치면은 10분마다 대략 10분마다 한 번씩 고장이 난단 소리예요. 내가 수리를 하면 또 10분 후에 고장이 날 거야. 이런 개념입니다.

13:55
지금 10분은 제가 너무 짧게 잡았죠 어쨌든 그런 개념이 평균 무장애 시간이다라는 거고요. 다음은 평균 장애 시간입니다. 수리가 불가능한 제품을 기준으로 봤을 때 고장이 발생할 때까지의 동작 시간 평균을 낼 수 있어요. 그래서 평균 장애 시간 무장애 시간 장애 시간 체크를 잘 해주셔야 됩니다. 다음으로는 평균 복구 시간이에요. 고장이 발생한 시점부터 수리가 완료될 때까지의 수리시간 평균이라고 되어 있습니다. 공식도 따로 나와 있죠. 공식 정도만 파악을 할 수 있으시면 좋을 것 같고요. 그다음에 이 평균 시간대를 이용해서 가용성 측정이 가능하다고 되어 있죠. 이 공식까지 체크를 해주시면, 되겠습니다.