실제 실행 없이 컴퓨터 소프트웨어, 특히 소스코드를 분석하는 것 (Static Analysis)
정적 테스트의 두 축 중 도구 기반 축. 검토(Review·Inspection·Walkthrough)가 사람의 눈으로 이뤄지는 반면, 정적 분석은 도구가 자동으로 소스코드를 스캔한다.
목적
- 소스코드의 잠재적 품질 문제 발견 — 네트워크 자원 누수(
open()만 있고close()없음), 높은 복잡도, 추천되지 않는 패턴 - 소스코드 표준 준수 확인 — 코딩 컨벤션(명명규칙), 보안
- 설계 상의 낮은 품질·표준 위반 확인 — 호출 관계 위반, 호출 횟수 위반
ISO 26262 연계
Table 9의 14개 검증 기법 중 정적 분석 범주 4기법(1f~1i)을 다룬다.
| 기법 | 명칭 | A | B | C | D |
|---|---|---|---|---|---|
| 1f | Control flow analysis | + | ++ | ++ | ++ |
| 1g | Data flow analysis | + | ++ | ++ | ++ |
| 1h | Static code analysis | ++ | ++ | ++ | ++ |
| 1i | Static analyses based on abstract interpretation | + | + | + | ++ |
→ 대상 산출물은 상세 설계서·소스코드. ASIL A부터 1h Static code analysis는 ++로 강하게 권장됨 (모든 ASIL에서 필수급).
3갈래 분류
| 분류 | 대상 | 대표 도구·가이드라인 |
|---|---|---|
| 룰 기반 정적 분석 | 소스코드의 룰 준수 여부 | MISRA, CERT / Coverity, Klocwork, CppCheck |
| 의존성 분석 | 함수·변수·모듈의 호출 관계 | Lattix, Imagix4D, Doxygen, CppDepend |
| 시맨틱 분석 (Semantic) | 코드의 의미 기반 결함 | Abstract interpretation 기반 도구 |
시맨틱 분석은 Table 9 1h의 “Semantic code analysis”에 대응 (모든 ASIL에서 + 권장).
룰 기반 정적 분석
개요
사전에 정해진 가이드라인을 소스코드가 만족하는지 분석
- 가이드라인은 검증 도구가 해석 가능한 룰(Rule)과 그에 대한 가이드로 구성
- 룰셋(Rule Set)은 룰을 카테고리화한 것
대표 가이드라인
| 가이드라인 | 출처 | 대상 언어 |
|---|---|---|
| MISRA | Motor Industry Software Reliability Association — 안전성·호환성·신뢰성 | C, C++ |
| CERT | SEI CERT (Computer Emergency Response Team) — SW 개발보안 | C, C++, Java |
상세 룰·버전 변천·세분화 레벨은 코딩 표준 참조.
대표 도구
| 언어 | 국산 | 외산 | 오픈소스 |
|---|---|---|---|
| C/C++ | Sparrow (파수) · CodeInspector (Suresoft) · Resort (Soft4Soft) | QAC/QAF (PRQA) · Coverity (Synopsys) · Polyspace-Bug Finder (MathWorks) · Klocwork (Rogue Wave) · LDRA · Parasoft | CppCheck |
| Java | — | JArchitect 등 | SonarQube (C/C++은 유료) |
- 국산 도구는 행정안전부 개발 보안 검증 대응
- ISO 26262 인증은 오픈소스 제외 (상용 도구만)
도구 선택 시 확인 사항
- 분석 대상 언어 (C/C++ 또는 Java)
- 1종 오류·2종 오류 발생률
- 1종 오류 — 결함인데 못잡는 것 (Missed Defect, 통계학의 False Negative에 대응)
- 2종 오류 — 결함이 아닌데 결함이라 하는 것 (False Alarm, 통계학의 False Positive에 대응)
1종/2종 용어는 통계학의 Type I/II와 역방향으로 정의된다. 도구 벤더 간 비교 시 용어 정의를 먼저 확인해야 혼선이 없다.
CppCheck (오픈소스 실습 도구)
- 업계에서 “안좋은 방식”으로 알려진 코드 패턴 발견
- 컴파일 에러는 아니지만 나중에 문제를 발생시킬 코드 탐지
- 코딩 중 컴파일 전에 사용
- 기본적으로 MISRA 지원 안 함 — MISRA 구매 후 룰 정보를 txt로 변환해야 MISRA 검증 가능 (모든 룰을 점검하지는 않음)
- 분석 대상 예시: curl (C로 개발된 HTTP/FTP CLI 도구)
탐지 패턴 예시:
- Connection을 열었으면 명시적으로 닫았는가?
int i같은 의미 없는 변수명 사용- 매개변수 15개 이상 사용
case마다break;가 있는가?final에서return금지- 빈
if문 피하기
의존성 분석
개요
함수·변수의 호출관계를 분석하는 도구 (Dependency Analysis)
도구 방향에 따라 패키지 / 클래스(파일) / 함수 단위로 표현.
목적
- 아키텍처 구조에서 서브 시스템 간 의존이 적절한지 확인
- 서브 시스템 레이어 간 호출 관계 (예: AUTOSAR 레이어)
- 동일 레벨 간 호출 관계 (자식-부모 패키지)
- 원형 의존성(Circular Dependency, 상호 참조) 관계 탐지
- 객체지향 특화 도구는 추상화·구체화 정도를 확인
표현 방식 3종
| 방식 | 특징 |
|---|---|
| DSM | Dependency Structure Matrix — X/Y축 매트릭스 형태로 서브 시스템 간 의존성 확인에 유리 |
| 지표 (Metric) | 호출 대상을 숫자로 표현. 객체지향 도구는 Robert C. Martin의 논문 근거로 의존성 관련 지표 정의 |
| 다이어그램 | 호출 관계를 시각적 그래프로 표현 |
대표 도구
| 언어 | 외산 | 오픈소스 |
|---|---|---|
| C/C++ | Lattix · Imagix4D | CppDepend · Doxygen |
| Java | JArchitect | JDepend · Doxygen |
Layered Architecture 의존성 규칙
Layered Architecture에서 서브 시스템 간 의존성은 3가지 관계로 구분:
- 각 레이어 간 호출 관계 (예: AUTOSAR)
- 동일 레벨 간 호출 관계 (자식-부모 패키지)
- 원형 의존성(상호 참조) 관계
→ 원형 의존성은 금지 대상. 레이어 위반과 함께 의존성 분석 도구의 주요 탐지 목표.
Doxygen + Graphviz
- Doxygen — 소스코드의 의존 관계를 분석하는 오픈소스 도구. C/C++ 외 Java·PHP 지원
- Graphviz — Doxygen의 다이어그램 렌더링 전문 도구. Graphviz 설치 시 Doxygen이 활용하도록 설정 가능
- Graphviz 실행 파일의 PATH를 추가해야 Doxygen이 위치 무관하게 Graphviz를 사용
최적의 룰 기반 정적 분석 사용법
생산성 — IDE·빌드 도구 통합
- Java 계열 — Eclipse·IntelliJ 두 IDE 플러그인만 제공하면 됨
- C 계열 — 컴파일러 자체 IDE 또는 VIM류 사용 → 정적 분석 도구가 IDE별 플러그인 개발 필요 → 플러그인이 거의 없음 → 코딩 IDE 따로, 정적분석 도구 따로 사용
- IDE 외에 Maven·Gradle 등 빌드 도구에 플러그인으로 적용 가능
적용 룰 최적화
- MISRA의 모든 룰을 사용할 것인가? 필요한 룰만 사용할 것인가?
- 필요한 룰은 어떻게 선정할 것인가?
- 자동차의 경우 전체 적용 필요 (MISRA-C 전 룰)
- 적용 룰은 구현 전 배포 및 교육
최악의 관행: 코딩 후반부에 정적분석 도구 적용 및 강제화. MISRA 도구는 고가라 협력사가 사용하기 어렵지만 강제하는 경우 발생.
CI 연계
Jenkins 기반 CI에 적용하는 것이 일반화됨. 거의 대부분의 유명 도구(상용·오픈소스 모두)가 Jenkins 플러그인 제공.
일반 vs Automotive 정적 분석 비교
| 구분 | 일반 | Automotive |
|---|---|---|
| 적용 룰 | 임베디드: MISRA 기본 + 자체 룰 (보통 50개 내외) / 웹·앱: 오픈소스 제공 룰의 Subset | MISRA C 전 룰 (150여개) |
| 순환 복잡도 | 임베디드: 20 이하 / 웹·앱: 10 이하 (유지보수 관점) | ISO 26262 요건 — 15 이하 권고 |
| 의존성 | 임베디드: 제어·데이터 흐름 관리(항공) / 웹·앱: 인터페이스를 이용한 의존성 관리 | ISO 26262 요건 — AUTOSAR 기반 의존성 관리 |
→ Automotive는 일반 임베디드보다 룰 적용 범위·복잡도 제약·의존성 관리 모두 엄격.