개념
실행하지 않는다 — 그게 가장 큰 차이다
모듈 16 레슨 12에서 OWASP ZAP과 Burp Suite로 DAST를 실행해봤다. 그 도구들은 애플리케이션을 켜놓고, 밖에서 요청을 보내며 응답을 보고 취약점을 추측했다. 서버가 떠 있어야 하고, URL이 있어야 하고, 공격이 실제로 통해야 발견된다.
SonarQube 는 정반대 방향에서 접근한다. 애플리케이션을 실행하지 않는다. 서버도 URL도 필요 없다. 대신 소스 코드 파일 자체를 읽어서 문법 구조를 분석하고, 위험한 패턴이 있는지 검사한다. 모듈 16 레슨 6에서 개념으로 배운 SAST(Static Application Security Testing)가 이것이다.
DAST (ZAP·Burp, 모듈 16 레슨 12)
앱 실행 필요 → 밖에서 요청 전송 → 응답으로 추측
"이 로그인 폼에 ' OR '1'='1 을 넣으니 에러가 났다"
SAST (SonarQube, 이 레슨)
앱 실행 불필요 → 소스 파일을 파싱 → 코드 패턴으로 판단
"이 파일 42번째 줄에서 사용자 입력이 SQL 문자열에
그대로 붙고 있다"가장 실무적인 차이는 시점 이다. 모듈 16 레슨 13의 SQLmap은 이미 배포된 서비스를 공격해서 SQL Injection을 찾아낸다 — 즉 취약한 코드가 이미 세상에 나가 있다. SonarQube는 그 코드가 머지되기도 전에 같은 문제를 잡는다. 늦게 발견할수록 수정 비용이 커진다는 원칙(모듈 1)이 여기서 그대로 적용된다.
실제로 무엇을 잡아내는가
SonarQube가 보고하는 항목은 크게 세 종류로 나뉜다.
| 분류 | 뜻 | 예시 |
|---|---|---|
| 버그(Bug) | 지금 당장 오작동할 수 있는 코드 | null 검사 없이 객체 참조, 닫히지 않는 파일 핸들 |
| 취약점(Vulnerability) | 보안 사고로 이어질 수 있는 코드 | SQL 문자열 직접 조합, 하드코딩된 비밀번호·API 키 |
| 코드 스멜(Code Smell) | 지금은 동작하지만 유지보수를 어렵게 하는 코드 | 사용하지 않는 변수, 중복 코드, 지나치게 복잡한 함수 |
특히 QA가 눈여겨볼 항목이 두 가지 있다.
하드코딩된 비밀 — 소스에 API 키나 DB 비밀번호가 문자열로 박혀 있으면 SonarQube가 잡아낸다. 이건 DAST로는 거의 발견할 수 없는 종류다. 밖에서 요청을 보내는 것만으로는 소스에 무엇이 적혀 있는지 알 수 없기 때문이다.
함수 복잡도 — 모듈 3 레슨 10에서 배운 순환 복잡도 를 SonarQube가 함수마다 자동으로 계산해준다. "이 함수는 복잡도 24, 독립 경로가 24개"라는 숫자가 그대로 화면에 나온다. 그때는 손으로 제어 흐름 그래프를 그려 세었지만, 실무에서는 도구가 전 파일에 대해 한 번에 계산해준다.
Quality Gate — 기준 미달이면 머지를 막는다
SonarQube의 진짜 힘은 리포트가 아니라 Quality Gate 에 있다. "이 조건을 만족하지 못하면 통과시키지 않는다"는 규칙을 미리 정의해두는 장치다.
Quality Gate 예시 (새로 추가·수정된 코드 기준)
- 신규 코드의 취약점: 0건
- 신규 코드의 버그: 0건
- 신규 코드 테스트 커버리지: 80% 이상
- 중복 코드 비율: 3% 이하
→ 하나라도 어기면 PR 체크가 빨간불, 머지 버튼이 막힌다이 흐름은 모듈 14 레슨 4에서 배운 품질 게이트 설계 와 정확히 같은 사고방식이다. CI 파이프라인이 PR마다 SonarQube 분석을 자동 실행하고, 결과가 PR 화면에 코멘트로 붙는다. 사람이 코드 리뷰를 시작하기 전에, 기계가 걸러낼 수 있는 것은 이미 걸러진 상태 가 된다. 리뷰어는 "변수명이 이상하다" 대신 설계와 로직에 집중할 수 있다.
여기서 중요한 설정이 "신규 코드 기준(New Code)"이다. 레거시가 쌓인 프로젝트에 전체 기준을 적용하면 첫날부터 수천 건이 뜨고, 팀은 곧 결과를 무시하게 된다. "기존 빚은 그대로 두되, 새로 쓰는 코드는 깨끗하게" 라는 접근이 현실적으로 정착한다.
QA가 이 결과를 왜 봐야 하는가
SonarQube는 흔히 개발자 도구로 취급되지만, QA에게는 테스트 우선순위를 정하는 지도 로 쓸모가 있다. 모듈 4 레슨 2에서 배운 리스크 기반 테스트는 "어디를 더 집중적으로 볼 것인가"를 정하는 일이었는데, SonarQube 대시보드가 그 판단 근거를 숫자로 준다.
대시보드에서 읽는 신호
복잡도 높음 + 커버리지 낮음 → 최우선 탐색적 테스트 대상
복잡도 높음 + 커버리지 높음 → 상대적으로 안전
최근 변경 많음 + 이슈 다수 → 회귀 테스트 강화 구간단, 모듈 10 레슨 5에서 배웠듯 커버리지 숫자는 품질의 증명이 아니다 . 커버리지 90%가 곧 안전을 뜻하지 않는다. 반대로 "복잡도 30인 함수의 커버리지가 12%"라는 조합은 위험 신호로 읽을 근거가 충분하다.
오픈소스 표준, 그리고 유료 확장
SonarQube는 오픈소스 정적 분석 진영의 사실상 표준이다. 무료 Community Edition 으로 시작할 수 있고, 자바스크립트·파이썬· 자바 등 주요 언어를 지원한다. 조직이 커지면 유료 에디션(Developer, Enterprise)으로 올라가면서 브랜치·PR 분석 강화, 더 깊은 보안 규칙, 포트폴리오 단위 관리가 붙는다. 모듈 16 레슨 12의 ZAP(무료) 대 Burp Suite(유료판이 실무 표준) 구도와 비슷하게, 무료로 시작해 필요할 때 확장하는 구조다.
실무에서 왜 필요한가
배포 후에 발견된 SQL Injection 한 건을 고치는 비용과, 머지 전 PR 체크에서 같은 패턴을 걸러내는 비용은 비교가 되지 않는다. SonarQube가 CI에 붙어 있으면 그 차이가 매일 자동으로 발생한다. QA 입장에서는 두 가지를 동시에 얻는다 — 명백한 코드 수준 결함이 테스트 단계에 도달하기 전에 걸러지고, 남은 코드 중 어디가 위험한지에 대한 객관적 지표가 생긴다. 감으로 "이 기능이 불안한 것 같다"고 말하는 대신 "이 모듈은 복잡도 상위 3개 함수가 몰려 있고 커버리지가 20%"라고 말할 수 있게 된다.