[Spring Boot] SonarQube (소나큐브): 코드 퀄리티를 감시하는 무자비한 경찰관

지금까지 우리는 스프링 부트의 온갖 심화 기술과 아키텍처를 총동원하여 서비스를 만들었고, 완벽한 테스트 코드(Testcontainers)까지 짜서 동작을 보증했습니다. 그런데 '동작하는 코드'가 곧 '좋은 코드'일까요? 후임 개발자가 들어와서 메서드 하나를 1,000줄짜리 스파게티로 짜놓고, 하드코딩된 비밀번호를 소스에 박아두고, 아무도 안 쓰는 쓰레기 변수(Dead Code)를 잔뜩 남겨둔 채 테스트만 턱걸이로 통과시켜서 배포를 요청했습니다. 바쁜 시니어 개발자가 눈으로 수천 줄의 PR(Pull Request)을 읽으며 이 악취(Code Smell) 나는 코드를 다 걸러낼 수 있을까요? "코드를 실행시키지 않고(Static), 그냥 텍스트 자체만 쓱 훑어보고 논리적 오류, 복잡도, 보안 취약점을 완벽하게 잡아내서 점수를 매겨주는 무자비한 로봇 경찰관"이 필요합니다. 이 정적 코드 분석(Static Code Analysis) 시장의 압도적 1위 툴이 바로 SonarQube(소나큐브)입니다.

이번 [Spring Boot 실무 완벽 가이드] 시리즈에서는 "스파게티 코드 원천 차단!" SonarQube의 원리와 젠킨스(Jenkins) CI/CD 파이프라인과의 악랄한 연동(Quality Gate) 비법에 대하여 다뤄보겠습니다.

🕵️ 1. 정적 분석의 3대 핵심 타겟

소나큐브는 코드를 돌려보지 않고 텍스트 구조 패턴만으로 문제를 귀신같이 잡아냅니다.

• Code Smells (코드 악취): 지금 당장 에러는 안 나지만, 나중에 유지보수 할 때 피를 토하게 만드는 코드들입니다. 예를 들어 if-else문이 7번이나 중첩되어 순환 복잡도(Cognitive Complexity)가 너무 높다거나, 사용하지 않는 import문이나 변수(Dead Code)가 방치된 것을 잡아냅니다.
• Bugs (논리적 버그): String 비교를 ==로 했다거나, NullPointerException이 터질 가능성이 명백한 위험한 코드를 잡아냅니다.
• Vulnerabilities (보안 취약점): 코드에 password = "1234"를 하드코딩했거나, 사용자의 입력을 검증 없이 쿼리에 집어넣어 SQL Injection에 노출된 보안 구멍을 무자비하게 찾아냅니다.

⚙️ 2. Spring Boot Gradle 환경에 Sonar 플러그인 꽂기

로컬이나 도커로 SonarQube 서버(예: http://localhost:9000)를 하나 띄워두고, 우리 스프링 부트 프로젝트가 코드를 그쪽으로 밀어 넣도록 설정해 봅니다.

// build.gradle 최상단에 플러그인 추가
plugins {
    id 'org.springframework.boot' version '3.x.x'
    id 'org.sonarqube' version '4.4.1.3373' // 🌟 소나큐브 스캐너 플러그인
    id 'jacoco' // 🌟 테스트 커버리지(테스트 코드가 전체 소스의 몇 %를 덮고 있는지) 측정 도구
}

// 소나큐브 서버로 리포트를 쏠 때 필요한 설정값
sonar {
    properties {
        property "sonar.projectKey", "my-shopping-mall"
        property "sonar.host.url", "http://localhost:9000" // 띄워둔 소나큐브 서버 주소
        property "sonar.login", "sqp_어쩌구저쩌구토큰" // 인증 토큰
        // Jacoco가 측정한 커버리지 결과 파일을 소나큐브가 읽을 수 있도록 경로 지정
        property "sonar.coverage.jacoco.xmlReportPaths", "build/reports/jacoco/test/jacocoTestReport.xml"
    }
}

터미널에서 ./gradlew test jacocoTestReport sonar 명령어를 날리면, 단위 테스트가 쫙 돌고 커버리지가 측정된 뒤, 모든 소스코드와 결과가 소나큐브 서버로 업로드(스캔)됩니다.

🛑 3. 악독한 실무의 종착역: Quality Gate (품질 게이트)

단순히 "너 코드 좀 더럽다?" 하고 시각화만 해주는 거라면 개발자들은 절대 고치지 않습니다. 실무에서는 소나큐브를 젠킨스(Jenkins) 배포 파이프라인 한가운데에 물리적인 바리케이드(Quality Gate)로 박아버립니다.

팀장이 소나큐브 설정에서 "테스트 코드 커버리지가 80% 미만이거나, 심각(Critical) 버그가 1개라도 발견되면 무조건 FAILED(실패) 판정!"이라는 엄격한 룰(Quality Gate)을 세팅합니다. 이제 후임 개발자가 코드를 푸시하면 젠킨스가 빌드를 하다가 소나큐브에게 "야, 얘 코드 합격이냐?"라고 묻습니다. 만약 커버리지가 79%라서 FAILED가 떨어지면? 젠킨스는 배포(Deploy) 버튼을 부숴버리고 파이프라인을 새빨갛게 물들이며 터뜨려버립니다! 개발자는 눈물을 머금고 테스트 코드를 마저 작성해서 80%를 넘겨야만 비로소 코드를 운영 서버로 내보낼 수 있습니다. 이 강제성이야말로 기술 부채를 막는 궁극의 방어막입니다.

🎯 4. 마무리 및 다음 단계

지금까지 더러운 코드가 서버에 올라가는 것을 로봇처럼 감시하고, 테스트 코드 커버리지를 핑계로 배포를 차단해버리는 악명 높고도 위대한 코드 품질 수호자, SonarQube 정적 분석과 Quality Gate 아키텍처에 대해 상세히 다루어 보았습니다. 이제 여러분의 프로젝트 소스코드는 시간이 지날수록 부패하는 것이 아니라 맑고 영롱하게 유지될 것입니다.

자, 드디어 [Spring Boot 실무 완벽 가이드] 50부작 시리즈의 마지막 포스팅입니다! 우리는 29단계에서 톰캣(Tomcat)의 쓰레드(Thread) 고갈 문제를 비동기 논블로킹(WebFlux)으로 우회하며 환호했습니다. 하지만 WebFlux의 리액티브 코드(Mono, Flux)는 너무나 기괴하고 학습 곡선이 가혹했습니다. "아니, 코드는 옛날처럼 직관적이고 편안한 동기식(Blocking)으로 짜면서, 성능만 WebFlux급으로 뽑아낼 수는 없을까?" 자바 진영이 10년의 연구 끝에 내놓은 '자바 생태계 최고의 혁명', OS 쓰레드의 한계를 박살 내는 초경량 가상 쓰레드(Virtual Threads)가 드디어 Spring Boot 3.2에 공식 탑재되었습니다. 시리즈의 화려한 피날레, 50단계 포스팅에서는 "WebFlux를 관짝으로 보내버릴 차세대 동시성 처리의 끝판왕!" Java 21 Virtual Threads(가상 쓰레드)의 충격적인 원리와 실무 스프링 부트 적용기에 대해 아주 뼈 때리게 파헤쳐 보겠습니다!