0. 이 챕터의 목적
인프라 관리 SaaS(CMP·Kubernetes 콘솔·클라우드 관리 화면 등)에서 사용자 작업은 여러 추상화 계층을 통과해 실제 효과를 만든다. 각 계층은 독립적인 결함 가능성을 가진다.
- UI가 입력값을 잘못 수집했을 수 있다
- UI가 입력값은 잘 수집했지만 API 호출 페이로드를 잘못 만들었을 수 있다
- API 호출은 정확한데 백엔드가 무시하거나 다르게 해석했을 수 있다
- 백엔드가 적용했다고 응답했지만 설정 파일이 안 바뀌었을 수 있다
- 한 노드의 설정 파일은 바뀌었지만 다른 노드에 동기화 안 됐을 수 있다
- 모든 게 정상인데 게스트가 인식하지 못해 실제로는 작동하지 않을 수 있다
본 챕터는 이 6단계를 명시적으로 검증하는 사슬을 정의한다. 사슬을 통과해야 작업이 "실제로 성공"이며, 단 한 단에서라도 끊어지면 결함이다.
1. 6 Layer 사슬
[L1] UI 동작 → 결과 표시
↓ "사용자가 본 것"
[L2] API 페이로드 (브라우저 DevTools 또는 프록시 캡처)
↓ "도구가 자기 입으로 무엇을 했다고 주장하는가"
[L3] 백엔드 API 직접 (도구 우회)
↓ "백엔드가 실제로 무엇을 받았는가"
[L4] 백엔드 설정 파일 직접 (CLI/SSH)
↓ "백엔드가 어떻게 자기 상태를 갱신했는가"
[L5] N개 노드 동기화 검증
↓ "변경이 모든 노드에 일관되게 전파됐는가"
[L6] 실제 사용 가능성 (게스트 OS / 실제 mount / ping / I/O)
↓ "사용자에게 약속된 효과가 실제로 나타나는가"2
3
4
5
6
7
8
9
10
11
12
1.1 사슬 통과 의미
각 단을 통과한다는 것은:
- L1: 사용자가 약속받은 결과 화면이 떴다
- L2: 도구가 자기가 한 일을 정직하게 보고했다 (UI 표시 = API 페이로드)
- L3: 백엔드가 그 주장과 일치하는 호출을 받았다
- L4: 백엔드가 호출에 따라 자기 상태를 변경했다
- L5: 변경이 클러스터 전체에 일관되게 동기화되었다
- L6: 약속된 효과가 실제 게스트·외부에서 작동한다
6단 모두 통과해야 "성공"이다.
1.2 단별 결함의 의미
각 단에서 끊기는 결함은 다른 본질을 가진다.
| 끊김 위치 | 결함 본질 | 책임 영역 |
|---|---|---|
| L1 → L2 | UI 표시 결함 (사용자 본 결과 ≠ 실제 호출) | 도구 프론트엔드 |
| L2 → L3 | 페이로드 결함 (도구 주장 ≠ 백엔드 수신) | 도구 백엔드 / 네트워크 |
| L3 → L4 | 백엔드 결함 (수신 ≠ 적용) | 인프라 백엔드 |
| L4 → L5 | 동기화 결함 (단일 노드 적용 ≠ 클러스터 전파) | 클러스터 메타 시스템 |
| L5 → L6 | 효과 결함 (구성 적용 ≠ 실제 작동) | 게스트 OS / 외부 시스템 / 인프라 통합 |
결함이 어느 단에서 끊겼는지 식별하면 책임 영역이 자동 결정된다. 이는 결함 보고서의 정확도를 결정적으로 높인다.
2. 단별 검증 기법
2.1 L1 — UI 검증
가장 직관적이지만 혼자서는 의미 없다. UI가 보여주는 것은 사용자에게 약속한 것일 뿐, 실제로 일어난 일과 다를 수 있다.
수행:
- 작업 직후 결과 화면 캡처
- 자원 목록·상태 갱신 확인
- 알림·에러 메시지 캡처
이 단에서 멈추면 도구의 거짓 성공 보고에 속는다.
2.2 L2 — API 페이로드 캡처
브라우저 DevTools(Network 탭) 또는 외부 HTTP 프록시(Charles, mitmproxy)로 도구가 백엔드에 보낸 실제 요청·응답을 캡처.
수행:
- F12 → Network → 해당 작업 클릭 → 요청 우클릭 → Copy as cURL
- 응답 본문 별도 저장 (시나리오 ID로 파일명)
- 헤더 검증 (인증 토큰, CSRF, 콘텐츠 타입)
이 단의 데이터가 L1과 다르면 UI 결함, L1과 같으나 L3와 다르면 페이로드 결함.
2.3 L3 — 백엔드 API 직접 호출
도구를 우회하고 백엔드 API를 직접 호출하여 같은 작업을 수행하거나 결과 상태를 조회.
가상 명령:
# 백엔드 CLI 직접 호출
backend-cli get resource $resource_id
# 또는 백엔드 REST API 직접
curl -k -H "Authorization: ..." \
https://backend.example.com/api/v1/resources/$resource_id2
3
4
5
6
L3와 L2의 차이가 없어야 정상.
2.4 L4 — 설정 파일 직접 확인
백엔드가 자기 상태를 어떻게 적용했는지 디스크 수준에서 확인. 가상 예시:
# 자원 정의 파일
ssh pve-nodeC "cat /etc/backend/resources/$resource_id.conf"
# 클러스터 메타 파일
ssh pve-nodeC "cat /etc/backend/cluster.cfg"2
3
4
5
L4가 L3와 다르면 백엔드 자체 결함 (수신했지만 적용 안 함).
2.5 L5 — N개 노드 동기화
설정 파일이 모든 노드에 일관되게 전파됐는지 검증. md5 비교가 가장 빠르다.
# 5노드에서 같은 파일의 md5 비교
for n in pve-nodeA pve-nodeB pve-nodeC pve-nodeD pve-nodeE; do
ssh "$n" "md5sum /etc/backend/cluster.cfg"
done
# 모든 md5가 일치하면 동기화 성공
# 일치하지 않는 노드 발견 시 그 노드의 동기화 메커니즘 점검2
3
4
5
6
7
L5에서 끊김은 단일 노드 검증으로 절대 잡히지 않는 결함이다. 이 단의 누락이 가장 자주 일어난다.
2.6 L6 — 실제 사용 가능성
설정만 정확하고 실제로는 작동하지 않을 수 있다. 가상 예시:
| 영역 | L6 검증 |
|---|---|
| 컴퓨트 (VM 생성) | 게스트 OS 부팅 + ping + 콘솔 접근 |
| 네트워크 (NIC 추가) | 게스트 내 인터페이스 인식 + IP 할당 + 외부 통신 |
| 스토리지 (디스크 추가) | 게스트 내 디스크 인식 + 마운트 + I/O 측정 |
| 방화벽 (룰 추가) | 호스트 nftables 박힘 + 외부에서 차단 확인 |
L6가 가장 높은 비용을 요구하지만 사용자가 실제로 마주치는 것이 L6다. L1~L5가 모두 통과해도 L6에서 끊기면 사용자에게는 결함이다.
3. 사슬 깊이 결정 — 모든 작업에 6단을 적용하지 않는다
6 Layer는 최대 깊이다. 모든 작업에 6단을 다 돌리는 것은 비용 낭비이며 실용적이지 않다.
01 L×R 격자와 02 4 분류에 따라 사슬 깊이를 결정한다.
3.1 격자 셀별 사슬 깊이
| 격자 셀 행동 코드 | 권장 사슬 깊이 |
|---|---|
| 안전 | L1 + L2 (UI + 페이로드 일치만 확인) |
| 주의 | L1 + L2 + L3 (백엔드 직접 비교) |
| 위험 | L1~L4 (설정 파일까지) |
| 금지 | L1~L6 전체 (사전·사후 양방향) |
| 절대금지 | L1~L6 + 인간 다중 승인 |
3.2 분류별 사슬 깊이
| 4 분류 | 권장 사슬 깊이 |
|---|---|
| 4.1 CRUD | L1·L2·L3 (+ L4·L6 선택) |
| 4.2 스테이징 | L1~L4 (+ L5·L6 선택) |
| 4.3 위험 시나리오 | L1~L6 전체 (특히 L6 — 사고 흔적) |
| 4.4 클러스터 일관성 | L5 필수 (다른 단은 선택) |
3.3 시간 예산
각 단의 일반적 비용:
| 단 | 시간 (단일 작업당) | 자동화 가능성 |
|---|---|---|
| L1 | 1~2분 | 부분 (UI 자동화) |
| L2 | 1~2분 | 가능 (HAR 캡처) |
| L3 | 2~5분 | 가능 (스크립트) |
| L4 | 2~5분 | 가능 |
| L5 | 5~10분 | 가능 (md5 비교) |
| L6 | 10~30분+ | 부분~수동 |
L6가 압도적으로 비싸다. 따라서 L6는 위험 셀에만 적용하는 것이 현실적.
4. 사슬 보고서 양식
각 검증 결과는 다음 양식으로 기록.
## [시나리오 ID] 사슬 검증 결과
### Layer 1: UI
- 동작: [작업 내용]
- UI 결과: [성공/실패/메시지]
- 캡처: [스크린샷 경로]
### Layer 2: API 페이로드
- METHOD URL
- payload: { ... }
- response: { status, body }
- 일치: L1 vs L2 [일치/불일치]
### Layer 3: 백엔드 API 직접
- 명령: [...]
- 결과: [...]
- 일치: L2 vs L3 [일치/불일치]
### Layer 4: 설정 파일
- 파일 경로
- diff: [...]
- 일치: L3 vs L4 [일치/불일치]
### Layer 5: N개 노드 동기화
- md5 결과: [...]
- 일치: 모든 노드 일치 [예/아니오]
### Layer 6: 실제 사용 가능성
- 검증 명령: [...]
- 결과: [...]
- 일치: 약속된 효과 발생 [예/아니오]
### 결함 후보
- [있다면 어느 단에서 끊겼는지 + 결함 패턴]2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
이 양식을 일관되게 사용하면 결함 보고서의 정확도가 결정적으로 높아진다. "실패했다"가 아니라 "L4까지는 정상인데 L5에서 노드 B만 동기화되지 않음" 수준의 정밀한 진단이 자동으로 만들어진다.
5. 양방향 사슬 — 사전·사후
위험 시나리오 테스트(4.3)에서는 사슬을 양방향으로 돌린다.
5.1 사전 사슬 (작업 직전)
작업 전에 L4·L5의 현재 상태를 박제. 이는 작업 후 비교의 기준선이 된다.
# 사전 박제
mkdir -p /tmp/snapshots/$timestamp
ssh pve-nodeC "cat /etc/backend/cluster.cfg" > /tmp/snapshots/$timestamp/cluster-before.cfg
for n in pve-nodeA pve-nodeB pve-nodeC pve-nodeD pve-nodeE; do
ssh "$n" "md5sum /etc/backend/cluster.cfg" >> /tmp/snapshots/$timestamp/sync-before.txt
done2
3
4
5
6
5.2 사후 사슬 (작업 직후)
L1부터 L6까지 정방향 검증.
5.3 차분 비교
사전·사후의 L4·L5를 비교해 변경 범위를 정확히 식별. 작업 결과로 변경되어야 할 항목만 변경되었는가, 의도치 않은 부수 변경은 없는가.
diff /tmp/snapshots/$timestamp/cluster-before.cfg \
<(ssh pve-nodeC "cat /etc/backend/cluster.cfg")2
이 차분이 부수 효과 검출의 핵심이다. 위험 시나리오 4.3에서 이 차분이 있어야 결함의 영향 범위를 정량적으로 보고할 수 있다.
6. 사슬의 한계와 보완
6.1 6단으로 부족한 영역
다음은 6단이 직접 다루지 않는다.
- 시간적 일관성: 이 시점에 L5가 통과했지만 1시간 뒤에도 통과하는가 (재동기화 안정성)
- 부하 하 일관성: 평시에 L5가 통과하는 것과 피크 시점에 L5가 통과하는 것은 다르다
- 장기 효과: L6 직후 작동하지만 24시간 뒤에 메모리 누수로 멈추는가
이 차원들이 중요한 환경에서는 6단 사슬을 시간축에 따라 N회 반복 (예: t+0, t+1h, t+24h)하는 식으로 보완한다.
6.2 단의 분리 한계
L3와 L4의 경계, L4와 L5의 경계는 도구·백엔드 구현에 따라 모호할 수 있다. 예를 들어 "설정 파일"이라는 개념이 백엔드에 없고 모든 상태가 데이터베이스에 있는 환경에서는 L4와 L5가 합쳐질 수 있다.
이 경우 사슬을 자기 환경에 맞게 5단 또는 7단으로 조정한다. 6단은 일반적 인프라 SaaS에서의 자연스러운 깊이일 뿐 절대 기준이 아니다.
7. 사슬 도입 절차
7.1 단계적 도입
처음부터 6단 모두 적용하면 비용이 폭증한다. 권장 순서:
- L1 + L2 도입 — DevTools 캡처 습관화. 비용 거의 없음.
- L4 추가 — 위험 작업에만 설정 파일 비교 도입.
- L5 추가 — 클러스터 일관성 결함 1건 발견 후 L5 도입 정당화.
- L3·L6 추가 — 4.3 위험 시나리오 테스트에 풀체인 적용.
이 순서로 도입하면 각 단의 가치를 환경 결함 발견으로 증명한 뒤 비용을 정당화하는 식이 된다. 처음부터 6단을 강제하면 팀이 형식만 따르고 실효성을 잃는다.
7.2 자동화 우선순위
L2·L3·L4·L5는 자동화 가능. L1·L6는 자동화 부분적·수동 의존.
자동화 우선순위:
- L5 (md5 비교 — 가장 단순, 가장 큰 가치)
- L4 (설정 diff)
- L3 (백엔드 API 호출)
- L2 (HAR 자동 캡처)
L1·L6는 자동화에 투자하지 않는 것이 합리적이다. 인간 관찰의 가치가 여기서 가장 크다.
8. 정리
본 사슬의 핵심은:
- 6단 분리가 결함 진단의 정밀도를 결정적으로 높인다 — "어디서 끊겼는가"가 자동으로 답해진다
- 사슬 깊이는 격자·분류로 결정되며 모든 작업에 6단을 다 돌리지 않는다
- 사전·사후 양방향이 위험 시나리오 4.3의 부수 효과 검출에 필수
- L5의 누락이 가장 자주 일어나며 단일 노드 검증의 함정이 된다
사슬이 정착되면 결함 보고서가 "실패함" 수준에서 "L5에서 노드 B만 동기화 안 됨, 클러스터 메타 시스템의 분산 일관성 결함"으로 바뀐다. 이 정밀도가 도구 개발팀의 수정 시간을 결정적으로 단축시킨다.
시리즈 마지막 챕터: 본 챕터로 CMP Meta Handbook 시리즈가 완료된다. 4 자산(L×R 격자·4 분류·챕터 구조·6 Layer 사슬)을 결합하여 자기 환경에 맞는 운영 거버넌스를 만들 수 있다.