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.0 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | verifiedOn |
|---|---|---|---|---|---|---|---|---|
| REFERENCE | check-which-duplicate-is-wired | 중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다 | duplicate-mechanisms | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | reference:check-which-duplicate-is-wired |
중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다
목적
같은 일을 하는 구현이 둘 있을 때 정교한 쪽을 읽고 판정해서, 실제로 도는 약한 쪽을 놓치는 것을 막는다.
규칙
-
조립된 쪽을 먼저 찾는다 어느 쪽이 스테레오타입을 갖는지, 어느 쪽이 빈으로 만들어지는지, 어느 쪽이 설정에서 지목되는지를 본다.
-
만들어지는 것과 호출되는 것을 나눠 센다 빈이 있다는 것과 그것을 주입받아 부르는 코드가 있다는 것은 다르다. 세 단계로 나눈다. 만들어지는가, 주입되는가, 호출되는가.
-
약한 쪽이 도는 경우가 흔하다 정교한 구현은 늦게 만들어지고 배선이 뒤따르지 않는 경우가 많다. 그동안 원래 있던 사본이 계속 돈다.
-
인프라 설정도 중복의 한쪽이다 같은 판정이 애플리케이션 코드와 프록시 설정에 각각 있으면, 도는 것은 대개 프록시 쪽이다.
-
정본을 정하는 것이 수정이다 둘 다 살려 두면 다음 사람이 어느 쪽을 고쳐야 하는지 모른다.
적용 조건
같은 개념의 구현이 둘 이상 발견되는 모든 경우
플랫폼과 애플리케이션이 한 저장소에 함께 있는 경우 특히
예외
의도적으로 계층별로 다른 강도를 두는 경우가 있다. 그때는 어느 계층이 무엇을 보장하는지가 문서에 있어야 하고, 약한 쪽이 강한 쪽을 우회하는 경로가 없어야 한다.
예시
전체 트랜잭션 재시도 코디네이터는 빈으로 만들어지고 주입받아 호출하는 코드가 0 이다.
웹푸시 구독 값은 클라이언트가 준 엔드포인트를 자기 private 검사로만 확인하고, 플랫폼의 목적지 정책을 지나지 않는다.
forwarded 헤더 신뢰 판정은 421 줄의 Java 정책과 Nginx 설정 양쪽에 있고, 도는 것은 Nginx 쪽이다.
outbox 는 두 스택으로 구현되어 있고 출하되는 것은 application-core 쪽이다.
관계
- 재시도 코디네이터는 빈이지만 그것을 어디에도 적용하지 않는다 두 번째 규칙이 필요한 사례다.
- 클라이언트가 준 엔드포인트가 SSRF 가드가 아니라 약한 private 사본을 지났다 세 번째 규칙의 사례다.
- forwarded 헤더 신뢰 판정이 Nginx에 있고 Java 정책 421 LOC은 대부분 참조되지 않는다 네 번째 규칙의 사례다.
- 조립 결함을 판정하려면 조립하는 쪽을 먼저 읽어야 한다 같은 계열의 상위 규칙이다.