diff --git a/.agents/skills/publishing-tech-log-to-studio/SKILL.md b/.agents/skills/publishing-tech-log-to-studio/SKILL.md
index ca3e86b..9228bca 100644
--- a/.agents/skills/publishing-tech-log-to-studio/SKILL.md
+++ b/.agents/skills/publishing-tech-log-to-studio/SKILL.md
@@ -61,11 +61,18 @@ aside[class*="studio-document-status"]   ← 이것이 안 보이면 인증 실
 ### 1. 기록을 읽고 무엇을 넣을지 정한다
 
 `kind` 로 칸 목록이 정해진다. 어떤 `##` 제목이 Studio 의 어느 칸인지는
-[references/studio-form-map.md](references/studio-form-map.md).
+[references/studio-form-map.md](references/studio-form-map.md), 그 칸이 서버에서 어떤 이름과
+자료형인지는 [references/studio-api.md](references/studio-api.md).
 
 **frontmatter 는 메타데이터고, 본문의 `##` 가 Studio 의 칸이며, 제목 아래 첫 문단이 `요약`
 이다.** 계약에 없는 `##` 는 화면에 자리가 없어 통째로 사라진다.
 
+**본문은 이제 화면으로 넣지 않는다.** 편집 화면의 본문이 블록 편집기로 바뀌어 블록 하나가
+`<textarea>` 하나다 — 기록 한 편이 블록 171개인 것을 실제로 봤다. 그런데 저장이 서버로 보내는
+것은 여전히 `bodyMarkdown` 이라는 마크다운 문자열 하나다. 그래서 **옮기는 일은 화면이 아니라
+`PUT /api/v1/studio/documents/{id}` 로 한다** — 로그인된 그 페이지 안에서 `fetch` 로 부르므로
+세션과 CSRF 가 그대로 실린다. 화면은 읽고 대조하는 데 쓴다.
+
 ### 2. 그림이 있으면 Asset 을 먼저 올린다
 
 frontmatter `assets:` 의 `file:` 이 올릴 파일이고 `key:` 는 저장소 쪽 이름이다. 올리면 서버가
@@ -101,6 +108,12 @@ python3 scripts/studio-body.py <기록.md> --key <저장소 key>=<서버가 준
 
 ### 4. 저장한다
 
+API 로 넣었으면 `PUT` 이 200 을 내는 것이 저장이다. **`expectedVersion` 은 저장 직전에 `GET`
+으로 읽은 `document.version` 이다** — 지어내지 않는다. 보내지 않은 칸은 비워지므로 그 종류의
+칸을 전부 담는다.
+
+화면으로 고쳤으면 버튼을 누른다.
+
 ```
 aside[class*="studio-document-status"] 안의 `저장` 버튼
 → 같은 aside 의 글자가 `저장됨` 으로 바뀔 때까지 기다린다 (최대 30초)
@@ -141,12 +154,12 @@ python3 scripts/verify-tech-log-tree.py <프로젝트>
 
 | 종류 | 경로 | 본문 |
 |---|---|---|
-| Case | `DELETE /v1/studio/cases/{id}` (`:72`) | `{"expectedVersion": <저장 버전>}` |
-| Reference | `DELETE /v1/studio/references/{id}` (`:81`) | `{"expectedVersion": <저장 버전>}` |
-| Concept | `DELETE /v1/studio/concepts/{id}` (`:95`) | `{"expectedVersion": <저장 버전>}` |
+| Case | `DELETE /api/v1/studio/cases/{id}` (`:72`) | `{"expectedVersion": <저장 버전>}` |
+| Reference | `DELETE /api/v1/studio/references/{id}` (`:81`) | `{"expectedVersion": <저장 버전>}` |
+| Concept | `DELETE /api/v1/studio/concepts/{id}` (`:95`) | `{"expectedVersion": <저장 버전>}` |
 | Setup | `DELETE /api/v1/studio/setups/{id}` | `{"expectedVersion": <저장 버전>}` |
-| Question | `DELETE /v1/studio/questions/{id}` (`:114`) | `{"expectedVersion": <저장 버전>}` |
-| Decision | `DELETE /v1/studio/projects/{id}/decisions/{decisionId}` (`:123`) | `{"expectedVersion": <저장 버전>}` |
+| Question | `DELETE /api/v1/studio/questions/{id}` (`:114`) | `{"expectedVersion": <저장 버전>}` |
+| Decision | `DELETE /api/v1/studio/projects/{id}/decisions/{decisionId}` (`:123`) | `{"expectedVersion": <저장 버전>}` |
 
 **본문 없이 부르면 204 가 아니라 422 다.** `ExpectedVersionRequest` 가 없으면
 `REQUEST_VALIDATION_FAILED` / `Request body is malformed` 로 거절된다. 헤더에는
diff --git a/.agents/skills/publishing-tech-log-to-studio/references/playwright-recipes.md b/.agents/skills/publishing-tech-log-to-studio/references/playwright-recipes.md
index 2b4fcd5..90f950f 100644
--- a/.agents/skills/publishing-tech-log-to-studio/references/playwright-recipes.md
+++ b/.agents/skills/publishing-tech-log-to-studio/references/playwright-recipes.md
@@ -114,31 +114,49 @@ while (cur < want) {                       // 모자라면 더한다
 const labels = await fs.locator('label span').allInnerTexts();
 ```
 
-## 칸 DOM 이 두 가지다
+## 칸은 `aria-label` 로 찾는다 (2026-09-17 에 다시 잼)
 
-위 xpath 는 절반만 통한다. 실제 편집 화면에는 모양이 둘이다.
-
-```html
-<label class="studio-field"><span>문제</span><textarea></textarea></label>       <!-- A -->
-<div class="studio-field"><label for="studio-field-summary">요약</label>
-     <textarea id="studio-field-summary"></textarea></div>                        <!-- B -->
-```
-
-`요약` · `본문 Markdown` · `관계 N 이유` 가 B형이다. A형만 찾으면 이 칸들이 조용히 안 채워진다.
-**둘 다 본다.**
+**위의 `label` 두 모양 이야기는 낡았다.** 지금 `label.studio-field` 가 감싸는 것은 제목과 요약
+둘뿐이고, 나머지 칸은 전부 `aria-label` 을 갖는다. xpath 로 `span` 을 뒤질 일이 없다.
 
 ```js
-async function field(page, name) {
-  const a = page.locator(`xpath=//label[./span[normalize-space(.)="${name}"]]`)
-                .locator('textarea, input').first();
-  if (await a.count()) return a;
-  const id = await page.locator(`xpath=//label[normalize-space(.)="${name}"]`)
-                       .first().getAttribute('for');
-  return id ? page.locator('#' + id) : null;
-}
+document.querySelector('input[aria-label="제목"]')
+document.querySelector('textarea[aria-label="요약"]')
+document.querySelector('input[aria-label="slug"]')
+document.querySelector('input[aria-label="판단 기준 1 제목"]')
+document.querySelector('textarea[aria-label="적용할 때 3"]')
 ```
 
-**본문 칸의 이름은 `본문` 이 아니라 `본문 Markdown` 이다.**
+되풀이 칸을 늘리는 버튼은 `+ 판단 기준` · `+ 적용할 때` · `+ 예외와 주의` · `+ 예시` ·
+`+ 버전 추가` 다. 줄 수를 먼저 맞추고 값을 넣는 규칙은 그대로다.
+
+## 본문 칸이 사라졌다 — 블록 편집기다
+
+**`본문 Markdown` 이라는 textarea 는 더 없다.** 본문은 `.studio-block-editor` 이고 블록 하나가
+`<textarea>` 하나다. 기록 한 편이 블록 171개인 것을 실제로 봤다.
+
+```
+.studio-block-editor
+├ textarea.studio-markdown-source     본문 전체의 거울. display:none · aria-hidden · readonly
+├ .studio-block-editor__blocks
+│  └ .studio-authoring-block[data-kind]   heading · paragraph · code · bullet · raw
+└ button  + 블록 추가
+```
+
+**코드 블록의 `input.studio-code-language` 에 울타리 뒤 정보 문자열 전체가 들어간다** —
+`bash label="[kc-lab-1] ① 기동 로그에서 쿠키 설정을 찾는다"` 가 그 입력의 값이었다. 라벨을
+넣을 별도 칸은 없다.
+
+합성한 `ClipboardEvent` 로 붙여넣는 것은 **안 먹는다.** 그래서 쓰인 기록을 화면으로 옮기지
+않는다 — [studio-api.md](studio-api.md) 의 `PUT` 으로 `bodyMarkdown` 을 통째로 보낸다.
+`.studio-markdown-source` 는 `readonly` 라 입력 자리가 아니지만, 화면이 지금 무엇을 직렬화할지를
+그대로 보여 주므로 **저장 전에 눈으로 대조하기에 좋다.**
+
+## 저장 다음은 게시가 아니라 검증이다
+
+편집 화면의 `aside` 에는 `저장` 과 `게시` 둘뿐인데, 저장만 된 기록은 서버가 `nextAction` 을
+**`VALIDATE`** 로 준다. 검증 화면은 `/studio/documents/{id}/validation` 이다. 이 스킬은 저장까지라
+거기까지 가지 않는다 — 다만 「저장했는데 왜 게시가 안 되나」의 답이 이것이다.
 
 ## Asset 을 올릴 때
 
diff --git a/.agents/skills/publishing-tech-log-to-studio/references/studio-api.md b/.agents/skills/publishing-tech-log-to-studio/references/studio-api.md
new file mode 100644
index 0000000..d4b59e9
--- /dev/null
+++ b/.agents/skills/publishing-tech-log-to-studio/references/studio-api.md
@@ -0,0 +1,175 @@
+# Studio 가 실제로 주고받는 것
+
+여기 적은 것은 **2026-09-17 에 로그인한 브라우저에서 직접 불러 확인한 것**이다. 문서를 보고
+적은 것이 아니라 요청을 보내고 돌아온 것을 옮겼다. 확인한 판이 바뀌면 이 파일도 낡는다.
+
+## 왜 이 파일이 필요해졌나
+
+**편집 화면의 본문이 블록 편집기로 바뀌었다.** 전에는 본문이 `본문 Markdown` 이라는 textarea
+하나였고 거기에 통째로 붙여넣으면 됐다. 지금은 블록 하나가 `<textarea>` 하나다 — 기록 한 편이
+블록 171개인 것을 실제로 봤다. 화면으로 그것을 채우는 것은 사람이 한 편을 쓸 때의 방식이지
+쓰인 기록을 옮기는 방식이 아니다.
+
+그런데 **저장이 서버로 보내는 것은 블록이 아니라 마크다운 문자열 하나**다. 화면은 그 문자열
+위의 편집기이고, 저장 요청은 `bodyMarkdown` 한 칸을 보낸다. 그래서 옮기는 일은 화면이 아니라
+이 API 로 한다.
+
+## 인증
+
+**자격증명을 이 저장소에 두지 않는다.** 이미 로그인된 브라우저 세션을 쓰고, 요청은 그 페이지
+안에서(`fetch`) 보낸다. 쿠키가 그대로 실린다.
+
+CSRF 토큰은 `XSRF-TOKEN` 쿠키에 있고 `x-csrf-token` 헤더로 되돌려 준다.
+
+```js
+document.cookie.match(/(?:^|;\s*)XSRF-TOKEN=([^;]+)/)?.[1]
+```
+
+로그인이 안 돼 있으면 `/studio` 가 「기록을 쓰려면 로그인이 필요합니다」를 낸다.
+**로그인 화면을 자동으로 통과하려 들지 않는다** — 사람에게 로그인해 달라고 말하고 멈춘다.
+
+## 응답 껍데기
+
+성공이든 실패든 같은 모양이다.
+
+```json
+{ "success": true, "data": { … }, "error": null,
+  "meta": { "requestId": "…", "traceId": "…", "correlationId": "…", "page": null } }
+```
+
+실패하면 `data` 가 `null` 이고 `error` 에 `{code, category, message, retryable, details}` 가 온다.
+`details.supportedMethods` 처럼 고칠 방법을 담아 주는 경우가 있다.
+
+## 경로
+
+| 무엇 | 요청 |
+|---|---|
+| 목록 | `GET /api/v1/studio/documents?limit=100` |
+| 한 편 | `GET /api/v1/studio/documents/{id}` |
+| 새로 만들기 | `POST /api/v1/studio/documents` → 201 |
+| **저장** | `PUT /api/v1/studio/documents/{id}` → 200 |
+| 지우기 | `DELETE /api/v1/studio/{종류}/{id}` → 204 |
+
+**`limit` 은 100 이 상한이다.** 200 을 주면 422 `REQUEST_VALIDATION_FAILED` 다. 더 받으려면
+`data.nextCursor` 를 `cursor` 로 넘긴다.
+
+**`/documents/{id}` 는 `PUT` 과 `GET` 만 받는다.** 거기에 `DELETE` 를 보내면 405 이고
+`details.supportedMethods` 가 `["PUT","GET"]` 을 준다. 삭제는 종류별 경로다 —
+`cases` · `references` · `concepts` · `setups` · `questions`, 그리고 Decision 은
+`projects/{projectId}/decisions/{decisionId}`.
+
+## 한 편 읽기
+
+```
+GET /api/v1/studio/documents/{id}
+→ data: { document, currentValidation, latestPreview, currentPublication,
+          dependencyRevision, nextAction }
+```
+
+`nextAction` 이 다음에 할 일을 말한다 — 저장만 된 기록은 `VALIDATE` 다. 검증 화면은
+`/studio/documents/{id}/validation` 이고 편집 화면의 `aside` 에는 **`저장` 과 `게시` 둘뿐**이라
+검증은 그 화면에서 따로 한다.
+
+## 저장
+
+```
+PUT /api/v1/studio/documents/{id}
+headers: content-type: application/json
+         accept: application/json
+         x-csrf-token: <XSRF-TOKEN 쿠키>
+         idempotency-key: <요청마다 새로>
+body:    { "expectedVersion": <읽어 온 document.version>, "document": { … } }
+```
+
+**`expectedVersion` 은 방금 읽은 `document.version` 이다.** 저장이 끝나면 1 올라간다. 지어내지
+말고 저장 직전에 `GET` 으로 읽는다.
+
+`document` 는 **그 종류의 칸을 전부** 담는다. 빠뜨린 칸은 비는 것으로 저장된다 — 부분 갱신이
+아니다.
+
+## 종류마다의 칸
+
+여섯이 함께 갖는 것: `kind` · `title` · `slug` · `summary` · `relations` · `projectId` ·
+`topicId` · `variantIds`. 서버가 주지만 보내지 않는 것: `id` · `version` · `updatedAt`.
+
+| kind | 그 종류만의 칸 |
+|---|---|
+| `CASE` | `problem` · `conclusion` · `environment` · `reproduction` · `bodyMarkdown` · `lastVerifiedOn` |
+| `CONCEPT` | `bodyMarkdown` · `basisVersion` |
+| `SETUP` | `bodyMarkdown` · `pinnedVersions` |
+| `REFERENCE` | `purpose` · `rules` · `applyWhen` · `exceptions` · `examples` · `verifiedOn` |
+| `QUESTION` | `facts` · `assumptions` · `unknowns` · `constraints` · `options` · `nextValidation` · `resolution` · `questionStatus` |
+
+되풀이되는 칸의 모양이다. `id` 는 서버가 붙이므로 새로 넣을 때는 빼고 `order` 만 0 부터 센다.
+
+| 칸 | 항목 |
+|---|---|
+| `relations` | `{ targetId, reason, order }` |
+| `facts` · `assumptions` · `unknowns` · `constraints` · `applyWhen` · `exceptions` · `examples` | `{ text, order }` |
+| `options` | `{ title, description, order }` |
+| `rules` | `{ title, body, order }` — **제목과 본문이 따로다** |
+| `pinnedVersions` | `{ name, version }` — `order` 가 없다 |
+
+## `bodyMarkdown` 은 바이트 그대로 돌아온다
+
+넣은 것과 읽어 온 것이 같은지 확인했다. **코드 울타리의 정보 문자열이 그대로 살아남는다.**
+
+```
+```bash label="[host] ① 친다"
+```
+
+넣고 다시 읽었을 때 `label="…"` 까지 한 글자도 안 바뀌었다. 그래서 `studio-body.py` 가 만든
+본문을 그대로 실어 보내면 된다.
+
+## 화면에서 블록이 어떻게 생겼나
+
+옮기는 일은 API 로 하지만, 사람이 화면을 읽을 때와 무엇이 어긋났는지 볼 때 필요하다.
+
+```
+.studio-block-editor
+├ textarea.studio-markdown-source     본문 전체의 거울. display:none · aria-hidden · readonly
+├ .studio-block-editor__blocks
+│  └ .studio-authoring-block[data-kind]   블록 하나
+└ button  + 블록 추가
+```
+
+`data-kind` 는 `heading` · `paragraph` · `code` · `bullet` · `raw` 다. `raw`(화면 이름
+**고급 블록**)가 표처럼 블록으로 안 갈리는 것을 그대로 담는다.
+
+**코드 블록의 `input.studio-code-language` 는 언어 이름만 담지 않는다.** 울타리 뒤의 정보
+문자열 **전체**가 거기 들어간다 — `bash label="[kc-lab-1] ① 기동 로그에서 쿠키 설정을 찾는다"`
+가 그 입력의 값이었다. 라벨을 넣을 별도 칸은 없다.
+
+**`.studio-markdown-source` 는 읽는 데만 쓴다.** `readonly` 이고 `display:none` 이라 입력
+자리가 아니다. 다만 화면이 지금 무엇을 직렬화할지를 그대로 보여 주므로, 저장 전에 눈으로
+대조하기에 좋다.
+
+합성한 `ClipboardEvent` 로 붙여넣는 것은 **안 먹는다.** 화면으로 본문을 채우려면 블록을 하나씩
+만들어야 한다.
+
+## 화면의 칸 셀렉터
+
+칸은 이제 `aria-label` 로 찾는다. `label.studio-field` 는 제목과 요약 둘만 감싼다.
+
+```js
+document.querySelector('input[aria-label="제목"]')
+document.querySelector('textarea[aria-label="요약"]')
+document.querySelector('input[aria-label="slug"]')
+document.querySelector('input[aria-label="판단 기준 1 제목"]')
+document.querySelector('textarea[aria-label="적용할 때 3"]')
+```
+
+되풀이 칸을 늘리는 버튼은 `+ 판단 기준` · `+ 적용할 때` · `+ 예외와 주의` · `+ 예시` ·
+`+ 버전 추가` 다.
+
+상태 레일은 그대로다 — `aside[class*="studio-document-status"]`(실제 class 는
+`studio-document-status-bar`). 그 안에 **`저장` 과 `게시` 둘뿐**이고, 저장된 상태에서는
+`저장` 이 `disabled` 이며 글자가 `저장됨` 이다.
+
+## 하지 않는 것
+
+- **게시하지 않는다.** 이 스킬은 저장까지다. 한 번이라도 게시한 문서는 게시를 취소해도 삭제가
+  409 로 거절된다
+- **`expectedVersion` 을 지어내지 않는다.** 저장 직전에 읽는다
+- **부분 갱신이라고 생각하지 않는다.** 보내지 않은 칸은 비워진다
+- **로그인 화면을 자동으로 넘기지 않는다**
diff --git a/.agents/skills/publishing-tech-log-to-studio/references/studio-form-map.md b/.agents/skills/publishing-tech-log-to-studio/references/studio-form-map.md
index e2f9b9d..03e611f 100644
--- a/.agents/skills/publishing-tech-log-to-studio/references/studio-form-map.md
+++ b/.agents/skills/publishing-tech-log-to-studio/references/studio-form-map.md
@@ -100,8 +100,20 @@ Decision 의 도메인 `ACCEPTED` 가 화면에서는 `ADOPTED` 로 보인다. 
 
 `Reference`·`Question`·`Decision` 의 칸은 **평문으로 렌더링된다.**
 
-- 백틱과 파이프가 글자 그대로 보인다. 코드·표를 넣지 않는다
-- 줄바꿈은 `<br>` 로만 살아난다
+**「평문」이 「전부 글자 그대로」라는 뜻은 아니다.** 렌더러
+(`tech-log-frontend` 의 `presentation/shared/public-render/prose-text.tsx`)가 셋을 해석한다.
+
+| 무엇 | 평문 칸에서 |
+|---|---|
+| 백틱 쌍 | **인라인 `<code>` 로 산다.** 빼지 않는다 — 빼면 식별자가 민무늬로 나온다 |
+| 빈 줄 | 문단이 갈린다 |
+| 한 줄 바꿈 | `<br>` |
+| 별표 · 파이프 · `#` · 코드펜스 · 인용 표지 `>` | **글자 그대로 나온다.** 넣지 않는다 |
+
+**전에 이 자리에 「백틱과 파이프가 글자 그대로 보인다」고 적혀 있었고 백틱 쪽은 틀렸다.**
+백틱이 글자로 나오던 것은 고쳐진 옛 버그이고 그 파일 주석에 그렇게 적혀 있다. 칸이 어떻게
+보이는지는 **렌더러가 정본이다** — 이 문서가 아니다.
+
 - 나열은 쉼표로 잇지 말고 `이름 : 값` 으로 줄을 나눈다
 
 코드·표·그림이 필요하면 짝이 되는 Case·Concept·Setup 에 담고 `관계` 로 가리킨다.
diff --git a/.agents/skills/writing-practitioner-guides/SKILL.md b/.agents/skills/writing-practitioner-guides/SKILL.md
index 5eaf86f..4a5eb30 100644
--- a/.agents/skills/writing-practitioner-guides/SKILL.md
+++ b/.agents/skills/writing-practitioner-guides/SKILL.md
@@ -367,6 +367,163 @@ Not `${NAME}` — guides use `$TOKEN`, `$SID` and friends as real shell
 variables, and a reader who reads a placeholder as one will paste it unchanged.
 `{{ }}` is not shell syntax, so pasting it fails where the reader can see it.
 
+## The reader cannot see what is not on screen
+
+Everything below came out of reading 35 finished guides in one pass. Each rule
+names the accident that produced it. None of them is a style preference — in
+every case the guide passed every other rule in this file and still handed the
+reader a wrong answer that looked right.
+
+### A value copied into a container is a snapshot, not a reference
+
+`kubectl run --env="K0=$K0"`, `docker run -e`, cloud-init user-data: each bakes
+the string as it was at that moment. From then on two spellings mean different
+things, and they differ by two characters:
+
+```bash
+exec pod -- sh -c '...$K0...'          # the value baked into the pod
+exec pod -- sh -c '...'"$K0"'...'      # the value in the shell typing this
+```
+
+**They agree until something restarts.** In one guide a `rollout restart` changed
+the pod IP, and a later step still read the baked copy; the request went to an
+address that no longer existed, and the failure it produced was a `500` — which
+was also that step's expected result. The screen looked correct.
+
+So: when a step replaces the thing a baked value points at — a pod IP, a node
+address, a lease — say in that step which spelling the next commands use.
+Prefer recreating the container. If state inside it forbids that, show the
+live-read form and add one line saying why it differs from the block above.
+
+**Distance is not the test.** A variable defined 700 lines up can be safe, and
+one defined nine lines up can be stale. Ask what happened in between.
+
+### A step that only works inside a window says when, not just what
+
+The four-part shape above — what / command / where to look / what it means —
+has no *when*. Several steps read correctly only during a restart, only while a
+rule is installed, only within sixty seconds. Read late, they do not error;
+they print a different, plausible number.
+
+Name the command that opens the window and the one that closes it, and say
+**what the reader sees if they type it after it closed** — that is what most
+readers will actually get.
+
+### A check must be able to fail
+
+For every line that says "이렇게 나오면 통과", state what would print the same
+thing while the condition is false. Three real cases:
+
+- `virsh list --all` used to prove a group membership took effect — it connects
+  to the per-user URI, which works with no group at all
+- a `postmaster.pid` path checked on a fixed node, when the volume may be on the
+  other one — "no such file" passes either way
+- `source ~/.bashrc` on a host whose login shell is zsh — true in that shell,
+  gone at next login, and the symptom surfaces one guide later
+
+If the check passes when the step was skipped — because it reads a different
+scope, host or shell than the step wrote to — it is not a check. Put the scope
+in the command, or write one line naming the failure this check cannot see.
+
+### Never ship a command the guide knows is wrong
+
+Three guides printed a command and told the reader, in prose underneath, to
+edit it before typing. Prose is not a guard. The worst of them was a **valid**
+assignment:
+
+```bash
+OLDID=980ee9b7-...        # ← copy from the output above
+```
+
+Paste it and `OLDID` holds the literal string, and the `delete` two lines later
+runs. Every other hardcoded value in those guides failed loudly — `(0 rows)`,
+`(nil)`. This one succeeded at the wrong thing.
+
+If prose under a block says "replace X first", the block already says it — or
+says `{{X}}`, which is not shell syntax and fails where the reader can see it.
+
+### One block, one machine
+
+A code block is the reader's copy unit. When the machine changes, the block
+ends, even when the commands form one logical step. Splitting the explanation
+in prose does not help: they copy the block.
+
+And a machine label tells the reader *where* a block runs — it does not put
+them there. When consecutive blocks carry different labels, the transition is
+its own step with its own command (`ssh host`, `exit`, "open a second
+terminal"). Count them per guide: entries and exits must balance. A
+verification section that runs somewhere else needs both.
+
+### A shell function defined mid-guide is worse than all three tiers
+
+It leaves no file, so the reader cannot re-read it. It dies with the shell, so
+a new window silently breaks every later step. `unset` does not reach it.
+
+One guide defined `R()` on line 188 and used it through line 617 — a one-letter
+name for `kubectl -n … exec deploy/redis -- redis-cli`. At the point of use
+the reader cannot see what command they are running.
+
+If something is repeated often enough to want a name, make it a script file
+with that name. If it must be a function, define it in the same block as its
+first use, name it for what it does (`redis`, not `R`), and restate the
+definition at the top of any later section more than a screen away.
+
+### Names the reader must already have
+
+A host alias, a directory, a volume, a file that no earlier step created is not
+a placeholder — it is an assumption, and the placeholder rule above does not
+catch it. Four guides in one set ran entirely on `ssh kc-lab-1` with no stanza
+anywhere that creates it; the second guide hits it on its first command.
+
+Show the command that creates it, or name the guide that owns it, in the prose
+above the first block that uses it.
+
+### Walk the guide twice
+
+`echo >>` is one case of a larger rule. Anything created under a fixed name — a
+pod, a volume, a DHCP reservation, a namespace — says what the second run
+prints and how to clear it first. `--rm` only removes on clean exit; Ctrl+C
+leaves the pod and the next run dies on `AlreadyExists`.
+
+And anything that destroys and recreates a host says what identity changes with
+it — SSH host keys, MAC-bound leases, certificates — and what that breaks the
+next time the reader connects.
+
+### The output block belongs to the command above it
+
+If it came from a wider `grep`, an extra `uniq -c`, or a `sed` that rewrote
+names, show that command too or say so on the line before. Readers compare
+their screen to yours character by character; a silent edit makes them hunt for
+a fault that is not there.
+
+### Context selectors are read as a set
+
+`-n`, `--context`, `-h`, `-U`. One guide's `kubectl exec` was missing
+`-n keycloak-lab` while the eight commands around it had it. On its own the
+line looks fine; next to its neighbours it is obviously running somewhere else.
+Read them as a column, not line by line.
+
+### When the same action has several forms, one of them is the step
+
+One guide gave three ways to kill a backend and marked none of them. Show the
+step; put the rest under a heading that says they are alternatives. Leaving the
+reader to choose asks them to weigh a trade-off the guide has not explained yet.
+
+### A fixed output path makes a block single-use
+
+"Change the variable and run it again" is incomplete when the block writes to a
+fixed file: the second run overwrites the first run's baseline, silently, and
+the comparison two sections later has nothing to compare against. Name the
+output path among the things to change.
+
+### Run the remedy you prescribe
+
+A guide diagnosed lexical sorting and prescribed `sort -g`. Every line in that
+file began with the same `200`, so `sort -g` compared equal and fell through to
+byte order — its output was identical to plain `sort`. The fix the guide
+offered did not fix anything, and the sentence "miss this and you misread the
+maximum" stayed true after following it.
+
 ## Rationalization table
 
 | Excuse | Reality |
@@ -383,6 +540,11 @@ variables, and a reader who reads a placeholder as one will paste it unchanged.
 | "The file ends up the same either way" | Only on the first run. `echo >>` appends again every time someone repeats the guide |
 | "So I should use nano for everything" | No. The trigger is authoring a file the reader must understand. `grep`, `virsh`, a long `virt-install` stay as they are |
 | "`python3 -c` only checks syntax" | Then it misses the schema. If the format has a validator — `cloud-init schema`, `nginx -t`, `--dry-run` — that is the step |
+| "The prose right under it says to change that value" | The reader copies the block. Prose is not a guard — put `{{NAME}}` in the block |
+| "The variable is defined earlier in the same shell" | Ask what restarted in between. A pod IP baked at line 877 was stale by line 764 |
+| "The label says which machine it runs on" | A label says where, not how to get there. The transition is its own step |
+| "It's the same command, just shorter" | A one-letter function hides the command at the exact moment the reader needs to read it |
+| "The check passed" | Ask what it would print if the step had been skipped. Three checks in one set passed either way |
 
 ## Red flags — stop and rewrite
 
@@ -398,6 +560,14 @@ variables, and a reader who reads a placeholder as one will paste it unchanged.
 - one line stacking connect + redirect + file creation (`ssh host 'cat > f' < f`)
 - `python3 -c` checking syntax when the format has its own validator
 - a step that appends, so walking the guide twice appends the line twice
+- prose under a block telling the reader to edit the command before typing it
+- a block whose machine label differs from the one above, with no command between
+- a one- or two-letter shell function, or any function defined far from its use
+- a host alias, directory or volume that no step in any guide creates
+- `--rm` with no line saying what a Ctrl+C leaves behind
+- a "통과" line that would print the same thing if the step had been skipped
+- a step that reads correctly only during a window, with no word about the window
+- a remedy you have not run against the data that made you prescribe it
 
 ## References
 
diff --git a/.playwright-mcp/send-plans.js b/.playwright-mcp/send-plans.js
new file mode 100644
index 0000000..e717339
--- /dev/null
+++ b/.playwright-mcp/send-plans.js
@@ -0,0 +1,124 @@
+// 저장 계획을 브라우저 문맥 안에서 보낸다.
+//
+// **왜 브라우저 안인가.** 세션 쿠키가 httpOnly 라 밖으로 못 읽고, 읽어서 옮기는 것은
+// 「비밀은 길이·존재 여부만」에 걸린다. `page.request` 는 그 브라우저 문맥의 쿠키를
+// 그대로 쓰므로 값이 이 프로세스 밖으로 나가지 않는다.
+//
+// **왜 계획을 그대로 안 보내나.** `studio-save.py` 의 계획은 `projectId`·`topicId` 를
+// `null` 로, `relations` 를 빈 배열로 낸다. 서버 저장은 부분 갱신이 아니라서 그대로
+// 보내면 **그 세 칸이 지워진다.** 그래서 저장 직전에 GET 으로 읽어 그 셋과
+// `variantIds` 는 서버 값을 쓰고, 기록이 갖는 칸만 계획 값으로 덮는다.
+//
+// **게시하지 않는다.** publish/unpublish 경로가 섞이면 그 편을 건너뛴다.
+
+async (page) => {
+  // 이 문맥은 샌드박스라 require 도 동적 import 도 안 된다. 그래서 계획은
+  // 127.0.0.1 의 정적 서버에서 받아 온다 — page.request 는 CORS 를 안 탄다.
+  const SUB = 'plans';
+  const LOCAL = 'http://127.0.0.1:8731/' + SUB + '/';
+  const getLocal = async (n) => {
+    const r = await page.request.fetch(LOCAL + n);
+    if (!r.ok()) throw new Error('계획을 못 받았다: ' + n + ' ' + r.status());
+    return await r.json();
+  };
+  const files = await getLocal('_index.json');
+
+  // 기록이 소유하는 칸. 이것만 계획 값으로 덮는다.
+  const OWNED = new Set([
+    'kind', 'title', 'slug', 'summary',
+    'problem', 'conclusion', 'environment', 'reproduction', 'bodyMarkdown', 'lastVerifiedOn',
+    'basisVersion', 'pinnedVersions',
+    'purpose', 'rules', 'applyWhen', 'exceptions', 'examples', 'verifiedOn',
+    'facts', 'assumptions', 'unknowns', 'constraints', 'options', 'nextValidation',
+    'resolution', 'questionStatus',
+  ]);
+  // 서버가 정본인 칸. 계획이 뭐라 하든 서버 값을 쓴다.
+  const SERVER_OWNED = ['projectId', 'topicId', 'relations', 'variantIds'];
+
+  const csrf = await page.evaluate(
+    () => document.cookie.match(/(?:^|;\s*)XSRF-TOKEN=([^;]+)/)?.[1] || null);
+  if (!csrf) return { fatal: 'XSRF-TOKEN 쿠키가 없다 — 로그인 상태가 아니다' };
+
+  const api = async (method, url, body, headers) => {
+    const r = await page.request.fetch('https://hyeonworks.com' + url, {
+      method,
+      headers: Object.assign({ accept: 'application/json' },
+                            body ? { 'content-type': 'application/json' } : {},
+                            headers || {}),
+      data: body ? JSON.stringify(body) : undefined,
+    });
+    let j = null; try { j = await r.json(); } catch (e) { /* 204 는 본문이 없다 */ }
+    return { status: r.status(), body: j };
+  };
+
+  const results = [];
+  for (const f of files) {
+    const plan = await getLocal(f);
+    const name = f.replace(/\.json$/, '');
+    const put = plan.requests.find(r => r.method === 'PUT');
+    if (!put) { results.push({ name, skipped: 'PUT 요청이 없다' }); continue; }
+    if (plan.requests.some(r => /\/(publish|unpublish)(\/|$)/.test(r.path))) {
+      results.push({ name, skipped: '게시 경로가 섞여 있다' }); continue;
+    }
+    const id = put.path.split('/').pop();
+
+    // ① 지금 상태를 읽는다
+    const cur = await api('GET', put.path);
+    if (cur.status !== 200) { results.push({ name, id, step: 'GET', status: cur.status }); continue; }
+    const server = cur.body.data.document;
+    const pub = cur.body.data.currentPublication;
+    if (pub && pub.status === 'PUBLISHED') {
+      results.push({ name, id, skipped: '게시된 문서다' }); continue;
+    }
+
+    // ② 합친다 — 서버 값을 살리고 기록이 갖는 칸만 덮는다
+    const planned = put.body.document;
+    const doc = {};
+    for (const [k, v] of Object.entries(planned)) if (OWNED.has(k)) doc[k] = v;
+    for (const k of SERVER_OWNED) doc[k] = server[k];
+
+    // ③ 보낸다
+    const res = await api('PUT', put.path,
+      { expectedVersion: server.version, document: doc },
+      { 'x-csrf-token': csrf,
+        'idempotency-key': (put.headers && put.headers['Idempotency-Key']) || ('send-' + id + '-' + Date.now()) });
+
+    if (res.status !== 200) {
+      results.push({ name, id, step: 'PUT', status: res.status,
+                     code: res.body && res.body.error && res.body.error.code });
+      continue;
+    }
+
+    // ④ 되읽어 대조한다
+    const back = await api('GET', put.path);
+    const b = back.body.data.document;
+    results.push({
+      name, id, kind: server.kind,
+      status: 200,
+      versionBefore: server.version, versionAfter: b.version,
+      bodyMatches: (b.bodyMarkdown || '') === (doc.bodyMarkdown || ''),
+      titleMatches: b.title === doc.title,
+      summaryMatches: b.summary === doc.summary,
+      keptProject: b.projectId === server.projectId,
+      keptTopic: b.topicId === server.topicId,
+      keptRelations: (b.relations || []).length === (server.relations || []).length,
+      stillUnpublished: !back.body.data.currentPublication,
+    });
+  }
+
+  const ok = results.filter(r => r.status === 200);
+  return {
+    total: files.length,
+    saved: ok.length,
+    skipped: results.filter(r => r.skipped).length,
+    failed: results.filter(r => r.status && r.status !== 200).length,
+    bodyMismatch: ok.filter(r => !r.bodyMatches).length,
+    lostProject: ok.filter(r => !r.keptProject).length,
+    lostTopic: ok.filter(r => !r.keptTopic).length,
+    lostRelations: ok.filter(r => !r.keptRelations).length,
+    becamePublished: ok.filter(r => !r.stillUnpublished).length,
+    problems: results.filter(r => r.skipped || (r.status && r.status !== 200)
+                                || (r.status === 200 && (!r.bodyMatches || !r.keptProject
+                                    || !r.keptTopic || !r.keptRelations || !r.stillUnpublished))),
+  };
+}
diff --git a/.playwright-mcp/studio-docs.json b/.playwright-mcp/studio-docs.json
new file mode 100644
index 0000000..743af6a
--- /dev/null
+++ b/.playwright-mcp/studio-docs.json
@@ -0,0 +1,695 @@
+{
+  "count": 138,
+  "byId": {
+    "8d6b8a7f-e08e-4c9f-9772-a14a9d569260": {
+      "kind": "SETUP",
+      "title": "TTL 로 고아 세션을 골라내 지운다",
+      "version": null
+    },
+    "d53181b9-bb28-4703-97ed-98adfb5b18dc": {
+      "kind": "SETUP",
+      "title": "cookie secret 을 갈아치우고 로그인해 있던 세션이 어떻게 되는지 본다",
+      "version": null
+    },
+    "9bb0b051-c158-497f-a744-b24769c93783": {
+      "kind": "SETUP",
+      "title": "신원 헤더를 위조해 보내고 어디까지 도착하는지 본다",
+      "version": null
+    },
+    "cf2e783c-424b-4167-aa27-3bd6b5f46ee2": {
+      "kind": "SETUP",
+      "title": "flannel.1 에 200ms 를 넣고 커넥션 풀이 고갈되는 것을 본다",
+      "version": null
+    },
+    "b90d719f-39fb-4bab-a263-0e32eedb2b36": {
+      "kind": "SETUP",
+      "title": "한 방향만 끊어 보고 raw PREROUTING 까지 내려간다",
+      "version": null
+    },
+    "d845adc8-be2c-4471-aa1d-7e4db864c471": {
+      "kind": "SETUP",
+      "title": "기계 전원을 뽑고 쿠버네티스가 알아채는 시각을 잰다",
+      "version": null
+    },
+    "91ce17ad-758d-4a63-be5b-489786609557": {
+      "kind": "SETUP",
+      "title": "PostgreSQL 을 진짜로 크래시시키고 잃은 로그인을 센다",
+      "version": null
+    },
+    "bf169fef-f900-4247-88f8-427742ae3fe9": {
+      "kind": "SETUP",
+      "title": "PostgreSQL 을 정상 종료시키고 네 경로를 잰다",
+      "version": null
+    },
+    "4f32b469-185a-4dea-8eba-599864a3b476": {
+      "kind": "SETUP",
+      "title": "deploy 훅 파일 하나를 넣고 nginx 워커가 저절로 갈리는지 확인한다",
+      "version": null
+    },
+    "9349a3fe-5234-48ae-af9f-029ffc0d2296": {
+      "kind": "SETUP",
+      "title": "인증서를 강제로 갱신하고 밖에서 보이는 일련번호가 언제 바뀌는지 잰다",
+      "version": null
+    },
+    "186443e8-a32a-4a94-8609-845a4247d120": {
+      "kind": "SETUP",
+      "title": "카나리아 Secret 을 심고 네 경로에서 평문이 어디까지 나오는지 본다",
+      "version": null
+    },
+    "e53c5947-e1df-400a-ad79-e9d55b1da452": {
+      "kind": "SETUP",
+      "title": "이미지 태그를 올렸다 내리며 롤백이 언제 막히는지 가른다",
+      "version": null
+    },
+    "7dc48b91-e31b-455c-9a9d-c766f95ff491": {
+      "kind": "SETUP",
+      "title": "스키마를 통째로 지우고 덤프 하나로 되살아나는지 본다",
+      "version": null
+    },
+    "5296a106-4c42-437d-b721-33a5e53a045c": {
+      "kind": "SETUP",
+      "title": "IdP 쪽에만 로그아웃 주소를 넣고 한쪽만 고치면 안 퍼지는 것을 확인한다",
+      "version": null
+    },
+    "3421185f-5f3c-4263-9455-6243306e9fc9": {
+      "kind": "SETUP",
+      "title": "두 앱을 한 로그인으로 묶고 IdP 세션만 끊어 앱 세션이 남는지 본다",
+      "version": null
+    },
+    "7447ccbf-1800-43a4-a9d2-8ac774965c4b": {
+      "kind": "SETUP",
+      "title": "서명 키를 더한 뒤 옛 키를 지우고 옛 토큰이 언제 끊기는지 본다",
+      "version": null
+    },
+    "af9645a0-8ca8-481d-9624-69fce6449b7c": {
+      "kind": "SETUP",
+      "title": "Redis 를 0대로 내리고 파드가 Ready 를 유지하는지 본다",
+      "version": null
+    },
+    "405c4206-9b59-491f-aed1-8b97cfd9f584": {
+      "kind": "SETUP",
+      "title": "같은 refresh token 다섯 개를 동시에 던지고 client session 을 센다",
+      "version": null
+    },
+    "df2ee798-7f31-4570-a355-11f96c0eea84": {
+      "kind": "SETUP",
+      "title": "토큰을 PostgreSQL 로 옮기고 기본키와 로그아웃 정리를 확인한다",
+      "version": null
+    },
+    "1e5d05fa-88f4-4ef5-a402-4a520ae4a52d": {
+      "kind": "SETUP",
+      "title": "Redis 를 붙이고 무엇이 옮겨졌는지 빈 목록으로 견준다",
+      "version": null
+    },
+    "4ef91d43-1f1d-481a-8b6f-5e015d068578": {
+      "kind": "SETUP",
+      "title": "아무 저장소도 주지 않고 Spring 이 무엇을 고르는지 찍어서 확인한다",
+      "version": null
+    },
+    "975a6d61-4e34-4034-a0d2-01fea3b498a3": {
+      "kind": "SETUP",
+      "title": "DNS-01 으로 와일드카드 인증서를 받고 갱신이 서빙까지 닿게 한다",
+      "version": null
+    },
+    "0cb0f195-b06b-4f8e-b52e-675eb0918805": {
+      "kind": "SETUP",
+      "title": "Prometheus 와 Grafana 를 올려 클러스터 안을 밖에서 본다",
+      "version": null
+    },
+    "7c66a553-0008-4294-a27a-687bd1bda0c1": {
+      "kind": "SETUP",
+      "title": "lab host 에 가상화 패키지를 깔고 virsh 가 sudo 없이 돌게 만든다",
+      "version": null
+    },
+    "7b113a04-180a-40ec-9270-033531c22221": {
+      "kind": "SETUP",
+      "title": "Keycloak 2노드와 PostgreSQL 을 k3s 에 올리고 클러스터가 묶였는지 확인한다",
+      "version": null
+    },
+    "5e629c2f-e653-4dd9-b1c9-1fe6b2bb181d": {
+      "kind": "SETUP",
+      "title": "k3s server 와 agent 를 게스트 두 대에 깔고 lab host 에서 kubectl 로 본다",
+      "version": null
+    },
+    "74a7bacf-e5d8-4129-926a-c8cf5cacb8c9": {
+      "kind": "SETUP",
+      "title": "엣지 게스트에 nginx 를 세우고 호스트 DNAT 으로 밖에서 들어오는 길을 연다",
+      "version": null
+    },
+    "f972ca27-7e18-41c1-9494-59cc6f676ae2": {
+      "kind": "SETUP",
+      "title": "cloud-init 시드로 게스트 세 대를 만들고 SSH 가 키로 붙게 한다",
+      "version": null
+    },
+    "0b64d23a-f82a-44b4-ad54-e079578977c4": {
+      "kind": "SETUP",
+      "title": "롤링 재시작을 걸고 재시작 전 토큰이 통하는지 본다",
+      "version": null
+    },
+    "21dce25a-a165-47dc-bb40-2ed9f6f9efea": {
+      "kind": "SETUP",
+      "title": "문장 로깅으로 그 500 을 낸 SQL 을 확정하고 캐시 온도 셋을 재현한다",
+      "version": null
+    },
+    "b8d7db33-afdc-4e49-9eab-ed4edbbe398e": {
+      "kind": "SETUP",
+      "title": "persistent-user-sessions 를 끄고 A층 결론 넷을 다시 잰다",
+      "version": null
+    },
+    "95e29500-b535-4246-86db-d569ed814904": {
+      "kind": "SETUP",
+      "title": "7800 을 막고 디스커버리와 트랜스포트를 갈라 끊는다",
+      "version": null
+    },
+    "4f56ed58-fc82-4ed1-ac87-c356b30c34f7": {
+      "kind": "SETUP",
+      "title": "세션을 공유하는 것이 Infinispan 인지 PostgreSQL 인지 손으로 가른다",
+      "version": null
+    },
+    "3b05c1f0-13e9-414a-97a6-2078fb4bab26": {
+      "kind": "CONCEPT",
+      "title": "Guest 의 write() 요청부터 virtqueue까지",
+      "version": null
+    },
+    "5b1de31c-0495-4226-8607-73ed7284b314": {
+      "kind": "CONCEPT",
+      "title": "Guest 의 packet에서 Host Physical NIC까지",
+      "version": null
+    },
+    "5bcae89b-0873-4a2b-af4a-10e5234c085b": {
+      "kind": "CONCEPT",
+      "title": "KVM 에서 vCPU 가 물리 CPU 에서 실행되기까지",
+      "version": null
+    },
+    "ecaaa37d-7b33-4cbf-9bc5-4c6caad14ee5": {
+      "kind": "CONCEPT",
+      "title": "VM 아래에 한 번 더 있는 Host block stack — blk-mq · I/O Scheduler · NVMe",
+      "version": null
+    },
+    "8fafaeea-8746-4537-87a4-679a3a91aa4c": {
+      "kind": "CONCEPT",
+      "title": "완료라는 말의 네 가지 뜻 — write · writeback · flush · 전원 장애 생존",
+      "version": null
+    },
+    "eead2379-94fe-463a-9e5e-06a01bf2105d": {
+      "kind": "QUESTION",
+      "title": "disk image 는 최종적으로 어느 Host block device 위에 있는가",
+      "version": null
+    },
+    "480f86ac-86fb-4290-9bf5-584763aa1363": {
+      "kind": "QUESTION",
+      "title": "이 VM 들의 QEMU disk cache mode 는 무엇인가",
+      "version": null
+    },
+    "decbab8d-9c98-45c6-b5b8-e6162e407299": {
+      "kind": "REFERENCE",
+      "title": "빨라진 구성이 durability contract 를 지운 것은 아닌지 먼저 가른다",
+      "version": null
+    },
+    "b1cda8c4-d31d-4ae4-a4d9-4103a0ab3109": {
+      "kind": "REFERENCE",
+      "title": "지연 원인을 CPU 로 읽기 전에 storage 계층을 따로 잰다",
+      "version": null
+    },
+    "ed64d4ff-aa01-48cc-ae68-6a683b025cde": {
+      "kind": "QUESTION",
+      "title": "VM1 의 storage 부하가 VM2 의 지연을 실제로 밀어 올리는가",
+      "version": null
+    },
+    "77aa0188-5c2b-4f47-bda7-7c66b084968d": {
+      "kind": "QUESTION",
+      "title": "이 호스트의 I/O Scheduler 는 무엇인가",
+      "version": null
+    },
+    "be3c2c58-1ed4-4eae-876a-3114faa61c94": {
+      "kind": "QUESTION",
+      "title": "Guest 의 fsync() 지연과 Host storage 지연은 같이 오르는가",
+      "version": null
+    },
+    "892b6087-8961-486c-b4d9-d3dd46bc2605": {
+      "kind": "CONCEPT",
+      "title": "/dev/vda 뒤에 있는 것 — qcow2 · RAW · Host block device",
+      "version": null
+    },
+    "ae69e2e1-1a3b-4ae3-ae2a-572af07b95d7": {
+      "kind": "QUESTION",
+      "title": "이 disk image 는 qcow2 인가 RAW 인가, 그리고 Guest 가 보는 크기와 Host 가 실제로 쓰는 크기는 얼마나 다른가",
+      "version": null
+    },
+    "1f76d54b-bb17-4174-8128-0c2d71d4256f": {
+      "kind": "QUESTION",
+      "title": "이 호스트의 /dev/vda 는 어떤 backend 에 붙어 있는가",
+      "version": null
+    },
+    "274c5636-33f6-4c19-a54b-d2a96af31289": {
+      "kind": "REFERENCE",
+      "title": "Guest 안에서 본 disk 로 backend 를 단정하지 않는다",
+      "version": null
+    },
+    "484fd832-c7d3-413e-897a-97892e4e10ac": {
+      "kind": "QUESTION",
+      "title": "이 호스트에서 vhost-net 이 실제로 packet datapath 를 맡고 있는가",
+      "version": null
+    },
+    "397c4789-0272-449b-86d6-2c4a3a122401": {
+      "kind": "QUESTION",
+      "title": "VM1 과 VM2 의 TAP/vnet interface 는 무엇이고 어디에 붙어 있는가",
+      "version": null
+    },
+    "38716d7f-1aa1-48d8-ab4c-3fc505332128": {
+      "kind": "QUESTION",
+      "title": "이 호스트의 가상 머신 네트워크는 Bridge 인가 NAT 인가 Routing 인가",
+      "version": null
+    },
+    "ca36f0db-9028-4761-91a8-afb7eb30f2b9": {
+      "kind": "REFERENCE",
+      "title": "Keycloak 실험 결과를 애플리케이션 원인으로 읽기 전에 network 계층을 따로 검증한다",
+      "version": null
+    },
+    "68a848c7-eaff-4421-ad25-de21673ca40c": {
+      "kind": "REFERENCE",
+      "title": "packet 이 어디서 끊겼는지는 계층마다 capture 해서 가른다",
+      "version": null
+    },
+    "79ac61d6-cbe6-483b-9961-02ca8c02b5c2": {
+      "kind": "QUESTION",
+      "title": "부하 중 network 가상화가 지연을 바꿀 만큼 호스트 CPU 를 쓰는가",
+      "version": null
+    },
+    "600a2621-f6d8-42df-9629-7db65011545d": {
+      "kind": "QUESTION",
+      "title": "Host Nginx 에서 Keycloak 까지 packet 은 실제로 어디를 지나는가",
+      "version": null
+    },
+    "1a996f8d-b04e-49d2-88ef-4877e21f7c0e": {
+      "kind": "QUESTION",
+      "title": "이 가상 머신들의 virtio-net 에 multi-queue 가 켜져 있는가",
+      "version": null
+    },
+    "bded6560-dc8d-473d-966c-5b037bb84c4c": {
+      "kind": "QUESTION",
+      "title": "QEMU backend 와 vhost-net 의 차이가 이 호스트에서 실제로 보이는가",
+      "version": null
+    },
+    "32d0be7d-d88e-4760-8d91-35d3a233a99a": {
+      "kind": "CASE",
+      "title": "Fetch 타입이 아닌 조회 방식으로 인한 N+1",
+      "version": null
+    },
+    "c1158754-e3d2-47b8-bb41-81787c0ca84b": {
+      "kind": "CASE",
+      "title": "Collection Fetch Join Pagination의 In-memory Paging",
+      "version": null
+    },
+    "1b59e6de-16f1-42b2-81bb-01d6198e34bf": {
+      "kind": "QUESTION",
+      "title": "QEMU 메모리는 vCPU 가 도는 NUMA node 와 같은 node 에 있는가",
+      "version": null
+    },
+    "6a60abe7-ea2c-46c2-bb9f-8281bfbe9644": {
+      "kind": "QUESTION",
+      "title": "balloon target 을 바꾸면 게스트가 쓸 수 있는 메모리는 어떻게 따라 움직이는가",
+      "version": null
+    },
+    "a05fe2a6-eb7c-4bcc-a7da-58e729436468": {
+      "kind": "QUESTION",
+      "title": "호스트 메모리 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는가",
+      "version": null
+    },
+    "380d4975-3be5-451d-aede-2e24c5a2a09e": {
+      "kind": "QUESTION",
+      "title": "NUMA remote access 가 이 작업의 지연을 실제로 바꾸는가",
+      "version": null
+    },
+    "63aef96b-03ef-4dbd-9ba6-9e61c6e695e1": {
+      "kind": "QUESTION",
+      "title": "이 가상 머신들에 virtio-balloon 이 붙어 있는가",
+      "version": null
+    },
+    "074a1cb4-cea8-4dad-bc4c-899692ff9aa9": {
+      "kind": "QUESTION",
+      "title": "게스트 page fault 증가는 workload 변화를 따라가는가",
+      "version": null
+    },
+    "a2cbc828-59ab-4e70-916a-d053e71960ae": {
+      "kind": "QUESTION",
+      "title": "호스트 major fault 와 스토리지 지연은 같은 시간축에서 함께 움직이는가",
+      "version": null
+    },
+    "50730203-df5f-4604-8535-7e93ab6fb724": {
+      "kind": "QUESTION",
+      "title": "이 호스트의 THP 정책과 huge page 상태는 무엇인가",
+      "version": null
+    },
+    "fa5b3782-9fcf-4113-8f51-a55c8023b2db": {
+      "kind": "QUESTION",
+      "title": "QEMU 프로세스가 실제로 붙잡고 있는 호스트 메모리는 얼마이고 어떻게 나뉘어 있는가",
+      "version": null
+    },
+    "67285d51-7eaf-4540-9577-cfd0b273b40e": {
+      "kind": "QUESTION",
+      "title": "이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가",
+      "version": null
+    },
+    "63fa33e5-9957-4d28-8d3c-c75735a73bd6": {
+      "kind": "REFERENCE",
+      "title": "메모리 증상 하나로 계층을 단정하지 않는다",
+      "version": null
+    },
+    "ded41b52-ec08-4231-a54c-86d6c80d38f0": {
+      "kind": "REFERENCE",
+      "title": "메모리 실험 결과에는 Host · VM · Workload 조건을 함께 남긴다",
+      "version": null
+    },
+    "f460e9a2-35ef-46ff-81cf-b36627a1b231": {
+      "kind": "QUESTION",
+      "title": "가상 머신 RAM 이 HugeTLB 로 명시적으로 backing 되어 있는가",
+      "version": null
+    },
+    "d3e8501f-e1b5-4f8f-aa9a-89f9c89a308e": {
+      "kind": "QUESTION",
+      "title": "지금 게스트와 호스트에서 swap 이 실제로 오가고 있는가",
+      "version": null
+    },
+    "647d6d11-5bb2-4028-a530-b10c8925aa11": {
+      "kind": "CONCEPT",
+      "title": "Host 메모리 압박이 Guest 와 스토리지까지 내려가는 경로",
+      "version": null
+    },
+    "68811272-5352-4409-aa20-7e22e601ede8": {
+      "kind": "CONCEPT",
+      "title": "NUMA 에서는 vCPU 배치와 메모리 배치를 함께 본다",
+      "version": null
+    },
+    "ebdf93d7-2dcb-4fc8-91b9-2364ac8196e6": {
+      "kind": "CONCEPT",
+      "title": "virtio-balloon 이 Guest 메모리를 회수하고 돌려주는 방식",
+      "version": null
+    },
+    "2f2ffafc-91ff-4971-a6a8-7c0e7d844ca2": {
+      "kind": "CONCEPT",
+      "title": "Guest 메모리 주소가 물리 RAM 에 닿기까지 — GVA · GPA · HPA",
+      "version": null
+    },
+    "efce9a6e-5f5d-45ec-86e5-056d8cb1b8d2": {
+      "kind": "CONCEPT",
+      "title": "Huge Page 를 VM 에서 볼 때 갈라지는 세 자리",
+      "version": null
+    },
+    "e80853fa-98b8-4cc3-a2df-427c7147794b": {
+      "kind": "CONCEPT",
+      "title": "VM 에서 page fault 는 세 계층에서 따로 일어난다",
+      "version": null
+    },
+    "688c6c02-c1bd-4cd2-a615-2396db145386": {
+      "kind": "QUESTION",
+      "title": "이 호스트의 NUMA 토폴로지는 가상 머신 성능을 고려해야 할 구조인가",
+      "version": null
+    },
+    "d103bb81-45df-402f-86e5-e41d66ed7f8d": {
+      "kind": "QUESTION",
+      "title": "Keycloak 작업의 VM Exit 분포는 idle · CPU-bound · I/O-bound 와 어떻게 다른가",
+      "version": null
+    },
+    "62319064-17ef-4b2f-bf8b-e363cd0e36a6": {
+      "kind": "QUESTION",
+      "title": "CPU pinning 전후로 Keycloak 지연과 vCPU 스케줄링 변동이 달라지는가",
+      "version": null
+    },
+    "116b806c-b176-401c-9363-1489fffb721c": {
+      "kind": "QUESTION",
+      "title": "cgroup CPU 제한과 호스트 vCPU 경쟁을 지표로 가를 수 있는가",
+      "version": null
+    },
+    "723d8930-9e82-4552-8376-038a6446ec71": {
+      "kind": "QUESTION",
+      "title": "vCPU 를 늘릴수록 이 호스트에서 Keycloak 처리량도 계속 오르는가",
+      "version": null
+    },
+    "2d058fb5-01f1-4be8-80bb-0e377868573c": {
+      "kind": "QUESTION",
+      "title": "가상 머신 두 대를 CPU-bound 로 만들면 게스트 steal time 은 얼마나 오르는가",
+      "version": null
+    },
+    "2acec7d5-3eaf-4115-9d61-45647c4ec01e": {
+      "kind": "QUESTION",
+      "title": "운영 서버는 CPU 가상화 계층의 영향을 받는 구조인가",
+      "version": null
+    },
+    "cd58d35d-3a93-4682-82b8-b64ce3a8813c": {
+      "kind": "QUESTION",
+      "title": "pinning 없이 vCPU 스레드는 호스트 논리 CPU 사이를 옮겨 다니는가",
+      "version": null
+    },
+    "61b7486f-5dab-41df-8f4f-e8fc21d88617": {
+      "kind": "QUESTION",
+      "title": "실제 작업에서 주로 발생하는 VM Exit 은 무엇인가",
+      "version": null
+    },
+    "4a2d3332-81c3-44fa-a4fb-216a41abb504": {
+      "kind": "QUESTION",
+      "title": "게스트가 유휴 상태일 때 vCPU 스레드는 이 테스트 환경에서 어떻게 보이는가",
+      "version": null
+    },
+    "da3a7b56-5691-4a9f-90c5-3a1a5d0f0013": {
+      "kind": "QUESTION",
+      "title": "Keycloak 동시 refresh 실험 중 CPU 가상화 계층이 결과를 흔들 만큼 포화되는가",
+      "version": null
+    },
+    "eba4a877-276a-4050-9a97-d32614546c71": {
+      "kind": "QUESTION",
+      "title": "가상 머신 두 대에 동시에 부하를 주면 이 호스트에서 vCPU 경쟁이 실제로 생기는가",
+      "version": null
+    },
+    "a0e1cc05-92b3-4dac-bce1-513ab8cd862b": {
+      "kind": "CASE",
+      "title": "Forward-Auth에서 Client가 보낸 Identity Header를 신뢰하면 안 되는 이유",
+      "version": null
+    },
+    "488ce49b-afa4-42a5-a2ce-de2e0653cd82": {
+      "kind": "CASE",
+      "title": "Refresh Token 관리만 서버로 이전, Access Token은 여전히 Browser에 노출",
+      "version": null
+    },
+    "bf675775-4f3e-4744-8014-f0efff51422a": {
+      "kind": "CASE",
+      "title": "SPA에서 OAuth Token을 JavaScript Memory에 보관한 경우",
+      "version": null
+    },
+    "036563a1-3a43-4931-a017-0e693b591e89": {
+      "kind": "REFERENCE",
+      "title": "패턴 검증을 실제로 돌릴 때의 안전한 순서",
+      "version": null
+    },
+    "4c9c3b90-bc89-4300-9334-088ea95d37d8": {
+      "kind": "CASE",
+      "title": "Projection 이후에도 1,509행을 읽은 Row Over-fetch",
+      "version": null
+    },
+    "7ed75172-fd56-42bf-956a-8f9fc1cca235": {
+      "kind": "CASE",
+      "title": "Collection Fetch Join으로 N+1을 해결하다 만난 MultiBag예외와 행 폭증 문제",
+      "version": null
+    },
+    "a3493786-d3fb-4b01-b1c5-ecb23c3d5497": {
+      "kind": "CONCEPT",
+      "title": "Forward-Auth와 Nginx auth_request의 동작",
+      "version": null
+    },
+    "5c8f12d5-1ead-469b-8e91-2de69401df48": {
+      "kind": "CONCEPT",
+      "title": "Cookie로 인증하는 요청에서 CSRF token이 하는 일",
+      "version": null
+    },
+    "d85bd6af-7599-4ef7-9407-6609927d5b5c": {
+      "kind": "CASE",
+      "title": "Browser Token을 없애면서 BFF에 Session과 CSRF 책임이 생긴 과정",
+      "version": null
+    },
+    "e1e0e2a0-c6b6-45bf-be42-f697ba5e2fff": {
+      "kind": "QUESTION",
+      "title": "ANALYZE 이후 Cardinality Estimate는 어떻게 달라지는가",
+      "version": null
+    },
+    "5159c415-232d-424a-970a-b0db52746767": {
+      "kind": "QUESTION",
+      "title": "Round Trip과 Row Volume을 독립 측정할 것인가",
+      "version": null
+    },
+    "b0b55ac9-c0a3-4c01-ba84-0aa478923ace": {
+      "kind": "REFERENCE",
+      "title": "JPA N+1 정량 진단 기준",
+      "version": null
+    },
+    "ae6c9bea-d3a3-46e1-bbd4-8d580d336394": {
+      "kind": "PROJECT_DECISION",
+      "title": "Query Plan은 실제 PostgreSQL에서 측정한다",
+      "version": null
+    },
+    "d99fdec9-fe9e-4e0f-a50b-6fb9b9ed5719": {
+      "kind": "CONCEPT",
+      "title": "외부 IdP Brokering의 동작",
+      "version": null
+    },
+    "bf5f2462-0e94-4723-bdc8-f7dd709b2dbb": {
+      "kind": "REFERENCE",
+      "title": "Top-N-per-group 선택 기준",
+      "version": null
+    },
+    "e8c2e9ea-cd87-46f8-9469-849dbd433d86": {
+      "kind": "REFERENCE",
+      "title": "PostgreSQL Query Plan 측정 기준",
+      "version": null
+    },
+    "06788903-3dfa-4f70-b159-f1224384fd0b": {
+      "kind": "REFERENCE",
+      "title": "Keyset Pagination 설계 기준",
+      "version": null
+    },
+    "51095f6e-2cc8-439c-8648-065033614215": {
+      "kind": "REFERENCE",
+      "title": "Fetch Type과 Fetch Strategy 구분",
+      "version": null
+    },
+    "db99cbc5-9123-4599-b368-39ff3170e81d": {
+      "kind": "REFERENCE",
+      "title": "Fetch Join · Batch · Projection 선택 기준",
+      "version": null
+    },
+    "635fcedd-d402-4297-bcf3-9fcdf4200d28": {
+      "kind": "REFERENCE",
+      "title": "Feed Visibility Query Pattern",
+      "version": null
+    },
+    "30a37f34-b406-4061-b924-e22e0be0c3bf": {
+      "kind": "PROJECT_DECISION",
+      "title": "화면 조회는 Read Projection을 사용한다",
+      "version": null
+    },
+    "4e3200c8-eff5-4442-ae84-ae7b7fa92c8b": {
+      "kind": "PROJECT_DECISION",
+      "title": "Query Strategy는 FeedQueryPort 뒤에서 소유한다",
+      "version": null
+    },
+    "5e4d033c-d6fe-4257-a4dc-1ade44473c72": {
+      "kind": "PROJECT_DECISION",
+      "title": "Collection Fetch Join과 Pagination을 같이 사용하지 않는다",
+      "version": null
+    },
+    "1dbce381-f0dc-4d49-ad68-bd31d205677e": {
+      "kind": "PROJECT_DECISION",
+      "title": "Feed Pagination은 Keyset을 사용한다",
+      "version": null
+    },
+    "7f248f68-ce2b-43ec-94ce-82324d0bd1a7": {
+      "kind": "PROJECT_DECISION",
+      "title": "현재 Read Model은 CQRS-lite로 유지한다",
+      "version": null
+    },
+    "08a74b35-10c3-4874-8fbc-209b0b6e942e": {
+      "kind": "PROJECT_DECISION",
+      "title": "Entity Graph 조회에는 Batch Fetch를 사용한다",
+      "version": null
+    },
+    "5088ce14-b096-41d3-abba-64b7afb48bb9": {
+      "kind": "QUESTION",
+      "title": "feed_visible을 Production CQRS로 승격할 것인가",
+      "version": null
+    },
+    "b099ca65-bf9f-4d61-814c-74722453fa3c": {
+      "kind": "QUESTION",
+      "title": "Highlight 없는 FeedItem을 허용할 것인가",
+      "version": null
+    },
+    "6cbe963f-86f8-4df6-be5a-900712970d01": {
+      "kind": "QUESTION",
+      "title": "실제 동시 트래픽에서도 이 구조가 안정적인가",
+      "version": null
+    },
+    "e6715e81-6dbd-4287-8e19-946c334f38fb": {
+      "kind": "CASE",
+      "title": "Visibility OR이 Keyset Index를 깨뜨린 문제",
+      "version": null
+    },
+    "3f886154-1b85-407b-bda4-57d28370e745": {
+      "kind": "REFERENCE",
+      "title": "OAuth/OIDC 인증 패턴 선택 기준",
+      "version": null
+    },
+    "19b55c39-c583-4161-9775-df954280a568": {
+      "kind": "PROJECT_DECISION",
+      "title": "BFF가 OAuth Token을 관리하는 조건",
+      "version": null
+    },
+    "7ff40767-a00b-4db2-98f6-0cdfce8c8936": {
+      "kind": "QUESTION",
+      "title": "Forward-Auth 구조에서 Application Authorization을 어디까지 Edge에 둘 것인가",
+      "version": null
+    },
+    "18a5cde2-dd1e-4bff-9f1c-997577ae438f": {
+      "kind": "QUESTION",
+      "title": "BFF의 Session과 OAuth2AuthorizedClient를 어디에 저장할 것인가",
+      "version": null
+    },
+    "66c18e42-116c-459f-86bd-b7e4bf394866": {
+      "kind": "REFERENCE",
+      "title": "OAuth Token과 Application Session을 구분하는 기준",
+      "version": null
+    },
+    "97eddd97-1096-426a-a2c6-a6c5bf1cd09f": {
+      "kind": "REFERENCE",
+      "title": "BFF 인증 구조 설계 기준",
+      "version": null
+    },
+    "004dd0a2-5fb3-4f25-80c9-576f709de331": {
+      "kind": "REFERENCE",
+      "title": "Forward-Auth에서 Identity Header를 신뢰하기 위한 조건",
+      "version": null
+    },
+    "1a00a640-8987-4075-a9e4-7ec023cdffbb": {
+      "kind": "REFERENCE",
+      "title": "외부 IdP 연동과 Application 인증 구조의 경계",
+      "version": null
+    },
+    "ede6b9ce-eeed-40c8-9175-9e8116029395": {
+      "kind": "REFERENCE",
+      "title": "Public Client와 Confidential Client 구분 기준",
+      "version": null
+    },
+    "c72656b5-842d-45d9-b5f6-82b66b09d0b9": {
+      "kind": "QUESTION",
+      "title": "서버 세션 기반 인증 구조는 다중 인스턴스에서 어떻게 운영할 것인가",
+      "version": null
+    },
+    "bb5c37ae-2d94-48f7-ad4e-a37c61c3fd07": {
+      "kind": "CONCEPT",
+      "title": "브라우저가 credential을 보관하는 위치와 그 성질",
+      "version": null
+    },
+    "87000d59-b69f-4010-9481-0b71c8bde32d": {
+      "kind": "CONCEPT",
+      "title": "Bearer JWT가 인증된 principal이 되기까지",
+      "version": null
+    },
+    "75c6c657-3e03-47a0-a9d0-5637fce9dd3f": {
+      "kind": "CONCEPT",
+      "title": "Authorization Code와 PKCE가 보호하는 구간",
+      "version": null
+    },
+    "8c1ebea7-204e-445c-9812-0421d9eb0e9c": {
+      "kind": "PROJECT_DECISION",
+      "title": "외부 IdP와의 연동이라도 별도의 인증 방식이 아니다.",
+      "version": null
+    },
+    "9ae4ec71-a32e-49a7-88c2-f7368541c28d": {
+      "kind": "QUESTION",
+      "title": "Refresh Token Rotation과 다중 Replica 경쟁을 어떻게 처리할 것인가",
+      "version": null
+    },
+    "39fdf472-82c4-43ed-abec-73de672f08ae": {
+      "kind": "REFERENCE",
+      "title": "Authorization Code Flow의 Endpoint와 Credential 이동 기준",
+      "version": null
+    }
+  }
+}
\ No newline at end of file
diff --git a/.playwright-mcp/studio-targets.json b/.playwright-mcp/studio-targets.json
new file mode 100644
index 0000000..370817e
--- /dev/null
+++ b/.playwright-mcp/studio-targets.json
@@ -0,0 +1,790 @@
+{
+  "asked": 87,
+  "missing": 0,
+  "published": 2,
+  "byId": {
+    "bf169fef-f900-4247-88f8-427742ae3fe9": {
+      "kind": "SETUP",
+      "version": 4,
+      "slug": "reproduce-a2-database-loss",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "f2183920-6573-4148-90ae-8a510500d862",
+      "relations": 0
+    },
+    "91ce17ad-758d-4a63-be5b-489786609557": {
+      "kind": "SETUP",
+      "version": 4,
+      "slug": "reproduce-a3-database-crash",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "f2183920-6573-4148-90ae-8a510500d862",
+      "relations": 0
+    },
+    "d845adc8-be2c-4471-aa1d-7e4db864c471": {
+      "kind": "SETUP",
+      "version": 4,
+      "slug": "reproduce-a4-node-loss",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "f2183920-6573-4148-90ae-8a510500d862",
+      "relations": 0
+    },
+    "b90d719f-39fb-4bab-a263-0e32eedb2b36": {
+      "kind": "SETUP",
+      "version": 4,
+      "slug": "reproduce-a5-asymmetric-partition",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "f2183920-6573-4148-90ae-8a510500d862",
+      "relations": 0
+    },
+    "cf2e783c-424b-4167-aa27-3bd6b5f46ee2": {
+      "kind": "SETUP",
+      "version": 4,
+      "slug": "reproduce-a6-latency-injection",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "f2183920-6573-4148-90ae-8a510500d862",
+      "relations": 0
+    },
+    "7dc48b91-e31b-455c-9a9d-c766f95ff491": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-d1-backup-restore",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "cf1fe22a-af52-4d57-9833-559f537d924b",
+      "relations": 0
+    },
+    "e53c5947-e1df-400a-ad79-e9d55b1da452": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-d2-version-upgrade",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "cf1fe22a-af52-4d57-9833-559f537d924b",
+      "relations": 0
+    },
+    "186443e8-a32a-4a94-8609-845a4247d120": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-d3-secret-exposure",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "cf1fe22a-af52-4d57-9833-559f537d924b",
+      "relations": 0
+    },
+    "9349a3fe-5234-48ae-af9f-029ffc0d2296": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-d4-certificate-renewal",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "cf1fe22a-af52-4d57-9833-559f537d924b",
+      "relations": 0
+    },
+    "4f32b469-185a-4dea-8eba-599864a3b476": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-d4a-deploy-hook",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "cf1fe22a-af52-4d57-9833-559f537d924b",
+      "relations": 0
+    },
+    "4f56ed58-fc82-4ed1-ac87-c356b30c34f7": {
+      "kind": "SETUP",
+      "version": 3,
+      "slug": "reproduce-a0-session-sharing-path",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "2ee927ff-217b-429f-b081-d313df65a5de",
+      "relations": 0
+    },
+    "95e29500-b535-4246-86db-d569ed814904": {
+      "kind": "SETUP",
+      "version": 3,
+      "slug": "reproduce-a1-jgroups-transport-block",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "2ee927ff-217b-429f-b081-d313df65a5de",
+      "relations": 0
+    },
+    "b8d7db33-afdc-4e49-9eab-ed4edbbe398e": {
+      "kind": "SETUP",
+      "version": 3,
+      "slug": "reproduce-a7-volatile-comparison",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "2ee927ff-217b-429f-b081-d313df65a5de",
+      "relations": 0
+    },
+    "21dce25a-a165-47dc-bb40-2ed9f6f9efea": {
+      "kind": "SETUP",
+      "version": 3,
+      "slug": "reproduce-a7a-volatile-cause",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "2ee927ff-217b-429f-b081-d313df65a5de",
+      "relations": 0
+    },
+    "0b64d23a-f82a-44b4-ad54-e079578977c4": {
+      "kind": "SETUP",
+      "version": 3,
+      "slug": "reproduce-a8-rolling-restart",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "2ee927ff-217b-429f-b081-d313df65a5de",
+      "relations": 0
+    },
+    "9bb0b051-c158-497f-a744-b24769c93783": {
+      "kind": "SETUP",
+      "version": 3,
+      "slug": "reproduce-b4-forged-identity-headers",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "116708bb-fcb8-4c7e-9814-a8661dfb1c52",
+      "relations": 0
+    },
+    "d53181b9-bb28-4703-97ed-98adfb5b18dc": {
+      "kind": "SETUP",
+      "version": 3,
+      "slug": "reproduce-b7-cookie-secret-rotation",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "116708bb-fcb8-4c7e-9814-a8661dfb1c52",
+      "relations": 0
+    },
+    "8d6b8a7f-e08e-4c9f-9772-a14a9d569260": {
+      "kind": "SETUP",
+      "version": 4,
+      "slug": "reproduce-b7a-orphan-session",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "116708bb-fcb8-4c7e-9814-a8661dfb1c52",
+      "relations": 0
+    },
+    "3421185f-5f3c-4263-9455-6243306e9fc9": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-c1-multi-app-sso",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "116708bb-fcb8-4c7e-9814-a8661dfb1c52",
+      "relations": 0
+    },
+    "5296a106-4c42-437d-b721-33a5e53a045c": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-c2-backchannel-logout",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "116708bb-fcb8-4c7e-9814-a8661dfb1c52",
+      "relations": 0
+    },
+    "4ef91d43-1f1d-481a-8b6f-5e015d068578": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-b0-default-session-store",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "3e8e8f8d-1f94-48ba-a821-b7403b35eba5",
+      "relations": 0
+    },
+    "1e5d05fa-88f4-4ef5-a402-4a520ae4a52d": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-b1-redis-session-store",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "3e8e8f8d-1f94-48ba-a821-b7403b35eba5",
+      "relations": 0
+    },
+    "df2ee798-7f31-4570-a355-11f96c0eea84": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-b2-jdbc-token-store",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "3e8e8f8d-1f94-48ba-a821-b7403b35eba5",
+      "relations": 0
+    },
+    "405c4206-9b59-491f-aed1-8b97cfd9f584": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-b3-refresh-contention",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "3e8e8f8d-1f94-48ba-a821-b7403b35eba5",
+      "relations": 0
+    },
+    "af9645a0-8ca8-481d-9624-69fce6449b7c": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-b5-redis-loss",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "3e8e8f8d-1f94-48ba-a821-b7403b35eba5",
+      "relations": 0
+    },
+    "7447ccbf-1800-43a4-a9d2-8ac774965c4b": {
+      "kind": "SETUP",
+      "version": 2,
+      "slug": "reproduce-b6-key-rotation",
+      "publication": null,
+      "projectId": "9a8ed8be-ecb1-4e40-8e11-4b5641e98ded",
+      "topicId": "3e8e8f8d-1f94-48ba-a821-b7403b35eba5",
+      "relations": 0
+    },
+    "d103bb81-45df-402f-86e5-e41d66ed7f8d": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "exit-distribution-for-keycloak-workload",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "e42456e2-9efd-41ee-b676-df82e90f2f53",
+      "relations": 0
+    },
+    "688c6c02-c1bd-4cd2-a615-2396db145386": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "host-numa-topology",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "e42456e2-9efd-41ee-b676-df82e90f2f53",
+      "relations": 0
+    },
+    "4a2d3332-81c3-44fa-a4fb-216a41abb504": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "idle-vcpu-thread-appearance",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "e42456e2-9efd-41ee-b676-df82e90f2f53",
+      "relations": 0
+    },
+    "2acec7d5-3eaf-4115-9d61-45647c4ec01e": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "is-production-on-a-hypervisor",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "e42456e2-9efd-41ee-b676-df82e90f2f53",
+      "relations": 0
+    },
+    "62319064-17ef-4b2f-bf8b-e363cd0e36a6": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "pinning-before-and-after",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "e42456e2-9efd-41ee-b676-df82e90f2f53",
+      "relations": 0
+    },
+    "2d058fb5-01f1-4be8-80bb-0e377868573c": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "steal-time-increase-under-two-cpu-bound-vms",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "e42456e2-9efd-41ee-b676-df82e90f2f53",
+      "relations": 0
+    },
+    "116b806c-b176-401c-9363-1489fffb721c": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "throttling-vs-contention",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "e42456e2-9efd-41ee-b676-df82e90f2f53",
+      "relations": 0
+    },
+    "723d8930-9e82-4552-8376-038a6446ec71": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "throughput-vs-vcpu-count",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "e42456e2-9efd-41ee-b676-df82e90f2f53",
+      "relations": 0
+    },
+    "cd58d35d-3a93-4682-82b8-b64ce3a8813c": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "vcpu-thread-migration-without-pinning",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "e42456e2-9efd-41ee-b676-df82e90f2f53",
+      "relations": 0
+    },
+    "da3a7b56-5691-4a9f-90c5-3a1a5d0f0013": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "virtualization-layer-saturation-during-refresh",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "e42456e2-9efd-41ee-b676-df82e90f2f53",
+      "relations": 0
+    },
+    "61b7486f-5dab-41df-8f4f-e8fc21d88617": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "vm-exit-distribution-by-workload",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "e42456e2-9efd-41ee-b676-df82e90f2f53",
+      "relations": 0
+    },
+    "f972ca27-7e18-41c1-9494-59cc6f676ae2": {
+      "kind": "SETUP",
+      "version": 3,
+      "slug": "create-three-guests-with-cloud-init",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "886181b9-5d25-47bf-81a4-813084e3d9d7",
+      "relations": 0
+    },
+    "74a7bacf-e5d8-4129-926a-c8cf5cacb8c9": {
+      "kind": "SETUP",
+      "version": 5,
+      "slug": "edge-nginx-and-host-dnat",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "886181b9-5d25-47bf-81a4-813084e3d9d7",
+      "relations": 0
+    },
+    "5e629c2f-e653-4dd9-b1c9-1fe6b2bb181d": {
+      "kind": "SETUP",
+      "version": 6,
+      "slug": "install-k3s-server-and-agent",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "886181b9-5d25-47bf-81a4-813084e3d9d7",
+      "relations": 0
+    },
+    "7b113a04-180a-40ec-9270-033531c22221": {
+      "kind": "SETUP",
+      "version": 5,
+      "slug": "keycloak-two-nodes-and-postgres-on-k3s",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "886181b9-5d25-47bf-81a4-813084e3d9d7",
+      "relations": 0
+    },
+    "7c66a553-0008-4294-a27a-687bd1bda0c1": {
+      "kind": "SETUP",
+      "version": 5,
+      "slug": "prepare-the-lab-host-for-virtualization",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "886181b9-5d25-47bf-81a4-813084e3d9d7",
+      "relations": 0
+    },
+    "0cb0f195-b06b-4f8e-b52e-675eb0918805": {
+      "kind": "SETUP",
+      "version": 5,
+      "slug": "prometheus-and-grafana-for-the-lab",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "886181b9-5d25-47bf-81a4-813084e3d9d7",
+      "relations": 0
+    },
+    "975a6d61-4e34-4034-a0d2-01fea3b498a3": {
+      "kind": "SETUP",
+      "version": 5,
+      "slug": "wildcard-certificate-with-dns-01-and-a-deploy-hook",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "886181b9-5d25-47bf-81a4-813084e3d9d7",
+      "relations": 0
+    },
+    "efce9a6e-5f5d-45ec-86e5-056d8cb1b8d2": {
+      "kind": "CONCEPT",
+      "version": 3,
+      "slug": "huge-pages-in-a-vm",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 1
+    },
+    "647d6d11-5bb2-4028-a530-b10c8925aa11": {
+      "kind": "CONCEPT",
+      "version": 3,
+      "slug": "memory-pressure-reclaim-swap-oom",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 3
+    },
+    "68811272-5352-4409-aa20-7e22e601ede8": {
+      "kind": "CONCEPT",
+      "version": 2,
+      "slug": "numa-locality-for-vcpu-and-memory",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 3
+    },
+    "e80853fa-98b8-4cc3-a2df-427c7147794b": {
+      "kind": "CONCEPT",
+      "version": 2,
+      "slug": "page-fault-layers-in-a-vm",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 1
+    },
+    "ebdf93d7-2dcb-4fc8-91b9-2364ac8196e6": {
+      "kind": "CONCEPT",
+      "version": 3,
+      "slug": "virtio-balloon-memory-reclaim",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 1
+    },
+    "6a60abe7-ea2c-46c2-bb9f-8281bfbe9644": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "balloon-target-vs-guest-available-memory",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 4
+    },
+    "074a1cb4-cea8-4dad-bc4c-899692ff9aa9": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "guest-page-fault-vs-workload",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 4
+    },
+    "a2cbc828-59ab-4e70-916a-d053e71960ae": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "host-major-fault-vs-storage-latency",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 5
+    },
+    "a05fe2a6-eb7c-4bcc-a7da-58e729436468": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "host-memory-pressure-vs-guest-latency",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 5
+    },
+    "50730203-df5f-4604-8535-7e93ab6fb724": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "host-thp-policy",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 3
+    },
+    "380d4975-3be5-451d-aede-2e24c5a2a09e": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "numa-remote-access-vs-workload-latency",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 4
+    },
+    "1b59e6de-16f1-42b2-81bb-01d6198e34bf": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "qemu-memory-numa-placement",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 4
+    },
+    "fa5b3782-9fcf-4113-8f51-a55c8023b2db": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "qemu-resident-memory-distribution",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 4
+    },
+    "d3e8501f-e1b5-4f8f-aa9a-89f9c89a308e": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "swap-activity-in-guest-and-host",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 3
+    },
+    "63aef96b-03ef-4dbd-9ba6-9e61c6e695e1": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "virtio-balloon-configured",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 3
+    },
+    "67285d51-7eaf-4540-9577-cfd0b273b40e": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "vm-configured-vs-current-memory",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 4
+    },
+    "f460e9a2-35ef-46ff-81cf-b36627a1b231": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "vm-ram-backed-by-hugetlb",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 4
+    },
+    "63fa33e5-9957-4d28-8d3c-c75735a73bd6": {
+      "kind": "REFERENCE",
+      "version": 3,
+      "slug": "memory-symptom-needs-layer-separation",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 6
+    },
+    "ded41b52-ec08-4231-a54c-86d6c80d38f0": {
+      "kind": "REFERENCE",
+      "version": 3,
+      "slug": "record-the-conditions-with-every-memory-experiment",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "5675627f-3616-409c-990b-c537d3c68ed6",
+      "relations": 4
+    },
+    "5b1de31c-0495-4226-8607-73ed7284b314": {
+      "kind": "CONCEPT",
+      "version": 160,
+      "slug": "guest-packet-path-to-physical-nic",
+      "publication": "PUBLISHED",
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "56089eec-a603-4eac-bbb6-6fb44392ea63",
+      "relations": 10
+    },
+    "600a2621-f6d8-42df-9629-7db65011545d": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "actual-packet-path-nginx-to-keycloak",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "56089eec-a603-4eac-bbb6-6fb44392ea63",
+      "relations": 5
+    },
+    "484fd832-c7d3-413e-897a-97892e4e10ac": {
+      "kind": "QUESTION",
+      "version": 4,
+      "slug": "is-vhost-net-actually-in-use",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "56089eec-a603-4eac-bbb6-6fb44392ea63",
+      "relations": 4
+    },
+    "79ac61d6-cbe6-483b-9961-02ca8c02b5c2": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "network-virtualization-cpu-cost-under-load",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "56089eec-a603-4eac-bbb6-6fb44392ea63",
+      "relations": 5
+    },
+    "bded6560-dc8d-473d-966c-5b037bb84c4c": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "qemu-backend-vs-vhost-net-on-this-host",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "56089eec-a603-4eac-bbb6-6fb44392ea63",
+      "relations": 4
+    },
+    "397c4789-0272-449b-86d6-2c4a3a122401": {
+      "kind": "QUESTION",
+      "version": 4,
+      "slug": "tap-interface-to-vm-mapping",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "56089eec-a603-4eac-bbb6-6fb44392ea63",
+      "relations": 4
+    },
+    "1a996f8d-b04e-49d2-88ef-4877e21f7c0e": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "virtio-net-multi-queue-enabled",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "56089eec-a603-4eac-bbb6-6fb44392ea63",
+      "relations": 3
+    },
+    "38716d7f-1aa1-48d8-ab4c-3fc505332128": {
+      "kind": "QUESTION",
+      "version": 4,
+      "slug": "vm-network-mode-bridge-nat-or-routed",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "56089eec-a603-4eac-bbb6-6fb44392ea63",
+      "relations": 4
+    },
+    "68a848c7-eaff-4421-ad25-de21673ca40c": {
+      "kind": "REFERENCE",
+      "version": 4,
+      "slug": "bisect-the-packet-path-with-capture-points",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "56089eec-a603-4eac-bbb6-6fb44392ea63",
+      "relations": 5
+    },
+    "ca36f0db-9028-4761-91a8-afb7eb30f2b9": {
+      "kind": "REFERENCE",
+      "version": 4,
+      "slug": "verify-the-network-path-before-blaming-the-application",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "56089eec-a603-4eac-bbb6-6fb44392ea63",
+      "relations": 5
+    },
+    "3b05c1f0-13e9-414a-97a6-2078fb4bab26": {
+      "kind": "CONCEPT",
+      "version": 84,
+      "slug": "guest-block-io-path-to-virtqueue",
+      "publication": "PUBLISHED",
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 7
+    },
+    "ecaaa37d-7b33-4cbf-9bc5-4c6caad14ee5": {
+      "kind": "CONCEPT",
+      "version": 4,
+      "slug": "host-block-stack-under-the-vm",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 7
+    },
+    "892b6087-8961-486c-b4d9-d3dd46bc2605": {
+      "kind": "CONCEPT",
+      "version": 4,
+      "slug": "qemu-block-backend-forms",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 7
+    },
+    "8fafaeea-8746-4537-87a4-679a3a91aa4c": {
+      "kind": "CONCEPT",
+      "version": 5,
+      "slug": "write-completion-is-not-durability",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 6
+    },
+    "ae69e2e1-1a3b-4ae3-ae2a-572af07b95d7": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "disk-image-format-and-actual-host-usage",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 4
+    },
+    "be3c2c58-1ed4-4eae-876a-3114faa61c94": {
+      "kind": "QUESTION",
+      "version": 2,
+      "slug": "guest-fsync-latency-vs-host-storage-latency",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 7
+    },
+    "eead2379-94fe-463a-9e5e-06a01bf2105d": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "host-block-device-under-the-disk-image",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 6
+    },
+    "77aa0188-5c2b-4f47-bda7-7c66b084968d": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "host-io-scheduler",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 4
+    },
+    "480f86ac-86fb-4290-9bf5-584763aa1363": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "qemu-disk-cache-mode",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 4
+    },
+    "1f76d54b-bb17-4174-8128-0c2d71d4256f": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "vm-disk-backend-mapping",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 5
+    },
+    "ed64d4ff-aa01-48cc-ae68-6a683b025cde": {
+      "kind": "QUESTION",
+      "version": 3,
+      "slug": "vm1-storage-load-vs-vm2-latency",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 6
+    },
+    "decbab8d-9c98-45c6-b5b8-e6162e407299": {
+      "kind": "REFERENCE",
+      "version": 4,
+      "slug": "a-speedup-that-removed-durability-is-not-an-optimization",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 5
+    },
+    "274c5636-33f6-4c19-a54b-d2a96af31289": {
+      "kind": "REFERENCE",
+      "version": 3,
+      "slug": "confirm-the-disk-backend-on-the-host",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 6
+    },
+    "b1cda8c4-d31d-4ae4-a4d9-4103a0ab3109": {
+      "kind": "REFERENCE",
+      "version": 4,
+      "slug": "read-storage-before-blaming-cpu-for-latency",
+      "publication": null,
+      "projectId": "8a638411-2b21-4202-8bf0-720180d77897",
+      "topicId": "23314be2-7350-44f5-8989-575c3b40898f",
+      "relations": 6
+    }
+  }
+}
\ No newline at end of file
diff --git a/docs/keycloak-session-store/final/document.md b/docs/keycloak-session-store/final/document.md
index 3c9ed97..fb616e3 100644
--- a/docs/keycloak-session-store/final/document.md
+++ b/docs/keycloak-session-store/final/document.md
@@ -136,6 +136,23 @@ Keycloak 26 은 `persistent-user-sessions` 가 기본값이라 세션을 DB 에
 아닌데, 이 제약은 나중에 실제 비용을 청구했다. oauth2-proxy 실험(B-7)을 할 때
 네 번째 이름이 없어 **Grafana 의 `app2` 를 빌려야 했다.**
 
+**★ `oauth2-proxy` 는 인증서가 서기 전에는 못 뜬다**(2026-09-17, observed). 기동할 때
+OIDC 디스커버리를 먼저 하는데 그 주소가 `https://auth.hyeonworks.com/...` 이라, 인증서
+단계를 안 끝낸 실험대에서는 `CrashLoopBackOff` 로 끝난다.
+
+```
+[provider.go:55] Performing OIDC Discovery...
+[main.go:59] ERROR: Failed to initialise OAuth2 Proxy: ... error while discovery OIDC configuration:
+  Get "https://auth.hyeonworks.com/realms/keycloak-patterns/.well-known/openid-configuration":
+  dial tcp 100.83.212.4:443: connect: connection refused
+```
+
+`oauth2-proxy-secrets` 가 있고 이미지도 받아지는데 기동 자체가 안 된다 — B-7·B-7a·C-1
+과 B-4 의 5절이 **배포가 아니라 TLS 를 전제로 선다.** 같은 상태에서 Redis 쪽 명령은
+정상이었다 — `redis-cli dbsize` 가 `0`, `--scan --pattern '_oauth2_proxy-*'` 가 빈
+출력이다(observed).
+
+
 #### 그 12GB 를 어떻게 나눠 썼나
 
 계획서는 게스트를 `kc-lab-1 5120MB` · `kc-lab-2 4096MB` 로 그렸지만
@@ -1731,6 +1748,27 @@ spec:
                   number: 8083
 ```
 
+**★ 2026-09-17 에 Redis 를 내리기 전과 후를 같은 세 줄로 쟀다**(observed). 세 그룹이 어디서
+갈리는지가 이 절의 전부다.
+
+```
+                            Redis 살아 있을 때   Redis 0대일 때
+/actuator/health                 UP                 DOWN   ← redis: RedisConnectionFailureException
+/actuator/health/readiness       UP                 UP     ← kubelet 이 보는 경로
+/actuator/health/liveness        UP                 UP
+
+파드                             1/1 Running        1/1 Running (둘 다)
+Service 엔드포인트                ready true,true    ready true,true
+```
+
+**Redis 가 통째로 사라졌는데 쿠버네티스는 아무것도 안 한다.** 합산 `health` 만 `DOWN`
+이고 kubelet 이 보는 `readiness` 는 `UP` 이라 Service 가 두 파드로 트래픽을 계속 보낸다.
+`/actuator/health` 를 프로브로 걸었다면 두 파드가 동시에 빠져 전면 장애가 됐을 것이고,
+`readiness` 로 건 지금은 아무 신호도 안 난다 — 어느 쪽이 맞는지가 아니라 **무엇을
+고르면 무엇을 못 보게 되는지**가 이 세 줄에 있다. Redis 를 되살리자 `health` 가 다시
+`UP` 이 됐다(observed).
+
+
 **`deploy/lab/k8s/b7-oauth2-proxy.yaml`** — B-7 · B-7a. oauth2-proxy 와 cookie secret 둘. 비밀 값 3곳을 가렸다.
 
 ```yaml
@@ -2890,6 +2928,30 @@ Deployment 도 성립한다.
 
 ---
 
+
+### 2026-09-17 재현 — 어디까지 밟았고 무엇이 막았나
+
+기반 가이드 7단계로 실험대를 철거하고 새로 세운 뒤 26편을 순서대로 밟았다. **밟은
+범위를 편마다 적어 둔다** — 못 밟은 것을 밟은 것처럼 읽히지 않게 하려는 것이다.
+
+| 밟은 정도 | 편 |
+|---|---|
+| 끝까지 | A-0 · A-1 · A-2 · A-3 · A-4 · A-5 · A-6 · A-7 · A-7a · A-8 · B-3 · B-4 · B-5 · C-2 · D-1 · D-2 · D-3 |
+| 되는 데까지 (각 편의 「이 실험대에서 아직 못 밟은 단계」가 남은 것을 적는다) | B-0 · B-1 · B-2 · B-6 · B-7 · B-7a · C-1 · D-4 · D-4a |
+
+**막은 것은 하나로 모인다 — `https://auth.hyeonworks.com` 이 서지 않는다.** 둘이
+같이 필요하다.
+
+| 무엇 | 왜 없나 |
+|---|---|
+| 와일드카드 인증서 | DNS-01 에 Cloudflare API 토큰이 필요하고, 그 값은 이 저장소에 두지 않는다 |
+| 밖에서 실험대에 닿는 길 | 호스트의 libvirt `guest_input` 구멍. A-4 에서 확인했듯 배포된 유닛에 `ExecStartPost` 가 없고, 고치려면 호스트의 `sudo` 비밀번호가 필요하다 |
+
+그 둘이 없으면 인가 코드 흐름(브라우저 로그인)이 본체인 구간과 인증서 발급 자체가
+본체인 두 편이 성립하지 않는다. **대신 그 구간이 왜 막히는지는 추측이 아니라 실측으로
+적었다** — `oauth2-proxy` 의 `CrashLoopBackOff` 원문, `echo` 의 `issuer=000`,
+`certbot certificates` 의 `No certificates found` 가 각 편에 있다.
+
 ## 재현 가이드 26편과, 그것을 따라가다 드러난 결함
 
 발견을 적은 문서와 별개로, **직접 쳐서 다시 만드는** 가이드가
@@ -4639,7 +4701,35 @@ sudo kubectl -n keycloak-lab get pods   # 이렇게 치면 안 된다
 README 의 설명은 이렇다 — **「`sudo` 를 붙이면 root 환경으로 돌아 그 kubeconfig
 를 못 본다.」** root 홈에는 `~/.kube/config` 가 없으므로 `localhost:8080` 으로
 붙으려다 `connection refused` 로 끝난다. 클러스터 문제가 아니라 **누구의 설정
-파일을 읽느냐**의 문제다. 이 문서 앞쪽 「재현 가이드 26편과, 그것을 따라가다
+파일을 읽느냐**의 문제다.
+
+**★ 그런데 그 규칙은 `kc-lab-1` 이 아니라 lab host 의 규칙이다.** 2026-09-17 에
+기반 가이드 7단계를 그대로 밟아 실험대를 새로 세운 뒤 양쪽에서 쳐서
+확인했다(observed).
+
+| 어디서 | `kubectl …` | `sudo kubectl …` |
+|---|---|---|
+| lab host | **된다** | 안 된다 (root 홈에 kubeconfig 가 없다) |
+| `kc-lab-1` | **안 된다** | **된다** |
+
+`kc-lab-1` 에서 `sudo` 없이 치면 이렇게 끝난다.
+
+```
+level=warning msg="Unable to read /etc/rancher/k3s/k3s.yaml, please start server with --write-kubeconfig-mode or --write-kubeconfig-group to modify kube config permissions"
+error: error loading config file "/etc/rancher/k3s/k3s.yaml": open /etc/rancher/k3s/k3s.yaml: permission denied
+```
+
+`connection refused` 가 아니라 `permission denied` 다. **k3s 의 `kubectl` 은
+`~/.kube/config` 가 없으면 `/etc/rancher/k3s/k3s.yaml` 로 떨어지는데** 그 파일은
+`600 root` 라 일반 사용자가 못 읽는다. 기반 가이드는 그 파일을 **lab host 의
+`~/.kube/config` 로만** 복사하고 게스트의 사용자 홈에는 두지 않는다 — 워커 한 대가
+털리면 클러스터가 통째로 털리는 구성을 피하려고 일부러 그렇게 했다.
+
+**그래서 고칠 것은 `sudo` 가 아니라 기계 이름이다.** `kubectl` 과 `kubectl exec`
+로만 이루어진 블록은 `[kc-lab-1]` 이 아니라 **`[lab host]`** 에서 친다. 게스트
+셸이 필요한 것은 아래 문단이 적는 `nft`·`tc`·`systemctl`·`virsh`·`crictl` 뿐이고,
+그 블록만 `[kc-lab-1]`·`[kc-lab-2]` 로 남는다. `kc-lab-1` 에서 굳이 치겠다면
+`sudo kubectl` 이 맞고, 그때는 README 의 규칙이 반대로 뒤집힌다. 이 문서 앞쪽 「재현 가이드 26편과, 그것을 따라가다
 드러난 결함」이 센 `sudo kubectl` 905건이 같은 고장이고, 반입한 `source/` 의 A층
 열 편은 본문 명령 블록에 `sudo kubectl` 을 한 번도 쓰지 않는다(observed) — 전제
 한 줄만 옛 형태로 남았다.
@@ -5043,7 +5133,7 @@ echo "refresh=${#RT}자 access=${#AT}자"
 실패한 것이고 `echo "$R"` 로 에러 본문을 본다.
 
 JWT 의 가운데 토막이 클레임이다. 가이드는 **먼저 통째로 디코드해 눈으로 보고**
-그 다음에 sid 만 잘라낸다. 두 줄 다 **미검증**이다(unknown).
+그 다음에 sid 만 잘라낸다. **두 줄 다 2026-09-17 에 쳐서 확인했다**(observed).
 
 ```sh
 echo "$AT" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null; echo
@@ -5056,7 +5146,28 @@ echo "SID=$SID"
 ```
 
 base64 패딩 때문에 끝이 깨져 보일 수 있고(`2>/dev/null` 이 그 불평을 지운다),
-`sid` 는 앞쪽에 있어서 대개 보인다.
+`sid` 는 앞쪽에 있어서 대개 보인다. 2026-09-17 실측에서는 마지막 `"}` 두 글자가
+잘렸다(observed).
+
+```text
+0EPyjFf8PwNJ-1q7","scope":"profile email
+```
+
+**끝까지 보려면 패딩을 채운다.** 가이드에 없는 형태이고 2026-09-17 에 만들어
+쳤다(observed).
+
+```sh
+P=$(echo "$AT" | cut -d. -f2)
+case $(( ${#P} % 4 )) in 2) P="$P==";; 3) P="$P=";; esac
+echo "$P" | tr '_-' '/+' | base64 -d; echo
+```
+
+```text
+{"exp":1789620347,"iat":1789620287,"jti":"onltro:ba0c11cf-5e4a-a378-7268-4efd5cef32b8","iss":"https://auth.hyeonworks.com/realms/master","typ":"Bearer","azp":"admin-cli","sid":"jbFsOn6E0EPyjFf8PwNJ-1q7","scope":"profile email"}
+```
+
+클레임 이름이 `azp exp iat iss jti scope sid typ` 여덟이고 **`sub` 이 없다**는
+가이드의 관측도 이 형태로 다시 확인했다(observed).
 
 같은 sid 가 두 노드 모두에서 보이는지 묻는다. 먼저 `admin-cli` 의 내부 id 가
 필요한데, 가이드는 **응답을 한 번 그대로 보고** 무엇을 자르는지 눈으로 본 다음
@@ -5293,6 +5404,14 @@ kubectl -n keycloak-lab logs deploy/postgres --since=60s \
   | grep "$K1" | grep 'LOG:  execute'
 ```
 
+**★ 요청을 보내자마자 이 명령을 치면 한 줄도 안 나온다.** 이 트랜잭션은 마지막에서
+두 번째 문장이 `SET LOCAL synchronous_commit TO OFF` 라 커밋이 미뤄지고 로그 줄도
+그만큼 늦게 나온다. 2026-09-17 에 요청 직후에 쳤더니 `keycloak-1` 쪽에서는
+디스커버리 질의 한 줄만 나왔고, 같은 필터를 몇 초 뒤에 다시 치니 아래 여덟 줄이 다
+나왔다(observed). **그 첫 화면을 그대로 읽으면 「반대편은 DB 를 안 읽었다 =
+복제였다」는 정반대 결론이 나온다** — 이 절차가 가르려는 바로 그 둘이 뒤집힌다.
+몇 초 기다렸다 친다.
+
 **실측**(observed) — `04-read-path-sql.txt`
 
 ```text
@@ -5336,6 +5455,17 @@ kubectl -n keycloak-lab logs deploy/postgres --since=60s \
 것이다(observed). `04-read-path-sql.txt` 에 보존된 것은 sid 가 걸린 `DETAIL` 줄과 **시각
 없는** 문장 목록뿐이라, 경계 시각의 출처는 그 실험 기록 하나다 — 원문 보존 범위가 거기까지다.
 
+**★ 자기 화면에서 그 두 줄을 보는 명령이 이제 있다.** 가이드에는 없어서 2026-09-17 에
+만들어 쳤다(observed). sid 필터를 빼고 `DETAIL` 줄의 대괄호 안 pid 로 다시 거른다.
+
+```bash
+kubectl -n keycloak-lab logs deploy/postgres --since=5m \
+  | grep '{{PID}}' | grep -E 'BEGIN|COMMIT|synchronous_commit'
+```
+
+그날의 `{{PID}}` 는 `[915]` 였고, 같은 pid 의 `BEGIN` 과 `COMMIT` 사이에 위 여덟
+문장이 들어 있는 것이 그대로 보였다.
+
 **증거 파일에는 IP 대신 `[keycloak-0]` `[keycloak-1]` 이 적혀 있다.** 원래 실행
 스크립트가 `sed` 로 IP 를 파드 이름으로 바꿔 놓은 것이고, **당신 화면에는
 `10.42.0.35` 같은 IP 가 그대로 나온다.** pid 가 다른 것도 본다 — `81407` 은
@@ -5826,6 +5956,26 @@ keycloak-1: ...23002A0A:9C57  ...2B012A0A:1E78  01
 
 conntrack 은 **두 노드 모두에서** 본다.
 
+**★ 그런데 게스트에 `conntrack` 이 깔려 있지 않다.** cloud-init 이 까는 것은
+`curl` 과 `nftables` 뿐이라 이 명령은 `sudo: conntrack: command not found` 로
+끝나는데, **`2>/dev/null` 이 그 한 줄을 지우고 종료 코드도 `0` 이다.** 화면에는
+아무것도 안 나오고, 그 빈 화면은 「7800 연결이 없다 = 정책이 먹었다」로 읽힌다 —
+이 절이 보여 주려는 것과 정반대다. 2026-09-17 에 갓 만든 게스트에서 그대로
+겪었다(observed).
+
+두 노드 각각에 먼저 깐다. 깔고 나면 아래 두 줄이 그대로 나왔다(observed).
+
+```bash
+sudo apt install -y conntrack
+```
+
+패키지를 안 깔고 보려면 커널 표를 직접 읽는다. 같은 내용이고 앞에 `ipv4 2` 두
+칸과 `zone=0` 이 더 붙는 것만 다르다(observed).
+
+```bash
+sudo grep 7800 /proc/net/nf_conntrack
+```
+
 **이 실험대는 이렇게 했다**(observed)
 
 ```bash
@@ -5988,18 +6138,54 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 분단된 노드는 스스로 빠진다.
 
 ```bash
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount \
+kubectl -n keycloak-lab get pods \
+  -o "custom-columns=NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount" \
   | grep keycloak
 ```
 
+**★ `-o` 값을 따옴표로 묶는다.** 묶지 않으면 zsh 가 `[0]` 을 글로브로 읽어 명령이
+아예 안 돈다 — 이 실험대의 lab host 가 zsh 다(2026-09-17, observed).
+
+```
+zsh: no matches found: custom-columns=NAME:.metadata.name,READY:.status.containerStatuses[0].ready,...
+```
+
 **실측**(observed) — `11-service-impact.txt` — `keycloak-0 false 0`,
-`keycloak-1 true 0`. 까닭은 헬스 본문에 있다.
+`keycloak-1 true 0`. 2026-09-17 에도 같은 두 줄이 나왔다(observed).
+
+**★ 그 `false` 는 파드를 지우자마자 나오지 않는다.** readiness 프로브가
+`periodSeconds: 10` · `failureThreshold: 3` 이라 헬스가 먼저 `503` 이 되고 그로부터
+최대 30초 뒤에 조건이 뒤집힌다. 2026-09-17 에 지운 지 60초 시점에는 헬스가 이미
+`503` 인데 파드는 아직 `1/1 Ready=True` 였다(observed). 그 시점 화면만 보고 「분단이
+서비스에 안 잡혔다」로 읽지 않는다 — 1~2분 두고 다시 본다.
+
+까닭은 헬스 본문에 있다.
 
 ```bash
 kubectl -n keycloak-lab describe pod keycloak-0 | grep -A5 Conditions
 ```
 
+이 명령이 내는 것은 조건표다(2026-09-17, observed).
+
+```
+Conditions:
+  Type                        Status
+  PodReadyToStartContainers   True
+  Initialized                 True
+  Ready                       False
+  ContainersReady             False
+```
+
+**★ 아래 JSON 은 이 명령의 출력이 아니다.** 헬스 엔드포인트를 직접 쳐야 나온다.
+그 명령이 가이드에 없어서 2026-09-17 에 만들어 쳤다(observed).
+
+```bash
+K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
+kubectl -n keycloak-lab run hp --rm -i --restart=Never \
+  --image=curlimages/curl:8.11.1 --quiet --env="K0=$K0" \
+  --command -- sh -c 'curl -s "http://$K0:9000/health/ready"'
+```
+
 **실측**(observed)
 
 ```json
@@ -6015,10 +6201,19 @@ DOWN 이고, 쿠버네티스가 그 신고를 받아 처리한다.
 
 ```bash
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 ```
 
+여기도 `-o` 값을 따옴표로 묶는다. `[*]` 가 앞의 `[0]` 과 같은 이유로 글로브다.
+
 **실측**(observed) — `ready 주소: [10.42.0.35]`, `notReady : [10.42.1.67]`.
+2026-09-17 에는 이렇게 나왔다(observed).
+
+```
+NAME             ADDR                        READY
+keycloak-lxk8h   [10.42.0.13],[10.42.1.17]   true,false
+```
+
 **`kubectl get endpoints` 는 쓰지 않는다** — v1.33 부터 deprecated 라 경고가
 뜬다.
 
@@ -6026,6 +6221,14 @@ kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak
 curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master
 ```
 
+**★ 인증서 단계를 건너뛴 실험대라면** 443 을 듣는 것이 없어 여기는 `000` 이다. 그때는
+TLS 를 빼고 `Host` 헤더를 실어 엣지에 친다 — 2026-09-17 에 이 형태로 `200` 을
+받았다(observed).
+
+```bash
+curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: auth.hyeonworks.com' http://192.168.122.10/realms/master
+```
+
 **실측**(observed) — 정문은 `HTTP 200`, 토큰 발급도 `HTTP 200`. **분단된 노드가
 스스로 로드밸런서에서 빠졌고 서비스는 계속됐다.** liveness 였다면 재시작을
 반복했을 텐데 재시작해도 안 나아지는 문제이므로 **readiness(격리)가 맞는
@@ -6065,6 +6268,21 @@ curl -s -w '\n%{http_code}\n' -X POST "http://$K0:8080$TOK" \
   -d grant_type=refresh_token -d client_id=admin-cli -d "refresh_token=$RT"
 ```
 
+**★ [4] 는 응답 본문을 통째로 찍는다.** 분단 중에는 그 요청이 성공하므로
+`access_token` 과 `refresh_token` 이 화면에 그대로 나오고, 화면을 갈무리하면 증거
+파일에도 그대로 들어간다. 2026-09-17 실행에서 실제로 그렇게 나와 길이만 남기고
+가렸다(observed). 판정에 필요한 것은 코드와 `error` 뿐이므로, 갈무리할 생각이면
+아래 형태로 친다.
+
+```sh
+curl -s -X POST "http://$K0:8080$TOK" \
+  -d grant_type=refresh_token -d client_id=admin-cli -d "refresh_token=$RT" \
+  -w '\n%{http_code}\n' -o /tmp/r
+sed -n 's/.*"error":"\([^"]*\)".*/error=\1/p' /tmp/r
+```
+
+`200` 이면 `error` 줄이 안 나오고, 그 없음이 곧 「로그아웃이 전파되지 않았다」다.
+
 **실측**(observed) — `09-cross-node-under-partition.txt`
 
 ```text
@@ -6074,6 +6292,10 @@ curl -s -w '\n%{http_code}\n' -X POST "http://$K0:8080$TOK" \
   [4] keycloak-0 에서 재갱신 시도 HTTP 200      ← 400 이어야 했다
 ```
 
+**2026-09-17 에 이 네 단계를 다시 쳐서 같은 네 값을 받았다**(observed) —
+`sid=XliiKcW3DYw4hY_a3m2FX6e4` · `200` · `204` · `200`. 정책을 지우자 30~60초
+안에 두 노드가 다시 `2` 를 보고했고 두 파드 모두 `1/1` 로 돌아왔다(observed).
+
 **[2] 세션 공유는 예측이 맞았다.** 클러스터가 갈라졌는데도 한쪽에서 만든 세션을
 반대쪽이 갱신했다 — 세션은 7800 으로 다니지 않는다. **[4] 로그아웃 전파는
 예측이 틀렸다.** 대조군에서 400 이던 곳이 200 이다.
@@ -6557,12 +6779,28 @@ Caused by: java.net.ConnectException: Connection refused
 연결이 즉시 거부되기 때문이다.
 
 ```bash
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount \
+kubectl -n keycloak-lab get pods -o "custom-columns=NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount" \
   | grep keycloak
 ```
 
-**실측**(observed) — `keycloak-0 false 0`, `keycloak-1 false 0`. `READY` 가
+**실측**(observed) — `keycloak-0 false 0`, `keycloak-1 false 0`. 2026-09-17 에도
+같은 두 줄을 받았다(observed).
+
+**★ 그 `false` 는 DB 를 내리자마자 나오지 않는다.** readiness 프로브가
+`periodSeconds: 10` · `failureThreshold: 3` 이라 헬스가 먼저 실패하고 그로부터
+최대 30초 뒤에 조건이 뒤집힌다. 2026-09-17 에 내린 직후에는 네 경로가 이미 전부
+`500` 인데 파드는 아직 `true true` 였고 정문도 `200` 이었다. 약 50초 뒤에
+`false false` · 정문 `503` 이 됐다(observed).
+
+```
+정지 직후      네 경로 500 500 500 500 · ready true,true  · 정문 200
+약 50초 뒤     ready false,false · 엔드포인트 false,false · 정문 503
+```
+
+그 50초 사이의 화면을 보고 「DB 가 없어도 멀쩡하다」로 읽지 않는다. 이미 500 인데
+아직 트래픽에서 안 빠졌을 뿐이고, 이 절이 잡으려는 것도 그 어긋남이다.
+
+`READY` 가
 `false` 인데 **`RESTARTS` 가 여전히 `0`** 이다. 파드는 죽지 않았고 트래픽에서
 빠졌을 뿐이다. `RESTARTS` 가 오르고 있으면 liveness 가 실패하는 것이고, 그
 상태에서 무엇을 재든 「DB 없는 Keycloak」이 아니라 「재시작 중인 Keycloak」을 재는
@@ -6669,7 +6907,7 @@ curl -s -o /dev/null -w 'well-known %{http_code}\n' \
 
 ```bash
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 ```
 
 **실측**(observed) — `04-health-and-service.txt`
@@ -6821,8 +7059,7 @@ deployment "postgres" successfully rolled out
 답하려던 물음(「사람 개입이 필요한가」)이 사라진다. 15초 간격으로 몇 번 친다.
 
 ```bash
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount \
+kubectl -n keycloak-lab get pods -o "custom-columns=NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount" \
   | grep keycloak
 curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master
 ```
@@ -6838,8 +7075,7 @@ curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/mast
 재시작 없이 회복한 것이 맞는지 따로 센다.
 
 ```bash
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount | grep keycloak
+kubectl -n keycloak-lab get pods -o "custom-columns=NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount" | grep keycloak
 ```
 
 **실측**(observed) — `keycloak-0  0`, `keycloak-1  0`. 주입 검증에서 본 값
@@ -7184,14 +7420,43 @@ while [ "$i" -lt 400 ]; do
          -d username=admin -d "password=$PW" \
        | sed -n 's/.*"access_token":"\([^"]*\)".*/\1/p')
   if [ -n "$AT" ]; then
-    echo "$AT" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null \
-      | sed -n 's/.*"sid":"\([^"]*\)".*/\1/p' >> /tmp/sids
+    SID=$(echo "$AT" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null \
+          | sed -n 's/.*"sid":"\([^"]*\)".*/\1/p')
+    [ -n "$SID" ] && echo "$SID" >> /tmp/sids
   fi
   i=$((i + 1))
 done
 echo "루프 종료: $(wc -l < /tmp/sids) 건"
 ```
 
+**★ `sed` 의 출력을 파일로 바로 흘리지 않는다.** 변수에 받아 `echo` 로 다시 쓴다.
+탐침 이미지의 셸이 busybox 이고 그 `sed` 는 **입력에 끝 개행이 없으면 출력에도 안
+붙인다.** `base64 -d` 가 내놓는 JSON 에는 끝 개행이 없으므로, 바로 `>>` 로 흘리면
+sid 가 줄바꿈 없이 이어 붙어 **파일 한 줄**이 된다. 2026-09-17 에 그대로
+겪었다(observed) — 로그인 217건이 DB 에 들어갔는데 파일은 이랬다.
+
+```
+0 /tmp/sids
+9384 /tmp/sids
+```
+
+`wc -l` 이 `0` 이고 `wc -c` 는 9384 다. **데이터는 다 있는데 줄이 하나도 없다.**
+이 파일을 `wc -l`·`sort -u`·`comm` 으로 세는 것이 이 실험의 측정 전부이므로, 이
+상태로는 손실 건수가 언제나 0 으로 나온다. `echo` 로 감싼 형태로 열 번 돌려
+`10 줄 / 250 바이트` 를 받아 고쳤다(observed).
+
+busybox 의 `sed` 가 그렇게 동작하는 것을 따로 확인했다(observed).
+
+```
+printf "%s" '{"sid":"ABC"}' | sed -n 's/.*"sid":"\([^"]*\)".*/\1/p' | od -c
+0000000   A   B   C
+0000003
+```
+
+원래 실행이 낸 「클라이언트가 200 을 받은 로그인 수: 0」 도 이 모양과 구별되지
+않는다. 그때는 배경 서브셸이 죽은 것으로 적었고 그것도 사실이지만, **이 결함은
+지금도 그대로 있고 배경 서브셸을 안 써도 같은 0 이 나온다**(observed).
+
 `/tmp/sids` 에는 **클라이언트가 `200` 과 토큰을 실제로 받은 것만** 쌓인다. `AT`
 가 비면 아무것도 안 적으므로 **이 파일이 「서버가 COMMIT 했다고 응답한 것」의
 목록**이고, 그게 이 실험의 시험군이다.
@@ -7446,8 +7711,7 @@ kubectl -n keycloak-lab logs deploy/postgres --since=5m \
 `ready to accept connections` 의 **시각이 새로 찍혔다.**
 
 ```bash
-kubectl -n keycloak-lab get pods -l app=postgres -o custom-columns=\
-NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount
+kubectl -n keycloak-lab get pods -l app=postgres -o "custom-columns=NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount"
 ```
 
 `RESTARTS` 는 `0` 이다. 컨테이너의 PID 1 인 postmaster 는 **살아 있고 자식만
@@ -7525,6 +7789,28 @@ comm -23 /tmp/a.txt /tmp/b.txt
 **로그인이 성공했다고 응답받았는데 세션이 존재하지 않는다.** 153건 중 4건,
 **약 2.6%** 다.
 
+**★ 2026-09-17 에 새 실험대에서 다시 재니 395건 중 3건이었다**(observed). 세 시도를
+순서대로 밟았고 앞의 둘은 그때도 0건이었다.
+
+```
+시도 ① --grace-period=0 --force   유실 0건 — 새 파드 로그가 `database system was shut down at …`
+시도 ② kill -9 1                  유실 0건 — RESTARTS 0, 파드 이름도 그대로
+시도 ③ 백엔드 PID 39 에 SIGKILL   유실 3건 — 클라이언트 395 · DB 392
+```
+
+시도 ③ 의 로그가 남긴 것도 같았다.
+
+```
+server process (PID 39) was terminated by signal 9: Killed
+all server processes terminated; reinitializing
+database system was not properly shut down; automatic recovery in progress
+redo starts at 0/1F80A00
+```
+
+**건수는 실행마다 다르다.** 크래시 순간에 아직 디스크로 못 내려간 트랜잭션만
+사라지므로 로그인 속도와 `wal_writer_delay` 와 크래시 타이밍이 그 수를 정한다.
+판정에 쓰는 것은 숫자가 아니라 **0 이 아니라는 것**이다.
+
 ```bash
 comm -23 /tmp/a.txt /tmp/b.txt | wc -l
 ```
@@ -7965,6 +8251,21 @@ done
   +60초  node=NotReady | keycloak-0=Running postgres-7b474b88c8-2gf27=Running | 외부 HTTP 503
 ```
 
+**★ 2026-09-17 에 새 실험대에서 다시 재니 같은 모양이었다**(observed). 차단은
+`14:39:28` 이다.
+
+```
+  14:39:56 (+28초)  kc-lab-2=Ready    | keycloak-0=Running postgres=Running | 정문 000
+  14:40:34 (+66초)  kc-lab-2=NotReady | keycloak-0=Running postgres=Running | 정문 503
+  14:42:41 (+3분)   kc-lab-2=NotReady | keycloak-0=Running postgres=Running | 정문 503
+```
+
+넘어가는 대목은 같고 초는 실행마다 다르다. 30초 간격으로 쟀으므로 이번 판에서는
+`+28초` 와 `+66초` 사이 어디쯤이고, `node-monitor-grace-period` 40초가 그 범위에
+들어간다. 그 뒤로 3분이 지나도 두 파드는 계속 `Running` 이었다. 이벤트에도
+`NodeNotReady` 두 줄과 `keycloak-1` 의 `context deadline exceeded` 가 문서대로
+나왔다(observed).
+
 `+30초` 줄과 `+45초` 줄 사이에서 노드 상태가 넘어간다.
 kube-controller-manager 는 kubelet 의 하트비트가
 `node-monitor-grace-period`(이 실험대에서 **40초**) 동안 없어야 `NotReady` 로
@@ -8014,8 +8315,7 @@ API 서버가 `kc-lab-1:6443` 에 있었으므로 **당연한 결과**다. 4a 
 **죽은 파드가 산 파드보다 건강해 보인다.**
 
 ```bash
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,PHASE:.status.phase,READY:.status.containerStatuses[0].ready,NODE:.spec.nodeName
+kubectl -n keycloak-lab get pods -o "custom-columns=NAME:.metadata.name,PHASE:.status.phase,READY:.status.containerStatuses[0].ready,NODE:.spec.nodeName"
 ```
 
 **실측**(observed) — `03-state-during-loss.txt`
@@ -8150,6 +8450,22 @@ watch -n 30 'kubectl -n keycloak-lab get pods -o wide'
 `Pending` 이다. 축출이 시작됐는데 `Terminating` 이 안 끝나고 새 파드는 뜨지
 못하며, **두 문제는 원인이 다르다.**
 
+**★ 2026-09-17 에 새 실험대에서 다시 재니 같은 모양이었다**(observed). 차단
+`05:39:28` 에 대해 두 파드의 `deletionTimestamp` 가 `05:44:17` 로 찍혔다 —
+**4분 49초**다.
+
+```
+keycloak-0                  Terminating  kc-lab-2   deletionTimestamp=2026-09-17T05:44:17Z
+postgres-7b474b88c8-prlxx   Terminating  kc-lab-2   deletionTimestamp=2026-09-17T05:44:17Z
+postgres-7b474b88c8-5zp6v   Pending      <none>     deletionTimestamp=<none>
+keycloak-1                  Running      kc-lab-1   deletionTimestamp=<none>
+```
+
+**StatefulSet 과 Deployment 의 처지가 그대로 갈린다.** 새 이름으로 생긴 것은
+postgres 쪽뿐이고 `keycloak-0` 은 대체 파드 없이 `Terminating` 으로만 남는다.
+StatefulSet 은 이름이 고정이라 같은 이름의 파드를 둘로 만들 수 없고, 죽은 노드의
+kubelet 이 「지웠다」고 답해 주지 못하므로 그 이름이 영원히 안 비워진다.
+
 ```bash
 kubectl -n keycloak-lab get pods --field-selector=status.phase=Pending
 kubectl -n keycloak-lab describe pod postgres-7b474b88c8-9cmsv | grep -A6 Events
@@ -8517,6 +8833,16 @@ sudo iptables -t raw -F PREROUTING ; sudo iptables -F FORWARD
 ssh kc-lab-2 'sudo iptables -t raw -F PREROUTING ; sudo iptables -F FORWARD'
 ```
 
+**★ 2026-09-17 에는 lab host 에서 양쪽을 같은 형태로 쳤다**(observed). kubectl 이 lab
+host 에서 도니 게스트에 들어갈 일이 `iptables` 뿐이고, 그러면 두 노드를 같은 모양으로
+다룰 수 있다.
+
+```bash
+ssh kc-lab-1 'sudo iptables -S FORWARD'
+ssh kc-lab-1 'sudo iptables -t raw -F PREROUTING'
+ssh kc-lab-1 'sudo iptables -F FORWARD'
+```
+
 **따라 하는 사람은** 반대 노드 쪽을 나눌 수 있다. 먼저 붙고, 붙은 다음에 두
 줄을 따로 친다. **행동 하나가 명령 하나**가 된다. 이 나눈 형태는 이 실험대에서
 치지 않았다(unknown).
@@ -8775,6 +9101,24 @@ sudo iptables -t raw -I PREROUTING 1 -p tcp -d $K1 --dport 57800 -j DROP
 date '+%H:%M:%S 주입'
 ```
 
+**★ 그 두 줄을 게스트 셸에서 치면 안 된다.** `$K1` 은 `[lab host]` 셸의 변수이고
+`ssh kc-lab-1` 로 들어간 셸에는 없다. 빈 문자열이 들어가면 `-d` 없는 규칙이 걸려
+**7800 으로 가는 모든 패킷**이 끊긴다. 2026-09-17 에 게스트 셸에서 확인했다(observed).
+
+```
+게스트 셸의 K1=[]
+```
+
+lab host 에서 한 줄 형태로 친다. 큰따옴표가 값을 여기서 펴서 보낸다.
+
+```bash
+ssh kc-lab-1 "sudo iptables -t raw -I PREROUTING 1 -p tcp -d $K1 --dport 7800  -j DROP"
+ssh kc-lab-1 "sudo iptables -t raw -I PREROUTING 1 -p tcp -d $K1 --dport 57800 -j DROP"
+ssh kc-lab-1 'sudo iptables -t raw -L PREROUTING -n -v'
+ssh kc-lab-1 'sudo iptables -t raw -L PREROUTING -n -v --line-numbers'
+ssh kc-lab-1 'sudo conntrack -L 2>/dev/null | grep 7800'
+```
+
 **실측**(observed) — `04-correct-direction.txt`
 
 ```text
@@ -9050,7 +9394,7 @@ kubectl -n observability exec deploy/prometheus -- \
 ```bash
 kubectl -n keycloak-lab get pods | grep keycloak
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 curl -s -o /dev/null -w '%{http_code}\n' --max-time 8 https://auth.hyeonworks.com/realms/master
 ```
 
@@ -9772,6 +10116,19 @@ ssh kc-lab-2 'sudo tc -s qdisc show dev flannel.1 | grep -A2 netem'
 ssh kc-lab-2 'sudo tc filter show dev flannel.1'
 ```
 
+**★ 2026-09-17 에 그 줄을 쳐서 이렇게 나왔다**(observed).
+
+```
+filter parent 1: protocol ip pref 3 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 *flowid 1:3 not_in_hw
+  match 0a2a011d/ffffffff at 12
+```
+
+`0a2a011d` 가 `10.42.1.29` 를 16진수로 적은 것이고, 그 값이 지금 postgres 의 IP 와
+같은지가 필터가 제 대상을 고르고 있다는 증거다. 같은 날 `netem` 카운터는 `83 pkt`
+이었고 로그인 한 번이 `0.067s` 에서 `1.87s` 로 늘었다 — 문서가 적은 `1,872ms` 와
+28배가 그대로였다(observed).
+
+
 #### 관찰
 
 단일 요청부터 본다. 앞에서 친 것과 **똑같은 명령**이다.
@@ -9899,7 +10256,23 @@ sort  /tmp/load.txt      # 사전순 — 10.5 가 3.4 앞에 온다
 sort -g /tmp/load.txt    # 수치순 — 이걸 써야 한다
 ```
 
-**시간 값을 정렬할 때는 `sort -g`.** 이걸 놓치면 「최대값」을 잘못 읽는다.
+**그런데 원 가이드의 이 처방은 이 파일에서 안 듣는다** (2026-09-17 에 같은 모양의
+줄로 직접 돌려 확인했다). `/tmp/load.txt` 의 각 줄이 `200 1.911191` 처럼 **전부
+같은 `200` 으로 시작해서**, `sort -g` 는 줄 앞머리 수치를 비교하다 전부 동률이
+되고 마지막에 바이트 순으로 떨어진다. 그래서 `sort` 와 출력이 **똑같다.**
+
+정렬할 열을 짚어 주어야 듣는다.
+
+```bash
+sort -g -k2 /tmp/load.txt
+```
+
+**이 부에 이미 있는 형태를 쓰는 편이 낫다** — 위 §6-2 의
+`awk '{print $2}' /tmp/load.txt | sort -g` 는 `awk` 가 둘째 열만 남기므로 제대로
+돈다. 최대값 하나만 볼 때는 거기에 `| tail -1` 을 붙인다.
+
+**시간 값을 정렬할 때는 열을 짚는다.** 이걸 놓치면 「최대값」을 잘못 읽고,
+`sort -g` 를 붙였다는 것만으로 고쳤다고 믿게 된다.
 
 **② 숫자를 순서대로 놓으면 계단이다.**
 
@@ -10098,7 +10471,7 @@ kubectl -n keycloak-lab delete pod a6-probe --ignore-not-found
 | 지연이 양쪽 다 늘었다 | `netem` 을 `root` 에 직접 붙였다 | `prio` + `filter` 로 골라 낸다 |
 | `kubectl` 이나 SSH 까지 느려졌다 | `enp1s0` 에 걸었다 | `tc qdisc del dev enp1s0 root` |
 | 20줄 중 몇 줄만 온다 | **`kubectl run --rm -i` 로 동시 실행하면 stdout 이 샌다** | 상주 파드 + 파일 |
-| 최대값이 `9.1` 로 보인다 | `sort` 가 **사전순**이다 | `sort -g` |
+| 최대값이 `9.1` 로 보인다 | `sort` 가 **사전순**이고, `sort -g` 만 붙여도 줄이 전부 `200` 으로 시작해 안 듣는다 | `sort -g -k2`, 또는 §6-2 의 `awk '{print $2}' … \| sort -g` |
 | `blocking_time` 이 0 이다 | 부하가 끝나고 한참 뒤에 읽었다 | **부하 직후**에 읽는다 |
 | `awaiting_count` 가 늘 0 이다 | **순간값이다** | 부하가 도는 **중에** 읽는다 |
 | 로그인이 전부 `401` | `PW` 가 안 넘어갔다 | `exec a6-probe -- sh -c 'echo ${#PW}'` |
@@ -10745,6 +11118,21 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c \
    volatile   :  keycloak-1 이 7800 을 통해 keycloak-0 에게 물어서 답했다
 ```
 
+**★ 2026-09-17 에 새 실험대에서 그 둘을 이어서 쳤다**(observed). 같은 명령 한 벌이
+전환 전후로 정반대 답을 냈다.
+
+```
+volatile · 분단 없음    교차 노드 refresh 200 · DB 세션 행 (0 rows)
+                        캐시 keycloak-0 sessions 1 · keycloak-1 sessions 0
+volatile · 7800 차단    교차 노드 refresh 400 · 로그아웃 400
+                        발급 노드 재갱신 400 invalid_grant / Invalid refresh token
+```
+
+**persistent 에서는 같은 것을 재면 `200` 이 나왔다.** A-1 에서 7800 을 막고 잰 값이
+`200`·`204`·`200` 이었고 여기서는 `400`·`400`·`400` 이다. 그 한 칸이 두 모드의 차이를 전부
+말한다.
+
+
 **같은 200 인데 다른 까닭이다.** 겉보기 결과만으로는 구별이 안 되고, 구별하려면
 그 경로를 끊어 봐야 한다.
 
@@ -11637,6 +12025,23 @@ kubectl -n keycloak-lab logs keycloak-0 --tail=150 \
   | grep -oE 'JDBC exception executing SQL \[[^]]*\] \[[^]]*\]'
 ```
 
+**★ 그 패턴은 속 예외가 그 문구일 때만 잡는다.** 속 예외는 DB 를 언제 끊었느냐에 따라
+둘로 갈리고, 2026-09-17 에는 `--tail=150` 과 이 패턴으로 **한 줄도 안 나왔다**(observed).
+
+```
+끊는 중에 걸린 요청   GenericJDBCException: JDBC exception executing SQL [FATAL: terminating connection due to administrator command]
+이미 사라진 뒤의 요청 org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection [Connection to postgres:5432 refused. …]
+```
+
+둘 다 앞머리가 `KC-SERVICES0015: Unexpected error when authenticating client` 이므로
+그것으로 걸고 `--tail` 도 늘린다 — 재시작 직후에는 기동 로그가 길어 150 줄로는 이
+줄까지 못 거슬러 올라간다.
+
+```bash
+kubectl -n keycloak-lab logs keycloak-0 --tail=400 \
+  | grep -oE 'KC-SERVICES0015[^[]*\[[^]]*\]'
+```
+
 **실측**(observed) — 같은 파일
 
 ```text
@@ -12426,7 +12831,7 @@ kubectl -n observability exec deploy/prometheus -- \
 
 ```bash
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 ```
 
 **`kubectl get endpoints` 는 쓰지 않는다.** v1.33 부터 deprecated 라 경고가
@@ -12709,6 +13114,51 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   -s 'redirectUris=["https://app1.hyeonworks.com/*"]'
 ```
 
+**★ B-0 을 그대로 밟으면 B-3 이 못 돈다**(2026-09-17, observed). 이 클라이언트와
+사용자에 두 가지가 빠져 있고, B-0 의 로그인은 인가 코드 흐름이라 **B-0 을 끝까지
+밟아도 안 드러난다.**
+
+| B-3 의 5번에서 나오는 것 | 무엇이 빠졌나 | 어디서 고치나 |
+|---|---|---|
+| `unauthorized_client` · `Client not allowed for direct access grants` | 클라이언트의 `directAccessGrantsEnabled` 가 `false` | 위 `create clients` 에 `-s directAccessGrantsEnabled=true` |
+
+고친 뒤의 클라이언트 생성은 이 줄이 하나 더 붙는다.
+
+```bash
+  -s directAccessGrantsEnabled=true \
+```
+| `invalid_grant` · `Account is not fully set up` | `labuser` 의 `emailVerified` 가 `false` 이고 이메일·이름 칸이 비었다 | 사용자 생성 뒤 아래 한 묶음 |
+
+```bash
+U=$(kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
+     get users -r keycloak-patterns -q username=labuser --fields id --format csv --noquotes | tr -d '\r')
+kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
+  update users/$U -r keycloak-patterns \
+  -s emailVerified=true -s email=labuser@example.invalid \
+  -s firstName=Lab -s lastName=User -s 'requiredActions=[]'
+```
+
+변수 이름을 `UID` 로 짓지 않는다 — zsh 에서 읽기 전용 숫자 변수라
+`bad math expression` 으로 끝난다(observed).
+
+**그리고 B-0 이 「없다」고 적어 둔 대조를 만들었다.** 매니페스트의
+`KEYCLOAK_CLIENT_SECRET` 과 Keycloak 쪽 클라이언트 비밀이 같은지를 값을 안 찍고 본다.
+2026-09-17 실측은 `매니페스트 14자 · Keycloak 14자` 와 `두 값이 같다` 였다(observed).
+
+```bash
+A=$(kubectl -n keycloak-lab get secret bff-secrets \
+      -o jsonpath='{.data.KEYCLOAK_CLIENT_SECRET}' | base64 -d)
+C=$(kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
+      get clients -r keycloak-patterns -q clientId=bff-confidential \
+      --fields id --format csv --noquotes | tr -d '\r')
+S=$(kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
+      get clients/$C/client-secret -r keycloak-patterns \
+      --fields value --format csv --noquotes | tr -d '\r')
+echo "매니페스트 ${#A}자 · Keycloak ${#S}자"
+[ "$A" = "$S" ] && echo "두 값이 같다" || echo "두 값이 다르다"
+```
+
+
 `accessTokenLifespan=60` 은 **B-3 을 위해 미리 짧게 잡는 것이다.** 만료를 기다리는
 시간이 짧아야 refresh 경쟁이 재현된다. 여기서 정해 두면 나중에 realm 을 다시 안 만든다.
 
@@ -13052,6 +13502,23 @@ JSON 을 파이썬 한 줄로 파싱하려다 따옴표 이스케이프에서 
   전체 빈 수: 321
 ```
 
+**★ 2026-09-17 에 저장소를 붙인 상태에서 같은 두 줄을 쳤다**(observed) — 그때까지
+미검증이던 형태다.
+
+```
+빈 개수: 437
+authorizedClientService     -> org.springframework.security.oauth2.client.JdbcOAuth2AuthorizedClientService
+authorizedClientRepository  -> …AuthenticatedPrincipalOAuth2AuthorizedClientRepository
+RedisSessionConfiguration   -> org.springframework.boot.autoconfigure.session.RedisSessionConfiguration
+```
+
+**`321` 이 아니라 `437` 인 것이 이 측정이 쓸모 있다는 증거다.** `321` 은 저장소를 하나도
+안 붙였을 때의 수이고, Redis 세션과 JDBC 토큰 저장소가 붙으면 빈이 그만큼 늘어난다 —
+**빈 수 하나로 지금 어느 상태인지 알 수 있다.** 같은 날 B-2 의 표도 봤다: 표는 생겨
+있고 행은 `0` 이었다(observed). `\d` 가 정의를 돌려주므로 「배선이 됐다」로 읽기 쉬운데,
+행은 브라우저 로그인이 한 번 끝나야 생긴다.
+
+
 ```text
   --- 세션 · 토큰 저장소 관련 ---
     authorizedClientManager      -> AuthorizedClientServiceOAuth2AuthorizedClientManager
@@ -15218,6 +15685,24 @@ done
   요청 5: HTTP 200  {"access_token":"...(발급됨)
 ```
 
+**★ 2026-09-17 에 같은 모양이 다시 나왔다**(observed). 손으로 치기 좋게 고친 5-way
+루프도 그대로 돌았다 — 그때까지 미검증이던 형태다.
+
+```
+요청 1: HTTP 400  Session doesn't have required client
+요청 2: HTTP 400  Session doesn't have required client
+요청 3: HTTP 400  Maximum allowed refresh token reuse exceeded
+요청 4: HTTP 200  (발급됨)
+요청 5: HTTP 400  Session doesn't have required client
+이긴 요청의 새 refresh 길이: 810
+그 토큰을 다시 쓰면: 400  Session doesn't have required client
+```
+
+**몇 번 요청이 이기는지는 실행마다 다르다.** 위 실측은 5번이고 2026-09-17 은 4번이다.
+판정에 쓰는 것은 번호가 아니라 **`200` 이 하나이고 그 하나가 받은 토큰도 안 통한다**는
+두 가지다.
+
+
 **성공 개수가 아니라 오류 메시지가 두 종류인 것**을 본다.
 
 | 메시지 | 뜻 |
@@ -15717,6 +16202,31 @@ Keycloak 이 `iss` 클레임과 리다이렉트를 만들 때 쓰는 값들이
 curl -s https://app1.hyeonworks.com/api/echo | grep -o '"x-forwarded-proto":\[[^]]*\]'
 ```
 
+그 형태는 못 잡는다. 공백을 허용한다.
+
+```bash
+curl -s https://app1.hyeonworks.com/api/echo | grep -o '"x-forwarded-proto" *: *\[[^]]*\]'
+```
+
+**★ 콜론을 붙여 쓴 형태는 한 줄도 못 잡는다**(2026-09-17, observed). `echo` 가 응답을
+들여쓰고 콜론 양옆에 공백을 넣어 찍기 때문이고, 이 문서의 실측은 줄바꿈을 없애고 옮겨
+적은 것이라 그 공백이 안 보인다. 실제 화면과 각 주입의 도착 값은 이렇다(observed).
+
+```
+  "x-forwarded-proto" : [ "http" ]
+  "x-auth-request-roles" : [ "admin", "editor" ]        ← 동명 헤더 둘
+  "x-auth-request-roles" : [ "admin,editor,viewer" ]    ← 쉼표로 구분한 값 하나
+  "x-auth-request-roles" : [ "role-with,comma" ]        ← 값 안에 쉼표
+  "x-auth-request-email" : [ "attacker@evil.invalid" ]  ← 위조한 신원이 그대로 닿았다
+  "x-auth-request-user" : [ "attacker" ]
+```
+
+뒤의 두 줄은 대조군에서 비어 있던 칸이므로, **보낸 것이 엣지를 지나 앱까지 닿았다**는
+뜻이다. 가운데 두 줄은 도착 시점에 구별되지 않는다 — 쉼표로 자르는 방식이 성립하지
+않는 근거다. `"x-auth-request[^]]*\]` 처럼 이름 뒤에 `:` 를 요구하지 않는 형태는 그대로
+써도 걸린다.
+
+
 **형태**(모양은 observed)
 
 ```text
@@ -15781,16 +16291,16 @@ proxy_set_header X-Forwarded-Proto https;   # 설정한 것 → 덮어쓴다
 
 ```bash
 curl -s -H 'X-Auth-Request-Roles: admin' -H 'X-Auth-Request-Roles: editor' \
-  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles":\[[^]]*\]'
+  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles" *: *\[[^]]*\]'
 ```
 
 값 안의 쉼표를 구분자와 구별할 수 있는지 본다.
 
 ```bash
 curl -s -H 'X-Auth-Request-Roles: admin,editor,viewer' \
-  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles":\[[^]]*\]'
+  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles" *: *\[[^]]*\]'
 curl -s -H 'X-Auth-Request-Roles: role-with,comma' \
-  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles":\[[^]]*\]'
+  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles" *: *\[[^]]*\]'
 ```
 
 크기를 키울 때는 **먼저 한 번 읽는 형태로 본다.** 무엇이 돌아오는지 봐야 뒤의 숫자를 읽을 수
@@ -16797,7 +17307,7 @@ curl -s https://app1.hyeonworks.com/actuator/health/readiness; echo
 
 ```bash
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=bff \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 ```
 
 **실측**(observed) — `03-health-groups.txt`
@@ -17300,7 +17810,25 @@ echo "$OLD" | cut -d. -f1 | tr '_-' '/+' | base64 -d 2>/dev/null; echo
 **형태**(모양은 observed)
 
 ```json
-{"alg":"RS256","typ":"JWT","kid":"OY-caYDNGoP4HMAz-Q9UPTU-DM1i896NuzUZu6gfCqM"}
+{"alg":"RS256","typ" : "JWT","kid" : "OY-caYDNGoP4HMAz-Q9UPTU-DM1i896NuzUZu6gfCqM"}
+```
+
+**★ 콜론 양옆의 공백을 눈여겨본다.** Keycloak 은 토큰 **헤더**를 `"typ" : "JWT"` 처럼
+공백을 넣어 찍고 페이로드는 `"sid":"…"` 처럼 붙여 찍는다. 그래서 페이로드에서 되던
+`sed` 가 헤더에서는 빈손으로 돌아온다. 2026-09-17 에 같은 토큰 하나로 두 형태를
+나란히 쳤다(observed).
+
+```
+헤더: {"alg":"RS256","typ" : "JWT","kid" : "HKy0uQhg-vlQackK6-oj3hW6vKbDj-95Wlvdgl37cGg"}
+'"kid":"' 로 뽑으면   : []
+'"kid" *: *"' 로 뽑으면: [HKy0uQhg-vlQackK6-oj3hW6vKbDj-95Wlvdgl37cGg]
+```
+
+헤더에서 값을 뽑을 때는 공백을 허용한다.
+
+```bash
+echo "$OLD" | cut -d. -f1 | tr '_-' '/+' | base64 -d 2>/dev/null \
+  | sed -n 's/.*"kid" *: *"\([^"]*\)".*/\1/p'
 ```
 
 **실측**(observed) — `01-before-rotation.txt`
@@ -19085,6 +19613,23 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   create realms/keycloak-patterns/logout-all
 ```
 
+**★ 2026-09-17 에 이 절을 그대로 쳤다**(observed). `logout-all` 을 친 **뒤에도** 세션이
+그대로 `6` 건이었다 — 이 방법으로는 안 지워진다.
+
+```
+logout-all 뒤   select count(*) from offline_user_session where offline_flag='0'  →  6
+
+delete from offline_client_session   DELETE 1633
+delete from offline_user_session     DELETE 6
+redis-cli flushall                   OK
+rollout restart 뒤 두 저장소         0 · Redis 스캔도 빈 출력
+```
+
+**자식 쪽이 훨씬 많다.** 부모부터 지우려 했다면 외래키에 걸렸을 것이고, 그래서 순서가
+정해져 있다. 그리고 롤아웃 직후 `kcadm` 이 `No server specified` 로 끝났다 — 세션
+파일이 파드와 함께 사라지는 것을 이 문서가 미리 적어 둔 그대로다(observed).
+
+
 세션이 지워졌는지 센다.
 
 **이 실험대는 이렇게 했다**(observed) — 스크립트로 돌렸고 **증거에 이 SQL 의 원문이
@@ -19749,6 +20294,24 @@ for P in /logout/connect/back-channel/keycloak /backchannel-logout /oauth2/sign_
 done
 ```
 
+**★ 2026-09-17 에도 세 경로가 전부 `302` 였다**(observed). 워크스테이션의
+`grep -rn "oidcLogout\|backchannel" bff/src/main/java/` 도 그대로 빈 출력이었고,
+그 디렉터리는 있으므로 **경로를 잘못 짚은 것이 아니라 정말 없다.**
+
+```
+HTTP/1.1 302 Found
+Location: http://app1.hyeonworks.com/oauth2/authorization/keycloak
+
+/logout/connect/back-channel/keycloak 302
+/backchannel-logout 302
+/oauth2/sign_out 302
+```
+
+`302` 는 「그 경로가 있다」가 아니라 「인증이 필요한 요청으로 처리됐다」이고, 그런
+핸들러가 없어 기본 규칙에 걸린 것이다. `Location` 이 로그인 시작점을 가리켜 그것을
+증명한다.
+
+
 **실측**(observed) — `01-current-state.txt`
 
 ```text
@@ -20666,6 +21229,23 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   남은 테이블: 0
 ```
 
+**★ 2026-09-17 에 이 절차를 처음부터 끝까지 쳤다**(observed).
+
+```
+덤프        101 테이블 · 976873 bytes · 8569 줄
+파괴 15:31:02   DROP SCHEMA · CREATE SCHEMA → 남은 테이블 0 · select count(*) from realm 이 relation does not exist
+그동안 밖에서는  200   ← 스키마가 통째로 없는데 정문은 멀쩡했다
+복구 15:31:02 → 15:31:08 (6초) · 복구 로그 ERROR 0
+복구 뒤      101 테이블 · 세션 6건  — 파괴 전과 같다
+```
+
+**크기와 줄 수는 실험대마다 다르다.** 이 문서가 적은 `394945 bytes · 6956 줄` 은 그
+실험대의 값이고, BFF 쪽 테이블이 있는 실험대에서는 `976873 bytes · 8569 줄` 이었다.
+같아야 하는 것은 테이블 수 `101` 과 복구 전후의 행 수다. 남은 테이블을 세는
+`select count(*) from pg_tables …` 형태도 그때 쳐서 `0` 을 받았다 — 미검증이던
+줄이다(observed).
+
+
 `0` 이어야 한다. 여기서 101 이 그대로 나오면 `DROP` 이 다른 데이터베이스에 걸린
 것이고 `-d` 인자를 본다. 애플리케이션 테이블이 정말 없는지 직접 물어본다.
 
@@ -20713,7 +21293,7 @@ Infinispan `realms` 캐시에서 서빙하기 때문이고(A-0 에서 그 캐시
 
 ```bash
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 ```
 
 **ready 주소가 여전히 둘이다.** 아무 파드도 Service 에서 빠지지 않았다. A-2 에서는
@@ -21093,6 +21673,27 @@ Keycloak 은 **Liquibase** 로 스키마를 관리한다. 적용한 변경 하
 |---|---|
 | 「26.7.3 에서 26.7.0 으로 내려도 되나?」 | **「`databasechangelog` 의 행 수가 바뀌었나?」** |
 
+**★ 2026-09-17 에 세 번을 이어서 쳤다**(observed). 네 값이 이 판정 전부다.
+
+| 언제 | 무엇 | 파드 | `databasechangelog` | 정문 |
+|---|---|---|---|---|
+| `15:32:15` → `15:33:40` (85초) | 26.7.0 → **26.7.3** | 둘 다 `true` · `RESTARTS 0` | 210 → **210** | 200 |
+| `15:33:48` → `15:34:55` (67초) | 26.7.3 → **26.7.0** (롤백) | 둘 다 `true` · `RESTARTS 0` | **210** | 200 |
+| `15:34:55` | 26.7.0 → **26.0** (역방향) | `keycloak-1` 만 `false` · `RESTARTS 2` | **210** | **200** |
+
+**스키마가 한 번도 안 움직였다.** `orderexecuted` 210 의 `26.7.0-cluster-event` 이
+끝까지 마지막 줄이었다. 패치 판올림이라 롤백이 안 막힌 것이고, 역방향이 막힌 까닭은
+판올림이 남긴 스키마가 아니라 체크섬이다.
+
+```
+liquibase.exception.ValidationFailedException: Validation Failed:
+     1 changesets check sum
+```
+
+**그런데 정문은 세 번 내내 `200` 이었다.** StatefulSet 이 파드를 하나씩 갈아 끼우고
+`keycloak-0` 이 26.7.0 에 남아 있었기 때문이다. 한 파드가 못 뜨는데 밖에서는 아무 일도
+없어 보인다. 실패한 기동은 스키마도 안 건드렸다(210 그대로).
+
 **★ 이 가이드는 정정된 결론을 따른다.** 해설 문서는 처음에 「롤백은 안 된다」고 단정했다가
 후속 실험에서 정정했다.
 
@@ -21179,9 +21780,17 @@ quay.io/keycloak/keycloak:26.7.0
 것**은 다를 수 있다(적용 중이거나 롤아웃이 멈춰 있으면).
 
 ```bash
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready,\
-RESTARTS:.status.containerStatuses[0].restartCount | grep keycloak
+kubectl -n keycloak-lab get pods \
+  -o "custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount" \
+  | grep keycloak
+```
+
+**★ `grep keycloak` 은 BFF 파드도 잡는다.** B층을 먼저 밟아 `keycloak-pattern-bff` 가
+떠 있으면 그 두 줄이 같이 나온다(2026-09-17, observed). 라벨로 거르는 편이 낫다.
+
+```bash
+kubectl -n keycloak-lab get pods -l app=keycloak \
+  -o "custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount"
 ```
 
 두 파드의 `IMAGE` 가 **서로 같고** StatefulSet 과도 같은지, `READY` 가 둘 다 `true`,
@@ -21343,9 +21952,9 @@ partitioned roll out complete: 2 new pods have been updated...
 **결과를 해석하기 전에, 주입이 의도한 것을 정확히 했는지 먼저 본다.**
 
 ```bash
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready,\
-RESTARTS:.status.containerStatuses[0].restartCount | grep keycloak
+kubectl -n keycloak-lab get pods \
+  -o "custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount" \
+  | grep keycloak
 ```
 
 **실측**(observed) — `followup/01-d2-forward-upgrade.txt`
@@ -21554,7 +22163,7 @@ kubectl -n keycloak-lab logs keycloak-1 --previous
 ```bash
 curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 kubectl -n keycloak-lab get statefulset keycloak
 ```
 
@@ -22030,9 +22639,27 @@ sudo grep -c 'd3-canary-zq7v-do-not-use' /var/lib/rancher/k3s/server/db/state.db
 
 ```bash
 sudo grep -c 'd3-canary-zq7v-do-not-use' /var/lib/rancher/k3s/server/db/state.db-wal
-sudo strings /var/lib/rancher/k3s/server/db/state.db | grep -c 'd3-canary-zq7v-do-not-use'
+sudo sh -c 'strings /var/lib/rancher/k3s/server/db/state.db | grep -c d3-canary-zq7v-do-not-use'
 ```
 
+**★ 게스트에 `strings` 가 없다.** `binutils` 가 안 깔려 있어 그대로 치면
+`sh: 1: strings: not found` 로 끝난다(2026-09-17, observed). `sudo apt install -y
+binutils` 로 깔거나 `strings` 없이 `grep -c` 만 써도 같은 수가 나온다 — 둘 다 쳐서
+확인했다(observed).
+
+**★ 그리고 삭제 후를 쟀다**(observed). 그때까지 이 실험이 안 밟은 단계다.
+
+```
+             state.db   state.db-wal
+삭제 전         0            1
+삭제 뒤         0            7
+```
+
+**지운 뒤에 오히려 늘었다.** `kubectl delete secret` 은 API 에서 그 객체를 없앨
+뿐이고, **그 삭제 자체가 같은 값을 담은 레코드를 `-wal` 에 더 쓴다.** 비밀이 유출됐을
+때 해야 하는 일이 삭제가 아니라 회전인 까닭이 이 표에 그대로 있다.
+
+
 | 왜 안 나올 수 있나 | 확인 |
 |---|---|
 | 아직 `-wal` 에만 있다 | `-wal` 을 같이 `grep` |
@@ -22501,6 +23128,44 @@ ssh test-server 'systemctl cat certbot-renew.service'
 ssh test-server 'systemctl cat certbot-renew.timer'
 ```
 
+**★ 이 실험대에서는 기계 이름도 유닛 이름도 다르다**(2026-09-17, observed).
+
+첫째, certbot 은 **엣지 게스트**에 있다. 기반 가이드 03 이 엣지 nginx 를 호스트에서
+`kc-lab-edge` 로 옮겼고 04 가 거기 certbot 을 깔았다. `test-server` 에도 실행 파일은
+있지만 타이머가 없다.
+
+```
+[test-server]    systemctl list-timers certbot-renew.timer  →  0 timers listed.
+[kc-lab-edge]    systemctl list-timers --all | grep -i certbot
+                 Thu 2026-09-17 17:06:05 UTC  10h left  certbot.timer  certbot.service
+```
+
+둘째, Debian 12 의 유닛 이름은 `certbot.timer` · `certbot.service` 다. 그래서 아래
+명령은 이름을 바꿔 친다.
+
+```bash
+ssh kc-lab-edge 'systemctl cat certbot.service'
+ssh kc-lab-edge 'systemctl cat certbot.timer'
+ssh kc-lab-edge 'sudo ls -l /etc/letsencrypt/renewal-hooks/deploy/'
+```
+
+**이름은 달라도 이 절이 찾는 것은 그대로 없다**(observed).
+
+```
+# /lib/systemd/system/certbot.service
+[Service]
+Type=oneshot
+ExecStart=/usr/bin/certbot -q renew --no-random-sleep-on-renew
+PrivateTmp=true
+
+/etc/letsencrypt/renewal-hooks/deploy/   total 0
+```
+
+`ExecStartPost` 도 `--deploy-hook` 도 없고 훅 디렉터리도 비어 있다. **갱신은 돌지만
+받은 것을 누가 읽게 만드는 일은 아무도 하지 않는다** — 이 결론이 유닛 이름과 무관하게
+성립한다.
+
+
 **실측**(observed) — `07-renewal-hook-missing.txt`
 
 ```text
@@ -22634,6 +23299,32 @@ A=$(date -u +%s.%N); B=$(ssh test-server 'date -u +%s.%N'); C=$(date -u +%s.%N)
 echo "$A"; echo "$B"; echo "$C"
 ```
 
+**★ 재는 대상은 엣지 게스트다**(2026-09-17, observed). 이 절차의 판정은 엣지 nginx 가
+언제 reload 됐나이고, 기반 가이드 03 이 그 nginx 를 `kc-lab-edge` 로 옮겼다.
+`test-server` 에는 nginx 프로세스가 아예 없다.
+
+```
+[test-server]   ps -ef | grep '[n]ginx'   →  아무것도 안 나온다
+[kc-lab-edge]   root 1065 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
+                www-data 1106 nginx: worker process
+```
+
+```bash
+A=$(date -u +%s.%N); B=$(ssh kc-lab-edge 'date -u +%s.%N'); C=$(date -u +%s.%N)
+```
+
+같은 날 lab host 와 엣지를 나란히 찍어 보니 **엣지가 94초 느렸다**(observed).
+
+```
+lab host    2026-09-17T06:51:28.799Z
+kc-lab-edge 2026-09-17T06:49:54.782Z
+```
+
+`106초` 는 그때 그 짝의 값이다. **수를 옮겨 쓰지 말고 지금 자기 실험대에서 다시 잰다** —
+게스트는 호스트와 따로 시계를 맞추므로 새로 만들 때마다 값이 다르다. 훅 디렉터리는
+2026-09-17 에도 비어 있었다(`total 8`, `.` 과 `..` 뿐, observed).
+
+
 세 수를 **눈으로 뺀다.** `A` 와 `C` 는 같은 기계에서 SSH 왕복 직전·직후에 찍은 것이므로 그
 가운데가 「저쪽 시각을 잰 순간의 이쪽 시각」이고, `B` 가 그보다 크면 저쪽이 빠른 것이다.
 **계산을 명령에 넣지 않는 것이 이 형태의 요점이다** — 두 값의 차를 셸이 대신 빼 주면 어느
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/README.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/README.txt
new file mode 100644
index 0000000..ea2bb96
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/README.txt
@@ -0,0 +1,167 @@
+2026-09-17 에 기반 가이드 7단계로 실험대를 처음부터 다시 세우고 A-0 을 그대로 다시
+밟은 기록이다. 명령과 출력은 그때 화면에 나온 것을 그대로 옮겼다.
+
+a0-01-baseline.txt              기준선 1~5 — 노드·파드 배치, 파드 IP, ISPN000094 (2), jgroups_ping coord 하나, \dt 100행, 세션 0행
+a0-02-cache-entries.txt         기준선 6 — Prometheus 의 vendor_statistics_approximate_entries_unique 통째로와 tr/grep 으로 자른 형태
+a0-03-inject-reset.txt          주입 — 세션 행 삭제와 rollout restart, 새 파드 IP
+a0-04-test0.txt                 시험 0 ①~⑦ — 로그인, 토큰 길이, 클레임 디코드, sid, CID, 두 노드에 grep -c
+a0-05-claims.txt                JWT 클레임 전체 (패딩을 채워 디코드) — sub 이 없다는 것을 확인
+a0-06-test0-cross-node.txt      시험 0 ⑧⑨ — 반대편 refresh 200 · 같은 sid, 로그아웃 204, 발급 노드에서 400 Session not active
+a0-07-test0b-cache-delta.txt    시험 0b — 로그인 한 번에 발급 노드만 +1, 반대편 +0
+a0-08-test0c-ownership.txt      시험 0c — 몰아준 쪽만 늘어 9 + 5 = 14, DB 총계 14
+a0-09-test0d-sql.txt            시험 0d 첫 시도 — 문장 로깅을 켜고 요청 직후에 걸렀더니 반대편 문장이 안 나왔다
+a0-10-test0d-retry.txt          같은 필터를 몇 초 뒤에 — 그래도 안 나온 판. 09 와 함께 「너무 일찍 걸렀다」의 증거다
+a0-11-test0d-window.txt         그 시간대에 반대편이 낸 모든 줄 — 디스커버리 질의뿐이었다
+a0-12-test0d-controlled.txt     대기를 넣고 다시 — 반대편 pid 가 낸 sid 줄 6개, 세션 테이블 문장 6/12
+a0-13-test0d-sql-lines.txt      반대편이 날린 여덟 문장과 pid 로 거른 BEGIN~COMMIT 경계. 끝에 문장 로깅을 되돌렸다
+
+비밀은 옮기지 않았다. 관리자 비밀번호는 길이(19)만 확인했고 값은 어느 파일에도 없다.
+
+A-1 (JGroups 7800 차단)
+a1-01-inject.txt                매니페스트 원문과 apply · 적용 시각
+a1-02-verify.txt                정책이 잡은 파드, 포트 셋(9000=200 · 8080=200 · 7800=exit 7), 클러스터는 아직 2, /proc/net/tcp6 의 1E78
+a1-03-conntrack.txt             conntrack 을 두 노드에서 — 빈 화면이 나왔다
+a1-04-conntrack-missing.txt     그 빈 화면의 까닭 — conntrack 미설치. 2>/dev/null 이 command not found 를 지웠다
+a1-05-conntrack-installed.txt   처방 검증 — 깔고 나니 ESTABLISHED [ASSURED] 두 줄이 나온다
+a1-06-forced-partition.txt      파드를 지워 분단 확정 — 두 노드가 각각 1 을 보고
+a1-07-readiness.txt             분단된 노드가 0/1 · Ready=False, Endpoints 가 하나로, health/ready 503 과 Failing since
+a1-08-readiness-commands.txt    문서가 적은 명령 그대로 — describe 는 조건표를 내고, custom-columns 는 zsh 에서 안 돈다
+a1-09-quoting-and-health.txt    따옴표를 씌운 형태와 헬스 본문을 내는 명령. 정문은 Host 헤더로 200
+a1-10-cross-node-under-partition.txt  분단 중 네 단계 — 200 · 204 · 200. 로그아웃이 전파되지 않았다 (토큰은 길이만 남기고 가렸다)
+a1-11-recover.txt               정책 삭제 뒤 30~60초 안에 두 노드가 다시 2
+
+A-2 (데이터베이스 정상 종료)
+a2-01-baseline-probe.txt        상주 탐침 a2-probe 와 정지 전 토큰 (길이만)
+a2-02-inject.txt                정지 전 네 경로 200×4, replicas=0, 파드 삭제, Deployment 0/0
+a2-03-during-outage.txt         정지 직후 — 네 경로 500×4, JWKS·well-known 200, Connection refused, 그런데 ready 는 아직 true
+a2-04-outage-progression.txt    약 50초 뒤 ready false,false · 정문 503 으로 뒤집히는 자리
+a2-05-recover.txt               replicas=1 에서 36초 만에 ready true,true · 정문 200 · 재시작 0
+
+A-3 (데이터베이스 크래시)
+a3-01-design-check.txt          로그인 트랜잭션에도 SET LOCAL synchronous_commit TO OFF 가 붙는다 · WAL 설정 네 줄
+a3-02-prepare.txt               세션 비우기, 파드 셋 상태, 루프 파일 주입
+a3-03-attempt1.txt              시도 ① 첫 판 — /tmp/sids 가 0줄이었다 (아래 04 가 그 까닭)
+a3-04-sids-no-newline.txt       busybox sed 가 끝 개행을 안 붙인다 — 9384바이트 0줄. echo 로 감싼 처방을 재서 10줄 확인
+a3-05-attempt1-redo.txt         고친 루프로 다시 — 8초에 109건, force delete 는 유실 0
+a3-06-attempt2.txt              시도 ② kill -9 1 — RESTARTS 0, 400 = 400, 유실 0
+a3-07-attempt3.txt              시도 ③ 백엔드 SIGKILL — crash recovery 로그와 395 vs 392
+a3-08-loss-count.txt            문서의 comm 방법으로 센 유실 3건과 그 sid 세 개
+a3-09-revert.txt                문장 로깅 off 확인, 세션 정리, 파드 재시작, 탐침 삭제
+
+A-4 (노드 상실)
+a4-01-baseline.txt              virsh uri·VM 셋·파드 배치·PV 가 kc-lab-2 에 고정된 것·관측 스택 위치
+a4-02-inject-4a.txt             kc-lab-2 영향 범위와 virsh destroy. 하이퍼바이저는 shut off 인데 쿠버네티스는 +10초에도 Ready
+a4-03-4a-progression.txt        +28초 Ready/정문 000 → +66초 NotReady/정문 503. 이벤트 NodeNotReady 와 context deadline exceeded
+a4-04-eviction-and-recover.txt  +4분 49초에 deletionTimestamp. Deployment 는 대체 파드(Pending), StatefulSet 은 대체 없이 Terminating
+a4-05-recovery-progression.txt  VM 을 켠 뒤 Ready 로 돌아오고 파드가 서고 정문이 200 이 되기까지
+a4-06-agent-token-missing.txt   복구가 막힌 진짜 까닭 — 유닛이 지워진 ~/node-token 을 기다린다. 파일을 되돌리자 Ready
+a4-07-token-remedy.txt          처방 — /etc/rancher/node-token(root 600)으로 옮기고 유닛을 돌리면 홈 사본을 지워도 뜬다
+
+A-5 (비대칭 분단)
+a5-01-attempt1.txt              시도 ① filter FORWARD — 카운터는 9·22 로 올라가는데 클러스터는 2 그대로. 게스트 셸의 $K1 이 비어 있는 것도 여기서 확인
+a5-02-attempt2-3.txt            시도 ② 보내는 쪽 raw — 카운터 0. 시도 ③ 받는 쪽 raw — 카운터 16·20, 멤버 1
+a5-03-one-direction-watch.txt   한 방향만 막은 채 2분 — 잠깐 1 이었다가 2 로 돌아온다 (문서의 「열린 방향으로 다시 붙는다」)
+a5-04-bidirectional.txt         양방향 — 멤버 1·1 과 jgroups_ping 의 coord 가 둘 다 t
+a5-05-revert.txt                두 체인을 비우자 2 와 coord 하나로 복귀
+
+A-6 (지연 주입)
+a6-01-attempt1-2.txt            시도 ① eth0 가 없다 · ip -brief link 목록 · enp1s0 는 노드 IP 만, flannel.1 은 파드 IP 가 보인다 (문서가 미검증으로 둔 두 줄)
+a6-02-inject.txt                주입 전 로그인 0.064~0.068s, flannel.1 에 prio·netem·filter 세 줄
+a6-03-effect.txt                주입 뒤 1.86~1.91s (문서의 1,872ms 와 28배가 그대로) · netem 83 pkt · tc filter show 의 match 0a2a011d
+a6-04-revert.txt                qdisc del 뒤 noqueue 로 돌아가고 시간도 0.04~0.07s 로 복귀
+
+A-7 (volatile 로 A층 넷을 다시)
+a7-01-switch-volatile.txt          세션 비우기, args 를 --features-disabled=persistent-user-sessions 로 patch, 롤아웃
+a7-02-cross-node-volatile.txt      교차 노드 refresh 200 인데 DB 세션 행은 (0 rows)
+a7-03-block-7800.txt               캐시가 keycloak-0 에만 1, 그 뒤 NetworkPolicy 로 7800 차단 — 멤버 1·1
+a7-04-partition-breaks-sharing.txt 분단 + volatile 에서 400·400·400 (persistent 의 200·204·200 과 정반대)
+a7-05-revert.txt                   NetworkPolicy 삭제와 args 원복
+
+A-7a (그 500 의 원인과 캐시 온도 셋)
+a7a-01-setup.txt                   문장 로깅 on, volatile 전환, StatefulSet 밖의 탐침
+a7a-02-repro-A.txt                 재현 A 완전 냉시동 — 로그인이 400 unauthorized_client
+a7a-03-repro-A-sql.txt             문서의 grep 이 한 줄도 못 잡는다. 속 예외가 JDBCConnectionException 쪽이었다
+a7a-04-repro-B.txt                 재현 B 로그인 한 번으로 덥힌 뒤 DB 정지 — refresh 가 500 unknown_error
+a7a-05-repro-C-and-revert.txt      재현 C — DB 를 켜니 같은 refresh 가 200. 로깅 off 와 args 원복까지
+
+A-8 (롤링 재시작)
+a8-01-baseline.txt              파드·args·DB 0건, 토큰과 sid 를 탐침에 담고 대조군 refresh 200, 그 sid 의 DB 행
+a8-02-restart.txt               재시작 전 캐시 0, rollout restart, AGE 로 교체 확인. (12번은 탐침의 낡은 K0 때문에 000 이 났다)
+a8-03-main-test.txt             새 IP 로 다시 — 재시작 전 토큰이 200, created_on 은 그대로이고 last_session_refresh 만 갱신 (토큰은 길이만 남기고 가렸다)
+
+D-3 (비밀 노출 네 경로)
+d3-01-secret-paths.txt          Secret 목록·describe 의 길이 표시·키 이름·길이, 카나리아 주입, 암호화 Disabled, state.db 0 / -wal 1
+d3-02-paths-and-revert.txt      strings 미설치, RBAC 는 둘 다 no, 카나리아 삭제 뒤 -wal 이 1 → 7 로 늘었다
+d3-03-strings-missing.txt       binutils 를 깔면 strings 가 생기고, 안 깔아도 grep -c 로 같은 7 이 나온다
+
+B층 준비 (B-0 의 실행 가능한 부분)
+b0-01-image-import.txt          워크스테이션에서 두 이미지를 빌드해 docker save | ssh | k3s ctr images import 로 두 노드에
+b0-02-realm-and-user.txt        kcadm 로그인, realm keycloak-patterns · client bff-confidential · user labuser 생성
+b0-03-deploy-bff.txt            bff-redis.yaml 적용 — Secret·PVC·redis·bff·Service·Ingress
+b0-04-bff-status.txt            bff 두 replica 와 redis 가 1/1. imagePullPolicy Never 로 반입 이미지가 붙었다
+
+B-3 (refresh 회전 경쟁) — 전제 검증까지
+b3-01-setup.txt                 realm 세 값(revokeRefreshToken false · maxReuse 0 · lifespan 60), 탐침, CS길이 14
+b3-02-secret-and-token.txt      B-0 이 없다고 한 비밀 대조를 만들어 「두 값이 같다」. 그런데 토큰 요청이 unauthorized_client
+b3-03-direct-grant-missing.txt  원인 — directAccessGrantsEnabled 가 false. 켜니 invalid_grant 로 바뀐다
+b3-04-account-not-fully-set-up.txt  둘째 원인 — labuser 의 emailVerified false. 고치니 토큰이 나온다 (rt=735자)
+b3-05-race.txt                  회전을 켜고 같은 토큰으로 동시에 5번 — 400 넷·200 하나, 이긴 토큰도 400 (토큰 조각은 가렸다)
+b3-06-revert.txt                revokeRefreshToken 원복과 탐침 삭제
+
+D-1 (백업과 복구)
+d1-01-backup.txt                기준선 101 테이블·세션 6건, pg_dump 로 976873 bytes·8569 줄·CREATE TABLE 101
+d1-02-destroy-restore.txt       DROP SCHEMA 뒤 남은 테이블 0 인데 정문은 200, 6초 만에 복구되고 ERROR 0, 101/6 으로 복귀
+
+D-2 (판올림과 롤백)
+d2-01-baseline.txt              태그 26.7.0, databasechangelog 210, 마지막 다섯 줄, 세션 6, quay 에 26.7.3 존재(200)
+d2-02-upgrade.txt               26.7.3 정방향 85초 — 스키마 210 그대로, 세션 보존, 정문 200
+d2-03-rollback-and-reverse.txt  롤백 67초 성공. 역방향 26.0 은 liquibase Validation Failed 로 keycloak-1 만 못 뜨고 정문은 200
+d2-04-revert.txt                체크섬 줄(1 changesets check sum)과 26.7.0 원복
+
+B-6 (키 회전) — 전제까지만
+b6-01-deploy-echo.txt           echo.yaml 로 header-lab 네임스페이스와 echo 두 replica (반입 이미지로 뜬다)
+b6-02-jwks-before.txt           JWKS 를 Host 헤더로 받는다. RS256 1개, kid 둘
+b6-03-providers.txt             kcadm 세션이 파드 교체로 사라진 것과 재로그인. 문서가 「빈 결과」라던 질의가 실제로는 결과를 낸다
+b6-04-old-token.txt             토큰 1397자. echo 는 유효한 토큰에 401, 토큰 없이는 200
+b6-05-echo-401.txt              그 까닭 — echo 의 issuer/jwk URI 가 https 이고 닿지 않는다. kid 를 뽑으려면 공백을 허용해야 한다
+b6-06-kid-and-issuer.txt        두 URI 원문, issuer=000(exit 7), 헤더의 "kid" : "…" 공백 형태와 두 sed 비교
+
+B-4 (신원 헤더 위조) — TLS 를 Host 헤더로 대체해 실행
+b4-01-forged-headers.txt        Ingress 네 줄, echo 응답 전문(들여쓰고 콜론 양옆에 공백), 대조군은 비어 있다
+b4-02-forged-headers-retry.txt  동명 헤더 둘 · 값 안의 쉼표 · 위조한 신원이 전부 그대로 도착. 문서의 콜론 붙인 grep 은 한 줄도 못 잡는다
+
+C-2 (백채널 로그아웃) — 브라우저 없이 되는 두 단계
+c2-01-backchannel-probe.txt     세 후보 경로가 전부 302 이고 Location 이 로그인 시작점. 워크스테이션 grep 도 빈 출력(디렉터리는 있다)
+
+B-7a / B-7 (엣지 세션) — 전제에서 막힌 자리를 쟀다
+b7a-01-oauth2-proxy.txt         oauth2-proxy 배포가 롤아웃 타임아웃. redis-cli dbsize 0 과 빈 스캔은 정상 동작
+b7a-02-oauth2-proxy-blocked.txt 까닭 — 기동 시 OIDC 디스커버리가 https://auth.hyeonworks.com 으로 가고 connection refused. CrashLoopBackOff
+
+B-0 / B-1 / B-2 — 브라우저 없이 되는 측정
+b1-01-beans.txt                 /actuator/beans 빈 437개, authorizedClientService 가 JdbcOAuth2AuthorizedClientService, RedisSessionConfiguration 존재. 문서의 미검증 두 줄이 돈다
+b2-01-jdbc-table.txt            oauth2_authorized_client 표는 생겨 있고 행은 0 (행은 브라우저 로그인 뒤에 생긴다)
+
+D-4 / D-4a (인증서 갱신과 배포 훅) — 인증서 없이 되는 부분
+d4-01-renewal-automation.txt    certbot 은 kc-lab-edge 에 있고 test-server 에는 타이머가 없다. 유닛 이름은 certbot.timer/.service (certbot-renew.* 아님). 기본 유닛에 ExecStartPost 도 --deploy-hook 도 없고 훅 디렉터리도 비었다. certificates 는 No certificates found
+d4a-01-hook-state.txt           test-server 에 nginx 프로세스가 없다(엣지에 있다). 훅 디렉터리 total 8. lab host 와 엣지의 시계가 94초 어긋나 있다
+
+B-5 (Redis 상실)
+b5-01-baseline.txt              Redis PONG·키 없음·save 와 appendonly·/data 가 PVC redis-data
+b5-02-redis-down.txt            replicas=0 뒤 health 는 DOWN 인데 readiness 는 UP. 파드 둘 다 1/1, 엔드포인트도 ready true,true
+b5-03-revert.txt                replicas=1 로 되살리자 health 가 다시 UP
+
+C-1 (여러 앱의 SSO) — 브라우저 없이 되는 세션 정리 구간
+c1-01-clear-sessions.txt        logout-all 을 쳐도 세션이 6건 그대로. 자식 1633 · 부모 6 순서로 지워야 한다. flushall·롤아웃 뒤 둘 다 0. 롤아웃이 kcadm 세션을 날린다
+
+이 폴더가 덮는 범위
+-------------------
+2026-09-17 에 기반 가이드 7단계로 실험대를 철거하고 새로 세운 뒤 kss 26편을 순서대로
+밟은 기록이다. 끝까지 밟은 편이 17, 되는 데까지 밟은 편이 9 다. 어느 편이 어디까지인지는
+SSOT 의 「2026-09-17 재현 — 어디까지 밟았고 무엇이 막았나」와 각 기록의
+「이 실험대에서 아직 못 밟은 단계」에 적혀 있다.
+
+막은 것은 하나다 — https://auth.hyeonworks.com 이 서지 않는다. 와일드카드 인증서
+(Cloudflare API 토큰)와 호스트의 libvirt guest_input 구멍(호스트 sudo)이 둘 다 필요하다.
+
+비밀은 어느 파일에도 값으로 들어 있지 않다. 비밀번호는 길이(19·22)만 적었고, 화면에
+찍혀 나온 토큰은 <REDACTED n자> 로 가렸다.
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-01-baseline.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-01-baseline.txt
new file mode 100644
index 0000000..eab37fb
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-01-baseline.txt
@@ -0,0 +1,131 @@
+=== a0 기준선 1 노드·파드 ===
+NAME       STATUS   ROLES           AGE   VERSION
+kc-lab-1   Ready    control-plane   18m   v1.36.4+k3s1
+kc-lab-2   Ready    <none>          16m   v1.36.4+k3s1
+NAME                        READY   STATUS    RESTARTS   AGE     IP          NODE       NOMINATED NODE   READINESS GATES
+keycloak-0                  1/1     Running   0          8m46s   10.42.1.3   kc-lab-2   <none>           <none>
+keycloak-1                  1/1     Running   0          8m46s   10.42.0.9   kc-lab-1   <none>           <none>
+postgres-7b474b88c8-s6vdh   1/1     Running   0          8m46s   10.42.1.5   kc-lab-2   <none>           <none>
+=== a0 기준선 2 파드 IP ===
+10.42.1.3 10.42.0.9
+=== a0 기준선 3 클러스터 뷰 ===
+2026-09-17 04:35:25,386 INFO  [org.infinispan.CLUSTER] (executor-thread-1) ISPN000094: Received new cluster view for channel ISPN: [keycloak-1-3159(v=16.0.12)|1] (2) [keycloak-1-3159(v=16.0.12), keycloak-0-13057(v=16.0.12)]
+2026-09-17 04:35:25,333 INFO  [org.infinispan.CLUSTER] (jgroups-5,keycloak-1-3159(v=16.0.12)) ISPN000094: Received new cluster view for channel ISPN: [keycloak-1-3159(v=16.0.12)|1] (2) [keycloak-1-3159(v=16.0.12), keycloak-0-13057(v=16.0.12)]
+=== a0 기준선 4 디스커버리 ===
+       name       |       ip       | coord 
+------------------+----------------+-------
+ keycloak-0-13057 | 10.42.1.3:7800 | f
+ keycloak-1-3159  | 10.42.0.9:7800 | t
+(2 rows)
+
+=== a0 기준선 5 테이블 목록 ===
+                     List of relations
+ Schema |             Name              | Type  |  Owner   
+--------+-------------------------------+-------+----------
+ public | admin_event_entity            | table | keycloak
+ public | associated_policy             | table | keycloak
+ public | auth_session                  | table | keycloak
+ public | authentication_execution      | table | keycloak
+ public | authentication_flow           | table | keycloak
+ public | authenticator_config          | table | keycloak
+ public | authenticator_config_entry    | table | keycloak
+ public | broker_link                   | table | keycloak
+ public | client                        | table | keycloak
+ public | client_attributes             | table | keycloak
+ public | client_auth_flow_bindings     | table | keycloak
+ public | client_initial_access         | table | keycloak
+ public | client_node_registrations     | table | keycloak
+ public | client_scope                  | table | keycloak
+ public | client_scope_attributes       | table | keycloak
+ public | client_scope_client           | table | keycloak
+ public | client_scope_role_mapping     | table | keycloak
+ public | cluster_event                 | table | keycloak
+ public | component                     | table | keycloak
+ public | component_config              | table | keycloak
+ public | composite_role                | table | keycloak
+ public | credential                    | table | keycloak
+ public | databasechangelog             | table | keycloak
+ public | databasechangeloglock         | table | keycloak
+ public | default_client_scope          | table | keycloak
+ public | event_entity                  | table | keycloak
+ public | fed_issued_ver_credential     | table | keycloak
+ public | fed_user_attribute            | table | keycloak
+ public | fed_user_consent              | table | keycloak
+ public | fed_user_consent_cl_scope     | table | keycloak
+ public | fed_user_credential           | table | keycloak
+ public | fed_user_group_membership     | table | keycloak
+ public | fed_user_required_action      | table | keycloak
+ public | fed_user_role_mapping         | table | keycloak
+ public | fed_user_ver_credential       | table | keycloak
+ public | federated_identity            | table | keycloak
+ public | federated_user                | table | keycloak
+ public | group_attribute               | table | keycloak
+ public | group_role_mapping            | table | keycloak
+ public | identity_provider             | table | keycloak
+ public | identity_provider_config      | table | keycloak
+ public | identity_provider_mapper      | table | keycloak
+ public | idp_mapper_config             | table | keycloak
+ public | issued_ver_credential         | table | keycloak
+ public | jgroups_ping                  | table | keycloak
+ public | keycloak_group                | table | keycloak
+ public | keycloak_role                 | table | keycloak
+ public | login_failure                 | table | keycloak
+ public | migration_model               | table | keycloak
+ public | offline_client_session        | table | keycloak
+ public | offline_user_session          | table | keycloak
+ public | org                           | table | keycloak
+ public | org_domain                    | table | keycloak
+ public | org_invitation                | table | keycloak
+ public | outbox_entry                  | table | keycloak
+ public | policy_config                 | table | keycloak
+ public | protocol_mapper               | table | keycloak
+ public | protocol_mapper_config        | table | keycloak
+ public | realm                         | table | keycloak
+ public | realm_attribute               | table | keycloak
+ public | realm_default_groups          | table | keycloak
+ public | realm_enabled_event_types     | table | keycloak
+ public | realm_events_listeners        | table | keycloak
+ public | realm_localizations           | table | keycloak
+ public | realm_required_credential     | table | keycloak
+ public | realm_smtp_config             | table | keycloak
+ public | realm_supported_locales       | table | keycloak
+ public | redirect_uris                 | table | keycloak
+ public | required_action_config        | table | keycloak
+ public | required_action_provider      | table | keycloak
+ public | resource_attribute            | table | keycloak
+ public | resource_policy               | table | keycloak
+ public | resource_scope                | table | keycloak
+ public | resource_server               | table | keycloak
+ public | resource_server_perm_ticket   | table | keycloak
+ public | resource_server_policy        | table | keycloak
+ public | resource_server_resource      | table | keycloak
+ public | resource_server_scope         | table | keycloak
+ public | resource_uris                 | table | keycloak
+ public | revoked_token                 | table | keycloak
+ public | role_attribute                | table | keycloak
+ public | root_auth_session             | table | keycloak
+ public | scope_mapping                 | table | keycloak
+ public | scope_policy                  | table | keycloak
+ public | server_config                 | table | keycloak
+ public | single_use_object             | table | keycloak
+ public | user_attribute                | table | keycloak
+ public | user_consent                  | table | keycloak
+ public | user_consent_client_scope     | table | keycloak
+ public | user_entity                   | table | keycloak
+ public | user_federation_config        | table | keycloak
+ public | user_federation_mapper        | table | keycloak
+ public | user_federation_mapper_config | table | keycloak
+ public | user_federation_provider      | table | keycloak
+ public | user_group_membership         | table | keycloak
+ public | user_required_action          | table | keycloak
+ public | user_role_mapping             | table | keycloak
+ public | user_ver_credential           | table | keycloak
+ public | web_origins                   | table | keycloak
+ public | workflow_state                | table | keycloak
+(100 rows)
+
+=== a0 기준선 5b 세션 수 ===
+ offline_flag | count 
+--------------+-------
+(0 rows)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-02-cache-entries.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-02-cache-entries.txt
new file mode 100644
index 0000000..e824de4
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-02-cache-entries.txt
@@ -0,0 +1,99 @@
+=== a0 기준선 6-① 캐시 엔트리 통째로 ===
+{"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"clientSessions","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"sessions","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"work","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"users","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"authorizationRevisions","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"keys","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"authorization","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"realmRevisions","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"118"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"userRevisions","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"4"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"offlineSessions","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"actionTokens","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"realms","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"5"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"loginFailures","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"crl","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"authenticationSessions","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"offlineClientSessions","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"offlineClientSessions","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"actionTokens","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"1"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"keys","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"loginFailures","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"crl","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"offlineSessions","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"authorization","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"realmRevisions","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"117"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"authorizationRevisions","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"realms","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"4"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"sessions","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"authenticationSessions","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"userRevisions","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"clientSessions","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"users","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"0"]},{"metric":{"__name__":"vendor_statistics_approximate_entries_unique","cache":"work","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620205.066,"1"]}]}}
+=== a0 기준선 6-② 잘라서 (가이드가 미검증으로 표시한 줄) ===
+"cache":"clientSessions"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"sessions"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"work"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"users"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"authorizationRevisions"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"keys"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"authorization"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"realmRevisions"
+"pod":"keycloak-1"}
+"118"]}
+"cache":"userRevisions"
+"pod":"keycloak-1"}
+"4"]}
+"cache":"offlineSessions"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"actionTokens"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"realms"
+"pod":"keycloak-1"}
+"5"]}
+"cache":"loginFailures"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"crl"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"authenticationSessions"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"offlineClientSessions"
+"pod":"keycloak-1"}
+"0"]}
+"cache":"offlineClientSessions"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"actionTokens"
+"pod":"keycloak-0"}
+"1"]}
+"cache":"keys"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"loginFailures"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"crl"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"offlineSessions"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"authorization"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"realmRevisions"
+"pod":"keycloak-0"}
+"117"]}
+"cache":"authorizationRevisions"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"realms"
+"pod":"keycloak-0"}
+"4"]}
+"cache":"sessions"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"authenticationSessions"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"userRevisions"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"clientSessions"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"users"
+"pod":"keycloak-0"}
+"0"]}
+"cache":"work"
+"pod":"keycloak-0"}
+"1"]}]}}
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-03-inject-reset.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-03-inject-reset.txt
new file mode 100644
index 0000000..7b22152
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-03-inject-reset.txt
@@ -0,0 +1,19 @@
+=== a0 주입 1-① 세션 행을 지운다 ===
+DELETE 0
+=== a0 주입 1-② 재시각과 롤아웃 ===
+13:45:12 재시작
+statefulset.apps/keycloak restarted
+=== a0 주입 1-③ 다 설 때까지 ===
+Waiting for partitioned roll out to finish: 0 out of 2 new pods have been updated...
+Waiting for 1 pods to be ready...
+Waiting for 1 pods to be ready...
+Waiting for 1 pods to be ready...
+Waiting for partitioned roll out to finish: 1 out of 2 new pods have been updated...
+Waiting for 1 pods to be ready...
+Waiting for 1 pods to be ready...
+Waiting for 1 pods to be ready...
+partitioned roll out complete: 2 new pods have been updated...
+=== a0 주입 검증 — 새 파드와 새 IP ===
+keycloak-0                  1/1     Running   0          21s     10.42.1.7    kc-lab-2   <none>           <none>
+keycloak-1                  1/1     Running   0          43s     10.42.0.13   kc-lab-1   <none>           <none>
+10.42.1.7 10.42.0.13
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-04-test0.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-04-test0.txt
new file mode 100644
index 0000000..398efd7
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-04-test0.txt
@@ -0,0 +1,13 @@
+### 탐침 파드 환경변수 (길이만)
+K0=10.42.1.7 K1=10.42.0.13 PW길이=19
+### 시험 0-① 발급 노드에 로그인하고 응답을 그대로 본다
+{"access_token":"<REDACTED 198자 · 화면에 잘려 나온 조각>"exp":1789620334,"iat":1789620274,"jti":"onltro:32cc3942-8475-c164-0629-9512d7325f7c","iss":"https://auth.hyeonworks.com/realms/master","typ":"Bearer","azp":"admin-cli","sid":"MjPiYcA-AWfeos1E8AaUtSeD","scope":"profile email
+### 시험 0-④ sid 만 뽑는다 (문서가 미검증으로 둔 줄)
+SID=MjPiYcA-AWfeos1E8AaUtSeD
+### 시험 0-⑥ CID (문서가 미검증으로 둔 줄)
+CID=2d7893fb-6003-4f0e-b6a8-d6e7e9e8fa25
+### 시험 0-⑦ 같은 질문을 두 노드에 (문서가 미검증으로 둔 루프)
+10.42.1.7 : 1
+10.42.0.13 : 1
+### 반대편 노드에 refresh 를 먼저 쓴다
+{"access_token":"<REDACTED 91자 · 화면에 잘려 나온 조각>
\ No newline at end of file
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-05-claims.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-05-claims.txt
new file mode 100644
index 0000000..9770069
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-05-claims.txt
@@ -0,0 +1,8 @@
+### 클레임 전체 (패딩을 채워 디코드)
+{"exp":1789620347,"iat":1789620287,"jti":"onltro:ba0c11cf-5e4a-a378-7268-4efd5cef32b8","iss":"https://auth.hyeonworks.com/realms/master","typ":"Bearer","azp":"admin-cli","sid":"jbFsOn6E0EPyjFf8PwNJ-1q7","scope":"profile email"}
+### 클레임 이름만
+azp exp iat iss jti scope sid typ 
+### sub 이 있는가
+0
+### 문서의 형태(패딩 없이)는 어디서 끊기나
+0EPyjFf8PwNJ-1q7","scope":"profile email
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-06-test0-cross-node.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-06-test0-cross-node.txt
new file mode 100644
index 0000000..7a6207f
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-06-test0-cross-node.txt
@@ -0,0 +1,9 @@
+발급 sid = 71afhj32x97hsvCFqQYB2KaV
+### 시험 0-⑧ 반대편 노드에서 refresh (기대 200, sid 같음)
+200
+갱신 sid = 71afhj32x97hsvCFqQYB2KaV
+### 시험 0-⑨ 반대편에서 로그아웃 (기대 204)
+204
+### 그 뒤 발급 노드에서 갱신 시도 (기대 400 invalid_grant / Session not active)
+{"error":"invalid_grant","error_description":"Session not active"}
+400
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-07-test0b-cache-delta.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-07-test0b-cache-delta.txt
new file mode 100644
index 0000000..925bb6c
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-07-test0b-cache-delta.txt
@@ -0,0 +1,13 @@
+=== 시험 0b 전값 ===
+keycloak-0   clientSessions   3
+keycloak-0   sessions         3
+keycloak-1   clientSessions   0
+keycloak-1   sessions         0
+=== 발급 노드(keycloak-0) 에만 로그인 한 번 ===
+200
+=== 30초 기다린다 (스크레이프 간격 15초) ===
+=== 시험 0b 후값 ===
+keycloak-0   clientSessions   4
+keycloak-0   sessions         4
+keycloak-1   clientSessions   0
+keycloak-1   sessions         0
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-08-test0c-ownership.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-08-test0c-ownership.txt
new file mode 100644
index 0000000..74efe77
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-08-test0c-ownership.txt
@@ -0,0 +1,27 @@
+  keycloak-0 = 10.42.1.7
+  keycloak-1 = 10.42.0.13
+=== 시험 0c 시작값 ===
+keycloak-0   clientSessions   4
+keycloak-0   sessions         4
+keycloak-1   clientSessions   0
+keycloak-1   sessions         0
+=== ① 반대편(keycloak-1) 에 로그인 5회 ===
+200 200 200 200 200 
+=== 5회 뒤 ===
+keycloak-0   clientSessions   4
+keycloak-0   sessions         4
+keycloak-1   clientSessions   5
+keycloak-1   sessions         5
+=== ② 발급 노드(keycloak-0) 에 로그인 5회 ===
+200 200 200 200 200 
+=== 5회 더 뒤 ===
+keycloak-0   clientSessions   9
+keycloak-0   sessions         9
+keycloak-1   clientSessions   5
+keycloak-1   sessions         5
+=== 대조: PostgreSQL 에는 몇 건인가 ===
+ count 
+-------
+    14
+(1 row)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-09-test0d-sql.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-09-test0d-sql.txt
new file mode 100644
index 0000000..226428a
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-09-test0d-sql.txt
@@ -0,0 +1,32 @@
+=== 0d-① 문장 로깅을 켠다 ===
+ALTER SYSTEM
+ALTER SYSTEM
+ pg_reload_conf 
+----------------
+ t
+(1 row)
+
+=== 0d-② 적용됐는지 읽는다 ===
+ log_statement 
+---------------
+ all
+(1 row)
+
+ log_line_prefix 
+-----------------
+ %m [%p] %h 
+(1 row)
+
+K0=10.42.1.7 K1=10.42.0.13
+=== 0d-③ 로그인 한 번 · 반대편에서 refresh 한 번 ===
+SID=wITYiY7I4t8Ovy9wzwM1ewOA
+REFRESH_ON_K1=200
+=== 반대편 노드가 날린 문장만 ===
+2026-09-17 04:47:30.547 UTC [916] 10.42.0.13 LOG:  execute <unnamed>: SELECT address, name, ip, coord, coordinated_by, last_update FROM JGROUPS_PING WHERE cluster_name=$1
+=== 그 sid 가 들어간 줄만 120자씩 ===
+2026-09-17 04:47:31.285 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = '0', $2 = 'wITYiY7I4t8Ovy9wzwM1ewOA'
+2026-09-17 04:47:31.288 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = '2d7893fb-6003-4f0e-b6a8-d6e7e9e8fa25', $2 = 'loca
+2026-09-17 04:47:31.294 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = '0', $2 = 'wITYiY7I4t8Ovy9wzwM1ewOA'
+2026-09-17 04:47:31.295 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = '2d7893fb-6003-4f0e-b6a8-d6e7e9e8fa25', $2 = 'loca
+2026-09-17 04:47:31.296 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = NULL, $2 = '1789620451', $3 = '{"ipAddress":"10.42
+2026-09-17 04:47:31.296 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = '{"authMethod":"openid-connect","notes":{"clientId
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-10-test0d-retry.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-10-test0d-retry.txt
new file mode 100644
index 0000000..026c4db
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-10-test0d-retry.txt
@@ -0,0 +1,10 @@
+=== 좀 지난 뒤 같은 필터를 다시 (K1=10.42.0.13) ===
+2026-09-17 04:47:43.568 UTC [915] 10.42.0.13 LOG:  execute S_2: COMMIT
+2026-09-17 04:47:43.580 UTC [915] 10.42.0.13 LOG:  execute S_2: COMMIT
+=== 그 sid 가 들어간 줄 전부 ===
+2026-09-17 04:47:31.285 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = '0', $2 = 'wITYiY7I4t8Ovy9wzwM1ewOA'
+2026-09-17 04:47:31.288 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = '2d7893fb-6003-4f0e-b6a8-d6e7e9e8fa25', $2 = 'loca
+2026-09-17 04:47:31.294 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = '0', $2 = 'wITYiY7I4t8Ovy9wzwM1ewOA'
+2026-09-17 04:47:31.295 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = '2d7893fb-6003-4f0e-b6a8-d6e7e9e8fa25', $2 = 'loca
+2026-09-17 04:47:31.296 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = NULL, $2 = '1789620451', $3 = '{"ipAddress":"10.42
+2026-09-17 04:47:31.296 UTC [948] 10.42.1.7 DETAIL:  parameters: $1 = '{"authMethod":"openid-connect","notes":{"clientId
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-11-test0d-window.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-11-test0d-window.txt
new file mode 100644
index 0000000..0ae795e
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-11-test0d-window.txt
@@ -0,0 +1,21 @@
+=== 04:47:31~04:47:50 사이 10.42.0.13 이 낸 모든 줄 ===
+2026-09-17 04:47:40.548 UTC [915] 10.42.0.13 LOG:  execute S_34: SELECT address, name, ip, coord, coordinated_by, last_update FROM JGROUPS_PING WHERE cluster_name=$1
+2026-09-17 04:47:40.548 UTC [915] 10.42.0.13 DETAIL:  parameters: $1 = 'ISPN'
+2026-09-17 04:47:40.548 UTC [916] 10.42.0.13 LOG:  statement: 
+2026-09-17 04:47:43.566 UTC [915] 10.42.0.13 LOG:  statement: BEGIN
+2026-09-17 04:47:43.566 UTC [915] 10.42.0.13 LOG:  execute S_36: DELETE from JGROUPS_PING WHERE address=$1
+2026-09-17 04:47:43.566 UTC [915] 10.42.0.13 DETAIL:  parameters: $1 = 'uuid://00000000-0000-0000-0000-000000000003'
+2026-09-17 04:47:43.567 UTC [915] 10.42.0.13 LOG:  execute S_37: INSERT INTO JGROUPS_PING (address, name, cluster_name, ip, coord, last_update, coordinated_by) values ($1
+2026-09-17 04:47:43.567 UTC [915] 10.42.0.13 DETAIL:  parameters: $1 = 'uuid://00000000-0000-0000-0000-000000000003', $2 = 'keycloak-1-50073', $3 = 'ISPN', $4 = '10.42.0.
+2026-09-17 04:47:43.568 UTC [915] 10.42.0.13 LOG:  execute S_2: COMMIT
+2026-09-17 04:47:43.578 UTC [915] 10.42.0.13 LOG:  statement: BEGIN
+2026-09-17 04:47:43.578 UTC [915] 10.42.0.13 LOG:  execute S_36: DELETE from JGROUPS_PING WHERE address=$1
+2026-09-17 04:47:43.578 UTC [915] 10.42.0.13 DETAIL:  parameters: $1 = 'uuid://00000000-0000-0000-0000-000000000004'
+2026-09-17 04:47:43.580 UTC [915] 10.42.0.13 LOG:  execute S_37: INSERT INTO JGROUPS_PING (address, name, cluster_name, ip, coord, last_update, coordinated_by) values ($1
+2026-09-17 04:47:43.580 UTC [915] 10.42.0.13 DETAIL:  parameters: $1 = 'uuid://00000000-0000-0000-0000-000000000004', $2 = 'keycloak-0-25228', $3 = 'ISPN', $4 = '10.42.1.
+2026-09-17 04:47:43.580 UTC [915] 10.42.0.13 LOG:  execute S_2: COMMIT
+2026-09-17 04:47:48.315 UTC [915] 10.42.0.13 LOG:  execute S_34: SELECT address, name, ip, coord, coordinated_by, last_update FROM JGROUPS_PING WHERE cluster_name=$1
+2026-09-17 04:47:48.315 UTC [915] 10.42.0.13 DETAIL:  parameters: $1 = 'ISPN'
+=== 같은 창의 줄 수 (pod 별) ===
+17
+26
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-12-test0d-controlled.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-12-test0d-controlled.txt
new file mode 100644
index 0000000..19f8884
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-12-test0d-controlled.txt
@@ -0,0 +1,20 @@
+K0(keycloak-0)=10.42.1.7  K1(keycloak-1)=10.42.0.13
+=== 캐시 전값 ===
+keycloak-0   clientSessions   10
+keycloak-0   sessions         10
+keycloak-1   clientSessions   5
+keycloak-1   sessions         5
+SID=j7eRVo7v08st1EAoQj1WLcjG
+MARK_BEFORE_REFRESH
+REFRESH_ON_K1=200
+=== 그 sid 가 들어간 DB 줄 — 어느 파드가 냈나 ===
+      6 [915]
+      6 [948]
+=== 같은 창에서 세션 테이블을 건드린 문장을 파드별로 ===
+      6 [915]
+     12 [948]
+=== 캐시 후값 (refresh 를 받은 keycloak-1 이 늘었나) ===
+keycloak-0   clientSessions   11
+keycloak-0   sessions         11
+keycloak-1   clientSessions   5
+keycloak-1   sessions         5
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-13-test0d-sql-lines.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-13-test0d-sql-lines.txt
new file mode 100644
index 0000000..4d69a2b
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a0-13-test0d-sql-lines.txt
@@ -0,0 +1,57 @@
+=== 반대편 노드(keycloak-1, pid 915) 가 날린 문장 — 문서의 여덟 줄과 대조 ===
+[915] 10.42.0.13 LOG:  statement: 
+[916] 10.42.0.13 LOG:  statement: 
+[915] 10.42.0.13 LOG:  statement: BEGIN
+[915] 10.42.0.13 LOG:  execute S_2: COMMIT
+[915] 10.42.0.13 LOG:  statement: BEGIN
+[915] 10.42.0.13 LOG:  execute S_2: COMMIT
+[916] 10.42.0.13 LOG:  statement: 
+[915] 10.42.0.13 LOG:  statement: 
+[916] 10.42.0.13 LOG:  statement: 
+[917] 10.42.0.13 LOG:  statement: 
+[916] 10.42.0.13 LOG:  statement: 
+[916] 10.42.0.13 LOG:  statement: 
+[915] 10.42.0.13 LOG:  statement: BEGIN
+[915] 10.42.0.13 LOG:  execute S_54/C_73: select puse1_0.OFFLINE_FLAG,puse1_0.USER_SESSION_ID,puse1_0.BROKER_SESSION_ID,puse1_0.CREATED_ON,puse1_0.DATA,puse1_0.LAST_
+[915] 10.42.0.13 LOG:  execute <unnamed>/C_74: select puse1_0.VERSION from OFFLINE_USER_SESSION puse1_0 where puse1_0.USER_SESSION_ID=$1 and puse1_0.OFFLINE_FLAG=$2 
+[915] 10.42.0.13 LOG:  execute S_56/C_75: select pcse1_0.CLIENT_ID,pcse1_0.CLIENT_STORAGE_PROVIDER,pcse1_0.EXTERNAL_CLIENT_ID,pcse1_0.OFFLINE_FLAG,pcse1_0.USER_SESSI
+[915] 10.42.0.13 LOG:  execute <unnamed>/C_76: select pcse1_0.VERSION from OFFLINE_CLIENT_SESSION pcse1_0 where pcse1_0.USER_SESSION_ID=$1 and pcse1_0.OFFLINE_FLAG=$
+[915] 10.42.0.13 LOG:  execute <unnamed>: update OFFLINE_CLIENT_SESSION set TIMESTAMP=$1,VERSION=$2 where CLIENT_ID=$3 and CLIENT_STORAGE_PROVIDER=$4 and EXTERNAL_CL
+[915] 10.42.0.13 LOG:  execute <unnamed>: update OFFLINE_USER_SESSION set LAST_SESSION_REFRESH=$1,VERSION=$2 where OFFLINE_FLAG=$3 and USER_SESSION_ID=$4 and VERSION
+[915] 10.42.0.13 LOG:  execute <unnamed>: SET LOCAL synchronous_commit TO OFF
+[915] 10.42.0.13 LOG:  execute S_2: COMMIT
+[915] 10.42.0.13 LOG:  statement: BEGIN
+[915] 10.42.0.13 LOG:  execute S_2: COMMIT
+[915] 10.42.0.13 LOG:  statement: BEGIN
+[915] 10.42.0.13 LOG:  execute S_2: COMMIT
+[916] 10.42.0.13 LOG:  statement: 
+[916] 10.42.0.13 LOG:  statement: 
+[916] 10.42.0.13 LOG:  statement: 
+[915] 10.42.0.13 LOG:  statement: BEGIN
+[915] 10.42.0.13 LOG:  execute S_2: COMMIT
+[915] 10.42.0.13 LOG:  statement: BEGIN
+[915] 10.42.0.13 LOG:  execute S_2: COMMIT
+[916] 10.42.0.13 LOG:  statement: 
+
+=== 그 트랜잭션의 경계 (pid 915 의 BEGIN~COMMIT) ===
+2026-09-17 04:48:13.896 UTC [915] 10.42.0.13 LOG:  statement: BEGIN
+2026-09-17 04:48:13.898 UTC [915] 10.42.0.13 LOG:  execute S_2: COMMIT
+2026-09-17 04:48:13.908 UTC [915] 10.42.0.13 LOG:  statement: BEGIN
+2026-09-17 04:48:13.912 UTC [915] 10.42.0.13 LOG:  execute S_2: COMMIT
+2026-09-17 04:48:45.920 UTC [915] 10.42.0.13 LOG:  statement: BEGIN
+2026-09-17 04:48:45.922 UTC [915] 10.42.0.13 LOG:  execute S_2: COMMIT
+2026-09-17 04:48:45.933 UTC [915] 10.42.0.13 LOG:  statement: BEGIN
+2026-09-17 04:48:45.934 UTC [915] 10.42.0.13 LOG:  execute S_2: COMMIT
+=== 되돌리기 — 문장 로깅을 끈다 ===
+ALTER SYSTEM
+ALTER SYSTEM
+ pg_reload_conf 
+----------------
+ t
+(1 row)
+
+ log_statement 
+---------------
+ none
+(1 row)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-01-inject.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-01-inject.txt
new file mode 100644
index 0000000..ec04cc1
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-01-inject.txt
@@ -0,0 +1,50 @@
+=== a1 주입 1-① 매니페스트를 먼저 읽는다 ===
+# Experiment A-1 — cut the JGroups transport (TCP 7800) while leaving discovery alone.
+#
+# The point is to separate two things that are easy to conflate:
+#
+#   discovery   how the nodes FIND each other   -> PostgreSQL JGROUPS_PING table
+#   transport   how they actually TALK          -> TCP 7800
+#
+# Blocking only the transport produces a state that cannot happen on a single
+# node: both members stay registered in the database, so each believes the other
+# exists, yet no message gets through.
+#
+#   kubectl apply -f deploy/lab/k8s/a1-block-jgroups-transport.yaml
+#   kubectl -n keycloak-lab delete networkpolicy a1-block-jgroups-transport
+#
+# NetworkPolicy is an ALLOWLIST, not a firewall with deny rules. There is no way
+# to write "deny 7800". The moment a pod is selected by a policy carrying
+# policyTypes: [Ingress], every inbound port is denied unless a rule permits it.
+# So 7800 is blocked by *omission*: 8080 and 9000 are listed, 7800 is not.
+#
+# That makes the two allow rules load-bearing — get them wrong and the experiment
+# measures a dead Keycloak instead of a partitioned cluster:
+#
+#   8080  the HTTP endpoint. Traefik, the other pod's REST calls, and the probe
+#         traffic all arrive here.
+#   9000  the management port: /health/started, /health/ready, /health/live and
+#         /metrics. Losing it means the kubelet fails the readiness probe and
+#         kills the pod — the cluster would break for the wrong reason.
+#
+# Both rules deliberately omit `from:`, which allows those ports from any source.
+# Narrowing the source is not the subject here; the 2-hop experiment already
+# established how to do that by label when it matters.
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: a1-block-jgroups-transport
+  namespace: keycloak-lab
+spec:
+  podSelector:
+    matchLabels:
+      app: keycloak
+  policyTypes: [Ingress]
+  ingress:
+    - ports:
+        - { port: 8080, protocol: TCP }   # HTTP — must stay open
+        - { port: 9000, protocol: TCP }   # health + metrics — must stay open
+    # 7800 is absent on purpose. That is the whole experiment.
+=== a1 주입 1-② 적용하고 시각 ===
+networkpolicy.networking.k8s.io/a1-block-jgroups-transport created
+13:53:51 적용
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-02-verify.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-02-verify.txt
new file mode 100644
index 0000000..44e9f50
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-02-verify.txt
@@ -0,0 +1,29 @@
+=== a1 검증 1 정책 ===
+NAME                         POD-SELECTOR   AGE
+a1-block-jgroups-transport   app=keycloak   11s
+Name:         a1-block-jgroups-transport
+Namespace:    keycloak-lab
+Created on:   2026-09-17 13:52:16 +0900 KST
+Labels:       <none>
+Annotations:  <none>
+Spec:
+  PodSelector:     app=keycloak
+  Allowing ingress traffic:
+    To Port: 8080/TCP
+    To Port: 9000/TCP
+    From: <any> (traffic not restricted by source)
+  Not affecting egress traffic
+  Policy Types: Ingress
+=== 파드가 죽지 않았는지 ===
+keycloak-0                  1/1     Running   0          8m25s   10.42.1.7    kc-lab-2   <none>           <none>
+keycloak-1                  1/1     Running   0          8m47s   10.42.0.13   kc-lab-1   <none>           <none>
+=== a1 검증 2 포트 셋 (K0=10.42.1.7) ===
+9000 200
+8080 200
+7800 000
+exit=7
+=== a1 검증 3 클러스터가 깨졌나 ===
+{"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"vendor_cluster_size","cache_manager":"keycloak","exported_node":"keycloak-1-50073","instance":"10.42.0.13:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620750.808,"2"]},{"metric":{"__name__":"vendor_cluster_size","cache_manager":"keycloak","exported_node":"keycloak-0-25228","instance":"10.42.1.7:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620750.808,"2"]}]}}
+=== 7800 은 16진수로 1E78 ===
+   4: 0000000000000000FFFF000007012A0A:1E78 00000000000000000000000000000000:0000 0A 00000000:00000000 00:00000000 00000000  1000        0 47139 1 00000000a06c8407 100 0 0 10 0
+  11: 0000000000000000FFFF000007012A0A:1E78 0000000000000000FFFF00000D002A0A:E94D 01 00000000:00000000 02:000A3CB8 00000000  1000        0 47142 2 00000000c8c90f53 22 4 30 10 -1
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-03-conntrack.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-03-conntrack.txt
new file mode 100644
index 0000000..01a74df
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-03-conntrack.txt
@@ -0,0 +1,3 @@
+=== a1 검증 4 conntrack — kc-lab-1 ===
+--- 같은 것을 2>/dev/null 없이 (요약 줄이 보인다) ---
+=== a1 검증 4 conntrack — kc-lab-2 ===
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-04-conntrack-missing.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-04-conntrack-missing.txt
new file mode 100644
index 0000000..368ceca
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-04-conntrack-missing.txt
@@ -0,0 +1,12 @@
+=== conntrack 이 게스트에 있나 ===
+sudo: conntrack: command not found
+(exit 0)
+--- 실행 파일 ---
+ls: cannot access '/usr/sbin/conntrack': No such file or directory
+dpkg-query: no packages found matching conntrack
+=== nf_conntrack 모듈과 표는 있나 ===
+6
+218 /proc/net/nf_conntrack
+=== 대안: /proc/net/nf_conntrack 에서 7800 을 찾는다 ===
+ipv4     2 tcp      6 86399 ESTABLISHED src=10.42.0.13 dst=10.42.1.7 sport=59725 dport=7800 src=10.42.1.7 dst=10.42.0.13 sport=7800 dport=59725 [ASSURED] mark=0 zone=0 use=2
+ipv4     2 tcp      6 85891 ESTABLISHED src=10.42.0.13 dst=10.42.1.7 sport=38439 dport=57800 src=10.42.1.7 dst=10.42.0.13 sport=57800 dport=38439 [ASSURED] mark=0 zone=0 use=2
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-05-conntrack-installed.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-05-conntrack-installed.txt
new file mode 100644
index 0000000..f95593a
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-05-conntrack-installed.txt
@@ -0,0 +1,11 @@
+=== 처방 검증: 두 노드에 conntrack 을 깐다 ===
+--- kc-lab-1 ---
+Setting up conntrack (1:1.4.7-1+b2) ...
+Processing triggers for man-db (2.11.2-2) ...
+tcp      6 86398 ESTABLISHED src=10.42.0.13 dst=10.42.1.7 sport=59725 dport=7800 src=10.42.1.7 dst=10.42.0.13 sport=7800 dport=59725 [ASSURED] mark=0 use=1
+tcp      6 85885 ESTABLISHED src=10.42.0.13 dst=10.42.1.7 sport=38439 dport=57800 src=10.42.1.7 dst=10.42.0.13 sport=57800 dport=38439 [ASSURED] mark=0 use=1
+--- kc-lab-2 ---
+Setting up conntrack (1:1.4.7-1+b2) ...
+Processing triggers for man-db (2.11.2-2) ...
+tcp      6 86397 ESTABLISHED src=10.42.0.13 dst=10.42.1.7 sport=59725 dport=7800 src=10.42.1.7 dst=10.42.0.13 sport=7800 dport=59725 [ASSURED] mark=0 use=1
+tcp      6 85884 ESTABLISHED src=10.42.0.13 dst=10.42.1.7 sport=38439 dport=57800 src=10.42.1.7 dst=10.42.0.13 sport=57800 dport=38439 [ASSURED] mark=0 use=1
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-06-forced-partition.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-06-forced-partition.txt
new file mode 100644
index 0000000..9873c07
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-06-forced-partition.txt
@@ -0,0 +1,12 @@
+=== a1 6-① 시각을 남기고 파드를 지운다 ===
+13:55:06 재시작
+pod "keycloak-0" deleted from keycloak-lab namespace
+=== a1 6-② 새 파드와 새 주소 ===
+keycloak-1                  1/1     Running   0          9m54s   10.42.0.13   kc-lab-1   <none>           <none>
+=== 60초 뒤 파드 상태 (분단된 노드가 Ready 를 잃었나) ===
+keycloak-0                  1/1     Running   0          60s   10.42.1.17   kc-lab-2   <none>           <none>
+keycloak-1                  1/1     Running   0          10m   10.42.0.13   kc-lab-1   <none>           <none>
+=== 멤버 수 ===
+{"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"vendor_cluster_size","cache_manager":"keycloak","exported_node":"keycloak-1-50073","instance":"10.42.0.13:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620875.437,"1"]},{"metric":{"__name__":"vendor_cluster_size","cache_manager":"keycloak","exported_node":"keycloak-0-53888","instance":"10.42.1.17:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620875.437,"1"]}]}}
+=== Service 뒤에 누가 남았나 ===
+Endpoints:                10.42.0.13:8080,10.42.1.17:8080
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-07-readiness.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-07-readiness.txt
new file mode 100644
index 0000000..cca74a1
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-07-readiness.txt
@@ -0,0 +1,40 @@
+=== 분단이 확정되고 몇 분 뒤 ===
+14:22:18
+keycloak-0                  0/1     Running   0          27m   10.42.1.17   kc-lab-2   <none>           <none>
+keycloak-1                  1/1     Running   0          37m   10.42.0.13   kc-lab-1   <none>           <none>
+--- Ready 조건 ---
+PodReadyToStartContainers=True Initialized=True Ready=False ContainersReady=False PodScheduled=True 
+PodReadyToStartContainers=True Initialized=True Ready=True ContainersReady=True PodScheduled=True 
+--- readiness 프로브 설정 ---
+{"failureThreshold":3,"httpGet":{"path":"/health/ready","port":"management","scheme":"HTTP"},"periodSeconds":10,"successThreshold":1,"timeoutSeconds":1}
+--- Service Endpoints ---
+Endpoints:                10.42.0.13:8080
+--- 두 노드의 health/ready 를 직접 ---
+keycloak-0 ready=503
+keycloak-1 ready=200
+--- keycloak-0 의 실패 항목 ---
+{
+    "status": "DOWN",
+    "checks": [
+        {
+            "name": "Graceful Shutdown",
+            "status": "UP"
+        },
+        {
+            "name": "Keycloak Initialized",
+            "status": "UP"
+        },
+        {
+            "name": "Keycloak cluster health check",
+            "status": "DOWN",
+            "data": {
+                "Failing since": "2026-09-17 04:54:25,769"
+            }
+        },
+        {
+            "name": "Keycloak database connections async health check"
+--- 멤버 수 ---
+"pod":"keycloak-1"}
+"1"]}
+"pod":"keycloak-0"}
+"1"]}]}}
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-08-readiness-commands.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-08-readiness-commands.txt
new file mode 100644
index 0000000..cd12cb8
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-08-readiness-commands.txt
@@ -0,0 +1,11 @@
+=== 문서가 적은 명령 그대로: describe pod | grep -A5 Conditions ===
+Conditions:
+  Type                        Status
+  PodReadyToStartContainers   True 
+  Initialized                 True 
+  Ready                       False 
+  ContainersReady             False 
+=== 문서의 Ready 칸 뽑기 형태 ===
+zsh:5: no matches found: custom-columns=NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount
+=== EndpointSlice 형태 ===
+zsh:7: no matches found: custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-09-quoting-and-health.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-09-quoting-and-health.txt
new file mode 100644
index 0000000..07cebc3
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-09-quoting-and-health.txt
@@ -0,0 +1,35 @@
+=== 이 호스트의 셸 ===
+/bin/zsh
+zsh
+=== 따옴표를 씌우면 ===
+keycloak-0                  false   0
+keycloak-1                  true    0
+NAME             ADDR                        READY
+keycloak-lxk8h   [10.42.0.13],[10.42.1.17]   true,false
+=== 헬스 본문을 내는 명령 (문서가 JSON 을 실은 자리의 진짜 출처) ===
+{
+    "status": "DOWN",
+    "checks": [
+        {
+            "name": "Graceful Shutdown",
+            "status": "UP"
+        },
+        {
+            "name": "Keycloak Initialized",
+            "status": "UP"
+        },
+        {
+            "name": "Keycloak cluster health check",
+            "status": "DOWN",
+            "data": {
+                "Failing since": "2026-09-17 04:54:25,769"
+            }
+        },
+        {
+            "name": "Keycloak database connections async health check",
+            "status": "UP"
+        }
+    ]
+}
+=== 밖에서 정문 (Host 헤더로 TLS 없이) ===
+200
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-10-cross-node-under-partition.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-10-cross-node-under-partition.txt
new file mode 100644
index 0000000..de751cd
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-10-cross-node-under-partition.txt
@@ -0,0 +1,9 @@
+분단 상태 K0=10.42.1.17 K1=10.42.0.13
+# [1] keycloak-0 에서 로그인
+sid=XliiKcW3DYw4hY_a3m2FX6e4# [2] keycloak-1 에서 refresh
+200
+# [3] keycloak-1 에서 로그아웃
+204
+# [4] keycloak-0 에서 재갱신 시도
+{"access_token":"<REDACTED 758자>","expires_in":60,"refresh_expires_in":1800,"refresh_token":"<REDACTED 612자>","token_type":"Bearer","not-before-policy":0,"session_state":"XliiKcW3DYw4hY_a3m2FX6e4","scope":"profile email"}
+200
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-11-recover.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-11-recover.txt
new file mode 100644
index 0000000..263f8a6
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a1-11-recover.txt
@@ -0,0 +1,14 @@
+a1 토큰 노출 경고 추가
+=== a1 되돌리기 1-① 시각을 남기고 정책을 지운다 ===
+14:23:52 해제
+networkpolicy.networking.k8s.io "a1-block-jgroups-transport" deleted from keycloak-lab namespace
+=== 30초 간격으로 멤버 수 ===
+14:24:22 "pod":"keycloak-1"} "1"]} "pod":"keycloak-0"} "1"]}]}} 
+14:24:52 "pod":"keycloak-1"} "2"]} "pod":"keycloak-0"} "2"]}]}} 
+14:25:22 "pod":"keycloak-1"} "2"]} "pod":"keycloak-0"} "2"]}]}} 
+14:25:52 "pod":"keycloak-1"} "2"]} "pod":"keycloak-0"} "2"]}]}} 
+=== 파드 상태 ===
+keycloak-0                  1/1     Running   0          30m   10.42.1.17   kc-lab-2   <none>           <none>
+keycloak-1                  1/1     Running   0          40m   10.42.0.13   kc-lab-1   <none>           <none>
+
+[exited with code 0]
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-01-baseline-probe.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-01-baseline-probe.txt
new file mode 100644
index 0000000..2bd2f54
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-01-baseline-probe.txt
@@ -0,0 +1,9 @@
+K0=10.42.1.17 K1=10.42.0.13
+=== a2 상주 탐침 파드 ===
+pod/a2-probe created
+pod/a2-probe condition met
+=== 환경변수 (길이만) ===
+K0=10.42.1.17 K1=10.42.0.13 PW길이=19
+=== 정지 전 네 경로 — 토큰을 파드 안 파일에 담는다 ===
+rt0=613자 rt1=613자 at=759자
+CID=2d7893fb-6003-4f0e-b6a8-d6e7e9e8fa25
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-02-inject.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-02-inject.txt
new file mode 100644
index 0000000..ed49228
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-02-inject.txt
@@ -0,0 +1,18 @@
+=== 정지 전 네 경로 ===
+① 200
+② 200
+③ 200
+④ 200
+=== a2 주입 ① 시각과 replicas=0 ===
+14:27:23 정지
+deployment.apps/postgres scaled
+=== ② 파드가 사라질 때까지 ===
+pod/postgres-7b474b88c8-s6vdh condition met
+14:27:24 삭제완료
+=== 검증 1 파드와 Deployment ===
+NAME         READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
+a2-probe     1/1     Running   0          10s   10.42.1.22   kc-lab-2   <none>           <none>
+keycloak-0   1/1     Running   0          32m   10.42.1.17   kc-lab-2   <none>           <none>
+keycloak-1   1/1     Running   0          42m   10.42.0.13   kc-lab-1   <none>           <none>
+NAME       READY   UP-TO-DATE   AVAILABLE   AGE
+postgres   0/0     0            0           51m
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-03-during-outage.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-03-during-outage.txt
new file mode 100644
index 0000000..2a409b5
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-03-during-outage.txt
@@ -0,0 +1,22 @@
+=== 정지 직후 네 경로 ===
+① 500
+② 500
+③ 500
+④ 500
+=== 500 의 본문 ===
+{"error":"unknown_error","error_description":"For more on this error consult the server log."}
+=== 서명 검증만 필요한 두 경로 ===
+JWKS      200
+well-known 200
+=== 커넥션 풀 로그 ===
+Caused by: java.net.ConnectException: Connection refused
+	at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:219)
+	at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:365)
+=== Ready 와 재시작 ===
+keycloak-0   true    0
+keycloak-1   true    0
+=== Endpoints ===
+NAME             ADDR                        READY
+keycloak-lxk8h   [10.42.0.13],[10.42.1.17]   true,true
+=== 정문 (TLS 없이 Host 헤더로) ===
+200
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-04-outage-progression.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-04-outage-progression.txt
new file mode 100644
index 0000000..6e44a4b
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-04-outage-progression.txt
@@ -0,0 +1,3 @@
+14:28:13 ready=false,false, 정문=503 엔드포인트=false,false
+14:28:43 ready=false,false, 정문=503 엔드포인트=false,false
+14:29:13 ready=false,false, 정문=503 엔드포인트=false,false
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-05-recover.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-05-recover.txt
new file mode 100644
index 0000000..c416b38
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a2-05-recover.txt
@@ -0,0 +1,19 @@
+=== a2 복구 시각과 replicas=1 ===
+14:29:20 복구
+deployment.apps/postgres scaled
+Waiting for deployment "postgres" rollout to finish: 0 out of 1 new replicas have been updated...
+Waiting for deployment "postgres" rollout to finish: 0 of 1 updated replicas are available...
+deployment "postgres" successfully rolled out
+14:29:56 ready=true,true, 정문=200 재시작=0,0,
+14:30:21 ready=true,true, 정문=200 재시작=0,0,
+14:30:46 ready=true,true, 정문=200 재시작=0,0,
+14:31:12 ready=true,true, 정문=200 재시작=0,0,
+=== 복구 뒤 네 경로 (④ 는 토큰이 만료됐을 수 있다) ===
+① 200
+② 200
+③ 200
+④ 401
+=== 탐침 파드를 지운다 ===
+pod "a2-probe" deleted from keycloak-lab namespace
+
+[exited with code 0]
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-01-design-check.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-01-design-check.txt
new file mode 100644
index 0000000..c93bb49
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-01-design-check.txt
@@ -0,0 +1,44 @@
+=== a3 설계 확인 ① 문장 로깅 켜기 ===
+ t
+(1 row)
+
+ log_statement 
+---------------
+ all
+(1 row)
+
+=== ② 탐침 파드 ===
+pod/a3-probe created
+pod/a3-probe condition met
+=== ③ 길이만 ===
+19
+K0=10.42.1.17 PW길이=19
+=== ④ 로그인 한 번 ===
+200
+=== ⑤ 그 로그인의 트랜잭션 ===
+2026-09-17 05:31:55.093 UTC [41] LOG:  statement: BEGIN
+2026-09-17 05:31:55.099 UTC [41] LOG:  execute S_6: COMMIT
+2026-09-17 05:31:55.101 UTC [41] LOG:  statement: BEGIN
+2026-09-17 05:31:55.104 UTC [41] LOG:  execute <unnamed>: insert into OFFLINE_USER_SESSION (BROKER_SESSION_ID,CREATED_ON,DATA,LAST_SESSION_REFRESH,REALM_ID,REMEMBER_ME,USER_ID,VERSION,OFFLINE_FLAG,USER_SESSION_ID) values ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10)
+2026-09-17 05:31:55.104 UTC [41] LOG:  execute <unnamed>: insert into OFFLINE_CLIENT_SESSION (DATA,REALM_ID,TIMESTAMP,VERSION,CLIENT_ID,CLIENT_STORAGE_PROVIDER,EXTERNAL_CLIENT_ID,OFFLINE_FLAG,USER_SESSION_ID) values ($1,$2,$3,$4,$5,$6,$7,$8,$9)
+2026-09-17 05:31:55.104 UTC [41] LOG:  execute <unnamed>: SET LOCAL synchronous_commit TO OFF
+2026-09-17 05:31:55.104 UTC [41] LOG:  execute S_6: COMMIT
+2026-09-17 05:31:59.694 UTC [40] LOG:  statement: BEGIN
+2026-09-17 05:31:59.696 UTC [40] LOG:  execute S_1: COMMIT
+=== ⑥ 문장 로깅 끄기 ===
+(1 row)
+
+ log_statement 
+---------------
+ none
+(1 row)
+
+=== 커밋·WAL 설정 네 줄 ===
+          name          | setting | unit | source  
+------------------------+---------+------+---------
+ commit_delay           | 0       |      | default
+ synchronous_commit     | on      |      | default
+ wal_writer_delay       | 200     | ms   | default
+ wal_writer_flush_after | 128     | 8kB  | default
+(4 rows)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-02-prepare.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-02-prepare.txt
new file mode 100644
index 0000000..9efc69e
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-02-prepare.txt
@@ -0,0 +1,15 @@
+=== a3 4-① 세션 비우기 ===
+DELETE 5
+ count 
+-------
+     0
+(1 row)
+
+=== 5. 파드 셋 ===
+NAME                        READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES
+a3-probe                    1/1     Running   0          30s     10.42.1.24   kc-lab-2   <none>           <none>
+keycloak-0                  1/1     Running   0          38m     10.42.1.17   kc-lab-2   <none>           <none>
+keycloak-1                  1/1     Running   0          48m     10.42.0.13   kc-lab-1   <none>           <none>
+postgres-7b474b88c8-sspdm   1/1     Running   0          4m38s   10.42.1.23   kc-lab-2   <none>           <none>
+=== 주입 1-② 루프 파일을 파드에 밀어 넣는다 ===
+18 /tmp/a3-login-loop.sh
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-03-attempt1.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-03-attempt1.txt
new file mode 100644
index 0000000..a7d03ef
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-03-attempt1.txt
@@ -0,0 +1,18 @@
+=== 8초 뒤 쌓인 수 ===
+0 /tmp/sids
+=== 시도 ① --grace-period=0 --force ===
+14:34:15.621 종료
+Warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
+pod "postgres-7b474b88c8-sspdm" force deleted from keycloak-lab namespace
+14:34:15.722 반환
+=== 루프 출력 ===
+=== 파드 상태 ===
+NAME                        READY   RESTARTS   AGE
+postgres-7b474b88c8-mh86k   true    0          2026-09-17T05:32:42Z
+=== 클라이언트가 200 받은 수 vs DB 행 수 ===
+0 /tmp/sids
+ count 
+-------
+   217
+(1 row)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-04-sids-no-newline.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-04-sids-no-newline.txt
new file mode 100644
index 0000000..714993b
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-04-sids-no-newline.txt
@@ -0,0 +1,12 @@
+=== 왜 0 줄인가 — 파일에 개행이 없다 ===
+0 /tmp/sids
+9384 /tmp/sids
+0022240   K   K   E   Q   -   g   O   y
+0022250
+=== busybox sed 가 끝에 개행을 안 붙인다 ===
+0000000   A   B   C
+0000003
+=== 처방: echo 로 감싼다 ===
+처방 결과: 10 줄 / 250 바이트
+iAxu1SRCu_c7uWTAka5MK-Xa
+4PU8l__EjhBWQVQTCnjyg_fD
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-05-attempt1-redo.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-05-attempt1-redo.txt
new file mode 100644
index 0000000..07c6376
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-05-attempt1-redo.txt
@@ -0,0 +1,18 @@
+19 /tmp/a3-login-loop.sh
+=== 8초 뒤 쌓인 수 ===
+109 /tmp/sids
+=== 시도 ① --grace-period=0 --force ===
+14:35:47.693 종료
+pod "postgres-7b474b88c8-mh86k" force deleted from keycloak-lab namespace
+14:35:47.797 반환
+=== 루프 출력 ===
+=== 새 파드 ===
+NAME                        READY   RESTARTS
+postgres-7b474b88c8-prlxx   true    0
+=== 클라이언트 200 수 vs DB 행 수 ===
+292 /tmp/sids
+ count 
+-------
+   296
+(1 row)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-06-attempt2.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-06-attempt2.txt
new file mode 100644
index 0000000..c278100
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-06-attempt2.txt
@@ -0,0 +1,19 @@
+=== 시도 ① 검증 — 재시작 횟수와 파드 나이 ===
+NAME                        RESTARTS   START
+postgres-7b474b88c8-prlxx   0          2026-09-17T05:34:14Z
+=== crash recovery 로그가 있나 ===
+2026-09-17 05:34:14.924 UTC [1] LOG:  starting PostgreSQL 16.15 on x86_64-pc-linux-musl, compiled by gcc (Alpine 15.2.0) 15.2.0, 64-bit
+2026-09-17 05:34:14.939 UTC [27] LOG:  database system was shut down at 2026-09-17 05:34:13 UTC
+
+=== 시도 ② kill -9 1 ===
+113 /tmp/sids
+14:36:29.106 SIGKILL
+=== 시도 ② 결과 ===
+NAME                        READY   RESTARTS
+postgres-7b474b88c8-prlxx   true    0
+400 /tmp/sids
+ count 
+-------
+   400
+(1 row)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-07-attempt3.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-07-attempt3.txt
new file mode 100644
index 0000000..d4ab1d0
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-07-attempt3.txt
@@ -0,0 +1,34 @@
+=== 시도 ③ 준비 — ps 로 무엇을 죽일지 본다 ===
+PID   USER     TIME  COMMAND
+    1 postgres  0:00 postgres
+   25 postgres  0:00 postgres: checkpointer 
+   26 postgres  0:00 postgres: background writer 
+   28 postgres  0:00 postgres: walwriter 
+   29 postgres  0:00 postgres: autovacuum launcher 
+   30 postgres  0:00 postgres: logical replication launcher 
+   39 postgres  0:00 postgres: keycloak keycloak 10.42.1.17(44654) idle
+   40 postgres  0:00 postgres: keycloak keycloak 10.42.1.17(44660) idle
+   41 postgres  0:00 postgres: keycloak keycloak 10.42.1.17(44670) idle
+   42 postgres  0:00 postgres: keycloak keycloak 10.42.1.17(44686) idle
+   43 postgres  0:00 postgres: keycloak keycloak 10.42.1.17(44690) idle
+=== 죽이기 직전 쌓인 수 ===
+113 /tmp/sids
+죽일 백엔드 PID=39
+14:37:10.925 백엔드 SIGKILL
+=== 시도 ③ 결과 ===
+NAME                        READY   RESTARTS
+postgres-7b474b88c8-prlxx   true    0
+--- crash recovery 로그 ---
+2026-09-17 05:35:36.810 UTC [1] LOG:  server process (PID 39) was terminated by signal 9: Killed
+2026-09-17 05:35:36.810 UTC [1] LOG:  terminating any other active server processes
+2026-09-17 05:35:36.817 UTC [1] LOG:  all server processes terminated; reinitializing
+2026-09-17 05:35:36.863 UTC [206] LOG:  database system was not properly shut down; automatic recovery in progress
+2026-09-17 05:35:36.885 UTC [207] LOG:  checkpoint starting: end-of-recovery immediate wait
+--- 클라이언트 200 수 ---
+395 /tmp/sids
+--- DB 행 수 ---
+ count 
+-------
+   392
+(1 row)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-08-loss-count.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-08-loss-count.txt
new file mode 100644
index 0000000..ddb6d0f
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-08-loss-count.txt
@@ -0,0 +1,32 @@
+=== 크래시 흔적 여섯 줄 ===
+2026-09-17 05:34:14.944 UTC [1] LOG:  database system is ready to accept connections
+2026-09-17 05:35:36.810 UTC [1] LOG:  server process (PID 39) was terminated by signal 9: Killed
+2026-09-17 05:35:36.817 UTC [1] LOG:  all server processes terminated; reinitializing
+2026-09-17 05:35:36.863 UTC [206] LOG:  database system was not properly shut down; automatic recovery in progress
+2026-09-17 05:35:36.865 UTC [206] LOG:  redo starts at 0/1F80A00
+2026-09-17 05:35:36.873 UTC [206] LOG:  redo done at 0/21D72B8 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
+2026-09-17 05:35:36.909 UTC [207] LOG:  checkpoint complete: wrote 243 buffers (1.5%); 0 WAL file(s) added, 0 removed, 1 recycled; write=0.008 s, sync=0.009 s, total=0.029 s; sync files=26, longest=0.007 s, average=0.001 s; distance=2397 kB, estimate=2397 kB; lsn=0/21D8048, redo lsn=0/21D8048
+2026-09-17 05:35:36.912 UTC [1] LOG:  database system is ready to accept connections
+=== 관찰 ① 클라이언트 sid 목록 ===
+395 /tmp/client-sids.txt
+uyMM_LOM5QgdNXZPymOt_d5-
+iNI2VuirdOjA-FT7iwt7F21I
+01uQ99zaBSaNtNt4v5tT-ned
+=== ② 총계 ===
+ count 
+-------
+   392
+(1 row)
+
+=== ③ 값만 파일로 ===
+392 /tmp/db-sids.txt
+=== ④ 정렬해서 왼쪽 전용만 ===
+  395 /tmp/a.txt
+  392 /tmp/b.txt
+  787 total
+=== ⑤ 유실 건수 ===
+3
+=== 유실된 sid (있으면) ===
+KvrWnKhKue4DlxozYc63HU4E
+S1iYLwU5oASbsePYH2Q1SB_A
+cUFSAEsClRh-OS-KvNnaa1Lu
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-09-revert.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-09-revert.txt
new file mode 100644
index 0000000..02c390b
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a3-09-revert.txt
@@ -0,0 +1,15 @@
+=== a3 되돌리기 ===
+ log_statement 
+---------------
+ none
+(1 row)
+
+DELETE 392
+statefulset.apps/keycloak restarted
+pod "a3-probe" deleted from keycloak-lab namespace
+=== DB 건강 ===
+ count 
+-------
+     1
+(1 row)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-01-baseline.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-01-baseline.txt
new file mode 100644
index 0000000..c79fbd7
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-01-baseline.txt
@@ -0,0 +1,29 @@
+=== a4 1-② virsh uri ===
+qemu:///system
+
+=== 주입 전 ① VM 전원 ===
+ Id   Name          State
+-----------------------------
+ 13   kc-lab-1      running
+ 14   kc-lab-2      running
+ 15   kc-lab-edge   running
+
+=== ② 노드와 파드 배치 ===
+NAME       STATUS   ROLES           AGE   VERSION
+kc-lab-1   Ready    control-plane   72m   v1.36.4+k3s1
+kc-lab-2   Ready    <none>          71m   v1.36.4+k3s1
+NAME                        READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES
+keycloak-0                  1/1     Running   0          37s     10.42.1.27   kc-lab-2   <none>           <none>
+keycloak-1                  1/1     Running   0          60s     10.42.0.14   kc-lab-1   <none>           <none>
+postgres-7b474b88c8-prlxx   1/1     Running   0          3m29s   10.42.1.26   kc-lab-2   <none>           <none>
+=== PVC 와 그 PV 가 요구하는 노드 ===
+NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
+postgres-data   Bound    pvc-fe269834-3dd1-4b1f-82f6-a53413310a30   5Gi        RWO            local-path     <unset>                 63m
+PV=pvc-fe269834-3dd1-4b1f-82f6-a53413310a30
+{"required":{"nodeSelectorTerms":[{"matchExpressions":[{"key":"kubernetes.io/hostname","operator":"In","values":["kc-lab-2"]}]}]}}
+=== 관측 스택이 어느 노드에 ===
+NAME                          READY   STATUS    RESTARTS   AGE   IP               NODE       NOMINATED NODE   READINESS GATES
+grafana-845b5678cf-bblgz      1/1     Running   0          59m   10.42.0.11       kc-lab-1   <none>           <none>
+node-exporter-82mmn           1/1     Running   0          59m   192.168.122.12   kc-lab-2   <none>           <none>
+node-exporter-g688j           1/1     Running   0          59m   192.168.122.11   kc-lab-1   <none>           <none>
+prometheus-6774f94f7c-pj8w9   1/1     Running   0          59m   10.42.0.12       kc-lab-1   <none>           <none>
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-02-inject-4a.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-02-inject-4a.txt
new file mode 100644
index 0000000..0a45956
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-02-inject-4a.txt
@@ -0,0 +1,27 @@
+=== 4a ① kc-lab-2 에 무엇이 있나 (영향 범위) ===
+keycloak-lab keycloak-0
+keycloak-lab postgres-7b474b88c8-prlxx
+kube-system svclb-traefik-72a92206-5jpxg
+observability node-exporter-82mmn
+=== ② 차단 시각 ===
+14:39:28 차단
+=== ③ 전원을 뽑는다 ===
+Domain 'kc-lab-2' destroyed
+
+=== 하이퍼바이저가 뭐라 하나 ===
+ Id   Name          State
+------------------------------
+ 13   kc-lab-1      running
+ 15   kc-lab-edge   running
+ -    kc-lab-2      shut off
+
+=== 10초 뒤 쿠버네티스 ===
+NAME       STATUS   ROLES           AGE   VERSION
+kc-lab-1   Ready    control-plane   72m   v1.36.4+k3s1
+kc-lab-2   Ready    <none>          71m   v1.36.4+k3s1
+NAME                        READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES
+keycloak-0                  1/1     Running   0          58s     10.42.1.27   kc-lab-2   <none>           <none>
+keycloak-1                  1/1     Running   0          81s     10.42.0.14   kc-lab-1   <none>           <none>
+postgres-7b474b88c8-prlxx   1/1     Running   0          3m50s   10.42.1.26   kc-lab-2   <none>           <none>
+=== 정문 (터미널 C: 밖에서) ===
+000
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-03-4a-progression.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-03-4a-progression.txt
new file mode 100644
index 0000000..7b9c1d9
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-03-4a-progression.txt
@@ -0,0 +1,20 @@
+--- 14:39:56 ---
+kc-lab-1 Ready kc-lab-2 Ready | 파드: keycloak-0                  Running   kc-lab-2;keycloak-1                  Running   kc-lab-1;postgres-7b474b88c8-prlxx   Running   kc-lab-2; | 정문=000
+--- 14:40:34 ---
+kc-lab-1 Ready kc-lab-2 NotReady | 파드: keycloak-0                  Running   kc-lab-2;keycloak-1                  Running   kc-lab-1;postgres-7b474b88c8-prlxx   Running   kc-lab-2; | 정문=503
+--- 14:41:08 ---
+kc-lab-1 Ready kc-lab-2 NotReady | 파드: keycloak-0                  Running   kc-lab-2;keycloak-1                  Running   kc-lab-1;postgres-7b474b88c8-prlxx   Running   kc-lab-2; | 정문=503
+--- 14:41:38 ---
+kc-lab-1 Ready kc-lab-2 NotReady | 파드: keycloak-0                  Running   kc-lab-2;keycloak-1                  Running   kc-lab-1;postgres-7b474b88c8-prlxx   Running   kc-lab-2; | 정문=503
+--- 14:42:08 ---
+kc-lab-1 Ready kc-lab-2 NotReady | 파드: keycloak-0                  Running   kc-lab-2;keycloak-1                  Running   kc-lab-1;postgres-7b474b88c8-prlxx   Running   kc-lab-2; | 정문=503
+--- 14:42:41 ---
+kc-lab-1 Ready kc-lab-2 NotReady | 파드: keycloak-0                  Running   kc-lab-2;keycloak-1                  Running   kc-lab-1;postgres-7b474b88c8-prlxx   Running   kc-lab-2; | 정문=503
+uccessfulCreate    statefulset/keycloak             Create Pod keycloak-0 in StatefulSet keycloak successful
+3m38s       Normal    Started             pod/keycloak-0                   Container started
+3m38s       Normal    Created             pod/keycloak-0                   Container created
+3m38s       Normal    Pulled              pod/keycloak-0                   Container image "quay.io/keycloak/keycloak:26.7.0" already present on machine and can be accessed by the pod
+3m28s       Warning   Unhealthy           pod/keycloak-0                   Startup probe failed: Get "http://10.42.1.27:9000/health/started": dial tcp 10.42.1.27:9000: connect: connection refused
+117s        Warning   NodeNotReady        pod/keycloak-0                   Node is not ready
+117s        Warning   NodeNotReady        pod/postgres-7b474b88c8-prlxx    Node is not ready
+6s          Warning   Unhealthy           pod/keycloak-1                   Readiness probe failed: Get "http://10.42.0.14:9000/health/ready": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-04-eviction-and-recover.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-04-eviction-and-recover.txt
new file mode 100644
index 0000000..a44c630
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-04-eviction-and-recover.txt
@@ -0,0 +1,34 @@
+=== 차단 +약 6분 — 축출이 일어났나 ===
+14:46:15
+keycloak-0 Terminating kc-lab-2
+keycloak-1 Running kc-lab-1
+postgres-7b474b88c8-5zp6v Pending <none>
+postgres-7b474b88c8-prlxx Terminating kc-lab-2
+kc-lab-1 Ready
+kc-lab-2 NotReady
+--- StatefulSet 파드와 Deployment 파드의 처지가 다른가 ---
+keycloak-0                  Running   2026-09-17T05:44:17Z
+keycloak-1                  Running   <none>
+postgres-7b474b88c8-5zp6v   Pending   <none>
+postgres-7b474b88c8-prlxx   Running   2026-09-17T05:44:17Z
+=== 복구: VM 을 다시 켠다 ===
+14:46:15 복구
+Domain 'kc-lab-2' started
+
+kc-lab-1 Ready
+kc-lab-2 NotReady
+keycloak-0 1/1 Terminating kc-lab-2
+keycloak-1 0/1 Running kc-lab-1
+postgres-7b474b88c8-5zp6v 0/1 Pending <none>
+postgres-7b474b88c8-prlxx 1/1 Terminating kc-lab-2
+정문=503
+
+[exited with code 0]
+--- 14:47:55 복구 확인 ---
+kc-lab-1 Ready
+kc-lab-2 NotReady
+keycloak-0 1/1 Terminating kc-lab-2
+keycloak-1 0/1 Running kc-lab-1
+postgres-7b474b88c8-5zp6v 0/1 Pending <none>
+postgres-7b474b88c8-prlxx 1/1 Terminating kc-lab-2
+정문=503
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-05-recovery-progression.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-05-recovery-progression.txt
new file mode 100644
index 0000000..45e1d4c
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-05-recovery-progression.txt
@@ -0,0 +1,12 @@
+14:48:49 kc-lab-1=Ready kc-lab-2=NotReady | keycloak-0:Terminating keycloak-1:Running postgres-7b474b88c8-5zp6v:Pending postgres-7b474b88c8-prlxx:Terminating | 정문=503
+14:49:34 kc-lab-1=Ready kc-lab-2=NotReady | keycloak-0:Terminating keycloak-1:Running postgres-7b474b88c8-5zp6v:Pending postgres-7b474b88c8-prlxx:Terminating | 정문=503
+14:50:19 kc-lab-1=Ready kc-lab-2=NotReady | keycloak-0:Terminating keycloak-1:Running postgres-7b474b88c8-5zp6v:Pending postgres-7b474b88c8-prlxx:Terminating | 정문=503
+14:51:05 kc-lab-1=Ready kc-lab-2=Ready | keycloak-0:Unknown keycloak-1:Running postgres-7b474b88c8-5zp6v:ContainerCreating postgres-7b474b88c8-prlxx:Unknown | 정문=503
+14:51:50 kc-lab-1=Ready kc-lab-2=Ready | keycloak-0:Running keycloak-1:Running postgres-7b474b88c8-5zp6v:Running | 정문=200
+14:48:49 kc-lab-1=Ready kc-lab-2=NotReady | keycloak-0:Terminating keycloak-1:Running postgres-7b474b88c8-5zp6v:Pending postgres-7b474b88c8-prlxx:Terminating | 정문=503
+14:49:34 kc-lab-1=Ready kc-lab-2=NotReady | keycloak-0:Terminating keycloak-1:Running postgres-7b474b88c8-5zp6v:Pending postgres-7b474b88c8-prlxx:Terminating | 정문=503
+14:50:19 kc-lab-1=Ready kc-lab-2=NotReady | keycloak-0:Terminating keycloak-1:Running postgres-7b474b88c8-5zp6v:Pending postgres-7b474b88c8-prlxx:Terminating | 정문=503
+14:51:05 kc-lab-1=Ready kc-lab-2=Ready | keycloak-0:Unknown keycloak-1:Running postgres-7b474b88c8-5zp6v:ContainerCreating postgres-7b474b88c8-prlxx:Unknown | 정문=503
+14:51:50 kc-lab-1=Ready kc-lab-2=Ready | keycloak-0:Running keycloak-1:Running postgres-7b474b88c8-5zp6v:Running | 정문=200
+
+[exited with code 0]
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-06-agent-token-missing.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-06-agent-token-missing.txt
new file mode 100644
index 0000000..5d514e9
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-06-agent-token-missing.txt
@@ -0,0 +1,10 @@
+=== 원인: 유닛이 --token-file 로 지운 파일을 가리킨다 ===
+	'--token-file' \
+	'/home/donghyeon/node-token' \
+
+=== 처방 ① 그 파일을 되돌려 놓는다 (값은 이 기계 밖으로 안 나간다) ===
+109
+=== agent 가 뜨나 ===
+active
+kc-lab-1 Ready
+kc-lab-2 Ready
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-07-token-remedy.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-07-token-remedy.txt
new file mode 100644
index 0000000..46f6f06
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a4-07-token-remedy.txt
@@ -0,0 +1,22 @@
+=== 처방 ② 토큰을 root 만 읽는 자리로 옮기고 유닛을 그쪽으로 돌린다 ===
+bash: line 1: /etc/rancher/node-token: Permission denied
+	'--token-file' \
+	'/etc/rancher/node-token' \
+=== 홈의 파일을 지운 뒤에도 뜨나 ===
+ls: cannot access '/home/donghyeon/node-token': No such file or directory
+active
+kc-lab-1 Ready
+kc-lab-2 Ready
+=== 재부팅을 견디는지 확인 — agent 를 완전히 다시 시작 ===
+active
+kc-lab-1 Ready
+kc-lab-2 Ready
+=== 옮긴 파일의 권한과 길이 ===
+-rw------- 1 root root 109 Sep 17 05:50 /etc/rancher/node-token
+109
+=== 유닛이 가리키는 자리 ===
+	'--token-file' \
+	'/etc/rancher/node-token' \
+=== 노드 ===
+kc-lab-1 Ready
+kc-lab-2 Ready
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-01-attempt1.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-01-attempt1.txt
new file mode 100644
index 0000000..20741d7
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-01-attempt1.txt
@@ -0,0 +1,17 @@
+K0(keycloak-0, kc-lab-2)=10.42.1.30  K1(keycloak-1, kc-lab-1)=10.42.0.14
+=== 문서의 [kc-lab-1] 블록을 그대로 — 게스트 셸에 $K1 이 있나 ===
+게스트 셸의 K1=[]
+=== 시도 ① filter FORWARD (보내는 쪽 노드에) ===
+14:54:11 주입
+--- 규칙과 카운터 ---
+Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
+num   pkts bytes target     prot opt in     out     source               destination         
+1        9   516 DROP       6    --  *      *       0.0.0.0/0            10.42.1.30           tcp dpt:57800
+2       22  2767 DROP       6    --  *      *       0.0.0.0/0            10.42.1.30           tcp dpt:7800
+3      921 1849K KUBE-ROUTER-FORWARD  0    --  *      *       0.0.0.0/0            0.0.0.0/0            /* kube-router netpol - TEMCG2JMHZYE7H7T */
+--- 멤버 수 ---
+"pod":"keycloak-1"} "2"]} "pod":"keycloak-0"} "2"]}]}} 
+=== 시도 ① 되돌리기 ===
+Chain FORWARD (policy ACCEPT)
+num  target     prot opt source               destination         
+1    KUBE-ROUTER-FORWARD  0    --  0.0.0.0/0            0.0.0.0/0            /* kube-router netpol - TEMCG2JMHZYE7H7T */
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-02-attempt2-3.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-02-attempt2-3.txt
new file mode 100644
index 0000000..5076721
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-02-attempt2-3.txt
@@ -0,0 +1,15 @@
+=== 시도 ② raw PREROUTING 을 보내는 쪽(kc-lab-2)에 ===
+14:55:06 주입
+Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
+num   pkts bytes target     prot opt in     out     source               destination         
+1        0     0 DROP       6    --  *      *       0.0.0.0/0            10.42.1.30           tcp dpt:57800
+2        0     0 DROP       6    --  *      *       0.0.0.0/0            10.42.1.30           tcp dpt:7800
+"pod":"keycloak-1"} "2"]} "pod":"keycloak-0"} "2"]}]}} 
+=== 시도 ② 되돌리기 ===
+=== 시도 ③ raw PREROUTING 을 받는 쪽(kc-lab-1)에 — 목적지는 keycloak-1 ===
+14:55:57 주입
+Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
+num   pkts bytes target     prot opt in     out     source               destination         
+1       16   916 DROP       6    --  *      *       0.0.0.0/0            10.42.0.14           tcp dpt:57800
+2       20  3257 DROP       6    --  *      *       0.0.0.0/0            10.42.0.14           tcp dpt:7800
+"pod":"keycloak-1"} "1"]} "pod":"keycloak-0"} "1"]}]}} 
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-03-one-direction-watch.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-03-one-direction-watch.txt
new file mode 100644
index 0000000..0209b71
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-03-one-direction-watch.txt
@@ -0,0 +1,7 @@
+=== 한 방향만 막은 채로 2분 더 — 다시 붙나 ===
+14:57:49 멤버="pod":"keycloak-1"} "2"]} "pod":"keycloak-0"} "2"]}]}} | coord=
+14:58:24 멤버="pod":"keycloak-1"} "2"]} "pod":"keycloak-0"} "2"]}]}} | coord=
+14:58:59 멤버="pod":"keycloak-1"} "2"]} "pod":"keycloak-0"} "2"]}]}} | coord=
+14:59:34 멤버="pod":"keycloak-1"} "2"]} "pod":"keycloak-0"} "2"]}]}} | coord=
+
+[exited with code 0]
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-04-bidirectional.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-04-bidirectional.txt
new file mode 100644
index 0000000..9f57b78
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-04-bidirectional.txt
@@ -0,0 +1,20 @@
+=== a5 네 번째 주입 — 양방향 ===
+15:00:13 주입
+--- 두 노드의 규칙과 카운터 ---
+Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
+ pkts bytes target     prot opt in     out     source               destination         
+   21  1208 DROP       6    --  *      *       0.0.0.0/0            10.42.0.14           tcp dpt:57800
+   21  3317 DROP       6    --  *      *       0.0.0.0/0            10.42.0.14           tcp dpt:7800
+Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
+ pkts bytes target     prot opt in     out     source               destination         
+    0     0 DROP       6    --  *      *       0.0.0.0/0            10.42.1.30           tcp dpt:57800
+   19  2595 DROP       6    --  *      *       0.0.0.0/0            10.42.1.30           tcp dpt:7800
+--- 멤버 수 ---
+"pod":"keycloak-1"} "1"]} "pod":"keycloak-0"} "1"]}]}} 
+--- coord 가 둘인가 ---
+       name       | coord 
+------------------+-------
+ keycloak-0-13476 | t
+ keycloak-1-8002  | t
+(2 rows)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-05-revert.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-05-revert.txt
new file mode 100644
index 0000000..7049399
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a5-05-revert.txt
@@ -0,0 +1,16 @@
+=== a5 되돌리기 — 두 노드의 raw 체인을 비운다 ===
+Chain PREROUTING (policy ACCEPT)
+num  target     prot opt source               destination         
+Chain PREROUTING (policy ACCEPT)
+num  target     prot opt source               destination         
+=== 다시 붙었나 ===
+"pod":"keycloak-1"} "2"]} "pod":"keycloak-0"} "2"]}]}} 
+       name       | coord 
+------------------+-------
+ keycloak-0-13476 | f
+ keycloak-1-8002  | t
+(2 rows)
+
+keycloak-0 1/1 Running
+keycloak-1 1/1 Running
+postgres-7b474b88c8-5zp6v 1/1 Running
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-01-attempt1-2.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-01-attempt1-2.txt
new file mode 100644
index 0000000..01430a5
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-01-attempt1-2.txt
@@ -0,0 +1,29 @@
+K0=10.42.1.30 K1=10.42.0.14 PG=10.42.1.29
+=== a6 시도 ① eth0 (예제 그대로) ===
+Cannot find device "eth0"
+=== ② 이 게스트에 무엇이 있나 ===
+lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
+enp1s0           UP             52:54:00:aa:bb:12 <BROADCAST,MULTICAST,UP,LOWER_UP> 
+flannel.1        UNKNOWN        da:f1:1f:7f:9e:da <BROADCAST,MULTICAST,UP,LOWER_UP> 
+cni0             UP             c6:f2:76:f6:72:0e <BROADCAST,MULTICAST,UP,LOWER_UP> 
+veth5f5079ef@if2 UP             7a:c7:1b:85:f0:92 <BROADCAST,MULTICAST,UP,LOWER_UP> 
+veth5ef1875b@if2 UP             82:ef:56:9c:1d:52 <BROADCAST,MULTICAST,UP,LOWER_UP> 
+veth8d0ac36c@if2 UP             56:50:6c:30:63:ac <BROADCAST,MULTICAST,UP,LOWER_UP> 
+=== 시도 ② 미검증 두 줄 — 물리 쪽 ===
+IP 10.42.1.30.7800 > 10.42.0.14.50799: Flags [.], ack 208, win 509, options [nop,nop,TS val 2179731813 ecr 4085265222], length 0
+06:02:02.268760 IP 192.168.122.12.53654 > 192.168.122.11.8472: OTV, flags [I] (0x08), overlay 0, instance 1
+IP 10.42.1.30.7800 > 10.42.0.14.50799: Flags [P.], seq 238:336, ack 208, win 509, options [nop,nop,TS val 2179731905 ecr 4085265222], length 98
+06:02:02.309848 IP 192.168.122.11.60237 > 192.168.122.12.8472: OTV, flags [I] (0x08), overlay 0, instance 1
+IP 10.42.0.14.50799 > 10.42.1.30.7800: Flags [.], ack 336, win 823, options [nop,nop,TS val 4085265356 ecr 2179731905], length 0
+5 packets captured
+5 packets received by filter
+0 packets dropped by kernel
+=== 터널 쪽 ===
+06:02:05.445308 IP 10.42.0.14.52916 > 10.42.1.29.5432: Flags [P.], seq 2469151212:2469151253, ack 2840346855, win 502, options [nop,nop,TS val 1040631333 ecr 678493794], length 41
+06:02:05.445613 IP 10.42.1.29.5432 > 10.42.0.14.52916: Flags [P.], seq 1:343, ack 41, win 502, options [nop,nop,TS val 678500272 ecr 1040631333], length 342
+06:02:05.446042 IP 10.42.0.14.52916 > 10.42.1.29.5432: Flags [.], ack 343, win 502, options [nop,nop,TS val 1040631334 ecr 678500272], length 0
+06:02:08.968064 IP 10.42.0.14.52916 > 10.42.1.29.5432: Flags [P.], seq 41:82, ack 343, win 502, options [nop,nop,TS val 1040634856 ecr 678500272], length 41
+06:02:08.968065 IP 10.42.0.14.52928 > 10.42.1.29.5432: Flags [P.], seq 617750272:617750278, ack 754926471, win 502, options [nop,nop,TS val 1040634856 ecr 678493795], length 6
+5 packets captured
+9 packets received by filter
+0 packets dropped by kernel
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-02-inject.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-02-inject.txt
new file mode 100644
index 0000000..dda654f
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-02-inject.txt
@@ -0,0 +1,14 @@
+PG=10.42.1.29 K1=10.42.0.14
+=== 주입 전 기준 — 로그인 한 번의 시간 ===
+200 0.623459s
+200 0.067946s
+200 0.064262s
+=== a6 성공한 주입 — flannel.1 에 세 줄 ===
+15:03:55 주입
+=== 넣은 직후의 카운터 ===
+qdisc prio 1: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
+ Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
+ backlog 0b 0p requeues 0
+qdisc netem 30: parent 1:3 limit 1000 delay 200ms
+ Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
+ backlog 0b 0p requeues 0
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-03-effect.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-03-effect.txt
new file mode 100644
index 0000000..869daea
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-03-effect.txt
@@ -0,0 +1,15 @@
+=== 주입 뒤 — 같은 로그인 (keycloak-1 은 kc-lab-1 에 있고 DB 는 kc-lab-2 다) ===
+200 1.905504s
+200 1.903161s
+200 1.860396s
+200 1.867929s
+200 1.872740s
+=== 카운터가 올라갔나 ===
+qdisc netem 30: parent 1:3 limit 1000 delay 200ms
+ Sent 8791 bytes 83 pkt (dropped 0, overlimits 0 requeues 0) 
+ backlog 0b 0p requeues 0
+=== 필터 목록 (문서가 미검증으로 둔 줄) ===
+filter parent 1: protocol ip pref 3 u32 chain 0 
+filter parent 1: protocol ip pref 3 u32 chain 0 fh 800: ht divisor 1 
+filter parent 1: protocol ip pref 3 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 *flowid 1:3 not_in_hw 
+  match 0a2a011d/ffffffff at 12
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-04-revert.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-04-revert.txt
new file mode 100644
index 0000000..8c80918
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a6-04-revert.txt
@@ -0,0 +1,6 @@
+=== a6 되돌리기 ===
+qdisc noqueue 0: root refcnt 2 
+=== 되돌린 뒤 같은 로그인 ===
+200 0.067775s
+200 0.043802s
+200 0.045763s
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-01-switch-volatile.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-01-switch-volatile.txt
new file mode 100644
index 0000000..b14ef88
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-01-switch-volatile.txt
@@ -0,0 +1,19 @@
+=== a7 7. 세션 테이블을 비운다 ===
+DELETE 11
+=== 8. args 를 volatile 로 (patch 형태) ===
+statefulset.apps/keycloak patched
+15:05:19 전환
+Waiting for partitioned roll out to finish: 0 out of 2 new pods have been updated...
+Waiting for 1 pods to be ready...
+Waiting for 1 pods to be ready...
+Waiting for 1 pods to be ready...
+Waiting for partitioned roll out to finish: 1 out of 2 new pods have been updated...
+Waiting for 1 pods to be ready...
+Waiting for 1 pods to be ready...
+Waiting for 1 pods to be ready...
+partitioned roll out complete: 2 new pods have been updated...
+=== 주입 검증 — args 가 바뀌었나 ===
+["start","--features-disabled=persistent-user-sessions"]
+keycloak-0 1/1 Running 10.42.1.34 kc-lab-2
+keycloak-1 1/1 Running 10.42.0.15 kc-lab-1
+postgres-7b474b88c8-5zp6v 1/1 Running 10.42.1.29 kc-lab-2
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-02-cross-node-volatile.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-02-cross-node-volatile.txt
new file mode 100644
index 0000000..5fe6efc
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-02-cross-node-volatile.txt
@@ -0,0 +1,15 @@
+=== a7 관찰 — A-0 의 시험 0 을 글자 그대로 다시 ===
+# [1] keycloak-0 에서 로그인
+sid=_szXQIOVaE8_v2-b-frn9npt
+# [2] keycloak-1 에서 refresh (교차 노드)
+200
+=== DB 세션 행은 몇 건인가 ===
+ user_session_id 
+-----------------
+(0 rows)
+
+=== 노드별 캐시 엔트리 ===
+keycloak-0   clientSessions   0
+keycloak-0   sessions         0
+keycloak-1   clientSessions   0
+keycloak-1   sessions         0
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-03-block-7800.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-03-block-7800.txt
new file mode 100644
index 0000000..c74bf35
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-03-block-7800.txt
@@ -0,0 +1,14 @@
+=== 스크레이프 뒤 캐시 — 세션이 어디 사나 ===
+keycloak-0   clientSessions   1
+keycloak-0   sessions         1
+keycloak-1   clientSessions   0
+keycloak-1   sessions         0
+=== 7800 을 막는다 (A-1 의 NetworkPolicy 를 그대로) ===
+networkpolicy.networking.k8s.io/a1-block-jgroups-transport created
+15:06:59 적용
+pod "keycloak-0" deleted from keycloak-lab namespace
+partitioned roll out complete: 2 new pods have been updated...
+=== 멤버 수 ===
+"pod":"keycloak-1"} "1"]} "pod":"keycloak-0"} "1"]}]}} 
+
+[exited with code 0]
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-04-partition-breaks-sharing.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-04-partition-breaks-sharing.txt
new file mode 100644
index 0000000..0d532bf
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-04-partition-breaks-sharing.txt
@@ -0,0 +1,16 @@
+분단 + volatile 에서 K0=10.42.1.36 K1=10.42.0.15
+=== A-1 의 네 단계를 그대로 (volatile 판) ===
+# [1] keycloak-0 에서 로그인
+sid=9tpo41BVY32uJdYOyv8maA5j# [2] keycloak-1 에서 refresh
+400
+# [3] keycloak-1 에서 로그아웃
+400
+# [4] keycloak-0 에서 재갱신 시도
+{"error":"invalid_grant","error_description":"Invalid refresh token"}
+400
+=== DB 행 ===
+ count 
+-------
+     0
+(1 row)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-05-revert.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-05-revert.txt
new file mode 100644
index 0000000..2031900
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7-05-revert.txt
@@ -0,0 +1,7 @@
+=== a7 복구 ① NetworkPolicy 를 지운다 ===
+networkpolicy.networking.k8s.io "a1-block-jgroups-transport" deleted from keycloak-lab namespace
+=== ② args 를 원래대로 ===
+statefulset.apps/keycloak patched
+15:09:07 원복
+partitioned roll out complete: 2 new pods have been updated...
+["start"]
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-01-setup.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-01-setup.txt
new file mode 100644
index 0000000..b507500
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-01-setup.txt
@@ -0,0 +1,16 @@
+=== a7a 6. 문장 로깅을 켠다 ===
+(1 row)
+
+ log_statement 
+---------------
+ all
+(1 row)
+
+=== 7. volatile 로 바꾼다 ===
+statefulset.apps/keycloak patched
+partitioned roll out complete: 2 new pods have been updated...
+["start","--features-disabled=persistent-user-sessions"]
+=== 4. 탐침 파드를 StatefulSet 밖에 ===
+pod/a7a-probe created
+pod/a7a-probe condition met
+K0=10.42.1.39 K1=10.42.0.17
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-02-repro-A.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-02-repro-A.txt
new file mode 100644
index 0000000..abda876
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-02-repro-A.txt
@@ -0,0 +1,10 @@
+=== a7a 재현 A — 완전 냉시동 ===
+statefulset.apps/keycloak restarted
+partitioned roll out complete: 2 new pods have been updated...
+deployment.apps/postgres scaled
+pod/postgres-7b474b88c8-5zp6v condition met
+pod/a7a-probe condition met
+=== ③ 로그인을 본문과 함께 (기대: 400 unauthorized_client) ===
+{"error":"unauthorized_client","error_description":"Unexpected error when authenticating client"}
+400
+=== ④ 실패한 SQL 을 Keycloak 로그에서 ===
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-03-repro-A-sql.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-03-repro-A-sql.txt
new file mode 100644
index 0000000..6f21bdb
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-03-repro-A-sql.txt
@@ -0,0 +1,10 @@
+=== ④ 문서가 적은 형태 그대로 ===
+(위가 비면 아래를 본다)
+=== 더 넓게 ===
+2026-09-17 06:11:31,802 WARN  [org.keycloak.jgroups.protocol.KEYCLOAK_JDBC_PING2] (blocking-thread--p3-t2) Failed to fetch the cluster members from the database.: org.postgresql.util.PSQLException: FATAL: terminating connection due to administrator command
+2026-09-17 06:11:59,291 ERROR [org.keycloak.services] (executor-thread-3) KC-SERVICES0015: Unexpected error when authenticating client: org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection [Connection to postgres:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.] [n/a]
+=== 실제로 찍힌 오류 줄 ===
+2026-09-17 06:11:49,114 ERROR [org.keycloak.jgroups.protocol.KEYCLOAK_JDBC_PING2] (Timer runner-2,keycloak-0-44929(v=16.0.12)) keycloak-0-44929(v=16.0.12): failed reading from the DB: org.postgresql.util.PSQLException: Connection to postgres:5432 refused. Chec
+2026-09-17 06:11:55,190 ERROR [org.keycloak.jgroups.protocol.KEYCLOAK_JDBC_PING2] (Timer runner-2,keycloak-0-44929(v=16.0.12)) keycloak-0-44929(v=16.0.12): failed writing to DB: org.postgresql.util.PSQLException: Connection to postgres:5432 refused. Check that
+2026-09-17 06:11:59,291 ERROR [org.keycloak.services] (executor-thread-3) KC-SERVICES0015: Unexpected error when authenticating client: org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection [Connection to postgres:5432 refused. Che
+2026-09-17 06:11:59,295 WARN  [org.keycloak.events] (executor-thread-3) type="LOGIN_ERROR", realmId="f9bed085-ff57-4ab0-92ab-af83adeb320e", realmName="master", clientId="admin-cli", userId="null", ipAddress="10.42.1.42", error="invalid_client_credentials", gra
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-04-repro-B.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-04-repro-B.txt
new file mode 100644
index 0000000..18614d7
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-04-repro-B.txt
@@ -0,0 +1,17 @@
+=== 넓힌 grep 이 둘 다 잡나 ===
+KC-SERVICES0015: Unexpected error when authenticating client: org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection [Connection to postgres:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.]
+
+=== a7a 재현 B — 로그인 한 번으로 캐시를 덥힌 뒤 DB 를 내린다 ===
+deployment.apps/postgres scaled
+deployment "postgres" successfully rolled out
+statefulset.apps/keycloak restarted
+partitioned roll out complete: 2 new pods have been updated...
+pod/a7a-probe condition met
+--- 로그인 한 번 (DB 살아 있을 때) ---
+rt=612자
+--- DB 를 내린다 ---
+deployment.apps/postgres scaled
+pod/postgres-7b474b88c8-dg4vb condition met
+--- refresh (기대: 500) ---
+{"error":"unknown_error","error_description":"For more on this error consult the server log."}
+500
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-05-repro-C-and-revert.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-05-repro-C-and-revert.txt
new file mode 100644
index 0000000..2bc40aa
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a7a-05-repro-C-and-revert.txt
@@ -0,0 +1,21 @@
+=== a7a 재현 C — DB 를 살리고 같은 refresh 를 다시 ===
+deployment.apps/postgres scaled
+deployment "postgres" successfully rolled out
+200
+=== a7a 되돌리기 ===
+(1 row)
+
+ log_statement 
+---------------
+ none
+(1 row)
+
+statefulset.apps/keycloak patched
+partitioned roll out complete: 2 new pods have been updated...
+pod "a7a-probe" deleted from keycloak-lab namespace
+["start"]
+keycloak-0 1/1 Running
+keycloak-1 1/1 Running
+postgres-7b474b88c8-48lrr 1/1 Running
+
+[exited with code 0]
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a8-01-baseline.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a8-01-baseline.txt
new file mode 100644
index 0000000..7513dbb
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a8-01-baseline.txt
@@ -0,0 +1,21 @@
+=== a8 1~3 기준선 ===
+keycloak-0 1/1 Running 103s 10.42.1.47
+keycloak-1 1/1 Running 2m17s 10.42.0.20
+postgres-7b474b88c8-48lrr 1/1 Running 2m57s 10.42.1.46
+["start"] replicas=2
+ count 
+-------
+     0
+(1 row)
+
+=== 4~6 탐침과 토큰 ===
+pod/a8-probe condition met
+rt=613자  sid=z_FpRg03WlwmkgqrpKZgzfNP
+# 대조군 — 재시작 전 refresh
+200
+=== 7. 그 세션이 DB 에 있나 ===
+     user_session_id      | created_on | last_session_refresh 
+--------------------------+------------+----------------------
+ z_FpRg03WlwmkgqrpKZgzfNP | 1789625835 |           1789625835
+(1 row)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a8-02-restart.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a8-02-restart.txt
new file mode 100644
index 0000000..d0e7ad5
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a8-02-restart.txt
@@ -0,0 +1,28 @@
+=== 8. 캐시와 클러스터 크기 ===
+keycloak-0   clientSessions   0
+keycloak-0   sessions         0
+keycloak-1   clientSessions   0
+keycloak-1   sessions         0
+=== 9. 롤링 재시작 ===
+15:18:57 재시작
+statefulset.apps/keycloak restarted
+partitioned roll out complete: 2 new pods have been updated...
+=== 10. 파드가 진짜 바뀌었나 (AGE) ===
+keycloak-0 1/1 Running 31s 10.42.1.49
+keycloak-1 1/1 Running 63s 10.42.0.21
+=== 12. 본 시험 — 재시작 전 토큰이 아직 통하는가 ===
+
+000
+command terminated with exit code 3
+=== 13. DB 행의 두 시각 ===
+     user_session_id      | created_on | last_session_refresh 
+--------------------------+------------+----------------------
+ z_FpRg03WlwmkgqrpKZgzfNP | 1789625835 |           1789625835
+(1 row)
+
+=== 14. 캐시와 클러스터 ===
+keycloak-0   clientSessions   0
+keycloak-0   sessions         0
+keycloak-1   clientSessions   0
+keycloak-1   sessions         0
+"pod":"keycloak-1"} "2"]} "pod":"keycloak-0"} "2"]}]}} 
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a8-03-main-test.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a8-03-main-test.txt
new file mode 100644
index 0000000..cdc7e48
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/a8-03-main-test.txt
@@ -0,0 +1,10 @@
+새 K0=10.42.1.49 (탐침 안의 낡은 값=10.42.1.47)
+=== 12. 본 시험 — 새 IP 를 명령줄로 넘긴다 ===
+{"access_token":"<REDACTED 758자>","expires_in":60,"refresh_expires_in":1800,"refresh_token":"<REDACTED 612자>","token_type":"Bearer","not-before-policy":0,"session_state":"z_FpRg03WlwmkgqrpKZgzfNP","scope":"profile email"}
+200
+=== 13. DB 행의 두 시각 (갱신됐나) ===
+     user_session_id      | created_on | last_session_refresh 
+--------------------------+------------+----------------------
+ z_FpRg03WlwmkgqrpKZgzfNP | 1789625835 |           1789625952
+(1 row)
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-01-image-import.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-01-image-import.txt
new file mode 100644
index 0000000..57b2a94
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-01-image-import.txt
@@ -0,0 +1,20 @@
+=== 이미지 두 개를 두 노드에 밀어 넣는다 (문서의 형태 그대로) ===
+--- keycloak-pattern-bff:lab → kc-lab-1 ---
+application/vnd.oci.image.index.v1+json sha256:9fb29178e7f8556a8d3b38cf6e23b55cfbc27396530451bb86dcea99206b7bbb
+Importing	elapsed: 7.8 s	total:   0.0 B	(0.0 B/s)	
+--- keycloak-pattern-bff:lab → kc-lab-2 ---
+application/vnd.oci.image.index.v1+json sha256:9fb29178e7f8556a8d3b38cf6e23b55cfbc27396530451bb86dcea99206b7bbb
+Importing	elapsed: 6.9 s	total:   0.0 B	(0.0 B/s)	
+--- keycloak-pattern-api:lab → kc-lab-1 ---
+application/vnd.oci.image.index.v1+json sha256:ff6ce2988e2fd19c44f38591c58e7cecc79c443368a502e328f356bee23d6ab3
+Importing	elapsed: 5.6 s	total:   0.0 B	(0.0 B/s)	
+--- keycloak-pattern-api:lab → kc-lab-2 ---
+application/vnd.oci.image.index.v1+json sha256:ff6ce2988e2fd19c44f38591c58e7cecc79c443368a502e328f356bee23d6ab3
+Importing	elapsed: 5.8 s	total:   0.0 B	(0.0 B/s)	
+=== 두 노드의 이미지 목록 ===
+--- kc-lab-1 ---
+docker.io/library/keycloak-pattern-api:lab
+docker.io/library/keycloak-pattern-bff:lab
+--- kc-lab-2 ---
+docker.io/library/keycloak-pattern-api:lab
+docker.io/library/keycloak-pattern-bff:lab
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-02-realm-and-user.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-02-realm-and-user.txt
new file mode 100644
index 0000000..fba0ead
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-02-realm-and-user.txt
@@ -0,0 +1,18 @@
+=== b0 3-① kcadm 로그인 ===
+Logging into http://localhost:8080 as user admin of realm master
+(exit=0)
+=== ③ realm 과 클라이언트 ===
+Created new realm with id 'keycloak-patterns'
+Created new client with id '7ae3362a-2bed-4902-b6af-d7307ea4ad0b'
+=== ④ realm 세 칸 ===
+{
+  "realm" : "keycloak-patterns",
+  "accessTokenLifespan" : 60,
+  "enabled" : true
+}
+=== 4. 사용자 ===
+Created new user with id '07d3be2a-9f22-4779-a211-e530c8b7ff3b'
+[ {
+  "username" : "labuser",
+  "enabled" : true
+} ]
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-03-deploy-bff.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-03-deploy-bff.txt
new file mode 100644
index 0000000..762fd1c
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-03-deploy-bff.txt
@@ -0,0 +1,29 @@
+=== bff-redis.yaml 이 무엇을 만드나 ===
+kind: Secret
+  name: bff-secrets
+kind: PersistentVolumeClaim
+  name: redis-data
+kind: Deployment
+  name: redis
+kind: Service
+  name: redis
+kind: Deployment
+  name: bff
+kind: Service
+  name: bff
+kind: Ingress
+  name: bff
+=== 적용 ===
+secret/bff-secrets created
+persistentvolumeclaim/redis-data created
+deployment.apps/redis created
+service/redis created
+deployment.apps/bff created
+service/bff created
+ingress.networking.k8s.io/bff created
+bff-5d97897676-nmlqs 0/1 Running kc-lab-1
+bff-5d97897676-zvfhp 0/1 Running kc-lab-2
+keycloak-0 1/1 Running kc-lab-2
+keycloak-1 1/1 Running kc-lab-1
+postgres-7b474b88c8-48lrr 1/1 Running kc-lab-2
+redis-f94bc6dbf-pjllr 0/1 ContainerCreating kc-lab-2
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-04-bff-status.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-04-bff-status.txt
new file mode 100644
index 0000000..0e2ebf8
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b0-04-bff-status.txt
@@ -0,0 +1,26 @@
+=== 파드 상태 ===
+bff-5d97897676-nmlqs 1/1 Running kc-lab-1
+bff-5d97897676-zvfhp 1/1 Running kc-lab-2
+keycloak-0 1/1 Running kc-lab-2
+keycloak-1 1/1 Running kc-lab-1
+postgres-7b474b88c8-48lrr 1/1 Running kc-lab-2
+redis-f94bc6dbf-pjllr 1/1 Running kc-lab-2
+=== bff 가 안 뜨면 왜인지 ===
+2026-09-17T06:24:23.717Z  INFO 1 --- [keycloak-bff] [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
+2026-09-17T06:24:23.718Z  INFO 1 --- [keycloak-bff] [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 2221 ms
+2026-09-17T06:24:23.943Z  INFO 1 --- [keycloak-bff] [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
+2026-09-17T06:24:24.223Z  INFO 1 --- [keycloak-bff] [           main] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 - Added connection org.postgresql.jdbc.PgConnection@be6d228
+2026-09-17T06:24:24.225Z  INFO 1 --- [keycloak-bff] [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed.
+2026-09-17T06:24:24.808Z  INFO 1 --- [keycloak-bff] [           main] o.s.b.a.w.s.WelcomePageHandlerMapping    : Adding welcome page: class path resource [static/index.html]
+2026-09-17T06:24:25.272Z  INFO 1 --- [keycloak-bff] [           main] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 5 endpoints beneath base path '/actuator'
+2026-09-17T06:24:25.909Z  INFO 1 --- [keycloak-bff] [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port 8083 (http) with context path '/'
+2026-09-17T06:24:25.926Z  INFO 1 --- [keycloak-bff] [           main] c.e.keycloakpattern.bff.BffApplication   : Started BffApplication in 5.298 seconds (process running for 5.885)
+2026-09-17T06:24:41.136Z  INFO 1 --- [keycloak-bff] [nio-8083-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring DispatcherServlet 'dispatcherServlet'
+2026-09-17T06:24:41.137Z  INFO 1 --- [keycloak-bff] [nio-8083-exec-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
+2026-09-17T06:24:41.139Z  INFO 1 --- [keycloak-bff] [nio-8083-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 1 ms
+=== 이미지 경로가 맞았나 ===
+keycloak-pattern-bff:lab Never
+Events:
+  Type    Reason     Age    From               Message
+  ----    ------     ----   ----               -------
+  Normal  Scheduled  2m39s  default-scheduler  Successfully assigned keycloak-lab/bff-5d97897676-nmlqs to kc-lab-1
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b1-01-beans.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b1-01-beans.txt
new file mode 100644
index 0000000..bbef3af
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b1-01-beans.txt
@@ -0,0 +1,23 @@
+=== BFF 파드: bff-5d97897676-nmlqs ===
+=== /actuator/beans 를 파드 안에서 받는다 ===
+155395 /tmp/beans.json
+=== ① 빈의 개수 (문서가 미검증으로 둔 줄) ===
+437
+=== ② 저장소 계열 빈 (문서가 미검증으로 둔 줄) ===
+"org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2ClientConfigurations$OAuth2AuthorizedClientServiceConfiguration": -> org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2ClientConfigurations$OAuth2AuthorizedClientServiceConfiguration"
+"authorizedClientManagerRegistrar": -> org.springframework.security.config.annotation.web.configuration.OAuth2ClientConfiguration$OAuth2AuthorizedClientManagerRegistrar"
+"org.springframework.security.config.annotation.web.configuration.OAuth2ClientConfiguration$OAuth2AuthorizedClientManagerConfiguration": -> org.springframework.security.config.annotation.web.configuration.OAuth2ClientConfiguration$OAuth2AuthorizedClientManagerConfiguration"
+"authorizedClientManager": -> org.springframework.security.oauth2.client.AuthorizedClientServiceOAuth2AuthorizedClientManager"
+"authorizedClientService": -> org.springframework.security.oauth2.client.JdbcOAuth2AuthorizedClientService"
+"authorizedClientRepository": -> org.springframework.security.oauth2.client.web.AuthenticatedPrincipalOAuth2AuthorizedClientRepository"
+=== 세션 저장소 쪽도 ===
+"reactiveRedisTemplate": -> org.springframework.data.redis.core.ReactiveRedisTemplate"
+"redisConnectionDetails": -> org.springframework.boot.autoconfigure.data.redis.PropertiesRedisConnectionDetails"
+"org.springframework.boot.autoconfigure.session.SessionAutoConfiguration$ServletSessionConfiguration$ServletSessionRepositoryConfiguration": -> org.springframework.boot.autoconfigure.session.SessionAutoConfiguration$ServletSessionConfiguration$ServletSessionRepositoryConfiguration"
+"redisCustomConversions": -> org.springframework.data.redis.core.convert.RedisCustomConversions"
+"org.springframework.boot.autoconfigure.session.RedisSessionConfiguration": -> org.springframework.boot.autoconfigure.session.RedisSessionConfiguration"
+=== 이 BFF 의 저장소 설정 ===
+SPRING_SESSION_STORE_TYPE=redis
+BFF_DB_URL=jdbc:postgresql://postgres.keycloak-lab.svc:5432/keycloak
+BFF_DB_USER=keycloak
+BFF_DB_PASSWORD=
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b2-01-jdbc-table.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b2-01-jdbc-table.txt
new file mode 100644
index 0000000..461bd55
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b2-01-jdbc-table.txt
@@ -0,0 +1,15 @@
+=== b2 — JDBC 토큰 저장소의 표가 있나 ===
+                                Table "public.oauth2_authorized_client"
+         Column          |            Type             | Collation | Nullable |         Default         
+-------------------------+-----------------------------+-----------+----------+-------------------------
+ client_registration_id  | character varying(100)      |           | not null | 
+ principal_name          | character varying(200)      |           | not null | 
+ access_token_type       | character varying(100)      |           | not null | 
+ access_token_value      | bytea                       |           | not null | 
+ access_token_issued_at  | timestamp without time zone |           | not null | 
+ access_token_expires_at | timestamp without time zone |           | not null | 
+ access_token_scopes     | character varying(1000)     |           |          | NULL::character varying
+ refresh_token_value     | bytea                       |           |          | 
+ refresh_token_issued_at | timestamp without time zone |           |          | 
+=== 행 수 ===
+0
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-01-setup.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-01-setup.txt
new file mode 100644
index 0000000..ed85030
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-01-setup.txt
@@ -0,0 +1,12 @@
+=== b3 2. kcadm 세션 ===
+Logging into http://localhost:8080 as user admin of realm master
+=== 3. realm 의 세 값 ===
+{
+  "revokeRefreshToken" : false,
+  "refreshTokenMaxReuse" : 0,
+  "accessTokenLifespan" : 60
+}
+=== 4-① 탐침 파드 ===
+pod/b3-probe condition met
+=== ② 길이만 ===
+KC=http://keycloak.keycloak-lab.svc:8080/realms/keycloak-patterns/protocol/openid-connect/token  CS길이=14
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-02-secret-and-token.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-02-secret-and-token.txt
new file mode 100644
index 0000000..dab9280
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-02-secret-and-token.txt
@@ -0,0 +1,6 @@
+=== 문서가 없다고 한 그 대조 — 두 값이 같은가 (길이와 해시만) ===
+매니페스트 쪽 길이=14  Keycloak 쪽 길이=14
+두 값이 같다
+=== b3 5. 토큰을 하나 받는다 ===
+rt=0자
+{"error":"unauthorized_client","error_description":"Client not allowed for direct access g
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-03-direct-grant-missing.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-03-direct-grant-missing.txt
new file mode 100644
index 0000000..748d991
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-03-direct-grant-missing.txt
@@ -0,0 +1,15 @@
+=== B-0 이 만든 클라이언트의 그랜트 설정 ===
+{
+  "clientId" : "bff-confidential",
+  "standardFlowEnabled" : true,
+  "directAccessGrantsEnabled" : false,
+  "publicClient" : false
+}
+=== 켜 본다 ===
+{
+  "clientId" : "bff-confidential",
+  "directAccessGrantsEnabled" : true
+}
+=== 켠 뒤 같은 토큰 요청 ===
+rt=0자
+{"error":"invalid_grant","error_description":"Account is not
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-04-account-not-fully-set-up.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-04-account-not-fully-set-up.txt
new file mode 100644
index 0000000..0ca7057
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-04-account-not-fully-set-up.txt
@@ -0,0 +1,19 @@
+=== 전체 오류 문구 ===
+{"error":"invalid_grant","error_description":"Account is not fully set up"}
+=== B-0 이 만든 사용자의 상태 ===
+{
+  "username" : "labuser",
+  "emailVerified" : false,
+  "enabled" : true,
+  "requiredActions" : [ ]
+}
+=== 처방: 계정을 완전하게 만든다 ===
+{
+  "username" : "labuser",
+  "emailVerified" : true,
+  "enabled" : true,
+  "requiredActions" : [ ]
+}
+=== 다시 토큰 요청 ===
+rt=735자
+{"access_token":"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2l
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-05-race.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-05-race.txt
new file mode 100644
index 0000000..7645915
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-05-race.txt
@@ -0,0 +1,16 @@
+=== b3 주입 — 회전을 켠다 ===
+15:29:22 회전 켬
+{
+  "revokeRefreshToken" : true,
+  "refreshTokenMaxReuse" : 0
+}=== 관찰 — 같은 토큰으로 동시에 다섯 번 ===
+
+refresh=810자  SID=7yVb2FfztKznk461jR10VpIT
+요청 1: HTTP 400  {"error":"invalid_grant","error_description":"Session doesn't have required client"}
+요청 2: HTTP 400  {"error":"invalid_grant","error_description":"Session doesn't have required client"}
+요청 3: HTTP 400  {"error":"invalid_grant","error_description":"Maximum allowed refresh token reuse exceeded
+요청 4: HTTP 200  {"access_token":"<REDACTED 73자 조각>
+요청 5: HTTP 400  {"error":"invalid_grant","error_description":"Session doesn't have required client"}
+이긴 요청의 새 refresh 길이: 810
+그 토큰을 다시 쓰면: 400
+error_description=Session doesn't have required client
\ No newline at end of file
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-06-revert.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-06-revert.txt
new file mode 100644
index 0000000..e0e8573
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b3-06-revert.txt
@@ -0,0 +1,6 @@
+=== b3 되돌리기 ===
+{
+  "revokeRefreshToken" : false,
+  "refreshTokenMaxReuse" : 0
+}
+pod "b3-probe" deleted from keycloak-lab namespace
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b4-01-forged-headers.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b4-01-forged-headers.txt
new file mode 100644
index 0000000..0e7288c
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b4-01-forged-headers.txt
@@ -0,0 +1,32 @@
+=== b4 1. app1 이 경로에 따라 어디로 가는가 ===
+NS              NAME       HOST                  PATH   SVC
+header-lab      echo       app1.hyeonworks.com   /api   echo
+keycloak-lab    bff        app1.hyeonworks.com   /      bff
+keycloak-lab    keycloak   auth.hyeonworks.com   /      keycloak
+observability   grafana    app2.hyeonworks.com   /      grafana
+=== 2. echo 응답을 통째로 (TLS 대신 Host 헤더) ===
+{
+  "headers" : {
+    "host" : [ "app1.hyeonworks.com" ],
+    "user-agent" : [ "curl/8.21.0" ],
+    "accept" : [ "*/*" ],
+    "x-forwarded-host" : [ "app1.hyeonworks.com" ],
+    "x-forwarded-port" : [ "80" ],
+    "x-forwarded-proto" : [ "http" ],
+    "x-forwarded-server" : [ "traefik-59b7647586-t8fc7" ],
+    "x-real-ip" : [ "10.42.0.1" ],
+    "accept-encoding" : [ "gzip" ]
+  },
+  "remoteAddr" : "10.42.0.1",
+  "localAddr" : "10.42.1.58",
+  "scheme" : "http",
+  "secure" : false,
+  "serverName" : "app1.hyeonworks.com",
+  "serverPort" : 80,
+  "requestUrl" : "http://app1.hyeonworks.com/api/echo"
+}
+=== 3. 대조군 — 아무것도 안 붙였을 때 ===
+(위가 비면 대조군에는 그 헤더가 없다)
+=== 주입 1. 동명 헤더 두 개 ===
+=== 주입 2. 값 안의 쉼표 ===
+=== 주입 4. 신원 자체를 위조 ===
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b4-02-forged-headers-retry.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b4-02-forged-headers-retry.txt
new file mode 100644
index 0000000..8199555
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b4-02-forged-headers-retry.txt
@@ -0,0 +1,11 @@
+=== 주입 1. 동명 헤더 두 개 (문서의 grep 형태) ===
+"x-auth-request-roles" : [ "admin", "editor" ]
+=== 주입 2. 값 안의 쉼표 ===
+"x-auth-request-roles" : [ "admin,editor,viewer" ]
+"x-auth-request-roles" : [ "role-with,comma" ]
+=== 주입 4. 신원 위조 ===
+"x-auth-request-email" : [ "attacker@evil.invalid" ]
+"x-auth-request-user" : [ "attacker" ]
+=== 문서가 적은 x-forwarded-proto grep 형태 ===
+(위가 비면 공백 때문이다)
+"x-forwarded-proto" : [ "http" ]
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b5-01-baseline.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b5-01-baseline.txt
new file mode 100644
index 0000000..cf19cbb
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b5-01-baseline.txt
@@ -0,0 +1,19 @@
+=== b5 1. 파드 배치 ===
+bff-5d97897676-nmlqs 1/1 Running kc-lab-1
+bff-5d97897676-zvfhp 1/1 Running kc-lab-2
+keycloak-0 1/1 Running kc-lab-2
+keycloak-1 1/1 Running kc-lab-1
+postgres-7b474b88c8-48lrr 1/1 Running kc-lab-2
+redis-f94bc6dbf-pjllr 1/1 Running kc-lab-2
+=== 2. Redis 안과 영속화 설정 ===
+PONG
+(위가 비면 키가 없다)
+save
+3600 1 300 100 60 10000
+appendonly
+yes
+=== 3. /data 가 볼륨인가 ===
+data=redis-data
+kube-api-access-nk4c6=
+data -> /data
+kube-api-access-nk4c6 -> /var/run/secrets/kubernetes.io/serviceaccount
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b5-02-redis-down.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b5-02-redis-down.txt
new file mode 100644
index 0000000..5d1bc4a
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b5-02-redis-down.txt
@@ -0,0 +1,23 @@
+=== b5 5-① health 그룹 셋 (정상 상태, TLS 대신 Host 헤더) ===
+/actuator/health -> {"status":"UP","groups":["liveness","readiness"],"components":{"db":{"status":"UP","details":{"database":"PostgreSQL","validationQuery":"isValid()"}},"diskSpace":{"status":"UP","details":{"total":20922114048,"free":15890649088,"threshold":10485760,"path":"/app/.","exists":true}},"livenessState":{"status":"UP"},"ping":{"status":"UP"},"readinessState":{"status":"UP"},"redis":{"status":"UP","details":{"version":"7.4.11"}},"ssl":{"status":"UP","details":{"validChains":[],"invalidChains":[]}}}}
+/actuator/health/readiness -> {"status":"UP"}
+/actuator/health/liveness -> {"status":"UP"}
+=== ② kubelet 이 보는 경로 ===
+/actuator/health/readiness
+=== 주입 1. Redis 를 0대로 ===
+15:52:37 정지
+deployment.apps/redis scaled
+pod/redis-f94bc6dbf-pjllr condition met
+=== 정지 뒤 health 그룹 셋 ===
+/actuator/health -> {"status":"DOWN","groups":["liveness","readiness"],"components":{"db":{"status":"UP","details":{"database":"PostgreSQL","validationQuery":"isValid()"}},"diskSpace":{"status":"UP","details":{"total":20922114048,"free":13710831616,"threshold":10485760,"path":"/app/.","exists":true}},"livenessState":{"status":"UP"},"ping":{"status":"UP"},"readinessState":{"status":"UP"},"redis":{"status":"DOWN","details":{"error":"org.springframework.data.redis.RedisConnectionFailureException: Unable to connect to Redis"}},"ssl":{"status":"UP","details":{"validChains":[],"invalidChains":[]}}}}
+/actuator/health/readiness -> {"status":"UP"}
+/actuator/health/liveness -> {"status":"UP"}
+=== 파드 상태 ===
+bff-5d97897676-nmlqs 1/1 Running kc-lab-1
+bff-5d97897676-zvfhp 1/1 Running kc-lab-2
+keycloak-0 1/1 Running kc-lab-2
+keycloak-1 1/1 Running kc-lab-1
+postgres-7b474b88c8-48lrr 1/1 Running kc-lab-2
+=== Service 엔드포인트 ===
+ADDR                        READY
+[10.42.1.51],[10.42.0.22]   true,true
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b5-03-revert.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b5-03-revert.txt
new file mode 100644
index 0000000..5d43ae9
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b5-03-revert.txt
@@ -0,0 +1,10 @@
+=== b5 되돌리기 ===
+deployment.apps/redis scaled
+deployment "redis" successfully rolled out
+/actuator/health -> "status":"UP"
+bff-5d97897676-nmlqs 1/1 Running
+bff-5d97897676-zvfhp 1/1 Running
+keycloak-0 1/1 Running
+keycloak-1 1/1 Running
+postgres-7b474b88c8-48lrr 1/1 Running
+redis-f94bc6dbf-s674z 1/1 Running
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-01-deploy-echo.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-01-deploy-echo.txt
new file mode 100644
index 0000000..074a4a1
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-01-deploy-echo.txt
@@ -0,0 +1,19 @@
+=== echo.yaml 이 무엇을 만드나 ===
+kind: Namespace
+  name: header-lab
+kind: Deployment
+  name: echo
+  namespace: header-lab
+kind: Service
+  name: echo
+  namespace: header-lab
+kind: Ingress
+  name: echo
+  namespace: header-lab
+=== 적용 ===
+namespace/header-lab created
+deployment.apps/echo created
+service/echo created
+ingress.networking.k8s.io/echo created
+echo-cd47dccc6-nq62j 1/1 Running kc-lab-2
+echo-cd47dccc6-q46lk 1/1 Running kc-lab-1
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-02-jwks-before.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-02-jwks-before.txt
new file mode 100644
index 0000000..3e3ca66
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-02-jwks-before.txt
@@ -0,0 +1,12 @@
+=== b6 2. 공급자 목록 ===
+=== 문서가 미검증으로 둔 「조용히 빈 결과」 형태 ===
+No server specified. Use --server, or 'kcadm.sh config credentials'.
+command terminated with exit code 1
+(위가 비면 문서 말이 맞다. exit=0)
+=== 3. JWKS 를 TLS 없이 (Host 헤더로) ===
+{"keys":[{"kid":"HKy0uQhg-vlQackK6-oj3hW6vKbDj-95Wlvdgl37cGg","kty":"RSA","alg":"RS256","use":"sig","x5c":["MIICsTCCAZkCBgGgrgllnjANBgkqhkiG9w0BAQsFADAcMRowGAYDVQQDDBFrZXljbG9hay1wYXR0ZXJuczAeFw0yNjA5MTcwNjIyMjZaFw0zNjA5MTcwNjI0MDZaMBwxGjAYBgNVBAMMEWtleWNsb2FrLXBhdHRlcm5zMIIBIjANBgkqhkiG9w0BAQEFAAOC
+=== 4. RS256 만 센다 ===
+1
+=== kid 목록 ===
+{"keys":[{"kid":"HKy0uQhg-vlQackK6-oj3hW6vKbDj-95Wlvdgl37cGg"
+{"kid":"5voCsAVhALEjGliTG9Z2bx6WSkHeAUFUXiYOYic-niI"
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-03-providers.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-03-providers.txt
new file mode 100644
index 0000000..b99718b
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-03-providers.txt
@@ -0,0 +1,12 @@
+=== kcadm 세션이 왜 사라졌나 ===
+ls: cannot access '/opt/keycloak/.keycloak/kcadm.config': No such file or directory
+=== 다시 로그인 ===
+Logging into http://localhost:8080 as user admin of realm master
+=== b6 2. 공급자 목록 ===
+,{"id":"807e653f-deaf-41cd-bbaa-5b19eaf74a2a","name":"hmac-generated-hs512","providerId":"hmac-generated"
+,{"id":"27216d59-950c-4c8c-b0a8-e1d8108e0c0f","name":"aes-generated","providerId":"aes-generated"
+,{"id":"a09ec151-6c8c-4e55-84c0-f02781221b83","name":"rsa-generated","providerId":"rsa-generated"
+=== 문서가 미검증으로 둔 「조용히 빈 결과」 형태 ===
+[ {
+  "id" : "d47b58ee-7c34-4be0-a3f3-30f49b4577c1",
+  "name" : "rsa-enc-generated",
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-04-old-token.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-04-old-token.txt
new file mode 100644
index 0000000..1de1327
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-04-old-token.txt
@@ -0,0 +1,3 @@
+at=1397자
+kid=echo 에 그 토큰으로: 401
+토큰 없이:           200
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-05-echo-401.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-05-echo-401.txt
new file mode 100644
index 0000000..35cdbdb
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-05-echo-401.txt
@@ -0,0 +1,9 @@
+=== echo 가 어느 발행자를 보나 ===
+{"name":"SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI"
+{"name":"SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URI"
+
+=== echo 로그에서 401 의 까닭 ===
+=== kid 를 따로 뽑아 본다 ===
+헤더 길이=111
+{"alg":"RS256","typ" : "JWT","kid" : "HKy0uQhg-vlQackK6-oj3hW6vKbDj-95Wlvdgl37cGgbase64: truncated input
+
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-06-kid-and-issuer.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-06-kid-and-issuer.txt
new file mode 100644
index 0000000..c643f80
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b6-06-kid-and-issuer.txt
@@ -0,0 +1,10 @@
+=== echo 의 두 URI ===
+SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI=https://auth.hyeonworks.com/realms/keycloak-patterns
+SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URI=https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/certs
+=== echo 가 그 주소에 닿나 ===
+issuer=000
+command terminated with exit code 7
+=== JWT 헤더는 공백이 들어간 형태다 ===
+헤더: {"alg":"RS256","typ" : "JWT","kid" : "HKy0uQhg-vlQackK6-oj3hW6vKbDj-95Wlvdgl37cGg"}
+문서 형태의 sed: []
+공백을 허용한 sed: [HKy0uQhg-vlQackK6-oj3hW6vKbDj-95Wlvdgl37cGg]
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b7a-01-oauth2-proxy.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b7a-01-oauth2-proxy.txt
new file mode 100644
index 0000000..6022eb6
Binary files /dev/null and b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b7a-01-oauth2-proxy.txt differ
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b7a-02-oauth2-proxy-blocked.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b7a-02-oauth2-proxy-blocked.txt
new file mode 100644
index 0000000..99d4240
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/b7a-02-oauth2-proxy-blocked.txt
@@ -0,0 +1,14 @@
+=== oauth2-proxy 파드 상태 ===
+oauth2-proxy-6c56c4c94f-2xthz 0/1 CrashLoopBackOff 4
+oauth2-proxy-6c56c4c94f-gkx8g 0/1 CrashLoopBackOff 5
+=== 그 Secret 이 있나 ===
+NAME                   TYPE     DATA   AGE
+oauth2-proxy-secrets   Opaque   3      3m11s
+=== 왜 안 뜨나 ===
+[2026/09/17 06:45:22] [provider.go:55] Performing OIDC Discovery...
+[2026/09/17 06:45:22] [main.go:59] ERROR: Failed to initialise OAuth2 Proxy: error initialising provider: could not create provider data: error building OIDC ProviderVerifier: could not get verifier builder: error while discovery OIDC configuration: failed to discover OIDC configuration: error performing request: Get "https://auth.hyeonworks.com/realms/keycloak-patterns/.well-known/openid-configuration": dial tcp 100.83.212.4:443: connect: connection refused
+Events:
+  Type     Reason     Age                    From               Message
+  ----     ------     ----                   ----               -------
+  Normal   Scheduled  4m44s                  default-scheduler  Successfully assigned keycloak-lab/oauth2-proxy-6c56c4c94f-2xthz to kc-lab-2
+  Normal   Pulling    4m44s                  kubelet            spec.containers{oauth2-proxy}: Pulling image "quay.io/oauth2-proxy/oauth2-proxy:v7.7.1"
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/c1-01-clear-sessions.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/c1-01-clear-sessions.txt
new file mode 100644
index 0000000..1fdd83e
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/c1-01-clear-sessions.txt
@@ -0,0 +1,31 @@
+=== c1 1. 앱 둘과 Ingress ===
+bff-5d97897676-nmlqs 1/1 Running
+bff-5d97897676-zvfhp 1/1 Running
+keycloak-0 1/1 Running
+keycloak-1 1/1 Running
+postgres-7b474b88c8-48lrr 1/1 Running
+redis-f94bc6dbf-s674z 1/1 Running
+header-lab echo app1.hyeonworks.com
+keycloak-lab bff app1.hyeonworks.com
+keycloak-lab keycloak auth.hyeonworks.com
+keycloak-lab oauth2-proxy app2.hyeonworks.com
+observability grafana app2.hyeonworks.com
+=== 2. kcadm 로그인 ===
+Logging into http://localhost:8080 as user admin of realm master
+=== 3-① realm 전체 로그아웃 ===
+=== 3-② 남은 세션 (문서가 미검증으로 둔 줄) ===
+6
+=== 4-① 자식 테이블부터 지운다 ===
+DELETE 1633
+DELETE 6
+=== 4-② 앱 세션도 비운다 ===
+OK
+=== 4-③ 롤아웃 ===
+statefulset.apps/keycloak restarted
+partitioned roll out complete: 2 new pods have been updated...
+=== 4-④ 두 저장소를 다시 센다 ===
+0
+(위가 비면 Redis 도 비었다)
+=== 문서가 적은 대로 kcadm 세션이 사라졌나 ===
+No server specified. Use --server, or 'kcadm.sh config credentials'.
+command terminated with exit code 1
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/c2-01-backchannel-probe.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/c2-01-backchannel-probe.txt
new file mode 100644
index 0000000..324f06c
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/c2-01-backchannel-probe.txt
@@ -0,0 +1,17 @@
+=== c2 ① 응답을 통째로 (TLS 대신 Host 헤더) ===
+HTTP/1.1 302 Found
+Server: nginx/1.22.1
+Date: Thu, 17 Sep 2026 06:45:53 GMT
+Content-Length: 0
+Connection: keep-alive
+Cache-Control: no-cache, no-store, max-age=0, must-revalidate
+Expires: 0
+Location: http://app1.hyeonworks.com/oauth2/authorization/keycloak
+Pragma: no-cache
+Set-Cookie: XSRF-TOKEN=b750fc30-e57f-4895-a465-98cb1a103ec7; Path=/
+X-Content-Type-Options: nosniff
+X-Frame-Options: DENY
+=== ② 후보 셋의 상태 코드 ===
+/logout/connect/back-channel/keycloak 302
+/backchannel-logout 302
+/oauth2/sign_out 302
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d1-01-backup.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d1-01-backup.txt
new file mode 100644
index 0000000..6ea4603
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d1-01-backup.txt
@@ -0,0 +1,12 @@
+=== d1 1~2 기준선 ===
+postgres-7b474b88c8-48lrr 1/1 Running kc-lab-2
+101
+6
+=== 5. 덤프 ===
+15:30:50 백업 시작
+15:30:50 백업 완료
+=== 6-① 크기와 줄 수 ===
+-rw-r--r-- 1 donghyeon donghyeon 976873 Sep 17 15:30 /tmp/keycloak-backup.sql
+8569 /tmp/keycloak-backup.sql
+=== 6-② 테이블 수 ===
+101
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d1-02-destroy-restore.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d1-02-destroy-restore.txt
new file mode 100644
index 0000000..d935097
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d1-02-destroy-restore.txt
@@ -0,0 +1,29 @@
+=== d1 주입 — 스키마를 통째로 지운다 ===
+15:31:02 파괴
+drop cascades to table cluster_event
+and 1 other object (see server log for list)
+DROP SCHEMA
+CREATE SCHEMA
+=== 주입 검증 ① 남은 테이블 (문서가 미검증으로 둔 형태) ===
+ count 
+-------
+     0
+(1 row)
+
+=== ② 테이블에 직접 물어본다 ===
+LINE 1: select count(*) from realm
+                             ^
+command terminated with exit code 1
+=== 밖에서는 (Host 헤더로) ===
+200
+=== 복구 ① ===
+15:31:02 복구 시작
+15:31:08 복구 완료
+=== ② 복구 로그의 오류 ===
+0
+ALTER TABLE
+ALTER TABLE
+ALTER TABLE
+=== 진짜 판정 — 주입 전과 견준다 ===
+101
+6
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-01-baseline.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-01-baseline.txt
new file mode 100644
index 0000000..8b75899
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-01-baseline.txt
@@ -0,0 +1,23 @@
+=== d2 2-① StatefulSet 의 태그 ===
+quay.io/keycloak/keycloak:26.7.0
+=== ② 파드가 실제로 돌리는 이미지 (고친 형태) ===
+bff-5d97897676-nmlqs        keycloak-pattern-bff:lab           true    0
+bff-5d97897676-zvfhp        keycloak-pattern-bff:lab           true    0
+keycloak-0                  quay.io/keycloak/keycloak:26.7.0   true    0
+keycloak-1                  quay.io/keycloak/keycloak:26.7.0   true    0
+=== 3. 마이그레이션 수 ===
+210
+=== 3-③ 마지막 다섯 줄 (문서가 미검증으로 둔 줄) ===
+                    id                     |  author  | orderexecuted |        dateexecuted        
+-------------------------------------------+----------+---------------+----------------------------
+ 26.7.0-cluster-event                      | keycloak |           210 | 2026-09-17 04:35:18.734357
+ 26.7.0-add-last-modified-timestamp-client | keycloak |           209 | 2026-09-17 04:35:18.703437
+ 26.7.0-add-timestamps-client              | keycloak |           208 | 2026-09-17 04:35:18.698699
+ 26.7.0-login-failure-index                | keycloak |           207 | 2026-09-17 04:35:18.69398
+ 26.7.0-login-failure-table                | keycloak |           206 | 2026-09-17 04:35:18.658204
+(5 rows)
+
+=== 4. 세션 ===
+6
+=== 6. 새 태그가 레지스트리에 있나 ===
+200
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-02-upgrade.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-02-upgrade.txt
new file mode 100644
index 0000000..8c18c14
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-02-upgrade.txt
@@ -0,0 +1,22 @@
+=== d2 주입 — 태그를 26.7.3 으로 ===
+15:32:15 정방향
+statefulset.apps/keycloak image updated
+partitioned roll out complete: 2 new pods have been updated...
+15:33:40 완료
+=== 판정 — 스키마가 움직였는가 ===
+210
+                    id                     | orderexecuted |        dateexecuted        
+-------------------------------------------+---------------+----------------------------
+ 26.7.0-cluster-event                      |           210 | 2026-09-17 04:35:18.734357
+ 26.7.0-add-last-modified-timestamp-client |           209 | 2026-09-17 04:35:18.703437
+ 26.7.0-add-timestamps-client              |           208 | 2026-09-17 04:35:18.698699
+(3 rows)
+
+=== 파드 이미지 ===
+NAME         IMAGE                              READY   RESTARTS
+keycloak-0   quay.io/keycloak/keycloak:26.7.3   true    0
+keycloak-1   quay.io/keycloak/keycloak:26.7.3   true    0
+=== 세션 ===
+6
+=== 밖에서 ===
+200
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-03-rollback-and-reverse.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-03-rollback-and-reverse.txt
new file mode 100644
index 0000000..52e144d
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-03-rollback-and-reverse.txt
@@ -0,0 +1,27 @@
+=== d2 롤백 — 26.7.0 으로 되돌린다 ===
+15:33:48 롤백
+statefulset.apps/keycloak image updated
+partitioned roll out complete: 2 new pods have been updated...
+15:34:55 완료
+NAME         IMAGE                              READY   RESTARTS
+keycloak-0   quay.io/keycloak/keycloak:26.7.0   true    0
+keycloak-1   quay.io/keycloak/keycloak:26.7.0   true    0
+210
+정문=200
+=== d2 선택 단계 — 역방향 26.0 으로 일부러 실패시킨다 ===
+15:34:55 역방향
+statefulset.apps/keycloak image updated
+NAME         IMAGE                              STATUS    READY   RESTARTS
+keycloak-0   quay.io/keycloak/keycloak:26.7.0   Running   true    0
+keycloak-1   quay.io/keycloak/keycloak:26.0     Running   false   2
+--- 왜 실패했나 ---
+2026-09-17 06:34:48,994 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) ERROR: Failed to start server in (production) mode
+2026-09-17 06:34:48,995 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) ERROR: liquibase.exception.ValidationFailedException: Validation Failed:
+2026-09-17 06:34:48,995 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) ERROR: Validation Failed:
+2026-09-17 06:34:48,995 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) For more details run the same command passing the '--verbose' option. Also you can use '--help' to see the details about the usage of the particular command.
+--- 그런데 서비스는 ---
+정문=200
+--- 실패한 기동이 스키마를 건드렸나 ---
+210
+
+[exited with code 0]
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-04-revert.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-04-revert.txt
new file mode 100644
index 0000000..32d81a8
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d2-04-revert.txt
@@ -0,0 +1,13 @@
+=== 실패 상세 — 체크섬 줄 ===
+2026-09-17 06:34:48,995 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) ERROR: liquibase.exception.ValidationFailedException: Validation Failed:
+     1 changesets check sum
+2026-09-17 06:34:48,995 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) ERROR: Validation Failed:
+     1 changesets check sum
+=== 되돌리기 — 26.7.0 으로 ===
+statefulset.apps/keycloak image updated
+partitioned roll out complete: 2 new pods have been updated...
+NAME         IMAGE                              READY   RESTARTS
+keycloak-0   quay.io/keycloak/keycloak:26.7.0   true    0
+keycloak-1   quay.io/keycloak/keycloak:26.7.0   true    0
+210
+정문=200
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d3-01-secret-paths.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d3-01-secret-paths.txt
new file mode 100644
index 0000000..b4338a7
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d3-01-secret-paths.txt
@@ -0,0 +1,26 @@
+=== d3 1. Secret 목록 ===
+NAME                   TYPE     DATA   AGE
+keycloak-lab-secrets   Opaque   2      106m
+=== 2. describe 가 무엇을 감추나 ===
+Data
+====
+KC_BOOTSTRAP_ADMIN_PASSWORD:  19 bytes
+POSTGRES_PASSWORD:            22 bytes
+=== 3-① 키 이름만 ===
+"KC_BOOTSTRAP_ADMIN_PASSWORD"
+"POSTGRES_PASSWORD"
+=== 3-② 값 대신 길이 ===
+22
+=== 주입 카나리아 ===
+secret/d3-canary created
+Data
+====
+CANARY:  25 bytes
+=== 경로 ② 저장소 — 노드 디스크에 평문이 있나 ===
+Encryption Status: Disabled, no configuration file found
+total 27152
+-rw-r--r-- 1 root root 12603392 Sep 17 06:20 state.db
+-rw-r--r-- 1 root root    32768 Sep 17 06:20 state.db-shm
+-rw-r--r-- 1 root root 15161632 Sep 17 06:20 state.db-wal
+0
+1
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d3-02-paths-and-revert.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d3-02-paths-and-revert.txt
new file mode 100644
index 0000000..17ea084
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d3-02-paths-and-revert.txt
@@ -0,0 +1,15 @@
+=== ④ -wal 과 strings 로 한 번 더 (문서가 미검증으로 둔 줄) ===
+3
+0
+sh: 1: strings: not found
+=== 경로 ④ RBAC — 막히는가 ===
+no
+no
+=== 되돌리기 1. 카나리아를 지운다 ===
+secret "d3-canary" deleted from keycloak-lab namespace
+=== 2. 지웠다고 파일에서 없어지나 ===
+0
+7
+=== 3. 네 항목 대조 ===
+NAME                   TYPE     DATA   AGE
+keycloak-lab-secrets   Opaque   2      106m
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d3-03-strings-missing.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d3-03-strings-missing.txt
new file mode 100644
index 0000000..69d8cb2
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d3-03-strings-missing.txt
@@ -0,0 +1,12 @@
+=== strings 가 없다 — 어디서 오나 ===
+(없다)
+(패키지 미설치)
+=== 처방: binutils 를 깐다 ===
+Processing triggers for libc-bin (2.36-9+deb12u14) ...
+Processing triggers for man-db (2.11.2-2) ...
+/usr/bin/strings
+=== 깔고 나서 문서의 ④ 를 그대로 ===
+0
+7
+=== 패키지 없이 같은 것을 보는 형태 ===
+7
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d4-01-renewal-automation.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d4-01-renewal-automation.txt
new file mode 100644
index 0000000..fa60c85
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d4-01-renewal-automation.txt
@@ -0,0 +1,33 @@
+=== d4 가 가리키는 기계(test-server)에 certbot 이 있나 ===
+/usr/bin/certbot
+NEXT LEFT LAST PASSED UNIT ACTIVATES
+
+0 timers listed.
+Pass --all to see loaded but inactive timers, too.
+=== 실제로 certbot 이 있는 기계(kc-lab-edge) ===
+certbot -> /usr/bin/certbot
+--- 5. 갱신 자동화가 도는가 ---
+NEXT                        LEFT     LAST PASSED UNIT          ACTIVATES
+Thu 2026-09-17 17:06:05 UTC 10h left -    -      certbot.timer certbot.service
+
+1 timers listed.
+--- 이름이 배포판마다 다르다 ---
+Thu 2026-09-17 17:06:05 UTC 10h left    -                           -            certbot.timer                certbot.service
+--- 6. 배포판 기본 유닛에 훅이 있나 ---
+# /lib/systemd/system/certbot.service
+[Unit]
+Description=Certbot
+Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
+Documentation=https://certbot.eff.org/docs
+[Service]
+Type=oneshot
+ExecStart=/usr/bin/certbot -q renew --no-random-sleep-on-renew
+PrivateTmp=true
+--- renewal-hooks 디렉터리 ---
+total 0
+--- 지금 인증서가 있나 ---
+Saving debug log to /var/log/letsencrypt/letsencrypt.log
+
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+No certificates found.
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
diff --git a/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d4a-01-hook-state.txt b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d4a-01-hook-state.txt
new file mode 100644
index 0000000..8bd09c9
--- /dev/null
+++ b/docs/keycloak-session-store/final/evidence/raw/relive-2026-09-17/d4a-01-hook-state.txt
@@ -0,0 +1,12 @@
+=== d4a 1. 출발점 nginx 워커 PID — 문서가 가리키는 기계(test-server) ===
+donghye+  178492  178491  0 15:51 ?        00:00:00 zsh -c  echo "=== d4a 1. ????????? nginx ?????? PID ??? ????????? ???????????? ??????(test-server) ===" ps -ef | grep "[n]ginx" | head -3 || echo "(test-server ??? nginx ??????????????? ??????)" echo "=== ?????? ??????(kc-lab-edge) ===" ssh -o BatchMode=yes kc-lab-edge "ps -ef | grep \"[n]ginx\" | head -3" echo "=== 3. ??? ??????????????? ?????? ????????? ===" ssh -o BatchMode=yes kc-lab-edge "sudo ls -la /etc/letsencrypt/renewal-hooks/deploy/" echo "=== 4. ??? ????????? ?????? ??? ===" echo -n "lab host : "; date -u "+%Y-%m-%dT%H:%M:%S.%3NZ" echo -n "kc-lab-edge: "; ssh -o BatchMode=yes kc-lab-edge "date -u \"+%Y-%m-%dT%H:%M:%S.%3NZ\"" 
+=== 실제 엣지(kc-lab-edge) ===
+root        1065       1  0 04:27 ?        00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
+www-data    1106    1065  0 04:27 ?        00:00:00 nginx: worker process
+=== 3. 훅 디렉터리가 비어 있는지 ===
+total 8
+drwxr-xr-x 2 root root 4096 Sep 17 04:33 .
+drwxr-xr-x 5 root root 4096 Sep 17 04:33 ..
+=== 4. 두 기계의 시계 차 ===
+lab host : 2026-09-17T06:51:28.799Z
+kc-lab-edge: 2026-09-17T06:49:54.782Z
diff --git a/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a2-database-loss.md b/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a2-database-loss.md
index 3380cf1..75c4c5b 100644
--- a/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a2-database-loss.md
+++ b/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a2-database-loss.md
@@ -41,9 +41,11 @@ PostgreSQL 을 정상 종료시키고 refresh 와 새 로그인과 관리 API 
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 전부 `[kc-lab-1]` 에서 `kubectl` 과 `psql` 로 친다. 노드 자체를 건드리는 명령이 없어서 `kc-lab-2` 로 들어갈 일이 없다. `kubectl` 에 `sudo` 를 붙이지 않는다 — root 홈에는 `~/.kube/config` 가 없어 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다.
+명령은 전부 `[lab host]` 에서 `kubectl` 과 `psql` 로 친다. 노드 자체를 건드리는 명령이 없어서 게스트에 들어갈 일이 없다. `kubectl` 에 `sudo` 를 붙이지 않는다 — root 홈에는 `~/.kube/config` 가 없어 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다.
 
-터미널은 둘을 연다. 하나는 탐침 파드 셸용이라 붙잡혀 있고, 하나는 관찰용이다. 그래서 `[kc-lab-1]` 라벨이 붙은 블록이 `[탐침 파드]` 블록 사이에 끼어 있으면 **관찰용 터미널에서 친다** — 파드 셸을 나가라는 뜻이 아니다. 나가라고 할 때는 `exit` 를 블록으로 따로 적는다.
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
+
+터미널은 둘을 연다. 하나는 탐침 파드 셸용이라 붙잡혀 있고, 하나는 관찰용이다. 그래서 `[lab host]` 라벨이 붙은 블록이 `[탐침 파드]` 블록 사이에 끼어 있으면 **관찰용 터미널에서 친다** — 파드 셸을 나가라는 뜻이 아니다. 나가라고 할 때는 `exit` 를 블록으로 따로 적는다.
 
 | 무엇 | 값 |
 |---|---|
@@ -84,7 +86,7 @@ A-1 과의 대비가 이 실험의 값이다.
 
 **이건 전면 장애를 만드는 실험이다.** 정문(`https://auth.hyeonworks.com`)이 실제로 `503` 이 된다. 이 실험대를 쓰는 다른 작업이 있으면 멈춘다. 정지 구간은 **1분 남짓**으로 짧게 잡는다. 되돌리는 명령은 아래 한 줄이다.
 
-```bash label="[kc-lab-1] 중간에 그만둘 때 치는 한 줄"
+```bash label="[lab host] 중간에 그만둘 때 치는 한 줄"
 kubectl -n keycloak-lab scale deployment/postgres --replicas=1
 ```
 
@@ -98,7 +100,7 @@ kubectl -n keycloak-lab scale deployment/postgres --replicas=1
 
 **무엇을 보는가** — 세 파드의 상태와 배치.
 
-```bash label="[kc-lab-1] 파드 배치를 본다"
+```bash label="[lab host] 파드 배치를 본다"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
@@ -116,7 +118,7 @@ postgres-7b474b88c8-sn9ff   true   10.42.1.24   kc-lab-2
 
 **무엇을 보는가** — 뒤의 모든 요청이 향할 주소.
 
-```bash label="[kc-lab-1] 파드 주소를 변수에 담는다"
+```bash label="[lab host] 파드 주소를 변수에 담는다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 echo "$K0 $K1"
@@ -128,14 +130,14 @@ echo "$K0 $K1"
 
 **무엇을 보는가** — 두 노드가 아는 멤버 수.
 
-```bash label="[kc-lab-1] ① 한 줄짜리 JSON 을 통째로 본다"
+```bash label="[lab host] ① 한 줄짜리 JSON 을 통째로 본다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size'
 ```
 
 라벨을 보고 나서 자른다. 아래 줄은 가이드가 미검증으로 표시했다(unknown).
 
-```bash label="[kc-lab-1] ② 필요한 줄만 자른다"
+```bash label="[lab host] ② 필요한 줄만 자른다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size' \
   | tr ',' '\n' | grep -E '"pod":|^"[0-9]'
@@ -151,7 +153,7 @@ kubectl -n observability exec deploy/prometheus -- \
 
 `--rm` 임시 파드는 매번 만들고 지우므로 느리고 경합이 있고, 토큰을 단계 사이로 넘길 수 없다. 이 실험은 DB 정지 전에 발급한 토큰을 정지 후에 써야 하므로 파드를 하나 띄워 두고 `exec` 로 단계를 이어간다.
 
-```bash label="[kc-lab-1] ① 상주 탐침 파드를 띄우고 Ready 까지 기다린다"
+```bash label="[lab host] ① 상주 탐침 파드를 띄우고 Ready 까지 기다린다"
 kubectl -n keycloak-lab run a2-probe --image=curlimages/curl:8.11.1 \
   --restart=Never \
   --env="K0=$K0" --env="K1=$K1" \
@@ -165,20 +167,20 @@ kubectl -n keycloak-lab wait --for=condition=Ready pod/a2-probe --timeout=120s
 
 비밀번호는 명령 치환으로 넘기므로 값이 터미널에도 셸 히스토리에도 남지 않는다. 존재와 길이만 확인한다.
 
-```bash label="[kc-lab-1] ② 비밀번호의 길이만 센다"
+```bash label="[lab host] ② 비밀번호의 길이만 센다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets \
   -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d | wc -c
 ```
 
 실측은 `19` 다(observed).
 
-```bash label="[kc-lab-1] ③ 파드 안에도 값이 들어왔는지 길이로 본다"
+```bash label="[lab host] ③ 파드 안에도 값이 들어왔는지 길이로 본다"
 kubectl -n keycloak-lab exec a2-probe -- sh -c 'echo "K0=$K0 K1=$K1 PW길이=${#PW}"'
 ```
 
 `PW길이=0` 이면 `--env` 가 빈 값을 넘긴 것이므로 파드를 지우고 다시 띄운다. 이제부터는 파드 셸에 들어가 친다. 나올 때는 `exit` 이고 파드는 안 지워진다.
 
-```bash label="[kc-lab-1] ④ 파드 셸로 들어간다"
+```bash label="[lab host] ④ 파드 셸로 들어간다"
 kubectl -n keycloak-lab exec -it a2-probe -- sh
 ```
 
@@ -211,7 +213,7 @@ done
 
 ### 6. 세션이 각자 노드에만 캐시됐는가
 
-```bash label="[kc-lab-1] 노드별 캐시 엔트리"
+```bash label="[lab host] 노드별 캐시 엔트리"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_statistics_approximate_entries_unique' \
   | tr ',' '\n' | grep -E '"cache":|"pod":|^"[0-9]'
@@ -227,7 +229,7 @@ kubectl -n observability exec deploy/prometheus -- \
 
 `keycloak-1` 이 `0` 인 것은 스크레이프 지연 때문이다. 방금 로그인했으므로 다음 15초 스크레이프에서 `1` 이 될 수 있고, 원래 실행 기록에도 「캐시 keycloak-0 = 1 건 / keycloak-1 = 0 건 (스크레이프 지연)」으로 적혀 있다. 판정에 쓰는 값은 양쪽이 다른지가 아니라 `keycloak-0` 이 확실히 가지고 있는지다.
 
-```bash label="[kc-lab-1] DB 세션 수도 적어 둔다"
+```bash label="[lab host] DB 세션 수도 적어 둔다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select offline_flag, count(*) from offline_user_session group by offline_flag"
 ```
@@ -291,7 +293,7 @@ curl -s -o /dev/null -w 'well-known %{http_code}\n' \
 
 밖에서 정문도 재 둔다.
 
-```bash label="[kc-lab-1] 밖에서 본 정문"
+```bash label="[lab host] 밖에서 본 정문"
 curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master
 ```
 
@@ -309,12 +311,12 @@ curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/mast
 | `delete pod` | Deployment 가 **곧바로 새로 만든다** — 몇 초 만에 돌아온다 |
 | 노드 정지 | Keycloak 도 같이 죽는다 — **두 장애가 섞인다** |
 
-```bash label="[kc-lab-1] ① 시각을 남기고 replica 를 0 으로 내린다"
+```bash label="[lab host] ① 시각을 남기고 replica 를 0 으로 내린다"
 date '+%H:%M:%S 정지'
 kubectl -n keycloak-lab scale deployment/postgres --replicas=0
 ```
 
-```bash label="[kc-lab-1] ② 파드가 사라질 때까지 기다리고 시각을 남긴다"
+```bash label="[lab host] ② 파드가 사라질 때까지 기다리고 시각을 남긴다"
 kubectl -n keycloak-lab wait --for=delete pod -l app=postgres --timeout=90s
 date '+%H:%M:%S 삭제완료'
 ```
@@ -339,7 +341,7 @@ pod/postgres-7b474b88c8-sn9ff condition met
 
 ### 1. postgres 파드가 하나도 없는가
 
-```bash label="[kc-lab-1] 파드와 Deployment 를 함께 본다"
+```bash label="[lab host] 파드와 Deployment 를 함께 본다"
 kubectl -n keycloak-lab get pods -o wide
 kubectl -n keycloak-lab get deploy postgres
 ```
@@ -348,7 +350,7 @@ kubectl -n keycloak-lab get deploy postgres
 
 ### 2. Keycloak 이 실제로 DB 를 못 잡고 있는가
 
-```bash label="[kc-lab-1] 커넥션 풀 쪽 로그를 본다"
+```bash label="[lab host] 커넥션 풀 쪽 로그를 본다"
 kubectl -n keycloak-lab logs keycloak-0 --tail=40 | grep -A3 -i 'connection'
 ```
 
@@ -366,19 +368,29 @@ Caused by: java.net.ConnectException: Connection refused
 
 ### 3. 파드가 죽지 않고 트래픽에서만 빠졌는가
 
-```bash label="[kc-lab-1] Ready 와 재시작 횟수만 뽑아 본다"
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount \
+```bash label="[lab host] Ready 와 재시작 횟수만 뽑아 본다"
+kubectl -n keycloak-lab get pods -o "custom-columns=NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount" \
   | grep keycloak
 ```
 
-실측은 `keycloak-0 false 0`, `keycloak-1 false 0` 이다(observed). `READY` 가 `false` 인데 `RESTARTS` 는 여전히 `0` 이다. 파드는 죽지 않았고 트래픽에서 빠졌을 뿐이다. `RESTARTS` 가 오르고 있으면 liveness 가 실패하는 것이고, 그 상태에서 무엇을 재든 「DB 없는 Keycloak」이 아니라 「재시작 중인 Keycloak」을 재게 된다. 이 `restarts=0` 이 자동 회복이라는 결론을 가능하게 하는 조건이다.
+실측은 `keycloak-0 false 0`, `keycloak-1 false 0` 이다(observed). 2026-09-17 에도 같은 두 줄을 받았다(observed).
+
+**그 `false` 는 DB 를 내리자마자 나오지 않는다.** readiness 프로브가 `periodSeconds: 10` · `failureThreshold: 3` 이라 헬스가 먼저 실패하고 그로부터 최대 30초 뒤에 조건이 뒤집힌다. 2026-09-17 에 내린 직후에는 네 경로가 이미 전부 `500` 인데 파드는 아직 `true true` 였고 정문도 `200` 이었다. 약 50초 뒤에 `false false` · 정문 `503` 이 됐다(observed).
+
+```text
+정지 직후      네 경로 500 500 500 500 · ready true,true  · 정문 200
+약 50초 뒤     ready false,false · 엔드포인트 false,false · 정문 503
+```
+
+**그 50초 사이의 화면을 보고 「DB 가 없어도 멀쩡하다」로 읽지 않는다.** 이미 500 인데 아직 트래픽에서 안 빠졌을 뿐이다. 이 편이 잡으려는 것도 그 어긋남이다 — 되는 것과 Ready 인 것은 다르다.
+
+`READY` 가 `false` 인데 `RESTARTS` 는 여전히 `0` 이다. 파드는 죽지 않았고 트래픽에서 빠졌을 뿐이다. `RESTARTS` 가 오르고 있으면 liveness 가 실패하는 것이고, 그 상태에서 무엇을 재든 「DB 없는 Keycloak」이 아니라 「재시작 중인 Keycloak」을 재게 된다. 이 `restarts=0` 이 자동 회복이라는 결론을 가능하게 하는 조건이다.
 
 ## 관찰
 
 탐침 파드 안에서 주입 전과 똑같은 명령을 다시 친다. 파드 셸에서 나갔다 들어오면 `RT0` `RT1` `AT` `CID` 가 사라지므로 셸을 붙잡고 있는 편이 낫다.
 
-```bash label="[kc-lab-1] 셸을 놓쳤으면 다시 들어간다"
+```bash label="[lab host] 셸을 놓쳤으면 다시 들어간다"
 kubectl -n keycloak-lab exec -it a2-probe -- sh
 ```
 
@@ -477,9 +489,9 @@ curl -s -o /dev/null -w '④ %{http_code}\n' --max-time 10 -H "Authorization: Be
 
 같은 파드, 같은 포트인데 경로에 따라 `200` 과 `500` 이 갈린다. realm 공개키와 메타데이터는 메모리에 있으므로 DB 없이도 응답하고, 이론적으로는 이미 JWKS 를 캐시한 리소스 서버가 토큰 검증을 계속할 수 있다는 뜻이다. 이 실험대에는 독립 리소스 서버가 아직 없으므로 거기까지가 말할 수 있는 범위다.
 
-```bash label="[kc-lab-1] Service 뒤에 누가 남았는지 본다"
+```bash label="[lab host] Service 뒤에 누가 남았는지 본다"
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 ```
 
 실측은 이렇다(observed, `04-health-and-service.txt`).
@@ -499,13 +511,13 @@ Warning: v1 Endpoints is deprecated in v1.33+; use discovery.k8s.io/v1 EndpointS
 
 사람이 눈으로 볼 때는 이쪽이 더 짧다.
 
-```bash label="[kc-lab-1] 같은 것을 짧게 보는 형태"
+```bash label="[lab host] 같은 것을 짧게 보는 형태"
 kubectl -n keycloak-lab describe svc keycloak | grep -i endpoints
 ```
 
 밖에서 본다. 한 번 눈으로 볼 때는 헤더까지 본다.
 
-```bash label="[kc-lab-1] 정문을 코드로 한 번, 헤더로 한 번"
+```bash label="[lab host] 정문을 코드로 한 번, 헤더로 한 번"
 curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master
 curl -I https://auth.hyeonworks.com/realms/master
 ```
@@ -523,7 +535,7 @@ curl -I https://auth.hyeonworks.com/realms/master
 
 헬스 본문이 까닭을 말한다. Keycloak 이미지에는 `curl` 이 없으므로 파드 밖에서 묻는다. 묻는 명령은 관찰용 터미널에서 치는데 `"http://$K0:9000/..."` 는 큰따옴표라 파드 안이 아니라 그 터미널의 셸이 편다. 두 값은 2번에서 잡았는데 그 터미널을 지금 탐침 파드 셸이 붙잡고 있으므로, 관찰용 터미널에서 두 줄을 다시 친다.
 
-```bash label="[kc-lab-1] 관찰용 터미널에서도 파드 주소를 잡는다"
+```bash label="[lab host] 관찰용 터미널에서도 파드 주소를 잡는다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 echo "$K0 $K1"
@@ -531,7 +543,7 @@ echo "$K0 $K1"
 
 DB 가 없어도 이 두 줄은 된다. 파드 주소는 쿠버네티스 API 가 답하고, 주입 검증 3번에서 본 대로 Keycloak 파드는 재시작하지 않았으므로(`RESTARTS 0`) 값도 2번과 같다. 이 두 줄을 건너뛰고 다음 블록을 치면 `curl -s "http://:9000/health/ready"` 가 되어 URL 이 거부되고 빈 출력이 나온다. 전면 장애 한복판이라 그 빈 줄을 「헬스 엔드포인트까지 죽었다」로 읽기 쉬운데, 실제로는 헬스가 응답하고 네 항목 중 하나만 DOWN 이다.
 
-```bash label="[kc-lab-1] 탐침 파드를 통해 헬스를 묻는다"
+```bash label="[lab host] 탐침 파드를 통해 헬스를 묻는다"
 kubectl -n keycloak-lab exec a2-probe -- \
   curl -s "http://$K0:9000/health/ready"
 ```
@@ -551,7 +563,7 @@ kubectl -n keycloak-lab exec a2-probe -- \
 
 관측의 함정이 여기 있다.
 
-```bash label="[kc-lab-1] up 지표를 본다"
+```bash label="[lab host] up 지표를 본다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=up' \
   | tr ',' '\n' | grep -E '"job":|"pod":|^"[0-9]'
@@ -577,7 +589,7 @@ A-0 은 `up` 을 「가장 중요한 합성 지표」라고 썼는데 절반만
 
 그럼 readiness 를 지표로 볼 수 있는지 물어본다.
 
-```bash label="[kc-lab-1] 파드 readiness 지표가 있는지 묻는다"
+```bash label="[lab host] 파드 readiness 지표가 있는지 묻는다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=kube_pod_status_ready' \
   | head -c 300; echo
@@ -597,12 +609,12 @@ kubectl -n observability exec deploy/prometheus -- \
 
 **목적** — PostgreSQL 을 되살리고 Keycloak 이 스스로 돌아오는지 본다.
 
-```bash label="[kc-lab-1] ① 시각을 남기고 replica 를 1 로 올린다"
+```bash label="[lab host] ① 시각을 남기고 replica 를 1 로 올린다"
 date '+%H:%M:%S 재기동'
 kubectl -n keycloak-lab scale deployment/postgres --replicas=1
 ```
 
-```bash label="[kc-lab-1] ② 롤아웃이 끝날 때까지 기다린다"
+```bash label="[lab host] ② 롤아웃이 끝날 때까지 기다린다"
 kubectl -n keycloak-lab rollout status deployment/postgres --timeout=180s
 ```
 
@@ -625,16 +637,14 @@ deployment "postgres" successfully rolled out
 
 **목적** — 사람이 한 일이 DB 를 켠 것뿐인지 확인한다.
 
-```bash label="[kc-lab-1] ① Ready 와 정문을 함께 친다"
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount \
+```bash label="[lab host] ① Ready 와 정문을 함께 친다"
+kubectl -n keycloak-lab get pods -o "custom-columns=NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount" \
   | grep keycloak
 curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master
 ```
 
-```bash label="[kc-lab-1] ② 재시작 횟수만 따로 센다"
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount | grep keycloak
+```bash label="[lab host] ② 재시작 횟수만 따로 센다"
+kubectl -n keycloak-lab get pods -o "custom-columns=NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount" | grep keycloak
 ```
 
 **예상 결과** — 실측은 이렇다(observed).
@@ -647,6 +657,18 @@ NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount | grep ke
 
 ②의 실측은 `keycloak-0  0`, `keycloak-1  0` 이다(observed). 주입 검증에서 본 값 그대로다.
 
+2026-09-17 에 다시 재 보니 `scale --replicas=1` 에서 두 파드가 `true` 로 돌아오기까지 **36초**였다(observed). 그 가운데 절반쯤은 PostgreSQL 파드가 뜨는 시간이다.
+
+```text
+14:29:20 복구
+deployment "postgres" successfully rolled out
+14:29:56 ready=true,true 정문=200 재시작=0,0
+```
+
+「약 15초」는 **DB 가 Ready 가 된 뒤부터** 센다. `scale` 을 친 순간부터 세면 더 걸리므로, 30초쯤 지나도 `503` 이면 그때 기다린다.
+
+**④ 는 이 시점에 `401` 이 정상이다.** 2026-09-17 실행에서 ①②③ 이 `200` 인데 ④ 만 `401` 이었다(observed). access token 이 60초짜리라 정지 구간을 지나오며 만료됐을 뿐 DB 와는 무관하다. 위 7번의 시계 경고가 이것을 미리 말해 둔다.
+
 **왜 필요한가** — 커넥션 풀이 스스로 재연결하고 readiness 가 다시 UP 이 되면서 Service 에 복귀했다. 회복 시간은 DB Ready 이후 약 15초, Keycloak 재시작은 불필요(`restarts=0`)였다. liveness 는 실패하면 재시작이라 재시작하면 나아지는 문제(교착, 메모리 누수)에 쓰고, readiness 는 실패하면 트래픽에서 격리라 재시작해도 안 나아지는 문제(의존 대상이 죽음)에 쓴다. DB 장애에 liveness 를 걸면 모든 파드가 무한 재시작하고, DB 가 돌아와도 CrashLoopBackOff 의 백오프 때문에 회복이 늦어지며, 재시작하면 캐시까지 날아간다.
 
 **문제가 생기면** — 계속 `503` 이면 Keycloak 이 아직 재연결 중이다. 15~30초 더 기다리고 재시작하지 않는다.
@@ -655,12 +677,12 @@ NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount | grep ke
 
 **목적** — 정상 종료가 데이터를 잃지 않았다는 것을 숫자로 확인하고 실험 도구를 치운다.
 
-```bash label="[kc-lab-1] ① 세션 수를 다시 센다"
+```bash label="[lab host] ① 세션 수를 다시 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select offline_flag, count(*) from offline_user_session group by offline_flag"
 ```
 
-```bash label="[kc-lab-1] ② 탐침 파드를 직접 지운다"
+```bash label="[lab host] ② 탐침 파드를 직접 지운다"
 kubectl -n keycloak-lab delete pod a2-probe --ignore-not-found
 ```
 
diff --git a/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a3-database-crash.md b/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a3-database-crash.md
index 1eb5ae6..704ab79 100644
--- a/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a3-database-crash.md
+++ b/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a3-database-crash.md
@@ -41,7 +41,9 @@ PostgreSQL 을 진짜로 죽여 커밋됐다고 응답받은 로그인 중 몇 
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 전부 `[kc-lab-1]` 에서 `kubectl` 과 `psql` 로 친다. 노드 자체를 건드리는 명령이 없어서 `kc-lab-2` 로 들어갈 일이 없다. `kubectl` 에 `sudo` 를 붙이지 않는다 — root 홈에는 `~/.kube/config` 가 없어 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다.
+명령은 전부 `[lab host]` 에서 `kubectl` 과 `psql` 로 친다. 노드 자체를 건드리는 명령이 없어서 게스트에 들어갈 일이 없다. `kubectl` 에 `sudo` 를 붙이지 않는다 — root 홈에는 `~/.kube/config` 가 없어 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 터미널은 둘이 반드시 필요하다. 터미널 ① 은 로그인 루프가 도는 동안 통째로 붙잡히고, 터미널 ② 에서 그 사이에 데이터베이스를 죽인다. 코드블록마다 어느 터미널인지 붙여 두었다.
 
@@ -95,7 +97,7 @@ A-0 을 끝내고 아직 아무것도 주입하기 전에 쓴 예측표에 이 
 
 지운 세션은 돌아오지 않는다. 되돌릴 수 있는 것은 문장 로깅 하나이고, 켜기 전에 끄는 명령을 먼저 읽어 둔다.
 
-```bash label="[kc-lab-1] 중간에 그만둘 때 치는 한 묶음"
+```bash label="[lab host] 중간에 그만둘 때 치는 한 묶음"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "alter system reset log_statement" -c "select pg_reload_conf()"
 ```
@@ -108,7 +110,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **무엇을 보는가** — 세션 테이블의 컬럼 타입.
 
-```bash label="[kc-lab-1] 세션 테이블의 정의를 본다"
+```bash label="[lab host] 세션 테이블의 정의를 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "\d offline_user_session"
 ```
@@ -137,7 +139,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **무엇을 보는가** — A-0 에서 잡은 것은 refresh 트랜잭션이었고 로그인(INSERT)도 그런지는 확인하지 않았다. 아니라면 로그인은 안 사라지고 이 측정 설계 자체가 성립하지 않는다.
 
-```bash label="[kc-lab-1] ① 문장 로깅을 잠깐 켠다"
+```bash label="[lab host] ① 문장 로깅을 잠깐 켠다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "alter system set log_statement='all'" -c "select pg_reload_conf()"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
@@ -146,7 +148,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 `none` 이면 `pg_reload_conf()` 가 안 돈 상태다. `alter system` 은 `postgresql.auto.conf` 에 쓸 뿐이고 reload 를 해야 적용된다.
 
-```bash label="[kc-lab-1] ② 탐침 파드를 띄우고 Ready 까지 기다린다"
+```bash label="[lab host] ② 탐침 파드를 띄우고 Ready 까지 기다린다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 kubectl -n keycloak-lab run a3-probe --image=curlimages/curl:8.11.1 \
   --restart=Never \
@@ -159,13 +161,13 @@ kubectl -n keycloak-lab wait --for=condition=Ready pod/a3-probe --timeout=120s
 
 명령줄에 비밀번호를 직접 쓰지 않는다. 원래 실험의 재현 절차에는 평문 비밀번호가 그대로 적혀 있는데 파드 안 `ps` 에도 셸 히스토리에도 남는다. `--env` 로 넘긴 값은 그 파드 안에서만 산다. 존재와 길이만 확인한다 — 실측은 `19` 다(observed).
 
-```bash label="[kc-lab-1] ③ 비밀번호의 길이만 두 곳에서 센다"
+```bash label="[lab host] ③ 비밀번호의 길이만 두 곳에서 센다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets \
   -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d | wc -c
 kubectl -n keycloak-lab exec a3-probe -- sh -c 'echo "K0=$K0 PW길이=${#PW}"'
 ```
 
-```bash label="[kc-lab-1] ④ 로그인 한 번을 보낸다"
+```bash label="[lab host] ④ 로그인 한 번을 보낸다"
 kubectl -n keycloak-lab exec a3-probe -- sh -c \
   'curl -s -o /dev/null -w "%{http_code}\n" -X POST \
      "http://$K0:8080/realms/master/protocol/openid-connect/token" \
@@ -173,7 +175,7 @@ kubectl -n keycloak-lab exec a3-probe -- sh -c \
      -d username=admin -d "password=$PW"'
 ```
 
-```bash label="[kc-lab-1] ⑤ 그 로그인의 트랜잭션을 로그에서 본다"
+```bash label="[lab host] ⑤ 그 로그인의 트랜잭션을 로그에서 본다"
 kubectl -n keycloak-lab logs deploy/postgres --since=60s \
   | grep -E 'BEGIN|insert into OFFLINE|synchronous_commit|COMMIT' | tail -20
 ```
@@ -196,7 +198,7 @@ kubectl -n keycloak-lab logs deploy/postgres --since=60s \
 
 곧바로 끈다.
 
-```bash label="[kc-lab-1] ⑥ 문장 로깅을 끄고 꺼졌는지 읽는다"
+```bash label="[lab host] ⑥ 문장 로깅을 끄고 꺼졌는지 읽는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "alter system reset log_statement" -c "select pg_reload_conf()"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
@@ -209,7 +211,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **무엇을 보는가** — 나중에 손실 창과 견줄 값.
 
-```bash label="[kc-lab-1] 커밋과 WAL 관련 설정 네 줄"
+```bash label="[lab host] 커밋과 WAL 관련 설정 네 줄"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select name, setting, unit, source from pg_settings
       where name in ('commit_delay','synchronous_commit','wal_writer_delay','wal_writer_flush_after')"
@@ -234,12 +236,12 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **무엇을 보는가** — 출발값.
 
-```bash label="[kc-lab-1] ① 세션 행을 지운다"
+```bash label="[lab host] ① 세션 행을 지운다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "delete from offline_user_session"
 ```
 
-```bash label="[kc-lab-1] ② 남은 행을 센다"
+```bash label="[lab host] ② 남은 행을 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select count(*) from offline_user_session where offline_flag='0'"
 ```
@@ -250,7 +252,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 ### 5. 파드 셋의 재시작 횟수를 적어 둔다
 
-```bash label="[kc-lab-1] 파드 셋의 상태"
+```bash label="[lab host] 파드 셋의 상태"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
@@ -282,7 +284,7 @@ kubectl -n keycloak-lab get pods -o wide
 
 0건이다. 파드 안에서 `( ... ) &` 로 띄운 루프가 `exec` 세션이 끝날 때 같이 죽었고 측정 자체가 없었다. 그래서 편집기로 파일을 연다.
 
-```bash label="[kc-lab-1] ① 편집기로 루프 파일을 연다"
+```bash label="[lab host] ① 편집기로 루프 파일을 연다"
 vim /tmp/a3-login-loop.sh
 ```
 
@@ -299,23 +301,41 @@ while [ "$i" -lt 400 ]; do
          -d username=admin -d "password=$PW" \
        | sed -n 's/.*"access_token":"\([^"]*\)".*/\1/p')
   if [ -n "$AT" ]; then
-    echo "$AT" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null \
-      | sed -n 's/.*"sid":"\([^"]*\)".*/\1/p' >> /tmp/sids
+    SID=$(echo "$AT" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null \
+          | sed -n 's/.*"sid":"\([^"]*\)".*/\1/p')
+    [ -n "$SID" ] && echo "$SID" >> /tmp/sids
   fi
   i=$((i + 1))
 done
 echo "루프 종료: $(wc -l < /tmp/sids) 건"
 ```
 
+**`sed` 의 출력을 파일로 바로 흘리지 않는다.** 변수에 받아 `echo` 로 다시 쓴다. 탐침 이미지의 셸이 busybox 이고 그 `sed` 는 **입력에 끝 개행이 없으면 출력에도 안 붙인다.** `base64 -d` 가 내놓는 JSON 에는 끝 개행이 없으므로, 바로 `>>` 로 흘리면 sid 가 줄바꿈 없이 이어 붙어 **파일 한 줄**이 된다. 2026-09-17 에 그대로 겪었다(observed) — 로그인 217건이 DB 에 들어갔는데 파일은 이랬다.
+
+```text
+0 /tmp/sids
+9384 /tmp/sids
+```
+
+`wc -l` 이 `0` 이고 `wc -c` 는 9384 다. **데이터는 다 있는데 줄이 하나도 없다.** 이 파일을 `wc -l`·`sort -u`·`comm` 으로 세는 것이 이 실험의 측정 전부이므로, 이 상태로는 손실 건수가 언제나 0 으로 나온다. `echo` 로 감싼 형태로 열 번 돌려 `10 줄 / 250 바이트` 를 받아 고쳤다(observed).
+
+busybox 의 `sed` 가 그렇게 동작하는 것을 따로 확인했다(observed).
+
+```text
+printf "%s" '{"sid":"ABC"}' | sed -n 's/.*"sid":"\([^"]*\)".*/\1/p' | od -c
+0000000   A   B   C
+0000003
+```
+
 `/tmp/sids` 에는 클라이언트가 `200` 과 토큰을 실제로 받은 것만 쌓인다. `AT` 가 비면 아무것도 안 적으므로 이 파일이 「서버가 COMMIT 했다고 응답한 것」의 목록이고, 그게 이 실험의 시험군이다.
 
-```bash label="[kc-lab-1] ② 파일을 파드 안으로 밀어 넣고 줄 수를 센다"
+```bash label="[lab host] ② 파일을 파드 안으로 밀어 넣고 줄 수를 센다"
 kubectl -n keycloak-lab exec -i a3-probe -- sh -c 'cat > /tmp/a3-login-loop.sh' \
   < /tmp/a3-login-loop.sh
 kubectl -n keycloak-lab exec a3-probe -- wc -l /tmp/a3-login-loop.sh
 ```
 
-**예상 결과** — 줄 수가 `17 /tmp/a3-login-loop.sh` 로 나오면 들어갔다.
+**예상 결과** — 줄 수가 `19 /tmp/a3-login-loop.sh` 로 나오면 들어갔다. 원래 실행의 파일은 `17` 줄이었고, 위에서 sid 를 변수로 받는 두 줄로 바꾸면서 늘었다.
 
 **왜 필요한가** — `kubectl cp` 도 되지만 컨테이너에 `tar` 가 있어야 한다. 이 실험대의 `curlimages/curl:8.11.1` 에 `tar` 가 있는지는 재지 않았다(unknown). 그래서 가이드는 `cat >` 로 밀어 넣는 쪽이 어디서나 통한다고 적고 그쪽을 골랐다.
 
@@ -455,7 +475,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- \
 
 ### 1. 시도 ① 의 검증 — 죽인 적이 없다
 
-```bash label="[kc-lab-1] 새 파드를 기다리고 기동 로그를 본다"
+```bash label="[lab host] 새 파드를 기다리고 기동 로그를 본다"
 kubectl -n keycloak-lab rollout status deployment/postgres --timeout=180s
 kubectl -n keycloak-lab logs deploy/postgres | grep -E 'not properly shut down|redo|ready to accept'
 ```
@@ -471,7 +491,7 @@ kubectl -n keycloak-lab logs deploy/postgres | grep -E 'not properly shut down|r
 
 그런데도 손실을 세어 보면 이렇게 나온다.
 
-```bash label="[kc-lab-1] 클라이언트가 받은 건수와 DB 건수를 나란히 본다"
+```bash label="[lab host] 클라이언트가 받은 건수와 DB 건수를 나란히 본다"
 kubectl -n keycloak-lab exec a3-probe -- wc -l /tmp/sids
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select count(*) from offline_user_session where offline_flag='0'"
@@ -492,7 +512,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 ### 2. 시도 ② 의 검증 — 아무 일도 일어나지 않았다
 
-```bash label="[kc-lab-1] 파드와 기동 로그의 마지막 세 줄"
+```bash label="[lab host] 파드와 기동 로그의 마지막 세 줄"
 kubectl -n keycloak-lab get pods -l app=postgres
 kubectl -n keycloak-lab logs deploy/postgres | grep -E 'not properly shut down|redo|ready to accept' | tail -3
 ```
@@ -522,7 +542,7 @@ kubectl -n keycloak-lab logs deploy/postgres | grep -E 'not properly shut down|r
 
 ### 3. 시도 ③ 의 검증 — 이번엔 걸렸다
 
-```bash label="[kc-lab-1] 크래시 흔적 여섯 줄을 한 번에 본다"
+```bash label="[lab host] 크래시 흔적 여섯 줄을 한 번에 본다"
 kubectl -n keycloak-lab logs deploy/postgres --since=5m \
   | grep -E 'terminated by signal|reinitializing|not properly shut down|redo|checkpoint complete|ready to accept'
 ```
@@ -542,16 +562,15 @@ kubectl -n keycloak-lab logs deploy/postgres --since=5m \
 
 여섯 줄이 순서대로 나온다. `terminated by signal 9` 는 내가 죽인 그 백엔드이고, `all server processes terminated; reinitializing` 은 postmaster 가 전체를 갈아엎기로 한 것이며, **`not properly shut down` 이 주입 성공 신호다 — 이게 없으면 결과를 해석하지 않는다.** `redo starts` 와 `redo done` 이 재생된 WAL 구간, `checkpoint complete` 가 재생 결과를 디스크에 고정한 것, 그리고 `ready to accept connections` 의 시각이 새로 찍혔다.
 
-```bash label="[kc-lab-1] 파드 재시작 횟수를 센다"
-kubectl -n keycloak-lab get pods -l app=postgres -o custom-columns=\
-NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount
+```bash label="[lab host] 파드 재시작 횟수를 센다"
+kubectl -n keycloak-lab get pods -l app=postgres -o "custom-columns=NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount"
 ```
 
 `RESTARTS` 는 `0` 이다. 컨테이너의 PID 1 인 postmaster 는 살아 있고 자식만 갈아치웠다. 쿠버네티스 관점에서는 아무 일도 없었지만 데이터 관점에서는 전원이 나간 것과 같다.
 
 ## 관찰
 
-```bash label="[kc-lab-1] ① 클라이언트가 받은 sid 목록을 꺼낸다"
+```bash label="[lab host] ① 클라이언트가 받은 sid 목록을 꺼낸다"
 kubectl -n keycloak-lab exec a3-probe -- cat /tmp/sids > /tmp/client-sids.txt
 wc -l /tmp/client-sids.txt
 head -3 /tmp/client-sids.txt
@@ -567,12 +586,12 @@ hkcOv1QskUFmYveMLB6Hljra
 
 DB 쪽은 먼저 총계를 보고 그다음 목록으로 뽑는다.
 
-```bash label="[kc-lab-1] ② 총계를 표로 본다"
+```bash label="[lab host] ② 총계를 표로 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select count(*) from offline_user_session where offline_flag='0'"
 ```
 
-```bash label="[kc-lab-1] ③ 값만 뽑아 파일로 내린다"
+```bash label="[lab host] ③ 값만 뽑아 파일로 내린다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select user_session_id from offline_user_session where offline_flag='0'" \
   > /tmp/db-sids.txt
@@ -583,7 +602,7 @@ wc -l /tmp/db-sids.txt
 
 차집합은 `comm` 으로 낸다. 정렬부터 한다 — 이 세 줄은 미검증이다(unknown).
 
-```bash label="[kc-lab-1] ④ 같은 정렬 순서로 맞춘 뒤 왼쪽 전용만 낸다"
+```bash label="[lab host] ④ 같은 정렬 순서로 맞춘 뒤 왼쪽 전용만 낸다"
 LC_ALL=C sort -u /tmp/client-sids.txt > /tmp/a.txt
 LC_ALL=C sort -u /tmp/db-sids.txt     > /tmp/b.txt
 comm -23 /tmp/a.txt /tmp/b.txt
@@ -608,13 +627,32 @@ comm -23 /tmp/a.txt /tmp/b.txt
 
 로그인이 성공했다고 응답받았는데 세션이 존재하지 않는다. 153건 중 4건, 약 2.6% 다.
 
-```bash label="[kc-lab-1] ⑤ 유실 건수를 센다"
+**2026-09-17 에 새 실험대에서 다시 재니 395건 중 3건이었다**(observed). 세 시도를 순서대로 밟았고 앞의 둘은 그때도 0건이었다.
+
+```text
+시도 ① --grace-period=0 --force   유실 0건 — 새 파드 로그가 `database system was shut down at …`
+시도 ② kill -9 1                  유실 0건 — RESTARTS 0, 파드 이름도 그대로
+시도 ③ 백엔드 PID 39 에 SIGKILL   유실 3건 — 클라이언트 395 · DB 392
+```
+
+시도 ③ 의 로그가 남긴 것도 같았다.
+
+```text
+server process (PID 39) was terminated by signal 9: Killed
+all server processes terminated; reinitializing
+database system was not properly shut down; automatic recovery in progress
+redo starts at 0/1F80A00
+```
+
+**건수는 실행마다 다르다.** 크래시 순간에 아직 디스크로 못 내려간 트랜잭션만 사라지므로 로그인 속도와 `wal_writer_delay` 와 크래시 타이밍이 그 수를 정한다. 판정에 쓰는 것은 숫자가 아니라 **0 이 아니라는 것**이다.
+
+```bash label="[lab host] ⑤ 유실 건수를 센다"
 comm -23 /tmp/a.txt /tmp/b.txt | wc -l
 ```
 
 사라지지 않은 것도 하나 본다. sid 는 첫 줄 `tail -1` 이 화면에 찍은 그 값을 옮겨 넣는다 — 로그인 루프가 만든 값이라 실행마다 다르다.
 
-```bash label="[kc-lab-1] ⑥ 마지막 sid 가 DB 에 있는지 본다"
+```bash label="[lab host] ⑥ 마지막 sid 가 DB 에 있는지 본다"
 tail -1 /tmp/client-sids.txt
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select user_session_id, created_on, last_session_refresh
@@ -676,12 +714,12 @@ ALTER DATABASE keycloak SET synchronous_commit = on;
 
 **목적** — 다음 실험의 측정값이 로그 폭주 때문에 달라지지 않게 한다.
 
-```bash label="[kc-lab-1] ① 두 설정을 읽는다"
+```bash label="[lab host] ① 두 설정을 읽는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "show log_statement" -c "show log_line_prefix"
 ```
 
-```bash label="[kc-lab-1] ② none 이 아니면 되돌리고 reload 한다"
+```bash label="[lab host] ② none 이 아니면 되돌리고 reload 한다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "alter system reset log_statement" -c "select pg_reload_conf()"
 ```
@@ -696,17 +734,17 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **목적** — DB 행과 캐시 엔트리를 함께 비우고 실험 도구를 치운다.
 
-```bash label="[kc-lab-1] ① 세션 행을 지운다"
+```bash label="[lab host] ① 세션 행을 지운다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "delete from offline_user_session"
 ```
 
-```bash label="[kc-lab-1] ② 파드를 갈아 끼워 캐시를 비운다"
+```bash label="[lab host] ② 파드를 갈아 끼워 캐시를 비운다"
 kubectl -n keycloak-lab rollout restart statefulset/keycloak
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s
 ```
 
-```bash label="[kc-lab-1] ③ 탐침 파드를 지운다"
+```bash label="[lab host] ③ 탐침 파드를 지운다"
 kubectl -n keycloak-lab delete pod a3-probe --ignore-not-found
 ```
 
@@ -720,11 +758,11 @@ kubectl -n keycloak-lab delete pod a3-probe --ignore-not-found
 
 **목적** — 크래시가 데이터 일부 손실인지 DB 파손인지 가른다.
 
-```bash label="[kc-lab-1] ① 파드 상태"
+```bash label="[lab host] ① 파드 상태"
 kubectl -n keycloak-lab get pods -l app=postgres
 ```
 
-```bash label="[kc-lab-1] ② 마이그레이션 이력 세 줄"
+```bash label="[lab host] ② 마이그레이션 이력 세 줄"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select id, dateexecuted from databasechangelog order by dateexecuted desc limit 3"
 ```
@@ -739,7 +777,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **목적** — 다음 실행이 옛 sid 목록을 읽지 않게 한다.
 
-```bash label="[kc-lab-1] 이 실험이 만든 로컬 파일 다섯 개"
+```bash label="[lab host] 이 실험이 만든 로컬 파일 다섯 개"
 rm -f /tmp/client-sids.txt /tmp/db-sids.txt /tmp/a.txt /tmp/b.txt /tmp/a3-login-loop.sh
 ```
 
diff --git a/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a4-node-loss.md b/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a4-node-loss.md
index d9b32ea..ea7c23d 100644
--- a/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a4-node-loss.md
+++ b/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a4-node-loss.md
@@ -42,7 +42,7 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 | 터미널 | 어디서 치나 | 무엇을 치나 |
 |---|---|---|
 | A | `test-server` (VM 호스트) | `virsh` — 전원을 뽑고 다시 넣는다 |
-| B | `kc-lab-1` | `kubectl` — 관찰. 4b 에서는 이 터미널이 죽는다 |
+| B | `test-server` | `kubectl` — 관찰. 4b 에서는 이 터미널이 살아 있고 `kubectl` 만 막힌다 |
 | C | `test-server` | 밖에서 `curl`. 사용자 시점 |
 
 4b 에서는 `kc-lab-2` 에도 붙는다. 터미널 A 와 같은 기계에서 `ssh kc-lab-2` 로 붙고, 이름이 안 풀리면 `ssh 192.168.122.12` 다.
@@ -284,7 +284,9 @@ virsh destroy kc-lab-1
   observability    prometheus-6774f94f7c-pzr2t
 ```
 
-④ 뒤에는 `차단 시각: 12:18:08` 과 `Domain 'kc-lab-1' destroyed` 가 나오고, 터미널 B 의 SSH 세션이 그대로 끊긴다.
+④ 뒤에는 `차단 시각: 12:18:08` 과 `Domain 'kc-lab-1' destroyed` 가 나오고, 원래 실행에서는 터미널 B 의 SSH 세션이 그대로 끊긴다 — 그 실행은 터미널 B 를 `kc-lab-1` 안에 두었기 때문이다.
+
+**터미널 B 를 `test-server` 에 두면 세션은 안 끊긴다.** 대신 `kubectl` 이 API 서버를 못 찾는다 — k3s server 가 방금 내린 그 노드에 있고 kubeconfig 의 `server:` 가 `https://192.168.122.11:6443` 을 가리키기 때문이다. 화면에 남는 것이 「셸이 죽었다」에서 「`kubectl` 이 안 닿는다」로 바뀔 뿐, **관찰이 멈춘다는 사실은 같다.** 이 실험이 보여 주려는 것도 그것이다 — 죽은 노드로 관찰하고 있었으면 죽는 순간을 못 본다. 터미널 C 의 `curl` 이 그래서 따로 있다.
 
 **왜 필요한가** — `traefik` 이 이 노드에 있고 `replicas` 가 `1` 이라, 이 노드를 뽑으면 클러스터로 들어갈 문이 사라진다. 인벤토리를 먼저 뽑아 두지 않으면 4b 에서 무엇이 없어졌는지 사후에 못 센다.
 
@@ -345,6 +347,16 @@ done
   +60초  node=NotReady | keycloak-0=Running postgres-7b474b88c8-2gf27=Running | 외부 HTTP 503
 ```
 
+2026-09-17 에 새 실험대에서 다시 재니 같은 모양이었다(observed). 차단은 `14:39:28` 이다.
+
+```text
+  14:39:56 (+28초)  kc-lab-2=Ready    | keycloak-0=Running postgres=Running | 정문 000
+  14:40:34 (+66초)  kc-lab-2=NotReady | keycloak-0=Running postgres=Running | 정문 503
+  14:42:41 (+3분)   kc-lab-2=NotReady | keycloak-0=Running postgres=Running | 정문 503
+```
+
+**넘어가는 대목은 같고 초는 실행마다 다르다.** 30초 간격으로 쟀으므로 이번 판에서는 `+28초` 와 `+66초` 사이 어디쯤이다. `node-monitor-grace-period` 가 40초라 그 범위에 들어간다. 그 뒤로 3분이 지나도 두 파드는 계속 `Running` 이었다.
+
 **이 결과가 뜻하는 것** — `+30초` 줄과 `+45초` 줄 사이에서 노드 상태가 넘어간다. kube-controller-manager 는 kubelet 의 하트비트가 `node-monitor-grace-period`(이 실험대에서 40초) 동안 없어야 `NotReady` 로 바꾸고, 그 40초 동안 쿠버네티스는 거짓말을 한다. 사용자는 그 40초에도 이미 장애를 겪고 있고 `000` 이 그것을 말한다. 여기서 주입이 안 걸렸다고 결론 내리면 틀린다 — 기계는 꺼져 있고 쿠버네티스가 아직 모를 뿐이다.
 
 처음 40초가 `503` 이 아니라 `000` 인 까닭은 층이 다르기 때문이다. `000` 은 `curl` 이 응답 자체를 못 받은 것(타임아웃 또는 연결 실패)이고, `503` 은 nginx 와 Traefik 은 살아 있고 뒤로 보낼 파드가 없는 것이다. 엣지 nginx(`kc-lab-edge`)의 upstream 에는 두 노드가 다 들어 있다.
@@ -379,8 +391,7 @@ kubectl get nodes
 ### 1. 죽은 파드가 산 파드보다 건강해 보인다
 
 ```bash label="[터미널 B] ① 파드마다 phase 와 ready 와 노드를 함께"
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,PHASE:.status.phase,READY:.status.containerStatuses[0].ready,NODE:.spec.nodeName
+kubectl -n keycloak-lab get pods -o "custom-columns=NAME:.metadata.name,PHASE:.status.phase,READY:.status.containerStatuses[0].ready,NODE:.spec.nodeName"
 ```
 
 ```text
@@ -482,6 +493,17 @@ watch -n 30 'kubectl -n keycloak-lab get pods -o wide'
 
 `+240초` 와 `+270초` 사이에 두 가지가 동시에 일어난다. `kc-lab-2` 의 파드들이 `Terminating` 으로 바뀌고, 새 이름의 postgres 파드가 생기며 `Pending` 이다. 축출이 시작됐는데 `Terminating` 이 안 끝나고 새 파드는 뜨지 못하며, 두 문제는 원인이 다르다.
 
+2026-09-17 에 새 실험대에서 다시 재니 같은 모양이었다(observed). 차단 `05:39:28` 에 대해 두 파드의 `deletionTimestamp` 가 `05:44:17` 로 찍혔다 — **4분 49초**다.
+
+```text
+keycloak-0                  Terminating  kc-lab-2   deletionTimestamp=2026-09-17T05:44:17Z
+postgres-7b474b88c8-prlxx   Terminating  kc-lab-2   deletionTimestamp=2026-09-17T05:44:17Z
+postgres-7b474b88c8-5zp6v   Pending      <none>     deletionTimestamp=<none>
+keycloak-1                  Running      kc-lab-1   deletionTimestamp=<none>
+```
+
+**StatefulSet 과 Deployment 의 처지가 그대로 갈린다.** 새 이름으로 생긴 것은 postgres 쪽뿐이고 `keycloak-0` 은 대체 파드 없이 `Terminating` 으로만 남는다. StatefulSet 은 이름이 고정이라 같은 이름의 파드를 둘로 만들 수 없고, 죽은 노드의 kubelet 이 「지웠다」고 답해 주지 못하므로 그 이름이 영원히 안 비워진다.
+
 ### 6. 새 파드가 갈 곳이 없다
 
 ```bash label="[터미널 B] ① Pending 인 파드 이름을 먼저 확인한다"
diff --git a/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a5-asymmetric-partition.md b/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a5-asymmetric-partition.md
index 0ff96a6..9851503 100644
--- a/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a5-asymmetric-partition.md
+++ b/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a5-asymmetric-partition.md
@@ -41,9 +41,13 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 ## 읽기 전에 — 어디서 치는가
 
-`kubectl` 은 `kc-lab-1` 에서 친다. `iptables` 는 노드 자체를 건드리는 명령이라 게스트 셸이 필요하고, 두 노드에 각각 넣어야 하며 어느 노드에 넣느냐가 결과를 가른다. 이쪽 노드의 규칙은 `[kc-lab-1]` 에서 그대로 치고, 반대 노드의 규칙은 `ssh kc-lab-2` 로 붙어서 친다. 코드블록마다 어느 셸인지 붙여 두었다.
+`kubectl` 은 `[lab host]` 에서 친다. `iptables` 는 노드 자체를 건드리는 명령이라 게스트 셸이 필요하고, 두 노드에 각각 넣어야 하며 어느 노드에 넣느냐가 결과를 가른다. 이쪽 노드의 규칙은 `[kc-lab-1]` 에서 그대로 치고, 반대 노드의 규칙은 `ssh kc-lab-2` 로 붙어서 친다. 코드블록마다 어느 셸인지 붙여 두었다.
 
-가이드는 터미널 둘을 권한다 — 하나는 상주 탐침 파드용, 하나는 관찰용이다. 다만 이 절차에는 탐침 파드의 셸 안에서 치는 명령이 하나도 없다. `a5-probe` 는 `kubectl exec` 으로만 쓰므로 명령은 전부 `[kc-lab-1]` 에서 치고, `$K0` 와 `$K1` 도 그 셸의 변수다. 다른 터미널에서 관찰 §7 의 헬스체크를 치면 두 변수가 빈 문자열이라 양쪽 다 안 닿고, 그 화면을 「둘 다 DOWN」으로 읽게 된다. 실제로는 한쪽만 `DOWN` 이다.
+**`[kc-lab-1]` 라벨이 붙은 블록은 게스트 셸이다.** lab host 에서 `ssh kc-lab-1` 로 들어가서 치고, 끝나면 `exit` 로 나온다. `ssh kc-lab-2 '…'` 한 줄 형태는 lab host 에서 그대로 쳐도 되므로 `[lab host]` 로 두었다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
+
+가이드는 터미널 둘을 권한다 — 하나는 상주 탐침 파드용, 하나는 관찰용이다. 다만 이 절차에는 탐침 파드의 셸 안에서 치는 명령이 하나도 없다. `a5-probe` 는 `kubectl exec` 으로만 쓰므로 명령은 전부 `[lab host]` 에서 치고, `$K0` 와 `$K1` 도 그 셸의 변수다. 다른 터미널에서 관찰 §7 의 헬스체크를 치면 두 변수가 빈 문자열이라 양쪽 다 안 닿고, 그 화면을 「둘 다 DOWN」으로 읽게 된다. 실제로는 한쪽만 `DOWN` 이다.
 
 | 무엇 | 값 |
 |---|---|
@@ -101,18 +105,18 @@ ssh kc-lab-2 'sudo iptables -t raw -F PREROUTING ; sudo iptables -F FORWARD'
 
 이쪽 노드의 규칙을 먼저 걷어낸다.
 
-```bash label="[kc-lab-1] ① 지우기 전에 무엇이 있었는지 본다"
-sudo iptables -S FORWARD
+```bash label="[lab host] ① 지우기 전에 무엇이 있었는지 본다"
+ssh kc-lab-1 'sudo iptables -S FORWARD'
 ```
 
-```bash label="[kc-lab-1] ② 두 체인을 비운다"
-sudo iptables -t raw -F PREROUTING
-sudo iptables -F FORWARD
+```bash label="[lab host] ② kc-lab-1 의 두 체인을 비운다"
+ssh kc-lab-1 'sudo iptables -t raw -F PREROUTING'
+ssh kc-lab-1 'sudo iptables -F FORWARD'
 ```
 
 그다음 반대 노드에 붙는다.
 
-```bash label="[kc-lab-1] ③ 게스트 셸로 들어간다"
+```bash label="[lab host] ③ 게스트 셸로 들어간다"
 ssh kc-lab-2
 ```
 
@@ -142,11 +146,11 @@ exit
 
 **무엇을 확인하는가** — 어느 파드가 어느 노드에 있고 IP(Internet Protocol 주소)가 무엇인지.
 
-```bash label="[kc-lab-1] ① 배치와 IP"
+```bash label="[lab host] ① 배치와 IP"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
-```bash label="[kc-lab-1] ② 뒤에서 계속 쓸 두 값을 셸 변수에 담는다"
+```bash label="[lab host] ② 뒤에서 계속 쓸 두 값을 셸 변수에 담는다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 echo "K0=$K0 K1=$K1"
@@ -167,12 +171,12 @@ postgres-7b474b88c8-9cmsv   1/1   Running   0               14m
 
 **무엇을 확인하는가** — 지금 코디네이터가 하나인지, 그리고 뷰 ID 가 몇인지.
 
-```bash label="[kc-lab-1] ① 디스커버리는 DB 가 말한다"
+```bash label="[lab host] ① 디스커버리는 DB 가 말한다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select name, ip, coord from jgroups_ping order by name"
 ```
 
-```bash label="[kc-lab-1] ② 뷰는 로그가 말한다"
+```bash label="[lab host] ② 뷰는 로그가 말한다"
 kubectl -n keycloak-lab logs keycloak-0 | grep ISPN000094 | tail -1
 kubectl -n keycloak-lab logs keycloak-1 | grep ISPN000094 | tail -1
 ```
@@ -199,12 +203,12 @@ ISPN000094: [keycloak-0-24309(v=16.0.12)|13] (2) [keycloak-0-24309(v=16.0.12), k
 
 Keycloak 컨테이너에는 `curl` 도 `wget` 도 없다(`exit 127`).
 
-```bash label="[kc-lab-1] ① 한 줄짜리 JSON 을 처음 한 번은 그대로 본다"
+```bash label="[lab host] ① 한 줄짜리 JSON 을 처음 한 번은 그대로 본다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size'
 ```
 
-```bash label="[kc-lab-1] ② 미검증 — 라벨과 값만 남겨 자르는 형태"
+```bash label="[lab host] ② 미검증 — 라벨과 값만 남겨 자르는 형태"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size' \
   | tr ',' '\n' | grep -E '"pod":|^"[0-9]'
@@ -240,9 +244,15 @@ sudo conntrack -L 2>/dev/null | grep 7800
 ssh kc-lab-2 'sudo conntrack -L 2>/dev/null | grep 7800'
 ```
 
+:::warning
+
+**게스트에 `conntrack` 이 깔려 있지 않다.** cloud-init 이 까는 것은 `curl` 과 `nftables` 뿐이라 이 명령은 `sudo: conntrack: command not found` 로 끝나는데, `2>/dev/null` 이 그 한 줄을 지우고 종료 코드도 `0` 이다. 빈 화면이 「7800 연결이 없다」로 읽힌다. 두 노드에 먼저 `sudo apt install -y conntrack` 을 치거나, 패키지 없이 `sudo grep 7800 /proc/net/nf_conntrack` 으로 커널 표를 직접 읽는다. A-1 에서 재서 확인했다(observed).
+
+:::
+
 **따라 하는 사람은** 둘째 줄을 나눈다. 붙고 나서 원격 셸에서 친다. 이 나눈 형태는 이 실험대에서 치지 않았다.
 
-```bash label="[kc-lab-1] ① 반대 노드에 붙는다"
+```bash label="[lab host] ① 반대 노드에 붙는다"
 ssh kc-lab-2
 ```
 
@@ -265,11 +275,11 @@ ESTABLISHED src=10.42.1.77 dst=10.42.0.42 sport=60485 dport=7800
 
 **무엇을 확인하는가** — 정문이 지금 무엇을 답하는지.
 
-```bash label="[kc-lab-1] ① 응답을 통째로 읽는 형태"
+```bash label="[lab host] ① 응답을 통째로 읽는 형태"
 curl -I --max-time 8 https://auth.hyeonworks.com/realms/master
 ```
 
-```bash label="[kc-lab-1] ② 여러 번 비교할 것이므로 코드만 뽑는 형태"
+```bash label="[lab host] ② 여러 번 비교할 것이므로 코드만 뽑는 형태"
 curl -s -o /dev/null -w '%{http_code}\n' --max-time 8 https://auth.hyeonworks.com/realms/master
 ```
 
@@ -297,32 +307,32 @@ curl -s -o /dev/null -w '%{http_code}\n' --max-time 8 https://auth.hyeonworks.co
 
 **목적** — `FORWARD` 최상단에 넣으면 conntrack 승인보다 먼저 평가되리라는 가설을 실제로 확인한다.
 
-```bash label="[kc-lab-1] ① 7800 을 FORWARD 1번에 넣는다"
+```bash label="[lab host] ① 7800 을 FORWARD 1번에 넣는다"
 ssh kc-lab-2 "sudo iptables -I FORWARD 1 -p tcp -d $K0 --dport 7800  -j DROP"
 ```
 
-```bash label="[kc-lab-1] ② 57800 도 같이 막는다"
+```bash label="[lab host] ② 57800 도 같이 막는다"
 ssh kc-lab-2 "sudo iptables -I FORWARD 1 -p tcp -d $K0 --dport 57800 -j DROP"
 ```
 
-```bash label="[kc-lab-1] ③ 주입 시각"
+```bash label="[lab host] ③ 주입 시각"
 date '+%H:%M:%S 주입'
 ```
 
 **예상 결과** — `iptables` 는 아무것도 찍지 않는다. `주입: 12:28:23` 만 남는다.
 
-이 줄들은 「전제와 되돌리기」의 중단 절차처럼 나눠 치면 안 된다. 거기는 `ssh kc-lab-2` 로 붙고 원격 셸에서 쳤지만, 여기는 `$K0` 가 들어간다. `$K0` 는 `[kc-lab-1]` 셸의 변수라 원격 셸에는 없고, 나눠 치면 빈 문자열이 들어가 `-d` 없는 규칙이 걸린다. 큰따옴표가 그 값을 `[kc-lab-1]` 에서 펴서 보내므로 한 줄 형태 그대로 친다.
+이 줄들은 「전제와 되돌리기」의 중단 절차처럼 나눠 치면 안 된다. 거기는 `ssh kc-lab-2` 로 붙고 원격 셸에서 쳤지만, 여기는 `$K0` 가 들어간다. `$K0` 는 `[lab host]` 셸의 변수라 원격 셸에는 없고, 나눠 치면 빈 문자열이 들어가 `-d` 없는 규칙이 걸린다. 큰따옴표가 그 값을 `[lab host]` 에서 펴서 보내므로 한 줄 형태 그대로 친다.
 
 **왜 필요한가** — 57800 을 같이 막는 것은 FD_SOCK2(장애 감지 채널)가 `bind_port + 50000` 을 쓰기 때문이다. 7800 만 막으면 장애 감지는 계속 통해서 분단이 어정쩡해진다.
 
 **결과를 본 다음 반드시 걷어낸다.** 주입 검증 §1 을 치고 여기로 와서 ④ 와 ⑤ 를 친다. 시도 ② 는 같은 두 포트를 같은 노드에서 다시 막으므로, `FORWARD` 에 남은 `DROP` 둘을 그대로 두면 어느 테이블이 패킷을 잡았는지 가릴 수 없다. 치우는 명령은 넣을 때와 인자가 같아야 한다.
 
-```bash label="[kc-lab-1] ④ 넣을 때와 같은 인자로 지운다"
+```bash label="[lab host] ④ 넣을 때와 같은 인자로 지운다"
 ssh kc-lab-2 "sudo iptables -D FORWARD -p tcp -d $K0 --dport 7800  -j DROP"
 ssh kc-lab-2 "sudo iptables -D FORWARD -p tcp -d $K0 --dport 57800 -j DROP"
 ```
 
-```bash label="[kc-lab-1] ⑤ 지워졌는지 줄 번호로 확인한다"
+```bash label="[lab host] ⑤ 지워졌는지 줄 번호로 확인한다"
 ssh kc-lab-2 'sudo iptables -L FORWARD -n --line-numbers | head -5'
 ```
 
@@ -353,15 +363,15 @@ netfilter 의 처리 순서가 그 근거다.
 | filter FORWARD 직접 | 순서에 따라 | 경쟁한다 (kube-router 가 밀어낸다) |
 | raw PREROUTING | 끊는다 | 없다 — CNI 가 안 쓰는 테이블 |
 
-```bash label="[kc-lab-1] ① 테이블만 바꾸고 노드와 목적지는 그대로 둔다"
+```bash label="[lab host] ① 테이블만 바꾸고 노드와 목적지는 그대로 둔다"
 ssh kc-lab-2 "sudo iptables -t raw -I PREROUTING 1 -p tcp -d $K0 --dport 7800  -j DROP"
 ```
 
-```bash label="[kc-lab-1] ② 57800 도 같이"
+```bash label="[lab host] ② 57800 도 같이"
 ssh kc-lab-2 "sudo iptables -t raw -I PREROUTING 1 -p tcp -d $K0 --dport 57800 -j DROP"
 ```
 
-```bash label="[kc-lab-1] ③ 주입 시각"
+```bash label="[lab host] ③ 주입 시각"
 date '+%H:%M:%S 주입'
 ```
 
@@ -371,11 +381,11 @@ date '+%H:%M:%S 주입'
 
 **이 규칙도 반드시 걷어낸다.** 주입 검증 §2 를 치고 여기로 와서 ④ 와 ⑤ 를 친다. **네 번째 주입이 `kc-lab-2` 의 `raw PREROUTING` 에 글자까지 같은 두 줄을 다시 넣는다.** 걷어내지 않으면 같은 규칙이 두 벌 쌓여 카운터가 네 줄로 갈리고, 검증 §4 의 예상 결과는 그 모양을 적어 두지 않았다. 지우기 전에 `-L` 로 무엇이 있는지 본다. `-F` 는 체인 전체를 비운다.
 
-```bash label="[kc-lab-1] ④ 무엇이 있는지 먼저 본다"
+```bash label="[lab host] ④ 무엇이 있는지 먼저 본다"
 ssh kc-lab-2 'sudo iptables -t raw -L PREROUTING -n --line-numbers'
 ```
 
-```bash label="[kc-lab-1] ⑤ 체인을 비운다"
+```bash label="[lab host] ⑤ 체인을 비운다"
 ssh kc-lab-2 'sudo iptables -t raw -F PREROUTING'
 ```
 
@@ -385,15 +395,23 @@ ssh kc-lab-2 'sudo iptables -t raw -F PREROUTING'
 
 **목적** — 7800 으로 실제로 들어가는 패킷을 잡는다. 목적지 파드가 있는 노드에서 잡아야 한다.
 
-```bash label="[kc-lab-1] ① keycloak-1 의 IP 를 목적지로, 이 노드에 넣는다"
-sudo iptables -t raw -I PREROUTING 1 -p tcp -d $K1 --dport 7800  -j DROP
+```bash label="[lab host] ① keycloak-1 의 IP 를 목적지로, 그 파드가 있는 노드에 넣는다"
+ssh kc-lab-1 "sudo iptables -t raw -I PREROUTING 1 -p tcp -d $K1 --dport 7800  -j DROP"
 ```
 
-```bash label="[kc-lab-1] ② 57800 도 같이"
-sudo iptables -t raw -I PREROUTING 1 -p tcp -d $K1 --dport 57800 -j DROP
+```bash label="[lab host] ② 57800 도 같이"
+ssh kc-lab-1 "sudo iptables -t raw -I PREROUTING 1 -p tcp -d $K1 --dport 57800 -j DROP"
 ```
 
-```bash label="[kc-lab-1] ③ 주입 시각"
+**`ssh kc-lab-1 "…"` 한 줄 형태인 까닭이 반대 노드 때와 같다.** `$K1` 은 `[lab host]` 셸의 변수다. `ssh kc-lab-1` 로 먼저 들어가서 치면 그 셸에는 그 변수가 없어 **빈 문자열**이 들어가고, `-d` 없는 규칙이 걸려 **7800 으로 가는 모든 패킷**이 끊긴다. 2026-09-17 에 게스트 셸에서 확인했다(observed).
+
+```text
+게스트 셸의 K1=[]
+```
+
+큰따옴표가 값을 `[lab host]` 에서 펴서 보내므로 이 두 줄은 한 줄 형태 그대로 친다.
+
+```bash label="[lab host] ③ 주입 시각"
 date '+%H:%M:%S 주입'
 ```
 
@@ -417,15 +435,15 @@ date '+%H:%M:%S 주입'
 
 **목적** — `kc-lab-1` 의 규칙은 그대로 두고 `kc-lab-2` 에 반대 방향을 더해 실제 분단을 만든다.
 
-```bash label="[kc-lab-1] ① 반대 방향을 반대 노드에 더한다"
+```bash label="[lab host] ① 반대 방향을 반대 노드에 더한다"
 ssh kc-lab-2 "sudo iptables -t raw -I PREROUTING 1 -p tcp -d $K0 --dport 7800  -j DROP"
 ```
 
-```bash label="[kc-lab-1] ② 57800 도 같이"
+```bash label="[lab host] ② 57800 도 같이"
 ssh kc-lab-2 "sudo iptables -t raw -I PREROUTING 1 -p tcp -d $K0 --dport 57800 -j DROP"
 ```
 
-```bash label="[kc-lab-1] ③ 주입 시각"
+```bash label="[lab host] ③ 주입 시각"
 date '+%H:%M:%S 주입'
 ```
 
@@ -438,6 +456,27 @@ date '+%H:%M:%S 주입'
 
 **왜 필요한가** — 한 방향만 막으면 JGroups 가 열린 방향으로 다시 붙는다. 양쪽을 막아야 `coord = t` 가 둘이 된다.
 
+2026-09-17 에 그 「다시 붙는」 과정을 초 단위로 봤다(observed). 한 방향만 막은 채로 두면 **잠깐 `1` 로 떨어졌다가 2분 안에 `2` 로 돌아온다.**
+
+```text
+주입 +60초    keycloak-1=1  keycloak-0=1     ← 여기서 멈추면 「분단됐다」로 읽는다
+주입 +2분     keycloak-1=2  keycloak-0=2
+주입 +3분     keycloak-1=2  keycloak-0=2
+```
+
+**그 첫 값을 결론으로 삼지 않는다.** 한 방향 차단은 한 번 재서 판정하지 않는다. 2~3분 두고 값이 돌아오는지를 본다.
+
+양방향으로 막은 뒤의 실측은 이렇다(observed).
+
+```text
+kc-lab-1 의 raw PREROUTING   7800: 21건  57800: 21건
+kc-lab-2 의 raw PREROUTING   7800: 19건  57800:  0건
+멤버 수                       keycloak-1=1  keycloak-0=1
+jgroups_ping                  keycloak-0-13476 t · keycloak-1-8002 t
+```
+
+분단을 가장 짧게 증명하는 것은 `coord` 가 둘 다 `t` 로 찍히는 순간이다. **`kc-lab-2` 쪽 57800 카운터만 `0` 인 것도 정상이다** — FD_SOCK2 가 그 방향에서 안 쓰였을 뿐이고, 7800 쪽이 올라갔으면 규칙은 걸렸다. 두 체인을 비우자 2분 안에 `2` 와 `coord` 하나로 돌아왔다(observed).
+
 **문제가 생기면** — 양쪽 카운터를 다 본다. 한쪽만 걸리면 그것은 여전히 단방향이다.
 
 ## 주입 검증
@@ -446,7 +485,7 @@ date '+%H:%M:%S 주입'
 
 ### 1. 시도 ① — 넣은 직후에는 맞게 보인다
 
-```bash label="[kc-lab-1] ① 규칙과 카운터를 함께 본다"
+```bash label="[lab host] ① 규칙과 카운터를 함께 본다"
 ssh kc-lab-2 'sudo iptables -L FORWARD -n -v --line-numbers'
 ```
 
@@ -482,7 +521,7 @@ kube-router 가 주기적으로 자기 체인을 `FORWARD` 최상단에 다시 
 
 ### 2. 시도 ② — CNI 와 경쟁하지도 않는데 0 이다
 
-```bash label="[kc-lab-1] ① raw 체인의 카운터"
+```bash label="[lab host] ① raw 체인의 카운터"
 ssh kc-lab-2 'sudo iptables -t raw -L PREROUTING -n -v'
 ```
 
@@ -498,8 +537,8 @@ ssh kc-lab-2 'sudo iptables -t raw -L PREROUTING -n -v'
 
 ### 3. 성공한 주입 — 처음으로 숫자가 올라간다
 
-```bash label="[kc-lab-1] ① 이 노드의 raw 체인"
-sudo iptables -t raw -L PREROUTING -n -v
+```bash label="[lab host] ① 그 노드의 raw 체인"
+ssh kc-lab-1 'sudo iptables -t raw -L PREROUTING -n -v'
 ```
 
 ```text
@@ -524,11 +563,11 @@ sudo iptables -t raw -L PREROUTING -n -v
 
 ### 4. 양방향 주입 — 양쪽 카운터를 다 본다
 
-```bash label="[kc-lab-1] ① 이 노드"
-sudo iptables -t raw -L PREROUTING -n -v
+```bash label="[lab host] ① kc-lab-1"
+ssh kc-lab-1 'sudo iptables -t raw -L PREROUTING -n -v'
 ```
 
-```bash label="[kc-lab-1] ② 반대 노드"
+```bash label="[lab host] ② 반대 노드"
 ssh kc-lab-2 'sudo iptables -t raw -L PREROUTING -n -v'
 ```
 
@@ -540,11 +579,11 @@ ssh kc-lab-2 'sudo iptables -t raw -L PREROUTING -n -v'
 
 **시도 ① 의 규칙이 `FORWARD` 에 걸려 있는 동안 친다.** 주입 §1 의 ④⑤ 로 걷어낸 뒤에 치면 규칙이 없는 상태를 재게 되는데, 화면은 규칙이 있든 없든 `외부 200` 이라 틀렸다는 신호가 안 나온다.
 
-```bash label="[kc-lab-1] ① 25초 간격으로 몇 번 친다"
+```bash label="[lab host] ① 25초 간격으로 몇 번 친다"
 kubectl -n keycloak-lab get pods | grep keycloak
 ```
 
-```bash label="[kc-lab-1] ② 같은 간격으로 밖에서"
+```bash label="[lab host] ② 같은 간격으로 밖에서"
 curl -s -o /dev/null -w '%{http_code}\n' --max-time 8 https://auth.hyeonworks.com/realms/master
 ```
 
@@ -573,7 +612,7 @@ curl -s -o /dev/null -w '%{http_code}\n' --max-time 8 https://auth.hyeonworks.co
 
 ### 3. 로그 시각은 UTC 다
 
-```bash label="[kc-lab-1] ① 최근 20분의 뷰 변화"
+```bash label="[lab host] ① 최근 20분의 뷰 변화"
 kubectl -n keycloak-lab logs keycloak-0 --since=20m | grep ISPN000094
 kubectl -n keycloak-lab logs keycloak-1 --since=20m | grep ISPN000094
 ```
@@ -604,8 +643,8 @@ Keycloak 컨테이너는 UTC(Coordinated Universal Time, 협정 세계시)로 
 
 앞에서 친 것과 똑같은 명령을 다시 친다. 그것이 대조하는 방법이다.
 
-```bash label="[kc-lab-1] ① 차단 전에 친 것과 같은 명령"
-sudo conntrack -L 2>/dev/null | grep 7800
+```bash label="[lab host] ① 차단 전에 친 것과 같은 명령"
+ssh kc-lab-1 'sudo conntrack -L 2>/dev/null | grep 7800'
 ```
 
 ```text
@@ -622,12 +661,12 @@ sudo conntrack -L 2>/dev/null | grep 7800
 
 JGroups 는 막힌 연결이 죽자 반대 방향으로 새로 연결했다. FD_SOCK2 가 상대를 의심하기 전에 복구가 끝났고, 의심 카운터가 그것을 뒷받침한다.
 
-```bash label="[kc-lab-1] ① 의심 카운터"
+```bash label="[lab host] ① 의심 카운터"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_jgroups_fd_sock2_get_num_suspected_members'
 ```
 
-```bash label="[kc-lab-1] ② 병합 횟수"
+```bash label="[lab host] ② 병합 횟수"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_jgroups_merge3_get_num_merge_events'
 ```
@@ -641,16 +680,16 @@ kubectl -n observability exec deploy/prometheus -- \
 
 ### 5. 양방향으로 막으면 갈라진다
 
-```bash label="[kc-lab-1] ① 25초 간격으로 파드"
+```bash label="[lab host] ① 25초 간격으로 파드"
 kubectl -n keycloak-lab get pods | grep keycloak
 ```
 
-```bash label="[kc-lab-1] ② Service 에서 빠졌는지"
+```bash label="[lab host] ② Service 에서 빠졌는지"
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 ```
 
-```bash label="[kc-lab-1] ③ 같은 간격으로 밖에서"
+```bash label="[lab host] ③ 같은 간격으로 밖에서"
 curl -s -o /dev/null -w '%{http_code}\n' --max-time 8 https://auth.hyeonworks.com/realms/master
 ```
 
@@ -675,7 +714,7 @@ curl -s -o /dev/null -w '%{http_code}\n' --max-time 8 https://auth.hyeonworks.co
 
 ### 6. split brain 은 DB 한 줄로 확인한다
 
-```bash label="[kc-lab-1] ① 앞에서 친 것과 같은 쿼리"
+```bash label="[lab host] ① 앞에서 친 것과 같은 쿼리"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select name, ip, coord from jgroups_ping order by name"
 ```
@@ -694,16 +733,16 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 Keycloak 컨테이너에 `curl` 이 없으므로 상주 파드를 띄운다.
 
-```bash label="[kc-lab-1] ① 상주 탐침을 띄운다"
+```bash label="[lab host] ① 상주 탐침을 띄운다"
 kubectl -n keycloak-lab run a5-probe --image=curlimages/curl:8.11.1 \
   --restart=Never --command -- sleep 1800
 ```
 
-```bash label="[kc-lab-1] ② 뜰 때까지 기다린다"
+```bash label="[lab host] ② 뜰 때까지 기다린다"
 kubectl -n keycloak-lab wait --for=condition=Ready pod/a5-probe --timeout=120s
 ```
 
-```bash label="[kc-lab-1] ③ 두 노드의 헬스체크를 각각"
+```bash label="[lab host] ③ 두 노드의 헬스체크를 각각"
 kubectl -n keycloak-lab exec a5-probe -- curl -s "http://$K0:9000/health/ready"
 kubectl -n keycloak-lab exec a5-probe -- curl -s "http://$K1:9000/health/ready"
 ```
@@ -751,25 +790,25 @@ Keycloak 의 클러스터 헬스체크는 비대칭이다. 코디네이터였던
 
 지우기 전에 무엇이 있는지 본다.
 
-```bash label="[kc-lab-1] ① 이 노드"
-sudo iptables -t raw -L PREROUTING -n -v --line-numbers
+```bash label="[lab host] ① kc-lab-1"
+ssh kc-lab-1 'sudo iptables -t raw -L PREROUTING -n -v --line-numbers'
 ```
 
-```bash label="[kc-lab-1] ② 반대 노드"
+```bash label="[lab host] ② 반대 노드"
 ssh kc-lab-2 'sudo iptables -t raw -L PREROUTING -n -v --line-numbers'
 ```
 
 그다음 해제 시각을 찍고 양쪽을 비운다.
 
-```bash label="[kc-lab-1] ③ 해제 시각"
+```bash label="[lab host] ③ 해제 시각"
 date '+%H:%M:%S 해제'
 ```
 
-```bash label="[kc-lab-1] ④ 이 노드를 비운다"
-sudo iptables -t raw -F PREROUTING
+```bash label="[lab host] ④ kc-lab-1 을 비운다"
+ssh kc-lab-1 'sudo iptables -t raw -F PREROUTING'
 ```
 
-```bash label="[kc-lab-1] ⑤ 반대 노드를 비운다"
+```bash label="[lab host] ⑤ 반대 노드를 비운다"
 ssh kc-lab-2 'sudo iptables -t raw -F PREROUTING'
 ```
 
@@ -791,7 +830,7 @@ ssh kc-lab-2 'sudo iptables -t raw -F PREROUTING'
 
 ### 2. 누가 붙였는지는 MergeView 가 말한다
 
-```bash label="[kc-lab-1] ① 양쪽 로그의 마지막 병합"
+```bash label="[lab host] ① 양쪽 로그의 마지막 병합"
 kubectl -n keycloak-lab logs keycloak-0 | grep MergeView | tail -1
 kubectl -n keycloak-lab logs keycloak-1 | grep MergeView | tail -1
 ```
@@ -811,7 +850,7 @@ MergeView::[...|15] (2)     ← 병합. 뷰 ID 는 계속 증가한다
 
 뷰 ID 는 단조 증가하므로 언제 몇 번 갈라졌는지를 로그만으로 셀 수 있다.
 
-```bash label="[kc-lab-1] ② 캐시별 재분배 로그"
+```bash label="[lab host] ② 캐시별 재분배 로그"
 kubectl -n keycloak-lab logs keycloak-0 | grep ISPN100007 | tail -6
 ```
 
@@ -848,7 +887,7 @@ kubectl -n keycloak-lab logs keycloak-0 | grep ISPN100007 | tail -6
 | 탐침 파드 | `kubectl -n keycloak-lab get pod a5-probe` | 지웠으면 `NotFound` |
 | 밖 | `curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master` | `200` |
 
-```bash label="[kc-lab-1] 탐침 파드를 지운다"
+```bash label="[lab host] 탐침 파드를 지운다"
 kubectl -n keycloak-lab delete pod a5-probe --ignore-not-found
 ```
 
diff --git a/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a6-latency-injection.md b/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a6-latency-injection.md
index 6adec65..7c33614 100644
--- a/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a6-latency-injection.md
+++ b/docs/keycloak-session-store/tech-log-studio/losing-a-node-or-the-store/setup/setup-reproduce-a6-latency-injection.md
@@ -39,7 +39,9 @@ postgres 가 보내는 패킷 중 노드를 건너가는 것만 200밀리초 지
 
 ## 읽기 전에 — 어디서 치는가
 
-`kubectl` 은 `kc-lab-1` 에서 친다. `tc` 는 노드 자체를 건드리는 명령이라 `kc-lab-2` 에서 치고, postgres 가 그 노드에 있다. 아래 명령들은 가이드가 실제로 친 한 줄 형태 그대로이므로 `ssh kc-lab-2 '...'` 가 붙어 있다. 코드블록마다 어느 셸인지 붙여 두었다.
+`kubectl` 은 `[lab host]` 에서 친다. `tc` 는 노드 자체를 건드리는 명령이라 `kc-lab-2` 에서 치고, postgres 가 그 노드에 있다. 아래 명령들은 가이드가 실제로 친 한 줄 형태 그대로이므로 `ssh kc-lab-2 '...'` 가 붙어 있다. 코드블록마다 어느 셸인지 붙여 두었다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 터미널은 둘을 연다. 하나는 부하와 측정, 하나는 이벤트 관찰이다.
 
@@ -83,13 +85,13 @@ A-2 는 DB 를 완전히 세웠고 A-4 는 기계를 통째로 껐다. 둘 다 
 
 **지금 치는 명령이 아니다.** 아래 한 줄은 중간에 그만둘 때 치는 것이고, 여기서는 어디 있는지만 봐 둔다. 아직 아무것도 걸지 않았으므로 지금 치면 지울 것이 없다.
 
-```bash label="[kc-lab-1] 중간에 그만둘 때 치는 한 줄 — 읽어만 둔다"
+```bash label="[lab host] 중간에 그만둘 때 치는 한 줄 — 읽어만 둔다"
 ssh kc-lab-2 'sudo tc qdisc del dev flannel.1 root'
 ```
 
 지금 쳐서 확인할 것은 걸린 것이 없다는 쪽이다.
 
-```bash label="[kc-lab-1] 지금 flannel.1 에 무엇이 걸려 있는지 본다"
+```bash label="[lab host] 지금 flannel.1 에 무엇이 걸려 있는지 본다"
 ssh kc-lab-2 'sudo tc qdisc show dev flannel.1'
 ```
 
@@ -111,11 +113,11 @@ ssh kc-lab-2 'sudo tc qdisc show dev flannel.1'
 
 **무엇을 확인하는가** — postgres 와 `keycloak-0` 이 같은 노드이고 `keycloak-1` 만 노드를 건너는지.
 
-```bash label="[kc-lab-1] ① 배치와 IP"
+```bash label="[lab host] ① 배치와 IP"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
-```bash label="[kc-lab-1] ② 뒤에서 계속 쓸 세 값을 셸 변수에 담는다"
+```bash label="[lab host] ② 뒤에서 계속 쓸 세 값을 셸 변수에 담는다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 PG=$(kubectl -n keycloak-lab get pod -l app=postgres -o jsonpath='{.items[0].status.podIP}')
@@ -148,7 +150,7 @@ echo "K0=$K0 K1=$K1 PG=$PG"
 
 **목적** — 같은 요청을 수십 번 반복할 수 있는 파드를 하나 띄우고, 비밀번호를 값으로 찍지 않고 넘긴다.
 
-```bash label="[kc-lab-1] ① 탐침 파드를 띄운다"
+```bash label="[lab host] ① 탐침 파드를 띄운다"
 kubectl -n keycloak-lab run a6-probe --image=curlimages/curl:8.11.1 \
   --restart=Never \
   --env="K0=$K0" --env="K1=$K1" \
@@ -157,11 +159,11 @@ kubectl -n keycloak-lab run a6-probe --image=curlimages/curl:8.11.1 \
   --command -- sleep 1800
 ```
 
-```bash label="[kc-lab-1] ② 뜰 때까지 기다린다"
+```bash label="[lab host] ② 뜰 때까지 기다린다"
 kubectl -n keycloak-lab wait --for=condition=Ready pod/a6-probe --timeout=120s
 ```
 
-```bash label="[kc-lab-1] ③ 값이 아니라 길이만 확인한다"
+```bash label="[lab host] ③ 값이 아니라 길이만 확인한다"
 kubectl -n keycloak-lab exec a6-probe -- sh -c 'echo "K0=$K0 K1=$K1 PW=${#PW}자"'
 ```
 
@@ -179,7 +181,7 @@ K0=10.42.1.77 K1=10.42.0.42 PW=32자
 
 **무엇을 확인하는가** — 시간이 연결에 드는지 첫 바이트까지 드는지.
 
-```bash label="[kc-lab-1] ① 구간별 시간을 함께 찍는다"
+```bash label="[lab host] ① 구간별 시간을 함께 찍는다"
 kubectl -n keycloak-lab exec a6-probe -- sh -c '
   curl -s -o /dev/null \
     -w "connect %{time_connect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
@@ -204,7 +206,7 @@ connect 0.001  ttfb 0.065  total 0.066
 
 **무엇을 확인하는가** — 주입 전 두 노드의 응답 시간.
 
-```bash label="[kc-lab-1] ① keycloak-1 에 20회"
+```bash label="[lab host] ① keycloak-1 에 20회"
 kubectl -n keycloak-lab exec a6-probe -- sh -c '
   rm -f /tmp/base-k1 ; i=0
   while [ $i -lt 20 ]; do
@@ -216,16 +218,16 @@ kubectl -n keycloak-lab exec a6-probe -- sh -c '
   done'
 ```
 
-```bash label="[kc-lab-1] ② 원본을 먼저 본다"
+```bash label="[lab host] ② 원본을 먼저 본다"
 kubectl -n keycloak-lab exec a6-probe -- cat /tmp/base-k1
 ```
 
-```bash label="[kc-lab-1] ③ 그다음 줄여서 본다"
+```bash label="[lab host] ③ 그다음 줄여서 본다"
 kubectl -n keycloak-lab exec a6-probe -- cat /tmp/base-k1 \
   | awk '{s+=$1} END {printf "%d회 평균 %.0f ms\n", NR, s*1000/NR}'
 ```
 
-`$K1` 을 `$K0` 로 바꿔 대조군도 똑같이 잰다.
+`$K1` 을 `$K0` 로 바꿔 대조군도 똑같이 잰다. **`/tmp/base-k1` 이라는 출력 파일 이름도 같이 바꾼다** — ① 은 그 경로에 덮어쓰므로, 변수만 바꾸고 다시 돌리면 `keycloak-1` 에서 잰 20회가 지워지고 `keycloak-0` 의 20회가 그 파일을 차지한다. 화면에는 아무 경고도 안 뜬다. 뒤에서 두 노드의 평균을 견줄 때 `keycloak-1` 쪽이 이미 없다.
 
 **출력에서 답이 되는 것** — 두 노드의 평균이다.
 
@@ -241,7 +243,7 @@ kubectl -n keycloak-lab exec a6-probe -- cat /tmp/base-k1 \
 
 **무엇을 확인하는가** — `agroal_*` 지표의 이름과 지금 값.
 
-```bash label="[kc-lab-1] ① 지표 이름 목록"
+```bash label="[lab host] ① 지표 이름 목록"
 kubectl -n keycloak-lab exec a6-probe -- sh -c \
   'curl -s "http://$K1:9000/metrics" | grep "^agroal_"'
 ```
@@ -280,7 +282,7 @@ agroal_destroy_count_total
 
 **목적** — 인터넷 예제가 전부 쓰는 이름을 그대로 써 보고 무엇이 나오는지 본다.
 
-```bash label="[kc-lab-1] ① 예제 그대로"
+```bash label="[lab host] ① 예제 그대로"
 ssh kc-lab-2 'sudo tc qdisc add dev eth0 root handle 1: prio'
 ```
 
@@ -307,7 +309,7 @@ Cannot find device "eth0"
 
 **문제가 생기면** — 인터페이스 이름을 확인한다.
 
-```bash label="[kc-lab-1] ② 이 게스트에 무엇이 있나"
+```bash label="[lab host] ② 이 게스트에 무엇이 있나"
 ssh kc-lab-2 'ip -brief link'
 ```
 
@@ -356,11 +358,11 @@ Debian 클라우드 이미지는 예측 가능한 인터페이스 이름을 쓴
 
 `enp1s0` 에서 `match ip src 10.42.1.76` 은 절대 일치하지 않는다. 그 IP 는 페이로드 안에 있고 헤더에는 노드 IP 만 있다. 눈으로 확인하는 두 줄을 가이드가 미검증으로 표시했다.
 
-```bash label="[kc-lab-1] ① 미검증 — 물리 쪽에는 노드 IP 만 보인다"
+```bash label="[lab host] ① 미검증 — 물리 쪽에는 노드 IP 만 보인다"
 ssh kc-lab-2 'sudo tcpdump -i enp1s0 -n -c 5 udp port 8472'
 ```
 
-```bash label="[kc-lab-1] ② 미검증 — 터널 쪽에는 파드 IP 가 보인다"
+```bash label="[lab host] ② 미검증 — 터널 쪽에는 파드 IP 가 보인다"
 ssh kc-lab-2 'sudo tcpdump -i flannel.1 -n -c 5 host 10.42.1.76'
 ```
 
@@ -380,22 +382,51 @@ ssh kc-lab-2 'sudo tcpdump -i flannel.1 -n -c 5 host 10.42.1.76'
 
 **목적** — postgres 가 보내는 패킷만 골라 200ms 지연시킨다.
 
+2026-09-17 에 새 실험대에서 이 세 줄을 쳐서 같은 수를 받았다(observed). 넣기 전과 뒤를 같은 명령으로 쟀다.
+
+```text
+넣기 전   200 0.067946s   200 0.064262s
+넣은 뒤   200 1.905504s   200 1.903161s   200 1.860396s   200 1.867929s   200 1.872740s
+되돌린 뒤 200 0.067775s   200 0.043802s   200 0.045763s
+```
+
+**200ms 를 넣었는데 1.87초가 된다.** 문서가 적은 `1,872ms` 와 28배가 그대로 나왔다. 그 사이 `netem` 카운터는 `83 pkt` 이었고, 되돌리자 `qdisc noqueue` 로 돌아가며 시간도 원래대로였다.
+
+시도 ① 과 ② 의 관측도 다시 나왔다(observed).
+
+```text
+sudo tc qdisc add dev eth0 root handle 1: prio   →  Cannot find device "eth0"
+enp1s0 의 헤더        192.168.122.12.53654 > 192.168.122.11.8472: OTV …   ← 노드 IP 뿐
+flannel.1 의 헤더     10.42.0.14.52916 > 10.42.1.29.5432 …                ← 파드 IP 가 보인다
+```
+
+**문서가 미검증으로 둔 세 줄도 전부 돌았다**(observed) — `tcpdump` 두 줄과 `tc filter show`. 필터 목록은 이렇게 나온다.
+
+```text
+filter parent 1: protocol ip pref 3 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 *flowid 1:3 not_in_hw
+  match 0a2a011d/ffffffff at 12
+```
+
+`0a2a011d` 가 `10.42.1.29` 를 16진수로 적은 것이고, 그 값이 지금 postgres 의 IP 와 같은지가 필터가 제 대상을 고르고 있다는 증거다.
+
+**`tcpdump` 에는 시간 제한을 걸어 둔다.** `-c 5` 는 패킷 다섯 개를 받아야 끝나므로, 그 조건에 맞는 트래픽이 없으면 명령이 안 끝난다. `sudo timeout 12 tcpdump …` 로 감싸면 조용한 구간에서도 프롬프트가 돌아온다.
+
 한 줄씩 친다. 앞 줄이 실패하면 뒤 줄은 붙을 곳이 없어서 다른 에러를 낸다.
 
-```bash label="[kc-lab-1] ① 밴드 3개짜리 분류기를 만든다"
+```bash label="[lab host] ① 밴드 3개짜리 분류기를 만든다"
 ssh kc-lab-2 "sudo tc qdisc add dev flannel.1 root handle 1: prio"
 ```
 
-```bash label="[kc-lab-1] ② 3번 밴드에 200ms 지연을 붙인다"
+```bash label="[lab host] ② 3번 밴드에 200ms 지연을 붙인다"
 ssh kc-lab-2 "sudo tc qdisc add dev flannel.1 parent 1:3 handle 30: netem delay 200ms"
 ```
 
-```bash label="[kc-lab-1] ③ 출발지가 postgres 인 패킷을 3번 밴드로 보낸다"
+```bash label="[lab host] ③ 출발지가 postgres 인 패킷을 3번 밴드로 보낸다"
 ssh kc-lab-2 "sudo tc filter add dev flannel.1 protocol ip parent 1:0 prio 3 \
      u32 match ip src $PG/32 flowid 1:3"
 ```
 
-```bash label="[kc-lab-1] ④ 주입 시각"
+```bash label="[lab host] ④ 주입 시각"
 date '+%H:%M:%S 주입'
 ```
 
@@ -438,7 +469,7 @@ date '+%H:%M:%S 주입'
 
 ### 2. 성공한 주입 뒤에는 카운터를 본다
 
-```bash label="[kc-lab-1] ① 넣은 직후의 카운터"
+```bash label="[lab host] ① 넣은 직후의 카운터"
 ssh kc-lab-2 'sudo tc -s qdisc show dev flannel.1'
 ```
 
@@ -453,14 +484,14 @@ qdisc netem 30: parent 1:3 limit 1000 delay 200ms
 
 `Sent 0 pkt` 인데 이것은 실패가 아니다. A-5 에서 `pkts 0` 은 규칙이 안 걸렸다는 뜻이었고, 여기서는 아직 아무 패킷도 지나가지 않았을 뿐이다. postgres 는 요청이 있어야 답하므로 트래픽을 한 번 만든다.
 
-```bash label="[kc-lab-1] ② 요청을 한 번 보낸다"
+```bash label="[lab host] ② 요청을 한 번 보낸다"
 kubectl -n keycloak-lab exec a6-probe -- sh -c '
   curl -s -o /dev/null -w "%{time_total}\n" \
     -X POST "http://$K1:8080/realms/master/protocol/openid-connect/token" \
     -d grant_type=password -d client_id=admin-cli -d username=admin -d "password=$PW"'
 ```
 
-```bash label="[kc-lab-1] ③ 다시 센다"
+```bash label="[lab host] ③ 다시 센다"
 ssh kc-lab-2 'sudo tc -s qdisc show dev flannel.1 | grep -A2 netem'
 ```
 
@@ -482,7 +513,7 @@ ssh kc-lab-2 'sudo tc -s qdisc show dev flannel.1 | grep -A2 netem'
 
 A-1 과 A-5 에서 나온 것과 같은 교훈이 세 번째로 나왔다 — 주입을 넣은 것과 걸린 것은 다르다. 필터 자체를 보는 줄은 가이드가 미검증으로 표시했다.
 
-```bash label="[kc-lab-1] ④ 미검증 — 필터 목록"
+```bash label="[lab host] ④ 미검증 — 필터 목록"
 ssh kc-lab-2 'sudo tc filter show dev flannel.1'
 ```
 
@@ -492,7 +523,7 @@ ssh kc-lab-2 'sudo tc filter show dev flannel.1'
 
 주입 전에 친 것과 똑같은 명령을 다시 친다.
 
-```bash label="[kc-lab-1] ① 구간별 시간"
+```bash label="[lab host] ① 구간별 시간"
 kubectl -n keycloak-lab exec a6-probe -- sh -c '
   curl -s -o /dev/null \
     -w "connect %{time_connect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
@@ -536,7 +567,7 @@ COMMIT
 
 순차로 20번 돌리면 큐잉이 재현되지 않는다. 백그라운드로 띄우고 `wait` 하며, 결과는 파드 안 파일에 모은다.
 
-```bash label="[kc-lab-1] ① 동시 20건"
+```bash label="[lab host] ① 동시 20건"
 kubectl -n keycloak-lab exec a6-probe -- sh -c '
   rm -f /tmp/load ; i=0
   while [ $i -lt 20 ]; do
@@ -549,16 +580,16 @@ kubectl -n keycloak-lab exec a6-probe -- sh -c '
   wait'
 ```
 
-```bash label="[kc-lab-1] ② 다 모였는지부터 센다"
+```bash label="[lab host] ② 다 모였는지부터 센다"
 kubectl -n keycloak-lab exec a6-probe -- cat /tmp/load > /tmp/load.txt
 wc -l /tmp/load.txt
 ```
 
-```bash label="[kc-lab-1] ③ 원본을 본다"
+```bash label="[lab host] ③ 원본을 본다"
 cat /tmp/load.txt
 ```
 
-```bash label="[kc-lab-1] ④ 상태 코드와 시간을 나눠 본다"
+```bash label="[lab host] ④ 상태 코드와 시간을 나눠 본다"
 awk '{print $1}' /tmp/load.txt | sort | uniq -c
 awk '{print $2}' /tmp/load.txt | sort -g
 ```
@@ -591,12 +622,20 @@ awk '{print $2}' /tmp/load.txt | sort -g
 
 순서가 이상하다. `10.5` 가 `3.4` 보다 앞에 있는데 원 실행이 `sort` 를 사전순으로 썼기 때문이다(맨 앞의 `1` 은 `uniq -c` 가 붙인 개수다). 문자열로 정렬하면 `"10.5" < "3.4"` 다.
 
-```bash label="[kc-lab-1] ⑤ 정렬 방식을 갈라 본다"
+```bash label="[lab host] ⑤ 정렬 방식을 갈라 본다"
 sort  /tmp/load.txt      # 사전순 — 10.5 가 3.4 앞에 온다
 sort -g /tmp/load.txt    # 수치순 — 이걸 써야 한다
 ```
 
-시간 값을 정렬할 때는 `sort -g` 를 쓴다. 이걸 놓치면 최대값을 잘못 읽는다. 숫자를 순서대로 놓으면 계단이 된다.
+**원 가이드의 저 처방은 이 파일에서 안 듣는다.** 각 줄이 `200 1.911191` 처럼 전부 같은 `200` 으로 시작해서, `sort -g` 는 줄 앞머리 수치를 비교하다 전부 동률이 되고 마지막에 바이트 순으로 떨어진다. `sort` 와 출력이 똑같다. 정렬할 열을 짚어야 듣는다.
+
+```bash label="[lab host] ⑥ 열을 짚어 다시 정렬한다"
+sort -g -k2 /tmp/load.txt
+```
+
+위 ③ 의 `awk '{print $2}' /tmp/load.txt | sort -g` 도 제대로 돈다 — `awk` 가 둘째 열만 남기기 때문이다. 최대값 하나만 볼 때는 거기에 `| tail -1` 을 붙인다.
+
+시간 값을 정렬할 때는 **열을 짚는다.** 이걸 놓치면 최대값을 잘못 읽고, `sort -g` 를 붙였다는 것만으로 고쳤다고 믿게 된다. 숫자를 순서대로 놓으면 계단이 된다.
 
 ```text
    1.9 → 3.4 → 4.8 → 6.2 → 7.7 → 9.1 → 10.5 → ... → 22.2
@@ -608,7 +647,7 @@ sort -g /tmp/load.txt    # 수치순 — 이걸 써야 한다
 
 ### 3. 커넥션 풀 지표는 부하가 끝나자마자 읽는다
 
-```bash label="[kc-lab-1] ① 부하 직후에 읽는다"
+```bash label="[lab host] ① 부하 직후에 읽는다"
 kubectl -n keycloak-lab exec a6-probe -- sh -c \
   'curl -s "http://$K1:9000/metrics" | grep -E "^agroal_(blocking_time|max_used|acquire|active|available|awaiting)"'
 ```
@@ -642,11 +681,11 @@ histogram_quantile(0.99, rate(http_server_requests_seconds_bucket[5m]))
 
 ### 4. 헬스체크가 같은 줄에 선다
 
-```bash label="[kc-lab-1] ① 최근 이벤트"
+```bash label="[lab host] ① 최근 이벤트"
 kubectl -n keycloak-lab get events --sort-by=.lastTimestamp | tail -20
 ```
 
-```bash label="[kc-lab-1] ② 파드 상태"
+```bash label="[lab host] ② 파드 상태"
 kubectl -n keycloak-lab get pods
 ```
 
@@ -702,7 +741,7 @@ readiness 프로브 자체가 타임아웃됐다. 헬스체크도 같은 커넥
 
 지연 구간의 로그를 세는 줄을 가이드가 미검증으로 표시했다. 원 실행의 정확한 패턴이 기록에 없다.
 
-```bash label="[kc-lab-1] ① 미검증 — 충돌 로그를 센다"
+```bash label="[lab host] ① 미검증 — 충돌 로그를 센다"
 kubectl -n keycloak-lab logs keycloak-1 --since=20m \
   | grep -icE 'optimistic|StaleState|version.*conflict'
 ```
@@ -727,15 +766,15 @@ kubectl -n keycloak-lab logs keycloak-1 --since=20m \
 
 **목적** — `flannel.1` 의 `root` qdisc 를 지워 `prio` 와 `netem` 과 filter 를 한꺼번에 없앤다.
 
-```bash label="[kc-lab-1] ① 해제 시각"
+```bash label="[lab host] ① 해제 시각"
 date '+%H:%M:%S 해제'
 ```
 
-```bash label="[kc-lab-1] ② root 를 지운다"
+```bash label="[lab host] ② root 를 지운다"
 ssh kc-lab-2 'sudo tc qdisc del dev flannel.1 root'
 ```
 
-```bash label="[kc-lab-1] ③ 무엇이 남았는지 본다"
+```bash label="[lab host] ③ 무엇이 남았는지 본다"
 ssh kc-lab-2 'sudo tc qdisc show dev flannel.1'
 ```
 
@@ -775,7 +814,7 @@ keycloak-1                  1/1   Running   1 (52m ago)   3h24m
 
 **문제가 생기면** — 탐침 파드를 지운다.
 
-```bash label="[kc-lab-1] 탐침 파드를 지운다"
+```bash label="[lab host] 탐침 파드를 지운다"
 kubectl -n keycloak-lab delete pod a6-probe --ignore-not-found
 ```
 
@@ -803,7 +842,7 @@ kubectl -n keycloak-lab delete pod a6-probe --ignore-not-found
 | 지연이 양쪽 다 늘었다 | `netem` 을 `root` 에 직접 붙였다 | `prio` + `filter` 로 골라 낸다 |
 | `kubectl` 이나 SSH 까지 느려졌다 | `enp1s0` 에 걸었다 | `tc qdisc del dev enp1s0 root` |
 | 20줄 중 몇 줄만 온다 | `kubectl run --rm -i` 로 동시 실행하면 stdout 이 샌다 | 상주 파드 + 파일 |
-| 최대값이 `9.1` 로 보인다 | `sort` 가 사전순이다 | `sort -g` |
+| 최대값이 `9.1` 로 보인다 | `sort` 가 사전순이고, `sort -g` 만 붙여도 줄이 전부 `200` 으로 시작해 안 듣는다 | `sort -g -k2`, 또는 ③ 의 `awk` 형태 |
 | `blocking_time` 이 0 이다 | 부하가 끝나고 한참 뒤에 읽었다 | 부하 직후에 읽는다 |
 | `awaiting_count` 가 늘 0 이다 | 순간값이다 | 부하가 도는 중에 읽는다 |
 | 로그인이 전부 `401` | `PW` 가 안 넘어갔다 | `exec a6-probe -- sh -c 'echo ${#PW}'` |
diff --git a/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d1-backup-restore.md b/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d1-backup-restore.md
index 5e81406..78d6742 100644
--- a/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d1-backup-restore.md
+++ b/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d1-backup-restore.md
@@ -42,7 +42,11 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 `kc-lab-1` 에서 친다. `kubectl` 에 `sudo` 를 붙이지 않는다 — 가이드가 「kubeconfig 를 사용자 홈에 복사해 뒀다면 `sudo` 는 빼도 된다」고 스스로 괄호를 달아 두었다. 마지막 한 단계만 호스트(`test-server`)로 넘어가고, 거기서는 사람이 비밀번호를 친다.
+명령은 `[lab host]` 에서 친다. `kubectl` 에 `sudo` 를 붙이지 않는다 — 가이드가 「kubeconfig 를 사용자 홈에 복사해 뒀다면 `sudo` 는 빼도 된다」고 스스로 괄호를 달아 두었다. 마지막 한 단계만 호스트(`test-server`)로 넘어가고, 거기서는 사람이 비밀번호를 친다.
+
+**`[kc-lab-1]` 라벨이 붙은 블록은 게스트 셸이다.** lab host 에서 `ssh kc-lab-1` 로 들어가서 치고, 끝나면 `exit` 로 나온다. `ssh kc-lab-2 '…'` 한 줄 형태는 lab host 에서 그대로 쳐도 되므로 `[lab host]` 로 두었다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 | 무엇 | 값 |
 |---|---|
@@ -88,7 +92,7 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 되돌리기는 한 줄이고, 파괴하기 전에 읽어 둔다.
 
-```bash label="[kc-lab-1] 파괴하기 전에 읽어 두는 되돌리기 한 줄"
+```bash label="[lab host] 파괴하기 전에 읽어 두는 되돌리기 한 줄"
 kubectl -n keycloak-lab exec -i deploy/postgres -- psql -U keycloak -d keycloak \
   < /tmp/keycloak-backup.sql
 ```
@@ -107,7 +111,7 @@ kubectl -n keycloak-lab exec -i deploy/postgres -- psql -U keycloak -d keycloak
 
 **무엇을 보는가** — 파드 넷의 상태와 배치.
 
-```bash label="[kc-lab-1] 파드 배치를 본다"
+```bash label="[lab host] 파드 배치를 본다"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
@@ -126,7 +130,7 @@ keycloak-1                     1/1   Running   0     4m38s
 
 **무엇을 보는가** — realm·client·user·세션의 개수. 처음 한 번은 읽는 형태로 친다. 값만 뽑는 형태부터 배우면 `psql` 이 무엇을 돌려주는지 모르게 된다.
 
-```bash label="[kc-lab-1] ① psql 이 무엇을 돌려주는지 한 번 본다"
+```bash label="[lab host] ① psql 이 무엇을 돌려주는지 한 번 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select count(*) from realm"
 ```
@@ -144,7 +148,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 이제 넷을 한 줄로 모은다. 비교할 값이 필요할 때만 이 형태를 쓴다.
 
-```bash label="[kc-lab-1] ② 대조할 한 줄을 뽑는다"
+```bash label="[lab host] ② 대조할 한 줄을 뽑는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select (select count(*) from realm), (select count(*) from client),
           (select count(*) from user_entity),
@@ -165,7 +169,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tA
 
 **무엇을 보는가** — 질문 ①의 재료. 세션 행이 실제로 테이블에 있어야 덤프에 들어갈 것이 있다.
 
-```bash label="[kc-lab-1] 세션 행을 나열한다"
+```bash label="[lab host] 세션 행을 나열한다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select user_session_id, offline_flag, realm_id from offline_user_session"
 ```
@@ -189,13 +193,13 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **무엇을 보는가** — 정문과 app1 의 응답. 처음 한 번은 응답을 읽는다.
 
-```bash label="[kc-lab-1] ① 헤더를 통째로 본다"
+```bash label="[lab host] ① 헤더를 통째로 본다"
 curl -I https://auth.hyeonworks.com/realms/master
 ```
 
 헤더가 통째로 나온다. `HTTP/2 200`, `content-type: application/json` 을 본다. 같은 것을 반복해서 재고 비교할 때만 코드만 뽑는다.
 
-```bash label="[kc-lab-1] ② 코드만 뽑아 둘을 잰다"
+```bash label="[lab host] ② 코드만 뽑아 둘을 잰다"
 curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master
 curl -s -o /dev/null -w '%{http_code}\n' https://app1.hyeonworks.com/
 ```
@@ -215,7 +219,7 @@ curl -s -o /dev/null -w '%{http_code}\n' https://app1.hyeonworks.com/
 
 ① 시각을 남기고 덤프를 뜬다.
 
-```bash label="[kc-lab-1] ① 시각과 함께 덤프를 뜬다"
+```bash label="[lab host] ① 시각과 함께 덤프를 뜬다"
 date '+%H:%M:%S 백업 시작'
 kubectl -n keycloak-lab exec deploy/postgres -- pg_dump -U keycloak -d keycloak \
   --clean --if-exists > /tmp/keycloak-backup.sql
@@ -243,7 +247,7 @@ date '+%H:%M:%S 백업 완료'
 
 **문제가 생기면** — 이 단계는 읽기만 하므로 파일이 마음에 안 들면 지우고 다시 뜬다.
 
-```bash label="[kc-lab-1] 덤프가 마음에 안 들면 지우고 다시 뜬다"
+```bash label="[lab host] 덤프가 마음에 안 들면 지우고 다시 뜬다"
 rm -f /tmp/keycloak-backup.sql
 ```
 
@@ -253,7 +257,7 @@ rm -f /tmp/keycloak-backup.sql
 
 ① 크기와 줄 수.
 
-```bash label="[kc-lab-1] ① 크기와 줄 수"
+```bash label="[lab host] ① 크기와 줄 수"
 ls -l /tmp/keycloak-backup.sql
 wc -l /tmp/keycloak-backup.sql
 ```
@@ -266,7 +270,7 @@ wc -l /tmp/keycloak-backup.sql
 
 ② 테이블 수.
 
-```bash label="[kc-lab-1] ② 덤프 안의 테이블 수"
+```bash label="[lab host] ② 덤프 안의 테이블 수"
 grep -c '^CREATE TABLE' /tmp/keycloak-backup.sql
 ```
 
@@ -280,7 +284,7 @@ grep -c '^CREATE TABLE' /tmp/keycloak-backup.sql
 
 ③ 끝까지 쓰였는가.
 
-```bash label="[kc-lab-1] ③ 마지막 세 줄"
+```bash label="[lab host] ③ 마지막 세 줄"
 tail -3 /tmp/keycloak-backup.sql
 ```
 
@@ -296,7 +300,7 @@ tail -3 /tmp/keycloak-backup.sql
 
 ④ 세션이 들어갔는가. 이것이 질문 ① 자체다.
 
-```bash label="[kc-lab-1] ④ COPY 블록에 세션 행이 붙어 있는가"
+```bash label="[lab host] ④ COPY 블록에 세션 행이 붙어 있는가"
 grep -c 'offline_user_session' /tmp/keycloak-backup.sql
 grep -A3 'COPY public.offline_user_session' /tmp/keycloak-backup.sql | cut -c1-110
 ```
@@ -320,7 +324,7 @@ grep -A3 'COPY public.offline_user_session' /tmp/keycloak-backup.sql | cut -c1-1
 
 **무엇을 보는가** — 파일의 경로와 그 파일이 올라앉은 디스크.
 
-```bash label="[kc-lab-1] 덤프의 경로와 디스크를 본다"
+```bash label="[lab host] 덤프의 경로와 디스크를 본다"
 ls -l /tmp/keycloak-backup.sql
 df -h /tmp
 ```
@@ -337,7 +341,7 @@ df -h /tmp
 
 ① 시각을 남기고 친다.
 
-```bash label="[kc-lab-1] ① 시각을 남기고 스키마를 지운다"
+```bash label="[lab host] ① 시각을 남기고 스키마를 지운다"
 date '+%H:%M:%S 파괴'
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"
@@ -362,12 +366,12 @@ CREATE SCHEMA
 
 결과를 해석하기 전에, 의도한 것만 지워졌는지 먼저 본다.
 
-```bash label="[kc-lab-1] ① 남은 테이블을 센다"
+```bash label="[lab host] ① 남은 테이블을 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select count(*) from pg_tables where schemaname='public'"
 ```
 
-이 실험대는 스크립트로 셌고(observed), 위 형태는 가이드가 미검증으로 표시한 줄이다(unknown). 결과는 이렇다(observed).
+이 실험대는 스크립트로 셌고(observed), **위 형태도 2026-09-17 에 쳐서 `0` 을 받았다**(observed). 결과는 이렇다(observed).
 
 ```text
   남은 테이블: 0
@@ -377,7 +381,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 애플리케이션 테이블이 정말 없는지 직접 물어본다.
 
-```bash label="[kc-lab-1] ② 테이블에 직접 물어본다"
+```bash label="[lab host] ② 테이블에 직접 물어본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select count(*) from realm"
 ```
@@ -394,7 +398,7 @@ LINE 1: select count(*) from realm
 
 **그런데 밖은 멀쩡하다.**
 
-```bash label="[kc-lab-1] ③ 파드와 밖에서 본 상태를 다시 잰다"
+```bash label="[lab host] ③ 파드와 밖에서 본 상태를 다시 잰다"
 kubectl -n keycloak-lab get pods -o wide
 curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master
 curl -s -o /dev/null -w '%{http_code}\n' https://app1.hyeonworks.com/
@@ -413,9 +417,9 @@ keycloak-1                     1/1   Running   0     4m38s
 
 엉뚱한 것을 죽이지 않았는지도 본다.
 
-```bash label="[kc-lab-1] ④ Service 에서 빠진 파드가 있는가"
+```bash label="[lab host] ④ Service 에서 빠진 파드가 있는가"
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 ```
 
 ready 주소가 여전히 둘이다. 아무 파드도 Service 에서 빠지지 않았다. A-2 에서는 여기가 빈 목록이었다. `kubectl get endpoints` 는 v1.33+ 에서 deprecated 이고, 이 실험대에서 실제로 그 경고를 봤다.
@@ -424,7 +428,7 @@ ready 주소가 여전히 둘이다. 아무 파드도 Service 에서 빠지지 
 
 여기까지의 주입 검증은 쉽게 통과한다. 어려운 확인은 반대편에 있다. 복구 명령에서 `-i` 를 빠뜨리면 파드 안의 `psql` 이 빈 입력을 받고 정상 종료하고, 셸은 오류를 내지 않고, 종료 코드도 0 이며, `date` 두 줄은 「1초 만에 끝났다」로 찍힌다. 복구된 것과 구별되지 않는다.
 
-```bash label="[kc-lab-1] 치지 않는다 — -i 가 있는 줄과 없는 줄을 눈으로 견준다"
+```bash label="[lab host] 치지 않는다 — -i 가 있는 줄과 없는 줄을 눈으로 견준다"
 kubectl -n keycloak-lab exec    deploy/postgres -- psql ... < dump.sql   # ✘
 kubectl -n keycloak-lab exec -i deploy/postgres -- psql ... < dump.sql   # ✔
 ```
@@ -435,7 +439,7 @@ kubectl -n keycloak-lab exec -i deploy/postgres -- psql ... < dump.sql   # ✔
 
 **전부 깨지지는 않는다.** 세 경로를 나눠서 친다.
 
-```bash label="[kc-lab-1] ① 두 경로를 잰다"
+```bash label="[lab host] ① 두 경로를 잰다"
 curl -s -o /dev/null -w 'certs      %{http_code}\n' \
   https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/certs
 curl -s -o /dev/null -w 'well-known %{http_code}\n' \
@@ -452,7 +456,7 @@ curl -s -o /dev/null -w 'well-known %{http_code}\n' \
 
 토큰 발급은 값이 필요하므로 따로 친다. 이 실험대는 스크립트로 돌렸고(observed), 아래는 가이드가 미검증으로 표시한 형태다(unknown).
 
-```bash label="[kc-lab-1] ② 토큰 발급을 잰다"
+```bash label="[lab host] ② 토큰 발급을 잰다"
 curl -s -o /dev/null -w '토큰 %{http_code}\n' -X POST \
   https://auth.hyeonworks.com/realms/master/protocol/openid-connect/token \
   -d grant_type=password -d client_id=admin-cli -d username=admin \
@@ -462,7 +466,7 @@ curl -s -o /dev/null -w '토큰 %{http_code}\n' -X POST \
 
 **비밀번호를 화면에 찍지 않는다.** 명령 치환으로 넘기므로 값은 터미널에도 셸 히스토리에도 남지 않는다. 길이만 확인하려면 한 줄을 더 친다.
 
-```bash label="[kc-lab-1] ③ 값이 아니라 길이만 잰다"
+```bash label="[lab host] ③ 값이 아니라 길이만 잰다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets \
   -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d | wc -c
 ```
@@ -479,7 +483,7 @@ kubectl -n keycloak-lab get secret keycloak-lab-secrets \
 
 로그가 이유를 말한다.
 
-```bash label="[kc-lab-1] ④ Keycloak 로그를 읽는다"
+```bash label="[lab host] ④ Keycloak 로그를 읽는다"
 kubectl -n keycloak-lab logs keycloak-0 --tail=50
 ```
 
@@ -516,7 +520,7 @@ kubectl -n keycloak-lab logs keycloak-0 --tail=50
 
 ① 시각을 남기고 복구한다. `-i` 가 있는지 치기 전에 눈으로 확인한다.
 
-```bash label="[kc-lab-1] ① 시각과 함께 덤프를 되돌린다"
+```bash label="[lab host] ① 시각과 함께 덤프를 되돌린다"
 date '+%H:%M:%S 복구 시작'
 kubectl -n keycloak-lab exec -i deploy/postgres -- psql -U keycloak -d keycloak \
   < /tmp/keycloak-backup.sql > /tmp/restore.log 2>&1
@@ -533,7 +537,7 @@ date '+%H:%M:%S 복구 완료'
 
 ② 로그의 오류를 센다.
 
-```bash label="[kc-lab-1] ② 복구 로그의 오류를 센다"
+```bash label="[lab host] ② 복구 로그의 오류를 센다"
 grep -ci '^ERROR' /tmp/restore.log
 tail -5 /tmp/restore.log
 ```
@@ -542,6 +546,20 @@ tail -5 /tmp/restore.log
 
 **왜 필요한가** — 시각 두 줄과 오류 0건은 `-i` 를 빠뜨렸을 때도 똑같이 나온다. 그래서 이 둘로는 복구를 판정하지 않는다.
 
+**2026-09-17 에 이 절차를 처음부터 끝까지 쳤다**(observed).
+
+```text
+덤프        101 테이블 · 976873 bytes · 8569 줄
+파괴 15:31:02   DROP SCHEMA · CREATE SCHEMA → 남은 테이블 0 · select count(*) from realm 이 relation does not exist
+그동안 밖에서는  200   ← 스키마가 통째로 없는데 정문은 멀쩡했다
+복구 15:31:02 → 15:31:08 (6초) · 복구 로그 ERROR 0
+복구 뒤      101 테이블 · 세션 6건  — 파괴 전과 같다
+```
+
+**크기와 줄 수는 실험대마다 다르다.** 위 실측의 `394945 bytes · 6956 줄` 은 그 실험대의 값이고, BFF 쪽 테이블이 있는 이 실험대에서는 `976873 bytes · 8569 줄` 이었다. **같아야 하는 것은 테이블 수 `101` 과 복구 전후의 행 수**다.
+
+**스키마가 없는 동안에도 정문이 `200` 인 것이 이 편의 핵심이다.** Keycloak 은 이미 읽어 둔 것으로 답하므로, 밖에서 보는 코드만으로는 데이터베이스가 통째로 비었다는 것을 알 수 없다.
+
 **문제가 생기면** — 1초 만에 끝났는데 다음 단계의 대조가 어긋나면 `-i` 를 의심한다.
 
 ### 2. 진짜 판정 — 주입 전과 문자 단위로 견준다
@@ -550,7 +568,7 @@ tail -5 /tmp/restore.log
 
 ① 주입 전에 친 것과 똑같은 명령을 친다.
 
-```bash label="[kc-lab-1] ① 대조할 한 줄을 다시 뽑는다"
+```bash label="[lab host] ① 대조할 한 줄을 다시 뽑는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select (select count(*) from realm), (select count(*) from client),
           (select count(*) from user_entity),
@@ -574,7 +592,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tA
 
 ① 15초쯤 뒤에 본다.
 
-```bash label="[kc-lab-1] ① 15초 뒤에 다시 잰다"
+```bash label="[lab host] ① 15초 뒤에 다시 잰다"
 curl -s -o /dev/null -w 'well-known %{http_code}\n' \
   https://auth.hyeonworks.com/realms/keycloak-patterns/.well-known/openid-configuration
 kubectl -n keycloak-lab get pods -o wide | grep keycloak
@@ -598,7 +616,7 @@ kubectl -n keycloak-lab get pods -o wide | grep keycloak
 
 ① 세션 행을 다시 나열한다. **주입 전 §3 에서 친 것과 열이 하나 다르다** — 거기는 `realm_id` 까지 셋을 뽑고 여기는 `user_session_id` 와 `offline_flag` 둘만 뽑는다. 가이드 원문이 그렇게 갈려 있어 그대로 싣는다. 열이 다르므로 행 수와 `user_session_id` 값으로 견준다.
 
-```bash label="[kc-lab-1] ① 세션 행을 다시 나열한다"
+```bash label="[lab host] ① 세션 행을 다시 나열한다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select user_session_id, offline_flag from offline_user_session"
 ```
diff --git a/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d2-version-upgrade.md b/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d2-version-upgrade.md
index 69707ad..0bdf4bf 100644
--- a/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d2-version-upgrade.md
+++ b/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d2-version-upgrade.md
@@ -45,7 +45,9 @@ databasechangelog 행 수를 먼저 세고 이미지 태그를 정방향·롤백
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 `kc-lab-1` 에서 친다. `kubectl` 에 `sudo` 를 붙이지 않는다. 호스트로 넘어가는 단계가 없어 전 구간을 게스트 안에서 끝낸다. 터미널을 두 개 열어 두면 편하다 — 하나는 가용성 폴링용, 하나는 관찰용이다.
+명령은 `[lab host]` 에서 친다. `kubectl` 에 `sudo` 를 붙이지 않는다. 호스트로 넘어가는 단계가 없어 전 구간을 게스트 안에서 끝낸다. 터미널을 두 개 열어 두면 편하다 — 하나는 가용성 폴링용, 하나는 관찰용이다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 | 무엇 | 값 |
 |---|---|
@@ -100,7 +102,7 @@ Keycloak 은 Liquibase 로 스키마를 관리한다. 적용한 변경 하나하
 
 되돌리기는 전부 태그 한 줄이고, 각 단계 앞에서 먼저 읽는다.
 
-```bash label="[kc-lab-1] 단계마다 먼저 읽어 두는 되돌리기 한 줄"
+```bash label="[lab host] 단계마다 먼저 읽어 두는 되돌리기 한 줄"
 kubectl -n keycloak-lab set image statefulset/keycloak \
   keycloak=quay.io/keycloak/keycloak:26.7.0
 ```
@@ -121,7 +123,7 @@ kubectl -n keycloak-lab set image statefulset/keycloak \
 
 ① 덤프를 뜨고 끝까지 쓰였는지 본다.
 
-```bash label="[kc-lab-1] ① 덤프를 뜨고 마지막 세 줄을 본다"
+```bash label="[lab host] ① 덤프를 뜨고 마지막 세 줄을 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- pg_dump -U keycloak -d keycloak \
   --clean --if-exists > /tmp/pre-upgrade.sql
 ls -l /tmp/pre-upgrade.sql
@@ -145,7 +147,7 @@ tail -3 /tmp/pre-upgrade.sql
 
 **무엇을 보는가** — StatefulSet 에 적힌 태그.
 
-```bash label="[kc-lab-1] ① StatefulSet 의 태그를 본다"
+```bash label="[lab host] ① StatefulSet 의 태그를 본다"
 kubectl -n keycloak-lab get statefulset keycloak \
   -o jsonpath='{.spec.template.spec.containers[0].image}'; echo
 ```
@@ -158,19 +160,28 @@ quay.io/keycloak/keycloak:26.7.0
 
 **이 값이 뜻하는 것** — `latest` 로 되어 있으면 무엇에서 무엇으로 가는지 말할 수 없기 때문에 이 실험이 성립하지 않는다. 그리고 StatefulSet 에 적힌 것과 파드가 실제로 돌리고 있는 것은 다를 수 있다 — 적용 중이거나 롤아웃이 멈춰 있으면 그렇다.
 
-```bash label="[kc-lab-1] ② 파드가 실제로 돌리는 이미지를 본다"
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready,\
-RESTARTS:.status.containerStatuses[0].restartCount | grep keycloak
+```bash label="[lab host] ② 파드가 실제로 돌리는 이미지를 본다"
+kubectl -n keycloak-lab get pods \
+  -o "custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount" \
+  | grep keycloak
 ```
 
 두 파드의 `IMAGE` 가 서로 같고 StatefulSet 과도 같은지, `READY` 가 둘 다 `true`, `RESTARTS` 가 `0` 인지를 본다.
 
+**`grep keycloak` 은 BFF 파드도 잡는다.** B층을 먼저 밟아 `keycloak-pattern-bff` 가 떠 있으면 그 두 줄이 같이 나온다(2026-09-17, observed). 이 편이 보려는 것은 Keycloak 파드 둘이므로 라벨로 거르는 편이 낫다.
+
+```bash label="[lab host] ②b 라벨로 걸러 Keycloak 파드만 본다"
+kubectl -n keycloak-lab get pods -l app=keycloak \
+  -o "custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount"
+```
+
+**`-o` 값을 따옴표로 묶고 한 줄로 둔다.** 묶지 않으면 zsh 가 `[0]` 을 글로브로 읽어 명령이 아예 안 돌고, 중간에서 줄을 접으면 따옴표가 먼저 닫혀 뒤쪽 칸이 명령 인자로 떨어진다.
+
 ### 3. 마이그레이션 수 — 이 실험의 전부다
 
 **무엇을 보는가** — `databasechangelog` 의 행 수. 처음 한 번은 읽는 형태로 친다.
 
-```bash label="[kc-lab-1] ① psql 이 무엇을 돌려주는지 한 번 본다"
+```bash label="[lab host] ① psql 이 무엇을 돌려주는지 한 번 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select count(*) from databasechangelog"
 ```
@@ -186,7 +197,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 비교용으로 값만 뽑는 형태도 익혀 둔다.
 
-```bash label="[kc-lab-1] ② 값만 뽑는 형태"
+```bash label="[lab host] ② 값만 뽑는 형태"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select count(*) from databasechangelog"
 ```
@@ -199,7 +210,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tA
 
 **이 값을 화면 밖에 적어 둔다.** 무엇이 마지막으로 적용됐는지도 한 번 본다. 나중에 「스키마가 언제 움직였나」를 물을 때 여기를 본다. 이 실험대는 개수만 셌고(observed), 아래는 가이드가 미검증으로 표시한 형태다(unknown).
 
-```bash label="[kc-lab-1] ③ 마지막 다섯 줄을 본다 (미검증)"
+```bash label="[lab host] ③ 마지막 다섯 줄을 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select id, author, orderexecuted, dateexecuted from databasechangelog
       order by orderexecuted desc limit 5"
@@ -211,7 +222,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **무엇을 보는가** — 판올림이 세션을 건드리는지 판정할 재료.
 
-```bash label="[kc-lab-1] 세션 수를 센다"
+```bash label="[lab host] 세션 수를 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select count(*) from offline_user_session"
 ```
@@ -229,7 +240,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tA
 
 **무엇을 보는가** — 멤버 수와 괄호 안의 판 번호.
 
-```bash label="[kc-lab-1] 클러스터 뷰 마지막 줄을 본다"
+```bash label="[lab host] 클러스터 뷰 마지막 줄을 본다"
 kubectl -n keycloak-lab logs keycloak-0 | grep ISPN000094 | tail -1
 ```
 
@@ -245,13 +256,13 @@ kubectl -n keycloak-lab logs keycloak-0 | grep ISPN000094 | tail -1
 
 **무엇을 보는가** — 올라갈 곳이 실제로 있는가. 처음 한 번은 응답을 그대로 본다.
 
-```bash label="[kc-lab-1] ① 응답을 통째로 본다"
+```bash label="[lab host] ① 응답을 통째로 본다"
 curl -s "https://quay.io/api/v1/repository/keycloak/keycloak/tag/?limit=40&onlyActiveTags=true"
 ```
 
 한 줄짜리 JSON 이 통째로 나온다. 어떤 필드가 있는지 보고 나서 자른다. 이 실험대는 `jq` 가 없어 이렇게 읽었고(observed), 가이드가 그 줄을 미검증으로 표시했다(unknown).
 
-```bash label="[kc-lab-1] ② 이름만 잘라 본다 (미검증)"
+```bash label="[lab host] ② 이름만 잘라 본다 (미검증)"
 curl -s "https://quay.io/api/v1/repository/keycloak/keycloak/tag/?limit=40&onlyActiveTags=true" \
   | tr ',' '\n' | grep '"name"'
 ```
@@ -264,7 +275,7 @@ curl -s "https://quay.io/api/v1/repository/keycloak/keycloak/tag/?limit=40&onlyA
 
 ① 1초 간격으로 150회, 뒤에서 돌린다.
 
-```bash label="[kc-lab-1] ① 폴링을 뒤에서 돌린다"
+```bash label="[lab host] ① 폴링을 뒤에서 돌린다"
 ( for i in $(seq 1 150); do
     printf '%s ' "$(curl -s -o /dev/null -w '%{http_code}' --max-time 3 \
       https://auth.hyeonworks.com/realms/master)"
@@ -274,7 +285,7 @@ curl -s "https://quay.io/api/v1/repository/keycloak/keycloak/tag/?limit=40&onlyA
 
 그만 재려면 `kill %1` 이다. **`&` 로 붙인 작업은 그것을 띄운 창의 것이라 `kill %1` 도 그 창에서만 듣는다.** 그래서 이 한 줄은 폴링용 창에서 치고, 아래 ② 부터 관찰 절까지는 다른 창에서 친다. 두 창 다 `kc-lab-1` 이다. 30초쯤 두고 먼저 평시를 센다.
 
-```bash label="[kc-lab-1] ② 평시 응답 코드를 센다"
+```bash label="[lab host] ② 평시 응답 코드를 센다"
 tr ' ' '\n' < /tmp/d2-avail.txt | grep -c 200
 tr ' ' '\n' < /tmp/d2-avail.txt | sort | uniq -c
 ```
@@ -293,7 +304,7 @@ tr ' ' '\n' < /tmp/d2-avail.txt | sort | uniq -c
 
 ① 시각을 남기고 태그를 바꾼다.
 
-```bash label="[kc-lab-1] ① 시각을 남기고 태그를 바꾼다"
+```bash label="[lab host] ① 시각을 남기고 태그를 바꾼다"
 date '+%H:%M:%S 태그 변경'
 kubectl -n keycloak-lab set image statefulset/keycloak \
   keycloak=quay.io/keycloak/keycloak:26.7.3
@@ -310,7 +321,7 @@ statefulset.apps/keycloak image updated
 
 ② 롤아웃을 기다린다.
 
-```bash label="[kc-lab-1] ② 롤아웃을 기다린다"
+```bash label="[lab host] ② 롤아웃을 기다린다"
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=600s
 date '+%H:%M:%S 롤아웃 완료'
 ```
@@ -332,10 +343,10 @@ partitioned roll out complete: 2 new pods have been updated...
 
 결과를 해석하기 전에, 주입이 의도한 것을 정확히 했는지 먼저 본다.
 
-```bash label="[kc-lab-1] ① 파드가 새 이미지를 돌리는가"
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready,\
-RESTARTS:.status.containerStatuses[0].restartCount | grep keycloak
+```bash label="[lab host] ① 파드가 새 이미지를 돌리는가"
+kubectl -n keycloak-lab get pods \
+  -o "custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount" \
+  | grep keycloak
 ```
 
 실측은 이렇다(observed, `followup/01-d2-forward-upgrade.txt`).
@@ -350,7 +361,7 @@ quay.io/keycloak/keycloak:26.7.3
 
 실제로 새 파드인지는 나이로 본다.
 
-```bash label="[kc-lab-1] ② 나이로 새 파드인지 본다"
+```bash label="[lab host] ② 나이로 새 파드인지 본다"
 kubectl -n keycloak-lab get pods -o wide | grep keycloak
 ```
 
@@ -365,7 +376,7 @@ keycloak-1                     1/1   Running   0     28s
 
 버전은 파드가 자기 입으로 말하게 한다.
 
-```bash label="[kc-lab-1] ③ 로그가 말하는 판을 본다"
+```bash label="[lab host] ③ 로그가 말하는 판을 본다"
 kubectl -n keycloak-lab logs keycloak-0 | grep -i 'Keycloak 26' | tail -1
 ```
 
@@ -379,9 +390,26 @@ kubectl -n keycloak-lab logs keycloak-0 | grep -i 'Keycloak 26' | tail -1
 
 ## 관찰
 
+**2026-09-17 에 세 번을 이어서 쳤다**(observed). 네 값이 이 편의 판정 전부다.
+
+| 언제 | 무엇 | 파드 | `databasechangelog` | 정문 |
+|---|---|---|---|---|
+| `15:32:15` → `15:33:40` (85초) | 26.7.0 → **26.7.3** | 둘 다 `true` · `RESTARTS 0` | 210 → **210** | 200 |
+| `15:33:48` → `15:34:55` (67초) | 26.7.3 → **26.7.0** (롤백) | 둘 다 `true` · `RESTARTS 0` | **210** | 200 |
+| `15:34:55` | 26.7.0 → **26.0** (역방향) | `keycloak-1` 만 `false` · `RESTARTS 2` | **210** | **200** |
+
+**스키마가 한 번도 안 움직였다.** `orderexecuted` 210 의 `26.7.0-cluster-event` 이 끝까지 마지막 줄이었다. 패치 판올림이라 롤백이 막히지 않은 것이고, 역방향이 막힌 까닭은 판올림이 남긴 스키마가 아니라 **체크섬**이다.
+
+```text
+liquibase.exception.ValidationFailedException: Validation Failed:
+     1 changesets check sum
+```
+
+**그런데 정문은 세 번 내내 `200` 이었다.** StatefulSet 이 파드를 하나씩 갈아 끼우고 `keycloak-0` 이 26.7.0 에 남아 있었기 때문이다. **한 파드가 `CrashLoopBackOff` 인데 밖에서는 아무 일도 없어 보인다** — 이 층이 「조용한 실패」라고 부르는 것이 이 모양이다. 실패한 기동은 스키마도 안 건드렸다(210 그대로).
+
 ### 1. 정방향은 무중단이었는가
 
-```bash label="[kc-lab-1] 폴링 결과를 센다"
+```bash label="[lab host] 폴링 결과를 센다"
 tr ' ' '\n' < /tmp/d2-avail.txt | sort | uniq -c
 ```
 
@@ -402,7 +430,7 @@ tr ' ' '\n' < /tmp/d2-avail.txt | sort | uniq -c
 
 주입 전에 친 것과 똑같은 명령이다.
 
-```bash label="[kc-lab-1] 마이그레이션 수를 다시 센다"
+```bash label="[lab host] 마이그레이션 수를 다시 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select count(*) from databasechangelog"
 ```
@@ -431,7 +459,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tA
 
 ⓪ §1 에서 센 `200 응답: 87 회 / 비200: 0` 을 먼저 손으로 적어 둔다. 루프가 `>` 로 파일을 잘라 쓰기 때문에 다시 띄우면 그 값은 화면에서 사라진다. 폴링 창에서 `jobs` 를 쳐 아직 돌고 있으면 `kill %1` 로 멈춘 뒤, 같은 창에서 친다.
 
-```bash label="[kc-lab-1] ⓪ 폴링 창에서 다시 띄운다"
+```bash label="[lab host] ⓪ 폴링 창에서 다시 띄운다"
 ( for i in $(seq 1 150); do
     printf '%s ' "$(curl -s -o /dev/null -w '%{http_code}' --max-time 3 \
       https://auth.hyeonworks.com/realms/master)"
@@ -441,7 +469,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tA
 
 ① 시각을 남기고 태그를 내린다.
 
-```bash label="[kc-lab-1] ① 태그를 26.7.0 으로 되돌린다"
+```bash label="[lab host] ① 태그를 26.7.0 으로 되돌린다"
 date '+%H:%M:%S 롤백'
 kubectl -n keycloak-lab set image statefulset/keycloak \
   keycloak=quay.io/keycloak/keycloak:26.7.0
@@ -466,7 +494,7 @@ partitioned roll out complete: 2 new pods have been updated...
 
 ### 4. 전환 순간의 000 을 읽는다
 
-```bash label="[kc-lab-1] 비200 이 어디에 있는지 본다"
+```bash label="[lab host] 비200 이 어디에 있는지 본다"
 tr ' ' '\n' < /tmp/d2-avail.txt | sort | uniq -c
 grep -n '000' /tmp/d2-avail.txt
 ```
@@ -497,7 +525,7 @@ grep -n '000' /tmp/d2-avail.txt
 
 ① 시각을 남기고 26.0 으로 내린다.
 
-```bash label="[kc-lab-1] ① 26.0 으로 내린다"
+```bash label="[lab host] ① 26.0 으로 내린다"
 date '+%H:%M:%S 26.0 으로 내린다'
 kubectl -n keycloak-lab set image statefulset/keycloak \
   keycloak=quay.io/keycloak/keycloak:26.0
@@ -505,7 +533,7 @@ kubectl -n keycloak-lab set image statefulset/keycloak \
 
 ② 이번에는 `rollout status` 로 기다리지 말고 눈으로 본다.
 
-```bash label="[kc-lab-1] ② 파드 상태를 눈으로 따라간다"
+```bash label="[lab host] ② 파드 상태를 눈으로 따라간다"
 kubectl -n keycloak-lab get pods -w
 ```
 
@@ -532,7 +560,7 @@ statefulset.apps/keycloak image updated
 
 ### 6. 왜 실패했는지 물어본다
 
-```bash label="[kc-lab-1] ① Liquibase 관련 줄만 뽑는다"
+```bash label="[lab host] ① Liquibase 관련 줄만 뽑는다"
 kubectl -n keycloak-lab logs keycloak-1 | grep -iE 'liquibase|changeset|validation'
 ```
 
@@ -547,16 +575,16 @@ kubectl -n keycloak-lab logs keycloak-1 | grep -iE 'liquibase|changeset|validati
 
 `1 changesets check sum` 이고 개수가 1이다. 26.7.0 이 적용한 changeset 하나를 26.0 도 알고 있는데 정의가 다르다. 같은 changeset 이 버전 사이에 수정됐고, Liquibase 는 스키마를 반쯤 아는 상태로 서비스하느니 기동 자체를 거부한다.
 
-```bash label="[kc-lab-1] ② 파드가 이미 죽었으면 직전 로그를 본다"
+```bash label="[lab host] ② 파드가 이미 죽었으면 직전 로그를 본다"
 kubectl -n keycloak-lab logs keycloak-1 --previous
 ```
 
 ### 7. 그런데 서비스는 살아 있다
 
-```bash label="[kc-lab-1] 밖과 Service 와 StatefulSet 을 함께 본다"
+```bash label="[lab host] 밖과 Service 와 StatefulSet 을 함께 본다"
 curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 kubectl -n keycloak-lab get statefulset keycloak
 ```
 
@@ -587,7 +615,7 @@ A-8 에서 「무중단은 replica ≥ 2 와 readiness 의 조합」이라고 
 
 같은 명령을 세 번째로 친다.
 
-```bash label="[kc-lab-1] 마이그레이션 수를 세 번째로 센다"
+```bash label="[lab host] 마이그레이션 수를 세 번째로 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select count(*) from databasechangelog"
 ```
@@ -632,7 +660,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tA
 
 ① 시각을 남기고 태그를 되돌린 뒤 롤아웃을 기다린다.
 
-```bash label="[kc-lab-1] ① 태그를 되돌리고 롤아웃을 기다린다"
+```bash label="[lab host] ① 태그를 되돌리고 롤아웃을 기다린다"
 date '+%H:%M:%S 복귀'
 kubectl -n keycloak-lab set image statefulset/keycloak \
   keycloak=quay.io/keycloak/keycloak:26.7.0
@@ -686,7 +714,7 @@ keycloak-1                     1/1   Running   0     28s
 
 **업그레이드 전 행 수를 안 적었을 때**는 덤프 안에 그 테이블이 통째로 들어 있다. 가이드가 미검증으로 표시한 줄이다(unknown).
 
-```bash label="[kc-lab-1] 덤프에서 행 수를 되찾는다 (미검증)"
+```bash label="[lab host] 덤프에서 행 수를 되찾는다 (미검증)"
 sed -n '/^COPY public.databasechangelog /,/^\\\.$/p' /tmp/pre-upgrade.sql | wc -l
 ```
 
diff --git a/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d3-secret-exposure.md b/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d3-secret-exposure.md
index 53ea1c1..1056070 100644
--- a/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d3-secret-exposure.md
+++ b/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d3-secret-exposure.md
@@ -41,9 +41,24 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 `kc-lab-1` 에서 친다. k3s 서버의 저장 파일도 이 노드에 있어서 디스크를 보는 경로를 여기서 칠 수 있다. 게스트(`kc-lab-1`/`kc-lab-2`)의 `sudo` 는 무암호이고, 호스트와 다르다.
+**기계가 둘이다.** `kubectl` 은 `[lab host]` 에서 치고, k3s 서버의 저장 파일을 들여다보는 `k3s`·`ls`·`grep`·`strings` 는 그 파일이 있는 `[kc-lab-1]` 에서 친다. 게스트(`kc-lab-1`/`kc-lab-2`)의 `sudo` 는 무암호이고, 호스트와 다르다.
 
-가이드의 전제는 「`kubectl` 은 `sudo` 로 쓴다」인데 본문의 `kubectl` 줄에는 `sudo` 가 없고 `k3s`·`ls`·`grep` 에만 붙어 있다. 아래는 본문의 형태를 그대로 옮긴다. **먼저 `sudo` 없이 치고, 권한 때문에 막히면 그때 앞에 `sudo` 를 붙인다.** 어느 쪽인지는 kubeconfig 를 어디에 뒀나가 가른다 — D-1 은 같은 전제를 옮기면서 「kubeconfig 를 사용자 홈에 복사해 뒀다면 `sudo` 는 빼도 된다」를 괄호로 달아 두었고, D-3 은 그 괄호가 없다.
+**`[kc-lab-1]` 라벨이 붙은 블록은 게스트 셸이다.** lab host 에서 `ssh kc-lab-1` 로 들어가서 치고, 끝나면 `exit` 로 나온다. `ssh kc-lab-2 '…'` 한 줄 형태는 lab host 에서 그대로 쳐도 되므로 `[lab host]` 로 두었다.
+
+원 가이드는 둘을 한 기계로 묶어 전부 `kc-lab-1` 에서 치라고 적었고, 전제 한 줄은 「`kubectl` 은 `sudo` 로 쓴다」인데 본문의 `kubectl` 줄에는 `sudo` 가 없다. 그 조합은 이 실험대에서 안 돈다 — 2026-09-17 에 양쪽에서 쳐서 확인했다(observed).
+
+| 어디서 | `kubectl …` | `sudo kubectl …` |
+|---|---|---|
+| lab host | 된다 | 안 된다 |
+| `kc-lab-1` | 안 된다 | 된다 |
+
+기반 가이드가 kubeconfig 를 lab host 의 `~/.kube/config` 에만 두고 게스트의 사용자 홈에는 일부러 두지 않기 때문이다. `kc-lab-1` 에서 `sudo` 없이 치면 이렇게 끝난다.
+
+```text
+error: error loading config file "/etc/rancher/k3s/k3s.yaml": open /etc/rancher/k3s/k3s.yaml: permission denied
+```
+
+그래서 `kubectl` 은 `[lab host]` 에서 치고, 저장 파일을 보는 넷만 `[kc-lab-1]` 에서 `sudo` 로 친다. 굳이 `kc-lab-1` 한 기계에서 다 치겠다면 `kubectl` 에도 `sudo` 를 붙인다. D-1 은 같은 전제에 「kubeconfig 를 사용자 홈에 복사해 뒀다면 `sudo` 는 빼도 된다」를 괄호로 달아 두었는데, 그쪽은 반대 방향을 말한다.
 
 | 무엇 | 값 |
 |---|---|
@@ -95,7 +110,7 @@ Secret 이 base64 를 쓰는 까닭은 감추려는 것이 아니라 YAML 에 
 
 **파괴적인 단계가 없는 편이다.** 만드는 것은 카나리아 Secret 하나뿐이고 복구 절에서 지운다. 전 구간 약 15분. 되돌리기는 한 줄이다.
 
-```bash label="[kc-lab-1] 되돌리기 한 줄"
+```bash label="[lab host] 되돌리기 한 줄"
 kubectl -n keycloak-lab delete secret d3-canary
 ```
 
@@ -111,7 +126,7 @@ Secret 목록 → describe 가 감추는 화면 → 키 이름만 → 길이만
 
 **무엇을 보는가** — 이름과 키 개수.
 
-```bash label="[kc-lab-1] Secret 목록을 본다"
+```bash label="[lab host] Secret 목록을 본다"
 kubectl -n keycloak-lab get secret
 ```
 
@@ -129,7 +144,7 @@ kubectl -n keycloak-lab get secret
 
 **무엇을 보는가** — 키 이름과 바이트 수.
 
-```bash label="[kc-lab-1] describe 화면을 본다"
+```bash label="[lab host] describe 화면을 본다"
 kubectl -n keycloak-lab describe secret bff-secrets
 ```
 
@@ -149,7 +164,7 @@ kubectl -n keycloak-lab describe secret bff-secrets
 
 **무엇을 보는가** — 어떤 키가 들어 있는가. 값은 보지 않는다.
 
-```bash label="[kc-lab-1] ① 키 이름만 뽑는다"
+```bash label="[lab host] ① 키 이름만 뽑는다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets -o jsonpath='{.data}' \
   | tr ',' '\n' | grep -o '"[A-Z_]*"'
 ```
@@ -163,7 +178,7 @@ kubectl -n keycloak-lab get secret keycloak-lab-secrets -o jsonpath='{.data}' \
 
 `jq` 가 없어서 `tr` 과 `grep` 으로 자른다. D-2 가 레지스트리 태그 목록을 자를 때 쓴 것과 같은 수법이고, `jq` 가 없다는 전제가 여기서도 형태를 정한다.
 
-```bash label="[kc-lab-1] ② 값 대신 길이를 잰다"
+```bash label="[lab host] ② 값 대신 길이를 잰다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets \
   -o jsonpath='{.data.POSTGRES_PASSWORD}' | base64 -d | wc -c
 ```
@@ -190,7 +205,7 @@ kubectl -n keycloak-lab get secret keycloak-lab-secrets \
 
 ① 카나리아를 만든다.
 
-```bash label="[kc-lab-1] ① 카나리아 Secret 을 만든다"
+```bash label="[lab host] ① 카나리아 Secret 을 만든다"
 kubectl -n keycloak-lab create secret generic d3-canary \
   --from-literal=CANARY=d3-canary-zq7v-do-not-use
 ```
@@ -207,7 +222,7 @@ secret/d3-canary created
 
 ## 주입 검증
 
-```bash label="[kc-lab-1] 카나리아가 심겼는지 본다"
+```bash label="[lab host] 카나리아가 심겼는지 본다"
 kubectl -n keycloak-lab get secret d3-canary
 kubectl -n keycloak-lab describe secret d3-canary
 ```
@@ -232,7 +247,7 @@ CANARY:  25 bytes
 
 값을 아는 카나리아로 먼저 해 본다.
 
-```bash label="[kc-lab-1] ① 카나리아를 API 로 뽑아 본다"
+```bash label="[lab host] ① 카나리아를 API 로 뽑아 본다"
 kubectl -n keycloak-lab get secret d3-canary \
   -o jsonpath='{.data.CANARY}' | base64 -d; echo
 ```
@@ -306,7 +321,14 @@ sudo grep -c 'd3-canary-zq7v-do-not-use' /var/lib/rancher/k3s/server/db/state.db
 sudo grep -c 'd3-canary-zq7v-do-not-use' /var/lib/rancher/k3s/server/db/state.db-wal
 ```
 
-이 실험대는 카나리아 대신 실제 값으로 쟀다(observed). 위의 카나리아 형태는 가이드가 미검증으로 표시했다(unknown). 실제로 나온 결과가 이것이다(observed, `02-at-rest.txt`).
+이 실험대는 카나리아 대신 실제 값으로 쟀다(observed). **위의 카나리아 형태는 2026-09-17 에 쳐서 확인했다**(observed) — 그때까지 가이드가 미검증으로 표시해 둔 줄이다.
+
+```text
+state.db      0
+state.db-wal  1
+```
+
+**그 `0` 과 `1` 이 가이드가 예측만 하고 못 가른 것을 가른다.** 방금 만든 값은 아직 본체로 안 내려가고 `-wal` 에만 있다. 그러니 본체에서 `0` 이 나왔다고 「평문이 없다」가 아니라, **`-wal` 까지 봐야 답이 나온다.** 실제로 나온 결과가 이것이다(observed, `02-at-rest.txt`).
 
 ```text
 === ★ 저장 파일에서 비밀번호가 그대로 보이는가 ===
@@ -327,11 +349,19 @@ sudo grep -c 'd3-canary-zq7v-do-not-use' /var/lib/rancher/k3s/server/db/state.db
 
 **가이드는 이 두 줄의 인자에 클라이언트 비밀 평문을 적어 두었다. 값은 옮기지 않는다** — 그리고 가이드 자신이 주입 절에서 「진짜 비밀번호를 `grep` 인자로 쓰면 셸 히스토리와 `ps` 에 남는다」고 적었으므로, 아래에는 카나리아 문자열을 넣었다.
 
-```bash label="[kc-lab-1] ④ -wal 과 strings 로 한 번 더 본다 (미검증)"
+```bash label="[kc-lab-1] ④ -wal 과 strings 로 한 번 더 본다"
 sudo grep -c 'd3-canary-zq7v-do-not-use' /var/lib/rancher/k3s/server/db/state.db-wal
-sudo strings /var/lib/rancher/k3s/server/db/state.db | grep -c 'd3-canary-zq7v-do-not-use'
+sudo sh -c 'strings /var/lib/rancher/k3s/server/db/state.db | grep -c d3-canary-zq7v-do-not-use'
 ```
 
+:::warning
+
+**게스트에 `strings` 가 없다.** `binutils` 가 안 깔려 있어 그대로 치면 `sh: 1: strings: not found` 로 끝난다(2026-09-17, observed). `sudo apt install -y binutils` 로 깔거나, `strings` 없이 `grep -c` 만으로도 같은 답이 나온다 — 둘 다 쳐서 같은 수를 받았다(observed).
+
+:::
+
+**`sudo strings … | grep` 이 아니라 `sudo sh -c '…'` 인 까닭**은 파이프가 `sudo` 밖에서 이어지기 때문이다. 앞의 형태로 치면 `strings` 만 root 로 돌고 `grep` 은 일반 사용자로 도는데, 여기서는 읽는 쪽이 `strings` 라 결과는 같다. 다만 파일을 `grep` 이 직접 읽는 아래 형태에서는 `sudo` 가 `grep` 에 붙어야 한다.
+
 | 왜 안 나올 수 있나 | 확인 |
 |---|---|
 | 아직 `-wal` 에만 있다 | `-wal` 을 같이 `grep` |
@@ -357,7 +387,7 @@ k3s 는 `--secrets-encryption` 플래그로 켤 수 있다. 지금은 안 켜져
 
 어느 파드를 볼지 먼저 정한다.
 
-```bash label="[kc-lab-1] ① BFF 파드를 본다"
+```bash label="[lab host] ① BFF 파드를 본다"
 kubectl -n keycloak-lab get pods -l app=bff
 ```
 
@@ -365,7 +395,7 @@ kubectl -n keycloak-lab get pods -l app=bff
 
 **치기 전에 — 이 줄은 값을 화면에 찍는다.** 나오는 것은 카나리아가 아니라 `KEYCLOAK_CLIENT_SECRET` 과 `BFF_DB_PASSWORD` 의 평문이다. 바로 아래 실측을 `<평문 14자>` 로 가린 것은 이 문서이지 당신의 터미널이 아니다. 찍힌 값은 스크롤백과 셸 히스토리에 남고, 화면을 공유 중이면 보는 사람 모두에게 간다. 이 편이 「읽기 전에」에서 세운 「남의 진짜 비밀은 길이와 키 이름까지만 본다」를 이 줄 하나가 벗어나는데, 같은 결론을 값 없이 내는 명령은 가이드에 없다(unknown). 운영 클러스터에서는 치지 않는다. 실험대에서 쳤으면 복구 절의 `history` 확인까지 마치고, 운영 값을 찍었으면 회전(B-6·B-7)으로 이어 간다.
 
-```bash label="[kc-lab-1] ② 파드 안의 환경변수를 본다 (미검증 · 평문이 화면에 찍힌다)"
+```bash label="[lab host] ② 파드 안의 환경변수를 본다 (미검증 · 평문이 화면에 찍힌다)"
 kubectl -n keycloak-lab exec deploy/bff -- sh -c 'env | grep -iE "secret|password"'
 ```
 
@@ -380,7 +410,7 @@ kubectl -n keycloak-lab exec deploy/bff -- sh -c 'env | grep -iE "secret|passwor
 
 `exec` 이 `deploy/bff` 로 안 되면(파드가 종료 중이거나 여럿이면) 이름을 골라 친다.
 
-```bash label="[kc-lab-1] ③ Running 인 파드 이름을 고른다"
+```bash label="[lab host] ③ Running 인 파드 이름을 고른다"
 kubectl -n keycloak-lab get pod -l app=bff \
   --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}'; echo
 ```
@@ -391,7 +421,7 @@ kubectl -n keycloak-lab get pod -l app=bff \
 
 **이 줄도 값을 화면에 찍는다.** ②에서 본 것과 같은 평문이 같은 자국을 남긴다. 여기서 확인하려는 것은 「같은 값이 또 나오는가」뿐이므로, 화면을 공유 중이거나 운영 클러스터에 붙어 있으면 치지 않고 ②의 결과로 판정한다.
 
-```bash label="[kc-lab-1] ④ 다른 프로세스의 환경변수를 읽는다 (미검증 · 평문이 화면에 찍힌다)"
+```bash label="[lab host] ④ 다른 프로세스의 환경변수를 읽는다 (미검증 · 평문이 화면에 찍힌다)"
 kubectl -n keycloak-lab exec deploy/bff -- \
   sh -c 'tr "\0" "\n" < /proc/1/environ | grep -i secret'
 ```
@@ -418,7 +448,7 @@ volumeMounts:
 
 ### 4. ④ RBAC — 유일하게 막는다
 
-```bash label="[kc-lab-1] ① 기본 서비스계정이 Secret 을 읽을 수 있는지 묻는다"
+```bash label="[lab host] ① 기본 서비스계정이 Secret 을 읽을 수 있는지 묻는다"
 kubectl auth can-i get secrets -n keycloak-lab \
   --as=system:serviceaccount:keycloak-lab:default
 ```
@@ -433,7 +463,7 @@ kubectl auth can-i get secrets -n keycloak-lab \
 
 어떤 권한이 있는지 통째로 보는 형태도 가이드에 있고, 미검증이다(unknown).
 
-```bash label="[kc-lab-1] ② 권한 목록과 Role 을 본다 (미검증)"
+```bash label="[lab host] ② 권한 목록과 Role 을 본다 (미검증)"
 kubectl auth can-i --list -n keycloak-lab \
   --as=system:serviceaccount:keycloak-lab:default
 kubectl -n keycloak-lab get role,rolebinding
@@ -473,7 +503,7 @@ kubectl -n keycloak-lab get role,rolebinding
 
 ① 지우고 목록을 다시 본다.
 
-```bash label="[kc-lab-1] ① 카나리아를 지우고 목록을 본다"
+```bash label="[lab host] ① 카나리아를 지우고 목록을 본다"
 kubectl -n keycloak-lab delete secret d3-canary
 kubectl -n keycloak-lab get secret
 ```
@@ -492,13 +522,23 @@ secret "d3-canary" deleted
 
 ### 2. 지웠다고 파일에서 없어지지는 않는다
 
-아래는 미검증이고, 이 실험은 삭제 후를 재지 않았다(unknown).
+**2026-09-17 에 삭제 후를 쟀다**(observed). 그때까지 이 실험이 안 밟고 넘어간 단계다.
 
-```bash label="[kc-lab-1] 삭제 뒤에 저장 파일을 다시 본다 (미검증)"
+```bash label="[kc-lab-1] 삭제 뒤에 저장 파일을 다시 본다"
 sudo grep -c 'd3-canary-zq7v-do-not-use' /var/lib/rancher/k3s/server/db/state.db
 sudo grep -c 'd3-canary-zq7v-do-not-use' /var/lib/rancher/k3s/server/db/state.db-wal
 ```
 
+**지운 뒤에 오히려 늘었다.**
+
+```text
+             state.db   state.db-wal
+삭제 전         0            1
+삭제 뒤         0            7
+```
+
+`kubectl delete secret` 은 API 에서 그 객체를 없앨 뿐이고, **그 삭제 자체가 같은 값을 담은 레코드를 `-wal` 에 더 쓴다.** 그래서 「Secret 을 지웠다」와 「그 값이 디스크에서 사라졌다」는 다른 사건인 정도가 아니라, 지우는 동작이 흔적을 **늘린다.**
+
 `0` 이 나오면 「이 시점에 이 형태로는 안 보인다」이고, `0` 이 아니면 지운 Secret 의 평문이 아직 파일에 있는 것이다. 어느 쪽이든 관찰 절의 결론은 안 바뀐다 — 판정은 이미 `2` 에서 났다.
 
 데이터베이스 파일은 지운 행의 공간을 즉시 0으로 덮어쓰지 않는다. 「Secret 을 지웠다」와 「그 값이 디스크에서 사라졌다」는 다른 사건이고, 비밀이 유출됐을 때 실제로 해야 하는 일이 삭제가 아니라 회전(rotation)인 까닭이 여기 있다 — B-6·B-7 의 주제다.
@@ -508,7 +548,7 @@ sudo grep -c 'd3-canary-zq7v-do-not-use' /var/lib/rancher/k3s/server/db/state.db
 | 항목 | 명령 | 돌아왔을 때 |
 |---|---|---|
 | 카나리아 | `kubectl -n keycloak-lab get secret d3-canary` | `NotFound` |
-| Secret 목록 | `kubectl -n keycloak-lab get secret` | 세 개 |
+| Secret 목록 | `kubectl -n keycloak-lab get secret` | 카나리아를 뺀 나머지. 2026-09-17 의 이 실험대에는 `keycloak-lab-secrets` 하나뿐이었다(observed) |
 | 파드 | `kubectl -n keycloak-lab get pods` | 전부 `Running` (아무것도 안 건드렸다) |
 | 터미널 | `history \| tail -40` | 비밀번호가 찍힌 줄이 어디까지 남았는지 본다 |
 
diff --git a/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d4-certificate-renewal.md b/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d4-certificate-renewal.md
index 9c70265..6e1f9d0 100644
--- a/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d4-certificate-renewal.md
+++ b/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d4-certificate-renewal.md
@@ -212,6 +212,18 @@ Fri 2026-09-04 17:03:46 KST     1h 54min  Fri 2026-09-04 03:19:39 KST  11h ago
 
 `NEXT`/`LEFT` 가 채워져 있는가, `LAST`/`PASSED` 가 하루 안쪽인가를 본다. 표가 통째로 비면 타이머가 없는 것이고, 이름이 배포판마다 다르므로 `systemctl list-timers --all | grep -i certbot` 으로 찾는다.
 
+**기계 이름과 유닛 이름이 둘 다 이 실험대와 다르다.** 2026-09-17 에 쳐서 확인했다(observed).
+
+첫째, 이 편은 `ssh test-server` 로 간다고 적는데 **certbot 은 엣지 게스트에 있다.** 기반 가이드 03 이 엣지 nginx 를 호스트에서 `kc-lab-edge` 로 옮겼고 04 가 certbot 을 거기 깔았기 때문이다. `test-server` 에도 `certbot` 실행 파일은 있지만 타이머가 없다.
+
+```text
+[test-server]    systemctl list-timers certbot-renew.timer  →  0 timers listed.
+[kc-lab-edge]    systemctl list-timers --all | grep -i certbot
+                 Thu 2026-09-17 17:06:05 UTC  10h left  certbot.timer  certbot.service
+```
+
+둘째, Debian 12 의 유닛 이름은 **`certbot.timer` · `certbot.service`** 이고 `certbot-renew.*` 가 아니다. 그래서 이 편의 `systemctl list-timers certbot-renew.timer` 와 `systemctl cat certbot-renew.service` 는 이 실험대에서 **빈 표와 오류**를 낸다. 아래부터는 `ssh kc-lab-edge` 로 가고 유닛 이름은 `--all | grep -i certbot` 이 찾아 준 것을 쓴다.
+
 ```bash label="[test-server] ② 서비스 상태와 오늘 journal 을 본다"
 ssh test-server 'systemctl status certbot-renew.service'
 ```
@@ -250,15 +262,33 @@ Let's Encrypt 는 90일 발급이고 certbot 은 30일 남았을 때 갱신한
 
 **무엇을 보는가** — 갱신된 인증서를 서버에 읽히는 경로는 셋뿐이고, 셋을 하나씩 연다. 아직 아무것도 주입하지 않았는데 이 실험의 원인 진단이 여기서 이미 끝난다.
 
-```bash label="[test-server] ① 유닛 본문을 본다"
-ssh test-server 'systemctl cat certbot-renew.service'
+```bash label="[kc-lab-edge] ① 유닛 본문을 본다"
+ssh kc-lab-edge 'systemctl cat certbot.service'
 ```
 
-```bash label="[test-server] ② 타이머 본문을 본다"
-ssh test-server 'systemctl cat certbot-renew.timer'
+```bash label="[kc-lab-edge] ② 타이머 본문을 본다"
+ssh kc-lab-edge 'systemctl cat certbot.timer'
 ```
 
-**어디를 보나** — 실측은 이렇다(observed, `07-renewal-hook-missing.txt`).
+```bash label="[kc-lab-edge] ③ 배포 훅 디렉터리가 비었는지 본다"
+ssh kc-lab-edge 'sudo ls -l /etc/letsencrypt/renewal-hooks/deploy/'
+```
+
+**2026-09-17 실측**(observed) — 이름은 다르지만 **이 편이 찾는 것은 그대로 없다.**
+
+```text
+# /lib/systemd/system/certbot.service
+[Service]
+Type=oneshot
+ExecStart=/usr/bin/certbot -q renew --no-random-sleep-on-renew
+PrivateTmp=true
+
+/etc/letsencrypt/renewal-hooks/deploy/   total 0
+```
+
+`ExecStartPost` 도 `--deploy-hook` 도 없고 훅 디렉터리도 비어 있다. **갱신은 돌지만 받은 것을 누가 읽게 만드는 일은 아무도 하지 않는다** — 이 편의 결론이 유닛 이름과 무관하게 성립한다는 뜻이다.
+
+**어디를 보나** — 원래 실행의 실측은 이렇다(observed, `07-renewal-hook-missing.txt`).
 
 ```text
   # /usr/lib/systemd/system/certbot-renew.service
@@ -1072,6 +1102,14 @@ crt.sh 에 관한 곁다리도 실측이다. 발급 사실은 Certificate Transp
 
 인증서에 SCT 가 박혀 있다는 것과 crt.sh 가 그것을 색인했다는 것은 다르다. 관측 도구가 진실의 부분집합만 본다는, A-2 의 `up` 지표와 같은 종류의 함정이다.
 
+## 이 실험대에서 아직 못 밟은 단계
+
+2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈췄는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
+
+- **남은 것** — 인증서 발급과 갱신·reload 판정 전부. Cloudflare API 토큰이 있어야 DNS-01 이 돈다. 지금까지 밟은 것 — 기계·유닛 이름 대조, 기본 유닛에 훅이 없다는 확인.
+- **막는 것** — `https://auth.hyeonworks.com` 이 서지 않는다. 와일드카드 인증서(Cloudflare API 토큰이 필요한 DNS-01)와, 밖에서 실험대에 닿는 길(호스트의 libvirt `guest_input` 구멍 — A-4 에서 확인한 `ExecStartPost` 누락)이 둘 다 있어야 한다.
+- **그때까지 이 편의 실측 가운데 `(observed)` 로 적힌 2026-09-17 값은 위 「지금까지 밟은 것」 범위뿐이다.** 나머지는 원래 실행의 값이다.
+
 ## 무엇이 관측이고 무엇이 아닌가
 
 - (observed) 주입 전 인증서의 `subject`·`issuer`·`notBefore=Sep  3 00:47:23 2026 GMT`·`notAfter=Dec  2 00:47:22 2026 GMT` 와 SAN 세 이름, SCT 두 줄, 체인 네 줄과 `Verify return code: 0 (ok)`, 타이머 표와 `status=0/SUCCESS`, `남은 일수: 88일`, 유닛 본문과 `ExecStart=/usr/bin/certbot -q renew`, 훅 디렉터리의 `Permission denied` 와 `sudo` 로 본 `total 8` 셋, `Discovered plugins: dns-cloudflare, manual, null, standalone, webroot` 와 `certbot 5.7.0`, 워커 두 줄(`585`·`586`·`80529`), 시계 측정 네 줄과 `+106.1` 세 번, 대조군 900건, 전송 중 대조군의 `845361`·`41.392198s`, `sudo -n -l` 두 줄, `Serial Number: 6c7cb6df1da8a6d7995d93c264bb9ecea1d`, `archive/` 여덟 줄과 `2026-09-04 17:22:13` mtime, 감시의 `serial=0520BB6416D569E26697B1691440F523B853` 과 161표본, `ssl_certificate` 두 줄, 일련번호가 바뀐 `08:58:52` 와 그 앞 구간의 `428회`, 폴링 `8856건` 과 구간 셋의 중앙·p95·최대, 전송 중 세 줄과 `845361`·`연결수=1`·`curl종료=0`, 아티팩트 76건과 `50µs`·`0/100`, reload 뒤의 워커 `28829`, crt.sh 의 `[]` 와 13건.
diff --git a/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d4a-deploy-hook.md b/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d4a-deploy-hook.md
index f7062f4..1bc57a8 100644
--- a/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d4a-deploy-hook.md
+++ b/docs/keycloak-session-store/tech-log-studio/operations-that-report-success/setup/setup-reproduce-d4a-deploy-hook.md
@@ -43,7 +43,17 @@ certbot 의 `deploy/` 훅에 두 줄짜리 파일 하나를 넣고, 갱신 뒤 n
 
 ## 읽기 전에 — 어디서 치는가
 
-기계가 둘이다. 밖에서 보는 `openssl` 은 `[dev]` 에서 치고, 주입은 전부 `[test-server]` 쪽이라 사람이 비밀번호를 친다.
+기계가 둘이다. 밖에서 보는 `openssl` 은 `[dev]` 에서 치고, 주입은 전부 엣지 쪽이라 사람이 비밀번호를 친다.
+
+**주입하는 기계는 `test-server` 가 아니라 `kc-lab-edge` 다.** 기반 가이드 03 이 엣지 nginx 를 호스트에서 게스트로 옮겼고 04 가 거기 certbot 을 깔았다. 2026-09-17 에 양쪽에서 확인했다(observed).
+
+```text
+[test-server]   ps -ef | grep '[n]ginx'   →  nginx 프로세스가 없다
+[kc-lab-edge]   root 1065 nginx: master process /usr/sbin/nginx …
+                www-data 1106 nginx: worker process
+```
+
+그래서 아래 `[test-server]` 라벨이 붙은 블록은 전부 `ssh kc-lab-edge` 로 간다. 그 게스트의 `sudo` 는 무암호라 사람이 비밀번호를 칠 일도 없다.
 
 | 무엇 | 값 |
 |---|---|
@@ -154,7 +164,15 @@ echo | openssl s_client -connect auth.hyeonworks.com:443 -servername auth.hyeonw
 ssh -t test-server 'sudo ls -la /etc/letsencrypt/renewal-hooks/deploy/'
 ```
 
-**어디를 보나** — 실측은 이렇다(observed, `d4-certificate-renewal/12-certbot-state.txt`).
+**어디를 보나** — 2026-09-17 에 엣지에서 친 것이다(observed). 디렉터리는 있고 안은 비었다.
+
+```text
+total 8
+drwxr-xr-x 2 root root 4096 Sep 17 04:33 .
+drwxr-xr-x 5 root root 4096 Sep 17 04:33 ..
+```
+
+원래 실측은 이렇다(observed, `d4-certificate-renewal/12-certbot-state.txt`).
 
 ```text
 /etc/letsencrypt/renewal-hooks/deploy/:
@@ -173,11 +191,22 @@ drwxr-xr-x 5 root root 4096 2026-09-03 10:46:54.658520760 +0900 ..
 
 ```bash label="[dev] ① 세 번 잰다"
 for i in 1 2 3; do
-  A=$(date -u +%s.%N); B=$(ssh test-server 'date -u +%s.%N'); C=$(date -u +%s.%N)
+  A=$(date -u +%s.%N); B=$(ssh kc-lab-edge 'date -u +%s.%N'); C=$(date -u +%s.%N)
   echo "A=$A  B=$B  C=$C"
 done
 ```
 
+**재는 대상이 엣지 게스트다.** 이 절차의 판정은 엣지 nginx 가 언제 reload 됐나이므로, 어긋난 시계를 재야 할 짝은 「보는 기계 ↔ 엣지」다.
+
+2026-09-17 에 lab host 와 엣지를 나란히 찍어 보니 **엣지가 94초 느렸다**(observed).
+
+```text
+lab host    2026-09-17T06:51:28.799Z
+kc-lab-edge 2026-09-17T06:49:54.782Z
+```
+
+문서가 적은 `106초` 는 그때 그 짝의 값이고, **수를 옮겨 쓰지 말고 지금 자기 실험대에서 다시 잰다.** 게스트는 호스트와 따로 시계를 맞추므로 새로 만들 때마다 값이 다르다.
+
 세 줄 각각에서 `B` 와 `(A+C)/2` 의 차이를 눈으로 뺀다. 그리고 세 번의 값이 서로 비슷한가를 본다 — 흔들리면 네트워크 지연이 섞였고, 안정적이면 진짜 왜곡이다.
 
 **2.** 어느 쪽이 맞는지는 외부 기준으로 가른다.
@@ -617,6 +646,14 @@ echo | openssl s_client -connect auth.hyeonworks.com:443 -servername auth.hyeonw
 
 이 편이 남기는 한 문장은 「처방을 적었으면 시험한다」이다. D-4 는 원인을 정확히 셋으로 특정하고 고치는 법까지 적었고, 그 처방이 듣는지 확인하는 데 든 비용은 파일 하나와 명령 두 줄이었다. 확인하지 않은 채로 문서에 남았다면 「고치는 법」 항목은 다음 갱신일까지 아무도 시험하지 않은 문장으로 남았을 텐데, 그날이 바로 시험할 수 없는 날이다.
 
+## 이 실험대에서 아직 못 밟은 단계
+
+2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈췄는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
+
+- **남은 것** — 훅을 설치하고 강제 갱신으로 워커 PID 가 바뀌는지 보는 구간 전부. 인증서가 있어야 갱신할 것이 생긴다. 지금까지 밟은 것 — 훅 디렉터리가 빈 것, 두 기계 시계 차 94초.
+- **막는 것** — `https://auth.hyeonworks.com` 이 서지 않는다. 와일드카드 인증서(Cloudflare API 토큰이 필요한 DNS-01)와, 밖에서 실험대에 닿는 길(호스트의 libvirt `guest_input` 구멍 — A-4 에서 확인한 `ExecStartPost` 누락)이 둘 다 있어야 한다.
+- **그때까지 이 편의 실측 가운데 `(observed)` 로 적힌 2026-09-17 값은 위 「지금까지 밟은 것」 범위뿐이다.** 나머지는 원래 실행의 값이다.
+
 ## 무엇이 관측이고 무엇이 아닌가
 
 - (observed) 주입 전 워커 두 줄(`585` 와 `28829`, `lstart Fri Sep  4 18:00:35`), 훅 디렉터리의 `total 8`, 시계 측정 네 줄과 `+106.1` 세 번, certbot 출력 전문(`ran with error output` · `types_hash` 경고 두 줄 · `test is successful` · `signal process started` · `Congratulations, all renewals succeeded` · `fullchain.pem (success)`), 주입 뒤 워커 두 줄(`585` · `37252` · `etimes 74` · `lstart Fri Sep  4 21:29:36 2026`), 새 인증서의 `serial=06F3E0EF4D1BB03DE58130EAAD1176101373` · `notBefore=Sep  4 11:29:18 2026 GMT` · `notAfter=Dec  3 11:29:17 2026 GMT` 와 SAN 세 이름, SCT 두 줄(`Sep  4 12:27:49.054` · `Sep  4 12:27:49.048`), `notBefore` ↔ SCT 표의 `약 89.8초` · `약 88.9초`.
diff --git a/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a0-session-sharing-path.md b/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a0-session-sharing-path.md
index 8413a06..b837e2c 100644
--- a/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a0-session-sharing-path.md
+++ b/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a0-session-sharing-path.md
@@ -42,16 +42,31 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 전부 `[kc-lab-1]` 에서 `kubectl` 과 `psql` 로 친다. 노드 자체를 건드리는 명령이 없어서 `kc-lab-2` 로 들어갈 일이 없다. `kubectl` 에 `sudo` 를 붙이지 않는다.
+명령은 전부 `[lab host]` 에서 `kubectl` 과 `psql` 로 친다. 노드 자체를 건드리는 명령이 없어서 게스트에 들어갈 일이 없다. `kubectl` 에 `sudo` 를 붙이지 않는다.
 
-```bash label="[kc-lab-1] sudo 를 붙이는 쪽이 틀린 형태다"
+```bash label="[lab host] sudo 를 붙이는 쪽이 틀린 형태다"
 kubectl -n keycloak-lab get pods        # 이렇게
 sudo kubectl -n keycloak-lab get pods   # 이렇게 치면 안 된다
 ```
 
 `sudo` 를 붙이면 root 환경으로 돌아 사용자 홈의 kubeconfig 를 못 본다. root 홈에는 `~/.kube/config` 가 없어서 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다. 막힌 곳은 클러스터가 아니라 `kubectl` 이 어느 설정 파일을 읽느냐다.
 
-터미널은 둘을 연다. 하나는 탐침 파드 셸용이라 붙잡혀 있고, 하나는 관찰용이다. 그래서 `[kc-lab-1]` 라벨이 붙은 블록이 `[탐침 파드]` 블록 사이에 끼어 있으면 **관찰용 터미널에서 친다** — 파드 셸을 나가라는 뜻이 아니다. 나가라고 할 때는 `exit` 를 블록으로 따로 적는다.
+**`kc-lab-1` 에서 치지 않는다.** 원본 가이드는 `kc-lab-1` 에서 치라고 적었는데, 기반 가이드가 세운 실험대에서는 **그 기계에 kubeconfig 가 아예 없다.** 2026-09-17 에 양쪽에서 쳐서 확인했다(observed).
+
+| 어디서 | `kubectl …` | `sudo kubectl …` |
+|---|---|---|
+| lab host | 된다 | 안 된다 |
+| `kc-lab-1` | 안 된다 | 된다 |
+
+`kc-lab-1` 에서 `sudo` 없이 치면 `connection refused` 가 아니라 이렇게 끝난다.
+
+```text
+error: error loading config file "/etc/rancher/k3s/k3s.yaml": open /etc/rancher/k3s/k3s.yaml: permission denied
+```
+
+k3s 의 `kubectl` 은 `~/.kube/config` 가 없으면 `/etc/rancher/k3s/k3s.yaml` 로 떨어지는데 그 파일은 `600 root` 다. 기반 가이드는 그 파일을 **lab host 의 `~/.kube/config` 로만** 복사하고 게스트의 사용자 홈에는 일부러 두지 않는다 — 워커 한 대가 털리면 클러스터가 통째로 털리는 구성을 피하려고 그렇게 했다. 그래서 「`sudo` 를 붙이지 않는다」는 규칙은 **lab host 의 규칙**이고, 기계를 `kc-lab-1` 로 읽으면 첫 명령부터 막힌다.
+
+터미널은 둘을 연다. 하나는 탐침 파드 셸용이라 붙잡혀 있고, 하나는 관찰용이다. 그래서 `[lab host]` 라벨이 붙은 블록이 `[탐침 파드]` 블록 사이에 끼어 있으면 **관찰용 터미널에서 친다** — 파드 셸을 나가라는 뜻이 아니다. 나가라고 할 때는 `exit` 를 블록으로 따로 적는다.
 
 | 무엇 | 값 |
 |---|---|
@@ -96,7 +111,7 @@ sudo kubectl -n keycloak-lab get pods   # 이렇게 치면 안 된다
 
 **이건 상태를 부수는 실험이다.** 세션 테이블을 비우고, StatefulSet 을 재시작하고, PostgreSQL 의 문장 로깅을 켠다. **실험대에서만 한다.** 지운 세션은 돌아오지 않는다. 되돌릴 수 있는 것은 문장 로깅 하나이고, 켜기 전에 끄는 명령을 먼저 읽어 둔다.
 
-```bash label="[kc-lab-1] 중간에 그만둘 때 치는 한 묶음"
+```bash label="[lab host] 중간에 그만둘 때 치는 한 묶음"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "alter system reset log_statement" -c "alter system reset log_line_prefix" \
   -c "select pg_reload_conf()"
@@ -114,11 +129,11 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **무엇을 보는가** — 파드가 둘 다 Ready 이고 다른 기계에 나뉘어 있는지.
 
-```bash label="[kc-lab-1] ① 노드를 본다"
+```bash label="[lab host] ① 노드를 본다"
 kubectl get nodes
 ```
 
-```bash label="[kc-lab-1] ② 파드가 어느 노드에 있는지 본다"
+```bash label="[lab host] ② 파드가 어느 노드에 있는지 본다"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
@@ -130,7 +145,7 @@ kubectl -n keycloak-lab get pods -o wide
 
 **무엇을 보는가** — 뒤의 모든 요청이 향할 주소.
 
-```bash label="[kc-lab-1] 파드 IP 를 변수에 담고 눈으로 확인한다"
+```bash label="[lab host] 파드 IP 를 변수에 담고 눈으로 확인한다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 echo "$K0 $K1"
@@ -150,7 +165,7 @@ echo "$K0 $K1"
 
 **무엇을 보는가** — 두 노드가 서로를 멤버로 세고 있는지.
 
-```bash label="[kc-lab-1] 양쪽 로그에서 마지막 클러스터 뷰 한 줄씩"
+```bash label="[lab host] 양쪽 로그에서 마지막 클러스터 뷰 한 줄씩"
 kubectl -n keycloak-lab logs keycloak-0 | grep ISPN000094 | tail -1
 kubectl -n keycloak-lab logs keycloak-1 | grep ISPN000094 | tail -1
 ```
@@ -176,7 +191,7 @@ kubectl -n keycloak-lab logs keycloak-1 | grep ISPN000094 | tail -1
 
 **무엇을 보는가** — 노드가 서로를 찾는 길인 `JGROUPS_PING` 테이블에 무엇이 등록돼 있는지.
 
-```bash label="[kc-lab-1] 디스커버리 테이블 세 열"
+```bash label="[lab host] 디스커버리 테이블 세 열"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select name, ip, coord from jgroups_ping order by name"
 ```
@@ -197,11 +212,11 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **무엇을 보는가** — 온라인 세션이 어느 테이블에 들어가는지.
 
-```bash label="[kc-lab-1] 테이블 목록"
+```bash label="[lab host] 테이블 목록"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c "\dt"
 ```
 
-**어디를 보나** — `USER_SESSION` 이라는 이름이 목록에 없는 것. 실측은 이렇다(observed).
+**어디를 보나** — `USER_SESSION` 이라는 이름이 목록에 없는 것. 실측은 이렇다 — **`(100 rows)` 가운데 이 실험이 쓰는 여섯 줄만 옮겼다**(observed, 2026-09-17 에 다시 세운 실험대에서도 100행이었다).
 
 ```text
  public | auth_session                  | table | keycloak
@@ -214,7 +229,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c
 
 **이 값이 뜻하는 것** — `persistent-user-sessions`(Keycloak 26 기본값)는 새 테이블을 만들지 않고 기존 오프라인 세션 테이블을 재사용한다. `offline_flag` 컬럼으로 구분하고 `'0'` 이 일반 로그인, `'1'` 이 `offline_access` 다. 기본키가 `(user_session_id, offline_flag)` 복합키인 까닭이 여기 있고, 이 절차의 모든 질의는 `offline_flag='0'` 이다.
 
-```bash label="[kc-lab-1] 지금 몇 건인지 센다"
+```bash label="[lab host] 지금 몇 건인지 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select offline_flag, count(*) from offline_user_session group by offline_flag"
 ```
@@ -225,14 +240,14 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 Keycloak 컨테이너에는 `curl` 도 `wget` 도 없어 `exec` 로 물으면 `exit 127` 이 난다. Prometheus 가 15초마다 이미 긁고 있으므로 밖에서 묻는 쪽이 짧다.
 
-```bash label="[kc-lab-1] ① 한 줄짜리 JSON 을 통째로 본다"
+```bash label="[lab host] ① 한 줄짜리 JSON 을 통째로 본다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_statistics_approximate_entries_unique'
 ```
 
 처음 한 번은 자르지 않고 그대로 본다. 어떤 라벨이 붙어 있는지 알아야 다음부터 무엇으로 거를지 정할 수 있다. 라벨을 보고 나면 읽기 좋게 자른다 — 아래 줄은 가이드가 미검증으로 표시했다(unknown).
 
-```bash label="[kc-lab-1] ② 라벨을 보고 나서 필요한 줄만 자른다"
+```bash label="[lab host] ② 라벨을 보고 나서 필요한 줄만 자른다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_statistics_approximate_entries_unique' \
   | tr ',' '\n' | grep -E '"cache":|"pod":|^"[0-9]'
@@ -284,17 +299,17 @@ Admin API 세션 목록의 id  jiv3rVZi1VeaO07oVJkL_MYW
 
 **목적** — DB 행과 캐시 엔트리를 동시에 0 으로 만들어, 뒤에 세는 숫자가 이 실험이 만든 것만 담게 한다.
 
-```bash label="[kc-lab-1] ① 온라인·오프라인 세션 행을 지운다"
+```bash label="[lab host] ① 온라인·오프라인 세션 행을 지운다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "delete from offline_user_session"
 ```
 
-```bash label="[kc-lab-1] ② 재시작 시각을 남기고 롤아웃을 건다"
+```bash label="[lab host] ② 재시작 시각을 남기고 롤아웃을 건다"
 date '+%H:%M:%S 재시작'
 kubectl -n keycloak-lab rollout restart statefulset/keycloak
 ```
 
-```bash label="[kc-lab-1] ③ 새 파드가 다 설 때까지 블록한다"
+```bash label="[lab host] ③ 새 파드가 다 설 때까지 블록한다"
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s
 ```
 
@@ -316,7 +331,7 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s
 
 ### 파드가 새로 떴고 IP 가 바뀌었는가
 
-```bash label="[kc-lab-1] 새 파드와 새 IP 를 다시 잡는다"
+```bash label="[lab host] 새 파드와 새 IP 를 다시 잡는다"
 kubectl -n keycloak-lab get pods -o wide | grep keycloak
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
@@ -327,7 +342,7 @@ echo "$K0 $K1"
 
 ### DB 에 세션이 한 행도 없는가
 
-```bash label="[kc-lab-1] 남은 행을 센다"
+```bash label="[lab host] 남은 행을 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select offline_flag, count(*) from offline_user_session group by offline_flag"
 ```
@@ -342,7 +357,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 상주 탐침 파드를 띄운다. Keycloak 이미지에 `curl` 이 없고, 토큰을 단계 사이로 넘겨야 하며, Service 로 보내면 어느 노드가 처리했는지 알 수 없다. 이 실험의 질문 자체가 어느 노드인가이므로 파드 IP 로 직접 친다.
 
-```bash label="[kc-lab-1] 탐침 파드를 띄우고 그 안의 셸로 들어간다"
+```bash label="[lab host] 탐침 파드를 띄우고 그 안의 셸로 들어간다"
 kubectl -n keycloak-lab run kc-probe --rm -it --restart=Never \
   --image=curlimages/curl:8.11.1 \
   --env="K0=$K0" --env="K1=$K1" \
@@ -353,7 +368,7 @@ kubectl -n keycloak-lab run kc-probe --rm -it --restart=Never \
 
 셸에서 `exit` 하면 `--rm` 이 파드를 지운다. 비밀번호는 명령 치환으로 넘기므로 값이 터미널에도 셸 히스토리에도 남지 않는다. 존재와 길이만 밖에서 확인한다.
 
-```bash label="[kc-lab-1] 비밀번호의 길이만 센다"
+```bash label="[lab host] 비밀번호의 길이만 센다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets \
   -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d | wc -c
 ```
@@ -400,9 +415,9 @@ AT=$(echo "$R" | sed -n 's/.*"access_token":"\([^"]*\)".*/\1/p')
 echo "refresh=${#RT}자 access=${#AT}자"
 ```
 
-`refresh=1187자 access=2043자` 같은 모양이 나온다. 길이가 `0자` 면 로그인이 실패한 것이고 `echo "$R"` 로 에러 본문을 본다.
+`refresh=1187자 access=2043자` 같은 모양이 나온다. **그 두 수를 기준값으로 삼지 않는다** — 2026-09-17 에 다시 세운 실험대에서는 `refresh=612자 access=758자` 였다(observed). 담긴 클레임과 서명 길이에 따라 달라지므로 **보는 것은 `0자` 가 아니라는 것 하나**다. `0자` 면 로그인이 실패한 것이고 `echo "$R"` 로 에러 본문을 본다.
 
-JWT 의 가운데 토막이 클레임이다. 먼저 통째로 디코드해 눈으로 보고 그다음에 sid 만 잘라낸다. 두 줄 다 미검증이다(unknown).
+JWT 의 가운데 토막이 클레임이다. 먼저 통째로 디코드해 눈으로 보고 그다음에 sid 만 잘라낸다. **두 줄 다 2026-09-17 에 쳐서 확인했다**(observed).
 
 ```sh label="[탐침 파드] ③ 클레임을 통째로 디코드해 본다"
 echo "$AT" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null; echo
@@ -414,9 +429,27 @@ SID=$(echo "$AT" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null \
 echo "SID=$SID"
 ```
 
-base64 패딩 때문에 끝이 깨져 보일 수 있고(`2>/dev/null` 이 그 불평을 지운다), `sid` 는 앞쪽에 있어서 대개 보인다.
+base64 패딩 때문에 끝이 깨져 보일 수 있고(`2>/dev/null` 이 그 불평을 지운다), `sid` 는 앞쪽에 있어서 대개 보인다. 2026-09-17 실측에서는 마지막 `"}` 두 글자가 잘렸다(observed).
 
-같은 sid 가 두 노드 모두에서 보이는지 물으려면 `admin-cli` 의 내부 id 가 필요하다. 응답을 한 번 그대로 보고 무엇을 자르는지 눈으로 본 다음 잘라낸다. 잘라내는 줄은 미검증이다(unknown).
+```text
+0EPyjFf8PwNJ-1q7","scope":"profile email
+```
+
+끝까지 보려면 패딩을 채운다. 이 형태로 디코드하면 클레임이 온전히 나온다(observed).
+
+```sh label="[탐침 파드] ③b 패딩을 채워 끝까지 디코드한다"
+P=$(echo "$AT" | cut -d. -f2)
+case $(( ${#P} % 4 )) in 2) P="$P==";; 3) P="$P=";; esac
+echo "$P" | tr '_-' '/+' | base64 -d; echo
+```
+
+```text
+{"exp":1789620347,"iat":1789620287,"jti":"onltro:ba0c11cf-5e4a-a378-7268-4efd5cef32b8","iss":"https://auth.hyeonworks.com/realms/master","typ":"Bearer","azp":"admin-cli","sid":"jbFsOn6E0EPyjFf8PwNJ-1q7","scope":"profile email"}
+```
+
+클레임 이름이 `azp exp iat iss jti scope sid typ` 여덟이고 `sub` 이 없다는 것도 이 형태로 확인했다(observed).
+
+같은 sid 가 두 노드 모두에서 보이는지 물으려면 `admin-cli` 의 내부 id 가 필요하다. 응답을 한 번 그대로 보고 무엇을 자르는지 눈으로 본 다음 잘라낸다. **잘라내는 줄도 2026-09-17 에 쳐서 확인했다**(observed).
 
 ```sh label="[탐침 파드] ⑤ 클라이언트 목록 응답을 그대로 본다"
 curl -s -H "Authorization: Bearer $AT" \
@@ -441,7 +474,14 @@ for H in "$K0" "$K1"; do
 done
 ```
 
-이 `for` 루프도 미검증이다(unknown). 실측은 이렇다(observed, `01-cross-node-session.txt`).
+**이 `for` 루프도 2026-09-17 에 쳐서 확인했다**(observed). 그때는 양쪽이 `1` 을 냈다.
+
+```text
+10.42.1.7  : 1
+10.42.0.13 : 1
+```
+
+원래 실행의 실측은 이렇다(observed, `01-cross-node-session.txt`).
 
 ```text
 === [3] 같은 sid 가 두 노드 모두에서 보이는가 ===
@@ -539,7 +579,7 @@ exit
 
 0b 에서 `exit` 했으므로 `--rm` 이 탐침 파드를 이미 지웠다. 0c 와 0d 는 파드 안에서 치므로 같은 명령으로 다시 띄운다.
 
-```bash label="[kc-lab-1] 탐침 파드를 다시 띄운다"
+```bash label="[lab host] 탐침 파드를 다시 띄운다"
 kubectl -n keycloak-lab run kc-probe --rm -it --restart=Never \
   --image=curlimages/curl:8.11.1 \
   --env="K0=$K0" --env="K1=$K1" \
@@ -587,7 +627,7 @@ keycloak-0 에 로그인 5회             7.0          5.0
 
 대각선이다. 한 번에 한 쪽만 늘고, `7 + 5 = 12` 로 DB 총계와 맞으므로 어느 엔트리도 두 번 세어지지 않았다.
 
-```bash label="[kc-lab-1] DB 총계를 센다"
+```bash label="[lab host] DB 총계를 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select count(*) from offline_user_session where offline_flag='0'"
 ```
@@ -598,7 +638,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 0b·0c 까지는 추론이다. 여기서 둘째 주입인 문장 로깅을 켠다. 앞의 세 시험이 끝난 지금 켜는 것이고, 시험 0d 가 끝나면 이 절의 마지막에서 곧바로 끈다.
 
-```bash label="[kc-lab-1] ① 문장 로깅과 클라이언트 주소 접두사를 켜고 같은 명령에서 reload 한다"
+```bash label="[lab host] ① 문장 로깅과 클라이언트 주소 접두사를 켜고 같은 명령에서 reload 한다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "alter system set log_statement='all'" \
   -c "alter system set log_line_prefix='%m [%p] %h '" \
@@ -607,7 +647,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 `pg_reload_conf` 가 `t` 를 돌려준다. `%h` 가 클라이언트 주소를 로그 줄 앞에 남기는데, 이것이 없으면 어느 파드가 보낸 질의인지 구별할 수 없어 이 시험의 판정이 성립하지 않는다.
 
-```bash label="[kc-lab-1] ② 두 설정이 실제로 적용됐는지 읽는다"
+```bash label="[lab host] ② 두 설정이 실제로 적용됐는지 읽는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "show log_statement" -c "show log_line_prefix"
 ```
@@ -650,7 +690,7 @@ curl -s -o /dev/null -w '%{http_code}\n' -X POST "http://$K1:8080$TOK" \
 
 `%h` 가 남긴 IP 로 걸러 `keycloak-1` 이 보낸 것만 본다. 거르는 명령은 관찰용 터미널에서 치는데 거기에는 `K0`·`K1` 이 없다. 두 값은 「주입 검증」에서 잡았는데 그 터미널을 지금 탐침 파드 셸이 붙잡고 있으므로, 관찰용 터미널에서 두 줄을 다시 친다.
 
-```bash label="[kc-lab-1] 관찰용 터미널에서도 파드 IP 를 잡는다"
+```bash label="[lab host] 관찰용 터미널에서도 파드 IP 를 잡는다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 echo "$K0 $K1"
@@ -658,11 +698,17 @@ echo "$K0 $K1"
 
 두 값이 「주입 검증」에서 본 것과 같아야 한다. 이 두 줄을 건너뛰고 다음 블록을 치면 `grep "$K1"` 이 `grep ""` 가 되어 모든 줄이 통과하므로, 두 파드가 날린 문장을 `keycloak-1` 만 걸러 낸 것으로 읽게 되고 뒤에서 세는 건수도 양쪽이 같은 값으로 나온다. 화면에는 아무 경고도 안 뜬다.
 
-```bash label="[kc-lab-1] 반대편 노드가 날린 문장만 추린다"
+```bash label="[lab host] 반대편 노드가 날린 문장만 추린다"
 kubectl -n keycloak-lab logs deploy/postgres --since=60s \
   | grep "$K1" | grep 'LOG:  execute'
 ```
 
+:::warning
+
+**요청을 보내자마자 이 명령을 치면 한 줄도 안 나온다.** 이 트랜잭션은 마지막에서 두 번째 문장이 `SET LOCAL synchronous_commit TO OFF` 라 커밋이 미뤄지고, 로그 줄도 그만큼 늦게 나온다. 2026-09-17 에 요청 직후에 쳤더니 `keycloak-1` 쪽에서는 디스커버리 질의 한 줄만 나왔고, 같은 필터를 몇 초 뒤에 다시 치니 아래 여덟 줄이 다 나왔다(observed). **그 첫 화면을 그대로 읽으면 「반대편은 DB 를 안 읽었다 = 복제였다」는 정반대 결론이 나온다.** 몇 초 기다렸다 친다.
+
+:::
+
 실측은 이렇다(observed, `04-read-path-sql.txt`).
 
 ```text
@@ -676,9 +722,9 @@ kubectl -n keycloak-lab logs deploy/postgres --since=60s \
   COMMIT
 ```
 
-`keycloak-1` 은 세션을 DB 에서 읽고 DB 에 쓴다. 파라미터는 `DETAIL` 줄에 있다. sid 는 ③ 이 `SID=` 로 화면에 찍은 값을 옮겨 넣는다 — 그 변수는 탐침 파드 안에만 있어서 `[kc-lab-1]` 셸에서는 `$SID` 가 빈 문자열이다. 로그인할 때마다 새로 생기는 값이기도 하다.
+`keycloak-1` 은 세션을 DB 에서 읽고 DB 에 쓴다. 파라미터는 `DETAIL` 줄에 있다. sid 는 ③ 이 `SID=` 로 화면에 찍은 값을 옮겨 넣는다 — 그 변수는 탐침 파드 안에만 있어서 `[lab host]` 셸에서는 `$SID` 가 빈 문자열이다. 로그인할 때마다 새로 생기는 값이기도 하다.
 
-```bash label="[kc-lab-1] 그 sid 가 들어간 줄만 앞에서 120자씩 본다"
+```bash label="[lab host] 그 sid 가 들어간 줄만 앞에서 120자씩 본다"
 kubectl -n keycloak-lab logs deploy/postgres --since=60s \
   | grep '{{SID}}' | cut -c1-120
 ```
@@ -698,11 +744,18 @@ kubectl -n keycloak-lab logs deploy/postgres --since=60s \
 
 증거 파일에는 IP 대신 `[keycloak-0]` `[keycloak-1]` 이 적혀 있다. 원래 실행 스크립트가 `sed` 로 IP 를 파드 이름으로 바꿔 놓은 것이고, 따라 하는 화면에는 `10.42.0.35` 같은 IP 가 그대로 나온다. pid 도 본다 — `81407` 은 `keycloak-0` 의 연결, `81376` 은 `keycloak-1` 의 연결이며 pid 가 트랜잭션의 경계를 가른다.
 
-이 갱신 트랜잭션은 `01:12:34.934` 의 `BEGIN` 에서 `01:12:34.947` 의 `COMMIT` 까지 13밀리초다. `BEGIN` 과 `COMMIT` 은 sid 를 파라미터로 달지 않아서 위 `grep` 에 안 걸린다. 그래서 화면에 남는 마지막 줄이 `.946` 이고, 거기까지만 세면 12 가 나온다. 경계 두 줄은 같은 pid `81376` 연결에서 나왔고, 실험 기록에 `pid=… |` 꼴로 옮겨 적힌 것으로만 남아 있다(observed). 자기 화면에서 그 둘을 보려면 sid 필터를 빼고 로그에 찍힌 그 pid 로 다시 걸러야 하는데, 그 명령은 원 가이드에 없다(unknown). 그 두 줄이 하는 일은 트랜잭션의 경계를 긋는 것이다. 뒤에 나오는 `SET LOCAL synchronous_commit TO OFF` 가 같은 트랜잭션 안에서 `COMMIT` 직전에 나왔다는 판정이 거기서 나오고, 원 가이드는 그 확인을 「pid 로 경계를 확인했다」로 적는다.
+이 갱신 트랜잭션은 `01:12:34.934` 의 `BEGIN` 에서 `01:12:34.947` 의 `COMMIT` 까지 13밀리초다. `BEGIN` 과 `COMMIT` 은 sid 를 파라미터로 달지 않아서 위 `grep` 에 안 걸린다. 그래서 화면에 남는 마지막 줄이 `.946` 이고, 거기까지만 세면 12 가 나온다. 경계 두 줄은 같은 pid `81376` 연결에서 나왔고, 실험 기록에 `pid=… |` 꼴로 옮겨 적힌 것으로만 남아 있다(observed). 자기 화면에서 그 둘을 보려면 sid 필터를 빼고 로그에 찍힌 그 pid 로 다시 거른다. 원 가이드에는 그 명령이 없어서 2026-09-17 에 만들어 쳐 봤다(observed).
+
+```bash label="[lab host] 그 pid 의 트랜잭션 경계만 본다"
+kubectl -n keycloak-lab logs deploy/postgres --since=5m \
+  | grep '{{PID}}' | grep -E 'BEGIN|COMMIT|synchronous_commit'
+```
+
+`{{PID}}` 는 위 `DETAIL` 줄의 대괄호 안 숫자다 — 그 실험대에서는 `[915]` 였다. 같은 pid 의 `BEGIN` 과 `COMMIT` 사이에 여덟 문장이 들어 있는 것이 보인다. 그 두 줄이 하는 일은 트랜잭션의 경계를 긋는 것이다. 뒤에 나오는 `SET LOCAL synchronous_commit TO OFF` 가 같은 트랜잭션 안에서 `COMMIT` 직전에 나왔다는 판정이 거기서 나오고, 원 가이드는 그 확인을 「pid 로 경계를 확인했다」로 적는다.
 
 파드별 질의 건수는 미검증 형태로 센다(unknown). 여기서도 sid 는 ③ 이 찍은 자기 값이다.
 
-```bash label="[kc-lab-1] 두 파드가 각각 몇 줄을 날렸는지 센다"
+```bash label="[lab host] 두 파드가 각각 몇 줄을 날렸는지 센다"
 kubectl -n keycloak-lab logs deploy/postgres --since=60s \
   | grep '{{SID}}' | grep -c "$K0"
 kubectl -n keycloak-lab logs deploy/postgres --since=60s \
@@ -726,7 +779,7 @@ kubectl -n keycloak-lab logs deploy/postgres --since=60s \
 
 13밀리초짜리 그 트랜잭션에는 셋이 들어 있었다. 낙관적 락(`VERSION` 컬럼), `FOR NO KEY UPDATE ... SKIP LOCKED`, 그리고 `SET LOCAL synchronous_commit TO OFF` 다. 전역 설정은 다르다.
 
-```bash label="[kc-lab-1] 전역 설정을 읽는다"
+```bash label="[lab host] 전역 설정을 읽는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "show synchronous_commit"
 ```
@@ -741,7 +794,7 @@ exit
 
 문장 로깅은 곧바로 끈다.
 
-```bash label="[kc-lab-1] 문장 로깅을 끄고 꺼졌는지 읽는다"
+```bash label="[lab host] 문장 로깅을 끄고 꺼졌는지 읽는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "alter system reset log_statement" -c "alter system reset log_line_prefix" \
   -c "select pg_reload_conf()"
@@ -759,12 +812,12 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **목적** — 다음 실험이 옛 설정 위에서 돌지 않게 한다.
 
-```bash label="[kc-lab-1] ① 두 설정을 읽는다"
+```bash label="[lab host] ① 두 설정을 읽는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "show log_statement" -c "show log_line_prefix"
 ```
 
-```bash label="[kc-lab-1] ② none 이 아니면 두 설정을 되돌리고 reload 한다"
+```bash label="[lab host] ② none 이 아니면 두 설정을 되돌리고 reload 한다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "alter system reset log_statement" -c "alter system reset log_line_prefix" \
   -c "select pg_reload_conf()"
@@ -780,12 +833,12 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **목적** — DB 행과 캐시 엔트리를 함께 비워 다음 실험의 출발값을 0 으로 만든다.
 
-```bash label="[kc-lab-1] ① 세션 행을 지운다"
+```bash label="[lab host] ① 세션 행을 지운다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "delete from offline_user_session"
 ```
 
-```bash label="[kc-lab-1] ② 파드를 갈아 끼워 캐시를 비운다"
+```bash label="[lab host] ② 파드를 갈아 끼워 캐시를 비운다"
 kubectl -n keycloak-lab rollout restart statefulset/keycloak
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s
 ```
@@ -809,7 +862,7 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s
 
 탐침 파드가 지워지지 않았으면 직접 지운다.
 
-```bash label="[kc-lab-1] --rm 이 안 먹었을 때"
+```bash label="[lab host] --rm 이 안 먹었을 때"
 kubectl -n keycloak-lab delete pod kc-probe --ignore-not-found
 ```
 
@@ -838,7 +891,10 @@ kubectl -n keycloak-lab delete pod kc-probe --ignore-not-found
 이 절차의 숫자는 `2026-09-04 09:52–10:14 KST` 에 돈 한 번의 실행에서 나왔다(observed).
 
 - (observed) 파드 IP `10.42.1.43`·`10.42.0.35`, 뷰 ID `5` 와 멤버 `(2)`, `jgroups_ping` 의 `coord = t` 하나, 캐시 델타 전량, `7 + 5 = 12`, `keycloak-1` 이 날린 SQL 여덟 줄, pid `81407`/`81376`, 비밀번호 길이 `19`.
-- (unknown) `tr ',' '\n' | grep -E` 로 자른 Prometheus 출력, JWT 를 디코드해 sid 를 뽑는 `sed` 줄, `CID` 를 뽑는 줄, 두 노드에 `grep -c` 를 도는 `for` 루프, 파드별 질의 건수를 세는 두 줄. 가이드가 미검증으로 표시했고 원래 실행은 스크립트로 했다.
+- (observed) 2026-09-17 에 기반 가이드 7단계로 실험대를 새로 세우고 이 절차를 처음부터 다시 밟았다. 가이드가 미검증으로 표시했던 줄이 전부 돌았다 — `tr ',' '\n' | grep -E` 로 자른 Prometheus 출력, JWT 를 디코드해 sid 를 뽑는 `sed` 줄, `CID` 를 뽑는 줄, 두 노드에 `grep -c` 를 도는 `for` 루프.
+- (observed) 같은 날 다시 나온 판정 — 반대편 노드의 refresh 가 `200` 이고 sid 가 같은 것, 반대편 로그아웃 뒤 발급 노드가 `400 invalid_grant / Session not active` 를 내는 것, 로그인 한 번에 발급 노드만 `+1` 이고 반대편은 `+0` 인 것, 로그인을 몰아준 쪽만 늘어 `9 + 5 = 14` 가 DB 총계 `14` 와 맞는 것, 반대편이 날린 SQL 여덟 줄이 같은 순서로 나온 것.
+- (observed) 같은 날 새로 드러난 것 — 요청 직후에 로그를 거르면 반대편 문장이 한 줄도 안 나온다는 것, pid 로 거르면 `BEGIN`~`COMMIT` 경계가 보인다는 것, 토큰 길이가 `612자`·`758자` 로 원래 실행과 다르다는 것.
+- (unknown) 파드별 질의 건수를 세는 두 줄은 이번에도 그대로 치지 않았다. 원래 실행은 스크립트로 했다.
 - 트랜잭션 경계 시각 `01:12:34.934` 와 `01:12:34.947` 은 실험 기록 한 벌에만 있다. `04-read-path-sql.txt` 에 보존된 것은 sid 가 걸린 `DETAIL` 줄과 시각 없는 문장 목록이라 타임스탬프가 붙은 `BEGIN`/`COMMIT` 이 없다. 그래서 13밀리초를 증거 원문으로 다시 확인할 수는 없다.
 - 캐시 설정은 파일에서 읽을 수 없다. `cache-ispn.xml` 에는 `<transport/>` 뿐이고, 「세션은 DB 로 공유된다」는 판정은 설정을 읽어서가 아니라 동작을 측정해서 얻었다.
 - 스크립트를 안 쓰는 까닭도 측정 실패에서 나왔다(observed). `kubectl run --rm -i ... | grep` 로 받았더니 중간 조각이 통째로 사라져 `keycloak-1` 의 스냅샷과 다음 마커가 함께 없어졌고, 전값이 0 으로 잡히면서 가짜 델타가 만들어졌다. 그때 리포트는 `keycloak-1` 이 `+9`, `+7` 증가한 것처럼 보였다 — 없는 복제가 있는 것처럼 보이는 오류다. 다른 하나는 중첩 인용이다. `ssh host '... $VAR ...'` 안에 다시 `sh -c "..."` 를 넣으면 인용이 세 겹이 되어 치환이 조용히 깨졌고, 첫 시도에서 파드 IP 가 빈 문자열이 되어 아무 출력도 나오지 않았다.
diff --git a/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a1-jgroups-transport-block.md b/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a1-jgroups-transport-block.md
index 483d541..8100136 100644
--- a/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a1-jgroups-transport-block.md
+++ b/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a1-jgroups-transport-block.md
@@ -43,11 +43,13 @@ NetworkPolicy 로 8080 과 9000 만 열어 JGroups 트랜스포트인 TCP 7800 
 
 ## 읽기 전에 — 어디서 치는가
 
-`kubectl` 은 `[kc-lab-1]` 에서 친다. `conntrack` 은 노드 자체를 건드리는 명령이라 게스트 셸이 필요하고 두 노드 모두에서 봐야 한다 — 이쪽 노드는 그대로 치고 반대 노드는 `ssh kc-lab-2` 로 붙어서 친다. `kubectl` 에는 `sudo` 를 붙이지 않는다. root 홈에 `~/.kube/config` 가 없어서 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다. 코드블록마다 어느 셸인지 붙여 두었다.
+`kubectl` 은 `[lab host]` 에서 친다. `conntrack` 은 노드 자체를 건드리는 명령이라 게스트 셸이 필요하고 두 노드 모두에서 봐야 한다 — 이쪽 노드는 그대로 치고 반대 노드는 `ssh kc-lab-2` 로 붙어서 친다. `kubectl` 에는 `sudo` 를 붙이지 않는다. root 홈에 `~/.kube/config` 가 없어서 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다. 코드블록마다 어느 셸인지 붙여 두었다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 주입에 쓰는 매니페스트 경로 `deploy/lab/k8s/a1-block-jgroups-transport.yaml` 는 저장소 상대경로다. 체크아웃을 `kc-lab-1` 의 어디에 뒀는지는 원 가이드에 없고 거기로 옮기는 명령도 없으므로(unknown), 이 상대경로가 그대로 통하는 디렉터리에서 시작한다. 다른 디렉터리에서 치면 `cat` 도 `kubectl apply` 도 파일을 못 찾고 끝난다.
 
-터미널은 둘을 연다. 하나는 임시 curl 파드용, 하나는 관찰용이다. 그래서 `[kc-lab-1]` 라벨이 붙은 블록이 `[탐침 파드]` 블록 사이에 끼어 있으면 **관찰용 터미널에서 친다** — 파드 셸을 나가라는 뜻이 아니다. 나가라고 할 때는 `exit` 를 블록으로 따로 적는다.
+터미널은 둘을 연다. 하나는 임시 curl 파드용, 하나는 관찰용이다. 그래서 `[lab host]` 라벨이 붙은 블록이 `[탐침 파드]` 블록 사이에 끼어 있으면 **관찰용 터미널에서 친다** — 파드 셸을 나가라는 뜻이 아니다. 나가라고 할 때는 `exit` 를 블록으로 따로 적는다.
 
 | 무엇 | 값 |
 |---|---|
@@ -82,7 +84,7 @@ A-0 은 세션이 Infinispan 복제가 아니라 PostgreSQL 로 공유된다고
 
 **이건 상태를 부수는 실험이다.** Keycloak 클러스터를 실제로 분단시키고 파드를 재시작한다. **실험대에서만 한다.** 중간에 그만두려면 아래 한 줄이면 된다.
 
-```bash label="[kc-lab-1] 중간에 그만둘 때 치는 한 줄"
+```bash label="[lab host] 중간에 그만둘 때 치는 한 줄"
 kubectl -n keycloak-lab delete networkpolicy a1-block-jgroups-transport
 ```
 
@@ -98,15 +100,15 @@ kubectl -n keycloak-lab delete networkpolicy a1-block-jgroups-transport
 
 **무엇을 보는가** — 파드 둘의 상태와 배치, 그리고 뒤에서 쓸 파드 주소.
 
-```bash label="[kc-lab-1] ① 노드를 본다"
+```bash label="[lab host] ① 노드를 본다"
 kubectl get nodes
 ```
 
-```bash label="[kc-lab-1] ② 파드가 어느 노드에 있는지 본다"
+```bash label="[lab host] ② 파드가 어느 노드에 있는지 본다"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
-```bash label="[kc-lab-1] ③ 파드 주소 두 개를 변수에 담는다"
+```bash label="[lab host] ③ 파드 주소 두 개를 변수에 담는다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 echo "$K0 $K1"
@@ -120,7 +122,7 @@ echo "$K0 $K1"
 
 **무엇을 보는가** — 네임스페이스에 이미 걸린 NetworkPolicy.
 
-```bash label="[kc-lab-1] 네임스페이스의 정책 목록"
+```bash label="[lab host] 네임스페이스의 정책 목록"
 kubectl -n keycloak-lab get networkpolicy
 ```
 
@@ -136,7 +138,7 @@ No resources found in keycloak-lab namespace.
 
 **무엇을 보는가** — 두 노드가 같은 멤버 목록을 찍고 있는지.
 
-```bash label="[kc-lab-1] 양쪽 로그에서 마지막 클러스터 뷰 한 줄씩"
+```bash label="[lab host] 양쪽 로그에서 마지막 클러스터 뷰 한 줄씩"
 kubectl -n keycloak-lab logs keycloak-0 | grep ISPN000094 | tail -1
 kubectl -n keycloak-lab logs keycloak-1 | grep ISPN000094 | tail -1
 ```
@@ -154,7 +156,7 @@ kubectl -n keycloak-lab logs keycloak-1 | grep ISPN000094 | tail -1
 
 **무엇을 보는가** — `JGROUPS_PING` 의 세 열.
 
-```bash label="[kc-lab-1] 디스커버리 테이블 세 열"
+```bash label="[lab host] 디스커버리 테이블 세 열"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select name, ip, coord from jgroups_ping order by name"
 ```
@@ -175,20 +177,20 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **무엇을 보는가** — 각 노드가 스스로 세는 클러스터 크기.
 
-```bash label="[kc-lab-1] ① 한 줄짜리 JSON 을 통째로 본다"
+```bash label="[lab host] ① 한 줄짜리 JSON 을 통째로 본다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size'
 ```
 
 라벨을 보고 나면 읽기 좋게 자른다. 아래 두 줄은 가이드가 미검증으로 표시했고(unknown), 둘째 줄은 `jq` 가 깔려 있는 환경용이라 이 실험대에서는 쓸 수 없다.
 
-```bash label="[kc-lab-1] ② 라벨을 보고 나서 필요한 줄만 자른다"
+```bash label="[lab host] ② 라벨을 보고 나서 필요한 줄만 자른다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size' \
   | tr ',' '\n' | grep -E '"pod":|^"[0-9]'
 ```
 
-```bash label="[kc-lab-1] ③ jq 가 있는 환경이라면 이 형태 — 이 실험대에는 jq 가 없다"
+```bash label="[lab host] ③ jq 가 있는 환경이라면 이 형태 — 이 실험대에는 jq 가 없다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size' \
   | jq -r '.data.result[] | "\(.metric.pod) \(.metric.node) \(.value[1])"'
@@ -198,7 +200,7 @@ kubectl -n observability exec deploy/prometheus -- \
 
 JGroups 카운터도 지금 0 인 것을 봐 둔다.
 
-```bash label="[kc-lab-1] 병합 이벤트 계수기"
+```bash label="[lab host] 병합 이벤트 계수기"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_jgroups_merge3_get_num_merge_events'
 ```
@@ -216,7 +218,7 @@ vendor_jgroups_fd_sock2_get_num_suspected_members 0.0 (양쪽 노드)
 
 임시 파드를 띄우고 그 안에서 A-0 과 같은 순서로 로그인·refresh·로그아웃을 친다. 임시 파드인 까닭은 셋이다. Keycloak 이미지에 `curl` 이 없어 Keycloak 파드 안에서는 못 치고, 토큰을 단계 사이로 넘겨야 하니 한 셸 안에서 다 끝내야 하며, Service 로 보내면 어느 노드가 처리했는지 알 수 없다. 이 실험의 질문 자체가 「어느 노드인가」라서 파드 주소로 직접 친다.
 
-```bash label="[kc-lab-1] 임시 curl 파드를 띄우고 그 안의 셸로 들어간다"
+```bash label="[lab host] 임시 curl 파드를 띄우고 그 안의 셸로 들어간다"
 kubectl -n keycloak-lab run kc-probe --rm -it --restart=Never \
   --image=curlimages/curl:8.11.1 \
   --env="K0=$K0" --env="K1=$K1" \
@@ -293,7 +295,7 @@ exit
 
 **목적** — 8080 과 9000 은 열어 둔 채 7800 으로 오는 새 연결만 막는다.
 
-```bash label="[kc-lab-1] ① 매니페스트를 먼저 읽는다"
+```bash label="[lab host] ① 매니페스트를 먼저 읽는다"
 cat deploy/lab/k8s/a1-block-jgroups-transport.yaml
 ```
 
@@ -321,7 +323,7 @@ spec:
 
 매니페스트 안에 `metadata.namespace` 가 `keycloak-lab` 으로 적혀 있다. ② 의 `apply` 에는 `-n` 이 없으니 네임스페이스는 이 줄이 정한다. 손으로 옮겨 적다 이 줄을 빠뜨리면 정책이 `default` 네임스페이스에 걸린다. 거기에는 `app=keycloak` 인 파드가 없으니 정책은 만들어지는데 아무 파드도 안 잡힌다.
 
-```bash label="[kc-lab-1] ② 적용하고 시각을 남긴다"
+```bash label="[lab host] ② 적용하고 시각을 남긴다"
 kubectl apply -f deploy/lab/k8s/a1-block-jgroups-transport.yaml
 date '+%H:%M:%S 적용'
 ```
@@ -343,14 +345,14 @@ networkpolicy.networking.k8s.io/a1-block-jgroups-transport created
 
 ### 1. 정책이 어떤 파드를 잡았는가
 
-```bash label="[kc-lab-1] 정책 목록과 상세"
+```bash label="[lab host] 정책 목록과 상세"
 kubectl -n keycloak-lab get networkpolicy
 kubectl -n keycloak-lab describe networkpolicy a1-block-jgroups-transport
 ```
 
 `To Port` 목록에 7800 이 없는 것, 그리고 `PodSelector` 가 `app=keycloak` 인 것을 본다. 오타로 아무 파드도 안 잡히면 정책은 걸렸는데 아무 일도 일어나지 않는다.
 
-```bash label="[kc-lab-1] 파드가 죽지 않았는지 본다"
+```bash label="[lab host] 파드가 죽지 않았는지 본다"
 kubectl -n keycloak-lab get pods -o wide | grep keycloak
 ```
 
@@ -358,7 +360,7 @@ kubectl -n keycloak-lab get pods -o wide | grep keycloak
 
 ### 2. 열어 둔 포트는 살아 있고 막은 포트는 죽었는가
 
-```bash label="[kc-lab-1] 임시 파드를 띄운다"
+```bash label="[lab host] 임시 파드를 띄운다"
 kubectl -n keycloak-lab run kc-probe --rm -it --restart=Never \
   --image=curlimages/curl:8.11.1 --env="K0=$K0" --env="K1=$K1" --command -- sh
 ```
@@ -387,7 +389,7 @@ exit
 
 ### 3. 그런데 클러스터가 안 깨졌다
 
-```bash label="[kc-lab-1] 두 노드가 아는 멤버 수를 다시 본다"
+```bash label="[lab host] 두 노드가 아는 멤버 수를 다시 본다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size'
 ```
@@ -402,7 +404,7 @@ kubectl -n observability exec deploy/prometheus -- \
 
 여기서 실험 실패라고 결론 내리면 틀린다. 파드 안 소켓을 본다. Keycloak 이미지에는 `ss` 도 없으므로 `/proc` 을 직접 읽는다.
 
-```bash label="[kc-lab-1] 7800 은 16진수로 1E78 이다"
+```bash label="[lab host] 7800 은 16진수로 1E78 이다"
 kubectl -n keycloak-lab exec keycloak-0 -- cat /proc/net/tcp6 | grep 1E78
 ```
 
@@ -429,13 +431,42 @@ keycloak-1: ...23002A0A:9C57  ...2B012A0A:1E78  01
 
 ### 4. conntrack 을 두 노드 모두에서 본다
 
+여기부터는 게스트 셸이다. lab host 에서 먼저 들어간다.
+
+```bash label="[lab host] 이쪽 노드에 붙는다"
+ssh kc-lab-1
+```
+
 ```bash label="[kc-lab-1] 이 노드의 conntrack 표를 본다"
 sudo conntrack -L 2>/dev/null | grep 7800
 ```
 
+:::warning
+
+**게스트에 `conntrack` 이 깔려 있지 않다.** cloud-init 이 까는 것은 `curl` 과 `nftables` 뿐이라 이 명령은 `sudo: conntrack: command not found` 로 끝나는데, **`2>/dev/null` 이 그 한 줄을 지우고 종료 코드도 `0` 이다.** 화면에는 아무것도 안 나오고, 그 빈 화면은 「7800 연결이 없다 = 정책이 먹었다」로 읽힌다 — 이 절이 보여 주려는 것과 정반대다. 2026-09-17 에 갓 만든 게스트에서 그대로 겪었다(observed). 두 노드 모두에 먼저 깐다.
+
+:::
+
+```bash label="[lab host] 없으면 먼저 깐다"
+sudo apt install -y conntrack
+```
+
+깔고 나면 문서가 적은 두 줄이 그대로 나온다(2026-09-17, observed).
+
+```text
+tcp      6 86398 ESTABLISHED src=10.42.0.13 dst=10.42.1.7 sport=59725 dport=7800 src=10.42.1.7 dst=10.42.0.13 sport=7800 dport=59725 [ASSURED] mark=0 use=1
+tcp      6 85885 ESTABLISHED src=10.42.0.13 dst=10.42.1.7 sport=38439 dport=57800 src=10.42.1.7 dst=10.42.0.13 sport=57800 dport=38439 [ASSURED] mark=0 use=1
+```
+
+**깔지 않고 보는 방법도 있다.** 커널 표를 직접 읽으면 같은 내용이 나온다 — 앞에 `ipv4 2` 두 칸이 더 붙고 `zone=0` 이 더 붙는 것만 다르다(observed).
+
+```bash label="[kc-lab-1] 패키지 없이 커널 표를 직접 읽는다"
+sudo grep 7800 /proc/net/nf_conntrack
+```
+
 반대편 노드는 붙어서 친다. 아래 세 줄 형태는 이 실험대에서 치지 않았다(unknown) — 원래 실행은 `ssh kc-lab-2 'sudo conntrack -L 2>/dev/null | grep 7800'` 한 줄로 쳤고, 한 줄에 원격 접속과 원격 셸의 인용을 겹쳐 놓는 대신 행동 하나를 명령 하나로 나눴다.
 
-```bash label="[kc-lab-1] ① 반대편 노드에 붙는다"
+```bash label="[lab host] ① 반대편 노드에 붙는다"
 ssh kc-lab-2
 ```
 
@@ -443,6 +474,8 @@ ssh kc-lab-2
 sudo conntrack -L 2>/dev/null | grep 7800
 ```
 
+**이 노드에도 따로 깔아야 한다.** 패키지는 노드마다이고, 여기서도 안 깔린 채로 치면 위와 같은 빈 화면이 나온다.
+
 ```bash label="[kc-lab-2] ③ 나온다"
 exit
 ```
@@ -460,7 +493,7 @@ exit
   tcp 6 33 SYN_SENT src=10.42.1.58 dst=10.42.0.35 sport=34824 dport=7800 [UNREPLIED] ...
 ```
 
-`2>/dev/null` 은 `conntrack` 이 stderr 로 찍는 「N flow entries have been shown」 요약을 지우려는 것이고, 처음에는 빼고 쳐서 그 줄도 한번 본다. 상태 열을 읽는다 — `ESTABLISHED` 는 양방향 통신이 성립해 규칙 평가를 건너뛰고, `[ASSURED]` 는 표가 꽉 차도 안 지워지는 오래된 연결이며, `SYN_SENT [UNREPLIED]` 가 정책이 동작하고 있다는 것을 보여 준다. `dport=57800` 도 ESTABLISHED 로 살아 있다. NetworkPolicy 는 이미 붙어 있는 연결을 떼어내지 못하므로, 보안 사고 대응으로 「지금 당장 이 통신을 끊어라」에 NetworkPolicy 를 걸면 새 연결만 막히고 진행 중인 연결은 계속된다. 같은 7800 을 한 방향만 끊는 A-5 가 NetworkPolicy 대신 `iptables` 의 raw PREROUTING 으로 간 까닭도 여기서 나왔다 — 그 체인은 conntrack 조회보다 먼저 평가된다.
+`2>/dev/null` 은 `conntrack` 이 stderr 로 찍는 「N flow entries have been shown」 요약을 지우려는 것이고, **처음에는 반드시 빼고 친다** — 위에서 본 `command not found` 가 거기로 나가기 때문이다. 상태 열을 읽는다 — `ESTABLISHED` 는 양방향 통신이 성립해 규칙 평가를 건너뛰고, `[ASSURED]` 는 표가 꽉 차도 안 지워지는 오래된 연결이며, `SYN_SENT [UNREPLIED]` 가 정책이 동작하고 있다는 것을 보여 준다. `dport=57800` 도 ESTABLISHED 로 살아 있다. NetworkPolicy 는 이미 붙어 있는 연결을 떼어내지 못하므로, 보안 사고 대응으로 「지금 당장 이 통신을 끊어라」에 NetworkPolicy 를 걸면 새 연결만 막히고 진행 중인 연결은 계속된다. 같은 7800 을 한 방향만 끊는 A-5 가 NetworkPolicy 대신 `iptables` 의 raw PREROUTING 으로 간 까닭도 여기서 나왔다 — 그 체인은 conntrack 조회보다 먼저 평가된다.
 
 ### 5. conntrack 항목을 튜플 그대로 지운다
 
@@ -482,7 +515,7 @@ sudo conntrack -D -p tcp -s 10.42.0.35 -d 10.42.1.43 --sport 50477 --dport 57800
 
 `kc-lab-2` 에서도 같은 일을 한다. 서버 쪽 노드에는 튜플이 뒤집혀 기록되어 있으므로, 그쪽에 붙어 그쪽 `-L` 출력을 보고 옮긴다.
 
-```bash label="[kc-lab-1] ① 반대편 노드에 붙는다"
+```bash label="[lab host] ① 반대편 노드에 붙는다"
 ssh kc-lab-2
 ```
 
@@ -510,12 +543,12 @@ exit
 
 **목적** — 새로 뜨는 노드가 7800 으로 JOIN 을 보내다 실패하게 만들어 분단을 확실히 만든다.
 
-```bash label="[kc-lab-1] ① 시각을 남기고 파드를 지운다"
+```bash label="[lab host] ① 시각을 남기고 파드를 지운다"
 date '+%H:%M:%S 재시작'
 kubectl -n keycloak-lab delete pod keycloak-0
 ```
 
-```bash label="[kc-lab-1] ② 새 파드와 새 주소를 다시 잡는다"
+```bash label="[lab host] ② 새 파드와 새 주소를 다시 잡는다"
 kubectl -n keycloak-lab get pods -o wide | grep keycloak
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 echo "$K0"
@@ -537,7 +570,7 @@ keycloak-0   false   10.42.1.67   2026-09-04T02:44:23Z
 
 ## 관찰
 
-```bash label="[kc-lab-1] 두 노드가 아는 멤버 수"
+```bash label="[lab host] 두 노드가 아는 멤버 수"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size'
 ```
@@ -551,7 +584,7 @@ kubectl -n observability exec deploy/prometheus -- \
 
 양쪽 다 1 이다. 서로를 멤버로 안 세고 있고, 로그가 까닭을 말한다.
 
-```bash label="[kc-lab-1] 합류 시도와 클러스터 뷰를 한 번에 본다"
+```bash label="[lab host] 합류 시도와 클러스터 뷰를 한 번에 본다"
 kubectl -n keycloak-lab logs keycloak-0 | grep -E "GMS|ISPN000094" | tail -20
 ```
 
@@ -567,7 +600,7 @@ ISPN000094: new cluster view [keycloak-0-26403|0] (1) [keycloak-0-26403]
 
 split brain 은 DB 한 줄로 확인된다.
 
-```bash label="[kc-lab-1] 코디네이터가 몇인지 센다"
+```bash label="[lab host] 코디네이터가 몇인지 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select name, ip, coord from jgroups_ping order by name"
 ```
@@ -585,18 +618,48 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 분단된 노드는 스스로 트래픽에서 빠진다.
 
-```bash label="[kc-lab-1] Ready 와 재시작 횟수만 뽑아 본다"
-kubectl -n keycloak-lab get pods -o custom-columns=\
-NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount \
+```bash label="[lab host] Ready 와 재시작 횟수만 뽑아 본다"
+kubectl -n keycloak-lab get pods \
+  -o "custom-columns=NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount" \
   | grep keycloak
 ```
 
-실측은 `keycloak-0 false 0`, `keycloak-1 true 0` 이다(observed, `11-service-impact.txt`). 까닭은 헬스 본문에 있다.
+**`-o` 값을 따옴표로 묶는다.** 묶지 않으면 zsh 가 `[0]` 을 글로브로 읽어 명령이 아예 안 돈다 — 이 실험대의 lab host 가 zsh 다(2026-09-17, observed).
 
-```bash label="[kc-lab-1] 파드 조건을 본다"
+```text
+zsh: no matches found: custom-columns=NAME:.metadata.name,READY:.status.containerStatuses[0].ready,...
+```
+
+실측은 `keycloak-0 false 0`, `keycloak-1 true 0` 이다(observed, `11-service-impact.txt`). 2026-09-17 에도 같은 두 줄이 나왔다(observed).
+
+**그 `false` 는 파드를 지우자마자 나오지 않는다.** readiness 프로브가 `periodSeconds: 10` · `failureThreshold: 3` 이라 헬스가 먼저 `503` 이 되고 그로부터 최대 30초 뒤에 조건이 뒤집힌다. 2026-09-17 에 지운 지 60초 시점에는 헬스가 이미 `503` 인데 파드는 아직 `1/1 Ready=True` 였다(observed). **그 시점 화면만 보고 「분단이 서비스에 안 잡혔다」로 읽지 않는다** — 1~2분 두고 다시 본다.
+
+까닭은 헬스 본문에 있다.
+
+```bash label="[lab host] 파드 조건을 본다"
 kubectl -n keycloak-lab describe pod keycloak-0 | grep -A5 Conditions
 ```
 
+이 명령이 내는 것은 조건표다(2026-09-17, observed).
+
+```text
+Conditions:
+  Type                        Status
+  PodReadyToStartContainers   True
+  Initialized                 True
+  Ready                       False
+  ContainersReady             False
+```
+
+**아래 JSON 은 이 명령의 출력이 아니다.** 헬스 엔드포인트를 직접 쳐야 나온다 — 그 명령이 원 가이드에 없어서 2026-09-17 에 만들어 쳤다(observed).
+
+```bash label="[lab host] 분단된 노드의 헬스 본문을 직접 받는다"
+K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
+kubectl -n keycloak-lab run hp --rm -i --restart=Never \
+  --image=curlimages/curl:8.11.1 --quiet --env="K0=$K0" \
+  --command -- sh -c 'curl -s "http://$K0:9000/health/ready"'
+```
+
 실측은 이렇다(observed).
 
 ```json
@@ -609,24 +672,37 @@ kubectl -n keycloak-lab describe pod keycloak-0 | grep -A5 Conditions
 
 Keycloak 은 클러스터 분단을 readiness 로 신고한다. DB 는 UP 인데 클러스터가 DOWN 이고, 쿠버네티스가 그 신고를 받아 처리한다.
 
-```bash label="[kc-lab-1] Service 뒤에 누가 남았는지 본다"
+```bash label="[lab host] Service 뒤에 누가 남았는지 본다"
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 ```
 
-실측은 `ready 주소: [10.42.0.35]`, `notReady : [10.42.1.67]` 다(observed). `kubectl get endpoints` 는 v1.33 부터 deprecated 라 경고가 뜨므로 쓰지 않는다.
+여기도 `-o` 값을 따옴표로 묶는다. `[*]` 가 앞의 `[0]` 과 같은 이유로 글로브다.
 
-```bash label="[kc-lab-1] 밖에서 정문을 친다"
+실측은 `ready 주소: [10.42.0.35]`, `notReady : [10.42.1.67]` 다(observed). 2026-09-17 에는 이렇게 나왔다(observed).
+
+```text
+NAME             ADDR                        READY
+keycloak-lxk8h   [10.42.0.13],[10.42.1.17]   true,false
+``` `kubectl get endpoints` 는 v1.33 부터 deprecated 라 경고가 뜨므로 쓰지 않는다.
+
+```bash label="[lab host] 밖에서 정문을 친다"
 curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master
 ```
 
+인증서 단계를 건너뛴 실험대라면 443 을 듣는 것이 없어 여기는 `000` 이다. 그때는 TLS 를 빼고 `Host` 헤더를 실어 엣지에 친다 — 2026-09-17 에 이 형태로 `200` 을 받았다(observed).
+
+```bash label="[lab host] TLS 없이 같은 것을 잰다"
+curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: auth.hyeonworks.com' http://192.168.122.10/realms/master
+```
+
 실측은 정문이 `HTTP 200`, 토큰 발급도 `HTTP 200` 이다(observed). 분단된 노드가 스스로 로드밸런서에서 빠졌고 서비스는 계속됐다. liveness 였다면 재시작을 반복했을 텐데 재시작해도 안 나아지는 문제이므로 readiness 로 격리하는 쪽이 맞는 신호다. 다만 비대칭이라서 살았다 — `keycloak-1` 은 멤버가 하나 줄어든 정상적인 사건이라 Ready 를 유지했고, `keycloak-0` 은 합류 자체를 못 해 DOWN 이 됐다. 양쪽이 동시에 DOWN 이 되는 경로가 있다면 전면 장애이고, 그것이 A-5 의 주제다.
 
 본 시험은 Service 를 쓰면 안 된다. `keycloak-0` 이 NotReady 라 Service 로 보내면 전부 `keycloak-1` 로 간다. 새 주소로 임시 파드를 다시 띄우고 파드 주소로 직접 친다.
 
 `keycloak-0` 을 지웠으므로 `$K0` 가 낡았다. 두 주소를 다시 잡고 그 값으로 파드를 띄운다. `$PW` 도 여기서 다시 넣는다 — 앞의 포트 시험 파드에는 안 넣었다.
 
-```bash label="[kc-lab-1] ① 새 주소를 잡고 탐침 파드를 다시 띄운다"
+```bash label="[lab host] ① 새 주소를 잡고 탐침 파드를 다시 띄운다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 kubectl -n keycloak-lab run kc-probe --rm -it --restart=Never \
@@ -664,7 +740,22 @@ curl -s -w '\n%{http_code}\n' -X POST "http://$K0:8080$TOK" \
   -d grant_type=refresh_token -d client_id=admin-cli -d "refresh_token=$RT"
 ```
 
-네 단계를 다 쳤으면 파드 셸에서 나온다. 뒤의 명령은 전부 `[kc-lab-1]` 이고, 나가지 않으면 `kubectl` 도 `psql` 도 없는 `curlimages/curl` 안에서 치게 된다.
+:::warning
+
+**[4] 는 응답 본문을 통째로 찍는다.** 분단 중에는 그 요청이 성공하므로 `access_token` 과 `refresh_token` 이 화면에 그대로 나오고, 화면을 갈무리하면 증거 파일에도 그대로 들어간다. 2026-09-17 실행에서 실제로 그렇게 나와 길이만 남기고 가렸다(observed). 판정에 필요한 것은 코드와 `error` 뿐이므로, 갈무리할 생각이면 아래 형태로 친다.
+
+:::
+
+```sh label="[탐침 파드] [4] 를 토큰 없이 재는 형태"
+curl -s -X POST "http://$K0:8080$TOK" \
+  -d grant_type=refresh_token -d client_id=admin-cli -d "refresh_token=$RT" \
+  -w '\n%{http_code}\n' -o /tmp/r
+sed -n 's/.*"error":"\([^"]*\)".*/error=\1/p' /tmp/r
+```
+
+`200` 이면 `error` 줄이 안 나오고, 그 없음이 곧 「로그아웃이 전파되지 않았다」다.
+
+네 단계를 다 쳤으면 파드 셸에서 나온다. 뒤의 명령은 전부 `[lab host]` 이고, 나가지 않으면 `kubectl` 도 `psql` 도 없는 `curlimages/curl` 안에서 치게 된다.
 
 ```sh label="[탐침 파드] ③ 나온다. --rm 이 파드를 지운다"
 exit
@@ -683,7 +774,7 @@ exit
 
 [4] 의 200 이 로그아웃이 아예 안 됐다는 뜻인지 확인한다. sid 는 [1] 에서 JWT payload 를 풀어 화면에 찍고 적어 둔 그 값이다. 로그인할 때마다 새로 생기므로 자기 실행의 값을 넣는다.
 
-```bash label="[kc-lab-1] 그 세션의 DB 행이 남아 있는지 본다"
+```bash label="[lab host] 그 세션의 DB 행이 남아 있는지 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select user_session_id, offline_flag, last_session_refresh
       from offline_user_session where user_session_id='{{SID}}'"
@@ -699,7 +790,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 (0 rows)                                            ← DB 행은 삭제되었다
 ```
 
-```bash label="[kc-lab-1] 세션 캐시 엔트리를 노드별로 본다"
+```bash label="[lab host] 세션 캐시 엔트리를 노드별로 본다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_statistics_approximate_entries_unique{cache="sessions"}'
 ```
@@ -724,12 +815,12 @@ kubectl -n observability exec deploy/prometheus -- \
 
 **목적** — 7800 을 다시 열어 두 노드가 하나의 뷰로 합쳐지게 한다.
 
-```bash label="[kc-lab-1] ① 시각을 남기고 정책을 지운다"
+```bash label="[lab host] ① 시각을 남기고 정책을 지운다"
 date '+%H:%M:%S 해제'
 kubectl -n keycloak-lab delete networkpolicy a1-block-jgroups-transport
 ```
 
-```bash label="[kc-lab-1] ② 30초 간격으로 멤버 수를 몇 번 친다"
+```bash label="[lab host] ② 30초 간격으로 멤버 수를 몇 번 친다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size'
 ```
@@ -755,7 +846,7 @@ networkpolicy.networking.k8s.io "a1-block-jgroups-transport" deleted from keyclo
 
 **목적** — 재형성이 저절로 일어난 것인지 확인한다.
 
-```bash label="[kc-lab-1] 병합 이벤트 계수기를 다시 읽는다"
+```bash label="[lab host] 병합 이벤트 계수기를 다시 읽는다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_jgroups_merge3_get_num_merge_events'
 ```
diff --git a/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a7-volatile-comparison.md b/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a7-volatile-comparison.md
index 4d709e9..24cbf6f 100644
--- a/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a7-volatile-comparison.md
+++ b/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a7-volatile-comparison.md
@@ -45,11 +45,15 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 ## 읽기 전에 — 어디서 치는가
 
-명령을 치는 곳이 둘이다. 대부분은 `[kc-lab-1]` 에서 `kubectl` 로 치고, `iptables` 만 노드 자체를 건드리므로 `kc-lab-1` 과 `kc-lab-2` 에 각각 들어가 친다. 코드블록마다 `label` 로 어디서 치는지 붙였다.
+명령을 치는 곳이 둘이다. 대부분은 `[lab host]` 에서 `kubectl` 로 치고, `iptables` 만 노드 자체를 건드리므로 `kc-lab-1` 과 `kc-lab-2` 에 각각 들어가 친다. 코드블록마다 `label` 로 어디서 치는지 붙였다.
+
+**`[kc-lab-1]` 라벨이 붙은 블록은 게스트 셸이다.** lab host 에서 `ssh kc-lab-1` 로 들어가서 치고, 끝나면 `exit` 로 나온다. `ssh kc-lab-2 '…'` 한 줄 형태는 lab host 에서 그대로 쳐도 되므로 `[lab host]` 로 두었다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 `kubectl` 에 `sudo` 를 붙이지 않는다. 실험 폴더의 README 가 까닭을 적는다 — `sudo` 를 붙이면 root 환경으로 돌아 그 kubeconfig 를 못 본다. root 홈에는 `~/.kube/config` 가 없으므로 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝나고, 그러면 클러스터가 아니라 누구의 설정 파일을 읽느냐가 문제인데 클러스터를 의심하게 된다.
 
-```bash label="[kc-lab-1] 두 형태의 차이"
+```bash label="[lab host] 두 형태의 차이"
 kubectl -n keycloak-lab get pods        # 이렇게
 sudo kubectl -n keycloak-lab get pods   # 이렇게 치면 안 된다
 ```
@@ -99,7 +103,7 @@ A-1 은 인터넷 자료의 통념과 어긋난 답을 냈고 그 까닭을 「2
 
 중간에 그만두려면 두 가지를 되돌린다. `args` 쪽은 이 두 줄이다.
 
-```bash label="[kc-lab-1] args 를 기본값으로 되돌린다"
+```bash label="[lab host] args 를 기본값으로 되돌린다"
 kubectl -n keycloak-lab patch statefulset keycloak --type=json \
   -p '[{"op":"replace","path":"/spec/template/spec/containers/0/args","value":["start"]}]'
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
@@ -111,7 +115,7 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
 sudo iptables -t raw -F PREROUTING
 ```
 
-```bash label="[kc-lab-1] 반대 노드로 붙는다"
+```bash label="[lab host] 반대 노드로 붙는다"
 ssh kc-lab-2
 ```
 
@@ -132,7 +136,7 @@ exit
 
 **목적** — 두 Keycloak 파드가 서로 다른 노드에 있는지 확인하고, 뒤에서 쓸 IP 를 변수에 담는다.
 
-```bash label="[kc-lab-1] ① 노드와 파드를 넓게 본다"
+```bash label="[lab host] ① 노드와 파드를 넓게 본다"
 kubectl get nodes
 kubectl -n keycloak-lab get pods -o wide
 ```
@@ -148,7 +152,7 @@ postgres-7b474b88c8-t6rrf   1/1    Running  0         5d   10.42.0.22   kc-lab-1
 
 `READY` 가 둘 다 `1/1`, `RESTARTS` 가 `0`, 그리고 `NODE` 가 서로 다른지를 본다. 파드 번호와 노드 번호는 어긋난다 — `keycloak-0` 이 `kc-lab-2` 에 있다.
 
-```bash label="[kc-lab-1] ② IP 를 변수에 담는다"
+```bash label="[lab host] ② IP 를 변수에 담는다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 echo "$K0 $K1"
@@ -166,7 +170,7 @@ echo "$K0 $K1"
 
 **목적** — 복구할 때 되돌릴 문자열을 확보한다.
 
-```bash label="[kc-lab-1] 컨테이너 args 를 그대로 찍는다"
+```bash label="[lab host] 컨테이너 args 를 그대로 찍는다"
 kubectl -n keycloak-lab get statefulset keycloak \
   -o jsonpath='{.spec.template.spec.containers[0].args}' ; echo
 ```
@@ -185,7 +189,7 @@ kubectl -n keycloak-lab get statefulset keycloak \
 
 **목적** — persistent 에서 로그인이 DB 행을 만든다는 것을 전환 전에 확인한다.
 
-```bash label="[kc-lab-1] 온라인 세션과 offline token 을 나눠 센다"
+```bash label="[lab host] 온라인 세션과 offline token 을 나눠 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select offline_flag, count(*) from offline_user_session group by offline_flag"
 ```
@@ -210,7 +214,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 Keycloak 컨테이너에는 `curl` 도 `wget` 도 없어서 `kubectl exec keycloak-0 -- curl` 은 `exit 127` 로 끝난다.
 
-```bash label="[kc-lab-1] ① 탐침을 띄우고 Ready 를 기다린다"
+```bash label="[lab host] ① 탐침을 띄우고 Ready 를 기다린다"
 kubectl -n keycloak-lab run a7-probe --image=curlimages/curl:8.11.1 \
   --restart=Never \
   --env="K0=$K0" --env="K1=$K1" \
@@ -222,7 +226,7 @@ kubectl -n keycloak-lab wait --for=condition=Ready pod/a7-probe --timeout=120s
 
 비밀번호는 명령 치환으로 넘어가므로 터미널에도 셸 히스토리에도 값이 남지 않는다. 존재와 길이만 본다.
 
-```bash label="[kc-lab-1] ② 비밀번호의 길이만 센다"
+```bash label="[lab host] ② 비밀번호의 길이만 센다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets \
   -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d | wc -c
 ```
@@ -231,7 +235,7 @@ kubectl -n keycloak-lab get secret keycloak-lab-secrets \
 19
 ```
 
-```bash label="[kc-lab-1] ③ 탐침 안에 값이 들어갔는지 본다"
+```bash label="[lab host] ③ 탐침 안에 값이 들어갔는지 본다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c 'echo "K0=$K0 K1=$K1 PW길이=${#PW}"'
 ```
 
@@ -247,7 +251,7 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c 'echo "K0=$K0 K1=$K1 PW길이=${#
 
 응답을 한 번은 통째로 본다.
 
-```bash label="[kc-lab-1] ① 로그인 응답 전문을 본다"
+```bash label="[lab host] ① 로그인 응답 전문을 본다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'curl -s -X POST "http://$K0:8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
@@ -261,7 +265,7 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c \
 
 `expires_in` 이 60 이다. access token 은 60초짜리고 그동안은 서버에 안 물어보므로, 이 실험의 탐침은 access token 이 아니라 refresh 다. refresh 는 노드가 세션 저장소를 실제로 뒤져야 답할 수 있다.
 
-```bash label="[kc-lab-1] ② 토큰을 파드 안 파일에 담고 길이를 찍는다"
+```bash label="[lab host] ② 토큰을 파드 안 파일에 담고 길이를 찍는다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'curl -s -X POST "http://$K0:8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
@@ -274,7 +278,7 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c \
 rt 1188 bytes
 ```
 
-```bash label="[kc-lab-1] ③ 반대 노드에서 그 토큰으로 갱신한다"
+```bash label="[lab host] ③ 반대 노드에서 그 토큰으로 갱신한다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'curl -s -o /dev/null -w "%{http_code}\n" -X POST \
      "http://$K1:8080/realms/master/protocol/openid-connect/token" \
@@ -296,7 +300,7 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c \
 
 **목적** — 기능 목록에 이름이 있는지 본다.
 
-```bash label="[kc-lab-1] 빌드 기능 목록에서 이름을 찾는다"
+```bash label="[lab host] 빌드 기능 목록에서 이름을 찾는다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kc.sh build --help-all \
   | tr ',' '\n' | grep -i persistent
 ```
@@ -321,7 +325,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kc.sh build --help-
 
 **목적** — 전환 후 「DB 0건」이 성립할 수 있게 옛 행을 먼저 없앤다.
 
-```bash label="[kc-lab-1] 온라인·오프라인 세션 행을 전부 지운다"
+```bash label="[lab host] 온라인·오프라인 세션 행을 전부 지운다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "delete from offline_user_session"
 ```
@@ -344,7 +348,7 @@ DELETE 151
 
 먼저 매니페스트를 편집기로 연다.
 
-```bash label="[kc-lab-1] ① 저장소의 매니페스트를 연다"
+```bash label="[lab host] ① 저장소의 매니페스트를 연다"
 vim deploy/lab/k8s/keycloak-cluster.yaml
 ```
 
@@ -357,13 +361,13 @@ args: ["start", "--features-disabled=persistent-user-sessions"]
 
 고친 파일을 적용한다.
 
-```bash label="[kc-lab-1] ② 적용한다"
+```bash label="[lab host] ② 적용한다"
 kubectl apply -f deploy/lab/k8s/keycloak-cluster.yaml
 ```
 
 파일을 안 건드리고 싶으면 patch 를 쓴다.
 
-```bash label="[kc-lab-1] 파일 대신 patch 로 바꾸는 형태"
+```bash label="[lab host] 파일 대신 patch 로 바꾸는 형태"
 kubectl -n keycloak-lab patch statefulset keycloak --type=json \
   -p '[{"op":"replace","path":"/spec/template/spec/containers/0/args",
         "value":["start","--features-disabled=persistent-user-sessions"]}]'
@@ -371,7 +375,7 @@ kubectl -n keycloak-lab patch statefulset keycloak --type=json \
 
 전환 시각을 적고 롤아웃을 기다린다.
 
-```bash label="[kc-lab-1] ③ 전환 시각을 남기고 롤아웃을 기다린다"
+```bash label="[lab host] ③ 전환 시각을 남기고 롤아웃을 기다린다"
 date '+%H:%M:%S 전환'
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
 ```
@@ -396,7 +400,7 @@ partitioned roll out complete: 2 new pods have been updated...
 
 **목적** — 선언만 바뀌고 프로세스는 그대로인 상태를 걸러 낸다.
 
-```bash label="[kc-lab-1] args 와 파드 나이를 함께 본다"
+```bash label="[lab host] args 와 파드 나이를 함께 본다"
 kubectl -n keycloak-lab get statefulset keycloak \
   -o jsonpath='{.spec.template.spec.containers[0].args}' ; echo
 kubectl -n keycloak-lab get pods -o wide | grep keycloak
@@ -416,13 +420,13 @@ kubectl -n keycloak-lab get pods -o wide | grep keycloak
 
 IP 가 바뀌었으므로 다시 잡고, 탐침 파드도 지우고 새 IP 로 다시 띄운다. 탐침의 `K0`·`K1` 은 만들 때 고정된 값이라 롤아웃 뒤에는 낡았고, 낡은 주소로 친 curl 은 아무 데도 안 닿는다. 여기서는 아직 파드 안에 지킬 파일이 없으므로 지우고 다시 만들어도 잃을 것이 없다.
 
-```bash label="[kc-lab-1] ① 롤아웃 뒤 IP 를 다시 잡는다"
+```bash label="[lab host] ① 롤아웃 뒤 IP 를 다시 잡는다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 echo "$K0 $K1"
 ```
 
-```bash label="[kc-lab-1] ② 탐침을 지우고 새 IP 로 다시 띄운다"
+```bash label="[lab host] ② 탐침을 지우고 새 IP 로 다시 띄운다"
 kubectl -n keycloak-lab delete pod a7-probe --ignore-not-found
 kubectl -n keycloak-lab run a7-probe --image=curlimages/curl:8.11.1 \
   --restart=Never \
@@ -437,7 +441,7 @@ kubectl -n keycloak-lab wait --for=condition=Ready pod/a7-probe --timeout=120s
 
 **목적** — args 문자열이 아니라 동작이 바뀐 것을 본다.
 
-```bash label="[kc-lab-1] ① 한쪽 노드에만 다섯 번 로그인한다"
+```bash label="[lab host] ① 한쪽 노드에만 다섯 번 로그인한다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'for i in 1 2 3 4 5; do
      curl -s -o /dev/null -w "%{http_code} " -X POST \
@@ -451,7 +455,7 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c \
 200 200 200 200 200
 ```
 
-```bash label="[kc-lab-1] ② 같은 질의로 DB 행을 다시 센다"
+```bash label="[lab host] ② 같은 질의로 DB 행을 다시 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select offline_flag, count(*) from offline_user_session group by offline_flag"
 ```
@@ -473,7 +477,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **목적** — 다음 사람이 이 지표로 판정하지 않도록, 두 모드가 같은 값을 낸다는 것을 눈으로 본다.
 
-```bash label="[kc-lab-1] ① 한 줄짜리 JSON 을 통째로 본다"
+```bash label="[lab host] ① 한 줄짜리 JSON 을 통째로 본다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_statistics_approximate_entries_unique'
 ```
@@ -486,7 +490,7 @@ kubectl -n observability exec deploy/prometheus -- \
 
 라벨을 보고 나면 읽기 좋게 자른다. 아래 형태는 가이드가 미검증으로 표시한 줄이다(unknown).
 
-```bash label="[kc-lab-1] ② 캐시 이름과 파드와 값만 세로로 늘어놓는다"
+```bash label="[lab host] ② 캐시 이름과 파드와 값만 세로로 늘어놓는다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_statistics_approximate_entries_unique' \
   | tr ',' '\n' | grep -E '"cache":|"pod":|^"[0-9]'
@@ -511,7 +515,7 @@ kubectl -n observability exec deploy/prometheus -- \
 
 **목적** — 겉보기 결과가 persistent 때와 같은지 본다.
 
-```bash label="[kc-lab-1] 로그인하고 반대 노드에서 갱신한다"
+```bash label="[lab host] 로그인하고 반대 노드에서 갱신한다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'curl -s -X POST "http://$K0:8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
@@ -539,6 +543,20 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c \
 
 구별하려면 그 경로를 끊어 봐야 하고, 14번이 그것을 한다.
 
+2026-09-17 에 새 실험대에서 12번과 14번을 이어서 쳤다(observed). 같은 명령 한 벌이 전환 전후로 정반대 답을 냈다.
+
+```text
+volatile · 분단 없음    로그인 sid=_szXQIOVaE8_v2-b-frn9npt  교차 노드 refresh 200
+                        DB 세션 행 (0 rows)
+                        캐시 keycloak-0 sessions 1 · keycloak-1 sessions 0
+
+volatile · 7800 차단    로그인 sid=9tpo41BVY32uJdYOyv8maA5j  교차 노드 refresh 400
+                        로그아웃 400 · 발급 노드 재갱신 400 invalid_grant / Invalid refresh token
+                        DB 세션 행 0
+```
+
+**persistent 에서는 같은 것을 재면 `200` 이 나왔다.** A-1 에서 7800 을 막고 잰 값이 `200`·`204`·`200` 이었고 여기서는 `400`·`400`·`400` 이다. 그 한 칸이 두 모드의 차이를 전부 말한다 — persistent 는 DB 를 읽고, volatile 은 7800 을 탄다.
+
 **문제가 생기면** — `400` 이 나오면 `/tmp/rt` 를 다시 안 채웠다. 로그인부터 다시 친다.
 
 ### 13. A-8 을 다시 돌린다 — 롤링 재시작이 곧 로그아웃이다
@@ -547,7 +565,7 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c \
 
 재시작 전에 로그인해서 토큰과 `sid` 를 파드 안에 담는다.
 
-```bash label="[kc-lab-1] ① 토큰을 담고 access token 의 클레임을 편다"
+```bash label="[lab host] ① 토큰을 담고 access token 의 클레임을 편다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'curl -s -X POST "http://$K0:8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
@@ -573,7 +591,7 @@ access token 의 가운데 토막이 클레임이다. 모양은 이렇고 값은
 
 그다음 재시작한다.
 
-```bash label="[kc-lab-1] ② 시각을 남기고 롤링 재시작을 건다"
+```bash label="[lab host] ② 시각을 남기고 롤링 재시작을 건다"
 date '+%H:%M:%S 재시작'
 kubectl -n keycloak-lab rollout restart statefulset/keycloak
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
@@ -584,15 +602,15 @@ statefulset.apps/keycloak restarted
 partitioned roll out complete: 2 new pods have been updated...
 ```
 
-파드 IP 를 다시 잡는다. 탐침은 다시 띄우지 않는다 — `/tmp/rt` 가 같이 사라진다. 그래서 새 IP 를 명령줄에 직접 넘긴다. `$K0` 는 `[kc-lab-1]` 셸의 변수이고 지금 값은 롤아웃 전 것이므로 먼저 다시 잡는다.
+파드 IP 를 다시 잡는다. 탐침은 다시 띄우지 않는다 — `/tmp/rt` 가 같이 사라진다. 그래서 새 IP 를 명령줄에 직접 넘긴다. `$K0` 는 `[lab host]` 셸의 변수이고 지금 값은 롤아웃 전 것이므로 먼저 다시 잡는다.
 
-```bash label="[kc-lab-1] ③ 롤아웃 뒤 IP 를 다시 잡는다"
+```bash label="[lab host] ③ 롤아웃 뒤 IP 를 다시 잡는다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 echo "$K0 $K1"
 ```
 
-```bash label="[kc-lab-1] ④ 재시작 전 토큰으로 갱신을 시도한다"
+```bash label="[lab host] ④ 재시작 전 토큰으로 갱신을 시도한다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'curl -s -w "\n%{http_code}\n" -X POST \
      "http://'"$K0"':8080/realms/master/protocol/openid-connect/token" \
@@ -637,7 +655,7 @@ date '+%H:%M:%S 차단'
 | `kc-lab-1` | `keycloak-1` | `$K1` |
 | `kc-lab-2` | `keycloak-0` | `$K0` |
 
-**뒤의 두 줄은 중단 절차처럼 나눠 치면 안 된다.** 거기서는 `ssh kc-lab-2` 로 먼저 붙고 원격 셸에서 쳤지만, 여기는 `$K0` 가 들어간다. `$K0` 는 `[kc-lab-1]` 셸의 변수라 원격 셸에는 없고, 나눠 치면 빈 문자열이 들어가 `-d` 없는 규칙이 걸린다. 큰따옴표가 그 값을 `[kc-lab-1]` 에서 펴서 보내므로 이 두 줄은 한 줄 형태 그대로 친다. 붙어서 치고 싶으면 먼저 `echo "$K0"` 로 값을 읽어 원격 셸에서 IP 를 손으로 넣는다.
+**뒤의 두 줄은 중단 절차처럼 나눠 치면 안 된다.** 거기서는 `ssh kc-lab-2` 로 먼저 붙고 원격 셸에서 쳤지만, 여기는 `$K0` 가 들어간다. `$K0` 는 `[lab host]` 셸의 변수라 원격 셸에는 없고, 나눠 치면 빈 문자열이 들어가 `-d` 없는 규칙이 걸린다. 큰따옴표가 그 값을 `[lab host]` 에서 펴서 보내므로 이 두 줄은 한 줄 형태 그대로 친다. 붙어서 치고 싶으면 먼저 `echo "$K0"` 로 값을 읽어 원격 셸에서 IP 를 손으로 넣는다.
 
 NetworkPolicy 대신 `iptables` 를 쓰는 까닭은 A-1 에서 나왔다. NetworkPolicy 는 conntrack 의 ESTABLISHED 를 못 뚫어서 이미 붙어 있는 7800 연결이 계속 산다.
 
@@ -670,7 +688,7 @@ Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 
 분단이 성립할 때까지 25초 간격으로 몇 번 친다.
 
-```bash label="[kc-lab-1] ③ 두 노드가 각각 아는 멤버 수를 본다"
+```bash label="[lab host] ③ 두 노드가 각각 아는 멤버 수를 본다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size' \
   | tr ',' '\n' | grep -E '"pod":|^"[0-9]'
@@ -690,7 +708,7 @@ kubectl -n observability exec deploy/prometheus -- \
 
 split brain 은 DB 한 줄로 확인한다.
 
-```bash label="[kc-lab-1] ④ 디스커버리 테이블의 코디네이터를 센다"
+```bash label="[lab host] ④ 디스커버리 테이블의 코디네이터를 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select name, ip, coord from jgroups_ping order by name"
 ```
@@ -706,7 +724,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 대조군을 먼저 재고 시험군을 잰다. 대조군은 같은 노드에서 갱신한다.
 
-```bash label="[kc-lab-1] ⑤ 대조군 — 로그인한 노드에서 갱신한다"
+```bash label="[lab host] ⑤ 대조군 — 로그인한 노드에서 갱신한다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'curl -s -X POST "http://'"$K0"':8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
@@ -718,7 +736,7 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c \
      -d "refresh_token=$(cat /tmp/rt)"'
 ```
 
-```bash label="[kc-lab-1] ⑥ 시험군 — 새로 로그인해서 반대 노드에서 갱신한다"
+```bash label="[lab host] ⑥ 시험군 — 새로 로그인해서 반대 노드에서 갱신한다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'curl -s -X POST "http://'"$K0"':8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
@@ -759,9 +777,9 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c \
 
 내리기 전에 로그인해서 `/tmp/rt` 를 채운다. **12번의 명령을 쓰지 않는다** — 그 블록은 로그인한 다음 곧바로 반대 노드에서 refresh 까지 해서 방금 받은 토큰을 소모한다. refresh token 은 한 번 쓰면 회전하므로 `/tmp/rt` 에는 이미 쓴 값이 남고, DB 를 내린 뒤의 `500` 이 DB 때문인지 재사용 때문인지 구별되지 않는다. 로그인만 하고 끝나는 13번의 ① 을 쓴다.
 
-```bash label="[kc-lab-1] ① 로그인만 해서 /tmp/rt 를 채운다"
+```bash label="[lab host] ① 로그인만 해서 /tmp/rt 를 채운다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
-  'curl -s -X POST "http://$K0:8080/realms/master/protocol/openid-connect/token" \
+  'curl -s -X POST "http://'"$K0"':8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
      -d username=admin -d "password=$PW" > /tmp/tok
    sed -n "s/.*\"refresh_token\":\"\([^\"]*\)\".*/\1/p" /tmp/tok > /tmp/rt
@@ -769,9 +787,11 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c \
      | cut -d. -f2 | base64 -d 2>/dev/null; echo'
 ```
 
+**인용이 세 겹인 것이 여기서도 중요하다.** 작은따옴표 안에 그냥 `$K0` 를 두면 그것을 펴는 것은 파드 안 셸이고, 그 값은 탐침을 만들 때 `--env` 로 **구워 넣은 것**이다. 12번의 `rollout restart` 로 파드 IP 가 바뀐 뒤라 그 값은 낡았다 — 요청이 없는 주소로 나가고, 그때 나오는 실패가 이 절의 예상 결과인 `500` 과 화면에서 같아 보인다. 위 ④ 와 같은 형태로 `[lab host]` 셸의 지금 값을 넘긴다.
+
 그다음 DB 를 내린다.
 
-```bash label="[kc-lab-1] ② 시각을 남기고 DB 를 0 replica 로 내린다"
+```bash label="[lab host] ② 시각을 남기고 DB 를 0 replica 로 내린다"
 date '+%H:%M:%S 정지'
 kubectl -n keycloak-lab scale deployment/postgres --replicas=0
 kubectl -n keycloak-lab wait --for=delete pod -l app=postgres --timeout=90s
@@ -781,7 +801,7 @@ kubectl -n keycloak-lab wait --for=delete pod -l app=postgres --timeout=90s
 
 두 경로를 차례로 친다.
 
-```bash label="[kc-lab-1] ③ 캐시를 가진 노드에서 refresh"
+```bash label="[lab host] ③ 캐시를 가진 노드에서 refresh"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'curl -s -o /dev/null -w "%{http_code}\n" -X POST \
      "http://'"$K0"':8080/realms/master/protocol/openid-connect/token" \
@@ -789,7 +809,7 @@ kubectl -n keycloak-lab exec a7-probe -- sh -c \
      -d "refresh_token=$(cat /tmp/rt)"'
 ```
 
-```bash label="[kc-lab-1] ④ 새 로그인"
+```bash label="[lab host] ④ 새 로그인"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'curl -s -o /dev/null -w "%{http_code}\n" -X POST \
      "http://'"$K0"':8080/realms/master/protocol/openid-connect/token" \
@@ -820,7 +840,7 @@ persistent 에서는 순서가 거꾸로였다. 새 로그인이 `500` 이었는
 
 마지막으로 DB 를 되살린다.
 
-```bash label="[kc-lab-1] ⑤ DB 를 다시 올린다"
+```bash label="[lab host] ⑤ DB 를 다시 올린다"
 kubectl -n keycloak-lab scale deployment/postgres --replicas=1
 kubectl -n keycloak-lab rollout status deployment/postgres --timeout=180s
 ```
@@ -841,13 +861,13 @@ sudo iptables -t raw -L PREROUTING -n
 ssh kc-lab-2 'sudo iptables -t raw -L PREROUTING -n'
 ```
 
-```bash label="[kc-lab-1] ② DB 파드를 본다"
+```bash label="[lab host] ② DB 파드를 본다"
 kubectl -n keycloak-lab get pods -l app=postgres
 ```
 
 `Running` 이 아니면 `scale deployment/postgres --replicas=1` 을 친다.
 
-```bash label="[kc-lab-1] ③ args 를 기본값으로 되돌린다"
+```bash label="[lab host] ③ args 를 기본값으로 되돌린다"
 kubectl -n keycloak-lab patch statefulset keycloak --type=json \
   -p '[{"op":"replace","path":"/spec/template/spec/containers/0/args","value":["start"]}]'
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
@@ -855,7 +875,7 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
 
 매니페스트를 고쳤다면 파일도 같이 되돌린다. 안 그러면 다음에 `apply` 할 때 volatile 로 다시 간다.
 
-```bash label="[kc-lab-1] ④ 매니페스트의 변경을 확인하고 되돌린다"
+```bash label="[lab host] ④ 매니페스트의 변경을 확인하고 되돌린다"
 git diff deploy/lab/k8s/keycloak-cluster.yaml
 git checkout -- deploy/lab/k8s/keycloak-cluster.yaml
 ```
@@ -868,7 +888,7 @@ partitioned roll out complete: 2 new pods have been updated...
 
 `args` 문자열만 보고 끝내지 않는다. 새 IP 로 탐침을 다시 띄우고 로그인을 한 번 한 다음 DB 행을 센다. 원복도 롤아웃이므로 여기서도 파드 주소가 바뀌었다.
 
-```bash label="[kc-lab-1] ⑤ 새 IP 로 탐침을 다시 띄운다"
+```bash label="[lab host] ⑤ 새 IP 로 탐침을 다시 띄운다"
 kubectl -n keycloak-lab delete pod a7-probe --ignore-not-found
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
@@ -881,14 +901,14 @@ kubectl -n keycloak-lab run a7-probe --image=curlimages/curl:8.11.1 \
 kubectl -n keycloak-lab wait --for=condition=Ready pod/a7-probe --timeout=120s
 ```
 
-```bash label="[kc-lab-1] ⑥ 로그인을 한 번 한다"
+```bash label="[lab host] ⑥ 로그인을 한 번 한다"
 kubectl -n keycloak-lab exec a7-probe -- sh -c \
   'curl -s -X POST "http://$K0:8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
      -d username=admin -d "password=$PW"'
 ```
 
-```bash label="[kc-lab-1] ⑦ 로그인 뒤 온라인 세션 행을 센다"
+```bash label="[lab host] ⑦ 로그인 뒤 온라인 세션 행을 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -tAc "select count(*) from offline_user_session where offline_flag='0'"
 ```
@@ -917,7 +937,7 @@ postgres-7b474b88c8-t6rrf   1/1   Running   0     2m8s
 | 탐침 파드 | `kubectl -n keycloak-lab get pod a7-probe` | `NotFound` |
 | 밖 | `curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master` | `200` |
 
-```bash label="[kc-lab-1] ⑧ 탐침 파드를 지운다"
+```bash label="[lab host] ⑧ 탐침 파드를 지운다"
 kubectl -n keycloak-lab delete pod a7-probe --ignore-not-found
 ```
 
diff --git a/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a7a-volatile-cause.md b/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a7a-volatile-cause.md
index 40d13f2..eae3304 100644
--- a/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a7a-volatile-cause.md
+++ b/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a7a-volatile-cause.md
@@ -41,7 +41,9 @@ PostgreSQL 문장 로깅을 켜고 volatile 상태의 로그인과 refresh 가 
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 전부 `[kc-lab-1]` 에서 `kubectl` 로 친다. 이 절차에는 노드 자체를 건드리는 명령이 없어서 `kc-lab-2` 로 들어갈 일이 없다. `kubectl` 에 `sudo` 를 붙이지 않는다 — root 홈에는 `~/.kube/config` 가 없어서 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다.
+명령은 전부 `[lab host]` 에서 `kubectl` 로 친다. 이 절차에는 노드 자체를 건드리는 명령이 없어서 게스트에 들어갈 일이 없다. `kubectl` 에 `sudo` 를 붙이지 않는다 — root 홈에는 `~/.kube/config` 가 없어서 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 이 편의 시각은 UTC 다. 증거의 `11:18:49` 는 KST 로 `20:18` 이고 같은 순간이다. PostgreSQL 컨테이너가 UTC 로 로그를 찍기 때문이고, 로그 시각과 `date` 를 견줄 때 이걸 잊으면 9시간을 헤맨다.
 
@@ -89,7 +91,7 @@ A-7 은 이렇게 끝났다.
 
 표식을 넣는 방식에서 이 절차가 원 실행과 갈라진다. 원 실행은 표식을 셸 함수로 감쌌다.
 
-```bash label="[kc-lab-1] 이 실험대는 이렇게 했다 (observed)"
+```bash label="[lab host] 이 실험대는 이렇게 했다 (observed)"
 m() { kubectl -n keycloak-lab exec deploy/postgres -- \
         psql -U keycloak -d keycloak -tAc "select 'MARK_$1'" >/dev/null; }
 ```
@@ -98,7 +100,7 @@ m() { kubectl -n keycloak-lab exec deploy/postgres -- \
 
 따라 하는 사람은 표식을 한 줄씩 손으로 넣는다. 느리지만 그 즉시 보이고, 안 보이면 그 즉시 안다. 아래 절차가 전부 그 형태다.
 
-```bash label="[kc-lab-1] 따라 하는 사람은 이 형태로 친다"
+```bash label="[lab host] 따라 하는 사람은 이 형태로 친다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -tAc "select 'MARK_TEST'"
 ```
@@ -113,7 +115,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **목적** — 이 절차가 내렸다 올릴 `postgres` 가 지금 있는지 확인한다.
 
-```bash label="[kc-lab-1] 네임스페이스의 파드를 넓게 본다"
+```bash label="[lab host] 네임스페이스의 파드를 넓게 본다"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
@@ -134,7 +136,7 @@ postgres-7b474b88c8-t6rrf   1/1    Running  0         5d   10.42.0.22   kc-lab-1
 
 **목적** — 지금 쌓이는 로그가 이 실험 것인지 앞 실험 것인지 가른다.
 
-```bash label="[kc-lab-1] 현재 설정값을 읽는다"
+```bash label="[lab host] 현재 설정값을 읽는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "show log_statement"
 ```
@@ -155,7 +157,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **목적** — 복구에서 되돌릴 문자열을 확보한다.
 
-```bash label="[kc-lab-1] 컨테이너 args 를 그대로 찍는다"
+```bash label="[lab host] 컨테이너 args 를 그대로 찍는다"
 kubectl -n keycloak-lab get statefulset keycloak \
   -o jsonpath='{.spec.template.spec.containers[0].args}' ; echo
 ```
@@ -176,7 +178,7 @@ kubectl -n keycloak-lab get statefulset keycloak \
 
 Keycloak 컨테이너에는 `curl` 도 `wget` 도 없어서 `kubectl exec keycloak-0 -- curl` 은 `exit 127` 로 끝난다.
 
-```bash label="[kc-lab-1] ① 탐침을 띄우고 Ready 를 기다린다"
+```bash label="[lab host] ① 탐침을 띄우고 Ready 를 기다린다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 kubectl -n keycloak-lab run a7a-probe --image=curlimages/curl:8.11.1 \
   --restart=Never \
@@ -189,7 +191,7 @@ kubectl -n keycloak-lab wait --for=condition=Ready pod/a7a-probe --timeout=120s
 
 비밀번호는 명령 치환으로 넘어가므로 터미널에도 셸 히스토리에도 값이 남지 않는다. 길이만 본다.
 
-```bash label="[kc-lab-1] ② 비밀번호의 길이만 센다"
+```bash label="[lab host] ② 비밀번호의 길이만 센다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets \
   -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d | wc -c
 ```
@@ -198,7 +200,7 @@ kubectl -n keycloak-lab get secret keycloak-lab-secrets \
 19
 ```
 
-```bash label="[kc-lab-1] ③ 탐침 안에 값이 들어갔는지 본다"
+```bash label="[lab host] ③ 탐침 안에 값이 들어갔는지 본다"
 kubectl -n keycloak-lab exec a7a-probe -- sh -c 'echo "K0=$K0 PW길이=${#PW}"'
 ```
 
@@ -212,7 +214,7 @@ kubectl -n keycloak-lab exec a7a-probe -- sh -c 'echo "K0=$K0 PW길이=${#PW}"'
 
 **목적** — 켜기 전의 로그를 한 번 봐 두고, 켠 뒤의 소음과 견준다.
 
-```bash label="[kc-lab-1] 마지막 20줄을 본다"
+```bash label="[lab host] 마지막 20줄을 본다"
 kubectl -n keycloak-lab logs deploy/postgres --tail=20
 ```
 
@@ -232,12 +234,12 @@ kubectl -n keycloak-lab logs deploy/postgres --tail=20
 
 되돌리는 명령을 먼저 읽어 둔다.
 
-```bash label="[kc-lab-1] ① 되돌리는 명령 — 먼저 읽어 둔다"
+```bash label="[lab host] ① 되돌리는 명령 — 먼저 읽어 둔다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "alter system reset log_statement" -c "select pg_reload_conf()"
 ```
 
-```bash label="[kc-lab-1] ② 문장 로깅을 켜고 설정을 다시 읽힌다"
+```bash label="[lab host] ② 문장 로깅을 켜고 설정을 다시 읽힌다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "alter system set log_statement='all'" -c "select pg_reload_conf()"
 ```
@@ -254,13 +256,13 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 되돌리는 명령을 먼저 읽어 둔다.
 
-```bash label="[kc-lab-1] ① 되돌리는 명령 — 먼저 읽어 둔다"
+```bash label="[lab host] ① 되돌리는 명령 — 먼저 읽어 둔다"
 kubectl -n keycloak-lab patch statefulset keycloak --type=json \
   -p '[{"op":"replace","path":"/spec/template/spec/containers/0/args","value":["start"]}]'
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
 ```
 
-```bash label="[kc-lab-1] ② persistent-user-sessions 를 끈다"
+```bash label="[lab host] ② persistent-user-sessions 를 끈다"
 kubectl -n keycloak-lab patch statefulset keycloak --type=json \
   -p '[{"op":"replace","path":"/spec/template/spec/containers/0/args",
         "value":["start","--features-disabled=persistent-user-sessions"]}]'
@@ -269,7 +271,7 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
 
 파드 IP 가 바뀌었으므로 탐침 파드를 다시 띄운다.
 
-```bash label="[kc-lab-1] ③ 탐침을 지우고 새 IP 로 다시 띄운다"
+```bash label="[lab host] ③ 탐침을 지우고 새 IP 로 다시 띄운다"
 kubectl -n keycloak-lab delete pod a7a-probe --ignore-not-found
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 kubectl -n keycloak-lab run a7a-probe --image=curlimages/curl:8.11.1 \
@@ -290,7 +292,7 @@ kubectl -n keycloak-lab wait --for=condition=Ready pod/a7a-probe --timeout=120s
 
 **목적** — DB 가 없는 구간을 만들어 캐시가 무엇을 대신하는지 본다.
 
-```bash label="[kc-lab-1] DB 를 0 replica 로 내리고 파드가 사라질 때까지 기다린다"
+```bash label="[lab host] DB 를 0 replica 로 내리고 파드가 사라질 때까지 기다린다"
 kubectl -n keycloak-lab scale deployment/postgres --replicas=0
 kubectl -n keycloak-lab wait --for=delete pod -l app=postgres --timeout=90s
 ```
@@ -309,7 +311,7 @@ kubectl -n keycloak-lab wait --for=delete pod -l app=postgres --timeout=90s
 
 **목적** — 설정값과 실제 출력을 둘 다 확인한다.
 
-```bash label="[kc-lab-1] ① 설정값을 읽는다"
+```bash label="[lab host] ① 설정값을 읽는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "show log_statement"
 ```
@@ -320,7 +322,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
  all
 ```
 
-```bash label="[kc-lab-1] ② 로그가 차는지 본다"
+```bash label="[lab host] ② 로그가 차는지 본다"
 kubectl -n keycloak-lab logs deploy/postgres --tail=10
 ```
 
@@ -338,12 +340,12 @@ kubectl -n keycloak-lab logs deploy/postgres --tail=10
 
 **목적** — 구간을 자를 수 있는 상태인지 확인한다.
 
-```bash label="[kc-lab-1] ① 표식을 하나 넣는다"
+```bash label="[lab host] ① 표식을 하나 넣는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -tAc "select 'MARK_TEST'"
 ```
 
-```bash label="[kc-lab-1] ② 그 표식이 로그에 있는지 본다"
+```bash label="[lab host] ② 그 표식이 로그에 있는지 본다"
 kubectl -n keycloak-lab logs deploy/postgres --tail=5 | grep MARK_TEST
 ```
 
@@ -361,7 +363,7 @@ kubectl -n keycloak-lab logs deploy/postgres --tail=5 | grep MARK_TEST
 
 **목적** — 선언과 동작이 같이 바뀌었는지 확인한다.
 
-```bash label="[kc-lab-1] args · 로그인 응답 코드 · DB 행 수를 이어서 본다"
+```bash label="[lab host] args · 로그인 응답 코드 · DB 행 수를 이어서 본다"
 kubectl -n keycloak-lab get statefulset keycloak \
   -o jsonpath='{.spec.template.spec.containers[0].args}' ; echo
 kubectl -n keycloak-lab exec a7a-probe -- sh -c \
@@ -387,7 +389,7 @@ volatile 전환 확인
 
 문장 로그가 지금 요청을 잡고 있는지도 본다.
 
-```bash label="[kc-lab-1] 최근 60초의 로그 끝을 본다"
+```bash label="[lab host] 최근 60초의 로그 끝을 본다"
 kubectl -n keycloak-lab logs deploy/postgres --since=60s | tail -20
 ```
 
@@ -401,7 +403,7 @@ kubectl -n keycloak-lab logs deploy/postgres --since=60s | tail -20
 
 **목적** — 로그인 한 번이 DB 에 무엇을 보내는지 센다.
 
-```bash label="[kc-lab-1] ① 표식 · 로그인 · 표식을 차례로 친다"
+```bash label="[lab host] ① 표식 · 로그인 · 표식을 차례로 친다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -tAc "select 'MARK_LOGIN_START'"
 kubectl -n keycloak-lab exec a7a-probe -- sh -c \
@@ -418,7 +420,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 rt 1188 bytes
 ```
 
-```bash label="[kc-lab-1] ② 로그를 파일로 받아 구간을 자른다"
+```bash label="[lab host] ② 로그를 파일로 받아 구간을 자른다"
 kubectl -n keycloak-lab logs deploy/postgres --tail=4000 > /tmp/pg.log
 awk '/MARK_LOGIN_START/,/MARK_LOGIN_END/' /tmp/pg.log | grep -v JGROUPS_PING
 ```
@@ -439,7 +441,7 @@ awk '/MARK_LOGIN_START/,/MARK_LOGIN_END/' /tmp/pg.log | grep -v JGROUPS_PING
 
 **목적** — A-7 의 가설이 지목한 테이블이 실제로 나오는지 본다.
 
-```bash label="[kc-lab-1] ① 표식 · refresh · 표식을 차례로 친다"
+```bash label="[lab host] ① 표식 · refresh · 표식을 차례로 친다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -tAc "select 'MARK_REFRESH_START'"
 kubectl -n keycloak-lab exec a7a-probe -- sh -c \
@@ -451,7 +453,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -tAc "select 'MARK_REFRESH_END'"
 ```
 
-```bash label="[kc-lab-1] ② 그 구간을 자른다"
+```bash label="[lab host] ② 그 구간을 자른다"
 kubectl -n keycloak-lab logs deploy/postgres --tail=4000 > /tmp/pg.log
 awk '/MARK_REFRESH_START/,/MARK_REFRESH_END/' /tmp/pg.log | grep -v JGROUPS_PING
 ```
@@ -473,7 +475,7 @@ awk '/MARK_REFRESH_START/,/MARK_REFRESH_END/' /tmp/pg.log | grep -v JGROUPS_PING
 
 가설이 지목한 테이블이 정말 없는지 직접 센다.
 
-```bash label="[kc-lab-1] ③ 그 구간에서 REVOKED_TOKEN 을 센다"
+```bash label="[lab host] ③ 그 구간에서 REVOKED_TOKEN 을 센다"
 awk '/MARK_REFRESH_START/,/MARK_REFRESH_END/' /tmp/pg.log | grep -ci revoked_token
 ```
 
@@ -492,7 +494,7 @@ refresh 는 새 access token 을 만든다. 그 토큰에 어떤 스코프를 
 
 그 UUID 가 어느 클라이언트인지 궁금하면 물어본다. UUID 는 렐름을 만들 때 정해지므로 실험대마다 다르다. ②가 자른 구간의 `parameters` 줄에 있는 `$1` 값을 그대로 옮겨 넣는다.
 
-```bash label="[kc-lab-1] ④ 그 UUID 가 어느 클라이언트인지 묻는다"
+```bash label="[lab host] ④ 그 UUID 가 어느 클라이언트인지 묻는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select id, client_id from client where id='{{CLIENT_UUID}}'"
 ```
@@ -507,7 +509,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **목적** — 첫 refresh 가 캐시를 채우고 이후로는 DB 를 보지 않는다는 것을 확인한다.
 
-```bash label="[kc-lab-1] ① 표식을 사이사이에 넣으며 refresh 를 돈다"
+```bash label="[lab host] ① 표식을 사이사이에 넣으며 refresh 를 돈다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -tAc "select 'MARK_R1'"
 kubectl -n keycloak-lab exec a7a-probe -- sh -c \
@@ -522,7 +524,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 같은 모양으로 `MARK_R3` 과 `MARK_R_END` 까지 두 번 더 한다. 매번 `/tmp/rt` 를 다시 채운다 — refresh token 은 회전하고, 옛것을 계속 쓰면 나오는 오류가 무효화 때문인지 재사용 때문인지 구별되지 않는다.
 
-```bash label="[kc-lab-1] ② 표식 넷 사이를 통째로 자른다"
+```bash label="[lab host] ② 표식 넷 사이를 통째로 자른다"
 kubectl -n keycloak-lab logs deploy/postgres --tail=4000 > /tmp/pg.log
 awk '/MARK_R1/,/MARK_R_END/' /tmp/pg.log | grep -v JGROUPS_PING
 ```
@@ -542,6 +544,16 @@ awk '/MARK_R1/,/MARK_R_END/' /tmp/pg.log | grep -v JGROUPS_PING
 
 **문제가 생기면** — `400 Session not active` 가 나오면 옛 refresh token 을 재사용했다. 매번 `/tmp/rt` 를 갱신한다.
 
+**세 재현의 2026-09-17 실측**(observed) — 같은 설정에서 캐시 온도만 달리해 셋을 이어서 쳤다.
+
+| 재현 | 만든 상태 | 쳤을 때 |
+|---|---|---|
+| A | 재시작 직후, 로그인 0회, DB 정지 | 로그인이 `400 unauthorized_client` |
+| B | 재시작 뒤 로그인 1회로 캐시를 덥히고 DB 정지 | refresh 가 `500 unknown_error` |
+| C | DB 를 다시 켜고 같은 refresh | `200` |
+
+A 의 `400` 은 `invalid_grant` 가 아니라 `unauthorized_client` 다 — 세션이 아니라 **클라이언트를 못 찾은 것**이고, 그래서 이 셋을 안 갈라 놓고 재면 A-7 의 결론을 잘못 읽는다.
+
 ### 15. 재현 A — 완전 냉시동이면 로그인부터 400 이다
 
 **목적** — 캐시가 전부 빈 상태에서 DB 를 내렸을 때의 답을 잰다.
@@ -557,7 +569,7 @@ awk '/MARK_R1/,/MARK_R_END/' /tmp/pg.log | grep -v JGROUPS_PING
 
 이 재시작을 건너뛰면 세 상태가 하나로 뭉개진다. 이미 더워진 캐시에서 계속 재게 되므로 A 와 B 를 재도 C 의 답이 나오고, 「A-7 이 틀렸다」는 엉뚱한 결론에 이른다.
 
-```bash label="[kc-lab-1] ① 재시작하고 곧바로 DB 를 내린다"
+```bash label="[lab host] ① 재시작하고 곧바로 DB 를 내린다"
 kubectl -n keycloak-lab rollout restart statefulset/keycloak
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
 kubectl -n keycloak-lab scale deployment/postgres --replicas=0
@@ -568,7 +580,7 @@ kubectl -n keycloak-lab wait --for=delete pod -l app=postgres --timeout=90s
 
 탐침의 `K0` 는 만들 때 고정된 값이라 재시작 뒤에는 낡았다. 지우고 새 IP 로 다시 만든다. 이 블록을 건너뛰면 뒤의 curl 이 없는 주소로 가고, 그 침묵을 「DB 가 없어서 실패」로 읽게 된다.
 
-```bash label="[kc-lab-1] ② 탐침을 지우고 새 IP 로 다시 띄운다"
+```bash label="[lab host] ② 탐침을 지우고 새 IP 로 다시 띄운다"
 kubectl -n keycloak-lab delete pod a7a-probe --ignore-not-found
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 kubectl -n keycloak-lab run a7a-probe --image=curlimages/curl:8.11.1 \
@@ -579,7 +591,7 @@ kubectl -n keycloak-lab run a7a-probe --image=curlimages/curl:8.11.1 \
 kubectl -n keycloak-lab wait --for=condition=Ready pod/a7a-probe --timeout=120s
 ```
 
-```bash label="[kc-lab-1] ③ 로그인을 본문과 함께 본다"
+```bash label="[lab host] ③ 로그인을 본문과 함께 본다"
 kubectl -n keycloak-lab exec a7a-probe -- sh -c \
   'curl -s -w "\n%{http_code}\n" -X POST \
      "http://$K0:8080/realms/master/protocol/openid-connect/token" \
@@ -596,11 +608,26 @@ kubectl -n keycloak-lab exec a7a-probe -- sh -c \
 
 `unauthorized_client` 이고 `invalid_grant` 가 아니다. 세션 문제가 아니라 클라이언트를 못 찾았다. 왜인지는 Keycloak 로그가 직접 말한다.
 
-```bash label="[kc-lab-1] ④ 실패한 SQL 을 Keycloak 로그에서 뽑는다"
-kubectl -n keycloak-lab logs keycloak-0 --tail=150 \
-  | grep -oE 'JDBC exception executing SQL \[[^]]*\] \[[^]]*\]'
+```bash label="[lab host] ④ 실패한 SQL 을 Keycloak 로그에서 뽑는다"
+kubectl -n keycloak-lab logs keycloak-0 --tail=400 \
+  | grep -oE 'KC-SERVICES0015[^[]*\[[^]]*\]'
 ```
 
+**이 형태로 넓혔다.** 원래 적힌 `grep -oE 'JDBC exception executing SQL …'` 은 **속 예외가 그 문구일 때만** 잡는데, 속 예외는 DB 를 언제 끊었느냐에 따라 둘로 갈린다. 2026-09-17 에는 `--tail=150` 과 그 패턴으로 **한 줄도 안 나왔다**(observed).
+
+```text
+끊는 중에 걸린 요청   GenericJDBCException: JDBC exception executing SQL [FATAL: terminating connection due to administrator command]
+이미 사라진 뒤의 요청 JDBCConnectionException: Unable to acquire JDBC Connection [Connection to postgres:5432 refused. …]
+```
+
+둘 다 앞머리가 `KC-SERVICES0015: Unexpected error when authenticating client` 이므로 그것으로 거는 편이 안전하다. 2026-09-17 실측은 뒤엣것이었다(observed).
+
+```text
+KC-SERVICES0015: Unexpected error when authenticating client: org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection [Connection to postgres:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.]
+```
+
+`--tail` 도 늘렸다. 재시작 직후에는 기동 로그가 길어서 150 줄로는 이 줄까지 못 거슬러 올라간다.
+
 ```text
   ERROR [org.keycloak.services] KC-SERVICES0015: Unexpected error when
     authenticating client: org.hibernate.exception.GenericJDBCException:
@@ -617,7 +644,7 @@ kubectl -n keycloak-lab logs keycloak-0 --tail=150 \
 
 **목적** — A-7 이 본 그 조건을 그대로 만든다.
 
-```bash label="[kc-lab-1] ① DB 를 살리고 다시 재시작한다"
+```bash label="[lab host] ① DB 를 살리고 다시 재시작한다"
 kubectl -n keycloak-lab scale deployment/postgres --replicas=1
 kubectl -n keycloak-lab rollout status deployment/postgres --timeout=180s
 kubectl -n keycloak-lab rollout restart statefulset/keycloak
@@ -626,7 +653,7 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
 
 탐침을 새 IP 로 다시 띄운 뒤 로그인 한 번만 한다. 15번과 같은 이유로 여기서도 탐침을 다시 만든다.
 
-```bash label="[kc-lab-1] ② 탐침을 지우고 새 IP 로 다시 띄운다"
+```bash label="[lab host] ② 탐침을 지우고 새 IP 로 다시 띄운다"
 kubectl -n keycloak-lab delete pod a7a-probe --ignore-not-found
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 kubectl -n keycloak-lab run a7a-probe --image=curlimages/curl:8.11.1 \
@@ -637,7 +664,7 @@ kubectl -n keycloak-lab run a7a-probe --image=curlimages/curl:8.11.1 \
 kubectl -n keycloak-lab wait --for=condition=Ready pod/a7a-probe --timeout=120s
 ```
 
-```bash label="[kc-lab-1] ③ 로그인 한 번으로 캐시를 절반만 데운다"
+```bash label="[lab host] ③ 로그인 한 번으로 캐시를 절반만 데운다"
 kubectl -n keycloak-lab exec a7a-probe -- sh -c \
   'curl -s -X POST "http://$K0:8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
@@ -648,7 +675,7 @@ kubectl -n keycloak-lab exec a7a-probe -- sh -c \
 
 여기서 refresh 를 하면 재현 C 가 된다. 8번의 DB 정지를 친 다음에 refresh 한다.
 
-```bash label="[kc-lab-1] ④ DB 가 없는 상태에서 refresh 한다"
+```bash label="[lab host] ④ DB 가 없는 상태에서 refresh 한다"
 kubectl -n keycloak-lab exec a7a-probe -- sh -c \
   'curl -s -w "\n%{http_code}\n" -X POST \
      "http://$K0:8080/realms/master/protocol/openid-connect/token" \
@@ -682,7 +709,7 @@ kubectl -n keycloak-lab exec a7a-probe -- sh -c \
 
 DB 를 살리고, 재시작하고, 탐침을 새로 만들고, 로그인하고, refresh 를 3회 미리 돌린 뒤 DB 를 내린다. 앞 절들의 명령을 그대로 다시 친다.
 
-```bash label="[kc-lab-1] ① DB 를 살리고 다시 재시작한다"
+```bash label="[lab host] ① DB 를 살리고 다시 재시작한다"
 kubectl -n keycloak-lab scale deployment/postgres --replicas=1
 kubectl -n keycloak-lab rollout status deployment/postgres --timeout=180s
 kubectl -n keycloak-lab rollout restart statefulset/keycloak
@@ -691,7 +718,7 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
 
 파드가 새로 떴으므로 `K0` 가 낡았다. 탐침도 그 값을 `--env` 로 박아 뒀으니 같이 다시 만든다.
 
-```bash label="[kc-lab-1] ② 탐침을 지우고 새 IP 로 다시 띄운다"
+```bash label="[lab host] ② 탐침을 지우고 새 IP 로 다시 띄운다"
 kubectl -n keycloak-lab delete pod a7a-probe --ignore-not-found
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 kubectl -n keycloak-lab run a7a-probe --image=curlimages/curl:8.11.1 \
@@ -704,7 +731,7 @@ kubectl -n keycloak-lab wait --for=condition=Ready pod/a7a-probe --timeout=120s
 
 새 탐침에는 `/tmp/rt` 가 없다. 16번의 ③ 과 같은 명령으로 다시 만든다.
 
-```bash label="[kc-lab-1] ③ 로그인해서 /tmp/rt 를 새로 만든다"
+```bash label="[lab host] ③ 로그인해서 /tmp/rt 를 새로 만든다"
 kubectl -n keycloak-lab exec a7a-probe -- sh -c \
   'curl -s -X POST "http://$K0:8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
@@ -717,12 +744,12 @@ kubectl -n keycloak-lab exec a7a-probe -- sh -c \
 
 그 세 번을 돌렸다고 보고, 8번과 같은 명령으로 DB 를 내린다.
 
-```bash label="[kc-lab-1] ④ DB 를 0 replica 로 내리고 파드가 사라질 때까지 기다린다"
+```bash label="[lab host] ④ DB 를 0 replica 로 내리고 파드가 사라질 때까지 기다린다"
 kubectl -n keycloak-lab scale deployment/postgres --replicas=0
 kubectl -n keycloak-lab wait --for=delete pod -l app=postgres --timeout=90s
 ```
 
-```bash label="[kc-lab-1] ⑤ 로그인과 refresh 를 이어서 친다"
+```bash label="[lab host] ⑤ 로그인과 refresh 를 이어서 친다"
 kubectl -n keycloak-lab exec a7a-probe -- sh -c \
   'curl -s -o /dev/null -w "login %{http_code}\n" -X POST \
      "http://$K0:8080/realms/master/protocol/openid-connect/token" \
@@ -765,14 +792,14 @@ persistent 기본값에는 이 조건부성이 없다. 세션 자체를 DB 에 
 
 셋을 순서대로 되돌린다. DB 가 살아 있어야 나머지가 된다.
 
-```bash label="[kc-lab-1] ① DB 를 올리고 Ready 까지 기다린다"
+```bash label="[lab host] ① DB 를 올리고 Ready 까지 기다린다"
 kubectl -n keycloak-lab scale deployment/postgres --replicas=1
 kubectl -n keycloak-lab wait --for=condition=Ready pod -l app=postgres --timeout=180s
 ```
 
 문장 로깅을 끈다. 잊으면 다음 실험이 전부 오염된다.
 
-```bash label="[kc-lab-1] ② 문장 로깅을 끄고 값을 다시 읽는다"
+```bash label="[lab host] ② 문장 로깅을 끄고 값을 다시 읽는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "alter system reset log_statement" -c "select pg_reload_conf()"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
@@ -787,7 +814,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 왜 급한가 — A-3 은 수백 건의 로그인을 최대한 빨리 돈다. `log_statement='all'` 이면 로그인 하나에 SQL 열 몇 줄씩 쌓이고, 로그가 폭주하고 디스크 입출력이 늘어 크래시 타이밍 자체가 달라진다. 다음 실험의 측정값이 이 설정 때문에 바뀐다.
 
-```bash label="[kc-lab-1] ③ args 를 기본값으로 되돌린다"
+```bash label="[lab host] ③ args 를 기본값으로 되돌린다"
 kubectl -n keycloak-lab patch statefulset keycloak --type=json \
   -p '[{"op":"replace","path":"/spec/template/spec/containers/0/args","value":["start"]}]'
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
@@ -795,7 +822,7 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=500s
 
 `args` 문자열만 보고 끝내지 않는다. 탐침을 새 IP 로 띄우고 로그인을 한 번 한 다음 행을 센다.
 
-```bash label="[kc-lab-1] ④ 로그인 뒤 온라인 세션 행을 센다"
+```bash label="[lab host] ④ 로그인 뒤 온라인 세션 행을 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -tAc "select count(*) from offline_user_session where offline_flag='0'"
 ```
@@ -814,7 +841,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 | 임시 파일 | `ls /tmp/pg.log` | 지워도 된다 |
 | 밖 | `curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master` | `200` |
 
-```bash label="[kc-lab-1] ⑤ 탐침과 임시 파일을 치운다"
+```bash label="[lab host] ⑤ 탐침과 임시 파일을 치운다"
 kubectl -n keycloak-lab delete pod a7a-probe --ignore-not-found
 rm -f /tmp/pg.log
 ```
diff --git a/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a8-rolling-restart.md b/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a8-rolling-restart.md
index 90105bc..ea17257 100644
--- a/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a8-rolling-restart.md
+++ b/docs/keycloak-session-store/tech-log-studio/session-custody-across-nodes/setup/setup-reproduce-a8-rolling-restart.md
@@ -41,7 +41,9 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 전부 `[kc-lab-1]` 에서 `kubectl` 로 친다. 노드 자체를 건드리는 명령이 없어서 `kc-lab-2` 로 들어갈 일이 없다. `kubectl` 에 `sudo` 를 붙이지 않는다 — root 홈에는 `~/.kube/config` 가 없어서 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다.
+명령은 전부 `[lab host]` 에서 `kubectl` 로 친다. 노드 자체를 건드리는 명령이 없어서 게스트에 들어갈 일이 없다. `kubectl` 에 `sudo` 를 붙이지 않는다 — root 홈에는 `~/.kube/config` 가 없어서 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 터미널은 둘을 연다. 하나는 가용성 감시용이라 루프가 도는 동안 붙잡혀 있고, 하나는 재시작과 관찰용이다.
 
@@ -86,7 +88,7 @@ A-0 은 「세션의 진실은 PostgreSQL 에 있고 Infinispan 캐시는 사본
 
 정말 되돌려야 하면 이 명령이 있다. 다만 중간에 `rollout status` 를 `Ctrl-C` 로 끊어도 롤아웃 자체는 계속 진행되므로 끝날 때까지 두는 편이 낫다.
 
-```bash label="[kc-lab-1] 직전 리비전으로 되돌린다"
+```bash label="[lab host] 직전 리비전으로 되돌린다"
 kubectl -n keycloak-lab rollout undo statefulset/keycloak
 ```
 
@@ -100,7 +102,7 @@ kubectl -n keycloak-lab rollout undo statefulset/keycloak
 
 **목적** — 재시작 전의 `AGE` 를 확보하고 replica 가 2 인지 확인한다.
 
-```bash label="[kc-lab-1] 파드를 노드와 함께 넓게 본다"
+```bash label="[lab host] 파드를 노드와 함께 넓게 본다"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
@@ -119,7 +121,7 @@ postgres-7b474b88c8-t6rrf   1/1    Running  0         5d   10.42.0.22   kc-lab-1
 
 **문제가 생기면** — `keycloak` 파드가 하나뿐이면 이 절차의 가용성 측정은 성립하지 않는다.
 
-```bash label="[kc-lab-1] 두 파드 IP 를 변수에 담는다"
+```bash label="[lab host] 두 파드 IP 를 변수에 담는다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 echo "$K0 $K1"
@@ -129,7 +131,7 @@ echo "$K0 $K1"
 
 **목적** — `persistent-user-sessions` 가 켜져 있는 상태에서 재는지 본다.
 
-```bash label="[kc-lab-1] 컨테이너 args 를 그대로 찍는다"
+```bash label="[lab host] 컨테이너 args 를 그대로 찍는다"
 kubectl -n keycloak-lab get statefulset keycloak \
   -o jsonpath='{.spec.template.spec.containers[0].args}' ; echo
 ```
@@ -148,7 +150,7 @@ kubectl -n keycloak-lab get statefulset keycloak \
 
 **목적** — 재시작 후에 견줄 값을 확보한다.
 
-```bash label="[kc-lab-1] 온라인 세션과 offline token 을 나눠 센다"
+```bash label="[lab host] 온라인 세션과 offline token 을 나눠 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select offline_flag, count(*) from offline_user_session group by offline_flag"
 ```
@@ -174,7 +176,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
      └─ 단독 탐침 파드의 /tmp   → StatefulSet 과 무관하게 산다   ★
 ```
 
-```bash label="[kc-lab-1] ① 탐침을 띄우고 Ready 를 기다린다"
+```bash label="[lab host] ① 탐침을 띄우고 Ready 를 기다린다"
 kubectl -n keycloak-lab run a8-probe --image=curlimages/curl:8.11.1 \
   --restart=Never \
   --env="K0=$K0" --env="K1=$K1" \
@@ -186,7 +188,7 @@ kubectl -n keycloak-lab wait --for=condition=Ready pod/a8-probe --timeout=120s
 
 비밀번호는 명령 치환으로 넘어가므로 터미널에도 셸 히스토리에도 값이 남지 않는다. 길이만 본다.
 
-```bash label="[kc-lab-1] ② 비밀번호의 길이만 센다"
+```bash label="[lab host] ② 비밀번호의 길이만 센다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets \
   -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d | wc -c
 ```
@@ -195,7 +197,7 @@ kubectl -n keycloak-lab get secret keycloak-lab-secrets \
 19
 ```
 
-```bash label="[kc-lab-1] ③ 탐침 안에 값이 들어갔는지 본다"
+```bash label="[lab host] ③ 탐침 안에 값이 들어갔는지 본다"
 kubectl -n keycloak-lab exec a8-probe -- sh -c 'echo "K0=$K0 K1=$K1 PW길이=${#PW}"'
 ```
 
@@ -205,7 +207,7 @@ kubectl -n keycloak-lab exec a8-probe -- sh -c 'echo "K0=$K0 K1=$K1 PW길이=${#
 
 **문제가 생기면** — `PW길이=0` 이면 `--env` 가 빈 값을 받았다. 파드를 지우고 ① 부터 다시 한다. `--rm` 이 없는 상주 파드라 지우지 않으면 같은 이름이 그대로 있어 ① 이 `AlreadyExists` 로 거절되고, 이 절차를 두 번째 칠 때도 같은 곳에서 걸린다.
 
-```bash label="[kc-lab-1] ④ 탐침을 지우고 ① 로 돌아간다"
+```bash label="[lab host] ④ 탐침을 지우고 ① 로 돌아간다"
 kubectl -n keycloak-lab delete pod a8-probe --ignore-not-found
 ```
 
@@ -215,7 +217,7 @@ kubectl -n keycloak-lab delete pod a8-probe --ignore-not-found
 
 이 단계에 이 실험의 함정이 있다.
 
-```bash label="[kc-lab-1] ① 로그인해서 refresh token 과 sid 를 파일로 남긴다"
+```bash label="[lab host] ① 로그인해서 refresh token 과 sid 를 파일로 남긴다"
 kubectl -n keycloak-lab exec a8-probe -- sh -c \
   'curl -s -X POST "http://$K0:8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
@@ -246,7 +248,7 @@ kubectl -n keycloak-lab exec a8-probe -- sh -c \
 
 못 미더우면 파일을 직접 본다.
 
-```bash label="[kc-lab-1] ② 파일 크기와 앞 40바이트를 본다"
+```bash label="[lab host] ② 파일 크기와 앞 40바이트를 본다"
 kubectl -n keycloak-lab exec a8-probe -- ls -l /tmp/tok /tmp/rt /tmp/sid
 kubectl -n keycloak-lab exec a8-probe -- head -c 40 /tmp/rt ; echo
 ```
@@ -264,7 +266,7 @@ eyJhbGciOiJIUzUxMiIsInR5cCIgOiAiSldU
 
 **목적** — 뒤의 `200` 이 무엇과 견준 값인지 확보한다.
 
-```bash label="[kc-lab-1] ① 같은 노드에서 갱신해 본다"
+```bash label="[lab host] ① 같은 노드에서 갱신해 본다"
 kubectl -n keycloak-lab exec a8-probe -- sh -c \
   'curl -s -o /dev/null -w "%{http_code}\n" -X POST \
      "http://$K0:8080/realms/master/protocol/openid-connect/token" \
@@ -280,7 +282,7 @@ kubectl -n keycloak-lab exec a8-probe -- sh -c \
 
 이 refresh 로 토큰이 회전했다. `/tmp/rt` 의 값은 이제 이미 쓴 토큰이라 다시 채워야 하고, 안 채우면 뒤의 `400` 이 재시작 때문인지 재사용 때문인지 구별되지 않는다. 5번의 ① 과 같은 명령을 그대로 다시 친다.
 
-```bash label="[kc-lab-1] ② 다시 로그인해서 두 파일을 새로 만든다"
+```bash label="[lab host] ② 다시 로그인해서 두 파일을 새로 만든다"
 kubectl -n keycloak-lab exec a8-probe -- sh -c \
   'curl -s -X POST "http://$K0:8080/realms/master/protocol/openid-connect/token" \
      -d grant_type=password -d client_id=admin-cli \
@@ -302,11 +304,11 @@ kubectl -n keycloak-lab exec a8-probe -- sh -c \
 
 원 가이드의 질의는 `sid` 를 셸 치환으로 집어넣어 `psql -c` 문자열 안에 `kubectl exec` 이 한 번 더 들어간다. 따라 하는 사람은 방금 적어 둔 `sid` 를 그대로 친다 — 앞 명령이 이미 그 값을 화면에 보여 줬고, 명령 하나가 한 가지 일만 한다. 이 두 단계 형태는 이 실험대에서 치지 않았다(unknown).
 
-```bash label="[kc-lab-1] ① sid 를 화면에서 읽는다"
+```bash label="[lab host] ① sid 를 화면에서 읽는다"
 kubectl -n keycloak-lab exec a8-probe -- cat /tmp/sid
 ```
 
-```bash label="[kc-lab-1] ② 읽은 값을 그대로 넣어 행을 찾는다"
+```bash label="[lab host] ② 읽은 값을 그대로 넣어 행을 찾는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select user_session_id, created_on, last_session_refresh from offline_user_session
       where offline_flag='0' and user_session_id='{{SID}}'"
@@ -333,7 +335,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **목적** — 재시작 후 0 이 되는 값을 먼저 확보한다.
 
-```bash label="[kc-lab-1] ① 한 줄짜리 JSON 을 통째로 본다"
+```bash label="[lab host] ① 한 줄짜리 JSON 을 통째로 본다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size'
 ```
@@ -348,7 +350,7 @@ kubectl -n observability exec deploy/prometheus -- \
 
 라벨을 보고 나면 읽기 좋게 자른다. 아래 형태는 가이드가 미검증으로 표시한 줄이다(unknown).
 
-```bash label="[kc-lab-1] ② 파드와 값만 세로로 늘어놓는다"
+```bash label="[lab host] ② 파드와 값만 세로로 늘어놓는다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_cluster_size' \
   | tr ',' '\n' | grep -E '"pod":|^"[0-9]'
@@ -381,21 +383,21 @@ echo
 
 첫 번째 터미널에서 재시작한다. `rollout restart` 는 바로 돌아오고, 파드 교체는 그 뒤에 백그라운드로 진행된다.
 
-```bash label="[kc-lab-1] ② 시각을 남기고 롤링 재시작을 건다"
+```bash label="[lab host] ② 시각을 남기고 롤링 재시작을 건다"
 date '+%H:%M:%S 재시작'
 kubectl -n keycloak-lab rollout restart statefulset/keycloak
 ```
 
 **엔드포인트는 여기서 봐야 보인다.** 파드가 서비스에서 빠졌다 돌아오는 것은 롤아웃이 도는 동안에만 나타나고, 끝난 뒤에 치면 ready 주소가 늘 둘로 나온다. 두 번째 터미널은 ① 의 루프에 붙잡혀 있으므로 이 터미널에서 몇 번 반복해서 친다. 찍힌 것을 어떻게 읽는지는 15번에서 적는다.
 
-```bash label="[kc-lab-1] ③ 롤아웃이 도는 동안 엔드포인트를 몇 번 본다"
+```bash label="[lab host] ③ 롤아웃이 도는 동안 엔드포인트를 몇 번 본다"
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=keycloak \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 ```
 
 그다음 롤아웃이 끝날 때까지 기다린다. 이 명령은 끝날 때까지 터미널을 붙잡는다.
 
-```bash label="[kc-lab-1] ④ 롤아웃이 끝날 때까지 기다린다"
+```bash label="[lab host] ④ 롤아웃이 끝날 때까지 기다린다"
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=420s
 ```
 
@@ -426,7 +428,7 @@ Waiting for 1 pods to be ready...
 
 **목적** — 「세션이 살아남았다」가 의미를 갖는 조건을 확인한다.
 
-```bash label="[kc-lab-1] 파드 나이와 재시작 카운터를 본다"
+```bash label="[lab host] 파드 나이와 재시작 카운터를 본다"
 kubectl -n keycloak-lab get pods -o wide | grep keycloak
 ```
 
@@ -446,7 +448,7 @@ keycloak-1                  1/1   Running   0     66s
 
 파드 IP 가 바뀌었으므로 다시 잡는다. 탐침 파드는 다시 띄우지 않는다 — `/tmp/rt` 와 `/tmp/sid` 가 같이 사라진다. 탐침 안의 `K0` 환경변수는 낡았으므로 새 IP 를 명령줄로 넘긴다.
 
-```bash label="[kc-lab-1] 새 파드 IP 를 다시 잡는다"
+```bash label="[lab host] 새 파드 IP 를 다시 잡는다"
 K0=$(kubectl -n keycloak-lab get pod keycloak-0 -o jsonpath='{.status.podIP}')
 K1=$(kubectl -n keycloak-lab get pod keycloak-1 -o jsonpath='{.status.podIP}')
 echo "$K0 $K1"
@@ -507,7 +509,7 @@ echo
 
 셸 인용이 세 겹이 되는 형태이고, 가이드는 여기에 다른 형태를 제시하지 않는다. 탐침을 다시 띄우면 토큰이 사라지기 때문이다.
 
-```bash label="[kc-lab-1] 재시작 전 토큰으로 갱신을 시도한다"
+```bash label="[lab host] 재시작 전 토큰으로 갱신을 시도한다"
 kubectl -n keycloak-lab exec a8-probe -- sh -c \
   'curl -s -w "\n%{http_code}\n" -X POST \
      "http://'"$K0"':8080/realms/master/protocol/openid-connect/token" \
@@ -529,13 +531,32 @@ kubectl -n keycloak-lab exec a8-probe -- sh -c \
 
 **문제가 생기면** — 아무 데도 안 닿으면 파드 IP 가 바뀐 것을 명령에 반영하지 않았다. 10번의 IP 잡기를 다시 한다.
 
+**2026-09-17 실측**(observed) — 롤링 재시작 전후로 같은 토큰을 썼다.
+
+```text
+재시작 전 대조군            200
+재시작 (파드 둘 교체)       AGE 31s · 63s · IP 10.42.1.47→.49, 10.42.0.20→.21
+재시작 뒤 같은 refresh      200 · session_state 가 같은 sid
+DB 행                       created_on 1789625835 그대로 · last_session_refresh 1789625835 → 1789625952
+캐시                        재시작 전후 모두 keycloak-0/1 sessions 0
+클러스터                    다시 2
+```
+
+**`created_on` 은 그대로이고 `last_session_refresh` 만 117초 뒤로 갔다.** 새로 만든 세션이 아니라 **남아 있던 행을 새 파드가 읽어서 갱신한 것**이고, 그것이 이 편의 결론이다.
+
+**탐침 안의 `$K0` 는 재시작 뒤에 낡는다.** 2026-09-17 에 낡은 값으로 쳐서 `000` 을 받았다(observed) — 문서가 미리 적어 둔 그 함정이다. 새 IP 를 명령줄로 넘겨 다시 쳤다.
+
+```text
+새 K0=10.42.1.49 (탐침 안의 낡은 값=10.42.1.47)
+```
+
 ### 13. DB 행의 두 시각을 견준다
 
 **목적** — 응답 코드만이 아니라 쓰기까지 정상인지 본다.
 
 적어 둔 `sid` 를 넣어 7번의 ② 와 같은 질의를 다시 친다.
 
-```bash label="[kc-lab-1] ① 같은 행을 다시 찾는다"
+```bash label="[lab host] ① 같은 행을 다시 찾는다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select user_session_id, created_on, last_session_refresh from offline_user_session
       where offline_flag='0' and user_session_id='{{SID}}'"
@@ -562,7 +583,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 두 값은 유닉스 시각(초)이라 사람이 읽는 형태로 보려면 이렇게 친다.
 
-```bash label="[kc-lab-1] ② 두 유닉스 시각을 사람이 읽는 형태로 바꾼다"
+```bash label="[lab host] ② 두 유닉스 시각을 사람이 읽는 형태로 바꾼다"
 date -d @1788495513 ; date -d @1788495577
 ```
 
@@ -572,7 +593,7 @@ date -d @1788495513 ; date -d @1788495577
 
 전체 세션 수도 함께 본다.
 
-```bash label="[kc-lab-1] ③ 온라인 세션 전체를 센다"
+```bash label="[lab host] ③ 온라인 세션 전체를 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -tAc "select count(*) from offline_user_session where offline_flag='0'"
 ```
@@ -587,7 +608,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
 
 **목적** — 재시작이 무엇을 지우고 무엇을 남겼는지 가른다.
 
-```bash label="[kc-lab-1] 캐시 엔트리 수와 클러스터 크기를 이어서 본다"
+```bash label="[lab host] 캐시 엔트리 수와 클러스터 크기를 이어서 본다"
 kubectl -n observability exec deploy/prometheus -- \
   wget -qO- 'localhost:9090/api/v1/query?query=vendor_statistics_approximate_entries_unique' \
   | tr ',' '\n' | grep -E '"cache":|"pod":|^"[0-9]'
@@ -650,7 +671,7 @@ kubectl -n observability exec deploy/prometheus -- \
 
 주입이 정상 작업이었으므로 되돌릴 것이 없다. 정리만 한다.
 
-```bash label="[kc-lab-1] 탐침 파드를 지운다"
+```bash label="[lab host] 탐침 파드를 지운다"
 kubectl -n keycloak-lab delete pod a8-probe --ignore-not-found
 ```
 
diff --git a/docs/keycloak-session-store/tech-log-studio/tech-log-tree.json b/docs/keycloak-session-store/tech-log-studio/tech-log-tree.json
index e779799..5d155c3 100644
--- a/docs/keycloak-session-store/tech-log-studio/tech-log-tree.json
+++ b/docs/keycloak-session-store/tech-log-studio/tech-log-tree.json
@@ -7,7 +7,7 @@
     "revision": "9465582b5d1630eb4ae7c4e078021486919bf6b6",
     "verified": "반입할 때 적어 둔 source/.source-revision 이 이 커밋이고 저장소에 실재한다 — 「chore: 실행 환경 구성 문서 추가 및 수정」, 2026-09-10. **전에 이 칸은 cdac9b81 이었고 그것은 틀렸다** (2026-09-17 대조) — 그 커밋은 2026-09-04 이고 반입본 306개 가운데 docs/guides/** 28개가 거기에 아예 없다. 가이드는 그 엿새 뒤 6f6ab86 에서 들어왔다. **그런데 반입한 바이트는 이 커밋과도 같지 않다** — 9465582b 와 같은 것은 276개이고 29개가 다르다. 같은 306개를 저장소의 **작업 트리**와 견주면 297개가 같다. HEAD 에서 200 커밋을 거슬러 전수 대조했을 때 가장 가까운 6f6ab86 도 28개가 어긋났다. **맞는 커밋은 없다** — 반입은 커밋이 아니라 **그 시점의 작업 트리**(미커밋 수정이 있던 상태)에서 떠 온 것이다. 지금도 저장소는 그 파일들을 M 으로 낸다. 작업 트리와 남은 차이 8개 가운데 5개가 그 M 목록에 있고(반입 뒤 저장소가 더 고쳤다), deploy/lab/host/nginx-keycloak-lab.conf 는 저장소에서 deploy/lab/edge/ 로 옮겨져 반입본에만 남았다. **이 커밋은 「반입 시점의 HEAD」라는 뜻이지 「반입한 바이트가 이것이다」가 아니다**"
   },
-  "ssotSha256": "986918aa05f1a7143ba6a6e30d1eed0e748f0daa8bb70aaf32c56f0f88e56620",
+  "ssotSha256": "f3916ea7c24798627a7e75e5f859af25e29ff404d218816c032e9356f0bf9dc8",
   "sourceRevision": "keycloak-session-lab@2026-09",
   "generatedAt": "2026-09-17",
   "candidateScope": {
diff --git a/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b4-forged-identity-headers.md b/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b4-forged-identity-headers.md
index f4470f7..7e2f9c3 100644
--- a/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b4-forged-identity-headers.md
+++ b/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b4-forged-identity-headers.md
@@ -37,7 +37,9 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 ## 읽기 전에 — 어디서 치는가
 
-기계가 셋이다. 위조 요청을 보내는 `curl` 은 어디서 쳐도 되고 밖에서 치는 편이 공격자 관점에 가깝다. `kubectl` 은 `[kc-lab-1]` 에서 치고 `sudo` 를 붙이지 않는다. **랩 호스트(`test-server`)로 넘어가는 것은 nginx 설정을 만지는 단계 하나뿐이고**, 그 블록만 `[test-server]` 라벨이 붙어 있다. 5절의 클레임 반영은 브라우저 콘솔에서 잰다 — oauth2-proxy 세션 쿠키가 `HttpOnly` 라 `curl` 로 로그인 상태를 재현할 수 없다.
+기계가 셋이다. 위조 요청을 보내는 `curl` 은 어디서 쳐도 되고 밖에서 치는 편이 공격자 관점에 가깝다. `kubectl` 은 `[lab host]` 에서 치고 `sudo` 를 붙이지 않는다. **랩 호스트(`test-server`)로 넘어가는 것은 nginx 설정을 만지는 단계 하나뿐이고**, 그 블록만 `[test-server]` 라벨이 붙어 있다. 5절의 클레임 반영은 브라우저 콘솔에서 잰다 — oauth2-proxy 세션 쿠키가 `HttpOnly` 라 `curl` 로 로그인 상태를 재현할 수 없다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 | 무엇 | 값 |
 |---|---|
@@ -86,7 +88,7 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 그 `HttpOnly` 는 짐작이 아니라 기동 로그에 적혀 있다.
 
-```bash label="[kc-lab-1] 쿠키 속성을 기동 로그에서 읽는다"
+```bash label="[lab host] 쿠키 속성을 기동 로그에서 읽는다"
 kubectl -n keycloak-lab logs -l app=oauth2-proxy | grep -i 'Cookie settings' | head -1
 ```
 
@@ -109,14 +111,14 @@ kubectl -n keycloak-lab logs -l app=oauth2-proxy | grep -i 'Cookie settings' | h
 
 되돌리기는 셋이고 셋 다 먼저 읽어 둔다.
 
-```bash label="[kc-lab-1] 중간에 그만둘 때 ① Ingress 를 돌려준다"
+```bash label="[lab host] 중간에 그만둘 때 ① Ingress 를 돌려준다"
 kubectl -n keycloak-lab delete ingress oauth2-proxy
 kubectl apply -f /tmp/grafana-ingress-backup.yaml
 ```
 
 `$USER_ID` 는 주입 5절 ③ 에서 잡는 값이라 여기를 먼저 읽는 지금은 비어 있다. 실제로 칠 일이 생기는 것은 그 절을 친 뒤이고, 1~3 절만 하고 그만두는 사람은 email 을 바꾼 적이 없으니 이 줄 자체가 필요 없다.
 
-```bash label="[kc-lab-1] 중간에 그만둘 때 ② IdP 의 email 을 되돌린다 — $USER_ID 를 잡은 뒤에 친다"
+```bash label="[lab host] 중간에 그만둘 때 ② IdP 의 email 을 되돌린다 — $USER_ID 를 잡은 뒤에 친다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   update users/$USER_ID -r keycloak-patterns -s email=labuser@example.com
 ```
@@ -140,7 +142,7 @@ sudo nginx -t && sudo systemctl reload nginx
 
 **무엇을 보는가** — 같은 호스트를 잡고 있는 Ingress 목록.
 
-```bash label="[kc-lab-1] ① Ingress 를 전부 본다"
+```bash label="[lab host] ① Ingress 를 전부 본다"
 kubectl get ingress -A
 ```
 
@@ -156,7 +158,7 @@ observability  grafana        traefik   app2.hyeonworks.com               80
 
 `app1` 이 두 줄이다. 같은 호스트에 Ingress 가 둘이고 경로로 갈린다. 어느 경로가 어디로 가는지는 눈으로 본다.
 
-```bash label="[kc-lab-1] ② echo 의 경로 규칙을 본다"
+```bash label="[lab host] ② echo 의 경로 규칙을 본다"
 kubectl -n header-lab describe ingress echo | grep -A5 Rules
 ```
 
@@ -193,16 +195,30 @@ curl -s https://app1.hyeonworks.com/api/echo
 
 **이 값이 뜻하는 것** — `headers` 의 값이 전부 배열이다. HTTP 가 같은 이름의 헤더를 여러 번 허용하기 때문이고, 동명 헤더를 두 개 보냈을 때 무엇이 도착했는지도 이 배열이 말해 준다. `x-forwarded-proto` 가 `https` 인 것은 nginx 가 `proxy_set_header` 로 설정한 헤더라서다. `scheme` · `secure` · `serverName` 은 Keycloak 이 `iss` 클레임과 리다이렉트를 만들 때 쓰는 값들이다.
 
-걸러 볼 때는 `grep -o` 를 쓴다. 가이드가 이 줄을 미검증으로 표시했다(unknown).
+걸러 볼 때는 `grep -o` 를 쓴다. **2026-09-17 에 쳐 보니 이 형태는 한 줄도 못 잡는다**(observed).
 
-```bash label="[밖에서] 한 헤더만 뽑아 본다"
+```bash label="[밖에서] 한 헤더만 뽑아 본다 — 이 형태는 안 걸린다"
 curl -s https://app1.hyeonworks.com/api/echo | grep -o '"x-forwarded-proto":\[[^]]*\]'
 ```
 
+`echo` 가 응답을 **들여쓰고 콜론 양옆에 공백을 넣어** 찍기 때문이다. 위 실측은 줄바꿈을 없애고 옮겨 적은 것이라 그 공백이 안 보인다. 실제 화면은 이렇다(observed).
+
 ```text
-"x-forwarded-proto":["https"]
+  "x-forwarded-proto" : [ "http" ],
 ```
 
+콜론과 대괄호 안쪽의 공백을 허용한다.
+
+```bash label="[밖에서] 공백을 허용한 형태"
+curl -s https://app1.hyeonworks.com/api/echo | grep -o '"x-forwarded-proto" *: *\[[^]]*\]'
+```
+
+```text
+"x-forwarded-proto" : [ "http" ]
+```
+
+**아래 3절의 `grep -o '"x-auth-request[^]]*\]'` 는 그대로 써도 된다.** 이름 뒤에 바로 `:` 를 요구하지 않아서 공백이 있어도 걸린다. 콜론을 붙여 쓴 형태만 고치면 된다.
+
 **`tr ',' '\n' | grep` 은 여기서 쓰면 안 된다.** 값 배열이 `["admin","editor"]` 처럼 쉼표를 품고 있어서 배열이 두 줄로 잘린다. 첫 줄만 보고 「하나만 도착했다」로 읽게 되는데, 이 절차에서 가장 조심할 오독이다. `grep -o '…\[[^]]*\]'` 는 대괄호 안을 통째로 뽑는다.
 
 ### 3. 대조군 — 아무것도 안 붙였을 때 무엇이 도착하나
@@ -213,7 +229,7 @@ curl -s https://app1.hyeonworks.com/api/echo | grep -o '"x-forwarded-proto":\[[^
 curl -s https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request[^]]*\]'
 ```
 
-**어디를 보나** — 아무것도 안 나와야 한다.
+**어디를 보나** — 아무것도 안 나와야 한다. 2026-09-17 에도 아무것도 안 나왔다(observed).
 
 **이 값이 뜻하는 것** — `x-auth-request-*` 는 엣지가 붙이는 헤더인데 `app1` 앞에는 oauth2-proxy 가 없으므로 지금은 없다. 이 칸이 비어 있는 것이 대조군이다. 주입 뒤 여기에 값이 나타나면 그건 내가 보낸 것이 도착한 것이고, 이 확인을 건너뛰면 원래 있던 것과 내가 넣은 것이 구별되지 않는다.
 
@@ -255,14 +271,20 @@ nginx 는 자기가 `proxy_set_header` 로 설정한 헤더만 덮어쓴다. 설
 
 **목적** — 같은 이름의 헤더 둘이 도착 시점에 어떻게 보이는지 만든다.
 
-① 같은 헤더를 값만 달리해 두 번 붙인다. 가이드가 미검증으로 표시했다(unknown) — 원래 실행은 스크립트가 응답을 정리했고 아래는 같은 값을 `grep` 으로 뽑는 형태다.
+① 같은 헤더를 값만 달리해 두 번 붙인다. **2026-09-17 에 쳐서 확인했다**(observed) — 원래 실행은 스크립트가 응답을 정리했고 아래는 같은 값을 `grep` 으로 뽑는 형태다. 콜론 양옆 공백을 허용해야 걸린다.
 
 ```bash label="[밖에서] 동명 헤더 두 개를 보낸다"
 curl -s -H 'X-Auth-Request-Roles: admin' -H 'X-Auth-Request-Roles: editor' \
-  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles":\[[^]]*\]'
+  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles" *: *\[[^]]*\]'
 ```
 
-**예상 결과** — 대괄호 안에 값이 둘 들어온다. 판정은 관찰 절에서 한다.
+**예상 결과** — 대괄호 안에 값이 둘 들어온다. 2026-09-17 실측이다(observed).
+
+```text
+"x-auth-request-roles" : [ "admin", "editor" ]
+```
+
+판정은 관찰 절에서 한다.
 
 **왜 필요한가** — 덮어쓰는지, 합치는지, 통과시키는지 셋 중 어느 것인지가 여기서 갈린다.
 
@@ -276,14 +298,19 @@ curl -s -H 'X-Auth-Request-Roles: admin' -H 'X-Auth-Request-Roles: editor' \
 
 ```bash label="[밖에서] 쉼표 구분과 값 안 쉼표를 각각 보낸다"
 curl -s -H 'X-Auth-Request-Roles: admin,editor,viewer' \
-  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles":\[[^]]*\]'
+  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles" *: *\[[^]]*\]'
 curl -s -H 'X-Auth-Request-Roles: role-with,comma' \
-  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles":\[[^]]*\]'
+  https://app1.hyeonworks.com/api/echo | grep -o '"x-auth-request-roles" *: *\[[^]]*\]'
 ```
 
-**예상 결과** — 두 줄이 같은 모양으로 온다.
+**예상 결과** — 두 줄이 같은 모양으로 온다. 2026-09-17 실측이다(observed).
 
-**왜 필요한가** — role 이름에 쉼표가 들어갈 수 있다면 쉼표로 자르는 방식이 성립하지 않는다.
+```text
+"x-auth-request-roles" : [ "admin,editor,viewer" ]
+"x-auth-request-roles" : [ "role-with,comma" ]
+```
+
+**왜 필요한가** — role 이름에 쉼표가 들어갈 수 있다면 쉼표로 자르는 방식이 성립하지 않는다. 위 두 줄이 도착 시점에 구별되지 않는다는 것이 그 근거다.
 
 **문제가 생기면** — 대괄호째 뽑았는지 다시 본다.
 
@@ -328,7 +355,14 @@ curl -s \
   https://app1.hyeonworks.com/api/echo
 ```
 
-**예상 결과** — echo 앱이 응답을 돌려준다. 무엇이 돌아왔는지는 주입 검증에서 읽는다.
+**예상 결과** — echo 앱이 응답을 돌려준다. 무엇이 돌아왔는지는 주입 검증에서 읽는다. 2026-09-17 에 쳐 보니 위조한 두 줄이 그대로 도착했다(observed).
+
+```text
+"x-auth-request-email" : [ "attacker@evil.invalid" ]
+"x-auth-request-user" : [ "attacker" ]
+```
+
+대조군(3절)에서는 그 칸이 비어 있었으므로, 이 두 줄은 **내가 보낸 것이 엣지를 지나 앱까지 닿았다**는 뜻이다.
 
 **왜 필요한가** — 여기까지가 요청만으로 되는 부분이다. 설치한 것도 받은 권한도 없다.
 
@@ -340,7 +374,7 @@ curl -s \
 
 ① 백업이 먼저다. 파일이 생겼는지 줄 수로 확인한 뒤에 원본을 지운다.
 
-```bash label="[kc-lab-1] ① Grafana Ingress 를 백업하고 프록시를 올린다"
+```bash label="[lab host] ① Grafana Ingress 를 백업하고 프록시를 올린다"
 kubectl -n observability get ingress grafana -o yaml > /tmp/grafana-ingress-backup.yaml
 wc -l /tmp/grafana-ingress-backup.yaml
 kubectl -n observability delete ingress grafana
@@ -354,7 +388,7 @@ kubectl -n keycloak-lab rollout status deployment/oauth2-proxy --timeout=180s
 
 ③ IdP 의 email 을 바꾸고 변경 시각을 UTC 로 남긴다.
 
-```bash label="[kc-lab-1] ③ IdP 의 email 을 바꾸고 시각을 남긴다"
+```bash label="[lab host] ③ IdP 의 email 을 바꾸고 시각을 남긴다"
 USER_ID=$(kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
         get users -r keycloak-patterns -q username=labuser \
         --fields id --format csv --noquotes | tail -1)
@@ -429,7 +463,7 @@ done
 
 **둘째 주입은 IdP 쪽이 정말 바뀌었는지와 세션이 그대로인지를 같이 본다.** 바뀌지 않은 것을 「반영 안 됨」으로 읽지 않으려면 반드시 본다.
 
-```bash label="[kc-lab-1] IdP 의 email 을 다시 읽는다"
+```bash label="[lab host] IdP 의 email 을 다시 읽는다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get users/$UID -r keycloak-patterns --fields email
 ```
@@ -450,7 +484,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 IdP 값은 바뀌었고 세션은 하나다. 이 두 줄이 있어야 다음 절의 옛 값을 「반영 안 됨」이라고 말할 수 있다. 세션 목록은 지우기 전에 항상 먼저 본다.
 
-```bash label="[kc-lab-1] oauth2-proxy 세션 키를 본다"
+```bash label="[lab host] oauth2-proxy 세션 키를 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '_oauth2_proxy-*'
 ```
 
@@ -472,7 +506,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '_oauth2
     도착:   ['admin', 'editor']              ← ★ 둘 다 도착. 덮어쓰지도 합치지도 않는다
 ```
 
-`curl` 로 직접 보면 `"x-auth-request-roles":["admin","editor"]` 로 보인다. 셋 중 어느 것도 아니었다.
+`curl` 로 직접 보면 `"x-auth-request-roles" : [ "admin", "editor" ]` 로 보인다. 셋 중 어느 것도 아니었다.
 
 | 가설 | 도착했을 모양 | 실제 |
 |---|---|---|
@@ -630,7 +664,7 @@ D 층의 「106초」와 이 「약 107초」는 같은 왜곡을 두 번 쟀다
 
 세션을 지우고 재인증시키면 새 값이 온다. 지우기 전에 목록을 본다. 가이드가 두 번째 줄을 미검증으로 표시했다(unknown).
 
-```bash label="[kc-lab-1] 세션을 보고 지운다"
+```bash label="[lab host] 세션을 보고 지운다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '_oauth2_proxy-*'
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '_oauth2_proxy-*' \
   | xargs -r kubectl -n keycloak-lab exec deploy/redis -- redis-cli del
@@ -694,7 +728,7 @@ D-4a 가 같은 판정법을 인증서 갱신에 쓴다.
 
 ① 사용자 id 를 다시 잡고 값을 되돌린 뒤 같은 명령으로 읽는다.
 
-```bash label="[kc-lab-1] email 을 되돌리고 다시 읽는다"
+```bash label="[lab host] email 을 되돌리고 다시 읽는다"
 USER_ID=$(kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
         get users -r keycloak-patterns -q username=labuser \
         --fields id --format csv --noquotes | tail -1)
@@ -720,14 +754,14 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 ① oauth2-proxy 것을 먼저 지우고 Grafana 것을 올린다.
 
-```bash label="[kc-lab-1] ① Ingress 를 돌려준다"
+```bash label="[lab host] ① Ingress 를 돌려준다"
 kubectl -n keycloak-lab delete ingress oauth2-proxy
 kubectl apply -f /tmp/grafana-ingress-backup.yaml
 ```
 
 ② 하나만 남았는지 확인한다.
 
-```bash label="[kc-lab-1] ② app2 를 잡고 있는 Ingress 를 센다"
+```bash label="[lab host] ② app2 를 잡고 있는 Ingress 를 센다"
 kubectl get ingress -A | grep app2
 curl -s -o /dev/null -w '%{http_code}\n' https://app2.hyeonworks.com/
 ```
diff --git a/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b7-cookie-secret-rotation.md b/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b7-cookie-secret-rotation.md
index eab7e7a..52cf2ea 100644
--- a/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b7-cookie-secret-rotation.md
+++ b/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b7-cookie-secret-rotation.md
@@ -41,7 +41,9 @@ oauth2-proxy 의 cookie secret 을 A 에서 B 로 바꿨을 때 로그인해 있
 
 ## 읽기 전에 — 어디서 치는가
 
-기계가 둘이고 표시가 둘이다. `kubectl` 과 `redis-cli` 는 `[kc-lab-1]` 에서 치고, 앞단 nginx 를 건너뛰고 Traefik 을 직접 두드리는 `curl` 과 `sudo` 는 `[test-server]` 에서 친다. 앞단 nginx 가 그 호스트에 있고 `192.168.122.11:80` 으로 넘겨주므로, 호스트에서 그 주소를 바로 치면 nginx 를 건너뛴다.
+기계가 둘이고 표시가 둘이다. `kubectl` 과 `redis-cli` 는 `[lab host]` 에서 치고, 앞단 nginx 를 건너뛰고 Traefik 을 직접 두드리는 `curl` 과 `sudo` 는 `[test-server]` 에서 친다. 앞단 nginx 가 그 호스트에 있고 `192.168.122.11:80` 으로 넘겨주므로, 호스트에서 그 주소를 바로 치면 nginx 를 건너뛴다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 브라우저도 필요하다. 쿠키가 `HttpOnly` 이고 OIDC(OpenID Connect, OAuth2 위에 신원 확인을 얹은 규격) 흐름을 폼까지 걸어야 세션이 생긴다. `curl` 로 완주하려던 시도는 실패했다.
 
@@ -87,11 +89,22 @@ B-6 에서 Keycloak 은 두 키를 동시에 들고 무중단으로 회전했다
 - B-0 이 끝나 있어야 한다. Redis 를 거기서 띄우고 `redis.keycloak-lab.svc:6379` 로 떠 있다.
 - 브라우저가 있어야 한다.
 
+**`oauth2-proxy` 는 인증서가 서기 전에는 못 뜬다.** 기동할 때 OIDC 디스커버리를 먼저 하는데 그 주소가 `https://auth.hyeonworks.com/...` 이라, 인증서 단계를 안 끝낸 실험대에서는 `CrashLoopBackOff` 로 끝난다. 2026-09-17 에 그대로 겪었다(observed).
+
+```text
+[provider.go:55] Performing OIDC Discovery...
+[main.go:59] ERROR: Failed to initialise OAuth2 Proxy: ... error while discovery OIDC configuration:
+  Get "https://auth.hyeonworks.com/realms/keycloak-patterns/.well-known/openid-configuration":
+  dial tcp 100.83.212.4:443: connect: connection refused
+```
+
+`oauth2-proxy-secrets` 가 있고 이미지도 받아지는데 기동 자체가 안 된다 — **이 편의 전제는 배포가 아니라 TLS 다.**
+
 **이건 남의 도메인을 빌리고 남의 세션을 끊는 실험이다.** 둘을 건드린다. 인증서가 `auth` · `app1` · `app2` 세 이름만 덮어서 네 번째 이름을 못 만들기 때문에 Grafana 의 Ingress 를 잠시 내리고 `app2` 를 빌린다. 그리고 secret 을 바꾸면 그때 로그인해 있던 사람의 쿠키가 전부 무효가 된다.
 
 되돌리기는 둘이고 먼저 읽어 둔다.
 
-```bash label="[kc-lab-1] ① secret 참조를 A 로 되돌린다"
+```bash label="[lab host] ① secret 참조를 A 로 되돌린다"
 kubectl -n keycloak-lab patch deployment oauth2-proxy --type=json \
   -p '[{"op":"replace",
         "path":"/spec/template/spec/containers/0/env/1/valueFrom/secretKeyRef/key",
@@ -100,7 +113,7 @@ kubectl -n keycloak-lab patch deployment oauth2-proxy --type=json \
 
 ①의 `env/1` 은 매니페스트의 env 배열 순서에 달린 숫자다. 중간에 멈춰서 되돌리는 사람은 주입 2 절 ①의 `env[*].name` 을 먼저 쳐서 `OAUTH2_PROXY_COOKIE_SECRET` 이 0 부터 세어 몇 번째인지 보고, 두 번째가 아니면 위 경로의 `1` 을 그 숫자로 바꾼다. 숫자가 틀리면 클라이언트 비밀을 쿠키 secret 으로 덮어쓴다.
 
-```bash label="[kc-lab-1] ② 빌린 Ingress 를 걷고 Grafana 것을 올린다"
+```bash label="[lab host] ② 빌린 Ingress 를 걷고 Grafana 것을 올린다"
 kubectl -n keycloak-lab delete ingress oauth2-proxy
 kubectl apply -f ~/grafana-ingress-backup.yaml
 ```
@@ -125,7 +138,7 @@ curl -sI https://app2.hyeonworks.com/ | head -3
 
 **②를 치기 전에 읽는다.** 셸은 `>` 를 kubectl 보다 먼저 처리한다. `~/grafana-ingress-backup.yaml` 은 kubectl 이 돌기도 전에 0바이트가 되고, `get` 이 실패하면 앞서 떠 둔 백업이 그때 없어진다. 뒤따르는 `wc -l` 과 `grep -c` 는 이미 비어 버린 파일을 센다. 그래서 이 절을 두 번째로 치는 사람은 — B-4 로 app2 를 먼저 빌렸거나 실험을 중간에 다시 시작했다면 — `wc -l ~/grafana-ingress-backup.yaml` 을 먼저 쳐서 쓸 만한 백업을 이미 갖고 있는지 보고, 갖고 있으면 ②를 건너뛴다.
 
-```bash label="[kc-lab-1] ② 백업을 뜨고 내용이 있는지 센다"
+```bash label="[lab host] ② 백업을 뜨고 내용이 있는지 센다"
 kubectl -n observability get ingress grafana -o yaml > ~/grafana-ingress-backup.yaml
 wc -l ~/grafana-ingress-backup.yaml
 grep -c 'app2.hyeonworks.com' ~/grafana-ingress-backup.yaml
@@ -143,11 +156,11 @@ grep -c 'app2.hyeonworks.com' ~/grafana-ingress-backup.yaml
 
 **행동** — 내리고, 올리고, 롤아웃이 끝날 때까지 기다린다. ②의 `deploy/lab/k8s/b7-oauth2-proxy.yaml` 은 저장소 체크아웃의 루트에서 푸는 상대 경로다. 체크아웃을 어디에 뒀는지는 가이드에 없으므로(unknown), 그 경로가 풀리는 디렉터리로 옮긴 다음 ②를 친다.
 
-```bash label="[kc-lab-1] ① Grafana Ingress 를 내린다"
+```bash label="[lab host] ① Grafana Ingress 를 내린다"
 kubectl -n observability delete ingress grafana
 ```
 
-```bash label="[kc-lab-1] ② oauth2-proxy 를 배포한다"
+```bash label="[lab host] ② oauth2-proxy 를 배포한다"
 kubectl apply -f deploy/lab/k8s/b7-oauth2-proxy.yaml
 kubectl -n keycloak-lab rollout status deploy/oauth2-proxy --timeout=180s
 ```
@@ -175,7 +188,7 @@ deployment "oauth2-proxy" successfully rolled out
 
 **무엇을 보는가** — 파드 수와 배치.
 
-```bash label="[kc-lab-1] 파드 배치를 본다"
+```bash label="[lab host] 파드 배치를 본다"
 kubectl -n keycloak-lab get pods -l app=oauth2-proxy -o wide
 ```
 
@@ -230,7 +243,7 @@ curl -H "Host: app2.hyeonworks.com" http://192.168.122.11/       →  302
 
 **이 값이 뜻하는 것** — Traefik 직접은 정상이므로 502 를 내는 것은 그 앞의 nginx 이고, 502 는 쿠키를 설정하는 응답에서만 났다. oauth2-proxy 는 기본적으로 세션 전체를 쿠키에 담는데 그 `Set-Cookie` 가 nginx 의 `proxy_buffer_size` 를 넘겼다. B-4 에서 본 헤더 크기 절벽이 이번에는 응답 쪽에서 나타났다 — 거기서는 요청 헤더가 8KB 에서 400 이 됐고, 여기서는 응답 헤더가 프록시 버퍼를 넘겨 502 가 됐다. 해결은 세션을 Redis 로 옮기는 것이고 매니페스트에 이미 들어 있다.
 
-```bash label="[kc-lab-1] 세션 저장소가 Redis 인지 인자에서 본다"
+```bash label="[lab host] 세션 저장소가 Redis 인지 인자에서 본다"
 kubectl -n keycloak-lab get deploy oauth2-proxy \
   -o jsonpath='{.spec.template.spec.containers[0].args}' | tr ',' '\n' | grep -i session
 ```
@@ -261,7 +274,7 @@ sudo: a password is required
 
 **무엇을 보는가** — 회전 대상이 준비되어 있는지. 값은 찍지 않는다.
 
-```bash label="[kc-lab-1] ① Secret 의 키 이름만 뽑는다"
+```bash label="[lab host] ① Secret 의 키 이름만 뽑는다"
 kubectl -n keycloak-lab get secret oauth2-proxy-secrets \
   -o jsonpath='{.data}' | tr ',' '\n' | grep -o '"[A-Z_]*"'
 ```
@@ -276,7 +289,7 @@ kubectl -n keycloak-lab get secret oauth2-proxy-secrets \
 
 길이도 본다. 가이드가 아래 두 줄을 미검증으로 표시했다(unknown) — 원래 실행 기록에 이 명령의 출력이 없다.
 
-```bash label="[kc-lab-1] ② 두 cookie secret 의 길이만 센다 (unknown)"
+```bash label="[lab host] ② 두 cookie secret 의 길이만 센다 (unknown)"
 kubectl -n keycloak-lab get secret oauth2-proxy-secrets \
   -o jsonpath='{.data.COOKIE_SECRET_A}' | base64 -d | wc -c
 kubectl -n keycloak-lab get secret oauth2-proxy-secrets \
@@ -308,7 +321,7 @@ kubectl -n keycloak-lab get secret oauth2-proxy-secrets \
 
 **무엇을 보는가** — 한 번은 통째로 본 다음 접두사로 좁힌다.
 
-```bash label="[kc-lab-1] ① Redis 전체를 본다"
+```bash label="[lab host] ① Redis 전체를 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize
 ```
@@ -324,7 +337,7 @@ _oauth2_proxy-b26111fbd1fdab3ae2182e287001b02a
 
 `dbsize` 는 2 인데 세션은 하나다. `b5:pvc` 는 B-5 가 남긴 키이고 이 실험과 무관하다. 이 Redis 는 이 실험 전용이 아니므로 `dbsize` 로 세션을 세면 틀린다.
 
-```bash label="[kc-lab-1] ② 세션만 세려면 접두사로 좁힌다"
+```bash label="[lab host] ② 세션만 세려면 접두사로 좁힌다"
 kubectl -n keycloak-lab exec deploy/redis -- \
   redis-cli --scan --pattern '_oauth2_proxy-*'
 ```
@@ -347,7 +360,7 @@ _oauth2_proxy=<ticket>|<timestamp>|<mac>
 
 **무엇을 보는가** — 회전을 치기 전에, 애초에 두 secret 을 동시에 들 수 있는지.
 
-```bash label="[kc-lab-1] 도움말에서 cookie-secret 을 찾는다"
+```bash label="[lab host] 도움말에서 cookie-secret 을 찾는다"
 kubectl -n keycloak-lab exec deploy/oauth2-proxy -- \
   /bin/oauth2-proxy --help 2>&1 | grep cookie-secret
 ```
@@ -373,7 +386,7 @@ kubectl -n keycloak-lab exec deploy/oauth2-proxy -- \
 
 **행동** — patch 가 지목하는 `env/1` 이 맞는지 먼저 보고, 시각을 남기고, 바꾼다.
 
-```bash label="[kc-lab-1] ① env 배열의 이름 순서를 본다"
+```bash label="[lab host] ① env 배열의 이름 순서를 본다"
 kubectl -n keycloak-lab get deploy oauth2-proxy \
   -o jsonpath='{.spec.template.spec.containers[0].env[*].name}'; echo
 ```
@@ -386,7 +399,7 @@ OAUTH2_PROXY_CLIENT_SECRET OAUTH2_PROXY_COOKIE_SECRET
 
 `OAUTH2_PROXY_COOKIE_SECRET` 이 몇 번째인지 0부터 센다. 위 모양에서는 두 번째이므로 `env/1` 이고, 순서가 다르면 patch 의 숫자를 고친다.
 
-```bash label="[kc-lab-1] ② 시각을 UTC 로 남기고 참조를 바꾼다"
+```bash label="[lab host] ② 시각을 UTC 로 남기고 참조를 바꾼다"
 date -u '+%H:%M:%S UTC 회전'
 kubectl -n keycloak-lab patch deployment oauth2-proxy --type=json \
   -p '[{"op":"replace",
@@ -411,7 +424,7 @@ deployment "oauth2-proxy" successfully rolled out
 
 ### 1. Deployment 의 참조가 실제로 바뀌었는가
 
-```bash label="[kc-lab-1] 지금 참조하는 키 이름을 뽑는다"
+```bash label="[lab host] 지금 참조하는 키 이름을 뽑는다"
 kubectl -n keycloak-lab get deploy oauth2-proxy \
   -o jsonpath='{.spec.template.spec.containers[0].env[1].valueFrom.secretKeyRef.key}'; echo
 ```
@@ -426,7 +439,7 @@ kubectl -n keycloak-lab get deploy oauth2-proxy \
 
 ### 2. Redis 는 그대로인가
 
-```bash label="[kc-lab-1] 주입 전과 똑같은 줄을 친다"
+```bash label="[lab host] 주입 전과 똑같은 줄을 친다"
 kubectl -n keycloak-lab exec deploy/redis -- \
   redis-cli --scan --pattern '_oauth2_proxy-*'
 ```
@@ -443,7 +456,7 @@ kubectl -n keycloak-lab exec deploy/redis -- \
 
 ### 3. 파드가 실제로 새로 떴는가
 
-```bash label="[kc-lab-1] 파드 이름이 바뀌었는지 본다"
+```bash label="[lab host] 파드 이름이 바뀌었는지 본다"
 kubectl -n keycloak-lab get pods -l app=oauth2-proxy -o wide
 ```
 
@@ -461,13 +474,13 @@ Keycloak SSO 세션이 살아 있어서 조용히 재인증이 일어났다. 쿠
 
 로그가 무슨 일이 났는지 말한다. 먼저 최근 로그를 통째로 본다.
 
-```bash label="[kc-lab-1] ① 최근 3분을 파드 이름과 함께 본다"
+```bash label="[lab host] ① 최근 3분을 파드 이름과 함께 본다"
 kubectl -n keycloak-lab logs -l app=oauth2-proxy --since=3m --prefix
 ```
 
 `--prefix` 는 각 줄 앞에 파드 이름을 붙여 준다. replica 가 둘이므로 이것이 없으면 누가 무엇을 했는지 못 가린다. `--since=3m` 은 최근 3분만 보므로 브라우저로 접속한 뒤 3분을 넘겨 치면 아무 줄도 안 나온다. 그때 나온 빈 결과는 「로그가 없다」가 아니라 창을 놓쳤다는 뜻이니, 브라우저를 한 번 더 열고 곧바로 친다. 그다음 좁힌다.
 
-```bash label="[kc-lab-1] ② 세션 저장소 쪽 줄만 좁힌다"
+```bash label="[lab host] ② 세션 저장소 쪽 줄만 좁힌다"
 kubectl -n keycloak-lab logs -l app=oauth2-proxy --since=3m | grep -i stored_session
 ```
 
@@ -496,7 +509,7 @@ kubectl -n keycloak-lab logs -l app=oauth2-proxy --since=3m | grep -i stored_ses
 
 그다음 Redis 를 본다.
 
-```bash label="[kc-lab-1] 세션 키를 다시 센다"
+```bash label="[lab host] 세션 키를 다시 센다"
 kubectl -n keycloak-lab exec deploy/redis -- \
   redis-cli --scan --pattern '_oauth2_proxy-*'
 ```
@@ -533,7 +546,7 @@ kubectl -n keycloak-lab exec deploy/redis -- \
 
 덤으로, 로그를 파드별로 갈라 보면 BFF 와 정반대인 성질이 보인다.
 
-```bash label="[kc-lab-1] 흐름을 시작한 파드와 콜백을 받은 파드를 가른다"
+```bash label="[lab host] 흐름을 시작한 파드와 콜백을 받은 파드를 가른다"
 kubectl -n keycloak-lab logs -l app=oauth2-proxy --since=10m --prefix \
   | grep -E 'Initiating login|AuthSuccess'
 ```
@@ -569,7 +582,7 @@ GET "/oauth2/callback?state=..."                  ← 콜백을 받은 replica
 
 **행동** — 시각을 남기고 되돌린다.
 
-```bash label="[kc-lab-1] 되돌리는 것도 회전이다"
+```bash label="[lab host] 되돌리는 것도 회전이다"
 date -u '+%H:%M:%S UTC 되돌림'
 kubectl -n keycloak-lab patch deployment oauth2-proxy --type=json \
   -p '[{"op":"replace",
@@ -596,7 +609,7 @@ kubectl -n keycloak-lab rollout status deploy/oauth2-proxy --timeout=180s
 
 전부 지울 때는 `b5:pvc` 같은 남의 키를 같이 죽이지 않도록 패턴으로 좁힌다. `FLUSHDB` 를 쓰지 않는다 — 이 Redis 는 BFF 세션도 담고 있다.
 
-```bash label="[kc-lab-1] 접두사에 걸린 것만 지운다"
+```bash label="[lab host] 접두사에 걸린 것만 지운다"
 kubectl -n keycloak-lab exec deploy/redis -- \
   redis-cli --scan --pattern '_oauth2_proxy-*' | while read K; do
     kubectl -n keycloak-lab exec deploy/redis -- redis-cli del "$K"
@@ -611,12 +624,12 @@ kubectl -n keycloak-lab exec deploy/redis -- \
 
 **지우기 전에 백업 파일이 손에 있는지 본다.** 지금은 Grafana Ingress 가 이미 없으니 파일이 비어 있으면 다시 뜰 원본도 없고, 되살리는 절차는 가이드에 없다(unknown). 아래 두 줄의 첫째가 줄 수를 내고 둘째가 `0` 이 아니면 그 파일로 돌려줄 수 있다. `No such file or directory` 가 나오면 ①을 치지 않는다 — B-4 로 app2 를 빌린 적이 있으면 그 편은 같은 백업을 `/tmp/grafana-ingress-backup.yaml` 에 떠 두므로 그쪽을 본다.
 
-```bash label="[kc-lab-1] ⓪ 백업 파일이 쓸 만한지 본다"
+```bash label="[lab host] ⓪ 백업 파일이 쓸 만한지 본다"
 wc -l ~/grafana-ingress-backup.yaml
 grep -c 'app2.hyeonworks.com' ~/grafana-ingress-backup.yaml
 ```
 
-```bash label="[kc-lab-1] ① 빌린 것을 걷고 백업을 올린다"
+```bash label="[lab host] ① 빌린 것을 걷고 백업을 올린다"
 kubectl -n keycloak-lab delete ingress oauth2-proxy
 kubectl apply -f ~/grafana-ingress-backup.yaml
 ```
@@ -663,6 +676,14 @@ curl -sI https://app2.hyeonworks.com/ | head -3
 | `app2` 가 Grafana 로 간다 | Ingress 를 안 만들었거나 이미 복구했다 | `kubectl -n keycloak-lab get ingress` |
 | 실험이 끝났는데 Grafana 가 안 열린다 | Ingress 복구를 안 했다 | oauth2-proxy Ingress 를 먼저 지우고 백업을 올린다 |
 
+## 이 실험대에서 아직 못 밟은 단계
+
+2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈췄는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
+
+- **남은 것** — 쿠키 비밀 회전 전부. `oauth2-proxy` 가 기동 시 OIDC 디스커버리를 `https` 로 하므로 인증서가 서야 뜬다.
+- **막는 것** — `https://auth.hyeonworks.com` 이 서지 않는다. 와일드카드 인증서(Cloudflare API 토큰이 필요한 DNS-01)와, 밖에서 실험대에 닿는 길(호스트의 libvirt `guest_input` 구멍 — A-4 에서 확인한 `ExecStartPost` 누락)이 둘 다 있어야 한다.
+- **그때까지 이 편의 실측 가운데 `(observed)` 로 적힌 2026-09-17 값은 위 「지금까지 밟은 것」 범위뿐이다.** 나머지는 원래 실행의 값이다.
+
 ## 무엇이 관측이고 무엇이 아닌가
 
 이 절차의 숫자는 `2026-09-04 14:35–14:42 KST` 에 돈 한 번의 실행에서 나왔다(observed). 증거의 로그가 `[2026/09/04 05:41:46]` 인 것과 수집 시각이 `14:35–14:42 KST` 인 것은 같은 순간이다(KST = UTC+9). 이 어긋남을 모르고 로그를 뒤지면 9시간 전을 뒤지게 된다.
diff --git a/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b7a-orphan-session.md b/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b7a-orphan-session.md
index 428bbf1..3fdc982 100644
--- a/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b7a-orphan-session.md
+++ b/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-b7a-orphan-session.md
@@ -37,7 +37,9 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 전부 `[kc-lab-1]` 에서 `kubectl` 로 친다. Redis 에 묻는 것도 `kubectl exec deploy/redis` 를 거치므로 노드에 들어갈 일이 없다.
+명령은 전부 `[lab host]` 에서 `kubectl` 로 친다. Redis 에 묻는 것도 `kubectl exec deploy/redis` 를 거치므로 노드에 들어갈 일이 없다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 브라우저도 필요하다. 고아는 사람이 옛 쿠키를 들고 와야 생긴다. 셸만으로는 아무리 회전시켜도 키가 늘지 않는다.
 
@@ -85,11 +87,22 @@ B-7 은 여기서 멈췄다.
 - 브라우저가 있어야 한다.
 - 기동 로그의 `refresh:disabled` 를 1 절에서 확인한다. **그것이 `disabled` 가 아니면 이 절차의 정리 규칙은 그 환경에서 성립하지 않는다.**
 
+**`oauth2-proxy` 는 인증서가 서기 전에는 못 뜬다.** 기동할 때 OIDC 디스커버리를 먼저 하는데 그 주소가 `https://auth.hyeonworks.com/...` 이라, 인증서 단계를 안 끝낸 실험대에서는 `CrashLoopBackOff` 로 끝난다. 2026-09-17 에 그대로 겪었다(observed).
+
+```text
+[provider.go:55] Performing OIDC Discovery...
+[main.go:59] ERROR: Failed to initialise OAuth2 Proxy: ... error while discovery OIDC configuration:
+  Get "https://auth.hyeonworks.com/realms/keycloak-patterns/.well-known/openid-configuration":
+  dial tcp 100.83.212.4:443: connect: connection refused
+```
+
+`oauth2-proxy-secrets` 가 있고 이미지도 받아지는데 기동 자체가 안 된다 — **이 편의 전제는 배포가 아니라 TLS 다.**
+
 **이건 남의 세션을 실제로 지우는 실험이다.** `redis-cli del` 로 세션 키를 지우고, 산 사람의 세션을 잘못 지우면 그 사람은 재로그인해야 한다. SSO 가 살아 있으면 조용히 지나간다. 그 이상의 피해는 측정되지 않았지만 실험대에서만 한다.
 
 되돌리기는 secret 참조를 A 로 되돌리는 한 줄이다. B-7 에서 Grafana 의 Ingress 를 빌렸다면 이 절차가 끝난 뒤에 돌려준다.
 
-```bash label="[kc-lab-1] 중간에 그만둘 때 치는 한 줄"
+```bash label="[lab host] 중간에 그만둘 때 치는 한 줄"
 kubectl -n keycloak-lab patch deployment oauth2-proxy --type=json \
   -p '[{"op":"replace",
         "path":"/spec/template/spec/containers/0/env/1/valueFrom/secretKeyRef/key",
@@ -106,7 +119,7 @@ kubectl -n keycloak-lab patch deployment oauth2-proxy --type=json \
 
 **무엇을 보는가** — 기동 로그의 쿠키 설정 한 줄. 이 한 단어가 정리 규칙 전체의 전제다.
 
-```bash label="[kc-lab-1] ① 기동 로그에서 쿠키 설정을 찾는다"
+```bash label="[lab host] ① 기동 로그에서 쿠키 설정을 찾는다"
 kubectl -n keycloak-lab logs -l app=oauth2-proxy | grep 'Cookie settings'
 ```
 
@@ -123,7 +136,7 @@ kubectl -n keycloak-lab logs -l app=oauth2-proxy | grep 'Cookie settings'
 
 기동 로그가 잘려 나갔으면 인자에서 직접 본다.
 
-```bash label="[kc-lab-1] ② 인자에서 쿠키 관련 값만 뽑는다"
+```bash label="[lab host] ② 인자에서 쿠키 관련 값만 뽑는다"
 kubectl -n keycloak-lab get deploy oauth2-proxy \
   -o jsonpath='{.spec.template.spec.containers[0].args}' | tr ',' '\n' | grep -i cookie
 ```
@@ -143,12 +156,22 @@ kubectl -n keycloak-lab get deploy oauth2-proxy \
 
 브라우저에서 `https://app2.hyeonworks.com/api/echo` 를 열고 `labuser` / `labpass` 로 로그인한다. 업스트림의 JSON 이 보이면 세션이 생겼다.
 
-```bash label="[kc-lab-1] ① 세션 키와 전체 키 수를 본다"
+```bash label="[lab host] ① 세션 키와 전체 키 수를 본다"
 kubectl -n keycloak-lab exec deploy/redis -- \
   redis-cli --scan --pattern '_oauth2_proxy-*'
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize
 ```
 
+**두 명령 자체는 2026-09-17 에 쳐서 돌았다**(observed). 세션이 없는 상태에서는 이렇게 나온다.
+
+```text
+(--scan --pattern '_oauth2_proxy-*' 는 아무것도 안 낸다)
+0
+```
+
+`dbsize` 가 `0` 이고 스캔이 비었다는 것은 **Redis 는 멀쩡한데 엣지 세션이 하나도 없다**는 뜻이다. `oauth2-proxy` 가 안 떠 있으면 늘 이 모양이므로, 이 값을 보고 「Redis 가 안 붙었다」로 읽지 않는다.
+
+
 **어디를 보나** — 실측은 이렇다(observed, `01-orphan-lifecycle.txt`).
 
 ```text
@@ -161,7 +184,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize
 
 그 키 하나에 대해 셋을 따로 묻는다. 나중에 루프로 묶더라도 처음에는 `type` · `ttl` · `strlen` 이 각각 무엇을 답하는지 봐 둔다. 키 이름은 위 출력에서 가져온다.
 
-```bash label="[kc-lab-1] ② 한 키에 세 가지를 따로 묻는다"
+```bash label="[lab host] ② 한 키에 세 가지를 따로 묻는다"
 kubectl -n keycloak-lab exec deploy/redis -- \
   redis-cli type _oauth2_proxy-f6a9201fd534a047998278452001ccbf
 kubectl -n keycloak-lab exec deploy/redis -- \
@@ -184,7 +207,7 @@ kubectl -n keycloak-lab exec deploy/redis -- \
 
 **이 절은 건너뛸 수 없다.** 7 절부터 끝까지 모든 Redis 조회가 이 `R` 을 부른다. 그리고 셸 함수는 그 셸에만 있다 — 터미널이 끊기거나 다른 창에서 이어 치면 `R: command not found` 가 나오고, 그때는 이 블록의 첫 줄부터 다시 친다.
 
-```bash label="[kc-lab-1] 이름 그대로 하는 한 줄짜리 함수 (unknown)"
+```bash label="[lab host] 이름 그대로 하는 한 줄짜리 함수 (unknown)"
 R() { kubectl -n keycloak-lab exec deploy/redis -- redis-cli "$@"; }
 R --scan --pattern '_oauth2_proxy-*' | while read K; do
   echo "$K type=$(R type $K) ttl=$(R ttl $K) len=$(R strlen $K)"
@@ -203,7 +226,7 @@ _oauth2_proxy-f6a9201fd534a047998278452001ccbf type=string ttl=3568 len=3510
 
 **무엇을 보는가** — 셸의 시각과 UTC, 그리고 NTP 동기화 여부.
 
-```bash label="[kc-lab-1] 로컬과 UTC 를 나란히 보고 동기화를 확인한다"
+```bash label="[lab host] 로컬과 UTC 를 나란히 보고 동기화를 확인한다"
 date; date -u
 timedatectl show -p NTP -p NTPSynchronized
 ```
@@ -225,11 +248,11 @@ NTPSynchronized=yes
 
 **행동** — 시각을 먼저 담고 참조를 바꾼다.
 
-```bash label="[kc-lab-1] ① 회전 시각을 UTC 로 담는다"
+```bash label="[lab host] ① 회전 시각을 UTC 로 담는다"
 ROT=$(date -u +%s); echo "회전 $ROT ($(date -u -d @$ROT +%H:%M:%S) UTC)"
 ```
 
-```bash label="[kc-lab-1] ② secret 참조를 B 로 바꾼다"
+```bash label="[lab host] ② secret 참조를 B 로 바꾼다"
 kubectl -n keycloak-lab patch deployment oauth2-proxy --type=json \
   -p '[{"op":"replace",
         "path":"/spec/template/spec/containers/0/env/1/valueFrom/secretKeyRef/key",
@@ -251,7 +274,7 @@ kubectl -n keycloak-lab rollout status deploy/oauth2-proxy --timeout=180s
 
 ### 6. Deployment 의 참조가 바뀌었는가
 
-```bash label="[kc-lab-1] 지금 참조하는 키 이름을 뽑는다"
+```bash label="[lab host] 지금 참조하는 키 이름을 뽑는다"
 kubectl -n keycloak-lab get deploy oauth2-proxy \
   -o jsonpath='{.spec.template.spec.containers[0].env[1].valueFrom.secretKeyRef.key}'; echo
 ```
@@ -266,7 +289,7 @@ COOKIE_SECRET_B
 
 주입 전과 똑같은 명령으로 본다.
 
-```bash label="[kc-lab-1] 키와 TTL 을 다시 본다"
+```bash label="[lab host] 키와 TTL 을 다시 본다"
 R --scan --pattern '_oauth2_proxy-*' | while read K; do
   echo "$K ttl=$(R ttl $K)"
 done
@@ -288,7 +311,7 @@ R dbsize
 
 로그인했던 그 브라우저 그대로 `https://app2.hyeonworks.com/api/echo` 를 연다.
 
-```bash label="[kc-lab-1] 최근 2분의 세션 저장소 로그를 좁힌다"
+```bash label="[lab host] 최근 2분의 세션 저장소 로그를 좁힌다"
 kubectl -n keycloak-lab logs -l app=oauth2-proxy --since=2m | grep stored_session
 ```
 
@@ -306,7 +329,7 @@ kubectl -n keycloak-lab logs -l app=oauth2-proxy --since=2m | grep stored_sessio
 
 **이 값이 뜻하는 것** — `AuthSuccess` 의 시각 `11:30:27` 을 적어 둔다. 13 절에서 이 숫자와 역산값을 맞춰 본다. 그리고 Redis 를 다시 본다.
 
-```bash label="[kc-lab-1] 키가 늘었는지 본다"
+```bash label="[lab host] 키가 늘었는지 본다"
 R --scan --pattern '_oauth2_proxy-*' | while read K; do
   echo "$K ttl=$(R ttl $K)"
 done
@@ -330,7 +353,7 @@ R dbsize
 
 **무엇을 보는가** — 두 키의 네 가지 성질.
 
-```bash label="[kc-lab-1] 두 키를 나란히 놓는다"
+```bash label="[lab host] 두 키를 나란히 놓는다"
 R --scan --pattern '_oauth2_proxy-*' | while read K; do
   echo "$K type=$(R type $K) len=$(R strlen $K) ttl=$(R ttl $K)"
 done
@@ -357,7 +380,7 @@ done
 
 아래 키 이름은 이 실험대에서 나온 값이라 그대로 치면 남의 키를 조회해 `(nil)` 이 돌아온다. 2 절의 `--scan` 출력에서 자기 키 이름을 옮겨 넣는다.
 
-```bash label="[kc-lab-1] 값의 앞머리만 이스케이프해서 본다 — 키 이름은 자기 것으로"
+```bash label="[lab host] 값의 앞머리만 이스케이프해서 본다 — 키 이름은 자기 것으로"
 R --no-raw get _oauth2_proxy-f6a9201fd534a047998278452001ccbf | head -c 120; echo
 ```
 
@@ -375,7 +398,7 @@ R --no-raw get _oauth2_proxy-f6a9201fd534a047998278452001ccbf | head -c 120; ech
 
 **무엇을 보는가** — 둘이다. TTL 이 실제로 줄어드는가, 요청을 보내면 되살아나는가. 30초 간격으로 세 번이고 여기에 1분이 그대로 든다.
 
-```bash label="[kc-lab-1] 30초 간격으로 세 번 재는 루프 (unknown)"
+```bash label="[lab host] 30초 간격으로 세 번 재는 루프 (unknown)"
 for i in 1 2 3; do
   date -u '+%H:%M:%S'
   R --scan --pattern '_oauth2_proxy-*' | while read K; do
@@ -421,7 +444,7 @@ done
 
 **행동** — 되돌리기가 없는 조작이니 지우기 전에 어느 키인지 두 번 확인한다. 지금은 TTL 이 작은 쪽이 고아다.
 
-```bash label="[kc-lab-1] ① 고아 하나를 지우고 남은 것을 센다"
+```bash label="[lab host] ① 고아 하나를 지우고 남은 것을 센다"
 R del _oauth2_proxy-f6a9201fd534a047998278452001ccbf
 R dbsize
 R --scan --pattern '_oauth2_proxy-*'
@@ -438,7 +461,7 @@ R --scan --pattern '_oauth2_proxy-*'
 
 반환값이 `1` 이다. `0` 이면 그 키가 없었던 것이고 이름을 잘못 옮겼다. 산 세션이 멀쩡한지는 브라우저로 다시 열어서 본다.
 
-```bash label="[kc-lab-1] ② 삭제 직후 요청이 200 인지 로그로 본다"
+```bash label="[lab host] ② 삭제 직후 요청이 200 인지 로그로 본다"
 kubectl -n keycloak-lab logs -l app=oauth2-proxy --since=1m | grep labuser
 ```
 
@@ -461,7 +484,7 @@ kubectl -n keycloak-lab logs -l app=oauth2-proxy --since=1m | grep labuser
 
 **행동** — 2차 회전 시각을 담고 B → A 로 되돌린다.
 
-```bash label="[kc-lab-1] 2차 회전 시각을 담고 참조를 A 로 바꾼다"
+```bash label="[lab host] 2차 회전 시각을 담고 참조를 A 로 바꾼다"
 ROT2=$(date -u +%s); echo "2차 회전 $ROT2 ($(date -u -d @$ROT2 +%H:%M:%S) UTC)"
 kubectl -n keycloak-lab patch deployment oauth2-proxy --type=json \
   -p '[{"op":"replace",
@@ -472,7 +495,7 @@ kubectl -n keycloak-lab rollout status deploy/oauth2-proxy --timeout=180s
 
 그리고 브라우저로 다시 연 뒤 본다.
 
-```bash label="[kc-lab-1] 키와 TTL 을 다시 본다"
+```bash label="[lab host] 키와 TTL 을 다시 본다"
 R --scan --pattern '_oauth2_proxy-*' | while read K; do
   echo "$K ttl=$(R ttl $K)"
 done
@@ -523,7 +546,7 @@ done
 
 **기준 시각을 먼저 정한다.** 이 루프가 재는 것은 「지금 걷어내려는 회전보다 앞에 만들어졌나」다. 5 절에서 담은 `ROT` 은 1차 회전 시각이고, 12 절을 쳤으면 지금 유효한 회전은 2차이므로 기준은 `ROT2` 다. **12 절을 친 뒤라면 아래 두 블록의 `"$ROT"` 를 `"$ROT2"` 로 바꿔 친다.** 안 바꾸면 두 회전 사이에 생긴 세션이 「산것」으로 분류되어 그대로 남고, 15 절의 실측(`87faa1c9…` 삭제 · 남은 `dbsize=1`)이 재현되지 않는다 — 그 키의 역산 생성시각 `11:30:26` 은 `ROT`(`11:29:56`)보다 뒤이기 때문이다.
 
-```bash label="[kc-lab-1] 지우지 않고 판정만 하는 루프 — 12 절을 쳤으면 $ROT 을 $ROT2 로 (unknown)"
+```bash label="[lab host] 지우지 않고 판정만 하는 루프 — 12 절을 쳤으면 $ROT 을 $ROT2 로 (unknown)"
 NOW=$(date -u +%s); EXP=3600
 R --scan --pattern '_oauth2_proxy-*' | while read K; do
   T=$(R ttl "$K"); C=$(( NOW - (EXP - T) ))
@@ -549,7 +572,7 @@ done
 
 **리허설이 보장하는 범위.** 두 블록은 `NOW` 를 각각 새로 잡고 `C = NOW − (EXP − T)` 로 역산한다. `NOW` 와 `T` 가 같이 흐르므로 `C` 는 대체로 같은 값이 나오지만, 11 절이 적었듯 TTL 이 초 단위 정수라 ±1초가 반올림으로 흔들린다. **생성시각이 기준 회전 시각의 ±1초 안에 놓인 키는 리허설에서 「산것」이었다가 실행에서 「고아」로 뒤집힐 수 있고, 그쪽 방향의 오판이 곧 산 세션 삭제다.** 리허설 출력의 생성시각이 기준 시각에 붙어 있는 키가 보이면 그 키는 이 루프로 지우지 않는다.
 
-```bash label="[kc-lab-1] 고아로 판정된 것만 지운다 — 14 절과 같은 기준으로 (unknown)"
+```bash label="[lab host] 고아로 판정된 것만 지운다 — 14 절과 같은 기준으로 (unknown)"
 NOW=$(date -u +%s); EXP=3600
 R --scan --pattern '_oauth2_proxy-*' | while read K; do
   T=$(R ttl "$K"); C=$(( NOW - (EXP - T) ))
@@ -571,7 +594,7 @@ R dbsize
 
 **문제가 생기면** — 전제가 깨졌을 때, 즉 `--cookie-refresh` 가 켜져 있을 때는 위 규칙을 쓰지 않는다. 전부 지우고 모두 재인증시킨다. `FLUSHDB` 를 쓰지 않는다 — 이 Redis 에는 BFF 세션도 들어 있어 패턴으로 좁히는 것이 이 실험대에서는 필수다.
 
-```bash label="[kc-lab-1] 전제가 깨졌을 때 — 접두사에 걸린 것만 전부 지운다"
+```bash label="[lab host] 전제가 깨졌을 때 — 접두사에 걸린 것만 전부 지운다"
 R --scan --pattern '_oauth2_proxy-*' | while read K; do R del "$K"; done
 ```
 
@@ -581,7 +604,7 @@ R --scan --pattern '_oauth2_proxy-*' | while read K; do R del "$K"; done
 
 **행동** — 참조를 확인하고, Grafana Ingress 를 돌려준다.
 
-```bash label="[kc-lab-1] ① 지금 참조가 A 인지 본다"
+```bash label="[lab host] ① 지금 참조가 A 인지 본다"
 kubectl -n keycloak-lab get deploy oauth2-proxy \
   -o jsonpath='{.spec.template.spec.containers[0].env[1].valueFrom.secretKeyRef.key}'; echo
 ```
@@ -590,14 +613,14 @@ kubectl -n keycloak-lab get deploy oauth2-proxy \
 
 **돌려주기 전에 백업 파일이 손에 있는지 본다.** 이 파일은 이 편이 만들지 않는다 — B-7 이 Grafana Ingress 를 걷어내기 **전에** 떠 둔다. 지금은 그 Ingress 가 이미 없으니 파일이 없으면 다시 뜰 수도 없고, 되살리는 경로는 가이드에 없다(unknown). 그러니 없으면 아래 `delete` 를 치지 않는다.
 
-```bash label="[kc-lab-1] ② 백업 파일이 쓸 만한지 본다"
+```bash label="[lab host] ② 백업 파일이 쓸 만한지 본다"
 wc -l ~/grafana-ingress-backup.yaml
 grep -c 'app2.hyeonworks.com' ~/grafana-ingress-backup.yaml
 ```
 
 줄 수가 나오고 둘째 줄이 `0` 이 아니면 그 파일로 돌려줄 수 있다. `No such file or directory` 면 여기서 멈춘다. B-4 로 app2 를 빌린 적이 있다면 그 편은 같은 백업을 `/tmp/grafana-ingress-backup.yaml` 에 떠 두므로 그쪽도 본다.
 
-```bash label="[kc-lab-1] ③ 빌린 Ingress 를 걷고 백업을 올린 뒤 밖에서 본다"
+```bash label="[lab host] ③ 빌린 Ingress 를 걷고 백업을 올린 뒤 밖에서 본다"
 kubectl -n keycloak-lab delete ingress oauth2-proxy
 kubectl apply -f ~/grafana-ingress-backup.yaml
 curl -sI https://app2.hyeonworks.com/ | head -3
@@ -640,6 +663,14 @@ curl -sI https://app2.hyeonworks.com/ | head -3
 | 루프가 너무 느리다 | 키마다 `kubectl exec` 를 한다 | `--scan` 결과를 먼저 받아 두고 필요한 것만 묻는다 |
 | 로그 시각이 9시간 어긋난다 | 프록시 로그는 UTC | 표시 규약 |
 
+## 이 실험대에서 아직 못 밟은 단계
+
+2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈췄는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
+
+- **남은 것** — 고아 세션 관찰 전부. 같은 이유로 `oauth2-proxy` 가 안 뜬다. 지금까지 밟은 것 — Redis 쪽 명령(`dbsize`·`--scan`)이 도는 것까지.
+- **막는 것** — `https://auth.hyeonworks.com` 이 서지 않는다. 와일드카드 인증서(Cloudflare API 토큰이 필요한 DNS-01)와, 밖에서 실험대에 닿는 길(호스트의 libvirt `guest_input` 구멍 — A-4 에서 확인한 `ExecStartPost` 누락)이 둘 다 있어야 한다.
+- **그때까지 이 편의 실측 가운데 `(observed)` 로 적힌 2026-09-17 값은 위 「지금까지 밟은 것」 범위뿐이다.** 나머지는 원래 실행의 값이다.
+
 ## 무엇이 관측이고 무엇이 아닌가
 
 이 절차의 숫자는 `2026-09-04 11:29–11:34 UTC` 에 돈 한 번의 실행에서 나왔다(observed). 시각은 전부 UTC 로 다룬다 — 이 실험의 결론이 시각 계산이라 KST 와 섞이면 9시간이 틀어진다.
diff --git a/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-c1-multi-app-sso.md b/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-c1-multi-app-sso.md
index 0dbbeb1..01e2eb4 100644
--- a/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-c1-multi-app-sso.md
+++ b/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-c1-multi-app-sso.md
@@ -44,7 +44,9 @@ app1 과 app2 를 한 번의 로그인으로 묶은 뒤 IdP 세션만 끊고, 
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 `kc-lab-1` 에서 `kubectl` 로 친다. `kubectl` 에 `sudo` 를 붙이지 않는다. 반입한 가이드의 전제 문장은 `sudo kubectl` 로 적혀 있지만 같은 폴더의 README 가 반대로 적고, 본문 명령 블록에도 `sudo kubectl` 은 한 번도 없다. `sudo` 를 붙이면 root 환경으로 돌아 사용자 홈의 kubeconfig 를 못 본다.
+명령은 `[lab host]` 에서 `kubectl` 로 친다. `kubectl` 에 `sudo` 를 붙이지 않는다. 반입한 가이드의 전제 문장은 `sudo kubectl` 로 적혀 있지만 같은 폴더의 README 가 반대로 적고, 본문 명령 블록에도 `sudo kubectl` 은 한 번도 없다. `sudo` 를 붙이면 root 환경으로 돌아 사용자 홈의 kubeconfig 를 못 본다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 `[밖에서]` 라벨이 붙은 `curl` 은 클러스터 밖에서 공개 이름을 두드린다는 뜻이다. 어느 기계에서 치라는 줄은 가이드에 없으므로(unknown), `https://app1.hyeonworks.com` 이 풀리는 기계면 어디서든 친다. 거기로 가는 `ssh` 명령도 가이드에 없다.
 
@@ -116,7 +118,7 @@ app1 과 app2 를 한 번의 로그인으로 묶은 뒤 IdP 세션만 끊고, 
 
 되돌리기는 둘이고 둘 다 먼저 읽어 둔다. 하나는 세션을 다시 깨끗하게 만드는 것이라 주입 전 절차와 같은 명령이다.
 
-```bash label="[kc-lab-1] ① 세션을 비우고 캐시를 버린다"
+```bash label="[lab host] ① 세션을 비우고 캐시를 버린다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "delete from offline_client_session" -c "delete from offline_user_session"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli flushall
@@ -126,7 +128,7 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s
 
 다른 하나는 빌린 이름을 돌려준다. ②는 먼저 지우고 나중에 올리므로, 백업 파일이 비어 있으면 Grafana 가 안 열리는 채로 끝난다. 실제로 칠 때는 복구 3 절의 확인 두 줄을 먼저 친다.
 
-```bash label="[kc-lab-1] ② 빌린 Ingress 를 걷고 Grafana 것을 올린다"
+```bash label="[lab host] ② 빌린 Ingress 를 걷고 Grafana 것을 올린다"
 kubectl -n keycloak-lab delete ingress oauth2-proxy
 kubectl apply -f ~/grafana-ingress-backup.yaml
 ```
@@ -153,7 +155,7 @@ C-2 를 이어서 할 생각이면 아직 돌려주지 않는다. C-2 가 두 
 
 **행동** — 클러스터 안을 먼저 보고, 밖에서 두 이름을 두드린다.
 
-```bash label="[kc-lab-1] ① 파드와 Ingress 를 통째로 본다"
+```bash label="[lab host] ① 파드와 Ingress 를 통째로 본다"
 kubectl -n keycloak-lab get pods -o wide
 kubectl -n keycloak-lab get ingress
 ```
@@ -179,7 +181,7 @@ curl -s -o /dev/null -w 'app2 %{http_code}\n' https://app2.hyeonworks.com/
 
 **행동** — 관리자 비밀번호를 Secret 에서 읽어 명령 치환으로 넘긴다.
 
-```bash label="[kc-lab-1] 비밀번호를 화면에 찍지 않고 로그인한다"
+```bash label="[lab host] 비밀번호를 화면에 찍지 않고 로그인한다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   config credentials --server http://localhost:8080 --realm master --user admin \
   --password "$(kubectl -n keycloak-lab get secret keycloak-lab-secrets \
@@ -198,14 +200,14 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 **행동** — 관리 API 를 치고 남은 세션을 센다.
 
-```bash label="[kc-lab-1] ① realm 전체 로그아웃을 건다"
+```bash label="[lab host] ① realm 전체 로그아웃을 건다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   create realms/keycloak-patterns/logout-all
 ```
 
-이 실험대는 세는 쪽을 스크립트로 돌렸고 증거에 SQL 원문이 없다. 따라 하는 사람은 가이드가 손으로 치기 좋게 고친 아래 형태를 친다. 가이드가 미검증으로 표시한 줄이다(unknown).
+이 실험대는 세는 쪽을 스크립트로 돌렸고 증거에 SQL 원문이 없다. 따라 하는 사람은 가이드가 손으로 치기 좋게 고친 아래 형태를 친다. **2026-09-17 에 쳐서 돌았다**(observed) — 그때까지 미검증이던 줄이다.
 
-```bash label="[kc-lab-1] ② 남은 세션을 센다"
+```bash label="[lab host] ② 남은 세션을 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select count(*) from offline_user_session where offline_flag='0'"
 ```
@@ -231,32 +233,46 @@ DELETE 1
 
 **목적** — `keycloak-patterns` 세션 수와 Redis 키를 둘 다 0 으로 만든다.
 
+**2026-09-17 실측**(observed) — `logout-all` 을 친 **뒤에도** 세션이 그대로 `6` 건이었다. 이 방법으로는 안 지워진다는 것이 이 절의 결론이고, 그래서 아래 4절로 간다.
+
 **행동** — 자식 테이블부터 지우고, 앱 세션을 비우고, 프로세스를 새로 띄운다.
 
-```bash label="[kc-lab-1] ① 자식 테이블부터 지운다"
+```bash label="[lab host] ① 자식 테이블부터 지운다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "delete from offline_client_session" -c "delete from offline_user_session"
 ```
 
-모양은 이렇다(observed).
+2026-09-17 실측이다(observed). **자식 쪽이 훨씬 많다** — 부모부터 지우려 했다면 외래키에 걸렸을 것이다.
+
+```text
+DELETE 1633
+DELETE 6
+```
+
+원래 실행의 모양은 이렇다(observed).
 
 ```text
 DELETE 2
 DELETE 4
 ```
 
-```bash label="[kc-lab-1] ② 앱 세션도 비운다"
+```bash label="[lab host] ② 앱 세션도 비운다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli flushall
 ```
 
-```bash label="[kc-lab-1] ③ 캐시를 버리려면 프로세스를 새로 띄운다"
+```bash label="[lab host] ③ 캐시를 버리려면 프로세스를 새로 띄운다"
 kubectl -n keycloak-lab rollout restart statefulset/keycloak
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s
 ```
 
-③ 이 끝나면 `keycloak-0` 파드가 새로 뜨고 그 안에 있던 kcadm 세션 파일이 함께 사라진다. 그러니 롤아웃이 끝나는 대로 주입 전 2 절의 `config credentials` 를 다시 친다. 건너뛰면 뒤에 나오는 `kcadm` 이 전부 `401` 을 내는데, 그 사실은 관찰 1 절에 가서야 보인다.
+③ 이 끝나면 `keycloak-0` 파드가 새로 뜨고 그 안에 있던 kcadm 세션 파일이 함께 사라진다. 2026-09-17 에 그대로 겪었다(observed) — 롤아웃 직후 `kcadm` 이 이렇게 끝난다.
 
-```bash label="[kc-lab-1] ④ 두 저장소를 다시 센다"
+```text
+No server specified. Use --server, or 'kcadm.sh config credentials'.
+```
+ 그러니 롤아웃이 끝나는 대로 주입 전 2 절의 `config credentials` 를 다시 친다. 건너뛰면 뒤에 나오는 `kcadm` 이 전부 `401` 을 내는데, 그 사실은 관찰 1 절에 가서야 보인다.
+
+```bash label="[lab host] ④ 두 저장소를 다시 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select count(*) from offline_user_session where offline_flag='0'"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
@@ -286,14 +302,14 @@ Redis 키 0, 세션 수 0 이어야 한다.
 
 **행동** — 두 형태를 나란히 친다. 이 실험대가 쓴 쪽이 틀린 방법이다.
 
-```bash label="[kc-lab-1] ① 전체를 세는 쪽 — 틀린 방법이다"
+```bash label="[lab host] ① 전체를 세는 쪽 — 틀린 방법이다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select count(*) from offline_user_session where offline_flag='0'"
 ```
 
 따라 하는 사람은 `realm` 을 조인한다. 가이드가 미검증으로 표시한 형태다(unknown).
 
-```bash label="[kc-lab-1] ② realm 을 조인하는 쪽"
+```bash label="[lab host] ② realm 을 조인하는 쪽"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select us.user_session_id, r.name as realm,
           (select count(*) from offline_client_session cs
@@ -336,7 +352,7 @@ https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/aut
 
 **행동** — 주입 전 5 절에서 고친 조인 쿼리에 realm 조건을 붙여 친다. 같은 이유로 미검증이다(unknown).
 
-```bash label="[kc-lab-1] ① keycloak-patterns 세션만 본다"
+```bash label="[lab host] ① keycloak-patterns 세션만 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select us.user_session_id, r.name as realm,
           (select count(*) from offline_client_session cs
@@ -355,7 +371,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c
 (1 row)
 ```
 
-```bash label="[kc-lab-1] ② 앱 세션 쪽을 본다"
+```bash label="[lab host] ② 앱 세션 쪽을 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
 ```
 
@@ -369,7 +385,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
 
 `authorized client` 를 세는 줄도 미검증이다(unknown).
 
-```bash label="[kc-lab-1] ③ 토큰이 들어간 행을 센다"
+```bash label="[lab host] ③ 토큰이 들어간 행을 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select count(*) from oauth2_authorized_client"
 ```
@@ -398,7 +414,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tA
 
 ### 1. 같은 user session 인가
 
-```bash label="[kc-lab-1] 주입 전과 똑같은 줄을 친다 — user session 과 client session 수"
+```bash label="[lab host] 주입 전과 똑같은 줄을 친다 — user session 과 client session 수"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select us.user_session_id, r.name as realm,
           (select count(*) from offline_client_session cs
@@ -431,7 +447,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c
 
 아래 쿼리의 `oqOjHekin4JU-BZjgQLjUByW` 는 원래 실행의 세션 id 다. 치기 전에 주입 2 절에서 적어 둔 자기 값으로 갈아 끼운다. 그대로 치면 조건에 걸리는 행이 없어 `(0 rows)` 가 나오고, 그것을 「두 앱이 안 붙었다」로 읽으면 판정이 뒤집힌다.
 
-```bash label="[kc-lab-1] 클라이언트 이름을 조인해서 본다"
+```bash label="[lab host] 클라이언트 이름을 조인해서 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select cs.client_id, c.client_id as name
      from offline_client_session cs join client c on c.id = cs.client_id
@@ -455,7 +471,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c
 
 ### 3. 저장소에는 무엇이 늘었는가
 
-```bash label="[kc-lab-1] 주입 전과 똑같은 줄을 친다 — Redis 키 목록"
+```bash label="[lab host] 주입 전과 똑같은 줄을 친다 — Redis 키 목록"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
 ```
 
@@ -490,7 +506,7 @@ Keycloak 은 세션을 `user session`(사람 하나)과 `client session`(그 사
 
 지우는 방법을 고르는 데서 하나가 걸러진다. 가이드가 미검증으로 표시했다(unknown).
 
-```bash label="[kc-lab-1] 세션 id 로 지운다 — 안 먹는다"
+```bash label="[lab host] 세션 id 로 지운다 — 안 먹는다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   delete sessions/oqOjHekin4JU-BZjgQLjUByW -r keycloak-patterns
 ```
@@ -505,7 +521,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 **행동** — 사용자 id 를 먼저 잡아 눈으로 확인하고, 그다음에 로그아웃을 건다.
 
-```bash label="[kc-lab-1] 두 단계로 나눠 친다"
+```bash label="[lab host] 두 단계로 나눠 친다"
 USERID=$(kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get users -r keycloak-patterns -q username=labuser --fields id \
   --format csv --noquotes | tail -1)
@@ -523,7 +539,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 ### 3. IdP 세션이 realm 별로 어떻게 남았는지 본다
 
-```bash label="[kc-lab-1] realm 을 조인해서 센다"
+```bash label="[lab host] realm 을 조인해서 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select us.user_session_id, r.name as realm,
           (select count(*) from offline_client_session cs
@@ -555,7 +571,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c
 
 ### 4. 앱 세션을 주입 검증과 같은 명령으로 본다
 
-```bash label="[kc-lab-1] 앞에서 친 것과 똑같은 줄이다"
+```bash label="[lab host] 앞에서 친 것과 똑같은 줄이다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
 ```
 
@@ -597,7 +613,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
 
 실제로 끊기는 순간을 보려면 수명 두 값을 읽고 기다린다. 가이드는 이 줄을 미검증으로 표시했고 기다려서 확인하지도 않았다(unknown).
 
-```bash label="[kc-lab-1] 수명 두 값을 읽는다"
+```bash label="[lab host] 수명 두 값을 읽는다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get realms/keycloak-patterns --fields accessTokenLifespan,ssoSessionIdleTimeout
 ```
@@ -630,7 +646,7 @@ IdP 는 로그인 경로의 단일 장애점이지 이미 로그인한 사용자
 
 **행동** — 주입 전 절차와 같은 명령이다.
 
-```bash label="[kc-lab-1] 세션을 비우고 캐시를 버린다"
+```bash label="[lab host] 세션을 비우고 캐시를 버린다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "delete from offline_client_session" -c "delete from offline_user_session"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli flushall
@@ -656,14 +672,14 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s
 
 **지우기 전에 백업 파일이 쓸 만한지 본다.** 이 파일은 이 편이 만들지 않는다 — B-7 이 Grafana Ingress 를 걷어내기 **전에** 떠 둔다. 지금은 그 Ingress 가 이미 없으니 파일이 비어 있으면 다시 뜰 원본도 없고, 되살리는 절차는 가이드에 없다(unknown).
 
-```bash label="[kc-lab-1] ⓪ 백업 파일이 쓸 만한지 본다"
+```bash label="[lab host] ⓪ 백업 파일이 쓸 만한지 본다"
 wc -l ~/grafana-ingress-backup.yaml
 grep -c 'app2.hyeonworks.com' ~/grafana-ingress-backup.yaml
 ```
 
 줄 수가 나오고 둘째 줄이 `0` 이 아니면 그 파일로 돌려줄 수 있다. `No such file or directory` 가 나오면 아래 `delete` 를 치지 않는다. B-4 로 app2 를 빌린 적이 있으면 그 편은 같은 백업을 `/tmp/grafana-ingress-backup.yaml` 에 떠 두므로 그쪽을 본다.
 
-```bash label="[kc-lab-1] C-2 를 이어서 하지 않을 때만 친다"
+```bash label="[lab host] C-2 를 이어서 하지 않을 때만 친다"
 kubectl -n keycloak-lab delete ingress oauth2-proxy
 kubectl apply -f ~/grafana-ingress-backup.yaml
 curl -sI https://app2.hyeonworks.com/ | head -3
@@ -703,6 +719,14 @@ curl -sI https://app2.hyeonworks.com/ | head -3
 | 스크린샷 두 장이 똑같다 | 실제로 같은 파일이다. 조작이 아니다 | 구별은 터미널 출력이 한다 |
 | `kubectl exec keycloak-0 -- curl` 이 `exit 127` | Keycloak 이미지에 curl 도 wget 도 없다 | 밖에서 치거나 임시 curl 파드 |
 
+## 이 실험대에서 아직 못 밟은 단계
+
+2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈췄는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
+
+- **남은 것** — app1·app2 로그인과 두 앱의 Redis 키 대조. 지금까지 밟은 것 — 세션 정리 구간 전부(`logout-all` 이 안 듣는 것, 자식 1633·부모 6, 롤아웃이 kcadm 세션을 날리는 것).
+- **막는 것** — `https://auth.hyeonworks.com` 이 서지 않는다. 와일드카드 인증서(Cloudflare API 토큰이 필요한 DNS-01)와, 밖에서 실험대에 닿는 길(호스트의 libvirt `guest_input` 구멍 — A-4 에서 확인한 `ExecStartPost` 누락)이 둘 다 있어야 한다.
+- **그때까지 이 편의 실측 가운데 `(observed)` 로 적힌 2026-09-17 값은 위 「지금까지 밟은 것」 범위뿐이다.** 나머지는 원래 실행의 값이다.
+
 ## 무엇이 관측이고 무엇이 아닌가
 
 이 절차의 숫자는 `2026-09-04 14:44–14:48 KST` 에 돈 한 번의 실행에서 나왔다(observed).
diff --git a/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-c2-backchannel-logout.md b/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-c2-backchannel-logout.md
index c5cc9e3..eda3aea 100644
--- a/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-c2-backchannel-logout.md
+++ b/docs/keycloak-session-store/tech-log-studio/trust-handed-over-at-the-edge/setup/setup-reproduce-c2-backchannel-logout.md
@@ -41,7 +41,9 @@ IdP 쪽에만 백채널 로그아웃 URL 을 넣고 로그아웃을 건 뒤, Red
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 `kc-lab-1` 에서 `kubectl` 로 친다. `kubectl` 에 `sudo` 를 붙이지 않는다. 앱 소스를 뒤지는 `grep -rn` 한 단계만 저장소를 체크아웃해 둔 워크스테이션에서 치고, 밖에서 후보 경로를 두드리는 `curl` 은 개발 머신에서 친다. 도달성을 재는 두 줄은 클러스터 안에 띄운 임시 파드 안에서 친다.
+명령은 `[lab host]` 에서 `kubectl` 로 친다. `kubectl` 에 `sudo` 를 붙이지 않는다. 앱 소스를 뒤지는 `grep -rn` 한 단계만 저장소를 체크아웃해 둔 워크스테이션에서 치고, 밖에서 후보 경로를 두드리는 `curl` 은 개발 머신에서 친다. 도달성을 재는 두 줄은 클러스터 안에 띄운 임시 파드 안에서 친다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 C-1 이 세운 두 앱을 그대로 쓴다. app1 은 BFF(Backend for Frontend, 브라우저 대신 토큰을 들고 있는 백엔드)이고 app2 는 oauth2-proxy 다.
 
@@ -111,7 +113,7 @@ C-1 은 왜 안 퍼졌는지를 안 물었다. 후보가 셋 있고 각각 판
 
 되돌리기는 백업한 값으로 다시 `update` 하는 것이고, 백업이 `{ }` 처럼 비어 있었다면 빈 객체로 되돌린다. 아래 한 줄이 그 빈 객체 갈래다 — 백업에 값이 있었던 사람이 그 값을 다시 넣는 명령은 가이드에 없다(unknown). 그쪽은 복구 1 절에서 다시 짚는다. `$CID` 는 주입 1 절에서 잡는 클라이언트 UUID 이므로, 여기를 먼저 읽는 지금은 아직 비어 있다. 실제로 칠 때는 그 절의 `CID=` 를 친 다음이다.
 
-```bash label="[kc-lab-1] 클라이언트 속성을 되돌린다 — $CID 를 잡은 뒤에 친다"
+```bash label="[lab host] 클라이언트 속성을 되돌린다 — $CID 를 잡은 뒤에 친다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   update "clients/$CID" -r keycloak-patterns -s 'attributes={}'
 ```
@@ -132,7 +134,7 @@ IdP 설정 → 앱 소스 → 앱의 실제 경로 → ★ 끊을 세션이 있
 
 **행동** — 관리자 비밀번호를 Secret 에서 읽어 명령 치환으로 넘긴다.
 
-```bash label="[kc-lab-1] 비밀번호를 화면에 찍지 않고 로그인한다"
+```bash label="[lab host] 비밀번호를 화면에 찍지 않고 로그인한다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   config credentials --server http://localhost:8080 --realm master --user admin \
   --password "$(kubectl -n keycloak-lab get secret keycloak-lab-secrets \
@@ -151,14 +153,27 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 **행동** — 두 클라이언트를 각각 본다.
 
-```bash label="[kc-lab-1] 속성을 통째로 받아 눈으로 훑는다"
+```bash label="[lab host] 속성을 통째로 받아 눈으로 훑는다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get clients -r keycloak-patterns -q clientId=bff-confidential --fields attributes
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get clients -r keycloak-patterns -q clientId=oauth2-proxy --fields attributes
 ```
 
-**예상 결과** — 실측은 이렇다(observed, `01-current-state.txt`).
+**예상 결과** — 2026-09-17 에도 세 경로가 전부 `302` 였고 `Location` 이 로그인 시작점을 가리켰다(observed).
+
+```text
+HTTP/1.1 302 Found
+Location: http://app1.hyeonworks.com/oauth2/authorization/keycloak
+
+/logout/connect/back-channel/keycloak 302
+/backchannel-logout 302
+/oauth2/sign_out 302
+```
+
+세 후보 어느 것도 백채널 엔드포인트가 아니다. **`302` 는 「그 경로가 있다」가 아니라 「인증이 필요한 요청으로 처리됐다」**를 뜻한다. 그런 핸들러가 없어 기본 규칙에 걸렸다. `Location` 이 로그인 시작점을 가리켜 그것을 증명한다.
+
+원래 실행의 실측은 이렇다(observed, `01-current-state.txt`).
 
 ```text
 === 현재 클라이언트의 백채널 로그아웃 설정 ===
@@ -201,6 +216,8 @@ grep -rn "oidcLogout\|backchannel" bff/src/main/java/
 
 **왜 필요한가** — 소스에 없으니 경로도 없다. 다만 빈 출력에는 원인이 둘이므로 다음 단계에서 배포된 앱을 직접 두드린다.
 
+2026-09-17 에 같은 저장소에서 다시 쳤다(observed). `bff/src/main/java/` 는 있는데 출력이 비었다 — **경로를 잘못 짚은 것이 아니라 정말 없다.**
+
 **문제가 생기면** — `grep` 이 빈 출력을 줄 때는 경로가 맞는지 먼저 의심한다. `ls bff/src/main/java/` 로 디렉터리가 실재하는지 본다. 없는 디렉터리를 뒤져도 `grep` 은 조용히 0건을 준다.
 
 ### 3. 배포된 앱의 실제 경로를 본다
@@ -246,7 +263,7 @@ done
 
 **행동** — C-1 에서 배운 대로 realm 을 조인해서 센다.
 
-```bash label="[kc-lab-1] ① realm 을 조인해 세고 Redis 도 본다"
+```bash label="[lab host] ① realm 을 조인해 세고 Redis 도 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select count(*) from offline_user_session us join realm r on r.id=us.realm_id
     where r.name='keycloak-patterns' and us.offline_flag='0'"
@@ -265,7 +282,7 @@ IdP 세션이 0 이다. Redis 에는 키가 2개 있는데 Keycloak 쪽은 비
 
 **행동** — 그러니 세션을 만든다. 브라우저에서 `https://app1.hyeonworks.com/` 을 열고 `labuser` 로 로그인한다. 가이드는 이 줄에 계정 이름과 비밀번호를 나란히 적지만 여기에는 이름만 옮긴다. 그 비밀번호는 B-0 의 `set-password` 로 따라 하는 사람이 정하는 값이다. 그리고 다시 센다.
 
-```bash label="[kc-lab-1] ② 똑같은 두 줄을 다시 친다"
+```bash label="[lab host] ② 똑같은 두 줄을 다시 친다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select count(*) from offline_user_session us join realm r on r.id=us.realm_id
     where r.name='keycloak-patterns' and us.offline_flag='0'"
@@ -296,7 +313,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
 
 **행동** — 클라이언트 UUID 를 먼저 잡아 눈으로 확인하고, 지금 속성을 파일로 받는다.
 
-```bash label="[kc-lab-1] UUID 를 잡고 속성을 파일로 받는다"
+```bash label="[lab host] UUID 를 잡고 속성을 파일로 받는다"
 CID=$(kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get clients -r keycloak-patterns -q clientId=bff-confidential --fields id \
   --format csv --noquotes | tail -1)
@@ -328,7 +345,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 **행동** — 점 표기로 한 번 쳐 본다.
 
-```bash label="[kc-lab-1] 점 표기 — 실패한다"
+```bash label="[lab host] 점 표기 — 실패한다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   update "clients/$CID" -r keycloak-patterns \
   -s "attributes.backchannel.logout.url=https://app1.hyeonworks.com/logout/connect/back-channel/keycloak"
@@ -350,7 +367,7 @@ command terminated with exit code 1
 
 **행동** — 두 속성을 한 JSON 으로 준다.
 
-```bash label="[kc-lab-1] JSON 으로 통째로 교체한다"
+```bash label="[lab host] JSON 으로 통째로 교체한다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   update "clients/$CID" -r keycloak-patterns \
   -s 'attributes={"backchannel.logout.url":"https://app1.hyeonworks.com/logout/connect/back-channel/keycloak",
@@ -369,7 +386,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 ### 1. 두 속성이 둘 다 들어갔는가
 
-```bash label="[kc-lab-1] 주입 전에 친 것과 똑같은 줄이다"
+```bash label="[lab host] 주입 전에 친 것과 똑같은 줄이다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get clients -r keycloak-patterns -q clientId=bff-confidential --fields attributes
 ```
@@ -391,7 +408,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 ### 2. 이 시점의 Redis 키 이름을 적어 둔다
 
-```bash label="[kc-lab-1] 키 이름을 그대로 적어 둔다"
+```bash label="[lab host] 키 이름을 그대로 적어 둔다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
 ```
 
@@ -416,7 +433,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
 
 **행동** — 시각을 남기고, 사용자 id 를 잡아 눈으로 확인하고, 로그아웃을 건다.
 
-```bash label="[kc-lab-1] 시각을 남기고 사용자 단위로 끊는다"
+```bash label="[lab host] 시각을 남기고 사용자 단위로 끊는다"
 date '+%H:%M:%S 로그아웃'
 USERID=$(kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get users -r keycloak-patterns -q username=labuser --fields id \
@@ -440,7 +457,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 ### 2. IdP 세션이 끊겼는지 먼저 본다
 
-```bash label="[kc-lab-1] realm 을 조인해 센다"
+```bash label="[lab host] realm 을 조인해 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select count(*) from offline_user_session us join realm r on r.id=us.realm_id
     where r.name='keycloak-patterns' and us.offline_flag='0'"
@@ -457,7 +474,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tA
 
 ### 3. 앱 세션을 주입 검증과 같은 명령으로 본다
 
-```bash label="[kc-lab-1] 앞에서 친 것과 똑같은 줄이다"
+```bash label="[lab host] 앞에서 친 것과 똑같은 줄이다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
 ```
 
@@ -483,7 +500,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '*'
 
 Keycloak 양쪽 노드와 앱 쪽이다.
 
-```bash label="[kc-lab-1] ① Keycloak 두 노드를 센다"
+```bash label="[lab host] ① Keycloak 두 노드를 센다"
 kubectl -n keycloak-lab logs keycloak-0 | grep -ci backchannel
 kubectl -n keycloak-lab logs keycloak-1 | grep -ci backchannel
 ```
@@ -496,7 +513,7 @@ kubectl -n keycloak-lab logs keycloak-1 | grep -ci backchannel
   keycloak-1: 0 줄
 ```
 
-```bash label="[kc-lab-1] ② BFF 쪽 도착 흔적을 본다"
+```bash label="[lab host] ② BFF 쪽 도착 흔적을 본다"
 kubectl -n keycloak-lab logs -l app=bff --since=5m --prefix | grep -i 'back-channel\|logout'
 ```
 
@@ -526,7 +543,7 @@ kubectl -n keycloak-lab logs -l app=bff --since=5m --prefix | grep -i 'back-chan
 
 **행동** — Keycloak 파드에는 `curl` 이 없으므로 같은 네임스페이스에 임시 파드를 띄운다. 가이드가 미검증으로 표시한 줄이고 원래 실행의 명령 원문은 기록에 없다(unknown). 출력은 실측이다.
 
-```bash label="[kc-lab-1] ① 임시 파드를 띄우고 들어간다"
+```bash label="[lab host] ① 임시 파드를 띄우고 들어간다"
 kubectl -n keycloak-lab run c2probe --rm -it --restart=Never \
   --image=curlimages/curl:8.11.1 --command -- sh
 ```
@@ -640,7 +657,7 @@ exit
 
 **행동** — 백업을 먼저 읽고, 읽은 값으로 되돌린다.
 
-```bash label="[kc-lab-1] ① 백업에 무엇이 있었는지 본다"
+```bash label="[lab host] ① 백업에 무엇이 있었는지 본다"
 cat ~/c2-bff-attributes-backup.json
 ```
 
@@ -648,7 +665,7 @@ cat ~/c2-bff-attributes-backup.json
 
 **값이 있었으면 여기서 멈춘다.** 그 값을 다시 넣는 명령은 원본 가이드에 없다(unknown). 지어내지 않으므로 이 절차에도 없다. 주입 3 절의 `attributes=` 가 통째로 교체했으니 원래 속성은 ①이 찍어 낸 `~/c2-bff-attributes-backup.json` 안에만 있다. 그 파일을 지우지 않는다 — 되돌릴 명령을 구하면 그 파일이 있어야 쓸 수 있다. 그리고 ②를 치지 않는다. `attributes={}` 는 지금 들어 있는 것과 함께 원래 값까지 비운다.
 
-```bash label="[kc-lab-1] ② 빈 객체로 되돌리는 경우 — 백업이 비어 있었을 때만 친다"
+```bash label="[lab host] ② 빈 객체로 되돌리는 경우 — 백업이 비어 있었을 때만 친다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   update "clients/$CID" -r keycloak-patterns -s 'attributes={}'
 ```
@@ -661,7 +678,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 ### 2. 세션을 정리한다
 
-```bash label="[kc-lab-1] C-1 과 같은 네 줄이다"
+```bash label="[lab host] C-1 과 같은 네 줄이다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "delete from offline_client_session" -c "delete from offline_user_session"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli flushall
@@ -679,14 +696,14 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s
 
 **지우기 전에 백업 파일이 쓸 만한지 본다.** 이 파일은 이 편이 만들지 않는다 — B-7 이 Grafana Ingress 를 걷어내기 **전에** 떠 둔다. 지금은 그 Ingress 가 이미 없으니 파일이 비어 있으면 다시 뜰 원본도 없고, 되살리는 절차는 가이드에 없다(unknown).
 
-```bash label="[kc-lab-1] ⓪ 백업 파일이 쓸 만한지 본다"
+```bash label="[lab host] ⓪ 백업 파일이 쓸 만한지 본다"
 wc -l ~/grafana-ingress-backup.yaml
 grep -c 'app2.hyeonworks.com' ~/grafana-ingress-backup.yaml
 ```
 
 줄 수가 나오고 둘째 줄이 `0` 이 아니면 그 파일로 돌려줄 수 있다. `No such file or directory` 가 나오면 아래 `delete` 를 치지 않는다. B-4 로 app2 를 빌린 적이 있으면 그 편은 같은 백업을 `/tmp/grafana-ingress-backup.yaml` 에 떠 두므로 그쪽을 본다.
 
-```bash label="[kc-lab-1] ① 빌린 것을 걷고 백업을 올린다"
+```bash label="[lab host] ① 빌린 것을 걷고 백업을 올린다"
 kubectl -n keycloak-lab delete ingress oauth2-proxy
 kubectl apply -f ~/grafana-ingress-backup.yaml
 curl -sI https://app2.hyeonworks.com/ | head -3
@@ -698,7 +715,7 @@ curl -sI https://app2.hyeonworks.com/ | head -3
 
 **문제가 생기면** — ⓪이 `No such file or directory` 를 냈다면 `delete` 를 치기 전이므로 Grafana Ingress 는 아직 없고 oauth2-proxy 것은 아직 있다. B-7 의 백업 단계를 다시 읽고, 두 경로에 다 없으면 Ingress 를 손대지 않은 채로 두고 여기서 멈춘다. oauth2-proxy 배포까지 걷어내려면 한 줄이 더 있다.
 
-```bash label="[kc-lab-1] ② 배포까지 걷어낼 때만 친다"
+```bash label="[lab host] ② 배포까지 걷어낼 때만 친다"
 kubectl delete -f deploy/lab/k8s/b7-oauth2-proxy.yaml
 ```
 
@@ -708,7 +725,7 @@ kubectl delete -f deploy/lab/k8s/b7-oauth2-proxy.yaml
 
 먼저 아래 확인표의 `kubectl -n keycloak-lab get pod c2probe` 로 남았는지 보고, `NotFound` 면 더 할 것이 없다. `--rm` 으로 안 지워졌으면 직접 지운다.
 
-```bash label="[kc-lab-1] 남아 있으면 지운다"
+```bash label="[lab host] 남아 있으면 지운다"
 kubectl -n keycloak-lab delete pod c2probe --ignore-not-found
 ```
 
diff --git a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b0-default-session-store.md b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b0-default-session-store.md
index b93c7f1..607cf6d 100644
--- a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b0-default-session-store.md
+++ b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b0-default-session-store.md
@@ -40,18 +40,35 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 ## 읽기 전에 — 어디서 치는가
 
-명령이 두 기계에 나뉜다. 소스를 고치고 이미지를 만드는 일은 워크스테이션에서 하고, 클러스터를 보고 배포하는 일은 `kc-lab-1` 에서 `kubectl` 과 `kcadm` 으로 한다. 그래서 코드블록마다 어디서 치는지를 붙여 두었다.
+명령이 두 기계에 나뉜다. 소스를 고치고 이미지를 만드는 일은 워크스테이션에서 하고, 클러스터를 보고 배포하는 일은 `[lab host]` 에서 `kubectl` 과 `kcadm` 으로 한다. 그래서 코드블록마다 어디서 치는지를 붙여 두었다.
+
+**`[kc-lab-1]` 라벨이 붙은 블록은 게스트 셸이다.** lab host 에서 `ssh kc-lab-1` 로 들어가서 치고, 끝나면 `exit` 로 나온다. `ssh kc-lab-2 '…'` 한 줄 형태는 lab host 에서 그대로 쳐도 되므로 `[lab host]` 로 두었다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 **시작 전에 셋을 스스로 정해 둔다. 그 명령이 원 가이드에 없다(unknown).**
 
-첫째, 워크스테이션에서 `kc-lab-1` 로 건너가는 명령이 이 절차에 없다. 라벨은 `[워크스테이션]` 과 `[kc-lab-1]` 을 여섯 번 오가는데 `ssh` 로 들어가는 줄도 `exit` 도 안 나온다. 경로는 이미지를 밀어 넣는 줄 하나에만 드러난다 — `ssh test-server "ssh kc-lab-1 '...'"`, 워크스테이션에서 `kc-lab-1` 까지 `test-server` 를 거친다. `[워크스테이션]` 블록은 처음 시작한 셸에서 치고 `[kc-lab-1]` 블록은 그 기계에 붙은 셸에서 친다.
+첫째, 워크스테이션에서 클러스터를 보는 기계로 건너가는 명령이 이 절차에 없다. 원 가이드의 라벨은 `[워크스테이션]` 과 `[kc-lab-1]` 을 여섯 번 오가는데 `ssh` 로 들어가는 줄도 `exit` 도 안 나온다. 경로는 이미지를 밀어 넣는 줄 하나에만 드러난다 — `ssh test-server "ssh kc-lab-1 '...'"`, 워크스테이션에서 `kc-lab-1` 까지 `test-server` 를 거친다. **`kubectl` 블록은 `kc-lab-1` 이 아니라 그 중간의 `test-server`, 즉 `[lab host]` 에서 친다** — 기반 가이드가 kubeconfig 를 거기에만 두기 때문이고, 까닭은 아래에 적었다. 그래서 건너갈 기계는 하나이고 `ssh test-server` 한 줄이면 된다. 이미지를 노드로 밀어 넣는 줄만 거기서 한 번 더 `ssh kc-lab-1` 로 들어간다.
 
 둘째, 이 절차의 파일 경로가 전부 저장소 상대경로다 — `bff/pom.xml`, `deploy/lab/k8s/bff-redis.yaml`. 어느 디렉터리에서 치는지 정하는 줄이 없으므로 두 기계 각각에서 저장소 루트로 먼저 옮겨 두고 시작한다. 다른 디렉터리에서 치면 `kubectl apply` 가 경로를 못 찾고 끝난다.
 
-셋째, 워크스테이션에서 고친 파일을 `kc-lab-1` 로 옮기는 단계가 없다. `vim deploy/lab/k8s/bff-redis.yaml` 은 `[워크스테이션]` 이고 그 파일을 읽는 `kubectl apply -f deploy/lab/k8s/bff-redis.yaml` 은 `[kc-lab-1]` 인데, 사이에 파일을 넘기는 명령이 원 가이드에 없다. **안 옮기고 치면 오류가 안 난다** — 손 안 댄 매니페스트가 그대로 적용돼 `SPRING_SESSION_STORE_TYPE=redis` 와 `BFF_DB_*` 가 살아 있는 채로 배포되고, 화면에는 배포 성공만 뜬다. 어긋난 것은 관찰 절의 빈 수가 `321` 이 아닌 다른 숫자로 나올 때 비로소 보인다.
+셋째, 워크스테이션에서 고친 파일을 클러스터를 보는 기계로 옮기는 단계가 없다. `vim deploy/lab/k8s/bff-redis.yaml` 은 `[워크스테이션]` 이고 그 파일을 읽는 `kubectl apply -f deploy/lab/k8s/bff-redis.yaml` 은 `[lab host]` 인데, 사이에 파일을 넘기는 명령이 원 가이드에 없다. **안 옮기고 치면 오류가 안 난다** — 손 안 댄 매니페스트가 그대로 적용돼 `SPRING_SESSION_STORE_TYPE=redis` 와 `BFF_DB_*` 가 살아 있는 채로 배포되고, 화면에는 배포 성공만 뜬다. 어긋난 것은 관찰 절의 빈 수가 `321` 이 아닌 다른 숫자로 나올 때 비로소 보인다.
 
 `kubectl` 에 `sudo` 를 붙이지 않는다. root 홈에는 `~/.kube/config` 가 없어 `localhost:8080` 으로 붙으려다 `connection refused` 로 끝난다. 반입한 B층 아홉 편의 전제 한 줄만 옛 형태로 `sudo kubectl` 을 적고 있고, 본문 명령 블록에는 한 번도 쓰지 않는다.
 
+**그 규칙은 `[lab host]` 의 규칙이지 `kc-lab-1` 의 규칙이 아니다.** 기반 가이드는 kubeconfig 를 lab host 의 `~/.kube/config` 에만 두고 게스트의 사용자 홈에는 일부러 두지 않는다. 그래서 `kc-lab-1` 에서는 `sudo` 없는 `kubectl` 이 도리어 막힌다 — 2026-09-17 에 양쪽에서 쳐서 확인했다(observed).
+
+| 어디서 | `kubectl …` | `sudo kubectl …` |
+|---|---|---|
+| lab host | 된다 | 안 된다 |
+| `kc-lab-1` | 안 된다 | 된다 |
+
+`kc-lab-1` 에서 `sudo` 없이 치면 `connection refused` 가 아니라 이렇게 끝난다.
+
+```text
+error: error loading config file "/etc/rancher/k3s/k3s.yaml": open /etc/rancher/k3s/k3s.yaml: permission denied
+```
+
 | 무엇 | 값 |
 |---|---|
 | 네임스페이스 | `keycloak-lab` |
@@ -105,7 +122,7 @@ git checkout -- bff/pom.xml bff/src/main/resources/application.yml \
   deploy/lab/k8s/bff-redis.yaml
 ```
 
-```bash label="[kc-lab-1] 배포한 것을 통째로 지운다"
+```bash label="[lab host] 배포한 것을 통째로 지운다"
 kubectl delete -f deploy/lab/k8s/bff-redis.yaml
 ```
 
@@ -123,7 +140,7 @@ PVC 는 `delete -f` 로 같이 지워진다. Redis 데이터도 함께 사라진
 
 **무엇을 보는가** — 두 노드의 메모리와 CPU 여유.
 
-```bash label="[kc-lab-1] 메모리와 노드 사용률을 본다"
+```bash label="[lab host] 메모리와 노드 사용률을 본다"
 free -m
 kubectl top nodes
 ```
@@ -144,11 +161,11 @@ kc-lab-2   121m         6%       1324Mi          33%
 
 **무엇을 보는가** — 지금 무엇이 떠 있는지.
 
-```bash label="[kc-lab-1] ① 워크로드를 본다"
+```bash label="[lab host] ① 워크로드를 본다"
 kubectl -n keycloak-lab get all
 ```
 
-```bash label="[kc-lab-1] ② Secret 과 Ingress 는 따로 본다"
+```bash label="[lab host] ② Secret 과 Ingress 는 따로 본다"
 kubectl -n keycloak-lab get secret,ingress
 ```
 
@@ -162,7 +179,7 @@ kubectl -n keycloak-lab get secret,ingress
 
 관리 자격증명을 잡는다. `kcadm` 은 Keycloak 이미지 안에 있다.
 
-```bash label="[kc-lab-1] ① kcadm 에 로그인한다"
+```bash label="[lab host] ① kcadm 에 로그인한다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   config credentials --server http://localhost:8080 --realm master --user admin \
   --password "$(kubectl -n keycloak-lab get secret keycloak-lab-secrets \
@@ -171,28 +188,37 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 비밀번호를 화면에 찍지 않는다. 명령 치환으로 넘기므로 값이 터미널에도 셸 히스토리에도 남지 않는다. 길이만 센다.
 
-```bash label="[kc-lab-1] ② 비밀번호의 길이만 센다"
+```bash label="[lab host] ② 비밀번호의 길이만 센다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets \
   -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d | wc -c
 ```
 
 realm 과 클라이언트를 만든다.
 
-```bash label="[kc-lab-1] ③ realm 과 confidential 클라이언트를 만든다"
+```bash label="[lab host] ③ realm 과 confidential 클라이언트를 만든다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   create realms -s realm=keycloak-patterns -s enabled=true -s accessTokenLifespan=60
 
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   create clients -r keycloak-patterns \
   -s clientId=bff-confidential -s publicClient=false -s secret=bff-lab-secret \
+  -s directAccessGrantsEnabled=true \
   -s 'redirectUris=["https://app1.hyeonworks.com/*"]'
 ```
 
+**`directAccessGrantsEnabled=true` 가 붙는 까닭은 B-3 때문이다.** 이 줄이 없으면 클라이언트는 기본값 `false` 로 만들어지고, B-3 이 같은 클라이언트로 `grant_type=password` 를 칠 때 이렇게 끝난다(2026-09-17, observed).
+
+```text
+{"error":"unauthorized_client","error_description":"Client not allowed for direct access grants"}
+```
+
+B-0 의 브라우저 로그인은 인가 코드 흐름이라 이 값이 `false` 여도 되고, 그래서 **B-0 을 끝까지 밟아도 안 드러난다.** 나중에 B-3 에서 막히고, 그때는 원인이 B-0 에 있다는 것이 안 보인다.
+
 `-s secret=bff-lab-secret` 은 Keycloak 쪽에 저장되는 값이고, BFF 가 실제로 보내는 값은 배포 매니페스트가 만드는 Secret `bff-secrets` 의 `KEYCLOAK_CLIENT_SECRET` 이다. 둘이 같아야 로그인이 끝까지 간다. 이 절차에는 둘을 견주는 단계가 없으므로, 주입 절에서 `deploy/lab/k8s/bff-redis.yaml` 을 열었을 때 그 칸을 눈으로 확인한다.
 
 만들어진 값을 되읽는다.
 
-```bash label="[kc-lab-1] ④ realm 설정 세 칸만 뽑아 본다"
+```bash label="[lab host] ④ realm 설정 세 칸만 뽑아 본다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get realms/keycloak-patterns --fields realm,enabled,accessTokenLifespan
 ```
@@ -209,17 +235,36 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 사용자를 만든다.
 
-```bash label="[kc-lab-1] ① 사용자를 만든다"
+```bash label="[lab host] ① 사용자를 만든다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   create users -r keycloak-patterns -s username=labuser -s enabled=true
 ```
 
 비밀번호를 준다.
 
-```bash label="[kc-lab-1] ② 비밀번호를 준다"
+```bash label="[lab host] ② 비밀번호를 준다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   set-password -r keycloak-patterns --username labuser --new-password 'lab-user-change-me'
 ```
+
+```bash label="[lab host] ②b 계정을 완전하게 만든다 — 안 하면 B-3 에서 막힌다"
+U=$(kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
+     get users -r keycloak-patterns -q username=labuser --fields id --format csv --noquotes | tr -d '\r')
+kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
+  update users/$U -r keycloak-patterns \
+  -s emailVerified=true -s email=labuser@example.invalid \
+  -s firstName=Lab -s lastName=User -s 'requiredActions=[]'
+```
+
+**①②만 치면 계정이 「완전히 설정되지 않은」 상태로 남는다.** `create users` 는 `emailVerified` 를 `false` 로 두고 이름과 이메일 칸을 비운 채 만든다. 그 상태로 B-3 이 `grant_type=password` 를 치면 이렇게 끝난다(2026-09-17, observed).
+
+```text
+{"error":"invalid_grant","error_description":"Account is not fully set up"}
+```
+
+**`$U` 를 쓸 때 변수 이름을 `UID` 로 짓지 않는다.** zsh 에서 `UID` 는 읽기 전용 숫자 변수라 `bad math expression` 으로 끝난다(2026-09-17, observed). 위처럼 `U` 같은 다른 이름을 쓴다.
+
+②b 까지 치면 같은 요청이 토큰을 돌려준다(observed).
 **★ 뒤의 편들이 이 값을 그대로 쓴다.** 이 실험대는 `labpass` 를 썼고, B-3 과 B-6 의 토큰
 요청이 `-d password=labpass` 로 그 값을 박아 놓고 있다. **여기서 다른 값을 정했으면 그
 자리들도 같이 바꿔야 한다** — 안 바꾸면 B-3 의 첫 토큰 요청이 `401` 로 떨어지고, 그것이
@@ -231,7 +276,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 **문제가 생기면** — realm 을 통째로 지우면 이 단계가 만든 것이 함께 사라진다.
 
-```bash label="[kc-lab-1] realm 을 통째로 지운다"
+```bash label="[lab host] realm 을 통째로 지운다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   delete realms/keycloak-patterns
 ```
@@ -368,7 +413,7 @@ org.yaml.snakeyaml.constructor.SafeConstructor.processDuplicateKeys
 
 매니페스트를 적용하고 롤아웃이 끝날 때까지 기다린다.
 
-```bash label="[kc-lab-1] ① 적용하고 두 롤아웃을 기다린다"
+```bash label="[lab host] ① 적용하고 두 롤아웃을 기다린다"
 kubectl apply -f deploy/lab/k8s/bff-redis.yaml
 kubectl -n keycloak-lab rollout status deployment/redis --timeout=180s
 kubectl -n keycloak-lab rollout status deployment/bff --timeout=300s
@@ -425,7 +470,7 @@ token-uri:         ${KC_ISSUER_INTERNAL}/protocol/openid-connect/token  # BFF 
 
 ### 파드 두 개가 서로 다른 노드에 떴는가
 
-```bash label="[kc-lab-1] BFF 와 Redis 의 배치를 본다"
+```bash label="[lab host] BFF 와 Redis 의 배치를 본다"
 kubectl -n keycloak-lab get pods -o wide -l app=bff
 kubectl -n keycloak-lab get pods -o wide -l app=redis
 ```
@@ -442,7 +487,7 @@ BFF 두 개가 서로 다른 노드에 있어야 한다. `topologySpreadConstrai
 
 ### 외부 진입점이 이 애플리케이션의 HTML 을 주는가
 
-```bash label="[kc-lab-1] 상태 줄과 헤더를 읽는 형태로 친다"
+```bash label="[lab host] 상태 줄과 헤더를 읽는 형태로 친다"
 curl -I https://app1.hyeonworks.com/
 ```
 
@@ -470,14 +515,14 @@ Bad Gateway
 
 그래서 파드 안에서 직접 받는다. alpine 기반 JRE 이미지에는 `wget` 이 들어 있어서 Keycloak 이미지와 달리 파드 안에서 HTTP 요청을 보낼 수 있다.
 
-```bash label="[kc-lab-1] ① 받을 파드 이름을 잡는다"
+```bash label="[lab host] ① 받을 파드 이름을 잡는다"
 kubectl -n keycloak-lab get pods -l app=bff
 BFF=$(kubectl -n keycloak-lab get pod -l app=bff \
         --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}')
 echo "$BFF"
 ```
 
-```bash label="[kc-lab-1] ② 파드 안에서 받아 크기를 센다"
+```bash label="[lab host] ② 파드 안에서 받아 크기를 센다"
 kubectl -n keycloak-lab exec "$BFF" -- \
   wget -qO- http://localhost:8083/actuator/beans > /tmp/beans.json
 wc -c /tmp/beans.json
@@ -491,7 +536,7 @@ wc -c /tmp/beans.json
 
 `0` 이면 못 받은 것이고 몇 백 바이트면 로그인 페이지나 오류 본문이다. 앞부분을 열어 확정한다.
 
-```bash label="[kc-lab-1] ③ 앞 200바이트만 본다"
+```bash label="[lab host] ③ 앞 200바이트만 본다"
 head -c 200 /tmp/beans.json ; echo
 ```
 
@@ -511,13 +556,13 @@ head -c 200 /tmp/beans.json ; echo
 "이름":{"aliases":[],"scope":"singleton","type":"패키지.클래스", ...}
 ```
 
-이 실험대는 `jq` 가 없어 `grep` 으로 덩어리를 뽑았다. 원 가이드가 아래 두 줄을 미검증으로 표시했다(unknown).
+이 실험대는 `jq` 가 없어 `grep` 으로 덩어리를 뽑았다. **아래 두 줄은 2026-09-17 에 쳐서 돌았다**(observed) — 그때까지 미검증이던 형태다.
 
-```bash label="[kc-lab-1] ① 빈의 개수를 센다"
+```bash label="[lab host] ① 빈의 개수를 센다"
 grep -o '"aliases":\[' /tmp/beans.json | wc -l
 ```
 
-```bash label="[kc-lab-1] ② 이름과 타입을 한 줄로 뽑아 거른다"
+```bash label="[lab host] ② 이름과 타입을 한 줄로 뽑아 거른다"
 grep -o '"[A-Za-z0-9_.$-]*":{"aliases":\[[^]]*\],"scope":"[a-z]*","type":"[^"]*"' /tmp/beans.json \
   | sed 's/{"aliases".*"type":"/ -> /' \
   | grep -i authorizedclient
@@ -527,6 +572,17 @@ grep -o '"[A-Za-z0-9_.$-]*":{"aliases":\[[^]]*\],"scope":"[a-z]*","type":"[^"]*"
 
 **어디를 보나** — ② 의 출력은 이렇게 생겼다(observed).
 
+2026-09-17 에는 저장소를 **붙인 상태**(B-1·B-2 를 거친 매니페스트)에서 쳐서 이렇게 나왔다(observed).
+
+```text
+빈 개수: 437
+authorizedClientService     -> org.springframework.security.oauth2.client.JdbcOAuth2AuthorizedClientService
+authorizedClientRepository  -> …AuthenticatedPrincipalOAuth2AuthorizedClientRepository
+RedisSessionConfiguration   -> org.springframework.boot.autoconfigure.session.RedisSessionConfiguration
+```
+
+**`321` 이 아니라 `437` 인 것이 이 측정이 쓸모 있다는 증거다.** B-0 의 `321` 은 저장소를 하나도 안 붙였을 때의 수이고, Redis 세션과 JDBC 토큰 저장소가 붙으면 빈이 그만큼 늘어난다. 이 편을 B-0 상태에서 재려면 위 「주입」 절의 되돌리기를 먼저 끝내야 한다 — **빈 수 하나로 지금 어느 상태인지 알 수 있다.**
+
 ```text
 "authorizedClientManager" -> org.springframework.security.oauth2.client.AuthorizedClientServiceOAuth2AuthorizedClientManager
 "authorizedClientRepository" -> org.springframework.security.oauth2.client.web.AuthenticatedPrincipalOAuth2AuthorizedClientRepository
@@ -554,7 +610,7 @@ grep -o '"[A-Za-z0-9_.$-]*":{"aliases":\[[^]]*\],"scope":"[a-z]*","type":"[^"]*"
 
 없다는 것은 세어서 확인한다.
 
-```bash label="[kc-lab-1] ③ Redis · Spring Session 계열 빈을 센다"
+```bash label="[lab host] ③ Redis · Spring Session 계열 빈을 센다"
 grep -ci 'RedisSessionRepository\|SpringHttpSessionConfiguration\|LettuceConnectionFactory' /tmp/beans.json
 ```
 
@@ -598,7 +654,7 @@ https://app1.hyeonworks.com/login?error
 
 로그를 본다.
 
-```bash label="[kc-lab-1] 두 replica 의 로그를 접두사와 함께 본다"
+```bash label="[lab host] 두 replica 의 로그를 접두사와 함께 본다"
 kubectl -n keycloak-lab logs -l app=bff --tail=100 --prefix
 ```
 
@@ -619,7 +675,7 @@ kubectl -n keycloak-lab logs -l app=bff --tail=100 --prefix
 
 replica 를 하나로 줄인다.
 
-```bash label="[kc-lab-1] ① replica 를 1 로 줄인다"
+```bash label="[lab host] ① replica 를 1 로 줄인다"
 kubectl -n keycloak-lab scale deployment/bff --replicas=1
 kubectl -n keycloak-lab rollout status deployment/bff --timeout=180s
 kubectl -n keycloak-lab get pods -l app=bff
@@ -664,7 +720,7 @@ kubectl -n keycloak-lab get pods -l app=bff
 
 ### 1. replica 를 되돌린다
 
-```bash label="[kc-lab-1] replica 를 2 로 올린다"
+```bash label="[lab host] replica 를 2 로 올린다"
 kubectl -n keycloak-lab scale deployment/bff --replicas=2
 kubectl -n keycloak-lab rollout status deployment/bff --timeout=180s
 ```
@@ -686,7 +742,7 @@ git status --short
 
 **B-1 이나 B-2 로 이어서 갈 것이면 이 절을 치지 않는다.** B-1 은 「Redis 는 배포만 되어 있고 아직 연결되지 않았다. B-0 이 그렇게 만들어 뒀다」를 전제로 시작하고 B-2 는 그 위에서 시작한다. 아래 두 줄은 `bff` 와 `redis` Deployment 를 PVC 까지, realm `keycloak-patterns` 를 `labuser` 까지 한꺼번에 없앤다. 치고 나면 B-1 은 배포와 realm 과 사용자를 다시 만드는 데서 시작해야 하는데 그 순서는 B-1 에 안 적혀 있고 이 편의 주입 절과 realm·사용자 단계로 되돌아와야 한다. B층을 여기서 끝낼 때만 친다.
 
-```bash label="[kc-lab-1] 배포와 realm 을 지운다"
+```bash label="[lab host] 배포와 realm 을 지운다"
 kubectl delete -f deploy/lab/k8s/bff-redis.yaml
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   delete realms/keycloak-patterns
@@ -748,6 +804,14 @@ authorization-uri: ${KC_ISSUER_EXTERNAL}/protocol/openid-connect/auth
 authorization-uri: ${KC_ISSUER_EXTERNAL:http://localhost:8080/realms/keycloak-patterns}/protocol/openid-connect/auth
 ```
 
+## 이 실험대에서 아직 못 밟은 단계
+
+2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈췄는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
+
+- **남은 것** — 브라우저 로그인(3절 뒤 전부)과 그 로그인이 만드는 `/actuator/beans` 재측정. 지금까지 밟은 것 — 이미지 빌드·반입, realm·클라이언트·사용자 생성, 매니페스트 적용, 빈 437개 확인.
+- **막는 것** — `https://auth.hyeonworks.com` 이 서지 않는다. 와일드카드 인증서(Cloudflare API 토큰이 필요한 DNS-01)와, 밖에서 실험대에 닿는 길(호스트의 libvirt `guest_input` 구멍 — A-4 에서 확인한 `ExecStartPost` 누락)이 둘 다 있어야 한다.
+- **그때까지 이 편의 실측 가운데 `(observed)` 로 적힌 2026-09-17 값은 위 「지금까지 밟은 것」 범위뿐이다.** 나머지는 원래 실행의 값이다.
+
 ## 무엇이 관측이고 무엇이 아닌가
 
 이 절차의 숫자는 `2026-09-04 13:39–13:46 KST` 에 돈 한 번의 실행에서 나왔다(observed).
diff --git a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b1-redis-session-store.md b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b1-redis-session-store.md
index 0d6833a..c465cdc 100644
--- a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b1-redis-session-store.md
+++ b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b1-redis-session-store.md
@@ -41,7 +41,9 @@ Redis 를 세션 저장소로 붙이고 B-0 에서 찍어 둔 빈 목록과 견
 
 ## 읽기 전에 — 어디서 치는가
 
-B-0 과 같다. 소스를 고치고 이미지를 만드는 일은 워크스테이션에서 하고, 클러스터를 보고 배포하는 일은 `kc-lab-1` 에서 친다. `kubectl` 에 `sudo` 를 붙이지 않는다. 브라우저 창도 하나 열어 둔다.
+B-0 과 같다. 소스를 고치고 이미지를 만드는 일은 워크스테이션에서 하고, 클러스터를 보고 배포하는 일은 `[lab host]` 에서 친다. `kubectl` 에 `sudo` 를 붙이지 않는다. 브라우저 창도 하나 열어 둔다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 **끊기는 곳도 B-0 과 같다. 시작 전에 셋을 스스로 정해 둔다 — 그 명령이 원 가이드에 없다(unknown).**
 
@@ -115,7 +117,7 @@ BFF 가 돌고 있나 → B-0 의 답 세 개 → Redis 가 비어 있나 → 
 
 **무엇을 보는가** — 파드 배치.
 
-```bash label="[kc-lab-1] BFF 와 Redis 의 배치를 본다"
+```bash label="[lab host] BFF 와 Redis 의 배치를 본다"
 kubectl -n keycloak-lab get pods -o wide -l app=bff
 kubectl -n keycloak-lab get pods -o wide -l app=redis
 ```
@@ -134,7 +136,7 @@ redis-568bd7c4-5c5vc   1/1   Running   0   20m   10.42.1.53   kc-lab-2
 
 **무엇을 보는가** — 주입 뒤에 견줄 빈 수와 빈 이름 셋.
 
-```bash label="[kc-lab-1] ① 빈 목록을 파드 안에서 받는다"
+```bash label="[lab host] ① 빈 목록을 파드 안에서 받는다"
 BFF=$(kubectl -n keycloak-lab get pod -l app=bff \
         --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}')
 kubectl -n keycloak-lab exec "$BFF" -- \
@@ -144,7 +146,7 @@ wc -c /tmp/beans-before.json
 
 이 실험대는 `jq` 가 없어 `grep` 으로 덩어리를 뽑았다. 원 가이드가 아래 두 줄을 미검증으로 표시했다(unknown).
 
-```bash label="[kc-lab-1] ② 빈을 세고 저장소 계열 이름을 뽑는다"
+```bash label="[lab host] ② 빈을 세고 저장소 계열 이름을 뽑는다"
 grep -o '"aliases":\[' /tmp/beans-before.json | wc -l
 grep -o '"[A-Za-z0-9_.$-]*":{"aliases":\[[^]]*\],"scope":"[a-z]*","type":"[^"]*"' /tmp/beans-before.json \
   | sed 's/{"aliases".*"type":"/ -> /' \
@@ -174,12 +176,12 @@ grep -o '"[A-Za-z0-9_.$-]*":{"aliases":\[[^]]*\],"scope":"[a-z]*","type":"[^"]*"
 
 **무엇을 보는가** — 연결 여부와 키 개수.
 
-```bash label="[kc-lab-1] ① 응답과 판 번호를 읽는 형태로 본다"
+```bash label="[lab host] ① 응답과 판 번호를 읽는 형태로 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli ping
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli info server | head
 ```
 
-```bash label="[kc-lab-1] ② 키 개수와 키 이름을 본다"
+```bash label="[lab host] ② 키 개수와 키 이름을 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan
 ```
@@ -205,11 +207,11 @@ redis_version:7.4.x
 
 한 번은 통째로 보고 그다음 걸러 본다.
 
-```bash label="[kc-lab-1] ① 환경변수를 통째로 본다"
+```bash label="[lab host] ① 환경변수를 통째로 본다"
 kubectl -n keycloak-lab exec "$BFF" -- printenv | sort
 ```
 
-```bash label="[kc-lab-1] ② Redis 쪽만 거른다"
+```bash label="[lab host] ② Redis 쪽만 거른다"
 kubectl -n keycloak-lab exec "$BFF" -- printenv | grep -i redis
 ```
 
@@ -339,13 +341,13 @@ kubectl -n keycloak-lab rollout restart deployment/bff
 
 지금 멈추려면 롤아웃을 되돌린다.
 
-```bash label="[kc-lab-1] 중간에 그만둘 때 치는 한 줄"
+```bash label="[lab host] 중간에 그만둘 때 치는 한 줄"
 kubectl -n keycloak-lab rollout undo deployment/bff
 ```
 
 **예상 결과** — 파드가 뜨지 않는다. 넓은 것부터 본다.
 
-```bash label="[kc-lab-1] ③ 파드 상태를 본다"
+```bash label="[lab host] ③ 파드 상태를 본다"
 kubectl -n keycloak-lab get pods -l app=bff
 ```
 
@@ -356,11 +358,11 @@ bff-695646ddb-kzs9k    0/1     CrashLoopBackOff   3 (20s ago)   90s
 
 로그보다 먼저 이벤트를 보고, 그다음 로그를 본다. 지금 파드와 죽기 전 파드를 따로 본다.
 
-```bash label="[kc-lab-1] ④ 이벤트를 본다"
+```bash label="[lab host] ④ 이벤트를 본다"
 kubectl -n keycloak-lab describe pod -l app=bff | tail -20
 ```
 
-```bash label="[kc-lab-1] ⑤ 지금 로그와 죽기 전 로그를 본다"
+```bash label="[lab host] ⑤ 지금 로그와 죽기 전 로그를 본다"
 kubectl -n keycloak-lab logs -l app=bff --tail=40
 kubectl -n keycloak-lab logs -l app=bff --previous --tail=40
 ```
@@ -377,7 +379,7 @@ Failed to bind properties under 'spring.data.redis.port' to int:
 
 **왜 필요한가** — 마지막 줄의 `"tcp://10.43.57.116:6379"` 는 매니페스트 어디에도 쓰지 않은 값이다. 주입 전에 `printenv` 로 미리 본 그 환경변수이고 쿠버네티스가 넣었다. Redis 는 멀쩡하고, 파드는 Redis 에 붙어 보지도 못한 채 설정 바인딩에서 죽었다. 메시지가 `Failed to bind properties` 라고 말하고 있다.
 
-```bash label="[kc-lab-1] ⑥ Redis 가 멀쩡한지 따로 확인한다"
+```bash label="[lab host] ⑥ Redis 가 멀쩡한지 따로 확인한다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli ping
 ```
 
@@ -414,7 +416,7 @@ spec:
           value: "6379"
 ```
 
-```bash label="[kc-lab-1] ② 적용하고 롤아웃을 기다린다"
+```bash label="[lab host] ② 적용하고 롤아웃을 기다린다"
 kubectl apply -f deploy/lab/k8s/bff-redis.yaml
 kubectl -n keycloak-lab rollout status deployment/bff --timeout=300s
 ```
@@ -441,7 +443,7 @@ bff-695646ddb-vjqzf    true   kc-lab-2
 
 ### 1. 자동 주입된 환경변수가 사라졌는가
 
-```bash label="[kc-lab-1] 새 파드 이름을 다시 잡고 환경변수를 본다"
+```bash label="[lab host] 새 파드 이름을 다시 잡고 환경변수를 본다"
 BFF=$(kubectl -n keycloak-lab get pod -l app=bff \
         --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}')
 kubectl -n keycloak-lab exec "$BFF" -- printenv | grep -i redis
@@ -458,7 +460,7 @@ REDIS_PORT=6379
 
 ### 2. 자동구성이 실제로 걸렸는가
 
-```bash label="[kc-lab-1] 파드 배치와 헬스를 본다"
+```bash label="[lab host] 파드 배치와 헬스를 본다"
 kubectl -n keycloak-lab get pods -o wide -l app=bff
 kubectl -n keycloak-lab exec "$BFF" -- \
   wget -qO- http://localhost:8083/actuator/health
@@ -486,7 +488,7 @@ kubectl -n keycloak-lab exec "$BFF" -- \
 
 B-0 의 방법을 그대로 다시 쓴다.
 
-```bash label="[kc-lab-1] ① 빈 목록을 받고 개수를 센다"
+```bash label="[lab host] ① 빈 목록을 받고 개수를 센다"
 kubectl -n keycloak-lab exec "$BFF" -- \
   wget -qO- http://localhost:8083/actuator/beans > /tmp/beans-after.json
 grep -o '"aliases":\[' /tmp/beans-after.json | wc -l
@@ -500,7 +502,7 @@ grep -o '"aliases":\[' /tmp/beans-after.json | wc -l
 
 새로 생긴 세션 저장소 빈을 뽑는다. 원 가이드가 아래 줄을 미검증으로 표시했다(unknown).
 
-```bash label="[kc-lab-1] ② 세션·Redis 계열 빈을 뽑는다"
+```bash label="[lab host] ② 세션·Redis 계열 빈을 뽑는다"
 grep -o '"[A-Za-z0-9_.$-]*":{"aliases":\[[^]]*\],"scope":"[a-z]*","type":"[^"]*"' /tmp/beans-after.json \
   | sed 's/{"aliases".*"type":"/ -> /' \
   | grep -iE 'session|redis'
@@ -518,7 +520,7 @@ grep -o '"[A-Za-z0-9_.$-]*":{"aliases":\[[^]]*\],"scope":"[a-z]*","type":"[^"]*"
 
 같은 파일에서 인가된 클라이언트 쪽을 따로 뽑는다. 이 실험이 판정하려는 것이 이쪽이다.
 
-```bash label="[kc-lab-1] ③ authorized client 계열을 뽑는다"
+```bash label="[lab host] ③ authorized client 계열을 뽑는다"
 grep -o '"[A-Za-z0-9_.$-]*":{"aliases":\[[^]]*\],"scope":"[a-z]*","type":"[^"]*"' /tmp/beans-after.json \
   | sed 's/{"aliases".*"type":"/ -> /' \
   | grep -i authorizedclient
@@ -550,7 +552,7 @@ grep -o '"[A-Za-z0-9_.$-]*":{"aliases":\[[^]]*\],"scope":"[a-z]*","type":"[^"]*"
 
 **무엇을 보는가** — 옮겨진 것 안에 무엇이 들었는지.
 
-```bash label="[kc-lab-1] ① 키 개수와 키 이름을 본다"
+```bash label="[lab host] ① 키 개수와 키 이름을 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan
 ```
@@ -567,7 +569,7 @@ bff:session:sessions:8963b6de-3564-4775-9ccd-1ee9616b83ae
 
 키 이름을 변수로 잡는다. 이 줄에는 걸러 내는 조각이 둘 붙어 있다.
 
-```bash label="[kc-lab-1] ② 세션 키 하나를 변수에 담는다"
+```bash label="[lab host] ② 세션 키 하나를 변수에 담는다"
 KEY=$(kubectl -n keycloak-lab exec deploy/redis -- \
         redis-cli --scan --pattern 'bff:session:sessions:*' | grep -v expires | head -1 | tr -d '\r')
 echo "$KEY"
@@ -577,7 +579,7 @@ echo "$KEY"
 
 바로 위 `redis-cli --scan` 이 이미 전체 키를 보여 줬으므로 그 출력에서 키 하나를 눈으로 골라 쳐도 되는데, 원 가이드가 그 두 단계 형태를 적어 두지 않았다(unknown).
 
-```bash label="[kc-lab-1] ③ 타입과 필드 이름을 본다"
+```bash label="[lab host] ③ 타입과 필드 이름을 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli type "$KEY"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli hkeys "$KEY"
 ```
@@ -599,7 +601,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli hkeys "$KEY"
 
 ### 3. TTL 과 값의 바이트를 본다
 
-```bash label="[kc-lab-1] ① 남은 수명을 본다"
+```bash label="[lab host] ① 남은 수명을 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli ttl "$KEY"
 ```
 
@@ -610,7 +612,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli ttl "$KEY"
 
 `spring.session.timeout=30m` 인 1800초에서 방금 지난 만큼 줄어든 값이다. 세션 TTL 1772초와 access token 수명 60초가 처음부터 어긋나 있다. 어느 쪽에 맞출지 고르기 전에 이미 어긋나 있고, 그 간극을 누가 메우는지가 B-3 의 주제다.
 
-```bash label="[kc-lab-1] ② 값의 앞 네 줄을 이스케이프해서 본다"
+```bash label="[lab host] ② 값의 앞 네 줄을 이스케이프해서 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --no-raw hgetall "$KEY" | head -4
 ```
 
@@ -633,7 +635,7 @@ D-2 의 버전 업그레이드에서 이 성질이 다시 나온다. Spring Secu
 
 **목적** — 롤링 재시작으로 Redis 덕을 보는지 확인한다. 롤링 재시작은 정상 작업이라 되돌릴 것이 없다.
 
-```bash label="[kc-lab-1] ① 파드를 전부 교체한다"
+```bash label="[lab host] ① 파드를 전부 교체한다"
 kubectl -n keycloak-lab rollout restart deployment/bff
 kubectl -n keycloak-lab rollout status deployment/bff --timeout=300s
 ```
@@ -710,7 +712,7 @@ kubectl -n keycloak-lab rollout status deployment/bff --timeout=300s
 
 Redis 를 비우는 것은 되돌릴 수 없다. 지운 세션은 돌아오지 않고 로그인한 사용자는 전부 로그아웃된다. 실험대라서 하는 일이다.
 
-```bash label="[kc-lab-1] ① 개수를 보고 비우고 다시 센다"
+```bash label="[lab host] ① 개수를 보고 비우고 다시 센다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli flushdb
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize
@@ -718,7 +720,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize
 
 세션 하나만 지우려면 이쪽이다. `$KEY` 는 관찰 2번에서 담아 둔 키이고, 그 뒤로 `rollout restart` 와 브라우저 왕복이 들어가 절차가 40분쯤 걸리므로 터미널을 새로 열었으면 값이 비어 있다. 치기 전에 `echo "$KEY"` 로 키가 나오는지 보고, 안 나오면 관찰 2번의 `KEY=$(...)` 두 줄을 다시 쳐서 담는다. 바로 위 ① 의 `flushdb` 를 이미 쳤으면 지울 키가 없으므로 ② 를 건너뛴다.
 
-```bash label="[kc-lab-1] ② 잡아 둔 키 하나만 지운다"
+```bash label="[lab host] ② 잡아 둔 키 하나만 지운다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli del "$KEY"
 ```
 
@@ -760,7 +762,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli del "$KEY"
 
 아래 줄의 `$BFF` 는 주입 검증 1번에서 담아 둔 파드 이름이다. 「막히면」은 아무 때나 펼치는 절이고 그 사이에 관찰 4번의 `rollout restart` 가 파드를 통째로 갈아치우므로, 그대로 치면 `NotFound` 가 온다. 치기 전에 주입 검증 1번의 `BFF=$(...)` 두 줄을 다시 쳐서 이름을 새로 담는다.
 
-```bash label="[kc-lab-1] 예외만 골라 본다"
+```bash label="[lab host] 예외만 골라 본다"
 kubectl -n keycloak-lab logs "$BFF" --tail=100 | grep -iE 'exception|error'
 ```
 
@@ -776,10 +778,18 @@ java.nio.channels.UnresolvedAddressException
   value: http://echo.header-lab.svc:8081
 ```
 
-```bash label="[kc-lab-1] 그 서비스가 어디 있는지 본다"
+```bash label="[lab host] 그 서비스가 어디 있는지 본다"
 kubectl -n header-lab get svc echo
 ```
 
+## 이 실험대에서 아직 못 밟은 단계
+
+2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈췄는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
+
+- **남은 것** — 브라우저 로그인 뒤의 Redis 키·필드·TTL 관찰. 지금까지 밟은 것 — 이미지 빌드·반입, 배포, `/actuator/beans` 로 `RedisSessionConfiguration` 확인.
+- **막는 것** — `https://auth.hyeonworks.com` 이 서지 않는다. 와일드카드 인증서(Cloudflare API 토큰이 필요한 DNS-01)와, 밖에서 실험대에 닿는 길(호스트의 libvirt `guest_input` 구멍 — A-4 에서 확인한 `ExecStartPost` 누락)이 둘 다 있어야 한다.
+- **그때까지 이 편의 실측 가운데 `(observed)` 로 적힌 2026-09-17 값은 위 「지금까지 밟은 것」 범위뿐이다.** 나머지는 원래 실행의 값이다.
+
 ## 무엇이 관측이고 무엇이 아닌가
 
 이 절차의 숫자는 `2026-09-04 13:59–14:03 KST` 에 돈 한 번의 실행에서 나왔다(observed).
diff --git a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b2-jdbc-token-store.md b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b2-jdbc-token-store.md
index 9972e2e..3d49d92 100644
--- a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b2-jdbc-token-store.md
+++ b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b2-jdbc-token-store.md
@@ -47,13 +47,28 @@ B-1 이 Redis 로 안 옮긴 토큰을 PostgreSQL 로 옮겨 보는 절차다. `
 
 **B-0 과 B-1 을 글자 그대로 따라 친 사람은 그 상태가 아니다.** B-0 의 주입 절이 `spring-boot-starter-jdbc` · `postgresql` · `h2` 와 `SecurityConfig` 의 명시 빈 둘과 `spring.datasource` 와 `BFF_DB_*` 를 **지우고**, B-1 은 그것을 되살리지 않는다. 그래서 B-0 → B-1 → B-2 순으로 온 BFF 에는 `JdbcOAuth2AuthorizedClientService` 가 없다.
 
+**2026-09-17 에 그 상태를 실제로 봤다**(observed). 저장소의 매니페스트를 그대로 배포하면 표는 생기고 행은 0 이다.
+
+```text
+                 Table "public.oauth2_authorized_client"
+ client_registration_id  | character varying(100)  | not null
+ principal_name          | character varying(200)  | not null
+ access_token_value      | bytea                   | not null
+ …
+select count(*) from oauth2_authorized_client  →  0
+```
+
+`\d` 가 정의를 돌려주므로 「배선이 됐다」로 읽기 쉬운데, 행은 브라우저 로그인이 한 번 끝나야 생긴다.
+
 **그 상태로 쳐도 화면은 정상으로 보인다.** 주입 전 3번이 표를 만들고 `\d oauth2_authorized_client` 도 정의를 돌려주는데, 행만 한 번도 안 생긴다. 그러면 주입 전 6번의 「이 값이 아직 `false` 로 나오면 … 로그아웃하고 다시 로그인한다」가 끝나지 않는 고리가 되어 로그인만 반복하게 된다. 두 번 재로그인해도 `accessTokenStoredOnServer` 가 `false` 이고 표의 행이 0이면 배선이 안 들어간 상태이므로 이 절차를 멈춘다.
 
 무엇을 넣어야 하는지는 B-0 의 주입 절이 지울 목록으로 적어 두었고, 바로 아래 「전제와 되돌리기」가 그 넷을 표로 옮겨 두었다. 그 넷을 되돌려 넣는 순서와 그때 친 빌드 명령은 원 가이드에 없다(unknown).
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 `kc-lab-1` 에서 `kubectl` 로 친다. `kubectl` 에 `sudo` 를 붙이지 않는다. 브라우저에서 버튼을 누르고 터미널에서 저장소를 세는 왕복이 이 절차의 대부분이라 터미널 하나와 브라우저 창 하나를 나란히 둔다. 로그아웃 한 단계만 브라우저 개발자 도구의 콘솔에서 친다.
+명령은 `[lab host]` 에서 `kubectl` 로 친다. `kubectl` 에 `sudo` 를 붙이지 않는다. 브라우저에서 버튼을 누르고 터미널에서 저장소를 세는 왕복이 이 절차의 대부분이라 터미널 하나와 브라우저 창 하나를 나란히 둔다. 로그아웃 한 단계만 브라우저 개발자 도구의 콘솔에서 친다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 예외는 아래 「전제와 되돌리기」의 두 블록뿐이다. 거기서만 워크스테이션의 저장소를 고치고 이미지를 다시 만든다. **그 기계로 건너가는 명령은 이 절차에 없다** — 경로는 이미지를 밀어 넣는 줄 하나에만 드러난다(`ssh test-server "ssh kc-lab-1 '...'"`, 워크스테이션에서 `test-server` 를 거쳐 `kc-lab-1` 로 간다). 그 블록의 `bff/pom.xml` 과 `deploy/lab/k8s/bff-redis.yaml` 도 저장소 상대경로라 어느 디렉터리에서 치는지 적힌 줄이 없으므로, 두 기계 각각에서 저장소 루트로 옮겨 두고 시작한다. 이 셋의 명령이 원 가이드에 없다(unknown).
 
@@ -155,7 +170,7 @@ B-2 자신의 가이드에는 JDBC 배선을 넣는 편집 명령도 그때 친
 
 **무엇을 보는가** — 파드 배치와 재시작 횟수.
 
-```bash label="[kc-lab-1] 네임스페이스 전체를 본다"
+```bash label="[lab host] 네임스페이스 전체를 본다"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
@@ -173,7 +188,7 @@ redis-...              1/1    Running  0         3d   ...          kc-lab-2
 
 파드 이름은 자주 바뀌므로 이름 대신 라벨로 부른다.
 
-```bash label="[kc-lab-1] 라벨로 BFF 만 본다"
+```bash label="[lab host] 라벨로 BFF 만 본다"
 kubectl -n keycloak-lab get pods -l app=bff
 ```
 
@@ -192,7 +207,7 @@ bff-555df79c97-vgg6g   1/1   Running       0     22s
 
 **무엇을 보는가** — `oauth2_authorized_client` 가 있는지. 원래 실행은 여기서 한 번 넘어졌다. 파드는 떴고 Hikari 도 붙었는데 테이블이 없었고 아무도 그것을 신고하지 않았다.
 
-```bash label="[kc-lab-1] 테이블 정의를 물어본다"
+```bash label="[lab host] 테이블 정의를 물어본다"
 kubectl -n keycloak-lab exec deploy/postgres -- \
   psql -U keycloak -d keycloak -c '\d oauth2_authorized_client'
 ```
@@ -222,7 +237,7 @@ command terminated with exit code 1
 
 DDL 은 여러 줄이고 나중에 다시 쓸 것이므로 파일로 만든다. 터미널에 붙여 넣는 명령과 프로그램 원문을 섞지 않는다.
 
-```bash label="[kc-lab-1] ① 편집기로 DDL 파일을 만든다"
+```bash label="[lab host] ① 편집기로 DDL 파일을 만든다"
 vim /tmp/oauth2-pg.sql
 ```
 
@@ -246,7 +261,7 @@ CREATE TABLE oauth2_authorized_client (
 
 위 DDL 은 `02-schema.txt` 의 `=== PostgreSQL 전용 스키마 ===` 절 원문이다(observed).
 
-```bash label="[kc-lab-1] ② 파일을 파드 안으로 넘겨 태운다"
+```bash label="[lab host] ② 파일을 파드 안으로 넘겨 태운다"
 kubectl -n keycloak-lab exec -i deploy/postgres -- \
   psql -U keycloak -d keycloak < /tmp/oauth2-pg.sql
 ```
@@ -262,7 +277,7 @@ CREATE TABLE
 
 **문제가 생기면** — 되돌리는 명령은 있지만 평소에는 치지 않는다. B-3 이후로도 이 표를 계속 쓴다.
 
-```bash label="[kc-lab-1] 표를 지운다. 평소에는 치지 않는다"
+```bash label="[lab host] 표를 지운다. 평소에는 치지 않는다"
 kubectl -n keycloak-lab exec deploy/postgres -- \
   psql -U keycloak -d keycloak -c 'drop table oauth2_authorized_client'
 ```
@@ -271,7 +286,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- \
 
 **무엇을 보는가** — 이 편의 답이 박혀 있는 한 줄. 이 줄을 보기 전에는 다음으로 넘어가지 않는다.
 
-```bash label="[kc-lab-1] 테이블 정의를 다시 물어본다"
+```bash label="[lab host] 테이블 정의를 다시 물어본다"
 kubectl -n keycloak-lab exec deploy/postgres -- \
   psql -U keycloak -d keycloak -c '\d oauth2_authorized_client'
 ```
@@ -310,7 +325,7 @@ PRIMARY KEY, btree (client_registration_id, principal_name)
 
 **무엇을 보는가** — 관찰 절에서 로그아웃 전후로 견줄 숫자 셋. 다른 명령으로 재면 비교가 아니다.
 
-```bash label="[kc-lab-1] ① BFF 세션 키를 접두어로 골라 본다"
+```bash label="[lab host] ① BFF 세션 키를 접두어로 골라 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern 'bff:session:*'
 ```
 
@@ -322,12 +337,12 @@ bff:session:sessions:8963b6de-3564-4775-9ccd-1ee9616b83ae
 
 `KEYS *` 대신 `--scan` 을 쓰는 것은 `KEYS` 가 Redis 를 잡아 두고 전 키를 훑기 때문이다. 그리고 `dbsize` 는 이 실험에서 부정확하다. Redis 하나를 BFF 와 B-7 의 oauth2-proxy 가 나눠 쓰므로 `dbsize` 에는 `_oauth2_proxy-…` 키도 섞인다. 접두어로 걸러 세는 쪽이 맞다.
 
-```bash label="[kc-lab-1] ② 토큰 행 수를 센다"
+```bash label="[lab host] ② 토큰 행 수를 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- \
   psql -U keycloak -d keycloak -c 'select count(*) from oauth2_authorized_client'
 ```
 
-```bash label="[kc-lab-1] ③ Keycloak 세션을 DB 쪽에서 센다"
+```bash label="[lab host] ③ Keycloak 세션을 DB 쪽에서 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- \
   psql -U keycloak -d keycloak \
   -c 'select offline_flag, count(*) from offline_user_session group by 1'
@@ -335,7 +350,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- \
 
 온라인 세션도 `offline_user_session` 에 `offline_flag = 0` 으로 들어 있다. B-3 에서 확인된 성질이다. 원래 실행은 Keycloak 관리 API 로 셌고 증거에는 숫자만 남아 있다. ③ 은 같은 숫자를 DB 쪽에서 보는 형태이고 원 가이드가 미검증으로 표시했다(unknown). 관리 API 로 보려면 이쪽이다.
 
-```bash label="[kc-lab-1] ④ 관리 API 로 세는 형태"
+```bash label="[lab host] ④ 관리 API 로 세는 형태"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   config credentials --server http://localhost:8080 --realm master --user admin \
   --password "$(kubectl -n keycloak-lab get secret keycloak-lab-secrets \
@@ -367,7 +382,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 **무엇을 보는가** — 덮어쓰이기 전의 행 수와 토큰 해시와 발급 시각.
 
-```bash label="[kc-lab-1] ① 행 수와 토큰 해시와 발급 시각을 함께 본다"
+```bash label="[lab host] ① 행 수와 토큰 해시와 발급 시각을 함께 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select client_registration_id, principal_name, access_token_issued_at,
           md5(access_token_value) as at_md5
@@ -390,7 +405,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c
 
 크기도 같이 본다.
 
-```bash label="[kc-lab-1] ② 두 토큰의 바이트 수를 본다"
+```bash label="[lab host] ② 두 토큰의 바이트 수를 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select client_registration_id, principal_name, access_token_type,
           length(access_token_value) as at_len, length(refresh_token_value) as rt_len
@@ -423,7 +438,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c
 
 지우기 전에 무엇을 지울지 눈으로 본다. 이 Redis 는 BFF 혼자 쓰는 것이 아니다.
 
-```bash label="[kc-lab-1] ① 전체 키를 한 번 본다"
+```bash label="[lab host] ① 전체 키를 한 번 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan
 ```
 
@@ -439,7 +454,7 @@ _oauth2_proxy-f6a9201fd534a047998278452001ccbf
 
 원래 실행은 스크립트를 돌렸고 아래 형태는 원 가이드가 손으로 치기 좋게 고쳐 미검증으로 표시한 것이다(unknown). 후속 문서 3절이 oauth2-proxy 세션을 지울 때 쓴 것과 같은 모양이다.
 
-```bash label="[kc-lab-1] ② BFF 세션만 골라 지우고 시각을 남긴다"
+```bash label="[lab host] ② BFF 세션만 골라 지우고 시각을 남긴다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern 'bff:session:*' \
   | xargs -r kubectl -n keycloak-lab exec deploy/redis -- redis-cli del
 date '+%H:%M:%S 세션 삭제'
@@ -466,7 +481,7 @@ date '+%H:%M:%S 세션 삭제'
 
 ### 1. BFF 세션만 사라지고 B-7 키는 그대로인가
 
-```bash label="[kc-lab-1] 두 접두어를 따로 센다"
+```bash label="[lab host] 두 접두어를 따로 센다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern 'bff:session:*'
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '_oauth2_proxy-*'
 ```
@@ -475,7 +490,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern '_oauth2
 
 ### 2. BFF 가 재시작되지 않았는가
 
-```bash label="[kc-lab-1] 재시작 횟수를 본다"
+```bash label="[lab host] 재시작 횟수를 본다"
 kubectl -n keycloak-lab get pods -l app=bff
 ```
 
@@ -491,7 +506,7 @@ kubectl -n keycloak-lab get pods -l app=bff
 
 **무엇을 보는가** — 주입 전에 친 것과 똑같은 명령의 결과.
 
-```bash label="[kc-lab-1] 대조군과 같은 질의를 다시 친다"
+```bash label="[lab host] 대조군과 같은 질의를 다시 친다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select client_registration_id, principal_name, access_token_issued_at,
           md5(access_token_value) as at_md5
@@ -559,7 +574,7 @@ A 쪽에서 다음 요청을 하면 B 의 토큰을 쓰게 된다. 같은 사용
 
 값을 찍기 전에 무엇을 찍게 될지 길이로 먼저 안다.
 
-```bash label="[kc-lab-1] ① refresh token 의 바이트 수만 본다"
+```bash label="[lab host] ① refresh token 의 바이트 수만 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select length(refresh_token_value) from oauth2_authorized_client"
 ```
@@ -568,7 +583,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tA
 
 원래 실행은 앞 200자 남짓을 통째로 찍었다. 아래 형태는 화면에 남는 양을 줄인 것이고 원 가이드가 미검증으로 표시했다(unknown).
 
-```bash label="[kc-lab-1] ② 앞 40자만 텍스트로 디코드해 본다"
+```bash label="[lab host] ② 앞 40자만 텍스트로 디코드해 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select left(convert_from(refresh_token_value,'UTF8'), 40) from oauth2_authorized_client"
 ```
@@ -584,7 +599,7 @@ eyJhbGciOiJIUzUxMiIsInR5cCIgOiAiSldU
 
 정말 JWT 인지 헤더를 풀어 본다. 원 가이드는 이 줄도 미검증으로 표시한다(unknown).
 
-```bash label="[kc-lab-1] ③ 첫 조각만 잘라 base64 로 푼다"
+```bash label="[lab host] ③ 첫 조각만 잘라 base64 로 푼다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
   "select convert_from(refresh_token_value,'UTF8') from oauth2_authorized_client limit 1" \
   | cut -d. -f1 | tr '_-' '/+' | base64 -d 2>/dev/null; echo
@@ -623,7 +638,7 @@ SyntaxError: invalid syntax
 
 로그아웃 전에 세 숫자를 먼저 잡는다. 주입 전에 정해 둔 명령 그대로다.
 
-```bash label="[kc-lab-1] ① 로그아웃 전 두 숫자를 잡는다"
+```bash label="[lab host] ① 로그아웃 전 두 숫자를 잡는다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern 'bff:session:*'
 kubectl -n keycloak-lab exec deploy/postgres -- \
   psql -U keycloak -d keycloak -tAc 'select count(*) from oauth2_authorized_client'
@@ -652,7 +667,7 @@ console.log(r.status, r.url);
 
 로그아웃 후 같은 세 명령을 친다.
 
-```bash label="[kc-lab-1] ② 로그아웃 뒤 세 숫자를 같은 명령으로 잡는다"
+```bash label="[lab host] ② 로그아웃 뒤 세 숫자를 같은 명령으로 잡는다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan --pattern 'bff:session:*'
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select principal_name, access_token_issued_at, access_token_expires_at
@@ -714,7 +729,7 @@ Q3 는 미지수 5번으로 「두 store 를 logout 에서 어떻게 한 번에
 
 ### 1. 남은 행을 지운다
 
-```bash label="[kc-lab-1] 이 사용자의 행만 지운다"
+```bash label="[lab host] 이 사용자의 행만 지운다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "delete from oauth2_authorized_client where principal_name = 'labuser'"
 ```
@@ -729,7 +744,7 @@ RP 가 로그아웃을 안 보내 주므로 사람이 직접 끊는다. 브라
 https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/logout
 ```
 
-```bash label="[kc-lab-1] 세션 수가 줄었는지 본다"
+```bash label="[lab host] 세션 수가 줄었는지 본다"
 kubectl -n keycloak-lab exec deploy/postgres -- \
   psql -U keycloak -d keycloak -c 'select offline_flag, count(*) from offline_user_session group by 1'
 ```
@@ -765,6 +780,14 @@ JDBC 배선까지 걷어낼 것이면 전제와 되돌리기 절의 두 블록
 | 로그아웃했는데 다시 들어가진다 | 버그가 아니다. Keycloak SSO 세션이 살아 있다 | RP-initiated logout 을 사람이 연다 |
 | `dbsize` 와 세어 본 키 수가 다르다 | oauth2-proxy 키가 섞여 있다 | `--scan --pattern` 으로 나눠 센다 |
 
+## 이 실험대에서 아직 못 밟은 단계
+
+2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈췄는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
+
+- **남은 것** — 브라우저 로그인 뒤의 `oauth2_authorized_client` 행 관찰과 `accessTokenStoredOnServer` 판정. 지금까지 밟은 것 — 표가 생겨 있고 행이 `0` 인 것까지.
+- **막는 것** — `https://auth.hyeonworks.com` 이 서지 않는다. 와일드카드 인증서(Cloudflare API 토큰이 필요한 DNS-01)와, 밖에서 실험대에 닿는 길(호스트의 libvirt `guest_input` 구멍 — A-4 에서 확인한 `ExecStartPost` 누락)이 둘 다 있어야 한다.
+- **그때까지 이 편의 실측 가운데 `(observed)` 로 적힌 2026-09-17 값은 위 「지금까지 밟은 것」 범위뿐이다.** 나머지는 원래 실행의 값이다.
+
 ## 무엇이 관측이고 무엇이 아닌가
 
 이 절차의 숫자는 `2026-09-04 14:09–14:13 KST` 에 돈 한 번의 실행에서 나왔다(observed).
diff --git a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b3-refresh-contention.md b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b3-refresh-contention.md
index 4c4487b..7abf2a6 100644
--- a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b3-refresh-contention.md
+++ b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b3-refresh-contention.md
@@ -37,7 +37,9 @@ sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 `kc-lab-1` 에서 `kubectl` 로 친다. 토큰을 주고받는 `curl` 만 탐침 파드 안에서 치는데, Keycloak 이미지에 `curl` 도 `wget` 도 없기 때문이다(`exit 127`). 브라우저는 필요 없다 — direct grant(`grant_type=password`)로 토큰을 만들므로 전 구간이 터미널에서 끝난다.
+명령은 `[lab host]` 에서 `kubectl` 로 친다. 토큰을 주고받는 `curl` 만 탐침 파드 안에서 치는데, Keycloak 이미지에 `curl` 도 `wget` 도 없기 때문이다(`exit 127`). 브라우저는 필요 없다 — direct grant(`grant_type=password`)로 토큰을 만들므로 전 구간이 터미널에서 끝난다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 터미널은 둘을 연다. 하나는 탐침 파드 셸을 붙잡고 있고, 다른 하나로 데이터베이스를 뒤진다. 파드 안에서 잡은 `RT` 와 `SID` 는 파드 밖으로 따라가지 않는다.
 
@@ -83,7 +85,7 @@ B-2 가 토큰을 PostgreSQL 로 옮겼고 두 replica 가 같은 행을 본다.
 
 **realm 설정을 바꾸는 실험이다.** `revokeRefreshToken` 을 켜면 realm 전체에 걸리고, 같은 realm 을 쓰는 다른 작업이 영향을 받는다. B-2 의 BFF 로그인도 그 안에 든다. 실험대에서만 하고, 중간에 그만두려면 아래 한 줄이면 된다.
 
-```bash label="[kc-lab-1] 중간에 그만둘 때 치는 한 줄"
+```bash label="[lab host] 중간에 그만둘 때 치는 한 줄"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   update realms/keycloak-patterns -s revokeRefreshToken=false -s refreshTokenMaxReuse=0
 ```
@@ -100,7 +102,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 **무엇을 보는가** — 파드 셋의 상태와 배치.
 
-```bash label="[kc-lab-1] 파드 배치를 본다"
+```bash label="[lab host] 파드 배치를 본다"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
@@ -121,7 +123,7 @@ postgres-... 1/1    Running  0         5d   ...          kc-lab-2
 
 ① 파드 안에서 관리 세션을 만든다. 비밀번호는 명령 치환으로 넘기므로 값이 터미널에도 셸 히스토리에도 안 남는다.
 
-```bash label="[kc-lab-1] kcadm 관리 세션을 만든다"
+```bash label="[lab host] kcadm 관리 세션을 만든다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   config credentials --server http://localhost:8080 --realm master --user admin \
   --password "$(kubectl -n keycloak-lab get secret keycloak-lab-secrets \
@@ -134,7 +136,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 **문제가 생기면** — 비밀번호가 실제로 있는지는 값이 아니라 길이로 본다.
 
-```bash label="[kc-lab-1] 비밀번호의 길이만 센다"
+```bash label="[lab host] 비밀번호의 길이만 센다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets \
   -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d | wc -c
 ```
@@ -143,7 +145,7 @@ kubectl -n keycloak-lab get secret keycloak-lab-secrets \
 
 **무엇을 보는가** — 주입이 건드릴 스위치와 건드리지 않을 값.
 
-```bash label="[kc-lab-1] realm 의 세 값을 읽는다"
+```bash label="[lab host] realm 의 세 값을 읽는다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get realms/keycloak-patterns \
   --fields revokeRefreshToken,refreshTokenMaxReuse,accessTokenLifespan
@@ -173,7 +175,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 ① 파드를 띄우고 Ready 까지 기다린다.
 
-```bash label="[kc-lab-1] ① 상주 탐침 파드를 띄운다"
+```bash label="[lab host] ① 상주 탐침 파드를 띄운다"
 kubectl -n keycloak-lab run b3-probe --image=curlimages/curl:8.11.1 \
   --restart=Never \
   --env="KC=http://keycloak.keycloak-lab.svc:8080/realms/keycloak-patterns/protocol/openid-connect/token" \
@@ -185,13 +187,39 @@ kubectl -n keycloak-lab wait --for=condition=Ready pod/b3-probe --timeout=120s
 
 ② 환경변수가 들어갔는지 값이 아니라 길이로 본다.
 
-```bash label="[kc-lab-1] ② 넘어간 값의 길이를 센다"
+```bash label="[lab host] ② 넘어간 값의 길이를 센다"
 kubectl -n keycloak-lab exec b3-probe -- sh -c 'echo "KC=$KC  CS길이=${#CS}"'
 ```
 
+**그 길이를 `15` 와 맞추려 하지 않는다.** 아래 실측의 `15` 는 그 실험대의 값이고, B-0 이 적은 `-s secret=bff-lab-secret` 을 쓰면 `14` 다(2026-09-17, observed). 볼 것은 숫자가 아니라 **매니페스트 쪽과 Keycloak 쪽이 같은가**이고, B-0 이 「이 절차에는 둘을 견주는 단계가 없다」고 적어 둔 그 대조가 이것이다. 값을 안 찍고 견주는 형태는 이렇다.
+
+```bash label="[lab host] 두 값이 같은지 값을 안 찍고 본다"
+A=$(kubectl -n keycloak-lab get secret bff-secrets \
+      -o jsonpath='{.data.KEYCLOAK_CLIENT_SECRET}' | base64 -d)
+C=$(kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
+      get clients -r keycloak-patterns -q clientId=bff-confidential \
+      --fields id --format csv --noquotes | tr -d '\r')
+S=$(kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
+      get clients/$C/client-secret -r keycloak-patterns \
+      --fields value --format csv --noquotes | tr -d '\r')
+echo "매니페스트 ${#A}자 · Keycloak ${#S}자"
+[ "$A" = "$S" ] && echo "두 값이 같다" || echo "두 값이 다르다"
+```
+
+2026-09-17 실측은 `매니페스트 14자 · Keycloak 14자` 와 `두 값이 같다` 였다(observed).
+
+**여기서 한 번에 막히는 것이 둘 더 있다.** 둘 다 원인이 B-0 에 있고 B-0 을 끝까지 밟아도 안 드러난다 — B-0 의 로그인은 인가 코드 흐름이라 둘 다 필요 없기 때문이다(2026-09-17, observed).
+
+| 5번에서 나오는 것 | 무엇이 빠졌나 | 어디서 고치나 |
+|---|---|---|
+| `unauthorized_client` · `Client not allowed for direct access grants` | 클라이언트의 `directAccessGrantsEnabled` 가 `false` | B-0 의 클라이언트 생성에 `-s directAccessGrantsEnabled=true` |
+| `invalid_grant` · `Account is not fully set up` | `labuser` 의 `emailVerified` 가 `false` 이고 이메일·이름 칸이 비었다 | B-0 의 사용자 생성 뒤 `-s emailVerified=true -s email=… -s firstName=… -s lastName=…` |
+
+둘을 고친 뒤 같은 요청이 토큰을 돌려줬다(observed).
+
 ③ 파드 셸로 들어간다. 프롬프트가 `/ $` 로 바뀐다.
 
-```bash label="[kc-lab-1] ③ 파드 셸로 들어간다"
+```bash label="[lab host] ③ 파드 셸로 들어간다"
 kubectl -n keycloak-lab exec -it b3-probe -- sh
 ```
 
@@ -205,7 +233,7 @@ KC=http://keycloak.keycloak-lab.svc:8080/realms/keycloak-patterns/protocol/openi
 
 **문제가 생기면** — `CS길이=0` 이면 `--env` 가 빈 값을 넘겼다. 파드를 지우고 다시 띄운다.
 
-```bash label="[kc-lab-1] 탐침 파드를 지운다"
+```bash label="[lab host] 탐침 파드를 지운다"
 kubectl -n keycloak-lab delete pod b3-probe --ignore-not-found
 ```
 
@@ -273,7 +301,7 @@ done
 
 **무엇을 보는가** — 정상 세션의 `client_sessions` 가 몇인가. 파드 밖에서 친다.
 
-```bash label="[kc-lab-1] 정상 세션의 client session 을 센다"
+```bash label="[lab host] 정상 세션의 client session 을 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select us.user_session_id, us.offline_flag,
           (select count(*) from offline_client_session cs
@@ -320,7 +348,7 @@ user session 과 client session 은 서로 다르다.
 
 ① 회전을 켜고 시각을 남긴다.
 
-```bash label="[kc-lab-1] 회전을 켜고 시각을 남긴다"
+```bash label="[lab host] 회전을 켜고 시각을 남긴다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   update realms/keycloak-patterns -s revokeRefreshToken=true -s refreshTokenMaxReuse=0
 date '+%H:%M:%S 회전 켬'
@@ -340,7 +368,7 @@ date '+%H:%M:%S 회전 켬'
 
 결과를 해석하기 전에, 주입이 의도한 것만 건드렸는지 본다. 설정은 똑같은 명령으로 다시 읽는다.
 
-```bash label="[kc-lab-1] ① realm 을 똑같은 명령으로 다시 읽는다"
+```bash label="[lab host] ① realm 을 똑같은 명령으로 다시 읽는다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get realms/keycloak-patterns \
   --fields revokeRefreshToken,refreshTokenMaxReuse,accessTokenLifespan
@@ -354,7 +382,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 `revokeRefreshToken` 이 `true` 여야 한다. `false` 그대로면 `update` 가 다른 realm 에 갔거나 kcadm 세션이 만료됐다. kcadm 은 실패해도 조용할 때가 있어 반드시 다시 읽어서 확인한다.
 
-```bash label="[kc-lab-1] ② 재시작이 올랐는지 본다"
+```bash label="[lab host] ② 재시작이 올랐는지 본다"
 kubectl -n keycloak-lab get pods -l app=keycloak
 ```
 
@@ -393,7 +421,7 @@ SID=$(echo "$R" | sed -n 's/.*"access_token":"\([^"]*\)".*/\1/p' | cut -d. -f2 \
 echo "refresh=${#RT}자  SID=$SID"
 ```
 
-**동시에 다섯 개를 던진다.** 원래 실행은 스크립트였고, 아래는 가이드가 손으로 치기 좋게 고쳐 미검증으로 표시한 형태다(unknown). 본문과 응답 코드를 파일로 갈라 순서대로 다시 읽게 했다.
+**동시에 다섯 개를 던진다.** 원래 실행은 스크립트였고, 아래는 가이드가 손으로 치기 좋게 고친 형태다. **2026-09-17 에 그대로 쳐서 돌았다**(observed). 본문과 응답 코드를 파일로 갈라 순서대로 다시 읽게 했다.
 
 ```sh label="[탐침 파드] ② 같은 토큰으로 동시에 다섯 번 갱신한다"
 i=1
@@ -437,6 +465,20 @@ done
 | `Maximum allowed refresh token reuse exceeded` | 재사용 탐지가 발동 |
 | `Session doesn't have required client` | 그 여파 — client session 이 이미 없다 |
 
+**2026-09-17 실측**(observed) — 같은 모양이 다시 나왔다.
+
+```text
+요청 1: HTTP 400  Session doesn't have required client
+요청 2: HTTP 400  Session doesn't have required client
+요청 3: HTTP 400  Maximum allowed refresh token reuse exceeded
+요청 4: HTTP 200  (발급됨)
+요청 5: HTTP 400  Session doesn't have required client
+이긴 요청의 새 refresh 길이: 810
+그 토큰을 다시 쓰면: 400  Session doesn't have required client
+```
+
+**몇 번 요청이 이기는지는 실행마다 다르다.** 위 실측에서는 5번이었고 2026-09-17 에는 4번이었다. 판정에 쓰는 것은 번호가 아니라 **`200` 이 하나이고 그 하나가 받은 토큰도 안 통한다**는 두 가지다.
+
 하나만 이기고 나머지가 진 것이라면 지는 쪽 메시지가 전부 같아야 한다. 두 종류라는 것은 중간에 상태가 바뀌었다는 뜻이다. 성공한 번호는 환경마다 다르고 증거에서는 5번이었지만 순서는 스케줄링이 정한다 — 몇 번이 이겼는가는 아무 의미가 없다.
 
 **이긴 요청의 토큰을 다시 써 본다.** 여기서 진짜 답이 나온다.
@@ -473,7 +515,7 @@ curl -s -w '\n%{http_code}\n' -X POST "$KC" \
 
 **아래 두 블록에 박힌 `'BvFiB01Rntz1FcLdf7zG4BNt'` 를 자기 `SID` 로 바꾼다.** 그것은 원래 실행의 sid 라, 그대로 붙여넣으면 질의는 오류 없이 성공하고 `(0 rows)` 만 돌아온다. 두 블록 모두 바꿔야 한다 — 한쪽만 바꾸면 두 출력이 서로 다른 세션을 말한다. 출력은 마지막 줄부터 읽는다. `(1 row)` 면 그 sid 의 세션을 찾았고, `(0 rows)` 면 sid 를 안 바꿨거나 다른 값을 넣었다.
 
-```bash label="[kc-lab-1] ④ 그 sid 의 세션이 남아 있는가"
+```bash label="[lab host] ④ 그 sid 의 세션이 남아 있는가"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select us.user_session_id, us.offline_flag, us.last_session_refresh
      from offline_user_session us
@@ -492,7 +534,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c
 
 행이 있다. 세션이 통째로 지워진 것이 아니다. 그러면 왜 `Session doesn't have required client` 인가 — client session 을 센다.
 
-```bash label="[kc-lab-1] ⑤ 같은 sid 의 client session 을 센다"
+```bash label="[lab host] ⑤ 같은 sid 의 client session 을 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select us.user_session_id, us.offline_flag,
           (select count(*) from offline_client_session cs
@@ -524,7 +566,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c
 
 폐기 목록에 실린 것도 아니다.
 
-```bash label="[kc-lab-1] ⑥ 폐기 목록을 센다"
+```bash label="[lab host] ⑥ 폐기 목록을 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
   "select count(*) as revoked_count from revoked_token"
 ```
@@ -556,7 +598,7 @@ t3 와 t4 의 순서가 전부다. 응답을 만들던 요청은 이미 성공
 
 **정책을 바꿔 두 번 더 잰다.** 한 번 더 재기 전에 세션을 새로 만든다 — 파괴된 세션으로 재면 전부 `400` 이다.
 
-```bash label="[kc-lab-1] ⑦ 구성 B — 회전을 끈다"
+```bash label="[lab host] ⑦ 구성 B — 회전을 끈다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   update realms/keycloak-patterns -s revokeRefreshToken=false
 ```
@@ -578,7 +620,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 전부 `200` 이고 세션도 멀쩡하다(observed, `04-policy-comparison.txt`). 같은 refresh token 을 계속 쓸 수 있으므로 경쟁 자체가 성립하지 않는다. 대신 잃는 것이 있다 — 토큰이 유출되면 만료까지 계속 쓸 수 있고, 회전의 목적이 그 창을 좁히는 것이었다.
 
-```bash label="[kc-lab-1] ⑧ 구성 C — 회전을 켜고 재사용 1회를 허용한다"
+```bash label="[lab host] ⑧ 구성 C — 회전을 켜고 재사용 1회를 허용한다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   update realms/keycloak-patterns -s revokeRefreshToken=true -s refreshTokenMaxReuse=1
 ```
@@ -624,7 +666,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 ① 두 값을 한 번에 되돌리고 시각을 남긴다.
 
-```bash label="[kc-lab-1] ① 회전을 끄고 시각을 남긴다"
+```bash label="[lab host] ① 회전을 끄고 시각을 남긴다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   update realms/keycloak-patterns -s revokeRefreshToken=false -s refreshTokenMaxReuse=0
 date '+%H:%M:%S 회전 끔'
@@ -632,7 +674,7 @@ date '+%H:%M:%S 회전 끔'
 
 ② 똑같은 명령으로 다시 읽는다.
 
-```bash label="[kc-lab-1] ② 되돌아갔는지 다시 읽는다"
+```bash label="[lab host] ② 되돌아갔는지 다시 읽는다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get realms/keycloak-patterns \
   --fields revokeRefreshToken,refreshTokenMaxReuse,accessTokenLifespan
@@ -654,7 +696,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 ① 파드를 직접 지운다. `--rm` 이 없으므로 자동으로 사라지지 않는다.
 
-```bash label="[kc-lab-1] ① 탐침 파드를 지운다"
+```bash label="[lab host] ① 탐침 파드를 지운다"
 kubectl -n keycloak-lab delete pod b3-probe --ignore-not-found
 ```
 
@@ -666,7 +708,7 @@ https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/log
 
 ③ 세션 수를 센다.
 
-```bash label="[kc-lab-1] ③ 세션 수를 센다"
+```bash label="[lab host] ③ 세션 수를 센다"
 kubectl -n keycloak-lab exec deploy/postgres -- \
   psql -U keycloak -d keycloak -c 'select offline_flag, count(*) from offline_user_session group by 1'
 ```
diff --git a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b5-redis-loss.md b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b5-redis-loss.md
index 5e78110..4af56fb 100644
--- a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b5-redis-loss.md
+++ b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b5-redis-loss.md
@@ -41,7 +41,9 @@ Redis 를 0대로 내렸을 때 무엇이 멈추는지 재는 절차다. 세 경
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 `kc-lab-1` 에서 `kubectl` 로 친다. `kubectl` 에 `sudo` 를 붙이지 않는다 — root 홈에는 kubeconfig 가 없어 `localhost:8080` 으로 붙으려다 끝난다. 브라우저는 시작 전에 한 번 쓴다. 세션이 Redis 에 하나는 있어야 잃는 것이 보인다.
+명령은 `[lab host]` 에서 `kubectl` 로 친다. `kubectl` 에 `sudo` 를 붙이지 않는다 — root 홈에는 kubeconfig 가 없어 `localhost:8080` 으로 붙으려다 끝난다. 브라우저는 시작 전에 한 번 쓴다. 세션이 Redis 에 하나는 있어야 잃는 것이 보인다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 | 무엇 | 값 |
 |---|---|
@@ -81,13 +83,13 @@ A-2 에서 Keycloak 의 PostgreSQL 을 내렸을 때는 이렇게 됐다.
 
 **저장소를 지우는 실험이다.** Redis 를 0대로 내리고 나중에 볼륨 없이 파드를 지운다. 그 안의 세션은 돌아오지 않고 로그인한 사용자는 전부 로그아웃된다. 중간에 그만두려면 한 줄이면 된다.
 
-```bash label="[kc-lab-1] 중간에 그만둘 때 치는 한 줄"
+```bash label="[lab host] 중간에 그만둘 때 치는 한 줄"
 kubectl -n keycloak-lab scale deployment/redis --replicas=1
 ```
 
 볼륨을 뗀 뒤에는 매니페스트를 다시 적용해 되돌린다. 그 두 줄이 둘째 주입의 유일한 되돌리기다. `deploy/lab/k8s/bff-redis.yaml` 은 저장소 안의 상대 경로다 — 저장소를 체크아웃한 디렉터리에서 쳐야 풀리고, 다른 디렉터리에서 치면 경로가 없다는 오류로 끝나 볼륨이 안 돌아온다. 그 체크아웃이 `kc-lab-1` 의 어디에 있는지는 원본 가이드에 없다(unknown).
 
-```bash label="[kc-lab-1] 볼륨을 뗀 뒤에 되돌리는 두 줄"
+```bash label="[lab host] 볼륨을 뗀 뒤에 되돌리는 두 줄"
 kubectl apply -f deploy/lab/k8s/bff-redis.yaml
 kubectl -n keycloak-lab rollout status deployment/redis --timeout=180s
 ```
@@ -102,7 +104,7 @@ kubectl -n keycloak-lab rollout status deployment/redis --timeout=180s
 
 **무엇을 보는가** — 파드 넷의 상태와 배치.
 
-```bash label="[kc-lab-1] 파드 배치를 본다"
+```bash label="[lab host] 파드 배치를 본다"
 kubectl -n keycloak-lab get pods -o wide
 ```
 
@@ -122,7 +124,7 @@ redis-...              1/1    Running  0         3d   ...          kc-lab-2
 
 **무엇을 보는가** — 키 수와 두 영속화 설정.
 
-```bash label="[kc-lab-1] Redis 의 내용과 영속화 설정을 본다"
+```bash label="[lab host] Redis 의 내용과 영속화 설정을 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli ping
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli config get save
@@ -154,7 +156,7 @@ kubectl -n keycloak-lab exec deploy/redis -- redis-cli config get appendonly
 
 **무엇을 보는가** — 영속화를 말하기 전에 확인할 셋. 이 확인을 건너뛰면 「AOF 를 켰는데 안 남는다」를 「Redis 가 이상하다」로 읽게 된다.
 
-```bash label="[kc-lab-1] ① 파드에 볼륨이 붙어 있는가"
+```bash label="[lab host] ① 파드에 볼륨이 붙어 있는가"
 kubectl -n keycloak-lab get pod -l app=redis \
   -o jsonpath='{.items[0].spec.volumes}'; echo
 ```
@@ -165,7 +167,7 @@ kubectl -n keycloak-lab get pod -l app=redis \
 [{"name":"data","persistentVolumeClaim":{"claimName":"redis-data"}}]
 ```
 
-```bash label="[kc-lab-1] ② 어디에 붙었는지와 PVC 상태를 본다"
+```bash label="[lab host] ② 어디에 붙었는지와 PVC 상태를 본다"
 kubectl -n keycloak-lab get pod -l app=redis \
   -o jsonpath='{.items[0].spec.containers[0].volumeMounts}'; echo
 kubectl -n keycloak-lab get pvc
@@ -197,7 +199,7 @@ Redis 는 이것을 모른다. `appendonly yes` 를 켜면 성실히 `/data` 에
 
 **무엇을 보는가** — 주입 후에 볼 세 경로를 주입 전에 똑같은 명령으로.
 
-```bash label="[kc-lab-1] 세 경로의 상태 코드를 뽑는다"
+```bash label="[lab host] 세 경로의 상태 코드를 뽑는다"
 for p in / /bff/token-boundary /actuator/health; do
   curl -s -o /dev/null -w "$p  %{http_code}\n" --max-time 10 "https://app1.hyeonworks.com$p"
 done
@@ -226,7 +228,7 @@ done
 
 **무엇을 보는가** — 세 응답의 본문. `/actuator/**` 는 이 실험대에서 열려 있다(운영에서는 절대 안 연다).
 
-```bash label="[kc-lab-1] ① health 그룹 셋의 본문을 받는다"
+```bash label="[lab host] ① health 그룹 셋의 본문을 받는다"
 curl -s https://app1.hyeonworks.com/actuator/health; echo
 curl -s https://app1.hyeonworks.com/actuator/health/readiness; echo
 curl -s https://app1.hyeonworks.com/actuator/health/liveness; echo
@@ -252,11 +254,25 @@ curl -s https://app1.hyeonworks.com/actuator/health/liveness; echo
    /actuator/health/liveness     liveness 그룹
 ```
 
-```bash label="[kc-lab-1] ② kubelet 이 보는 경로를 확인한다"
+```bash label="[lab host] ② kubelet 이 보는 경로를 확인한다"
 kubectl -n keycloak-lab get deploy bff \
   -o jsonpath='{.spec.template.spec.containers[0].readinessProbe.httpGet.path}'; echo
 ```
 
+**2026-09-17 에 Redis 를 내리기 전과 후를 같은 세 줄로 쟀다**(observed). 세 그룹이 어디서 갈리는지가 이 편의 전부다.
+
+```text
+                            Redis 살아 있을 때   Redis 0대일 때
+/actuator/health                 UP                 DOWN   ← redis: RedisConnectionFailureException
+/actuator/health/readiness       UP                 UP     ← kubelet 이 보는 경로
+/actuator/health/liveness        UP                 UP
+
+파드                             1/1 Running        1/1 Running (둘 다)
+Service 엔드포인트                ready true,true    ready true,true
+```
+
+**Redis 가 통째로 사라졌는데 쿠버네티스는 아무것도 안 한다.** 합산 `health` 만 `DOWN` 이고 kubelet 이 보는 `readiness` 는 `UP` 이라 Service 가 두 파드로 트래픽을 계속 보낸다. `/actuator/health` 를 프로브로 걸었다면 두 파드가 동시에 빠져 전면 장애가 됐을 것이고, `readiness` 로 건 지금은 **아무 신호도 안 난다** — 어느 쪽이 맞는지가 아니라 **무엇을 고르면 무엇을 못 보게 되는지**가 이 세 줄에 있다.
+
 ```text
 /actuator/health/readiness
 ```
@@ -283,7 +299,7 @@ kubectl -n keycloak-lab get deploy bff \
 
 ① 시각을 남기고 replica 를 0으로 내린다.
 
-```bash label="[kc-lab-1] 시각을 남기고 Redis 를 0대로 내린다"
+```bash label="[lab host] 시각을 남기고 Redis 를 0대로 내린다"
 date '+%H:%M:%S 정지'
 kubectl -n keycloak-lab scale deployment/redis --replicas=0
 ```
@@ -307,14 +323,14 @@ deployment.apps/redis scaled
 
 **⓪ 먼저 Redis 를 다시 올린다.** 바로 앞 절에서 0대로 내려 두었고, 이 절의 명령은 전부 파드가 살아 있어야 한다. 올리지 않고 이어 치면 `exec deploy/redis` 가 붙을 파드를 못 찾는다.
 
-```bash label="[kc-lab-1] ⓪ 앞 절의 주입을 되돌린다"
+```bash label="[lab host] ⓪ 앞 절의 주입을 되돌린다"
 kubectl -n keycloak-lab scale deployment/redis --replicas=1
 kubectl -n keycloak-lab rollout status deployment/redis --timeout=180s
 ```
 
 ① `volumeMounts` 와 `volumes` 를 함께 뗀다. 가이드가 이 방향을 미검증으로 표시했다(unknown) — 원래 실행은 반대 순서였다.
 
-```bash label="[kc-lab-1] ① 볼륨 참조를 떼고 롤아웃을 기다린다"
+```bash label="[lab host] ① 볼륨 참조를 떼고 롤아웃을 기다린다"
 kubectl -n keycloak-lab patch deployment redis --type=json \
   -p '[{"op":"remove","path":"/spec/template/spec/containers/0/volumeMounts"},
        {"op":"remove","path":"/spec/template/spec/volumes"}]'
@@ -323,7 +339,7 @@ kubectl -n keycloak-lab rollout status deployment/redis --timeout=180s
 
 ② AOF 를 켜고 키를 심은 뒤 `/data` 를 본다.
 
-```bash label="[kc-lab-1] ② AOF 를 켜고 키를 심는다"
+```bash label="[lab host] ② AOF 를 켜고 키를 심는다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli config set appendonly yes
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli config get appendonly
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli set b5:aof "written-with-aof"
@@ -343,7 +359,7 @@ kubectl -n keycloak-lab exec deploy/redis -- ls -la /data
 
 **네 확인이 같은 시점을 보지 않는다.** ①②③ 은 첫째 주입이 걸려 있는 동안에만 성립한다 — 주입 1 절을 친 직후, 주입 2 절의 ⓪ 으로 Redis 를 다시 올리기 전에 본다. ④ 는 둘째 주입을 친 뒤라 Redis 가 1대로 살아 있을 때 본다. 절 순서대로 위에서 아래로 한 번에 치면 ① 이 `1/1` 을 내는데, 그것은 스케일이 안 먹은 증상이 아니라 ⓪ 이 제대로 올린 결과다.
 
-```bash label="[kc-lab-1] ① Redis 가 0대인가"
+```bash label="[lab host] ① Redis 가 0대인가"
 kubectl -n keycloak-lab get pods -l app=redis
 kubectl -n keycloak-lab get deploy redis
 ```
@@ -361,7 +377,7 @@ redis   0/0     0            0           3d
 
 **응답이 없는 것과 붙지 못하는 것은 다르다.** 로그가 이유를 말한다.
 
-```bash label="[kc-lab-1] ② BFF 로그에서 연결 시도를 찾는다"
+```bash label="[lab host] ② BFF 로그에서 연결 시도를 찾는다"
 kubectl -n keycloak-lab logs -l app=bff --tail=40 | grep -iE 'redis|connect|netty' | tail -10
 ```
 
@@ -378,7 +394,7 @@ kubectl -n keycloak-lab logs -l app=bff --tail=40 | grep -iE 'redis|connect|nett
 
 `pollConnect` 와 `finishConnect` 는 연결을 맺는 중이라는 뜻이다. 이미 실패한 것이 아니라 아직 시도 중이고, Lettuce(Netty 기반 Redis 클라이언트)가 재연결을 시도하며 타임아웃을 기다린다. 관찰 절의 `000` 이 여기서 나온다.
 
-```bash label="[kc-lab-1] ③ 엉뚱한 것을 죽이지 않았는지 본다"
+```bash label="[lab host] ③ 엉뚱한 것을 죽이지 않았는지 본다"
 kubectl -n keycloak-lab get pods
 ```
 
@@ -392,7 +408,7 @@ bff-555df79c97-vgg6g   1/1   Running   0     16m
 
 **둘째 주입도 걸렸는지 본다.** 볼륨 확인은 주입 전과 똑같은 명령이다.
 
-```bash label="[kc-lab-1] ④ 볼륨이 정말 떨어졌는가"
+```bash label="[lab host] ④ 볼륨이 정말 떨어졌는가"
 kubectl -n keycloak-lab get pod -l app=redis \
   -o jsonpath='{.items[0].spec.volumes}'; echo
 ```
@@ -416,7 +432,7 @@ kubectl -n keycloak-lab get pod -l app=redis \
 
 **`000` 은 오류가 아니라 멈춤이다.** 주입 전과 똑같은 명령을 친다.
 
-```bash label="[kc-lab-1] 세 경로를 다시 친다"
+```bash label="[lab host] 세 경로를 다시 친다"
 for p in / /bff/token-boundary /actuator/health; do
   curl -s -o /dev/null -w "$p  %{http_code}\n" --max-time 10 "https://app1.hyeonworks.com$p"
 done
@@ -456,7 +472,7 @@ done
 
 **그런데 파드는 `Ready` 를 유지한다.** 이 절차의 가장 중요한 발견이다.
 
-```bash label="[kc-lab-1] health 그룹 셋을 코드와 본문으로 본다"
+```bash label="[lab host] health 그룹 셋을 코드와 본문으로 본다"
 curl -s -o /dev/null -w 'health      %{http_code}\n' --max-time 10 https://app1.hyeonworks.com/actuator/health
 curl -s -o /dev/null -w 'readiness   %{http_code}\n' --max-time 10 https://app1.hyeonworks.com/actuator/health/readiness
 curl -s -o /dev/null -w 'liveness    %{http_code}\n' --max-time 10 https://app1.hyeonworks.com/actuator/health/liveness
@@ -489,9 +505,9 @@ curl -s https://app1.hyeonworks.com/actuator/health/readiness; echo
 
 그래서 Service 에서 파드를 빼지 않는다.
 
-```bash label="[kc-lab-1] 엔드포인트가 아직 ready 인지 본다"
+```bash label="[lab host] 엔드포인트가 아직 ready 인지 본다"
 kubectl -n keycloak-lab get endpointslice -l kubernetes.io/service-name=bff \
-  -o custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready
+  -o "custom-columns=NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready"
 ```
 
 ```text
@@ -533,7 +549,7 @@ liveness 에는 넣지 않는다. liveness 가 실패하면 kubelet 이 파드
 
 **첫째 주입을 되돌리고 손대지 않는다.** BFF 를 재시작하고 싶은 충동을 참는다 — 재시작하면 스스로 회복하는가를 영영 알 수 없다.
 
-```bash label="[kc-lab-1] ① Redis 를 다시 올린다"
+```bash label="[lab host] ① Redis 를 다시 올린다"
 date '+%H:%M:%S 복구'
 kubectl -n keycloak-lab scale deployment/redis --replicas=1
 kubectl -n keycloak-lab rollout status deployment/redis --timeout=180s
@@ -547,7 +563,7 @@ deployment.apps/redis scaled
 deployment "redis" successfully rolled out
 ```
 
-```bash label="[kc-lab-1] ② 회복했는지와 재시작 횟수를 본다"
+```bash label="[lab host] ② 회복했는지와 재시작 횟수를 본다"
 for p in /actuator/health /bff/token-boundary; do
   curl -s -o /dev/null -w "$p  %{http_code}\n" --max-time 10 "https://app1.hyeonworks.com$p"
 done
@@ -568,7 +584,7 @@ kubectl -n keycloak-lab get pods -l app=bff
 
 `rollout status` 가 돌아와도 지운 파드가 아직 종료 중일 수 있다. 이어지는 `exec deploy/redis` 가 그 파드에 붙으면 명령이 실패하거나 지우기 전 숫자를 낸다. 이 절차의 판정이 바로 그 `dbsize` 이므로, 숫자가 이상하면 `get pods -l app=redis` 로 `Running` 하나만 남았는지 보고 다시 친다.
 
-```bash label="[kc-lab-1] ③ 볼륨 없이 파드를 지우고 남은 것을 센다"
+```bash label="[lab host] ③ 볼륨 없이 파드를 지우고 남은 것을 센다"
 kubectl -n keycloak-lab delete pod -l app=redis
 kubectl -n keycloak-lab rollout status deployment/redis --timeout=180s
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize
@@ -597,7 +613,7 @@ deployment "redis" successfully rolled out
 
 볼륨을 되돌리고 같은 시험을 다시 하면 결과가 갈린다.
 
-```bash label="[kc-lab-1] ④ 볼륨을 되돌리고 같은 시험을 다시 한다"
+```bash label="[lab host] ④ 볼륨을 되돌리고 같은 시험을 다시 한다"
 kubectl apply -f deploy/lab/k8s/bff-redis.yaml
 kubectl -n keycloak-lab rollout status deployment/redis --timeout=180s
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli set b5:pvc "written-on-pvc"
@@ -642,7 +658,7 @@ deployment "redis" successfully rolled out
 
 PVC 도 노드에 못박힌다.
 
-```bash label="[kc-lab-1] PVC 의 스토리지 클래스를 본다"
+```bash label="[lab host] PVC 의 스토리지 클래스를 본다"
 kubectl get pvc -n keycloak-lab redis-data -o jsonpath='{.spec.storageClassName}'; echo
 ```
 
@@ -683,7 +699,7 @@ Prometheus 가 긁는 대상에 Redis·PostgreSQL·BFF 가 애초에 없다(obse
 
 ① 관찰 절에서 이미 쳤더라도 한 번 더 친다. `apply` 는 같은 결과를 낸다.
 
-```bash label="[kc-lab-1] 매니페스트를 다시 적용한다"
+```bash label="[lab host] 매니페스트를 다시 적용한다"
 kubectl apply -f deploy/lab/k8s/bff-redis.yaml
 kubectl -n keycloak-lab rollout status deployment/redis --timeout=180s
 ```
@@ -700,7 +716,7 @@ kubectl -n keycloak-lab rollout status deployment/redis --timeout=180s
 
 ① 접두어로만 지운다. **`FLUSHALL` 은 치지 않는다** — BFF 세션과 oauth2-proxy 세션이 같은 Redis 에 있다.
 
-```bash label="[kc-lab-1] 실험 키만 지우고 남은 키를 본다"
+```bash label="[lab host] 실험 키만 지우고 남은 키를 본다"
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli del b5:aof b5:pvc b5:probe
 kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan
 ```
diff --git a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b6-key-rotation.md b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b6-key-rotation.md
index 543b2a2..296de81 100644
--- a/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b6-key-rotation.md
+++ b/docs/keycloak-session-store/tech-log-studio/where-application-state-lives/setup/setup-reproduce-b6-key-rotation.md
@@ -37,7 +37,9 @@ realm 에 RSA 서명 키를 하나 더해 겹치는 구간을 만들고, 옛 공
 
 ## 읽기 전에 — 어디서 치는가
 
-명령은 전부 `[kc-lab-1]` 에서 친다. Keycloak 이미지에는 `curl` 도 `wget` 도 없어서(`exit 127`) 파드 안에서 HTTP 요청을 보낼 수 없다. JWKS(JSON Web Key Set, 서버가 공개키를 싣는 목록)와 토큰은 호스트에서 공개 이름으로 치고, `kcadm.sh` 만 `kubectl exec` 로 감싸 파드 안에서 돌린다.
+명령은 전부 `[lab host]` 에서 친다. Keycloak 이미지에는 `curl` 도 `wget` 도 없어서(`exit 127`) 파드 안에서 HTTP 요청을 보낼 수 없다. JWKS(JSON Web Key Set, 서버가 공개키를 싣는 목록)와 토큰은 호스트에서 공개 이름으로 치고, `kcadm.sh` 만 `kubectl exec` 로 감싸 파드 안에서 돌린다.
+
+**원 가이드는 이 명령들을 `kc-lab-1` 에서 치라고 적었다.** 기반 가이드가 세운 실험대에서는 그 기계에 kubeconfig 가 없어서 `sudo` 없는 `kubectl` 이 `permission denied` 로 막힌다 — kubeconfig 는 lab host 의 `~/.kube/config` 에만 있다(2026-09-17 에 양쪽에서 쳐서 확인했다, observed). 그래서 `kubectl` 블록의 기계 이름을 `[lab host]` 로 적었고, 노드 자체를 건드리는 명령에만 게스트 셸을 쓴다.
 
 터미널은 하나면 된다. 붙잡아 두어야 하는 셸이 없고, 대신 `OLD` 과 `NEW` 두 변수를 끝까지 들고 가므로 중간에 터미널을 닫지 않는다.
 
@@ -76,14 +78,23 @@ realm 에 RSA 서명 키를 하나 더해 겹치는 구간을 만들고, 옛 공
 - `05-keycloak` 이 끝나 있고 realm `keycloak-patterns` 에 클라이언트 `bff-confidential` 과 사용자 `labuser` 가 있다.
 - B-0 이 끝나 BFF 가 떠 있다.
 - 리소스 서버(`echo`, 네임스페이스 `header-lab`)가 떠 있다. 이 절차의 401 과 200 은 전부 그 앱이 판정한다.
+- **`echo` 가 발행자에 닿아야 한다.** 그 앱은 `SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI` 와 `…JWK_SET_URI` 를 **`https://auth.hyeonworks.com/…`** 로 들고 있어서, 인증서 단계를 안 끝낸 실험대에서는 JWKS 를 못 받아 **모든 토큰을 `401` 로 떨어뜨린다.** 2026-09-17 에 그 상태에서 재 보니 이랬다(observed).
+
+```text
+echo 가 발행자에 닿나      issuer=000  (curl exit 7)
+유효한 토큰으로 /api/echo  401
+토큰 없이 /api/echo        200
+```
+
+`401` 과 `200` 이 뒤집혀 보이지만 키 회전과는 무관하다 — 검증기가 공개키를 못 구해 전부 거절했고, 보호되지 않은 경로만 통과했다. **이 편의 판정은 TLS 가 서 있어야 성립한다.**
 
 **이건 되돌릴 수 없는 실험이다.** 지우는 것은 서명 키 공급자이고 그 안의 개인키가 함께 사라진다. 같은 이름으로 공급자를 다시 만들어도 새 키 쌍이 생기고 `kid` 가 달라지므로, 옛 키로 서명된 토큰은 영구히 검증되지 않는다. 실험대에서만 한다.
 
-되돌릴 수 있는 것은 주입 하나다. 방금 만든 공급자를 지우면 원래대로 돌아간다. id 는 주입이 화면에 찍어 주는 값이고 그 줄을 그대로 옮겨 친다 — 원래 실행에서는 `7902af43-a0cc-4ebd-ad25-04d563854d16` 이었다. 아래 블록에 박힌 값이 그 원래 실행의 id 라, 8 절을 친 뒤에 그 출력이 찍어 준 자기 id 로 바꿔야 지워진다. 8 절을 치기 전에는 지울 공급자가 없다.
+되돌릴 수 있는 것은 주입 하나다. 방금 만든 공급자를 지우면 원래대로 돌아간다. id 는 주입이 화면에 찍어 주는 값이다 — 원래 실행에서는 `7902af43-a0cc-4ebd-ad25-04d563854d16` 이었다. 아래 블록의 `{{NEW_PROVIDER_ID}}` 를 8 절 출력이 찍어 준 자기 id 로 바꿔야 지워진다. 8 절을 치기 전에는 지울 공급자가 없다.
 
-```bash label="[kc-lab-1] 관찰 절로 넘어가기 전에 그만둘 때 — id 를 8 절 출력의 자기 값으로 바꾼다"
+```bash label="[lab host] 관찰 절로 넘어가기 전에 그만둘 때 — id 를 8 절 출력의 자기 값으로 바꾼다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
-  delete components/7902af43-a0cc-4ebd-ad25-04d563854d16 -r keycloak-patterns
+  delete components/{{NEW_PROVIDER_ID}} -r keycloak-patterns
 ```
 
 ## 주입 전에 같은 명령으로 먼저 본다
@@ -100,14 +111,14 @@ kcadm 로그인 → 키 공급자 목록 → JWKS 원문 → 토큰의 kid → 
 
 **행동** — 관리자 자격증명으로 로그인하고, 값이 넘어갔는지는 길이로만 본다.
 
-```bash label="[kc-lab-1] ① kcadm 에 로그인한다"
+```bash label="[lab host] ① kcadm 에 로그인한다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   config credentials --server http://localhost:8080 --realm master --user admin \
   --password "$(kubectl -n keycloak-lab get secret keycloak-lab-secrets \
                 -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d)"
 ```
 
-```bash label="[kc-lab-1] ② 비밀번호의 길이만 센다"
+```bash label="[lab host] ② 비밀번호의 길이만 센다"
 kubectl -n keycloak-lab get secret keycloak-lab-secrets \
   -o jsonpath='{.data.KC_BOOTSTRAP_ADMIN_PASSWORD}' | base64 -d | wc -c
 ```
@@ -122,27 +133,45 @@ kubectl -n keycloak-lab get secret keycloak-lab-secrets \
 
 **무엇을 보는가** — 이 realm 에 어떤 키 공급자가 있고 각각의 id 가 무엇인지.
 
-```bash label="[kc-lab-1] 공급자 목록을 필드 셋으로 받는다"
+```bash label="[lab host] 공급자 목록을 필드 셋으로 받는다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get components -r keycloak-patterns --fields id,name,providerId
 ```
 
 **어디를 보나** — JSON 배열이 여러 줄로 나온다. `providerId` 가 `rsa-generated` 인 항목이 서명 키 공급자이고 `hmac-generated` · `aes-generated` 등이 함께 나온다. `"name" : "rsa-generated"` 인 항목의 `"id"` 를 지금 적어 둔다. 관찰 절에서 지울 대상이다.
 
-**이 값이 뜻하는 것** — 여기서 「키 공급자만 걸러 보자」는 시도가 빈 결과를 준다. 가이드가 이 줄을 미검증으로 표시했다(unknown) — 원래 실행에서 이렇게 치고 아무것도 못 받았다.
+**이 값이 뜻하는 것** — 가이드는 「키 공급자만 걸러 보자」는 아래 시도가 빈 결과를 준다고 적고 미검증으로 표시했다.
 
-```bash label="[kc-lab-1] 이렇게 치면 조용히 빈 결과다 (unknown)"
+```bash label="[lab host] 키 공급자만 걸러 본다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get components -r keycloak-patterns -q type=org.keycloak.keys.KeyProvider
 ```
 
-오류도 종료코드도 없이 비어 있다. 「키 공급자가 하나도 없구나」로 읽으면 이 절차 전체가 무너진다. 빈 출력은 「없다」가 아니라 「이 명령으로는 안 보인다」일 수 있고, `--fields` 로 전체를 받아 눈으로 고른다.
+**2026-09-17 에 쳐 보니 결과가 나왔다**(observed). 26.7.0 에서 이 질의는 공급자 넷을 그대로 돌려준다.
+
+```text
+"name":"rsa-enc-generated"  "name":"hmac-generated-hs512"  "name":"aes-generated"  "name":"rsa-generated"
+```
+
+**빈 결과를 봤다면 세션이 없어서일 수 있다.** 같은 날 세션이 끊긴 상태로 먼저 쳤을 때는 이렇게 끝났다(observed).
+
+```text
+No server specified. Use --server, or 'kcadm.sh config credentials'.
+```
+
+어느 쪽이든 판정은 같다 — **빈 출력은 「없다」가 아니라 「이 명령으로는 안 보인다」일 수 있다.** 그때는 `--fields` 로 전체를 받아 눈으로 고른다.
+
+:::warning
+
+**`kcadm` 세션은 파드 안에 산다.** `/opt/keycloak/.keycloak/kcadm.config` 에 놓이므로 `rollout restart` 나 이미지 교체로 파드가 갈리면 **그 파일째 사라진다.** 그러면 `401` 이 아니라 `No server specified` 로 끝나고, 앞 절에서 `config credentials` 를 이미 쳤어도 소용없다. 파드를 갈아 끼운 뒤에는 다시 친다(2026-09-17, observed).
+
+:::
 
 ### 3. JWKS 원문을 한 번 통째로 본다
 
 **무엇을 보는가** — 어떤 필드가 실려 있는지. 다음부터 무엇으로 걸를지가 여기서 정해진다.
 
-```bash label="[kc-lab-1] ① JWKS 를 자르지 않고 본다"
+```bash label="[lab host] ① JWKS 를 자르지 않고 본다"
 curl -s https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/certs
 ```
 
@@ -154,7 +183,7 @@ curl -s https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-con
 
 그 뒤로 `kty` · `alg` · `use` · `n` · `e` 가 이어지고 다음 키가 온다. `kid` 마다 `alg` 가 따로 붙는다. 읽을 만하게 자를 때는 `jq` 가 없으므로 `tr` 로 쉼표를 줄바꿈으로 바꾼다.
 
-```bash label="[kc-lab-1] ② kid 만 뽑아 본다"
+```bash label="[lab host] ② kid 만 뽑아 본다"
 curl -s https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/certs \
   | tr ',' '\n' | grep kid
 ```
@@ -181,14 +210,14 @@ curl -s https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-con
 
 JWKS 는 키 하나가 `}` 로 끝나므로 `tr '}'` 로 자르면 한 줄이 한 키가 된다.
 
-```bash label="[kc-lab-1] ① 키 단위로 잘라 RS256 만 센다 (unknown)"
+```bash label="[lab host] ① 키 단위로 잘라 RS256 만 센다 (unknown)"
 curl -s https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/certs \
   | tr '}' '\n' | grep -c RS256
 ```
 
 Keycloak 자신에게 묻는 쪽이 확실하고 그쪽이 1순위 도구다.
 
-```bash label="[kc-lab-1] ② Keycloak 에 직접 묻는다 (unknown)"
+```bash label="[lab host] ② Keycloak 에 직접 묻는다 (unknown)"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get keys -r keycloak-patterns
 ```
@@ -203,7 +232,7 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 **행동** — 토큰 엔드포인트와 클라이언트 비밀을 변수에 담고 direct grant 로 받는다.
 
-```bash label="[kc-lab-1] ① 옛 키로 서명된 토큰을 받고 길이만 본다"
+```bash label="[lab host] ① 옛 키로 서명된 토큰을 받고 길이만 본다"
 KC=https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/token
 CS=$(kubectl -n keycloak-lab get secret bff-secrets \
      -o jsonpath='{.data.KEYCLOAK_CLIENT_SECRET}' | base64 -d)
@@ -228,14 +257,29 @@ echo "${#OLD}자"
 
 **무엇을 보는가** — JWT 의 첫 토막이 헤더이고 거기 `kid` 가 있다.
 
-```bash label="[kc-lab-1] 토큰 헤더를 디코드한다"
+```bash label="[lab host] 토큰 헤더를 디코드한다"
 echo "$OLD" | cut -d. -f1 | tr '_-' '/+' | base64 -d 2>/dev/null; echo
 ```
 
 **어디를 보나** — 원래 실행의 모양은 이렇다(observed).
 
 ```json
-{"alg":"RS256","typ":"JWT","kid":"OY-caYDNGoP4HMAz-Q9UPTU-DM1i896NuzUZu6gfCqM"}
+{"alg":"RS256","typ" : "JWT","kid" : "OY-caYDNGoP4HMAz-Q9UPTU-DM1i896NuzUZu6gfCqM"}
+```
+
+**콜론 양옆의 공백을 눈여겨본다.** Keycloak 은 토큰 **헤더**를 `"typ" : "JWT"` 처럼 공백을 넣어 찍고, 페이로드는 `"sid":"…"` 처럼 붙여 찍는다. 그래서 페이로드에서 되던 `sed` 가 헤더에서는 빈손으로 돌아온다. 2026-09-17 에 같은 토큰 하나로 두 형태를 나란히 쳤다(observed).
+
+```text
+헤더: {"alg":"RS256","typ" : "JWT","kid" : "HKy0uQhg-vlQackK6-oj3hW6vKbDj-95Wlvdgl37cGg"}
+'"kid":"' 로 뽑으면   : []
+'"kid" *: *"' 로 뽑으면: [HKy0uQhg-vlQackK6-oj3hW6vKbDj-95Wlvdgl37cGg]
+```
+
+헤더에서 값을 뽑을 때는 공백을 허용한다.
+
+```bash label="[lab host] 헤더에서 kid 만 뽑는다 — 콜론 양옆 공백을 허용한다"
+echo "$OLD" | cut -d. -f1 | tr '_-' '/+' | base64 -d 2>/dev/null \
+  | sed -n 's/.*"kid" *: *"\([^"]*\)".*/\1/p'
 ```
 
 증거 파일에는 이렇게 남아 있다(observed, `01-before-rotation.txt`).
@@ -250,13 +294,13 @@ echo "$OLD" | cut -d. -f1 | tr '_-' '/+' | base64 -d 2>/dev/null; echo
 
 **무엇을 보는가** — 대조군. 이 확인을 건너뛰면 뒤의 401 이 아무 의미가 없다.
 
-```bash label="[kc-lab-1] ① 상태줄과 본문을 함께 본다"
+```bash label="[lab host] ① 상태줄과 본문을 함께 본다"
 curl -s -i -H "Authorization: Bearer $OLD" https://app1.hyeonworks.com/api/me
 ```
 
 200 이면 `subject` 같은 클레임이 돌아오고, 401 이면 `WWW-Authenticate` 헤더에 이유가 붙는다. 이 헤더를 한 번 봐 두면 뒤에서 401 이 났을 때 왜인지 물을 근거가 생긴다. 여러 번 비교할 때부터는 코드만 뽑는다.
 
-```bash label="[kc-lab-1] ② 상태 코드만 뽑는다"
+```bash label="[lab host] ② 상태 코드만 뽑는다"
 curl -s -o /dev/null -w 'old %{http_code}\n' \
   -H "Authorization: Bearer $OLD" https://app1.hyeonworks.com/api/me
 ```
@@ -286,7 +330,7 @@ Keycloak 의 키 회전은 바꾸기가 아니라 더 높은 우선순위로 추
 
 **행동** — 공급자를 만들고 시각을 남긴다.
 
-```bash label="[kc-lab-1] priority 200 짜리 RSA 공급자를 만든다"
+```bash label="[lab host] priority 200 짜리 RSA 공급자를 만든다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   create components -r keycloak-patterns \
   -s name=rsa-rotated -s providerId=rsa-generated \
@@ -314,7 +358,7 @@ Created new component with id '7902af43-a0cc-4ebd-ad25-04d563854d16'
 
 ### 9. JWKS 에 옛 키가 남아 있는가
 
-```bash label="[kc-lab-1] 3 절과 똑같은 줄을 다시 친다"
+```bash label="[lab host] 3 절과 똑같은 줄을 다시 친다"
 curl -s https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/certs \
   | tr ',' '\n' | grep kid
 ```
@@ -336,7 +380,7 @@ curl -s https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-con
 
 `OLD` 은 건드리지 않는다.
 
-```bash label="[kc-lab-1] 새 토큰을 받고 헤더를 읽는다"
+```bash label="[lab host] 새 토큰을 받고 헤더를 읽는다"
 NEW=$(curl -s -X POST "$KC" \
   -d grant_type=password -d client_id=bff-confidential -d "client_secret=$CS" \
   -d username=labuser -d password=labpass -d scope=openid \
@@ -355,7 +399,7 @@ echo "$NEW" | cut -d. -f1 | tr '_-' '/+' | base64 -d 2>/dev/null; echo
 
 ### 11. 둘 다 통해야 겹치는 구간이 무중단이다
 
-```bash label="[kc-lab-1] 두 토큰을 같은 두 줄로 친다"
+```bash label="[lab host] 두 토큰을 같은 두 줄로 친다"
 curl -s -o /dev/null -w 'old %{http_code}\n' \
   -H "Authorization: Bearer $OLD" https://app1.hyeonworks.com/api/me
 curl -s -o /dev/null -w 'new %{http_code}\n' \
@@ -374,7 +418,7 @@ curl -s -o /dev/null -w 'new %{http_code}\n' \
 
 여기서 `old` 가 401 이면 둘 중 하나다. 토큰이 만료됐거나(60초), 추가 말고 다른 것을 건드렸다. 가르는 법은 옛 토큰의 `exp` 를 보는 것이고 JWT 의 가운데 토막이 클레임이다.
 
-```bash label="[kc-lab-1] 만료인지 아닌지 가른다"
+```bash label="[lab host] 만료인지 아닌지 가른다"
 echo "$OLD" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null; echo
 date +%s
 ```
@@ -391,14 +435,14 @@ date +%s
 
 **무엇을 보는가** — 남길 것과 지울 것의 id. `-q` 는 여전히 안 먹는다.
 
-```bash label="[kc-lab-1] ① 목록을 다시 받는다"
+```bash label="[lab host] ① 목록을 다시 받는다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get components -r keycloak-patterns --fields id,name,providerId
 ```
 
 목록이 길면 그 항목 둘레만 잘라 본다. `"id"` 는 `"name"` 보다 위에 나온다.
 
-```bash label="[kc-lab-1] ② 지울 항목 둘레만 본다"
+```bash label="[lab host] ② 지울 항목 둘레만 본다"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get components -r keycloak-patterns --fields id,name,providerId \
   | grep -B2 '"name" : "rsa-generated"'
@@ -412,10 +456,10 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 
 **목적** — 옛 서명 키를 JWKS 에서 없앤다.
 
-**행동** — 위 출력의 id 를 변수에 옮기고 지운다. 아래 블록은 그대로 붙여넣으면 안 된다. 첫 줄의 `980ee9b7-...` 은 원래 실행의 값이므로 12 절 출력에서 읽은 자기 id 로 바꾼다. 안 바꾸고 치면 없는 컴포넌트를 지우라는 요청이 되어 옛 공급자는 살아 있고, 15 절이 `옛 200` 을 내 결론이 뒤집힌다.
+**행동** — 위 출력의 id 를 변수에 옮기고 지운다. 첫 줄의 `{{OLD_PROVIDER_ID}}` 를 12 절 출력에서 읽은 자기 id 로 바꾼 뒤에 친다. **그대로 붙여넣으면 셸이 멈춘다** — `{{ }}` 는 셸 문법이 아니라서 눈앞에서 실패한다. 전에는 첫 줄에 원래 실행의 값이 그대로 박혀 있었는데, 그것은 **유효한 대입이라 조용히 돌았다**: `OLDID` 에 그 문자열이 들어가고 아래 `delete` 가 실제로 나가 없는 컴포넌트를 지우라는 요청이 되고, 옛 공급자는 살아 있고, 15 절이 `옛 200` 을 내 결론이 뒤집힌다.
 
-```bash label="[kc-lab-1] 옛 공급자를 지우고 시각을 남긴다"
-OLDID=980ee9b7-...        # ← 위 출력에서 그대로 옮긴다. 환경마다 다르다
+```bash label="[lab host] 옛 공급자를 지우고 시각을 남긴다"
+OLDID={{OLD_PROVIDER_ID}}        # ← 12 절 출력의 id 를 그대로 옮긴다. 환경마다 다르다
 
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   delete components/"$OLDID" -r keycloak-patterns
@@ -435,7 +479,7 @@ date '+%H:%M:%S 제거'
 
 ### 14. JWKS 에서 사라졌는지 본다
 
-```bash label="[kc-lab-1] 또 같은 줄을 친다"
+```bash label="[lab host] 또 같은 줄을 친다"
 curl -s https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/certs \
   | tr ',' '\n' | grep kid
 ```
@@ -455,7 +499,7 @@ curl -s https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-con
 
 **치기 전에 `$OLD` 가 아직 안 죽었는지 본다.** 11 절의 만료 확인 두 줄을 그대로 다시 친다. `exp` 가 `date +%s` 보다 작으면 아래에서 나올 `old 401` 은 키 제거가 아니라 만료이고, 두 401 은 화면에서 똑같이 보인다.
 
-```bash label="[kc-lab-1] 11 절과 똑같은 두 줄"
+```bash label="[lab host] 11 절과 똑같은 두 줄"
 curl -s -o /dev/null -w 'old %{http_code}\n' \
   -H "Authorization: Bearer $OLD" https://app1.hyeonworks.com/api/me
 curl -s -o /dev/null -w 'new %{http_code}\n' \
@@ -478,7 +522,7 @@ curl -s -o /dev/null -w 'new %{http_code}\n' \
 
 **목적** — 401 이 캐시 상태 때문인지 가른다.
 
-```bash label="[kc-lab-1] echo 를 다시 띄우고 기다린다"
+```bash label="[lab host] echo 를 다시 띄우고 기다린다"
 kubectl -n header-lab rollout restart deploy/echo
 kubectl -n header-lab rollout status deploy/echo --timeout=180s
 ```
@@ -522,7 +566,7 @@ deployment "echo" successfully rolled out
 
 수명 세 값은 realm 설정이므로 직접 볼 수 있다. 가이드가 이 줄을 미검증으로 표시했다(unknown).
 
-```bash label="[kc-lab-1] realm 의 수명 세 값을 받는다 (unknown)"
+```bash label="[lab host] realm 의 수명 세 값을 받는다 (unknown)"
 kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
   get realms/keycloak-patterns --fields accessTokenLifespan,ssoSessionIdleTimeout,ssoSessionMaxLifespan
 ```
@@ -575,6 +619,14 @@ kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
 | 「캐시 때문일 것」이라 재시작을 기다린다 | 캐시는 유예를 주지 않는다 | 재시작 전후가 같다 |
 | 지운 키를 되살리려 한다 | 되살릴 수 없다. 같은 이름과 같은 키는 다르다 | 새 키 하나만 남은 상태가 정상이다 |
 
+## 이 실험대에서 아직 못 밟은 단계
+
+2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈췄는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
+
+- **남은 것** — 키 공급자 추가·삭제와 `echo` 가 내는 `401`/`200` 판정 전부. `echo` 가 JWKS 를 `https://auth.hyeonworks.com` 에서 받으므로 인증서가 서야 한다. 지금까지 밟은 것 — realm·사용자·`echo` 배포, JWKS 와 `kid` 읽기, 공급자 목록.
+- **막는 것** — `https://auth.hyeonworks.com` 이 서지 않는다. 와일드카드 인증서(Cloudflare API 토큰이 필요한 DNS-01)와, 밖에서 실험대에 닿는 길(호스트의 libvirt `guest_input` 구멍 — A-4 에서 확인한 `ExecStartPost` 누락)이 둘 다 있어야 한다.
+- **그때까지 이 편의 실측 가운데 `(observed)` 로 적힌 2026-09-17 값은 위 「지금까지 밟은 것」 범위뿐이다.** 나머지는 원래 실행의 값이다.
+
 ## 무엇이 관측이고 무엇이 아닌가
 
 이 절차의 숫자는 `2026-09-04 14:30–14:32 KST` 에 돈 한 번의 실행에서 나왔다(observed). 해설 문서 머리의 `15:50–16:00 KST` 는 문서를 쓴 시각이고 증거 파일의 mtime 이 앞의 값이라, 실측으로 인용하는 것은 뒤쪽이라고 가이드가 적는다.
diff --git a/docs/virtualization/final/document.md b/docs/virtualization/final/document.md
index c043181..7c172dc 100644
--- a/docs/virtualization/final/document.md
+++ b/docs/virtualization/final/document.md
@@ -22,7 +22,7 @@
 
 | 무엇 | 지금 |
 |---|---|
-| 증거 | `evidence/raw` 1 · `evidence/meta` 1 — 두 폴더에 있는 것은 폴더를 설명하는 `README.txt` 한 장씩이고 캡처한 원문은 0건이다 (`rendered`·`browser` 도 같다) |
+| 증거 | **2026-09-17 기준** `evidence/raw` 43 · `evidence/meta` 1. 2026-09-16 까지는 두 폴더에 `README.txt` 한 장씩뿐이고 캡처한 원문이 0건이었다. 2026-09-17 에 실험대를 철거하고 다시 세우며 `raw/lab-state-before-rebuild/` 에 42건을 남겼다 (`rendered`·`browser` 는 여전히 0건이다) |
 
 제5~9부의 코드 블록에 있는 명령 출력은 전부 **사람이 문서에 옮겨 적은 것**이다. 실행한 명령·cwd·실행 시각·종료 코드를 짝지어 남긴 `evidence/meta/` 항목이 하나도 없으므로, 그 값들이 언제 어느 상태에서 나왔는지는 **문서가 스스로 밝힌 날짜**(제7부 2026-09-10, §218 2026-09-03)까지만 확인된다. 반입한 `source/` 에도 캡처 원문은 없었다 — 원본 문서들도 출력을 본문에 옮겨 적는 방식이었다.
 
@@ -8277,6 +8277,34 @@ echo 'export LIBVIRT_DEFAULT_URI=qemu:///system' >> ~/.bashrc
 virsh uri
 ```
 
+**★ rc 파일에만 넣으면 `ssh lab-host '명령'` 에서는 안 먹는다**(2026-09-17, observed).
+그 형태는 비대화형 셸이라 `.bashrc`·`.zshrc` 를 안 읽는다.
+
+```
+ssh 로 한 줄     LIBVIRT_DEFAULT_URI=[(비어 있음)]
+대화형 셸        LIBVIRT_DEFAULT_URI=qemu:///system
+```
+
+셸과 무관하게 고정하려면 libvirt 자기 설정에 넣는다. 이 실험대에는 그 파일도
+있었다(observed).
+
+```bash
+mkdir -p ~/.config/libvirt
+echo 'uri_default = "qemu:///system"' >> ~/.config/libvirt/libvirt.conf
+virsh uri
+```
+
+```
+/home/donghyeon/.config/libvirt/libvirt.conf:uri_default = "qemu:///system"
+qemu:///system
+```
+
+**둘 중 하나만 있으면 어디선가 어긋난다.** rc 만 있으면 `ssh` 한 줄에서
+`qemu:///session` 을 보게 되고 — 그쪽에는 VM 이 없으므로 목록이 빈 채로 나와
+「VM 이 죽었다」로 읽힌다 — libvirt 설정만 있으면 대화형 셸의
+`echo $LIBVIRT_DEFAULT_URI` 가 비어서 「설정이 안 됐다」로 읽힌다.
+
+
 **따라 하는 사람은** 편집기로 연다. `echo >>` 는 가이드를 두 번 따라 하면 같은
 줄을 한 번 더 붙이고, 파일에 이미 무엇이 들어 있는지도 보여 주지 않는다.
 
@@ -9297,8 +9325,40 @@ rm ~/node-token
 
 토큰이 `/tmp/token` 대신 자기 홈에 놓이고, `sudo tee` 대신 `scp` 와 `chmod 600`
 이 그 파일을 만든다. 설치 스크립트는 `sudo` 아래 root 로 도니 홈의 `600` 파일도
-읽는다. 설치가 끝나면 지우는 것은 양쪽이 같다. 이 여덟 줄 형태는 이 실험대에서
-치지 않았다(unknown).
+읽는다.
+
+**★ 그런데 마지막 줄의 `rm ~/node-token` 만 치면 이 노드는 다시 못 뜬다.** 설치
+스크립트가 `--token-file` 에 준 경로를 유닛의 `ExecStart` 에 **그대로 굽기**
+때문에, 파일이 사라지면 agent 가 영원히 그 파일을 기다린다. 2026-09-17 에 A-4 를
+돌려 노드 전원을 뽑았다 다시 켜면서 그대로 겪었다(observed) — VM 은 떴는데 노드가
+`NotReady` 에서 안 돌아왔다.
+
+```
+k3s[522]: level=info msg="Waiting for file \"/home/donghyeon/node-token\" to be created"
+k3s-agent.service: Scheduled restart job, restart counter is at 1.
+```
+
+**지우기 전에 토큰을 root 만 읽는 자리로 옮기고 유닛을 그쪽으로 돌린다.** 그렇게
+하고 홈의 사본을 지우자 agent 를 완전히 세웠다 다시 켜도 `active` 였고 노드도
+`Ready` 로 돌아왔다(observed).
+
+```bash
+sudo install -m 600 -o root -g root ~/node-token /etc/rancher/node-token
+sudo ls -l /etc/rancher/node-token
+sudo sed -i "s|$HOME/node-token|/etc/rancher/node-token|" /etc/systemd/system/k3s-agent.service
+sudo systemctl daemon-reload
+sudo systemctl restart k3s-agent
+rm ~/node-token
+```
+
+```
+-rw------- 1 root root 109 /etc/rancher/node-token
+	'--token-file' \
+	'/etc/rancher/node-token' \
+```
+
+이 여덟 줄 형태는 2026-09-17 에 쳤다 — 설치 자체는 이 판으로 다시 돌리지 않았고,
+유닛을 고쳐 다시 시작하는 쪽만 확인했다(observed).
 
 **확인** — agent 가 클러스터에 들어왔는가, 그리고 **제 주소로** 들어왔는가
 
@@ -9627,7 +9687,7 @@ kubectl get nodes
 **확인 ① nginx 가 깔려 있는가** — `[kc-lab-edge]`
 
 ```bash
-which nginx
+ls /etc/nginx/
 ```
 
 **관측** — 2026-09-11, 새로 만든 `kc-lab-edge` 에서 실제로 나온 것(observed)
@@ -9637,10 +9697,25 @@ donghyeon@kc-lab-edge:~$ cd /etc/nginx/
 -bash: cd: /etc/nginx/: No such file or directory
 ```
 
-**어디를 봐야 하는가** — `which nginx` 가 **아무것도 안 찍으면** 미설치다.
+**어디를 봐야 하는가** — `No such file or directory` 가 나오면 미설치다.
 `/etc/nginx` 디렉터리는 패키지가 만든다. 그것이 없다는 것은 **경로를 잘못 찾은
 것이 아니라 설치가 안 된 것**이다.
 
+**★ 여기에 `which nginx` 를 쓰지 않는다.** 처음에는 그렇게 적어 두었는데 **깔려
+있을 때도 똑같이 아무것도 안 찍힌다.** 2026-09-17 에 nginx 가 돌고 있는
+`kc-lab-edge` 에서 직접 쳐서 확인했다(observed).
+
+```
+which nginx   -> (아무것도 안 찍고 exit 1)
+PATH          -> /usr/local/bin:/usr/bin:/bin:/usr/games
+sudo nginx -v -> nginx version: nginx/1.22.1
+```
+
+실행 파일은 `/usr/sbin/nginx` 인데 데비안의 일반 사용자 `PATH` 에 `/usr/sbin` 이
+없다. 그래서 `which nginx` 의 빈손은 **「안 깔렸다」가 아니라 「이 PATH 에서는 안
+보인다」**이고, 깔린 경우와 안 깔린 경우가 같은 출력이라 **판정에 쓸 수 없다.**
+판 번호를 볼 때도 `nginx -v` 가 아니라 `sudo nginx -v` 로 친다.
+
 **실행 절차**
 
 번호는 가이드 03 의 것을 그대로 쓴다.
@@ -9783,7 +9858,8 @@ ls -l /etc/nginx/sites-enabled/
 sudo nginx -t && sudo systemctl reload nginx
 ```
 
-통과하면 이런 형태다. Debian 12 는 `[warn]` 한 줄을 늘 같이 내놓는다(observed).
+통과하면 이런 형태다. 2026-09-11 의 엣지에서는 `[warn]` 한 줄이 앞에 붙어 세
+줄이었다(observed).
 
 ```
 nginx: [warn] could not build optimal types_hash, you should increase either
@@ -9792,6 +9868,20 @@ nginx: configuration file /etc/nginx/nginx.conf syntax is ok
 nginx: configuration file /etc/nginx/nginx.conf test is successful
 ```
 
+**★ 그 `[warn]` 은 늘 나오지는 않는다.** 처음에는 「Debian 12 는 늘 같이
+내놓는다」고 적었는데, 2026-09-17 에 같은 Debian 12 · 같은 `nginx/1.22.1` 엣지를
+새로 세우고 `sudo nginx -t` 를 세 번 쳤더니 **한 번도 안 나왔다**(observed). 두
+줄뿐이었다.
+
+```
+nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
+nginx: configuration file /etc/nginx/nginx.conf test is successful
+```
+
+그러니 이 줄이 안 보인다고 설정이 덜 읽힌 것이 아니다. **판정은 `syntax is ok`
+와 `test is successful` 두 마디로만 하고**, `[warn]` 줄은 나오면 무시하고 안
+나오면 없는 대로 둔다.
+
 **어디를 봐야 하는가** — `nginx -t` 가 내놓는 **마지막 줄**이다. `syntax is ok`
 와 `test is successful` 두 마디가 다 나와야 통과다. 앞에 나오는 `[warn]` 줄(예:
 `types_hash_max_size`)은 통과를 막지 않는다 — **04 에서 이 경고를 실패로
@@ -10035,9 +10125,32 @@ curl -s -o /dev/null -w '%{http_code}\n' http://192.168.122.12
 curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://192.168.122.10
 ```
 
-**어디를 봐야 하는가** — `301` 과 `Location` 이 나오는가. 여기서 막히면 문제는
-**엣지 안**이다(설정·기동). 통과하는데 아래 ③ 이 안 되면 문제는 **DNAT** 이다.
-이 한 층을 끼워 두면 그 둘을 헷갈리지 않는다.
+**어디를 봐야 하는가** — **엣지가 답을 하는가.** 여기서 막히면 문제는 **엣지
+안**이다(설정·기동). 통과하는데 아래 ③ 이 안 되면 문제는 **DNAT** 이다. 이 한
+층을 끼워 두면 그 둘을 헷갈리지 않는다.
+
+**★ 이 단계에서 나오는 코드는 `301` 이 아니라 `404` 다.** 처음에는 `301` 이라고
+적었는데, 2026-09-17 에 이 절을 그대로 따라 엣지를 다시 세우고 재 보니 이렇게
+나왔다(observed).
+
+```
+HTTP/1.1 404 Not Found
+Server: nginx/1.22.1
+Content-Type: text/plain; charset=utf-8
+Content-Length: 19
+```
+
+```
+404 page not found
+```
+
+`Server:` 가 `nginx/1.22.1` 이고 본문이 Traefik 의 `404 page not found` 라는 것이
+**엣지가 받아서 Traefik 으로 넘겼다**는 증거다. 이 단계의 설정에는 리다이렉트를 낼
+블록이 없다 — 위 「② 에 쓸 내용」은 `listen 80` 블록 하나뿐이고 그 안은
+`proxy_pass` 다. `301` 은 **04 가 443 블록과 80→443 리다이렉트를 얹은 뒤**의
+값이고, 처음 적은 `301` 은 다 끝난 실험대에서 잰 것을 이 자리로 옮겨 적은
+것이었다. 그래서 이 층의 통과 기준은 코드값이 아니라 **「`curl: (7)` 없이 응답이
+온다」와 `Server: nginx`** 두 가지다.
 
 **확인 ③ 밖에서, 즉 DNAT 을 거쳐 닿나**
 
@@ -10073,6 +10186,21 @@ curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://auth.hyeonworks.
 301 https://auth.hyeonworks.com/
 ```
 
+**★ 이 `301` 도 04 이후의 값이다.** 03 까지만 한 상태라면 ② 와 같은 `404` 가
+정상이고, 이 층이 묻는 것은 코드값이 아니라 **「밖에서 친 것이 엣지까지
+닿았는가」**다 — ② 와 같은 응답이 밖에서도 오면 DNAT 과 구멍이 살아 있다는 뜻이다.
+
+2026-09-17 에 밖에서 재 보니 **닿지 않았다**(observed).
+
+```
+curl: (7) Failed to connect to auth.hyeonworks.com port 80 after 54 ms
+```
+
+같은 시각에 호스트 안에서 친 `http://192.168.122.10` 은 `404` 로 답했다. 아래
+「막히면」 표의 마지막 줄이 가리키는 상태 그대로이고, 원인도 거기 적힌 대로였다 —
+**이 호스트에 실제로 깔려 있는 유닛에 `ExecStartPost` 줄이 없다.** 아래 「배포된
+것과 적어 둔 것이 다르다」를 본다.
+
 **확인 ④ 끝까지 닿나** (TLS 이후)
 
 ```bash
@@ -10153,10 +10281,10 @@ error 로그에 있었는데 잘려 있었고, access 로그에는 **3492자**
 | ① 이 `502` | Traefik 은 떴는데 백엔드가 없음 | Ingress 확인 |
 | ② 가 응답 없음 | nginx 가 안 떴거나 방화벽 | `systemctl status nginx` |
 | ③ 이 `502` | 인증서 문제 또는 upstream 다운 | 04 · 위 로그 |
-| `/etc/nginx: No such file or directory` | **nginx 미설치.** cloud-init 은 안 깐다 | `which nginx` |
+| `/etc/nginx: No such file or directory` | **nginx 미설치.** cloud-init 은 안 깐다 | `ls /etc/nginx/` — `which nginx` 는 깔려 있어도 빈손이라 못 가른다 |
 | `nginx -t` 가 `duplicate default server` | `sites-enabled/default` 가 살아 있다 | `ls -l /etc/nginx/sites-enabled/` |
 | 설정을 썼는데 아무 변화가 없다 | 경로 오타 — `site-available`(단수)에 썼다 | `ls /etc/nginx/sites-available/` |
-| `unknown directive "http2"` | nginx < 1.25.1. Debian 12 는 1.22 다 | `nginx -v` → `listen 443 ssl http2` 형태로 |
+| `unknown directive "http2"` | nginx < 1.25.1. Debian 12 는 1.22 다 | `sudo nginx -v` → `listen 443 ssl http2` 형태로 |
 | `systemctl reload` 가 실패한다 | 설정이 `nginx -t` 를 못 통과했다 | **reload 말고 `sudo nginx -t` 를 먼저** 친다 |
 | `cp: cannot stat 'deploy/...'` | 엣지에서 쳤거나, lab host 에 리포가 없다 | `ls ~/workspace` → 없으면 00 의 0번으로 |
 | `Unit lab-edge-dnat.service does not exist` | 유닛 파일이 없거나, `/etc/systemd/` 에 썼거나, `daemon-reload` 를 안 했다 | `find /etc/systemd -name 'lab-edge-dnat*'` — `system/` 아래여야 한다 |
@@ -10169,7 +10297,8 @@ error 로그에 있었는데 잘려 있었고, access 로그에는 **3492자**
 - (observed) 2026-09-11 새로 만든 엣지에서 `/etc/nginx` 가 없던 것, `nginx -t`
   출력 세 줄, 층별 확인 ①~④ 의 코드, `301 https://auth.hyeonworks.com/`,
   upstream 실패 errno 세 줄, access 로그 3492자
-- (observed) `.nft` 와 유닛 파일의 내용은 저장소 원본과 같다
+- (observed) 위에 실은 `.nft` 와 유닛의 내용은 **저장소 원본**과 같다. 다만
+  **호스트에 실제로 깔려 있는 두 파일은 그것이 아니다** — 바로 아래를 본다
 - (unknown) `curl -I http://192.168.122.11` 의 전체 출력은 캡처해 두지 않았다.
   가이드도 봐야 할 줄만 적었다
 - (unknown) `systemctl status nginx` 두 번, `ls -l /etc/nginx/sites-enabled/`,
@@ -10181,6 +10310,43 @@ error 로그에 있었는데 잘려 있었고, access 로그에는 **3492자**
 - **되돌리기는 가이드 7편 가운데 이 편에만 있다.** 위 네 줄이 원문 그대로이고,
   그 네 줄을 실제로 쳐서 걷어내 본 기록은 없다(unknown)
 
+**배포된 것과 적어 둔 것이 다르다**
+
+2026-09-17 에 이 절을 따라 실험대를 다시 세우다 호스트의 두 파일을 열어 봤더니
+**위에 실은 내용과 달랐다**(observed). 저장소 원본을 고친 뒤 호스트에 다시
+배포하지 않았다 — 파일 시각이 그렇게 말한다.
+
+| 파일 | 호스트에 깔린 것 (`11:00` · `10:52`) | 저장소 원본과 위 본문 (`13:30`) |
+|---|---|---|
+| `lab-edge-dnat.nft` | `prerouting` 뒤에 `forward` 체인이 **그대로 있다** (`priority filter - 10` · `ct state new accept`) | 그 체인이 **없다.** 자리에 「왜 뺐는지」 주석만 남겼다 |
+| `lab-edge-dnat.service` | `ExecStartPost` 줄이 **없다** | `ExecStartPost=-…insert rule ip libvirt_network guest_input…` 이 있다 |
+
+**이것이 위 확인 ③ 의 `curl: (7)` 을 그대로 설명한다.** 고친 쪽의 요점이 「앞
+체인의 `accept` 로는 뒤 체인의 `reject` 를 못 막으니 구멍은 libvirt 체인 안에
+뚫는다」(§180)인데, 호스트에는 **효과가 없는 쪽만 깔려 있고 효과가 있는 쪽은 안
+깔려 있다.** 게다가 그 구멍은 런타임 상태라 libvirt 가 네트워크를 다시 세우면
+날아가고, 다시 넣어 줄 `ExecStartPost` 가 유닛에 없으니 **실험대를 다시 세운
+직후에는 밖에서 못 들어온다.**
+
+**그래서 03 을 다시 밟을 때 4·5 번을 「이미 있으니 건너뛴다」로 넘기지 않는다.**
+파일이 있는 것과 그 파일이 위 본문의 내용인 것은 다르다. 두 파일을 열어 위와 한
+줄씩 대조하거나, 갈린 두 자리만 세어 본다.
+
+```bash
+grep -c 'chain forward' /etc/nftables.d/lab-edge-dnat.nft
+grep -c ExecStartPost /etc/systemd/system/lab-edge-dnat.service
+```
+
+`0` 과 `1` 이 나와야 맞다. 반대로 나오면 고치기 전 판이 깔려 있는 것이고, 다시
+써서 `sudo systemctl daemon-reload && sudo systemctl restart lab-edge-dnat.service`
+로 올린다.
+
+**그런데 고쳤는지는 이번에 확인하지 못했다**(unknown). 이 호스트의 `sudo` 는
+비밀번호를 묻고 이번 작업에는 그 비밀번호가 없었다. 그래서 `nft list table ip
+lab_edge` 도 `guest_input` 체인 조회도 못 돌렸고, 두 파일을 다시 배포하지도
+않았다. 위 표는 **파일 내용과 타임스탬프만으로** 적은 것이고, `reject` 줄의
+카운터가 실제로 올라갔는지는 안 봤다.
+
 ## 190. 단계 04 — Let's Encrypt 와 인증서 갱신
 
 **어디서 치는가** — 이 단계도 셸이 갈린다. 1~3·5 번은 전부 `[kc-lab-edge]` 에서
@@ -10278,13 +10444,29 @@ DNS 연동도 없어 관리할 것이 적다. 감수한 비용은 Cloudflare API
 **확인 ① 이 도메인이 무엇으로 풀리는가**
 
 ```bash
-dig +short auth.hyeonworks.com
+getent hosts auth.hyeonworks.com
 ```
 
 **실측**(observed)
 
 ```
-100.83.212.4
+100.83.212.4    auth.hyeonworks.com
+```
+
+**★ 여기에 `dig` 를 바로 쓰지 않는다.** 처음에는 `dig +short auth.hyeonworks.com`
+이라고 적었는데 **엣지 게스트에 `dig` 가 없다.** 2026-09-17 에 cloud-init 으로
+갓 만든 `kc-lab-edge` 에서 쳐서 확인했다(observed).
+
+```
+dig: command not found
+```
+
+cloud-init 이 까는 것은 `curl` 과 `nftables` 뿐이라 `dnsutils` 가 안 들어간다.
+`getent hosts` 는 `libc` 가 주는 것이라 어디서나 있고, 주소와 이름을 한 줄로 낸다.
+`dig` 의 형태가 꼭 필요하면 먼저 깐다 — 둘 다 같은 `100.83.212.4` 를 냈다(observed).
+
+```bash
+sudo apt install -y dnsutils && dig +short auth.hyeonworks.com
 ```
 
 **어디를 봐야 하는가** — 주소 한 줄. 그 주소가 공개 인터넷 대역인가,
@@ -10299,9 +10481,14 @@ dig +short auth.hyeonworks.com
 **확인 ② nginx 판 번호는 몇인가**
 
 ```bash
-nginx -v
+sudo nginx -v
 ```
 
+**★ `sudo` 가 붙는 까닭은 §189 확인 ① 과 같다.** 실행 파일이 `/usr/sbin/nginx`
+인데 데비안 일반 사용자 `PATH` 에 그 디렉터리가 없다. `sudo` 없이 치면
+`nginx: command not found` 다 — 안 깔린 것처럼 보이지만 아니다(2026-09-17,
+observed).
+
 **실측**(observed) — 같은 설정인데 배포판에서 갈린다.
 
 ```
@@ -10899,7 +11086,7 @@ timedatectl show -p NTP -p NTPSynchronized
 
 | 증상 | 원인 | 확인 |
 |---|---|---|
-| certbot 검증 실패 | DNS 가 이 호스트를 안 가리킴 · 80 이 막힘 | `dig +short auth.hyeonworks.com` · 밖에서 `curl -I http://auth.hyeonworks.com` |
+| certbot 검증 실패 | DNS 가 이 호스트를 안 가리킴 · 80 이 막힘 | `getent hosts auth.hyeonworks.com` · 밖에서 `curl -I http://auth.hyeonworks.com` |
 | 체인 단계가 1개 | `cert.pem` 을 씀 | 위 확인 ② |
 | 갱신은 됐는데 옛 인증서가 나감 | **deploy 훅 없음** | 워커 PID · `sudo ls /etc/letsencrypt/renewal-hooks/deploy/` |
 | 훅이 실패한 것처럼 보임 | stderr 경고를 error 로 표시 | 문구 말고 **워커 PID** |
@@ -10966,11 +11153,19 @@ timedatectl show -p NTP -p NTPSynchronized
 | PostgreSQL | Deployment `postgres` — ReplicaSet `postgres-7b474b88c8` |
 | Service | `keycloak` → Endpoints `10.42.0.67:8080,10.42.1.155:8080` |
 | Secret | `keycloak-lab-secrets` — `KC_BOOTSTRAP_ADMIN_PASSWORD` 19 bytes · `POSTGRES_PASSWORD` 22 bytes |
-| PVC | StorageClass `local-path`, 이름 끝에 파드 번호가 붙는다 |
+| PVC | `postgres-data` 하나. StorageClass `local-path` — **파드 번호가 붙지 않는다**(아래) |
 | Ingress | HOSTS 가 `auth.hyeonworks.com` |
 | 클러스터링 | JGroups — 디스커버리 테이블 `jgroups_ping`, 메시지 포트 7800 |
 | 관리 포트 | `9000` — `/metrics` 가 거기 있다 |
 
+**★ 이미지 태그는 이제 안다.** 2026-09-17 에 `keycloak-pattern` @ `9465582b` 의
+`deploy/lab/k8s/keycloak-cluster.yaml` 을 열어 읽었다(observed).
+
+```
+image: postgres:16-alpine
+image: quay.io/keycloak/keycloak:26.7.0
+```
+
 **판 번호는 여기 없다.** 가이드 05 는 Keycloak 과 PostgreSQL 의 이미지 태그를 적지
 않았고 `keycloak-cluster.yaml` 원문은 `source/` 에 반입되지 않았다. 이 두 판 번호는
 이 문서에서 대조하지 못한다(unknown). 가이드 안에 태그가 찍힌 이미지는 아래 임시
@@ -11012,8 +11207,20 @@ ls deploy/lab/k8s/
 curl -s -o /dev/null -w '%{http_code} tls=%{ssl_verify_result}\n' https://auth.hyeonworks.com/
 ```
 
-**어디를 봐야 하는가** — 04 에서 잰 `404 tls=0` 이 그대로인가. `tls=0` 이 아니면
-05 를 시작할 때가 아니라 04 로 돌아갈 때다.
+**어디를 봐야 하는가** — 04 에서 잰 `404 tls=0` 이 그대로인가. **앞의 코드를 같이
+본다.**
+
+**★ `tls=0` 만 보면 안 된다.** 연결이 **아예 안 됐을 때도** `tls=0` 이 나온다 —
+`%{ssl_verify_result}` 는 TLS 검증까지 갔을 때만 뜻이 있고 못 갔으면 초기값 `0` 이
+그대로 찍힌다. 2026-09-17 에 04 를 건너뛴 상태에서 재 보니 이렇게 나왔다(observed).
+
+```
+000 tls=0
+```
+
+`000` 은 응답이 없었다는 뜻이다. **판정은 코드가 `404` 인 것과 `tls=0` 이 같이
+나오는 것으로 한다.** `000 tls=0` 이면 04 가 아직 안 됐거나 밖에서 들어오는 길이
+막힌 것이라 05 를 시작할 때가 아니다.
 
 **이 결과가 의미하는 것** — 가이드 04 가 이 값 옆에 한 줄을 적어 두었다 —
 「앞의 `404` 는 05 이후에 `200` 으로 바뀐다.」 지금 재 두면 아래 5번의 `200` 이
@@ -11047,9 +11254,21 @@ kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s
 partitioned roll out complete: 2 new pods have been updated...
 ```
 
-**어디를 봐야 하는가** — 이 명령은 **끝날 때까지 아무것도 안 찍고 멈춰 있다.** 그
-침묵이 정상이다. 마지막에 나오는 한 줄에서 `complete` 라는 낱말과 파드 개수 `2` 를
-본다. 300초를 다 쓰고 타임아웃으로 끝나면 그것도 답이다 — 「안 떴다」가 확정된 것이니
+**어디를 봐야 하는가** — 마지막에 나오는 한 줄에서 `complete` 라는 낱말과 파드 개수
+`2` 를 본다. 그 줄이 나올 때까지 명령이 안 끝나고 멈춰 있는 것이 정상이다.
+
+**★ 다만 아무것도 안 찍고 멈춰 있지는 않다.** 처음에는 「끝날 때까지 아무것도 안
+찍는다」고 적었는데, 2026-09-17 에 갓 세운 클러스터에서 재 보니 기다리는 동안 줄이
+먼저 나왔다(observed).
+
+```
+Waiting for 2 pods to be ready...
+Waiting for 1 pods to be ready...
+partitioned roll out complete: 2 new pods have been updated...
+```
+
+`Waiting for …` 줄은 진행 상황이지 오류가 아니다. 숫자가 줄어들수록 파드가 하나씩
+Ready 가 된다. 300초를 다 쓰고 타임아웃으로 끝나면 그것도 답이다 — 「안 떴다」가 확정된 것이니
 아래 「막히면」으로 간다.
 
 **이 결과가 의미하는 것** — `complete` 면 두 파드가 다 Ready 가 됐다는 뜻이라 2번의
@@ -11326,8 +11545,24 @@ kubectl -n keycloak-lab get pvc
 ```
 
 **어디를 봐야 하는가** — STATUS 칸(`Bound`/`Pending`)과 VOLUME 칸(비어 있는지),
-그리고 STORAGECLASS 칸이 `local-path` 인가. StatefulSet 이면 PVC 이름 끝에 파드
-번호가 붙어 있어(`...-keycloak-0`) 어느 파드 것인지 바로 보인다.
+그리고 STORAGECLASS 칸이 `local-path` 인가.
+
+**★ 이 실험대에는 파드 번호가 붙은 PVC 가 없다.** 처음에는 「StatefulSet 이면 PVC
+이름 끝에 파드 번호가 붙어 있어 어느 파드 것인지 바로 보인다」고 적었는데, 그것은
+`volumeClaimTemplates` 를 쓰는 StatefulSet 의 이야기이고 **이 매니페스트의
+`keycloak` StatefulSet 에는 그 칸이 없다.** PVC 는 PostgreSQL 이 쓰는
+`postgres-data` 하나뿐이고 그것도 StatefulSet 이 아니라 별도 문서로 선언되어
+Deployment 가 `claimName` 으로 가리킨다. 2026-09-17 에 매니페스트와 클러스터
+양쪽에서 확인했다(observed).
+
+```
+NAME            STATUS   VOLUME                                     CAPACITY   STORAGECLASS
+postgres-data   Bound    pvc-fe269834-3dd1-4b1f-82f6-a53413310a30   5Gi        local-path
+```
+
+그래서 **Keycloak 파드는 볼륨을 안 갖는다.** 세션이 어디 사는지를 묻는 이 실험대의
+질문에서 그것이 중요하다 — 파드가 죽으면 그 안의 것은 사라지고
+`postgres-data` 만 남는다.
 
 **이 결과가 의미하는 것** — `Bound` 면 볼륨이 붙었다. `Pending` 이면 StorageClass 가
 없거나 노드에 자리가 없다. **`local-path` 는 파드가 스케줄될 때까지
@@ -11364,6 +11599,17 @@ ISPN000094: Received new cluster view for channel ISPN:
 **이름 목록**, 그리고 `|1` 이 **뷰 번호**(멤버가 들고 날 때마다 올라간다).
 `tail -1` 을 붙였으므로 지금 보고 있는 것은 **가장 최근 뷰** 하나다.
 
+**★ 이름 뒤에 `(v=…)` 가 붙어 나오기도 한다.** 2026-09-17 에 새로 세운 클러스터에서
+같은 줄을 뽑아 보니 이랬다(observed).
+
+```
+[keycloak-1-3159(v=16.0.12)|1] (2) [keycloak-1-3159(v=16.0.12), keycloak-0-13057(v=16.0.12)]
+```
+
+`(v=16.0.12)` 는 JGroups 가 붙인 판 번호이고, 볼 것은 그대로 `(2)` 와 이름 목록과
+`|1` 이다. **맨 앞의 이름이 `keycloak-0` 이 아니어도 정상이다** — 맨 앞에는 코디네이터가 오고
+먼저 뜬 쪽이 그 일을 맡는다. 이 판에서는 `keycloak-1` 이었다.
+
 **이 결과가 의미하는 것** — `(2)` 면 이 노드는 상대를 봤다. `(1)` 이면 혼자 있다고
 알고 있다. 뷰 번호가 계속 오르고 있으면 멤버가 붙었다 떨어지기를 반복하는 중이라,
 「지금 2 다」라는 스냅숏보다 그 사실이 더 중요하다. **이 줄은 과거형이다** — 지금
@@ -11466,6 +11712,26 @@ Service 뒤에 파드가 있는지(2-4), 파드가 Ready 인지(2-2) 순서다.
 curl -I https://auth.hyeonworks.com/realms/master
 ```
 
+**★ 이 `200` 은 04 를 끝냈을 때의 값이다.** 04 를 건너뛰고 05 만 했다면 443 을 듣는
+것이 없으므로 여기는 `000` 이다. 2026-09-17 에 그 상태에서 재 보니 이렇게
+나왔다(observed).
+
+```
+curl: (7) Failed to connect to auth.hyeonworks.com:443 after 2 ms: Could not connect to server
+```
+
+**그때도 05 가 세운 것까지는 잴 수 있다.** TLS 를 빼고 `Host` 헤더를 실어 80 으로
+치면 nginx → Traefik → Ingress → Service → 파드가 이어졌는지가 그대로 나온다. 둘 다
+`200` 이었다(observed).
+
+```bash
+curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: auth.hyeonworks.com' http://192.168.122.10/realms/master
+curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: auth.hyeonworks.com' http://192.168.122.11/realms/master
+```
+
+앞엣것은 엣지 nginx 를 지나고 뒤엣것은 Traefik 에 바로 친다. 둘이 같으면 남은 것은
+TLS 뿐이다.
+
 **확인 ⑤ 관리 콘솔에 로그인된다**
 
 브라우저로 `https://auth.hyeonworks.com/admin` 에 들어가 관리자로 로그인한다.
@@ -11478,7 +11744,7 @@ curl -I https://auth.hyeonworks.com/realms/master
 |---|---|---|
 | 롤아웃 | `kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s` | `complete` · 파드 `2` |
 | Service 뒤 | `kubectl -n keycloak-lab describe svc keycloak \| grep -i endpoints` | 주소 두 개 |
-| 클러스터 | `… query=vendor_cluster_size` | 원소 둘 · 값 둘 다 2 |
+| 클러스터 | `… query=vendor_cluster_size` | 원소 둘 · 값 둘 다 2 — **`health` 가 `up` 이 된 뒤에 잰다** |
 | 밖에서 | `curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/master` | `200` |
 
 **근거를 재려면 (선택)** — 세션이 실제로 어디 저장되는지는 DB 를 직접 본다.
@@ -11573,9 +11839,17 @@ kubectl -n keycloak-lab exec -it keycloak-0 -- sh
 - (observed) 디스커버리 테이블에는 둘 다 있는데 메시지가 안 가는 상태를 실제로 겪었다
 - (external) `kubectl get endpoints` 의 v1.33 deprecation 은 쿠버네티스 쪽 규격이고
   이 실험대가 잰 값이 아니다
-- (unknown) `keycloak-cluster.yaml` 원문은 `source/` 에 없다. **Keycloak 과
-  PostgreSQL 의 이미지 태그**, 파드 자원 한도, 프로브 설정, `persistent-user-sessions`
-  설정값은 여기서 대조하지 못했다
+- (observed) 2026-09-17 에 이 절차를 갓 세운 클러스터에서 처음부터 다시 밟았다.
+  같은 값이 다시 나온 것 — `postgres-7b474b88c8` 이라는 ReplicaSet 해시, Secret 의
+  19·22 bytes 와 주입된 길이 19·복호 길이 22, Endpoints 두 개와 `ready` 두 줄,
+  `jgroups_ping` 2 행, 임시 파드가 읽은 `vendor_cluster_size … 2.0`, Keycloak
+  이미지에 `curl` 이 없다는 것과 exit code 127, `kubectl get endpoints` 의 deprecation
+  경고. **파드 IP 와 Infinispan 접미사만 달랐다** — 그것들은 매번 새로 붙는다
+- (observed) `keycloak-cluster.yaml` 원문을 `keycloak-pattern` @ `9465582b` 에서
+  읽었다. 이미지 태그는 `postgres:16-alpine` 과 `quay.io/keycloak/keycloak:26.7.0`
+  이다
+- (unknown) 파드 자원 한도, 프로브 설정, `persistent-user-sessions` 설정값은 아직
+  이 문서로 옮기지 않았다
 - (unknown) `get all`·`get deploy`·`get pvc`·`describe pvc`·`jgroups_ping` 조회·
   `get events`·`describe pod`·`logs` 의 출력은 가이드가 봐야 할 줄만 적었고 값이 남아
   있지 않다
@@ -11731,6 +12005,19 @@ kubectl -n observability exec deploy/prometheus -- \
 준다(연결 거부·타임아웃·404). 확인 ③ 에서 값이 한 노드만 나오는 증상의 원인이 대개
 여기 있고, 그때 **클러스터가 아니라 스크레이프가 문제다.**
 
+**★ `down` 말고 `unknown` 도 있다.** 스택을 막 올린 직후에는 `health` 가 `unknown`
+이고 `lastError` 는 빈 문자열이다 — 실패한 것이 아니라 **아직 한 번도 안 긁은**
+것이다. 2026-09-17 에 `rollout status` 직후에 잡힌 모습이다(observed).
+
+```
+"job":"keycloak"
+"lastError":""
+"health":"unknown"
+```
+
+한 주기 뒤에 같은 줄이 `"health":"up"` 으로 바뀌었다. `unknown` 을 보고 권한이나
+네트워크를 뒤지기 전에 한 번 더 친다.
+
 **확인 ③ 클러스터 상태 — 두 노드가 각각 몇 명을 보고 있는가**
 
 ```bash
@@ -11746,9 +12033,40 @@ keycloak-0 → 2
 ```
 
 **어디를 봐야 하는가** — 응답은 **줄바꿈 없는 JSON 한 줄**이다. `data.result` 배열의
-원소가 **몇 개인가**(보고하는 노드 수), 각 원소에서 두 군데만 읽는다 — `"metric"`
-안의 `node` 라벨과 `"value"` 배열의 **둘째 원소**(따옴표에 싸인 값). `jq` 가 없으므로
-눈으로 읽는다.
+원소가 **몇 개인가**(보고하는 노드 수), 각 원소에서 두 군데만 읽는다 — 어느 Keycloak
+파드가 보고한 것인지와 `"value"` 배열의 **둘째 원소**(따옴표에 싸인 값). `jq` 가
+없으므로 눈으로 읽는다.
+
+**★ 어느 파드인지는 `node` 라벨이 아니라 `pod` 라벨이 말한다.** 처음에는 「`node`
+라벨을 읽는다」고 적었는데, Prometheus 를 거쳐 나온 응답에서 `node` 는 **쿠버네티스
+노드 이름**(`kc-lab-1`)이다. Keycloak 이 자기 지표에 붙인 `node` 는 스크레이프할 때
+이름이 겹쳐 `exported_node` 로 밀린다. 2026-09-17 에 원소 하나를 그대로 옮기면
+이렇다(observed).
+
+```
+"metric":{"__name__":"vendor_cluster_size","cache_manager":"keycloak",
+ "exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak",
+ "node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620021.097,"2"]
+```
+
+세 라벨이 각각 다른 것을 말한다 — `pod` 가 Keycloak 파드(`keycloak-1`),
+`exported_node` 가 Infinispan 멤버 식별자(`keycloak-1-3159`), `node` 가 그 파드가 떠
+있는 쿠버네티스 노드(`kc-lab-1`)다. 앞의 확인에서 본 `ISPN000094` 의 이름과 견줄
+것은 `exported_node` 이고, 어느 노드를 끊었을 때 무엇이 바뀌는지를 볼 때는 `node` 다.
+
+**★ 스택을 막 올린 직후에는 원소가 모자란다.** 1번의 `rollout status` 가 성공한
+직후에 이 질의를 치면 Keycloak 대상이 아직 한 번도 안 긁혀서 원소가 하나뿐이거나
+아예 없다. 2026-09-17 에 38초 시점과 약 2분 시점에 같은 질의를 쳐서
+확인했다(observed).
+
+| 언제 | 확인 ② 의 keycloak `health` | 이 질의의 원소 |
+|---|---|---|
+| `rollout status` 직후(38초) | `"health":"unknown"` | 1 개 |
+| 약 2분 뒤 | `"health":"up"` | 2 개 · 둘 다 `2` |
+
+**`unknown` 은 실패가 아니라 아직 안 긁었다는 뜻이다.** 원소가 모자라면 분단을
+의심하기 전에 확인 ② 의 `health` 를 먼저 보고, `unknown` 이면 한 주기 기다렸다 다시
+친다.
 
 **이 결과가 의미하는 것** — **두 노드가 각각 자기가 아는 멤버 수를 보고한다.** 둘 다
 2 면 클러스터가 온전하다. 분단되면 한쪽은 2, 다른 쪽은 1 이 된다 — **한 노드만 보면
@@ -11838,6 +12156,11 @@ kubectl -n observability port-forward svc/grafana 3000:3000
 
 **이 절차가 성립하는 범위**
 
+- (observed) 2026-09-17 에 이 절차를 갓 세운 클러스터에서 다시 밟았다. 파드 네 줄과
+  job 네 개가 그대로 나왔고 ReplicaSet 해시 `845b5678cf`·`6774f94f7c` 까지 같았다.
+  달랐던 것 — `rollout status` 직후에는 Grafana 가 `0/1` 이었고 Keycloak 대상의
+  `health` 가 `unknown` 이라 `vendor_cluster_size` 의 원소가 하나뿐이었다. 약 2분
+  뒤에 둘 다 `2` 가 됐다
 - (observed) 파드 네 줄과 job 네 개, `vendor_cluster_size` 2·2, 503 중에도 `up` 이
   1 이었던 것
 - (observed) Redis·BFF·PostgreSQL 이 스크레이프 대상에 없다는 것. 「안 찍은 것」이
@@ -16770,6 +17093,16 @@ kubectl auth can-i get nodes/proxy --as=system:serviceaccount:observability:prom
 kubectl describe clusterrole prometheus
 ```
 
+**★ 첫 명령은 답 앞에 경고 한 줄을 같이 낸다**(2026-09-17, observed). 실패가 아니라
+`nodes` 가 네임스페이스에 속한 자원이 아니라는 안내이고, 볼 것은 그 아래의 `yes`
+또는 `no` 다.
+
+```
+Warning: resource 'nodes' is not namespace scoped
+
+yes
+```
+
 ## 312. 배치 제어 — nodeSelector · 라벨 · taint
 
 ```yaml
@@ -17131,6 +17464,23 @@ virsh setmem    kc-lab-1 5120M --config
 `setmaxmem --live`는 대개 거부된다 — 게스트가 부팅 시 메모리 맵을 정하기
 때문이다. **상한을 바꾸려면 게스트를 껐다 켜야 한다.**
 
+**★ 바꾼 것이 들어갔는지는 `dominfo` 로 판정하지 않는다.** `--config` 는 다음 기동부터
+쓸 설정만 바꾸는데 `dominfo` 는 **지금 돌고 있는 값**을 보여 준다. 그래서 명령이 제대로
+먹어도 `dominfo` 의 숫자는 안 바뀌고, 그 화면을 「안 먹었다」로 읽게 된다. 2026-09-17 에
+같은 순간을 두 명령으로 나란히 찍었다(observed).
+
+```
+virsh dominfo kc-lab-1 | grep -i memory
+  Max memory:     5242880 KiB          ← 돌고 있는 값
+
+virsh dumpxml kc-lab-1 --inactive | grep -E '<memory|<currentMemory'
+  <memory unit='KiB'>4194304</memory>  ← 방금 바꾼 설정
+  <currentMemory unit='KiB'>4194304</currentMemory>
+```
+
+같은 도메인, 같은 시각, 다른 숫자다. **바꾼 것이 들어갔는지는 `--inactive` 가 답하고,
+`dominfo` 는 지금 무엇으로 돌고 있는지를 답한다.**
+
 ```bash
 virsh dominfo kc-lab-1 | grep -i memory
 ssh kc-lab-1 free -m        # 게스트가 실제로 인식한 값
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/01-host-before-teardown.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/01-host-before-teardown.txt
new file mode 100644
index 0000000..213519e
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/01-host-before-teardown.txt
@@ -0,0 +1,99 @@
+### virsh list --all
+ Id   Name          State
+-----------------------------
+ 9    kc-lab-edge   running
+ 10   kc-lab-1      running
+ 12   kc-lab-2      running
+
+
+### virsh vol-list default
+ Name                   Path
+----------------------------------------------------------------------
+ base.qcow2             /var/lib/libvirt/images/base.qcow2
+ kc-lab-1.qcow2         /var/lib/libvirt/images/kc-lab-1.qcow2
+ kc-lab-2.qcow2         /var/lib/libvirt/images/kc-lab-2.qcow2
+ kc-lab-edge.qcow2      /var/lib/libvirt/images/kc-lab-edge.qcow2
+ seed-kc-lab-1.iso      /var/lib/libvirt/images/seed-kc-lab-1.iso
+ seed-kc-lab-2.iso      /var/lib/libvirt/images/seed-kc-lab-2.iso
+ seed-kc-lab-edge.iso   /var/lib/libvirt/images/seed-kc-lab-edge.iso
+
+
+### virsh net-dumpxml default
+<network>
+  <name>default</name>
+  <uuid>a14c3b01-2c56-4181-8310-e6cba888e2a8</uuid>
+  <forward mode='nat'>
+    <nat>
+      <port start='1024' end='65535'/>
+    </nat>
+  </forward>
+  <bridge name='virbr0' stp='on' delay='0'/>
+  <mac address='52:54:00:6c:a6:a8'/>
+  <ip address='192.168.122.1' netmask='255.255.255.0'>
+    <dhcp>
+      <range start='192.168.122.2' end='192.168.122.254'/>
+      <host mac='52:54:00:aa:bb:11' name='kc-lab-1' ip='192.168.122.11'/>
+      <host mac='52:54:00:aa:bb:12' name='kc-lab-2' ip='192.168.122.12'/>
+      <host mac='52:54:00:aa:bb:10' name='kc-lab-edge' ip='192.168.122.10'/>
+    </dhcp>
+  </ip>
+</network>
+
+
+### df -h /
+Filesystem      Size  Used Avail Use% Mounted on
+/dev/nvme0n1p3  226G   16G  199G   8% /
+
+### free -m
+               total        used        free      shared  buff/cache   available
+Mem:           11648       10444         191           4        1345        1204
+Swap:           8191         959        7232
+
+### virsh dominfo (셋)
+-- kc-lab-1
+Name:           kc-lab-1
+State:          running
+CPU(s):         2
+Max memory:     5242880 KiB
+Used memory:    5242880 KiB
+Persistent:     yes
+Autostart:      disable
+Autostart Once: disable
+-- kc-lab-2
+Name:           kc-lab-2
+State:          running
+CPU(s):         2
+Max memory:     4194304 KiB
+Used memory:    4194304 KiB
+Persistent:     yes
+Autostart:      disable
+Autostart Once: disable
+-- kc-lab-edge
+Name:           kc-lab-edge
+State:          running
+CPU(s):         1
+Max memory:     1048576 KiB
+Used memory:    1048576 KiB
+Persistent:     yes
+Autostart:      disable
+Autostart Once: disable
+
+### virsh domblklist (셋)
+-- kc-lab-1
+ Target   Source
+-----------------------------------------------------
+ vda      /var/lib/libvirt/images/kc-lab-1.qcow2
+ vdb      /var/lib/libvirt/images/seed-kc-lab-1.iso
+
+-- kc-lab-2
+ Target   Source
+-----------------------------------------------------
+ vda      /var/lib/libvirt/images/kc-lab-2.qcow2
+ vdb      /var/lib/libvirt/images/seed-kc-lab-2.iso
+
+-- kc-lab-edge
+ Target   Source
+--------------------------------------------------------
+ vda      /var/lib/libvirt/images/kc-lab-edge.qcow2
+ vdb      /var/lib/libvirt/images/seed-kc-lab-edge.iso
+
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/02-teardown-step0.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/02-teardown-step0.txt
new file mode 100644
index 0000000..697caa4
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/02-teardown-step0.txt
@@ -0,0 +1,27 @@
+ Id   Name          State
+-----------------------------
+ 9    kc-lab-edge   running
+ 10   kc-lab-1      running
+ 12   kc-lab-2      running
+
+ Name                   Path
+----------------------------------------------------------------------
+ base.qcow2             /var/lib/libvirt/images/base.qcow2
+ kc-lab-1.qcow2         /var/lib/libvirt/images/kc-lab-1.qcow2
+ kc-lab-2.qcow2         /var/lib/libvirt/images/kc-lab-2.qcow2
+ kc-lab-edge.qcow2      /var/lib/libvirt/images/kc-lab-edge.qcow2
+ seed-kc-lab-1.iso      /var/lib/libvirt/images/seed-kc-lab-1.iso
+ seed-kc-lab-2.iso      /var/lib/libvirt/images/seed-kc-lab-2.iso
+ seed-kc-lab-edge.iso   /var/lib/libvirt/images/seed-kc-lab-edge.iso
+
+    <dhcp>
+      <range start='192.168.122.2' end='192.168.122.254'/>
+      <host mac='52:54:00:aa:bb:11' name='kc-lab-1' ip='192.168.122.11'/>
+      <host mac='52:54:00:aa:bb:12' name='kc-lab-2' ip='192.168.122.12'/>
+      <host mac='52:54:00:aa:bb:10' name='kc-lab-edge' ip='192.168.122.10'/>
+    </dhcp>
+  </ip>
+</network>
+
+Filesystem      Size  Used Avail Use% Mounted on
+/dev/nvme0n1p3  226G   16G  199G   8% /
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/03-teardown-step1.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/03-teardown-step1.txt
new file mode 100644
index 0000000..e70e67b
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/03-teardown-step1.txt
@@ -0,0 +1,18 @@
+Domain 'kc-lab-edge' destroyed
+
+Domain 'kc-lab-edge' has been undefined
+Volume 'vda'(/var/lib/libvirt/images/kc-lab-edge.qcow2) removed.
+Volume 'vdb'(/var/lib/libvirt/images/seed-kc-lab-edge.iso) removed.
+
+Domain 'kc-lab-2' destroyed
+
+Domain 'kc-lab-2' has been undefined
+Volume 'vda'(/var/lib/libvirt/images/kc-lab-2.qcow2) removed.
+Volume 'vdb'(/var/lib/libvirt/images/seed-kc-lab-2.iso) removed.
+
+Domain 'kc-lab-1' destroyed
+
+Domain 'kc-lab-1' has been undefined
+Volume 'vda'(/var/lib/libvirt/images/kc-lab-1.qcow2) removed.
+Volume 'vdb'(/var/lib/libvirt/images/seed-kc-lab-1.iso) removed.
+
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/04-teardown-step2.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/04-teardown-step2.txt
new file mode 100644
index 0000000..1c30c4f
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/04-teardown-step2.txt
@@ -0,0 +1,5 @@
+Updated network default persistent config and live state
+Updated network default persistent config and live state
+Updated network default persistent config and live state
+--- 확인 ---
+      <range start='192.168.122.2' end='192.168.122.254'/>
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/05-teardown-verify.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/05-teardown-verify.txt
new file mode 100644
index 0000000..a0f04ca
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/05-teardown-verify.txt
@@ -0,0 +1,16 @@
+ Id   Name   State
+--------------------
+
+ Name         Path
+--------------------------------------------------
+ base.qcow2   /var/lib/libvirt/images/base.qcow2
+
+    <dhcp>
+      <range start='192.168.122.2' end='192.168.122.254'/>
+    </dhcp>
+  </ip>
+</network>
+
+Filesystem      Size  Used Avail Use% Mounted on
+/dev/nvme0n1p3  226G  7.9G  206G   4% /
+virbr0           DOWN           192.168.122.1/24 
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/06-build-seed-as-documented.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/06-build-seed-as-documented.txt
new file mode 100644
index 0000000..9dc3473
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/06-build-seed-as-documented.txt
@@ -0,0 +1,4 @@
+xorriso 1.5.8.pl02 : RockRidge filesystem manipulator, libburnia project.
+
+xorriso : FAILURE : Cannot determine attributes of source file '/home/donghyeon/workspace/cloud/meta-kc-lab-1' : No such file or directory
+종료 코드: 5
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/07-build-seed-fixed.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/07-build-seed-fixed.txt
new file mode 100644
index 0000000..239d219
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/07-build-seed-fixed.txt
@@ -0,0 +1,12 @@
+xorriso 1.5.8.pl02 : RockRidge filesystem manipulator, libburnia project.
+
+kc-lab-1 → 종료 0
+xorriso 1.5.8.pl02 : RockRidge filesystem manipulator, libburnia project.
+
+kc-lab-2 → 종료 0
+xorriso 1.5.8.pl02 : RockRidge filesystem manipulator, libburnia project.
+
+kc-lab-edge → 종료 0
+-rw-r--r-- 1 donghyeon donghyeon 378880 Sep 17 13:23 seed-kc-lab-1.iso
+-rw-r--r-- 1 donghyeon donghyeon 378880 Sep 17 13:23 seed-kc-lab-2.iso
+-rw-r--r-- 1 donghyeon donghyeon 378880 Sep 17 13:23 seed-kc-lab-edge.iso
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/08-build-seed-upload.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/08-build-seed-upload.txt
new file mode 100644
index 0000000..c07bff8
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/08-build-seed-upload.txt
@@ -0,0 +1,17 @@
+Vol seed-kc-lab-1.iso created
+
+
+Vol seed-kc-lab-2.iso created
+
+
+Vol seed-kc-lab-edge.iso created
+
+
+--- 확인 ---
+ Name                   Path
+----------------------------------------------------------------------
+ base.qcow2             /var/lib/libvirt/images/base.qcow2
+ seed-kc-lab-1.iso      /var/lib/libvirt/images/seed-kc-lab-1.iso
+ seed-kc-lab-2.iso      /var/lib/libvirt/images/seed-kc-lab-2.iso
+ seed-kc-lab-edge.iso   /var/lib/libvirt/images/seed-kc-lab-edge.iso
+
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/09-build-dhcp.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/09-build-dhcp.txt
new file mode 100644
index 0000000..d96fc47
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/09-build-dhcp.txt
@@ -0,0 +1,8 @@
+Updated network default persistent config and live state
+Updated network default persistent config and live state
+Updated network default persistent config and live state
+--- 확인 ---
+      <range start='192.168.122.2' end='192.168.122.254'/>
+      <host mac='52:54:00:aa:bb:10' name='kc-lab-edge' ip='192.168.122.10'/>
+      <host mac='52:54:00:aa:bb:11' name='kc-lab-1' ip='192.168.122.11'/>
+      <host mac='52:54:00:aa:bb:12' name='kc-lab-2' ip='192.168.122.12'/>
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/10-build-virt-install-1.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/10-build-virt-install-1.txt
new file mode 100644
index 0000000..b969624
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/10-build-virt-install-1.txt
@@ -0,0 +1,6 @@
+
+Starting install...
+
Allocating 'kc-lab-1.qcow2'                                 |  20 GB  00:00     
+
Creating domain...                                          |         00:00     
+Domain creation completed.
+kc-lab-1 종료 0
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/11-build-virt-install-2-edge.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/11-build-virt-install-2-edge.txt
new file mode 100644
index 0000000..608dafd
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/11-build-virt-install-2-edge.txt
@@ -0,0 +1,12 @@
+
+Starting install...
+
Allocating 'kc-lab-2.qcow2'                                 |  20 GB  00:00     
+
Creating domain...                                          |         00:00     
+Domain creation completed.
+kc-lab-2 종료 0
+
+Starting install...
+
Allocating 'kc-lab-edge.qcow2'                              |  10 GB  00:00     
+
Creating domain...                                          |         00:00     
+Domain creation completed.
+kc-lab-edge 종료 0
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/12-build-guests-up.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/12-build-guests-up.txt
new file mode 100644
index 0000000..8944b46
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/12-build-guests-up.txt
@@ -0,0 +1,15 @@
+=== virsh list --all ===
+ Id   Name          State
+-----------------------------
+ 13   kc-lab-1      running
+ 14   kc-lab-2      running
+ 15   kc-lab-edge   running
+
+
+=== DHCP 리스 ===
+ Expiry Time           MAC address         Protocol   IP address          Hostname      Client ID or DUID
+--------------------------------------------------------------------------------------------------------------------------------------------------
+ 2026-09-17 14:24:12   52:54:00:aa:bb:10   ipv4       192.168.122.10/24   kc-lab-edge   ff:56:50:4d:98:00:02:00:00:ab:11:d7:90:6d:17:fc:bf:ab:64
+ 2026-09-17 14:24:06   52:54:00:aa:bb:11   ipv4       192.168.122.11/24   kc-lab-1      ff:56:50:4d:98:00:02:00:00:ab:11:96:13:63:32:a6:4c:7b:ed
+ 2026-09-17 14:24:11   52:54:00:aa:bb:12   ipv4       192.168.122.12/24   kc-lab-2      ff:56:50:4d:98:00:02:00:00:ab:11:ef:d1:ff:8b:ff:65:e4:56
+
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/13-build-guest-ssh.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/13-build-guest-ssh.txt
new file mode 100644
index 0000000..34e875d
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/13-build-guest-ssh.txt
@@ -0,0 +1,24 @@
+=== kc-lab-1 ===
+kc-lab-1
+NAME     SIZE FSTYPE  LABEL  MOUNTPOINT
+vda       20G                
+├─vda1  19.9G ext4           /
+├─vda14    3M                
+└─vda15  124M vfat           /boot/efi
+vdb      370K iso9660 CIDATA 
+=== kc-lab-2 ===
+kc-lab-2
+NAME     SIZE FSTYPE  LABEL  MOUNTPOINT
+vda       20G                
+├─vda1  19.9G ext4           /
+├─vda14    3M                
+└─vda15  124M vfat           /boot/efi
+vdb      370K iso9660 CIDATA 
+=== kc-lab-edge ===
+kc-lab-edge
+NAME     SIZE FSTYPE  LABEL  MOUNTPOINT
+vda       10G                
+├─vda1   9.9G ext4           /
+├─vda14    3M                
+└─vda15  124M vfat           /boot/efi
+vdb      370K iso9660 CIDATA 
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/14-cloudinit-schema-check.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/14-cloudinit-schema-check.txt
new file mode 100644
index 0000000..b8a4465
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/14-cloudinit-schema-check.txt
@@ -0,0 +1,8 @@
+=== 게스트에서 sudo 가 되나 ===
+uid=0(root) gid=0(root) groups=0(root)
+
+=== 실제로 쓴 kc-lab-1.yaml 을 게스트의 cloud-init schema 에 건다 ===
+Error:
+Cloud config schema errors: users.0: {'name': 'donghyeon', 'groups': ['sudo'], 'shell': '/bin/bash', 'sudo': ['ALL=(ALL) NOPASSWD:ALL'], 'lock_passwd': False, 'plain_text_passwd': '<REDACTED 5자>', 'ssh_authorized_keys': ['ssh-ed25519 <REDACTED> test-server -> kc-lab', 'ssh-ed25519 <REDACTED> donghyeon@donghyeon-960XGK']} is not valid under any of the given schemasCloud config schema deprecations: 
+
+종료=1
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/15-k3s-precheck.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/15-k3s-precheck.txt
new file mode 100644
index 0000000..3ffd94b
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/15-k3s-precheck.txt
@@ -0,0 +1,19 @@
+ Id   Name          State
+-----------------------------
+ 13   kc-lab-1      running
+ 14   kc-lab-2      running
+ 15   kc-lab-edge   running
+
+@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
+@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
+@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
+IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
+Someone could be eavesdropping on you right now (man-in-the-middle attack)!
+It is also possible that a host key has just been changed.
+The fingerprint for the ED25519 key sent by the remote host is
+SHA256:4crUKIfcfmBFDkk5ARCqZ0z/m1AIuSjZ8Ys6ZMoNxBI.
+Please contact your system administrator.
+Add correct host key in /home/donghyeon/.ssh/known_hosts to get rid of this message.
+Offending ED25519 key in /home/donghyeon/.ssh/known_hosts:1
+Host key for 192.168.122.11 has changed and you have requested strict checking.
+Host key verification failed.
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/16-hostkey-defect.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/16-hostkey-defect.txt
new file mode 100644
index 0000000..69fc6f9
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/16-hostkey-defect.txt
@@ -0,0 +1,13 @@
+=== 별칭으로는 되나 ===
+kc-lab-1
+PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
+
+=== known_hosts 에 무엇이 있나 ===
+# Host 192.168.122.11 found: line 1 
+192.168.122.11 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBG+/wya7fn6K845Mh717dDobbgUbpTqyK1hi2qLyMGm
+
+=== config 에서 IP 직접 지정에 걸리는 규칙 ===
+Host kc-lab-*
+	StrictHostKeyChecking no
+	UserKnownHostsFile /dev/null
+	LogLevel ERROR
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/17-hostkey-cleared.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/17-hostkey-cleared.txt
new file mode 100644
index 0000000..bcf56ce
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/17-hostkey-cleared.txt
@@ -0,0 +1,4 @@
+옛 키 셋 제거
+Warning: Permanently added '192.168.122.11' (ED25519) to the list of known hosts.
+kc-lab-1
+PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/18-k3s-server-install.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/18-k3s-server-install.txt
new file mode 100644
index 0000000..25949c2
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/18-k3s-server-install.txt
@@ -0,0 +1,18 @@
+[INFO]  Finding release for channel stable
+[INFO]  Using v1.36.4+k3s1 as release
+[INFO]  Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.36.4%2Bk3s1/sha256sum-amd64.txt
+[INFO]  Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.36.4%2Bk3s1/k3s
+[INFO]  Verifying binary download
+[INFO]  Installing k3s to /usr/local/bin/k3s
+[INFO]  Skipping installation of SELinux RPM
+[INFO]  Creating /usr/local/bin/kubectl symlink to k3s
+[INFO]  Creating /usr/local/bin/crictl symlink to k3s
+[INFO]  Creating /usr/local/bin/ctr symlink to k3s
+[INFO]  Creating killall script /usr/local/bin/k3s-killall.sh
+[INFO]  Creating uninstall script /usr/local/bin/k3s-uninstall.sh
+[INFO]  env: Creating environment file /etc/systemd/system/k3s.service.env
+[INFO]  systemd: Creating service file /etc/systemd/system/k3s.service
+[INFO]  systemd: Enabling k3s unit
+Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service.
+[INFO]  systemd: Starting k3s
+=== 종료 0 ===
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/19-k3s-server-verify.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/19-k3s-server-verify.txt
new file mode 100644
index 0000000..0084200
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/19-k3s-server-verify.txt
@@ -0,0 +1,3 @@
+active
+NAME       STATUS   ROLES           AGE   VERSION
+kc-lab-1   Ready    control-plane   44s   v1.36.4+k3s1
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/20-kubeconfig.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/20-kubeconfig.txt
new file mode 100644
index 0000000..5874ecc
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/20-kubeconfig.txt
@@ -0,0 +1,7 @@
+=== 고치기 전 server 줄 ===
+    server: https://127.0.0.1:6443
+=== 고친 뒤 ===
+    server: https://192.168.122.11:6443
+=== kubectl get nodes ===
+NAME       STATUS   ROLES           AGE   VERSION
+kc-lab-1   Ready    control-plane   52s   v1.36.4+k3s1
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/21-k3s-token.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/21-k3s-token.txt
new file mode 100644
index 0000000..05488ab
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/21-k3s-token.txt
@@ -0,0 +1,4 @@
+109 node-token
+scp OK
+lab host 사본 지움
+109 /home/donghyeon/node-token
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/22-k3s-agent-install.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/22-k3s-agent-install.txt
new file mode 100644
index 0000000..28a9102
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/22-k3s-agent-install.txt
@@ -0,0 +1,19 @@
+[INFO]  Finding release for channel stable
+[INFO]  Using v1.36.4+k3s1 as release
+[INFO]  Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.36.4%2Bk3s1/sha256sum-amd64.txt
+[INFO]  Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.36.4%2Bk3s1/k3s
+[INFO]  Verifying binary download
+[INFO]  Installing k3s to /usr/local/bin/k3s
+[INFO]  Skipping installation of SELinux RPM
+[INFO]  Creating /usr/local/bin/kubectl symlink to k3s
+[INFO]  Creating /usr/local/bin/crictl symlink to k3s
+[INFO]  Creating /usr/local/bin/ctr symlink to k3s
+[INFO]  Creating killall script /usr/local/bin/k3s-killall.sh
+[INFO]  Creating uninstall script /usr/local/bin/k3s-agent-uninstall.sh
+[INFO]  env: Creating environment file /etc/systemd/system/k3s-agent.service.env
+[INFO]  systemd: Creating service file /etc/systemd/system/k3s-agent.service
+[INFO]  systemd: Enabling k3s-agent unit
+Created symlink /etc/systemd/system/multi-user.target.wants/k3s-agent.service → /etc/systemd/system/k3s-agent.service.
+[INFO]  systemd: Starting k3s-agent
+=== 종료 0 ===
+토큰파일 지움
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/23-k3s-cluster-verify.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/23-k3s-cluster-verify.txt
new file mode 100644
index 0000000..59ee7b0
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/23-k3s-cluster-verify.txt
@@ -0,0 +1,18 @@
+=== kubectl get nodes -o wide ===
+NAME       STATUS   ROLES           AGE    VERSION        INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION                 CONTAINER-RUNTIME
+kc-lab-1   Ready    control-plane   2m8s   v1.36.4+k3s1   192.168.122.11   <none>        Debian GNU/Linux 12 (bookworm)   6.1.0-53-cloud-amd64 (amd64)   containerd://2.3.4-k3s1.36
+kc-lab-2   Ready    <none>          52s    v1.36.4+k3s1   192.168.122.12   <none>        Debian GNU/Linux 12 (bookworm)   6.1.0-53-cloud-amd64 (amd64)   containerd://2.3.4-k3s1.36
+
+=== kube-system ===
+coredns-54996dc9b4-x8c24 Running
+helm-install-traefik-crd-v5m5f Completed
+helm-install-traefik-rjnbm Completed
+local-path-provisioner-77b9867795-j8qkb Running
+metrics-server-6dc596dfb8-4dkmg Running
+svclb-traefik-72a92206-5jpxg Running
+svclb-traefik-72a92206-lpswx Running
+traefik-59b7647586-t8fc7 Running
+
+=== StorageClass ===
+NAME                   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
+local-path (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  2m3s
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/24-edge-nginx-install.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/24-edge-nginx-install.txt
new file mode 100644
index 0000000..48cdb03
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/24-edge-nginx-install.txt
@@ -0,0 +1,26 @@
+설치 종료 0
+● nginx.service - A high performance web server and a reverse proxy server
+     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
+     Active: active (running) since Thu 2026-09-17 04:27:39 UTC; 1s ago
+       Docs: man:nginx(8)
+    Process: 1041 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
+--- ls /etc/nginx/ ---
+conf.d
+fastcgi.conf
+fastcgi_params
+koi-utf
+koi-win
+mime.types
+modules-available
+modules-enabled
+nginx.conf
+proxy_params
+scgi_params
+sites-available
+sites-enabled
+snippets
+uwsgi_params
+win-utf
+--- sites-enabled ---
+total 0
+lrwxrwxrwx 1 root root 34 Sep 17 04:27 default -> /etc/nginx/sites-available/default
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/25-edge-nginx-config.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/25-edge-nginx-config.txt
new file mode 100644
index 0000000..133dd92
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/25-edge-nginx-config.txt
@@ -0,0 +1,12 @@
+--- sites-enabled ---
+total 0
+lrwxrwxrwx 1 root root 39 Sep 17 04:27 keycloak-lab -> /etc/nginx/sites-available/keycloak-lab
+--- nginx -t ---
+nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
+nginx: configuration file /etc/nginx/nginx.conf test is successful
+reload-OK
+--- 프로세스 트리 ---
+root        1065       1  0 04:27 ?        00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
+www-data    1066    1065  0 04:27 ?        00:00:00 nginx: worker process
+donghye+    1093    1092  0 04:27 ?        00:00:00 bash -c    sudo rm /etc/nginx/sites-enabled/default   sudo cp /tmp/keycloak-lab /etc/nginx/sites-available/keycloak-lab   sudo ln -s /etc/nginx/sites-available/keycloak-lab /etc/nginx/sites-enabled/keycloak-lab   echo "--- sites-enabled ---"; ls -l /etc/nginx/sites-enabled/   echo "--- nginx -t ---"; sudo nginx -t 2>&1   sudo systemctl reload nginx && echo reload-OK   echo "--- 프로세스 트리 ---"; ps -ef | grep "[n]ginx" | head -4 
+www-data    1106    1065  0 04:27 ?        00:00:00 nginx: worker process
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/26-edge-nginx-verify.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/26-edge-nginx-verify.txt
new file mode 100644
index 0000000..ba5a851
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/26-edge-nginx-verify.txt
@@ -0,0 +1,38 @@
+=== 3-③ nginx -t (문서는 [warn] types_hash 줄이 늘 같이 나온다고 적었다) ===
+nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
+nginx: configuration file /etc/nginx/nginx.conf test is successful
+=== nginx -v ===
+bash: line 5: nginx: command not found
+=== 3-② ls -l sites-enabled ===
+total 0
+lrwxrwxrwx 1 root root 39 Sep 17 04:27 keycloak-lab -> /etc/nginx/sites-available/keycloak-lab
+=== 3-④ systemctl status nginx | head -20 ===
+● nginx.service - A high performance web server and a reverse proxy server
+     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
+     Active: active (running) since Thu 2026-09-17 04:27:39 UTC; 1min 23s ago
+       Docs: man:nginx(8)
+    Process: 1041 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
+    Process: 1042 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
+    Process: 1105 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=0/SUCCESS)
+   Main PID: 1065 (nginx)
+      Tasks: 2 (limit: 1141)
+     Memory: 1.8M
+        CPU: 12ms
+     CGroup: /system.slice/nginx.service
+             ├─1065 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
+             └─1106 "nginx: worker process"
+=== 확인 ① Traefik 직접 (기대 404) ===
+  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
+                                 Dload  Upload  Total   Spent   Left   Speed
+
  0      0   0      0   0      0      0      0                              0HTTP/1.1 404 Not Found
+Content-Type: text/plain; charset=utf-8
+X-Content-Type-Options: nosniff
+Date: Thu, 17 Sep 2026 04:29:02 GMT
+Content-Length: 19
+
+=== 두 노드 비교 ===
+404
+404
+=== 확인 ② 엣지 nginx 직접 (기대 301) ===
+404 
+
  0     19   0      0   0      0      0      0                              0
  0     19   0      0   0      0      0      0                              0
  0     19   0      0   0      0      0      0                              0
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/27-edge-doc-mismatch.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/27-edge-doc-mismatch.txt
new file mode 100644
index 0000000..b822f2e
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/27-edge-doc-mismatch.txt
@@ -0,0 +1,23 @@
+=== 엣지 응답 헤더 전체 (Server: 가 누구인가) ===
+HTTP/1.1 404 Not Found
+Server: nginx/1.22.1
+Date: Thu, 17 Sep 2026 04:29:13 GMT
+Content-Type: text/plain; charset=utf-8
+Content-Length: 19
+Connection: keep-alive
+X-Content-Type-Options: nosniff
+
+
+=== 엣지 응답 본문 ===
+404 page not found
+
+=== 문서 전제: which nginx 가 미설치 판정에 쓰인다. 설치된 지금 무엇이 나오나 ===
+which nginx  -> (exit 1)
+nginx -v     -> bash: line 3: nginx: command not found
+sudo nginx -v-> nginx version: nginx/1.22.1
+PATH         -> /usr/local/bin:/usr/bin:/bin:/usr/games
+dpkg 판       -> 
+=== nginx -t 를 세 번 더 — [warn] 이 정말 안 나오나 ===
+0
+0
+0
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/28-host-state-before-dnat.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/28-host-state-before-dnat.txt
new file mode 100644
index 0000000..1d6067f
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/28-host-state-before-dnat.txt
@@ -0,0 +1,17 @@
+=== 4번 치기 전 호스트 상태 ===
+--- tailscale0 있나 ---
+3: tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 500
+    inet 100.83.212.4/32 scope global tailscale0
+       valid_lft forever preferred_lft forever
+--- 80/443 을 듣는 프로세스 ---
+sudo: a terminal is required to read the password; either use ssh's -t option or configure an askpass helper
+sudo: a password is required
+--- 기존 lab_edge 테이블 ---
+sudo: a terminal is required to read the password; either use ssh's -t option or configure an askpass helper
+sudo: a password is required
+--- 기존 파일 ---
+-rw-r--r-- 1 root root 384 Sep 11 11:00 /etc/nftables.d/lab-edge-dnat.nft
+-rw-r--r-- 1 root root 332 Sep 11 10:52 /etc/systemd/system/lab-edge-dnat.service
+--- 유닛 상태 ---
+active
+enabled
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/29-host-dnat-files.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/29-host-dnat-files.txt
new file mode 100644
index 0000000..ae4e6d8
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/29-host-dnat-files.txt
@@ -0,0 +1,36 @@
+=== /etc/nftables.d/lab-edge-dnat.nft (실물) ===
+#!/usr/sbin/nft -f
+table ip lab_edge
+delete table ip lab_edge
+
+table ip lab_edge {
+	chain prerouting {
+		type nat hook prerouting priority dstnat; policy accept;
+		iifname "tailscale0" tcp dport {80, 443} dnat to 192.168.122.10
+	}
+
+	chain forward {
+		type filter hook forward priority filter - 10; policy accept;
+		ip daddr 192.168.122.10 tcp dport {80, 443} ct state new accept
+	}
+}
+=== /etc/systemd/system/lab-edge-dnat.service (실물) ===
+[Unit]
+Description=Lab edge DNAT (tailnet :80/:443 -> kc-lab-edge)
+After=network-online.target libvirtd.service
+Wants=network-online.target
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStart=/usr/sbin/nft -f /etc/nftables.d/lab-edge-dnat.nft
+ExecStop=/usr/sbin/nft delete table ip lab_edge
+
+[Install]
+WantedBy=multi-user.target
+
+=== 유닛 ===
+active
+enabled
+=== sudo 는 비밀번호를 요구한다 (4·5번을 그대로 칠 수 없다) ===
+sudo: a password is required
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/30-layer3-from-workstation.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/30-layer3-from-workstation.txt
new file mode 100644
index 0000000..41327d1
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/30-layer3-from-workstation.txt
@@ -0,0 +1,8 @@
+=== [워크스테이션] auth.hyeonworks.com 이 어디로 도나 ===
+100.83.212.4    auth.hyeonworks.com
+=== 확인 ③ 밖에서 도메인으로 (문서 기대: 301 https://auth.hyeonworks.com/) ===
+curl: (7) Failed to connect to auth.hyeonworks.com port 80 after 54 ms: Couldn't connect to server
+000 
+=== 같은 것을 tailnet 주소로 직접 (DNS 를 건너뛴다) ===
+curl: (7) Failed to connect to 100.83.212.4 port 80 after 2 ms: Couldn't connect to server
+000
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/31-cert-doc-precheck.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/31-cert-doc-precheck.txt
new file mode 100644
index 0000000..57121b1
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/31-cert-doc-precheck.txt
@@ -0,0 +1,29 @@
+=== 04 확인 ① dig ===
+bash: line 3: dig: command not found
+(dig 이 없다: 127)
+=== 04 확인 ② nginx -v (문서가 그대로 적은 형태) ===
+bash: line 5: nginx: command not found
+=== 같은 것을 sudo 로 ===
+nginx version: nginx/1.22.1
+=== 04 1-① certbot 설치 ===
+Created symlink /etc/systemd/system/timers.target.wants/certbot.timer → /lib/systemd/system/certbot.timer.

+Setting up python3-lxml:amd64 (4.9.2-1+b1) ...
+Setting up python3-certbot-dns-cloudflare (2.0.0-1) ...
+Processing triggers for man-db (2.11.2-2) ...
+Processing triggers for libc-bin (2.36-9+deb12u14) ...
+=== 04 1-② 문서가 적은 형태 그대로 (일반 사용자) ===
+* dns-cloudflare
+* standalone
+* webroot
+(exit 0)
+=== 같은 것을 sudo 로 ===
+* dns-cloudflare
+* standalone
+* webroot
+(exit 0)
+=== 일반 사용자로 쳤을 때 stderr 에 무엇이 나오나 ===
+
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+* dns-cloudflare
+Description: Obtain certificates using a DNS TXT record (if you are using
+Cloudflare for DNS).
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/32-cert-doc-dig-remedy.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/32-cert-doc-dig-remedy.txt
new file mode 100644
index 0000000..6fbd3a6
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/32-cert-doc-dig-remedy.txt
@@ -0,0 +1,8 @@
+=== 처방 후보 A: getent (기본 설치) ===
+100.83.212.4    auth.hyeonworks.com
+(exit 0)
+=== 처방 후보 B: dnsutils 를 깔고 dig ===
+Setting up dnsutils (1:9.18.49-1~deb12u2) ...
+Processing triggers for man-db (2.11.2-2) ...
+100.83.212.4
+(exit 0)
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/33-keycloak-precheck.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/33-keycloak-precheck.txt
new file mode 100644
index 0000000..edd3c9b
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/33-keycloak-precheck.txt
@@ -0,0 +1,15 @@
+=== 05 확인 ① 저장소 루트에서 매니페스트가 보이나 ===
+a1-block-jgroups-transport.yaml
+b7-oauth2-proxy.yaml
+bff-redis.yaml
+echo-network-policy.yaml
+echo.yaml
+keycloak-cluster.yaml
+observability.yaml
+traefik-forwarded-headers.yaml
+=== 05 확인 ② 앞 단계의 404 tls=0 이 그대로인가 ===
+000 tls=0
+=== kubectl 이 도나 ===
+NAME       STATUS   ROLES           AGE     VERSION        INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION                 CONTAINER-RUNTIME
+kc-lab-1   Ready    control-plane   9m12s   v1.36.4+k3s1   192.168.122.11   <none>        Debian GNU/Linux 12 (bookworm)   6.1.0-53-cloud-amd64 (amd64)   containerd://2.3.4-k3s1.36
+kc-lab-2   Ready    <none>          7m56s   v1.36.4+k3s1   192.168.122.12   <none>        Debian GNU/Linux 12 (bookworm)   6.1.0-53-cloud-amd64 (amd64)   containerd://2.3.4-k3s1.36
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/34-keycloak-apply.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/34-keycloak-apply.txt
new file mode 100644
index 0000000..b4acc93
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/34-keycloak-apply.txt
@@ -0,0 +1,14 @@
+=== 05 1-② kubectl apply ===
+namespace/keycloak-lab created
+secret/keycloak-lab-secrets created
+persistentvolumeclaim/postgres-data created
+deployment.apps/postgres created
+service/postgres created
+statefulset.apps/keycloak created
+service/keycloak-headless created
+service/keycloak created
+ingress.networking.k8s.io/keycloak created
+=== 05 2-① rollout status (문서: partitioned roll out complete: 2 new pods...) ===
+Waiting for 2 pods to be ready...
+Waiting for 1 pods to be ready...
+partitioned roll out complete: 2 new pods have been updated...
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/35-keycloak-verify-1-3.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/35-keycloak-verify-1-3.txt
new file mode 100644
index 0000000..6fa5014
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/35-keycloak-verify-1-3.txt
@@ -0,0 +1,53 @@
+=== 05 판정 ①-① get all ===
+NAME                            READY   STATUS    RESTARTS   AGE
+pod/keycloak-0                  1/1     Running   0          68s
+pod/keycloak-1                  1/1     Running   0          68s
+pod/postgres-7b474b88c8-s6vdh   1/1     Running   0          68s
+
+NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
+service/keycloak            ClusterIP   10.43.173.152   <none>        8080/TCP            69s
+service/keycloak-headless   ClusterIP   None            <none>        8080/TCP,9000/TCP   69s
+service/postgres            ClusterIP   10.43.38.64     <none>        5432/TCP            69s
+
+NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
+deployment.apps/postgres   1/1     1            1           69s
+
+NAME                                  DESIRED   CURRENT   READY   AGE
+replicaset.apps/postgres-7b474b88c8   1         1         1       69s
+
+NAME                        READY   AGE
+statefulset.apps/keycloak   2/2     69s
+=== 05 판정 ①-② get secret,configmap,pvc,ingress ===
+NAME                          TYPE     DATA   AGE
+secret/keycloak-lab-secrets   Opaque   2      69s
+
+NAME                         DATA   AGE
+configmap/kube-root-ca.crt   1      69s
+
+NAME                                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
+persistentvolumeclaim/postgres-data   Bound    pvc-fe269834-3dd1-4b1f-82f6-a53413310a30   5Gi        RWO            local-path     <unset>                 69s
+
+NAME                                 CLASS     HOSTS                 ADDRESS                         PORTS   AGE
+ingress.networking.k8s.io/keycloak   traefik   auth.hyeonworks.com   192.168.122.11,192.168.122.12   80      69s
+=== 05 판정 ② postgres 사슬 ===
+NAME                                  DESIRED   CURRENT   READY   AGE
+replicaset.apps/postgres-7b474b88c8   1         1         1       69s
+
+NAME                            READY   STATUS    RESTARTS   AGE
+pod/postgres-7b474b88c8-s6vdh   1/1     Running   0          69s
+--- Deployment 는 라벨 없이 ---
+NAME       READY   UP-TO-DATE   AVAILABLE   AGE
+postgres   1/1     1            1           69s
+--- keycloak 쪽 ---
+NAME             READY   STATUS    RESTARTS   AGE
+pod/keycloak-0   1/1     Running   0          69s
+pod/keycloak-1   1/1     Running   0          69s
+=== 05 판정 ③ Secret 길이 (값은 안 찍는다) ===
+Data
+====
+KC_BOOTSTRAP_ADMIN_PASSWORD:  19 bytes
+POSTGRES_PASSWORD:            22 bytes
+--- ② 길이만 ---
+22
+--- ③ 파드 안에서 길이만 ---
+길이=19
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/36-keycloak-verify-4-6.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/36-keycloak-verify-4-6.txt
new file mode 100644
index 0000000..cbe1a17
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/36-keycloak-verify-4-6.txt
@@ -0,0 +1,39 @@
+=== 판정 ③ 끝 — 환경변수가 어느 Secret 에서 왔나 ===
+KC_DB	
+KC_DB_URL	
+KC_DB_USERNAME	
+KC_DB_PASSWORD	keycloak-lab-secrets
+KC_HOSTNAME	
+KC_HOSTNAME_STRICT	
+KC_PROXY_HEADERS	
+KC_HTTP_ENABLED	
+KC_HEALTH_ENABLED	
+KC_METRICS_ENABLED	
+JAVA_OPTS_KC_HEAP	
+KC_BOOTSTRAP_ADMIN_USERNAME	
+KC_BOOTSTRAP_ADMIN_PASSWORD	keycloak-lab-secrets
+=== 판정 ④ Endpoints ===
+Endpoints:                10.42.0.9:8080,10.42.1.3:8080
+--- EndpointSlice ---
+NAME             ADDRESSTYPE   PORTS   ENDPOINTS             AGE
+keycloak-lxk8h   IPv4          8080    10.42.0.9,10.42.1.3   82s
+--- ready 까지 ---
+10.42.0.9	true
+10.42.1.3	true
+--- 문서가 쓰지 말라는 형태를 실제로 쳐 본다 ---
+Warning: v1 Endpoints is deprecated in v1.33+; use discovery.k8s.io/v1 EndpointSlice
+NAME                ENDPOINTS                                                  AGE
+keycloak            10.42.0.9:8080,10.42.1.3:8080                              82s
+keycloak-headless   10.42.0.9:8080,10.42.1.3:8080,10.42.0.9:9000 + 1 more...   82s
+=== 판정 ⑤ PVC ===
+NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
+postgres-data   Bound    pvc-fe269834-3dd1-4b1f-82f6-a53413310a30   5Gi        RWO            local-path     <unset>                 82s
+=== 판정 ⑥ 로그 ===
+2026-09-17 04:35:25,386 INFO  [org.infinispan.CLUSTER] (executor-thread-1) ISPN000094: Received new cluster view for channel ISPN: [keycloak-1-3159(v=16.0.12)|1] (2) [keycloak-1-3159(v=16.0.12), keycloak-0-13057(v=16.0.12)]
+=== 판정 ⑥ 테이블 ===
+       name       |       ip       
+------------------+----------------
+ keycloak-1-3159  | 10.42.0.9:7800
+ keycloak-0-13057 | 10.42.1.3:7800
+(2 rows)
+
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/37-keycloak-cluster-size.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/37-keycloak-cluster-size.txt
new file mode 100644
index 0000000..a45f535
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/37-keycloak-cluster-size.txt
@@ -0,0 +1,6 @@
+=== 판정 ⑥ 지표 — Prometheus 가 아직 없을 때의 임시 파드 형태 ===
+K0=10.42.1.3
+vendor_cluster_size{cache_manager="keycloak",node="keycloak-0-13057"} 2.0
+=== 문서가 적은 대로 Keycloak 컨테이너 안에는 curl 이 없나 ===
+sh: line 1: curl: command not found
+command terminated with exit code 127
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/38-keycloak-verify-7-8.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/38-keycloak-verify-7-8.txt
new file mode 100644
index 0000000..9470631
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/38-keycloak-verify-7-8.txt
@@ -0,0 +1,13 @@
+=== 판정 ⑦ 밖에서 (문서 기대 200) — 04 를 안 했으니 443 이 없다 ===
+000
+--- 같은 것을 읽는 형태로 ---
+curl: (7) Failed to connect to auth.hyeonworks.com:443 after 2 ms: Could not connect to server
+=== 04 를 건너뛴 상태에서 Ingress~파드까지는 이어졌나 (엣지에 80 으로, Host 를 실어) ===
+200
+--- Traefik 에 직접 ---
+200
+=== 판정 ⑧ 세션 표 (로그인 전) ===
+ offline_flag | count 
+--------------+-------
+(0 rows)
+
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/39-observability-apply.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/39-observability-apply.txt
new file mode 100644
index 0000000..1819944
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/39-observability-apply.txt
@@ -0,0 +1,29 @@
+=== 06 1-② apply + rollout ===
+namespace/observability created
+serviceaccount/prometheus created
+clusterrole.rbac.authorization.k8s.io/prometheus created
+clusterrolebinding.rbac.authorization.k8s.io/prometheus created
+configmap/prometheus-config created
+persistentvolumeclaim/prometheus-data created
+deployment.apps/prometheus created
+service/prometheus created
+daemonset.apps/node-exporter created
+service/node-exporter created
+deployment.apps/grafana created
+configmap/grafana-datasources created
+service/grafana created
+ingress.networking.k8s.io/grafana created
+Waiting for deployment "prometheus" rollout to finish: 0 of 1 updated replicas are available...
+deployment "prometheus" successfully rolled out
+=== 06 판정 ①-① get pods ===
+NAME                          READY   STATUS    RESTARTS   AGE
+grafana-845b5678cf-bblgz      0/1     Running   0          30s
+node-exporter-82mmn           1/1     Running   0          30s
+node-exporter-g688j           1/1     Running   0          30s
+prometheus-6774f94f7c-pj8w9   1/1     Running   0          30s
+=== 06 판정 ①-② get pods -o wide ===
+NAME                          READY   STATUS    RESTARTS   AGE   IP               NODE       NOMINATED NODE   READINESS GATES
+grafana-845b5678cf-bblgz      0/1     Running   0          30s   10.42.0.11       kc-lab-1   <none>           <none>
+node-exporter-82mmn           1/1     Running   0          30s   192.168.122.12   kc-lab-2   <none>           <none>
+node-exporter-g688j           1/1     Running   0          30s   192.168.122.11   kc-lab-1   <none>           <none>
+prometheus-6774f94f7c-pj8w9   1/1     Running   0          30s   10.42.0.12       kc-lab-1   <none>           <none>
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/40-observability-verify.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/40-observability-verify.txt
new file mode 100644
index 0000000..591fdd9
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/40-observability-verify.txt
@@ -0,0 +1,50 @@
+=== 06 판정 ①-① 다시 (grafana 가 Ready 가 됐나) ===
+NAME                          READY   STATUS    RESTARTS   AGE
+grafana-845b5678cf-bblgz      1/1     Running   0          38s
+node-exporter-82mmn           1/1     Running   0          38s
+node-exporter-g688j           1/1     Running   0          38s
+prometheus-6774f94f7c-pj8w9   1/1     Running   0          38s
+=== 06 판정 ① 스크레이프 job 이름 ===
+"job":"keycloak"
+"job":"kubelet"
+"job":"node-exporter"
+"job":"prometheus"
+=== 06 판정 ② health 와 lastError ===
+"job":"keycloak"}
+"job":"keycloak"
+"lastError":""
+"health":"unknown"
+"job":"keycloak"}
+"job":"keycloak"
+"lastError":""
+"health":"unknown"
+"job":"kubelet"}
+"job":"kubelet"
+"lastError":""
+"health":"up"
+"job":"kubelet"}
+"job":"kubelet"
+"lastError":""
+"health":"up"
+"job":"node-exporter"}
+"job":"node-exporter"
+"lastError":""
+"health":"up"
+"job":"node-exporter"}
+"job":"node-exporter"
+"lastError":""
+"health":"up"
+"job":"prometheus"}
+"job":"prometheus"}
+"lastError":""
+"health":"up"
+"job":"keycloak"}}
+"job":"keycloak"}}
+=== 06 판정 ② 권한 ===
+Warning: resource 'nodes' is not namespace scoped
+
+yes
+=== 06 판정 ③ vendor_cluster_size ===
+{"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"vendor_cluster_size","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789619921.770,"2"]}]}}
+=== 06 판정 ④ up ===
+{"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"up","instance":"192.168.122.12:9100","job":"node-exporter","node":"kc-lab-2"},"value":[1789619921.874,"1"]},{"metric":{"__name__":"up","beta_kubernetes_io_arch":"amd64","beta_kubernetes_io_instance_type":"k3s","beta_kubernetes_io_os":"linux","instance":"kc-lab-2","job":"kubelet","kubernetes_io_arch":"amd64","kubernetes_io_hostname":"kc-lab-2","kubernetes_io_os":"linux","node_kubernetes_io_instance_type":"k3s"},"value":[1789619921.874,"1"]},{"metric":{"__name__":"up","beta_kubernetes_io_arch":"amd64","beta_kubernetes_io_instance_type":"k3s","beta_kubernetes_io_os":"linux","instance":"kc-lab-1","job":"kubelet","kubernetes_io_arch":"amd64","kubernetes_io_hostname":"kc-lab-1","kubernetes_io_os":"linux","node_kubernetes_io_instance_type":"k3s","node_role_kubernetes_io_control_plane":"true"},"value":[1789619921.874,"1"]},{"metric":{"__name__":"up","instance":"192.168.122.11:9100","job":"node-exporter","node":"kc-lab-1"},"value":[1789619921.874,"1"]},{"metric":{"__name__":"up","instance":"localhost:9090","job":"prometheus"},"value":[1789619921.874,"1"]},{"metric":{"__name__":"up","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789619921.874,"1"]}]}}
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/41-observability-cluster-size-retry.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/41-observability-cluster-size-retry.txt
new file mode 100644
index 0000000..b52d7da
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/41-observability-cluster-size-retry.txt
@@ -0,0 +1,18 @@
+=== 90초 뒤 다시 — 스크레이프가 한 바퀴 더 돈 뒤 ===
+--- targets 의 keycloak health ---
+"job":"keycloak"}
+"job":"keycloak"
+"health":"up"
+"job":"keycloak"}
+"job":"keycloak"
+"health":"up"
+--
+"job":"keycloak"}}
+"job":"keycloak"}}
+"job":"keycloak"}}
+"job":"keycloak"}}
+"job":"keycloak"}}
+--- vendor_cluster_size ---
+{"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"vendor_cluster_size","cache_manager":"keycloak","exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620021.097,"2"]},{"metric":{"__name__":"vendor_cluster_size","cache_manager":"keycloak","exported_node":"keycloak-0-13057","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620021.097,"2"]}]}}
+--- up{job=keycloak} ---
+{"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"up","instance":"10.42.0.9:9000","job":"keycloak","node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620021.182,"1"]},{"metric":{"__name__":"up","instance":"10.42.1.3:9000","job":"keycloak","node":"kc-lab-2","pod":"keycloak-0"},"value":[1789620021.182,"1"]}]}}
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/42-power-cycle-memory.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/42-power-cycle-memory.txt
new file mode 100644
index 0000000..f2b3af7
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/42-power-cycle-memory.txt
@@ -0,0 +1,18 @@
+=== 07 1-① 상한을 올리고 현재 할당을 맞춘다 ===
+Max memory:     5242880 KiB
+Used memory:    5242880 KiB
+
+setmaxmem OK
+
+setmem OK
+=== ② 도메인이 보는 값과 게스트가 인식한 값 ===
+Max memory:     5242880 KiB
+Used memory:    5242880 KiB
+               total        used        free      shared  buff/cache   available
+Mem:            4929        2587         126           2        2507        2342
+=== 되돌린다 (원래 값으로) ===
+
+
+원복 OK
+Max memory:     5242880 KiB
+Used memory:    5242880 KiB
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/43-dominfo-vs-config.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/43-dominfo-vs-config.txt
new file mode 100644
index 0000000..2460d20
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/43-dominfo-vs-config.txt
@@ -0,0 +1,14 @@
+=== dominfo 는 무엇을 보여 주나 (도메인이 돌고 있을 때) ===
+Max memory:     5242880 KiB
+Used memory:    5242880 KiB
+=== 같은 순간의 설정값 (--inactive) ===
+  <memory unit='KiB'>4194304</memory>
+  <currentMemory unit='KiB'>4194304</currentMemory>
+=== 돌고 있는 값 ===
+  <memory unit='KiB'>5242880</memory>
+  <currentMemory unit='KiB'>5242880</currentMemory>
+=== 다시 5120M 으로 맞춰 둔다 (원래 상태) ===
+
+
+  <memory unit='KiB'>5242880</memory>
+  <currentMemory unit='KiB'>5242880</currentMemory>
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/44-host-prep-checks.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/44-host-prep-checks.txt
new file mode 100644
index 0000000..5632d3d
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/44-host-prep-checks.txt
@@ -0,0 +1,40 @@
+=== 00 확인 ① CPU 가 확장을 내놓나 ===
+vmx
+=== 확인 ② 커널이 잡고 있나 ===
+kvm_intel             524288  11
+kvm                  1490944  6 kvm_intel
+irqbypass              16384  1 kvm
+=== 1. 저장소 ===
+cloud
+keycloak-pattern
+a1-block-jgroups-transport.yaml
+b7-oauth2-proxy.yaml
+bff-redis.yaml
+echo-network-policy.yaml
+=== 2. virsh 판 ===
+12.7.0
+=== 3. libvirt 소켓과 그룹 ===
+● libvirtd.socket - libvirt legacy monolithic daemon socket
+     Loaded: loaded (/usr/lib/systemd/system/libvirtd.socket; enabled; preset: disabled)
+     Active: active (running) since Thu 2026-09-03 19:00:35 KST; 1 week 6 days ago
+ Invocation: e330532b350d4d79ad7f31f7c6512a6c
+libvirt
+libvirt:x:962:donghyeon
+=== 4. 연결 URI ===
+LIBVIRT_DEFAULT_URI=[(비어 있음)]
+/home/donghyeon/.zshrc:2:export LIBVIRT_DEFAULT_URI=qemu:///system
+/home/donghyeon/.bashrc:11:export LIBVIRT_DEFAULT_URI=qemu:///system
+qemu:///system
+
+=== 5. 기본 네트워크 ===
+ Name      State    Autostart   Persistent
+--------------------------------------------
+ default   active   yes         yes
+
+=== 확인 ① virsh 가 sudo 없이 통과하나 ===
+ Id   Name          State
+-----------------------------
+ 13   kc-lab-1      running
+ 15   kc-lab-edge   running
+ 16   kc-lab-2      running
+
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/45-libvirt-uri-mechanism.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/45-libvirt-uri-mechanism.txt
new file mode 100644
index 0000000..7b7a7c9
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/45-libvirt-uri-mechanism.txt
@@ -0,0 +1,13 @@
+=== rc 파일이 비대화형 ssh 에서 읽히나 ===
+비대화형: LIBVIRT_DEFAULT_URI=[(비어 있음)]
+=== 그런데도 virsh 가 system 을 보는 까닭 ===
+-rw-r--r-- 1 root      root      547 Sep  1 19:16 /etc/libvirt/libvirt.conf
+-rw-r--r-- 1 donghyeon donghyeon  31 Sep  9 13:42 /home/donghyeon/.config/libvirt/libvirt.conf
+/home/donghyeon/.config/libvirt/libvirt.conf:uri_default = "qemu:///system"
+/etc/libvirt/libvirt.conf:# (@uri_default also prevents probing of the hypervisor driver).
+/etc/libvirt/libvirt.conf:#uri_default = "qemu:///system"
+=== virsh 가 지금 무엇을 보나 ===
+qemu:///system
+
+=== 대화형 셸에서는 rc 가 읽힌다 ===
+대화형: LIBVIRT_DEFAULT_URI=qemu:///system
diff --git a/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/README.txt b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/README.txt
new file mode 100644
index 0000000..49f341f
--- /dev/null
+++ b/docs/virtualization/final/evidence/raw/lab-state-before-rebuild/README.txt
@@ -0,0 +1,51 @@
+2026-09-17 에 test-server 를 문서대로 철거하고 다시 세운 기록.
+
+문서가 맞는지 실물로 확인하는 것이 목적이라, 명령을 고쳐 치지 않고 **문서에 적힌
+그대로** 쳤다. 그래서 실패한 출력도 그대로 들어 있다 — 06 이 그것이다.
+
+| 파일 | 무엇 |
+|---|---|
+| 01 | 철거 전 호스트 상태 전부 |
+| 02 | 철거 문서의 「지우기 전에 먼저 본다」 |
+| 03 | 철거 1단계 — 게스트 셋 |
+| 04 | 철거 2단계 — DHCP 예약 셋 |
+| 05 | 철거 확인표 다섯 줄 |
+| 06 | **구축 5번을 문서 그대로 쳤다 → 실패.** meta 파일 이름에 `.yaml` 이 빠져 있다 |
+| 07 | 이름을 고치고 세 장을 구웠다. 문서에는 한 장 굽는 절만 있다 |
+| 08 | 시드 볼륨 셋 업로드 |
+| 09 | DHCP 예약 셋 |
+| 10~11 | `virt-install` 세 대 |
+| 12 | 부팅 뒤 리스 — 셋 다 예약 주소를 받았다 |
+| 13 | 게스트 SSH 와 `vdb` 가 `iso9660 CIDATA` 인 것 |
+| 14 | `cloud-init schema` 는 `sudo:` 리스트형을 거부하는데 런타임은 받는다 |
+| 15 | **k3s 사전 확인이 실패.** `REMOTE HOST IDENTIFICATION HAS CHANGED!` |
+| 16 | 별칭은 되고 IP 직접 지정은 막힌다 — `Host kc-lab-*` 가 IP 에 안 걸린다 |
+| 17 | 옛 키를 지우고 다시 |
+| 18~19 | k3s server 설치와 확인 |
+| 20 | kubeconfig 를 lab host 로 |
+| 21~22 | 토큰 전달과 agent 설치 |
+| 23 | 2노드 클러스터 확인 |
+
+비밀은 옮기지 않았다. 14 에 평문 비밀번호와 공개키가 찍혀 나와 `<REDACTED>` 로
+가렸고, 가린 자리에 길이만 남겼다.
+25-edge-nginx-config.txt        03 1-④·2·3 — sites-enabled/default 를 지우고 keycloak-lab 을 써서 링크·nginx -t·reload 까지
+26-edge-nginx-verify.txt        03 3-②③④ 와 층 ①② — nginx -t 가 두 줄이다([warn] 없음), nginx -v 가 command not found, 층 ② 가 404
+27-edge-doc-mismatch.txt        which nginx 가 깔린 상태에서도 빈손인 것 · PATH · sudo nginx -v · nginx -t 3회 warn 0
+28-host-state-before-dnat.txt   03 4번 치기 전 호스트 — tailscale0 있음, DNAT 파일과 유닛이 2026-09-11 자로 이미 있음, 호스트 sudo 는 비밀번호를 묻는다
+29-host-dnat-files.txt          호스트에 깔려 있는 .nft 와 유닛 원문 — forward 체인이 남아 있고 ExecStartPost 가 없다 (문서·저장소 원본과 다르다)
+30-layer3-from-workstation.txt  03 층 ③ 을 밖에서 — curl: (7) Failed to connect. 29 의 ExecStartPost 누락이 그대로 드러난 자리
+31-cert-doc-precheck.txt        04 확인 ①② 와 1번 — dig 이 게스트에 없다, nginx -v 가 sudo 없이는 안 된다, certbot plugins 세 줄은 문서대로
+32-cert-doc-dig-remedy.txt      처방 검증 — getent hosts 와 dnsutils 설치 뒤의 dig 이 같은 주소를 낸다
+33-keycloak-precheck.txt        05 확인 ①② — 매니페스트 목록, 000 tls=0 (연결이 안 돼도 tls=0 이 찍힌다), 2노드 Ready
+34-keycloak-apply.txt           05 1-②·2-① — apply 출력 9줄과 rollout status. Waiting for … 줄이 먼저 나온다
+35-keycloak-verify-1-3.txt      05 판정 ①~③ — get all·get secret,configmap,pvc,ingress·사슬·Secret 길이 19/22/19 (값은 안 찍었다)
+36-keycloak-verify-4-6.txt      05 판정 ④~⑥ — Endpoints 둘, PVC 가 postgres-data 하나, ISPN000094 에 (v=16.0.12), jgroups_ping 2행
+37-keycloak-cluster-size.txt    05 판정 ⑥ 지표 — 임시 파드가 읽은 vendor_cluster_size 2.0, Keycloak 안에 curl 이 없다(exit 127)
+38-keycloak-verify-7-8.txt      05 판정 ⑦⑧ — 밖에서는 000(04 미실시), Host 헤더를 실은 80 은 엣지·Traefik 둘 다 200, 세션 표 0행
+39-observability-apply.txt      06 1·2 — apply 출력, rollout, 파드 네 줄(38초에 grafana 가 0/1)
+40-observability-verify.txt     06 판정 ①~④ — job 네 개, health 가 unknown 인 keycloak 둘, can-i 의 경고 줄, 원소 하나뿐인 cluster_size
+41-observability-cluster-size-retry.txt  90초 뒤 다시 — health 가 up 이 되고 원소 둘 다 2. node/pod/exported_node 세 라벨이 다른 것을 말한다
+42-power-cycle-memory.txt        07 1번 — setmaxmem/setmem --config 뒤 dominfo 가 안 바뀐다. 게스트 free -m 도 옛 값
+43-dominfo-vs-config.txt         같은 순간의 dominfo(5242880) 와 dumpxml --inactive(4194304). 바꾼 것이 들어갔는지는 --inactive 가 답한다
+44-host-prep-checks.txt          00 의 확인 명령 전부 — vmx, kvm 모듈 셋, 저장소, virsh 12.7.0, libvirtd.socket, libvirt 그룹, default 네트워크, sudo 없는 virsh list
+45-libvirt-uri-mechanism.txt     rc 파일은 비대화형 ssh 에서 안 읽힌다. 그런데도 되는 까닭은 ~/.config/libvirt/libvirt.conf 의 uri_default
diff --git a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-edge-nginx-and-host-dnat.md b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-edge-nginx-and-host-dnat.md
index 88ff432..c376b85 100644
--- a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-edge-nginx-and-host-dnat.md
+++ b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-edge-nginx-and-host-dnat.md
@@ -123,11 +123,11 @@ ssh kc-lab-edge
 
 **무엇을 확인하는가** — 엣지에 nginx 가 이미 깔려 있는지.
 
-```bash label="[kc-lab-edge] 실행 파일이 있는지 본다"
-which nginx
+```bash label="[kc-lab-edge] 패키지가 만드는 디렉터리를 본다"
+ls /etc/nginx/
 ```
 
-**어디를 봐야 하는가** — 아무것도 안 찍히면 미설치다. 2026-09-11 에 새로 만든 `kc-lab-edge` 에서는 이렇게 나왔다(observed).
+**어디를 봐야 하는가** — `No such file or directory` 가 나오면 미설치다. 2026-09-11 에 새로 만든 `kc-lab-edge` 에서는 이렇게 나왔다(observed).
 
 ```text
 donghyeon@kc-lab-edge:~$ cd /etc/nginx/
@@ -136,6 +136,16 @@ donghyeon@kc-lab-edge:~$ cd /etc/nginx/
 
 **이 결과가 의미하는 것** — `/etc/nginx` 디렉터리는 패키지가 만든다. 그것이 없다는 것은 경로를 잘못 짚었다는 뜻이 아니라 설치가 안 됐다는 뜻이다. 앞 단계의 cloud-init 목록에 nginx 가 없으므로 1번에서 깐다.
 
+**여기에 `which nginx` 를 쓰지 않는다.** 깔려 있을 때도 똑같이 아무것도 안 찍힌다 — 2026-09-17 에 nginx 가 돌고 있는 엣지에서 직접 쳐서 확인했다(observed).
+
+```text
+which nginx   -> (아무것도 안 찍고 exit 1)
+PATH          -> /usr/local/bin:/usr/bin:/bin:/usr/games
+sudo nginx -v -> nginx version: nginx/1.22.1
+```
+
+실행 파일은 `/usr/sbin/nginx` 인데 데비안의 일반 사용자 `PATH` 에 `/usr/sbin` 이 없다. 그래서 이 명령의 빈손은 「안 깔렸다」가 아니라 「이 PATH 에서는 안 보인다」이고, **깔린 경우와 안 깔린 경우의 출력이 같아 판정에 쓸 수 없다.** 판 번호를 볼 때도 `nginx -v` 가 아니라 `sudo nginx -v` 다.
+
 ## 실행 절차
 
 ### 1. 엣지에 nginx 를 깔고 기본 사이트를 끈다
@@ -239,7 +249,7 @@ sudo nginx -t && sudo systemctl reload nginx
 systemctl status nginx --no-pager | head -20
 ```
 
-**예상 결과** — Debian 12 는 `[warn]` 한 줄을 늘 같이 내놓는다(observed).
+**예상 결과** — 2026-09-11 의 엣지에서는 `[warn]` 한 줄이 앞에 붙어 세 줄이었다(observed).
 
 ```text
 nginx: [warn] could not build optimal types_hash, you should increase either
@@ -248,7 +258,14 @@ nginx: configuration file /etc/nginx/nginx.conf syntax is ok
 nginx: configuration file /etc/nginx/nginx.conf test is successful
 ```
 
-`syntax is ok` 와 `test is successful` 두 마디가 다 나와야 통과다. 앞의 `[warn]` 줄은 통과를 막지 않는다. 통과했으면 `&&` 뒤의 reload 가 이어서 돌고 `systemctl reload` 는 아무 말 없이 끝난다.
+**그 `[warn]` 이 늘 나오지는 않는다.** 2026-09-17 에 같은 Debian 12 · 같은 `nginx/1.22.1` 엣지를 새로 세우고 세 번 쳤더니 한 번도 안 나왔다(observed). 두 줄뿐이었다.
+
+```text
+nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
+nginx: configuration file /etc/nginx/nginx.conf test is successful
+```
+
+**판정은 `syntax is ok` 와 `test is successful` 두 마디로만 한다.** `[warn]` 줄은 나오면 무시하고 안 나오면 없는 대로 둔다 — 없다고 설정이 덜 읽힌 것이 아니다. 통과했으면 `&&` 뒤의 reload 가 이어서 돌고 `systemctl reload` 는 아무 말 없이 끝난다.
 
 **왜 필요한가** — `&&` 로 이은 것은 문법이 깨진 설정으로 reload 하지 않으려는 것이다. 실패면 `[emerg]` 줄에 파일과 줄 번호가 찍히고 reload 는 아예 안 돌아, 지금 돌고 있는 nginx 는 옛 설정 그대로 멀쩡하다. 경고와 오류를 여기서 갈라 두면 다음 단계에서 같은 `types_hash` 경고를 실패로 오독하지 않는다. ④ 의 프로세스 트리에서 워커 줄의 PID 를 눈에 담아 둔다 — reload 는 마스터를 그대로 두고 워커만 갈아 끼우므로, 전후로 워커 PID 가 바뀌면 새 설정이 적용된 것이다. 다음 단계에서 인증서 갱신이 서빙까지 닿았는지를 똑같은 방법으로 판정한다.
 
@@ -399,12 +416,14 @@ PREROUTING nat 은 라우팅 결정보다 먼저 도므로 이 규칙이 호스
 
 한 번에 밖에서 치지 말고 가까운 층부터 본다. 네 명령이 각각 다른 층을 건너뛰므로 어디서 끊겼는지가 바로 나온다.
 
-| # | 무엇을 건너뛰나 | 실측 |
-|---|---|---|
-| ① `192.168.122.11` | nginx 를 건너뛴다 | `404` |
-| ② `192.168.122.10` | DNAT 을 건너뛴다 | `301` |
-| ③ 도메인 | 밖에서 | `301 https://auth.hyeonworks.com/` |
-| ④ 도메인 · TLS 이후 | — | `200` |
+| # | 무엇을 건너뛰나 | 이 단계까지 했을 때 | 다 끝난 실험대에서 |
+|---|---|---|---|
+| ① `192.168.122.11` | nginx 를 건너뛴다 | `404` | `404` |
+| ② `192.168.122.10` | DNAT 을 건너뛴다 | `404` | `301` |
+| ③ 도메인 | 밖에서 | `404` | `301 https://auth.hyeonworks.com/` |
+| ④ 도메인 · TLS 이후 | — | (아직 안 된다) | `200` |
+
+**칸이 둘인 까닭.** 이 단계가 쓰는 설정에는 `listen 80` 블록 하나뿐이고 그 안은 `proxy_pass` 다. 리다이렉트를 낼 블록이 없으니 **`301` 은 여기서 나오지 않는다.** 다음 단계가 443 블록과 80→443 리다이렉트를 얹어야 그 값이 나온다. 오른쪽 칸을 그대로 기준으로 삼으면 정상인 `404` 를 실패로 읽는다.
 
 처음 볼 때는 응답을 눈으로 읽는 형태로 치고, 같은 것을 여러 번 재거나 두 노드를 나란히 비교할 때만 값만 뽑는 형태로 바꾼다.
 
@@ -437,9 +456,20 @@ curl -s -o /dev/null -w '%{http_code}\n' http://192.168.122.12
 curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://192.168.122.10
 ```
 
-**어디를 봐야 하는가** — `301` 과 `Location` 이 나오는가.
+**어디를 봐야 하는가** — 엣지가 답을 하는가. **이 단계에서 나오는 코드는 `404` 다.** 2026-09-17 에 이 절을 그대로 따라 엣지를 세우고 재 보니 이렇게 나왔다(observed).
 
-**이 결과가 의미하는 것** — 여기서 막히면 문제는 엣지 안이다. 통과하는데 아래 ③ 이 안 되면 문제는 DNAT 이다. 이 한 층을 끼워 두면 그 둘을 헷갈리지 않는다.
+```text
+HTTP/1.1 404 Not Found
+Server: nginx/1.22.1
+Content-Type: text/plain; charset=utf-8
+Content-Length: 19
+```
+
+```text
+404 page not found
+```
+
+**이 결과가 의미하는 것** — `Server:` 가 `nginx/1.22.1` 이고 본문이 Traefik 의 `404 page not found` 라는 것이 엣지가 받아서 Traefik 으로 넘겼다는 증거다. **이 층의 통과 기준은 코드값이 아니라 「`curl: (7)` 없이 응답이 온다」와 `Server: nginx` 두 가지다.** 여기서 막히면 문제는 엣지 안이다. 통과하는데 아래 ③ 이 안 되면 문제는 DNAT 이다. 이 한 층을 끼워 두면 그 둘을 헷갈리지 않는다.
 
 ### 확인 ③ 밖에서, 즉 DNAT 을 거쳐 닿나
 
@@ -461,6 +491,16 @@ curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://auth.hyeonworks.
 301 https://auth.hyeonworks.com/
 ```
 
+**그 `301` 도 다음 단계 이후의 값이다.** 여기까지만 했다면 ② 와 같은 `404` 가 정상이고, 이 층이 묻는 것은 코드값이 아니라 밖에서 친 것이 엣지까지 닿았는가다.
+
+2026-09-17 에 밖에서 재 보니 닿지 않았다(observed).
+
+```text
+curl: (7) Failed to connect to auth.hyeonworks.com port 80 after 54 ms
+```
+
+같은 시각에 호스트 안에서 친 `http://192.168.122.10` 은 `404` 로 답했다. 아래 「막히면」 표의 마지막 줄이 가리키는 상태 그대로였고, 원인도 거기 적힌 대로였다 — **그 호스트에 깔려 있는 유닛에 `ExecStartPost` 줄이 없다.** 아래 「배포된 것과 적어 둔 것이 다르다」를 본다.
+
 ### 확인 ④ 끝까지 닿나
 
 **무엇을 확인하는가** — nginx 에서 Traefik 을 지나 파드까지 2홉이 다 이어졌는지.
@@ -525,10 +565,10 @@ grep oauth2/callback /var/log/nginx/access.log | tail -1 | wc -c
 | 유닛 | `systemctl is-active lab-edge-dnat.service` | `active` |
 | 우리 테이블 | `sudo nft list table ip lab_edge` | `dnat to 192.168.122.10` · 포트 `80, 443` · SNAT 없음 |
 | 층 ① | `curl -I http://192.168.122.11` | `404` |
-| 층 ② | `curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://192.168.122.10` | `301` |
-| 층 ③ | `curl -I http://auth.hyeonworks.com` | `301` · `Location` 이 원래 호스트명 |
+| 층 ② | `curl -sS -D - -o /dev/null http://192.168.122.10` | `404` · `Server: nginx/1.22.1` |
+| 층 ③ | `curl -I http://auth.hyeonworks.com` | ② 와 같은 응답이 밖에서도 온다 |
 
-층 ④ 는 다음 단계가 인증서를 얹은 뒤에 통과한다.
+층 ④ 는 다음 단계가 인증서를 얹은 뒤에 통과한다. **층 ②③ 의 `301` 도 그때 나온다** — 여기서는 `404` 가 통과다.
 
 ## 막히면
 
@@ -538,10 +578,10 @@ grep oauth2/callback /var/log/nginx/access.log | tail -1 | wc -c
 | ① 이 `502` | Traefik 은 떴는데 백엔드가 없음 | Ingress 확인 |
 | ② 가 응답 없음 | nginx 가 안 떴거나 방화벽 | `systemctl status nginx` |
 | ③ 이 `502` | 인증서 문제 또는 upstream 다운 | 다음 단계 · 위 확인 ⑤ |
-| `/etc/nginx: No such file or directory` | nginx 미설치. cloud-init 은 안 깐다 | `which nginx` |
+| `/etc/nginx: No such file or directory` | nginx 미설치. cloud-init 은 안 깐다 | `ls /etc/nginx/` — `which nginx` 는 깔려 있어도 빈손이라 못 가른다 |
 | `nginx -t` 가 `duplicate default server` | `sites-enabled/default` 가 살아 있다 | `ls -l /etc/nginx/sites-enabled/` |
 | 설정을 썼는데 아무 변화가 없다 | 경로 오타 — `site-available`(단수)에 썼다 | `ls /etc/nginx/sites-available/` |
-| `unknown directive "http2"` | nginx < 1.25.1. Debian 12 는 1.22 다 | `nginx -v` |
+| `unknown directive "http2"` | nginx < 1.25.1. Debian 12 는 1.22 다 | `sudo nginx -v` |
 | `systemctl reload` 가 실패한다 | 설정이 `nginx -t` 를 못 통과했다 | reload 말고 `sudo nginx -t` 를 먼저 |
 | `cp: cannot stat 'deploy/...'` | 엣지에서 쳤거나 lab host 에 저장소가 없다 | `ls ~/workspace` |
 | `Unit lab-edge-dnat.service does not exist` | 유닛이 없거나 `/etc/systemd/` 에 썼거나 `daemon-reload` 를 안 했다 | `find /etc/systemd -name 'lab-edge-dnat*'` |
@@ -549,10 +589,33 @@ grep oauth2/callback /var/log/nginx/access.log | tail -1 | wc -c
 | 호스트 안에서는 404 인데 밖에서만 connection refused | libvirt `guest_input` 의 `reject`. 구멍이 빠졌거나 날아갔다 | `sudo nft -a list chain ip libvirt_network guest_input` — `reject` 줄의 카운터가 올라가면 여기다 |
 | `Error: syntax error, unexpected ct` | 셸이 `{80,443}` 을 펼쳤다 | `'{80,443}'` 로 따옴표 |
 
+## 배포된 것과 적어 둔 것이 다르다
+
+2026-09-17 에 이 절차를 따라 실험대를 다시 세우다 호스트의 두 파일을 열어 봤더니 **위에 실은 내용과 달랐다**(observed). 저장소 원본을 고친 뒤 호스트에 다시 배포하지 않았다 — 파일 시각이 그렇게 말한다.
+
+| 파일 | 호스트에 깔린 것 (`11:00` · `10:52`) | 저장소 원본과 위 본문 (`13:30`) |
+|---|---|---|
+| `lab-edge-dnat.nft` | `prerouting` 뒤에 `forward` 체인이 그대로 있다 (`priority filter - 10` · `ct state new accept`) | 그 체인이 없다. 자리에 왜 뺐는지 주석만 남겼다 |
+| `lab-edge-dnat.service` | `ExecStartPost` 줄이 없다 | `ExecStartPost=-…insert rule ip libvirt_network guest_input…` 이 있다 |
+
+**이것이 위 확인 ③ 의 `curl: (7)` 을 그대로 설명한다.** 고친 쪽의 요점은 앞 체인의 `accept` 로는 뒤 체인의 `reject` 를 못 막으니 구멍은 libvirt 체인 안에 뚫는다는 것인데, 호스트에는 **효과가 없는 쪽만 깔려 있고 효과가 있는 쪽은 안 깔려 있다.** 게다가 그 구멍은 런타임 상태라 libvirt 가 네트워크를 다시 세우면 날아가고, 다시 넣어 줄 `ExecStartPost` 가 유닛에 없으니 **실험대를 다시 세운 직후에는 밖에서 못 들어온다.**
+
+**그래서 4번과 5번은 「이미 있으니 건너뛴다」로 넘기지 않는다.** 파일이 있는 것과 그 파일이 이 문서가 싣는 내용인 것은 다르다. 두 파일을 연 다음 위 본문과 한 줄씩 대조한다.
+
+```bash label="[lab host] 깔려 있는 것이 이 문서가 싣는 내용인지 본다"
+grep -c 'chain forward' /etc/nftables.d/lab-edge-dnat.nft
+grep -c ExecStartPost /etc/systemd/system/lab-edge-dnat.service
+```
+
+`0` 과 `1` 이 나와야 맞다. 반대로 나오면 고치기 전 판이 깔려 있는 것이고, 다시 써서 `sudo systemctl daemon-reload && sudo systemctl restart lab-edge-dnat.service` 로 올린다.
+
+**고쳤는지는 확인하지 못했다**(unknown). 그 호스트의 `sudo` 는 비밀번호를 묻고 이번 작업에는 그 비밀번호가 없었다. `nft list table ip lab_edge` 도 `guest_input` 체인 조회도 못 돌렸고 두 파일을 다시 배포하지도 않았다. 위 표는 **파일 내용과 타임스탬프만으로** 적은 것이고 `reject` 줄의 카운터가 실제로 올라갔는지는 안 봤다.
+
 ## 무엇이 관측이고 무엇이 아닌가
 
-- (observed) 2026-09-11 새로 만든 엣지에서 `/etc/nginx` 가 없던 것, `nginx -t` 출력 세 줄, 층별 확인 ①~④ 의 코드, `301 https://auth.hyeonworks.com/`, upstream 실패 errno 세 줄, access 로그 3492자.
-- (observed) `.nft` 와 유닛 파일의 내용은 저장소 원본과 같다.
+- (observed) 2026-09-11 새로 만든 엣지에서 `/etc/nginx` 가 없던 것, `nginx -t` 출력 세 줄, 다 끝난 실험대에서 잰 층별 확인 ①~④ 의 코드, `301 https://auth.hyeonworks.com/`, upstream 실패 errno 세 줄, access 로그 3492자.
+- (observed) 2026-09-17 에 이 절차를 따라 엣지를 다시 세우고 잰 것 — `nginx -t` 가 두 줄인 것, `which nginx` 가 깔린 상태에서도 빈손인 것, 층 ① 이 `.11`·`.12` 둘 다 `404` 인 것, 층 ② 가 `404` · `Server: nginx/1.22.1` 인 것, 층 ③ 이 `curl: (7)` 인 것, 호스트의 두 파일이 위 본문과 다른 것.
+- (observed) 위에 실은 `.nft` 와 유닛의 내용은 저장소 원본과 같다. 다만 **호스트에 실제로 깔려 있는 두 파일은 그것이 아니다** — 「배포된 것과 적어 둔 것이 다르다」를 본다.
 - (inferred) 이 이동으로 L7 홉 수가 2홉 그대로라는 판정이 이 배치의 전제다. 늘어난 것은 커널이 하는 L4 전달 한 번뿐이라 `X-Forwarded-*` 계약이 그대로 성립한다.
 - (unknown) `curl -I http://192.168.122.11` 의 전체 출력은 캡처해 두지 않았다. 가이드도 봐야 할 줄만 적었다.
 - (unknown) `systemctl status nginx` 두 번과 `ls -l /etc/nginx/sites-enabled/`, 파일 찾기, 체인 조회, `journalctl -u nginx`, access 로그 두 줄은 가이드가 적어 둔 명령이고 출력이 남아 있지 않다.
diff --git a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-install-k3s-server-and-agent.md b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-install-k3s-server-and-agent.md
index d2161c4..154d3db 100644
--- a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-install-k3s-server-and-agent.md
+++ b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-install-k3s-server-and-agent.md
@@ -261,11 +261,41 @@ curl -sfL https://get.k3s.io | sudo sh -s - agent \
   --node-ip 192.168.122.12
 ```
 
-```bash label="[kc-lab-2] ⑥ 설치가 끝나면 토큰 파일을 지운다"
+```bash label="[kc-lab-2] ⑥ 토큰을 root 만 읽는 자리로 옮긴다"
+sudo install -m 600 -o root -g root ~/node-token /etc/rancher/node-token
+sudo ls -l /etc/rancher/node-token
+```
+
+```bash label="[kc-lab-2] ⑦ 유닛이 그 자리를 보게 고치고 다시 읽는다"
+sudo sed -i "s|$HOME/node-token|/etc/rancher/node-token|" /etc/systemd/system/k3s-agent.service
+sudo systemctl daemon-reload
+sudo systemctl restart k3s-agent
+```
+
+```bash label="[kc-lab-2] ⑧ 이제 홈의 사본을 지운다"
 rm ~/node-token
 ```
 
-```bash label="[kc-lab-2] ⑦ lab host 로 나온다"
+:::warning
+
+**⑥⑦ 을 건너뛰고 `rm ~/node-token` 만 치면 이 노드는 다시 못 뜬다.** 설치 스크립트가 `--token-file` 에 준 경로를 유닛의 `ExecStart` 에 그대로 굽기 때문에, 파일이 사라지면 agent 가 영원히 그 파일을 기다린다. 2026-09-17 에 A-4 를 돌려 노드 전원을 뽑았다 다시 켜면서 그대로 겪었다(observed) — VM 은 떴는데 노드가 `NotReady` 에서 안 돌아왔다.
+
+:::
+
+```text
+k3s[522]: level=info msg="Waiting for file \"/home/donghyeon/node-token\" to be created"
+k3s-agent.service: Scheduled restart job, restart counter is at 1.
+```
+
+토큰을 `/etc/rancher/node-token` 으로 옮기고 유닛을 그쪽으로 돌린 뒤 홈의 사본을 지우자, agent 를 완전히 세웠다 다시 켜도 `active` 였고 노드도 `Ready` 로 돌아왔다(observed).
+
+```text
+-rw------- 1 root root 109 /etc/rancher/node-token
+	'--token-file' \
+	'/etc/rancher/node-token' \
+```
+
+```bash label="[kc-lab-2] ⑨ lab host 로 나온다"
 exit
 ```
 
diff --git a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-keycloak-two-nodes-and-postgres-on-k3s.md b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-keycloak-two-nodes-and-postgres-on-k3s.md
index 85991af..a2d739c 100644
--- a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-keycloak-two-nodes-and-postgres-on-k3s.md
+++ b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-keycloak-two-nodes-and-postgres-on-k3s.md
@@ -71,12 +71,19 @@ source:
 | PostgreSQL | Deployment `postgres` — ReplicaSet `postgres-7b474b88c8` |
 | Service | `keycloak` → Endpoints `10.42.0.67:8080,10.42.1.155:8080` |
 | Secret | `keycloak-lab-secrets` — `KC_BOOTSTRAP_ADMIN_PASSWORD` 19 bytes · `POSTGRES_PASSWORD` 22 bytes |
-| PVC | StorageClass `local-path`, 이름 끝에 파드 번호가 붙는다 |
+| PVC | `postgres-data` 하나. StorageClass `local-path` — **파드 번호가 붙지 않는다**(판정 ⑤) |
 | Ingress | HOSTS 가 `auth.hyeonworks.com` |
 | 클러스터링 | JGroups — 디스커버리 테이블 `jgroups_ping`, 메시지 포트 7800 |
 | 관리 포트 | `9000` — `/metrics` 가 거기 있다 |
 
-**판 번호는 여기 없다**(unknown). 가이드 05 는 Keycloak 과 PostgreSQL 의 이미지 태그를 적지 않았고 `keycloak-cluster.yaml` 원문은 반입되지 않았다. 가이드 안에 태그가 찍힌 이미지는 아래 임시 파드의 `curlimages/curl:8.11.1` 하나뿐이다.
+**이미지 태그는 매니페스트가 갖는다.** 가이드 05 는 그것을 적지 않았지만 2026-09-17 에 `keycloak-pattern` @ `9465582b` 의 `deploy/lab/k8s/keycloak-cluster.yaml` 을 열어 읽었다(observed).
+
+```text
+image: postgres:16-alpine
+image: quay.io/keycloak/keycloak:26.7.0
+```
+
+파드 자원 한도와 프로브 설정과 `persistent-user-sessions` 설정값은 아직 이 기록으로 옮기지 않았다(unknown).
 
 ## 전제와 되돌리기
 
@@ -105,7 +112,15 @@ ls deploy/lab/k8s/
 curl -s -o /dev/null -w '%{http_code} tls=%{ssl_verify_result}\n' https://auth.hyeonworks.com/
 ```
 
-**어디를 봐야 하는가** — 앞 단계에서 잰 `404 tls=0` 이 그대로인가. `tls=0` 이 아니면 이 단계를 시작할 때가 아니라 앞 단계로 돌아갈 때다.
+**어디를 봐야 하는가** — 앞 단계에서 잰 `404 tls=0` 이 그대로인가. **앞의 코드를 같이 본다.**
+
+**`tls=0` 만 보면 안 된다.** 연결이 아예 안 됐을 때도 `tls=0` 이 나온다 — `%{ssl_verify_result}` 는 TLS 검증까지 갔을 때만 뜻이 있고 못 갔으면 초기값 `0` 이 그대로 찍힌다. 2026-09-17 에 앞 단계를 건너뛴 상태에서 재 보니 이렇게 나왔다(observed).
+
+```text
+000 tls=0
+```
+
+`000` 은 응답이 없었다는 뜻이다. **판정은 코드가 `404` 인 것과 `tls=0` 이 같이 나오는 것으로 한다.**
 
 **이 결과가 의미하는 것** — 가이드가 그 값 옆에 한 줄을 적어 두었다 — 앞의 `404` 는 이 단계 이후에 `200` 으로 바뀐다. 지금 재 두면 아래의 `200` 이 이 단계가 만든 변화인지가 분명해진다.
 
@@ -137,13 +152,15 @@ kubectl apply -f deploy/lab/k8s/keycloak-cluster.yaml
 kubectl -n keycloak-lab rollout status statefulset/keycloak --timeout=300s
 ```
 
-**예상 결과**
+**예상 결과** — 2026-09-17 에 갓 세운 클러스터에서 잰 것이다(observed).
 
 ```text
+Waiting for 2 pods to be ready...
+Waiting for 1 pods to be ready...
 partitioned roll out complete: 2 new pods have been updated...
 ```
 
-이 명령은 끝날 때까지 아무것도 안 찍고 멈춰 있다. 그 침묵이 정상이고, 마지막 한 줄에서 `complete` 라는 낱말과 파드 개수 `2` 를 본다. StatefulSet 은 파드를 하나씩 순서대로 띄우므로 중간에 `0/2` 로 한참 멈춰 있는 것도 정상이다.
+마지막 한 줄에서 `complete` 라는 낱말과 파드 개수 `2` 를 본다. 그 줄이 나올 때까지 명령이 안 끝나고 멈춰 있는 것이 정상이다. **다만 아무것도 안 찍고 멈춰 있지는 않다** — `Waiting for …` 줄은 진행 상황이지 오류가 아니다. 숫자가 줄어들수록 파드가 하나씩 Ready 가 된다. StatefulSet 은 파드를 하나씩 순서대로 띄우므로 중간에 `0/2` 로 한참 멈춰 있는 것도 정상이다.
 
 **왜 필요한가** — 300초를 다 쓰고 타임아웃으로 끝나면 그것도 답이 된다. 「안 떴다」가 확정되고 진단으로 넘어간다. `rollout status` 를 쓰는 까닭은 `get pods` 를 반복해서 치는 것보다 나아서만이 아니라, 언제 끝났는지를 사람이 판정하지 않아도 되기 때문이다. 기다리지 않고 판정으로 가면 아직 안 뜬 것과 못 뜨는 것이 섞인다.
 
@@ -279,8 +296,19 @@ KC_DB
 KC_DB_URL
 KC_DB_USERNAME
 KC_DB_PASSWORD	keycloak-lab-secrets
+KC_HOSTNAME
+KC_HOSTNAME_STRICT
+KC_PROXY_HEADERS
+KC_HTTP_ENABLED
+KC_HEALTH_ENABLED
+KC_METRICS_ENABLED
+JAVA_OPTS_KC_HEAP
+KC_BOOTSTRAP_ADMIN_USERNAME
+KC_BOOTSTRAP_ADMIN_PASSWORD	keycloak-lab-secrets
 ```
 
+열세 줄이 나오고 **오른쪽이 채워진 줄은 둘**이다(2026-09-17, observed). 처음에는 앞의 네 줄만 실었는데 그러면 `KC_BOOTSTRAP_ADMIN_PASSWORD` 가 Secret 에서 오는 것이 안 보인다.
+
 오른쪽 칸이 채워진 줄만 Secret 을 참조한다. 비밀이어야 할 변수의 오른쪽이 비어 있으면 그 값은 매니페스트에 평문으로 적혀 있다는 뜻이고, 그 파일은 대개 git 에 들어간다.
 
 ### 확인 ④ Service 뒤에 파드가 있나
@@ -339,7 +367,16 @@ kubectl -n keycloak-lab get pods --show-labels
 kubectl -n keycloak-lab get pvc
 ```
 
-**어디를 봐야 하는가** — STATUS 칸이 `Bound` 인가 `Pending` 인가, VOLUME 칸이 비어 있는지, STORAGECLASS 칸이 `local-path` 인가. StatefulSet 이면 PVC 이름 끝에 파드 번호가 붙어 있어 어느 파드 것인지 바로 보인다.
+**어디를 봐야 하는가** — STATUS 칸이 `Bound` 인가 `Pending` 인가, VOLUME 칸이 비어 있는지, STORAGECLASS 칸이 `local-path` 인가.
+
+**이 실험대에는 파드 번호가 붙은 PVC 가 없다.** 「StatefulSet 이면 PVC 이름 끝에 파드 번호가 붙는다」는 `volumeClaimTemplates` 를 쓰는 StatefulSet 의 이야기이고 **이 매니페스트의 `keycloak` StatefulSet 에는 그 칸이 없다.** PVC 는 PostgreSQL 이 쓰는 `postgres-data` 하나뿐이고 그것도 StatefulSet 이 아니라 별도 문서로 선언되어 Deployment 가 `claimName` 으로 가리킨다. 2026-09-17 에 매니페스트와 클러스터 양쪽에서 확인했다(observed).
+
+```text
+NAME            STATUS   VOLUME                                     CAPACITY   STORAGECLASS
+postgres-data   Bound    pvc-fe269834-3dd1-4b1f-82f6-a53413310a30   5Gi        local-path
+```
+
+그래서 **Keycloak 파드는 볼륨을 안 갖는다.** 세션이 어디 사는지를 묻는 이 실험대의 질문에서 그것이 중요하다 — 파드가 죽으면 그 안의 것은 사라지고 `postgres-data` 만 남는다.
 
 **이 결과가 의미하는 것** — `Bound` 면 볼륨이 붙었다. `Pending` 이면 StorageClass 가 없거나 노드에 자리가 없다. `local-path` 는 파드가 스케줄될 때까지 기다리므로, 파드가 안 뜨면 PVC 도 `Pending` 인 것이 정상이다. 둘이 서로를 기다리는 것처럼 보이지만 파드 쪽 원인을 먼저 본다. 사유는 PVC 의 이벤트에 적혀 있다.
 
@@ -364,6 +401,14 @@ ISPN000094: Received new cluster view for channel ISPN:
 
 **어디를 봐야 하는가** — 세 군데다. 괄호 안의 `(2)` 가 멤버 수, 대괄호 안의 이름 목록, 그리고 `|1` 이 뷰 번호다. 뷰 번호는 멤버가 들고 날 때마다 올라간다.
 
+**이름 뒤에 `(v=…)` 가 붙어 나오기도 한다.** 2026-09-17 에 새로 세운 클러스터에서 같은 줄을 뽑아 보니 이랬다(observed).
+
+```text
+[keycloak-1-3159(v=16.0.12)|1] (2) [keycloak-1-3159(v=16.0.12), keycloak-0-13057(v=16.0.12)]
+```
+
+`(v=16.0.12)` 는 JGroups 가 붙인 판 번호이고, 볼 것은 그대로 `(2)` 와 이름 목록과 `|1` 이다. **맨 앞의 이름이 `keycloak-0` 이 아니어도 정상이다** — 맨 앞에는 코디네이터가 오고 먼저 뜬 쪽이 그 일을 맡는다. 이 판에서는 `keycloak-1` 이었다.
+
 이름 목록의 `keycloak-0-10001` 은 파드 이름 그대로가 아니다. Infinispan 이 파드 이름 뒤에 임의의 접미사를 붙여 클러스터 노드 식별자로 쓰기 때문에, 아래 지표에 나오는 `keycloak-0-46674` 와는 `keycloak-0` 까지만 같다. 그래서 대조할 때 맞춰 보는 것은 접미사 앞의 파드 이름이다. Keycloak 만 StatefulSet 이라 그 앞부분이 고정이고, 덕분에 로그와 `jgroups_ping` 테이블과 지표를 같은 이름으로 견줄 수 있다.
 
 **이 결과가 의미하는 것** — `(2)` 면 이 노드는 상대를 봤다. `(1)` 이면 혼자 있다고 알고 있다. 뷰 번호가 계속 오르고 있으면 멤버가 붙었다 떨어지기를 반복하는 중이라, 「지금 2 다」라는 스냅숏보다 그 사실이 더 중요하다. 이 줄은 과거형이므로 지금 상태는 지표로 본다.
@@ -435,6 +480,21 @@ curl -s -o /dev/null -w '%{http_code}\n' https://auth.hyeonworks.com/realms/mast
 curl -I https://auth.hyeonworks.com/realms/master
 ```
 
+**이 `200` 은 앞 단계를 끝냈을 때의 값이다.** 인증서 단계를 건너뛰고 이 단계만 했다면 443 을 듣는 것이 없으므로 여기는 `000` 이다. 2026-09-17 에 그 상태에서 재 보니 이렇게 나왔다(observed).
+
+```text
+curl: (7) Failed to connect to auth.hyeonworks.com:443 after 2 ms: Could not connect to server
+```
+
+**그때도 이 단계가 세운 것까지는 잴 수 있다.** TLS 를 빼고 `Host` 헤더를 실어 80 으로 치면 nginx → Traefik → Ingress → Service → 파드가 이어졌는지가 그대로 나온다. 둘 다 `200` 이었다(observed).
+
+```bash label="[lab host] TLS 를 빼고 사슬만 잰다"
+curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: auth.hyeonworks.com' http://192.168.122.10/realms/master
+curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: auth.hyeonworks.com' http://192.168.122.11/realms/master
+```
+
+앞엣것은 엣지 nginx 를 지나고 뒤엣것은 Traefik 에 바로 친다. 둘이 같으면 남은 것은 TLS 뿐이다.
+
 ### 확인 ⑧ 관리 콘솔에 로그인된다
 
 **무엇을 확인하는가** — 가이드가 적은 「이 단계가 끝나면」의 앞 절반.
@@ -511,10 +571,12 @@ kubectl -n keycloak-lab exec -it keycloak-0 -- sh
 - (observed) 디스커버리 테이블에는 둘 다 있는데 메시지가 안 가는 상태를 실제로 겪었다.
 - (external) `kubectl get endpoints` 의 v1.33 deprecation 은 쿠버네티스 쪽 규격이고 이 실험대가 잰 값이 아니다.
 - (external) Infinispan 이 파드 이름에 임의의 접미사를 붙여 클러스터 노드 식별자로 쓴다는 것은 Infinispan 의 동작이다. 이 기록에 실린 `keycloak-0-10001` 과 `keycloak-0-46674` 가 그렇게 생긴 이름이다(observed).
-- (unknown) `keycloak-cluster.yaml` 원문이 반입되지 않아 Keycloak 과 PostgreSQL 의 이미지 태그, 파드 자원 한도, 프로브 설정, `persistent-user-sessions` 설정값은 대조하지 못했다. 위에 적은 객체 이름과 해시와 바이트 수는 돌고 있던 실험대에서 읽은 것이고, 매니페스트가 그것들을 어떤 값으로 선언했는지는 여기서 확인할 수 없다.
+- (unknown) `keycloak-cluster.yaml` 원문은 `source/` 에 없다. 파드 자원 한도와 프로브 설정과 `persistent-user-sessions` 설정값은 아직 이 기록으로 옮기지 않았다.
 - (unknown) `get all` 과 `get deploy` 와 `get pvc` 와 `describe pvc` 와 디스커버리 테이블 조회와 `get events` 와 `describe pod` 와 `logs` 의 출력은 가이드가 봐야 할 줄만 적었고 값이 남아 있지 않다.
 - (unknown) 원본 가이드 05 에 되돌리는 절차가 없다. `local-path` PVC 가 노드 디스크에 남긴 데이터가 네임스페이스를 지울 때 어떻게 되는지도 확인하지 않았다.
 - (unknown) 이 단계에는 「이 실험대는 이렇게 했다」와 「따라 하는 사람은」 두 갈래가 없다. 05 는 파일을 직접 쓰지 않고 저장소의 매니페스트를 적용한다.
-- (unknown) 만드는 명령은 구축할 때 친 것을 옮긴 것이라 다시 쳐서 같은 상태가 되는지는 확인되지 않았다.
+- (observed) 2026-09-17 에 갓 세운 클러스터에서 이 절차를 처음부터 다시 밟았다. 같은 값이 다시 나온 것 — `postgres-7b474b88c8` 이라는 ReplicaSet 해시, Secret 의 19·22 bytes 와 주입된 길이 19·복호 길이 22, Endpoints 두 개와 `ready` 두 줄, `jgroups_ping` 2 행, 임시 파드가 읽은 `vendor_cluster_size … 2.0`, Keycloak 이미지에 `curl` 이 없다는 것과 exit code 127, `kubectl get endpoints` 의 deprecation 경고. **파드 IP 와 Infinispan 접미사만 달랐다** — 그것들은 매번 새로 붙는다.
+- (observed) 같은 날 잰 것 가운데 문서와 달랐던 것 — `rollout status` 가 `Waiting for …` 를 찍는다는 것, PVC 가 `postgres-data` 하나라는 것, 환경변수 목록이 열세 줄이라는 것, `ISPN000094` 이름에 `(v=16.0.12)` 가 붙는다는 것, 인증서 단계를 건너뛰면 밖에서가 `000` 이라는 것.
+- (observed) `keycloak-cluster.yaml` 을 `keycloak-pattern` @ `9465582b` 에서 읽었다. 이미지 태그는 `postgres:16-alpine` 과 `quay.io/keycloak/keycloak:26.7.0` 이다.
 
 <!-- body:end -->
diff --git a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-power-cycle-the-lab-and-reallocate-guest-memory.md b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-power-cycle-the-lab-and-reallocate-guest-memory.md
index 9f7f4f1..29706b5 100644
--- a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-power-cycle-the-lab-and-reallocate-guest-memory.md
+++ b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-power-cycle-the-lab-and-reallocate-guest-memory.md
@@ -79,12 +79,25 @@ virsh setmaxmem kc-lab-1 5120M --config
 virsh setmem kc-lab-1 5120M --config
 ```
 
-```bash label="[lab host] ② 도메인이 보는 값과 게스트가 인식한 값을 함께 본다"
+```bash label="[lab host] ② 바꾼 값이 설정에 들어갔는지 본다"
+virsh dumpxml kc-lab-1 --inactive | grep -E '<memory|<currentMemory'
+```
+
+```bash label="[lab host] ③ 지금 돌고 있는 값과 게스트가 인식한 값도 함께 본다"
 virsh dominfo kc-lab-1 | grep -i memory
 ssh kc-lab-1 free -m
 ```
 
-**예상 결과** — `dominfo` 의 `Max memory` 가 바뀐 상한으로 나온다. 게스트의 `free -m` 은 재부팅 전까지 옛 값을 보여 준다.
+**예상 결과** — ② 의 두 줄이 방금 준 값으로 바뀐다. ③ 의 `dominfo` 와 게스트의 `free -m` 은 **재부팅 전까지 옛 값 그대로**다.
+
+**`dominfo` 로 판정하지 않는다.** `--config` 는 다음 기동부터 쓸 설정만 바꾸는데 `dominfo` 는 **지금 돌고 있는 값**을 보여 준다. 그래서 `setmaxmem … --config` 가 제대로 먹어도 `dominfo` 의 숫자는 안 바뀌고, 그 화면을 보고 「안 먹었다」로 읽게 된다. 2026-09-17 에 같은 순간을 두 명령으로 나란히 찍었다(observed).
+
+```text
+virsh dominfo               Max memory: 5242880 KiB   ← 돌고 있는 값
+virsh dumpxml --inactive    <memory unit='KiB'>4194304</memory>   ← 방금 바꾼 설정
+```
+
+같은 도메인, 같은 시각, 다른 숫자다. **바꾼 것이 들어갔는지는 `--inactive` 가 답하고, `dominfo` 는 지금 무엇으로 돌고 있는지를 답한다.**
 
 **왜 필요한가** — 두 명령이 다른 것을 바꾼다.
 
diff --git a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-prepare-the-lab-host-for-virtualization.md b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-prepare-the-lab-host-for-virtualization.md
index 52672e1..c3ccd36 100644
--- a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-prepare-the-lab-host-for-virtualization.md
+++ b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-prepare-the-lab-host-for-virtualization.md
@@ -274,6 +274,28 @@ echo 'export LIBVIRT_DEFAULT_URI=qemu:///system' >> ~/.bashrc
 virsh uri
 ```
 
+**rc 파일에만 넣으면 `ssh lab-host '명령'` 에서는 안 먹는다.** 그 형태는 비대화형 셸이라 `.bashrc`·`.zshrc` 를 안 읽는다. 뒤의 편들이 `ssh test-server 'virsh …'` 처럼 한 줄로 치는 일이 많으므로 여기서 갈라 둔다. 2026-09-17 에 확인했다(observed).
+
+```text
+ssh 로 한 줄     LIBVIRT_DEFAULT_URI=[(비어 있음)]
+대화형 셸        LIBVIRT_DEFAULT_URI=qemu:///system
+```
+
+**셸과 무관하게 고정하려면 libvirt 자기 설정에 넣는다.** 이 실험대에는 그 파일도 있었다(observed).
+
+```bash label="[lab host] 셸을 안 타는 자리에 고정한다"
+mkdir -p ~/.config/libvirt
+echo 'uri_default = "qemu:///system"' >> ~/.config/libvirt/libvirt.conf
+virsh uri
+```
+
+```text
+/home/donghyeon/.config/libvirt/libvirt.conf:uri_default = "qemu:///system"
+qemu:///system
+```
+
+**둘 중 하나만 있으면 어디선가 어긋난다.** rc 만 있으면 `ssh` 한 줄에서 `qemu:///session` 을 보게 되고 — 그쪽에는 VM 이 없으므로 **목록이 빈 채로 나와 「VM 이 죽었다」로 읽힌다** — libvirt 설정만 있으면 대화형 셸의 `echo $LIBVIRT_DEFAULT_URI` 가 비어서 「설정이 안 됐다」로 읽힌다. 둘 다 넣어 두는 편이 낫다.
+
 따라 하는 사람에게는 편집기 쪽이 맞다. `echo >>` 는 같은 가이드를 두 번 따라 하면 같은 줄을 한 번 더 붙이고, 파일에 이미 무엇이 들어 있는지도 보여 주지 않는다. 파일을 열면 둘 다 해결된다.
 
 **문제가 생기면** — `.bashrc` 에 넣은 것은 새로 여는 셸에만 적용된다. 지금 셸에서 값이 안 바뀌었으면 `source ~/.bashrc` 를 치거나 새 셸을 연다.
diff --git a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-prometheus-and-grafana-for-the-lab.md b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-prometheus-and-grafana-for-the-lab.md
index bcfba4f..73056a2 100644
--- a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-prometheus-and-grafana-for-the-lab.md
+++ b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-prometheus-and-grafana-for-the-lab.md
@@ -195,6 +195,16 @@ kubectl -n observability exec deploy/prometheus -- \
 
 **이 결과가 의미하는 것** — `down` 인 대상이 있으면 `lastError` 가 까닭을 그대로 말해 준다. 연결 거부인지 타임아웃인지 404 인지가 거기 적혀 있다. 확인 ③ 에서 값이 한 노드만 나오는 증상의 원인이 대개 여기 있고, 그때는 클러스터가 아니라 스크레이프가 문제다.
 
+**`down` 말고 `unknown` 도 있다.** 스택을 막 올린 직후에는 `health` 가 `unknown` 이고 `lastError` 는 빈 문자열이다 — 실패한 것이 아니라 **아직 한 번도 안 긁은** 것이다. 2026-09-17 에 `rollout status` 직후에 잡힌 모습이다(observed).
+
+```text
+"job":"keycloak"
+"lastError":""
+"health":"unknown"
+```
+
+한 주기 뒤에 같은 줄이 `"health":"up"` 으로 바뀌었다. `unknown` 을 보고 권한이나 네트워크를 뒤지기 전에 한 번 더 친다.
+
 권한이 모자라 대상 하나만 빠지는 일이 이 실험대에서 실제로 있었다. Prometheus 는 타깃을 적어 두지 않고 쿠버네티스 API 에 물어서 찾으므로 읽기 권한이 필요하다. 그 권한을 담는 `ClusterRole` 에서 `nodes/proxy` 를 빠뜨리자 kubelet 타깃만 `403 Forbidden` 으로 실패하고 나머지 잡은 전부 정상이었다. `nodes` 와 `nodes/metrics` 와 `nodes/proxy` 는 서로 다른 권한이라, 노드 지표를 긁는 경로 `/api/v1/nodes/<name>/proxy/metrics` 에는 셋째 것이 따로 있어야 한다. 부분 실패라 1번의 `rollout status` 는 성공이라고 말하고, 타깃 목록을 직접 봐야 드러난다. 권한만 따로 물을 수도 있다.
 
 ```bash label="[lab host] 그 ServiceAccount 가 그 동사를 쓸 수 있는지 묻는다"
@@ -202,6 +212,14 @@ kubectl auth can-i get nodes/proxy --as=system:serviceaccount:observability:prom
 kubectl describe clusterrole prometheus
 ```
 
+첫 명령은 답 앞에 경고 한 줄을 같이 낸다(2026-09-17, observed). 실패가 아니라 `nodes` 가 네임스페이스에 속한 자원이 아니라는 안내이고, 볼 것은 그 아래의 `yes` 또는 `no` 다.
+
+```text
+Warning: resource 'nodes' is not namespace scoped
+
+yes
+```
+
 ### 확인 ③ 클러스터 상태 — 두 노드가 각각 몇 명을 보고 있는가
 
 **무엇을 확인하는가** — 두 Keycloak 이 서로를 보고 있는지.
@@ -218,7 +236,26 @@ keycloak-1 → 2
 keycloak-0 → 2
 ```
 
-**어디를 봐야 하는가** — `data.result` 배열의 원소가 몇 개인가, 각 원소에서 `metric` 안의 `node` 라벨과 `value` 배열의 둘째 원소만 읽는다. `jq` 가 없으므로 눈으로 읽는다.
+**어디를 봐야 하는가** — `data.result` 배열의 원소가 몇 개인가, 각 원소에서 어느 Keycloak 파드가 보고한 것인지와 `value` 배열의 둘째 원소만 읽는다. `jq` 가 없으므로 눈으로 읽는다.
+
+**어느 파드인지는 `node` 라벨이 아니라 `pod` 라벨이 말한다.** Prometheus 를 거쳐 나온 응답에서 `node` 는 **쿠버네티스 노드 이름**이다. Keycloak 이 자기 지표에 붙인 `node` 는 스크레이프할 때 이름이 겹쳐 `exported_node` 로 밀린다. 2026-09-17 에 원소 하나를 그대로 옮기면 이렇다(observed).
+
+```text
+"metric":{"__name__":"vendor_cluster_size","cache_manager":"keycloak",
+ "exported_node":"keycloak-1-3159","instance":"10.42.0.9:9000","job":"keycloak",
+ "node":"kc-lab-1","pod":"keycloak-1"},"value":[1789620021.097,"2"]
+```
+
+세 라벨이 각각 다른 것을 말한다 — `pod` 가 Keycloak 파드, `exported_node` 가 Infinispan 멤버 식별자, `node` 가 그 파드가 떠 있는 쿠버네티스 노드다. 앞 단계의 `ISPN000094` 이름과 견줄 것은 `exported_node` 이고, 어느 노드를 끊었을 때 무엇이 바뀌는지를 볼 때는 `node` 다.
+
+**스택을 막 올린 직후에는 원소가 모자란다.** 1번의 `rollout status` 가 성공한 직후에 이 질의를 치면 Keycloak 대상이 아직 한 번도 안 긁혀서 원소가 하나뿐이거나 아예 없다. 2026-09-17 에 38초 시점과 약 2분 시점에 같은 질의를 쳐서 확인했다(observed).
+
+| 언제 | 확인 ② 의 keycloak `health` | 이 질의의 원소 |
+|---|---|---|
+| `rollout status` 직후(38초) | `"health":"unknown"` | 1 개 |
+| 약 2분 뒤 | `"health":"up"` | 2 개 · 둘 다 `2` |
+
+원소가 모자라면 분단을 의심하기 전에 확인 ② 의 `health` 를 먼저 보고, `unknown` 이면 한 주기 기다렸다 다시 친다.
 
 **이 결과가 의미하는 것** — 두 노드가 각각 자기가 아는 멤버 수를 보고한다. 둘 다 2 면 클러스터가 온전하다. 분단되면 한쪽은 2, 다른 쪽은 1 이 된다 — 한 노드만 보면 분단을 놓친다. 원소가 하나뿐이면 분단이 아니라 스크레이프 실패일 수 있으므로 확인 ② 의 `health` 를 먼저 본다. 값이 아예 안 나오면 `"result":[]` 로 빈 배열이 오는데, 이것은 「0 이다」가 아니라 「그런 지표가 없다」는 뜻이다. 지표 이름을 잘못 쳤거나 그 대상을 긁고 있지 않은 것이므로 확인 ① 로 돌아간다.
 
@@ -260,7 +297,7 @@ kubectl -n observability port-forward svc/grafana 3000:3000
 | 파드 | `kubectl -n observability get pods` | 네 줄 · `node-exporter` 가 둘 |
 | 대상 | `… /api/v1/targets \| grep -o '"job":"[^"]*"' \| sort -u` | `keycloak` 이 목록에 있다 |
 | 상태 | `… /api/v1/targets \| tr ',' '\n' \| grep -E …` | `"health":"up"` 아닌 줄이 없다 |
-| 클러스터 | `… query=vendor_cluster_size` | 원소 둘 · 값 둘 다 2 |
+| 클러스터 | `… query=vendor_cluster_size` | 원소 둘 · 값 둘 다 2 — **`health` 가 `up` 이 된 뒤에 잰다** |
 
 ## 막히면
 
@@ -285,6 +322,7 @@ kubectl -n observability port-forward svc/grafana 3000:3000
 - (unknown) 원본 가이드 06 에 되돌리는 절차가 없다. DaemonSet 이 노드마다 남긴 것을 걷어내 본 적이 없다.
 - (unknown) 이 단계에는 「이 실험대는 이렇게 했다」와 「따라 하는 사람은」 두 갈래가 없다. 06 은 파일을 직접 쓰지 않고 저장소의 매니페스트를 적용한다.
 - (inferred) node-exporter 가 재는 것은 게스트 안에서 본 값이다. 호스트에서 같은 것을 재면 다른 수가 나올 수 있는데, 스크레이프 대상 넷이 전부 클러스터 안이라 이 실험대는 호스트 쪽 지표를 긁지 않는다.
-- (unknown) 만드는 명령은 구축할 때 친 것을 옮긴 것이라 다시 쳐서 같은 상태가 되는지는 확인되지 않았다.
+- (observed) 2026-09-17 에 이 절차를 갓 세운 클러스터에서 다시 밟았다. 파드 네 줄과 job 네 개가 그대로 나왔고 ReplicaSet 해시 `845b5678cf`·`6774f94f7c` 까지 같았다. 달랐던 것 — `rollout status` 직후에는 Grafana 가 `0/1` 이었고 Keycloak 대상의 `health` 가 `unknown` 이라 `vendor_cluster_size` 의 원소가 하나뿐이었다. 약 2분 뒤에 둘 다 `2` 가 됐다.
+- (observed) `kubectl auth can-i get nodes/proxy --as=…` 는 `yes` 앞에 `Warning: resource 'nodes' is not namespace scoped` 한 줄을 같이 낸다. 경고이지 실패가 아니다.
 
 <!-- body:end -->
diff --git a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-wildcard-certificate-with-dns-01-and-a-deploy-hook.md b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-wildcard-certificate-with-dns-01-and-a-deploy-hook.md
index 2ae9814..1f1d90b 100644
--- a/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-wildcard-certificate-with-dns-01-and-a-deploy-hook.md
+++ b/docs/virtualization/tech-log-studio/lab-environment-build/setup/setup-wildcard-certificate-with-dns-01-and-a-deploy-hook.md
@@ -133,13 +133,25 @@ ssh kc-lab-edge
 ### 확인 ① 이 도메인이 무엇으로 풀리는가
 
 ```bash label="[kc-lab-edge] 도메인이 어느 주소로 풀리는지 본다"
-dig +short auth.hyeonworks.com
+getent hosts auth.hyeonworks.com
 ```
 
 **실측**(observed)
 
 ```text
-100.83.212.4
+100.83.212.4    auth.hyeonworks.com
+```
+
+**여기에 `dig` 를 바로 쓰지 않는다.** 엣지 게스트에는 `dig` 가 없다 — 2026-09-17 에 cloud-init 으로 갓 만든 `kc-lab-edge` 에서 쳐서 확인했다(observed).
+
+```text
+dig: command not found
+```
+
+cloud-init 이 까는 것은 `curl` 과 `nftables` 뿐이라 `dnsutils` 가 안 들어간다. `getent hosts` 는 `libc` 가 주는 것이라 어디서나 있고 주소와 이름을 한 줄로 낸다. `dig` 의 형태가 꼭 필요하면 먼저 깐다 — 둘 다 같은 `100.83.212.4` 를 냈다(observed).
+
+```bash label="[kc-lab-edge] dig 를 쓰려면 먼저 깐다"
+sudo apt install -y dnsutils && dig +short auth.hyeonworks.com
 ```
 
 **어디를 봐야 하는가** — 주소 한 줄. 그 주소가 공개 인터넷 대역인가, `100.64.0.0/10` 안인가.
@@ -149,9 +161,11 @@ dig +short auth.hyeonworks.com
 ### 확인 ② nginx 판 번호는 몇인가
 
 ```bash label="[kc-lab-edge] 이 게스트의 nginx 판 번호"
-nginx -v
+sudo nginx -v
 ```
 
+**`sudo` 가 붙는 까닭은 앞 단계와 같다.** 실행 파일이 `/usr/sbin/nginx` 인데 데비안 일반 사용자 `PATH` 에 그 디렉터리가 없다. `sudo` 없이 치면 `nginx: command not found` 가 나오고, 안 깔린 것처럼 보이지만 아니다(2026-09-17, observed).
+
 **실측**(observed) — 같은 설정인데 배포판에서 갈린다.
 
 ```text
@@ -548,7 +562,7 @@ ps -eo pid,lstart,args | grep 'nginx: worker' | grep -v grep
 
 | 증상 | 원인 | 확인 |
 |---|---|---|
-| certbot 검증 실패 | DNS 가 이 호스트를 안 가리킴 · 80 이 막힘 | `dig +short auth.hyeonworks.com` · 밖에서 `curl -I http://auth.hyeonworks.com` |
+| certbot 검증 실패 | DNS 가 이 호스트를 안 가리킴 · 80 이 막힘 | `getent hosts auth.hyeonworks.com` · 밖에서 `curl -I http://auth.hyeonworks.com` |
 | 체인 단계가 1개 | `cert.pem` 을 씀 | 확인 ② |
 | 갱신은 됐는데 옛 인증서가 나감 | deploy 훅 없음 | 워커 PID · `sudo ls /etc/letsencrypt/renewal-hooks/deploy/` |
 | 훅이 실패한 것처럼 보임 | stderr 경고를 error 로 표시 | 문구 말고 워커 PID |
@@ -562,7 +576,9 @@ ps -eo pid,lstart,args | grep 'nginx: worker' | grep -v grep
 
 ## 무엇이 관측이고 무엇이 아닌가
 
-- (observed) `dig` 가 낸 `100.83.212.4`, `certbot plugins` 세 줄, `nginx -v` 두 줄, 체인 4단계와 `Verify return code: 0 (ok)`, `404 tls=0`, 배포판 기본 유닛에 훅이 없다는 것, 갱신에서 서빙까지 2305초 대 1~2초, reload 무중단 측정값.
+- (observed) 이름 풀이가 낸 `100.83.212.4`, `certbot plugins` 세 줄, `nginx -v` 두 줄, 체인 4단계와 `Verify return code: 0 (ok)`, `404 tls=0`, 배포판 기본 유닛에 훅이 없다는 것, 갱신에서 서빙까지 2305초 대 1~2초, reload 무중단 측정값.
+- (observed) 2026-09-17 에 새로 만든 엣지에서 잰 것 — `dig` 가 없다는 것, `getent hosts` 와 `dnsutils` 설치 뒤의 `dig` 가 같은 주소를 낸다는 것, `nginx -v` 가 `sudo` 없이는 `command not found` 라는 것, `certbot plugins` 세 줄이 문서에 적힌 것과 같다는 것.
+- (unknown) 2번부터 4번까지(토큰 발급 · 자격증명 파일 · 시험 발급 · 실제 발급)는 2026-09-17 에 다시 밟지 않았다. Cloudflare 토큰이 필요한 구간이라 토큰 없이는 칠 수 없고, 값을 옮겨 오지도 않았다. 그래서 **5번의 443 블록과 6번의 훅도 재확인하지 못했다** — 인증서 파일이 없으면 그 설정은 `nginx -t` 를 못 지난다.
 - (external) `100.64.0.0/10` 이 CGNAT 예약 대역이라는 것과 Let's Encrypt 의 발급 한도와 유효기간 90일은 규격이고 이 실험대가 잰 값이 아니다.
 - (external) Cloudflare 계정에 남는 토큰은 엣지를 지운다고 없어지지 않는다. 가이드는 폐기를 적지 않았다.
 - (inferred) 2305초 측정은 훅이 물리 호스트에만 있던 시절의 기록이라, 엣지 게스트에서 다시 잰 값이 아니다. 지금 배치에서 같은 수가 나오는지는 재지 않았다.
diff --git a/docs/virtualization/tech-log-studio/tech-log-tree.json b/docs/virtualization/tech-log-studio/tech-log-tree.json
index 57cfe3d..fe0ffe9 100644
--- a/docs/virtualization/tech-log-studio/tech-log-tree.json
+++ b/docs/virtualization/tech-log-studio/tech-log-tree.json
@@ -2,7 +2,7 @@
   "schemaVersion": 4,
   "project": "virtualization",
   "ssot": "final/document.md",
-  "ssotSha256": "7f6b40ab80434185a4bcd206ff1bf59b616b8ddcbb916fad1b9a82c0a854ad22",
+  "ssotSha256": "2b860da308e69e0803c5bf2a6f911c1bafa01c1ef5e0e121100567d2ffdc353e",
   "sourceRevision": "no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다",
   "generatedAt": "2026-09-17",
   "sourceRepository": [