Software Fault Tolerance와 소프트웨어 구현 기법 (N-Version Programming)

소프트웨어는 현대 사회에서 필수적인 역할을 담당하며, 다양한 분야에서 중요한 기능을 수행합니다. 특히, 항공, 자동차, 의료, 금융 시스템과 같이 높은 신뢰성과 안전성이 요구되는 영역에서는 결함(fault)이 발생해도 시스템이 안정적으로 동작할 수 있도록 보장하는 결함 허용(Software Fault Tolerance)이 필수적입니다.

 

1. Software Fault Tolerance란 무엇인가?

Software Fault Tolerance는 소프트웨어 시스템이 결함(fault)이나 오류(error)가 발생하더라도 정상적인 기능을 유지하거나 복구할 수 있도록 설계하는 기법으로 다음과 같은 주요 목표를 가집니다.

1-1. 주요 목표:

• Fault Detection: 결함 발생 여부를 신속히 감지.
• Fault Recovery: 결함이 발생해도 정상적인 작동 상태로 복구.
• Fault Masking: 사용자가 결함을 인지하지 못하도록 정상적인 결과를 제공.

또한 결함 허용(Fault Tolerance)과 유사하게 많이 사용되는 용어로 "고장 안전(Fail-Safety)"이 있는데 먼저 이들을 비교함으로써 소프트웨어 결함 허용(Software Fault Tolerance)의 개념을 정리하도록 하겠습니다.

1-2. Software Fault Tolerance

Software Fault Tolerance는 시스템의 지속적인 동작을 목적으로 시스템에서 결함이 발생하더라도 정상적인 작동을 유지할 수 있도록 설계된 능력을 의미합니다. 결함이 시스템에 영향을 미치지 않도록 복구 메커니즘이 내장되어 있으며, 시스템은 결함이 발생해도 사용자에게 영향을 최소화합니다.

1-3. Software Fail Safety

Software Fail Safety는 사용자의 안전과 환경을 보호하기 위해 시스템에 고장이 발생하거나 예기치 않은 상황에 직면했을 때 "안전한 상태(Safe State)"로 전환되도록 설계된 능력을 의미합니다. 시스템은 고장으로 인해 위험한 상황이 초래되지 않도록 안전성을 우선적으로 보장하며, 안전한 상태(Limphome Mode)로 전환하는 제어로직을 내장하고 있습니다. 

1-4. Fault Tolerance vs. Fail Safety 구현방식 비교

Software Fault Tolerance 구현 방식	Software Fail Safety 구현 방식
중복성(Redundancy) 하드웨어나 소프트웨어를 중복 배치하여 하나의 요소가 실패해도 다른 요소가 대체.	안전 상태 전환 (Transition to Safe State) 고장 시 시스템을 사전에 정의된 안전 상태로 전환
결함 탐지 및 복구 (Detection and Recovery) 결함 발생 시 복구 메커니즘 실행	물리적 차단 (Physical Cutoff) 고장 시 위험 요소를 물리적으로 차단
결함 회피 (Avoidance) 결함 요소를 격리하여 나머지 시스템에 영향을 미치지 않도록 처리	최소 기능 유지 시스템이 안전 상태에서 최소한의 기능만 수행

 

---

2. N-Version Programming 개요

소프트웨어 결함 허용(Software Fault Tolerance)을 구현하기 위한 대표적인 기법에는 N-Version Programming(NVP)이 있습니다.

N-Version Programming 개념

 

먼저 N-Version Programming은 동일한 문제를 해결하기 위해 말 그대로 여러 개의 독립적인 소프트웨어 버전을 개발하고, 다수결(Majority Voting)을 통해 결과를 결합하는 결함 허용 기법입니다. 이때 각 버전은 다른 알고리즘, 프로그래밍 언어, 또는 개발팀을 통해 독립적으로 구현되어야 하며, 여러 버전의 결과를 비교하여 다수결 방식으로 최종 결과를 결정하는 것이 특징입니다. 이를 통해 단일 버전의 오류가 전체 시스템에 영향을 미치지 않게 되며, 결과 비교를 통해 해당 소프트웨어의 신뢰성을 강화할 수 있다는 것이 장점입니다. 

 

그러나 이런 장점에도 불구하고, 여러 버전을 독립적으로 개발해야 하기 때문에 개발 비용이 높고, 개발 시간 또한 길어질 수밖에 없습니다.  그리고 더 큰 문제로 동일하거나 유사한 문제에 의한 설계 결함에 의한 소프트웨어 고장 즉, 공통 모드 고장(Common Mode Failure)에 대해서는 모든 버전이 동일한 설계 결함을 공유할 가능성이 있다는 점이 한계점이라 할 수 있습니다.

---

3. N-Version Programming의 주요 고려사항 및 설계 영향성

3-1. 출력 비교기와 투표 메커니즘

하드웨어 시스템과 마찬가지로, N-Version Programming에서 출력 비교기(Output Comparator)는 여러 버전의 결과를 비교해 투표 메커니즘을 사용하여 최종 출력을 결정하는 간단한 소프트웨어입니다. 여기서 출력 비교기는 NVP에서 여러 소프트웨어 버전의 결과를 분석하여 투표 메커니즘(예: 다수결)을 적용해 최종 출력을 결정하는 핵심 역할을 합니다.

다음은 출력 비교기가 갖추어야 할 특징입니다.

• 단순성 유지: 비교기 로직은 간단하고 신뢰성 있어야 하며, 새로운 오류를 유발하지 않아야 합니다.
• 결함 마스킹: 일부 버전이 실패하더라도 투표 메커니즘을 통해 신뢰할 수 있는 출력을 제공합니다.
• 단일 실패 지점의 위험: 출력 비교기는 모든 결과를 통합하는 역할을 하므로, 출력 비교기의 실패는 시스템 전체의 신뢰성을 위협할 수 있습니다.
  
  

3-2. 실시간 시스템에서의 시간 제약

실시간 시스템에서는 다양한 버전에서 결과가 특정 시간 내에 생성되어야 한다는 요구 사항이 있을 수 있습니다. 이는 각 버전 구현에 따른 시간 제약사항이 될 수 있기 때문에 NVP는 시간 민감도가 높은 애플리케이션(예: 자율주행 차량, 의료 기기)에서 엄격한 타이밍 요구 사항을 충족해야 합니다. 이를 위해 각 버전은 정해진 시간 안에 결과를 생성하고, 서로 동기화되어야 합니다.

• 자원 관리: 각 버전이 충분한 연산 자원과 처리 시간을 확보하도록 설계해야 합니다.
• 지연 허용: 비교기와 투표 과정이 시스템 응답 시간에 부정적인 영향을 미치지 않도록 지연을 최소화해야 합니다.
  
  

3-3. 개발 팀의 독립성과 설계 독립성

각 시스템 버전은 서로 다른 팀이 설계 및 구현합니다. 이때 각 팀들은 동일한 실수를 저지를 확률이 낮다고 가정합니다. NVP의 핵심 원칙은 개발 팀 간 독립성을 유지하여 동일한 설계 결함이 여러 버전에서 동시에 발생하는 것을 방지하는 데 있습니다. 이를 통해 서로 다른 개발 팀이 작업하면 설계 결함이나 해석 오류의 공통 모드 고장(Common Mode Failure) 가능성이 낮아집니다. 다만, 각 팀의 독립성을 보장하기 위해 명확한 요구사항 정의와 팀 간 의사소통 제한이 필요합니다.

 

3-4. 사양 오해와 공통 알고리즘 선택

NVP를 구현하는 서로 다른 팀들이 사양을 유사하게 잘못 해석하고 동일한 알고리즘을 선택하는 경우가 흔하다는 실증적 증거가 있습니다. 즉, 설계 독립성을 유지하려는 노력에도 불구하고, 개발 팀이 동일한 알고리즘을 선택하거나 사양을 유사하게 잘못 해석할 가능성이 있습니다. 이러한 동일 알고리즘 선택은 동일한 결함을 유발할 가능성이 높아, 공통 모드 실패를 초래할 수 있습니다.

 

해결 방안:

• 요구사항 명확화와 다중 리뷰를 통해 사양 해석 오류를 줄입니다.
• 알고리즘 설계를 다변화하거나, 다양한 설계 패턴을 활용하도록 팀을 독려합니다.

---

4. N-Version Programing에서 다중 독립 구현 범위

N-Version Programming에서는 여러 개의 독립적인 소프트웨어를 구현할 때 각 버전 간 독립 구현의 범위를 어느 수준으로 해야 하는지가 이슈가 될 수 있습니다. 이는 앞서 언급한 공통 모드 고장 문제를 해결하기 위해 반드시 고려해야 할 사항으로 독립성의 범위와 기준이 명확하게 결정되어야 한다는 점입니다.  

 

4-1. 알고리즘의 독립성

각 버전은 서로 다른 알고리즘을 기반으로 구현됩니다.

• 동일한 문제를 해결하기 위해 다양한 알고리즘 설계 방법을 활용.
• 각 알고리즘의 설계 철학이나 접근 방식이 다르면, 동일한 조건에서 발생하는 설계 결함을 줄일 수 있음.

예시: 자율주행 차량의 충돌 방지 시스템에서, 한 버전은 LiDAR 데이터를 사용한 거리 계산 알고리즘, 다른 버전은 카메라 데이터를 사용한 객체 탐지 알고리즘을 기반으로 구현.

 

4-2. 프로그래밍 언어의 독립성

서로 다른 프로그래밍 언어를 사용하여 각 버전을 구현합니다.

각 언어는 고유의 문법, 런타임 환경, 컴파일 방식, 오류 처리 메커니즘을 가지므로, 동일한 설계 결함이 모든 버전에 영향을 미칠 가능성을 낮춤.

예시: 동일한 문제를 해결하기 위해, 한 버전은 Python으로, 다른 버전은 C++로 개발.

 

4-3. 개발 팀의 독립성

서로 다른 팀 또는 개발자가 각 버전을 독립적으로 설계하고 개발합니다.

각 팀은 독립적으로 문제를 분석하고 구현 전략을 결정하며, 이를 통해 동일한 요구사항 해석 오류나 설계 결함 발생을 줄임.

예시: A팀은 특정 기능에 대한 요구사항을 독립적으로 분석하고 구현하며, B팀은 같은 요구사항을 다르게 해석하고 구현.

 

4-4. 컴파일러 및 빌드 환경의 독립성

각 버전은 다른 컴파일러 또는 빌드 환경에서 컴파일 및 실행됩니다.

컴파일러의 최적화 방식이나 런타임 환경에 따라 발생할 수 있는 결함을 분산.

예시: 한 버전은 GCC(GNU Compiler Collection)에서 컴파일하고, 다른 버전은 MSVC(Microsoft Visual C++)에서 컴파일.

 

4-5. 실행 환경의 독립성

각 버전은 서로 다른 하드웨어 또는 소프트웨어 실행 환경에서 동작합니다.

특정 하드웨어나 운영체제에서 발생하는 결함이 모든 버전에 동시에 영향을 미치는 것을 방지.

예시: 한 버전은 Windows 운영체제에서 실행되고, 다른 버전은 Linux에서 실행.

 

4-6. 데이터 처리 및 입력 독립성

각 버전은 동일한 데이터를 다르게 처리하거나, 독립적으로 전처리된 데이터를 사용합니다.

데이터의 전처리 방법이나 입력 데이터 형식을 다르게 정의하여 동일한 데이터 오류로부터 보호.

예시: 한 버전은 센서의 원시 데이터를 직접 처리하고, 다른 버전은 필터링된 데이터를 기반으로 처리.

 

---

5. N-Version Programming 적용이 적절한 상황은?

NVP는 동일한 문제를 해결하기 위해 독립적으로 설계된 여러 소프트웨어 버전을 활용하여 시스템의 결함 허용(Fault Tolerance)을 보장하는 기법입니다. 그러나 높은 개발 비용, 설계 복잡성, 테스트 어려움 등의 현실적인 어려움이 있습니다. 이러한 한계를 고려할 때, NVP를 사용하는 상황은 제한적이지만, 특정 상황에서는 매우 효과적인 선택이 될 수도 있습니다. 

 

5-1. 높은 신뢰성과 안전성이 요구되는 상황

항공, 선박, 우주 시스템, 원자력 발전소와 같은 산업에서는 신뢰성과 안전성이 최우선적으로 고려되어야 하며, 이는 상품성이나 사용성보다 더 중요한 요소입니다. 이런 고신뢰성을 요구하는 시스템은 단순히 서비스를 중단하는 것을 넘어 대규모 인명 피해와 환경 재앙을 초래할 수도 있습니다. 

이처럼 신뢰성과 안전성이 무조건적으로 우선시해야 하는 경우, 이를 위해 상품성이나 사용성 등 기타 소프트웨어 품질 속성보다 신뢰성이나 안전성이 더 높은 우선순위를 가지는 경우에는 NVP를 적용하는 것을 적극 고려할 수 있습니다.

다만 추가적인 고려사항으로 고착화된 개발 프로세스나, 개발 조직 내부의 관행의 경직성이나 의사소통과 요구사항 해석 간 이견이나 한계가 있다는 점은 NVP를 적용하는데 걸림돌이 될 수 있습니다.

 

5-2. 실시간 시스템에서의 활용

자율주행차량과 의료기기와 같은 실시간 시스템에서는 실시간성이 시스템 안정성과 안전성을 결정짓는 가장 중요한 요소입니다. 이러한 시스템에서는 단 한순간의 지연이나 결함이 인명 피해나 심각한 사고로 이어질 수 있기 때문에, 상품성(사용자 친화성)이나 사용성보다 실시간 안정성과 안전성이 최우선적으로 고려되어야 합니다.

특히 실시간 시스템은 입력 데이터를 실시간으로 처리하고, 결과를 지연 없이 안정적으로 신뢰성 있게 출력해야 하는 특성을 가집니다. 따라서 NVP를 이용하여 일부 버전에서 결함이 발생해도 다수결 메커니즘을 통해 안정적인 결과를 제공할 수 있으며, 실시간성 관점에서도 독립적으로 실행되는 여러 버전이 동시에 작동하므로 단일 결함이 시스템 전반에 영향을 미치지 않기 때문에 NVP를 적극적으로 고려해야 할 필요가 있습니. 다만, 공통 모드 고장에 대해서는 시스템 전체에 영향을 줄 수 있기 때문에 유의해야 할 사항입니다.

 

5-3. 복구 시간이 제한적인 시스템

온라인 결제 시스템이나 주식 거래 플랫폼, 은행 시스템과 같은 금융 및 거래 시스템은 실시간 데이터 처리와 복구 시간이 매우 중요한 특성을 가진 시스템입니다. 이들 시스템은 매일 수십억 달러 규모의 금융 거래를 처리하며, 결함이나 복구 지연은 막대한 경제적 손실로 이어질 수 있습니다. 예를 들어 초당 수백만건의 금융 거래를 처리해야 함에도 불구하고 고장이 발생하는 경우 금융 거래 처리 불가에 따른 재정적 손실과 더 나아가 금융 시스템 중단에 따른 계약 위반이나 법적 책임으로 이어지게 되는 경우에는 NVP와 같은 Fault Tolerance 기법이 적용되어 결함 허용 능력을 향상하는 것을 적극적으로 고려해야 합니다.

 

5-4. 고비용 개발이 정당화되는 시스템

군사 작전 제어 시스템이나 국가 안보 시스템은 극도의 신뢰성과 내구성을 요구합니다. 예를 들어 미사일 제어 시스템의 경우, 단 한 번의 발사 버튼을 통해 제어 시스템 동작의 성공 여부가 결정되며, 고장 발생 시 목표물을 맞히지 못하거나 예기치 않은 사고를 초래할 수 있습니다. 또한 군함이나 전투 통제 시스템의 경우, 경량의 프로토타입을 통해 반복적인 시험을 통해 신뢰성을 확보하는 것이 쉽지 않습니다. 뿐만 아니라 국방 시스템은 극한의 온도와 압력, 전자기파 간섭 등의 조건에서 안정적으로 작동해야 한다는 점을 추가로 고려해야 합니다. 

따라서 단일 결함에 따른 치명적 영향을 방지하거나 공통 모드 고장을 방지하면서도 높은 신뢰성을 보장해야 하는 경우, 즉 시스템 실패 비용이 매우 큰 경우에는 NVP를 적극 고려해 볼 수 있습니다.

 

---

6. N-Version Programming 적용을 고려하지 않는 것이 나은 상황

6-1. 낮은 신뢰성 요구 시스템

비즈니스 애플리케이션이나 소비자용 웹 서비스와 같은 일부 시스템은 결함이 발생하더라도 치명적인 결과를 초래하지 않으며, 결함 발생 가능성을 일정 수준에서 허용할 수 있습니다. 이러한 시스템에서 NVP를 적용하면 불필요하게 높은 비용이 발생할 수 있으며, 간단한 리던던시(redundancy)나 재시도(retry) 메커니즘으로 충분히 결함 허용성을 제공할 수 있습니다.

 

6-2. 개발 예산과 시간 제약이 큰 시스템

스타트업의 MVP (Minumum Viable Product)나 핵심 기술에 대한 원리 시험용 소프트웨어, 선행 개발 프로토타입과 같은 초기/단기 프로젝트에서 NVP를 활용하게 되면 다중 독립 소프트웨어 버전을 개발해야 하므로, 초기 개발 비용과 시간이 크게 증가합니다. 이러한 상황에서는 제한된 자원을 효율적으로 활용하기 위해 간단한 설계와 최소한의 결함 처리 메커니즘이 더 적합합니다.

 

6-3. 유지보수 및 업데이트가 빈번한 시스템

전자상거래 플랫폼이나 모바일 애플리케이션과 같이 소프트웨어가 자주 업데이트되거나 지속적인 유지보수가 필요한 시스템에서는 NVP를 적용하면 각 버전의 소프트웨어를 개별적으로 업데이트하고 테스트해야 하므로 유지보수 비용이 급격히 증가합니다.

 

6-4. 실시간 성능보다 가용성이 더 중요한 시스템

백오피스 데이터 처리 시스템이나 비실시간 보고서 생성 소프트웨어와 같은 일부 시스템은 실시간 처리가 아닌 안정적인 가용성을 중시합니다. 이렇게 실시간 처리가 필요하지 않다면, NVP보다는 단순한 백업 및 복구 메커니즘이 더 적합합니다.

 

6-5. NVP 적용이 적합하지 않은 사례

상용 소비자 소프트웨어

• 특징: 대부분의 소비자 소프트웨어는 비교적 낮은 신뢰성을 요구하며, 결함 발생 시 사용자 불편 수준에 머무르는 경우가 많습니다.
• 이유: NVP의 높은 비용과 복잡성은 상용 소프트웨어의 개발 목표와 맞지 않습니다. 대신, 지속적인 업데이트와 간단한 복구 메커니즘이 선호됩니다.

비용 대비 효율성이 중요한 시스템

• 특징: 예산 제약이 크고, 시스템 결함에 따른 피해가 비교적 적은 프로젝트.
• 예: 중소기업의 사내 소프트웨어, 비핵심 업무용 애플리케이션.
• 이유: NVP는 높은 비용이 소요되므로, 소규모 프로젝트나 핵심 업무가 아닌 시스템에서는 과도한 선택이 될 수 있습니다.

테스트 및 통합 복잡성을 피해야 하는 시스템

• 특징: 다중 버전의 테스트와 통합이 복잡한 프로젝트.
• 예: 짧은 개발 주기를 가진 애자일 소프트웨어 프로젝트.
• 이유: NVP를 도입하면 테스트와 통합 과정이 복잡해지며, 프로젝트 일정에 지연을 초래할 수 있습니다.
  
  

6-6. NVP를 적용하지 않아도 되는 조건

결함 발생 시 복구가 용이한 경우

시스템 결함 발생 시, 데이터를 복원하거나 프로세스를 재시작하면 문제가 해결될 수 있다면 NVP는 과도한 선택일 수 있습니다.

 

시스템 결함으로 인한 피해가 제한적인 경우

결함으로 인해 서비스가 일시적으로 중단되더라도, 경제적 손실이나 고객 신뢰도 저하가 크지 않은 경우 NVP를 피할 수 있습니다.

 

결함 확률이 매우 낮은 경우

높은 코드 품질과 테스트 과정을 통해 결함 발생 확률이 극도로 낮아진 경우, NVP 없이도 충분히 안정적인 시스템 운영이 가능합니다.

 

---

N-Version Programming의 적용과 선택

N-Version Programming(NVP)은 시스템 신뢰성과 안전성을 극대화하기 위한 강력한 설계 기법으로, 항공, 방위, 원자력, 금융 및 거래 시스템과 같은 고위험, 고비용의 필수 시스템에서 필수적으로 활용됩니다. 특히, 단 한 번의 실행으로 성패가 결정되거나 복구 지연이 치명적 영향을 미치는 시스템에서는 NVP의 적용이 불가피합니다. NVP는 다중 독립적 소프트웨어 버전을 통해 단일 결함과 공통 모드 실패를 방지하며, 시스템의 안정성과 안전성을 확보하는 데 중추적 역할을 합니다.

 

그러나 NVP는 높은 개발 비용과 복잡성, 유지보수의 어려움이라는 한계를 가지고 있으며, 모든 시스템에 적합하지는 않습니다. 결함 발생 시 피해가 제한적이거나, 복구가 비교적 용이한 시스템에서는 단순한 리던던시, 재시도 메커니즘, 코드 품질 강화와 같은 대안이 더 경제적이고 효율적일 수 있습니다.

 

결론적으로, NVP는 그 자체로 보편적인 해답이 아니라 특정 조건과 요구사항에 맞춘 전략적 선택입니다. 시스템의 목적, 신뢰성 요구, 예산, 운영 환경을 면밀히 분석하여 NVP의 적용 여부를 결정해야 하며, 이러한 선택 과정에서 합리적 균형을 유지하는 것이 중요합니다. 기술적 발전과 설계 방법론 개선을 통해 앞으로 NVP는 더 많은 영역에서 실용적이고 효율적인 방식으로 활용될 가능성을 열어갈 것입니다.