신뢰성·유지보수성·이식성 테스트 — 덜 다뤄지는 축을 측정 가능하게

개념

왜 이 세 축만 비어 있는가

레슨 3의 5단계 절차를 신뢰성·유지보수성·유연성에 적용하면 대부분의 팀이 ②번(품질 요구 진술)에서 막힌다. 이유가 세 특성에 공통이다.

① 관측 창이 릴리즈보다 길다  "3개월 무장애"는 2주 시험 기간에 판정 불가
② 측정 주체가 QA가 아니다    가용성은 운영이, 복잡도는 개발이 본다
③ 판정 기준을 쓸 언어가 없다  "안정적이어야 한다"는 합격·불합격이 갈리지 않는다

①②는 바꾸기 어렵다. 바꿀 수 있는 것은 ③ 이고, ③을 해결하면 ①②도 따라온다 — 판정 가능한 문장이 있으면 누가 언제 재는지가 정해진다.

판정 가능한 요구 문장의 여섯 칸

비기능 요구 문장이 시험 항목이 되려면 여섯 칸이 채워져야 한다.

측정 창과 측정 방법이 제일 자주 빈다. 이 둘이 비면 문장은 그럴듯한데 판정하려는 순간 논쟁이 된다.

용어 — 어느 판을 기준으로 쓰는가

모듈 30 레슨 2에서 확인한 대로 ISO/IEC 25010은 2023년 2판에서 특성 구성이 바뀌었다. 관련된 변화는 둘이다 — 이식성(Portability)이 유연성(Flexibility)으로 바뀌고 확장성이 신설됐으며(적응성·설치성·대체성 이름은 유지), 신뢰성의 성숙성(maturity)이 무결함성(faultlessness)으로 바뀌었다.

이 레슨은 2023판 이름을 기본으로 쓰되 2011판 이름을 괄호로 병기한다. 병기가 필요한 이유는 측정량 쪽에 있다 — ISO/IEC 25023:2016은 2011판 특성 이름 기준 이라 그 측정량을 인용하는 순간 "이식성 – 설치성" 표기와 마주친다. 문서에는 분류 기준 판과 측정량 기준 판을 각각 명시한다.

유지보수성은 이름도 구성도 그대로다 — 모듈성·재사용성·분석성·수정성·시험성 다섯이다.

신뢰성 — MTBF·MTTR 을 그대로 합격 기준으로 쓰지 않는다

신뢰성의 네 부특성은 서로 다른 질문이다.

MTBF·MTTR 은 모듈 25 레슨 3의 25023 측정량 표와 모듈 37 레슨 1의 ITSM 지표로 이미 다뤘다. 정의를 아는 것과 합격 기준으로 쓰는 것은 다르다. 한계가 넷이다.

① 분모가 정의 나름이다      "고장"이 장애 등급 몇 등급부터인가, 부분 저하는 세는가
   → MTTR 시작점이 '발생'인지 '접수'인지로 값이 배 이상 달라진다 (모듈 37 레슨 1)
② 관측 창이 짧으면 무의미     2주에 고장 0건이면 MTBF 는 '∞'가 아니라 '모른다'
③ 출시 전에는 잴 데이터가 없다  운영 로그에서 나오는 후행 지표다
④ 평균이 분포를 가린다       대부분 5분인데 한 건이 8시간이면 평균은 괜찮아 보인다
   → p95·최대값을 함께 본다

출시 전 시험에서는 MTBF 대신 관측 창 안에서 판정되는 대리 지표 를 쓴다.

가운데 행이 중요한 전환이다. 가용성 목표는 그대로는 못 재지만 "단일 구성요소가 죽었을 때 영향 시간"으로 바꾸면 잴 수 있다. 장기 지표를 단발 사건의 거동으로 번역하는 것이 신뢰성 분석의 핵심이다.

복구성 시험 사다리 — 장애 주입 없이도 오늘 시작할 수 있다

"카오스 엔지니어링 도구가 없어서 복구성 시험을 못 한다"는 말이 나오는데, 사다리의 아래 세 칸은 도구도 권한도 필요 없다.

5단  운영 환경 무작위 장애 주입        권한·문화·관측이 모두 갖춰진 뒤
4단  스테이징에서 의존 구성요소 격리   네트워크 차단·프로세스 강제 종료
3단  단일 프로세스 재시작 후 거동 확인  재기동 중 요청은 어떻게 되는가
2단  백업에서 복원 리허설              실제로 복원해 본다. 시간을 잰다
1단  복구 절차 문서 검토               절차서를 읽고 실행 가능성을 따진다

1단이 가장 저평가된 단계다. 복구 절차서를 리뷰 대상으로 놓고 레슨 2의 퍼스펙티브 기반 읽기를 — "야간에 혼자 당직 중인 주니어" 관점으로 — 적용하면 실행 불가능한 절차가 즉시 드러난다.

[복구 절차서에서 반복적으로 나오는 결함]
- 복원 대상 백업을 "최근 것"이라고만 쓰고 식별 방법이 없다
- 복구 중 들어오는 신규 요청을 어떻게 할지 없다
- 절차 중간에 "담당자에게 문의" 가 있다 (담당자가 장애 원인일 수 있다)
- 복구 완료를 무엇으로 판정하는지 없다 (레슨 1의 오라클 공백이다)
- 부분 복구 후 정합성 확인 단계와 롤백 실패 시 절차가 없다

2단은 가장 자주 건너뛰고 가장 자주 실패하는 단계 다. 백업이 돌고 있다는 것과 복원된다는 것은 다른 사실이다. 리허설 한 번이 백업이 읽히는가·절차가 맞는가·RPO/RTO 가 지켜지는가를 함께 확인한다.

RPO(복구 시점 목표)·RTO(복구 시간 목표)는 여섯 칸 틀에 바로 들어간다.

나쁨: "장애 시 신속히 복구한다"
좋음: "주문 DB 는(주체) 스토리지 전체 손실 상황에서(조건) 마지막 정상 커밋 기준
       15분 이내 데이터까지 복원되고(RPO), 복구 선언까지 60분 이내여야 한다(RTO).
       분기 1회 복원 리허설로 확인하고(측정 창·방법), 복구 완료 판정은
       대사 스크립트 전건 일치로 한다(오라클)."

유지보수성 — QA 가 요구사항으로 만들 수 있는 부분은 따로 있다

다섯 부특성 중 모듈성·재사용성은 설계 품질이라 QA가 요구 문장으로 쓰기 어렵다. 코드 복잡도·중복률을 들고 가면 "그건 개발 내부 지표"라는 반응이 돌아오고, 그 반응이 틀리지 않다. QA 가 정당하게 요구할 수 있는 것은 분석성과 시험성 이다 — 둘 다 "우리가 일하려면 필요한 것"이라 근거가 명확하다.

시험성 요구는 구체적으로 쓸수록 힘이 있다. "테스트하기 쉽게 만들어 주세요"는 요구가 아니다. 요구 문장으로 바로 옮길 수 있는 목록은 이렇다.

[상태 제어] 임의의 주문 상태를 API 한 번으로 만들 수 있다 (UI 10단계 없이)
           테스트 계정 데이터를 초기 상태로 되돌릴 수 있다
[시간 제어] 시험 환경에서 시각을 이동시키고, 배치를 수동 기동할 수 있다
[의존 대체] 외부 연동을 설정으로 목 서버로 바꿀 수 있다 (레슨 3 ③층의 전제)
           랜덤·ID 생성 시드를 고정할 수 있다
[관측]     요청 하나를 상관 ID 로 전 구간 추적하고, 비동기 처리의 완료를
           폴링 없이 확인할 수단이 있다

이 목록은 개발 착수 전에 올려야 한다. 만들어진 뒤에 요구하면 "그건 리팩터링"이 되고, 설계 시점에 올리면 "그건 요구사항"이 된다.

나쁨: "시스템은 유지보수가 용이해야 한다" / "테스트 자동화가 가능하도록 설계한다"
좋음: "주문 도메인은(주체) 통합 시험 환경에서(조건) 문서화된 관리 API 로
       10개 주문 상태 각각을 3초 이내에 생성할 수 있어야 하고(관측량·임계값),
       릴리즈마다 해당 API 의 상태 커버리지를 점검한다(측정 창·방법)."
 
나쁨: "충분한 로그를 남긴다"
좋음: "결제 실패 응답에는 모든 실패 경로에서 상관 ID 와 실패 분류 코드가
       포함되어야 하며, 실패 로그 표본 40건 중 95% 이상이 로그만으로
       원인 분류가 가능해야 한다(통합 시험 종료 시 판정)."

유연성(2011 이식성) — 설치·업그레이드·롤백은 왜 매번 빠지는가

적응성은 그나마 다뤄진다 — 모듈 30 레슨 3에서 확인한 대로 실무의 "호환성 테스트"가 표준의 적응성이다. 비는 것은 설치성과 대체성 이고 이유가 구조적이다.

① 시험 환경은 이미 설치된 상태에서 시작한다  → 설치 자체가 시험 대상이 안 된다
② 배포가 QA 범위 밖에 있다                → 배포 실패 시나리오에 케이스가 없다
③ 롤백은 "안 일어날 일" 로 취급된다         → 계획서에 한 줄 있고 시험된 적이 없다
④ 데이터 마이그레이션에 역방향이 없다
   올리는 스크립트는 있고 내리는 스크립트는 없다
   → 코드는 롤백되는데 데이터는 못 돌아간다. 이게 진짜 사고다

④가 롤백 사고의 대부분을 만든다. 모듈 4 레슨 6이 대규모 전환을 다룬다면 여기는 평시 릴리즈마다 반복되는 업그레이드·롤백 이다. 경로를 매트릭스로 만들면 한 줄이 한 항목이 된다.

대체성은 "같은 목적의 다른 제품·다른 버전으로 갈아탈 수 있는가"다. QA 관점의 시험 조건은 데이터 이관 가능성과 병행 운영 가능성 두 가지로 내려온다.

나쁨: "무중단 업그레이드를 지원한다"
좋음: "서비스는(주체) N-1·N-2 두 경로에서(조건) 업그레이드 중 5xx 응답률이
       0.1% 를 넘지 않아야 하며(관측량·임계값), 시작부터 완료까지 전 구간을
       부하 상태에서 측정한다(측정 창·방법). 롤백 시에는 롤백 완료 후
       업그레이드 중 생성된 데이터가 손실 없이 조회되어야 한다."

세 특성을 한 표에 모은다

레슨 3의 추적표에 세 축을 얹으면 이렇게 된다. 특성 칸에 두 판 이름을 함께 적는다.

실무에서 왜 필요한가

세 특성이 비어 있을 때의 손해는 릴리즈 당일에 나타난다. 롤백을 해 본 적이 없어서 되돌리다 새 장애가 나는 상황, 복구는 됐는데 그 사이 유실된 데이터를 아무도 판정하지 못하는 상황, 결함을 재현할 상태를 만들 방법이 UI 15단계뿐이라 하루가 가는 상황이 모두 여기서 온다.

계약·인증 쪽 이유도 있다. 공공·SI 제안서의 비기능 요구사항표에는 이 세 축이 반드시 들어가는데 문장이 대개 "안정적으로 운영되어야 한다" 수준이고, 검수 단계에서 증명을 요구받으면 그때부터 협상이 된다. 여섯 칸이 찬 문장을 제안 단계에 만들어 두면 검수 범위가 미리 정해진다.

시험성은 성격이 다르다. 다른 부특성이 제품의 품질이라면 시험성은 앞으로의 모든 시험의 비용 을 결정한다. 자동화 전환이 번번이 실패하는 팀은 도구 문제가 아니라 상태 제어·시간 제어 수단이 없는 경우가 대부분이다.

실습 과제

과제 1 — 비기능 요구 문장 여섯 칸 채우기 (25분)

요구사항 문서나 제안서에서 신뢰성·유지보수성·유연성(이식성) 관련 문장을 세 개 이상 찾아 그대로 옮긴다. 각 문장마다 아래 표를 그리고 빈 칸을 표시한다.

그다음 각 문장을 여섯 칸이 찬 형태로 다시 쓴다. 다시 쓰는 과정에서 "이 값을 누구에게 물어야 하는가"가 나오고, 그 질문 목록이 실제 산출물이다. 임계값을 QA가 혼자 정하면 안 된다.

과제 2 — 복구성 사다리 1·2단 수행 (30분)

복구 절차서를 구한다. 없으면 "없음"이 첫 번째 발견이다.

1. 1단 — 절차서를 "야간 당직 중인 입사 3개월 차" 관점으로 읽고 실행 불가능한 지점을 표시한다. 본문의 결함 유형을 체크리스트로 쓴다.
2. 2단 — 복원 리허설을 한 번 하거나, 불가능하면 마지막 리허설이 언제였는지 확인해 기록한다.
3. 복구 완료 판정 기준이 절차서에 있는지 본다. 없으면 레슨 1의 오라클 형식으로 한 문장 쓴다.

과제 3 — 업그레이드 경로 매트릭스 (25분)

본문의 여섯 경로 표를 담당 제품에 맞게 채운다. 각 행에 세 칸을 적는다.

"시험한 적 없음"이면서 "실패 시 데이터 손실"인 행이 다음 릴리즈 계획에 들어갈 항목이다. 특히 롤백 경로의 역방향 마이그레이션 스크립트 존재 여부 를 확인한다.

자가 체크리스트

• 비기능 요구 문장의 여섯 칸(주체·조건·관측량·임계값·측정 창·방법)을 채워 쓸 수 있다
• MTBF·MTTR 을 그대로 합격 기준으로 쓸 수 없는 이유를 네 가지로 설명할 수 있다
• 장기 신뢰성 목표를 시험 기간 안에 판정되는 대리 지표로 번역할 수 있다
• 복구성 시험 사다리 5단을 알고 도구 없이 1·2단을 오늘 시작할 수 있다
• RPO·RTO 를 요구 문장으로 쓰고 복구 완료 판정 기준을 함께 정의한다
• 유지보수성 중 QA 가 요구할 수 있는 부분(분석성·시험성)을 구분하고, 상태 제어·시간 제어·의존 대체·관측 네 갈래로 시험성 요구 목록을 낼 수 있다
• 업그레이드·롤백·중단된 업그레이드·재설치를 경로 매트릭스로 만든다
• 2023판 유연성과 2011판 이식성의 관계를 알고 문서에 판을 명시한다

흔한 실수

• "안정적이어야 한다"로 끝낸다. 판정 기준이 없는 문장은 검수 단계에서 분쟁이 되고 대개 QA가 진다.
• MTBF 목표를 출시 판정 기준에 넣는다. 운영 로그가 있어야 계산되는 후행 지표다. 고장·복구의 정의 없이 비교하면 같은 이름의 다른 지표가 된다(모듈 37 레슨 1).
• 복구성 시험을 장애 주입 도구가 필요한 일로 여긴다. 절차서 리뷰와 복원 리허설이 먼저고 결함도 거기서 더 나온다. 복원해 보지 않은 백업은 검증된 적 없는 가정이다.
• 유지보수성을 코드 복잡도 지표로만 요구한다. 개발 내부 지표라는 반론에 막힌다. 분석성·시험성으로 바꾸면 근거가 생긴다.
• 시험성을 개발 완료 후에 요구한다. 그 시점엔 리팩터링 요청이 되어 밀린다.
• 업그레이드를 N-1 경로만 시험한다. 건너뛴 버전과 중단된 업그레이드에서 결함이 난다.
• 롤백 절차를 문서에만 둔다. 역방향 마이그레이션 스크립트가 없으면 코드만 돌아가고 데이터는 못 돌아간다.

참고 자료

• ISO/IEC 25010:2023 — Product quality model — 신뢰성·유지보수성·유연성 부특성 정의의 정본. 부특성 구성은 원문 확인 권장
• ISO/IEC 25023:2016 — MTBF·가동률 등 측정량의 정의. 2011판 특성 이름 기준 이라는 점에 주의
• ISTQB Advanced Level Technical Test Analyst (CTAL-TTA) — 신뢰성·유지보수성·이식성 시험 영역
• 레슨 s2-m25-l03 — 25023 측정량과 GS인증(MTBF 가 놓이는 자리)
• 레슨 s2-m30-l02 — 25010 2판 개정(이식성 → 유연성, 성숙성 → 무결함성) / 레슨 s2-m37-l01 — MTTR 정의서 쓰기
• 레슨 s2-m04-l06 — 마이그레이션·전환 검증(대규모 전환. 여기는 평시 업그레이드·롤백)
• 레슨 s2-m58-l03 — 기능 적합성·상호운용성 분석(같은 5단계 절차의 앞부분)