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>
98 lines
5.2 KiB
Markdown
98 lines
5.2 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: jpa-platform-capabilities-have-no-consumer
|
|
title: JPA 플랫폼 capability 대부분에 production 소비자가 없다
|
|
topic: duplicate-mechanisms
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: case:jpa-platform-capabilities-have-no-consumer
|
|
evidenceCapturedOn: 2026-09-01
|
|
assets:
|
|
- key: jpa-platform-capabilities-have-no-consumer
|
|
file: ../../../final/evidence/rendered/jpa-platform-capabilities-have-no-consumer.svg
|
|
evidence:
|
|
- ../../../final/evidence/raw/jpa-platform-capabilities-have-no-consumer.txt
|
|
source:
|
|
- 원본 분석 절은 final/document.md#8-2 항목 8 · analysis/05 §17 P8, §11.0 이다.
|
|
---
|
|
|
|
# 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
|
|
|
|
## 재현 조건
|
|
|
|
1. persistence-jpa 의 각 능력 패키지에서 main 파일 수를 센다.
|
|
2. 각 패키지의 정규화된 패키지 이름을 리프 밖 main 소스에서 검색해 참조 파일 수를 센다.
|
|
3. 두 수를 나란히 놓는다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
`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들을 가져다 쓰는지 확인할 방법이 이 저장소 안에 없다 — 그것이 세 선택지(채택 / 명시적 라이브러리 선언 / 제거) 중 무엇이 맞는지를 정한다
|
|
|
|
<!-- body:end -->
|