Software Quality Assurance

소프트웨어의 품질이 만족할 만한 수준이라는 확실한 증거를 얻기 위해서는 무엇이 필요할까? 소프트웨어 제품의 품질과 개발 프로세스의 품질을 연결하는 것도, 소프트웨어의 품질을 평가하기 위한 여러 지표도 그 질문에 대한 답을 얻기 위한 노력의 산물이다. 소프트웨어의 품질이 만족할 만한 수준이라고 확실하게 말하기 위해서는 소프트웨어의 품질을 보증하기 위한 활동, 소프트웨어 품질 보증이 필요하다. 아래에 그 정의가 적혀 있다.

SQA의 역사적 맥락

소프트웨어 품질 보증이라는 개념이 독립적인 활동으로 자리잡기까지는 상당한 시간이 걸렸다. 1968년 NATO 소프트웨어 공학 회의에서 "소프트웨어 위기"가 공식적으로 인식된 이후에도, 품질은 오랫동안 개별 개발자의 역량에 의존하는 문제로 여겨졌다. 이 상황을 근본적으로 바꾼 것이 1987년 Watts Humphrey와 SEI 연구팀이 발표한 소프트웨어 공학 역량 평가 방법론이다 (Humphrey et al., 1987)¹. 이 보고서는 소프트웨어 개발 조직의 프로세스 역량을 체계적으로 평가할 수 있는 프레임워크를 최초로 제시했으며, 이후 CMM과 CMMI로 발전하는 토대가 되었다. Humphrey의 핵심 통찰은 "소프트웨어의 품질은 그것을 만드는 프로세스의 품질에 의해 결정된다"는 것이었고, 이 관점이 SQA를 개별 제품 검사에서 프로세스 중심의 체계적 활동으로 전환시킨 분수령이 되었다.

QA(Quality Assurance) vs QC(Quality Control)

품질 보증과 품질 통제Quality Control은 제조업에서의 품질 관리 개념이 진화하면서 등장하게 되었는데, 둘의 차이는 진화의 과정에서 설명된다.

장인의 역량 → 1차 산업혁명, 근대적 생산 공장의 탄생 → 작업 감독관 → 감독관의 책임과 압박 상승, WW1 → 정밀 검사, 독립적인 검사자 → 제품 기능의 복잡도 향상, WW2 → 테스팅, 통계적 품질 관리(여기서 품질 통제의 개념이 도입됨) → 경쟁 심화로 제조 품질의 한계 봉착, 설계 품질 향상 필요 → 표준과 가이드(여기서 품질 보증의 개념이 도입됨) → 품질은 특정 부서의 책임이 아니라 조직의 문화임 → 전사적 품질 관리 활동(Total Quality Management 개념이 도입됨)

그래서 품질 통제는 다음과 같이 정의된다.

표로 비교하면 다음과 같다.

SQA의 원칙

SQA 수행 체계는 조직의 규모나 프로젝트의 개발 규모, 제품 특성, 고객 요구사항, 개발 라이프사이클 등을 고려하여 정의한다. 핵심 원칙은 크게 네 가지다. 첫째, 결함 유입을 최소화한다. 둘째, 유입된 결함은 가능한 한 일찍 발견한다. 셋째, 라이프사이클 전체를 고려하고 고객의 관점에서 프로젝트를 바라본다. 넷째, 품질 보증 활동의 객관성을 확보한다.

SQA의 요소

Pressman은 SQA가 포괄하는 관심 영역과 활동을 다음과 같이 정리한다 (Pressman & Maxim, 2020, Ch.17).

SQA는 여섯 가지 핵심 요소로 구성된다. (1) SQA 프로세스, (2) 기술 검토와 다층적 테스팅 전략을 포함하는 품질 보증·통제 태스크, (3) 효과적인 소프트웨어 공학 실천(방법론과 도구), (4) 모든 산출물과 변경 사항에 대한 통제(형상 관리), (5) 개발 표준 준수를 보장하는 절차, (6) 측정과 보고 메커니즘이다.

이 요소들은 다시 구체적인 활동 영역으로 나뉜다².

• 표준: IEEE, ISO 등 표준 기관이 제정한 소프트웨어 공학 표준의 채택과 준수를 보장한다.
• 검토와 감사: 기술 검토는 엔지니어가 수행하는 품질 통제 활동이며, 감사Audit는 SQA 인력이 품질 가이드라인 준수 여부를 확인하는 활동이다.
• 테스팅: 테스트가 적절히 계획되고 효율적으로 수행되어 결함 발견의 가능성을 극대화하도록 보장한다.
• 결함 수집과 분석: 오류·결함 데이터를 수집·분석하여, 어떤 소프트웨어 공학 활동이 결함 제거에 가장 적합한지 이해한다.
• 변경 관리: 변경이 적절히 관리되지 않으면 혼란으로 이어지고, 혼란은 거의 항상 낮은 품질을 초래한다.
• 교육: SQA 조직이 소프트웨어 프로세스 개선의 선두에 서서 교육 프로그램을 주관한다.
• 공급업체 관리: 외부 벤더에게 품질 실천을 권고하고, 계약에 품질 요구사항을 명시한다.
• 보안 관리: 데이터 보호 정책, 방화벽, 소프트웨어 무결성 검증 등 적절한 프로세스와 기술이 적용되도록 보장한다.
• 안전성: 소프트웨어 장애가 초래할 수 있는 잠재적 위험hazard을 식별하고 평가하여, 위험을 제거하거나 통제하는 설계 특성을 명세한다.
• 리스크 관리: 리스크 분석과 완화 활동이 적절히 수행되고 대응 계획이 수립되었는지 확인한다.

품질 비용

SQA 활동에 자원을 투입하는 것이 과연 경제적으로 합리적인지에 대한 질문은 품질 비용Cost of Quality, CoQ 모델로 답할 수 있다. Pressman은 품질 비용을 세 가지 범주로 구분한다 (Pressman & Maxim, 2020, Ch.17).

첫째, 예방 비용Prevention Cost은 결함이 발생하지 않도록 사전에 투입하는 비용이다. 품질 계획 수립, 기술 교육, 공식적인 기술 검토³, 테스트 장비 구축 등이 여기에 해당한다. 둘째, 평가 비용Appraisal Cost은 소프트웨어가 요구사항을 만족하는지 확인하기 위해 투입하는 비용으로, 인스펙션inspection과 테스트 실행 비용이 대표적이다. 셋째, 실패 비용Failure Cost은 결함이 발견되지 않아 발생하는 비용이다. 실패 비용은 다시 내부 실패 비용과 외부 실패 비용으로 나뉘는데, 내부 실패 비용은 제품이 출시되기 전에 결함이 발견되었을 때의 재작업rework 비용이고, 외부 실패 비용은 출시 후 사용자가 결함을 발견했을 때의 수정·지원·배상 비용이다.

Crosby (1979)가 "품질은 공짜"라고 주장한 핵심 논거가 바로 이 구조에 있다. 예방과 평가에 투자하면 실패 비용이 극적으로 줄어들어 총 품질 비용이 오히려 감소한다는 것이다. Boehm과 Basili (2001)의 연구에 따르면 요구사항 단계에서 발견된 결함의 수정 비용을 1로 놓았을 때 유지보수 단계에서의 수정 비용은 최대 100배에 달하므로, 품질 활동을 개발 초기에 집중하는 것이 경제적으로도 합리적이다.

산업계의 품질 문화: Google의 사례

학술적 SQA 프레임워크와 별개로, 산업계에서는 조직 문화 차원에서 품질을 내재화하는 접근이 주목받고 있다. Google은 "소프트웨어 공학은 시간에 걸쳐 통합된 프로그래밍"이라는 정의 아래, 테스트를 독립적인 QA 부서의 책임이 아닌 모든 엔지니어의 책임으로 규정한다 (Winters et al., 2020, Ch.11)⁴.

Google의 접근에서 핵심적인 원칙은 두 가지다. 첫째, 테스트 작성은 코드 작성의 일부이지 별도의 활동이 아니다. 코드 리뷰 과정에서 테스트가 없는 변경은 원칙적으로 승인되지 않으며, 이 관행이 조직 전체에 품질 의식을 체화시킨다. 둘째, 코드 리뷰 그 자체가 강력한 품질 게이트 역할을 한다. Google에서는 모든 코드 변경이 최소 한 명의 다른 엔지니어의 승인을 받아야 하며, 이 과정에서 설계 결함, 가독성 문제, 잠재적 버그가 사전에 걸러진다 (Winters et al., 2020, Ch.9). 이는 Pressman이 강조한 예비 검사 단계의 결손 제거 효율성이 테스팅보다 높다는 데이터와도 정확히 일치하는 산업계의 실증 사례다.

Jalote (2000)는 이러한 조직 문화적 접근을 CMM 프로세스 프레임워크 안에서 구현한 Infosys의 사례를 상세히 기술한다. Infosys는 프로젝트마다 품질 계획을 수립하고, 결함 데이터를 체계적으로 수집·분석하여 프로세스 개선에 반영하는 순환 구조를 운영함으로써 CMM 레벨 5에 도달했다. 학술적 프레임워크와 산업 실천 사이의 간극을 메우는 대표적인 사례라 할 수 있다.

QA In Production

전통적으로 QA 활동은 배포 이전 활동에 중점을 두었지만, 소프트웨어와 운영 환경이 복잡해지면서 프로덕션 환경의 소프트웨어를 모니터링하여 품질 이슈를 식별할 필요성이 대두되었다. 프로덕션에서 수집되는 데이터를 통해 현실에 기반한 QA 접근이 가능해진 것이다.

이러한 흐름 속에서, CMMI에서 소프트웨어 품질 보증을 담당하는 프로세스 영역이 바로 프로세스 및 제품의 품질 보증Process and Product Quality Assurance, PPQA이다. 이 프로세스 영역의 목표와 프랙티스를 살펴보자.

Process and Product Quality Assurance

^0a76ec

프로세스 영역의 목표와 프랙티스는 아래 다이어그램과 같다.

Objectively Evaluate Processes and Work Products

프로세스 그리고 프로세스와 연결된 산출물이 프로세스의 기술, 프로세스의 표준, 그리고 프로세스의 절차에 충실한지 객관적으로 판단하는 것이 PPQA의 첫번째 목표다. 여기에는 두 개의 프랙티스가 존재한다.

Objectively Evaluate Selected Performed Processes Against Applicable Process Descriptions, Standards, and Procedures

첫번째 프랙티스는 수행된 프로세스와 객관적으로 비교하는 방식으로 적용 가능한 프로세스를 평가하는 것이다. 이미 수행된 프로세스 그 자체를 두고 다른 대안을 적용하는 게 더 낫지 않았는지 비교하는 것이다.

Objectively Evaluate Selected Work Products Against Applicable Process Descriptions, Standards, and Procedures

두번째 프랙티스도 첫번째와 비슷하지만, 이번에는 산출물이 평가의 대상이 된다. 프로세스의 결과로서 만들어진 산출물과 적용 가능한 다른 프로세스의 결과로 나왔을 산출물을 비교하게 된다.

Provide Objective Insight

PPQA의 두번째 목표는 객관적인 인사이트를 제공하는 것이다. 기존의 계획이나 목표를 충족하지 못하면서 생긴 이슈Noncompliance Issue들은 객관적인 기준 아래에서 추적되고 소통되며, 이러한 이슈들은 반드시 해결되어야 한다. 이를 위한 프랙티스는 총 두 개다.

Communicate quality issues and ensure the resolution of noncompliance issues with the staff and managers.

품질 이슈에 대해 프로젝트에 참여한 스태프들과 관리자들과 소통하고 기대치를 충족하지 못한 부분이 반드시 채워지도록 보장해야 한다.

Establish and maintain records of quality assurance activities.

이러한 모든 품질 보증 활동은 기록되어야 한다.

Quality Assurance Activities

그런데 품질 보증 활동에는 어떤 것들이 있을까? 기준은 Verification과 Validation이다. Verification은 내가 지금 일을 올바르게 하고 있는지 점검하는 것이며, Validation은 내가 지금 올바른 일을 하고 있는지 점검하는 것이다. 주요 방법으로는 검토⁵, 테스팅(정적 테스트 / 동적 테스트), 감사Audit, 제품 메트릭 수집/분석 등이 있다. 그렇다면 어떤 방법이 제일 좋은 방법일까?

Test vs Pretest

소프트웨어의 품질을 추산하거나 실제로 품질을 측정할 때 중요한 주제 중 하나는 예비 검사pretest에서 오류를 제거하는 활동removal activity과 테스트 단계에서 결손 제거의 효율성defect removal efficiency이 어느 정도 수준인지 아는 것이다.

Test

아래 표는 기능 점수가 10,000점이거나 자바와 같은 언어로 500,000개의 선언문이 작성된 정도의 크기를 가진 애플리케이션을 전제로 테스트 단계에서 일어나는 활동의 효율성을 분석한 것이다. 데이터는 결손 제거 효율성의 내림차순으로 정렬되어 있다.

위와 아래에 표가 이어져 있는데, 이중에서 시스템 테스트System Testing와 새로운 함수 테스트New Function Testing, 회귀 테스트Regression Testing, 그리고 단위 테스트Unit Testing이 새로운 결손을 낳는 잘못된 수정을 주입하는 비율Bad-Fix Injection Percent이 유독 높은 편인 것을 확인할 수 있다.

이것을 정리해보자면, 테스트가 결손을 아주 잘 찾아내거나 비용 측면에서 엄청 효율적이었던 적은 없는 셈이다.

Pretest

그렇다면 예비 검사에서는 어떨까? 예비 검사에서의 결손 제거Pretest Defect Removal는 실제 테스트를 진행하기 이전에 결손을 제거하는 여러가지 활동을 뜻한다. 직접 코드를 읽어가며 코드를 검사traditional desk checking하거나 비공식적인 동료 리뷰informal peer review를 받는 것부터 설계와 코드에 대한 공식적인 정밀 검사, 그리고 소스 코드에 대한 정적 검사까지 포괄하는 개념이다. 버그를 잡는 데 효과적이고 비용 절감 효과도 같이 누릴 수 있다. 테스트 사이클 횟수가 줄고 테스트의 효율이 높아진다. 예비 검사 단계에서 정밀하게 검사하고 정적 분석을 하는 것이 테스팅보다 25% 더 효율적이고, 추가적인 정밀 검사와 정적 분석이 테스트의 효율 수준을 5% 가량 올려줄 수 있다.

위 테이블을 보면 모든 테스트를 조합해도 누적 결손 제거 효율성이 85%를 넘기기가 힘들고 95%를 넘으려면 예비 검사 단계와 최소 8가지 이상의 정식 테스트를 모두 거쳐야 한다. 다행히 결손 제거 효율성이 95%를 넘어가면 테스팅만 하는 것보다 비용도 낮고 일정도 짧아서 품질도 높아지고 개발 속도도 올라간다.

예비 검사 단계에서 결손을 미리 제거하는 방법은 프로젝트의 규모에 따라 달라진다. 작은 규모의 프로젝트에서는 스스로 직접 코드를 검토하거나 스크럼 세션을 가지거나 명세서에 대한 분명한 리뷰, 동료들의 비공식적인 리뷰, 코드의 정적 분석 등을 통해 결손을 찾을 수 있다. 반면 더 큰 규모에서는 독립적인 검증과 인증Independent V&V, SQA 리뷰, 페이즈 리뷰, 각종 형식적인 정밀 검사Formal Inspection들이 추가된다 (Jones & Bonsignour, 2011, Ch.4).

통계적 소프트웨어 품질 보증

통계적 품질 보증Statistical Software Quality Assurance은 소프트웨어 산업 전반에서 품질에 대해 더 정량적으로 접근하려는 흐름을 반영한다. Pressman은 이 접근을 네 단계로 요약한다 (Pressman & Maxim, 2020, Ch.17).

1. 소프트웨어 오류와 결함에 대한 정보를 수집하고 범주화한다.
2. 각 오류와 결함의 근본 원인을 추적한다. 예컨대 명세서 불완전, 설계 오류, 표준 위반, 고객과의 소통 부재 등이 원인이 될 수 있다.
3. 파레토 원칙⁶을 적용하여, 전체 결함의 80%를 유발하는 20%의 핵심 원인vital few을 격리한다.
4. 핵심 원인이 식별되면 해당 문제를 교정한다.

이 과정은 적응적 소프트웨어 프로세스adaptive software process를 향한 중요한 단계로, 오류를 유발하는 프로세스 요소를 개선하는 데 초점을 맞춘다. 실제로 통계적 SQA 기법을 적용한 소프트웨어 조직에서는 연간 50%의 결함 감소를 달성한 사례가 보고되었다.

Six Sigma

Six Sigma는 오늘날 산업 전반에서 가장 널리 사용되는 통계적 품질 보증 전략이다. 1980년대 Motorola에서 시작된 이 전략은 프로세스 산출물의 품질을 향상시키기 위해 변동variation과 결함의 원인을 최소화하는 데 집중한다. 'Six Sigma'라는 이름은 100만 건당 3.4건의 결함이라는 극도로 높은 품질 기준에서 유래했다⁷.

기존 프로세스가 존재하고 개선이 필요한 경우에는 DMAIC(Define → Measure → Analyze → Improve → Control) 방법을 사용한다. 새로운 프로세스를 설계하는 경우에는 DMADV(Define → Measure → Analyze → Design → Verify) 방법을 적용한다.

소프트웨어 신뢰성

소프트웨어 신뢰성Software Reliability은 품질의 여러 요소 중에서도 직접 측정이 가능한 요소다. 통계적 용어로 정의하면, "지정된 환경에서 지정된 시간 동안 컴퓨터 프로그램이 고장 없이 작동할 확률"이다 (Musa et al., 1987).

신뢰성과 가용성 측정

초기의 소프트웨어 신뢰성 연구는 하드웨어 신뢰성 이론의 수학을 소프트웨어에 적용하려 했지만, 하드웨어 고장이 주로 마모wear에 기인하는 반면 소프트웨어 고장은 전적으로 설계나 구현의 결함에 기인한다는 근본적인 차이가 있다.

대표적인 신뢰성 척도는 평균 고장 간격Mean Time Between Failure, MTBF이다.

$\text{MTBF} = \text{MTTF} + \text{MTTR}$

여기서 MTTF는 평균 고장 시간Mean Time To Failure, MTTR은 평균 수리 시간Mean Time To Repair이다⁸. 최종 사용자의 관심사는 총 결함 수가 아니라 고장 그 자체이므로, MTBF가 다른 품질 메트릭보다 더 유용한 척도라는 주장이 많다.

가용성Availability은 주어진 시점에서 프로그램이 요구사항에 따라 작동할 확률이며, 다음과 같이 정의된다.

$\text{Availability} = \frac{\text{MTTF}}{\text{MTTF} + \text{MTTR}} \times 100\%$

이 공식에서 알 수 있듯이 가용성은 MTTR, 즉 소프트웨어의 유지보수성maintainability에 더 민감하게 반응한다.

SQA 계획

SQA 계획SQA Plan은 소프트웨어 품질 보증을 조직적으로 수행하기 위한 로드맵이다. IEEE는 SQA 계획의 표준 구조를 다음과 같이 권고한다 (IEEE 730:2014).

1. 계획의 목적과 범위
2. SQA의 관할 대상인 모든 소프트웨어 공학 산출물(모델, 문서, 소스코드)에 대한 기술
3. 소프트웨어 프로세스에 적용되는 모든 표준과 실천 방법
4. SQA 활동과 태스크(검토, 감사 포함) 및 소프트웨어 프로세스 내 배치
5. SQA 활동을 지원하는 도구와 방법
6. 소프트웨어 형상 관리 절차
7. 모든 SQA 관련 기록의 수집·보관·유지 방법
8. 제품 품질에 대한 조직적 역할과 책임

이 계획은 프로젝트 계획의 일부로 개발되며, 모든 이해관계자가 검토한다. SQA 그룹이 존재하지 않는 조직에서는 소프트웨어 팀 자체가 이 계획을 수립한다.

마무리

소프트웨어 품질 보증은 소프트웨어 공학의 우산 활동umbrella activity으로서, 소프트웨어 프로세스의 모든 단계에 적용된다. SQA는 방법론과 도구의 효과적인 적용, 기술 검토와 테스팅을 통한 품질 통제, 형상 관리를 통한 변경 관리, 표준 준수 절차, 그리고 측정과 보고 메커니즘을 포괄한다.

핵심은 테스트만으로는 충분하지 않다는 점이다. Jones & Bonsignour (2011)의 데이터가 보여주듯, 모든 테스트를 조합해도 누적 결손 제거 효율성이 85%를 넘기기 어렵다. 예비 검사 단계의 정밀 검사와 정적 분석을 결합해야 비로소 95% 이상의 결손 제거 효율성에 도달할 수 있으며, 이때 비용은 오히려 줄어들고 일정은 단축된다.

통계적 SQA는 파레토 원칙을 활용하여 핵심 원인에 자원을 집중하고, 소프트웨어 신뢰성 모델은 수집된 결함 데이터를 고장률과 신뢰성 예측으로 확장한다. Dunn & Ullman (1982)의 표현처럼, "소프트웨어 품질 보증은 품질 보증의 관리적 원칙과 설계 규율을 소프트웨어 공학의 관리적·기술적 영역에 매핑하는 것"이다. 이 매핑이 성공적으로 이루어질 때, 성숙한 소프트웨어 공학이 실현된다.

---

출처

• Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill. Ch.15–17.
• Jones, C., & Bonsignour, O. (2011). The Economics of Software Quality. Addison-Wesley. Ch.4–5.
• Winters, T., Manshreck, T., & Wright, H. (2020). Software Engineering at Google: Lessons Learned from Programming over Time. O'Reilly. Ch.9, Ch.11.
• Humphrey, W., Sweet, W. L., Edwards, R. K., LaCroix, G. R., Owens, M. F., & Schulz, H. P. (1987). A Method for Assessing the Software Engineering Capability of Contractors. Software Engineering Institute, Carnegie Mellon University. CMU/SEI-87-TR-23.
• Jalote, P. (2000). CMM in Practice: Processes for Executing Software Projects at Infosys. Addison-Wesley.
• IEEE 730:2014. IEEE Standard for Software Quality Assurance Processes.
• CMMI-DEV 1.3. CMMI for Development, Version 1.3. Software Engineering Institute.
• ISO/IEC/IEEE 24765:2017. Systems and software engineering — Vocabulary.
• Musa, J. D., Iannino, A., & Okumoto, K. (1987). Software Reliability: Measurement, Prediction, Application. McGraw-Hill.
• Crosby, P. B. (1979). Quality Is Free. McGraw-Hill.
• Boehm, B. W., & Basili, V. R. (2001). 'Software Defect Reduction Top 10 List', Computer, 34(1), pp.135–137.
• Fagan, M. E. (1976). 'Design and Code Inspections to Reduce Errors in Program Development', IBM Systems Journal, 15(3), pp.182–211.

---

Footnotes

1. Humphrey et al. (1987)의 CMU/SEI-87-TR-23 보고서. 미 국방부의 소프트웨어 계약자 역량 평가를 위해 개발되었으며, 5단계 성숙도 프레임워크의 원형을 제시했다. 이 보고서가 1991년 CMM v1.0과 이후 CMMI로 발전하는 직접적인 기반이 되었다. ↩

2. Pressman & Maxim (2020, pp.341–342)이 제시한 SQA 요소 목록. 각 요소는 독립적이 아니라 상호 연결되어 있으며, SQA 그룹은 이 모든 영역을 조율하는 역할을 한다. ↩

3. 공식 기술 검토Formal Technical Review는 Fagan (1976)이 IBM에서 체계화한 인스펙션에 뿌리를 둔다. Fagan은 설계와 코드에 대한 구조화된 인스펙션이 결함의 60~90%를 테스트 이전에 제거할 수 있음을 실증했다. ↩

4. Winters et al. (2020, Ch.11)은 Google의 테스트 철학을 "테스트는 생산성의 배수기multiplier"라고 표현한다. 테스트에 투자한 시간이 디버깅과 장애 대응에 소비될 시간을 몇 배로 절약해준다는 의미다. ↩

5. Peer Review, Walkthrough, Inspection 등을 포괄한다. 검토의 종류와 효과에 대해서는 Pressman Ch.16을 참고하라. ↩

6. 파레토 원칙Pareto Principle. 이탈리아 경제학자 Vilfredo Pareto가 발견한 80/20 법칙으로, 소프트웨어 결함의 80%가 전체 원인의 20%에서 비롯된다는 경험적 규칙이다. ↩

7. Six Sigma의 'σ(시그마)'는 통계적 표준 편차를 의미하며, 6σ 수준은 100만 건당 3.4건의 결함률에 해당한다. DMAIC와 DMADV는 각각 기존 프로세스 개선과 신규 프로세스 설계에 적용되는 체계적 방법론이다. ↩

8. MTBF와 관련 측정은 벽시계 시간wall clock time이 아닌 CPU 시간 기준이라는 점에 유의해야 한다. 또한 고장 후 다른 변경 없이 재시작만으로 정상 작동하는 경우도 많다. ↩