docs(TechLog): 글감 56개를 기록으로 쓴다
주제 13개 · Case 28 · Concept 5 · Reference 15 · Question 4 · Decision 4. 계약의 노드마다 종류가 요구하는 칸을 채우고, 본문이 있는 두 종류에는 SSOT 가 이미 그려 둔 도식 셋(value-boundaries · decision-path-404 · topic-variant-model)을 tech-log-studio/ 로 옮겨 붙였다. 새로 그린 그림은 없다. 검사 셋 전부 통과한다. check_body.mjs 56 편 중 본문이 있는 33 편 PASS check_prose.mjs 56 편 error 0 check_evidence.mjs --repo 포함 문제 없음 verify-tech-log-tree.py 프로젝트 5 · error 0 · warn 0 인용한 코드블록은 전부 SSOT 에서 찾아 대조했다. check_evidence.mjs 가 본문의 각 줄과 source 앵커와 계약 제목을 다시 확인한다. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
DongHyeonka
co-authored by
Claude Opus 5
Claude Opus 5
parent
6955611439
commit
f6c825e858
+91
@@ -0,0 +1,91 @@
|
||||
---
|
||||
kind: CONCEPT
|
||||
slug: topic-variant-and-record-variant
|
||||
title: 축은 주제가 이름을 정하고, 기록은 종류와 아이디의 쌍으로 축에 걸린다
|
||||
topic: an-axis-inside-a-topic
|
||||
topicName: 주제 안의 축
|
||||
project: TechLog
|
||||
status: 게시 전
|
||||
basisVersion: tech-log-backend 2026-09-01 의 축 스키마 · record_variant 에 외래키 없음 · studio_validation 과 publication 이 쓰는 방식을 따름
|
||||
assets:
|
||||
- key: topic-variant-model
|
||||
file: ../../../final/assets/tech-log-studio/topic-variant-model.svg
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/db/topic-variant-rows.txt
|
||||
- ../../../final/evidence/raw/db/record-variant-links.txt
|
||||
sourceRevision: tech-log@2026-09-02
|
||||
source:
|
||||
- final/document.md#§14.1
|
||||
---
|
||||
|
||||
# 축은 주제가 이름을 정하고, 기록은 종류와 아이디의 쌍으로 축에 걸린다
|
||||
|
||||
주제 안의 축은 세 테이블로 표현된다. 주제가 축의 이름을 스스로 정하고, 축의 값들이 따로 있고, 어느 기록이 어느 축에 걸리는지를 종류와 아이디의 쌍으로 적는다. 기록이 종류마다 다른 테이블에 살기 때문에 그 쌍에 외래키를 걸지 못한다.
|
||||
|
||||
## 관계
|
||||
|
||||
- **주제를 넷으로 쪼개지 않고 주제 안에 축을 하나 뒀다**
|
||||
이 구조를 만든 결정이다.
|
||||
- **축 링크가 자기 자신을 가리켰고, 고친 뒤에는 백엔드를 먼저 배포했다**
|
||||
이 구조 위에 축 화면을 만든 사건이다.
|
||||
- **홈의 비교 구역이 세 번 바뀌었다**
|
||||
이 구조가 화면에서 어떻게 쓰이는지가 그 기록에 있다.
|
||||
|
||||
## 본문
|
||||
|
||||
<!-- body:start -->
|
||||
|
||||
## 세 테이블
|
||||
|
||||
```text
|
||||
topic (주제)
|
||||
├─ variant_label 축의 이름 — 주제마다 다르다
|
||||
│ 인증 경계 → 「구조」 / 조회 성능 → 「조회 전략」
|
||||
└─ topic_variant 축의 값들 (SPA, Mediator, BFF, Forward-Auth)
|
||||
└─ record_variant 어느 기록이 어느 축에 걸리는지 (kind, id) 쌍
|
||||
```
|
||||
|
||||
:::evidence key="topic-variant-model" alt="topic·topic_variant·record_variant 가 이어지고 record_variant 가 세 테이블을 가리키는 구조도" caption=" " zoom="true"
|
||||
:::
|
||||
|
||||
## 축 이름은 주제가 정한다
|
||||
|
||||
내부 이름은 축으로 고정하고, 화면에 보이는 이름은 주제가 자기 칸에 적는다. 인증 경계 주제는 「구조」, 조회 성능 주제는 「조회 전략」이다.
|
||||
|
||||
## 기록은 여러 축에 걸린다
|
||||
|
||||
한 기록이 여러 축에 걸릴 수 있다. PKCE 는 SPA 와 BFF 양쪽에 관계된다.
|
||||
|
||||
아무 축에도 걸리지 않은 기록은 그 주제의 공통 기록으로 읽는다. 「공통」이라는 축을 따로 만들지 않는다.
|
||||
|
||||
## 외래키가 없다
|
||||
|
||||
`record_variant` 는 외래키를 갖지 않는다. 기록이 종류마다 다른 테이블에 살기 때문이다 — 문서·열린 질문·프로젝트 결정이 각각 다른 테이블이다. 종류와 아이디의 쌍으로만 가리킨다.
|
||||
|
||||
이 방식은 이 저장소에서 처음 쓰는 것이 아니다. 검증 상태와 게시 기록이 이미 같은 방식으로 기록을 가리키고 있었다.
|
||||
|
||||
## 사람이 쓰는 칸
|
||||
|
||||
주제의 논지, 축의 요약과 결론은 기록을 합쳐 자동으로 나오는 글이 아니다. 특히 결론은 비교표가 읽는 칸이라 기록의 요약 첫 줄을 잘라 쓰면 안 된다.
|
||||
|
||||
## 같은 구조가 다르게 보일 때
|
||||
|
||||
두 주제가 같은 구조를 쓰는데 축에 걸린 기록 수가 달라 다르게 보인다.
|
||||
|
||||
```text
|
||||
oauth-oidc-auth-boundary 축 이름 「구조」 축 4개
|
||||
spa ← CASE 1 + REFERENCE 3 (기록 4)
|
||||
mediator ← CASE 1 + QUESTION 2 + REFERENCE 2 (기록 5)
|
||||
bff ← CASE 1 + QUESTION 3 + REFERENCE 1 (기록 5)
|
||||
forward-auth ← CASE 1 + QUESTION 1 + REFERENCE 1 (기록 3)
|
||||
공통 기록: CONCEPT 1 + 결정 2 + REFERENCE 2
|
||||
|
||||
jpa-feed-query-performance 축 이름 「조회 전략」 축 3개
|
||||
derived-query ← CASE 1
|
||||
fetch-join ← CASE 1
|
||||
fetch-join-paging ← CASE 1
|
||||
```
|
||||
|
||||
축마다 기록이 하나씩이고 축 제목을 그 기록 제목과 비슷하게 적으면 「문서가 그대로 나온다」로 보인다. 구조 차이가 아니라 내용 양의 차이다.
|
||||
|
||||
<!-- body:end -->
|
||||
Reference in New Issue
Block a user