독립적인 검증 및 확인(IV&V, Independent Verification and Validation)에 애자일 원칙 통합하기

이 포스팅은 CMU(Carnegie Melon University)의 SEI (Software Engineering Institute) 블로그의 "Incorporating Agile Principles into Independent Verificaiton and Validation (Author: Justin Smith, June 24, 2024)"을 기반으로 작성되었습니다. 

 

우주로 사람을 보내는 소프트웨어를 개발할 때는 예상대로 작동하는지 철저히 검증해야 합니다. 이처럼 안전이 중요한 시스템에서 독립적인 검증 및 확인(IV&V) 프로세스는 제품이 요구사항을 충족하고 의도대로 기능하는지 확인하기 위해 존재합니다. 대부분의 IV&V 방식은 프로젝트 관리의 폭포수 모델과 연관되어 있지만, 애자일 사고방식과 원칙을 도입하면 IV&V 팀이 최신 소프트웨어 개발 프로세스와 더 잘 연계되어 더 나은 결과를 만들어 낼 수 있습니다. 이번 글에서는 애자일 원칙이 IV&V 프로세스와 어떻게 융합될 수 있는지, NASA에서 애자일 IV&V를 실천한 사례, 그리고 애자일로 전환하는 데 도움이 되는 조언을 소개합니다.

또한 NASA의 사례를 소개 합니다. NASA에서는 안전하고 신뢰할 수 있는 소프트웨어 개발을 목표로 애자일 방법론과 IV&V의 통합을 추구하면서, 애자일을 IV&V에 적용하는 실질적인 방법을 고민하고 실험한 사례를 소개합니다.

 

1. IV&V (Independent Verification and Validation)란?

IV&V는 독립 검증 및 확인(Verification and Validation)을 의미하며, 소프트웨어 및 시스템이 요구 사항을 충족하고 기대대로 작동하도록 하기 위해 개발 팀과 독립된 팀이 수행하는 중요한 품질 보증 활동입니다. IV&V는 주로 안전과 신뢰성이 중요한 시스템에서 사용되며, 특히 항공우주, 국방, 의료 및 자동차와 같은 고위험 산업에서 널리 적용됩니다.

Verification and Validation

1-1. 검증(Verification)

검증은 “우리가 올바르게 제품을 만들고 있는가?“라는 질문에 답합니다. 즉, 정해진 절차에 따라 요구사항을 만족하면서 제품을 만들고 있는가에 중점을 둡니다. 따라서 제품이 명세서에 일치하여 개발되고 있는지 확인하는 과정으로, 설계 및 구현이 요구 사항에 부합하는지를 평가합니다.

1-2. 확인(Validation)

확인은 “우리가 올바른 제품을 만들고 있는가?“라는 질문에 답합니다. 즉, 제품이 궁극적으로 고객이나 프로젝트의 실제 필요에 부합하는지 확인하는 과정입니다.

1-3. 독립성의 중요성

IV&V의 “독립성”은 분석을 수행하는 팀이 개발 팀과 별도로 운영되며, 이를 통해 조직적 충돌이나 외부의 영향을 최소화할 수 있도록 합니다. 독립성이 보장되면 분석의 객관성이 유지되고, 제품 품질을 높이기 위한 공정한 평가가 가능합니다. IEEE 1012 표준은 기술적, 관리적, 재정적 독립성을 통해 이러한 독립성을 달성할 수 있도록 권장합니다.

테스트 독립성에 대해서는 따로 정리된 자료를 참고 하실 수 있습니다.

 

소프트웨어 테스트 독립성 (Software Test Independence)

 

1-4. IV&V의 필요성

IV&V는 특히 공공 및 민간 부문에서 리스크 완화나 규정 준수의 일환으로 널리 사용됩니다. 예를 들어, 정부 프로젝트에서는 IV&V가 필수적인 경우가 많으며, 이로 인해 잠재적인 오류를 조기에 발견하고 수정할 수 있어 전반적인 프로젝트 성공 가능성을 높입니다.

그러나 IV&V는 때때로 기존 개발팀과의 ‘우리 대 그들’이라는 대립적인 관계를 형성할 수 있으며, 이는 특히 전통적인 폭포수 개발 방법론을 사용할 때 발생하기 쉽습니다. 폭포수 모델에서는 각 단계가 순차적으로 진행되므로, IV&V 분석은 특정 리뷰 게이트에서 완료되어야 하는 마일스톤으로 설정됩니다. 반면, 점점 더 많은 팀들이 애자일 프로세스로 전환하면서 IV&V는 개발 과정에서 더 빠른 피드백을 제공하도록 요구됩니다.

 

2. IV&V와 애자일

애자일 개발 방식에서는 소규모 작업 단위로 짧은 개발 주기를 반복하며 점진적으로 결과물을 개선합니다. 이러한 방식은 IV&V에서도 활용될 수 있으며, 이를 통해 개발 초기부터 지속적으로 피드백을 제공하고 리스크를 관리할 수 있습니다. IV&V 팀이 애자일 접근 방식을 채택하면 개발 과정에서 발생하는 변경 사항에 보다 유연하게 대응할 수 있어, 개발 팀과의 협업이 개선되고 더 빠르게 유의미한 결과를 제공할 수 있습니다.

 

IV&V는 공공 및 민간 부문에서 리스크 완화 또는 준수 요건의 일환으로 일반적으로 시행되는 관행입니다. 검증(Verification)은 “제품을 제대로 만들고 있는가?“라는 질문을 통해, 제품 구현이 사양과 일치하는지 확인합니다. 반면, 확인(Validation)는 “우리가 만들고자 하는 것이 실제로 필요한 제품인가?“라는 질문으로, 제품이 실제 요구사항에 부합하는지를 평가합니다.

 

IV&V에서 중요한 ‘독립적’이라는 부분은 검증과 확인이 개발팀에 속하지 않은 분석가들에 의해 수행된다는 점을 의미합니다. 이 과정은 프로젝트 성공에 대한 높은 신뢰성을 제공하는 또 다른 시선으로 작동하도록 설계되었습니다. IEEE 1012, 즉 검증 및 확인의 업계 표준은 기술적, 관리적, 재정적 측면에서 독립성을 규정하고 있습니다. 이러한 독립성이 확보되면 분석과 결과가 외부의 영향에 덜 노출되고, 조직의 이해 충돌을 최소화하여 업무에 집중할 수 있습니다.

 

하지만 실무에서는 이러한 접근법이 긴장감을 유발할 수 있습니다. 특히 정부 프로젝트에서는 IV&V가 필수 요건으로 설정되어 ‘우리 대 그들’이라는 분위기를 조성할 수 있습니다. 또한 IV&V는 전통적인 폭포수(Waterfall) 방식이 표준이던 시절에 개발되었습니다. 폭포수 모델에서는 소프트웨어 개발이 순차적으로 진행되며, 요구사항 수집 후 설계, 구현, 테스트가 진행됩니다. IV&V도 이 과정에서 특정한 확인 단계를 통해 완성된 각 단계마다 분석을 수행하는 방식으로 자리 잡았습니다.

 

그러나 최근 많은 소프트웨어 팀이 애자일 프로세스를 채택함에 따라, IV&V 분석가는 개발 과정과 맞지 않는 문제에 직면하게 되었습니다. 애자일 방식에서는 피드백이 필요한 시점에 IV&V가 적시에 이루어지지 않아 불필요한 작업이 발생하고, 이에 따른 불만과 좌절감이 나타나기도 합니다.

IV&V 필요성

 

3. 애자일 원칙과 프레임워크

애자일 프로세스는 반복적이고 점진적인 개발 주기를 강조합니다. 2001년에 소프트웨어 개발자 그룹에 의해 처음 제안된 애자일 소프트웨어 개발 선언문에는 애자일 사고방식을 뒷받침하는 네 가지 가치와 12가지 원칙이 포함되어 있습니다. 이러한 원칙은 고객 만족, 투명성, 유연성을 강조하며, 이는 IV&V(독립적인 검증 및 확인) 팀과 개발팀 간의 협력 관계를 강화하는 중요한 가치로 자리 잡고 있습니다. 이 같은 이유로 애자일 방식은 IV&V 프로세스에 많은 장점을 제공합니다.

애자일의 4가지 가치와 12가지 원칙은 따로 정리된 자료를 참고하시면 좋을거 같습니다.

애자일 소프트웨어 개발 (Agile Software Development)

 

2001년 이후 다양한 애자일 프레임워크 변형이 등장했으며, 대부분은 ‘백로그’라는 개념을 포함합니다. 백로그는 팀이 완료해야 하는 작업을 우선순위에 따라 나열한 목록으로, 팀은 이를 참조하여 작업 계획을 세우고 자원을 할당합니다. 폭포수 방식과 달리, 애자일 개발팀은 시작부터 끝까지 모든 작업을 미리 계획할 필요가 없습니다. 짧은 시간 단위로 작업하면서 문제에 더 빠르게 대응할 수 있으며, 이는 IV&V 프로세스에서 식별된 문제들에 대응하는 데도 유리합니다. 아래는 IV&V에 애자일 방식을 통합하는 데 도움이 된 몇 가지 일반적인 애자일 프레임워크와 요소들의 예입니다.

3-1. 스크럼(Scrum)

스크럼은 다양한 산업에서 널리 사용되는 애자일 프레임워크로, 보통 2~4주 동안 짧은 스프린트(sprint)로 작업을 수행하는 방식을 강조합니다. 스프린트 동안 팀의 지속적인 소통과 협업을 보장하기 위해 여러 계획과 점검 회의가 이루어지는데, 대표적인 예로는 스프린트 시작 시 목표 설정과 백로그 항목을 정하는 초기 계획 회의가 있습니다. 또한, 많은 팀은 매일 ‘데일리 스탠드업’ 미팅을 열어 팀원들이 진행 상황을 공유하고 장애 요인을 식별하는 시간을 갖습니다. 스프린트가 끝나면, 회고(retrospective) 회의를 통해 작업 결과를 평가하고 개선점을 찾습니다.

 

스크럼은 자율 관리 팀을 강조합니다. 자율 관리 팀은 높은 수준의 자율성을 가지고 자체적으로 계획을 세우고 작업을 수행할 수 있습니다. 이러한 팀 구조의 목표는 팀원들이 외부에서 부과된 계획 없이도 결과에 대한 주인의식과 공동 책임감을 느낄 수 있도록 하는 데 있습니다.

스크럼에 대해서는 따로 정리된 자료를 참고하시면 좋을거 같습니다.

스크럼(Scrum): 문제 해결과 솔루션 제시를 위한 간단하지만 강력한 프레임 워크

3-2. 확장형 애자일 프레임워크(SAFe)

SAFe(Scaled Agile Framework)는 대규모 팀에서 애자일 방식을 효과적으로 구현하기 위한 일련의 프로세스를 제공합니다. 대규모 조직이 애자일 워크플로를 도입할 때 다양한 도전에 직면하게 되는데, SAFe는 이러한 복잡한 개발 프로세스를 지원합니다. 특히 장기적인 계획이 필요할 때 계획 간격(PI, Planning Interval)을 도입하여 해결합니다. PI는 일정한 시간 안에 여러 개발 스프린트가 진행된 후 계획 반복 주기를 거치는 시퀀스를 의미하며, 일반적으로 2~3개월 정도의 기간을 갖습니다. 다만, 정부 프로젝트와 같은 경우에는 PI가 더 길어질 수도 있습니다.

 

대규모 애자일을 성공적으로 구현하려면 아키텍처가 매우 중요한 역할을 하는데, 이는 SAFe의 일반적인 적용 사례에서도 확인할 수 있는 부분입니다.

 

4. IV&V에 애자일 적용하기

애자일 프레임워크를 IV&V(독립적 검증 및 확인)에서 적용할 때는 어떻게 활용될까요?

 

애자일 선언서의 주요 우선 사항 중 첫 번째는 “초기와 지속적인 납품 또는 배포를 통해 고객을 만족시키기”이며, 이어서 “몇 주에서 몇 달 사이의 짧은 주기로 작동하는 소프트웨어를 자주 배포”하는 것입니다. 이를 IV&V의 맥락에서 살펴보면, 여기서의 “납품물”을 소프트웨어나 제품이 아닌 “보증”으로 볼 수 있습니다. 애자일 IV&V의 가치는 바로 빠르고 신뢰할 수 있는 보증을 제공해 개발팀의 작업 속도에 맞춰 검증을 진행하는 것입니다. 이러한 애자일 방식은 미 국방부(DoD)에서 사용하는 “연속 운영 허가(Continuous ATO)“와 유사한 개념으로, DoD 시스템의 보안 태세를 강화합니다.

 

그러나 이러한 원칙을 적용하기 위해서는 IV&V에서의 문화와 사고방식의 변화가 필요합니다. 분석가는 전체 소프트웨어를 평가하는 기존 방식에서 벗어나, 개별 기능이나 알고리즘과 같은 작은 단위로 작업해야 할 수 있습니다. 이러한 작은 단위로 작업하는 방식은 워터폴 방식을 탈피하여 오류를 빠르게 파악하고 수정을 더 신속하게 반영할 수 있도록 도와줍니다.

 

또한, 실질적인 워터폴 방식에서의 전환을 넘어서, 애자일 IV&V는 투명성과 커뮤니케이션 강화를 요구합니다. 예를 들어, 스프린트 계획과 회고 미팅을 통해 팀 전체가 진행 상황을 파악하고, 잘 되고 있거나 개선이 필요한 사항에 대해 논의할 수 있습니다. IV&V 활동에 대한 논의가 포함된 일일 스탠드업 미팅은 팀의 일상 업무에 대한 투명성을 높이며 빠른 피드백과 조정의 기회를 제공합니다.

 

애자일 방식의 IV&V는 단순히 더 작은 단위로 검증을 수행하는 것에 그치지 않고, 개발팀과의 긴밀한 협력과 실시간 피드백을 통해 더욱 강력한 품질 보증을 목표로 합니다.

 

스크럼 팀(Scrum Team): 자율성과 협력으로 목표를 달성하는 핵심 단위

 

 

5. NASA의 애자일 IV&V 구현

NASA의 Katherine Johnson IV&V 시설에서 프로젝트 관리를 담당할 당시, 저는 애자일 IV&V 방식을 도입하기 시작했습니다. 그 당시 NASA는 아르테미스 미션을 위해 달 복귀를 목표로 개발 중인 다목적 유인 우주선인 오리온(Orion)을 개발하고 있었습니다. 오리온의 소프트웨어는 매우 복잡하며, 소프트웨어 개발팀은 3개월마다 주요 릴리스를 진행하는 SAFe 모델을 사용하고 있었습니다. 그러나 IV&V 분석가들은 전통적인 개발 모델에 익숙해져 있어, 개발 속도에 맞춰 검증 작업을 따라가지 못했고, V&V 결과를 소프트웨어 개발자들에게 수개월 늦게 전달하는 상황이 발생했습니다.

 

이 문제를 해결하기 위해 NASA는 새로운 접근 방식을 도입해야 한다고 판단했습니다. SEI의 윌 헤이스(Will Hayes)는 IV&V 문맥에서 애자일 원칙을 어떻게 활용할 수 있는지에 대한 이해를 도와주었고, 애자일 방법을 보증 작업에 통합할 수 있도록 목표를 정의하고 구체적인 방법을 제시했습니다. 그리고 백로그(backlog) 활용, 일일 스탠드업, 회고 미팅과 같은 애자일 실무들을 도입하게 되었습니다.

 

또한, 이해 관계자와의 원활한 소통을 통해 팀 간의 협력을 증진하고, 작업 계획을 더욱 효율적으로 세우기 위해 진행 상황을 가시적으로 나타낼 필요가 있었습니다. 이를 위해, 프로젝트 진행 상황, 위험 요소, 그리고 전반적인 프로젝트 상태를 한눈에 보여줄 수 있는 히트 맵(heat map)을 작성하여 진척도를 시각화했습니다.

 

이와 같은 애자일 IV&V 접근 방식은 전통적인 IV&V의 속도와 유연성 한계를 극복하고, 보다 빠르고 신뢰성 있는 검증 결과를 제공할 수 있는 기반을 마련해 주었습니다.

 

Our team's heat map representing the status of each capability we were evaluating for the Artemis I mission.

 

히트 맵의 육각형 하나하나는 Artemis I 미션의 특정 기능을 나타내며, 이는 각 기능의 위험 수준을 시각적으로 보여주는 도구입니다. 작업을 개별 기능 단위로 나누어 애자일의 작은 증분 단위로 작업을 진행함으로써, 필요에 따라 유연하게 우선순위를 재조정하고 반복할 수 있는 구조를 도입했습니다. 분석가들은 먼저 미션 성공에 필수적인 상위 기능을 식별했고, 그 다음 이 상위 기능들이 성공적으로 작동하는 데 필요한 하위 기능들을 독립적으로 구체화했습니다. 이후 NASA IV&V 프로그램에서 개발한 도구를 사용해 이러한 기능들을 위험 수준에 따라 점수화했으며, 전통적인 위험 스케일을 반영해 색상으로 위험도를 나타냈습니다. 히트 맵에서 빨간색은 가장 높은 위험을, 노란색은 다소의 위험을, 녹색은 가장 낮은 위험 수준을 의미합니다.

 

우리 팀은 연 3회 진행되는 PI(Program Increment) 세션 동안 이 히트 맵과 위험 점수를 활용해 백로그의 우선순위를 정하고, 4개월 동안 수행할 작업을 계획했습니다. 특히, 위험도가 높은 기능에 우선순위를 두고 작업을 계획했습니다.

 

애자일 원칙을 적용한 후, 모든 이해 관계자가 쉽게 이해할 수 있는 뛰어난 성과를 확인할 수 있었습니다. 작업을 기능 단위로 나누어 설명함으로써, 단순히 발견된 문제에 대한 설명 대신 프로그램의 모든 수준에서 이해하기 쉽게 의사소통할 수 있었습니다. 기술적 관점에서도 IV&V 팀은 가장 영향력이 크고 위험이 높은 문제에 집중할 수 있었고, 사소한 결함보다 중요한 문제에 우선적으로 작업을 배정할 수 있었습니다. 이로 인해 배포 주기도 수개월에서 몇 주 단위로 단축되어 개발자들의 작업 흐름에 훨씬 잘 맞추게 되었습니다. 요약하자면, 우리는 더 빠르고 유용하며 품질 높은 작업을 제공할 수 있었습니다.

 

6. 더 나은 문화, 더 나은 성과

NASA에서 애자일 IV&V를 도입한 후, 분석가들은 자신이 담당하는 시스템에 대한 깊은 이해와 더불어 프로그램 및 개발 팀과의 소통이 향상되었습니다. 현재 SEI에서 Will Hayes와 함께 애자일 전환 리더로서 저는 이 경험을 바탕으로 DoD 고객들을 위한 IV&V 실무의 애자일 전환을 돕고 있습니다.

 

애자일 사고방식으로의 전환은 곧 문화의 변화입니다. 이는 팀의 신뢰, 심리적 안전성, 그리고 새로운 시도를 하려는 의지와 밀접하게 연결됩니다. 다행히도 애자일 실무는 이런 변화를 촉진하고, 무엇인가 잘 맞지 않는 부분이 있다면 유연하게 변경할 수 있는 환경을 제공합니다. 이 개념은 소규모 팀과 대규모 팀 모두에 적용될 수 있습니다. IV&V의 관점에서 우리의 주요 요소는 독립적으로 구축한 기능 백로그였으며, 전환의 또 다른 핵심은 팀의 신뢰를 쌓는 다양한 애자일 의식이었습니다. 이러한 의식은 개발팀과 분석가 간의 신뢰를 강화하는 데 도움이 됩니다.

 

신뢰가 높아질수록, 팀은 어려운 문제에 대해 더욱 솔직하게 소통하게 됩니다. 문제가 있는 부분에 대해 두려움 없이 이야기할 수 있는 분위기가 조성되면, 팀은 보다 신중하게 계산된 위험을 감수하게 되며 이는 심층적으로 숨겨진 문제를 발견하고 작업 방식에서의 혁신을 촉진할 수 있습니다.