인프라 QA 실습 랩 — 내 노트북에 올리고 기준·폴링 대기·스냅샷 비교를 직접 쓰기

개념

이 레슨은 읽는 레슨이 아니다

레슨 1~9 는 관점을 다뤘다. 제어 평면과 데이터 평면, 비동기 수렴, conditions, GitOps 동기화 판정, GPU 진단, 추론 지표, 장애 주입. 그 관점들의 공통 전제가 하나 있다 — 실제로 돌려 본 적이 있어야 감각이 생긴다.

문제는 환경이다. Private Cloud 도, GPU 클러스터도, 사내 플랫폼도 개인이 만들 수 없다. 그래서 이 분야는 "일을 해 봐야 배울 수 있는데, 배워야 일을 받는" 순환에 갇히기 쉽다.

이 레슨은 그 순환을 끊는다. 노트북 한 대에서 돌아가는 환경으로, 이 모듈의 핵심 기법 세 가지를 실제로 작동시킨다.

1. 상태 모델을 판정 기준으로 쓰기 — 허용 경로와 금지 전이를 코드로 검사
2. 수렴을 기다리는 폴링 — 고정 대기(sleep) 를 쓰지 않는 방법
3. 스냅샷 전후 비교 — 시험이 남긴 리소스를 잡아내기

세 가지 모두 Kubernetes 에서 익히면 OpenStack 이나 사내 플랫폼으로 그대로 옮겨진다. 대상 API 는 바뀌지만 기법은 같다.

왜 kind 인가 — 그리고 한계

kind(Kubernetes IN Docker) 는 Docker 컨테이너를 노드로 써서 클러스터를 만드는 도구다. 공개 문서가 설명하는 설정 파일의 최소 형태는 kind: Cluster 와 apiVersion: kind.x-k8s.io/v1alpha4 를 지정하는 것이고, 노드 역할을 나열해 다중 노드 클러스터 를 만들 수 있다. 현재 지원 apiVersion, 설치 방법, 설정 항목은 kind 공식 문서에서 확인한다(원문 확인) — 버전에 따라 바뀌는 부분이다.

QA 실습에 kind 가 적합한 이유는 셋이다.

• 노드를 여러 개 만들 수 있다. 스케줄링, 노드 격리(cordon·drain), 노드 장애를 흉내 낼 수 있다. 단일 노드 환경으로는 못 하는 실습이다
• 클러스터를 버리고 다시 만드는 비용이 거의 없다. 기준선 상태로 되돌리는 것이 쉬워 반복 실습에 적합하다
• 제어 평면 구성 요소가 컨테이너로 보인다. 제어 평면을 일부러 멈춰 보는 실습이 가능하다(레슨 7 의 장애 주입 발상)

한계도 분명히 해 둔다. kind 에서 확인할 수 없는 것이 많다.

그래서 kind 랩의 목적은 성능 측정이 아니라 기법 숙달 이다. "이 환경에서 성능을 재서 보고한다" 는 결론으로 가면 틀린 결론이 된다. 이 구분은 모듈 62 레슨 3(시뮬레이터가 대체하지 못하는 것) 과 모듈 63 레슨 4(호스트와 대상의 차이) 에서 다룬 원칙과 같다.

랩 0단계 — 기준선을 먼저 만든다

실습에서 가장 많이 건너뛰는 단계이고, 건너뛰면 모든 비교가 무의미해진다.

[기준선(baseline) 이 없을 때]
시험 실행 → "리소스가 3개 남았네?" → 원래 몇 개였는지 모름 → 판정 불가
 
[기준선이 있을 때]
스냅샷 A 저장 → 시험 실행 → 스냅샷 B 저장 → A·B 차분 → 남은 것이 정확히 보인다

기준선은 "시험 전 상태" 를 기계가 읽을 수 있는 형태로 저장한 것 이다. 사람이 눈으로 본 것은 기준선이 아니다.

클러스터에서 기준선으로 담을 것은 이렇다.

• 노드 목록과 각 노드의 Ready 상태
• 네임스페이스 목록
• 네임스페이스별 리소스 수(파드·서비스·PVC·시크릿·컨피그맵 등)
• PersistentVolume 목록과 각 상태
• 클러스터 범위 리소스(ClusterRole·CRD 등) 목록

기법 1 — 상태 모델을 판정 기준으로 쓰기

레슨 2 에서 선언형 상태와 conditions 를 다뤘다. 여기서는 그것을 검사 코드 로 옮긴다.

Kubernetes 리소스의 상태는 대개 status.conditions 배열로 노출된다. 각 조건에는 type, status, reason, message, 그리고 전이 시각이 담긴다. QA 가 판정에 쓸 수 있는 것이 이 구조다.

판정 기준을 세 축으로 쓴다.

축 1 — 최종 상태. 정해진 시간 안에 원하는 조건이 True 가 되는가.

축 2 — 허용된 경로. 중간에 거친 상태가 허용 목록 안에 있는가. 이것을 확인하려면 이벤트와 조건 전이를 수집 해야 한다. 한 번만 보면 최종 상태만 알 수 있다.

축 3 — 금지 전이. 일어나서는 안 되는 전이가 없었는가. 예 — 사용자 조작 없이 Ready=True 에서 Ready=False 로 돌아가기, 준비 완료 후 재시작 횟수가 올라가기.

축 2 와 3 이 QA 가 기여하는 지점이다. 개발자가 쓰는 검사는 대개 축 1 에서 멈춘다. "결국 됐다" 와 "제대로 됐다" 는 다르다 — 중간에 한 번 실패하고 재시도로 성공한 것은 축 1 에서는 통과이고 축 3 에서는 결함일 수 있다.

기법 2 — 폴링을 제대로 쓰기

인프라 검증에서 가장 흔한 나쁜 코드가 고정 대기 다.

[나쁜 코드]
apply 후 sleep 60 → 상태 확인
  문제 1: 환경이 느리면 60초로 부족 → 간헐 실패(flaky)
  문제 2: 환경이 빠르면 55초를 낭비 → 전체 시험이 느려짐
  문제 3: 왜 60인지 설명할 수 없다 → 근거 없는 기준
 
[옳은 코드]
apply 후 "조건이 충족될 때까지" 폴링, 상한 시간과 함께
  - 충족되면 즉시 진행 (빠르다)
  - 상한까지 안 되면 실패 (근거 있는 기준)
  - 실패 시 그 시점의 상태·이벤트를 함께 남긴다 (진단 가능)

kubectl 에는 조건 대기 기능이 있다. 공개 문서가 설명하는 형태는 kubectl wait --for=condition=<조건> <리소스> 이고 --timeout 으로 상한을 준다. 지원하는 --for 표현과 옵션은 사용 중인 버전의 kubectl wait 문서에서 확인한다(원문 확인) — 버전에 따라 표현이 늘어난 부분이 있다.

도구가 제공하는 대기로 충분하지 않을 때(사내 플랫폼 API, 복합 조건, 전이 이력 수집) 는 직접 폴링을 쓴다. 직접 쓸 때 반드시 들어가야 하는 다섯 요소다.

세 번째 요소가 실무에서 큰 차이를 만든다. 리소스가 Failed 로 떨어졌는데 상한 10분을 다 기다리면, 시험 100건에서 수 시간이 날아간다. 즉시 실패 조건을 넣으면 몇 초에 끝난다.

상한 시간의 근거 도 적어 둔다. "경험적으로 60초" 가 아니라 "이 환경에서 측정한 수렴 시간 분포의 상위값 + 여유" 로 정하고, 그 측정 결과를 남긴다. 근거가 있으면 환경이 바뀔 때 다시 계산할 수 있다.

기법 3 — 스냅샷 전후 비교로 누수 잡기

이 모듈의 첫 문장이 "인프라 플랫폼의 결함은 수렴하지 않는 상태와 남은 리소스로 드러난다" 였다. 남은 리소스를 잡는 방법이 스냅샷 비교다.

흐름은 단순하다.

스냅샷 A (시험 전)
    ↓
시험 실행 (리소스를 만들고, 쓰고, 지운다)
    ↓
정리 완료 대기 (여기서도 폴링 — 즉시 사라지지 않는다)
    ↓
스냅샷 B (시험 후)
    ↓
차분: B - A = 남은 것 / A - B = 사라진 것(있으면 더 심각)

"A - B" 를 보는 것이 중요하다. 시험이 기존 리소스를 지워 버린 경우이고, 남은 리소스보다 훨씬 심각한 결함이다. 많은 팀이 "남은 것" 만 확인한다.

스냅샷 비교에서 다룰 세 가지 어려움이 있다.

1) 노이즈. 상태 필드, 타임스탬프, 리소스 버전, 자동 생성 토큰처럼 시험과 무관하게 바뀌는 항목 이 차분에 섞인다. 비교 전에 제외 규칙을 정한다. 제외 규칙을 문서로 두고, 무엇을 왜 제외했는지 적는다 — 제외 규칙이 과하면 결함을 못 보게 된다.

2) 비동기 정리. 리소스는 삭제 요청 즉시 사라지지 않는다. 종료 유예 기간이 있고, 종료자(finalizer) 가 붙어 있으면 더 오래 걸린다. "정리 완료" 를 폴링으로 확인한 뒤 스냅샷 B 를 찍는다. 이걸 안 하면 매번 "남은 리소스 있음" 이 나와 검사가 신뢰를 잃고, 결국 아무도 보지 않게 된다.

3) 소유 관계. 어떤 리소스는 다른 리소스가 만든 것이다. 상위 리소스를 지우면 하위가 따라 지워져야 한다. 차분에서 "하위만 남은 경우" 를 찾는 것이 소유 관계 결함을 잡는 방법이다.

OpenStack 올인원 — 선택지와 비용

레슨 3 에서 OpenStack 검증을 다뤘고, 그것도 손으로 해 보고 싶을 수 있다. 올인원 개발 환경을 구성하는 공개 수단이 있다(개발용 설치 스크립트 방식이 대표적). 설치 방법, 지원 운영체제와 버전, 필요 사양, 설정 파일 형식은 해당 프로젝트의 공식 문서에서 확인한다(원문 확인) — 이 영역은 변화가 빠르다.

다만 kind 와 비교해 비용 구조가 다르다 는 점을 알고 시작해야 한다.

실무적 권고는 이렇다. 기법 숙달은 kind 에서 하고, OpenStack 올인원은 "레슨 3 의 도구를 한 번 실행해 보는" 목적으로 제한한다. Tempest 같은 표준 도구를 실제로 돌려 보고, 포함·제외 목록이 어떻게 동작하는지 확인하는 정도로 목표를 좁히면 투자 대비 효과가 있다. 올인원 환경에서 성능이나 업그레이드를 검증하겠다는 목표는 비현실적이다.

그리고 가상 머신에 격리해서 올린다. 올인원 설치 스크립트는 호스트 설정을 광범위하게 바꾸므로, 개인 작업 환경에 직접 설치하지 않는다.

랩에서 얻은 것을 실무로 옮기기

이 랩의 최종 산출물은 클러스터가 아니라 재사용 가능한 검증 코드와 문서 다. 실무에 들어갔을 때 옮겨 갈 수 있는 형태로 만든다.

• 스냅샷 수집·비교 스크립트 — 대상 API 만 바꾸면 다른 플랫폼에 쓰인다
• 폴링 헬퍼 — 다섯 요소를 갖춘 대기 함수. 사내 플랫폼 API 에 그대로 적용
• 상태 모델 판정 기준서 — 허용 경로·금지 전이를 적는 양식
• 제외 규칙 문서 — 무엇을 왜 노이즈로 뒀는가
• 상한 시간 근거 기록 — 측정된 수렴 시간 분포

면접과 포트폴리오에서도 이쪽이 쓰인다. "Kubernetes 를 공부했습니다" 보다 "다중 노드 kind 클러스터에서 상태 전이 금지 조건을 검사하고, 스냅샷 차분으로 리소스 누수를 잡는 스크립트를 만들었습니다" 가 다르게 들린다.

실무에서 왜 필요한가

인프라 플랫폼 QA 채용에서 가장 큰 장벽이 환경 접근성 이다. 공고는 Kubernetes· OpenStack·GPU 플랫폼 경험을 요구하는데, 그 경험은 해당 조직에 들어가야 생긴다. 그래서 지원자 대부분이 문서로 읽은 지식 만 갖고 면접에 온다.

면접에서 그 차이가 바로 드러나는 질문이 있다. "비동기로 생성되는 리소스를 어떻게 검증하십니까." 읽기만 한 사람은 "상태가 ACTIVE 가 되는지 확인합니다" 라고 답한다. 해 본 사람은 고정 대기를 쓰지 않는 이유, 즉시 실패 조건, 실패 시 상태 덤프, 상한 시간의 근거 를 말한다. 이 차이는 kind 클러스터에서 한 주 실습하면 생긴다.

그리고 실무에 들어간 뒤에도 이 랩이 쓰인다. 사내 플랫폼의 시험 코드를 고칠 때, 먼저 kind 에서 기법을 검증해 보고 옮기는 것 이 안전하다. 운영 환경에서 실험하면 영향 범위를 통제하기 어렵다.

가장 실질적인 가치는 간헐 실패를 줄이는 역량 이다. 인프라 시험은 간헐 실패가 많고, 그 대부분이 고정 대기와 정리 미완료 에서 온다. 이 두 원인을 아는 사람이 시험 묶음을 고치면 실패율이 눈에 띄게 떨어지고, 그 성과는 조직에서 즉시 인정된다.

실습 과제

과제 1 — 다중 노드 클러스터와 기준선 (30분)

1. 설정 파일로 제어 평면 1 + 워커 2 구성의 클러스터를 만든다. 설정 파일 형식과 현재 지원 apiVersion 은 공식 문서에서 확인 한다
2. 모든 노드가 준비 상태가 되는 것을 고정 대기 없이 확인한다
3. 기준선 스냅샷 스크립트 를 쓴다. 본문의 다섯 항목을 수집해 기계가 읽을 수 있는 형태(JSON 등) 로 파일에 저장한다
4. 스크립트를 두 번 실행해 두 스냅샷을 비교 한다. 아무 작업도 안 했는데 달라지는 항목을 찾는다 — 그것이 노이즈이고, 제외 규칙의 출발점 이다
5. 제외 규칙 문서를 만들고, 항목마다 왜 제외하는지 를 한 줄 적는다

과제 2 — 상태 모델 판정 기준서와 검사 코드 (35분)

1. 간단한 워크로드(복제본 2개짜리 디플로이먼트) 를 대상으로 상태 모델 을 쓴다. 허용 경로, 금지 전이, 상한 시간을 각각 정한다
2. 금지 전이를 최소 4개 만든다. 예 — 준비 완료 후 준비 해제, 재시작 횟수 증가, 조건이 Unknown 으로 체류, 복제본 수가 요청과 달라진 채 유지
3. 세 축(최종 상태·허용 경로·금지 전이) 을 각각 검사하는 코드를 쓴다. 축 2·3 을 위해 전이를 수집 해야 한다는 점에 주의한다
4. 일부러 결함을 만든다 — 잘못된 이미지 이름, 즉시 종료되는 명령, 과도한 자원 요청. 각 경우에 어느 축에서 잡히는지 를 표로 적는다
5. 축 1 만으로는 잡히지 않는 결함을 하나 찾아내 기록한다

과제 3 — 폴링 헬퍼 작성 (30분)

본문의 다섯 요소를 모두 갖춘 폴링 함수 를 쓴다.

1. 상한 시간·폴링 간격을 인자로 받는다
2. 즉시 실패 조건을 인자로 받아, 해당하면 상한까지 기다리지 않는다
3. 실패 시 대상 리소스의 상태와 최근 이벤트를 수집해 함께 출력한다
4. 전이 이력을 수집해 반환한다(과제 2 의 축 2·3 에서 쓴다)
5. 같은 시험을 고정 대기 버전 과 폴링 버전 으로 각각 작성해 10회 실행하고 총 소요 시간과 실패 횟수 를 비교한다. 결과를 표로 적는다
6. 상한 시간의 근거를 만든다 — 10회 수렴 시간을 측정해 분포를 적고, 상한을 어떻게 정했는지 한 문단 쓴다

과제 4 — 리소스 누수 잡기 (35분)

1. 리소스를 만들고 쓰고 지우는 시험 시나리오를 하나 쓴다. 네임스페이스, 파드, 서비스, 컨피그맵, PVC 를 포함한다
2. 일부러 정리를 불완전하게 만든다(한 리소스의 삭제를 빠뜨린다)
3. 스냅샷 A → 시험 → 정리 완료 폴링 → 스냅샷 B → 차분 흐름을 구현한다
4. 차분에서 B - A(남은 것) 와 A - B(사라진 것) 를 모두 출력한다
5. 정리 완료 폴링을 빼고 같은 시험을 10회 돌려 본다. 몇 번 거짓 양성이 나오는지 세고, 왜 그런지 적는다. 이것이 간헐 실패의 전형이다
6. 소유 관계 검사 를 추가한다 — 상위 리소스를 지웠는데 하위만 남은 경우를 찾아내는 규칙을 쓴다
7. 기존 리소스를 지워 버리는 시나리오를 하나 만들고(A - B 가 비지 않게) 그것이 왜 더 심각한 결함인지 한 문단 적는다

과제 5 — 제어 평면 중단 실습 (25분)

레슨 7 의 발상을 랩에서 작게 돌려 본다. 자신의 랩 환경에서만 수행한다.

1. 워크로드를 실행해 동작 중인 상태 로 둔다
2. 제어 평면 구성 요소를 멈춘다(컨테이너 정지 등 소프트웨어 계층 조작만)
3. 그 동안 데이터 평면이 계속 동작하는지 확인한다. 본문의 "제어 평면이 멈춰도 데이터 평면은 계속 돌아야 한다" 를 직접 본다
4. 제어 평면을 되살리고, 멈춘 동안 들어온 변경 요청이 어떻게 처리되는지 본다
5. 관찰한 것을 검증 기준 문장 으로 옮긴다("제어 평면 중단 N 분 동안 기존 워크로드의 가용성이 유지되어야 한다" 형태)
6. 이 실습이 실제 운영 환경에서는 승인과 계획 없이 하지 않는다 는 것을 한 줄 적어 둔다

과제 6 (선택) — OpenStack 올인원 한 번 (시간 가변)

1. 가상 머신에 격리해 올인원 개발 환경을 구성한다. 설치 방법·사양·지원 버전은 공식 문서에서 확인 한다. 개인 작업 환경에 직접 설치하지 않는다
2. 목표를 좁힌다 — 레슨 3 의 표준 도구를 한 번 실행 하고, 포함·제외 목록이 어떻게 동작하는지 확인하는 것까지
3. 설치 과정에서 막힌 지점과 해결 방법을 기록한다. 이 기록이 과제의 산출물이다
4. 이 환경에서 측정할 수 없는 것 을 목록으로 적는다(성능, 업그레이드, 다중 테넌트 간섭 등)

자가 체크리스트

• 이 분야의 "해 봐야 배우는데 배워야 일을 받는" 순환과 랩이 그것을 끊는 방식을 안다
• kind 가 Docker 컨테이너를 노드로 쓰며 다중 노드 구성이 가능하다는 것을 안다
• kind 설정의 apiVersion·설치 방법은 공식 문서에서 확인해야 함을 안다
• kind 랩에서 확인 가능한 것과 불가능한 것을 각각 들 수 있다
• 랩의 목적이 성능 측정이 아니라 기법 숙달이라는 것을 설명할 수 있다
• 기준선 없이는 모든 비교가 무의미하다는 것과, 기준선이 기계가 읽는 형태여야 함을 안다
• 상태 판정의 세 축(최종 상태·허용 경로·금지 전이) 을 구분할 수 있다
• 축 2·3 을 확인하려면 전이를 수집해야 한다는 것을 안다
• "결국 됐다" 와 "제대로 됐다" 의 차이를 예로 설명할 수 있다
• 고정 대기의 세 문제(부족·낭비·근거 없음) 를 들 수 있다
• 조건 대기 명령의 형태와, 지원 표현은 버전 문서 확인임을 안다
• 직접 폴링의 다섯 요소를 들 수 있다
• 즉시 실패 조건이 전체 시험 시간을 크게 줄이는 이유를 설명할 수 있다
• 상한 시간을 측정된 수렴 분포에서 정하고 근거를 남길 수 있다
• 스냅샷 전후 비교 흐름을 쓰고, A - B(사라진 것) 도 봐야 하는 이유를 안다
• 노이즈 제외 규칙이 과하면 결함을 놓친다는 것을 알고 문서로 남길 수 있다
• 정리 완료를 폴링으로 확인한 뒤 스냅샷을 찍어야 하는 이유와, 안 하면 생기는 간헐 실패를 안다
• 소유 관계 검사로 "하위만 남은 경우" 를 찾을 수 있다
• OpenStack 올인원과 kind 의 비용 구조 차이를 비교할 수 있다
• 올인원 환경을 가상 머신에 격리해야 하는 이유를 안다
• 올인원 환경에서 성능·업그레이드 검증은 비현실적이라는 것을 안다
• 랩의 산출물이 클러스터가 아니라 재사용 가능한 코드·문서라는 것을 안다
• 간헐 실패의 두 주요 원인(고정 대기·정리 미완료) 을 알고 고칠 수 있다

흔한 실수

기준선을 안 찍고 시작한다. 시험 후에 리소스가 남았는지 판단할 근거가 없다. 눈으로 본 것은 기준선이 아니다. 기계가 읽는 형태로 저장한다.

단일 노드 환경으로 실습한다. 스케줄링, 노드 격리, 노드 장애를 흉내 낼 수 없다. 다중 노드 구성이 kind 를 쓰는 주된 이유다.

랩에서 성능을 재서 보고한다. 컨테이너 기반 랩의 네트워크·스토리지 특성은 실제와 다르다. 기법 숙달과 성능 측정을 섞으면 틀린 결론이 나온다.

고정 대기를 쓴다. 간헐 실패의 가장 큰 원인이고, 시험 전체를 느리게 만들며, 숫자의 근거를 설명할 수 없다. 조건 폴링으로 바꾼다.

즉시 실패 조건을 넣지 않는다. 이미 실패한 리소스를 상한까지 기다린다. 시험 100건이면 수 시간이 날아간다.

타임아웃 메시지만 남긴다. "10분 안에 Ready 가 되지 않음" 만 보고는 원인을 알 수 없다. 실패 시점의 상태와 이벤트를 함께 덤프한다.

최종 상태만 검사한다. 중간에 실패하고 재시도로 성공한 것을 통과로 본다. 금지 전이 검사가 QA 가 더하는 가치다.

정리 완료를 기다리지 않고 스냅샷을 찍는다. 매번 "남은 리소스 있음" 이 나와 검사가 거짓 양성을 쏟아내고, 결국 아무도 보지 않게 된다.

남은 리소스만 본다. 시험이 기존 리소스를 지워 버린 경우가 더 심각하다. 양방향 차분을 본다.

노이즈 제외 규칙을 넓게 잡는다. 차분을 깨끗하게 만들려고 많이 제외하면 결함도 함께 제외된다. 제외 항목마다 사유를 적고 주기적으로 다시 본다.

소유 관계를 확인하지 않는다. 상위를 지웠는데 하위만 남는 결함은 차분 목록을 그냥 보면 눈에 띄지 않는다. 전용 규칙이 필요하다.

OpenStack 올인원으로 모든 것을 하려 한다. 설치에만 시간을 다 쓰고 기법은 못 익힌다. 목표를 "표준 도구 한 번 실행" 으로 좁힌다.

올인원 환경을 개인 작업 환경에 직접 설치한다. 호스트 설정을 광범위하게 바꾸므로 가상 머신에 격리한다.

제어 평면 중단 실습을 공용·운영 환경에서 한다. 자신의 랩에서만 한다. 운영 환경의 장애 주입은 승인과 계획이 전제다(레슨 7).

랩에서 만든 코드를 버린다. 이 랩의 산출물은 클러스터가 아니라 스크립트와 문서다. 대상 API 만 바꾸면 실무 플랫폼에 그대로 옮겨진다.

참고 자료

• kind 공식 문서 — 설치, 설정 파일 형식과 현재 지원 apiVersion, 다중 노드 구성, 이미지 적재. 버전에 따라 바뀌므로 반드시 공식 문서를 본다(원문 확인)
• Kubernetes 공식 문서 — kubectl wait 의 지원 표현과 옵션, 리소스별 conditions 의 의미, 종료 유예와 종료자(finalizer) 동작(원문 확인)
• OpenStack 개발용 올인원 설치 문서 — 설치 절차, 요구 사양, 지원 운영체제와 버전, 설정 파일 형식. 변화가 빠른 영역이다(원문 확인)
• 모듈 39 레슨 2 — Kubernetes 위에서 검증하기: 상태 모델과 conditions 의 근거
• 모듈 39 레슨 3 — OpenStack 검증: 과제 6 의 목표가 되는 표준 도구
• 모듈 39 레슨 4 — GitOps 동기화 판정: 랩에서 이어 실습할 수 있는 다음 단계
• 모듈 39 레슨 7 — 장애 주입: 과제 5 의 발상과 안전 원칙
• 모듈 62 레슨 3 — 시뮬레이터가 대체하지 못하는 것: 랩의 한계를 다루는 같은 원칙
• 모듈 63 레슨 4 — 호스트와 대상의 차이: 어느 결과를 증거로 쓸 수 있는가