DongHyeonkaandClaude Opus 5
b1653dbba8
주소가 게시 시점에 굳어 저장되는 구조, 축 링크를 두 번 옮긴 순서, 한글 slug 가 간헐적으로 보인 두 가지 어긋남을 표로 갈랐다. 화면이 실패를 없음으로 그릴 때 작성 도구에서 왜 더 오래 숨는지, Promise.all 이 거절과 던짐에서 다른 경로를 타는 이유를 채웠다. CSS module 이 왜 전역 규칙에 닿지 않는지, 403 과 404 가 원인을 어떻게 좁혔는지도 적었다. link-audit.py 를 감사 Case 의 evidence 로 걸어 배정한 증거 하나를 메웠다. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
79 lines
4.3 KiB
Markdown
79 lines
4.3 KiB
Markdown
---
|
|
kind: REFERENCE
|
|
slug: say-you-could-not-read-it
|
|
title: 화면은 못 읽은 것을 없다고 말하지 않는다
|
|
topic: failure-drawn-as-absence
|
|
topicName: 실패를 없음으로 그린다
|
|
project: TechLog
|
|
status: 게시 전
|
|
verifiedOn: 2026-09-04
|
|
sourceRevision: tech-log@2026-09-02
|
|
source:
|
|
- final/document.md#§10.1
|
|
- final/document.md#§17.3
|
|
---
|
|
|
|
# 화면은 못 읽은 것을 없다고 말하지 않는다
|
|
|
|
목록이나 요약처럼 「비어 있음」이 정상값인 화면에서는 실패와 0건이 같은 모양으로 그려진다. 작성자는 그것을 자기가 아직 쓰지 않은 것으로 읽는다. 못 읽었으면 못 읽었다고 적는다.
|
|
|
|
## 관계
|
|
|
|
- **「이 프로젝트에 열린 질문이 없습니다」 — 실제로는 넷이 있었다**
|
|
이 규칙의 근거 사건이다.
|
|
- **한 칸의 실패가 옆 칸을 끌고 내려갔다**
|
|
실패가 어디까지 번지는지를 다룬 사건이다.
|
|
- **매퍼가 null 을 돌려주고 호출부가 걸러 내, 기록이 조용히 사라졌다**
|
|
실패가 아니라 항목이 사라진 변종이다.
|
|
|
|
## 목적
|
|
|
|
작성자가 「아직 안 썼다」와 「못 읽었다」를 구분할 수 있게 한다.
|
|
|
|
이 둘이 같은 화면이면 작성자는 다음에 무엇을 할지 정할 수 없다. 실패면 다시 부르거나 서버를 봐야 하고 0건이면 쓰면 되는데, 화면이 「없습니다」 하나로 답하면 뒤쪽으로 읽고 다시 쓰게 된다.
|
|
|
|
## 규칙
|
|
|
|
### 1. 요청이 실패하면 실패했다고 적는다
|
|
|
|
빈 배열로 삼키지 않는다. 0건과 실패는 다른 문구를 쓴다.
|
|
|
|
목록 응답을 받아 그리는 코드에서 실패 경로가 빈 배열을 만들면, 그 아래의 「비어 있으면 이 문구」 분기가 두 경우를 같은 화면으로 만든다. 실패를 빈 값으로 접는 지점을 없애야 한다.
|
|
|
|
### 2. 한 칸의 실패가 옆 칸을 끌고 내려가지 않게 한다
|
|
|
|
여러 목록을 하나로 묶어 기다리면 하나라도 거절되는 순간 전체가 거절된다. 성공한 응답이 있어도 쓸 수 없다.
|
|
|
|
따로 읽고 실패한 목록에만 적는다. 화면에 여러 묶음이 있으면 실패가 번질 수 있는 범위를 그 묶음 하나로 좁힌다.
|
|
|
|
### 3. 거절만 잡는 처리로는 부족하다
|
|
|
|
호출이 동기적으로 던지면 그 처리기를 지나지 않는다. 배열 리터럴 안에서 부르는 함수가 던지면 배열이 완성되지 않으므로, 거기에 붙인 거절 처리기도 붙을 대상이 없다.
|
|
|
|
던지는 경로도 함께 잡아야 한 칸의 실패가 화면 전체로 번지지 않는다.
|
|
|
|
### 4. 항목을 걸러 낼 때 걸러 낸 것을 세어 둔다
|
|
|
|
매퍼가 모르는 종류에 빈 값을 돌려주고 호출부가 그것을 거르면, 오류도 빈 줄도 남지 않고 목록 길이만 줄어든다.
|
|
|
|
목록에 몇 개가 있어야 하는지 아는 사람만 알아챌 수 있다. 공개 화면에서는 그것을 아는 사람이 작성자뿐이다.
|
|
|
|
## 적용 조건
|
|
|
|
- 목록·요약·카운트처럼 「비어 있음」이 정상값이라 실패와 구분되지 않는 화면을 만들 때
|
|
- 작성 도구를 만들 때. 작성자가 자기 작업물과 화면을 대조하므로 오독이 곧바로 작업 판단이 된다
|
|
- 한 화면이 여러 목록을 함께 받아 그릴 때
|
|
- 매퍼가 모르는 값에 빈 값을 돌려주고 호출부가 그것을 거를 때
|
|
|
|
## 예외
|
|
|
|
- 정말로 0건인 것과 못 읽은 것을 구분할 수 없는 화면이라면 그 구분을 먼저 만든다. 구분 없이 문구만 바꾸면 0건이 실패로 읽힌다.
|
|
- 읽는 사람이 그 데이터를 만들지 않는 화면에서는 실패를 화면 전체의 오류로 다뤄도 된다. 방문자에게는 어느 목록이 실패했는지가 할 일을 바꾸지 않는다.
|
|
|
|
## 예시
|
|
|
|
- 「이 프로젝트에 열린 질문이 없습니다」가 적혀 있는 동안 그 프로젝트에는 질문이 넷 있었고 공개 사이트에도 나오고 있었다
|
|
- 결정 목록만 404 인데 함께 묶어 읽은 질문 목록까지 「불러오지 못했습니다」가 됐다
|
|
- 탭 하나를 못 받아도 탭 줄과 나머지 탭은 그대로 그리고, 못 받은 탭에는 못 받았다고 적는다
|
|
- 매퍼가 모르는 종류에 빈 값을 돌려주고 호출부가 걸러 내, 질문과 개념이 목록에서 사라졌다
|