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>
4.2 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 | messaging-schema-avro-c03 | 틀린 스키마로 디코딩해도 실패하지 않는다 | schema-and-wire-models | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:messaging-schema-avro-c03 | 2026-09-01 |
|
|
|
messaging-schema-avro |
틀린 스키마로 디코딩해도 실패하지 않는다
"does not fail — it produces plausible garbage"가 이 leaf의 모든 방어의 전제다. JSON이나 Protobuf와 달리 Avro는 잘못된 스키마로 디코딩해도 예외를 던지지 않는 경우가 있다.
관계
- 모드 enum을 분기 조건으로 쓰면 각 분기에 테스트를 둔다 같은 분석 리프에서 끌어낸 규칙이다.
- 컬렉션 순서가 계약이면 양쪽에서 같은 방향으로 적는다 같은 분석 리프에서 끌어낸 규칙이다.
- 안정 코드는 판단 단위로 정하고 구현 단위로 정하지 않는다 같은 분석 리프에서 끌어낸 규칙이다.
본문
"does not fail — it produces plausible garbage"가 이 leaf의 모든 방어의 전제다. JSON이나 Protobuf와 달리 Avro는 잘못된 스키마로 디코딩해도 예외를 던지지 않는 경우가 있다. single-object encoding에 헤더를 붙이지 않는 것도 명시적 결정이다 — "The framing that would carry a schema fingerprint belongs to the transport headers, where the platform already carries schema identity for every format, rather than being duplicated inside the Avro payload for this one format."
얕은 복사가 만든 구멍
:::evidence key="messaging-schema-avro-c03-diagram" alt="중첩 맵 쪽에 바깥 맵만 복사와 안쪽 맵은 호출자 소유가 빗금으로 놓이고 평탄화된 키 쪽에 두 레벨 모두 복사와 버전이 키의 일부가 놓인다" caption="얕은 복사가 만든 구멍" zoom="false" :::
생성자가 받는 것은 중첩 맵 Map<MessageType, Map<SchemaVersion, Schema>>이고, Map.copyOf는 바깥 레벨만 복사한다 — 안쪽 맵은 호출자 객체로 남아, 참조를 쥔 호출자가 생성 후에 버전을 추가·교체·제거하면 codec이 조용히 그것으로 인코딩하기 시작했다. (type, version) 키로 평탄화하면 두 레벨이 모두 복사되고 버전이 조회 identity의 일부가 된다. 이 결함이 위험했던 이유는 위와 곱해진다 — 스키마가 바뀌어도 디코딩이 실패하지 않고 그럴듯한 쓰레기를 낸다.
AvroRegistryBoundsTest 참조 위치
:::evidence key="messaging-schema-avro-c03" alt="코드베이스에서 AvroRegistryBoundsTest 를 검색한 출력 1줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="AvroRegistryBoundsTest 코드베이스 검색 — 1줄 · exit 0" zoom="true" :::
mutatingTheCallersMapAfterConstructionChangesNothing이 세 가지를 한 번에 확인한다 — 생성 후 추가한 버전은 미등록, 생성 후 추가한 타입도 미등록, 원래 등록한 스키마는 그대로. 평탄화가 MessageContractKey(schema-api)를 키로 쓰므로 §4.5의 2단 에러 구분도 자연히 따라온다.
direct encoder 한 줄에 방어가 걸려 있다
BoundedByteSink(schema-api)의 경계가 실제로 작동하려면 인코더가 증분적으로 써야 한다. EncoderFactory.get().binaryEncoder(...)는 버퍼링하므로 sink가 첫 write를 보기 전에 큰 레코드가 이미 할당된다. 즉 schema-api의 방어가 이 한 줄에 의존한다.
인코딩 전 검사 둘
payload가 GenericRecord인가 → AVRO_PAYLOAD_NOT_A_RECORD. schema.equals(record.getSchema())인가 → AVRO_SCHEMA_MISMATCH. 두 번째는 테스트가 이유를 적는다 — as("encoding v2 data under the v1 version would produce bytes nothing can decode").