Files
document-haness/docs/TechLog/tech-log-studio/failure-drawn-as-absence/case/case-it-said-there-were-no-open-questions.md
T
DongHyeonkaandClaude Opus 5 b1653dbba8 docs(TechLog): 주제 7~10 을 다시 쓴다
주소가 게시 시점에 굳어 저장되는 구조, 축 링크를 두 번 옮긴 순서, 한글 slug 가
간헐적으로 보인 두 가지 어긋남을 표로 갈랐다. 화면이 실패를 없음으로 그릴 때 작성
도구에서 왜 더 오래 숨는지, Promise.all 이 거절과 던짐에서 다른 경로를 타는 이유를
채웠다. CSS module 이 왜 전역 규칙에 닿지 않는지, 403 과 404 가 원인을 어떻게
좁혔는지도 적었다.

link-audit.py 를 감사 Case 의 evidence 로 걸어 배정한 증거 하나를 메웠다.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 19:06:20 +09:00

4.3 KiB

kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source
kind slug title topic topicName project status lastVerifiedOn sourceRevision source
CASE it-said-there-were-no-open-questions 「이 프로젝트에 열린 질문이 없습니다」 — 실제로는 넷이 있었다 failure-drawn-as-absence 실패를 없음으로 그린다 TechLog 게시 전 2026-09-04 tech-log@2026-09-02
final/document.md#§10.1

「이 프로젝트에 열린 질문이 없습니다」 — 실제로는 넷이 있었다

홈 「지금 집중하는 것」 편집기가 「이 프로젝트에 열린 질문이 없습니다」라고 적었다. 실제로는 넷이 있었고 공개 사이트에도 나오고 있었다. 편집기가 질문과 결정을 못 읽으면 빈 배열로 삼키고 있었다.

관계

  • 화면은 못 읽은 것을 없다고 말하지 않는다 이 사건에서 굳힌 규칙이다.
  • 계약에 선언만 있고 구현이 없어 화면 다섯 곳이 비어 있었다 못 읽은 원인이 그 기록에 있다 — 컨트롤러가 없었다.
  • 한 칸의 실패가 옆 칸을 끌고 내려갔다 같은 편집기에서 난 다른 부류의 실패다.

문제

홈 편집기에서 「지금 집중하는 것」에 걸 질문을 고르려 했다. 목록이 비어 있고 「이 프로젝트에 열린 질문이 없습니다」가 적혀 있었다.

같은 프로젝트의 공개 사이트에는 질문 넷이 나오고 있었다.

결론

편집기가 질문과 결정 목록을 못 읽으면 빈 배열로 삼키고 있었다. 서버는 404 를 주고 있었다 — 그 두 연산에 컨트롤러가 없었다.

작성자에게는 「아직 안 쓴 것」으로 읽힌다.

거짓말을 하느니 못 읽었다고 말한다.

못 읽었을 때 못 읽었다고 적게 고쳤다. 같은 판단을 주제 탭에도 적용했다.

검증 환경

tech-log-frontend : 7acde27 · 3bb724b tech-log-backend : 911e8ba — 없던 두 컨트롤러를 구현 확인 방식 : 편집기 목록과 공개 사이트의 같은 프로젝트를 대조

재현 조건

  1. 프로젝트에 Open Question 을 하나 이상 게시한다
  2. 그 목록을 주는 연산을 서버에서 막는다
  3. 홈 편집기를 연다 — 옛 코드에서는 「없습니다」가, 지금은 못 읽었다는 문구가 나온다

본문

빈 배열이 두 가지를 뜻했다

편집기는 질문 목록을 받아 고를 수 있게 그린다. 목록이 비면 「이 프로젝트에 열린 질문이 없습니다」를 적는다.

요청이 실패했을 때도 빈 배열이 되고 있었다. 그래서 「없다」와 「못 읽었다」가 같은 화면이 됐다.

서버는 404 를 주고 있었다. 그 두 목록 조회에 컨트롤러가 없었고, 계약에는 선언돼 있어 프론트가 그것을 믿고 불렀다.

작성자가 무엇으로 읽었나

작성자는 자기가 쓴 것과 화면을 대조한다. 화면이 「없습니다」라고 하면 아직 안 썼거나 게시하지 않았다고 읽는다.

이 경우에는 넷이 있었고 공개 사이트에도 나오고 있었다. 두 화면이 같은 데이터베이스를 보는데 한쪽만 비어 있었으므로, 공개 사이트를 함께 보지 않으면 알아챌 방법이 없었다.

작성 도구에서 이 부류가 특히 오래 숨는다. 읽기 전용 화면이면 방문자가 「데이터가 없나 보다」로 넘어가지만, 작성 도구에서는 그 오독이 곧바로 작업 판단이 된다 — 없다고 읽으면 다시 쓰게 된다.

못 읽었다고 적는다

거짓말을 하느니 못 읽었다고 말한다.

요청이 실패하면 실패했다고 적고 0건은 0건이라고 적는다. 이 둘을 구분할 수 있어야 작성자가 다음에 무엇을 할지 정한다 — 실패면 다시 부르거나 서버를 보고, 0건이면 쓰면 된다.

같은 판단을 다른 화면에

주제 탭에도 같은 판단을 적용했다. 탭 하나를 못 받아도 탭 줄과 나머지 탭은 그대로 그리고, 못 받은 탭에는 못 받았다고 적는다.

탭 줄이 남는 것이 중요하다. 탭 줄까지 사라지면 그 주제가 없는 것처럼 보이고, 그러면 못 읽은 범위가 화면에서 더 넓어진다.

확인하지 못한 것

화면이 못 읽은 것을 없다고 그리는 곳을 전수로 세지 않았다. 고친 것은 홈 편집기와 주제 탭 둘이다.