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>
109 lines
4.9 KiB
Markdown
109 lines
4.9 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: analysis-finding-a10-f003
|
|
title: SDK가 선언한 두 진입점에 구현이 없다
|
|
topic: caching-and-redis
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: case:analysis-finding-a10-f003
|
|
evidenceCapturedOn: 2026-09-01
|
|
body: case-analysis-finding-a10-f003.body.md
|
|
assets:
|
|
- key: analysis-finding-a10-f003
|
|
file: ../../../final/evidence/rendered/analysis-finding-a10-f003.svg
|
|
evidence:
|
|
- ../../../final/evidence/raw/analysis-finding-a10-f003.txt
|
|
source:
|
|
- 원본 분석 절은 analysis/10-adapter-outbound-cache-redis.md#L251 이다.
|
|
---
|
|
|
|
# SDK가 선언한 두 진입점에 구현이 없다
|
|
|
|
동기와 반응형 진입점 인터페이스가 각각 열두 접근자를 선언한다. 개별 표면은 사십삼 종이 모두 구현되어 있는데 두 진입점을 구현하는 클래스는 하나도 없다. 대칭 테스트는 인터페이스끼리만 비교하므로 이것을 가리지 못한다.
|
|
|
|
## 관계
|
|
|
|
- **README readiness 표가 있는 것을 없다고 적는다**
|
|
같은 리프의 반대 방향 사례이고 원인은 같다.
|
|
- **미배선 경계가 문서에만 있고 compile 경로에서 닫히지 않는다**
|
|
같은 형태의 절반 조립이다.
|
|
- **인터페이스끼리 비교하는 test는 구현의 부재를 못 본다**
|
|
이 사례가 그 규칙의 형태다.
|
|
|
|
## 문제
|
|
|
|
동기 진입점 인터페이스가 자신을 형 있는 API 로의 동기 진입점이라 소개하고, 반응형 인터페이스가 그 짝이다.
|
|
|
|
두 인터페이스는 각각 열두 접근자를 선언한다. 값과 해시와 리스트와 집합과 정렬 집합과 비트맵과 비트 필드와 확률적 집계와 지리와 스트림과 키와 배치다.
|
|
|
|
## 결론
|
|
|
|
둘 다 구현체가 없다.
|
|
|
|
리프 전체의 구현 선언을 전수 조사했다. 개별 표면은 전부 구현되어 있다. 동기 스물여섯 종과 반응형 열일곱 종이다.
|
|
|
|
그런데 두 진입점을 구현한다고 선언한 클래스는 0 건이다.
|
|
|
|
main 안에서 두 타입을 이름으로 부르는 곳도 없다. 유일한 참조가 반응형 인터페이스 자바독의 링크 하나와 대칭 테스트의 반사 두 줄이다.
|
|
|
|
결과적으로 이 SDK 를 쓰는 코드는 진입점을 얻을 수 없다.
|
|
|
|
열두 표면을 각각 어디선가 따로 받아야 하고, 진입점이 약속하는 하나의 객체에서 형 있는 표면 전체는 존재하지 않는다.
|
|
|
|
접근자를 추가하고 반응형 짝을 맞추는 규율은 실행되고 있다. 그 규율이 만드는 대상을 실제로 만드는 코드가 없다.
|
|
|
|
판정은 P2 다.
|
|
|
|
데이터 위험은 없다. 없는 타입은 잘못된 답을 주지 않는다.
|
|
|
|
위험은 API 계약의 신뢰다. 이 리프의 공개 표면 중 가장 먼저 읽히는 두 타입이 구현되지 않은 상태이고, 대칭 테스트가 그 사실을 가리지 못한다. 인터페이스끼리만 비교하기 때문이다.
|
|
|
|
같은 리프의 준비도 표 사례와 방향이 반대이면서 원인은 같다. 조립이 절반이다.
|
|
|
|
수정은 이미 존재하는 구현들을 묶는 두 클래스를 추가하고, 대칭 테스트에 두 진입점이 구현을 가진다는 검사를 더하는 것이다.
|
|
|
|
## 검증 환경
|
|
|
|
확인 방식 : 구현 선언 전수 조사와 이름 참조 검색
|
|
소스 수정 : x
|
|
|
|
## 재현 조건
|
|
|
|
원문은 final/evidence/raw/160 계열에 있다.
|
|
|
|
1. 두 진입점 인터페이스의 접근자 목록을 확인한다.
|
|
2. 리프 전체에서 구현 선언을 전수 조사한다.
|
|
3. 두 진입점을 구현하는 클래스가 있는지 센다.
|
|
4. main 안에서 두 타입 이름을 검색한다.
|
|
5. 대칭 테스트가 무엇과 무엇을 비교하는지 확인한다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
SDK가 선언한 두 진입점에 구현이 없다.
|
|
|
|
## SDK 가 선언한 두 진입점
|
|
|
|
:::evidence key="analysis-finding-a10-f003" alt="분석 문서 analysis/10-adapter-outbound-cache-redis.md 에서 이 기록의 근거 절을 그대로 잘라낸 15줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="analysis/10-adapter-outbound-cache-redis.md 발췌 — 15줄" zoom="true"
|
|
:::
|
|
|
|
## 데이터 위험은 없다
|
|
|
|
없는 타입은 잘못된 답을 주지 않는다. P2.
|
|
|
|
## 위험은 API 계약의 신뢰다
|
|
|
|
이 leaf의 공개 표면 중 가장 먼저 읽히는 두 타입이 구현되지 않은 상태이고, 대칭 test가 그 사실을 가리지 못한다 — 인터페이스끼리만 비교하기 때문이다. sub-scope 01의 §5와 방향이 반대이면서 원인은 같다: 조립이 절반이다.
|
|
|
|
## 수정
|
|
|
|
이미 존재하는 26개 구현을 묶는 `LettuceRedisOperations` / `LettuceReactiveRedisOperations` 두 클래스를 추가하고, `ApiParityTest`에 "두 facade는 구현을 가진다"는 검사를 더하는 것이다.
|
|
|
|
## 확인하지 못한 것
|
|
|
|
두 진입점이 과거에 구현체를 가졌는지 이력에서 확인하지 않았다.
|
|
|
|
<!-- body:end -->
|