Clean Code를 구현하기 위해 Sonarqube로 정적 코드 분석을 해보자

 

 

Sonarqube는 Clean Code를 구현하기 위한 정적 코드 분석 도구입니다.

 

Clean Code란 안전하고, 유지보수가 용이하며, 믿을 수 있는 코드를 뜻하는 Sonarqube에서 정의한 용어입니다. 

 

즉 Sonarqube를 통해서 모범적인 소프트웨어를 만들기 위한 높은 수준의 코드 품질을 유지할 수 있다는 뜻입니다.

 

게다가 CI 파이프라인과의 통합으로 자동화된 코드 리뷰를 수행할 수 있으며, 스크립트나 IaC코드 또한 분석이 가능합니다.

 

이번 포스팅에서는 Sonarqube가 무엇인지, 그리고 Sonarqube의 구축 및 사용 방법을 알아보도록 하겠습니다.

 

 

1. 정적 코드 분석 vs 동적 코드 분석

 

앞서 Sonarqube는 정적 코드 분석을 위한 도구라고 말씀드렸습니다. 정적 코드 분석이란 어떠한 코드 분석을 말하는 걸까요?

 

정적 코드 분석(Static Code Analysis)이란 정적인 환경, 즉 프로그램 런타임이 실행되지 않는 환경에서 코드를 분석하는 방법을 말합니다.

 

이와 반대되는 개념인 동적 코드 분석(Dynamic Code Analysis) 또한 존재합니다. 동적 코드 분석이란 프로그램 런타임이 실행되는 환경에서 진행되는 코드 분석을 말합니다.

 

정적 코드 분석은 소스 코드 기반으로 진행되며, 미리 지정된 규칙(Rule) 셋을 통해 코드를 분석하기 때문에 빠르고 효율적인 방법이라는 장점이 있지만, 런타임이 실행되는 환경에서의 약점을 잡아내지 못한다는 단점이 존재합니다. 

 

하지만 동적 코드 분석은 실행된 코드 기반으로 진행되며, 테스트 케이스 및 입출력을 통해 코드를 분석하기 때문에 실제 프로그램이 구동되는 것과 비슷한 환경에서 코드를 분석할 수 있다는 장점이 있지만, 분석에 많은 리소스와 시간이 소요된다는 단점이 존재합니다.

 

정적 코드 분석과 동적 코드 분석을 비교한 테이블은 아래와 같습니다.

 

특성	정적 코드 분석	동적 코드 분석
분석 대상	소스 코드	실행된 코드
분석 시점	프로그램 컴파일 전	프로그램 컴파일 후
분석 방법	규칙 및 패턴	테스트 케이스, 입출력 결과
장점	빠른 속도, 광범위한 분석 가능	런타임 환경에서 취약점 발견 가능
단점	프로그램의 구조적 취약점 발견 불가	리소스 및 시간 다수 소요, 분석 역량에 큰 영향

 

2. Sonarqube 구축

Sonarqube의 구성요소는 크게 3가지로 나눌 수 있습니다.

 

• Scanner : CI 파이프라인과 통합되어 소스 코드를 분석하기 위한 구성 요소
• Sonarqube Server : Web 인터페이스 제공을 위한 Web Server, 검색을 위한 ElasticSearch 기반 Search Server, 분석 코드 처리를 위한 Compute Engine으로 이루어진 구성 요소
• Database : Sonarqube Server의 설정 및 코드 분석 결과를 DB에 저장하기 위한 구성 요소 

이번 장에서는 Sonarqube 구축에 필요한 위 3가지 구성요소를 생성하는 방법에 대해 알아보겠습니다.

 

2-1. Sonarqube 설치 요구사항

Sonarqube 설치를 위한 Hardware 및 Software 요구사항은 다음과 같습니다.

 

이름	요구 사항	비고
Hardware 요구사항
CPU	8 Core	Compute Engine worker 성능에 영향
Memory	16 GB	DB 및 Elasticsearch 성능에 영향
Software 요구사항
Java Version	17 or above	11 Deprecated
Database	Postgresql : 11 or above mssql : 2014 or above oracle : 19C or above	UTF-8 charset을 사용하도록 구성 필요

 

Sonarqube가 설치될 호스트 Linux 머신의 요구사항은 다음과 같습니다.

 

• vm.max_map_count 값 262144 이상
• fs.file-max 값 65536 이상
• Sonarqube를 실행하는 User 계정은 최소 131072 file descriptors를 열 수 있어야 함
• Sonarqube를 실행하는 User 계정은 최소 8192 threads를 열 수 있어야 함

 

Linux 머신의 요구사항을 확인하는 커맨드는 다음과 같습니다.

sysctl vm.max_map_count
sysctl fs.file-max
ulimit -n
ulimit -u

 

2-2. Sonarqube 설치 및 구성

현재 Sonarqube를 설치하는 방법은 Container화된 이미지와 배포판 파일 2가지로 구분할 수 있습니다.

 

본 포스팅에서는 두 방법 중 배포판 파일을 이용한 방법을 알아보도록 하겠습니다.

 

Java Install

Sonarqube의 요구사항인 Java 17을 설치하기 위해 다음 커맨드를 실행합니다.

sudo yum install java-17-amazon-corretto.x86_64

설치가 완료되면 java -version 커맨드를 통해 설치를 확인할 수 있습니다.

 

Add User

Sonarqube 기동에 필요한 Elasticsearch는 Root 유저로 실행되지 않도록 설정되어 있기 때문에 꼭 Sonarqube 실행용 유저를 생성해야 합니다.

 

Sonarqube 실행용 유저를 생성하기 위해 다음 커맨드를 실행합니다.

sudo adduser --system --no-create-home sonarqube
sudo passwd sonarqube

패스워드까지 설정하면 유저 생성은 완료한 것입니다.

 

Edit Kernal parameter

Sonarqube의 요구사항을 충족하기 위해 Linux 커널 파라미터를 변경합니다.

파라미터 값을 변경하기 위해 다음 커맨드를 실행합니다.

sudo sysctl -w vm.max_map_count=262144
sudo sysctl -w fs.file-max=65536
ulimit -n 131072
ulimit -u 8192

 

위 설정을 영구히 변경하려면 /etc/sysctl.conf 파일에 다음과 같이 변경 사항을 적용합니다.

 

Install Sonarqube

Sonarqube는 현재 글을 작성하는 2020-10-28 기준으로 9.9.2가 LTS 버전입니다.

 

따라서 9.9.2 버전을 설치하는 것을 기준으로 설치 방법을 알아보겠습니다.

 

Sonarqube 9.9.2 버전 배포판을 설치하기 위해 다음 커맨드를 실행합니다.

wget https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-9.9.2.77730.zip
unzip sonarqube-9.9.2.77730.zip
mv sonarqube-9.9.2.77730 /opt/sonarqube
sudo chown -R sonarqube:sonarqube /opt/sonarqube

 

Edit Sonarqube Configuration

Sonarqube의 기동을 위해서는 postgresql, mssql, oracle 중 하나의 DB가 필요합니다.

 

Sonarqube가 사용할 데이터베이스는 미리 생성되어 있어야 합니다.

 

DB가 준비되었다면 DB와의 연결을 구성하기 위해 /opt/sonarqube/conf/sonar.properties 파일을 다음과 같이 수정합니다.

본 포스팅에서는 postgresql을 사용했으며 Sonarqube가 이용할 데이터베이스로 "sonar"를 생성했습니다.

 

Service registration

Sonarqube가 재부팅 후에도 실행될 수 있도록 서비스를 등록합니다.

/etc/systemd/system/sonar.service 파일을 생성한 후 다음과 같이 구성합니다.

[Unit]
Description=SonarQube Server Service
After=syslog.target network.target crowd.service
 
[Service]
Type=forking
User=sonarqube
ExecStart=/opt/sonarqube/bin/linux-x86-64/sonar.sh start
ExecStop=/opt/sonarqube/bin/linux-x86-64/sonar.sh stop
LimitNOFILE=131072
LimitNPROC=8192
 
[Install]
WantedBy=multi-user.target

 

이후 생성한 Sonarqube 서비스를 실행하기 위해 다음 커맨드를 실행합니다.

sudo systemctl enable sonar.service
sudo systemctl start sonar.service

 

모든 절차를 마쳤다면 Sonarqube 프로세스가 정상적으로 실행되는 것을 확인합니다.

 

Web server를 노출하는 Port(default 9000)로 접근하면 아래와 같이 Sonarqube 웹으로 접근할 수 있습니다.

 

 

3. Sonarqube 사용

 

 

Sonarqube를 사용한 코드 분석 절차는 다음과 같습니다.

 

1. 개발자는 코드를 작성한 뒤 Git 등의 SCM 도구에 코드를 저장합니다.
2. CI 파이프라인과 통합된 Sonarqube Scanner가 저장된 코드를 스캔한 뒤 보고서를 생성합니다.
3. Scanner는 스캔 보고서를 Sonarqube Server로 Publish합니다.
4. Sonarqube Server는 보고서를 Database에 저장하고, Web 인터페이스를 통해 접근할 수 있도록 합니다.
5. 개발자는 분석 결과를 확인한 뒤 Code 품질을 개선합니다.
6. 개선할 점을 코드에 반영한 뒤, 1번 절차로 돌아갑니다.

결과적으로 개발자는 코드 작성, 분석 보고서 확인, 개선점 반영이라는 싸이클을 반복함으로써 Clean code를 완성할 수 있습니다.

 

그렇다면 Sonarqube를 사용해서 코드를 분석하기 위해 어떠한 작업을 수행해야 하는지 알아보도록 하겠습니다.

 

3-1. CI 파이프라인 구성

위에서 언급했다시피, Sonarqube는 Git과 연계된 CI 파이프라인을 실행함으로써 코드 분석을 수행합니다.

 

그래서 Sonarqube를 사용하기 위해서는 자신이 사용하는 CI 도구에 따른 파이프라인 구성이 선행되어야 합니다.

 

이번 포스팅에서는 Github의 CI 도구인 Github action을 기반으로 CI 파이프라인을 구성해보겠습니다.

 

Github app 생성

Sonarqube를 Github action과 연계하려면 Github app을 생성해야 합니다.

 

Github의 Github app 생성 페이지에서 다음과 같이 구성합니다.

 

• Github App Name : 사용할 Github app 이름을 지정합니다.
• Homepage URL : 사용할 임의의 URL을 지정합니다.
• Use authorization callback URL : Sonarqube 서버의 엔드포인트를 지정합니다.

 

생성할 Github app의 권한은 아래와 같이 구성합니다.

 

Permission	Access
Repository permission
Checks	Read & Write
Metadata	Read Only
Pull Requests	Read & Write
Private repository permission (Private 레포지토리일 경우 설정)
Contents	Read Only
Organization permission
Members	Read Only
Projects	Read Only

 

3-2. 프로젝트 생성 및 구성

Sonarqube는 프로젝트라는 단위로 각 Git 레포지토리를 관리합니다.

 

Git 레포지토리에 존재하는 코드를 분석하기 위해서는 먼저 해당 레포지토리를 Sonarqube 프로젝트로 등록해야 합니다.

 

Sonarqube 프로젝트를 생성하고 구성하는 방법에 대해 알아보겠습니다.

 

Create Proeject

프로젝트를 생성하기 위해 Sonarqube 웹의 Projects 페이지에서 우측 상단의 Create Project -> Github 순으로 클릭합니다.

 

 

이후 코드를 분석할 레포지토리가 존재하는 Github Organization과 레포지토리 명을 선택하고 우측 상단의 Set up selected repository 버튼을 클릭합니다.

 

 

다음 페이지에서 With Github Actions를 클릭해 Github action으로 CI 파이프라인을 사용하도록 지정합니다.

 

 

다음 페이지에서 Github actions를 연동하기 위한 가이드를 볼 수 있습니다. 

 

 

Github 레포지토리의 Setting 페이지에서 가이드에 표시된 이름과 값을 기반으로 Github Secret을 생성합니다.

 

 

Secret을 등록하고 다음 단계로 넘어가면 작성해야 할 Github workflow 스크립트를 확인할 수 있습니다.

 

빌드 도구를 선택한 뒤 코드를 분석할 레포지토리에 .github/workflows/build.yml 파일을 제시된 스크립트로 생성합니다.

 

이후 정상 동작을 확인하기 위해 코드를 main 브랜치에 Push합니다.

 

Github 레포지토리의 Actions 페이지에서 Action이 실행되는 것을 확인합니다.

 

 

Action이 정상적으로 완료되면 다음과 같이 Sonarqube 웹에서 코드 분석 보고서를 받아볼 수 있습니다.

 

 

 

3-3.  코드 분석

위와 같이 Sonarqube 프로젝트를 생성하면 해당 레포지토리에 코드를 반영할 시 분석 보고서를 받아볼 수 있습니다.

 

분석 보고서에는 지정된 규칙 셋에 따라 소스 코드의 규칙 위반 여부를 확인할 수 있습니다.

 

그렇다면 분석 보고서를 기반으로 어떻게 코드를 수정해야 할지 알아보도록 하겠습니다.

 

 

Analyze report

 코드 분석 보고서가 준비되면 Overview의 Overall Code 탭에서 전체 코드에 대한 분석 결과를 확인할 수 있습니다.

 

아래는 확인할 수 있는 분석 결과들입니다.

 

1. Quality Gate status :
   코드가 일정 수준 이상의 품질을 갖추었는지 판단하는 기준을 나타냅니다.
   Reliability, Security, Security Review, Maintainablity 등의 점수를 기반으로 Pass or Fail을 결정합니다.
    
2. Bugs (Reliability) :
   코드 내의 잠재적인 버그 혹은 실행시간에 예상하지 않은 동작을 하는 코드를 나타냅니다.
   Quality gate의 Reiliablity 랭크에 영향을 미칩니다.
   
   
3. Vulnerabilities (Security) :
   해커들에게 잠재적인 약점이 될 수 있는 보안상의 이슈를 나타냅니다. SQL 인젝션, 크로스 사이트 스크립팅과 같은 보안 취약성을 감지합니다.
   Quality gate의 Security 랭크에 영향을 미칩니다.
   
   
4. Security Hotspots (Security Review) :
   보안에 위협이 될지 여부를 직접 판단해야 하는 코드를 나타냅니다. 리뷰를 통해 보안 위협 여부를 결정할 수 있습니다.
   Quality gate의 Security Review 랭크에 영향을 미칩니다.
   
   
5. Debt :
   Bug, Code smell 등 코드 상의 이슈를 해결하기 위해 필요한 총 시간을 나타냅니다.
   기본값으로 이슈가 있는 코드 1 라인 당 30분의 Debt가 누적됩니다.
   
   
6. Code Smells (Maintainability) :
   심각한 이슈는 아니지만, 코드의 유지 보수 관점에서 악영향을 미칠 수 있는 코드를 나타냅니다. 
   Qulity gate의 Maintainability 랭크에 영향을 미칩니다.
7. Unit test :
   단위테스트 커버리지를 통해 단위 테스트의 수행 정도와 수행한 테스트의 성공/실패 정보를 나타냅니다.
   
   
8. Duplicated code :
   중복 라인, 중복 블록, 중복 파일 등 중복되는 코드를 나타냅니다.

 

Overall Code 좌측의 New Code 탭에서는 추가적으로 커밋한 코드 라인에 대해서만 분석한 결과 보고서를 확인할 수 있습니다.

 

 

Issues

Sonarqube 프로젝트의 Issues 탭에서는 현재 프로젝트에 존재하는 이슈들의 리스트를 타입 별로 확인할 수 있습니다.

 

이슈는 심각도, 태그, 상태 등의 값에 따라 필터링하거나 나에게 할당된 이슈만 확인할 수 있습니다.

 

각 이슈를 클릭하면 이슈 페이지로 접근할 수 있습니다. 

 

이슈 페이지에서는 다음과 같은 사항들을 확인할 수 있습니다.

1. Type :
   현재 이슈의 타입을 나타냅니다.
   타입은 Bug, Vulnerability, Code smell 가 존재하며 이슈에 따라 자동으로 지정됩니다.
   
   
2. Severity :
   현재 이슈의 심각도를 나타냅니다. 심각도는 코드가 소프트웨어의 퀄리티에 미치는 영향에 따라 결정됩니다.
   심각도는 높은 순으로 Blocker, Critical, Major, Minor, Info가 존재합니다.
   
   
3. Status :
   현재 이슈의 상태를 나타냅니다. 이슈의 Flow에 따라 여러가지 상태를 가질 수 있습니다.
   
   
4. Assigned User :
   현재 이슈에 할당된 유저를 나타냅니다. 기본적으로 Not assigned 값을 가집니다.
   해당 이슈의 코드를 커밋한 유저가 Sonarqube 유저 ID와 동일한 경우, 해당 유저에게 자동으로 이슈가 할당됩니다.
   
   
5. Issue :
   현재 이슈가 발생한 원인이 되는 코드를 나타냅니다.
   상단의 Why is this an issue? 탭을 클릭하면 해당 이슈가 문제되는 이유 및 이슈 해결 방법을 확인할 수 있습니다.

 

Issue status

 

Clean Code를 구현하기 위해서는 발생한 이슈들이 어떤 상태에 있는지 확인해야 합니다.

 

이 이슈들이 어떤 상태를 가질 수 있는지 알아보겠습니다.

새로 생성된 이슈는 아래 상태(Status) 중 하나를 가집니다.

• Open: 이슈 생성 시 Sonarqube에 의해 자동으로 할당되는 상태입니다.
• Confirmed: 해당 이슈가 존재함을 확인했음을 나타내는 수동으로 할당되는 상태입니다.
• Resolved: 해당 이슈를 해결했으며 다음 분석 때 Close되어야 함을 나타내는 수동으로 할당되는 상태입니다.
• Reopened: Resolved 상태의 이슈가 분석 때 해결되지 않았을 시 Sonarqube에 의해 자동으로 할당되는 상태입니다.
• Closed: 이슈가 처리되었을시 Sonarqube에 의해 자동으로 할당되는 상태입니다.

 

Closed된 이슈는 아래 해결(Resolution) 중 하나를 가집니다.

• Fixed: 분석 결과 이슈가 해결되었거나 해당 파일이 더이상 사용 불가능한 상태일때 Sonarqube에 의해 자동으로 할당되는 해결입니다.
• Removed: 해당 이슈와 관련된 Rule이 더 이상 사용 불가능할때 Sonarqube에 의해 자동으로 할당되는 해결입니다.

 

Resolved된 이슈는 아래 해결(Resolution) 중 하나를 가집니다.

• False Positive: 해당 이슈가 문제되지 않음을 나타내는 수동으로 할당되는 해결입니다.
• Won't Fix: 해당 이슈를 고치지 않을 것임을 나타내는 수동으로 할당되는 해결입니다.

 

Issue workflow

위와 같이 여러 상태를 가지는 이슈들을 상태에 따라 처리할 수 있습니다.

 

이슈를 처리하기 위해서는 Issue Workflow에 따른 프로세스를 진행해야 합니다.

 

이슈가 생성됨 

• Confirm: 해당 이슈를 인지하고 문제될 여지가 존재한다면 Confirmed 상태로 이슈를 변경합니다.
• False Positive: 문맥에 비춰 봤을때 해당 이슈가 문제될 여지가 없다면 False Positive를 선택해 Resolved 상태로 이슈를 변경합니다.
  이 행동은 프로젝트에 Administer Issues 권한이 존재하는 유저만 수행 가능합니다.
• Severity change: Sonarqube가 자동으로 할당한 Serverity가 실제 문제의 심각도와 다르다면 Serverity를 변경합니다.
  이 행동은 프로젝트에 Administer Issues 권한이 존재하는 유저만 수행 가능합니다. 
• Won't Fix: 문맥에 비춰 봤을때 해당 이슈를 고치지 않을 것이라면 Won’t fix를 선택해 Resolved 상태로 이슈를 변경합니다. 이는 해당 이슈로 인해 누적되는 기술적 부채를 받아드리겠음을 의미합니다.
  이 행동은 프로젝트에 Administer Issues 권한이 존재하는 유저만 수행 가능합니다. 
• Fixed: 해당 이슈를 고쳤다고 생각하면 Fixed를 선택해 Resolve 상태로 이슈를 변경합니다. 실제로 이슈가 해결됐다면 다음 분석때 Closed 상태로 변경됩니다. 해결되지 않았다면 다음 분석때 re-opened 상태로 변경됩니다.

 

이슈가 Confirmed됨

• False Positive: Confirm된 이슈가 문제될 여지가 없다면 False Positive를 선택해 Resolved 상태로 이슈를 변경합니다.
• Won't Fix: Confirm된 이슈를 고치지 않을 것이라면 Won’t fix를 선택해 Resolved 상태로 이슈를 변경합니다. 이는 해당 이슈로 인해 누적되는 기술적 부채를 받아드리겠음을 의미합니다.
• Fixed: Confirm된 이슈를 고쳤다고 생각하면 Fixed를 선택해 Resolve 상태로 이슈를 변경합니다. 실제로 이슈가 해결됐다면 다음 분석때 Closed 상태로 변경됩니다. 해결되지 않았다면 다음 분석때 re-opened 상태로 변경됩니다.
• Unconfirm: Confirm된 이슈를 다시 검토해야 된다면 Unconfirm을 선택해 Open 상태로 이슈를 변경합니다.

 

이슈가 Resolved됨 

• Reopen : 해당 이슈를 다시 리뷰해야 할 필요성이 있다면 Reopen을 선택해 Open 상태로 이슈를 변경합니다.

 

이슈를 발생한 코드가 처리됨

• 처리된 이슈는 자동으로 Closed(Fixed) 상태로 변경됩니다.

 

 

4.  추가 기능 사용

현재 Sonarqube는 코드 분석을 더 편리하게 도와주는 다양한 기능들을 제공하고 있습니다.

 

이 기능들을 통해 Sonarqube를 더욱 풍부하게 사용할 수 있습니다.

 

이번 포스팅에서는 중요한 추가 기능 몇 가지만 다뤄보도록 하겠습니다.

 

4-1. Sonarllint

Sonarlint는 Sonarqube과 통합된 IDE Extension입니다.

Sonarlint를 통해 선제적으로 코드가 Clean Code를 준수하는지 확인할 수 있습니다.

 

그 외에 Sonarlint를 사용하면 다음과 같은 이점을 얻을 수 있습니다.

• IDE에서 코드 작성 시에 이슈와 관련된 즉각적인 피드백을 받을 수 있습니다.
• Sonarqube에서 적용한 Quality gates, Quality profiles, custom analyze setting 등의 설정을 IDE에서 공유받을 수 있습니다.
• “won’t fix”, 혹은 “false positive”로 표시된 이슈는 Sonarlint에서 제외할 수 있습니다.

 

Sonarlint를 설정하기 위해 사용 중인 IDE에서 SonarLint Extension을 설치합니다.

 

 

설치 후 Sonarlint 탭에서 Add Sonarqube Connection을 클릭합니다.

 

 

Server URL에 Sonarqube 엔드포인트 주소를 입력한 뒤, Generate Token 버튼을 클릭해 생성한 토큰을 입력합니다.

 

 

Save Connection을 클릭해 연결을 마무리한 뒤, 코드를 분석하고자 하는 레포지토리에서 연결된 Sonarqube의 + 버튼을 클릭합니다.

 

이후 연결하고자 하는 Sonarqube 프로젝트를 선택합니다.

 

 

정상적으로 설정이 완료되었다면 IDE의 Suggestion에서 Sonarqube의 규칙을 확인할 수 있습니다.

 

 

4-2. Email 알림

Sonarqube의 설정을 통해 이슈가 새로 등록되었거나 나에게 할당된 이슈의 상태가 변경되는 등의 이벤트를 이메일로 알림받을 수 있습니다.

 

이메일 알림을 위해서는 SMTP 설정을 구성해야 합니다.

 

Adminisration -> General의 Email 섹션에서 SMTP 설정을 확인할 수 있습니다.

 

 

위 설정 창에서 Sonarqube가 이메일을 발신하기 위한 SMTP를 구성할 수 있습니다.

 

Gmail을 이용한 SMTP를 구성하고자 할 시 아래와 같이 구성합니다.

 

속성	값	비고
SMTP Host	smtp.gmail.com	gmail은 smtp.gmail.com 호스트 사용
SMTP Port	587	TLS SMTP 포트
Secure Connection	SSL/TLS	Gmail SMTP는 TLS 필수
SMTP Username	Email Address	메일 발신에 사용할 Gmail 계정
SMTP Password	App Password	계정 비밀번호가 아닌 App Password를 발급받아 사용

 

 

알림을 받기 위한 개인 이메일 알림 설정은 Account 페이지의 Notification 탭에서 구성할 수 있습니다.

 

 

이메일 알림 설정이 완료되었다면 이벤트가 발생할 시 아래와 같이 이메일 알림을 받을 수 있습니다.

 

 

 

5.  마치며

지금까지 정적 코드 분석을 위한 도구 Sonarqube를 사용하는 방법에 대해서 알아봤습니다.

 

이번 포스팅에서는 Sonarqube의 정적 코드 분석이 무엇인지, Sonarqube의 구축 및 사용 방법, 마지막으로 Sonarqube의 추가 기능까지 확인할 수 있었습니다.

 

안전한 프로그램을 위한 Clean Code를 구현하기 위해서는 Sonarqube와 같은 정적 코드 분석을 사용하는 것이 바람직할 것입니다. 

 

이 포스팅을 보시는 분들이 Sonarqube 구축 및 사용에 도움을 받으셨으면 합니다.