주제 11~13 을 다시 쓰고, Case 가 얇은 것들을 저장소에서 실물을 확인해 채웠다.
§13.4 ManagementClientSafeMessages — 삭제 관련 코드 여섯의 고정 문구와
원문 메시지를 내보내지 않는 이유(javadoc)
§16.1 다섯 참조가 전부 DOCUMENT_IN_USE 하나로 나가고, SSOT 가 인용한 영어 문장은
DeleteDocumentDraftUseCase 안에 남는 진단 메시지라 밖으로 나가지 않는다
§13.6 romanizeSyllable 실물과 음운 변동을 뺀 이유, 문서 slug 와 같은 정규식을 쓰는 이유
§15.4 check:types 가 도는 tsconfig 여섯 — app·node·test·recipes·web-worker·service-worker
SSOT 62,643 → 67,526 자. 인용한 코드는 전부 저장소에서 찾아 대조했다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
58 lines
3.4 KiB
Markdown
58 lines
3.4 KiB
Markdown
---
|
|
kind: PROJECT_DECISION
|
|
slug: an-axis-inside-a-topic-not-four-topics
|
|
title: 주제를 넷으로 쪼개지 않고 주제 안에 축을 하나 뒀다
|
|
topic: an-axis-inside-a-topic
|
|
topicName: 주제 안의 축
|
|
project: TechLog
|
|
status: 게시 전
|
|
decisionStatus: ADOPTED
|
|
decidedOn: 2026-09-01
|
|
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
|
|
- final/document.md#§14.3
|
|
---
|
|
|
|
# 주제를 넷으로 쪼개지 않고 주제 안에 축을 하나 뒀다
|
|
|
|
「브라우저와 서버 사이 credential 책임을 어디에 둘 것인가」 하나의 질문에 네 구조를 만들어 봤는데, 기록에 붙는 축이 주제와 프로젝트뿐이라 그 넷을 담을 데가 없었다. 주제를 넷으로 쪼개는 대신 주제 안에 축을 하나 뒀다.
|
|
|
|
## 근거
|
|
|
|
- **축은 주제가 이름을 정하고, 기록은 종류와 아이디의 쌍으로 축에 걸린다**
|
|
이 결정을 담은 스키마다.
|
|
- **홈의 비교 구역이 세 번 바뀌었다**
|
|
이 결정이 화면에 어떻게 나타났는지가 그 기록에 있다.
|
|
- **축의 결론 문장과 기록 수는 기록을 붙여도 따라오지 않는다**
|
|
이 결정으로 감수한 비용이 그 질문에 있다.
|
|
|
|
## 결정문
|
|
|
|
한 질문에 여러 구조를 만들어 비교하는 경우, 주제를 그 수만큼 쪼개지 않고 주제 안에 축을 하나 둔다.
|
|
|
|
축의 이름은 주제가 정하고, 기록은 여러 축에 걸릴 수 있으며, 아무 축에도 걸리지 않은 기록은 그 주제의 공통 기록으로 읽는다.
|
|
|
|
## 판단 이유
|
|
|
|
주제를 넷으로 쪼개면 네 구조가 함께 쓰는 기록을 어디에 둘지 애매해진다. PKCE·CSRF·Authorization Code 가 그런 기록이다. 어느 한 주제에 넣으면 나머지 셋에서 그 기록에 닿을 수 없고, 넷에 복사하면 같은 글이 넷이 된다.
|
|
|
|
비교도 어려워진다. 네 주제가 나란히 서면 그것이 같은 질문의 네 답이라는 것을 화면이 말하지 못하고, 독자는 목록에서 넷을 각각 열어 봐야 한다.
|
|
|
|
축을 주제 안에 두면 공통 기록은 축을 고르지 않고 두면 되고, 여러 구조에 걸치는 기록은 여러 축에 건다. 화면은 축을 나란히 세워 비교로 그린다.
|
|
|
|
축 이름을 주제가 정하게 한 것은 주제마다 비교하는 것이 다르기 때문이다. 인증 경계 주제는 credential 을 어디에 두느냐로 갈리고 조회 성능 주제는 같은 데이터를 어떻게 읽느냐로 갈린다.
|
|
|
|
## 영향
|
|
|
|
축의 이름·요약·결론이 기록에서 자동으로 나오지 않는다. 주제의 논지와 축의 요약·결론은 사람이 쓰는 칸이고, 기록을 스무 개 붙여도 그 문장은 누가 고치기 전까지 그대로다.
|
|
|
|
홈의 비교 구역에서 줄은 문서가 아니라 축이다. 줄을 늘리려면 Studio 에서 축을 추가해야 한다.
|
|
|
|
기록이 어느 축에 걸리는지를 담는 표에 외래키를 걸 수 없다. 기록이 종류마다 다른 테이블에 살기 때문이고, 그래서 기록을 지울 때 그 쌍을 함께 지우는 것은 코드가 한다.
|
|
|
|
축이 붙은 기록 수가 적으면 「문서가 그대로 나온다」로 보인다. 축마다 기록이 하나씩이고 축 제목을 그 기록 제목과 비슷하게 적으면 그렇게 읽힌다. 구조 차이가 아니라 내용 양의 차이다.
|