소스 정적 분석도구 SonarQube

v9.9 리뉴얼 

SonarQube 관련글은 이미 두 번이나 작성했지만 다시 한번 글을 판다.

최근 새로운 플랫폼을 기획하면서 SonarQube를 다시 설치할 일이 생겼는데, 메이저 버전이 10이 됐더라. 처음 SonarQube를 적용한 게 v2.6이었는데... 시간이 참 빠르다.

이전 글을 기반으로 가장 최신 LTS 버전인 v9.9에 맞는 내용들로 업데이트한다.

---

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

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

본 글에서는, 
SonarQube의 구성부터 실제 프로젝트에 적용하기까지 SonarQube(v10.0)를 통한 정적 분석 과정을 아래의 순서대로 정리해 보고자 한다.

왜 정적 분석인가?

SonarQube Component

SonarQube Integration

SonarQube 설치하기

SonarQube 분석 결과 보기

SonarQube 분석지표

SonarQube Tip & Tech

마무리 그리고 다음

왜 정적 분석인가?

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

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

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

스쿼트의 잘못된 자세

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

그렇다면 어떻게 “제.대.로” 할 수 있을까? 

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

헬스의 정석 시리즈 — 수피

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

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

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

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

몹 프로그래밍의 잘못된 예

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

본 글에서는 개발자의 역량 향상과 미래의 장애 발생 확률을 줄이는 정적 분석 도구들 중, SonarQube에 대해서 정리한다.

SonarQube Component

SonarQube는 3개의 컴포넌트로 구성된다.

1. SonarQube Server

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

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

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

    - Compute Engine : 정적 분석 결과를 생성하고 이를 SonarQube Database에 저장

2. Database Server

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

3. Scanner

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

SonarQube Integration

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

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

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

3. CI서버에서 트리거 된 빌드 수행 시 Scanner를 실행하고 결과를 SonarQube로 전송한다.

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

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

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

SonarQube 설치하기

SonarQube의 설치는 크게 세 가지로 구분된다. Database Server, SonarQube Server 그리고 분석을 시작하는 Scanner의 설치다. 예전 글들이 윈도우 환경의 설치를 다뤘기 때문에, 이번에는 리눅스 환경에서 진행한다.(ubuntu 22.04 기반)

SonarQube의 권장스펙(스프트웨어, 하드웨어)은 하기 링크를 참고한다.

- 사전 요구사항 : https://docs.sonarqube.org/9.9/requirements/prerequisites-and-overview/

- 하드웨어 추천 스펙 : https://docs.sonarqube.org/9.9/requirements/hardware-recommendations/

Database Server 설치

과거 SonarQube는 기본으로 H2 DB가 포함되었지만 최근 버전은 별도로 설치를 해야 한다. 현재 지원 가능한 DB는 Oracle, MS SQL Server, PostgreSQL이다. MySQL은 성능과 확장성을 고려하여 더 이상 지원하지 않는다.(MySQL을 사용하려면 v9.4 이하 버전 사용)

Ubuntu 22.04에서 PostgreSQL을 설치하고 설정하는 방법은 다음과 같다.

1. PostgreSQL 패키지 설치 (https://www.postgresql.org/download/linux/ubuntu/)

# Create the file repository configuration:
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

# Import the repository signing key:
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

# Update the package lists:
sudo apt-get update

# Install the latest version of PostgreSQL.
sudo apt-get -y install postgresql

2. PostgreSQL 서비스 상태 확인

sudo systemctl status postgresql

3. PostgreSQL로 로그인

PostgreSQL은 설치 시 자동으로 `postgres` 사용자를 생성한다. 이 사용자를 이용해 PostgreSQL에 로그인한다.

sudo su - postgres

4. SonarQube를 위한 데이터베이스와 사용자 생성

psql

CREATE DATABASE sonarqube OWNER sonarqube;
CREATE USER sonarqube WITH ENCRYPTED PASSWORD '비밀번호';
GRANT ALL PRIVILEGES ON DATABASE sonarqube TO sonarqube;

5. 외부 접속을 위한 처리 (optional)

sudo su - postgres

vi /etc/postgresql/<버전>/main/postgresql.conf 
   listen_addresses = '*'

vi /etc/postgresql/10/main/pg_hba.conf
    host    all             all             0.0.0.0/0               scram-sha-256

PostgreSQL이 설치됐고 SonarQube 데이터베이스와 사용자도 생성됐다.

이후 설치하는 SonarQube에서 이 데이터베이스 정보를 사용한다.

SonarQube Server 설치

1. 설치에 앞서, SonarQube의 기반인 Java 설치를 먼저 진행한다.(이미 설치되어 있는 경우 생략한다.)

sudo apt update
sudo apt upgrade
sudo apt install openjdk-17-jdk

2. SonarQube는 root 사용자로 실행하면 안 되므로, 별도의 유저를 생한다.

sudo useradd -b /opt/sonarqube -s /bin/bash sonarqube

3. 커널 매개변수 max_map_count, file-max를 추가한다.

sudo vi /etc/sysctl.conf

vm.max_map_count=524288
fs.file-max=131072

sudo sysctl --system

4. ulimit 구성을 추가한다.

sudo vi /etc/security/limits.conf

sonarqube   -   nofile   131072
sonarqube   -   nproc    8192

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

https://www.sonarsource.com/products/sonarqube/downloads/success-download-community-edition/

sudo apt install unzip software-properties-common wget

wget https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-9.9.1.69595.zip

unzip sonarqube-*.zip
rm -f sonarqube-*.zip

sudo mv sonarqube-* /opt/sonarqube

6. SonarQube는 root 사용자로 실행하면 안 되므로, 위에서 생성한 sonarqube 계정으로 권한을 부여한다.

sudo chown -R sonarqube:sonarqube /opt/sonarqube

7. SonarQube에서 사용할 DB 정보를 설정한다. 위에서 설치한 Database 정보를 입력한다.

sudo vi /opt/sonarqube/conf/sonar.properties

sonar.jdbc.username=sonarqube
sonar.jdbc.password=비밀번호
sonar.jdbc.url=jdbc:postgresql://서버IP:5432/sonarqube

8. SonarQube에서 사용할 ElasticSearch 메모리를 설정한다.

sonar.search.javaOpts=-Xmx512m -Xms512m -XX:MaxDirectMemorySize=256m -XX:+HeapDumpOnOutOfMemoryError

nar.jdbc.username=sonarqube sonar.jdbc.password=your_secure_password 

9. SonarQube 서비스를 생성하고 활성화한다.

sudo vi /etc/systemd/system/sonarqube.service

[Unit]
Description=SonarQube service
After=syslog.target network.target

[Service]
Type=forking
ExecStart=/opt/sonarqube/bin/linux-x86-64/sonar.sh start
ExecStop=/opt/sonarqube/bin/linux-x86-64/sonar.sh stop
User=sonarqube
Group=sonarqube
LimitNOFILE=131072
LimitNPROC=8192

[Install]
WantedBy=multi-user.target

sudo systemctl start sonarqube
sudo systemctl enable sonarqube

10. 브라우저에서 SonarQube 웹 서비스가 정상적으로 동작하는지 확인한다. (실 운영환경에서는 리버스 프록시 적용을 추천한다.)

URL : http://서버IP:9000
기본 계정 : admin/admin

SonarQube Rules

11. 리버스 프록시 설정을 통해 보안을 강화한다.(optional)

sudo apt install nginx

sudo vi /opt/sonarqube/conf/sonar.properties

sonar.web.host=127.0.0.1
sonar.web.port=9000
sonar.web.javaAdditionalOpts=-server


sudo vi /etc/nginx/sites-available/sonarqube.conf

# nginx 설정내용
server {
    listen 80;
    server_name 도메인;
    access_log /var/log/nginx/sonarqube.access.log;
    error_log /var/log/nginx/sonarqube.error.log;
    proxy_buffers 16 64k;
    proxy_buffer_size 128k;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto http;
    }
}

sudo ln -s /etc/nginx/sites-available/sonarqube.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

Scanner 설치

SonarQube Scanner는 다양한 방식으로 제공하고 있으며, 본인이 익숙한 빌드 툴이나 CI 플러그인 방식을 선택하면 된다. 본 글에서는 GitHub Actions을 사용한다. (예전처럼 별도로 CI 서버를 설치해야 하는 노력이 필요 없다. 깃헙 만세 -_ -b)

다른 방식은 이전에 작성했던 글에서 다룬 바 있다.

- CLI, Gradle 방식 : https://brunch.co.kr/@joypinkgom/43

- CI 방식 : https://brunch.co.kr/@joypinkgom/45

https://docs.sonarqube.org/9.9/analyzing-source-code/overview/

1. SonarQube에서 프로젝트 생성

GitHub에서 직접 프로젝트를 생성하는 옵션이 존재하지만, 여기서는 "Manually"를 선택하여 직접 프로젝트를 생성한다.

프로젝트 이름을 지정하면 프로젝트 키는 자동으로 설정된다. 분석을 원하는 GitHub 리파지토리의 메인 브랜치 이름도 설정한다. 참고로 무료버전인 SonarQube Community Edition에서는 기본 브랜치만 분석이 가능하다. 복수 브랜치는 Developer Edition 이상에서만 가능하다.

소스코드를 어떻게 분석할지 방법을 선택한다. 위에서 언급한 대로 GitHub Actions 기능을 선택한다.

2. GitHub Actions에서 분석을 시작하기 때문에 GitHub 설정이 필요하다. SonarQube에서는 이후 설정방법을 무작정 따라 하면 될 정도로 친절하게 설명해 준다.

GitHub Repositoy의 Setting 메뉴에서 Actions에서 사용할 두 개의 변수(SONAR_TOKEN, SONAR_HOST_URL)를 설정한다. 토큰은 화면에서 "Generate a token" 버튼을 통해 생성 가능하다.

프로젝트 루트에 Scanner가 참조할 sonar-project.properties 파일을 추가하고 제공하는 내용을 입력한다. 이후 GitHub의 Actions 메뉴에서 workflow 파일을 아래의 내용을 복사하여 추가한다. (프로젝트 루트에 .github/workflows 디렉토리를 만들고 그 안에 yml 파일을 생성해도 되지만 그보다는 Actions 화면에서 "New workflow" 버튼을 클릭하는 걸 추천한다.

3. 설정이 끝나면 Actions이 자동으로 실행된다. 실행결과는 Actions 화면에서 아래처럼 확인이 가능하다. 

메인 브랜치의 소스가 변경(push, PR등)되면 Scanner를 실행하여 분석결과를 SonarQube에서 확인할 수 있다.

SonarQube 분석 결과 보기

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

SonarQube Projects

Projects

첫 화면에서 특정 프로젝트를 선택하면 SonarQube의 메인화면에 해당하는 프로젝트 화면으로 이동한다. 프로젝트 화면은 프로젝트 Overview를 포함, 총 6개의 메뉴로 구성되어 있다.

Overview에서는 Quality Gate 통과 여부와 주요 지표에 대한 합계를 최근 분석과 전체로 구분하여 보여준다. 해당 지표를 클릭하면 수정해야 할 상세 내용을 보여준다(드릴다운 기능).

프로젝트 Overview

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

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

보안에 위협이 될 수 있는 분석 결과를 보고 싶을 때는 "Security Hotspot" 메뉴를 사용한다.

Security Hotspot 화면

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

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

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

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

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

코드 뷰어

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

상단에는 해당 파일의 분석 지표를 요약해서 보여주며, 문제가 발생한 라인이 어떤 문제인지 상세 내용으로 표시된다. SonarQube 버전별로 화면이 조금씩 다를 수 있지만 내용은 크게 다르지 않다.

“Why is this an issue”을 클릭하면 규칙에 대한 자세한 설명과 함께 해결을 위한 가이드를 제공한다. 경험상 Complexity 해결을 위한 리팩토링이 아니면, 대부분의 문제는 제공되는 가이드를 통해 손쉽게 해결이 된다.

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

중복 코드에 대한 파일뷰어

SonarQube 분석지표

SonarQube가 코드를 분석(정적 테스트)하기 위해서는 언어별 규칙과 이에 해당하는 지표가 존재한다. 어떤 기준으로 분석을 수행하는지 살펴보자.

품질 모델

SonarQube에 적용되는 규칙은 신뢰성(버그), 보안성(취약점), 보안 검토성(보안 핫스팟), 유지보수성(코드냄새), 이라는 네 가지 유형으로 구분된다. 규칙의 구분 방법은 다음과 같다.

명백하게 틀린 코드에 대한 규칙이거나 잘못된 코드에 관한 규칙입니까? 

대답이 “예”이면 신뢰성(Reliability, Bug) 규칙이다. 그렇지 않다면,

해커가 악용할 수 있는 코드에 대한 규칙이거나 CWE , SANS Top 25, OWASP Top 10를 근간으로 하는 규칙입니까?

그렇다면 보안성(Security, Vulnerability) 규칙이다. 그렇지 않다면,

규칙이 신뢰성도 아니고 보안성도 아닙니까? 

그렇다면 유지보수성(Maintainability, Code Smell) 또는 보안 검토성(Security review, Security Hotspot) 규칙이다.

Vulnerability와 Security Hotspot의 차이점은, 'Vulnerabilities'가 실제 및 긴급한 보안 위협을 나타내는 반면, 'Security Hotspots'는 주의가 필요한 잠재적인 보안 이슈를 나타낸다.

심각도(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 % 이상

Security(Vulnerability)

> A : 0개 취약점

> B : 1개 이상의 Minor 취약점

> C : 1개 이상의 Major 취약점

> D : 1개 이상의 Critical 취약점

> E : 1개 이상의 Blocker 취약점

Security Review(Security Hotspot)

> A : 검토(Acknowledged/Fixed/Safe)된 Security Hotspot 비율이 80% 이상

> B : 70% and <80%

> C : >= 50% and <70%

> D : >= 30% and <50%

> E : < 30%

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

Quality Gate

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

SonarQube Way Quality Gate

SonarQube Tip & Tech

SonarQube 문제 해결 순서

일반적으로 처음 SonarQube를 접하는 개발자는 다양한 분석 결과 앞에서 당장 무엇부터 해야 할지 당황스러워한다. 그렇다면 어떤 순서로 문제를 해결하는 것이 좋을까? SonarQube의 공식 문서에서는 다음과 같은 방법을 권장한다.

가장 최근에 발생한 문제부터 접근

프로젝트 화면에서 가장 최근 분석 결과를 보여주고 있는 탭에 위치한 문제를 먼저 검토하고 수정한다. 이후 해결되지 않은 프로젝트 전체에 발생된 문제를 해결한다.

Duplication부터 제거

다양한 품질 지표 중 Duplication을 제거한 뒤 다른 주요 지표를 고치는 방법을 권장한다. Duplicated Code를 수정하다 보면 새로운 이슈들이 생겨난다. 당황하지 말자 @_@

SonarQube 분석 주기

품질 점검이 실패하는 사례를 보면, 프로젝트가 마무리되는 시점에 한 번에 몰아서 진행하는 경우가 대부분이다. 결합도를 최소화 한 코드라 할지라도 코드의 수정이 다른 코드에 미치는 영향은 시간이 흐를수록 커진다. 게다가 자신이 짠 코드일지라도 일주일 후에 보면 코드의 분석이 다시 필요해지기 마련이다. 결국 뒤늦은 코드의 수정은 큰 비용을 초래하게 된다. 무엇보다 코드 수정에 따른 책임 소재가 불분명 해 지는 것이 더 큰 문제다.

때문에 정적 테스트는 가급적 매일 수행되어야 하고 발생한 문제에 대해서는 해당 개발자가 바로 수정할 수 있도록 안내하는 것이 중요하다.

SonarQube Rule & Profile

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

SonarQube — Rules

규칙을 클릭하면 상세 내용을 확인할 수 있으며, 내용 혹은 태그를 추가할 수 있다.

Rule 상세 및 수정화면

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

SonarQube — Quality Profile 화면

분석 결과 사용자 메일 발송

문제가 발생한 코드의 마지막 커미터 정보가 SonarQube 사용자의 이메일 주소 또는 SCM 계정과 동일할 경우 메일이 발송된다.

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

My Account > Notification 설정

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

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

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

대표 사용자

테스트를 위해 Bad Smell이 있는 코드를 Push 하여 Github에 Action으로 정적 분석을 수행했다.

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

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

SonarQube Issue Email 목록

SonarQube Local 수행

SonarQube Scanner를 통한 주기적 분석 활동 외에, 개발 시점에 미리 문제를 찾아내어 해결하는 방법도 존재한다. SonarLint를 활용하면, IDE 내에서 사전에 문제를 해결할 수 있다. 

SonarLint

본인이 사용하는 IDE에 위 페이지의 linter를 설치하면 프로그램 코드를 분석하여 해결 방법을 안내해 준다. 

이슈 처리 트래킹

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

Issue 처리 기능

Trouble Shootings

'솔루션 설치가 이렇게 복잡한 일이야?...' 처음도 아닌데 SonarQube 설치에 시행착오를 많이 겪었다. 물론 5년이 지나긴 했지만... 그래도 그래봐야 솔루션 설친데 이렇게 고생할 줄이야;;; 그 내용들을 정리한다.

소나큐브 로그가 웹, 검색엔진, 내부엔진 등으로 나뉘다 보니, 시스템 구동 시 발생하는 에러 찾는 게 직관적이지 않다. 그래서 고생하더라. 때문에, 서비스 생성할 때 재실행 옵션은 빼는 걸로;; 로그 보기 너무 어렵다.

Restart=always

잊지 말자. DB 생성은 반드시 소유자 권한 부여해야 한다. 

CREATE DATABASE sonarqube OWNER sonarqube;

서버가 정상적으로 구동되지 않을 경우, 로그 디렉토리(logs)에서 sonar.log, es.log, web.log 순서대로 확인한다. 순서대로 컴퓨트엔진/검색엔진/웹서버로그기록으로, 위에도 밝혔듯 로그가 분산되어 있어서 모두 열어봐야 버그를 잡기 수월하다.

권장 JDK는 반드시 준수하자. JDK 마이너 버전까지 체크한다. 가급적이면 최신 버전의 JDK로 설치해야 고생을 안 한다.

SONAR_HOST_URL 값이 HTTPS로 설정된 경우, action이 수행되는 GitHub의 서버에서 호출 문제가 발생한다. 별도의 인증서 설정 혹은 인증 무시 설정이 필요한데, 필자는 내부 사용이므로 http로 사용했다.(맞다. 귀차니즘이다.)

GitHub Actions 연동을 위해 SonarQube에서 생성하는 토큰값은 다른 곳에 꼭 저장하자. GitHub에 저장해도 다시 찾아볼 방법이 없다.

마무리

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

이는 SonarQube를 활용한 정적 분석에서도 마찬가지다. SonarQube는 프로젝트 코드의 품질 관리를 보다 쉽고 빠르게 할 수 있는 훌륭한 도구지만, 이를 제대로 활용하기 위해서는 지속적인 관리가 필요하고 나아가 QA 활동에 대한 정책 및 가이드가 필요하다. 무엇보다 분석 결과를 통해 개발자들이 부담 없이 코드 개선을 할 수 있는 문화를 조성해야 한다.