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>
2026-09-07 15:29:33 +09:00
parent 6955611439
commit f6c825e858
62 changed files with 6381 additions and 186 deletions
@@ -0,0 +1,65 @@
+---
+kind: REFERENCE
+slug: a-missing-contract-field-has-a-signature
+title: Studio 에서는 보이는데 공개 쪽만 비면 그 사이에 계약이 있다
+topic: values-lost-between-boundaries
+topicName: 값이 경계에서 사라진다
+project: TechLog
+status: 게시 전
+verifiedOn: 2026-09-04
+sourceRevision: tech-log@2026-09-02
+source:
+  - final/document.md#§5.6
+  - final/document.md#§5.5
+---
+
+# Studio 에서는 보이는데 공개 쪽만 비면 그 사이에 계약이 있다
+
+Studio 편집기에서는 값이 다 보이는데 공개 화면만 비어 있으면, 두 화면이 같은 DB 를 보고 있으므로 그 사이의 계약에 칸이 없다. 이 저장소에서 같은 신호가 여덟 번 같은 원인을 가리켰다.
+
+## 관계
+
+- **공개 Reference 가 통째로 비어 있었다 — 이름이 어긋났고 본문은 다른 테이블에 있었다**
+  이 신호가 처음 잡힌 사건이다.
+- **결정에는 상세 화면이 없어 목록 항목이 문서 전체를 실어야 했다**
+  화면 쪽에서 역으로 확인해야 했던 사건이다.
+- **한 경계를 고쳤으면 값의 여정 끝에서 확인한다**
+  칸을 더한 뒤 무엇을 확인할지가 그 기준에 있다.
+
+## 목적
+
+DB 에 값이 있는데 화면이 비어 있을 때, 어디를 먼저 볼지 정한다. 이 부류는 오류를 내지 않으므로 로그에서 출발하면 아무것도 나오지 않는다.
+
+## 규칙
+
+**Studio 에서는 보이고 공개 쪽만 비면 그 사이의 계약을 먼저 본다**
+두 화면이 같은 DB 를 보는데 한쪽만 비면, 다른 것은 그 사이에 놓인 계약이다.
+
+**화면이 그리는 칸을 먼저 적고 응답에 있는지 하나씩 맞춘다**
+응답에서 출발하면 없는 칸은 보이지 않는다. 상세 endpoint 가 없는 종류에서 특히 그렇다 — 목록 항목이 문서 전체를 실어야 한다.
+
+**칸을 더할 때 required 로 올릴지는 따로 판단한다**
+이미 나가 있는 응답에는 그 칸이 없다. required 로 올리면 배포 순서에 따라 검증이 깨진다.
+
+**값이 아니라 이름을 지키는 검사를 둔다**
+게이트웨이가 읽는 이름이 계약의 타입에 있는지를 묻는다. 값을 비교하는 검사는 픽스처를 게이트웨이가 읽는 이름으로 만들면 그대로 통과한다.
+
+## 적용 조건
+
+같은 데이터를 두 표면이 각자의 계약으로 읽고, 한쪽만 비어 보이는 화면. 작성 계약과 조회 계약이 나뉜 구조에서 걸린다.
+
+## 예외
+
+두 표면이 같은 계약을 쓰면 이 신호는 성립하지 않는다. 그때는 매퍼나 질의를 먼저 본다.
+
+저장 구조가 종류마다 다르면 계약이 아니라 조회가 원인일 수 있다. Reference 의 본문이 문서 본문 칸이 아니라 별도 테이블에 있던 것이 그 예다.
+
+## 예시
+
+공개 Reference 가 통째로 비었을 때 게이트웨이가 읽던 네 이름이 전부 계약에 없었다.
+
+프로젝트의 「주요 주제」는 테이블도 조인도 가능했는데 응답에 실을 칸이 없었다.
+
+질문 목록만 주제가 빠져 있어서 질문 줄의 맥락이 「· 프로젝트」로 시작했다. 지식 목록은 처음부터 그 칸을 싣고 있었다.
+
+프로젝트 목록 행에 slug 가 없었다. 다른 목록이 프로젝트를 가리킬 때 쓰는 것은 id 가 아니라 slug 다.
@@ -0,0 +1,64 @@
+---
+kind: REFERENCE
+slug: verify-at-the-end-of-the-value-journey
+title: 한 경계를 고쳤으면 값의 여정 끝에서 확인한다
+topic: values-lost-between-boundaries
+topicName: 값이 경계에서 사라진다
+project: TechLog
+status: 게시 전
+verifiedOn: 2026-09-04
+sourceRevision: tech-log@2026-09-02
+source:
+  - final/document.md#§17.1
+  - final/document.md#§5.2
+  - final/document.md#§6.6
+---
+
+# 한 경계를 고쳤으면 값의 여정 끝에서 확인한다
+
+값이 여러 경계를 갈아타는 구조에서 한 경계를 고치고 「고쳤다」고 판단해 세 번 틀렸다. 타입 검사도 단위 테스트도 「코드를 읽어 보니 맞다」도 전부 중간 지점이다. 배포본에서 그 값이 실제로 그려지는 곳까지 가서 확인한다.
+
+## 관계
+
+- **관계의 요약이 경계 세 곳을 지나며 사라졌다**
+  한 경계를 고치고 판단해 두 번 틀린 사건이다.
+- **공개 화면 한 줄이 그려지기까지 값이 지나는 경계 열한 개**
+  왜 중간 확인이 부족한지가 그 개념에 있다.
+- **TypeScript 가 검사를 놓아 주는 네 곳**
+  타입 통과가 반영의 증거가 아닌 이유가 그 개념에 있다.
+
+## 목적
+
+「고쳤다」는 판단이 틀리는 것을 막는다. 값이 열한 경계를 지나는 구조에서 한 경계만 보고 판단하면, 다음 경계가 같은 값을 다시 버려도 알 수 없다.
+
+## 규칙
+
+**고친 값이 실제로 그려지는 곳까지 가서 본다**
+배포본에서 그 화면을 열거나, 실제 요청을 보내 응답을 읽는다.
+
+**타입 검사 통과를 반영의 증거로 쓰지 않는다**
+메서드 매개변수의 bivariance, `as` 단언, 검사 대상이 없는 tsconfig 가 각각 통과시킨 사례가 있다.
+
+**게이트웨이를 실제로 불러 어떤 연산이 나가는지 확인한다**
+등록을 빠뜨린 연산은 옆 분기로 떨어지므로 서버는 정상 응답을 준다. 나가는 경로를 봐야 알 수 있다.
+
+**여정이 끝나는 곳을 먼저 정하고 시작한다**
+어디까지 가면 확인이 끝나는지 모르면 중간에서 멈추게 된다.
+
+## 적용 조건
+
+값이 계약·매퍼·포트를 여러 번 갈아타는 구조에서 「고쳤다」를 판단할 때. 계약을 소유한 저장소가 따로 있고 생성기를 지나 들어오면 특히 걸린다.
+
+## 예외
+
+경계가 하나뿐이거나 고친 그 곳이 여정의 끝이면 중간 확인으로 충분하다.
+
+값이 아니라 이름을 지키는 검사를 이미 뒀으면 그 검사가 여정의 한 구간을 대신한다. 다만 검사가 덮는 구간이 어디까지인지 적어 둔다.
+
+## 예시
+
+관계 요약을 세 번 고쳤다. 매번 화면을 보고 나서야 다음 경계가 버리는 것을 알았다.
+
+개념 삭제가 계속 질문 삭제 경로로 나갔다. 타입 검사가 통과해서 반영된 줄 알았고, 배포된 번들의 서버 로그에서 404 를 보고 알았다.
+
+CONCEPT 을 `deleteQuestion` 으로 되돌려 가드가 깨지는 것을 확인했다.