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>
3.7 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source, module
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | module | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CONCEPT | adapter-inbound-graphql-c09 | 선언한 전송 프로파일과 실제 응답을 만드는 쪽이 다르다 | composition-and-lifecycle-models | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:adapter-inbound-graphql-c09 | 2026-09-01 |
|
|
|
adapter-inbound-graphql |
선언한 전송 프로파일과 실제 응답을 만드는 쪽이 다르다
http 패키지 19개 파일 중 자동설정이 값으로 소비하는 둘을 빼면 나머지는 실행되지 않는다. 실제로 응답을 만드는 것은 Spring GraphQL이다.
본문
http 패키지 19개 파일 중 자동설정이 값으로 소비하는 둘(GraphQlHttpProfile autoconf=2, GraphQlJsonStructurePolicy autoconf=4)을 빼면, 나머지는 실행되지 않는다.
응답을 실제로 만드는 쪽
:::evidence key="adapter-inbound-graphql-c09-diagram" alt="Spring GraphQL 경계 안에 상태 코드 규칙과 미디어 타입 협상이 들어 있고 http 패키지가 경계 밖에 빗금 상자로 놓인 구조" caption="응답을 실제로 만드는 쪽" zoom="false" :::
GraphQL-over-HTTP에서 상태 코드 규칙은 미디어 타입에 달려 있다 — application/json은 실행 오류에도 200을, application/graphql-response+json은 실제 상태를 쓴다. 그 규칙을 GraphQlHttpStatusMapper와 GraphQlAcceptHeader가 담고 있고, 실제로 응답을 만드는 것은 Spring GraphQL이다.
GraphQlHttpProfile 참조 위치
:::evidence key="adapter-inbound-graphql-c09" alt="코드베이스에서 GraphQlHttpProfile 를 검색한 출력 30줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="GraphQlHttpProfile 코드베이스 검색 — 30줄 · exit 0" zoom="true" :::
노출이 아니라 통제권의 문제다
Spring GraphQL 자신이 GraphQL-over-HTTP 스펙을 구현하므로 동작은 합리적이다. 잃는 것은 (a) 이 플랫폼이 선언한 프로파일(V1)이 실제 동작과 일치한다는 보장, (b) 사전 파싱 한계 중 봉투 검증기에만 있는 부분, (c) "새 결과 종류가 임의 상태를 갖고 한 호출 지점에 생기는 것"을 막겠다는 단일 팩토리의 목적.
운영자가 문서대로 클라이언트를 쓸 때
운영자가 GraphQlPlatformConfigurationReport(§8.1을 고쳐 발행하게 된 뒤)에서 httpProfile=V1을 읽고 그 프로파일 문서대로 클라이언트를 작성한다. 실제 응답 상태와 미디어 타입은 Spring GraphQL이 정하며, 두 문서가 다른 지점에서 클라이언트가 깨진다.
두 갈래 권고
(a) 프레임워크 전송을 정본으로 인정하고 http 패키지에서 전송 기계를 제거한 뒤 GraphQlHttpProfile을 프레임워크 동작의 서술로 좁힌다. (b) WebGraphQlInterceptor(GraphQlPlatformWebInterceptor가 이미 그 자리에 있다)에서 봉투 검증과 응답 정책을 적용해 프로파일을 실제로 강제한다. 지금은 선언과 실행이 분리돼 있다.
무엇이 미배선인가
GraphQlAcceptHeader(151), GraphQlRequestEnvelopeValidator(152), GraphQlHttpResponseFactory(84), GraphQlMediaTypes(100), 그리고 봉투·결과·확장 정책 타입 470줄이 실행되지 않는다.