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>
2.4 KiB
2.4 KiB
통과 기준이 되는 글 여섯 편
우아한형제들 기술블로그에서 가져왔다. 이 저장소의 글이 이 정도로 읽히면 통과다.
| 파일 | 원문 | 무엇을 보나 |
|---|---|---|
17386-kafka-in-our-team.md |
17386 | 개념을 모르는 독자를 데리고 가는 법. 용어 정의 → 우리 사례 |
20161-elasticsearch-query-optimization.md |
20161 | 현상 → 원인 분석 → 해결 → 개선 결과를 다섯 번 반복 |
22396-real-distance-system.md |
22396 | 왜 이 문제가 어려운지를 수로 먼저 세운다. 시도 1 실패 → 시도 2 |
7835-member-event-architecture.md |
7835 | 같은 코드를 네 번 고쳐 보이며 「왜 아직 부족한가」를 쌓는다 |
13569-10x-faster-batch.md |
13569 | 수정 전/후 코드를 나란히. 빨라져서 생긴 문제까지 |
23625-rdb-task-queue.md |
23625 | 요구사항 목록 → 표 설계 → 트레이드오프 (본문 일부) |
23625 는 페이지가 자바스크립트로 그려져 본문 일부만 받았다. 나머지 다섯은 전문이다.
이 여섯 편의 공통 골격
여섯 편이 서로 다른 주제인데도 같은 뼈대를 쓴다. ../references/article-shape.md 가 그 뼈대를
규칙으로 적은 것이다.
- 누가 읽으면 좋은지, 무엇을 알아야 하는지 먼저 말한다 — 17386 의 「누가 읽으면 좋을까」
- 문제를 수로 세운다 — 22396 의 「분당 20만 건 × 6 = 120만 건, 초당 2만 TPS」
- 코드를 보여 준다. 이름과 줄 번호로 대신하지 않는다 — 13569 의 수정 전/수정 후 전문
- 틀린 시도를 지우지 않는다 — 22396 의 「시도 1. 데이터 압축」이 실패한 채로 남아 있다
- 결과를 수로 닫는다 — 20161 의 「980ms → 104ms」, 13569 의 「390분 → 30분」
- 감수한 것을 적는다 — 23625 의 「트레이드오프」, 22396 의 TTL 대 명시적 삭제 표
쓰지 않는 방법
이 글들을 흉내 내지 않는다. 문체를 베끼면 남의 목소리가 된다. 보는 것은 골격과 밀도다 — 독자가 모르는 것을 어디서 채워 주는가, 주장 하나에 근거를 몇 개 대는가, 코드를 언제 꺼내는가.