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>
66 lines
3.1 KiB
Markdown
66 lines
3.1 KiB
Markdown
---
|
|
kind: PROJECT_DECISION
|
|
slug: grpc-stays-build-only-until-the-bridge-is-decided
|
|
title: gRPC 플랫폼은 build-only로 두고 애플리케이션 도달 경로를 먼저 정한다
|
|
topic: learning-transfer-between-families
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: decision:grpc-stays-build-only-until-the-bridge-is-decided
|
|
decisionStatus: ADOPTED
|
|
decidedOn: 2026-08-30
|
|
source:
|
|
- docs/adr/ADR-GRPC-001-platform-family-and-registry-shape.md
|
|
- src/config/architecture/modules.json
|
|
- src/grpc/CLAUDE.md
|
|
- docs/compatibility/grpc-support-matrix.md
|
|
- analysis/20-grpc-platform.md
|
|
---
|
|
|
|
# gRPC 플랫폼은 build-only로 두고 애플리케이션 도달 경로를 먼저 정한다
|
|
|
|
## 결정문
|
|
|
|
gRPC 가족의 18개 리프는 어떤 런타임 컴포지션에도 넣지 않고, 배선하려면 레지스트리를 먼저 바꾸고 게이트를 통과시켜야 한다.
|
|
|
|
## 판단 이유
|
|
|
|
messaging 가족은 스타터를 컴포지션 루트의 의존으로 넣었고, 그 결과 25개 리프가 출하 아티팩트에 실렸다. 배선되지 않은 코드가 배포에 포함되는 문제가 그때부터 실재하게 됐다.
|
|
|
|
gRPC 가족은 그 선을 넘지 않기로 했다. 그리고 그 결정을 규약이 아니라 레지스트리로 표현했다.
|
|
|
|
18개 리프 전부의 런타임 멤버십이 비어 있다
|
|
인바운드 gRPC 어댑터의 허용 의존 목록에 이 가족이 없다
|
|
|
|
배선하려면 멤버십을 먼저 바꾸고 런타임 모듈 멤버십 검증을 통과시켜야 한다. 즉 배선이 실수로 일어날 수 없다.
|
|
|
|
그리고 그 상태를 문서가 공시한다. 호환성 문서가 출시되지 않았고 빌드 전용이라고 적고, 블록의 안내 문서가 같은 상태를 서술한다. 이 점이 messaging 의 지원 매트릭스와 대비된다.
|
|
|
|
## 영향
|
|
|
|
감수하는 것
|
|
|
|
가족 전체가 어떤 배포에도 없다. 18개 리프의 코드는 컴파일되고 테스트되지만 실행되지 않는다.
|
|
|
|
그 상태에서 발견되는 결함의 심각도를 판정하기 어렵다. 프로덕션 영향이 0 이므로 전부 낮아 보이지만, 배선되는 날 한꺼번에 나타난다.
|
|
|
|
릴리스 게이트와 시작 검증기가 배선되지 않은 채로 남았다. 배선하는 날 그것들도 함께 연결해야 한다.
|
|
|
|
얻는 것
|
|
|
|
배선되지 않은 코드가 출하 아티팩트에 실리지 않는다.
|
|
|
|
상태가 레지스트리에 있으므로 실수로 넘어갈 수 없고, 넘어가려면 게이트가 막는다.
|
|
|
|
운영 문서가 실제 상태와 일치한다.
|
|
|
|
## 근거
|
|
|
|
- **두 번째 플랫폼이 첫 번째의 bridge 부재는 막고 게이트 배선은 옮기지 않았다**
|
|
이 결정이 무엇을 막았고 무엇을 남겼는지 보여 주는 사례다.
|
|
- **레지스트리로 표현된 규칙은 전이되고 CI로 표현된 규칙은 전이되지 않는다**
|
|
이 결정이 레지스트리로 표현된 이유를 설명한다.
|
|
- **릴리스 게이트가 읽는 증거를 아무도 생산하지 않는다**
|
|
배선하는 날 함께 해결해야 할 항목이다.
|
|
|