docs(keycloak-session-store): import the session-storage lab as a new project
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
DongHyeonka
co-authored by
Claude Opus 5
Claude Opus 5
parent
43bccd08a8
commit
b2963105a8
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
kind: CASE
|
||||
slug: claim-check-has-no-wiring-line-in-the-starter
|
||||
title: claim-check는 starter에 배선 코드가 한 줄도 없다
|
||||
topic: cross-leaf-integration-facts
|
||||
project: clean-architecture-backend-template
|
||||
status: 게시 전
|
||||
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
||||
rootTreeNode: case:claim-check-has-no-wiring-line-in-the-starter
|
||||
evidenceCapturedOn: 2026-09-01
|
||||
assets:
|
||||
- key: claim-check-has-no-wiring-line-in-the-starter
|
||||
file: ../../../final/evidence/rendered/claim-check-has-no-wiring-line-in-the-starter.svg
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/claim-check-has-no-wiring-line-in-the-starter.txt
|
||||
source:
|
||||
- 원본 분석 절은 analysis/19-messaging-platform.md#L926 이다.
|
||||
module: integration/19-messaging-platform
|
||||
priority: P3
|
||||
---
|
||||
|
||||
# claim-check는 starter에 배선 코드가 한 줄도 없다
|
||||
|
||||
claim-check 리프는 runtime_memberships 가 출하 컴포지션이고 starter 의 허용 의존에도 들어 있다. 그런데 starter 에 저장소 구현도, 빈도, 오프로드를 부르는 발행 경로도 없다.
|
||||
|
||||
## 문제
|
||||
|
||||
claim-check 리프는 runtime_memberships 가 출하 컴포지션이고 starter 의 허용 의존에도 들어 있다.
|
||||
|
||||
그런데 starter 에 저장소 구현도, 빈도, 오프로드를 부르는 발행 경로도 없다.
|
||||
|
||||
## 결론
|
||||
|
||||
리프 SSOT 는 자기 안에서 '소비자 0' 까지만 말할 수 있고, '배포에는 실려 있다' 는 레지스트리와 starter 를 함께 읽어야 나온다.
|
||||
|
||||
## 검증 환경
|
||||
|
||||
OpenJDK : 21.0.12 java -version 으로 확인
|
||||
Gradle : 9.0.0 src/gradle/wrapper/gradle-wrapper.properties 의 distributionUrl 로 확인
|
||||
확인 방식 : starter 자동설정 전문에서 ClaimCheck 문자열 검색과 두 클래스의 main 참조 수 확인
|
||||
소스 수정 : x
|
||||
|
||||
## 재현 조건
|
||||
|
||||
원문은 analysis/19-messaging-platform.md#L926 에 있다.
|
||||
|
||||
## 본문
|
||||
|
||||
<!-- body:start -->
|
||||
|
||||
claim-check 리프는 `runtime_memberships` 가 출하 컴포지션이고 starter 의 허용 의존에도 들어 있다. 그런데 starter 에 저장소 구현도, 빈도, 오프로드를 부르는 발행 경로도 없다.
|
||||
|
||||
## 리프가 출하 컴포지션에 든 상태
|
||||
|
||||
:::evidence key="claim-check-has-no-wiring-line-in-the-starter" alt="분석 문서 analysis/19-messaging-platform.md 에서 이 기록의 근거 절을 그대로 잘라낸 15줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="analysis/19-messaging-platform.md 발췌 — 15줄" zoom="true"
|
||||
:::
|
||||
|
||||
## 리프 SSOT 혼자서는 이 사실을 말할 수 없다
|
||||
|
||||
리프 SSOT 는 자기 안에서 "소비자 0" 까지만 말할 수 있고, "배포에는 실려 있다" 는 레지스트리와 starter 를 함께 읽어야 나온다.
|
||||
|
||||
## 확인하지 못한 것
|
||||
|
||||
부팅된 컨텍스트에서 임계값을 넘는 payload 를 발행해 claim check 가 일어나지 않는 것을 관측하지 않았다. 자동설정에 이 리프의 이름이 등장하지 않는다는 것으로 판정했다.
|
||||
|
||||
<!-- body:end -->
|
||||
+82
@@ -0,0 +1,82 @@
|
||||
---
|
||||
kind: CASE
|
||||
slug: messaging-migration-stream-has-no-applier-and-collides-on-adoption
|
||||
title: messaging 마이그레이션 스트림을 적용하는 곳이 없고, 적용하려는 순간 버전이 충돌한다
|
||||
topic: cross-leaf-integration-facts
|
||||
project: clean-architecture-backend-template
|
||||
status: 게시 전
|
||||
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
||||
rootTreeNode: case:messaging-migration-stream-has-no-applier-and-collides-on-adoption
|
||||
evidenceCapturedOn: 2026-09-01
|
||||
assets:
|
||||
- key: messaging-migration-stream-has-no-applier-and-collides-on-adoption
|
||||
file: ../../../final/evidence/rendered/messaging-migration-stream-has-no-applier-and-collides-on-adoption.svg
|
||||
- key: messaging-migration-stream-has-no-applier-and-collides-on-adoption-diagram
|
||||
file: ../../../final/assets/diagrams/messaging-migration-stream-has-no-applier-and-collides-on-adoption.svg
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/messaging-migration-stream-has-no-applier-and-collides-on-adoption.txt
|
||||
source:
|
||||
- 원본 분석 절은 analysis/19-messaging-platform.md#L860 이다.
|
||||
module: integration/19-messaging-platform
|
||||
priority: P2
|
||||
---
|
||||
|
||||
# messaging 마이그레이션 스트림을 적용하는 곳이 없고, 적용하려는 순간 버전이 충돌한다
|
||||
|
||||
리프 하나만 읽어서는 보이지 않는 사실이다. 두 messaging 리프가 각자 마이그레이션을 갖는데 그 스트림을 적용하는 Flyway location 이 어떤 컴포지션에도 없다.
|
||||
|
||||
## 관계
|
||||
|
||||
- **messaging 마이그레이션 두 leaf가 같은 디렉터리에서 V2를 둘 만들었다**
|
||||
같은 구조에서 실제로 확인된 사건이다.
|
||||
|
||||
## 문제
|
||||
|
||||
리프 하나만 읽어서는 보이지 않는 사실이다.
|
||||
|
||||
두 messaging 리프가 각자 마이그레이션을 갖는데 그 스트림을 적용하는 Flyway location 이 어떤 컴포지션에도 없다.
|
||||
|
||||
## 결론
|
||||
|
||||
그리고 적용하려는 순간 두 리프가 같은 디렉터리에서 같은 버전 번호를 만들어 둔 것이 드러난다 — 즉 배선 부재가 번호 충돌을 가려 왔다.
|
||||
|
||||
두 사실이 한 사건인 이유는 순서다.
|
||||
|
||||
적용이 시작되는 날 첫 실패가 충돌이고, 그때까지는 어느 쪽도 관측되지 않는다.
|
||||
|
||||
## 검증 환경
|
||||
|
||||
OpenJDK : 21.0.12 java -version 으로 확인
|
||||
Gradle : 9.0.0 src/gradle/wrapper/gradle-wrapper.properties 의 distributionUrl 로 확인
|
||||
확인 방식 : 두 리프의 마이그레이션 파일 목록과 컴포지션들의 Flyway location 설정 대조
|
||||
소스 수정 : x
|
||||
|
||||
## 재현 조건
|
||||
|
||||
원문은 analysis/19-messaging-platform.md#L860 에 있다.
|
||||
|
||||
## 본문
|
||||
|
||||
<!-- body:start -->
|
||||
|
||||
리프 하나만 읽어서는 보이지 않는 사실이다. 두 messaging 리프가 각자 마이그레이션을 갖는데 그 스트림을 적용하는 Flyway location 이 어떤 컴포지션에도 없다.
|
||||
|
||||
## 적용이 없어 가려진 충돌
|
||||
|
||||
:::evidence key="messaging-migration-stream-has-no-applier-and-collides-on-adoption-diagram" alt="리프 둘의 마이그레이션만 존재하는 것 안에 놓이고 Flyway 적용 위치가 바깥에 빗금으로 놓인다" caption="적용이 없어 가려진 충돌" zoom="false"
|
||||
:::
|
||||
|
||||
## 스트림을 적용하는 컴포지션이 없다
|
||||
|
||||
:::evidence key="messaging-migration-stream-has-no-applier-and-collides-on-adoption" alt="분석 문서 analysis/19-messaging-platform.md 에서 이 기록의 근거 절을 그대로 잘라낸 15줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="analysis/19-messaging-platform.md 발췌 — 15줄" zoom="true"
|
||||
:::
|
||||
|
||||
## 두 사실이 한 사건인 이유는 순서다
|
||||
|
||||
적용하려는 순간 두 리프가 같은 디렉터리에서 같은 버전 번호를 만들어 둔 것이 드러난다 — 배선 부재가 번호 충돌을 가려 왔다. 적용이 시작되는 날 첫 실패가 충돌이고, 그때까지는 어느 쪽도 관측되지 않는다.
|
||||
|
||||
## 확인하지 못한 것
|
||||
|
||||
그 디렉터리를 Flyway location 에 넣어 부팅 실패를 재현하지 않았다. 적용 위치가 없어 충돌이 아직 발현하지 않는다는 것이 이 기록의 요지다.
|
||||
|
||||
<!-- body:end -->
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
---
|
||||
kind: CASE
|
||||
slug: the-admin-switch-turns-on-the-guard-and-not-the-service
|
||||
title: admin 스위치가 가드를 켜고 서비스는 켜지 않는다
|
||||
topic: cross-leaf-integration-facts
|
||||
project: clean-architecture-backend-template
|
||||
status: 게시 전
|
||||
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
||||
rootTreeNode: case:the-admin-switch-turns-on-the-guard-and-not-the-service
|
||||
evidenceCapturedOn: 2026-09-01
|
||||
assets:
|
||||
- key: the-admin-switch-turns-on-the-guard-and-not-the-service
|
||||
file: ../../../final/evidence/rendered/the-admin-switch-turns-on-the-guard-and-not-the-service.svg
|
||||
- key: the-admin-switch-turns-on-the-guard-and-not-the-service-diagram
|
||||
file: ../../../final/assets/diagrams/the-admin-switch-turns-on-the-guard-and-not-the-service.svg
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/the-admin-switch-turns-on-the-guard-and-not-the-service.txt
|
||||
source:
|
||||
- 원본 분석 절은 analysis/19-messaging-platform.md#L975 이다.
|
||||
module: integration/19-messaging-platform
|
||||
priority: P2
|
||||
---
|
||||
|
||||
# admin 스위치가 가드를 켜고 서비스는 켜지 않는다
|
||||
|
||||
운영자가 admin 기능을 켜는 프로퍼티 하나가 파괴적 작업 가드를 활성화한다. 같은 스위치가 그 가드를 실제로 부르는 admin 서비스 빈은 만들지 않는다.
|
||||
|
||||
## 문제
|
||||
|
||||
운영자가 admin 기능을 켜는 프로퍼티 하나가 파괴적 작업 가드를 활성화한다.
|
||||
|
||||
같은 스위치가 그 가드를 실제로 부르는 admin 서비스 빈은 만들지 않는다.
|
||||
|
||||
## 결론
|
||||
|
||||
결과적으로 스위치는 '켜졌다' 는 상태를 만들고 그 상태를 소비하는 경로가 없다.
|
||||
|
||||
두 리프의 SSOT 를 겹쳐야만 보이는 형태다 — 한쪽은 가드의 조건을, 다른 쪽은 서비스 빈의 부재를 소유한다.
|
||||
|
||||
## 검증 환경
|
||||
|
||||
OpenJDK : 21.0.12 java -version 으로 확인
|
||||
Gradle : 9.0.0 src/gradle/wrapper/gradle-wrapper.properties 의 distributionUrl 로 확인
|
||||
확인 방식 : admin 스위치가 만드는 빈 4종 전수 확인과 그 가드를 부르는 서비스 빈의 생성 지점 검색
|
||||
소스 수정 : x
|
||||
|
||||
## 재현 조건
|
||||
|
||||
원문은 analysis/19-messaging-platform.md#L975 에 있다.
|
||||
|
||||
## 본문
|
||||
|
||||
<!-- body:start -->
|
||||
|
||||
운영자가 admin 기능을 켜는 프로퍼티 하나가 파괴적 작업 가드를 활성화한다. 같은 스위치가 그 가드를 실제로 부르는 admin 서비스 빈은 만들지 않는다.
|
||||
|
||||
## 스위치가 닿는 범위
|
||||
|
||||
:::evidence key="the-admin-switch-turns-on-the-guard-and-not-the-service-diagram" alt="admin 스위치에서 가드와 저널과 검증기는 만들어지고 admin 서비스 빈은 빗금인 두 갈래가 나온다" caption="스위치가 닿는 범위" zoom="false"
|
||||
:::
|
||||
|
||||
## 스위치가 만드는 빈 넷
|
||||
|
||||
:::evidence key="the-admin-switch-turns-on-the-guard-and-not-the-service" alt="분석 문서 analysis/19-messaging-platform.md 에서 이 기록의 근거 절을 그대로 잘라낸 15줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="analysis/19-messaging-platform.md 발췌 — 15줄" zoom="true"
|
||||
:::
|
||||
|
||||
## 켜졌다는 상태를 소비하는 경로가 없다
|
||||
|
||||
두 리프의 SSOT 를 겹쳐야만 보이는 형태다 — 한쪽은 가드의 조건을, 다른 쪽은 서비스 빈의 부재를 소유한다.
|
||||
|
||||
## 확인하지 못한 것
|
||||
|
||||
부팅된 컨텍스트에서 admin 평면을 켜고 빈 그래프를 관측하지 않았다. 런타임 관측을 수행하지 않았다.
|
||||
|
||||
<!-- body:end -->
|
||||
+70
@@ -0,0 +1,70 @@
|
||||
---
|
||||
kind: CASE
|
||||
slug: the-public-surface-contract-test-lives-outside-the-family
|
||||
title: MessagingPublicSurfaceContractTest가 가족 밖(app-bootstrap)에 있다
|
||||
topic: cross-leaf-integration-facts
|
||||
project: clean-architecture-backend-template
|
||||
status: 게시 전
|
||||
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
||||
rootTreeNode: case:the-public-surface-contract-test-lives-outside-the-family
|
||||
evidenceCapturedOn: 2026-09-01
|
||||
assets:
|
||||
- key: the-public-surface-contract-test-lives-outside-the-family
|
||||
file: ../../../final/evidence/rendered/the-public-surface-contract-test-lives-outside-the-family.svg
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/the-public-surface-contract-test-lives-outside-the-family.txt
|
||||
source:
|
||||
- 원본 분석 절은 analysis/19-messaging-platform.md#L1114 이다.
|
||||
module: integration/19-messaging-platform
|
||||
priority: P3
|
||||
---
|
||||
|
||||
# MessagingPublicSurfaceContractTest가 가족 밖(app-bootstrap)에 있다
|
||||
|
||||
messaging 가족의 공개 표면을 붙드는 계약 테스트가 그 가족이 아니라 컴포지션 리프에 있다. 그래서 messaging 리프만 빌드하는 경로에서는 그 계약이 돌지 않고, 가족 안의 어느 SSOT 도 자기 표면이 어디서 검증되는지 알 수 없다.
|
||||
|
||||
## 문제
|
||||
|
||||
messaging 가족의 공개 표면을 붙드는 계약 테스트가 그 가족이 아니라 컴포지션 리프에 있다.
|
||||
|
||||
그래서 messaging 리프만 빌드하는 경로에서는 그 계약이 돌지 않고, 가족 안의 어느 SSOT 도 자기 표면이 어디서 검증되는지 알 수 없다.
|
||||
|
||||
## 결론
|
||||
|
||||
테스트의 소재가 곧 그 테스트가 도는 조건이라는 점이 이 관측의 요지다.
|
||||
|
||||
## 검증 환경
|
||||
|
||||
OpenJDK : 21.0.12 java -version 으로 확인
|
||||
Gradle : 9.0.0 src/gradle/wrapper/gradle-wrapper.properties 의 distributionUrl 로 확인
|
||||
확인 방식 : MessagingPublicSurfaceContractTest 참조 1건 검색으로 파일의 소속 소스셋 확인
|
||||
소스 수정 : x
|
||||
|
||||
## 재현 조건
|
||||
|
||||
원문은 analysis/19-messaging-platform.md#L1114 에 있다.
|
||||
|
||||
## 본문
|
||||
|
||||
<!-- body:start -->
|
||||
|
||||
messaging 가족의 공개 표면을 붙드는 계약 테스트가 그 가족이 아니라 컴포지션 리프에 있다.
|
||||
|
||||
## MessagingPublicSurfaceContractTest 참조 위치
|
||||
|
||||
:::evidence key="the-public-surface-contract-test-lives-outside-the-family" alt="코드베이스에서 MessagingPublicSurfaceContractTest 를 검색한 출력 1줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="MessagingPublicSurfaceContractTest 코드베이스 검색 — 1줄 · exit 0" zoom="true"
|
||||
:::
|
||||
|
||||
## 두 결과
|
||||
|
||||
messaging 리프만 빌드하는 경로에서는 그 계약이 돌지 않고, 가족 안의 어느 SSOT 도 자기 표면이 어디서 검증되는지 알 수 없다.
|
||||
|
||||
## 이 관측의 요지
|
||||
|
||||
테스트의 소재가 곧 그 테스트가 도는 조건이다.
|
||||
|
||||
## 확인하지 못한 것
|
||||
|
||||
messaging 리프만 빌드하는 경로를 실제로 돌려 그 계약이 빠지는 것을 관측하지 않았다. 파일 위치로 판정했다.
|
||||
|
||||
<!-- body:end -->
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
kind: CASE
|
||||
slug: twenty-five-main-files-and-one-test-file
|
||||
title: messaging-admin-api는 main 25파일 · 1,613 LOC에 테스트 파일이 1개다
|
||||
topic: cross-leaf-integration-facts
|
||||
project: clean-architecture-backend-template
|
||||
status: 게시 전
|
||||
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
||||
rootTreeNode: case:twenty-five-main-files-and-one-test-file
|
||||
evidenceCapturedOn: 2026-09-01
|
||||
assets:
|
||||
- key: twenty-five-main-files-and-one-test-file
|
||||
file: ../../../final/evidence/rendered/twenty-five-main-files-and-one-test-file.svg
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/twenty-five-main-files-and-one-test-file.txt
|
||||
source:
|
||||
- 원본 분석 절은 analysis/19-messaging-platform.md#L997 이다.
|
||||
module: integration/19-messaging-platform
|
||||
priority: P3
|
||||
---
|
||||
|
||||
# messaging-admin-api는 main 25파일 · 1,613 LOC에 테스트 파일이 1개다
|
||||
|
||||
가족 관점에서만 나오는 비율 관측이다. 이 리프의 운영자 표면 전체가 테스트 한 파일에 기대고 있고, 그 파일이 겨냥하지 않는 타입들이 §17 에서 각각 미검증으로 잡힌다.
|
||||
|
||||
## 문제
|
||||
|
||||
가족 관점에서만 나오는 비율 관측이다.
|
||||
|
||||
이 리프의 운영자 표면 전체가 테스트 한 파일에 기대고 있고, 그 파일이 겨냥하지 않는 타입들이 §17 에서 각각 미검증으로 잡힌다.
|
||||
|
||||
## 결론
|
||||
|
||||
리프 SSOT 는 개별 타입의 미검증을 말하고, 이 관측은 그것들이 한 원인에서 나온다는 것을 말한다.
|
||||
|
||||
## 검증 환경
|
||||
|
||||
OpenJDK : 21.0.12 java -version 으로 확인
|
||||
Gradle : 9.0.0 src/gradle/wrapper/gradle-wrapper.properties 의 distributionUrl 로 확인
|
||||
확인 방식 : 두 리프의 main·test 파일 수와 LOC 집계
|
||||
소스 수정 : x
|
||||
|
||||
## 재현 조건
|
||||
|
||||
원문은 analysis/19-messaging-platform.md#L997 에 있다.
|
||||
|
||||
## 본문
|
||||
|
||||
<!-- body:start -->
|
||||
|
||||
가족 관점에서만 나오는 비율 관측이다. 이 리프의 운영자 표면 전체가 테스트 한 파일에 기대고 있다.
|
||||
|
||||
## main 과 test 파일 수
|
||||
|
||||
:::evidence key="twenty-five-main-files-and-one-test-file" alt="분석 문서 analysis/19-messaging-platform.md 에서 이 기록의 근거 절을 그대로 잘라낸 15줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="analysis/19-messaging-platform.md 발췌 — 15줄" zoom="true"
|
||||
:::
|
||||
|
||||
## 그 파일이 겨냥하지 않는 타입들
|
||||
|
||||
§17 에서 각각 미검증으로 잡힌다. 리프 SSOT 는 개별 타입의 미검증을 말하고, 이 관측은 그것들이 한 원인에서 나온다는 것을 말한다.
|
||||
|
||||
## 확인하지 못한 것
|
||||
|
||||
테스트 한 파일이 겨냥하지 않는 타입들이 실제로 어떻게 깨지는지 확인하지 않았다. 리프 SSOT 의 §17 이 개별 미검증을 소유한다.
|
||||
|
||||
<!-- body:end -->
|
||||
Reference in New Issue
Block a user