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.3 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 | registry-column-too-short-for-its-own-path | 레지스트리 컬럼이 38자 경로에서 짧아 "더 짧은 경로를 적는" 우회를 유혹했다 | schema-ownership-and-capability-streams | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:registry-column-too-short-for-its-own-path | 2026-09-01 |
|
|
|
레지스트리 컬럼이 38자 경로에서 짧아 "더 짧은 경로를 적는" 우회를 유혹했다
능력 스키마 레지스트리의 스트림 경로 컬럼이 32자였다. 실제 스트림 경로가 그보다 길어 거절됐고, 오류 메시지는 컬럼 이름을 부르지 이유를 말하지 않았다.
관계
- 독립 Flyway 스트림과 baseline version 0 이 레지스트리가 기록하는 대상이다.
- 두 트리가 다 V1부터 번호를 매겨 공유 history가 하나를 건너뛸 수 있었다 스트림 경로가 길어진 이유와 연결된다.
문제
능력 스키마 레지스트리는 각 능력의 스키마 스트림 경로를 기록한다. 그 컬럼이 32자였다.
능력별 스트림 경로는 그보다 길다. 능력 이름과 디렉터리 구조가 경로에 들어가기 때문이다.
결론
컬럼이 자기가 기록해야 할 경로보다 짧았다.
이 상태의 위험은 실패 자체가 아니라 우회의 유혹이다. 오류가 컬럼 길이를 말하므로, 가장 쉬운 대응은 경로를 짧게 바꾸는 것이다. 그러면 경로가 구조를 반영하지 않게 되고 다음 능력에서 같은 문제가 다시 난다.
수정은 컬럼을 넓히는 것이었다. 그리고 두 위치가 같은 테이블을 만들기 때문에 양쪽 다 넓혀야 했다.
마이그레이션 헤더가 그 이유를 적는다. 한쪽으로만 마이그레이션한 배포는 여전히 32자를 넘는 스트림 경로를 거절하고, 그 오류는 이유가 아니라 컬럼 이름을 부른다는 것이다.
번호 선택에도 근거가 있다. 두 트리가 샘플 컴포지션에서 하나의 위치 목록으로 병합되므로 버전 공간을 공유한다. 샘플이 이미 몇 개 번호를 갖고 있어서 그것들을 피해야 했다. 중복 버전은 Flyway 가 해결하는 병합 충돌이 아니라 기동 거부다.
검증 환경
데이터베이스 : PostgreSQL 마이그레이션 도구 : Flyway 확인 방식 : 마이그레이션 헤더의 사후 기록 확인 소스 수정 : x
재현 조건
- 컬럼을 넓히는 마이그레이션의 헤더를 읽는다. 번호 선택 근거와 두 위치 문제가 적혀 있다.
- 원래 컬럼 정의를 확인한다.
- 같은 테이블을 만드는 다른 위치를 확인한다.
본문
schema_stream이 varchar(32)였고 작성 당시 모든 스트림에 맞았으며 'db/migration/jpa/notification-platform'(38자)에서 안 맞기 시작했다.
컬럼 폭이 맞지 않기 시작한 경로
:::evidence key="registry-column-too-short-for-its-own-path" alt="분석 문서 analysis/05-adapter-outbound-persistence-jpa.md 에서 이 기록의 근거 절을 그대로 잘라낸 3줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="analysis/05-adapter-outbound-persistence-jpa.md 발췌 — 3줄" zoom="true" :::
실패 모드가 나쁜 종류다
모든 면에서 올바른 등록이 value too long으로 마이그레이션 타임에 실패하고, 뻔한 우회책은 스트림의 실제 경로가 아닌 더 짧은 경로를 기록하는 것이며, 스키마가 어디서 왔는지에 대해 거짓말하는 레지스트리는 없는 것보다 나쁘다.
128로 넓힌 이유
capability_id가 이미 varchar(128)이고 하나의 bound가 두 개보다 추론하기 쉽다.
확인하지 못한 것
32자를 넘는 경로로 삽입해 거절을 재현하지 않았다. 이 기록은 마이그레이션 헤더에 근거한다.
없음