SonarQube 를 사용해보자.(About and using SonarQube)

개발을 하다보면 코드 품질을 챙기라는(?) 지시를 받는 경우가 종종 생긴다. 물론 개발자들이 알아서 기술부채(?)에 대한 고민을 하면서 이를 처리 하기 위해서 코드 리팩토링을 하면서 코드 품질을 챙기는 경우도 있다. 하지만, 내가 경험한 대부분의 경우는 회사의 프로세스에 의해 코드 품질을 챙기는 경우가 많다. 이런 경우 가장 많이 사용하는 것이 소나큐브(SonarQube)라는 정적 코드 분석 도구이다.

이런 소나큐브는 WIKI 에서 아래와 같이 설명해주고 있다.

소나큐브(SonarQube, 이전 이름: 소나/Sonar)는 20개 이상의 프로그래밍 언어에서 버그, 코드 스멜, 보안 취약점을 발견할 목적으로 정적 코드 분석으로 자동 리뷰를 수행하기 위한 지속적인 코드 품질 검사용 오픈 소스 플랫폼이다. 소나소스(SonarSource)가 개발하였다. 소나큐브는 중복 코드, 코딩 표준, 유닛 테스트, 코드 커버리지, 코드 복잡도, 주석, 버그 및 보안 취약점의 보고서를 제공한다.

이렇게 좋은 SonarQube 를 사용하려면 돈을 내야 할것 같아서 걱정이 되겠지만, 다행이도 우리는 Community Edition 을 이용하여 무료로 이용이 가능합니다. 하지만, 지원 언어와 기능이 다르기 때문에 아래 내용을 보고 필요한 경우 라이센스를 구매하여 사용하면 됩니다. 하지만, 보통 많이 사용하는 js, java, python 등과 같은 경우는 무료로 사용 가능한 Community Edition 을 이용할 수 있습니다.

SonarQube 를 사용하면 지속적인 코드 품질 가시화가 가능하다고 이야기하는데, 사실 여기까지를 생각하고 사용하기 보단 빠르게 Code Smell 이나 Bug 를 찾아 고치는데 큰 의미가 있다고 생각합니다.

SonarQube 구성

SonarQube 는 아래와 같은 구성을 갖습니다.
1) SonarQube Server : SonarQube Scanner 로 업로드한 소스 코드 분석
2) SonarQube Database : SonarQube 분석 결과 저장
3) SonarQube Scanner : SonarQube 분석을 위해 소스 코드 업로드

SonarQube 를 구성하려면 Docker 로 SonarQube Server(Community Edition) 만 실행해도 되지만, 이런 경우는 SonarQube 분석 결과는 로컬 H2 에 저장이 됩니다. 하지만, 이런 경우는 추후 SonarQube 버전 변경시 분석 결과가 다 사라지므로, PostgreSql 을 함께 구성하겠습니다.

1) 아래와 같은 docker-compose.yaml 파일을 생성합니다.

2) docker-compose 로 SonarQube 를 실행합니다.

$ docker-compose up -d 

3) SonarQube(http://localhost:39270) 으로 접속합니다. ID/PW 는 admin/admin 입니다.

4) SonarQube Scanner 에서 사용할 token 을 생성합니다.

SonarQube Scanner 로 분석 하기

보통 SonarQube 서버에 코드를 업로드하는 것은 Jenkins 나 Github Action 을 이용하여 구성하지만, 이번에는 docker 를 이용하여 SonarQube Scanner 를 실행해보겠습니다.

1) 분석하고 싶은 source 가 있는 프로젝트로 이동하여 아래 명령어를 실행합니다.

2) SonarQube 에 접속하여 결과를 확인합니다. 각 지표에 대한 설명도 함께 정리 하였으니 참고 하시면 좋겠습니다. :)

Bugs

• 일반적으로 잠재적인 버그 혹은 실행시간에 예상되는 동작을 하지 않는 코드를 나타낸다.
  Bugs 의 High/Low 는 아래의 조건에 따라 결정된다.
  * Impact : 어플리케이션을 중단시킬 영향을 주는가? 저장된 데이터에 손상을 줄 수 있는가?
  * Likelihood : 해커가 이 취약점을 악용할 가능성은 얼마나되는가?

Vulnerabilities

• 해커들에게 잠재적인 약점이 될 수 있는 보안상의 이슈를 말한다. SQL 인젝션, 크로스 사이트 스크립팅과 같은 보안 취약성을 찾아낸다.
  Vulnerabilities의 High/Low 는 아래의 조건에 따라 결정된다.
  * Impact : 이 취약점을 악용하여 사람 혹은 자산에 심각한 피해를 주는가?
  * Likelihood : 해커가 이 취약점을 악용할 가능성은 얼마나되는가?

Security Hotspots

• 취약성이 존재하는지 여부를 평가하기 위해 수동 검토가 필요한 보안에 민감한 코드에 대한 정보

Code Smell

• 심각한 이슈는 아니지만 베스트 프렉티스에서 사소한 이슈들로 모듈성(modularity), 이해 가능성(understandability), 변경 가능성(changeability), 테스트 용의성(testability), 재사용성(reusability) 등이 포함된다.(=유지관리에 관련해서 코드에서 더 심오한 문제를 일으킬 가능성이 있는 프로그램 소스 코드)
  Code Smell 의 High/Low 는 아래의 조건에 따라 결정된다.
  * Impact : 코드스멜로 인해 유지보수자(개발자)가 버그를 만들 수 있는가?
  * Likelihood : Worst 케이스가 일어날 가능성은 얼마나되는가?

Duplications

• 코드 중복은 코드의 품질을 저해시키는 가장 큰 요인 중 하나이다.

Unit Test

• 단위테스트 커버리지를 통해 단위 테스트의 수행 정도와 수행한 테스트의 성공/실패 정보를 제공한다.

Complexity

• 코드의 순환 복잡도, 인지 복잡도를 측정합니다.

Size

• 소스코드 사이즈와 관련된 다양한 지표를 제공합니다.

이 외에도 다양한 기능이 존재하지만, 개발시에 확인 할 부분은 Bugs(버그), Security Vulnerabilities(취약점), Hotspots(보안 핫스팟), Code Smells(코드 스멜) 들을 잘 확인하는 것부터 시작 하면 됩다. 이 것들만 잘 처리해도 코드 품질은 확실히 올라갈 수 있다는게 좋은 점이라 생각합니다. 물론 같이 하는 코드 리뷰도 좋지만요!!

그럼 다들 즐거운 개발세발~~ :)