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.0 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 | analysis-finding-a18-f001 | 출하되는 web 어댑터의 스위치가 활성화 모델 밖에 있다 | composition-root-and-bootstrap | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:analysis-finding-a18-f001 | 2026-09-01 |
|
|
|
출하되는 web 어댑터의 스위치가 활성화 모델 밖에 있다
이 어댑터는 두 런타임의 구성원이라 빌드 전용 예외가 아니다. 그런데 네 스위치가 조건 안의 문자열 리터럴로만 존재해 마스터 스위치 자바독이 경계하는 상태다. 다만 이 어댑터는 성질이 달라 그 모델에 그대로 넣을 수 없다.
관계
- 이 leaf의 리액티브 절반 29개 파일은 어떤 출하 배포에서도 활성화될 수 없다 같은 어댑터의 조립 미해결 사례다.
- 능력 프로퍼티 이름을 만드는 코드와 실제 게이트가 다른 접두사를 쓴다 같은 계열의 스위치 이름 사례다.
- 무엇을 스위치로 부를지 정하기 전에는 활성화 모델에 넣을 수 없다 이 사례가 그 규칙의 형태다.
문제
이 조립 루트는 선택 어댑터의 활성화를 명시적 스위치 모델로 다룬다.
전부 기본 꺼짐이고, 환경 키 파일에 행이 있고, 삼자 일치 테스트가 강제한다.
웹 어댑터가 그 모델 안에 있는지 확인했다.
결론
밖에 있다.
이 어댑터는 두 런타임의 구성원이므로 빌드 전용 예외에 해당하지 않는다.
그런데 그 네 스위치가 조건 안의 문자열 리터럴로만 존재한다.
마스터 스위치의 자바독이 경계하는 상태다. 조건 곳곳에 문자열 리터럴로 흩어지면 이름 변경이 조용한 활성화 변경이 된다는 것이다.
다만 이 어댑터는 다른 넷과 성질이 다르다.
두 전송 스위치가 없으면 참으로 처리되도록 되어 있어 기본이 켜짐이다. 그러므로 선택 어댑터가 아니다.
마스터 스위치가 규정하는 명시적 스위치 모델에 그대로 넣을 수 없다.
그리고 그 어댑터의 조립 자체가 미해결이다. 훑기에서 다섯 패키지를 빼고 넘겨받는 자동 설정을 만들지 않은 상태다.
기록하는 것은 순서다.
이 어댑터의 스위치를 활성화 모델에 넣는 것은 어떤 자동 설정이 무엇을 소유하는가를 먼저 정한 뒤에 할 수 있는 일이다.
지금은 무엇을 스위치로 부를지가 결정되지 않았다.
판정은 P3 다.
검증 환경
Spring Boot : 4.0.8 확인 방식 : 스위치 선언 위치 확인과 활성화 모델 대조 소스 수정 : x
재현 조건
원문은 final/evidence/raw/188 계열에 있다.
- 활성화 모델의 규칙 셋을 확인한다.
- 이 어댑터의 런타임 구성원 목록을 확인한다.
- 네 스위치가 어디에 선언되어 있는지 확인한다.
- 두 전송 스위치의 기본값을 확인한다.
- 마스터 스위치 자바독의 경계 문장을 읽는다.
본문
adapter-inbound-web은 두 런타임 멤버이므로 build-only 예외에 해당하지 않는다(§4.1).
MasterSwitch 참조 위치
:::evidence key="analysis-finding-a18-f001" alt="코드베이스에서 MasterSwitch 를 검색한 출력 17줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="MasterSwitch 코드베이스 검색 — 17줄 · exit 0" zoom="true" :::
네 스위치가 문자열 리터럴로만 존재한다
backend.web.mvc.enabled · backend.web.webflux.enabled(둘 다 matchIfMissing=true, 기본 켜짐) · backend.web.budgets.enabled · app.web-platform.durable-operations.enabled가 MasterSwitch에도 env-keys.yaml 341개 키에도 없다. MasterSwitch의 javadoc이 경계하는 상태다 — "Spread across conditions as string literals, a rename becomes a silent activation change."
다만 web은 다른 넷과 성질이 다르다
MVC/WebFlux 스위치는 matchIfMissing = true로 기본 켜짐이므로 "옵션 어댑터"가 아니고, MasterSwitch가 규정하는 explicit switch 모델(전부 기본 꺼짐, env-keys.yaml에 행이 있고 삼자 일치 테스트가 강제)에 그대로 넣을 수 없다. 그리고 모듈 14 §8.1이 확인했듯 web의 조립 자체가 미해결이다.
기록하는 것은 순서다
web의 스위치를 활성화 모델에 넣는 것은 모듈 14 §8.1(어떤 자동설정이 무엇을 소유하는가)을 먼저 정한 뒤에 할 수 있는 일이다. 지금은 "무엇을 스위치로 부를지"가 결정되지 않았다. P3.
확인하지 못한 것
스위치 이름을 바꿔 조용한 활성화 변경이 일어나는지 재현하지 않았다.