Files
document-haness/docs/clean-architecture-backend-template/tech-log-studio/contract-domain-and-bounds/case/case-grpc-advanced-streaming-f01.md
T
DongHyeonkaandClaude Opus 5 b2963105a8 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>
2026-09-04 22:51:59 +09:00

3.7 KiB

kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source, module, priority
kind slug title topic project status sourceRevision rootTreeNode evidenceCapturedOn assets evidence source module priority
CASE grpc-advanced-streaming-f01 클래스가 비판한 무제한 증가를 형제 맵이 그대로 한다 contract-domain-and-bounds clean-architecture-backend-template 게시 전 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 case:grpc-advanced-streaming-f01 2026-09-01
key file
grpc-advanced-streaming-f01 ../../../final/evidence/rendered/grpc-advanced-streaming-f01.svg
../../../final/evidence/raw/grpc-advanced-streaming-f01.txt
원본 분석 절은 analysis/grpc/grpc-advanced-streaming.md#L125 이다.
grpc-advanced-streaming P3

클래스가 비판한 무제한 증가를 형제 맵이 그대로 한다

클래스 javadoc 이 집합 방식을 거부한 이유가 무제한 증가다 — "A set grows without bound for the life of a session". 체크포인트는 그 비판을 지킨다.

문제

클래스 javadoc 이 집합 방식을 거부한 이유가 무제한 증가다 — "A set grows without bound for the life of a session".

체크포인트는 그 비판을 지킨다.

결론

세션당 항목 하나이고 순번만 앞으로 간다.

형제 맵은 지키지 않는다.

제거는 endSession 뿐이고, 그때 그 세션의 접두를 가진 키를 전부 지운다.

그러므로 결과 참조를 기록하는 세션에서는 적용된 메시지 수만큼 항목이 쌓인다.

상한도 만료도 없다.

클래스 javadoc 은 다르게 말한다.

작은 창이 코드에 없다.

체크포인트가 앞으로 가도 그 이전 결과들은 남는다.

검증 환경

OpenJDK : 21.0.12 java -version 으로 확인 Gradle : 9.0.0 src/gradle/wrapper/gradle-wrapper.properties 의 distributionUrl 로 확인 확인 방식 : 체크포인트와 형제 맵의 제거 경로 유무 대조, 클래스 javadoc 의 거부 근거 확인 소스 수정 : x

재현 조건

원문은 analysis/grpc/grpc-advanced-streaming.md#L125 에 있다.

본문

클래스 javadoc 이 집합 방식을 거부한 이유가 무제한 증가다 — "A set grows without bound for the life of a session".

javadoc 이 집합 방식을 거부한 이유

:::evidence key="grpc-advanced-streaming-f01" alt="분석 문서 analysis/grpc/grpc-advanced-streaming.md 에서 이 기록의 근거 절을 그대로 잘라낸 15줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="analysis/grpc/grpc-advanced-streaming.md 발췌 — 15줄" zoom="true" :::

체크포인트는 그 비판을 지키고 형제 맵은 지키지 않는다

체크포인트는 세션당 항목 하나이고 순번만 앞으로 간다. 형제 맵의 제거는 endSession 뿐이고, 그때 그 세션의 접두를 가진 키를 전부 지운다. 그러므로 결과 참조를 기록하는 세션에서는 적용된 메시지 수만큼 항목이 쌓인다 — 상한도 만료도 없다. 클래스 javadoc 은 다르게 말한다: 작은 창이 코드에 없다.

실제로 필요한 창은 좁다

판정이 alreadyApplied(sequence) 로 재생을 결정하고, 재생 응답에 쓰이는 것은 그 순번의 결과 하나다. 체크포인트보다 한참 뒤처진 순번의 결과가 필요할 상황은 재개 직후의 좁은 구간뿐이다. 수정은 창을 실제로 만드는 것이다 — 세션당 최근 N개만 유지하거나, 체크포인트가 앞으로 갈 때 그보다 오래된 항목을 지운다. 후자가 자바독의 서술과 정확히 같다.

확인하지 못한 것

장시간 실행으로 이 맵의 증가를 측정하지 않았다. 제거 경로가 없다는 것으로 판정했다.