[Troubleshooting] SonarCloud 자동 분석과 GitHub Actions CI 분석 충돌 해결하기

1. 문제 상황

GitHub Actions에서 테스트용 PostgreSQL을 준비한 뒤, SonarCloud 분석 과정에서 새로운 오류가 발생했다.

워크플로에서는 다음 명령어로 빌드와 분석을 실행하고 있었다.

./gradlew build sonar --info

발생한 오류 메시지는 다음과 같다.

실제 CI 오류 화면

You are running CI analysis while Automatic Analysis is enabled.

해석하면 “자동 분석이 활성화된 상태에서 CI 분석을 실행하고 있다”는 의미다.

앞서 발생했던 PostgreSQL 연결 오류는 테스트 실행 환경의 문제였다. 이번에는 SonarCloud에 설정된 분석 방식과 GitHub Actions에서 실행하는 분석 방식이 충돌한 것이었다.

원인을 이해하기 위해 먼저 각 도구의 역할과 분석 방식의 차이를 정리했다.

---

2. 먼저 이해해야 할 개념

CodeRabbit, SonarCloud, GitHub Actions의 차이

PR 화면에서 여러 도구의 결과를 함께 확인하다 보니, 어떤 도구에서 발생한 오류인지 혼동하기 쉬웠다.

도구	역할
CodeRabbit	PR의 변경 코드를 검토하고 리뷰 의견을 제공한다.
SonarCloud	코드의 버그 가능성, 보안 문제, 유지보수성 등을 분석한다.
GitHub Actions	빌드·테스트·분석·배포 등의 작업을 자동으로 실행한다.
AWS	서버, 데이터베이스, 스토리지 같은 클라우드 자원을 제공한다.

 

이번 오류는 SonarCloud의 분석 방식 충돌이다. CodeRabbit에서 관련 설명을 확인했더라도 오류의 주체가 CodeRabbit인 것은 아니다. 

CI와 GitHub Actions

CI는 Continuous Integration, 즉 지속적 통합을 의미한다.

팀원이 변경한 코드를 통합할 때 빌드와 테스트 등의 검증을 반복적으로 수행해 문제를 빠르게 발견하는 방식이다. GitHub Actions는 이러한 과정을 자동화할 수 있는 실행 환경이다.

우리 프로젝트에서는 코드가 push 되거나 PR이 생성·갱신되면 GitHub Actions가 다음 명령어를 실행하도록 구성했다.

./gradlew build sonar --info

 

명령	역할
build	컴파일, 테스트, 패키징 등 빌드 작업 수행
sonar	SonarScanner for Gradle을 통한 코드 분석 수행 및 결과 전달
--info	실행 과정을 확인할 수 있도록 상세 로그 출력

즉, GitHub Actions가 코드를 직접 평가하는 것이 아니라 Gradle과 분석 도구를 실행하는 환경을 제공하는 것이다.

🔸 SonarScanner란?

SonarScanner는 프로젝트를 분석하고 결과를 SonarCloud에 전달하는 도구다.

Gradle 프로젝트에서는 SonarScanner for Gradle을 연결해 sonar 작업으로 실행할 수 있다.

역할을 나누면 다음과 같다.

• GitHub Actions: 작업을 실행하는 환경
• SonarScanner: 코드 분석을 수행하고 결과를 전송하는 도구
• SonarCloud: 분석 결과와 품질 상태를 확인하는 서비스

---

3. 자동 분석과 CI 분석의 차이

SonarCloud는 Automatic Analysis와 CI 기반 분석이라는 두 가지 분석 방식을 제공한다.

구분	자동 분석	CI 분석
실행 위치	SonarCloud 측 환경	GitHub Actions 등 빌드 환경
실행 방식	저장소의 코드를 가져와 분석	워크플로에서 SonarScanner 실행
설정 방식	프로젝트의 자동 분석 기능 활성화	빌드 도구와 워크플로에 분석 설정
빌드·테스트와의 연계	자체 분석 흐름 사용	팀의 빌드·테스트 흐름에 통합 가능
테스트 커버리지 보고서 연동	지원하지 않음	별도 생성한 보고서 연동 가능

자동 분석은 저장소와 연결해 간단하게 시작할 수 있다.

CI 분석은 분석 실행에 필요한 설정을 직접 관리하는 대신, 기존 빌드 과정과 함께 구성할 수 있다.

CI 분석도 자동으로 실행될 수 있다.

우리 프로젝트처럼 push나 PR을 계기로 워크플로를 실행하면 CI 분석 역시 자동 실행된다. 따라서 두 방식의 차이는 ‘자동 실행인지 수동 실행인지’가 아니다.

Automatic Analysis는 SonarCloud가 제공하는 특정 분석 방식의 이름이다.

---

4. 원인: 두 분석 방식이 함께 설정되어 있었다

당시 프로젝트에는 다음 설정이 모두 존재했다.

설정 위치	설정 내용
SonarCloud 프로젝트	Automatic Analysis 활성화
GitHub Actions	./gradlew build sonar --info 실행

SonarCloud에서 자동 분석이 켜진 상태인데, GitHub Actions에서도 같은 프로젝트를 대상으로 CI 분석을 요청한 것이다.

SonarCloud는 자동 분석이 활성화된 프로젝트에 대한 CI 분석을 허용하지 않는다. 공식 문서에서도 두 방식 중 하나를 사용하도록 안내한다.

이때 중요한 점은 두 분석이 정확히 같은 순간에 실행되어야 오류가 발생하는 것은 아니라는 것이다. 자동 분석이 활성화된 상태에서 CI 분석을 요청하면 충돌한다.

따라서 실행 시간을 조정하거나 동일한 작업을 다시 실행하는 것만으로는 해결되지 않는다. 프로젝트의 분석 방식을 하나로 정해야 한다.

 

글로벌 설정과 프로젝트별 설정

일반적으로 설정은 적용 범위에 따라 구분된다.

• 글로벌·조직 설정: 여러 프로젝트에 적용되는 공통 설정
• 프로젝트별 설정: 특정 프로젝트에 적용되는 설정

다만 이번 오류를 해결하기 위해 모든 글로벌 설정과 프로젝트 설정을 꺼야 하는 것은 아니다.

핵심은 분석 대상인 SonarCloud 프로젝트에서 Automatic Analysis를 비활성화하는 것이다. 설정을 변경할 때는 어떤 서비스의 어떤 기능을 끄는지 구분해야 한다.

---

5. 해결: 자동 분석을 끄고 CI 분석으로 통일

이미 GitHub Actions에 빌드와 분석 작업이 구성되어 있었기 때문에, 기존 CI 분석을 유지하고 SonarCloud의 자동 분석을 비활성화했다.

변경 순서는 다음과 같다.

1. SonarCloud에서 spa-2_zeloTest 프로젝트에 접속한다.
2. Administration → Analysis Method로 이동한다.
3. Automatic Analysis를 비활성화한다.
4. GitHub Actions에서 실패한 작업을 Re-run jobs로 다시 실행한다.

공식 문서에서도 자동 분석에서 CI 분석으로 전환할 때 해당 메뉴를 사용하도록 안내한다.

설정 변경 후 CI 분석만 실행하도록 통일했고, 팀에서 해당 충돌 문제가 해결되었음을 확인했다.

여기서 끈 것은 SonarCloud 서비스가 아니라 자동 분석 기능이다.

GitHub Actions에서 실행한 분석 결과는 계속 SonarCloud로 전달된다. 코드 품질을 확인하는 대시보드도 그대로 사용한다.

---

6. CI 분석을 유지한 이유

빌드·테스트·분석을 한 흐름에서 관리할 수 있다

프로젝트에는 이미 GitHub Actions를 통한 빌드와 테스트 과정이 있었다.

여기에 코드 분석을 연결하면 코드 변경에 대한 검증을 하나의 워크플로에서 관리할 수 있다. 실패했을 때도 빌드, 테스트, 분석 중 어느 단계에서 문제가 발생했는지 로그로 구분할 수 있다.

테스트 커버리지를 연동할 수 있다

테스트 커버리지는 테스트 실행 중 코드가 얼마나 실행되었는지를 나타내는 지표다.

Java 프로젝트에서는 JaCoCo 같은 도구로 커버리지를 측정하고 보고서를 생성할 수 있다.

SonarCloud가 직접 커버리지를 측정하는 것은 아니다. CI에서 생성한 보고서를 SonarScanner가 읽어 분석 결과에 포함하는 방식이다. 자동 분석에서는 이 보고서 연동을 지원하지 않는다.

커버리지를 표시하려면 다음 작업이 필요하다.

1. JaCoCo 같은 커버리지 측정 도구를 설정한다.
2. 테스트를 실행하고 XML 보고서를 생성한다.
3. SonarScanner가 해당 보고서를 읽도록 설정한다.
4. 보고서 생성 이후에 Sonar 분석을 실행한다.

따라서 CI 분석을 켜는 것만으로 커버리지가 자동으로 표시되지는 않는다.

이번에는 분석 방식 충돌을 해결했고, 커버리지 보고서 연동은 별도로 구성할 수 있는 후속 작업으로 구분했다.

분석 정확도보다는 프로젝트 요구사항을 기준으로 선택했다

자동 분석은 부정확하고 CI 분석은 정확하다고 단순하게 구분하지는 않았다.

우리 프로젝트에서 CI 분석을 선택한 근거는 다음과 같다.

• 기존 GitHub Actions 설정을 활용할 수 있다.
• 빌드·테스트와 분석의 실행 순서를 관리할 수 있다.
• 분석에 필요한 환경과 설정을 직접 제어할 수 있다.
• 향후 테스트 커버리지 보고서를 연동할 수 있다.

---

7. 배운 점

이번 문제를 통해 코드 분석 도구를 연결할 때는 분석을 어디에서 어떤 방식으로 실행할지 먼저 정해야 한다는 것을 배웠다.

또한 같은 GitHub Actions 워크플로에서 발생한 오류라도 원인과 해결 위치는 다를 수 있었다.