핵심 인사이트

1. 본질: 인스펙션 (Inspection)은 공식 사회자(Moderator)가 주도하고 체크리스트를 활용해 소프트웨어 산출물의 결함을 체계적으로 발견하는 가장 공식적이고 효과적인 SW 리뷰 기법이다.
2. 가치: IBM 마이클 페이건 (Michael Fagan)의 연구에 따르면 인스펙션은 코드 테스트보다 비용 대비 결함 발견 효율이 높으며, 요구사항·설계 단계의 결함도 조기에 제거할 수 있다.
3. 판단 포인트: 인스펙션의 핵심은 결함을 찾는 것이지 수정하는 것이 아님—인스펙션 회의에서 수정 방법을 논의하면 시간이 낭비되고 핵심 목적(결함 목록 작성)을 잃는다.

Ⅰ. 개요 및 필요성

인스펙션 (Inspection)은 1972년 IBM의 마이클 페이건 (Michael Fagan)이 개발한 공식 SW 리뷰 프로세스로, "Fagan Inspection"이라고도 불린다. 이 기법은 정형화된 역할 분담, 체크리스트 기반 준비, 공식 결함 기록 절차를 갖추고 있어 비공식 리뷰보다 훨씬 높은 결함 발견율을 자랑한다.

인스펙션이 필요한 이유는 개발자 개인의 자기 검토(Self-Review)에는 인지 편향이 있기 때문이다. 자신이 작성한 코드나 문서의 결함은 심리적으로 인식하기 어렵다. 인스펙터들의 다양한 시각과 체크리스트 기반의 체계적 검토가 이 편향을 극복한다.

실무에서 인스펙션은 요구사항 명세서(SRS), 설계 문서, 소스 코드, 테스트 계획서에 모두 적용 가능하다. 특히 안전 필수 시스템(Safety-Critical System)—항공, 의료기기, 원자력—에서는 인스펙션이 인증 요건의 일부로 의무화되는 경우도 있다.

📢 섹션 요약 비유: 인스펙션은 국세청 세무 조사와 같다. 담당자(저자)가 직접 설명하지만, 검사관(인스펙터)들이 체크리스트를 들고 체계적으로 오류를 찾아낸다—느낌이 아닌 기준으로 평가한다.

Ⅱ. 아키텍처 및 핵심 원리

인스펙션 4대 역할

(사회자가 인스펙터 역할을 겸할 수 있음. 저자는 회의에서 방어적이지 않아야 함)

인스펙션 6단계 프로세스

┌────────────────────────────────────────────────────────────────┐
│              Fagan Inspection 6단계                            │
├──────────────┬─────────────────────────────────────────────────┤
│  1. 계획     │ 인스펙션 일정, 참가자, 자료 준비                 │
│  (Planning)  │ 사회자가 조율                                    │
├──────────────┼─────────────────────────────────────────────────┤
│  2. 개요 설명│ 저자가 산출물 배경, 구조, 목적 설명             │
│  (Overview)  │ 인스펙터들이 맥락 이해                          │
├──────────────┼─────────────────────────────────────────────────┤
│  3. 준비     │ 각 인스펙터가 체크리스트로 독립 검토            │
│  (Preparation│ 개인별 결함 목록 작성                           │
├──────────────┼─────────────────────────────────────────────────┤
│  4. 인스펙션 │ 팀 회의: 결함 식별·분류 (수정 방법 논의 금지)  │
│  회의       │ 기록자가 결함 로그 작성                          │
│  (Meeting)   │                                                 │
├──────────────┼─────────────────────────────────────────────────┤
│  5. 수정     │ 저자가 결함 수정                                │
│  (Rework)    │ 수정 내용 문서화                                │
├──────────────┼─────────────────────────────────────────────────┤
│  6. 후속 조치│ 사회자가 수정 완료 확인                         │
│  (Follow-up) │ 미해결 결함은 재인스펙션                        │
└──────────────┴─────────────────────────────────────────────────┘

체크리스트 기반 결함 분류

결함 유형 분류 (일반):
  누락 (Omission): 요구사항/로직이 빠진 경우
  불일치 (Inconsistency): 다른 부분과 모순되는 경우
  잘못됨 (Wrong): 명세와 다르게 구현된 경우
  애매함 (Ambiguous): 다르게 해석될 수 있는 경우
  추가 필요 (Extra): 명세에 없는 기능이 구현된 경우

결함 심각도:
  Major: 기능에 영향을 미치는 결함 → 반드시 수정
  Minor: 권고 사항, 개선 가능한 사항
  Questionable: 추가 확인이 필요한 사항

인스펙션 메트릭

📢 섹션 요약 비유: 인스펙션 회의에서 "수정 방법 논의 금지"는 법정에서 판사가 판결만 선고하고 변론하지 않는 것과 같다. 결함을 기록하는 것(판결)과 해결책을 찾는 것(수정)은 다른 단계다—회의에서 수정을 논하면 전체 검토 시간이 낭비된다.

Ⅲ. 비교 및 연결

공식 리뷰 유형 비교

IEEE 1028 SW 리뷰 표준

IEEE 1028은 다음 리뷰 유형을 정의:
  1. 관리 검토 (Management Review): 프로젝트 상태, 계획 확인
  2. 기술 검토 (Technical Review): 명세 일치성, 표준 준수
  3. 인스펙션 (Inspection): 가장 공식적인 결함 발견 활동
  4. 워크스루 (Walkthrough): 저자 주도 이해 공유
  5. 감사 (Audit): 독립 외부 평가

📢 섹션 요약 비유: 인스펙션, 워크스루, 동료 검토의 차이는 정식 법원 재판, 토론 수업, 스터디 그룹의 차이와 같다. 정식 재판(인스펙션)이 가장 엄격하고 효과적이지만 시간이 많이 든다.

Ⅳ. 실무 적용 및 기술사 판단

인스펙션 투자 대비 효과

연구 결과 (Fagan, IBM):
  코드 인스펙션으로 결함의 60~90% 발견 가능
  테스트보다 결함당 수정 비용이 약 1/3~1/10

소규모 팀에서의 실용적 적용:
  전체 코드베이스 인스펙션 → 비용 과다
  
  선택적 적용 권장:
  - 핵심 모듈 (인증, 결제, 안전 필수)
  - 복잡도 높은 알고리즘
  - 자주 버그가 발생하는 컴포넌트
  - 신입 개발자 산출물

기술사 시험 핵심 포인트

1. 저자가 수정하지 않는 것이 원칙: 인스펙션 회의에서 저자는 설명만 하고, 방어적 태도 금지.

2. 수정 방법 논의 금지: 결함을 식별·기록하는 것이 목적—해결책은 저자가 나중에 별도로 수립.

3. 사회자의 역할: 중립성과 프로세스 진행. 기술 전문성보다 진행 능력이 더 중요.

4. Ego-less Programming: 인스펙션의 전제—코드는 개인 소유가 아닌 팀의 자산이라는 마인드.

인스펙션 vs 테스트 병행

인스펙션 대상:
  - 정적 산출물 (코드, 문서, 설계)
  - 실행 없이 분석 가능한 모든 것

테스트 대상:
  - 동적 실행 결과
  - 인터페이스, 성능, 보안 취약점

병행 이유:
  인스펙션: 논리 오류, 코딩 표준 위반, 설계 결함 발견
  테스트: 런타임 오류, 경계값 오류, 성능 문제 발견
  → 두 기법의 결함 발견 영역이 다름 → 상호 보완적

📢 섹션 요약 비유: 인스펙션과 테스트의 병행은 자동차의 설계도 검토(인스펙션)와 실제 시험 주행(테스트)의 병행이다. 설계도를 검토해도 주행해봐야 알 수 있는 문제가 있고, 주행해도 설계 상의 근본 오류를 찾기 어렵다.

Ⅴ. 기대효과 및 결론

인스펙션을 체계적으로 적용하면:

1. 결함 조기 제거: 요구사항·설계 단계의 결함을 개발 전에 제거해 수정 비용을 수십 배 절감한다.
2. 코딩 표준 준수: 체크리스트 기반 검토로 팀 전체의 코딩 품질이 향상된다.
3. 지식 공유: 인스펙터들이 다른 팀원의 코드를 검토하며 시스템 전반 이해도가 높아진다.
4. 품질 메트릭 수집: 결함 로그를 통해 결함 유형, 밀도, 원인을 분석해 프로세스 개선의 근거가 된다.

인스펙션의 핵심 성공 요소는 조직 문화다. 결함 발견을 "개인 공격"이 아닌 "제품 개선"으로 인식하는 문화—"자아를 버린 프로그래밍 (Ego-less Programming)"—가 없으면 인스펙션은 형식적 절차로 전락한다.

📢 섹션 요약 비유: 인스펙션 성공의 핵심은 운동 선수의 코치 관계와 같다. 코치가 선수의 폼을 지적할 때 "선수를 공격"하는 게 아니라 "경기력을 향상"시키는 것처럼—결함 지적은 개인이 아닌 코드를 향해야 한다.

📌 관련 개념 맵

👶 어린이를 위한 3줄 비유 설명

1. 인스펙션은 여러 명이 숙제를 함께 검토하는 것이에요 — 한 명(사회자)이 진행하고, 다른 친구들이 체크리스트를 들고 틀린 부분을 찾아줘요.
2. 검토 회의에서는 "어떻게 고칠까"는 말하지 않아요 — "이 부분이 틀렸어"라고만 기록하고, 고치는 것은 나중에 따로 해요.
3. 내 숙제의 실수를 찾아줘도 기분 나빠하면 안 돼요 — 숙제는 내 것이 아니라 우리 모두의 것이니까요 (Ego-less Programming).