상태: 정리 (2026-10-16). 앞의 다섯 편에서 확인한 사실만으로 묶었습니다. 각 편의 근거와 한계는 그 편에 있습니다.
목차
1. 보이지 않는 라벨과 기본값
다섯 사고 중 넷은 누가 일부러 설정하지 않은 값에서 시작했습니다.
| 사고 | 조용히 동작을 바꾼 것 | 누가 정했나 |
|---|---|---|
| 공인 접속 | 컨트롤 플레인의 exclude-from-external-load-balancers 라벨 |
kubeadm 이 설치 때 자동으로 |
| GPU | 자동 갱신은 켜짐, 자동 재부팅은 꺼짐 | Ubuntu unattended-upgrades 의 기본값 |
| DNS | 처음 만든 정책의 matchPattern: "*", 그리고 * 가 점을 넘지 않는다는 규칙 |
첫 설계 / Cilium 의 패턴 규칙 |
| 묶음 게이트 | \b 가 쉼표 뒤에서 맞는다는 규칙 |
정규식 엔진 |
공통점은 화면에 드러나지 않는다는 것입니다. 노드 목록의 기본 출력에는 라벨이 안 보이고, 갱신 로그에는 「재부팅 안 함」이 적히지
않고, 정책은 모양만 보면 그럴듯하고, 정규식은 짧습니다. 그래서 무언가를 고를 때(광고 노드, 패턴, 정규식)는 그 대상의 라벨과 기본
규칙을 먼저 펼쳐 보는 습관이 필요합니다. kubectl get nodes --show-labels, 설정 파일의 주석 처리된 기본값, 제품 문서의 「와일드카드」
절, 정규식의 경계 규칙이 그 「펼쳐 보기」입니다.
2. 「초록불」과 실제 상태
각 사고에는 「괜찮다」고 말하는 신호가 있었습니다. 그리고 그 신호는 거짓말을 하지 않았습니다. 보는 범위가 좁았을 뿐입니다.
- 클러스터 안에서 게이트웨이로 보낸 요청은 정말 성공했습니다. 공유기와 광고 노드 사이를 보지 않았을 뿐입니다.
- 노드는 정말 Ready 였고 자동 갱신은 정말 성공했습니다. 메모리의 커널 모듈을 보지 않았을 뿐입니다.
unchanged는 정말 「바꿀 것이 없었다」였습니다. 읽은 파일이 낡았을 뿐입니다.- 비밀값 게이트는 정말 통과했습니다. 값이 있던 폴더를 보지 않았을 뿐입니다.
- 범인 찾기는 정말 범인을 몰랐습니다. 실패 문구의
.js경로를 보지 않았을 뿐입니다.
같은 주에 배포 도구의 문서에서도 비슷한 것을 봤습니다. ArgoCD 문서는 CronJob 의 작업이 도는 동안 상태가 「Progressing」이라고 적고 있었는데, 내장 검사는 그동안 「Healthy」를 냅니다. 문서와 실제가 다르다는 이슈를 올렸고 2026-10-15 에 완료로 닫혔습니다 — argoproj/argo-cd#30209. 초록불이 무엇을 보고 켜지는지 모르면, 초록불은 아무것도 말해 주지 않습니다.
그래서 이렇게 하기로 했습니다. 확인은 결과물 쪽에서 한다. 배포됐는지는 파이프라인의 초록불이 아니라 운영이 내주는 파일로, 정책이
바뀌었는지는 apply 의 출력이 아니라 클러스터에서 다시 읽은 값으로, 사이트가 열리는지는 안이 아니라 바깥에서 봅니다.
3. 사람 몫과 자동화의 경계
이번 주에 일이 멈춘 자리는 대부분 경계였습니다.
| 일 | 왜 사람 몫인가 | 경계에서 멈춘 것 |
|---|---|---|
| GPU 노드 재부팅 | 같은 노드의 다른 서비스가 끊긴다. 시각과 영향을 사람이 정한다 | 사흘 동안 아무도 몰랐다 |
| 실습 DNS 정책 적용 | 클러스터 변경. 실습이 깨질 수 있다 | 한 달 동안 저장소에만 있었다 |
| 자격증명 회전 | 값을 쓰는 모든 연동을 함께 바꿔야 한다 | 회전 전까지는 기록 속 값이 살아 있다 |
| 묶음 게이트 실패 판단 | 「범인 모름」은 기계가 결론 낼 수 없다 | 기계가 26번 다시 돌렸다 |
자동화가 사람 몫을 대신하면 안 되지만, 사람 몫을 사람에게 정확히 넘기는 것은 자동화의 일입니다. 이번에 효과가 있었던 넘김은 이런 모양이었습니다 — 원인 한 줄, 그대로 붙여 넣을 명령, 영향 받는 것의 목록, 그리고 「했는지」를 확인하는 읽기 명령. 반대로 효과가 없었던 것은 저장소에 넣고 끝난 변경이었습니다 — DNS 정책은 클러스터에 적용할 사람도, 적용됐는지 볼 명령도 정해지지 않은 채 한 달을 보냈습니다. 넘긴 일에는 확인 명령과 기한이 붙어 있어야 하고, 확인되지 않은 넘김은 「적용 대기」로 눈에 보이게 남겨야 합니다.
4. 고친 것을 시험으로 못 박기
고친 것이 다시 깨지지 않게 하는 방법은 시험입니다. 그런데 이번 주는 시험도 틀릴 수 있다는 것을 함께 보여 줬습니다.
- 자격증명 게이트는 넣기 전에 고치기 전 트리에서 13곳이 빨개지는 것을 먼저 봤습니다. 이 순서가 맞습니다.
- DNS 정책의 시험은 정책 문자열의 모양만 봤습니다. 그래서 의도와 다르게 동작하는 패턴(
*.cluster.local)이 통과했습니다. 시험은 「이 이름은 통과, 저 이름은 거절」 같은 의미를 단언해야 합니다. - 상표 검사는 지키는 시험이었지만, 숫자 속
729를 상표로 오해했습니다. 지키는 시험에도 「이건 걸리면 안 된다」 예시가 필요합니다.
정리하면, 시험을 넣을 때마다 세 가지를 확인합니다. ① 고치기 전에 빨간가, ② 고친 뒤에 초록인가, ③ 걸리면 안 되는 예시에서 초록인가.
5. 다음 사고 전에 쓸 점검표
- 대상을 고르기 전에 라벨·기본값·와일드카드 규칙을 펼쳐 봤나
- 「된다」를 결과물 쪽(바깥, 클러스터에서 다시 읽은 값, 운영이 내주는 파일)에서 확인했나
- 적용 명령이 읽는 파일이 원격 main 의 것인가,
kubectl diff가 비어 있지 않은가 - 자동 갱신이 켜진 노드에서, 재부팅이 필요한 패키지가 몰래 올라갈 수 있나
- 저장소에 들어간 비밀이 있다면 회전했나(파일에서 지운 것만으로는 아니다)
- 사람에게 넘긴 일에 명령·영향·확인 명령·기한이 붙어 있나
- 새 시험이 고치기 전에 빨갛고, 걸리면 안 되는 예시에서 초록인가
- 같은 실패가 두 번 나면 멈추고 사람에게 보이는가
티티 한마디. 다섯 번 넘어지고 보니 넘어진 자리가 다 비슷했어요. 안 보이는 기본값, 좁게 보는 초록불, 아무도 안 집어 간 일감, 그리고 모양만 보는 시험. 다음엔 점검표부터 펴고 시작해요!
참고
모든 자료는 2026-10-16 에 열람했습니다.
- 이번 주에 보낸 문서 PR·이슈: https://github.com/metallb/metallb/pull/3156, https://github.com/NVIDIA/cloud-native-docs/pull/524, https://github.com/argoproj/argo-cd/issues/30209
- 각 사고의 근거는 이 시리즈의 1~5편 「참고」에 있습니다.