08. 위험 매트릭스 및 격리 전략 — STN 직전의 붉은 선

0. 이 챕터의 성격

본 챕터는 새로운 정찰 데이터를 수집하지 않는다. 앞선 01~07장에서 이미 발견되고 박제된 리스크를 재배치·재분류·우선순위화하여, STN 직전의 단일 의사결정 문서로 통합한다.

챕터 00 §3에서 도입된 격자 매트릭스 — Blast Radius (L1~L5) × Reversibility (R1~R4) — 가 본 챕터의 중심 도구가 된다. 1~7장에서 개별적으로 "격자 LN×RN"으로 평가된 항목들을 한 평면에 투영하여 다음 질문에 답한다.

STN 전에 반드시 해결되어야 하는 것은 무엇인가?
STN 중에도 절대 건드리지 말아야 할 것은 무엇인가?
5명 테스터가 물리적 분리 없이 공존하는 환경에서 자원 격리는 어떻게 구현하는가?
우리 팀만의 책임으로 해결 가능한 것과 타 팀/운영팀 협의가 필요한 것을 어떻게 구분하는가?

0.1 본 챕터의 독자 시나리오

팀 리더가 STN 시작 회의에서 팀원 5명에게 "건드리지 말 것"을 공표할 때 참조
테스터 각자가 테스트 액션 전에 격자 평가를 자가 진단할 때 참조
장애 발생 후 복구 회의에서 **"이 사건이 예견된 리스크였는가"**를 판정할 때 참조

0.2 본 챕터의 한계

본 챕터는 2026-04-25 현재 스냅샷에 기반한다. 환경이 변하면 이 매트릭스도 갱신되어야 한다. STN 중 새 리스크가 발견되면 즉시 본 챕터의 해당 섹션에 추가 기록하고, 그 결정을 WorkLog로 별도 문서화.

1. 격자 매트릭스의 복습

1.1 Blast Radius — 영향 범위

격자	의미	예시
L1	자기 소유 자원 범위	자기 VM 내부 파일 편집, 자기 iSCSI target 조작
L2	단일 노드 내 여러 자원	노드 로컬 스토리지 재배치, 노드 하나의 VM 다수 정지
L3	단일 노드 전체 또는 타 테스터 자원	노드 reboot, `/etc/pve/storage.cfg` 편집
L4	클러스터 다수 노드 또는 모든 사용자 영향	`storage.cfg`에서 shared storage 제거, Corosync 설정 변경
L5	외부 시스템 또는 비가역 영향	TrueNAS zVol 삭제, `pvecm delnode`, BIOS 업데이트

1.2 Reversibility — 복구 가능성

격자	의미	예시
R1	완전 가역 (즉시 원복 가능)	서비스 재시작, 네트워크 인터페이스 up/down
R2	가역이지만 일정 작업 필요	VM config 수정 → 이전 값으로 덮어쓰기
R3	부분 가역 또는 데이터 일부 손실	snapshot rollback, LVM 볼륨 크기 축소
R4	비가역	디스크 삭제, `qm template` 변환, `pvecm delnode` 완료

1.3 격자 조합의 의미

L과 R의 곱이 의사결정 난이도를 결정한다.

L1×R1: 단독 판단 실행 가능. 즉시 실행 또는 거부.
L2×R1~R2: 단독 실행 가능하나 사전 백업 원칙.
L3 이상 또는 R3 이상: 사용자 합의 필수. 합의 없이 실행 금지.
L4 또는 R4: 두 번 이상의 확인 절차 + 롤백 계획 사전 수립.
L5×R4: 원칙적 금지. 운영팀 공식 승인 후에만 수행.

본 매트릭스는 본 챕터 §3에서 리스크 각 항목에 다시 적용된다.

2. 1~7장 리스크 집약 — 계층별 재배치

2.1 물리·하드웨어 계층 리스크

#	항목	출처	L×R	우선순위
2.1.1	nd02 storage 평면 100 Mbps 링크 (다른 4노드 2.5 Gbps)	챕터 05 §2.3	L3×R2 (운영팀)	P0
2.1.2	5노드 NVMe 동일 로트 공급 (시리얼 끝 25C 공통)	챕터 03 §2.1.1	L5×R4 (운영팀)	P2
2.1.3	NIC bonding 부재 — 평면별 단일 NIC	챕터 05 §2.15	L4×R2 (운영팀)	P2
2.1.4	nd03 PCI 슬롯 이름 차이 (enp9s0 vs enp10s0)	챕터 05 §2.3	영향 없음	P3

집약 판단:

STN 전 반드시 해결: 2.1.1 (nd02 링크 속도). 방치 시 iSCSI/NFS 타임아웃이 nd02에서만 발생. 테스트 결과 왜곡의 단일 최대 원인.
STN 중 수용: 2.1.2, 2.1.3. 동시 장애 가능성은 알고 있되, 단기 STN 기간에는 확률 낮음. 장기 운영 대비 운영팀 인계.
무시 가능: 2.1.4. 기능 영향 없음.

2.2 클러스터·네트워크 계층 리스크

#	항목	출처	L×R	우선순위
2.2.1	Corosync ring1 + storage 평면 공유	챕터 05 §2.11	L4×R1	P2
2.2.2	CMP 요청 nd01 집중 — HA 효과 무실	챕터 05 §2.7	L4×R1	P0
2.2.3	NFS 평면 혼용 (mgmt 평면으로 흐르는 NFS 트래픽)	챕터 03 §2.7.3, 05 §2.10	L3×R2	P1
2.2.4	NFS alias chaos — testerC 데이터가 testerB 이름 경로	챕터 03 §2.7.1	L2×R4	P0
2.2.5	사내 DNS 부재, Google DNS 단일 의존	챕터 05 §2.13	L4×R1 (운영팀)	P2
2.2.6	PVE firewall 5노드 disabled	챕터 05 §2.14	L3×R1	P2
2.2.7	TrueNAS nd06 corosync 평면 IP FAILED	챕터 05 §2.9	L1×R1	P3

집약 판단:

STN 전 반드시 해결:
- 2.2.2 (CMP nd01 집중): STN의 전제 자체(5노드 분산 검증)가 무너진다. 테스트 설계가 쓸모없어짐. 최소한 라우팅 설계 의도를 확인하여 "의도된 집중"인지 "미구현된 분산"인지 구분해야 한다.
- 2.2.4 (NFS alias chaos): 누군가 정리 명령을 실행하는 순간 엉뚱한 사람의 데이터가 사라진다. 먼저 매핑을 전원 공유 + cleanup 전 테스트 중 NFS 삭제 전면 금지 합의.
STN 중 주의: 2.2.3 (NFS 평면 혼용)의 추가 발생 방지. 새 NFS 등록 시 반드시 storage 평면 IP 사용.
무시 가능: 2.2.7 (TrueNAS corosync IP FAILED — 기능 영향 없음).

2.3 스토리지 계층 리스크

#	항목	출처	L×R	우선순위
2.3.1	iSCSI 유령 LUN 45만 건/일 에러	챕터 03 §2.1.2, 07 §2.4	L2×R1 (본인) + L3×R2 (testerA)	P0
2.3.2	pve-nd06-nfs SPOF — 거의 모든 VM 디스크 수렴	챕터 00 §1.3, 03 §2.6	L5×R2 (TrueNAS 다운 시)	P1
2.3.3	VM 100015 node03-dir 마이그레이션 제약	챕터 03 §2.6, 06 §2.9	L3×R2	P2
2.3.4	VM 809 orphaned disk	챕터 03 §2.6, 06 §2.10	L1×R2	P2
2.3.5	VM 802 마이그레이션 중단 8일 방치	챕터 06 §2.8, 07 §2.6	L2×R2	P1
2.3.6	nd07 NFS 마운트 mgmt 평면 경유	챕터 03 §2.7.4	L3×R2	P2
2.3.7	빈 VG `vg`, `lvm-test-testerC`	챕터 03 §2.5.4	L2×R1	P3
2.3.8	LVM LV 이름에 `.qcow2` 확장자	챕터 03 §2.5.3	L3×R3	P3
2.3.9	ARC c_max 1 GiB 튜닝 주체·근거 확인	챕터 03 §2.4.3, 04 보류	L1×R1	P2

집약 판단:

STN 전 반드시 해결:
- 2.3.1 (iSCSI 유령 LUN): 자기 영역(testerSelf SID 7)은 워크로그로 정리 완료. testerA 영역은 본인 동의 필요 (워크로그 §5.2 문의 템플릿 활용). STN 전 완료 시 ERROR 레이트 99% 감소(챕터 07 §2.4.3) — 실제 장애 알림이 의미를 가지게 된다.
STN 중 핵심 주의:
- 2.3.2 (SPOF): TrueNAS nd06 장애 시 거의 모든 VM 영향. 단일 장애 발생 시의 복구 순서 문서화 + 백업 최신성 확인.
STN 중 수행 가능: 2.3.4 (VM 809 디스크 정리), 2.3.5 (VM 802 프로세스 종료) — L2 이하이므로 소유자 확인 후 실행.

2.4 가상 자원 계층 리스크

#	항목	출처	L×R	우선순위
2.4.1	VM 112 3일 61.6% CPU, 작성자 미상, mgmt 평면	챕터 02 §2.5, 05 §2.5, 06 §2.7, 07 §2.9	L2×R3	P0
2.4.2	14개 VM mgmt 평면 연결 (test VM 9 + 서비스 VM 5)	챕터 05 §2.5.2, 06 §2.5	L2×R1	P1
2.4.3	VM 100004 NIC1 fwbr 미래핑	챕터 05 §2.5, 06 §2.5.2	L2×R1	P2
2.4.4	VM description/comment HTML 렌더링 (XSS 가능성)	챕터 06 §2.3.1, §2.16	L4×R2	P2
2.4.5	ciuser 회사 정보 노출 14건 VM	챕터 06 §2.13	L3×R2	P2
2.4.6	같은 이름 VM 2쌍 (Prom01/PromAgent01)	챕터 06 §2.2	L2×R2	P2
2.4.7	VM 702 snapshot 3개 방치 + QGA 미응답	챕터 06 §2.12, 07 §2.3.1	L2×R3	P3
2.4.8	VM 799/800 HA 리밸런싱 주체 미상	챕터 07 §2.8.2	L2×R1	P3
2.4.9	VM 116 HA 마이그레이션 lock timeout	챕터 07 §2.8.1	L3×R1	P2

집약 판단:

STN 전 반드시 해결:
- 2.4.1 (VM 112): 단독 삭제 금지 원칙(챕터 06 §7.1) 유지. 작성자 추적 실패 상태(챕터 07 §2.9.3) → Slack 전체 질의 발송이 유일한 현실 경로. 질의 24시간 응답 대기.
STN 중 격리 원칙:
- 2.4.4 (XSS): STN 중 추가로 HTML description 작성 금지. 기존 것은 관찰만.
STN 후 정리: 2.4.6, 2.4.7, 2.4.8.

2.5 로그·운영 계층 리스크

#	항목	출처	L×R	우선순위
2.5.1	nd02·nd03 49일 무재부팅 — 커널 미패치	챕터 02 §2.8	L4×R1 (운영팀)	P1
2.5.2	admin01@pve 공용 계정 다수 사용	챕터 07 §2.5	L3×R2	P2
2.5.3	test_yhkim@pve 새 사용자	챕터 07 §2.5	L1×R1	P2
2.5.4	nd04 journal 2.9GiB (타 노드 10배)	챕터 07 §2.1	L1×R1	P2
2.5.5	journald SystemMaxUse 미설정	챕터 07 §2.1.2	L2×R1 (운영팀)	P3
2.5.6	chrony 5노드 3개 외부 NTP 산개	챕터 02 §2.7	L3×R1 (운영팀)	P2

집약 판단:

STN 전 확인:
- 2.5.1: 운영팀에 STN 후 일괄 패치 계획 확인. STN 중에는 패치 금지(환경 변경 최소화).
- 2.5.3: 새 사용자 정체 확인. 팀원 또는 보조 계정.
STN 중 수용: 2.5.2, 2.5.4, 2.5.5, 2.5.6 모두 즉시 영향 없음. 기록·관찰.

2.6 핸드북 보조 시리즈로 이미 관리되는 항목

WorkLog 2026-04-24 (iscsi-multi-storage-provisioning)에서 이미 관리 중인 항목은 본 챕터에서 중복 관리하지 않는다. 연결 링크만 박는다.

testerSelf 영역 4종 iSCSI 스토리지 프로비저닝: WorkLog §3
testerA 영역 고아 iSCSI 리소스: WorkLog §5
Open-iSCSI 3계층 책장 관리: WorkLog §1, §4

본 챕터의 2.3.1이 이 워크로그로 연결된다. 이중 관리 방지.

3. STN 붉은 선 — "절대 하지 말 것" 목록

본 절은 STN 기간 중 5명 테스터 전원이 반드시 지켜야 할 금지사항을 단일 페이지로 정리한다. 팀 회의에서 공표하기 위한 형태.

3.1 L5 또는 R4 영역 — 전면 금지

markdown

┌─ STN 기간 절대 금지 (L5 또는 R4) ─────────────────────────────────┐
│                                                                     │
│  🚫 TrueNAS 측 자원 직접 변경 (zVol·Target·Extent 삭제/수정)        │
│  🚫 `pvecm delnode` 또는 클러스터 탈퇴 명령                         │
│  🚫 `/etc/corosync/corosync.conf` 직접 편집                         │
│  🚫 shared storage 삭제 (`pve-nd06-nfs`, `prom-lvm`, `vg-prom`)     │
│  🚫 `qm template` 변환 (비가역)                                     │
│  🚫 다른 테스터의 VM·스토리지 직접 삭제                             │
│  🚫 BIOS 업데이트, 커널 설치·업그레이드                             │
│  🚫 PVE 주요 패키지 `apt upgrade` (단일 노드)                       │
│  🚫 iscsiadm `-o delete` 타 테스터 target                           │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

3.2 L3~L4 영역 — 합의 필수

markdown

┌─ 사전 합의 필수 (테스트팀 5명 또는 개발팀) ──────────────────────┐
│                                                                   │
│  ⚠ 노드 reboot (본인 노드 제외)                                   │
│  ⚠ `storage.cfg` 편집 (pvesm set/add/remove)                      │
│  ⚠ HA config 변경 (`ha-manager` state/node 변경)                  │
│  ⚠ VM 마이그레이션 (특히 local-zfs VM)                            │
│  ⚠ 네트워크 평면 이전 (NFS mgmt→storage 등)                       │
│  ⚠ PVE firewall 활성화                                            │
│  ⚠ VM 처분 (test 포함이라도 작성자 불명이면 합의)                 │
│                                                                   │
└───────────────────────────────────────────────────────────────────┘

3.3 L1~L2 영역 — 단독 수행 가능 (사전 백업 권고)

markdown

┌─ 단독 수행 가능 ──────────────────────────────────────────────────┐
│                                                                   │
│  ✓ 본인 VM 내부 파일·설정 편집                                    │
│  ✓ 본인 VM 디스크 추가·제거                                        │
│  ✓ 본인 iSCSI target 등록·삭제                                     │
│  ✓ 본인 VM snapshot 생성·삭제                                      │
│  ✓ 본인 VM 기동·정지                                               │
│  ✓ `qm config`, `pvesm list` 등 조회 명령 전체                     │
│  ✓ 로그 조회 (journalctl, last, dmesg)                             │
│                                                                   │
│  원칙: **본인 소유 자원**은 자유. **조회**는 전면 자유.            │
│                                                                   │
└───────────────────────────────────────────────────────────────────┘

3.4 테스트 VM 생성 시 권장 규약

새 VM 생성 시 본 챕터 집약을 반영한 권장 규약:

이름 규칙: {VMID}-test-{testerID}-{용도} 형식. test 포함 필수 (처분 기준 — 챕터 06 §0.1)
네트워크 기본값: bridge=vmbr1 (vm 평면). mgmt 평면 연결 금지 (§2.4.2)
스토리지 기본값: pve-nd06-nfs 또는 본인 iSCSI target. SPOF 인지 후 선택 (§2.3.2)
ciuser: 회사명 파생값 금지. {testerID} 또는 용도별 이름 (§2.4.5)
description: HTML 태그 사용 금지 (§2.4.4). 평문만
tags: 최소한 test-YYYY-MM-DD 생성일 또는 {testerID} 포함
HA 등록: 실제 HA 검증용 아니면 등록 금지 (chaos 방지)

4. 자원 격리 전략 — 5명 테스터 공존 환경에서

4.1 물리적 분리 부재 — 본 환경의 전제

챕터 00 §2에서 정리된 대로 본 환경은 5명 테스터가 단일 서버랙에서 공존. 각 테스터에 전용 노드를 할당하지 않고 자유 배치. 이 상태에서 격리는 물리·네트워크 수준이 아닌, 논리·규약 수준으로만 구현된다.

관찰된 실제 분산 패턴(수집 기준):

노드	주 사용자 추정	자원 편중
nd01	다수 공유 (PBS + docker-registry)	mgmt 집중 (CMP 요청 집중)
nd02	미상	VM 112 (3일 고부하, 미상 작성자)
nd03	testerA 편중	100010/100015/100021 등 Prom 스택, node03-dir
nd04	admin01/CI/CD	VM 106 (CI/CD 서비스)
nd05	testerSelf 집중	cmptest-* 스토리지, 17 VM 중 주력

관찰: 각 테스터가 특정 노드에 편향되어 있으나 배타 독점은 아님. testerSelf(작성자)는 nd05 편향이되 다른 노드에도 자원 존재. 챕터 05 §2.10 iSCSI 세션 분포도 이 패턴 반영.

4.2 격리 원칙 4단계

1단계 — 이름 격리 (가장 기본):

자원명에 {testerID} 포함. 예: nfs-test-testerA, lvm-test-testerB, iscsi-test-testerC.
규약 미준수 자원의 소유자 추적 불가 → 처분 보류 대상.

2단계 — VMID 대역 분할:

팀 합의로 각 테스터가 특정 VMID 대역 사용 (현재 미합의)
예시 제안: testerA (100000~109999), testerB (110000~119999), ...
단 기존 VM 다수가 100 대역 또는 9000 대역 혼용이라 소급 적용 불가. 신규 생성부터 적용 권고.

3단계 — 노드 편향 합의:

각 테스터의 주 활동 노드를 명시적 합의. 다른 노드 사용 시 예고.
본 챕터 §4.1의 관찰된 패턴을 출발점으로 사용.

4단계 — 삭제 시 2인 승인:

P0 자원 삭제는 작성자 외 1명의 확인 필수
삭제 전 WorkLog 작성 의무화
본 원칙은 개발팀 협의 영역 (테스트팀 단독 결정 불가)

4.3 CMP 요청 라우팅 격리 (STN 중 임시 대안)

챕터 05 §2.7에서 확인된 CMP 요청 nd01 집중이 STN 전까지 해결 불가 시, 각 테스터가 의도적으로 다른 노드의 CMP로 요청을 던져 분산 동작 검증:

테스터	테스트 대상 CMP 엔드포인트
testerA	`http://10.99.10.13:18080` (nd03)
testerB	`http://10.99.10.12:18080` (nd02)
testerC	`http://10.99.10.14:18080` (nd04)
testerD	`http://10.99.10.15:18080` (nd05)
testerSelf	`http://10.99.10.11:18080` (nd01)

5노드 분산이 실제로 작동하는지 수동 분산을 통해 검증 가능. 단 이는 의도된 분산이 설계되어 있다는 전제 하에서만 의미. 그렇지 않다면 각 노드가 독립 작동하여 5명이 서로 다른 상태의 CMP를 보게 됨 — STN 결과 해석이 복잡해진다.

개발팀 협의 전까지는 이 대안을 각자 다른 노드로 접속은 하되, 상태 일관성을 크로스 체크하는 방식으로 운용 권고.

5. STN 직전 체크리스트 요약

상세 체크리스트는 챕터 09에서 다룬다. 본 절은 본 매트릭스의 관점에서 반드시 검증되어야 할 항목만 요약.

5.1 P0 항목 — STN 전 100% 해소

#	항목	해소 방법	책임	예상 소요
P0-A	nd02 storage 평면 100 Mbps	운영팀 케이블 교체 또는 포트 변경	운영팀	1시간
P0-B	CMP nd01 집중 — 설계 의도 확인	개발팀 인터뷰	개발팀	30분
P0-C	NFS alias chaos 매핑 공유	챕터 03 §2.7.1 매트릭스를 팀 전원과 공유	본 작성자	15분
P0-D	iSCSI 유령 LUN testerA 영역 정리	WorkLog §5 문의 템플릿 발송	본 작성자→testerA	1일
P0-E	VM 112 작성자 확인	Slack 전체 질의 (챕터 06 §7.3 5번)	본 작성자	1일

5.2 P1 항목 — STN 전 확인 또는 기록

#	항목	액션	책임
P1-A	14개 VM mgmt 평면 연결	매트릭스 공유 (이전 선택 아님, 관찰만)	본 작성자
P1-B	VM 802 프로세스 종료 (admin01 동의 후)	admin01 확인 후 `qm stop 802 --force`	본 작성자
P1-C	pve-nd06-nfs SPOF 복구 절차 문서화	TrueNAS 다운 시 순서 정리	운영팀
P1-D	nd02·nd03 커널 미패치 위험 인지	STN 후 일괄 패치 일정 수립	운영팀

5.3 STN 시작 직전 5분 체크

bash

# === STN 시작 직전 헬스 체크 ===
NODES="pve-nd01 pve-nd02 pve-nd03 pve-nd04 pve-nd05"

# [1] 클러스터 정족수
ssh pve-nd01 "pvecm status | grep -E 'Quorate|Nodes|Activity'"

# [2] 5노드 링크 속도 (nd02가 2.5G로 복구됐는지)
for n in $NODES; do
  ssh "$n" "ethtool enp10s0 2>/dev/null | grep Speed || \
            ethtool enp9s0 2>/dev/null | grep Speed"
done

# [3] iSCSI 에러 레이트 (정비 후 급감 확인)
for n in $NODES; do
  cnt=$(ssh "$n" "journalctl --since '10 minutes ago' -p err --no-pager | wc -l")
  echo "[$n] last 10min ERROR: $cnt"
done

# [4] 모든 VM 상태 확인
ssh pve-nd01 "pvesh get /cluster/resources --type vm --output-format json 2>&1 | jq -r '.[] | select(.status==\"running\") | .vmid' | wc -l"

# [5] HA manager 상태
ssh pve-nd01 "ha-manager status | head -10"

모든 출력이 정상 기준을 만족하면 STN 진입 GO. 하나라도 이상 시 각 챕터의 §3 참조하여 진단.

6. 마스킹 정책 v3으로의 전환 권고

6.1 현 v2 정책의 한계

핸드북 01~07장에서 적용된 마스킹 정책 v2의 효과는:

✅ 명령 블록 실행 가능성 보존 (실제 IP 유지)
✅ 출력 인용 블록 마스킹 (물리 IP 대역 → 본 핸드북 전용 대역, {테스터실명} → testerA~testerE)
✅ 실명·회사명 제거 (한글 실명 → testerX-real, 회사명 파생어 → corp)

그러나 다음 한계가 드러났다:

corp → corp.local 마스킹이 회사 식별성을 완전히 제거하지 못함. corp는 특정 단어에서 파생된 느낌을 남김.
챕터 06 §2.13에서 ciuser: corp로 마스킹한 후 원본 이해에 주석 필요 — 독자가 마스킹 이유를 재구성해야 함.
외부 유출 극단 시나리오 방어가 미흡.

6.2 v3 정책 제안 — 일반화 강화

v3에서 치환할 표현:

v2	v3	근거
`corp` (ciuser 등)	`internal-user`	일반 테스트 환경 명명
`corp.local` (도메인)	`internal.example`	RFC 6761 예약 도메인 기반
`testerA`~`testerE`, `testerSelf`	(유지)	이미 일반적
외부 NTP `ntp-kr-1.example.net` 등	(유지)	이미 example 도메인
10.99.X.Y 대역	(유지)	일반 사내 대역 느낌

변경 영향 범위: 핸드북 챕터 00~07 + 마스킹 정책 문서. 소급 변경이 아닌 v3 시점부터 적용 권고. 기존 문서는 v2 기준으로 보존하고, v3는 신규 챕터(09, 10) 및 WorkLog 시리즈에 적용.

6.3 v3 전환 실행 방안

v3 정책 문서 작성: masking-policy-v3.md. v2와의 차이점 명시.
챕터 09 이후 신규 문서는 v3 적용.
WorkLog 시리즈는 v3 소급 적용 가능: 워크로그는 외부 공유 가능성이 더 높으므로 강한 마스킹 유효.
핸드북 00 §5 "마스킹 정책 변경 이력"에 v2→v3 전환 기록.

본 전환 자체는 챕터 09 작성 전 또는 챕터 09 작성 중 처리. 본 챕터 08에서는 방향성만 제시하고 실 전환은 별도 작업으로 분리.

7. 본 챕터에서 새로 식별된 리스크

본 챕터는 주로 기존 발견의 재배치이나, 통합 관점에서 새로 드러난 항목:

#	항목	출처 교차	우선순위
7.1	5명 테스터 VMID 대역 분할 합의 부재 — 소급 불가	§4.2	P2
7.2	CMP 요청 수동 분산 대안의 상태 일관성 리스크	§4.3	P1
7.3	STN 전·후·중 리스크 관리 책임자 미지정	§0.1	P2
7.4	마스킹 정책 v2→v3 전환 필요성	§6	P2

7.1 격리 전략의 조직 차원 함의

챕터 08 §4의 자원 격리 전략은 기술이 아닌 조직 합의 영역이다. 5명 테스터의 공존 규약이 미성숙 상태에서 핸드북은:

기술적 격리 부재를 메꿀 수 없다 (환경은 이미 구축됨)
논리적 격리 규약을 제안할 수 있다 (본 챕터 §4.2)
실행은 팀 리더 또는 PL의 의사결정에 의존

따라서 본 챕터는 팀 리더에게 현 상태를 보고하고 규약 도입을 제안하는 문서로도 기능한다. 테스터 단독 권한으로 강제할 수 있는 것이 아님.

8. 다음 챕터로의 인계

본 챕터가 통합을 마쳤으므로, 챕터 09·10은 실행 가능한 산출물에 집중한다.

본 챕터 결과	챕터 09 (Pre-test 체크리스트) 처리
§5.1 P0 항목 5건	체크리스트 최상단
§5.3 STN 직전 5분 체크	실행 가능 스크립트로 정제
§3 붉은 선 목록	팀 회의 공표 슬라이드

본 챕터 결과	챕터 10 (정찰 산출물 템플릿) 처리
§4.2 4단계 격리 원칙	자원 생성 요청서 템플릿
§6 v3 마스킹 정책	신규 WorkLog 작성 가이드

부록 A. 격자 매트릭스 단일 페이지

본 핸드북 전체에서 참조할 격자 평가 요약.

markdown

┌──────────────────────────────────────────────────────────────────────┐
│                          Reversibility (R)                           │
│                    R1      R2      R3      R4                        │
│ Blast  L1  │  즉시  │  백업  │  합의  │  금지  │                       │
│ Radius L2  │  즉시  │  백업  │  합의  │  금지  │                       │
│ (L)    L3  │  백업  │  합의  │  합의  │  금지  │                       │
│        L4  │  합의  │  합의  │  승인  │  금지  │                       │
│        L5  │  승인  │  금지  │  금지  │  금지  │                       │
└──────────────────────────────────────────────────────────────────────┘

즉시 = 단독 판단 실행 가능
백업 = 사전 백업 + 단독 실행
합의 = 관련자 사전 합의
승인 = 운영팀 공식 승인
금지 = 원칙적 금지, 특별 승인만

부록 B. 참고 자료

주제	URL
Blast Radius 개념 (일반 시스템 엔지니어링)	https://sre.google/workbook/eliminating-toil/
위험 관리 격자 (RACI, 의사결정)	https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
Proxmox VE Cluster Admin	https://pve.proxmox.com/pve-docs/chapter-pvecm.html
RFC 6761 Example Domains	https://tools.ietf.org/html/rfc6761

다음 챕터: 09-pretest-checklist.md — 본 챕터의 §5 "STN 직전 5분 체크"를 실행 가능한 스크립트 + 수동 확인 항목 체크리스트 형태로 정제한다. 본 챕터의 §3 붉은 선 목록은 팀 회의 공표용 1페이지로 추출.

data-snapshots

0. 이 챕터의 성격 ​

0.1 본 챕터의 독자 시나리오 ​

0.2 본 챕터의 한계 ​

1. 격자 매트릭스의 복습 ​

1.1 Blast Radius — 영향 범위 ​

1.2 Reversibility — 복구 가능성 ​

1.3 격자 조합의 의미 ​

2. 1~7장 리스크 집약 — 계층별 재배치 ​

2.1 물리·하드웨어 계층 리스크 ​

2.2 클러스터·네트워크 계층 리스크 ​

2.3 스토리지 계층 리스크 ​

2.4 가상 자원 계층 리스크 ​

2.5 로그·운영 계층 리스크 ​

2.6 핸드북 보조 시리즈로 이미 관리되는 항목 ​

3. STN 붉은 선 — "절대 하지 말 것" 목록 ​

3.1 L5 또는 R4 영역 — 전면 금지 ​

3.2 L3~L4 영역 — 합의 필수 ​

3.3 L1~L2 영역 — 단독 수행 가능 (사전 백업 권고) ​

3.4 테스트 VM 생성 시 권장 규약 ​

4. 자원 격리 전략 — 5명 테스터 공존 환경에서 ​

4.1 물리적 분리 부재 — 본 환경의 전제 ​

4.2 격리 원칙 4단계 ​

4.3 CMP 요청 라우팅 격리 (STN 중 임시 대안) ​

5. STN 직전 체크리스트 요약 ​

5.1 P0 항목 — STN 전 100% 해소 ​

5.2 P1 항목 — STN 전 확인 또는 기록 ​

5.3 STN 시작 직전 5분 체크 ​

6. 마스킹 정책 v3으로의 전환 권고 ​

6.1 현 v2 정책의 한계 ​

6.2 v3 정책 제안 — 일반화 강화 ​

6.3 v3 전환 실행 방안 ​

7. 본 챕터에서 새로 식별된 리스크 ​

7.1 격리 전략의 조직 차원 함의 ​

8. 다음 챕터로의 인계 ​

부록 A. 격자 매트릭스 단일 페이지 ​

부록 B. 참고 자료 ​

0. 이 챕터의 성격

0.1 본 챕터의 독자 시나리오

0.2 본 챕터의 한계

1. 격자 매트릭스의 복습

1.1 Blast Radius — 영향 범위

1.2 Reversibility — 복구 가능성

1.3 격자 조합의 의미

2. 1~7장 리스크 집약 — 계층별 재배치

2.1 물리·하드웨어 계층 리스크

2.2 클러스터·네트워크 계층 리스크

2.3 스토리지 계층 리스크

2.4 가상 자원 계층 리스크

2.5 로그·운영 계층 리스크

2.6 핸드북 보조 시리즈로 이미 관리되는 항목

3. STN 붉은 선 — "절대 하지 말 것" 목록

3.1 L5 또는 R4 영역 — 전면 금지

3.2 L3~L4 영역 — 합의 필수

3.3 L1~L2 영역 — 단독 수행 가능 (사전 백업 권고)

3.4 테스트 VM 생성 시 권장 규약

4. 자원 격리 전략 — 5명 테스터 공존 환경에서

4.1 물리적 분리 부재 — 본 환경의 전제

4.2 격리 원칙 4단계

4.3 CMP 요청 라우팅 격리 (STN 중 임시 대안)

5. STN 직전 체크리스트 요약

5.1 P0 항목 — STN 전 100% 해소

5.2 P1 항목 — STN 전 확인 또는 기록

5.3 STN 시작 직전 5분 체크

6. 마스킹 정책 v3으로의 전환 권고

6.1 현 v2 정책의 한계

6.2 v3 정책 제안 — 일반화 강화

6.3 v3 전환 실행 방안

7. 본 챕터에서 새로 식별된 리스크

7.1 격리 전략의 조직 차원 함의

8. 다음 챕터로의 인계

부록 A. 격자 매트릭스 단일 페이지

부록 B. 참고 자료