diff --git a/history/2026-06-01-longhorn-snapshot-retention-fix.md b/history/2026-06-01-longhorn-snapshot-retention-fix.md
index ef258e4..b5a5bb9 100644
--- a/history/2026-06-01-longhorn-snapshot-retention-fix.md
+++ b/history/2026-06-01-longhorn-snapshot-retention-fix.md
@@ -111,6 +111,8 @@ kubectl -n longhorn-system get snapshots.longhorn.io --sort-by=.metadata.creatio
 
 ## 잔여 사항 / 후속
 
+> **[2026-07-11 재발 확인]** 이 "영구 수정"의 검증 단계가 실제로 이뤄지지 않은 채 방치됐었고, 2026-07-11 재확인 결과 `spec.labels` patch는 살아있으나 신규 스냅샷에 라벨이 여전히 안 붙어 retention이 계속 작동 안 하고 있었음(outline-data 볼륨이 250 하드캡 초과로 발견). 상세: [[../history/2026-07-11-outline-data-snapshot-cap-exceeded|2026-07-11 history]]
+
 - RecurringJob 4개 spec.labels 수동 patch만 적용. **ArgoCD/IaC 매니페스트에도 같은 변경 반영 필요** (다음 sync에서 빈 spec.labels로 되돌아갈 위험)
 - snapshot `.checksum` 파일 누락 패턴은 Longhorn 알려진 이슈일 가능성 — GitHub issue 검색 후 v1.11.3+ 업그레이드 시 해소되는지 확인 필요
 - 같은 corruption loop가 다른 volume에서 재발 시 동일 절차 (anti-affinity 활용한 노드 회피 rebuild) 적용 가능
diff --git a/history/2026-07-11-outline-data-snapshot-cap-exceeded.md b/history/2026-07-11-outline-data-snapshot-cap-exceeded.md
index c6e180e..aa7aead 100644
--- a/history/2026-07-11-outline-data-snapshot-cap-exceeded.md
+++ b/history/2026-07-11-outline-data-snapshot-cap-exceeded.md
@@ -85,13 +85,31 @@ curl -s -X POST -H "Content-Type: application/json" -d '{}' \
 
 **교훈**: 이 볼륨의 문제는 kubectl CR delete로는 못 풀리고(webhook이 finalizer 유지) engine 재시작(파드 재배포/재attach)으로도 안 풀렸다 — **오직 Longhorn 자체 `snapshotPurge` API를 반복 호출해야만 체인이 실제로 정리**됐다. 1회 호출은 충분하지 않고, 남은 개수가 줄어드는 걸 보면서 **여러 번 반복 호출**해야 완전히 정리됨(한 번에 전부 처리되는 게 아니라 매 호출마다 일부 chain만 병합·정리하는 것으로 보임).
 
-## 후속 필요 (근본 원인은 여전히 미확정)
+### 7. 근본 원인 재구성: [[2026-06-01-longhorn-snapshot-retention-fix|2026-06-01 수정]]이 사실상 작동한 적이 없었음
 
-- **당장의 하드캡 문제는 해소됨** (58개, 여유 충분). critical-snapshot/critical-backup 재개 여부는 다음 스케줄(정각/6시간 단위)에 확인 필요
-- **근본 원인은 여전히 미확정**: 애초에 이 볼륨만 왜 retain 정책이 안 먹혀 256개까지 쌓였는지는 안 풀림. 재발 시 아래 순서로 대응:
-  1. 먼저 이번에 검증된 `snapshotPurge` API 반복 호출 (가장 빠르고 효과 확인됨) — port-forward + curl 반복, 수 분 내 해결
-  2. 재발 빈도가 잦으면 [[2026-05-02-longhorn-snapshot-purge-cron|보존된 longhorn-snapshot-purge 차트]]를 outline-data 대상으로 상시 cron화하는 것도 고려 (현재는 1회성 수동 대응으로 충분)
-  3. Longhorn upstream에 v1.11.2에서의 신규 케이스로 문의/이슈 등록 검토 (근본 원인 규명 목적, 급하지 않음)
+이 사건 도중 기존 이력 [[2026-06-01-longhorn-snapshot-retention-fix|2026-06-01-longhorn-snapshot-retention-fix]]를 재확인. 그 문서의 핵심: 당시 전체 906개 스냅샷이 `recurring-job.longhorn.io/<job>` 라벨 100% 누락 상태였고(각 RecurringJob의 `spec.labels`가 `{}`라서 retention이 자기 소속 스냅샷을 식별 못함), 4개 RecurringJob(`critical-snapshot`/`critical-backup`/`standard-snapshot`/`standard-backup`)에 `spec.labels`를 수동 patch해서 "다음 cron 실행부터 라벨 붙어 정상화될 것"이라 결론지었음. 단, 그 문서의 "검증" 섹션은 **"(예정)"으로 끝나 실제 확인이 안 된 채 방치**되어 있었음.
+
+오늘(2026-07-11) 직접 재검증한 결과:
+
+```bash
+kubectl get recurringjobs.longhorn.io -n longhorn-system critical-snapshot -o jsonpath='{.spec.labels}'
+# → {"recurring-job.longhorn.io/critical-snapshot":"enabled"}  (patch는 그대로 살아있음, ArgoCD에 되돌려지지 않음)
+```
+
+그런데 **가장 최근 생성된 스냅샷들(오늘 새벽 03시대, 다른 여러 볼륨)조차 `recurring-job.longhorn.io/*` 라벨이 전혀 붙어있지 않음** — `longhornvolume` 라벨만 존재. 즉 `spec.labels` 설정은 살아있는데 실제 라벨 부착 메커니즘이 **지금도 작동하지 않고 있음**. 2026-06-01의 "영구 수정"은 patch 자체는 유지됐지만 **한 번도 실제로 의도대로 동작한 적이 없었던 것**으로 재확인됨 (또는 이후 알 수 없는 이유로 재차 깨짐 — 어느 쪽이든 결과는 동일).
+
+**중요한 함의**: 라벨 기반 retention이 클러스터의 **모든 볼륨에서 지금도 동작 안 함**. outline-data(256)와 다른 볼륨들(8~55)의 극심한 개수 차이는 retention 여부 차이가 아니라 — **볼륨별 실제 쓰기 빈도 차이**로 보임 (Outline 위키는 상시 활발히 쓰기 발생 → 매 스케줄마다 실질적으로 새 스냅샷이 계속 쌓임 vs 조용한 볼륨은 변경 없으면 스냅샷 생성 자체가 적어 우연히 250 근처에 못 감). 즉 **outline-data는 "첫 번째로 한도에 도달한 사례일 뿐, 나머지 볼륨들도 시간 문제**"일 가능성이 높음.
+
+## 후속 필요 (근본 원인 재조사 필요 — 재발/타 볼륨 위험 있음)
+
+- **당장의 하드캡 문제는 해소됨** (58개, 여유 충분)
+- **진짜 근본 원인**: `spec.labels`는 올바르게 설정돼 있는데도 실제 스냅샷에 `recurring-job.longhorn.io/*` 라벨이 안 붙는 메커니즘 자체의 결함 — Longhorn v1.11.2의 알려지지 않은 버그이거나, RecurringJob 오브젝트를 patch가 아니라 재생성해야 반영되는 구조일 가능성. **미해결**
+- **위험 범위 재평가 필요**: 라벨/retention 결함이 전 볼륨 공통이므로, 쓰기 빈도가 높은 다른 볼륨(gitea, postgres 등)도 시간이 지나면 같은 250 하드캡에 부딪힐 수 있음 — outline-data 국한 문제가 아님
+- 우선순위 제안:
+  1. **Longhorn `recurring-job.longhorn.io/*` 라벨이 왜 안 붙는지 직접 조사** (instance-manager/longhorn-manager 로그, RecurringJob 재생성 필요 여부 확인) — 이번 사건의 진짜 근본 수정
+  2. 원인 규명 전까지는 주기적으로(예: 주 1회) 전체 볼륨 스냅샷 개수 점검해 250 근접 볼륨 조기 발견 (`kubectl get snapshots.longhorn.io -A -o json | jq` 로 볼륨별 카운트)
+  3. 재발 시 이번에 검증된 `snapshotPurge` API 반복 호출로 즉시 완화 가능 (수 분 내 해결, 재현성 확인됨)
+  4. Longhorn upstream에 "`spec.labels` 설정에도 불구하고 스냅샷에 라벨 미부착" 으로 신규 이슈 등록 검토
 
 ## 관련 문서
 
diff --git a/infra/platform/longhorn.md b/infra/platform/longhorn.md
index 009d872..f43e6a8 100644
--- a/infra/platform/longhorn.md
+++ b/infra/platform/longhorn.md
@@ -104,9 +104,13 @@ kubectl get snapshots.longhorn.io -A -o json | jq '[.items[] | select(.status.ma
 
 상세 도입 기록: [[../../history/2026-05-02-longhorn-snapshot-purge-cron|2026-05-02 도입]] / [[../../history/2026-05-07-longhorn-1-11-2-upgrade|2026-05-07 fix 적용]] / [[../../history/2026-05-09-longhorn-snapshot-purge-cron-removal|2026-05-09 회수]]
 
+## ⚠️ snapshot retention 라벨 결함 — 전 볼륨 공통, 미해결 (2026-07-11 재확인)
+
+[[../../history/2026-06-01-longhorn-snapshot-retention-fix|2026-06-01]]에 RecurringJob `spec.labels` patch로 "영구 수정"했다고 기록했으나, 그 문서의 검증 단계는 "(예정)"으로 남아 실제 확인이 안 됐음. **2026-07-11 재확인 결과 patch(`spec.labels`)는 그대로 살아있는데도 신규 생성되는 스냅샷에 `recurring-job.longhorn.io/*` 라벨이 여전히 하나도 안 붙음** — retention이 자기 소속 스냅샷을 식별 못해 **전 볼륨에서 자동 정리가 사실상 계속 작동 안 하는 중**. 볼륨별 개수 차이(8~256)는 retention 여부가 아니라 볼륨별 쓰기 빈도 차이로 추정 — **쓰기 빈도가 높은 다른 볼륨도 시간이 지나면 250 하드캡에 부딪힐 위험 있음**. 근본 원인(라벨 부착 메커니즘 자체의 결함) 미해결 — 원인 조사 필요. 상세: [[../../history/2026-07-11-outline-data-snapshot-cap-exceeded|2026-07-11 history]]
+
 ## 볼륨별 snapshot count 하드리밋(250) 초과 시 대응 (2026-07-11 사례)
 
-`outline-data` (`pvc-c4bb2746-...`) 볼륨이 스냅샷 256개까지 쌓여 볼륨당 하드캡 250을 초과, `critical-snapshot`/`critical-backup` 신규 생성 실패한 사례 발생. 근본 원인(왜 이 볼륨만 retain 정책이 안 먹혔는지)은 미확정이나, **`kubectl delete`(admission webhook이 finalizer 재부착해 무효) 와 파드/노드 재attach(효과 없음) 둘 다 실패**하고, **Longhorn REST API `snapshotPurge` 액션을 반복 호출**해서만 정상화(256→58) 성공:
+`outline-data` (`pvc-c4bb2746-...`) 볼륨이 위 결함으로 스냅샷 256개까지 쌓여 볼륨당 하드캡 250을 초과, `critical-snapshot`/`critical-backup` 신규 생성 실패한 사례 발생. **`kubectl delete`(admission webhook이 finalizer 재부착해 무효) 와 파드/노드 재attach(효과 없음) 둘 다 실패**하고, **Longhorn REST API `snapshotPurge` 액션을 반복 호출**해서만 정상화(256→58) 성공:
 
 ```bash
 kubectl port-forward -n longhorn-system svc/longhorn-frontend 19500:80 &