서론

신뢰성(Dependability)

• 정의: 신뢰성, 가용성, 안전성, 보안을 포함.
• 의미: 시스템이 예상대로 작동하고 정상 사용에서 실패하지 않는 정도.
• 중요성:
  1. 시스템 실패는 모든 사용자에게 영향.
  2. 불안정한 시스템 → 사용자 거부 및 기업 신뢰도 하락.
  3. 시스템 실패 비용은 매우 큼 (예: 항공기, 원자로 제어 시스템).
  4. 신뢰성 부족 → 데이터 손실 및 복구 비용 상승.
• 설계: 소프트웨어, 하드웨어, 운영 환경 통합 고려, 전체 시스템 관점 필요.
• 고려 요소:
  1. 하드웨어 실패: 설계 오류, 제조 결함, 환경 요인, 수명 종료.
  2. 소프트웨어 실패: 명세, 설계, 구현 오류.
  3. 운영 실패: 사용자의 잘못된 사용이 주요 실패 원인.

---

10.1 Dependability properties

신뢰성의 주요 요소

1. 가용성: 시스템이 특정 시점에 동작하고 서비스를 제공할 확률.
2. 신뢰성: 시스템이 특정 기간 동안 예상대로 서비스를 제공할 확률.
3. 안전성: 시스템이 사람이나 환경에 피해를 줄 가능성.
4. 보안: 시스템이 의도적 또는 우발적 침입에 저항할 가능성.
5. 회복력: 시스템이 중단 상황(예: 장비 고장, 사이버 공격)에서도 핵심 서비스를 유지하는 능력.

세부 속성

• 보안: 무결성(데이터 손상 방지), 기밀성(권한 사용자만 접근 가능).
• 신뢰성: 정확성(정확한 서비스 제공), 정밀성(적절한 정보 수준 제공), 적시성(필요한 시점에 정보 제공).

시스템별 중요 속성 예시

1. 인슐린 펌프: 신뢰성, 안전성 (올바른 용량 제공, 위험한 용량 방지).
2. 기상 관측 시스템: 가용성, 신뢰성 (수리 비용이 높음).
3. 환자 정보 시스템: 보안, 회복력 (민감 정보 보호 및 서비스 지속성).

관련 속성

1. 복구성: 시스템 고장 시 빠르게 진단 및 복구 가능.
2. 유지보수성: 새로운 요구사항에 맞게 저비용으로 시스템 수정 가능.
3. 오류 허용성: 사용자 오류를 감지하고 자동 수정하거나 재입력을 유도.

신뢰성 확보 방법

1. 오류 예방: 개발 및 명세 단계에서 오류 최소화.
2. 검증 및 검증: 잔여 오류 탐색.
3. 내결함성 설계: 고장 시에도 시스템이 동작 유지.
4. 보호 메커니즘: 외부 공격 방지.
5. 환경에 맞는 설정: 운영 환경에 적합하게 시스템 배포.
6. 사이버 공격 대응: 감지 및 저항 기능 포함.
7. 빠른 복구: 실패 및 공격 후 중요한 데이터 손실 없이 회복.

신뢰성 향상 한계

• 성능 저하: 오류 감지를 위한 추가 검사 필요. 성능과 신뢰성 사이의 균형 필요.
• 비용 증가: 높은 신뢰성 확보 → 설계, 구현, 검증 비용 상승.
• 검증 한계: 신뢰성이 높아질수록 오류 발견이 어려워짐 → 더 많은 테스트 필요.
• 극한 사례: 안전-critical 시스템(예: 항공기 제어 시스템)은 규제 기관에 안전성 증명 필요.

---

10.2 Sociotechnical systems

시스템의 특성

• 시스템의 구성 요소들이 통합되고 함께 작동할 때 특정한 속성이 드러남.
• 소프트웨어 엔지니어링은 시스템 엔지니어링의 한 부분임.
• 사회기술 시스템:
  • 하드웨어, 소프트웨어 외에 사람, 프로세스, 조직, 규정 등을 포함하는 시스템.
  • 신뢰성은 기술적 요소뿐 아니라 비기술적 요소에 의해서도 영향을 받음.

사회기술 시스템의 계층 (Sociotechnical System Stack)

1. 장비 계층 (Equipment Layer): 하드웨어 장치로 구성됨.
2. 운영체제 계층 (Operating System Layer): 하드웨어와 상호작용하며 상위 소프트웨어에 공통 기능 제공.
3. 통신 및 데이터 관리 계층 (Communications and Data Management Layer): 원격 시스템, 데이터베이스 접근 등 중간 인터페이스 제공. (미들웨어)
4. 응용 프로그램 계층 (Application Layer): 특정 기능을 수행하는 응용 소프트웨어가 존재.
5. 비즈니스 프로세스 계층 (Business Process Layer): 조직의 업무 프로세스를 포함함.
6. 조직 계층 (Organizational Layer): 비즈니스 규칙, 정책, 전략적 프로세스 등 포함.
7. 사회 계층 (Social Layer): 시스템 운영에 영향을 주는 법률, 규정.

계층 간 상호작용

• 원칙적으로는 인접 계층 간의 상호작용이 이루어져야 함.
• 그러나 예기치 못한 상호작용이 발생할 수 있음.
  • 예: 개인정보 접근법 변경(사회 계층) → 조직 정책 변경 → 비즈니스 프로세스 수정 → 응용 프로그램 및 데이터 관리 계층 수정 필요.

소프트웨어 신뢰성과 시스템 접근

• 소프트웨어는 독립된 것이 아니라 시스템의 한 부분임.
• 소프트웨어 오류의 파급 효과:
  • 중요한 데이터 손실 또는 변조.
  • 추가 작업 필요 (복구 또는 오류 보완).
  • 장비 손상, 기밀성 위반 등의 결과 초래.

• 설계 시 고려 사항:
  1. 소프트웨어 오류가 시스템 스택 내에 격리되어 다른 계층에 영향을 최소화해야 함.
  2. 다른 계층의 결함이 소프트웨어에 미치는 영향을 이해하고, 오류 탐지 및 복구 메커니즘을 포함해야 함.

소프트웨어와 시스템 문제의 구분

• 소프트웨어 엔지니어는 종종 하드웨어나 시스템 설계의 한계를 소프트웨어로 보완해야 하는 상황에 처함.
• 예: 레이더 이미지 고스트 현상:
  • 소프트웨어 이미지 처리 기능 강화.
  • 이로 인해 성능 저하 발생 → 소프트웨어 문제로 인식되지만 사실은 시스템 설계 실패임.
• 예: 덴버 공항 수하물 시스템 실패:
  • 소프트웨어에 장비의 한계를 보완하도록 요구한 결과 발생한 문제.
    - 문제의 근본 원인은 시스템 설계였음.

규제 및 준수

규제와 규제 기관

• 정부는 규칙과 규정을 만들어 제품의 안전과 보안을 보장함.
• 규제 기관:
  • 규정 준수 여부를 감시하는 역할 수행.
  • 규정 위반 시 기업에 벌금 부과 또는 임원 처벌 가능.
  • 특정 산업(항공, 원자력 등)에서 면허 발급 권한을 가짐.

안전 사례와 인증

• 안전 사례: 시스템이 안전하게 작동한다는 것을 규제 기관에 입증하는 문서.
• 안전 사례 개발 비용:
  • 문서 개발 비용은 시스템 개발 비용과 동등할 정도로 높음.

원자력 산업 예시

• 목표: 과열 상황에서도 방사능이 환경으로 유출되지 않도록 보장.
• 안전 사례의 구성 요소:
  1. 소프트웨어 보호 시스템: 소프트웨어가 올바르게 작동해 원자로를 차단함을 입증.
  2. 운영 프로세스: 원자로 코어를 모니터링하는 운영 절차의 신뢰성.
  3. 물리적 구조물: 방사능 유출을 방지하는 물리적 구조의 무결성.

다중 안전 메커니즘

• 소프트웨어 보호 시스템에 대한 대체 안전 메커니즘이 존재해야 함.
• 소프트웨어가 실패해도 다른 안전 장치가 작동함을 입증해야 함.

---

10.3 Redundancy and diversity

소프트웨어 시스템에서의 중복성과 다양성

• 중복성:
  • 동일한 기능을 수행하는 예비 구성 요소를 포함.
  • 주요 구성 요소가 실패하면 자동으로 대체됨.
• 다양성:
  • 중복된 구성 요소를 서로 다르게 설계.
  • 예: 다른 운영 체제를 사용하는 서버로 중복 구성.

검사 코드의 활용

• 필수 기능은 아니지만 데이터 오류와 같은 문제를 감지.
• 오류 감지 시 복구 메커니즘을 실행해 시스템 운영을 유지.

고가용 시스템

• 예비 서버:
  • 주요 서버 실패 시 자동으로 가동됨.
  • 서버가 다른 유형이거나 다른 OS를 사용하여 취약점 악용을 방지.

신뢰성 있는 소프트웨어 개발 프로세스

• 개발 프로세스의 중복성과 다양성:
  • 단일 도구나 기술에 의존하지 않고 여러 방법을 사용.
• 예시:
  • 프로그램 테스트, 수동 코드 검토, 정적 분석을 병행.
  • 같은 작업을 서로 다른 팀원이 수행 → 다양한 관점 제공.

중복성과 다양성의 한계

• 중복성과 다양성은 시스템의 복잡도를 증가시킴.
  • 더 많은 코드 작성 및 검토 필요.
  • 실패 감지 및 제어 전환 기능 추가로 오류 발생 가능성 증가.
• 일부 엔지니어의 관점:
  • 소프트웨어는 마모되지 않음.
  • 중복성과 다양성을 피하고, 단순성에 집중하는 것이 더 나음.
  • 철저한 검증과 검증 절차로 소프트웨어의 신뢰성을 보장.

---

10.4 Dependable processes

신뢰할 수 있는 소프트웨어 개발 프로세스

• 오류를 최소화하여 실행 중 실패 가능성을 줄이는 것.
• 규제 기관에게 소프트웨어가 신뢰할 수 있는 프로세스로 개발되었음을 증명하기 위해 프로세스 모델과 문서화된 증거가 필요함.

신뢰할 수 있는 프로세스의 속성

1. 명확하게 정의된 프로세스:
   • 프로세스 모델이 명확히 정의되어 있고 이를 기반으로 개발이 진행됨.
   • 프로세스가 정확히 수행되었음을 증명하는 데이터가 수집되어야 함.
2. 반복 가능한 프로세스:
   • 개인의 판단이나 해석에 의존하지 않으며, 다른 팀원이나 프로젝트에서도 일관되게 재현될 수 있어야 함.
   • 장기 개발 주기를 가진 중요 시스템에서 특히 중요함.

신뢰성 향상을 위한 활동

1. 요구사항 검토:
   • 요구사항의 완전성과 일관성을 검토.
2. 요구사항 관리:
   • 요구사항 변경이 통제되며, 변경의 영향을 이해하도록 함.
3. 형식적 명세:
   • 수학적 모델을 기반으로 소프트웨어를 명세화하고 분석.
   • 철저한 요구사항 분석을 강제하여 숨겨진 문제를 발견.
4. 시스템 모델링:
   • 소프트웨어 설계를 그래픽 모델로 명확하게 문서화.
   • 요구사항과 모델 간의 연결을 명확히 문서화.
5. 설계 및 프로그램 검토:
   • 다른 사람들이 시스템 설명을 검토하고 체크리스트를 사용해 오류를 찾음.
6. 정적 분석:
   • 자동화된 도구를 통해 소스 코드의 오류를 탐지.
7. 테스트 계획 및 관리:
   • 포괄적인 시스템 테스트를 설계하고, 테스트가 요구사항을 충분히 검증하는지 확인.

품질 관리 및 변경 관리

품질 관리

• 프로세스 및 제품 표준을 설정하고, 표준 준수를 입증하기 위해 프로세스 정보를 문서화.
• 예: 프로그램 검토 표준 → 검토 리더가 표준 준수 여부를 문서화.

변경 관리

• 변경이 관리되고 구현되며, 계획된 소프트웨어 릴리스에 올바른 변경이 포함되도록 보장.
• 문제: 잘못된 구성 요소가 빌드에 포함될 수 있음.
• 해결책: 구성 관리 절차를 정의해 이를 방지.

애자일 접근법과 신뢰할 수 있는 시스템 개발

• 기존 계획 기반 프로세스는 안전-critical 시스템에 널리 사용됨.
• 하지만 애자일 방법론의 가치를 인정하고 일부 수정된 애자일 방법을 채택하는 추세임.

신뢰할 수 있는 시스템 개발에 적합한 애자일 방법:

1. 반복적 개발:
   • 시스템을 작은 단위로 개발 및 검증.
2. 테스트 우선 개발:
   • 오류를 초기에 탐지.
3. 사용자 참여:
   • 개발팀에 사용자 참여를 유도.

---

10.5 Formal methods and dependability

주요 개념

1. 형식 모델:

   • 시스템의 사용자 요구사항을 수학적 언어로 변환하여 명확하고 비모호한 사양을 제공.
   • 수학적으로 정의된 의미론(semantics)을 기반으로 자동 분석 가능.

2. 형식적 분석:

   • 모델을 수학적으로 분석해 오류와 불일치를 탐지하거나 요구사항이 만족됨을 증명.

3. 정확성 보존 변환:

   • 형식 명세를 올바른 변환을 통해 점진적으로 소프트웨어로 구현.
   • 소프트웨어가 명세와 일치함을 보장.

주요 접근법

프로그램 증명 (Program Proving)

• 독립적으로 개발된 프로그램과 명세 간의 일관성을 수학적 증명을 통해 입증.
• 초기에는 수동으로 증명했으나, 자동화된 정리 증명기(theorem provers)가 등장해 더 큰 시스템에서도 적용 가능.

정제 기반 개발 (Refinement-Based Development)

• 형식 명세를 시작점으로 하여 정확성 보존 변환을 통해 소프트웨어를 생성.
• 예시: 파리 메트로 시스템 개발에 사용된 B 언어.

모델 검사 (Model Checking)

• 시스템의 상태 모델을 생성하고, 모델 검사기를 사용해 특정 속성이 항상 만족되는지 검증.
• 속성이 위배될 경우, 시스템의 문제를 식별하고 오류 상태를 제시.
• 예시: 동시 시스템의 데드락 상태 탐지.

형식 방법이 해결하는 오류의 유형

1. 명세와 설계의 오류 및 누락:
   • 형식 모델 개발 및 분석 과정에서 요구사항의 오류와 누락을 발견.
   • 모델 검사를 통해 원치 않는 상태(예: 데드락) 탐지.
2. 명세와 프로그램 간의 불일치:
   • 정제 방법을 통해 소프트웨어 일관성 유지.
   • 프로그램 증명을 통해 명세와 프로그램 간의 불일치를 탐지.

형식 명세의 이점

1. 요구사항에 대한 깊은 이해:
   • 상세한 형식 명세 개발은 요구사항 문제를 조기에 발견하게 함.
   • 개발 후반부에서 발견되는 오류보다 비용이 적게 듦.
2. 자동 분석 가능:
   • 형식 명세는 자동화 도구를 활용해 일관성과 완전성을 검증할 수 있음.
3. 정확성 보존 변환:
   • B 방법과 같은 기법을 사용하면 명세에서 프로그램으로 변환하는 과정이 정확성 보장.
4. 테스트 비용 절감:
   • 형식 검증을 통해 소프트웨어의 정확성이 입증되므로 단위 테스트 비용이 줄어듦.
   • 예시: 파리 메트로 시스템의 경우 시스템 테스트만 수행됨.

출처: Ian Sommerville - Software Engineering