vue.js 관련 사이드 프로젝트 진행하면서 배우는 것도 많고 관련 지식도 늘어가고 있는데 막상 이를 시간내서 정리하기는 참 어렵다. 진척이 많이 된 것 같으면서도 중요한 내용들을 놓치고 지나가고 있는 것 같아서 아쉬운 마음 반, 퇴근하고 주말에도 시간 써가며 하고 있는 상황이 지겨운 마음 반.
마음이 복잡하지만 막상 얼추 완성되어가는 모습을 보면 또 나름 뿌듯하다.
최근에 포스팅을 계속 못했던 나 나름의 반성과 성찰을 쓰면서 포스팅을 시작한다.
오늘은 소스코드 정적분석과 동적분석에 대해 정리해보려고 한다.
용어만 들으면 얼추 다 아는 얘기인데 뭐 정리할거까지야 있나 싶긴한데, 공부하는 방법의 최고는 누군가를 가르치면서 배우는 것이 크다고 하지 않나? 요즘 누구에게 설명할 일이 종종 생겨서 이해하기 쉽게 설명하기 위해 내가 더 자세하게 알아두고자 정리한다.
프로그램/소스코드 정적 분석 (Static Analysis)
정적이라는 단어 그대로, 멈춰있는 상태의 소스코드를 분석함을 의미한다.
목적에 부합하는 프로그램을 구성하기 위해 소스코드를 작성하고, 빌드 단계를 거치면서 컴파일 에러가 발생하면 수정하고 이상이 없으면 프로그램 작성을 완료하게 된다. 이 과정을 거쳐서 에러가 발생하지 않는 코드를 기본적인 상태라고 했을 때, 정적 분석은 이 코드를 특정한 가이드라인을 가지고 면면히 뜯어보는 과정을 말한다.
이러한 기준에 의해 찾아진 코드를 결함이라고 부르기도 하고, 문제를 일으킬 가능성이 있는 코드라서 냄새가 난다며 Code Smell이라고 하기도 한단다. (뭔가 내 코드에서 스멜 난다고 하는건 자존심 상하는 느낌)
정적 분석 도구로는 Checkstyle, Cppcheck, PMD, SonarQube, StyleCop, cobertura, cpplint 등 다양하게 존재하고 있으나 이 중 SonarQube가 대표적으로 많이 쓰이는 듯 하다. (https://www.sonarqube.org/downloads/)
사실 내가 써봤으니 지극히 주관적인 입장이 반영되어 있다. Community Edition은 무료이고, Jenkins와 같은 CI/CD 툴과의 연계도 가능하다. 지속적으로 관리되고 있는 제품이므로 사용해보는 것을 추천한다.
이 이후 정적 분석 도구와 관련한 내용은 SonarQube 기준으로 설명한다.
또 다른 정적 분석 도구인 PMD(Programming Mistake Detector)의 경우도, SonarQube에서 Plug-in 형태로 추가할 수 있으므로 PMD에서 제공하는 코드 분석 규칙을 적용할 수도 있다.
1. 정적 분석을 진행할 규칙 Rule 을 모아둔 규칙 묶음을 만들고 (Quality Profile)
2. 이 규칙에 의거하여 도출된 결과값을 어느선까지 통과시킬지, 기준선을 정의한다 (Quality Gate)
3. SonarQube를 통해 소스를 분석하면 확인할 수 있는 주요 지표
- Bugs - 코드를 손상시키고 즉시 수정해야하는 코딩 오류
- Vulnerabilities - 취약점, 공격 할 수있는 코드의 한 지점
- Code Smells - 문제가 될 수 있는 코드, 유지보수하기 어렵게 만드는 코드
- Duplications - 중복된 코드
위에서 발견된 문제점들을 개선하게 되면, 코드 품질과 보안 향상에 도움이 된다고 한다.
현재 본인의 경우는 CI/CD 툴인 Jenkins와 연계하여, 소스 코드 빌드 후 SonarQube를 통해 정적 분석를 진행했을 때 분석 결과가 통과 기준을 부합하는 경우 서버에 배포를 수행하도록 설정해두었다.
이러한 정적 분석 단계는 사실 프로젝트 초기 단계부터 수행하는 것이 가장 좋다.
만드는 과정에서 비슷한 코드들을 계속해서 만들 수도 있고, 문제가 있는 줄도 모르고 Ctrl + C, Ctrl + V가 반복될 수 있다. 이렇게 코드 다 짜놓고 나중에 돌리면 전체적으로 삽질하게 되는 사유가 될 수 있다 ^_ㅜ
그럼 다음은 정적 분석과 상반되는 개념의 동적 분석을 알아보자.
프로그램/소스코드 동적 분석 (Dynamic Testing)
동적 분석은 소스 코드 자체를 분석하는 것이 아닌, 일련의 시나리오를 적용하여 실행하는 과정에서 문제가 발생하지 않는지 확인하는 방식이다.
개발자가 개발 과정에서 진행하는 입력값에 대한 유효성 검사, 디버깅, 유닛테스트 등도 일종의 동적 분석이다.
+ 추가로 시스템 오픈 전 일부러 부하를 주어서 문제점을 파악하는 스트레스 테스트도 동적 분석!
다들 많이들 알고 있는 테스트 기반 개발법 (Test Driven Development, TDD) 도 동적 분석이라고 볼 수 있다.
TMI를 추가하자면, TDD 방식으로 개발을 진행하고자 했으나, 일단 프로그램 단위별로 이 프로그램 작동이 성공임을 정의하는 내용을 하나하나 만들어야 하는게 매우 귀찮아서 중간에 포기했다.
잘만 구축해두면 점검 자동화가 가능하다는 점에서 의미는 있다고 본다. (물론 아직 내가 만드는 프로그램에서 유의미한 사용처를 발견하진 못함)
사실 동적 분석 도구를 사용해보지 않아서, 이렇다하게 사용 방법이나 대표적인 도구를 소개하기는 어렵다.
소스 코드를 실행시키며 프로그램 내 결함 및 취약점 분석, 메모리 및 스레드 결함 등을 분석할 수 있는 도구로 Avalanche, Valgrind 등이 있다고 한다.
Valgrind는 공개 SW 품질검증분야에서 주요 SW 목록에 언급된 것으로 보아 많이들 쓰는듯 하다. 다만, C/C++ 기반 프로그램에 대한 메모리 및 쓰레드 문제를 동적으로 분석 할 수 있는 프로그램이라 본인은 적용이 어려울 듯 하다.
별도의 동적 분석 도구를 적용하기 어렵다면, 대체 방법으로 동적 분석 도구가 프로그램을 실행하는 과정에서 발생하는 문제를 파악하는 방법이라고 했으니, JAVA 프로그램에 적용이 가능한 테스트도구를 적용하여 동적 분석을 수행할 수 있을 듯 하다.
- Jmeter - 부하 테스트 기능 동작과 성능을 측정하기 위해 디자인 된 100% 순수 자바 Application
- Junit - 자바 프로그래밍 언어용 유닛 테스트 프레임워크
- Selenium WebDrive - 웹 어플리케이션을 테스팅할 때 사용할 수 있는 무료 도구, API를 제공하는 오픈소스
- nGrinder - 스크립트 생성, 테스트 실행, 모니터링 및 결과 보고서 생성기를 동시에 실행할 수 있는 스트레스 테스트용 플랫폼
- TestNG - Java로 만들어진 Testing Framework로, 단위테스트, 기능테스트, end-to-end 테스트, 통합테스트 가능
위와 같은 테스트도구를 이용하여 일련의 테스트 시나리오를 실행하도록 하여 동적 분석을 진행할 수 있겠다.
소스 코드 분석의 경우, 동적 분석으로 찾아낼 수 있는 문제점과 정적 분석으로 찾아낼 수 있는 문제점이 분명히 다르고 방식도 확연하게 다르기 때문에 둘 다 수행해서 좀 더 안전하고 향상된 프로그램을 구축할 필요가 있다.
다만, 둘 다 수행하고 있지 않다면 가장 쉽게 도입할 수 있는 정적 분석 도구부터 순차적으로 적용해봄이 어떨까.
참고
- 공개 SW 품질검증분야 https://www.oss.kr/storage/app/public/oss/oss_use_153.pdf
- 정적/동적 분석기법이 잘 정리된 네이버 블로그 https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=bi1189&logNo=221521693365
'PROGRAM' 카테고리의 다른 글
| SQLException : 인덱스에서 누락된 IN 또는 OUT 매개변수 (0) | 2022.11.08 |
|---|---|
| [Apache Kafka] 개념, 설치 및 Producer/Consumer 사용 예제 (0) | 2022.04.20 |
| 도로명주소 API 호출 시 connection timed out 원인 파악, IP 차단 여부 확인 (0) | 2021.02.01 |
| 암호 알고리즘과 키 생성 기준이 있을까? KISA 기준을 따라보자 (0) | 2020.12.13 |
| [Python] 파이썬 표류기 2 : python 2, 3의 차이와 python 활용도 (0) | 2020.10.21 |
