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>
130 lines
7.1 KiB
Markdown
130 lines
7.1 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: analysis-finding-a14-f019
|
|
title: 크로스 스택 게이트가 검증하는 조립은 픽스처의 조립이고, 플랫폼의 조립이 아니다
|
|
topic: web-inbound-and-http-surface
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: case:analysis-finding-a14-f019
|
|
evidenceCapturedOn: 2026-09-01
|
|
body: case-analysis-finding-a14-f019.body.md
|
|
assets:
|
|
- key: analysis-finding-a14-f019
|
|
file: ../../../final/evidence/rendered/analysis-finding-a14-f019.svg
|
|
evidence:
|
|
- ../../../final/evidence/raw/analysis-finding-a14-f019.txt
|
|
source:
|
|
- 원본 분석 절은 analysis/14-adapter-inbound-web.md#L1575 이다.
|
|
---
|
|
|
|
# 크로스 스택 게이트가 검증하는 조립은 픽스처의 조립이고, 플랫폼의 조립이 아니다
|
|
|
|
이 리프는 저장소에서 가장 정교한 검증 장치를 갖고 있다. 그 장치가 세우는 애플리케이션은 픽스처 애플리케이션이다. 증명되는 명제는 필터가 등록되면 계약이 지켜진다는 것이고, 플랫폼이 그 필터를 등록한다는 명제는 어떤 레인도 세우지 않는다.
|
|
|
|
## 관계
|
|
|
|
- **용량 보호 계층 전체가 자기 테스트 픽스처 안에서만 실행된다**
|
|
이 공백이 만든 결과 중 하나다.
|
|
- **멱등 실행 계층과 durable-operation 표면이 픽스처에서만 조립된다**
|
|
같은 공백이 만든 다른 결과다.
|
|
- **능력이 올바른가와 플랫폼이 능력을 설치하는가는 다른 질문이다**
|
|
이 사례가 그 규칙의 형태다.
|
|
|
|
## 문제
|
|
|
|
이 리프는 저장소에서 가장 정교한 검증 장치를 갖고 있다.
|
|
|
|
여섯 소스 집합과 다섯 사용자 정의 레인, 세 런타임 대칭 비교, 실제 역방향 프록시 컨테이너, 실제 소켓 고장 주입이다.
|
|
|
|
그 장치가 무엇을 증명하는지 확인했다.
|
|
|
|
## 결론
|
|
|
|
그 장치가 세우는 애플리케이션은 픽스처 애플리케이션이다.
|
|
|
|
예산 픽스처 애플리케이션이 예산 필터의 등록 빈을 손수 등록한다.
|
|
|
|
두 통합 테스트가 그 애플리케이션을 띄워 예산 계약을 세 런타임에서 증명한다.
|
|
|
|
증명되는 명제는 이 필터가 등록되면 예산이 지켜진다는 것이다.
|
|
|
|
플랫폼이 이 필터를 등록한다는 명제는 어떤 레인도 세우지 않는다. 그리고 플랫폼은 등록하지 않는다.
|
|
|
|
같은 구조가 조절과 멱등과 서버 전송 이벤트와 요청 컨텍스트에 반복된다.
|
|
|
|
빠진 검증은 하나다.
|
|
|
|
두 플랫폼 자동 설정이 세운 컨텍스트에 무엇이 있는지 확인하는 테스트다.
|
|
|
|
두 자동 설정 테스트가 존재하지만 자동 설정이 선언한 빈들을 확인할 뿐이다. 필터 사슬에 예산과 조절과 멱등이 있는지는 묻지 않는다.
|
|
|
|
자동 설정이 그것들을 선언하지 않으므로 확인할 것도 없다.
|
|
|
|
이 하위 범위에 P1 을 두는 이유는 이렇다.
|
|
|
|
결함은 픽스처에 있지 않다. 픽스처는 정확하고 계약은 잘 쓰였다.
|
|
|
|
결함은 검증 전략의 경계에 있다.
|
|
|
|
이 리프는 능력이 올바른가를 다섯 레인으로 묻고, 플랫폼이 능력을 설치하는가를 묻는 레인을 하나도 갖지 않는다.
|
|
|
|
그 공백이 다섯 개의 상위 발견이 초록 묶음 아래에서 성립할 수 있게 한 단일 원인이다.
|
|
|
|
권고는 픽스처를 하나 더 만드는 것이 아니다.
|
|
|
|
아무것도 등록하지 않는 픽스처를 하나 만드는 것이다. 부트 설정과 자동 설정 활성화만 있고 빈이 없는 애플리케이션을 띄워 필터 사슬과 컨트롤러 조언과 인터셉터 목록을 스냅숏으로 고정한다.
|
|
|
|
그 스냅숏이 두 미등록 사례를 즉시 드러내고 이후 회귀도 막는다.
|
|
|
|
이 리프에 기록과 비교 형태를 갖춘 계약 기록 장치가 이미 있으므로 형식은 있다.
|
|
|
|
## 검증 환경
|
|
|
|
Spring Boot : 4.0.8
|
|
확인 방식 : 레인이 띄우는 애플리케이션과 자동 설정 테스트 대상 확인
|
|
소스 수정 : x
|
|
|
|
## 재현 조건
|
|
|
|
원문은 final/evidence/raw/176 계열에 있다.
|
|
|
|
1. 레인 목록과 각 레인이 띄우는 애플리케이션을 확인한다.
|
|
2. 픽스처 애플리케이션이 무엇을 손수 등록하는지 읽는다.
|
|
3. 두 자동 설정 테스트가 무엇을 단언하는지 확인한다.
|
|
4. 자동 설정이 선언한 빈 목록을 확인한다.
|
|
5. 필터 사슬 구성을 확인하는 테스트가 있는지 검색한다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
이 leaf는 이 저장소에서 가장 정교한 검증 장치를 갖고 있다 — 여섯 소스셋, 다섯 커스텀 레인, 세 런타임 패리티 비교, 실제 Nginx 컨테이너, 실제 소켓 고장 주입.
|
|
|
|
## 이 leaf 가 갖춘 검증 장치
|
|
|
|
:::evidence key="analysis-finding-a14-f019" alt="분석 문서 analysis/14-adapter-inbound-web.md 에서 이 기록의 근거 절을 그대로 잘라낸 15줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="analysis/14-adapter-inbound-web.md 발췌 — 15줄" zoom="true"
|
|
:::
|
|
|
|
## 증명되는 명제가 다르다
|
|
|
|
`BudgetFixtureApplication`이 `FilterRegistrationBean<WebMvcBudgetFilter>`를 손수 등록한다. `JettyWebBudgetIT` · `ReactiveWebBudgetIT`가 그 애플리케이션을 띄워 예산 계약을 세 런타임에서 증명한다. 증명되는 명제는 "**이 필터가 등록되면** 예산이 지켜진다"이고, "플랫폼이 이 필터를 등록한다"는 명제는 어떤 레인도 세우지 않는다 — 그리고 §16.1이 확인했듯 플랫폼은 등록하지 않는다. 같은 구조가 스로틀(§16.1) · 멱등성(§20.1) · SSE(§36.1) · 요청 컨텍스트(§12.1)에 반복된다.
|
|
|
|
## 빠진 검증은 하나다
|
|
|
|
두 자동설정(`WebMvcPlatformAutoConfiguration` · `WebFluxPlatformAutoConfiguration`)이 세운 컨텍스트에 무엇이 있는지 확인하는 테스트. 두 `*AutoConfigurationTest`(각 112줄)가 존재하지만 자동설정이 **선언한** 빈들을 확인할 뿐, 필터 체인에 예산·스로틀·멱등성이 있는지는 묻지 않는다 — 자동설정이 그것들을 선언하지 않으므로 확인할 것도 없다.
|
|
|
|
## 결함은 픽스처가 아니라 검증 전략의 경계에 있다
|
|
|
|
이 leaf는 "능력이 올바른가"를 다섯 레인으로 묻고 "플랫폼이 능력을 설치하는가"를 묻는 레인을 하나도 갖지 않는다. 그 공백이 §12.1 · §16.1 · §20.1 · §36.1 · §40.1 다섯 개의 P1/P2가 초록색 스위트 아래에서 성립할 수 있게 한 단일 원인이다. P1.
|
|
|
|
## 권고
|
|
|
|
픽스처를 하나 더 만드는 것이 아니라, **아무것도 등록하지 않는** 픽스처를 하나 만든다 — `@SpringBootConfiguration` + `@EnableAutoConfiguration`만 있고 `@Bean`이 없는 애플리케이션을 띄워 필터 체인·컨트롤러 조언·인터셉터 목록을 스냅샷으로 고정한다. `WebPlatformContractRecording`이 이미 기록·비교 형태를 갖고 있으므로 형식은 있다.
|
|
|
|
## 확인하지 못한 것
|
|
|
|
빈 픽스처를 만들어 스냅숏을 떠 보지 않았다. 문서 작업 범위에서 테스트를 추가하지 않는다.
|
|
|
|
<!-- body:end -->
|