소프트웨어 인스펙션(Software Inspection) - 개요와 절차, 워크쓰루와의 차이점

 

소프트웨어 인스펙션은 동료 검토 방식 중 가장 엄격한 절차로 수행되는 리뷰 방법입니다.

최근 여러 시스템들이 안전과 보안이 중요해 짐에 따라 가끔식 등장하는 용어인데요.

이번 포스팅에서는 소프트웨어 인스펙션 절차에 대해 상세히 알아 보겠습니다.

 

---

1. 소프트웨어 인스펙션 개요

1.1 소프트웨어 인스펙션의 정의와 목적

소프트웨어 인스펙션은 코드, 설계 문서, 요구사항 명세서와 같은 소프트웨어 산출물을 체계적으로 검토하여 결함을 조기에 발견하고 품질을 높이는 검토 기법입니다. 개발자가 아닌 검토자가 결함을 찾아내고 개선 사항을 제안하는 정적 분석 기법으로, 주로 코드 실행 없이 문서와 코드 자체를 검토하는 방식으로 진행됩니다.

• 결함의 조기 발견: 개발 단계에서 결함을 미리 발견해 수정 비용을 절감하고, 후반부 결함으로 인한 리스크를 줄입니다.
• 품질 향상: 코드의 일관성, 가독성, 유지보수성을 높이고, 소프트웨어 전반의 품질을 향상시킵니다.
• 표준 준수 확인: 코드 작성 표준과 가이드라인을 준수했는지 점검해, 코드 품질의 일관성을 보장합니다.
• 개발자 역량 강화: 동료와의 검토 과정에서 개발자들이 서로 피드백을 주고받으며 코드 작성 능력을 높이고, 코드 작성 방식을 학습할 기회를 제공합니다.

소프트웨어 리뷰에 대한 경제적 가치에 대해 별도로 정리 해 두었습니다.

 

소프트웨어 리뷰(검토)의 경제적 가치, 이익

 

1.2 다른 검토 방식과의 차이점 (동료 리뷰, 워크쓰루와의 차이점)

구분	인스펙션 (Inspection)	동료검토 (Peer Review)	워크쓰루 (Walkthrough)
목적	결함의 체계적 발견, 품질 및 표준 준수 확인	결함 발견과 코드 품질 개선	코드 이해도 향상과 피드백 수집
형식성	고도로 형식적인 구조 기반 진행	자유로운 진행	비공식적, 자유로운 진행
검토방식	정해진 절차와 체크리스트, 기록 유지	코드와 문서 중심의 간단한 검토	작성자가 설명하고, 의견을 자유롭게 교환
진행 주제	인스펙션 리더(Moderator)가 주도	검토자가 주도	작성자가 주도
주요 역할	모더레이터, 작성자, 검토자, 기록자	작성자와 검토자	작성자와 피드백 제공자 (팀원)

 

또한 워크쓰루(Walkthrough)와 인스펙션(Inspection)의 가장 큰 차이점 중 하나는 피드백에 대한 후속 관리(Follow up)의 존재 여부 입니다. 인스펙션의 경우, 피드백에 대해 모더레이터가 지속적으로 개선 여부를 확인하여 후속 관리를 진행해야 하는 것이 절차적으로 명시되어 있지만, 워크쓰루의 경우 별도의 후속 관리가 없이 피드백으로 기반으로 작성자가 피드백을 스스로 반영하도록 하는 것입니다.

 

기능안전 표준인 (ISO/IEC 61508-3)에서는 소프트웨어 정적 분석의 일환으로 워크쓰루와 인스펙션의 활용을 다음과 같이 구분하고 있습니다. 인스펙션의 경우 특정한 기준을 가지고 정형화된 방식으로 인스펙션을 정의하고 있으며, SIL(Safety Integrity Level) 3 부터는 매우 권장(Highly Recommended, HR)로 규정하는 반면 워크쓰루의 경우 전체적으로 권장(Recommended)하고는 있지만 자유롭게 진행할 수 있도록 규정하고 있습니다.

ISO61508-3 Table B-8 Static Analysis

 

그런데 자동차 분야 기능안전 표준인 (ISO 26262-6)에서는 좀 더 엄격하고 구분하고 있습니다. 아래 표에서 보는 바와 같이 ASIL A 인 경우 워크쓰루만으로 허용가능하지만 AIL B 이상인 경우에는 반드시 인스펙션을 수행하도록 규정하고 있습니다.

ISO 26262-4 Table 2 Verification

 

ISO 26262 기능안전 용어에 대해서는 별도로 정의해 두었습니다.

ISO 26262:2018, 자동차 기능안전 용어 (Part 1) : 용어의 중요성과 설명

 

 

2. 소프트웨어 인스펙션의 주요 절차

소프트웨어 인스펙션은 다음과 같이 각 단계별로 지정된 활동의 역할 그리고 산출물들이 지정되어 있습니다.

Fagan Inspection Process

절차 1: 계획 단계 (Planning)

성공적인 인스펙션을 수행하기 위해서는 준비 단계에서 사전 준비를 얼마나 잘 하느냐가 그 결과를 좌우 할 수 있습니다. 

• 대상 선정 및 범위 설정(Author): 인스펙션할 산출물과 검토 범위를 명확히 정하여 모더레이터에게 인스텍션 수행을 요청하게 됩니다. 인스펙션 산출물과 검토 범위의 명확화를 통해 핵심 결함에 집중할 수 있도록 하며, 모더레이터는 인스펙션 수행에 필요한 다음 활동들을 수행하게 됩니다. 하지만 필요에 의해 모더레이터에 의해 이 활동이 수행될 수도 있습니다. 
• 참여자 선정 및 역할 분담(Moderator): 모더레이터는 인스펙션에 참여할 검토자(Inspector)와 테스터(Testoer), 기록자(Recorder), 낭독자(Reader) 등의 역할을 구분하여 인스펙션 팀원을 선정합니다. 
• 자료 준비 및 배포(Moderator): 참여자 선정 및 역할 분담 시 모더레이터는 모든 참여자에게 검토할 코드나 문서, 체크리스트 등을 미리 준비해 검토자들에게 배포하여 사전 숙지할 수 있도록 합니다.
• 검토 기준 설정(Moderator): 결함 발생 가능성이 높은 부분을 중심으로 검토 체크리스트를 작성하여 검토자들이 일관성 있게 검토하도록 합니다. 이때 중요한 사항으로 사전 검토에서 도출해야 하는 것은 결함(Fault)이 아닙니다. 단지 인스펙션을 통해 논의가 필요한 이슈(issue)들을 선정하는 것이어야 합니다. 따라서 검토 기준 설정 시, 반드시 이를 반영하여 검토 기준이 설정되어야 합니다.
• 사전 검토 시간 제공(Moderator): 미팅 전 자료를 충분히 검토할 시간을 제공하여 미팅 시 논의가 효율적으로 이루어지도록 합니다. 
• 일정 및 장소 조율(Moderator): 모든 참여자가 참여 가능한 일정을 잡고, 필요한 경우 온라인 도구 등을 미리 준비합니다.

계획단계에서 고려해야 할 인스펙션 참여자의 역할에 대해서는 별도로 정리해 두었습니다.

 

소프트웨어 인스펙션(Software Inspection) - 참여자 역할과 주의 사항

 

절차 1-1: 개요 단계 (Overview) - 생략 가능

인스펙션 계획에서 참여자가 선정되고, 검토 기준이 설정되었다 하더라도, 모든 참여자가 인스펙션 대상에 대한 내용을 잘 알고 검토를 수행하기에는 어려움이 있을 수 있습니다. 물론, 참여자들이 이미 고경력자로 구성되어 있다면 별도의 개요 단계가 필요 없을 수 있습니다. 그러나 해당 분야에 대해 지식이 미흡한 참여자의 경우 적절한 사전 검토와 인스펙션을 수행하기 어려울 수 있습니다.

이 경우, 개요 단계를 통해 모더레이터는 작성자에게 해당 내용의 설명을 요청할 수 있습니다. 그러면 작성자는 모든 참여자들에게 인스펙션 대상 산출물에 대한 설명을 추가로 진행할 수 있습니다. 이를 통해 모든 참여자들이 적절한 수준의 이해를 바탕으로 사전 검토를 수행할 수 있게 됩니다.

절차 2: 사전 준비 단계 (Preparation)

사전 준비 단계에서는 인스펙션 팀으로 구성된 참여자들의 대상 산출물들을 사전에 정의된 검토 기준에 따라 이슈를 산정하는 활동을 의미합니다. 앞에서 검토 기준 설정에서도 언급한 바와 같이 사전 준비단계에서 참여자들은 인스펙션 산출물에 결함 또는 문제가 있는지를 지적하는 것이 아닙니다. 인스펙션 산출물에 결함 또는 문제점의 지적 및 발견은 실제 인스펙션 미팅에서 결정됩니다. 따라서 사전 준비 단계에서 참여자는 검토 기준에 따라 문제가 있을 수 있다는 이슈 사항 또는 작성자의 의도와 참여자의 이해가 상충되는 경우 이를 이슈로 선정하여 인스펙션 미팅에서 적절한 질의를 통해 문제 또는 결함을 확정하는 과정입니다.

절차 3: 인스펙션 미팅 단계 (Inspection)

인스펙션 미팅의 주요 목적은 산출물에 존재하는 결함을 발견하고 확정하여 이를 개선하기 위한 방안을 논의하는 것입니다. 세부적인 활동 내역은 다음과 같습니다.

• 미팅 시작과 목표 확인: 모더레이터 미팅을 주도하며, 검토 대상과 미팅 목표를 명확히 합니다. 이를 통해 참여자들이 검토의 초점을 맞추고 집중할 수 있도록 합니다.
• 산출물의 설명: 일반적으로 산출물 설명은 낭독자(Reader)라는 역할을 가진 사람에 의해 수행되어야 합니다. 이에 낭독자는 인스펙션 미팅이 빠르게 진행될 수 있도록 논의가 종료되면 바로 사항으로 설명을 이어갈 수 있습니다. 다만, 산출물에 대한 추가 설명이 필요한 경우 작성자가 이를 설명하여 검토자들이 전체적인 흐름을 파악하도록 하며, 필요한 경우 질문에 답변을 하는 지원 역할을 수행할 수 있습니다. 또한 낭독자가 산출물 설명을 하게 함으로써 검토자(Inspector)들이 자유롭고 편안하게 산출물에 대한 이슈 제기를 할 수 있게 할 수 있습니다. 따라서 산출물 설명은 모더레이터나 작성자가 설명하지 않도록 하는 것이 좋습니다.  
• 검토자 피드백 및 결함 발견: 검토자(Inspector)들은 사전 검토에서 발견한 이슈를 공유하고, 이를 논의합니다. 이 과정에서 발견된 결함은 작성자와 검토자 간의 의견 교환을 통해 구체화되며, 결함의 심각성 및 수정 방법에 대한 논의가 이루어집니다.
• 결함 및 논의 사항 기록: 기록자(Recorder)는 발견된 결함과 주요 논의 사항을 상세히 기록하여, 후속 조치가 원활히 이루어지도록 합니다. 기록된 내용은 추후 수정과 개선을 위한 참고 자료로 활용됩니다.
• 미팅 종료와 후속 조치 계획: 미팅이 종료되면 모더레이터가 결함 수정 및 개선 활동에 대한 후속 조치를 정리하고, 일정 및 책임자를 지정합니다. 이를 통해 인스펙션 결과가 실제 품질 개선으로 이어지도록 합니다.

절차 3-1: 인스펙션 분석 단계 (Inspection Analysis) - 생략 가능

인스펙션 분석 단계는 인스펙션 미팅에서 발견된 결함과 개선 사항을 분석하고, 인스펙션의 효과성을 평가하는 단계입니다. 이 단계에서는 인스펙션 결과를 정리하여 결함 수정과 프로세스 개선에 반영하고, 인스펙션 활동이 프로젝트에 기여한 가치를 파악합니다.

• 결함 정리 및 분류: 인스펙션 미팅에서 기록된 결함을 유형별로 분류하고, 결함의 심각도와 우선순위를 평가합니다. 이렇게 분류된 결함 목록은 수정 작업의 효율성을 높이고, 결함 발생 패턴을 분석하는 데 활용됩니다.
• 수정 계획 수립 및 할당: 결함을 수정하기 위한 구체적인 계획을 수립하고, 각각의 결함에 대한 수정 책임자를 지정합니다. 일정과 우선순위에 따라 결함 수정이 체계적으로 진행되도록 관리합니다.
• 인스펙션 효율성 평가: 이번 인스펙션이 얼마나 효과적으로 결함을 발견하고 코드 품질을 향상했는지 평가합니다. 발견된 결함의 수, 인스펙션 소요 시간, 결함 심각도 등을 분석하여 인스펙션 프로세스의 효율성을 점검합니다.
• 프로세스 개선점 도출: 분석 결과를 바탕으로 인스펙션 프로세스 자체를 개선할 수 있는 사항을 도출합니다. 결함 패턴과 인스펙션 과정에서 발견된 문제점, 비효율성을 분석하여, 이후 인스펙션에서 참고할 수 있는 개선 방안을 마련합니다.

절차 4: 수정 단계 (Rework)

인스펙션 수정(Rework) 단계는 인스펙션 과정에서 발견된 결함과 개선 사항을 반영하여 코드를 수정하고 품질을 개선하는 단계입니다. 이 단계에서는 결함이 효율적으로 수정될 수 있도록 정리된 결함 목록을 바탕으로 수정 작업이 이루어집니다.

• 결함 수정 및 개선: 작성자(Author)는 인스펙션 미팅과 분석 단계에서 발견된 결함을 하나씩 수정합니다. 작성자는 결함 목록을 참고하여 코드나 문서에서 필요한 부분을 수정하며, 개선 사항을 코드에 반영합니다. 또한 수정 작업에서는 발견된 결함의 우선순위에 따라 중요한 결함을 먼저 수정하여, 후속 검토 시 수정된 내용이 확인될 수 있도록 합니다.
• 수정 내역 기록: 또한 작성자는 수정된 결함과 개선 사항을 문서화하여 기록으로 남깁니다. 수정 내역 기록은 인스펙션 후속 단계에서 재검토할 수 있도록 하며, 추후 품질 분석에 중요한 참고 자료가 됩니다. 이러한 기록은 특히 반복되는 결함 패턴을 파악하고, 재발을 방지하기 위한 분석 자료로도 활용될 수 있습니다.
• 수정 후 확인 준비: 작성자는 수정이 완료되면, 수정된 부분을 검토할 준비를 합니다. 추가 검토가 필요한 경우, 후속 인스펙션이나 후속 관리(Follow up)를 통해 수정 사항을 점검하고, 결함이 적절히 해결되었는지 확인합니다.

절차 5: 후속 관리 단계 (Follow up)

인스펙션 후속 관리(Follow-up) 단계는 수정 단계에서 이루어진 결함 수정 사항을 검토하고, 인스펙션이 성공적으로 완료되었는지 최종 확인하는 단계입니다. 이 단계는 인스펙션이 실제로 품질 향상에 기여했는지 검증하고, 필요 시 추가 조치를 취함으로써 인스펙션 프로세스를 체계적으로 마무리하는 역할을 합니다.

• 수정 사항 검토: 모더레이터는 수정 단계에서 반영된 결함 수정 내역을 검토하여, 수정 사항이 인스펙션 목적에 부합하는지 확인합니다. 필요한 경우 작성자와 함께 수정된 코드를 재검토하고, 결함이 완전히 해결되었는지 검증합니다. 이 과정을 통해 수정된 내용이 올바르게 반영되었는지, 추가적인 결함이 없는지를 점검할 수 있습니다.
• 재검토 또는 추가 인스펙션: 만약 수정된 코드나 문서에 대해 추가 검토가 필요하다고 판단되면, 후속 인스펙션을 계획합니다. 일부 결함이 제대로 해결되지 않았거나 새로운 결함이 발견된 경우, 이를 재검토하여 문제를 완벽히 해결하도록 조치합니다.
• 인스펙션 결과 문서화: 모더레이터는 최종적으로 모든 결함이 수정되었음을 확인한 후, 인스펙션 결과를 문서화하여 기록으로 남깁니다. 이 기록은 결함 유형, 수정 내역, 인스펙션 소요 시간 등과 함께 인스펙션의 효과성과 효율성을 평가하는 자료로 사용됩니다. 문서화된 결과는 향후 프로젝트에서 참고할 수 있는 자료가 되며, 인스펙션 프로세스 개선에 기여합니다.
• 인스펙션 완료 보고: 모든 수정이 완료되고 검토가 끝나면, 인스펙션 리더는 인스펙션이 완료되었음을 보고합니다. 이로써 인스펙션 프로세스가 마무리되며, 산출물은 다음 단계로 넘어갈 수 있습니다.

---

마치며...

소프트웨어 인스펙션은 단순히 결함을 찾는 과정을 넘어 소프트웨어 품질을 높이고 개발 효율성을 극대화하는 중요한 활동입니다. 인스펙션을 통해 초기 단계에서 결함을 발견하고 수정하면 후반부의 위험을 줄일 수 있으며, 나아가 팀 내 지식 공유와 개발자 역량 강화에도 기여할 수 있습니다.

인스펙션이 성공적으로 이루어지려면, 각 단계에서의 역할을 충실히 수행하고 꼼꼼한 후속 관리가 뒷받침되어야 합니다. 코드 품질과 팀의 발전을 위해 적절한 절차와 기준을 준수하고, 서로 협력하며, 인스펙션에 최선을 다해 노력하는 자세가 중요합니다.

소프트웨어 품질을 향상하는 가장 효과적인 방법 중 하나가 인스펙션임을 기억하며, 모든 참여자가 적극적이고 열정적으로 인스펙션에 임할 때, 보다 완성도 높은 소프트웨어를 만들어 갈 수 있을 것입니다.