refactor: 문서 개선 중

2026-09-21 14:30:55 +09:00
parent c93cdea150
commit 805a18f486
1497 changed files with 525837 additions and 59152 deletions
@@ -23,7 +23,7 @@ source:
 - **계약은 앵커라고 적었고 만드는 쪽은 경로를 만들었다**
  같은 앵커 구조에서 난 주소 쪽 사건이다.
 - **관계의 요약이 경계 세 곳을 지나며 사라졌다**
-  같은 시기에 계약의 빈칸으로 난 다른 사건이다.
+  같은 시기에 계약의 빈칸으로 난 다른 사건이다. 여기서 요약은 공개 계약의 `ResolvedRelation.summary`다.

 ## 문제

@@ -7,6 +7,9 @@ topicName: 값이 경계에서 사라진다
 project: TechLog
 status: 게시 전
 lastVerifiedOn: 2026-09-04
+assets:
+  - key: summary-drop-path
+    file: ../../../final/assets/diagrams/summary-drop-path/summary-drop-path.svg
 sourceRevision: tech-log@2026-09-02
 source:
  - final/document.md#§5.2
@@ -15,7 +18,7 @@ source:

 # 관계의 요약이 경계 세 곳을 지나며 사라졌다

-관계 목록의 라벨을 고쳤는데 요약은 여전히 비어 있었다. 한 경계를 고치고 확인했더니 다음 경계가 버리고 있었고, 그것을 고치니 그다음이 버렸다. 세 번째는 계약에 담을 칸 자체가 없었다.
+공개 relation 목록의 라벨을 고쳤는데 `ResolvedRelation.summary`는 여전히 비어 있었다. 한 경계를 고치고 확인했더니 다음 경계가 버리고 있었고, 그것을 고치니 그다음이 버렸다. 세 번째는 계약에 담을 칸 자체가 없었다.

 ## 관계

@@ -28,7 +31,7 @@ source:

 ## 문제

-관계 목록은 한 줄에 대상의 종류와 작성자가 쓴 이유와 대상의 요약을 보인다. 라벨은 고쳤는데 요약 칸이 계속 비어 있었다.
+공개 relation 목록은 한 줄에 대상의 종류와 작성자가 쓴 이유와 대상의 요약을 보인다. 라벨은 고쳤는데 요약 칸이 계속 비어 있었다.

 계약에는 요약이 있었다. DB 에도 값이 있었다. 화면까지 오지 못했다.

@@ -63,6 +66,10 @@ tech-log-backend : 92679f5 이후

 ## 세 번 버려졌다

+이 그림은 열한 경계 전체가 아니라 이번 사고에서 `summary`가 실제로 끊긴 세 지점만 좁혀 본다.
+
+![summary가 계약에서 flattenRelations, ResolvedRelation, 화면 목록을 지나며 세 번 끊긴 경로](../../../final/assets/diagrams/summary-drop-path/summary-drop-path.svg)
+
 관계 목록의 라벨을 고치고 화면을 봤을 때 요약은 여전히 비어 있었다. 값이 지나는 경계를 하나씩 따라가니 세 곳에서 버려지고 있었다.

 ```text
@@ -25,7 +25,7 @@ source:
 - **공개 Reference 가 통째로 비어 있었다 — 이름이 어긋났고 본문은 다른 테이블에 있었다**
  이 경계 중 두 곳에서 값이 사라진 사건이다.
 - **관계의 요약이 경계 세 곳을 지나며 사라졌다**
-  한 값이 연달아 세 경계에서 버려진 사건이다.
+  한 값이 연달아 세 경계에서 버려진 사건이다. 여기서 관계 요약은 `ResolvedRelation.summary`를 뜻한다.
 - **한 경계를 고쳤으면 값의 여정 끝에서 확인한다**
  이 경계 수가 그 규칙의 근거다.

@@ -51,7 +51,7 @@ PostgreSQL 테이블
                                               └─ 화면 컴포넌트
 ```

-![저장·백엔드 조립·HTTP envelope·프론트엔드 조립·화면 다섯 묶음을 세 저장소 구역으로 나눠 이은 흐름도](../../../final/assets/diagrams/value-boundaries/value-boundaries.svg)
+![열한 개 경계를 저장·백엔드 조립·전선·프론트엔드 조립·화면의 다섯 구간으로 묶은 흐름도](../../../final/assets/diagrams/value-boundaries/value-boundaries.svg)

 저장 쪽에 둘, 백엔드 조립에 넷, 전선에 하나, 프론트엔드 조립에 셋, 화면에 하나다. 저장소 경계로 보면 백엔드가 여섯, 전선이 하나, 프론트엔드가 넷이다.

@@ -15,7 +15,7 @@ source:

 # Studio 에서는 보이는데 공개 쪽만 비면 그 사이에 계약이 있다

-Studio 편집기에서는 값이 다 보이는데 공개 화면만 비어 있으면, 두 화면이 같은 DB 를 보고 있으므로 그 사이의 계약에 칸이 없다. 이 저장소에서 같은 신호가 여덟 번 같은 원인을 가리켰다.
+Studio 편집기에서는 값이 다 보이는데 공개 화면만 비어 있다면, 작성과 공개 사이의 계약 경계를 먼저 확인할 만한 강한 신호다. 이 저장소에서는 같은 신호가 여덟 번 계약 누락을 가리켰지만, 저장 구조가 종류별로 다른 경우에는 조회 로직이 원인일 수 있다.

 ## 관계

@@ -36,7 +36,7 @@ Studio 편집기에서는 값이 다 보이는데 공개 화면만 비어 있으

 ### 1. Studio 에서는 보이고 공개 쪽만 비면 그 사이의 계약을 먼저 본다

-두 화면이 같은 데이터베이스를 보는데 한쪽만 비면, 다른 것은 그 사이에 놓인 계약이다. 작성 쪽은 작성 계약을 지나고 조회 쪽은 조회 계약을 지난다. 이 저장소에서 같은 신호가 여덟 번 같은 원인을 가리켰다.
+두 화면이 같은 데이터베이스를 보는데 한쪽만 비면, 먼저 두 화면 사이의 계약 차이를 확인한다. 작성 쪽은 작성 계약을 지나고 조회 쪽은 조회 계약을 지난다. 이 저장소에서는 같은 신호가 여덟 번 계약 누락을 가리켰다. 이름과 계약이 맞는데도 값이 비면 종류별 저장 구조와 조회 로직으로 범위를 옮긴다.

 ### 2. 화면이 그리는 칸을 먼저 적고 응답에 있는지 하나씩 맞춘다

@@ -21,7 +21,7 @@ source:
 ## 관계

 - **관계의 요약이 경계 세 곳을 지나며 사라졌다**
-  한 경계를 고치고 판단해 두 번 틀린 사건이다.
+  한 경계를 고치고 판단해 두 번 틀린 사건이다. 여기서 요약은 공개 계약의 `ResolvedRelation.summary`다.
 - **공개 화면 한 줄이 그려지기까지 값이 지나는 경계 열한 개**
  왜 중간 확인이 부족한지가 그 개념에 있다.
 - **TypeScript 가 검사를 놓아 주는 네 곳**