DongHyeonkaandClaude Opus 5
b2963105a8
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>
5.2 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | jpa-platform-capabilities-have-no-consumer | JPA 플랫폼 capability 대부분에 production 소비자가 없다 | duplicate-mechanisms | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:jpa-platform-capabilities-have-no-consumer | 2026-09-01 |
|
|
|
JPA 플랫폼 capability 대부분에 production 소비자가 없다
JPA 리프의 능력별 패키지를 리프 밖 프로덕션 코드가 얼마나 참조하는지 세면 대부분이 0 이다. 코드가 없는 것이 아니라 그것을 쓰는 애플리케이션 코드가 없다.
관계
- 중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다 이 사례가 그 규칙과 같은 계열이다.
- Bean 애너테이션이 있다는 것은 조립 증거가 아니다 같은 계열의 확인 규칙이다.
- 재시도 코디네이터는 빈이지만 그것을 어디에도 적용하지 않는다 같은 리프에서 나타난 더 좁은 사례다.
문제
이 리프는 JPA 플랫폼의 여러 능력을 패키지 단위로 담는다. 스프링 데이터 통합, 하이버네이트 정책, 캐시, 감사 이력, 쿼리 DSL 같은 것들이다.
능력 리포트는 이것들을 지원 등급과 함께 보고한다. 그러면 그 능력을 실제로 쓰는 코드가 있는가.
결론
패키지별로 리프 밖 프로덕션 참조 파일 수를 세면 이렇다.
springdata : main 파일 17, 리프 밖 참조 0 hibernate : main 파일 22, 리프 밖 참조 2 cache : main 파일 5, 리프 밖 참조 0 envers : main 파일 6, 리프 밖 참조 0 querydsl : main 파일 3, 리프 밖 참조 0
다섯 중 넷이 0 이다. 하이버네이트 패키지만 둘이다.
이 수치의 의미를 정확히 두어야 한다. 리프 안에서 서로 쓰는 것은 셈에서 빠져 있고, 자동설정이 빈으로 만드는 것도 별개다. 여기서 센 것은 이 리프의 능력 패키지를 리프 밖의 프로덕션 코드가 타입으로 참조하는가다.
그 답이 0 이라는 것은 애플리케이션 계층이 그 능력을 이름으로 부르지 않는다는 뜻이다. 스프링 데이터처럼 리포지터리 인터페이스로 간접 사용되는 경우도 있으므로, 0 이 곧 미사용을 뜻하지는 않는다. 다만 능력 리포트가 지원 등급으로 보고하는 것과 애플리케이션이 그것에 의존하는 것 사이에 거리가 있다는 것은 분명하다.
이 리프에서 같은 형태가 더 좁게 나타난 사례가 재시도 코디네이터다. 그쪽은 빈까지 만들어지고 소비자가 0 이다.
검증 환경
OpenJDK : 21.0.12 Gradle : 9.0.0 확인 방식 : 패키지 이름 기준 리프 밖 main 참조 파일 수 계수 소스 수정 : x
재현 조건
- persistence-jpa 의 각 능력 패키지에서 main 파일 수를 센다.
- 각 패키지의 정규화된 패키지 이름을 리프 밖 main 소스에서 검색해 참조 파일 수를 센다.
- 두 수를 나란히 놓는다.
본문
JpaKeysetQuerySupport·SafeSortMapper·JpaStreamExecutor·FetchPlanApplier·batch/bulk/stateless executor·업서트·work claim·JSON/range/array·COPY·CacheRegionCatalog·EntityGraphCatalog가 전부 leaf 밖 참조 0이다.
JpaKeysetQuerySupport 참조 위치
:::evidence key="jpa-platform-capabilities-have-no-consumer" alt="코드베이스에서 JpaKeysetQuerySupport 를 검색한 출력 2줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="JpaKeysetQuerySupport 코드베이스 검색 — 2줄 · exit 0" zoom="true" :::
결정적 증거는 같은 leaf 안의 두 스토어다
fileserver(25파일)와 notification(53파일)이 합쳐 350KB이고 매일 PostgreSQL에 쓰는데 JPA 플랫폼 타입을 하나도 import하지 않고, 같은 문제(SKIP LOCKED 큐 클레임·안전 정렬·충돌 판정)를 각자 다시 만들었다. 즉 "아직 소비자가 없어서"가 아니라 소비자가 있는데도 안 쓴다.
거짓말은 아니지만 겹치면 다른 문장이 된다
support-matrix.md가 대부분을 Advanced로 표기한다. 다만 이 조합은 §P2(계약 테스트가 production 타입을 실행하지 않음)와 겹쳐 "구현됐고, 안 쓰이고, 테스트도 없다"가 된다.
확인하지 못한 것
간접 사용을 세지 않았다. 스프링 데이터 리포지터리처럼 인터페이스 상속과 프록시로 쓰이는 경우는 타입 참조로 나타나지 않는다.
각 능력이 자동설정으로 빈이 되는지 개별로 확인하지 않았다. 이 기록은 애플리케이션 계층의 참조에 대한 것이다.
파생 프로젝트가 실제로 이 capability들을 가져다 쓰는지 확인할 방법이 이 저장소 안에 없다 — 그것이 세 선택지(채택 / 명시적 라이브러리 선언 / 제거) 중 무엇이 맞는지를 정한다