가설·측정·결론을 각각 다른 시점에 남긴다

한 줄 요약

실험의 결과물은 고장이 아니라 노트다. 가설·측정·결론 셋이 서로 맞을 때만 그 노트가 쓸모 있다.

왜 이게 필요했나

장애를 주입하는 일 자체는 어렵지 않다. 명령 한 줄이면 된다. 어려운 것은
그 다음 주에도 남는 무언가를 만드는 일이다. 실험이 끝나고 나면 사람들의
기억은 놀랄 만큼 빨리 흐려지고, 심지어 방향까지 바뀐다. 성공률이 76%였던 것을
"거의 다 실패했었죠" 로 기억하고, 반대로 확실히 실패했던 실험을 "그때도 잘
버텼던 것 같은데" 로 기억한다. 그래서 실험은 세 조각을 각각 다른 시점에
글로 남긴다.

어떻게 동작하나

첫째, 가설은 부수기 전에 적는다. 나중에 적으면 그것은 가설이 아니라 결과의
요약이다. 사람은 결과를 본 뒤에는 "그럴 줄 알았다" 는 느낌을 실제 예측과
구별하지 못한다. 그래서 순서 자체가 방법의 일부다. 가설에는 무엇이 일어날
것인지뿐 아니라 왜 그렇게 예상하는지와 언제 멈출지를 함께 적는다.

둘째, 측정은 실험 창 안에서 한다. 고장을 낸 다음에 따로 재면 이미 복구가
시작된 뒤의 숫자를 재게 된다. 부하를 먼저 걸어 두고, 그 창 안에서 고장을 내고,
창이 닫힌 뒤에 결과를 읽는 순서여야 한다.

셋째, 결론은 가설과 측정을 견준 결과다. 여기서 가장 중요한 규칙이 하나
있다. 반증된 가설은 실패가 아니다. 오히려 예상과 다른 결과야말로 그 실험이
벌 수 있는 가장 비싼 정보다. "복제본을 셋으로 늘리면 요청이 하나도 안 깨질
것이다" 라고 적었는데 실제로는 몇 건이 깨졌다면, 그날 배운 것은 "복제본 수만으로는
부족하다" 라는 사실이다. 결론에 confirmed 만 적히는 실험 노트는 대개 가설을
나중에 적었다는 뜻이다.

실험 한 건의 최소 구성  가설      availability: ok / latency: slower        + 왜 + 중단 조건  측정      성공률 0.993 · p95 291ms (기준선 33ms)  결론      관측 ok / slower → 가설과 같음 → confirmed + 무엇을 바꿀 것인가

이 세 조각을 각각 다른 파일로 남기는 것도 방법의 일부다. 한 파일에 계속
덧쓰면 가설이 언제 적혔는지, 어느 숫자가 어느 실험의 것인지 금세 흐려진다.
가설 파일은 실험이 시작된 뒤에는 손대지 않고, 측정 파일은 도구가 그 순간의
클러스터와 함께 통째로 쓰고, 결론 파일은 맨 마지막에 따로 만든다. 나중에
누군가 이 노트를 읽을 때 **"이 문장이 언제 쓰였는가" 를 파일 단위로 답할 수
있는 것**이 신뢰의 대부분이다.

숫자에 이름을 붙이는 규칙도 미리 정해 둔다. 성공률 0.993 이 "괜찮음" 인지
"나빠짐" 인지는 사람마다 다르게 읽기 때문이다. 이 코스의 실습은 성공률
0.98 이상을 ok, 0.5 이상을 degraded, 그 아래를 down 으로 부르고, 지연은
기준선 p95 의 2배 이상이면 slower 로 부른다. 규칙이 먼저 있으면 결론이
말싸움이 되지 않는다.

현장에서 만나는 모습

실험 노트에는 한계도 함께 적어야 한다. 이 실습에서 관측 파일은 도구가
만들지만, 그 파일은 결국 VM 안의 편집 가능한 텍스트다. 그래서 채점은 숫자만
보지 않고 클러스터에 실제로 남은 흔적 — 배포 때마다 새로 생기는
[ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)과
지금 살아 있는 Pod — 을 함께 본다. 숫자는 지어낼 수 있어도 하지 않은 배포가
남긴 ReplicaSet 은 지어낼 수 없기 때문이다. 현장에서도 마찬가지다. 보고서의
숫자는 언제나 다시 확인할 수 있는 경로와 함께 적어 두어야 한다.

노트의 마지막 칸은 "그래서 무엇을 바꿀 것인가" 다. 이 칸이 비어 있으면
실험은 구경거리로 끝난다. 바꿀 것은 코드일 수도 있고 설정일 수도 있지만,
"알림 기준을 지연 쪽으로 하나 더 만든다" 처럼 운영 절차일 때도 많다. 특히
성공률은 멀쩡한데 지연만 나빠지는 종류의 사건은 기존 알림에 전혀 걸리지
않으므로, 실험에서 그것을 확인했다면 그 자리에서 알림을 하나 더 만드는 것이
정확한 후속 조치다. 다섯 번의 실험에서 다섯 개의 서로 다른 결정이 나오는 것이
이상적이고, 다섯 칸에 같은 문장이 적힌다면 대개 실험을 하나만 한 것이다.

그리고 실험이 끝나면 반드시 원래대로, 혹은 배운 것을 반영한 더 나은 설계로
되돌린다. 되돌리지 않은 실험은 다음 사람에게 그냥 고장으로 인계된다.
[돌아가는 Pod 를 들여다보는 방법](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/)을
익혀 두면 복구 직후 확인도 빨라진다.

노트가 쌓이면 그다음 단계는 자동화다. 손으로 하던 실험을 정해진 시각에 돌리고
정상 상태를 벗어나면 스스로 멈추게 만드는 것인데, 그 출발점은 언제나 **손으로
한 번 해 본 실험 하나**다. 사람이 읽을 수 있는 노트가 먼저 있어야 그 노트를
기계가 다시 쓸 수 있다.

다음 실습에서 할 것

진짜 k3s 위에서 다섯 번의 실험을 한다. 정상 기준선을 재고, 다섯 실험의 가설을
한꺼번에 적은 뒤, Pod 를 죽이고 CPU 를 조이고 메모리를 말린다. 마지막에는
배운 것을 반영해 설계를 고치고 같은 공격을 다시 받아 본다.