소프트웨어를 실행하지 않고 결함을 찾아내는 것. 개발 중에 생성되는 모든 산출물에 적용 가능.
검증과 확인의 정적(Static) 기법에 해당. 동적 기법은 소프트웨어 테스팅에서 다룬다.
대표 방법
- 검토 (Review) — 여러 참여자가 모여 산출물을 점검
- 인스펙션 (Inspection)
- 워크쓰루 (Walk-through)
- 데스크체크 (Desk Check)
- 도구 기반 정적 분석(Static Analysis)
- 룰 기반 정적 분석 (MISRA 등)
- 의존성 분석
- 시맨틱 분석
식별 가능한 결함 유형
정적 테스트 단계에서 발견할 수 있는 결함 (ISTQB CTFL v4.0):
| 유형 | 예시 |
|---|---|
| 요구사항 결함 | 불일치, 모호성, 모순, 누락, 부정확성, 중복 |
| 설계 결함 | 비효율적 DB 구조, 모듈화 불량 |
| 코딩 결함 | 미정의 변수, 미선언 변수, 도달 불가 코드, 중복 코드, 과도 복잡성 |
| 표준 위반 | 코딩 표준 명명 규칙 미준수 |
| 인터페이스 명세 오류 | 매개변수 개수/유형/순서 불일치 |
| 보안 취약성 | 버퍼 오버플로우 |
| 테스트 베이시스 커버리지 | 인수 조건 누락 |
결함 발생 원인
아무리 능숙한 프로그래머라도 평균적으로 35 Defs/KLoc이 발생한다 (빙산 모델 — 외부 품질 이면에 유지보수·복잡도·가독성·결합도 등 보이지 않는 내부 품질 문제가 축적).
| 원인 | 설명 |
|---|---|
| Communication | 10명의 팀이면 45개의 Path가 생김 (n(n-1)/2 커뮤니케이션 경로 폭발) |
| Cognitive Dissonance | 자신의 산출물에서 결함을 찾기가 힘듦 |
| Short Term Memory | 사람이 관리 가능한 범위(7 digits) + 여러 Interruption |
| Complexity of Work | 설계 문서의 복잡성으로 코드 작성이 어려운 경우 |
→ 개인의 역량만으로는 결함을 막을 수 없으므로, 동료의 눈으로 교차 검증하는 정적 테스트가 필수.
동료 검토 (Peer Review)
기술적 내용이나 품질을 평가하기 위해 저자와 동료에 의해 산출물을 평가하는 소프트웨어 검토 방법 (Wikipedia)
- 리뷰 대상: 소프트웨어 계획, 요구사항, 디자인, 코드, 테스트 절차, 테스트 케이스 등
- 개발 당사자를 제외한 주변 동료가 검토·분석·개선 제안 (TTA 용어사전)
- 결함 제거를 목적으로 결함 발견을 위해 수행 (CMMI)
프로세스
사전 준비 (공지 → 검토자 지정 → 배포 → 개인 준비)
↓
검토 회의
↓
후속 조치 (문제점 해결 → 보고서 작성)체크리스트 작성 원칙
- 결함 분석에 기초하여 정기적으로 갱신
- 한 페이지 이내 — 검토 중 책상에 놓고 즉시 참조
- 질문 또는 명령문 형태로 구체화 — “각 변수는 처음 사용되기 전에 적절하게 초기화되었는가?”
- 너무 일반적이지 않게 — “모든 요구사항이 완전하고 일관성 있고 명백한가?”는 너무 추상적
예시:
| No. | 체크리스트 |
|---|---|
| 1 | 요구사항 명세서에 기술된 기능이 모두 소스 코드에 반영되었는가? |
| 2 | 소스 코드의 주석을 작성 규칙에 따라 명시하였는가? |
| 3 | 메소드 리턴 값은 적절하게 명시하였는가? |
| 4 | 변수는 사용되기 전에 초기화 되었는가? |
| 5 | 무한 루프로 진입하는 조건이 있는가? |
소스코드 동료검토 8가지 원칙
- Review fewer than 200~400 lines of code at a time — 한 번에 200~400라인 이내
- Aim for an inspection rate of less than 300~500 LOC/hour — 너무 빠른 검토 금물
- Authors should annotate source code before the review begins — 작성자가 사전 설명 제공
- Establish quantifiable goals and capture metrics — “에러율을 50% 줄인다”처럼 수치 목표 설정
- Verify that defects are actually fixed! — 지적만큼 중요한 건 수정 확인
- Managers must foster a good code review culture — 결함 발견을 긍정적으로 보는 문화 조성
- The Ego Effect — 시간이 없어도 일부라도 검토. 전체의 20~30%만 검토해도 Ego Effect 최대 효과. 개발자는 자신의 코드가 검토받을 것을 알고 실수를 줄이려 노력
- Beware the “Big Brother” effect — 지적을 인격 비하로 느끼지 않도록. 품질 과정일 뿐
유형 스펙트럼
비공식 ↔ 공식의 연속체.
| 비공식 리뷰(Informal Review) | 공식 리뷰(Formal Review) |
|---|---|
| 공식적 절차·표준 존재하지 않음 | 공식적 절차·표준 존재 |
| 참여자별 역할과 책임 불명확 | 참여자별 역할과 책임 명확 |
3종 배치:
데스크 체크 ─── 워크쓰루 ─── 인스펙션
(비공식) (공식)인스펙션 (Inspection)
표준이나 명세서에 대한 편차와 에러를 포함한 결함을 발견·식별하기 위해 작업 산출물에 대해 수행하는 검사
1970년대 초 IBM의 마이클 페이건(Michael Fagan)이 정립.
주요 특징
- 검토 대상 산출물의 작성자가 아닌 훈련된 진행자(Moderator)에 의한 진행
- 시작·종료 조건을 갖는 체크리스트와 규칙 기반의 정식 프로세스 존재
- 소프트웨어 구성요소·산출물의 정확성 평가
- 전문가 검토이며 공식적 평가
- 결함 발견이 주 목적
인스펙션의 효과
| 인용 | 평가 |
|---|---|
| Tom Gilb | 테스트 단계 이전 소프트웨어에서 95% 이상의 에러를 감소 |
| Watts Humphrey | 개발 단계에서 생산성·품질 개선에 탁월. 개발자가 찾지 못한 오류를 반드시 발견 |
| Vern Crandell | 하나의 좋은 인스펙션은 30,000개의 테스트 케이스와 동등한 효과 |
| 분류 | 도입 효과 |
|---|---|
| 에러 예방 | 개발 초기 예방, 테스팅 단계 전파 에러 60~80% 감소 (IBM 82%, HP 80% 제거) |
| 비용 절감 | 1시간 인스펙션이 8~12시간의 테스트 작업 절약, 테스팅 시 에러 수정 비용 60~80% 절감 |
| 기타 | 팀 간 대화 향상, 개발·테스트 프로세스 품질/생산성 향상, 개발 기간·유지보수 노력 단축 |
→ 생명주기 단계별 결함 제거 효과에서 Code Inspection이 가장 높음 (J.E. Heiser, 1997).
5가지 역할
| 역할 | 책임 |
|---|---|
| 진행자 (Moderator) | 의장 역할, 인스펙션 계획, 검토자 선정 |
| 작성자 (Author) | 검토 대상 산출물(문서·코드) 작성, 검토 결과 조치 |
| 제출자 (Reader) | 객관적이고 정확하게 검토 자료 제출, 작성자보다 객관적 입장에서 의견 |
| 검토자 (Inspector) | 사전 충분 검토, 결함 발견 노력, 해결보다 의견 제시 |
| 기록자 (Recorder) | 모든 의견 기록, 종료 후 정리·문서화 |
프로세스 (5단계)
준비 → 개인 준비 → 검토 회의 → 수정 → 후속 조치 순으로 진행된다.
워크쓰루 (Walkthrough)
개발자 위주의 비공식적 검토 과정. 각 개발 담당자가 서로 협력하는 자주적인 리뷰 (IEEE 1028-1997).
주요 특징
- 작성자에 의해 진행·제어 (인스펙션과 반대)
- 시간·인원수 등에 제한이 없고 상황에 따라 변경 가능
- 시스템 이해 향상 + 결함 발견 목적
프로세스 (2단계)
01. 사전 준비
- 개발자가 동료 검토 요청
- 1명 이상의 검토자 선정
- 일정·계획 공지, 검토 대상과 체크리스트 배포
02. 검토 회의
- 개발자가 검토 대상 설명
- 검토자는 개선 의견 제안
- 개발자는 결과 기록, 결함 등록·조치워크쓰루 vs 인스펙션
| 구분 | 워크쓰루 | 인스펙션 |
|---|---|---|
| 검토 시점 | 임의 시점 (산출물 작성 중) | 산출물 작성 완료 시 |
| 검토 대상 | 중간 산출물 | 개발 산출물 완성본 |
| 진행 주체 | 산출물 작성자 | 훈련된 리더(Moderator) |
| 검토 규정 | 정식 규정·프로세스 없음 | 정식 규정·프로세스 존재 |
| 산출물 | (약식) | 인스펙션 결과서, 결함 리포트 |
| 후속 처리 | (약식) | 재작업 후속 처리 확인 프로세스 존재 |
검토 시 주의사항
- 검토는 산출물에 대한 품질 평가 — 사람에 대한 평가가 아님
- 관리자는 권장하나 참여하지 말 것 — 자유로운 의견 개진 보장
- Ego Effect 활용 — 내 산출물의 일부분이라도 검토받기
- 오류를 발견해도 수정하지 않으면 무의미 — 조치 확인 필수
ISO 26262 리뷰 요건
ISO 26262는 아래 산출물에 대한 리뷰를 요구:
- 아키텍처 설계서
- 상세 설계서
- 소스코드
→ 아키텍처 설계와 단위 설계·구현 검증을 위한 Methods 표(Walkthrough·Inspection·Semi-formal verification 포함)를 ASIL별로 권장. 1c Inspection이 페이건 인스펙션에 해당. ASIL별 권장도는 SW 단위 설계·구현 검증 기법 — Table 9 참조.
A-SPICE 연계
A-SPICE SWE.4 Software Unit Verification BP3 “Perform static verification of software units”가 정적 테스트에 대응. 정적(BP3) + 동적(BP4)의 이원 구조로 단위 검증을 구성. → SWE.4 상세.
도구 기반 정적 분석
룰 기반 검사(MISRA·CERT), 의존성 분석, 시맨틱 분석은 정적 분석 페이지에서 다룬다. ISO 26262 Table 9 기준 1f Control flow·1g Data flow·1h Static code·1i Abstract interpretation 4기법이 이 범주.
→ CI Jenkins 파이프라인에서 자동 수행. 룰 상세는 코딩 표준, 복잡도 지표는 순환 복잡도 참조.