document-haness/docs/TechLog/tech-log-studio/values-lost-between-boundaries/case/case-a-list-item-had-to-carry-the-whole-document.md

kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source

kind	slug	title	topic	topicName	project	status	lastVerifiedOn	sourceRevision	source
CASE	a-list-item-had-to-carry-the-whole-document	결정에는 상세 화면이 없어 목록 항목이 문서 전체를 실어야 했다	values-lost-between-boundaries	값이 경계에서 사라진다	TechLog	게시 전	2026-09-04	tech-log@2026-09-02	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. 저장된 값과 화면에 그려진 값을 대조한다

본문

상세가 없으면 목록이 전부 실어야 한다

결정은 자기 화면을 갖지 않는다. 공개 라우트는 프로젝트의 결정 목록 하나이고, 개별 결정은 그 목록 위의 앵커로 간다.

앞선 종류들과 여기서 갈린다. Case 와 Reference 와 Question 은 상세 화면이 있어서 목록 항목이 가볍고 상세를 부르면 나머지가 온다. 결정에는 상세를 부를 곳이 없으므로 화면이 그리는 칸이 전부 목록 항목에 있어야 한다.

종류마다 사는 곳이 다르다

편집 화면이 고르는 유형 다섯은 하나의 애그리거트가 아니다. 각 유형이 자기 애그리거트와 테이블을 갖고, 문서 세 종류만 한 테이블을 공유한다.

결정은 그중 문서 테이블에 살지 않는다. 프로젝트 안에서만 읽히므로 자기 목록도 자기 상세 화면도 없고, 공개 주소가 프로젝트 결정 목록 위의 앵커다.

종류별 목록 주소 표에서도 결정만 다른 규칙을 따른다. 그 표의 javadoc 이 그것을 적어 둔다.

결정은 프로젝트 안에서만 읽히므로 자기 목록이 없다. 그 자리를 /projects 로 두는 것은 빠뜨린 것이 아니라 그렇게 정한 것이고, 표에 적혀 있으니 다음 사람이 구분할 수 있다.

네 증상이 한 원인이었다

목록 항목에 title·summary·consequences·evidence 가 빠져 있었고, 화면 쪽이 없는 칸을 각자 메우고 있었다.

화면에서 무엇이 보였나	목록 항목에 무엇이 없었나	프론트가 무엇으로 메웠나
제목 자리에 결정문 전문	title	statement 를 제목 자리에 씀
요약 줄이 비어 있음	summary	아무것도 그리지 않음
영향과 근거가 늘 비어 있음	consequences · evidence	빈 배열로 고정

결정문은 한 문장이 아니라 문단일 수 있다. 제목 자리에 전문이 들어가면 목록의 한 줄이 문단 높이로 늘어난다.

줄바꿈은 원인이 달랐다. 마크다운이 아닌 칸의 줄바꿈을 화면이 접고 있었고, 그것은 목록 항목의 문제가 아니라 렌더링의 문제였다.

저장된 값은 그대로 있었다

데이터베이스를 조회하면 작성자가 쓴 제목과 여러 줄 요약과 영향 4건이 있었다. 어느 것도 화면까지 오지 못했다.

Studio 편집기에서는 그 값들이 다 보인다. 두 화면이 같은 데이터를 보는데 한쪽만 비었으므로, 다른 것은 그 사이에 놓인 계약이다.

화면 쪽에서 역으로 확인한다

이 부류는 응답에서 출발하면 보이지 않는다. 응답에 없는 칸을 찾는 일이기 때문이다.

화면이 그리는 칸을 먼저 적고 그 칸이 응답에 있는지 하나씩 맞춰야 한다. 상세 endpoint 가 없는 종류에서는 그 목록이 곧 문서 전체가 된다.

확인하지 못한 것

저장된 값이 그대로였다는 것은 조회로 확인했다. 그 시점의 화면 캡처는 남기지 않았다.