소스 정적 분석도구 SonarQube 리서칭

프로그램 소스의 정적 분석 도구로 유명한 SonarQube에 대해 정리합니다.

 

프로그램 정적 분석(static analysis)이라 함은, 프로그램의 실제 실행 없이 코드를 분석하는 것을 말합니다. xLint 계열 도구를 비롯해서 PMD, CheckStyle, Findbugs 등 다양한 오픈소스들이 존재하지만, 다양한 룰셋을 사용할 수 있고 쉬운 플러그인 설치를 통해 보다 다양한 기능을 제공하는 SonarQube가 지속적으로 업데이트되며 보편적으로 사용되고 있는 듯합니다.

 

본 글에서는, 
SonarQube의 구성부터 실제 프로젝트에 적용하기까지 SonarQube를 통한 정적 분석 과정을 아래의 순서대로 정리 해 보고자 합니다.
(현시점의 SonarQube 버전은 6.3입니다.)

 

• 왜 정적 분석인가?
• SonarQube Architecture
• SonarQube Integration
• SonarQube 설치하기
• SonarQube 사용하여 분석하기
• SonarQube 분석 결과 보기
• SonarQube Tip & Tech
• SonarQube 분석지표
• 마무리 그리고 다음

 

 

 

왜 정적 분석인가?

 

피트니스 센터에 가본 사람이라면 한 번쯤은 들어 봤을, “스쿼트”라는 전신운동이 있습니다. 몸을 구성하는 큰 근육들을 모두 활용할 수 있는 운동이기 때문에 남녀노소 불문하고 많이 추천하는 운동입니다.

스쿼트의 바른 자세 ( https://en.wikipedia.org/wiki/File:Squats.svg)

 

 

재밌는 사실은, 스쿼트가 가장 기본적인 운동임에도 불구하고 제대로 된 자세로 정확히 하는 사람은 많지 않다는 사실입니다. 때문에 힘만들고 몸의 변화는 적다는 생각에 스쿼트를 등한시하거나, 혹은 잘못된 자세 때문에 부상을 입는 경우가 많습니다.

스쿼트의 잘못된 자세

 

 

비단 스쿼트뿐만 아니라, 대부분의 근력 운동들도 마찬가지입니다. 제대로 된 자세로, 원하는 부위에 집중해서 운동을 하지 않는다면 근육 생성도 더딜뿐더러 피트니스를 빙자한 노동으로 변모해 버리고 맙니다.

 

그렇다면 어떻게 “제.대.로” 할 수 있을까요? 처음부터 제대로 된 자세로 운동을 할 수 있는 사람은 많지 않습니다. 결국 시행착오를 겪고 옳은 자세로 잘못된 부분을 조금씩 고쳐나가는 노력이 필요합니다. 자신의 잘못된 부분을 옆에서 지적해 주고 바른 방향으로 수정해 주는 누군가가 있다면 금상첨화겠죠. 사람들이 Personal Trainer 비용을 투자하는 데는 다 이유가 있는 겁니다.;; 시간만 주어진다면 좋은 도서를 통한 학습도 훌륭한 대안이 될 수 있습니다.

헬스의 정석 시리즈 — 수피

 

 

프로그래밍의 경우도 마찬가지입니다. ‘돌아가기만 하면 되는 코드’는 개발자에게도, 프로젝트에도 전혀 도움이 되지 않습니다. 잘못된 코드는 또 다른 잘못된 코드를 양상 하고, 떨어지는 가독성과 높아지는 복잡도 덕분에 프로젝트 코드는 시간이 지남에 따라 점점 이해하기 힘든 모습이 되어갑니다. 개발자는 더 많은 노력과 시간이 필요해지고, 프로젝트는 언제 터질지 모르는 폭탄을 품고 살아가게 됩니다.

 

때문에 프로그래밍에서도 잘못된 자세를 지적해 주고 제대로 개발할 수 있도록 이끌어줄 방법들이 필요합니다. 개발자의 필수 도서라 불리는 책들은 몇 번을 읽어도 손해 볼 게 없습니다.

코드 개선을 위한 필수 도서들

 

 

애자일 진영에서 강조하는 페어 프로그래밍, 몹 프로그래밍이나 코드 인스펙션 활동들 역시 좋은 대안이 될 수 있습니다. 이러한 문화를 이끌어 줄 수 있는 멘토가 있다면 빠른 시간 내 코드의 품질이 좋아질 수 있습니다. 
문제는 ‘사람 == 시간 == 돈’ 이기 때문에 제대로 된 개발을 위해서는 그만큼 많은 비용이 필요할 수밖에 없습니다.

몹 프로그래밍의 잘못된 예

 

 

결국, 이러한 부분에 대한 고민 끝에, 비용이 추가로 들지 않으면서 코드의 품질을 검토하고 잘못된 부분을 옳은 방향으로 고칠 수 있도록 멘토링 하는 다양한 도구들이 만들어졌습니다.

 

본 글에서는 개발자의 역량 향상과 미래의 장애 발생 확률을 줄이는 정적 분석 도구들 중, 오픈소스로 많이 알려진 SonarQube에 대해서 정리해 보도록 하겠습니다.

 

 

 

 

SonarQube Architecture

 

SonarQube 플랫폼은 4개의 컴포넌트로 구성되어있습니다.

SonarQube Architecture

 

1. SonarQube Server

3가지의 메인 프로세스를 구동시킵니다.

    - Web Server : 사용자들에게 분석 결과를 보여주고, SonarQube 설정 페이지를 제공합니다.

    - Search Server : Elasticsearch 서버를 사용하며, 사용자에게 검색 기능을 제공합니다.

    - Compute Engine Server : 정적 분석 결과를 생성하고 이를 SonarQube Database를 통해 저장합니다.

 

2. SonarQube Database

SonarQube의 기본 설정들(보안, Plugin 정보 등)과 프로젝트 분석 스냅샷들을 저장합니다. 설치 시, 기본으로 H2 DB를 포함하며, 설정을 통해 다양한 DB 사용이 가능합니다.

 

3. SonarQube Plugin

내부에서 사용하는 다양한 기능(분석 프로그램 언어, 권한, 관리, SCM 등)을 플러그인 형태로 설치 가능합니다.

 

4. SonarQube Scanner

프로젝트 정적 분석을 수행하는 툴로 다양한 형식으로 제공되며 CI Server와 연계하여 사용이 가능합니다.

 

 

 

 

SonarQube Integration

 

아래의 그림에서는 SonarQube가 ALM도구들과 어떻게 통합되는지, SonarQube의 다양한 구성요소들이 어떤 식으로 사용되는지 보여줍니다.

SonarQube Integration ( https://docs.sonarqube.org/download/attachments/7997457/SQ55Integration.png)

 

1. 개발자는 IDE에서 코드를 작성하고, Sonar Lint 등을 통해 로컬에서 코드 분석을 실행합니다.

2. 개발자는 분석을 통해 수정된 완성 코드를 SCM으로 Push 합니다.

3. CI서버에서 트리거 된 빌드 수행 시 SonarQube Scanner를 실행합니다.

4. SonarQube Scanner는 생성한 분석 리포트의 처리를 위해 SonarQube로 전송합니다.

5. SonarQube Server는 분석 리포트 결과를 처리하여 DB에 저장하고 결과를 웹서버를 통해 제공합니다.

6. 개발자는 웹페이지에서 분석 결과를 확인하여 코드를 개선합니다.

7. 관리자는 결과 보고서를 받습니다.

    SonarQube에서 데이터를 추출하기 위해 API를 활용하거나 SonarQube Server 모니터링을 위해 JMX를 사용할 수 있습니다.

 

 

 

 

SonarQube 설치하기

 

SonarQube의 설치는 크게 두 가지로 나뉘어 진행됩니다. SonarQube Server, SonarQube Database, SonarQube Plugin을 포함하고 있는 SonarQube 배포본의 설치와 분석 리포트를 생성하여 분석을 시작시키는 SonarQube Scanner의 설치입니다.

 

SonarQube 설치

SonarQube 배포본은 SonarQube 공식 홈페이지에서 다운로드할 수 있으며, 별도의 설치 과정 없이 다운로드한 배포본 압축파일을 원하는 위치에 풀면 됩니다. 본 문서에서는 작성 시 최신 버전인 SonarQube 6.3 버전을 사용했습니다.

SonarQube 다운로드

 

압축 해제된 SonarQube 디렉토리 구조

 

 

SonarQube Scanner 설치

SonarQube Scanner는 다양한 방식으로 제공(현재 총 7가지 방식)하고 있으며, 본인이 익숙한 빌드 툴이나 CI 플러그인 방식을 선택하여 설치하면 됩니다. 본 글에서는 커맨드 라인에서 수동으로 구동시키는 “기본 버전”과 빌드 툴 Gradle을 활용하는 “Gradle 버전”을 설치해 보도록 하겠습니다. (본 글은 SonarQube의 이해에 목적을 두고 있기 때문에 이 두 가지 버전을 선택하였지만, 현장에서는 CI와 연계하여 활용하는 경우가 많기 때문에 Jenkins와 연계하여 구동하는 방식은 "SonarQube + Jenkins + GitLab" 글을 참고바랍니다.)

 

> 기본 버전

SonarQube Scanner 다운로드 페이지에서 본인의 OS에 해당하는 링크를 클릭하여 압축파일을 다운로드합니다. SonarQube와 동일하게 압축을 원하는 위치에 해제합니다.

SonarQube Scanner 기본버전 다운로드

 

압축 해제된 SonarQube Scanner 기본버전

 

참고로, 기본 버전을 편리하게 사용하기 위해서는 SonarQube Scanner의 bin 디렉터리를 Path 에 추가해 주는 것이 좋습니다.

SonarQube Scanner Path 등록

 

 

> Gradle 버전

Gradle이 설치되어 있어야 하며(2.1 이상 버전의 사용을 권장) 빌드 스크립트에 플러그인 사용을 명시합니다. 보다 자세한 설정 정보는 Gradle Plugin 사이트를 참고합니다.

// https://plugins.gradle.org/plugin/org.sonarqubeplugins {
    id "org.sonarqube" version "2.2.1"
}

 

 

SonarQube 서버 및 시스템 구성

• SonarQube 플랫폼은 오직 하나의 SonarQube Server와 SonarQube Database로 구성됩니다.
• 최적의 성능을 위해 각 구성 요소 (서버, 데이터베이스, 스캐너)는 별도의 시스템에 설치해야 하며, 서버 시스템은 별도로 분리되어 운영되어야 합니다.
• SonarQube Scanner는 서버를 추가하여 확장할 수 있습니다.
• 모든 시스템은 시간을 동기화해야 합니다.
• SonarQube Server와 SonarQube Database는 동일한 네트워크로 구성되어야 합니다.
• SonarQube Scanner는 SonarQube Server와 동일한 네트워크로 구성될 필요는 없습니다.
• SonarQube Scanner와 SonarQube Database 사이의 통신은 존재하지 않습니다.

 

요구사항

SonarQube를 실행하기 위한 유일한 전제 조건은 Java (Oracle JRE 8 이상 또는 OpenJDK 8 이상)를 시스템에 설치하는 것입니다. 권장 하드웨어 사양, 지원 브라우저, 지원 DB 등과 같은 자세한 정보는 SonarQube 공식 문서에서 확인할 수 있습니다.

 

 

 

 

SonarQube 사용하여 분석하기

너무나 간단한 설치가 마무리됐으면, 본격적으로 냄새가 나는 코드를 분석해 보도록 하겠습니다. 분석을 위해서는 위에서 설치한 SonarQube Server가 구동되어 있어야 하고, SonarQube Scanner로 분석을 시작시켜야 합니다.

 

SonarQube Server 구동

위에서 설치한 SonarQube 디렉터리 하위의 bin 디렉터리로 이동하면 OS별 디렉터리를 확인할 수 있습니다. 본인의 OS에 해당하는 디렉터리로 이동하여 SonarQube Server를 구동시킵니다. (필자는 Windows 7 64bit 환경에서 구동하였습니다.) Windows의 경우, 직접 구동시키거나 Service 방식의 구동이 가능합니다.

SonarQube Server 디렉토리

 

SonarQube Server 구동

 

서버 구동이 완료되면 브라우저에서 http://127.0.0.1:9000로 SonarQube 웹페이지가 정상적으로 뜨는지 확인할 수 있습니다. 기본으로 생성된 관리자 계정(admin/admin)으로 로그인도 가능합니다.

SonarQube 웹서버 첫 페이지

 

 

서버를 종료(Ctrl+C)할 때는 Compute Engine, Web Server, ElasticSearch 서버가 종료되는 것을 확인할 수 있습니다.

서버의 종료

SonarQube 설정은 SonarQube 홈 디렉터리/conf/sonar.properties 파일에서 수정이 가능하며, DB JDBC 정보, 웹서버 정보 등 다양한 설정이 가능합니다.

 

SonarQube Scanner 분석 시작

SonarQube는 20개 이상의 프로그램 언어 분석이 가능합니다. 기본으로 포함되어있는 언어 이외의 프로그램 언어를 분석하기 위해서는 플러그인 추가가 필요하며, 이중 상용 라이선스를 구매해야 사용이 가능한 것들(아래 그림에서 * 표시)도 있기 때문에 적용 전에 확인이 반드시 필요합니다. 프로그램 언어 플러그인 설치 방법은 뒤에 나오는 사용자 가이드 항목에서 다시 설명하도록 하겠습니다.

분석 가능 언어 목록 ( https://docs.sonarqube.org/display/PLUG/Plugin+Library)

 

Scanner를 통해 분석이 시작되면, 설치된 프로그램 언어 플러그인에서 인식 가능한 소스코드만 분석이 일어나며 해당 분석 리포트(Sources, Issues, Metrics)가 SonarQube Server로 전송됩니다. 분석 리포트는 Compute Engine Server에 의해 처리되어 최종 분석 결과가 DB에 저장됩니다.

코드 분석을 위해 SonarQube Scanner를 구동할 때, 분석할 코드에 대한 정보가 필요하며 이는 매개변수를 통해 Scanner에 전달됩니다. 이 매개변수는 다양한 방식으로 설정이 가능합니다.

• SonarQube Server 웹페이지의 Administration > Configuration > General Settings 화면에 정의된 매개변수는 모든 프로젝트에 적용됩니다.
• SonarQube Server 웹페이지의 Proejct 선택 > Administration > General Settings 화면에 정의된 프로젝트 매개변수는 전역 매개 변수보다 우선합니다.
• 프로젝트 내에 설정된 설정 파일 또는 SonarQube Scanner 설정 파일에 정의된 매개변수는 웹페이지에서 설정한 매개 변수보다 우선합니다.
• SonarQube Scanner 실행 시 입력하는 명령 행 매개 변수는 설정 파일 매개 변수를 대체합니다.

 

매개변수 중 필수 값은 다음과 같습니다. 분석 언어, 소스 디렉터리 등의 다양한 매개변수 정보는 홈페이지의 공식 문서를 참고 바랍니다.

• sonar.host.url
      SonarQube 서버의 URL
• sonar.projectKey
      분석하고자 하는 프로젝트의 고유한 키값
• sonar.sources
      소스 파일이 들어있는 디렉터리

 

실제 분석 작업을 위에서 설치한 두 가지 버전의 SonarQube Scanner를 통해 수행해 보도록 하겠습니다.

 

> 기본 버전
위의 매개변수 내용에서 언급한 대로, SonarQube Scanner 설치 디렉터리 하위의 conf/sonar-scanner.properties 파일을 통해 기본 설정이 가능하며, 분석하고자 하는 프로젝트의 홈 디렉터리에 sonar-project.properties 파일을 생성해서도 설정이 가능합니다. 아래 명령행은 매개변수 방식을 사용해서 Swift 프로젝트를 분석합니다.

// Command Line
$ sonar-scanner -Dsonar.projectKey=mplatform.ios -Dsonar.sources=./MBC_ENT -Dsonar.projectName="Mobile Platform for iOS"   

 

Default SonarQube Scanner 실행 결과

 

 

커맨드 라인 실행 결과 EXECUTION SUCCESS 메시지를 확인하면 성공적으로 분석이 완료된 것입니다. SonarQube 웹서버 페이지(http://127.0.0.1:9000/projects)로 들어가 분석 결과가 정상적으로 보이는지 확인합니다.

분석 결과 페이지 (http://127.0.0.1:9000/dashboard?id=mplatform.ios)

 

 

> Gradle 버전
Gradle을 사용하여 SonarQube Scanner를 구동할 경우, 보다 쉽게 분석 시작이 가능합니다. build.gradle 파일에 매개변수를 properties로 지정한 뒤 Gradle을 수행하면 됩니다. 아래 build.gradle 파일은 안드로이드 프로젝트의 Java 코드를 분석합니다.

// SonarQube Scanner for Gradle의 build.gradle
sonarqube {
    properties {
        property "sonar.projectKey", "mplatform.android" 
        property "sonar.sources", "src/main/java"
        property "sonar.projectName", "Mobile Platform for Android"  
        property "sonar.sourceEncoding", "UTF-8"
    }
}

SonarQube Scanner for Gradle 실행 결과

분석 결과 페이지 (http://127.0.0.1:9000/dashboard?id=mplatform.android)

 

 

 

 

SonarQube 분석 결과 보기

 

SonarQube의 첫 화면은 현재 분석된 다양한 프로젝트들의 주요 지표를 보여주고 있습니다. 제일 중요한 부분은 Quality Gate 값으로, 통과 여부(Pass or Fail)에 따라 프로젝트의 상태를 쉽게 확인할 수 있습니다. 해당 프로젝트 제목을 클릭하여 보다 자세한 정보를 확인할 수 있습니다.

 

SonarQube 첫화면

 

Project

첫 화면에서 특정 프로젝트를 선택하면 SonarQube의 메인화면에 해당하는 프로젝트 화면으로 이동합니다. 프로젝트 화면은 프로젝트 홈페이지를 포함하여 총 6개의 메뉴로 구성되어 있습니다.

 

프로젝트 홈페이지에서는 Quality Gate 통과 여부와 주요 지표에 대한 합계 및 최근 분석 시점에서 발생한 지표를 비교하여 보여줍니다. 해당 지표를 클릭하면 수정해야 할 상세 내용을 보여줍니다(드릴다운 기능).

프로젝트 홈페이지

 

현재 프로젝트에 있는 모든 이슈를 한눈에 보고 싶을 때는 “Issues” 메뉴를 이용하면 됩니다. 화면 좌측의 다양한 필터 옵션을 통해서 원하는 이슈만 찾아서 볼 수도 있습니다.

모든 이슈를 확인 가능한 Issues 화면

 

프로젝트의 분석 결과를 다양한 관점으로 보고 싶을 때는 “Measures” 메뉴를 이용하면 됩니다. Reliability, Security, Duplications 등 다양한 관점의 분석 결과를 주요 지표와 그래프로 보여주며, 해당 문제의 상세 페이지 이동하는 드릴다운 기능을 제공합니다.

다양한 관점의 분석 결과 Measures(Duplications) 화면

 

프로젝트의 디렉터리 구조와 실제 코드를 보고 싶을 때는 “Code” 메뉴를 클릭합니다. 디렉터리나 파일별 주요 지표를 확인 가능합니다. 다른 메뉴와 마찬가지로 드릴다운 기능을 제공합니다.

디렉토리, 파일의 분석 결과를 확인 가능한 Code 화면

 

그밖에 프로젝트의 분석 수행 히스토리를 볼 수 있는 “Activity” 메뉴와 프로젝트 분석을 위한 설정 기능인 “Administration” 메뉴가 있습니다.

분석 수행 히스토리를 확인 가능한 Activity 화면

 

코드 뷰어

드릴다운을 통해 상세 페이지로 이동하면 코드 뷰어가 보입니다. 코드 뷰어에서는 문제의 내용을 보여주고 해결을 위한 가이드를 제공합니다. 중복 코드의 경우 중복된 파일을 별도로 고정시켜 비교도 가능합니다.

 

상단에는 해당 파일의 분석 지표를 요약해서 보여주며, 문제가 발생한 라인에 어떤 문제인지 보다 상세 내용이 표시됩니다.

코드뷰어

 

문제가 발생한 규칙명 옆의 “…”을 클릭하면 규칙에 대한 자세한 설명과 함께 해결을 위한 가이드를 제공합니다. 경험상 Complexity 해결을 위한 리팩터링이 아닌 이상, 대부분의 문제는 제공되는 가이드를 통해 손쉽게 해결이 됩니다.

문제에 해당하는 규칙과 해결 가이드

 

중복 코드가 발견된 경우, 좌측의 코드라인 옆에 주황색 라인으로 표시가 되며, 주황색 라인을 클릭하면 중복된 파일과 라인 정보가 나타납니다. 해당 라인 정보를 클릭하면 하단에 중복된 파일의 내용이 나타나 비교가 가능합니다.

중복 코드에 대한 파일뷰어

 

 

 

SonarQube Tip & Tech

SonarQube 문제 해결 순서

개발자는 다양한 분석 결과 앞에서 당장 무엇을 어떻게 해야 할지 망설이는 경우가 많습니다. 그렇다면 어떤 순서로 문제를 해결하는 것이 좋을까요? SonarQube의 공식 문서에서는 다음과 같은 방법을 권장합니다.

 

 

• 가장 최근에 발생한 문제부터 접근
  프로젝트의 홈페이지 화면에서 가장 최근 분석 결과를 보여주고 있는 우측의 노란 영역에 위치한 문제를 먼저 검토하고 수정합니다. 이후 해결되지 않은 프로젝트 전체에 발생된 문제를 해결합니다.
• Duplication부터 제거
  다양한 품질 지표 중 Duplication을 제거한 뒤 다른 주요 지표를 고치는 방법을 권장합니다.

프로젝트 홈페이지

 

SonarQube 분석 주기

품질 점검이 실패하는 사례를 보면, 프로젝트가 마무리되는 시점에 한 번에 몰아서 진행되는 경우가 대부분입니다.

 

결합도를 최소화 한 코드라 할 지라도 코드의 수정이 다른 코드에 미치는 영향은 시간이 흐를수록 커집니다. 게다가 자신이 짠 코드일지라도 일주일 후에 보면 코드의 분석 시간이 다시 필요해 지기 마련입니다. 결국 뒤늦은 코드의 수정은 큰 비용을 초래하게 됩니다. 무엇 보다도, 코드 수정에 따른 책임 소재가 불분명 해 지는 것이 더 큰 문제입니다.

 

때문에 정적 분석은 가급적 매일 수행되어, 발생된 문제에 대해서는 해당 개발자가 바로 수정할 수 있도록 안내하는 것이 중요합니다.

 

SonarQube Rule & Profile

정적 분석에 사용되는 규칙(Rule)은 언어별 플러그인에서 기본으로 제공합니다. 새로운 분석 언어 플러그인을 설치하면 해당하는 규칙 역시 추가됩니다. SonarQube 페이지 상단의 Rules 메뉴를 통해 설치된 규칙들과 상세 정보(를 확인할 수 있습니다. 좌측의 필터 기능을 통해 원하는 내용만 확인이 가능합니다.

SonarQube — Rules 화면

 

규칙을 클릭하면 상세 내용을 확인할 수 있으며, 내용을 추가하거나 일부 내용(태그, 프로필에 적용된 심각도, 활성화 여부)은 변경이 가능합니다.

Rule 상세 및 수정화면

 

이러한 규칙들을 특정 상황(예, Java를 사용하는 Android 개발)에 맞도록 그룹으로 묶은 것이 품질 프로필(Quality Profile)입니다. SonarQube에서는 기본으로 “Sonar Way”라는 프로필을 제공하고 있습니다.

SonarQube — Quality Profile 화면

 

분석 결과 사용자 메일 발송

문제가 발생한 소스 코드 라인의 마지막 커미터가 사용자가 등록한 이메일 주소 또는 SCM 계정과 동일할 경우 메일이 발송됩니다.

 

이메일을 받기 위해서는, 사용자가 본인의 알림 설정에서 이메일 발송 항목을 지정해야 합니다.

My Account > Notification 설정

 

물론, SonarQube의 설정 화면에서 Email 관련 항목에 SMTP 설정이 되어있어야만 메일이 발송 가능합니다. 필자는 Gmail의 SMTP 서버를 활용하였습니다. (일일 최대 2000개 메일 발송 제한)

Administration > Configuration > General 메뉴를 통한 Email 설정

 

 

커미터가 지정되지 않은 이슈들에 대한 대표 사용자를 지정할 수도 있습니다.

대표 사용자

 

테스트를 위해 Bad Smell이 있는 코드를 작성하여 커밋한 뒤, SonarQube Scanner를 수행하여 정적 분석을 수행하였습니다.

Bad Smell이 존재하는 코드와 해당 커미터

 

해당 커미터의 메일로 이슈 내용이 발송되었으며, 이슈에 대한 상세 설명과 해당 페이지로의 링크가 포함된 메일을 확인할 수 있었습니다.

SonarQube Issue Email 목록

 

SonarQube Issue Email 상세내용

 

 

SonarQube Local 수행

SonarQube Scanner를 통한 주기적 분석 활동 외에, 개발 시점에 미리 문제를 찾아내어 해결하는 방법도 존재합니다. SonarLint를 활용하여 사용하는 IDE 내에서 사전에 문제를 해결하면 이후 문제 해결에 들어가는 비용을 줄일 수 있습니다.

 

이슈 처리 트래킹

프로젝트 내에 JIRA와 같은 이슈 트래킹 시스템이 존재하지 않는다면, SonarQube를 통한 이슈 처리 트래킹도 가능합니다.

Issue 처리 기능

 

 

 

 

SonarQube 분석지표

 

품질 모델

SonarQube에 적용되는 규칙은 신뢰성(버그), 취약성(보안) 및 유지보수 (코드 냄새)라는 세 가지 유형으로 구분이 됩니다. 규칙의 구분 방법은 다음과 같습니다.

 

• 명백하게 틀린 코드에 대한 규칙이거나 잘못된 코드에 관한 규칙입니까? 
  대답이 “예”이면 신뢰성(Reliability, Bug) 규칙입니다. 그렇지 않다면,
  
  
• 해커가 악용할 수 있는 코드에 대한 규칙이거나 CWE , SANS Top 25, OWASP Top 10를 근간으로 하는 규칙입니까?
  그렇다면 취약성(Vulnerability, Security) 규칙입니다. 그렇지 않다면,

• 규칙이 버그도 아니고 취약성도 아닙니까? 
  그렇다면 유지보수성(Maintainability, Code Smell) 규칙입니다.

 

심각도(Serverity)

SonarQube에서는 프로젝트 분석을 위해서 규칙들의 집합인 Quality Profile을 사용하며, 적용된 규칙이 얼마나 심각하고 중요한지 아래와 같이 5가지 수준으로 정의하고 있습니다.

 

• BLOCKER
  프로그램의 동작에 영향을 줄 가능성이 높은 버그로 코드를 즉시 수정해야 합니다.
  ex) 메모리 누출, 닫히지 않은 JDBC 연결 등

• CRITICAL
  프로그램의 동작에 영향을 줄 가능성이 낮은 버그 또는 보안 결함으로 코드를 즉시 검토해야 합니다.
  ex) 비어있는 catch 블록, SQL Injection 등
• MAJOR
  개발자 생산성에 영향을 크게 줄 수 있는 품질 결함으로 시간을 두고 검토해야 합니다.
  ex) 중괄호로 덮여있지 않은 코드, 중복 코드, 사용되지 않은 매개 변수 등

• MINOR
  개발자의 생산성에 잠재적인 영향을 미칠 수 있는 품질 결함입니다.
  ex) 너무 긴 코드, 3개 미만의 switch 문 등

• INFO
  버그이거나 품질상의 결함이 아닙니다. 인지를 위한 알림입니다.

 

품질 모델 등급

• Reliability(Bug)
  > A : 0개 버그
  > B : 1개 이상의 Minor 버그
  > C : 1개 이상의 Major 버그
  > D : 1개 이상의 Critical 버그
  > E : 1개 이상의 Blocker 버그

• Maintainability(Code Smell)
  > A : 추가로 발생한 Technical Debt가 프로그램 전체 Debt의 5 % 이하
  > B : 6 ~ 10 %
  > C : 11 ~ 20 %
  > D : 21 ~ 50 %
  > E : 50 % 이상

• Vulnerability(Security)
  > A : 0개 취약점
  > B : 1개 이상의 Minor 취약점
  > C : 1개 이상의 Major 취약점
  > D : 1개 이상의 Critical 취약점
  > E : 1개 이상의 Blocker 취약점

복잡도(Complexity), 문서화(Documentation, Comment), 중복(Duplication) 등의 주요 수치는 분석 대상(프로그램 언어)에 따라 결과 값이 상이하므로 언어별로 정의한 기준이 존재하며 이에 대한 자세한 정보는 SonarQube 공식 문서의 Metric 정의에서 확인할 수 있습니다.

 

Quality Gate

상단의 Quality Gates 메뉴를 클릭하면 Quality Gate 설정 화면으로 이동합니다. Quality Gate의 결과는 “현재 버전의 프로젝트를 배포해도 됩니까?”라는 질문의 답입니다. 주요 지표의 값에 따라 Pass/Fail 수준을 정의해 사용하면 되며, 설치 시 기본으로 “SonarQube way” 값이 적용되어있습니다.

SonarQube Way Quality Gate

 

 

 

 

마무리 그리고 다음

 

웨이트 효과가 쉽게 눈으로 드러나는 가슴/팔 운동과는 달리, 전신운동인 스쿼트는 단시간에 표면적으로 운동 결과가 나타나지는 않습니다. 자세를 고쳐가며 꾸준한 훈련을 해야만 비로소 몸의 변화를 느낄 수 있고 지속적인 노력을 통해 다른 부위의 운동을 하기 위한 근간을 만들 수 있습니다.

 

 

 

 

 

이는 SonarQube를 활용한 정적 분석에서도 마찬가지입니다. SonarQube는 프로젝트 코드의 품질 관리를 보다 쉽고 빠르게 할 수 있는 훌륭한 도구지만, 이를 제대로 활용하기 위해서는 지속적인 관리가 필요하고 나아가 QA 활동에 대한 정책 및 가이드가 필요합니다.

 

CI를 통해 주기적인 정적 분석과 단위 테스트가 수행되고, 분석 결과를 통해 개발자들이 코드 개선 작업을 부담 없이 할 수 있도록 손쉬운 가이드가 제공되어야 합니다.

 

다음에는 대표적인 CI 도구인 Jenkins와 SonarQube의 연동을 통한 지속적인 정적 분석 작업과 프로젝트에 적용하기 위한 정책 수립에 대해 정리해 보도록 하겠습니다.