0. 이 챕터의 목적
인프라 관리 SaaS(CMP·Kubernetes 대시보드·클라우드 관리 콘솔 등)의 테스트는 단순 CRUD에 머물지 않는다. 사용자 작업이 여러 단계의 추상화(UI → API → 백엔드 → 노드 → 게스트)를 통과해 실제 효과를 만들어내며, 단계마다 다른 종류의 결함이 발생할 수 있다.
본 챕터는 이러한 인프라 SaaS 테스트를 4 분류로 묶어 빈틈 없는 카테고리화를 가능하게 한다. 4 분류 외 테스트는 존재하지 않는다 — 단언이 아니라, 분류가 모든 테스트를 흡수하도록 설계된 결과다.
1. 4 분류 매트릭스
| 분류 | 명칭 | 검증 대상 | 결함 발견율 | 사전 정찰 의존도 |
|---|---|---|---|---|
| 4.1 | CRUD 기능 검증 | 입력→출력 매핑의 정확성 | 낮음 (회귀 검증 성격) | 낮음 |
| 4.2 | 스테이징 워크플로우 | 변경 누적·일괄 적용·되돌리기의 정합성 | 높음 | 중간 |
| 4.3 | 위험 시나리오·에러 처리 | 의도적 실패의 처리 품질 | 매우 높음 | 매우 높음 |
| 4.4 | 클러스터 일관성 | 다중 노드 동기화·페일오버 | 중간 | 높음 |
각 분류는 다른 결함 종을 검출한다. 4분류 중 한 분류만 돌리는 테스트는 다른 3 분류가 검출하는 결함을 놓친다.
2. 4.1 — CRUD 기능 검증
가장 기본이며 회귀 검증(Regression) 성격이 강한 영역.
2.1 검증 대상
- 자원 생성 API가 호출 시 백엔드의 실제 자원 인벤토리에 정확한 형식으로 항목을 추가하는가
- 자원 수정 API의 파라미터가 백엔드 CLI/SDK의 옵션과 의미상 일치하는가
- 자원 삭제 API가 종속 자원까지 깨끗이 정리하는가, 아니면 orphan을 남기는가
2.2 시나리오 예시
| 시나리오 | 검증 포인트 |
|---|---|
| 단일 컴퓨트 자원 생성 | UI 입력 → API 페이로드 → 노드의 자원 정의 파일 → 자원 실행 가능 여부 |
| 컴퓨트 자원 옵션 수정 | 메모리·CPU·NIC·디스크 등 변경 후 게스트 측 인식 |
| 자원 영구 삭제 | 디스크·스냅샷·자원명 메타·외부 백엔드 종속 자원의 정리 여부 |
| 스토리지 등록 | 신규 NFS/iSCSI/Object Storage 정의 시 마운트 가능성·노드 전파 |
| 사용자/그룹 생성 | 권한 매트릭스, 토큰 발급, 외부 IdP 연동 |
2.3 결함 패턴
이 분류에서 잡히는 결함은 비교적 직관적이다.
- 표시 vs 실제 불일치: UI에 "성공"으로 표시되지만 실제 자원이 만들어지지 않음 (캐시 결함)
- 부분 실패 silent: 5개 자원 중 3개만 만들어졌는데 UI는 "전체 성공" 표시
- 타입 변환 결함: UI 입력값(문자열)이 API 호출 시 잘못된 타입으로 변환
2.4 자동화 가능성
이 분류는 자동화에 가장 적합하다. 입력·출력이 명확하므로 다음 패턴으로 회귀 테스트 자동화 가능:
# 가상의 자동화 흐름
api_call --create resource --params $params
sleep 5
expected=$(generate_expected_state)
actual=$(api_call --get resource | normalize)
diff <(echo "$expected") <(echo "$actual") || flag_failure2
3
4
5
6
3. 4.2 — 스테이징 워크플로우
CMP 특유의 검증 영역. 결함 발견율이 가장 높다.
3.1 검증 대상
많은 인프라 관리 도구는 변경사항을 즉시 적용하지 않는다. 사용자가 여러 변경을 누적시킨 뒤 "적용" 버튼으로 일괄 반영하는 패턴이 일반적이다. 이 추상화는 백엔드에는 존재하지 않으므로 도구 자체가 만드는 상태 머신이며, 결함이 풍부하게 발생한다.
- 변경사항 누적 화면에 표시되는 항목과 실제 적용 시 들어가는 항목의 일치
- "되돌리기(Revert)" 시 부분 적용 상태의 처리
- 적용 도중 일부 항목 실패 시 전체 트랜잭션의 처리 (all-or-nothing? 부분 적용?)
- 다중 사용자가 동시에 같은 자원을 변경할 때 last-write-wins / 충돌 검출
3.2 시나리오 예시
| 시나리오 | 검증 포인트 |
|---|---|
| 5개 변경 누적 후 "적용" | 5개 모두 적용? 순서는? 트랜잭션 보장? |
| 누적 후 일부만 "되돌리기" | 부분 되돌리기 가능성, 의존 변경의 처리 |
| 적용 중 3번째 항목 실패 | 1·2번은 적용된 상태로 멈추는가, 1·2번도 롤백되는가 |
| 적용 직전 동료가 같은 자원 수정 | 충돌 검출, 경고 표시, 강제 적용 옵션 |
| 적용 후 즉시 "되돌리기" | 되돌리기 자체가 새 변경으로 누적되는가, 즉시 반영되는가 |
3.3 결함 패턴
이 분류는 상태 머신 결함이 풍부하다.
- 유령 변경: 누적 화면에 표시 안 되는 변경이 적용 시 들어감
- 부분 적용 후 invisible: 일부 실패 후 UI는 "성공" 표시, 백엔드는 부분 상태
- 충돌 silent: 동시 변경 시 한쪽 변경이 통보 없이 사라짐
- 되돌리기 결함: 되돌리기가 적용되지 않거나, 의존 자원의 상태가 어긋남
3.4 검증 비용
이 분류는 백엔드 직접 호출과 도구 UI를 동시 추적해야 한다. 양쪽 상태 머신의 정합성이 검증 대상이므로 단일 측면 관찰로는 결함을 잡을 수 없다.
검증 도구는 04 6 Layer 검증 사슬의 L1·L2·L3·L4 사이의 일치성을 동시에 보는 방식으로 구성된다.
4. 4.3 — 위험 시나리오·에러 처리
품질 테스트의 진짜 알맹이로 분류되는 영역. 결함 발견율 최고이며 사전 정찰 의존도도 최고.
4.1 검증 대상
이 분류는 "실패해야 할 작업"을 의도적으로 만들어 도구가 어떻게 실패하는지 관찰한다. 좋은 실패와 나쁜 실패는 구별된다.
- 좋은 실패: 명확한 에러 메시지 + 환경에 자취 없음 + 사용자가 즉시 다음 행동 결정 가능
- 나쁜 실패: orphan 자원 생성 / 무응답 / 거짓 성공 보고 / 부분 자취
4.2 시나리오 예시
| 카테고리 | 시나리오 |
|---|---|
| 하드웨어 제약 위반 | 활성 본드(Bond) 슬레이브 변경, 마지막 관리 인터페이스(mgmt NIC) 삭제 |
| 입력 검증 실패 | VLAN ID 0/4096 초과, 잘못된 IP 형식, 음수 메모리 |
| 종속성 누락 | OVS 미설치 상태에서 OVS 브릿지 생성, 패키지 미설치 상태에서 의존 기능 호출 |
| 자원명 충돌 | 이미 존재하는 이름으로 자원 생성, 동시 같은 이름 자원 생성 |
| 외부 의존 단절 | 백엔드 스토리지 다운, NTP 끊김, IdP 응답 없음, 노드 재기동 중 |
| 권한 부족 | 일반 사용자가 admin 권한 작업 시도, 토큰 만료 후 호출 |
| 동시성 한계 | 1000개 자원 동시 생성, API 레이트 리밋 초과 |
4.3 결함 패턴
이 분류에서 잡히는 결함이 가장 위험하다.
- Orphan 자원: API가 실패했지만 백엔드에는 자원의 일부가 남음 (다음 시도 시 충돌 트리거)
- 거짓 성공: API는 200을 돌려주지만 실제로는 작업이 진행되지 않음
- 무응답 hang: API 응답 없이 타임아웃까지 대기 (HTTP keep-alive 같은 인프라 결함 시그널)
- 에러 메시지 빈약: "Internal Server Error" 같은 정보 없는 메시지로 사용자 차단
4.4 사전 정찰 의존도
위험 시나리오 테스트는 자기가 만들지 않은 자원을 잘못 파괴할 위험이 가장 높다. 따라서 이 분류는 사전 환경 정찰이 가장 정확해야 한다.
테스트 시작 전:
- 환경의 모든 자원 인벤토리 (다른 사용자 자원 포함)
- 자원의 종속 그래프 (한 자원 삭제 시 영향받는 자원 목록)
- 백엔드 스토리지·외부 시스템 가용성 확인
- 롤백 절차 미리 준비
이 정찰 부재 시 테스트가 실수로 운영 환경을 손상시키는 사고로 변질된다.
4.5 격자와의 관계
위험 시나리오 테스트는 01 L×R 격자의 위험·금지·절대금지 셀에 의도적으로 진입한다. 테스트가 격자 코드를 위반하는 것이 아니라, 격자가 정의한 안전장치(사전 백업·다중 승인·롤백 자동화)를 갖춘 상태에서 진입하는 것이다.
5. 4.4 — 클러스터 일관성
다중 노드·다중 인스턴스를 관리하는 도구에 특화된 영역.
5.1 검증 대상
인프라 관리 SaaS는 5노드, 50노드, 500노드를 단일 화면으로 관리한다는 약속을 한다. 그 약속의 단일 화면 = 단일 진실이라는 가정을 검증하는 영역이다.
- 한 노드에서 일어난 변경이 다른 노드의 상태 표시에 어떻게 동기화되는가
- 노드 다운/복구 시 도구가 표시하는 자원 상태와 실제 백엔드 상태의 정합성
- HA 페일오버 발생 시 도구가 자동으로 자원 위치를 갱신하는가
- 클러스터 전반 통계(CPU 합계, 메모리 합계)가 실제와 일치하는가
5.2 시나리오 예시
| 시나리오 | 검증 포인트 |
|---|---|
| 노드 다운 시 자원 표시 | 다운된 노드의 자원이 도구에 어떻게 보이는가 |
| 노드 복구 시 자동 동기화 | 복구된 노드의 자원이 즉시 일치하는가, 수동 새로고침 필요한가 |
| 자원 마이그레이션 시 위치 추적 | 마이그레이션 중·후 자원의 노드 표시 정확성 |
| 다중 노드 동시 작업 | 5노드 동시 변경 시 도구의 처리 순서·일관성 |
| 클러스터 통계 일치 | 노드별 합계와 도구의 클러스터 합계 비교 |
5.3 결함 패턴
이 분류 결함은 단일 노드 검증으로 절대 잡히지 않는다.
- 노드별 표시 불일치: 같은 자원이 노드 A에서는 보이고 노드 B에서는 보이지 않음
- stale 캐시: 노드에서 변경된 상태가 도구에 30초~수분간 갱신 안 됨
- fence 후 좀비: 페일오버된 자원이 새 노드에도 표시되고 원래 노드에도 표시됨
- 통계 누락: 5개 노드 중 4개의 데이터만 합산됨
5.4 검증 의무
이 분류 테스트는 반드시 N개 노드 동시 비교를 전제로 한다. 단일 노드 측에서 한 모든 작업의 결과를 N개 노드에서 동시에 관찰해야 한다.
가상의 검증 패턴:
# 변경 적용 후 5노드 동시 상태 비교
for n in pve-nodeA pve-nodeB pve-nodeC pve-nodeD pve-nodeE; do
ssh "$n" "show-resource-state $resource_id" > "/tmp/state-$n.txt" &
done
wait
# 5개 출력의 md5 일치 확인
md5sum /tmp/state-*.txt | awk '{print $1}' | sort -u | wc -l
# 결과가 1이면 일치, 2 이상이면 불일치 → 결함 후보2
3
4
5
6
7
8
9
6. 4 분류 × 영역 매트릭스
테스트 영역(컴퓨트·스토리지·네트워크·백업·HA 등)이 4 분류와 직교한다. 모든 영역은 4 분류 각각에 해당 시나리오를 가진다.
| 영역 \ 분류 | 4.1 CRUD | 4.2 스테이징 | 4.3 위험 시나리오 | 4.4 클러스터 일관성 |
|---|---|---|---|---|
| 컴퓨트 | VM/CT CRUD | 일괄 생성·수정 | 활성 자원 잘못 종료 | 자원 위치 추적 정확성 |
| 스토리지 | storage CRUD | 일괄 등록 | 마운트 실패 처리 | shared 스토리지 노드별 표시 |
| 네트워크 | NIC/Bridge/VLAN/Bond CRUD | 적용/되돌리기 | 활성 슬레이브 변경 | 노드별 NIC 정보 동기화 |
| 백업 | 백업 잡 CRUD | 다중 스케줄 변경 | 백업 도중 노드 다운 | 백업 결과 클러스터 표시 |
| HA | HA 정책 CRUD | 정책 일괄 적용 | 페일오버 폭주 | 페일오버 후 자원 위치 |
| 권한 | 사용자/그룹 CRUD | 권한 일괄 변경 | 권한 회수 후 진행 작업 | 권한 변경 노드 전파 |
이 매트릭스는 자기 영역의 테스트 카탈로그를 만들 때 출발점이 된다. 빈 셀은 시나리오 누락을 의미한다.
7. 4 분류와 메타 자산의 결합
7.1 격자(01)와의 결합
분류별 일반 셀 위치:
- 4.1 CRUD: L1 × R1~R2 (안전~주의)
- 4.2 스테이징: L1~L4 × R1~R3 (주의~위험)
- 4.3 위험 시나리오: L3~L5 × R3~R4 (위험~절대금지) — 의도적 위험 셀 진입
- 4.4 클러스터 일관성: L4~L5 × R2~R3 (위험~금지)
7.2 검증 사슬(04)과의 결합
분류별 권장 검증 깊이:
| 분류 | 최소 Layer | 권장 Layer |
|---|---|---|
| 4.1 CRUD | L1·L2·L3 (UI·API·백엔드 직접) | + L4·L6 |
| 4.2 스테이징 | L1·L2·L3·L4 | + L5·L6 |
| 4.3 위험 시나리오 | L1~L6 전체 (특히 L6 — 사고 흔적 검증) | 양방향 (사전·사후) |
| 4.4 클러스터 일관성 | L5 필수 (5노드 동시 관찰) | + L1·L4 비교 |
8. 활용 절차
8.1 테스트 카탈로그 생성
- 자기 영역의 모든 자원 종을 행으로 나열
- 각 자원 × 4 분류로 셀 생성 (총 N × 4)
- 각 셀에 시나리오 1~5개 작성
- 시나리오마다 §7의 격자 셀 + 검증 Layer 매핑
8.2 우선순위 결정
자원이 많아 모든 셀을 채울 수 없을 때 우선순위:
- 4.3 위험 시나리오 (결함 발견율 최고, 사고 시 영향 최대)
- 4.2 스테이징 (CMP 특성상 결함 풍부)
- 4.4 클러스터 일관성 (단일 노드로 잡히지 않는 결함)
- 4.1 CRUD (마지막 — 자동화 가능)
이 순서는 자동화 가능성 역순이다. 자동화 가능한 영역은 후순위로 두고, 인간 관찰이 필요한 영역을 우선 직접 수행한다.
8.3 분류 외 테스트?
만약 4 분류 중 어디에도 해당하지 않는 테스트가 있다면, 다음 중 하나다.
- 분류의 정의가 너무 좁다 → 분류를 다시 본다
- 본 분류 체계가 자기 환경에 맞지 않는다 → 환경 특화 5번째 분류 추가
- 인프라 SaaS 테스트가 아닌 다른 종류 테스트 → 본 격자가 잘못 적용됨
대부분의 경우 첫 번째다. 4 분류는 인프라 SaaS의 본질적 추상화 4종을 다루므로 빠뜨림이 거의 없다.
9. 정리
본 분류의 핵심은:
- 4 분류는 직교한다 — 한 분류가 다른 분류를 흡수하지 않으며, 모든 인프라 SaaS 테스트는 4 분류로 분배된다
- 결함 종이 분류마다 다르다 — 분류 별 결함 패턴을 알면 어디에 인력 투입해야 하는지 결정할 수 있다
- 4.3 위험 시나리오가 가장 가치 높다 — 결함 발견율 + 사고 영향 모두 최대
이 분류가 정착되면 QA 리드는 "이번 분기 4.3에 인력의 40%를 투입하자"는 식의 의사결정을 정량적으로 할 수 있다. 분류 없는 환경에서는 같은 결정이 직관에 의존한다.
다음 챕터: 03 챕터 표준 구조 — 정찰·테스트 결과를 매뉴얼로 옮길 때 사용하는 6섹션 표준 구조.