소프트웨어 인스펙션: 정적 테스트로 결함을 조기에 찾는 동료 검토

실행 전에 산출물의 결함을 드러내는 검토

결함을 배포 뒤에 발견할수록 수정 범위와 비용은 커진다. 소프트웨어 인스펙션(Software Inspection)은 코드나 설계서를 실행하지 않은 상태에서 체크리스트와 Rule Set으로 잠재 결함을 찾아내는 공식 정적 테스트 기법이다.

이 기법은 1970년대 마이클 패건(Michael Fagan)이 정립했으며, 패건 인스펙션이라고도 한다. 일반적인 코드 리뷰나 워크스루와 구별되는 지점은 절차와 참여자 역할이 명확하게 정해져 있다는 데 있다.

인스펙션은 코딩 또는 설계 단계의 오류가 배포 후 장애로 번지는 위험을 줄인다. 팀이 함께 산출물을 검토하면서 아키텍처와 로직에 대한 이해를 공유할 수 있고, 표준 미준수나 가독성 저하 요인을 찾아 유지보수성도 높일 수 있다. Rule Set을 기준으로 취약한 로직과 보안 약점을 체계적으로 식별하는 품질 보증 활동이기도 하다.

계획부터 후속 조치까지 이어지는 검토 흐름

인스펙션은 회의 한 번으로 끝나는 검토가 아니다. 대상 선정과 준비, 결함 확정, 수정 확인이 각각 분리되어 진행된다.

⤢✕

계획 단계에서는 Moderator가 검토할 산출물을 정하고, 참여 인력의 일정과 장소를 조율한다. 이때 Rule Set과 체크리스트도 준비한다.

개요 단계에서는 작성자가 대상 산출물의 배경, 목적, 주요 로직을 참여자에게 설명한다. 이후 각 참여자는 준비 단계에서 맡은 역할을 기준으로 산출물을 개별 검토하고, 의심 사항과 결함 후보를 기록한다.

인스펙션 회의에서는 준비 과정에서 수집한 이슈를 공유해 실제 결함인지 확정한다. Reader가 산출물을 한 문장씩 읽으며 검토를 이끌고, Moderator가 회의를 중재한다. 확정된 결함은 작성자(Author 또는 Coder)가 재작업 단계에서 수정하며, 마지막으로 Moderator가 수정 상태를 확인해 종료 또는 재인스펙션 여부를 결정한다.

역할을 나눠 결함에 집중하는 방식

Moderator는 인스펙션 전체를 주관하는 중재자다. 참여자가 개인을 비난하지 않고 결함 발견에 집중하도록 회의를 이끌며, 인스펙션 완료 여부도 결정한다.

Reader는 코드나 로직을 읽고 설명하면서 참여자 사이의 공동 이해를 만든다. 검토 중 제기되는 질문과 인터뷰에 대응하며 산출물의 흐름을 드러내는 역할을 맡는다.

Coder는 검토 대상 코드나 문서를 작성한 사람이다. 논리 구조를 설명하고, 인스펙션에서 확정된 결함을 바탕으로 재작업을 수행한다.

Tester는 결함을 기록하고 모듈 테스트 관점에서 산출물을 검토한다. 사용자 요구사항과 기술 표준의 부합 여부를 확인하며, 잠재적인 실행 오류를 포착하는 데 집중한다.

Rule Set이 검토 기준을 고정한다

인스펙션의 효과는 명확한 Rule Set과 체크리스트를 사용할 때 커진다. 코딩 표준 준수 여부, 변수 명명 규칙, 자원 해제 로직 포함 여부처럼 검토 기준이 구체적이어야 주관적 판단을 줄이고 결함 발견율을 높일 수 있다.

통합 테스트나 시스템 테스트에서 발견될 결함을 단위 단계에서 찾아내면 수정 비용을 10배 이상 줄일 수 있다. 또한 시니어 개발자의 노하우가 주니어 개발자에게 전달되는 동료 학습(Peer Learning)의 장이 되며, 발견된 결함의 수·유형·밀도를 관리해 이후 프로젝트의 품질 예측에도 활용할 수 있다.

Sources

IEEE Standard for Software Reviews and Audits (IEEE Std 1028)
Software Inspection by Tom Gilb and Dorothy Graham
Michael Fagan's original research on "Design and Code Inspections to Reduce Errors in Program Development"