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