SW/DevOps

DevOps : 정적 분석의 이해와 관련 도구 소개

얇은생각 2019. 12. 7. 07:30
반응형

정적 분석

 

소스코드 리뷰의 기법을 나누는 방법은 얼마나 정적이고 프로세스적으로 구분하느냐에 따라 화면 상단에 코드 리뷰 스펙트럼으로 구분할 수 있고, 자동화된 도구로 이루어지는 정적분석인 코드 인스펙션과 사람에 의해 수동적으로 수행되는 코드 리뷰 등으로 나눌 수 있습니다.

코드 리뷰 중 정형화된 방법으로는 주로 개발 단계 후반의 결함 발견에 집중하고, 손쉬운 방법의 측면은 결함 발견뿐 만 아니라 아이디어 회의, 팀원 간 지식 공유의 목적도 있습니다. Peer review는 두세 명이 진행하는 형태로 코드 작성자가 자신의 코드를 설명하고, 다른 사람이 아이디어를 제안하거나 결함을 발견하는 방식입니다.

주로 시니어 개발 사수가 주니어 개발자를 멘토링할 때 사용하지만, 시니어 개발자의 역량에 따라 품질이 달라질 수 있고 시간이 많이 소요됩니다. Pass around는 작성자가 리뷰 대상을 메일 또는 시스템을 통해 등록하면 참여자가 각자의 의견을 표시하는 방식입니다.

같은 시간, 장소에서 진행되는 것이 아니라서 좀 더 유연하지만, 오너십이 애매하고 커뮤니케이션 속도가 매우 느리기 때문에 진행 담당자가 있는 것이 좋습니다.

Work through는 발표자가 리뷰의 주제와 시간을 정해 발표를 하고, 참여자의 의견과 아이디어를 듣는 방식입니다. 주로 버그 사례 같은 정보 공유의 성격이 유리합니다.

각자의 리뷰 기법은 프로젝트 상황에 따라 적절히 변형해서 적용해야 합니다.

 

정적 분석의 개념과 필요성

앞서 설명 드린 소스코드를 도구를 사용하여 점검하는 코드 인스펙션 활동을 정적분석이라고 합니다. 보통 소프트웨어 결함을 처리하는 비옹은 결함을 늦게 발견할수록 급격히 증가하는 경향을 가집니다.

개발 단계에서 결함을 발견 후 제거할 수 있다면, 테스트 비용은 획기적으로 줄어들게 됩니다. 대신 부가적인 비용이 발생하게 되는데 대표적인 예가 코드 리뷰입니다.

하지만 많은 시간과 인적 비용이 들기 때문에 사전에 정적분석 도구를 활용해 적은 추가비용으로 미리 결함을 찾아내는 것이 좋습니다.

정적분석 도구는 가끔 실제 결함이 아닌 것을 결함으로 검출하기도 하지만, 허위경보처리 및 검출 프로세스를 수립 후 자동화하게 되면 적은 비용으로 큰 효과를 가져올 수 있습니다.

하지만 정적분석 기술은 태생적으로 완벽할 수 없습니다. 이미 풀 수 없다는 것이 증명된 정지 문제처럼 정적분석도 실행 중에 결정될 수 있는 정보를 모르는 상태에서 실행 의미를 예측하는 것이 불가능합니다.

이런 태생적 한계로 인해 코드 리뷰를 하기 전에 코드 품질을 검증하는 용도의 보조수단으로 활용하는 것이 좋습니다.

 

 

정적 분석 도구의 적용 방안

룰 기반으로 개발자가 작성한 소스코드를 검사하여 오류 및 위험요인을 식별하여 알려주는 기능을 제거합니다. 환경설정 및 실행할 때를 제외하고 인적 투입이 없는 자동화가 가능하고, 객관적인 코드 검토가 가능합니다.

점검 규칙 등 미리 정의된 패턴들은 반드시 프로젝트 상황에 맞게 최적화해서 사용해야 합니다.

 

 

CheckStyle 개요

체크 스타일은 자바 소스코드의 코딩 규칙에 대한 위반사항을 분석하는 오픈소스 도구입니다. 코딩 표준에 따른 스타일을 프로젝트에 쉽게 적용할 수 있고, 코딩 스타일 위반 내용과 잠재적 결함을 분석할 수 있습니다.

화면과 같이 소스코드에 적용할 수 있는 많은 검사 규칙을 제공합니다. 보다 상세한 검사 규칙에 대한 설명은 체크 스타일 홈페이지를 참고하시기 바랍니다.

 

 

CheckStyle 설치, 실행, 결과

설치 방법은 이클립스 내 마켓 플레이스 검색을 통해 설치할 수 있습니다. 그 외에 Gitup, 메이븐센트럴을 사용하는 방법도 있습니다.

이클립스 프리퍼런스 옵션을 통해 기본적인 룰셋은 구글 체크 또는 선 체크 스타일을 제공하고, 룰셋에 포함된 상세내역을 확인하고 필요할 경우 수정 가능합니다.

소스를 코딩하면서 룰을 활성화 또는 비활성화할 수 있습니다. 또한 개별소스 또는 전체 프로젝트에 대해 오류분석을 일괄적으로 수행하여 리포팅하게 할 수도 있습니다.

규칙 위반된 소스코드는 이클립스 창을 통해 오류 내역을 표시합니다.

점검해야 할 파일 수가 많은 경우 다소 시간이 걸리게 되므로 검토가 필요하지 않은 클래스나 패키지를 생략해서 시간과 자원을 절약할 수 있습니다.

 

 

FindBugs 개요

파인드버그는 메일랜드 대학 연구로 만들어진 자바 정적분석 도구로 다른 정적분석 도구와 조금 관점이 다른데, 코드 포맷 표준보다는 best practice, 즉 코딩 모범사례에 중점을 두어 실제로 잠재적인 버그와 성능 이슈를 찾는 데 집중합니다.

또한 소스코드 자체를 검사하기보다는 컴파일된 클래스파이링, 바이트 코드를 분석하여 작동하게 됩니다. 실행하려면 자바7 이상이 필요합니다. 200개가 넘는 규칙들을 분류하여 제공하고, 보다 상세한 규칙은 파인드버그 홈페이지를 참고하시기 바랍니다.

 

FindBugs 설치 방법

설치 방법은 이클립스의 업데이트 사이트를 통해 설치할 수 있습니다. 그 외에 파인드버그 사이트에서 플러그인을 다운로드 받아 이클립스 플러그인 폴더에 복사할 수도 있고, 메이븐 플러그인을 설치하는 방법도 있습니다.

 

FindBugs 설정

설치 후 프로젝트 속성 창 옵션을 통해 룰들을 선택하여 상세한 설정을 할 수 있습니다. 우선순위나 카테고리에 따라 확인하기 원하는 이슈 타임만 필터링할 수도 있습니다. Run automatically 항목에 체크를 하면 클래스가 변경될 때마다 이슈 여부를 확인합니다.

하지만 Find often stream 등 몇몇 이슈 처리는 매우 느리기 때문에 개발환경에서는 동작하지 않게 하고, 지속적 통합 환경에서만 수행하기도 합니다.

Context manual find bug 항목을 클릭하여 실행시킬 수 있고, 발견된 이슈는 Problems, Bug explorer 창을 통해 확인 가능하고, 더 상세한 내용은 Bug info에 표시됩니다.

파인드버그는 소스코드가 아니라 바이트 코드를 분석하기 때문에 코드 변경 후 build가 자동으로 수행되지 않는다면 수동으로 build를 실행시키기 전까지는 이슈를 확인할 수 없는 점을 반드시 주의해야 합니다.

 

 

PMD 개요

PMD는 자바, 자바스크립트, XML, JSP 등의 언어로 작성된 소스코드의 정적분석을 수행하는 오픈소스 도구입니다. 사전 준비사항으로 JDK, 자바 기반 도구 IDE 등이 필요합니다. 코딩 스타일과 불필요한 코드 등 규칙을 기반으로 위반사항을 찾아주며, 사용자에 맞는 리포트를 생성합니다.

 

 

PMD 룰 설정

설치 방법은 이클립스의 업데이트 사이트를 통해 설치할 수 있습니다. 그 외에 깃헙을 통해 사용하는 방법도 있습니다. best practice, 코드 스타일, 디자인, 문서화, 오류, 멀티쓰레딩, 성능, 보안 등 다양한 룰셋들이 있으며, 이클립스 창을 통해 정형화된 룰을 적용하여 관리가 가능합니다.

앞서 설명 드린 체크스타일과 같이 사용할 경우 중복되는 부분이 있을 수 있으므로 조절해서 적용하면 좋습니다. 예를 들어 체크스타일은 코딩 표준을, PMD는 코딩 베스트 프랙티스 룰을 적용하는 방법이 있을 수 있습니다. 정의된 룰을 기반으로 소스코드의 위반 내용을 분석하여 룰 위반이 발생한 코드라인 위치도 확인할 수 있습니다.

위반 메시지를 클릭하면 해당 결함이 발생한 위치의 소스코드를 보여주게 됩니다. 또한 각 룰별로 위반횟수, 출현률 등에 대한 통계자료를 보여줍니다.

 

 

PMD 실행 및 결과 확인

Copy/Paste Detector(CPD)를 통해 프로젝트 현장에서 많이 발생하는 중복 코드를 찾을 수 있습니다. 발견된 결함 내용을 엑셀, HTML, 텍스트, XML 파일 등 다양한 포맷의 리스트로 생성할 수 있습니다.

 

 

 

상세한 내용은 화면의 표를 참고하시기 바랍니다. 세 가지 툴의 성격이 다르고 겹치는 영역도 있기 때문에 프로젝트 상황에 따라 적절히 혼용해서 사용해야 합니다.

반응형