정적 분석(Static Analysis)은 소프트웨어를 실행하지 않고 코드나 산출물을 분석하여 품질을 진단하는 방식이다.
이 분석은 사람이 직접 수행하는 리뷰와 달리,
정적 분석 도구를 통해 자동으로 진행된다.
이 글에서는 정적 분석 도구의 개념과 역할,
주요 검출 항목, 도구의 예시, 실무 적용 시 고려사항까지 정리한다.
1. 정적 분석이란?
✅ 정의
정적 분석은 소프트웨어 코드나 문서를 실행 없이 자동 분석하여
결함, 규칙 위반, 보안 취약점 등을 탐지하는 기법이다.
✅ 특징
- 소프트웨어 실행이 필요 없음
- 코딩 초기에 적용 가능 (컴파일 전에 수행 가능)
- 자동화 가능 → 빠르고 일관된 결과 제공
- 리뷰와 병행 시 상호 보완 효과
2. 정적 분석 도구의 역할
정적 분석 도구는 다음과 같은 품질 문제를 조기에 발견할 수 있다.
| 검출 항목 | 설명 |
| 구문 오류 | 문법 오류, 컴파일 불가 코드 |
| 코딩 규칙 위반 | 조직 내 코딩 스타일 또는 표준 위반 |
| 보안 취약점 | SQL Injection, 하드코딩된 비밀번호 등 |
| 복잡도 과다 | 함수 또는 클래스의 과도한 복잡성 |
| 사용되지 않는 코드 | 미사용 변수, 함수, import 등 |
| 데이터 흐름 문제 | 초기화되지 않은 변수 사용 등 |
| 메모리 누수 가능성 | 자원 반환 누락 등 |
3. 정적 분석 도구의 주요 기능
1) 구문 및 규칙 검사
- 언어별 문법 오류 탐지
- 사내 코딩 표준 및 스타일 가이드 적용 여부 확인
예: int i = 0 뒤에 세미콜론 누락
2) 복잡도 측정
- 코드 복잡도를 정량화하여 유지보수성 평가
- 사이클 복잡도(Cyclomatic Complexity) 지표 사용
사이클 복잡도가 높을수록 테스트 케이스 수 증가 → 리팩토링 권장
3) 보안 취약점 탐지
- OWASP Top 10 등 주요 취약점 자동 검출
- 하드코딩된 인증정보, 사용자 입력 검증 누락 등 식별
4) 코드 커버리지와 통합
- 일부 도구는 테스트 커버리지 측정 기능 내장
- CI/CD와 연동해 자동 분석 및 리포트 생성
5) 품질 기준 통과 여부 확인
- 품질 게이트(Quality Gate) 설정 가능
- 특정 오류 개수 초과 시 커밋/배포 차단
4. 대표적인 정적 분석 도구
| 도구 | 언어/환경 | 특징 |
| SonarQube | 다국어 지원 | 코드 품질 대시보드, 보안/복잡도 분석 |
| ESLint | JavaScript | 스타일, 규칙 위반 검출 |
| FindBugs / SpotBugs | Java | 잠재적 결함, 멀티스레드 이슈 탐지 |
| Pylint | Python | 규칙 위반, 복잡도 분석 |
| PMD | Java, Apex 등 | 코드 스타일 및 중복 코드 탐지 |
| StyleCop | C# | 마이크로소프트 코딩 규칙 검사 |
→ 대부분의 도구는 CI/CD 환경과 쉽게 통합 가능하며,
Pull Request 시 자동 분석 → 피드백 제공 형태로 활용됨
5. 정적 분석 도구의 적용 시점
정적 분석은 최대한 이른 시점에 적용하는 것이 좋다.
이때 Shift Left 전략이 효과적이다.
| 개발 단계 | 적용 형태 |
| 로컬 개발 환경 | IDE 플러그인 활용 (VS Code, IntelliJ 등) |
| 코드 커밋 시 | Git Hook 또는 Pull Request 트리거 |
| 빌드/배포 파이프라인 | Jenkins, GitHub Actions, GitLab CI 연동 |
| 운영 후 리뷰 | 품질 리포트 기반 코드 리팩토링 제안 |
6. 정적 분석 도구의 이점
✅ 객관적인 코드 품질 지표 제공
- 코드 커버리지, 복잡도, 결함 수 등 수치화 가능
- 팀/개인별 품질 관리 및 개선 방향 설정에 도움
✅ 리뷰 시간 단축
- 단순 스타일/규칙 위반은 자동 분석으로 대체
→ 리뷰자는 논리·설계 검토에 집중 가능
✅ 신입/외주 코드 품질 보장
- 표준 코딩 가이드 자동 검사
- 코드 일관성 확보 가능
✅ 릴리즈 전 리스크 사전 제거
- 보안 취약점, 오류 가능성 조기 발견
→ 사용자 이슈 및 클레임 사전 차단
7. 한계 및 주의점
정적 분석은 만능이 아니다. 다음 한계에 유의해야 한다.
❌ 실행 중 오류는 탐지 불가
→ 런타임 오류, 사용자 환경 차이 등은 분석 대상 아님
❌ 오탐 가능성
→ 규칙에 따라 실제 문제 없는 코드도 오류로 판단 가능
→ 규칙 커스터마이징 필요
❌ 복잡한 논리 오류는 분석 불가
→ 조건문 조합, 동적 의존성 등은 검출 한계 있음
❌ 지나친 의존은 개발자의 사고력 저하 초래
→ 도구가 지적하지 않는 부분도 ‘스스로 점검’하는 습관 필요
8. 효과적인 정적 분석 운영 전략
- 정책 수립
– 어떤 도구를, 어떤 기준으로, 언제 실행할 것인지 정의 - 규칙 커스터마이징
– 조직 상황에 맞는 규칙 세트 적용 - 지속적 피드백 루프 구성
– 코드 작성 → 분석 → 개선 → 재분석의 순환 구조 - 분석 결과 추적 및 보고
– 오류 이력 관리, 릴리즈 전 품질 기준 달성 여부 점검 - 팀원 교육
– 도구 사용법과 품질 기준에 대한 이해 필요
9. 실제 현장 사례
- 전자상거래 플랫폼: CI 단계에서 SonarQube 연동
→ 매일 아침 팀별 품질 리포트 메일 자동 발송
→ 코드 품질 점수 하락 시 리팩토링 우선순위 상향 - 핀테크 서비스: 보안 감사 대비 정적 분석 강화
→ 하드코딩, 민감정보 로그 출력 등 자동 탐지
→ 감사 항목 90% 이상 사전 해결
정적 분석 도구는
코드를 ‘개발자의 눈’이 아닌 ‘기계의 눈’으로 평가하게 만든다.
사람이 놓치는 반복적 실수, 스타일 편차, 보안 맹점까지
모두 빠짐없이 지적하고 정리한다.
하지만 도구는 ‘조언자’일 뿐,
진짜 판단과 책임은 개발자와 QA의 몫이다.
📚 ISTQB FL CHAPTER 3 전체 목록
'ISTQB Foundation Level > 제 3장 정적 테스팅' 카테고리의 다른 글
| [ISTQB FL 3-2] 리뷰의 종류 (Review Types) (1) | 2025.07.02 |
|---|---|
| [ISTQB FL 3-1] 작업 제품 검토의 개념 (Static Testing Basics) (1) | 2025.07.02 |
| [ISTQB FL 3] 정적 테스팅 (Static Testing) (0) | 2025.07.02 |