--- kind: CASE slug: a-list-item-had-to-carry-the-whole-document title: 결정에는 상세 화면이 없어 목록 항목이 문서 전체를 실어야 했다 topic: values-lost-between-boundaries topicName: 값이 경계에서 사라진다 project: TechLog status: 게시 전 lastVerifiedOn: 2026-09-04 sourceRevision: tech-log@2026-09-02 source: - final/document.md#§5.4 --- # 결정에는 상세 화면이 없어 목록 항목이 문서 전체를 실어야 했다 공개 결정 화면에서 제목 자리에 결정문 전문이 나오고, 요약이 없고, 줄바꿈이 전부 접히고, 영향과 근거가 늘 비어 있었다. 네 증상이 한 구조에서 나왔다 — 결정에는 상세 화면이 없고 공개 주소가 목록 위의 앵커다. 그래서 화면이 그리는 칸이 전부 목록 항목에 있어야 했다. ## 관계 - **Studio 에서는 보이는데 공개 쪽만 비면 그 사이에 계약이 있다** 이 사건이 그 신호의 예다. - **계약은 앵커라고 적었고 만드는 쪽은 경로를 만들었다** 같은 앵커 구조에서 난 주소 쪽 사건이다. - **관계의 요약이 경계 세 곳을 지나며 사라졌다** 같은 시기에 계약의 빈칸으로 난 다른 사건이다. ## 문제 결정은 상세 endpoint 가 없다. 공개 주소가 `/projects/{slug}/decisions#{slug}` 로 목록 위의 앵커다. 상세가 없으면 화면이 그리는 칸이 전부 목록 항목에 있어야 한다. 목록 항목에는 `title`·`summary`·`consequences`·`evidence` 가 빠져 있었다. ## 결론 네 증상이 전부 목록 항목의 빈칸에서 나왔다. 제목 자리 : statement 를 대신 썼다 요약 : 실을 칸이 없었다 줄바꿈 : 접혔다 영향과 근거 : 프론트가 빈 배열로 고정해 뒀다 DB 에는 작성자가 쓴 제목, 여러 줄 요약, 영향 4건이 그대로 있었다. 목록 항목이 화면이 그리는 칸을 전부 싣게 하고 네 곳을 이었다. ## 검증 환경 tech-log-design-package : 987c1b8 이후 tech-log-backend : 026460f 이후 tech-log-frontend : 31afb4d 이후 확인 방식 : DB 조회로 저장된 값을 확인하고 공개 화면과 대조 ## 재현 조건 1. Studio 에서 결정을 작성하고 제목·요약·영향을 채운다 2. 게시한 뒤 프로젝트의 결정 목록을 공개 화면에서 연다 3. 저장된 값과 화면에 그려진 값을 대조한다 ## 본문 ## 상세가 없으면 목록이 전부 실어야 한다 결정은 자기 화면을 갖지 않는다. 공개 라우트는 `/projects/{slug}/decisions` 하나이고, 개별 결정은 그 목록 위의 앵커로 간다. 이 구조에서는 화면이 그리는 칸이 전부 목록 항목에 있어야 한다. 상세를 부를 곳이 없기 때문이다. ## 네 증상이 한 원인이었다 `ProjectDecisionItem` 에 `title` 이 없어서 프론트가 `statement` 를 제목 자리에 썼다. 결정문은 한 문장이 아니라 문단일 수 있으므로 제목 자리에 전문이 들어갔다. `summary` 가 없어서 요약 줄이 비었다. `consequences` 와 `evidence` 가 없어서 프론트가 그 둘을 빈 배열로 고정해 뒀다. 줄바꿈은 다른 이유였다. 마크다운이 아닌 칸의 줄바꿈을 화면이 접고 있었다. ## 저장된 값은 그대로 있었다 DB 를 조회하면 작성자가 쓴 제목과 여러 줄 요약과 영향 4건이 있었다. 어느 것도 화면까지 오지 못했다. ## 화면 쪽에서 역으로 확인한다 이 부류는 응답에서 출발하면 보이지 않는다. 응답에 없는 칸을 찾는 일이기 때문이다. 화면이 그리는 칸을 먼저 적고 그 칸이 응답에 있는지 하나씩 맞춰야 한다. ## 확인하지 못한 것 저장된 값이 그대로였다는 것은 조회로 확인했다. 그 시점의 화면 캡처는 남기지 않았다.