feat(pipeline): keycloak-session-store 25편·virtualization 59편을 S3→S5→S6 으로 돌린다

기록 84편을 계약 에이전트로 다시 썼다. 기존 71편(kss 25 · virt 46)과, 계약에만
있고 안 쓰여 있던 새 글감 13편이다. 원장 84개를 열어 단계마다 스킬 영수증과 관문
종료 코드를 적었고 verify-pipeline-run.py 가 error 0 으로 닫는다.

SSOT 결함 둘을 고쳤다.

- kss 의 `약 58일` 이 반입 중 `약 59일` 로 바뀌어 있었다. 원 증거 파일이
  「남은 일수: 88일 … 실제 갱신까지 약 58일」로 산수를 직접 적는다. D-4a 쪽
  `약 59일` 은 강제 갱신 뒤(`VALID: 89 days`)라 맞는 값이라 그대로 뒀다.
- virt §198 의 `11.6GB` 는 §178 의 원 측정 `Mem: 11648`(MiB)과 어긋나는데
  원 가이드의 표기 그대로라 고치지 않고 쓰이는 자리에 대조를 적었다.

기록의 수치 오류 셋을 고쳤다 — CASE 요약의 「게스트 셋에 8240MB」(5120+3120 은
둘이다), k3s 편이 같은 것을 여섯·일곱·여덟로 세던 것, no-docker 편의 「셋을 더
든다」(§281 의 표는 네 행이고 디스크 행이 빠져 있었다).

계약을 셋 고쳤다.

- kss 의 sourceRepository 리비전이 cdac9b8 이었는데 그 커밋에는 docs/guides/**
  28개가 아예 없다. 9465582b 로 바꾸고, 반입한 바이트가 어느 커밋과도 같지 않다는
  것을 측정값과 함께 적었다 — 반입은 커밋이 아니라 그 시점의 작업 트리에서 떠 온
  것이다(kss 297/306 · virt 12/14 가 작업 트리와 같고, 200 커밋을 거슬러 전수
  대조했을 때 가장 가까운 커밋도 28개가 어긋났다).
- virt 계약이 「2026-09-11 재배분」이라고 적는데 SSOT 는 재배분 날짜를 적지 않고
  재배분 뒤 값은 이미 2026-09-10 측정에 찍혀 있다.
- kss 후보 대장이 지나친 절 아홉에 처분을 적었다(warn 9 → 0). 새 글감은 0건이고
  넷은 앵커가 h3 슬러그의 접두가 아니라 중간 토막이라 검사기가 못 본 것이었다.

style_profile.mjs 의 결함 둘을 고쳤다 — frontmatter 가 문장으로 세어져
(실측 398자짜리 「문장」 하나) 평균 길이를 기준 안으로 밀어 올리고 있었고,
engPerSent 의 분자는 목록을 포함한 글에서, 분모는 목록을 걷어낸 글에서 세고
있었다(Question 기록에서 11.94 → 3.86).

verify-pipeline.py 전 항목 PASS · error 0 · unittest 334건 OK.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/reference/reference-state-the-version-and-the-setting-with-the-result.md

@@ -0,0 +1,84 @@
+---
+kind: REFERENCE
+slug: state-the-version-and-the-setting-with-the-result
+title: 버전과 설정을 결과와 함께 적는다
+topic: session-custody-across-nodes
+topicName: Keycloak 두 노드가 같은 세션을 읽는 경로
+project: keycloak-session-store
+status: 게시 전
+sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
+source:
+  - final/document.md#코드보다-먼저-드러난-문제-버전-조건
+  - final/document.md#얻은-것-잃은-것-적용하지-않을-때-적용되지-않는-조건
+evidence:
+  - ../../../final/evidence/raw/a7-volatile-comparison__01-switch-to-volatile.txt
+  - ../../../final/evidence/raw/a1-jgroups-transport-block__09-cross-node-under-partition.txt
+  - ../../../final/evidence/raw/a7-volatile-comparison__04-a1-rerun-partition.txt
+  - ../../../final/evidence/raw/a8-rolling-restart__02-session-survival.txt
+  - ../../../final/evidence/raw/a7-volatile-comparison__03-a8-rerun-restart.txt
+  - ../../../final/evidence/raw/a2-database-loss__03-four-paths.txt
+  - ../../../final/evidence/raw/a7-volatile-comparison__05-a2-rerun-db-loss.txt
+---
+
+# 버전과 설정을 결과와 함께 적는다
+
+버전과 설정을 빼고 적은 결과는 절반이 틀린 말이 된다. Keycloak 26 의 기본값 하나를 끄자 같은 실험 세 건이 정반대로 뒤집혔다. 이 기준의 근거는 그 사례 하나다.
+
+## 관계
+
+- **persistent-user-sessions 가 세션의 거처를 정한다**
+  이 기준이 나온 대조다. 같은 실험을 두 설정으로 돌린 결과가 거기 있다.
+- **같은 설정이 캐시 온도만으로 세 가지 답을 냈다**
+  설정 이름을 적은 뒤에도 결과가 다시 갈린 사례다.
+
+## 목적
+
+Keycloak 26 은 persistent-user-sessions 가 기본값이라 세션을 DB 에 쓴다. 그래서 한 노드에서 만든 세션을 다른 노드가 쓸 수 있고, 그렇게 되는 이유는 복제가 아니라 두 노드가 같은 데이터베이스를 보기 때문이다. 24 이전은 그렇지 않아서 메모리에 두고 Infinispan 으로 복제했다.
+
+같은 실험을 --features-disabled=persistent-user-sessions 로 다시 돌리자 세 결과가 정반대로 뒤집혔다. 그래서 「Keycloak 은 이렇다」고 쓸 수 있는 문장이 거의 없다.
+
+제품 이름만 달고 나간 결과는 기본값이 바뀌는 순간 반대 사실을 가리킨다. 이 기준은 결과를 적을 때 그 결과가 어느 버전, 어느 설정에서 나온 것인지를 같이 남겨 두려는 것이다.
+
+## 규칙
+
+### 1. 결과 옆에 제품 버전과 그 결과를 가른 설정 이름을 적는다
+
+Keycloak 26 에서 잰 A층 결론 가운데 셋은 persistent-user-sessions 가 기본이 아닌 환경에서 뒤집힌다. 버전과 설정 이름이 붙어 있지 않으면 그 셋은 제품의 성질처럼 읽힌다.
+
+### 2. 기본값이 바뀌었으면 옛 기본값으로 같은 실험을 다시 돌린다
+
+A-7 과 A-7a 가 그 대조군이다. 26.7.0 에서 옛 기본값을 플래그로 끄고 A층을 다시 돌렸고, A-1 · A-8 · A-2 세 건이 반대 결과를 냈다.
+
+### 3. 재현한 동작을 그 버전에서 잰 값으로 적지 않는다
+
+이 실험대는 Keycloak 24 를 설치해 보지 않았다. 26.7.0 위에서 persistent-user-sessions 기능을 꺼서 24 이전의 기본값 동작을 재현했다. 그래서 volatile 쪽 수치는 24 이전의 기본값과 같은 설정에서 잰 값이고, 24 에서 잰 값이 아니다.
+
+### 4. 뒤집힌 방향을 실험마다 적는다
+
+A-1 의 교차 노드 refresh 와 A-8 의 롤링 재시작 뒤 refresh 는 persistent 에서 200, volatile 에서 400 Session not active 였다. A-2 의 DB 정지 중 새 로그인은 persistent 에서 500, volatile 에서 200 이었다. 세 건의 방향이 같지 않다.
+
+### 5. 같은 설정 안에서 결과가 다시 갈리는지 확인한다
+
+volatile 에서 DB 를 세웠을 때의 동작은 캐시 온도로 갈린다. 설정 이름까지 적고 나서도 그 결과에 걸리는 조건이 더 있는지 본다. 이 규칙은 A-7 이 그 두 값을 한 번 재고 표로 옮겼기 때문에 생겼다. A-7a 가 같은 설정을 캐시 온도 셋으로 갈라 재 보니 A-7 이 적은 것은 그 셋 중 하나였다.
+
+## 적용 조건
+
+- 메이저 버전 사이에 기본값이 바뀐 제품의 동작을 적을 때
+- 장애를 주입해 얻은 결과를 문서로 남길 때
+- 옛 기본값을 쓰는 환경과 새 기본값을 쓰는 환경을 함께 다룰 때
+- 근거의 범위 : 이 기준은 Keycloak 26 의 persistent-user-sessions 사례 하나에서 나왔다. 실험은 A-1 · A-2 · A-8 세 건이 전부다
+
+## 예외
+
+- 측정 대상이 그 설정에 걸리지 않는 경로라면 조건을 달지 않아도 된다. 무엇이 걸리는지를 먼저 확인한다
+- 다른 제품의 기본값 변경에서도 같은 일이 나는지는 이 프로젝트가 재지 않았다. 이 기록을 그 근거로 쓰지 않는다
+- 이 기준이 말하는 것은 무엇을 적는가이지 어느 설정이 나은가가 아니다. 두 설정의 우열은 여기서 재지 않았다
+
+## 예시
+
+- A-1 · 7800 차단 후 교차 노드 refresh : persistent(26 기본) 200 · volatile(24 이전) 400 Session not active
+- A-8 · 롤링 재시작 후 refresh : persistent 200 · volatile 400 Session not active
+- A-2 · DB 정지 중 새 로그인 : persistent 500 · volatile 200
+- 쓰지 않는다 : Keycloak 은 다중 노드에서 세션을 공유한다
+- 쓴다 : Keycloak 26 은 persistent-user-sessions 가 기본이라 두 노드가 같은 데이터베이스를 읽고 같은 세션을 본다
+- 쓴다 : 위 결과는 26.7.0 에서 그 기능을 꺼서 재현한 것이고 24 에서 잰 값이 아니다